diff --git a/.torch/prompts/COMMON.md b/.torch/prompts/COMMON.md index c4d27fd..db9b900 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, @@ -19,6 +55,54 @@ 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. + +## 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. + +## 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 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 bc0e0e6..c8ffd17 100644 --- a/docs/TODO.md +++ b/docs/TODO.md @@ -72,6 +72,43 @@ 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. +- [ ] `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 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, + 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. +- [ ] `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) diff --git a/reports/audit/first-development-pilot-2026-09-30.md b/reports/audit/first-development-pilot-2026-09-30.md index b5e430a..520e784 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. @@ -94,3 +104,95 @@ 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. + +## 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. + +## 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. 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.