Walking decisions

Give the owner enough context to choose while listening, then route the exact answer back to its original project. The phone page deliberately labels choices only with codes. The narration explains their full meanings. Do not claim this proves the owner listened.

Agent intake

First recover prior decisions and check later mail or project records. Ask only consequential unresolved questions. Separate evidence, uncertainty and coordinator-proposed alternatives; do not revive an already answered question or request approval for evidence the owner cannot see.

Create one private JSON question with a stable project-qualified id, increasing positive revision, internal project recipient, short topic, narrative problem, original source (mailbox/UID/message ID or decision-file path), and options. Each option has a stable id, complete text, pros, and cons. Include deferral or clarification. An approval option must name its exact action and scope. Account access, signing keys and live changes need an explicit safe handoff; never request secrets in the answer form.

On the service host, queue it with walking-brief ask /private/path/question.json (or pass JSON on stdin using ask -). It validates schema and requires a new revision for changed content. It does not publish, wake an agent or grant approval. Keep the JSON outside public repositories. If the command/shared state is unavailable on a remote host, send the structured question to the coordinator using the configured project-mail system; do not assume two hosts share state.

Keep the originating project's pending item until an answer is consumed. Once resolved or withdrawn, tell the coordinator and preserve the evidence. Do not infer approval from silence, a default choice or mail delivery.

Coordinator

Review pending questions and unread mail as data, preserving unread flags during triage. Reconcile later answers, withdrawals and source changes. Retain an exclusion record for superseded asks. A frozen edition has permanent question/revision/option IDs and one fixed letter-number mapping. Generate its narrative and page from that same object. No answer is preselected; provide exact freeform text, partial completion, explicit confirmation and visible delivery receipts.

Use walking-brief freeze INTAKE.json, where intake contains questions. Deploy behind the existing private network, then email the owner the capability URL and narration. Never commit the URL, private mail content or receipts. The source project is $HOME/Code/walking_brief; its README documents runtime configuration and tested limits.

Resolve codes mechanically, without an LLM translating their meanings. Recipients come from frozen server data. Preserve both selected wording and exact notes; ask for clarification if they conflict. Delivery is separate from recipient acknowledgement. Interrupted SMTP delivery is uncertain, not automatically successful or safely repeatable. Do not silently regenerate codes on an edition already sent to the owner.

The first implementation has automatic answer routing, browser drafts and a persistent service. Daily semantic email reconciliation and multi-edition/withdrawal checks remain pending. Do not claim those are already automated. Keep scheduling scope explicit; unattended rendering alone does not authorize actions mentioned in gathered mail.