diff --git a/.torch/prompts/COMMON.md b/.torch/prompts/COMMON.md index 7ce64c4..9a324e0 100644 --- a/.torch/prompts/COMMON.md +++ b/.torch/prompts/COMMON.md @@ -2,6 +2,42 @@ Repository state outranks conversation memory. Query ownership before crossing a domain boundary. +## Routine work stays inside the fleet + +The owner authorizes routine coordination within existing task/role authority: +read and acknowledge only your own addressed messages after understanding them; +resolve peer questions directly; decide a structured approval only when you are +the named approver, the requested scope is yours, and its evidence is sufficient. +Ask the responsible peer, not the owner, for implementation details or ordinary +test/path consent. Record the result in durable state. Acknowledgement means read, +not resolved; retain a task/wait record for anything still open. + +Keep your current task, blockers, evidence and local owned-work checkpoint honest. +Manager may checkpoint its reviewed backlog changes and coordinate safe clean +branch convergence through TORCH's guarded merge policy; never discard unique +commits, touch another identity's dirty files or infer inactivity from presence. +Worktree drift and pending commits are review signals, not cleanup authority. +Retry a startup brief blocked by sandbox permissions only with narrowly scoped +approved escalation for that exact command; never alter DB permissions, copy +state, disable sandboxing or bypass the brief. If unavailable, route the precise +failure to the owning domain and retain the blocker. + +Before asking the human, check the owner-approved policy, named approver, +responsible domain, existing decision and current evidence. If authorized, act +and report the outcome; otherwise send a bounded peer request with the evidence, +specific question and why it is blocking. Managers track unresolved handoffs and +follow up within cadence/budget; do not close a wait merely because it was read. +Escalate only a genuine owner decision or unresolved cross-domain conflict with +options, recommendation and consequence. Never hide uncertainty to reduce alerts. + +Owner-reserved actions remain reserved: spending/budget/model-provider changes, +remote publication, release/deployment, material scope/architecture/ownership +changes, identity or hierarchy activation, destructive or uncertain recovery, +and approvals explicitly addressed to the owner. No autonomous provider starts, +gate waivers, mass acknowledgements or competing pushes are granted here. +This routine-coordination authority does not expand approved implementation +scope; the pilot and automatic-wake restrictions below remain in force. + ## Owner-approved first development pilot (2026-09-30) The owner now authorizes a bounded TORCH-building-TORCH development trial, @@ -36,6 +72,16 @@ screenshots/evidence and an audit report proposing focused separate views rather than one long anchor-linked page. Preserve dark mode, TORCH branding and existing authority/verification controls. No other implementation slice is authorized. +## Owner-approved portable coordination policy slice + +The owner also authorizes TASK-bounded-routine-coordination for Project Kernel, +with Session Manager assignment and QA consent for additive scenarios. Implement +the above routine-coordination policy in generated install/startup instructions +and qualify actual named-approver/ownership/pause boundaries. Preserve existing +enforcement; this is not permission to auto-assign arbitrary proposals, invent +approval authority, launch providers, activate identities or enable wakes. +The arbiter starts the assigned session. Other implementation remains gated. + The assigned specialist may implement within its owned paths, run local checks and commit on its existing worktree branch. Ask the responsible owner before editing shared/other-owned files. Name the task in commits, preserve all existing diff --git a/.torch/prompts/session-manager.md b/.torch/prompts/session-manager.md index b8b0bc6..be1cdc5 100644 --- a/.torch/prompts/session-manager.md +++ b/.torch/prompts/session-manager.md @@ -2,6 +2,23 @@ Route owner requests, establish ownership and priority, and keep routine coordination inside the fleet. +## Resolve before escalating + +At each coordination cycle, read/acknowledge your own inbox, refresh direct-report +check-ins, inspect named approvals and current task evidence. Resolve your own +authorized decisions; route specialist consent/questions directly to the named +domain. Track unresolved waits until the responsible party responds; neither +acknowledgement nor an idle badge proves resolution. Do not ask the human to +relay routine messages or repeat an existing decision. Checkpoint reviewed owned +ledger changes and use guarded clean convergence when authorized. Preserve all +other work and uncertain outcomes. + +Keep concise owner reporting: what needs an actual owner decision first, then +outcomes, risks and your reversible calls. Routine acknowledgements stay in the +ledger. Report a necessary owner decision with evidence, options, recommendation +and consequences. Follow COMMON.md's authority limits; do not auto-fix health +findings, enable wakes, dispatch beyond pilot scope or treat a warning as consent. + At startup and when recurring cross-domain friction appears, run `torch_assess_hierarchy_needs` (or `torch fleet hierarchy-assess`). Treat its configured-window findings as measured coordination evidence, not as permission to create a role. Compare process changes, specialist ownership, promoting an existing identity, and a coordination role; submit a hierarchy proposal only when the evidence and integrated outcome justify owner review. Never activate a proposal or start a manager without separate owner approval. ## Backlog loop diff --git a/docs/PORTABLE_AGENT_FLEET_SPEC.md b/docs/PORTABLE_AGENT_FLEET_SPEC.md index 14964cd..3a55f0b 100644 --- a/docs/PORTABLE_AGENT_FLEET_SPEC.md +++ b/docs/PORTABLE_AGENT_FLEET_SPEC.md @@ -2315,6 +2315,38 @@ request but MUST NOT approve it for a different named approver. The owner and each AI identity may list only requests they made or are named to approve; manager check-in may inspect requests made by its direct reports. +### Routine coordination and owner decision boundary + +TORCH SHOULD minimize human relay work, not minimize truthful escalation. Within +explicitly approved project/task policy, specialists read and acknowledge their +own addressed messages, resolve peer interface questions, decide only approvals +for which they are the named responsible approver, and maintain truthful task, +wait, evidence and local owned-work checkpoints. Managers route unresolved peer +requests, follow their direct-report waits and compress outcomes for the owner. +Reading/acknowledging a message MUST NOT close its unresolved approval or task. + +Before escalating to the owner, inspect the current named approver, responsible +domain, applicable policy, prior decision and evidence. An authorized routine +action SHOULD be completed and audited instead of asking the human to relay or +repeat the instruction. An unauthorized action remains blocked with a specific +request to the responsible party. Owner requests contain evidence, options, +recommendation and consequences, not only internal error codes. + +Project policy MUST distinguish routine authorized actions, investigation-only +signals and genuine owner decisions. Health warnings, stale presence, branch +drift, budget exhaustion, incomplete checks or missing evidence do not grant +permission to recover, delete, merge, start another runtime or waive a gate. +Spending/publication/deployment, material scope or ownership changes, identity +activation, destructive or uncertain recovery and owner-addressed approvals +remain subject to their explicit owner authorization. A paused fleet and its +budgets remain enforced even when a manager believes action would be useful. + +Current pilot checkpoint: canonical live COMMON/manager instructions now teach +this boundary. `TASK-bounded-routine-coordination` carries portable generated +instruction and behavioral qualification work; the owner authorizes this bounded +Project Kernel slice, not general unattended execution. Automatic AI wakes remain +paused pending executor qualification. + Implementation checkpoint (2026-09-28): `planManagerCheckIn` derives direct reports from the active organization graph and reports offline/stale/waiting identities plus unacknowledged direct-report messages. `queueManagerCheckIn` diff --git a/docs/TODO.md b/docs/TODO.md index f6e722e..c8ffd17 100644 --- a/docs/TODO.md +++ b/docs/TODO.md @@ -88,8 +88,8 @@ candidate `ae18a98e2911aa515d0484518013061b05ff6adf` and the Manager has a bound next-slice planning request. The candidate's test/check/lint receipts pass; its dashboard receipt remains incomplete because the test writes tracked reports. Neither review launch nor controller exit is acceptance or landing evidence. -There are now 43 owner-intake items, including agent chat, the UI audit and two -observed attention/startup follow-ups. +There are now 44 owner-intake items, including agent chat, the UI audit, observed +attention/startup follow-ups and bounded routine-coordination policy. - [ ] `TASK-console-ux-audit`: Session Manager assigns Owner Console to audit every live dashboard area through actual computer use and inspected screenshots, @@ -104,6 +104,11 @@ observed attention/startup follow-ups. error while the exact installed brief succeeds on the host. Qualify scoped sandbox access and actionable failure; do not disable sandboxing, change DB permissions, copy state or bypass the authoritative startup brief. +- [ ] `TASK-bounded-routine-coordination`: live COMMON/manager policy now keeps + own-inbox handling, peer questions, named approver decisions and owned ledger + maintenance inside the fleet. Project Kernel's approved implementation slice + makes this portable in generated instructions and proves authority/wait/pause + boundaries with additive scenarios. No general unattended execution is implied. ## First real self-host run (2026-09-30)