Fix Stefano PDF email delivery path
This commit is contained in:
@@ -77,7 +77,9 @@ Operational rule:
|
||||
- For CAD/public-record lookup, prefer official assessor/CAD pages via `web_fetch` first and `web-automation` second if the site needs rendered interaction.
|
||||
- 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.
|
||||
- If delivery is being performed on Stefano's behalf, do not route it through Luke-only wrappers such as `gog-luke`; use the Stefano/user delivery path configured for this workspace.
|
||||
- If delivery is being performed on Stefano's behalf, use `node ~/.openclaw/workspace/integrations/google-workspace/gw.js send --to "<target>" --subject "<subject>" --body "<body>" --attach "<pdf-path>"`.
|
||||
- Do not route property-assessor delivery through generic `gog`, `gog auth list`, or Luke-only wrappers such as `gog-luke`.
|
||||
- If the agent needs to confirm the active Stefano identity before sending, use `node ~/.openclaw/workspace/integrations/google-workspace/gw.js whoami`.
|
||||
- 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.
|
||||
|
||||
Reference in New Issue
Block a user