Merge commit 'c269781985cb163345d5a01b0ceb0f10ea19b6e0' into torch/session-manager

.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

.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

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`

docs/TODO.md

@@ -88,13 +88,27 @@ 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 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)
 

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.

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.