fix: make property-assessor safer for whatsapp runs
This commit is contained in:
@@ -67,6 +67,9 @@ Operational rule:
|
||||
- Preliminary helper output should be treated as structured scaffolding for the remaining work, not as a reason to stop and wait for another user nudge.
|
||||
- In chat/messaging runs, do not waste the turn on `npm install` or `npm ci` when the local skill dependencies are already present.
|
||||
- If the user asks `update?` or `and?` mid-run, treat that as a status request and continue the same assessment rather than restarting or stopping at the last checkpoint.
|
||||
- In WhatsApp or similar messaging runs, keep the core analysis on native `web_search`, `web_fetch`, and bounded browser actions. Do not make helper subprocesses the default path for discovery, CAD lookup, or photo extraction.
|
||||
- In those messaging runs, reserve subprocess use for a single final `render-report` attempt after the verdict and fair-value range are complete.
|
||||
- If final PDF render/send fails, return the completed decision-grade report in chat and report delivery failure separately rather than restarting the whole assessment.
|
||||
|
||||
### `assess`
|
||||
|
||||
@@ -84,6 +87,7 @@ Current behavior:
|
||||
- automatically tries to discover Zillow and HAR listing URLs from the address when no listing URL is provided
|
||||
- runs Zillow photo extraction first, then HAR as fallback when available
|
||||
- reuses the OpenClaw web-automation logic in-process instead of spawning nested helper commands
|
||||
- fails fast when Zillow/HAR discovery or photo extraction stalls instead of hanging indefinitely
|
||||
- returns a structured preliminary report payload
|
||||
- does not require recipient email(s) for the analysis-only run
|
||||
- asks for recipient email(s) only when PDF rendering is explicitly requested
|
||||
@@ -226,7 +230,9 @@ When those extractors return `imageUrls`, that returned set is the photo-review
|
||||
|
||||
## Approval-safe command shape
|
||||
|
||||
For chat-driven runs, prefer file-based commands.
|
||||
For local/manual runs, prefer file-based commands.
|
||||
|
||||
For chat-driven messaging runs, prefer native `web_search`, `web_fetch`, and bounded browser actions first. Treat these commands as local/manual helpers or non-chat fallbacks, not as the default core-analysis path.
|
||||
|
||||
Good:
|
||||
|
||||
@@ -240,6 +246,13 @@ Good:
|
||||
- `scripts/property-assessor render-report --input ... --output ...`
|
||||
- `web_fetch` to read an official CAD / assessor page when the TypeScript helper needs a plain page fetch
|
||||
|
||||
Messaging default:
|
||||
|
||||
- `web_search` to discover listing and public-record URLs
|
||||
- `web_fetch` for official CAD / assessor pages and accessible listing pages
|
||||
- bounded `web-automation` actions for rendered listing/photo views
|
||||
- one final `scripts/property-assessor render-report ...` attempt only after the decision-grade report is complete
|
||||
|
||||
Avoid when possible:
|
||||
|
||||
- `node -e "..."`
|
||||
|
||||
Reference in New Issue
Block a user