Merge canonical for TASK-pilot-cli-suite-timeout

docs/ADAPTIVE_COMPANY_INTEGRATION_PLAN.md

@@ -0,0 +1,243 @@
+# Adaptive software company: integration plan
+
+Status: owner-approved roadmap direction, 2026-10-01; implementation pending.
+Applies to the Portable Agent Fleet. This document records the supplied adaptive
+software company proposal and the agreed refinements. It does not certify the
+current alpha as unattended or production-ready. The fleet remains manually
+paused until the owner explicitly requests resume.
+
+## Product boundary
+
+TORCH supplies organization, ownership, intent, authority, durable work,
+coordination, evidence, verification, integration and recovery. Coding harnesses
+supply implementation intelligence, tools and temporary delegation. Start with
+the smallest useful organization; do not require a fixed Engineering/Product/QA
+taxonomy or a new permanent AI supervisor. Projects may use different roles.
+
+Preserve worktree isolation, one active implementation assignment per specialist,
+revision-checked mutations, direct peer communication, resource leases, exact
+candidate verification, serialized integration, independent review where required,
+audits and separate release/deployment authority. KB/handbook/working-memory
+requirements remain governed by [Project knowledge](PROJECT_KNOWLEDGE_SPEC.md).
+
+## Existing work: extend, do not replace
+
+This is a staged extension of current systems, not a rewrite. Reuse the current
+identity, organization, backlog, messaging, runtime, checks, resource, integration,
+delivery and schedule services. Owner-approved grants are already proposed as
+`TASK-874ed1e4-9414-4a8f-8575-a6c5aceefc56`; do not build a competing grant system.
+Link first-work intake, event-driven wakes, usage governor, hierarchy pilots,
+starting-presence and provider update-path tasks instead of duplicating them.
+
+The earlier executor-outcome task is completed, but later pilot launches exposed
+stdout-bound/terminal-outcome disagreement. A completed historical task is not
+proof that the later installed runtime is ready for unattended operation.
+Preserve those receipts and qualify the new regression explicitly.
+
+## Phase A: trustworthy runtime state before unattended coordination
+
+Lead domains: Provider Runtime, with Project Kernel and independent QA.
+
+1. Reproduce the installed output-bound failure using bounded deterministic
+   fixtures. Keep parser/transport bounds; do not treat a wrapper's observation
+   as a substitute for an authenticated runtime outcome.
+2. Define startup reservation, process/session ownership, terminal outcome and
+   recovery contracts. Distinguish success, failure, unknown and physically stopped.
+3. Publish guarded starting presence before launching. Coordinate manual,
+   scheduled and controller paths through the same exclusivity mechanism.
+4. Add a supported, owner-attributed recovery operation with executor-stopped
+   evidence, revision/lease checks and audit. Never impersonate a specialist,
+   edit SQLite manually, infer death from a name or drop an unknown reservation.
+5. Qualify manual pause across reboot, quota reset, schedule due, message arrival,
+   upgrade and event replay. Only explicit owner resume can clear this pause.
+
+Exit gate: oversized output, timeout, signal, malformed terminal data and a crash
+between spawn and receipt cannot produce false success or a duplicate launch;
+unknown outcomes remain recoverable and block unsafe actions. Actual installed
+runtime qualification and independent QA are required, not just fixture tests.
+
+## Phase B: scoped capability authority migration
+
+Lead: Project Kernel; extend the existing owner-grants proposal.
+
+Identity identifies the participant; role describes responsibility; an approved
+grant confers authority. Reporting edges and implementation ownership do not
+confer management capabilities. Never interpret delegated user authority as
+permission to impersonate the owner or act outside its explicit scope.
+
+Before coding, inventory identity-special business rules and their CLI, MCP,
+Console, scheduled and internal entry points. Define a single authorization
+service and a capability mapping for each action. Grant records must identify:
+
+- grant ID, issuer/delegation provenance, recipient and required capability;
+- project/domain/task/path scope and operation constraints;
+- approval/reference evidence and policy/grant revision;
+- validity/revocation and whether further delegation is allowed;
+- owner-reserved exclusions and independent-review conflict rules.
+
+Initially migrate the current Session Manager's permitted operations without
+widening permissions. Support preview and explicit approval of broader grants.
+No default wildcard capabilities, hierarchy inheritance or self-granting.
+Evaluate the current grant immediately before effects; audit the actual actor,
+grant, scope, relevant revisions and allow/deny reason.
+
+Exit gate: old permitted actions still work under equivalent grants; ungranted,
+out-of-scope, revoked and stale actions fail across every entry point. A new lead
+can be assigned a bounded capability without source changes. Independent review
+cannot approve its own work merely because it also holds a leadership role.
+
+## Phase C: durable event contract
+
+Lead: Work & Integration, with Kernel/Runtime; extend existing event-driven wakes.
+
+Version events for work-ready/blocked, assignment completion, verification,
+integration readiness, approval requests/decisions, pending messages, resource
+release, runtime observations, schedule due and evidence-backed organization
+pressure. Existing audit records are evidence, not automatically executable orders.
+
+Each event needs an ID, project, type/schema version, source entity and revision,
+actor/cause, timestamp, correlation/causation IDs and deduplication key. Keep
+payloads bounded and avoid credentials, private document bodies or full transcripts.
+
+Define emission and recovery at each state-change boundary. Use transactional
+outbox semantics where one store supports them; when Git/files and SQLite cross
+a boundary, specify a durable journal/reconciliation protocol rather than claiming
+one atomic transaction. Preserve one authority for task state. Define cursor,
+retention, replay and schema-upgrade behavior before enabling consumers.
+
+Exit gate: crash before/after state mutation or event delivery, duplicate delivery,
+out-of-order delivery and replay cannot lose a significant transition or authorize
+a stale action. Event delivery may be at-least-once; effects must be idempotent.
+
+## Phase D: small desired-state reconciler
+
+Lead: Work & Integration / Provider Runtime. No strategy or implementation logic.
+
+For each supported action, observe authoritative current state, compare with
+approved policy and desired work, evaluate eligibility, reserve one bounded action,
+recheck revisions/authority/pause/budget, execute and record the outcome.
+Eligibility is allow, deny or unknown; unknown is not permission to retry.
+
+Begin with durable notices and read-only explanations. Then pilot wake of one
+eligible identity for assigned work, followed by narrowly configured ready-work
+self-claim and integration-authority notifications. Do not automatically approve,
+land, release, deploy, reassign ownership or create identities just because an
+event arrived. Preserve existing checks and authorization gates for each operation.
+
+Require persisted pause/backoff, launch reservations, concurrency limits,
+bounded retry rules, actionable failures and periodic safety reconciliation.
+Queue/backend/usage/model/auth unavailability must not create busy model loops.
+Check budgets before launching, including uncertainty in subscription usage.
+Use minimum useful wake context; a timer is a safety net, not another AI supervisor.
+
+Exit gate: duplicate events cannot duplicate execution; paused or uncertain work
+is never restarted; missed events are found by reconciliation; stale observations
+cannot override a newly revoked grant. Start with an owner-approved bounded pilot,
+manual intervention metric and immediate pause/rollback path.
+
+## Phase E: native execution capabilities and repository evidence
+
+Runtime lead: Provider Runtime. Repository evidence lead: Project Kernel.
+
+Keep execution capabilities separate from lifecycle functions. Describe native
+subagents/delegation, browser/computer use, artifacts, worktrees, background tasks,
+checkpoints and review as advertised, locally available, qualified, unavailable
+or unknown. Bind qualification to executable/version, host, account/config and
+evidence; declarations alone do not prove availability. No model calls merely
+to populate the inventory without approval.
+
+Temporary harness workers are accountable to the persistent TORCH specialist,
+not new roster members. They must not acquire broader TORCH credentials, authority,
+ownership or uncontrolled resource access. Keep delegation provenance and aggregate
+available cost evidence. Coordinate native worktrees with TORCH-owned workspaces.
+Native review is useful but not automatically independent QA. Avoid orchestration
+squared and promote workers only through evidence-backed organizational proposals.
+
+Extend deterministic reconnaissance with bounded workspace/build/module graphs,
+CODEOWNERS, co-change observations, entry points, schemas, deployment/process
+boundaries and recurring cross-domain tasks. Give the Architect provenance,
+coverage and uncertainty, not invented semantic conclusions. Do not execute
+untrusted build tools or fetch history merely to analyze a repository silently.
+
+Exit gate: absent capabilities have honest fallbacks; helper delegation cannot
+expand authority; organization proposals cite real evidence and remain advisory.
+
+## Phase F: owner-oriented onboarding and evidence UX
+
+Leads: Owner Console, Release/Self-host and Kernel. Extend first-work intake.
+
+Offer one guided path through prerequisites/runtime qualification, analysis,
+small-team proposal and rationale, ownership/check gaps, explicit review,
+installation/worktree preview, first-work intake and optional startup. Preserve
+advanced CLI and diagnostics. Do not redefine the existing read-only `init` into
+a mutating command without a documented compatibility decision and tests.
+
+"Company ready" must distinguish configured, launchable and actually operational.
+Missing models/auth, unknown outcomes, unresolved ownership and unqualified checks
+must remain visible. Separate consent for downloads, spending, persistent services,
+agent startup and publication; onboarding cannot override a manual pause.
+
+Show conclusions, reason, evidence and exact artifacts progressively, with stable
+links to commits, check conditions, receipts, decisions and discussions. Derive
+implemented/verified/independently reviewed/integrated/released/live states from
+their actual authorities. Surface unknown coverage and rejected/relaxed criteria;
+green exit alone does not support a claimed business outcome or performance number.
+
+Exit gate: a fresh user can reach useful reviewed work without knowing SQLite,
+runtime IDs or schedule unit internals; desktop/mobile/keyboard browser inspection
+passes. Every important asserted status can be traced to exact evidence.
+
+## Phase G: adaptive organization and storage investigation
+
+Extend existing evolution/hierarchy pilots to evidence-backed contraction,
+promotion and consolidation. Roles must justify recurring outcomes rather than
+headcount. Record baseline/window, hypothesis, costs, success/stop criteria and
+owner-reviewed pilot. Transfer authority, ownership, docs and unfinished work
+safely; never retire an active/dirty/unknown worker. Keep one implementation owner.
+
+Measure bookkeeping friction before changing storage: dirty manager time,
+administrative commits, collisions, checkpoint effort and integration delay
+attributable to state. Compare current tracked records, dedicated state branch
+and Git-intent/SQLite-operations alternatives against offline recovery, export,
+backup and migration requirements. Do not dual-write authoritative task state or
+move it until a separate reviewed decision and recovery tests justify the change.
+
+## Phase H: multi-project and release qualification
+
+Use separate controlled fixtures/pilots for a small web app, monorepo, compiled
+systems project, graphics/game project and optional docs/data-heavy project.
+Record init-to-useful-team, request-to-assignment, verified integration latency,
+owner interventions, coordination volume, launch failures, false greens and
+measured/estimated usage separately. Evaluate organization changes for actual benefit.
+Do not run expensive/live-provider experiments without owner-approved budgets.
+
+Release gates include migrations/backup compatibility, crash-safe lock recovery,
+model/auth preflight, repository relocation, provider update compatibility,
+distribution provenance/signing decision, atomic upgrade/rollback, event replay
+and platform-specific schedule qualification. Remote execution is optional and
+needs a separate trust/deployment boundary, not an implicit requirement.
+
+## Integration and rollback discipline
+
+- Assign bounded slices through the existing backlog; agree shared contracts first.
+- Add scenario-based fault and authority tests with Test Integrity Notes. Do not
+  weaken accepted scenarios or substitute simulated success for installed evidence.
+- Land exact checked commits through the existing integration mechanism, not
+  concurrent direct pushes or a second queue. Keep runtime/parser/security work
+  independently qualified from marketing and UI changes.
+- Ship additive, disabled-by-default policy/config first. Migrations need explicit
+  version/compatibility rules, backup/restore tests and an upgrade preview.
+- Do not roll back a database by blindly activating old code. Define supported
+  data downgrade or fail closed while preserving the new store and receipts.
+- Enable notifications before wakes; qualify one-domain pilot before broad fleet
+  activation. Fresh source is not automatically an installed runtime upgrade.
+- Give the owner a report of configured/enabled/qualified state and remaining gates.
+
+## Backlog index
+
+The authoritative proposals use `TASK-company-` IDs: runtime-recovery,
+authority-migration, event-contract, reconciler, native-capabilities,
+repository-evidence, onboarding, evidence-ux, organization-experiments,
+storage-study and multi-project-qualification. Existing tasks remain authoritative
+for their previously scoped work. New proposals are unassigned until Manager
+triage after explicit owner resume; this document is not another work queue.

docs/CONSOLE_CHAT_AND_COMPACT_CARDS_SPEC.md

@@ -0,0 +1,91 @@
+# Priority Console upgrade: compact cards and agent Chat
+
+Status: owner-approved development requirement; completion is determined by the
+authoritative backlog and exact installed/browser evidence, not this document.
+On 2026-10-03 the owner promoted TASK-owner-agent-chat,
+TASK-console-agent-chat-ui and TASK-console-chat-cards-qualification to urgent.
+The fleet is explicitly resumed. Existing runtime safety gates and any subsequent
+owner pause still apply.
+
+## Immediate owner-facing milestone
+
+Prioritize a minimal usable Chat: approved coordinator selected by default,
+activated-agent selector, durable per-agent history and message composer with
+explicit destination and truthful queued/handled status. Session Manager should
+assign eligible Console/Runtime/QA contributions without stealing active work.
+Keep recovery prerequisites progressing alongside this owner-facing milestone.
+If history/composer can safely ship before automatic wake qualification, propose
+a named, scoped slice through normal triage; do not silently remove dependencies.
+Paused or unqualified messaging may persist but must not trigger provider starts.
+
+## Compact cards and detail modal
+
+Make card-based views a scanning layer rather than full-document readers. Apply
+a shared collapsed-height/max-height policy across data types, with consistent
+heights within each grid/view and responsive size variants. Do not squeeze tables,
+charts or conversations into an arbitrary universal card height.
+
+Show title, state, accountable agent, a two/three-line summary and important
+blockers or decisions. Clamp overflowing ordinary content with an explicit
+View details action. Critical warnings must remain identifiable and accessible;
+provide a concise warning summary and full detail rather than clipping it silently.
+Retain sensible quick actions such as approve/reject on collapsed cards, using
+existing evidence/revision/preview confirmation and authority checks.
+
+Clicking the card's detail affordance opens an accessible modal with complete
+content, evidence, linked conversations/tasks and contextual actions. Nested
+action buttons must not accidentally open the modal or trigger another mutation.
+Modal content may scroll. Preserve underlying view/filter/scroll and unsent input;
+support keyboard access, focus containment/restoration, Escape, labelled headings,
+mobile full-screen details and explicit stale/deleted-record states. Refresh must
+not replace unsaved edits or apply an action against an obsolete revision.
+
+Start with Work and Needs Your Attention, then cover remaining card-based views
+with the same pattern. Do not replace specialist views or create duplicate data.
+
+## Conversational Chat view
+
+Add Chat immediately below Overview in the sidebar. Default to the highest-level
+approved project coordinator, currently Session Manager, not a permanently
+hard-coded identity. Show an empty/explanatory state if none is configured; never
+create or activate an agent to satisfy the screen.
+
+Provide a familiar chronological message stream, composer and selector for every
+activated fleet identity. Persistently show Talking to…, identity, role, runtime
+availability and a distinct visual accent. Colour is supplementary: labels,
+avatars/initials and accessible contrast must also distinguish participants.
+
+Combine durable owner exchanges and publishable inter-agent exchanges involving
+the selected agent, preserving sender, recipient, thread/context and causal links.
+Clearly distinguish direct owner conversation from collapsible routine fleet
+traffic; replying must explicitly target the selected agent or named thread and
+never silently broadcast. Do not claim every harness transcript is available.
+Reuse existing owner-agent-chat/messages and formal Conversations audit view,
+not a parallel conversation database. Include links to tasks, approvals, images
+and supporting evidence. No private chain-of-thought or indiscriminate terminal,
+secret or private-file exposure.
+
+Stream publishable replies/progress only when the adapter supports it; otherwise
+show honest durable-message updates. Expose queued/delivered/being-handled/failed
+outcomes accurately: acknowledgement alone does not mean work is done. Preserve
+drafts per recipient, history on navigation/reload, reconnect deduplication and
+an explicit send destination. New arrivals must not force-scroll a user reading
+history. Keep the composer usable on mobile and by keyboard.
+
+Messages can be saved while paused without waking an agent. Future wake-on-message
+requires separately qualified reservations, budget, authority and owner-approved
+policy. Casual chat does not bypass an explicit approval or grant new authority.
+Use clearly labelled demo fixtures with no live APIs, not private fleet history.
+
+## Acceptance and delivery
+
+Use realistic long content, many senders, agent switches, interrupted delivery,
+stale records and pending owner decisions. Inspect desktop/mobile/keyboard flows
+in an actual browser and retain screenshots. Prove bounded collapsed layout,
+complete details, action correctness, focus restoration, preserved filters/drafts,
+safe refresh, accurate chat attribution and no launch on paused send.
+
+Existing backlog proposals remain authoritative. New high-priority slices cover
+compact cards/details, Chat presentation and independent browser qualification.
+Runtime wake safety remains a prerequisite for execution, not a reason to delay
+safe read-only/chat-intake UI development.

docs/OPS_FLOW_IMPROVEMENT_SPEC.md

@@ -0,0 +1,107 @@
+# Operational flow improvements and Ops responsibility pilot
+
+Owner approved 2026-10-03. Extends SELF_HEALING_QUALIFICATION_PLAN.md and existing
+services, backlog and authority. No additional standing agent is created.
+
+## Operational incidents and wait resolution
+
+An incident connects the existing task, message, approval, check, resource and
+runtime evidence. It does not become a second task ledger. Record stable cause
+identity, accountable resolver, affected work, first/last observation, next action,
+configurable response deadline, escalation authority and resolution evidence.
+Keep received, acknowledged, acted-on and resolved distinct. A reply, timeout,
+state churn or healthy doctor result cannot resolve the underlying condition.
+
+Acceptance scenarios:
+
+- A waits on B, B acknowledges but does not decide: A remains waiting; a due
+  deadline produces one actionable escalation to the correct manager.
+- A current decision resolves the wait: a refreshed observation removes the
+  active escalation, preserving original history and exact decision evidence.
+- Duplicate, reordered or missed notifications: one incident per exact cause,
+  periodic reconciliation catches the missing notification; unrelated candidates,
+  scopes and approvers remain separate.
+- Manager is offline or authority revoked: deterministic monitoring persists
+  the wait and routes only to a currently authorized resolver; it cannot assume
+  approval, impersonate a manager or launch a duplicate executor.
+- Quota/auth failure or an uncertain live executor: persisted hold/backoff and
+  guarded recovery remain; repeated incident notices do not create model loops.
+
+Reuse existing event/reconciler, approval-dedup and attention tasks. Contract/API
+changes require owned review, revision checks and independent QA; no prompt-only
+claim of successful incident handling.
+
+## Source adoption and test/QA handoffs
+
+Provide a supported, attributable path from a legitimate contributor/release
+candidate to registered ownership and native exact-candidate qualification.
+Bind source and destination identities, immutable SHA, ownership/path scope,
+required contributor consent and actual engine/adapter provenance. Preview
+current branch/worktree/assignment/guard/lease state before any mutation.
+
+- A clean exact owner-approved release candidate can be transferred or composed
+  through the supported route and produce fresh native check receipts, independent
+  review and serialized integration without a manual branch reset.
+- Dirty destination, active task/check/lease, stale source or changed approval
+  refuses/defer with an exact remedy and responsible owner; preserve every byte
+  and unique commit. Installation activation never counts as canonical landing.
+- Interrupted/repeated adoption is idempotent; preserve original lineage and
+  failure evidence. Never fabricate receipts or silently change scope.
+- Test handoff has a named test implementer, exact permitted paths/scenarios,
+  candidate/revision binding and reviewer. Approved additive tests can proceed
+  without repeatedly seeking the same consent; new scope needs a new decision.
+- QA rejection returns an actionable issue to a named owner. QA acceptance is
+  exact and independent, never a blanket authority or weakened test criterion.
+
+Extend the existing candidate-source qualification and authority services, not a
+parallel landing queue. Agree owned interfaces and contribution boundaries once,
+then validate them mechanically. Preserve one active assignment per specialist.
+
+## Additive acceptance for existing Chat and evidence tasks
+
+Applies to TASK-owner-agent-chat, TASK-console-agent-chat-ui,
+TASK-company-evidence-ux and TASK-console-attention-actions. Retain all original
+criteria. The installer currently has no owner criterion-amendment API; attach
+this owner-approved addendum by durable references, with manager-owned tracked
+reconciliation rather than unsupported live task-file rewriting.
+
+- Message status distinguishes queued, delivered/observed, acknowledged,
+  action started, decision/result and failed; unsupported stages remain unknown.
+- Configurable response expectations show overdue requests and next resolver,
+  using deterministic reconciliation without duplicate wakes or owner nagging.
+- Explicit permission-denied/provider-unavailable/offline states explain delay;
+  measured response latency is not an invented completion-time guarantee.
+- Separate process activity from implementing, checking, coordinating and waiting.
+  Progress includes timestamp/source and links to exact changes/checks/decisions;
+  unavailable evidence is unknown, not idle, success or a fabricated percentage.
+- A continuously active agent with an unresolved wait is visibly waiting or
+  coordinating; acknowledgements and unchanged status reports never imply useful
+  delivery. Display owner interventions and verified integration separately.
+- Desktop/mobile/keyboard and stale/reconnected observation scenarios preserve
+  current modal accessibility, recipient identity, drafts and approval boundaries.
+
+## Ops responsibility pilot
+
+Provider Runtime is the initial Ops engineering contact, with Work and Integration
+and Release collaborating within their existing implementation ownership.
+Session Manager retains priority/assignment authority. This request creates no
+new role capability, worktree, model choice or overlapping implementation owner.
+Manager must arrange eligible task slices without overloading the existing active
+assignment. Native temporary helpers stay under their responsible identity and
+are used only when supported by the approved runtime policy.
+
+Deterministic monitoring handles routine detection and qualified recovery. Ops
+investigates novel incidents, proposes repairs/runbooks and measures recurring
+failure causes. Ops cannot self-approve checks, overwrite dirty work, change
+product priorities, spend through a paid fallback, or broaden recovery authority.
+
+Review after ten resolved incidents or seven active development days, whichever
+comes first. Record investigation vs waiting time, repeat incidents, escalations,
+owner interventions, regression/recovery failures and displaced implementation
+work. Recommend a dedicated standing Ops specialist only if sustained incident
+load crowds out implementation and a distinct ownership/outcome can be shown.
+Any new identity follows the existing approved organization-change pathway.
+
+Success means fewer repeated unresolved handoffs and owner interventions without
+weaker checks, higher failure rates or unbounded retries. Report the baseline and
+observed result; do not claim the organizational change worked from agent count.

docs/PORTABLE_AGENT_FLEET_SPEC.md

@@ -2743,6 +2743,18 @@ and refuses to replace a launcher path not owned by that installation.
 
 ## 27. User interfaces
 
+The owner-approved [Adaptive software company integration plan](ADAPTIVE_COMPANY_INTEGRATION_PLAN.md)
+extends this architecture with scoped capabilities, durable events, bounded
+reconciliation, native-runtime awareness, evidence UX and project-fit onboarding.
+It preserves current invariants and requires staged migration and qualification;
+it is not a claim that the adaptive-company upgrade is implemented.
+
+Project reference documentation, domain handbooks and provisional working memory
+MUST follow [Project knowledge and domain institutional memory](PROJECT_KNOWLEDGE_SPEC.md).
+This owner-approved extension requires a Git-backed shared KB, durable domain
+ownership, compact agent entry points and a dedicated Console Knowledge view.
+It is a development requirement, not a claim that the feature is implemented.
+
 ### 27.1 CLI
 
 The target command surface includes:

docs/PROJECT_KNOWLEDGE_SPEC.md

@@ -0,0 +1,111 @@
+# Project knowledge and domain institutional memory
+
+Status: owner-approved development requirement, 2026-10-01. Not implemented.
+The fleet remains manually paused; recording this requirement does not authorize
+dispatch, new sessions, model calls, publication or automatic restart.
+
+## Purpose
+
+Give users and agents a shared, evolving project reference, while preserving
+focused domain knowledge across session restarts, provider changes and agent
+replacement. Documentation should explain how the project actually works, not
+be a transcript archive, another backlog or a source of implicit authority.
+
+## Three connected layers
+
+1. **Project KB:** authoritative, Git-backed Markdown documenting architecture,
+   setup, interfaces, workflows, pipelines, troubleshooting and decisions.
+2. **Domain handbook:** a compact entry point owned by the domain, linking to
+   relevant KB pages and recording domain conventions, procedures and pitfalls.
+   Prefer links over duplicated shared contracts. Knowledge belongs to the
+   durable domain identity, not a provider conversation or disposable session.
+3. **Working memory:** current investigations, hypotheses, handoffs and unfinished
+   work. It is explicitly provisional; promotion to reference documentation
+   requires supporting evidence and the ordinary review/integration process.
+
+The existing backlog remains the sole task queue. Handbooks may link to tasks
+and domain coordination summaries but must not become competing task ledgers.
+
+## Storage and adoption
+
+The repository is the source of truth; Console indexes and search results are
+rebuildable projections, never independent authoritative copies. Documentation
+must remain usable offline and without TORCH. Do not require a hosted service,
+particular AI provider or external documentation platform.
+
+During init/analyze, discover existing documentation and propose a project-fit
+navigation and ownership map. Reuse existing directories and conventions rather
+than silently moving documents. For projects without conventions, a candidate
+layout is `docs/knowledge/`, `docs/domains/<domain>/` and a clearly separated
+working-memory area. Exact paths and metadata format need a reviewed implementation
+contract; the layout is not a mandate for every project.
+
+One accountable domain owns each reference page; collaborators and reviewers may
+be named separately. Cross-domain interface documentation retains one owner and
+review links to affected domains. Domain retirement, merge, split or reassignment
+must preserve history and transfer responsibility, not delete institutional memory.
+
+## Agent use and maintenance
+
+Startup/resume briefs expose the compact domain index and essential references,
+not the full KB. Agents retrieve relevant detail on demand and can discover
+cross-domain references without loading unrelated documentation into every context.
+Record which revision was supplied; warn about stale references where detectable.
+
+Completion of a behavior, interface or workflow change requires documentation
+impact to be considered: update affected pages or record why no update is needed.
+Do not make clerical documentation edits a permission to change another domain's
+implementation. Route cross-domain documentation changes through existing ownership
+and review mechanisms and notify affected owners.
+
+Reference pages expose owner, status (draft/experimental/reference/deprecated),
+verification evidence and exact last-verified commit. A timestamp or successful
+render does not prove accuracy. Branch/candidate documentation must not masquerade
+as landed canonical behavior; represent divergence and unknown freshness honestly.
+Flag broken links, missing owners and affected pages needing re-verification.
+Do not automatically certify pages, mass-rewrite them or invent a freshness score.
+
+## Console Knowledge view
+
+Add a dedicated Knowledge screen, not another long Overview section. Provide
+Read-the-Docs-style sidebar navigation, search, breadcrumbs, readable articles,
+stable deep links, responsive/mobile navigation and keyboard accessibility.
+Show owner, status, verified revision, related domains, tasks, pipeline definitions
+and history. Keep handbook, reference and provisional memory visibly distinct.
+
+Offer bounded actions to ask the responsible domain and report outdated content
+through existing durable conversations/intake. Show queued/delivered outcomes;
+these actions must not wake agents while paused or silently grant edit authority.
+Use the same renderer for live project documentation and labelled demo fixtures.
+Do not bundle private project documents into the public marketing demo.
+
+## Safety and portability
+
+Render repository text as untrusted content: sanitize Markdown, block script/raw
+HTML execution, unsafe URL schemes, path traversal and escaping symlinks. Restrict
+indexing/serving to approved documentation roots. Exclude credentials and private
+working-memory content according to explicit project visibility policy, including
+search snippets and cached indexes. External links/imported instructions do not
+override TORCH policy. KB content does not expand operational authority.
+
+## Required acceptance scenarios
+
+- Existing project docs are discovered and linked without moves or overwrite;
+  an empty project receives only a reviewed, project-fit plan.
+- Restart or provider replacement inherits the same domain handbook; unrelated
+  KB bodies are not injected into its startup context.
+- A shared interface change updates its single authoritative page and routes
+  affected-domain notification; unchanged pages are not falsely re-verified.
+- A domain ownership change preserves document history and transfers maintenance
+  responsibility without creating two authoritative copies.
+- Provisional claims and candidate-branch behavior remain distinct from verified
+  reference docs; missing evidence is visible rather than converted into confidence.
+- Navigation, search, deep links, keyboard and mobile use work on a realistic
+  multi-domain project; actual browser inspection is required before UI acceptance.
+- Unsafe Markdown, traversal, symlink escape and private search leakage fail closed.
+- Questions/corrections are durable while paused; no provider launch occurs.
+- Markdown remains readable without TORCH, and the public demo has no private docs
+  or live control-plane calls.
+
+Implementation slices are recorded in the existing authoritative TORCH backlog.
+They remain proposed and unassigned for Session Manager triage after owner resume.

docs/SELF_HEALING_QUALIFICATION_PLAN.md

@@ -0,0 +1,81 @@
+# Bounded self-healing qualification
+
+Owner approved this priority on 2026-10-03. This extends the adaptive-company
+plan and existing authoritative backlog; it is not a second work queue.
+
+## Outcome
+
+TORCH recovers authorized interrupted work without external babysitting. It
+preserves unfinished work, assignments and evidence, never duplicates executors,
+and escalates a genuine decision once with an actionable explanation. Managers
+resolve coordination within delegated authority; deterministic machinery must
+also detect manager/controller failure without relying on the failed agent.
+
+## Execution order and existing owners
+
+1. Provider Runtime / Kernel: finish `TASK-company-runtime-recovery`, including
+   exact stopped-process proof, retained guard/controller-lock recovery, fresh
+   instructions and preservation of dirty work. Qualification and native source
+   adoption/integration remain prerequisites, not gates to bypass.
+2. Release / Runtime / Kernel: finish `TASK-conversation-persistent-operations`;
+   installer-owned services survive reboot, reconcile idempotently and uninstall
+   only manifest-owned resources. Keep dormant-install and explicit activation.
+3. Runtime / QA: prioritize the failure/backoff portion of
+   `TASK-conversation-usage-governor`. Distinguish transient failure, quota,
+   authentication, unavailable model, unknown outcome and owner pause. Circuit
+   breakers must suppress repeated launches for the same unresolved cause.
+4. Kernel / Work: complete the authority/event prerequisites and
+   `TASK-company-reconciler`, with existing `TASK-conversation-event-driven-wakes`
+   and `TASK-conversation-queue-watchdog`. Observe, reserve, recheck authority
+   and revision, execute one bounded action, record and reconcile. No duplicate
+   grant, event, task, messaging or recovery stores.
+5. Manager / Console / QA: report the current wait owner, reason, age, last
+   recovery attempt, next eligible action and exact evidence. Chase dependencies
+   and approvals without inventing permission or sending repeated notices.
+
+Urgent recovery does not preempt a running gate or steal an assignment. Managers
+should resolve existing test/file-boundary handoffs and assign QA-owned tests
+explicitly rather than circulate the same approval request indefinitely.
+
+## Failure-injection acceptance matrix
+
+Run against isolated fixtures and then an installed, owner-approved qualification
+project. Do not intentionally kill the live development fleet to prove recovery.
+
+| Fault | Required observable outcome |
+| --- | --- |
+| Specialist exits mid-task | Retain task/session/evidence and dirty bytes; prove old process stopped before one authorized resume |
+| Process alive but quiet | Inspect tools/check queues and progress evidence; quiet alone never permits kill or guard release |
+| Manager exits | Independent deterministic controller discovers the loss and performs one policy-authorized resume |
+| Controller crashes after reservation | Reconcile exact invocation and durable reservation; no lost or duplicate execution |
+| Crash leaves turn/controller lock | Recover only with exact ownership/process proof; unknown or foreign state fails closed |
+| Reboot or service restart | Restore approved desired state once; preserve explicit manual pause and detached status |
+| Missed/duplicate/out-of-order notification | Periodic reconciliation finds the wait; duplicates and stale revisions cannot repeat effects |
+| Dependency or approval wait | Route to correct authority, record acknowledgement and escalate overdue wait without self-approval |
+| Check/integration conflict | Preserve failed evidence and candidate; return actionable work to its owner without relaxing checks |
+| Transient provider fault | Bounded retries with persisted backoff; no immediate unbounded restart loop |
+| Quota/auth/model unavailable | Persist scoped hold/circuit breaker; report once, no paid fallback or unrelated-provider switch |
+| Pause or authority revoked during recovery | Recheck immediately before effect and stop further launches |
+
+Every accepted case needs exact candidate, controlled conditions, observable
+assertions, original failure evidence and independent QA. Record recovery latency,
+duplicate launches, lost work, retry count and owner interventions. A running
+process, green command, task-state churn or acknowledgement is not itself useful
+delivery. Finish with verified integration and next-work continuation.
+
+## Current spending policy
+
+The owner explicitly enabled unlimited automatic daily turns in alpha.4.2;
+missing subscription telemetry must remain unknown, not become a false credit
+estimate. Do not silently restore a finite cap as part of governor work. This
+specific authorization supersedes older pilot cap instructions, not approval,
+ownership, concurrency, no-progress or provider-failure boundaries. Unlimited
+eligible work is not unlimited retries. No paid API fallback was authorized.
+
+## Completion boundary
+
+Do not close recovery/reconciler umbrellas from focused source tests alone.
+Require installed-runtime failure injection, independent QA, reboot/pause
+qualification and an observed unattended work cycle. Report remaining limitations
+plainly; intentional owner decisions may remain blocked, forgotten handoffs may
+not. No new permanent supervisor is required merely to implement this loop.

docs/TEST_INTEGRITY.md

@@ -1,5 +1,172 @@
 # Test Integrity Notes
 
+## 2026-10-03 — Current unread inbox startup mitigation
+
+```yaml
+test_integrity_note:
+  change_type: new_tests
+  scenarios:
+    - id: SCN-fleet-startup-inbox
+      given: "Manager and specialist each have 102 unread handoffs, exceeding the legacy default history page"
+      when: "Fresh and resumed provider launch messages specify the current unread-inbox request and it is invoked through the registered identity-bound tool"
+      then: "Both launches name the correct identity and retrieve newer messages absent from default history, without acknowledging them or weakening authority; overflow coverage is explicitly uncertain"
+  observable_outcomes:
+    - "Actual provider launch arguments, registered MCP response, newest message identity and unchanged unread count"
+  determinism_controls:
+    - "Hermetic project/worktrees, increasing fixed clock and real local tool; no provider launches"
+  anti_cheat_rationale:
+    prevents:
+      - "Prompt-only proof that never exercises the actual inbox tool"
+      - "Claiming truncated history is complete or reading acknowledges a handoff"
+  relaxation:
+    did_relax_any_assertion: false
+    if_true_explain_spec_basis: ""
+```
+
+## 2026-10-03 — Audited one-day additional allowance
+
+```yaml
+test_integrity_note:
+  change_type: new_tests
+  scenarios:
+    - id: SCN-runtime-continuation-day-override
+      given: "An exhausted owner-approved daily allowance and retained charged attempts"
+      when: "The owner approves a bounded current-UTC-day total and later pauses or the day rolls over"
+      then: "Extra work starts without resetting attempts; non-owner/invalid overrides refuse; pause persists; the following day uses the original daily cap"
+  observable_outcomes:
+    - "Actual launched count, charged attempts, remaining allowance, owner audit and next-day limit"
+  determinism_controls:
+    - "Hermetic project, fixed clock and controlled launch callback; no live provider or host scheduling"
+  anti_cheat_rationale:
+    prevents:
+      - "Erasing usage or permanently removing daily caps on an owner override"
+      - "Allowing a specialist to authorize extra budget or bypass pause"
+  relaxation:
+    did_relax_any_assertion: false
+    if_true_explain_spec_basis: ""
+```
+
+## 2026-10-03 — Owner-configured concurrency
+
+```yaml
+test_integrity_note:
+  change_type: new_tests
+  scenarios:
+    - id: SCN-runtime-continuation-concurrency
+      given: "Seven eligible identities and an approved 48-turn daily cap"
+      when: "The owner raises concurrency to seven, starts a bounded controller, then pauses"
+      then: "Seven pending starts occur before completion; a tighter limit restricts candidates; invalid settings refuse; pause preserves cap, concurrency and charged attempts"
+  observable_outcomes:
+    - "Pending launch count, policy capacity, ledger attempts and refusal codes"
+  determinism_controls:
+    - "Hermetic Git repository, fixed clock, controlled promises and no provider calls"
+  anti_cheat_rationale:
+    prevents:
+      - "Treating sequential starts as concurrency or resetting usage on configuration"
+      - "Tick limits exceeding owner-approved policy"
+  relaxation:
+    did_relax_any_assertion: false
+    if_true_explain_spec_basis: ""
+```
+
+## 2026-10-03 — Visible automatic-work stops
+
+```yaml
+test_integrity_note:
+  change_type: new_tests
+  scenarios:
+    - id: SCN-runtime-continuation-health
+      given: "An enabled pilot exhausts its daily attempt allowance"
+      when: "Observation reads the ledger, next UTC day, pause or malformed state"
+      then: "The exact stop and remaining allowance are visible without resetting or modifying state, and no timer/token qualification is fabricated"
+    - id: SCN-console-continuation-stop
+      given: "A daily cap stop and a specialist no-progress hold"
+      when: "Attention items are projected"
+      then: "The budget decision belongs to the owner, coordination belongs to the manager, and no fake approval action or automatic budget increase is offered"
+  observable_outcomes:
+    - "Live snapshot health, byte-identical ledger and owner/manager attention routing"
+  determinism_controls:
+    - "Hermetic repository, fixed UTC clock, injected executor and plain snapshot fixtures"
+  anti_cheat_rationale:
+    prevents:
+      - "Silent budget exhaustion disguised as healthy idle"
+      - "Resetting a ledger to make work appear available"
+      - "Treating declared policy as a verified running timer or measured usage"
+  relaxation:
+    did_relax_any_assertion: false
+    if_true_explain_spec_basis: ""
+```
+
+## 2026-10-03 — Rolling continuation and bounded no-progress escalation
+
+```yaml
+test_integrity_note:
+  change_type: new_tests
+  scenarios:
+    - id: SCN-runtime-continuation-refill
+      given: "A long manager turn and a short specialist turn occupy two slots; a third identity waits"
+      when: "Only the short turn completes"
+      then: "The third starts before manager completion and the daily attempt cap still holds"
+    - id: SCN-runtime-continuation-no-progress
+      given: "An unchanged unfinished eligible assignment"
+      when: "Two successful executor turns make no recorded task progress"
+      then: "Exactly two specialist turns occur, one durable coordination request is sent, unchanged-work repeats stop, new revisions may resume and unmet dependencies remain ineligible"
+    - id: SCN-runtime-continuation-capacity
+      given: "An owner-started executor already occupies the configured automatic capacity"
+      when: "The continuation controller runs"
+      then: "No additional automatic turn starts and no attempt is charged"
+    - id: SCN-runtime-continuation-fairness
+      given: "One specialist keeps advancing revisions while another eligible identity has not started"
+      when: "A slot becomes available"
+      then: "The least-recently-dispatched peer starts before the returning specialist"
+  observable_outcomes:
+    - "Actual launch ordering, daily charges, coordination messages and explicit held-work reason"
+  determinism_controls:
+    - "Hermetic installed Git projects, manually resolved provider promises and task fixtures; no sleep, network or live model"
+  anti_cheat_rationale:
+    prevents:
+      - "Replacing the batch barrier by raising concurrency"
+      - "Claiming refill only after all turns finish"
+      - "Spending unlimited turns on unchanged work or ignoring dependency gates"
+      - "Ignoring physical executors started outside the controller"
+  relaxation:
+    did_relax_any_assertion: false
+    if_true_explain_spec_basis: ""
+```
+
+## 2026-10-03 — Process-verified runtime presence
+
+```yaml
+test_integrity_note:
+  change_type: new_tests
+  scenarios:
+    - id: SCN-runtime-live-presence
+      given: "A Linux executor holds a real identity guard while durable state is idle"
+      when: "The observation API reads starting, working, approval waiting and terminal phases"
+      then: "Live phases display accurately, semantic waits persist, terminal guards vanish and durable reports are not fabricated"
+    - id: SCN-runtime-live-presence-refusal
+      given: "A guarded identity with injected OS observations"
+      when: "PID is replaced, dead, foreign-user, unavailable or project binding is wrong"
+      then: "It never reports active execution"
+    - id: SCN-runtime-live-presence-legacy
+      given: "A pre-observation guard without a process-start token"
+      when: "The exact TORCH up identity and canonical cwd match or disagree"
+      then: "Only a verified matching live executor displays working"
+  observable_outcomes:
+    - "Observation API state, reportedState, executor source and unchanged durable identity"
+  determinism_controls:
+    - "Hermetic installed repository and injected PID observations for refusal cases"
+    - "Supplemental Linux /proc integration observes the test process itself, with no provider or timing sleeps"
+  anti_cheat_rationale:
+    prevents:
+      - "Painting all idle badges working without process evidence"
+      - "Treating a crashed guard or reused PID as an active agent"
+      - "Hiding approval waits or fabricating heartbeat/task progress"
+  relaxation:
+    did_relax_any_assertion: false
+    if_true_explain_spec_basis: ""
+```
+
 ## 2026-09-30 — Bounded routine coordination
 
 ```yaml
@@ -2716,6 +2883,45 @@ test_integrity_note:
     if_true_explain_spec_basis: ""
 ```
 
+# Candidate source B2 frozen-input and fence boundaries (2026-10-01)
+
+```yaml
+test_integrity_note:
+  change_type: new_tests
+  scenarios:
+    - id: SCN-candidate-bootstrap-one-shot
+      given: "An issued, nonce-bound native admission"
+      when: "It is opened, replayed, expired, foreign, or malformed"
+      then: "Only one bounded private bootstrap opens; every invalid case refuses before child start and exposes no authority handle"
+    - id: SCN-candidate-input-consumption
+      given: "A frozen project-local source snapshot"
+      when: "The original source changes before the fixed Node child reads its cwd"
+      then: "The child observes the captured bytes; snapshot drift refuses"
+    - id: SCN-candidate-execution-boundary
+      given: "A fixed command and explicit bounded environment"
+      when: "Ambient PATH/HOME/cache fallback or output overflow is attempted"
+      then: "Execution refuses or remains non-success"
+    - id: SCN-candidate-fence-closure
+      given: "A private PID1 namespace observation"
+      when: "Descendant closure is absent or uncertain"
+      then: "The outcome is UNKNOWN/INCOMPLETE, never terminal PASS"
+  observable_outcomes:
+    - "No DB, ControlPlane, writer, receipt adapter, or authority FD reaches the child"
+    - "Product input links and special nodes refuse; frozen product S stays under 64MiB/file and 512MiB total"
+    - "Artifact output remains M/artifactManifest; receipt-adapter A is absent and unclaimed"
+  determinism_controls:
+    - "Temporary source trees, fixed Node executable, explicit empty ambient environment, bounded streams, and injected observations"
+    - "No live policy registration, installation, network, cache, or provider process"
+  anti_cheat_rationale:
+    prevents:
+      - "Reading mutated live source instead of captured bytes"
+      - "Replaying a private admission or relabeling fixture output as a receipt"
+      - "Treating PGID emptiness, zero exit, or Chromium metadata as descendant/binary proof"
+  relaxation:
+    did_relax_any_assertion: false
+    if_true_explain_spec_basis: ""
+```
+
 # Console attention advisory cohorts (2026-10-01)
 
 ```yaml
@@ -2765,6 +2971,47 @@ test_integrity_note:
     if_true_explain_spec_basis: ""
 ```
 
+# Candidate source B2 authenticated-attempt spec correction (2026-10-01)
+
+```yaml
+test_integrity_note:
+  change_type: spec_correction
+  scenarios:
+    - id: SCN-candidate-bootstrap-one-shot
+      given: "A CheckService-issued opaque registered-plan handle"
+      when: "A foreign, cloned, expired, replayed, or already-closed handle is used"
+      then: "No FD3 admission opens; the only accepted acknowledgement is the exact FD4 binding frame and it closes the original linear handle"
+    - id: SCN-candidate-input-consumption
+      given: "A frozen, bounded product snapshot and a fixed Node E binding"
+      when: "The original product bytes change before execution"
+      then: "An actual spawned child reads the frozen bytes; post-capture drift refuses before spawn"
+    - id: SCN-candidate-execution-boundary
+      given: "An opaque attempt with fixed command, arguments, explicit environment, and output cap"
+      when: "The child exits zero after exceeding the cap"
+      then: "The parent records overflow as non-success without accepting an injected executor or caller-selected limit"
+    - id: SCN-candidate-fence-closure
+      given: "A closed opaque attempt"
+      when: "The backend has not recorded namespace identity, FD closure, and descendant reaping"
+      then: "Terminal proof is UNKNOWN; fabricated observations and cloned handles cannot create proof"
+  observable_outcomes:
+    - "Only the exact FD4 acknowledgement closes a one-shot opaque admission"
+    - "Child stdout proves frozen-byte consumption, not same-process test reads"
+    - "Zero exit plus output overflow is never success"
+    - "Missing backend fence evidence is never TerminalProof"
+  determinism_controls:
+    - "Temporary source trees, fixed absolute Node runtime, explicit empty child environment, bounded streams"
+    - "No injected executor, caller-provided command, root, environment, limit, or terminal observation"
+  anti_cheat_rationale:
+    prevents:
+      - "Arbitrary tuple issuance or a fabricated bootstrap literal"
+      - "Boolean caller observations minting terminal proof"
+      - "Cloned or reused handles reopening an admission"
+      - "Same-process snapshot reads impersonating child consumption"
+  relaxation:
+    did_relax_any_assertion: false
+    if_true_explain_spec_basis: ""
+```
+
 # Compact Console Overview density (2026-10-01)
 
 ```yaml
@@ -2811,6 +3058,257 @@ test_integrity_note:
     did_relax_any_assertion: false
     if_true_explain_spec_basis: ""
 ```
+# Owner-requested legacy recovery and bounded continuation (2026-10-03)
+
+Implementation and behavioral basis:
+[legacy runtime recovery](spec_changes/2026-10-03-legacy-runtime-recovery.md).
+Existing assertions are unchanged; the new scenarios are in
+`test/fleet/legacy-runtime-recovery.test.mjs`.
+
+```yaml
+test_integrity_note:
+  change_type: new_tests
+  scenarios:
+    - id: SCN-legacy-runtime-recovery
+      given: "A stopped exact invocation and retained unknown identity"
+      when: "The owner recovers presence"
+      then: "One owner audit, offline presence and preserved task/session/unknown"
+    - id: SCN-legacy-runtime-recovery-refusal
+      given: "Live or mismatched invocation/process evidence"
+      when: "Proof is requested"
+      then: "Recovery refuses without mutation"
+    - id: SCN-legacy-runtime-recovery-cas
+      given: "Stale, expired, forged or newly live evidence"
+      when: "Recovery applies"
+      then: "Transaction refuses without success audit"
+    - id: SCN-legacy-runtime-recovery-authority
+      given: "A specialist or incomplete expected snapshot"
+      when: "Owner recovery is attempted"
+      then: "Authority/snapshot validation refuses"
+    - id: SCN-runtime-turn-guard
+      given: "A physically live executor reporting idle"
+      when: "A second turn tries to start"
+      then: "The executor mutex refuses overlap until terminal release"
+    - id: SCN-runtime-continuation
+      given: "Owner-enabled roster and a new durable signal"
+      when: "Turns repeat, hit a cap or are paused"
+      then: "Only new eligible signals launch within the owner daily cap"
+    - id: SCN-runtime-continuation-signals
+      given: "Two eligible identities with multiple unread messages"
+      when: "A bounded batch starts and only acknowledgements change afterward"
+      then: "Both starts occur concurrently, a competing controller refuses, and acknowledgements alone cause no wake"
+    - id: SCN-runtime-continuation-pause
+      given: "Two eligible turns"
+      when: "The owner pauses during the first"
+      then: "The second does not start and pause is retained"
+    - id: SCN-legacy-runtime-recovery-project
+      given: "Cloned project/session metadata in distinct checkouts"
+      when: "Proof crosses checkout boundaries"
+      then: "Recovery refuses and leaves the other identity untouched"
+  observable_outcomes:
+    - "Persisted identity, task/session, owner audit, launch count and refusal codes"
+  determinism_controls:
+    - "Hermetic repositories, fixed clock and OS-boundary fixtures; no live provider"
+  anti_cheat_rationale:
+    prevents:
+      - "Boolean stopped proof or stop-as-PASS"
+      - "Stale/cross-project mutations and peer impersonation"
+      - "Duplicate physical turns or unchanged-signal busy loops"
+      - "Losing pause or refunding interrupted attempts"
+  relaxation:
+    did_relax_any_assertion: false
+    if_true_explain_spec_basis: ""
+```
+
+```yaml
+test_integrity_note:
+  change_type: new_tests
+  scenarios:
+    - id: SCN-codex-mcp-runtime-dir
+      given: "A Codex adapter receives an injected Linux parent environment with a valid XDG runtime directory, or deterministic missing, malformed, or unsupported-platform context"
+      when: "It creates or resumes an identity-bound Codex session with a TORCH MCP server"
+      then: "Both launch records name only XDG_RUNTIME_DIR in MCP env_vars for valid context; invalid context emits no env_vars, and no runtime value, DBUS, home, path, token, or general environment is serialized"
+  observable_outcomes:
+    - "Create and resume plans expose the exact single-name MCP env_vars allowlist only for valid parent context"
+    - "Invalid or unsupported context omits the allowlist without synthesizing a runtime path"
+    - "The serialized invocation never exposes parent environment values"
+  determinism_controls:
+    - "Narrow injected adapter env and platform inputs; no process-wide environment mutation, host service, provider, or native check"
+  anti_cheat_rationale:
+    prevents:
+      - "Hard-coded runtime UID or directory values"
+      - "Forwarding DBUS, secrets, home, PATH, or the complete parent environment"
+      - "Treating a mocked launch record as native runtime qualification"
+  relaxation:
+    did_relax_any_assertion: false
+    if_true_explain_spec_basis: ""
+```
+
+# Exact-source adoption (2026-10-03)
+
+```yaml
+test_integrity_note:
+  change_type: new_tests
+  scenarios:
+    - id: SCN-integration-adoption-private-ref-cas
+      given: "A clean disposable Git repository, a base commit, and an owner-bound private-ref adoption"
+      when: "The adoption finalizes and a stale compare-and-swap attempts to alter its candidate ref"
+      then: "Real Git private archive and candidate refs are created atomically, while the stale write refuses"
+    - id: SCN-integration-adoption-journal-and-binding
+      given: "A prepared adoption journal record"
+      when: "A second preparation or lifecycle request supplies a different candidate binding"
+      then: "The journal revision compare-and-swap and immutable binding checks refuse without changing the prepared record"
+    - id: SCN-integration-adoption-finalize-recovery
+      given: "A real private-ref transaction completed before its journal write"
+      when: "Reconciliation is run and then replayed"
+      then: "One durable finalized recovery is recorded and the replay is consistent without another mutation"
+    - id: SCN-integration-adoption-rollback-recovery
+      given: "A finalized candidate whose private ref was removed before its rollback journal write, or whose candidate ref diverged"
+      when: "Rollback is requested"
+      then: "The completed rollback is recovered once and divergent candidate bytes refuse"
+    - id: SCN-integration-adoption-private-ref-intake
+      given: "An existing unfinalized private candidate ref and a separate finalized owner-bound private candidate ref"
+      when: "Direct private-ref intake and authenticated native qualification are requested"
+      then: "Direct intake refuses without a queue record, while the authenticated path records the exact private ref and commit in ordinary testing state"
+    - id: SCN-integration-adoption-approval-boundaries
+      given: "An ordinary source-only approval, or an adoption whose actor, action, approval revision, or provenance differs from the approved immutable binding"
+      when: "Preparation or a lifecycle transition is attempted"
+      then: "The transition refuses with its structured boundary code and no integration queue record"
+    - id: SCN-integration-adoption-request-replay
+      given: "A finalized adoption that has created its one ordinary private-ref integration request"
+      when: "Two independently opened authenticated API callers request it concurrently"
+      then: "The existing transactional adoption journal serializes them, one caller refuses after the completed transition, and exactly one queue row remains"
+    - id: SCN-integration-adoption-legacy-retries
+      given: "An existing project database containing two historical ordinary-request retry rows with the same source branch and commit"
+      when: "IntegrationService starts"
+      then: "Both records remain readable; startup adds no global uniqueness constraint and does not reject historical evidence"
+  observable_outcomes:
+    - "Git ref values, structured refusal codes, durable journal state, and native integration-request fields"
+  determinism_controls:
+    - "Disposable local Git repositories, temporary SQLite-backed control-plane state, fixed fixture bytes, and no network or provider"
+  anti_cheat_rationale:
+    prevents:
+      - "Fixture-only CAS implementations that do not exercise Git update-ref"
+      - "Mutable lifecycle bindings or overwriteable adoption journal records"
+      - "Claiming crash recovery without preserving actual ref effects"
+      - "Treating a private candidate as an ordinary specialist branch"
+      - "Using an unrelated, source-only, stale, or mismatched approval as adoption authority"
+      - "Duplicating a private-ref queue record through concurrent authenticated API requests or replay"
+      - "Rejecting historical ordinary-request retry evidence with an unqualified schema constraint"
+  relaxation:
+    did_relax_any_assertion: false
+    if_true_explain_spec_basis: ""
+```
+
+```yaml
+test_integrity_note:
+  change_type: new_tests
+  scenarios:
+    - id: SCN-integration-adoption-lifecycle-revision-cas
+      given: "A prepared or finalized owner-bound adoption record with a known journal revision"
+      when: "A caller supplies a stale or omitted expectedRecordRevision to finalize, reconcile, rollback, or request native qualification"
+      then: "The operation refuses before private-ref, journal, queue, or audit effects; the original record and refs remain unchanged"
+  observable_outcomes:
+    - "ADOPTION_RECORD_REVISION_STALE is returned for stale or omitted lifecycle callers"
+    - "Private candidate/archive refs, durable journal record, audit count, and integration queue remain unchanged for every rejected lifecycle call"
+  determinism_controls:
+    - "Disposable local Git repository and temporary SQLite-backed control-plane fixture; no network, provider, or live adoption"
+  anti_cheat_rationale:
+    prevents:
+      - "Issuing external ref or queue effects from a stale lifecycle read"
+      - "Treating journal revision as an internal-only implementation detail"
+  relaxation:
+    did_relax_any_assertion: false
+    if_true_explain_spec_basis: ""
+```
+
+```yaml
+test_integrity_note:
+  change_type: spec_correction
+  scenarios:
+    - id: SCN-integration-adoption-request-replay
+      given: "Two authenticated callers carry the same finalized adoption revision into the serialized native-request transition"
+      when: "One caller completes the transition and the other resumes with its now-stale expectedRecordRevision"
+      then: "The second caller strictly receives ADOPTION_RECORD_REVISION_STALE while exactly one requested journal record and one queue row remain"
+  observable_outcomes:
+    - "The replay loser reports the stale journal-revision boundary, not a generic post-state refusal"
+    - "Exactly one private-ref integration request and requested audit transition exist"
+  spec_correction_basis:
+    - "The former ADOPTION_REQUEST_STATE_INVALID replay expectation was wrong: after the serialized winner commits, the loser carries an obsolete journal revision, so revision CAS is the first observable refusal boundary under SCN-integration-adoption-request-replay."
+  determinism_controls:
+    - "Two independently opened local API processes over disposable Git and SQLite fixture state"
+  anti_cheat_rationale:
+    prevents:
+      - "Accepting a stale lifecycle read after another caller has committed"
+      - "Relaxing the exactly-one-request invariant after adding revision binding"
+  relaxation:
+    did_relax_any_assertion: false
+    if_true_explain_spec_basis: ""
+```
+
+## 2026-10-03 — Schema-v2 read-only owner-reply boundary
+
+```yaml
+test_integrity_note:
+  change_type: new_tests
+  scenarios:
+    - id: SCN-read-only-v2-control-plane
+      given: "A canonical schema-v2 fixture, including a write-refusing state directory"
+      when: "A reader opens a normal SQLite read transaction and a mutation is attempted"
+      then: "It returns one coherent snapshot or a typed refusal; no database or sidecar bytes change"
+    - id: SCN-read-only-pinned-correlated-snapshot
+      given: "Two v2 identities in one observable generation"
+      when: "A writer atomically commits their next generation while the reader remains open"
+      then: "The reader observes one generation or refuses, never a mixed pair"
+    - id: SCN-owner-addressed-reply-durability
+      given: "A registered agent has an owner-originated request addressed to it"
+      when: "It sends a dedicated reply and state is reopened"
+      then: "The reply linkage, bounded owner cursor, and actor audit persist"
+    - id: SCN-owner-addressed-reply-refusal
+      given: "Spoofed senders, a different valid registered agent, generic owner recipients, foreign/forged references, or a non-owner reader"
+      when: "They invoke the owner-reply boundary"
+      then: "They refuse without message or audit writes; the owner conversation remains unchanged; direct and broadcast delivery remain intact"
+  observable_outcomes:
+    - "Schema-v2 compatibility refusal, stable snapshot rows, byte/sidecar preservation, durable reply linkage, cursor page, and audit event"
+  determinism_controls:
+    - "Hermetic Git/SQLite fixtures, fixed clocks and IDs, explicit transactions, no network, provider, sleep, or retry"
+  anti_cheat_rationale:
+    prevents:
+      - "Migrating or initializing a read-only or unknown schema"
+      - "Returning stale or mixed identity generations"
+      - "Treating owner as a fleet identity or accepting generic recipient bypasses"
+      - "Accepting foreign, forged, or valid-identity wrong-addressee owner-reply linkage"
+  relaxation:
+    did_relax_any_assertion: false
+    if_true_explain_spec_basis: ""
+```
+
+## 2026-10-03 — Public MCP owner-reply wrapper
+
+```yaml
+test_integrity_note:
+  change_type: new_tests
+  scenarios:
+    - id: SCN-mcp-owner-reply-public-boundary
+      given: "A registered agent has an owner-originated request addressed to it and a second registered identity exists"
+      when: "Each identity invokes the public stdio MCP owner-reply tool"
+      then: "Only the bound addressee can persist a reply with replyTo and audit attribution; selector fields and another valid identity refuse before a write"
+  observable_outcomes:
+    - "The MCP schema exposes only request_id and body with no additional properties or owner-history tool"
+    - "The persisted reply is linked to the owner request and audited as the bound actor"
+    - "Selector-field and wrong-addressee refusals leave owner conversation and audit counts unchanged"
+  determinism_controls:
+    - "Hermetic Git/SQLite fixture, fixed topology, local stdio MCP process, no network, provider, sleep, or retry"
+  anti_cheat_rationale:
+    prevents:
+      - "Selecting a sender, recipient, owner, or history through MCP input"
+      - "Replying from a different valid Fleet identity"
+      - "Exposing an agent-facing owner-history reader"
+      - "Claiming an in-process helper as public MCP qualification"
+  relaxation:
+    did_relax_any_assertion: false
+    if_true_explain_spec_basis: ""
+```
 
 # Self-host runtime metadata observations (2026-10-01)
 

docs/TODO.md

@@ -1,5 +1,133 @@
 # TORCH remaining work
 
+## Immediate owner-facing milestone: agent Chat (2026-10-03)
+
+Owner promoted `TASK-owner-agent-chat`, `TASK-console-agent-chat-ui` and
+`TASK-console-chat-cards-qualification` to urgent. Deliver default coordinator
+chat, activated-agent switching, durable history and a safe composer first,
+following [the Chat specification](CONSOLE_CHAT_AND_COMPACT_CARDS_SPEC.md).
+Manager must triage eligible slices; priority does not remove runtime-wake
+dependencies or preempt active work. Recovery unblockers continue alongside it.
+
+## Owner-approved self-healing priority (2026-10-03)
+
+Owner also approved [operational flow and Ops pilot improvements](OPS_FLOW_IMPROVEMENT_SPEC.md):
+two focused incident-resolution/adoption-and-QA-handoff requests, additive Chat
+and evidence acceptance, and an existing-identity Ops responsibility pilot. No
+eighth standing agent or overlapping implementation ownership is implied.
+
+Authoritative urgent proposals (assignment remains with Session Manager):
+
+- [ ] `TASK-fe86062d-847f-46ab-9ad9-d721113e5dcd`: operational incident ownership
+  and overdue wait resolution, extending current messages/events/approvals.
+- [ ] `TASK-f40126ee-2485-45c8-a67b-4279e4e8704a`: supported exact-source
+  adoption and named QA/test handoffs through native qualification/integration.
+
+The linked spec supplies additive acceptance for existing Chat/evidence tasks
+and the Ops responsibility pilot; task-file criteria have not been rewritten by
+the owner because the installed API has no supported amendment operation.
+
+Follow [bounded self-healing qualification](SELF_HEALING_QUALIFICATION_PLAN.md).
+Prioritize the existing runtime-recovery, persistent-operations, provider-failure
+governor, event/reconciler and queue-watchdog work without duplicating their
+backlog records or bypassing dependencies. Require installed failure-injection
+evidence and independent QA, not merely active executors. The owner subsequently
+enabled unlimited daily continuation in alpha.4.2; older cap/resume statements
+below are historical and do not override that specific authorization. Retry
+circuit breakers, concurrency and approval/ownership gates still apply.
+
+## Current owner priority: reliability first (2026-10-03 UTC)
+
+End-to-end repair qualification is still open. Runtime reported exact converged
+candidate `d2d9845` with four fresh native check PASS receipts; QA independent
+acceptance is not yet recorded. Owner source fixes cover guarded presence,
+rolling/fair dispatch, no-progress escalation and visible daily-cap stops. The
+first automatic allowance of 12 turns was exhausted; any increase needs an
+explicit owner choice, not a manual-start bypass. Next dispatch should prioritize
+QA's exact verdict/support decisions, Release's declared-inventory consumer
+decision, safe Kernel/Work composition and actual Console implementation.
+Require evidence of specialist work, independent review/checks, serialized
+integration and next-work continuation before calling the autonomous loop ready.
+
+Live all-fleet resume exposed a new urgent proposal:
+`TASK-d95e72d0-816d-4fc2-acaf-b73642fd4881` — refill continuation capacity
+when individual turns exit instead of waiting for the longest batch member.
+Manager remained running after Kernel/Runtime exited, leaving free slots unused
+and delaying the other four specialists. Preserve identity guards, pause, global
+capacity and attempt accounting when replacing the batch barrier.
+The same run reconfirmed the existing `TASK-pilot-starting-presence`: actual
+executors can display idle during startup. Do not duplicate that task or falsify
+presence to make the board look busy. Owner explicitly requested one simultaneous
+resume of all seven existing identities; that manual batch is separate from the
+automatic pilot's 12-turn daily ledger, not proof of a global usage governor.
+
+This ordering supersedes the UI-first ordering below. The existing authoritative
+backlog, not this index, controls task state and assignment.
+
+1. Safe current-schema runtime recovery (`TASK-company-runtime-recovery`) and
+   combined CLI qualification (`TASK-pilot-cli-suite-timeout`).
+2. Truthful startup/session status (`TASK-pilot-starting-presence`) and its
+   existing Kernel reservation/Work candidate-safety prerequisites.
+3. Persistent operations and bounded event-driven continuation
+   (`TASK-conversation-persistent-operations`,
+   `TASK-conversation-event-driven-wakes`), followed by actual scheduler
+   qualification (`TASK-conversation-scheduler-qualification`).
+4. Specific actionable operational warnings (`TASK-console-attention-actions`).
+5. Compact cards/detail modals and coordinator-first Chat remain high priority.
+
+The first four groups and incomplete technical prerequisites are urgent;
+scheduler qualification is high. These priority-only changes preserve owners,
+states, dependencies and evidence. Blocked remains blocked; automatic wakes stay
+disabled until qualified and explicitly activated. Older pause/install/status
+statements below are historical snapshots, not current runtime evidence.
+
+Owner-requested recovery/continuation implementation is described in
+[the source pilot specification](spec_changes/2026-10-03-legacy-runtime-recovery.md).
+Do not close the runtime-recovery, persistent-operations or event-wake umbrellas
+from focused tests alone. Release/Fleet Operations still need installer-owned
+permanent timer provisioning/removal, installed artifact qualification and restart
+recovery of retained crashed turn/controller guards. The transient host pilot does
+not survive reboot, and its daily turn cap is not a token/dollar usage governor.
+
+## Priority UI cycle: compact cards and agent Chat
+
+Owner-approved [Console UI spec](CONSOLE_CHAT_AND_COMPACT_CARDS_SPEC.md).
+Prioritize these after explicit owner resume, ahead of broad company expansion:
+`TASK-console-compact-details`, `TASK-console-agent-chat-ui` and
+`TASK-console-chat-cards-qualification`. Extend the existing high-priority
+`TASK-owner-agent-chat`; do not duplicate messaging or bypass paused wake policy.
+Proposals remain unassigned. Fleet startup is not authorized by this addition.
+
+## Adaptive software company upgrade (owner-approved, 2026-10-01)
+
+The [integration plan](ADAPTIVE_COMPANY_INTEGRATION_PLAN.md) records scope,
+existing-task reuse, phased contracts, exit gates and migration/rollback rules.
+The existing authoritative backlog contains eleven linked `TASK-company-`
+proposals, not a second queue. Runtime recovery gates unattended coordination;
+authority comes from scoped revocable grants, not reporting relationships.
+Existing grants, event-driven wakes, first-work intake, usage governance and
+hierarchy pilots are reused rather than replaced. All new items are proposed
+and unassigned. No automatic restart or implementation is authorized by this
+roadmap addition; the fleet remains manually paused pending owner resume.
+
+## Owner-approved project knowledge requirement (2026-10-01)
+
+See [Project knowledge and domain institutional memory](PROJECT_KNOWLEDGE_SPEC.md).
+The existing authoritative backlog holds the implementation slices below; this
+section is an index, not a second queue. All are proposed/unassigned, and the
+fleet remains manually paused until the owner explicitly requests resume.
+
+- `TASK-knowledge-contract`: project-fit Git-backed KB, domain handbooks and
+  provisional memory; metadata, visibility, evidence and ownership contract.
+- `TASK-knowledge-agent-context`: documentation discovery, compact domain brief
+  references and provider-independent retrieval/inheritance without context bloat.
+- `TASK-knowledge-maintenance`: documentation-impact workflow, verification
+  evidence, cross-domain notifications and ownership transfer without duplicate truth.
+- `TASK-knowledge-console`: dedicated accessible Knowledge view, safe rendering,
+  search, history and durable ask-domain/report-outdated actions.
+- `TASK-knowledge-qualification`: end-to-end inheritance/freshness/privacy/pause
+  scenarios and realistic browser acceptance, including isolated demo fixtures.
+
 ## Authoritative current handoff (2026-09-30, after alpha.2 reinstall)
 
 TORCH is installed and healthy at `0.1.0-alpha.2`. Setup/restore and all seven

docs/spec_changes/2026-10-03-continuation-concurrency.md

@@ -0,0 +1,16 @@
+# Owner-configured continuation concurrency
+
+The owner can configure `torch continuation enable --concurrency 7 --yes`.
+The default remains three; valid settings are integers from one through seven.
+An explicit tick `--limit` may tighten but never exceed the approved policy.
+Each refill reads current policy; lowering capacity does not cancel active turns.
+Omitted configuration fields preserve the approved daily cap and concurrency.
+Configuration never resets the attempt ledger or bypasses physical identity guards.
+
+An already-running older controller cannot hot-load this change. Replace its
+timer, not its active service, and allow its native turns and controller lock to
+finish before the new controller takes over. No concurrent controllers may
+dispatch through the same project lock.
+
+Scenario SCN-runtime-continuation-concurrency proves seven simultaneous pending
+starts, tighter tick limits, invalid-policy refusal and preserved usage on pause.

docs/spec_changes/2026-10-03-daily-continuation-override.md

@@ -0,0 +1,14 @@
+# One-day continuation allowance override
+
+An explicit owner decision can grant a higher bounded total for the current UTC
+day using `torch continuation enable --today-max-turns 96 --yes`.
+The override total includes turns already charged; it never erases usage.
+The ordinary daily cap (1–48) remains unchanged. The override ceiling is 96.
+At UTC midnight the override ceases to apply without a scheduled reset write.
+Owner-only audited configuration, seven-slot concurrency, identity guards,
+pause, unknown-outcome protection and all verification boundaries remain intact.
+Omitting the override argument preserves its existing same-day decision.
+This is a turn allowance, not a measured token, subscription-credit or cost limit.
+
+SCN-runtime-continuation-day-override checks actual extra dispatch, preserved
+charges, authorization/range refusals, pause and automatic next-day expiry.

docs/spec_changes/2026-10-03-legacy-runtime-recovery.md

@@ -0,0 +1,93 @@
+# Manual owner recovery for retained unknown executor outcomes
+
+The owner requested fixing the stalled fleet. Legacy runtime records lacked a
+recovery API: three physically stopped executors remained `working/unknown` and
+correctly refused duplicate launches. This change adds an owner-only, previewed
+`recover-runtime` operation without schema changes or automatic recovery.
+
+The owner explicitly selects a project-scoped systemd service invocation. Its
+working directory and exact area argument must match this installation; its
+terminal timestamp must match the retained identity update within five seconds
+(systemd displays timestamps with one-second precision). Both service PIDs must
+be zero, its cgroup absent, and no visible same-user native process may reference
+the session or registered workspace. Physical state is checked again at apply.
+Unreadable process visibility, an active service, foreign invocation or changed
+identity refuses recovery. This is a **manual legacy operator binding**, not
+cryptographic session provenance or protection against arbitrary same-user code.
+
+Evidence is process-local, branded, single-use and expires after sixty seconds.
+The service transaction compares the exact state/runtime/session/update snapshot,
+sets presence to offline and writes an owner-attributed audit. Session, current
+task and the unknown outcome are preserved. No task, test or launch is completed;
+no process is killed, lease removed, schema migrated or provider started.
+
+Preview and apply use the same implementation. Apply additionally requires the
+session and update timestamp from the preview. Hosts/providers without verifiable
+Linux/systemd evidence refuse this legacy recovery; no Boolean fallback exists.
+
+## Bounded continuation pilot
+
+`torch continuation enable --max-turns-per-day 12 --yes` approves only the
+currently activated identity roster. `status` previews eligible identities;
+`tick --limit 3 --yes` runs at most three normal guarded `up` operations. New
+unacknowledged messages or assigned/in-progress task revision changes supply the
+signal; an unchanged signal is not retried. Active/unknown identities, held turn
+guards, detach, disabled policy and the daily UTC attempt cap prevent launch.
+Attempts are charged before invocation, including failed/interrupted attempts.
+The cap limits turns, **not dollars or token consumption**. Unknown quota remains
+unknown. This controller makes no product/approval/assignment decisions.
+
+`torch continuation pause --yes` prevents subsequent launches. Policy and attempt
+ledger are separate atomic files so an in-flight turn cannot overwrite a pause.
+Pause does not kill an already-running turn. A controller lock serializes ticks;
+a crashed lock is retained rather than expired automatically. Each executor has
+a separate physical turn guard held through classification and final presence,
+so an agent reporting idle cannot permit overlapping native turns.
+
+The first host pilot uses an explicitly installed transient user-systemd timer.
+It survives this chat ending, but not a host reboot. Permanent installer-owned
+provisioning/removal and installed artifact qualification remain existing backlog
+work; this is not a claim that the alpha.3 installed package has been upgraded.
+
+```yaml
+test_integrity_note:
+  change_type: new_tests
+  scenarios:
+    - id: SCN-legacy-runtime-recovery
+      given: "An exact retained working/unknown identity and stopped project invocation"
+      when: "The owner previews and applies recovery"
+      then: "Presence becomes offline once; session, task and unknown outcome persist with one owner audit"
+    - id: SCN-legacy-runtime-recovery-refusal
+      given: "Live, foreign, mismatched or incomplete stopped-executor evidence"
+      when: "Recovery evidence is requested"
+      then: "Recovery refuses without identity mutation"
+    - id: SCN-legacy-runtime-recovery-cas
+      given: "Issued proof followed by a changed identity, live process, expiration or forgery"
+      when: "Recovery is applied"
+      then: "Transactional recovery refuses and creates no success audit"
+    - id: SCN-legacy-runtime-recovery-authority
+      given: "A specialist actor or incomplete expected snapshot"
+      when: "Owner recovery is requested"
+      then: "Authority or snapshot validation refuses"
+    - id: SCN-runtime-turn-guard
+      given: "A physical executor holds an identity guard and reports idle early"
+      when: "Another executor attempts the same identity"
+      then: "It refuses until the first executor finishes and releases its own guard"
+    - id: SCN-runtime-continuation
+      given: "An explicitly enabled roster, a new durable signal and a fixed daily turn cap"
+      when: "Continuation ticks, repeats a signal, exhausts its cap or is paused"
+      then: "Only eligible new signals launch; deduplication, cap, owner authority and pause remain enforced"
+  observable_outcomes:
+    - "Durable presence, session and task state; owner-attributed audit; explicit refusal codes"
+  determinism_controls:
+    - "Hermetic Git/install fixtures, fixed clock and injected OS observation boundary"
+  anti_cheat_rationale:
+    prevents:
+      - "Caller Boolean as stopped proof"
+      - "Process stop promoted to successful task or test"
+      - "Stale snapshot overwrites or silent peer impersonation"
+      - "Expired, foreign or replayed proof"
+  relaxation:
+    did_relax_any_assertion: false
+    if_true_explain_spec_basis: ""
+```

docs/spec_changes/2026-10-03-live-runtime-presence.md

@@ -0,0 +1,13 @@
+# Live runtime presence instead of stale idle badges
+
+The owner requires active executor turns to be distinguishable from old self-reported idle/offline state. Display is observational, not a new task-state machine or a substitute for authorization.
+
+Each new physical turn guard records a starting phase and Linux process-start token, then enters working immediately before invoking the authorized executor. The read-only observation API validates the exact project/identity guard against a live same-user process with the matching start token. Existing legacy guards additionally require the exact TORCH up identity and canonical working directory. Dead, foreign-user, replaced or unobservable processes are not called active; retained unverified guards display unknown instead of false idle/offline.
+
+An active verified guard overrides idle/offline display with starting/working. Original `reportedState`, `reportedSummary`, task and heartbeat are retained. Waiting/blocked reports remain visible even during a live turn. Guard removal naturally restores the last reported state after completion. No report, task, authority, launch policy, budget or receipt is changed by observation.
+
+On unsupported OS process-observation surfaces, guarded execution remains unknown, not optimistically working. Other platform qualification remains open. Native harnesses with no resident TORCH executor may continue to rely on durable reports; this change does not claim to discover every external runtime process.
+
+The live console pilot must load the source candidate to expose this observation. Updating its owned server does not upgrade the installed distribution or restart running agent turns. Broader startup/launch reservation work remains tracked by `TASK-pilot-starting-presence`.
+
+Test integrity scenarios are recorded in docs/TEST_INTEGRITY.md. No existing expectations or test timeouts are relaxed.

docs/spec_changes/2026-10-03-rolling-continuation.md

@@ -0,0 +1,23 @@
+# Rolling continuation without a whole-batch barrier
+
+Owner-requested fix for `TASK-d95e72d0-816d-4fc2-acaf-b73642fd4881`.
+
+The serialized controller reserves and charges each launch before dispatch. It waits for the first pending turn to complete, records its outcome, re-reads current policy/backlog/messages and immediately fills any available slot. A long manager turn no longer prevents other eligible identities from running. The controller lock still excludes competing automatic controllers; pending launches and all observed physical turn guards count toward automatic capacity. Owner-requested manual batches are separate authorization and are not silently included in the daily automatic attempt ledger.
+
+The same approved roster, per-identity mutex, pause, detached state and daily cap remain authoritative. A pause prevents additional launches and never kills an already-started turn. Unknown or failed executor outcomes are not silently retried. Retained crashed guards/controller locks remain fail-closed and require supported recovery.
+
+Successful turns may continue unchanged assigned/in-progress work if recorded dependencies are complete. After two consecutive successful turns leave the same task IDs/revisions unchanged, further unchanged-work retries are held and one durable request asks the Manager to resolve the blocker. New task revisions or fresh messages can justify another bounded turn. This is a conservative no-progress signal, not proof that no files changed or that a task is done; the Manager must inspect evidence. Waiting, blocked, unassigned, completed or unmet-dependency work is not automatically converted into implementation work. Existing one-assignment rules and self-claim policy are not changed.
+
+Resume instructions now request eligible implementation/verification/coordination rather than just a status report. They do not grant additional ownership or approval authority. All output completion remains exact-evidence gated.
+
+Status exposes occupied guard identities and no-progress holds. Installed release and reboot persistence remain unqualified. Existing native pilot service executes this source candidate on its next activation; the daily limit remains 12 automatic attempts, not a token-cost governor.
+
+Eligible identities are ordered least-recently-dispatched within the current UTC day, with the Manager first only on ties. A repeatedly revised specialist task must not consume every freed slot while an eligible peer has never started.
+
+## Visible operating stops
+
+The read-only project observation includes the automatic-turn budget, remaining attempts, exact pause/cap stop, retained capacity guards and current no-progress holds. It never resets the ledger, changes authority or treats declared policy as verified timer installation. No-progress holds are displayed only while the same active task IDs/revisions remain; resolved or revised tasks do not retain stale alerts.
+
+An exhausted automatic allowance appears as an owner policy decision in Overview and as an explicit Fleet status line. Manager-owned no-progress waits remain with the Manager, rather than being falsely routed to the owner. There is no fabricated approval button or silent allowance increase. Manual owner turns are not included in this ledger; token/cost governance remains unknown.
+
+Deterministic acceptance scenarios and anti-cheat notes are in docs/TEST_INTEGRITY.md. Independent live qualification remains necessary; do not close broader event-driven or persistent-operations umbrellas based on this source fix alone.

docs/spec_changes/2026-10-03-startup-unread-mitigation.md

@@ -0,0 +1,15 @@
+# Explicit unread inbox on startup and resume
+
+Legacy `torch_read_messages` defaults to the oldest 100 historical messages.
+Observed native inboxes exceeded 100 unread messages during fleet supervision.
+Launch/resume now explicitly requests the bound identity's unread inbox with a
+limit of 1000 and explains chronological order, potential overflow and deliberate
+acknowledgements. This uses the existing tool without changing its API contract.
+
+This mitigation does not implement pagination, newest-first history, coherent
+cross-query observation, or complete overflow detection. Those remain in the
+existing unread-first inbox task. A result of 1000 is explicitly uncertain,
+not a complete-inbox claim. No permissions follow from reading a message.
+
+SCN-fleet-startup-inbox exercises the actual fresh/resume launch arguments and
+registered identity-bound inbox tool against messages beyond the default page.