docs: treat explicit email target as send authorization
This commit is contained in:
@@ -33,6 +33,11 @@ scripts/property-assessor --help
|
||||
|
||||
The wrapper script uses the skill-local Node dependencies under `node_modules/`.
|
||||
|
||||
Delivery rule:
|
||||
|
||||
- If the user explicitly says to email or send the finished PDF to a stated target address, that counts as delivery authorization once the report is ready.
|
||||
- The agent should not ask for a second `send it` confirmation unless the user changed the destination or showed uncertainty.
|
||||
|
||||
## Commands
|
||||
|
||||
```bash
|
||||
@@ -71,6 +76,7 @@ Operational rule:
|
||||
- In those messaging runs, reserve subprocess use for a single final `render-report` attempt after the verdict and fair-value range are complete.
|
||||
- In those messaging runs, do not start Gmail/email-send skill discovery or delivery tooling until the report content is complete and the PDF is ready to render or already rendered.
|
||||
- Treat a silent helper as a failed helper in messaging runs. If a helper produces no useful output within a short bound, abandon it and continue with the chat-native path instead of repeatedly polling it.
|
||||
- If the original request already authorized sending the finished PDF to a stated email address, do not pause for a redundant send-confirmation prompt after rendering.
|
||||
- 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`
|
||||
|
||||
@@ -19,6 +19,7 @@ If the user does not say why they want the property assessed, stop and ask befor
|
||||
Do not silently infer or reuse the assessment purpose from earlier turns just because the property address is the same.
|
||||
Only reuse a prior purpose when the user explicitly says it is the same purpose as before.
|
||||
If the current request includes only the property/address plus email or PDF instructions, treat the assessment purpose as missing and ask again.
|
||||
If the current request explicitly says to email or send the PDF to a stated target address, treat that as delivery authorization for that target once the report is ready. Do not ask for a second "send it" confirmation unless the user expressed uncertainty or changed the destination.
|
||||
|
||||
If the property has a unit / apartment / suite number, include it.
|
||||
Do not drop the unit when discovering listing sources. Unit-qualified condo/townhome addresses must be matched as the exact unit, while single-family addresses with no unit should still work normally.
|
||||
@@ -62,6 +63,7 @@ Rules:
|
||||
- Do **not** inspect Gmail/email-send skills, mail tooling, or delivery integrations until the assessment is complete and the PDF is either already rendered or ready to render immediately.
|
||||
- A silent helper is a failed helper in messaging runs. If a background helper produces no useful stdout/stderr and no result within a short bound, stop polling it, treat that path as failed, and continue on the chat-native assessment path instead of narrating that it is still chewing.
|
||||
- Do **not** leave the user parked behind background helper polling. If a helper has not produced a result quickly, give a concise status update and continue the assessment with the next available non-helper path.
|
||||
- If the user already instructed you to email/send the finished PDF to a specific target, do **not** ask for a second send confirmation after rendering. Render, send, and report the result.
|
||||
- If the final PDF render fails, return the complete decision-grade report in chat and say the render/send step failed. Do not restart the whole assessment.
|
||||
- Do **not** run `npm install`, `npm ci`, or other dependency-setup commands during a normal chat assessment flow when the local skill already has `node_modules` present.
|
||||
- On this machine, treat `property-assessor` dependencies as already installed. Use the helper entrypoints directly unless the wrapper itself explicitly reports missing local dependencies.
|
||||
@@ -128,6 +130,7 @@ Agent follow-through rule:
|
||||
- If the user sends `update?`, `and?`, or similar mid-run, answer with status and keep the original assessment going. Do not treat that message as a reset or a cue to stop at the last helper checkpoint.
|
||||
- In WhatsApp or similar messaging runs, do **not** start a background `assess` helper and then wait on repeated zero-output polls. That counts as a failed path; abandon it and continue with native search/fetch/browser work.
|
||||
- In WhatsApp or similar messaging runs, do **not** start mail-sending or mail-skill discovery before the report content, verdict, and delivery artifact are ready.
|
||||
- Once the report is ready, treat an explicit prior instruction like "Email pdf version to me at <address>" as sufficient authorization to send.
|
||||
|
||||
## Public-record enrichment
|
||||
|
||||
|
||||
Reference in New Issue
Block a user