docs: treat explicit email target as send authorization

This commit is contained in:
2026-03-28 01:40:47 -05:00
parent d2d43df24d
commit a88d960ec9
2 changed files with 9 additions and 0 deletions

View File

@@ -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`

View File

@@ -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