Context
/do now pushes one-way notifications at human gates / hard stops / completion (see references/notify.md, PR #10). Two-way — approve/deny or open-ended direction from the phone — was prototyped over ntfy.sh and works end-to-end (tapping an action button POSTs the reply to a topic; the run long-polls it and acts). It was pulled for a real security reason.
Why one-way for now
An open ntfy.sh topic is unauthenticated:
- Anyone who knows/guesses the reply topic could POST a fake
approve and inject a decision into a running machine — authorizing a gate the operator never saw.
- The publish topic is readable by anyone who knows it (gate context: DDL, what's being built) — a confidentiality leak.
Approving red gates from an unauthenticated channel is unacceptable, so responses are deferred until an authenticated channel is wired.
What to build
An authenticated two-way channel that keeps the same shape (push a gate → tap/reply on phone → the run receives it), where a response cannot be forged by a third party. Preferred: Slack (operator's lean; interactive Block Kit buttons + typed replies, bot-token auth, mobile app — needs socket mode or an interactions webhook). Telegram bot is the lighter alternative (bot-token auth, inline keyboards + typed replies, agent long-polls getUpdates, no server).
Then re-enable in /do's Autonomy & safety tiers the deferred behavior: a red gate that only needs a decision → ask and wait for the authenticated reply, act on it — but a production mutation is still never executed by the agent even when approved (prepare it, hand back the exact command). Schedule a self-wakeup so independent work proceeds while a gate waits.
Constraints / decisions already made
- Config lives in the consumer repo's
AGENTS.md (Run notifications), never in the synced skills; unset → silent no-op.
- Messages are plain, glanceable across concurrent runs (
[item] stage — why), no secrets/PHI in bodies.
- Production execution is never delegated to a phone approval.
Notes from the prototype
- ntfy mobile app: does not render Markdown (send plain text), HTTP action buttons are Android + iOS (iOS via detail view), max 3 actions,
--data-binary needed to preserve newlines.
- The one-way path (this PR) is the safe baseline to keep regardless.
Context
/donow pushes one-way notifications at human gates / hard stops / completion (seereferences/notify.md, PR #10). Two-way — approve/deny or open-ended direction from the phone — was prototyped overntfy.shand works end-to-end (tapping an action button POSTs the reply to a topic; the run long-polls it and acts). It was pulled for a real security reason.Why one-way for now
An open
ntfy.shtopic is unauthenticated:approveand inject a decision into a running machine — authorizing a gate the operator never saw.Approving red gates from an unauthenticated channel is unacceptable, so responses are deferred until an authenticated channel is wired.
What to build
An authenticated two-way channel that keeps the same shape (push a gate → tap/reply on phone → the run receives it), where a response cannot be forged by a third party. Preferred: Slack (operator's lean; interactive Block Kit buttons + typed replies, bot-token auth, mobile app — needs socket mode or an interactions webhook). Telegram bot is the lighter alternative (bot-token auth, inline keyboards + typed replies, agent long-polls
getUpdates, no server).Then re-enable in
/do's Autonomy & safety tiers the deferred behavior: a red gate that only needs a decision → ask and wait for the authenticated reply, act on it — but a production mutation is still never executed by the agent even when approved (prepare it, hand back the exact command). Schedule a self-wakeup so independent work proceeds while a gate waits.Constraints / decisions already made
AGENTS.md(Run notifications), never in the synced skills; unset → silent no-op.[item] stage — why), no secrets/PHI in bodies.Notes from the prototype
--data-binaryneeded to preserve newlines.