From ed1f7614d1ea2634c24c9967a673d753f32c8080 Mon Sep 17 00:00:00 2001 From: thePR0M3TH3AN Date: Wed, 30 Sep 2026 16:32:52 -0400 Subject: [PATCH 1/6] Record first pilot verification blocker and provider handover gate --- docs/TODO.md | 6 ++++++ reports/audit/first-development-pilot-2026-09-30.md | 10 ++++++++++ 2 files changed, 16 insertions(+) diff --git a/docs/TODO.md b/docs/TODO.md index bc0e0e6..a7c764a 100644 --- a/docs/TODO.md +++ b/docs/TODO.md @@ -72,6 +72,12 @@ pilot reliability issues have also been added to the same backlog: handling instead of equating installed files with an operational timer. - [ ] `TASK-pilot-executor-outcomes`: zero exit plus timeout/error/signal cannot produce a successful lifecycle/wake receipt; qualify before automatic wakes. +- [ ] `TASK-pilot-generated-check-artifacts`: retain exact-commit check artifacts + outside the tested tree and safely recover proven generated outputs so a gate + does not make the following required gate fail WORKTREE_DIRTY. +- [ ] `TASK-provider-handover`: after release qualification, checkpoint and safely + switch one session then the fleet to reviewed Claude Code/Pi profiles; preserve + TORCH identity/tasks/messages but never reuse another harness's native session ID. ## First real self-host run (2026-09-30) diff --git a/reports/audit/first-development-pilot-2026-09-30.md b/reports/audit/first-development-pilot-2026-09-30.md index b5e430a..e2f3e9a 100644 --- a/reports/audit/first-development-pilot-2026-09-30.md +++ b/reports/audit/first-development-pilot-2026-09-30.md @@ -81,6 +81,16 @@ issues were added through audited owner intake: starting presence, native unit rendering/operational status and executor timeout/outcome semantics. The manager backlog remains the authoritative queue, separate from this narrative report. +Recovery follow-up: the specialist produced regression commit `2f1ca15` but exact +TORCH check planning was blocked by five tracked report images generated by the +dashboard gate. The owner/arbiter gave narrow reversible archive-and-restore +directions for proven check-owned outputs, not permission to rewrite expectations. +`TASK-pilot-generated-check-artifacts` records the durable fix. The explicitly +requested post-quality-release whole-fleet provider migration now has its own +`TASK-provider-handover`, dependent on release qualification. Total intake is +39 items (34 original follow-ups plus five later pilot/handover items); one real +implementation assignment does not imply the rest are dispatched. + 1. Finish diagnostics regression evidence and independent QA review. 2. Fix executor outcome/launch-presence guards and qualify one real bounded wake. 3. Complete reviewed automatic init/install onboarding and persistent operations. From 0224abf2e08de0b9e9d44ebddb3cea66b5076c13 Mon Sep 17 00:00:00 2001 From: thePR0M3TH3AN Date: Wed, 30 Sep 2026 18:20:05 -0400 Subject: [PATCH 2/6] Record owner-approved computer-use Console audit and chat roadmap --- .torch/prompts/COMMON.md | 17 +++++++++++ docs/TODO.md | 17 +++++++++++ .../first-development-pilot-2026-09-30.md | 28 +++++++++++++++++++ 3 files changed, 62 insertions(+) diff --git a/.torch/prompts/COMMON.md b/.torch/prompts/COMMON.md index c4d27fd..7ce64c4 100644 --- a/.torch/prompts/COMMON.md +++ b/.torch/prompts/COMMON.md @@ -19,6 +19,23 @@ coordinate its Release/QA boundaries and request independent review. Do not dispatch other development items in this first pilot. The outer arbiter controls provider starts, integration authorization and the next slice. +## Owner-approved parallel Console audit (2026-09-30) + +The owner additionally authorizes TASK-console-ux-audit for owner-console. +Session Manager may triage and assign that exact task while diagnostics QA +continues. The arbiter launches the assigned UI session; managers still must not +launch providers. This is a browser-based audit and design proposal, not a +dashboard rewrite or release. Audit the actual live Console through computer +use: navigate every area, inspect screenshots and interactions at desktop and +mobile sizes, and document coverage. Read applicable frontend-design and browser +skills before browser use. If computer-use tools are unavailable, report that +specific blocker; source inspection alone is not completion. Do not substitute +generated screenshots for actually viewing the interface. Keep live state +read-only; use the isolated demo for exploratory mutations. Publish task-owned +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. + 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/docs/TODO.md b/docs/TODO.md index a7c764a..a722d56 100644 --- a/docs/TODO.md +++ b/docs/TODO.md @@ -78,6 +78,23 @@ pilot reliability issues have also been added to the same backlog: - [ ] `TASK-provider-handover`: after release qualification, checkpoint and safely switch one session then the fleet to reviewed Claude Code/Pi profiles; preserve TORCH identity/tasks/messages but never reuse another harness's native session ID. +- [ ] `TASK-owner-agent-chat`: persistent per-agent owner conversations for the + Manager and every activated domain, durable replies and clear queued/delivered/ + running/failed outcomes. Reviewed wake-on-message must respect pauses, budgets + and runtime leases; qualify executor outcomes and starting presence first. + +The owner approved continuing the controlled pilot. Independent QA now has exact +candidate `ae18a98e2911aa515d0484518013061b05ff6adf` and the Manager has a bounded +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 41 owner-intake items, including agent chat and the UI audit. + +- [ ] `TASK-console-ux-audit`: Session Manager assigns Owner Console to audit + every live dashboard area through actual computer use and inspected screenshots, + including desktop/mobile and keyboard/refresh behavior. Owner rejects the long + single-page/anchor-navigation layout. Propose focused separate screens, concise + overview and contextual drilldowns. Audit/proposal only; no UI rewrite yet. ## First real self-host run (2026-09-30) diff --git a/reports/audit/first-development-pilot-2026-09-30.md b/reports/audit/first-development-pilot-2026-09-30.md index e2f3e9a..8c11e83 100644 --- a/reports/audit/first-development-pilot-2026-09-30.md +++ b/reports/audit/first-development-pilot-2026-09-30.md @@ -104,3 +104,31 @@ Receipts are under `/tmp/torch-pilot-*`, including repaired full-source acceptan native parser tests, scheduler installation/reconciliation, durable wake/run state and owner-request messages. The live dashboard and actual branch state take precedence over historical progress descriptions in this report. + +## Continued pilot and owner UX feedback + +The owner approved continuing the controlled pilot and is watching the Console. +Independent QA reviewed candidate `ae18a98e2911aa515d0484518013061b05ff6adf`: +the lifecycle scenario independently PASSed 7/7, with no assertion relaxation. +QA accepted code/scenario content, **not integration qualification**. Required +dashboard receipt remains incomplete and canonical convergence remains required. +QA's durable report is message `8275d64a-7b28-49ee-a379-2c6d0bdcacb3`. + +Two additional owner-intake proposals bring the backlog to 41: + +- `TASK-owner-agent-chat`: threaded durable owner conversations and reviewed + wake-on-message after executor/presence qualification. Current agent message + recipient validation does not permit the owner as a recipient; owner replies + need a distinct authorized API, not an invented specialist identity. +- `TASK-console-ux-audit`: the owner rejects excessive scrolling and a generic + all-in-one-page dashboard. Session Manager has an explicit bounded assignment + request for existing Owner Console. Require actual computer-use navigation, + inspected screenshots of every current area, desktop/mobile and interaction + coverage, and a focused multi-screen proposal. Live state is read-only; demo + may exercise mutations. Missing browser tools are a blocker, not permission + to claim a source-only audit completed the request. + +Canonical COMMON now permits this audit in parallel with diagnostics QA, without +authorizing UI implementation, unrelated dispatch, automatic wakes or release. +The arbiter launches Owner Console only after actual manager assignment; a +request in an inbox is not itself assignment evidence. From 7b7c6584b9d315d901133cff828f26f0fcc2003f Mon Sep 17 00:00:00 2001 From: thePR0M3TH3AN Date: Wed, 30 Sep 2026 19:04:13 -0400 Subject: [PATCH 3/6] Document observed live Console usability and attention findings --- docs/TODO.md | 11 +- .../first-development-pilot-2026-09-30.md | 26 ++++ .../live-console-arbiter-audit-2026-09-30.md | 145 ++++++++++++++++++ 3 files changed, 181 insertions(+), 1 deletion(-) create mode 100644 reports/design-system/live-console-arbiter-audit-2026-09-30.md diff --git a/docs/TODO.md b/docs/TODO.md index a722d56..f6e722e 100644 --- a/docs/TODO.md +++ b/docs/TODO.md @@ -88,13 +88,22 @@ 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 41 owner-intake items, including agent chat and the UI audit. +There are now 43 owner-intake items, including agent chat, the UI audit and two +observed attention/startup follow-ups. - [ ] `TASK-console-ux-audit`: Session Manager assigns Owner Console to audit every live dashboard area through actual computer use and inspected screenshots, including desktop/mobile and keyboard/refresh behavior. Owner rejects the long single-page/anchor-navigation layout. Propose focused separate screens, concise overview and contextual drilldowns. Audit/proposal only; no UI rewrite yet. +- [ ] `TASK-console-attention-actions`: meaningful condition/agent/branch labels, + deduplicated findings and contextual quick actions. Owner approve/reject uses + existing evidence/revision/preview confirmation; never clear peer messages, + merge branches or publish to a remote through a generic warning button. +- [ ] `TASK-pilot-brief-sandbox`: the first UI audit stopped at a read-only SQLite + 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. ## First real self-host run (2026-09-30) diff --git a/reports/audit/first-development-pilot-2026-09-30.md b/reports/audit/first-development-pilot-2026-09-30.md index 8c11e83..791ef7b 100644 --- a/reports/audit/first-development-pilot-2026-09-30.md +++ b/reports/audit/first-development-pilot-2026-09-30.md @@ -132,3 +132,29 @@ Canonical COMMON now permits this audit in parallel with diagnostics QA, without authorizing UI implementation, unrelated dispatch, automatic wakes or release. The arbiter launches Owner Console only after actual manager assignment; a request in an inbox is not itself assignment evidence. + +## Attention-panel triage and audit recovery + +Session Manager assigned `TASK-console-ux-audit` to Owner Console at revision 3. +The first audit turn **did not perform browser coverage**: installed `torch brief` +failed with `ERR_SQLITE_ERROR` / read-only database. The identical installed brief +passes from the host. The arbiter resumed the same session with directions to +request narrowly scoped escalation for that exact command, not change permissions +or skip the guard. `TASK-pilot-brief-sandbox` captures durable qualification. + +Owner additionally requests contextual quick actions in Needs your attention. +`TASK-console-attention-actions` requires meaningful per-agent/branch findings, +deduplicated messages and owner-only reviewed approve/reject actions. Total +owner intake is now 43. It does not authorize warning dismissal, blanket message +acknowledgement, automatic merging or remote publication. + +Observed worktree warnings: manager backlog updates are dirty, and manager and +Provider Runtime retain unique commits. These are preserved task state and +unlanded work, not permission to remove worktrees or discard commits. The manager +has a narrowly authorized local backlog checkpoint/convergence request and must +review its own inbox. Provider code still requires integration gates. + +Recovery is `ONE-DISK` for current rewrite HEAD: origin exists, but local +remote-tracking references do not contain that commit. This is not proof of a +live remote query. Off-machine synchronization requires an explicit owner +publication/backup decision; no remote push or default-main promotion occurred. diff --git a/reports/design-system/live-console-arbiter-audit-2026-09-30.md b/reports/design-system/live-console-arbiter-audit-2026-09-30.md new file mode 100644 index 0000000..417a239 --- /dev/null +++ b/reports/design-system/live-console-arbiter-audit-2026-09-30.md @@ -0,0 +1,145 @@ +# Live Console arbiter usability audit + +## Evidence and scope + +Owner requested direct inspection of `http://127.0.0.1:4174/console` and a report +to Session Manager. Inspected the real installed workspace in the connected Brave +browser using interactive navigation, DOM observations and actually viewed +viewport screenshots. No live task, approval, profile, release or message was +mutated through the browser. Expanded the request composer and one incomplete +check receipt only. Screenshots were viewed in this audit conversation; no new +artifact catalog or saved screenshot files are claimed. + +Visited all ten navigation entries: Overview, Briefing, Flow watch, Work, +Progress, Fleet, Conversations, Organization, Evidence and Release gates. +Temporary narrow viewport was reset afterward. Desktop DOM viewport was +1253×685. Requested mobile override 390×844 produced reported CSS viewport +433×938 in this browser; responsive measurements below use the reported values. +No full keyboard audit, draft/refresh experiment, approval submission, empty/error +simulation or hidden Operations panel coverage is claimed. Those remain the +assigned UI agent's coverage requirements. + +## Prioritized findings + +### P1: one document makes monitoring impractical + +Desktop document height measured 50,288 pixels. Work occupied 36,662 pixels, +Conversations 5,723 and Organization 2,931 at the observation point. Navigation +changes URL fragments and scroll position rather than opening focused views. +The masthead/project/freshness controls scroll away on lower sections. Current +nav styling exists, but every navigation link lacked `aria-current`. + +Use addressable separate screens with persistent project context. Keep Overview +to a concise pulse, real decisions, blockers and recent outcomes. Route detail +links to exact task, agent, check or decision rather than a broad section. + +### P1: work-card density dominates the page + +There were 43 active tasks, including 41 Queue cards. Narrow desktop kanban +columns wrap IDs and titles heavily and show full long descriptions. Filtering, +saved-view editing and task creation sit above the actual work. At narrow size, +the filter block alone measured approximately 572 CSS pixels, followed by a +horizontally navigated kanban. + +Use compact task summaries with a detail drawer/page. Separate proposed backlog +from active work by default; retain one authoritative task system. Put secondary +filters/saved-view editing behind an intentional control. Mobile should offer a +usable list or selected-column view, not require navigating every column. + +### P1: attention is opaque and duplicates the same condition + +Actual Overview repeated MESSAGE_BACKLOG plus the unacknowledged message count, +and three WORKTREE_PROBLEM entries all said only “Doctor reported a project +condition to review.” Unique commits and manager backlog edits are not equivalent +to a failed merge or missing tree. The Healthy badge can imply more operational +readiness than these conditions justify; the existing doctor threshold may be +valid, but the UI label should describe its narrower meaning. + +Implement `TASK-console-attention-actions`: group and deduplicate actual entities, +name identity/branch/reason, distinguish safety gates from routine agent progress. +Offer owner Approve/Reject only for an actual pending owner-addressed approval, +using current revision/evidence preview-confirm checks. Offer exact inspect, +message/review or supported recovery actions otherwise. No blanket dismiss, +peer-message acknowledgement, merge, deletion or publication shortcut. + +### P1: conversations is an internal transcript, not owner chat + +Two-column entries expose entire long coordination instructions. There is no +agent-thread picker, compact subject/task grouping or focused reply experience. +The expanded installed request composer displayed “Install a reviewed Fleet +before sending owner requests” while identity options were populated and Preview +request was present. This contradicts the installed workspace state. Existing +request composition is not a native owner reply channel or automatic wake. + +Implement `TASK-owner-agent-chat` with truthful per-agent threading, delivery and +reply states. Keep engineering message detail expandable; show concise relevant +summaries first. Fix stale placeholder status from actual capability state. + +### P2: fleet, ownership and organization repeat technical metadata + +Fleet repeats runtime/model/profile text and mixes implementation paths with +session monitoring. Organization cards repeat peer links and large owned-path +lists; the QA role shows an extensive historical report-file inventory. These +are useful audit details but poor default monitoring content. + +Use a compact agent table/list showing work, state, last evidence, blocker and +chat/open actions. Put ownership paths and authority into agent detail. Use an +actual hierarchy/relationships view for Organization with a details inspector. +Do not replace observed presence with inferred process liveness. + +### P2: briefing and progress do not provide a quick owner outcome + +Briefing was unpublished and instructed the owner to run digest build/publish CLI +commands. Progress showed feature/milestone group totals but did not provide an +obvious exact-task drilldown. Preserve its good distinction between task progress +and verification/release readiness. + +Provide permission-aware local generate/review/publish flow when supported and +link progress groups to filtered work. Do not send notifications or publish a +release as a side effect of preparing a local briefing. + +### P2: evidence is honest but recovery navigation is weak + +Expanded test-dashboard receipt correctly showed incomplete, +worktree-changed-during-check, exact SHA and missing frozen/condition evidence. +This is valuable and must remain strict. Artifacts are not connected yet; +integration/delivery records are empty and correctly avoid implying deployment. +Flow watch still said timer installation not verified despite the earlier +host-qualified timer; review how operational evidence reaches this snapshot, +rather than merely removing the warning. + +Add links from an incomplete check to its task, author, candidate and blocking +condition. Show the reviewed next step without turning “retry” into an automatic +repeat of uncertain effects. Place receipts and advanced operational detail on +the relevant screen, not below every unrelated workflow. + +## Proposed information architecture + +- Overview: concise project outcome, decisions, blockers, recent events. +- Work: active work; compact proposed backlog; filters and exact task detail. +- Agents: state/work/waits, per-agent chat and profile/ownership detail. +- Pipelines: conditional project-defined flows, deliverables and stage history. +- Evidence: checks/artifacts with exact task/commit links and review actions. +- Releases: integration, delivery and separately authorized recovery. +- Organization / Settings: hierarchy, ownership, operations and configuration. + +Briefing may be accessible from Overview; advanced operational panels should have +their own destination. Retain dark mode and original TORCH mark. Avoid filling +every view with duplicate cards or decorative labels. + +## Implementation acceptance recommendations + +1. A navigation action displays only its focused workspace, preserves project + identity/freshness, and supports addressable reload/back/forward behavior. +2. Forty-plus proposed tasks do not make Overview or agent conversations taller; + compact cards and bounded/paginated detail preserve all underlying records. +3. Attention is entity-specific and deduplicated, with authority-aware actions + and unchanged stale-preview/revision/evidence safety checks. +4. Installed request status derives from current capability, not leftover loading + copy. Per-agent threads remain readable after reload and provider changes. +5. Narrow/mobile monitoring reaches work and actions without a full-screen wall + of filters; current navigation is accessible via focus and `aria-current`. +6. Independent browser scenarios verify navigation, refresh/drafts, mobile, + pending approvals, wrong approver, incomplete checks and failed launches. + +This report is audit evidence and a proposal, not implementation qualification. From c269781985cb163345d5a01b0ceb0f10ea19b6e0 Mon Sep 17 00:00:00 2001 From: thePR0M3TH3AN Date: Wed, 30 Sep 2026 19:09:01 -0400 Subject: [PATCH 4/6] Define bounded routine fleet coordination and owner decision gates --- .torch/prompts/COMMON.md | 46 +++++++++++++++++++++++++++++++ .torch/prompts/session-manager.md | 17 ++++++++++++ docs/PORTABLE_AGENT_FLEET_SPEC.md | 32 +++++++++++++++++++++ docs/TODO.md | 9 ++++-- 4 files changed, 102 insertions(+), 2 deletions(-) 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) From 3ca70f2d43be3eac1a4df26d8aa485f58e239beb Mon Sep 17 00:00:00 2001 From: thePR0M3TH3AN Date: Wed, 30 Sep 2026 19:15:18 -0400 Subject: [PATCH 5/6] Authorize next bounded executor and check-artifact reliability slices --- .torch/prompts/COMMON.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/.torch/prompts/COMMON.md b/.torch/prompts/COMMON.md index 9a324e0..db9b900 100644 --- a/.torch/prompts/COMMON.md +++ b/.torch/prompts/COMMON.md @@ -82,6 +82,27 @@ 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. +## Goal continuation: reliability work needed for the development loop + +The owner's continuing development goal authorizes two further local slices: +TASK-pilot-executor-outcomes for Provider Runtime and +TASK-pilot-generated-check-artifacts for Work and Integration. Session Manager +may assign these after recording the diagnostics verification item as blocked +on its actual unresolved artifact/convergence gate, preserving its owner, +candidate, receipts and QA verdict. Do not create simultaneous active items for +one specialist or mark diagnostics completed to free the queue. + +Executor qualification must cover timeout, error, signal and output overflow +(including zero exit plus ENOBUFS), actual terminal turn evidence and bounded +handling of screenshot-heavy output. No false successful/idle receipt or exposed +private reasoning. Coordinate exact CLI-owned paths with Release and tests with +QA. Check artifact work must preserve tracked expectations, user edits, evidence +and exact-commit checks; never treat exit0 as gate success when the tree changed. +Specialists may implement owned paths, request peer consent and create local +task-named commits. Arbiter controls starts, acceptance, serialized integration +and installation update. Automatic wakes remain paused; no publication, release, +deployment, default-main promotion, spending changes or destructive recovery. + 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 From 00d6e1fa6c23fae833da3f7198d9c93c387eecdc Mon Sep 17 00:00:00 2001 From: thePR0M3TH3AN Date: Wed, 30 Sep 2026 19:27:07 -0400 Subject: [PATCH 6/6] Record bounded coordination candidate and assigned reliability follow-through --- .../first-development-pilot-2026-09-30.md | 38 +++++++++++++++++++ 1 file changed, 38 insertions(+) diff --git a/reports/audit/first-development-pilot-2026-09-30.md b/reports/audit/first-development-pilot-2026-09-30.md index 791ef7b..520e784 100644 --- a/reports/audit/first-development-pilot-2026-09-30.md +++ b/reports/audit/first-development-pilot-2026-09-30.md @@ -158,3 +158,41 @@ Recovery is `ONE-DISK` for current rewrite HEAD: origin exists, but local remote-tracking references do not contain that commit. This is not proof of a live remote query. Off-machine synchronization requires an explicit owner publication/backup decision; no remote push or default-main promotion occurred. + +## Bounded coordination and reliability follow-through + +The owner clarified that ordinary peer coordination should not require human +relay. Live COMMON and Session Manager instructions now require own-inbox review, +named-approver decisions, durable unresolved waits and direct responsible-peer +follow-up. Spending, publication, releases, scope/ownership changes, destructive +recovery and owner-addressed approvals remain reserved. There are 44 backlog +items; `TASK-bounded-routine-coordination` carries this policy into fresh installs. + +Project Kernel committed candidate `d3a679849b0f5e55c2114223a2e56977c318391e`. +The arbiter independently ran its new routine-coordination test: **2/2 PASS**. +This covers generated instruction surfaces, acknowledgement not completing work, +and named-approver enforcement. It does not independently prove paused runtime +execution or full integration qualification. QA has a review request for that +coverage gap. Kernel reports test/check/lint evidence, but its dashboard gate is +blocked: root Playwright is 1.58.2, Kernel's installed dependency is 1.63.0, and +the latter expects absent `chromium_headless_shell-1243`. QA and manager were +asked to resolve reproducible setup, not waive assertions or use an unverified +browser substitution. + +Session Manager explicitly blocked the earlier runtime diagnostics task while +preserving its accepted candidate and incomplete dashboard receipt. It then +assigned `TASK-pilot-executor-outcomes` to Provider Runtime and +`TASK-pilot-generated-check-artifacts` to Work and Integration, one active item +per specialist. Named QA additive-test/output-plumbing consent and Release CLI +consent were requested through the control plane. The arbiter started their +review turns and both assigned implementation turns using separate owned +transient user services. A running service proves an active launch handle, not +task completion or successful native terminal output. + +Owner Console is continuing its actual browser audit through a bounded temporary +diagnostic launcher. The launcher captures outcome metadata only, checks terminal +turn evidence and refuses false success. Its larger output buffer is diagnostic +recovery, **not an installed engine fix**. The permanent executor task must handle +timeouts, signals, errors, output overflow and uncertain captured identities. +Automatic wakes remain paused; no remote push, release, installation update or +default-main promotion has occurred.