TORCH/docs/TODO.md

TORCH remaining work

Current owner priority: reliability first (2026-10-03 UTC)

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. 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. 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 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. 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 worktree briefs have been verified. The active organization is Session Manager plus six specialists. A first bounded development pilot is now active through Session Manager, Provider Runtime and QA; the remaining domains have not started. See reports/audit/first-development-pilot-2026-09-30.md for current live state. The default Git branch remains legacy TORCH; the configured development/integration boundary is rewrite/portable-agent-fleet. No publication or default-branch promotion is authorized. Later sections retain historical audit snapshots, including old "uncommitted/no launcher" statements; those are superseded by this handoff.

The conversation's unfinished work is now owner-proposed in the existing authoritative backlog in the Session Manager worktree, not a second TODO queue. Use torch backlog list --json to see it from any registered checkout. Tasks use the TASK-conversation- prefix, have acceptance criteria, affected domains and dependencies, and remain unassigned for manager triage. See reports/audit/conversation-handoff-2026-09-30.md for the domain review and index.

New owner requirements: first work and automatic operations

• TASK-conversation-first-work-intake: init/install/setup offers reviewed TODO/backlog import or asks what the owner wants to begin with; previews and confirms proposed tasks; deduplicates resumes; never activates stale/completed TODOs or launches agents silently.
• TASK-conversation-persistent-operations: reviewed init/install provisions machine-level scheduler/services automatically, not merely schedule JSON or a separate manual cron-install command. Paused installs remain dormant. Services declare system/session lifetimes, budgets, timezone, restart/missed-run policy, pause/resume and manifest-owned uninstall/restore behavior. This extends the earlier TASK-conversation-automatic-scheduler requirement.
• TASK-conversation-event-driven-wakes: durable deduplicated significant events wake the appropriate manager under budget; periodic checks are the quiet safety net, not repeated usage-consuming busywork.
• TASK-conversation-queue-watchdog: detect stuck resource queues and disappearing slots, audit removals and stop displaced waiters; never infer browser ownership/termination from a process name or runner death.
• TASK-conversation-nightly-main-tests: project-declared full canonical suite on an exact frozen commit, resource-aware idle window and evidence-backed regression routing. Do not guess the offending change.
• TASK-conversation-usage-governor: provider-neutral usage/credit evidence, conservative fallback budgets, graceful wind-down and reviewed reset/restart policy that cannot override manual pause or detach.
• TASK-conversation-idle-worktree-refresh: scheduled merges into clean, idle, unguarded branches; skip active/dirty/unknown work and preserve conflicts.
• TASK-conversation-queue-planning: measured test durations, uncertain wait estimates, slowdown visibility, GPU-exclusive resources and approved heavy-run windows; preserve the resource queue's authority.
• TASK-conversation-closure-revert-review: verified revert/follow-up policy and evidence-backed review of unnamed finished work; never mass-close or reopen tasks based only on untrusted commit trailers.
• TASK-conversation-project-services: reviewed project-specific landing worker, local dev/Console server, local summary and optional release jobs. No COMBATRIG schedules, Vercel deployment, credentials, LAN exposure or automatic phone notifications are assumed.

These are proposed development tasks, not implemented automatic init/install. For the first pilot the arbiter explicitly installed an hourly machine manager coordination timer and verified real systemd parsing/activation. Automatic AI wakes are paused pending the timeout/outcome guard; self-claim remains disabled. COMMON.md authorizes only the diagnostics development slice, not broad autonomous dispatch. The original 34 proposals remain the handoff; three newly observed pilot reliability issues have also been added to the same backlog:

• TASK-pilot-starting-presence: publish guarded startup state before a blocking provider launch and prevent duplicate manual/timer execution.
• TASK-pilot-systemd-rendering: native scalar-path rendering is fixed and qualified in source; finish active/failed unit evidence and false-success handling instead of equating installed files with an operational timer.
• TASK-pilot-executor-outcomes: zero exit plus timeout/error/signal cannot produce a successful lifecycle/wake receipt; qualify before automatic wakes.
• TASK-pilot-generated-check-artifacts: retain exact-commit check artifacts outside the tested tree and safely recover proven generated outputs so a gate does not make the following required gate fail WORKTREE_DIRTY.
• TASK-provider-handover: after release qualification, checkpoint and safely switch one session then the fleet to reviewed Claude Code/Pi profiles; preserve TORCH identity/tasks/messages but never reuse another harness's native session ID.
• TASK-owner-agent-chat: persistent per-agent owner conversations for the Manager and every activated domain, durable replies and clear queued/delivered/ running/failed outcomes. Reviewed wake-on-message must respect pauses, budgets and runtime leases; qualify executor outcomes and starting presence first.

The owner approved continuing the controlled pilot. Independent QA now has exact candidate ae18a98e2911aa515d0484518013061b05ff6adf and the Manager has a bounded next-slice planning request. The candidate's test/check/lint receipts pass; its dashboard receipt remains incomplete because the test writes tracked reports. Neither review launch nor controller exit is acceptance or landing evidence. There are now 44 owner-intake items, including agent chat, the UI audit, observed attention/startup follow-ups and bounded routine-coordination policy.

• TASK-console-ux-audit: Session Manager assigns Owner Console to audit every live dashboard area through actual computer use and inspected screenshots, including desktop/mobile and keyboard/refresh behavior. Owner rejects the long single-page/anchor-navigation layout. Propose focused separate screens, concise overview and contextual drilldowns. Audit/proposal only; no UI rewrite yet.
• TASK-console-attention-actions: meaningful condition/agent/branch labels, deduplicated findings and contextual quick actions. Owner approve/reject uses existing evidence/revision/preview confirmation; never clear peer messages, merge branches or publish to a remote through a generic warning button.
• TASK-pilot-brief-sandbox: the first UI audit stopped at a read-only SQLite error while the exact installed brief succeeds on the host. Qualify scoped sandbox access and actionable failure; do not disable sandboxing, change DB permissions, copy state or bypass the authoritative startup brief.
• TASK-bounded-routine-coordination: live COMMON/manager policy now keeps own-inbox handling, peer questions, named approver decisions and owned ledger maintenance inside the fleet. Project Kernel's approved implementation slice makes this portable in generated instructions and proves authority/wait/pause boundaries with additive scenarios. No general unattended execution is implied.

First real self-host run (2026-09-30)

Portable production pipelines (new roadmap element)

• Detect justified recurring multi-stage flows from repo/spec and handoff evidence; propose owner-reviewed pipeline definitions without auto-creation.

• Define versioned stage DAGs with one flow coordinator, specialist owners, pinned inputs/outputs, project invariants, checks, resources and approval roles.

• Track deliverable instances through the existing backlog/artifact/check/ approval systems; do not create another independently scheduled task queue.

• Implement revision-checked transitions, provenance, attempt lineage, invalidation, parallel joins, rework and idempotent interrupted-stage recovery.

• Add why-waiting/stall diagnostics and manager exception check-ins for handoffs and deliverables, not just stale task commits.

• Add Console deliverable cards, stage timeline, exact-output feedback, approval/rework actions and before/after evidence.

• Add conditional Pipelines navigation, per-definition deliverable rows, reciprocal Work-board links, why-waiting drilldown, parallel stage view, accessible mobile/current-blocker presentation and protected refresh.

• Add evidence-backed stage metrics and configurable sample-based reviews; keep unknown costs explicit and preserve definition-version comparisons. Use the same renderer for private live state and clearly labelled demo fixtures.

• Pilot a TORCH software/docs pipeline, then separately qualify project- supplied mesh, UV-paintback, transcription or other domain checks as needed. Canonical contract/acceptance plan: spec section 14.0a. No runtime implemented yet.

• Install accepted 0.1.0-alpha.0 into the normal version store, activate stable launcher, install six-domain configuration and create seven worktrees.

• Verify ChatGPT sign-in, Luna specialist startup and Sol 6.1 manager startup using the current installed Codex 0.159.2 binary. Durable specialist message, manager acknowledgement and runtime IDs observed. No development dispatch, pushes, deployments or host timers enabled.

• Add owner-approved install/startup provider version preflight for Codex, Claude Code and Pi: exact managed binaries, 24-hour freshness, serialized updates, retained previous installs, offline previews and fail-closed errors. Four deterministic scenarios added; live download qualification recorded in the first-run audit, not implied by mocked installer tests.

• Fix torch brief invoked from a managed worktree: both live sessions hit LOCAL_STATE_METADATA_MISMATCH. Resolve canonical project binding with checked worktree membership, never weaken root/installation identity checks.

• Surface Codex JSON stdout failure events: first Sol launch hid the actual model rejection behind an unrelated inherited Vercel MCP authentication error.

• Add exact executable/version/model/auth preflight to owner Console and setup flow. PATH selected CLI 0.158.0 while the current session used 0.159.2; the older child rejected Sol 6.1 and required manual investigation/retry.

• Make configuration checkpoint/worktree/manifest handoffs explicit or guided: generated tracked files and provisioning manifest updates require deliberate commits; a healthy doctor does not prove startup readiness.

• Isolate irrelevant inherited global MCP servers without removing user settings. Vercel auth noise appeared in both failed and successful Codex runs.

• Integrate approved update policy into hierarchy activation and persistent schedule wakes; qualify interrupted-update recovery and Windows npm execution.

• Qualify current Pi flag/extension/login compatibility after its official package migration; a verified binary --help is not a full adapter proof.

Review corrections (2026-09-29)

Fresh readiness audit (2026-09-30)

Current checkpoint: 03fcbdd committed the portable rewrite. The protected fixture remains untracked and excluded. A commit-bound candidate passed all 38 acceptance groups in an isolated temporary version store; it is inactive and no stable launcher was installed. Older dirty-source/pending-checkpoint statements below are historical snapshots, not the current commit state.

Install-readiness follow-up: exact observed-file ownership evidence now permits reviewable primary ownership for package metadata, schemas, documentation and other deliverables, without admitting unobserved paths or invented directory globs. Evidence is capped at 1000 entries with explicit truncation. Thirteen focused scenarios and all 38 source acceptance groups PASS. Re-checkpoint this fix, regenerate a complete six-area proposal and qualify its stopped-install rehearsal before requesting real installation or live provider launch.

Self-host ownership follow-up: see reports/audit/self-host-roster-review-2026-09-30.md. A proposed six-specialist grouping covers 124 current implementation/assets/harness/test files with zero missing/duplicate primary mappings. A pending six-domain JSON proposal now passes the real Architect CLI validator with zero unassigned analyzer components: /tmp/torch-selfhost-six-domain-proposal-20260930-ownership.json (validated at that source checkpoint; subsequent bootstrap changes make its binding stale). This is not approved or commit-bound; root metadata/schema ownership review and a fresh post-checkpoint intake remain required. The local source checkpoint decision has been requested; no install or launch occurred.

See reports/audit/readiness-audit-2026-09-30.md for current specification exit gates and evidence boundaries. Latest intake contains 15 candidate domains, 13 unassigned components and 41 coordination boundaries; it remains pending, not approved for installation. The older self-host report's 10/18/24 counts are historical, as is the earlier 14/14/39 intake. Latest preview is /tmp/torch-selfhost-intake-20260930-ownership.json; regenerate after the source checkpoint. main still points to legacy TORCH; the rewrite is uncommitted, candidate planning correctly refuses it, and no stable version/launcher exists. Prioritize frozen queued-browser/same-runtime qualification and stale-work manager review, then a scoped source checkpoint and reviewed TORCH roster before a separately authorized bounded live trial.

COMBATRIG operational lessons (2026-09-30)

• Generate collision-free baseline rosters for test-only, release-only and combined repositories. Catch-all Core fallback is used only if no evidenced domain exists, preserving empty-project startup without inventing a conflicting owner. SCN-bootstrap-specialist-only is required by candidate acceptance.

• Reject provable duplicate primary ownership at both pending Architect and approved-install boundaries. Exact normalized paths, universal ownership and literal recursive-parent claims fail closed, including planned files; shared consultation is allowed. Arbitrary glob intersections remain outside this check. SCN-bootstrap-primary-ownership is required by candidate acceptance.

• Add optional frozen check inputs with project-declared build provenance, reflink/independent-copy isolation, durable preparation and exact-SHA receipts. CLI/MCP prepare/list/run/cancel paths integrate with explicit FIFO resource acquisition. Specialist rebuilds do not mutate captured inputs; tampering/policy changes/executor failures cannot count as passes.

• Qualify a real queued browser test serving its frozen build, including project harness paths/dependencies, disk use and interrupted-run recovery. Real Chromium capture/rebuild/queued-run qualification now PASS: the browser serves captured HTML after an in-place live rebuild, reopens prepared state, credits only the captured SHA and rejects the newer build with the unchanged harness. Explicit external harness/module resolution is exercised. Disk use, other-project interruption and project-specific qualification remain unfinished; see reports/audit/frozen-browser-qualification-2026-09-30.md.

• Add explicit owner-only abandoned-check recovery with persisted runner identity, conservative live-runner rejection, stopped-executor/descendant attestation and audit. Terminal recovery creates no receipt and releases no lease. Owned-snapshot cleanup is replayable; ownership mismatch preserves it. Real Linux runner/measurement SIGKILL qualification and cleanup replay PASS.

• Qualify one real Linux Chromium harness surviving TORCH runner death, then explicit owned browser/harness shutdown before owner recovery. Pre-opened pidfds confirm the captured isolated browser group and harness terminate; live browser status after runner death proves those are different events.

• Extend interrupted-check qualification to other platforms and arbitrary project harnesses, including descendants escaping captured process groups. Linux process metadata observes only the runner, not descendant termination.

• Persist prepared-check cleanup outcomes and surface abandoned checks in the actual Console/shared demo. Completed, pending and unconfirmed states remain distinct; private paths, owner evidence and process IDs are omitted. No recovery buttons or implied descendant liveness proof. Crash-before-outcome persistence remains conservatively pending; replay updates cleanup without duplicate audit.

• Add project-configurable test-condition receipts and prerequisites (build identity, switches, acceleration, simulation clock, visibility for COMBATRIG; other projects define their own conditions).

• Qualify condition probes with a real browser harness observing the same runtime that it measures, including drift detection through the measurement interval. Current receipts enforce project-reported pre/post contracts, not independent sensor truth or continuous monitoring. Real persistent Chromium qualification now PASS for healthy, preflight-frozen, mid-measurement-frozen and replaced-runtime cases. Preflight, measurement and postflight contact the same page; invalid conditions/replacement cannot count as exact passes. Optional reported runtime identity is now continuity-checked. Transient drift that recovers between probes, actual GPU/game conditions and project-specific harness qualification remain unfinished.

• Pass captured commit/input digest to the measurement command itself, not just condition probes. Real browser qualification exposed the missing wiring; conditioned and unconditional child-command regressions now enforce it.

• Require frozen receipt linkage to a finished prepared operation before exact-pass qualification; orphaned pass output after interruption is insufficient.

• Surface condition/snapshot receipt details and interrupted prepared checks in the dashboard rather than requiring CLI/MCP inspection. Read-only, bounded, project-scoped projection supports legacy databases; running records are explicitly unconfirmed, not assumed live or auto-restarted.

Condition-receipt verification: thirteen focused condition/resource/self-host tests PASS; final current-source acceptance PASS (38 groups, test/lint/syntax). Probe observations are project-reported; malformed/missing/mismatched preflight prevents measurements, invalid postflight makes green output incomplete. Long-running check services reload canonical policy before planning/execution and qualification. No live browser/GPU/provider or host timer was started.

• Add bounded commit-linked task activity and neglected owner-request detection, with owner requests first and incomplete coverage explicitly unknown.
• Wire landed Closes: intent into idempotent task completion only after matching current-policy verification, ownership, task state and exact landing evidence. Automatic closure is opt-in; read-only activity still only reports intent. Manager preview/confirmed reconciliation supports interruption/lock recovery without a second landing. Invalid items stay open.
• Qualify real specialist trailer conventions and live landing/closure recovery before enabling automatic closure in an installed fleet.

Landed-closure verification: seventeen focused integration/MCP/self-host tests PASS; final source acceptance PASS (38 groups, test/lint/syntax), including generated specialist instructions. Receipt: /tmp/torch-landed-closure-final-20260930-acceptance.json. Actual disposable Git landings prove closure/replay and locked-task failure recovery; default remains disabled. Source is uncommitted and not installed/live-qualified.

• Expose commit activity/stale coverage in the actual dashboard and isolated demo, with owner-request attention links, blocked-wait context and unknown coverage kept distinct from proven inactivity.
• Add configurable daily manager review of stale work via optional manager-check-in.action.stale_work bounds and existing approved scheduling. Owner requests first; direct-report tasks plus Fleet Operations' unassigned intake only; incomplete history stays unknown; blocked work is not restarted. Durable review deduplicates separately from routine check-ins and requires a fresh read-only MCP query before decisions. No task mutation or host timer is implied by observation or inbox delivery.
• Qualify an owner-approved installed daily stale-review cadence and manager follow-through with live specialists; local scheduler and durable delivery are tested, not real AI judgment or timer installation.
• Add non-disruptive 15-second live dashboard refresh with pause/resume, visible-tab-only polling and bounded reads. Edited/focused forms and active previews retain their existing DOM while unrelated evidence updates; the view explicitly labels retained panels as potentially older. Successful actions release only their own editor; background reads are single-flight and explicit newer requests supersede older responses. Failed reads retain displayed evidence.
• Qualify live installed-fleet refresh against real provider activity and native browser background/back-cache behavior. Controlled browser clock and visibility/page lifecycle events are verified locally without starting a fleet.

Activity verification: eighteen focused activity/backlog/MCP tests PASS; current-source acceptance PASS (38 required groups, test/lint/syntax). Commit messages remain untrusted intent, not completion authority. Missing/truncated managed history produces unknown absence of activity. Receipt: /tmp/torch-task-activity-20260930-acceptance.json.

• Persist delivery failures/attempt receipts and add bounded classified retries for explicitly safe delivery adapters without broadening approval. Per-delivery unresolved reservations prevent overlapping effects; unknown outcomes stop. Owner-attested not-applied recovery retains original evidence.
• Complete recovery for externally succeeded operations whose local lifecycle update was interrupted; preserve the receipt and do not re-execute. Owner-approved executor-stopped preview/reconciliation checks exact state, destination hash and current authority; repeat application is harmless.
• Qualify real adapter receipt identity and stopped-executor confirmations for success/not-applied recovery; project-reported success is not live proof.

Success-recovery verification: nine focused delivery/self-host scenarios PASS; all 38 current-source acceptance groups PASS (test/lint/syntax). Receipt: /tmp/torch-delivery-success-recovery-20260930-acceptance.json. Injected local failures and reopening prove zero re-execution, rollback, legacy preservation, destination/authority checks and idempotent replay. Not installed/live-qualified.

• Qualify real release/deploy adapters, provider-side idempotency and network classifications; adapters currently supplied through the service interface are not automatically installed or invoked by CLI configuration alone.
• Add bounded retries for safe canonical object fetch separately from release/deploy authority. Owner-confirmed CLI defaults to three attempts (one to five), retries only recognized transport failures, imports a resolved canonical SHA without moving refs/FETCH_HEAD and persists attempt receipts. Destination/policy changes stop subsequent attempts; raw transport errors and remote URLs are not persisted. Read-only CLI status/snapshot expose results.
• Surface latest canonical fetch and delivery attempt outcome details in the actual dashboard and shared demo. Project-scoped bounded receipts show classifications/effect uncertainty, with unconfirmed-running and adapter-success caveats, no retry/recovery buttons and no raw references or transport errors.
• Qualify real remote transport classification before relying on it operationally. Initial canonical head discovery fails closed, not retried.

Delivery-attempt verification: three focused scenarios PASS (original real lifecycle, durable retry/uncertainty/recovery, safety/limit/policy boundaries); current-source acceptance PASS (38 groups, test/lint/syntax). Receipt: /tmp/torch-delivery-attempts-20260930-acceptance.json. Actual provider behavior and receipt correctness remain project-adapter claims, not live qualification.

• Add configurable owner-first local digest of recorded shipping, structured approval decisions, blockers, owner approvals and neglected requests without another task queue. Read-only Markdown/JSON generation, approved durable publication, latest CLI/API view and typed owner-authorized scheduling are implemented; default automatic publication is disabled.
• Add the readable digest dashboard view/navigation to the actual Console and the shared isolated demo, with owner-first sections, recorded-versus-live labels, stale/unpublished/unknown/truncated states and safe text rendering.
• Add explicit opt-in external notification adapters; no public publication or message delivery is implied by local publication. Qualify an installed daily cadence only after owner approval. Unstructured manager decision documents need time-indexing before the digest can honestly claim complete coverage of management calls.

Digest verification: eight focused digest/self-host scenarios PASS; final current-source acceptance PASS (38 groups, test/lint/syntax). Receipt: /tmp/torch-owner-digest-final-20260930-acceptance.json. Local loopback verifies stable GET-only no-store retrieval; no real timer, AI wake, external send, public publication, stable install or fleet activation occurred.

Dashboard briefing follow-up: renderer/demo regression tests PASS and all 38 current-source acceptance groups PASS; receipt /tmp/torch-owner-briefing-final-20260930-acceptance.json. Real Playwright desktop and mobile demo checks PASS with zero live API calls, including sticky-navigation anchor clearance and expanded evidence width. Screenshots are saved under reports/design-system/torch-dashboard-owner-briefing-{desktop,mobile}.png.

• Add atomic self-claim under approved fleet policy and exception-only specialist escalation. Preserve resume-first/single-active assignment.
• Qualify the autonomous settle/claim loop with live specialists under an approved policy. Claim readiness is mechanically checked; model compliance with exception-only communication and fresh per-item instructions still requires a live trial.

Self-claim verification: twenty focused backlog/MCP/self-host tests PASS; final current-source acceptance PASS (38 groups, tests/lint/syntax). Real competing local processes preserve one active assignment. Blocked-to-active reactivation uses the same assignment lock/busy rule; priority selection now honors the existing owner-controlled priority field. Acceptance scenario IDs are matched as exact tokens, not substrings. No live fleet, timer or provider was launched; source remains uncommitted and stable installation is still gated.

• Add bounded dashboard auto-refresh with visible freshness/error state. Completed by the protected 15-second refresh checkpoint above; do not reopen this duplicate implementation task. Live installed-fleet/native browser qualification remains a separate unfinished gate.

Verification: frozen-input/resource/CLI/MCP scenarios PASS (11 focused tests); full current-source candidate acceptance PASS (38 groups, test/lint/syntax). The strengthened missing-evidence gate PASS (five focused self-host tests). No real browser/GPU workload, provider or timer was launched. Owned disposable snapshot copies were removed by the scenarios; source build files were retained.

Review follow-up

First-release trial correction: specification section 32 requires at least two domain managers to coordinate one real task, not merely one manager supervising two specialists. Review/activate the proposed lead graph separately from the pending roster, then record actual coordination evidence. A smaller rehearsal does not complete the release gate. Source checkpoint approval remains pending; generation-zero/no-launcher status and dirty-source rejection were revalidated.

2026-09-30 self-host readiness review: current candidate planning correctly rejects the dirty checkout; the real version store and stable launcher remain empty. Fresh no-provider intake finds ten candidate domains, 24 coordination boundaries, four project checks, and 18 unassigned components requiring roster review. These are not approved agent assignments. The ordered clean-checkpoint, commit-bound candidate, roster, stopped install, and bounded live-trial path is in reports/audit/self-host-readiness-2026-09-30.md. No agent or timer was started.

• The public demo now runs the actual Console at /console.html?demo=1, with tab-local sample state and working preview/confirm flows. Its link is View dashboard demo. Chromium verifies opening a separate tab, queued work, priority changes, messages, feedback, runtime profiles, approval and organization review, reset, mobile layout, and zero live API calls.
• Generated domain roles inherit the install runtime. Codex-only and mixed installations are tested; --default-runtime controls inheritance without replacing explicit per-role assignments. Architect validation accepts Pi and custom adapter identifiers while installation checks adapter trust and availability.
• Domain creation and merge/split proposals now inherit the installed default when runtime is omitted or default; a Codex-only Fleet no longer tries to introduce Claude for a newly proposed specialist.
• The work board now groups actual ready tasks in Queue. The prior open grouping did not match the backlog state model.
• Resolve manager wake policy for subscription/local runtimes. Explicit invocation-count mode now permits configured built-in adapters without claiming dollar enforcement; USD-hard-cap mode retains its exact receipt requirements. Shared UTC invocation budgets, pending-message recovery, duplicate suppression, and overlapping-wake reservations are tested.
• Qualify manager wake behavior with real configured providers after the fleet is ready and launch is authorized. Current evidence uses real adapter planning with simulated invocation, not live provider sessions.
• Add CLI inspection and owner-attested recovery of interrupted wake reservations. Recovery requires an offline manager, explicit stopped-runtime confirmation and evidence note; it is atomic/audited and retains budget and message replay guards. No provider is launched or message acknowledged. The read-only Console now exposes unknown launches in owner attention and Operations with reservation/message provenance. Following the warning opens the collapsed panel; observation never releases a launch lock.
• Qualify interrupted-wake recovery against live runtime lifecycle evidence; owner attestation is explicit but is not independent proof of termination.
• Qualify the updated source as a clean commit before self-host activation; older artifact receipts predate these changes. No fleet or timer has started.

Review verification (2026-09-30): full regression suite through isolated candidate acceptance PASS; npm run test:dashboard PASS; lint, syntax and diff hygiene PASS. The existing preview at http://127.0.0.1:4173/console.html?demo=1 serves the shared Console demo. Details: reports/audit/product-alignment-review-2026-09-29.md.

2026-09-30 self-host gate follow-up: candidate acceptance now explicitly requires provider-inheritance, count-mode wake, overlap reservation, wake-policy validation and interrupted-wake recovery evidence. Missing any one marker rejects acceptance even with green command exits. The updated current source passes all 38 acceptance groups using disposable HOME/TMPDIR/XDG state, including the full regression suite, lint and syntax checks. This is a source gate run, not a new installed candidate receipt or clean-commit qualification. Read-only live candidate status still reports no installed version, active version or stable launcher. Legacy branches remain present. User-owned dirty changes and the protected untracked fixture remain untouched.

This is the restart checklist for rewrite/portable-agent-fleet. The detailed state and evidence are in reports/audit/completion-audit-report-2026-09-27.md.

Current snapshot (2026-09-29)

This snapshot supersedes older counts and artifact paths further below. The latest isolated artifact-mode self-host candidate passed all 38 required acceptance scenarios plus npm test, lint, and syntax checks. Candidate acceptance now creates and removes a disposable HOME/TMPDIR/XDG environment so validation cannot share the active version store; the npm tarball bundles its pinned production dependencies so its offline-consumer gate does not depend on a warmed global cache. This build is non-commit-bound and isolated under /tmp/torch-selfhost-final.rD27ls; it is installed there only, with no active version or launcher. The exact artifact digest is 521a2d6af0931bc9461ad706f9809bda2c9f84cee92f6d62dc83dc306207a5f8. The latest read-only self-host design intake is /tmp/torch-self-bootstrap-current.tmVj5s/architect-brief.json, bound to HEAD d31437a4fb255c1e307bbb70ee9513cc1e0bdf4c and working-tree fingerprint 5b97b6850526da2f6ca01f6eefd9ea7ec7e57e2afe9247086cb670c5d4b0f7dc. It proposes nine code/QA domains, records 19 collision candidates for review, and identifies three repository-wide checks (test, check, lint). This proposal is pending and unapproved. Specialists now receive these project integration gates separately from domain-specific checks, without inferred gate ownership. The existing untracked test-torch-config-host-uQKdqL/ fixture appears among shared-surface candidates; it remains untouched and the proposed roster is not approved or installed. The Console Flow watch now allows preview-confirmed owner decisions only for requests named to the owner; requests assigned to a manager/peer remain read-only. Confirmation is same-origin, revision-bound, audited, and replay idempotent (SCN-console-owner-approval). Re-run intake after further code or documentation changes before owner review. No TORCH runtime, timer, or provider was started. The pre-existing untracked fixture remains untouched and was excluded from the candidate source copy.

2026-09-29 follow-up: manager scheduled wakes now require both the shared daily invocation count and an adapter-enforced positive per-invocation USD cap for the exact create/resume mode. The cap receipt is validated before count reservation; built-in Claude, Codex, and Pi modes all fail closed and leave the check-in queued. The landing page now links to a separate, noindex interactive dashboard demo at /demo.html and opens it in a new browser tab; it has no project/provider connection. Current working-tree verification: npm test 128/128 PASS, all 38 candidate acceptance scenarios PASS, lint/check and git diff --check PASS. This still does not qualify a committed candidate: live candidate status shows no installed/active version or launcher, and candidate plan --source is blocked by modified tracked files. No fleet, provider, or system timer was started.

2026-09-30 UTC: an exact mirror of the latest working tree, treated explicitly as a prepared non-Git artifact and excluding .git, local Torch state, reports, and the protected fixture, passed isolated candidate staging and acceptance. Digest f62082b3ea5424607dd7ff40790d7c9a9c67ab7141507338c6788bf55f0d00fc; receipt /tmp/torch-selfhost-tree-PuFzM2/state/torch/runtime/versions/0.1.0-alpha.0/.torch-validation.json. The isolated store reports the version installed but activeVersion: null and no launcher. This strengthens artifact-mode evidence only; source commit is null, the checkout still needs a reviewed clean commit for commit-bound qualification, and no project Fleet/provider/timer was started.

The Fleet dashboard now lets the owner review and change one identity's next-launch runtime/model/reasoning profile. Its same-origin preview calls the existing CLI validation path, clears old adapter-specific policy on provider switch, rechecks the exact config digest at confirmation, and records a profile.change audit event. It does not reconfigure an active session or start a runtime (SCN-console-runtime-profile).

The Console now also offers preview-confirmed setup or refresh of the persistent schedule timer. Review shows the configured system schedules (including mutating actions and provider-wake policy), exact owned unit paths/content digests, and the schedule configuration digest. Same-origin, five-minute, single-use confirmation rechecks the plan, audits the owner action, then calls the unit manager; observation reports file ownership/digest without claiming the timer is live. The tests use only a fake systemd executor; no host timer was installed (SCN-console-schedule-launcher).

Manager check-in wake messages now carry a timestamped, explicitly staleable snapshot and require a fresh read before the manager acts. The identity-bound, read-only torch_plan_manager_check_in MCP tool recomputes direct-report presence and structured approval waits from current durable state, including approvals created after a deduplicated wake was queued; specialists cannot use it to inspect manager reports. SCN-manager-check-in-refresh is required candidate-acceptance evidence. No manager is automatically granted another identity's approval authority.

Session Architect bootstrap now requires an evidence-backed flat-versus- coordination assessment. Any proposed lead must have a concrete integrated outcome, bounded decision scope and owner escalations; the contract separately states implementation, coordination, fleet-operations, priority, review, and owner-only authority while preserving direct peer communication. Validation rejects unresolved shapes, unknown evidence, fabricated domains, code-ownership or owner-approval grants, and manager-only routing in the architect assessment scenario. No provider or organization activation was involved.

Integration now has a durable FIFO drain over authorized requests via torch integrate drain --area <manager> --yes. Each fast-forward remains serialized and revalidated; after one lands, stale sibling tips are recorded as needs_convergence until their owner merges the latest main and reruns exact checks. This prevents concurrent landing races without relaxing check freshness. The Console exposes pending queue order, authorization, and wait reason read-only. A typed integration-drain action can now be added as an owner-authorized, at-least-minute system schedule. It only drains requests already authorized by the configured landing authority and reuses the same exact-check/FIFO/lock path; a test proves an unauthorized request stays put and a fresh authorized request lands. Defining the schedule does not install or start its exact-config systemd timer. Remote publishing is now a separate, owner-confirmed torch forge sync operation: it fast-forwards the configured remote to an already-landed local canonical commit, never force-pushes, blocks remote-ahead/diverged history, and writes an owner audit event. The SCN-forge-sync test passes against temporary local bare remotes. No TORCH runtime, timer, provider, or hosted remote was started. Remaining COMBATRIG parity differences are deliberate: TORCH does not automatically merge latest main into each candidate or run a batch of quick merged-tree checks in the lander. Source owners converge and record exact-commit check receipts before integration; remote publication remains separate.

Self-host candidate planning now lists non-ignored untracked Git paths that will be excluded from the exact-commit artifact; ignored local data remains unlisted and excluded. SCN-candidate-untracked-visibility verifies the plan and staged artifact agree while tracked modifications still block candidate staging. The isolated-candidate tests do not install the current dirty source tree into user-local state.

Latest isolated artifact qualification (2026-09-29): candidate version 0.1.0-alpha.0, digest 861bc58f94ecd7f8396a0cf1f5822a53ac3cd0eb2f2d576a3344fb20b7ea3aec, passed all 36 required scenarios plus npm test, lint, and syntax checks. Its receipt is /tmp/torch-hierarchy-candidate-de5hgZ/data/torch/runtime/versions/0.1.0-alpha.0/.torch-validation.json. The staged artifact omitted .git, .torch, .claude, .scheduler-memory, reports, coverage, and the protected untracked fixture; the local dependency tree was copied separately for offline gates. It is a working-tree artifact (source.commit: null), not a clean Git-commit candidate. Version state and launcher paths were redirected to /tmp; the active pointer and stable launcher are absent. No persistent install, activation, runtime, timer, or provider was started. Commit-bound candidate qualification remains open until a clean, reviewed source commit exists.

An earlier isolated artifact-mode snapshot passed the actual candidate acceptance runner: version 0.1.0-alpha.0, digest eee55b9a5af9ce83e70df6e5e718fc202e2f7e26e2a0a1cd5c7e38b20b10c11a, all 32 required scenarios, npm test, lint, and syntax checks. Its validation receipt is /tmp/torch-candidate-qualification-mGmYqa/state/torch/runtime/versions/0.1.0-alpha.0/.torch-validation.json. This was an explicitly filtered snapshot (.git, .torch, .claude, .scheduler-memory, reports, and the protected untracked fixture excluded), installed only in /tmp; verification found no active pointer or stable launcher. It is not a clean Git-commit candidate or persistent installation. That older receipt predates the candidate failure-diagnostics change and does not qualify the latest tree; the fresh isolated artifact qualification above supersedes it. SCN-candidate-failure-diagnostics verifies bounded stdout/stderr excerpts on failed acceptance while successful logs remain summarized. Commit-bound qualification against a clean Git candidate is still required before stable self-host installation.

2026-09-29 follow-up: the candidate acceptance runner was also invoked directly against the current working tree. It passed all 36 named scenario markers plus npm test, lint, and syntax checks. This proves the current checkout's gates and evidence mapping, but it did not stage a versioned candidate artifact; the isolated artifact qualification above provides that separate evidence. The first attempt inside the sandbox could not run the fixture-spawning tests; the successful run was repeated outside the sandbox without installing or activating TORCH.

2026-09-29 follow-up: after adding the organization lifecycle order preview, the current dirty working tree again passed all 38 named candidate acceptance scenarios, npm test, lint, and syntax checks through the isolated acceptance runner. This is current-tree evidence only; it did not stage a versioned candidate or authorize installation, activation, runtime launch, provider use, or timer installation.

Read-only COMBATRIG compatibility audit (2026-09-28) confirms the importer remains correctly blocked at source HEAD 7a543fe2a658a474f7598efec7a516172895f5fd and working-tree fingerprint fd399be1b70e8ec30ca0f85faf14c7c0218c544dfe1e0dd59a1a7f89926b4c1d. The 33 roster entries have 33 missing owned_paths declarations and 23 missing explicit not_scope declarations (56 blocking gaps total). Of 33 roster worktree references, 1 currently matches, 1 points at a mismatched branch, and 31 have no matching live worktree; do not reconcile these automatically because active/external work may be intentionally absent. The legacy backlog contains 570 items (148 assigned, 95 open, 5 blocked, 322 done), and the package exposes 461 test/build/QA scripts; the import only selects test:sessions, build, and test, so check mapping still needs human qualification. The report is /tmp/torch-combatrig-readonly-escalated-20260928.json. COMBATRIG remained unchanged (main behind origin/main by 4, pre-existing untracked .codex/); no worktrees, tests, gates, or migration actions were run there.

The importer now exposes an assessment-only backlog migration view, refreshed at /tmp/torch-combatrig-backlog-assessment-20260928.json. Current evidence: 12 items reference four area IDs absent from the roster (ai-contracts 3, contracts 1, music 7, roadway 1); 22 items are in the legacy ai-sessions queue; all 148 assigned items carry free-form assignedTo labels; 322 legacy done items cannot be called Torch completed without commit, evidence, and a landed integration request; and observedAt is absent on 125 items or malformed on 4. The assessment creates no Torch tasks and does not infer identities. Existing COMBATRIG work remains the source of truth until a separately reviewed queue migration.

Next safe implementation task

• Repair the Codex adapter for codex-cli 0.157.1:
  • do not combine --sandbox workspace-write with --approve-for-me;
  • put repository, approval, and MCP options before exec when resuming;
  • put resume-specific options after exec resume;
  • retain the worktree as the subprocess working directory and explicit command scope.
• Repair the Claude adapter for Claude Code 2.1.281:
  • do not supply or persist a synthetic --session-id with --bg;
  • mark background creation as requiring runtime-ID capture;
  • parse and validate the manager-assigned ID printed by Claude;
  • retain ownership verification before any stop operation.
• Correct SCN-claude-adapter, SCN-codex-adapter, and SCN-mixed-runtime with equally strict boundary assertions. Add the required Test Integrity Note documenting this as a spec correction plus stronger installed-contract coverage.
• Run focused adapter/lifecycle scenarios outside the sandbox where their temporary Git worktrees require it, followed by npm test, npm run lint, npm run check, and git diff --check.
• Refresh the completion audit with the new exact commit and evidence.

Historical adapter repair completed in d8ab841; its focused scenarios passed 8/8 and that tree's suite passed 61/61 with lint, syntax checks, and diff hygiene also passing.

New coordination reliability work

• Project the approved hierarchy's executable start and wind-down order in the owner Console. Snapshot data now shares the same topological ordering helper as runtime lifecycle plans, includes direct manager dependencies and graph blockers, and is explicitly read-only. The responsive view lists the exact startup order and its reverse shutdown order without exposing launch controls (SCN-console-readonly, SCN-hierarchy-aware-start-stop).
• Qualify serialized canonical landing. The landing path now holds a project SQLite BEGIN IMMEDIATE transaction across exact-plan revalidation, canonical fast-forward, and durable result recording; competing processes fail closed with INTEGRATION_LANDING_BUSY. SCN-integration- landing-serialization uses independent database handles to prove the lock boundary. Revised focused/full gates pass and prompt tests verify the single integration path. TORCH cannot stop users or agents with independent forge credentials from bypassing its local queue; hosted branch protection or credential isolation is optional defense in depth.
• Qualify current instructions on resume. Start and resume plans now rebuild digest-addressed prompts from canonical project files; Claude/Pi get current prompt-file flags and Codex gets a current instruction envelope in the resume turn. torch brief uses the same composer. The new regression scenario mutates canonical prompts and leaves stale worktree copies behind. Revised runtime scenarios pass; live provider resume remains a separate owner-authorized qualification gate.
• Include active organization roles, authority, reporting lines, direct reports, coordination links, and implementation ownership in each identity's digest-addressed start/resume bundle and torch brief. The current graph is rebuilt from canonical project config; resumed manager prompts cannot rely on stale worktree copies. SCN-current-instructions-on-resume now changes the graph and verifies updated context reaches the prompt without starting a runtime during planning.
• Complete hierarchy-aware manager check-in timers. Implemented now: durable structured approval requests name one owner/Fleet approver; requests notify AI approvers; only the named approver can decide; decisions are revision-checked, audited, and durably returned; owners decide through an explicit CLI confirmation; direct-report check-ins classify waits as manager, peer AI, or owner without taking over another approver's decision. Also implemented: read-only organization-aware check-in plans, durable deduplicated queueing, typed coordination schedule dispatch, a default 15-minute Session Manager schedule in proposals, and scenario coverage. Manager schedules are now derived for every reporting identity; hierarchy pilot plans show missing additions and obsolete candidates while preserving existing cadence and leaving activation to a distinct owner-confirmed CLI step. Owner hierarchy previews surface this timer delta and explicitly mark timer installation unverified. The owner can now inspect and explicitly reconcile an installed exact-config launcher with torch schedules launcher plan-reconcile / reconcile --yes; it verifies unit ownership, refreshes the digest-bearing service, updates the manifest, and rolls back on daemon-reload failure (SCN-system-schedule-launcher). Hand-edited interval schedules enforce the same 60-second minimum as generated schedules (SCN-manager-check-in-cadence-floor). An opt-in adapter-mediated wake is wired behind a shared project-wide daily invocation ceiling and skips active managers. Owner-confirmed hierarchy-activate now commits the approved organization graph, derived manager schedules, manifest hashes, and pilot record; it never changes systemd state or starts identities. When a launcher is installed, its digest becomes stale and the owner must separately reconcile it. Check-in wakes now carry a timestamped, potentially stale snapshot; before acting, a manager refreshes direct-report state and named approval waits through the identity-bound, read-only torch_plan_manager_check_in MCP tool. Specialists without direct reports cannot use it to inspect manager state, and it grants no approval authority (SCN-manager-check-in-refresh). Start/resume instruction bundles now derive manager duties from the active reporting graph, direct managers to refresh check-ins and route named approvals, and omit those duties from specialist-only bundles. SCN-hierarchy-aware-start-stop covers promoted middle-manager prompt behavior. Adapter contracts now declare hard-cap support separately for create/resume modes; scheduled wakes require a positive per-invocation USD cap, preflight an exact enforced-cap receipt, fail closed before invocation-count reservation when unsupported or mismatched, and reuse the prepared adapter plan. Tests prove the built-in Claude, Codex, and Pi adapters cannot currently wake managers because none declares an enforceable persistent-session cap (SCN-runtime-cost-ceiling, SCN-manager-check-in-cost-ceiling). The project-wide daily invocation ceiling remains an independent safeguard, not a dollar ceiling. Still needed: verify a genuine runtime/provider hard-cap mode and end-to-end timer qualification; telemetry or estimated price alone does not qualify. The Console Flow watch shows manager/report state, named approval waits, and configured cadence without implying that a timer is installed. Owner-addressed approval controls use the existing audited, named-approver decision path; manager-addressed requests cannot be decided there. Persistent timer installation and provider wake remain separate owner-authorized gates. Latest current-tree reliability validation (2026-09-29): npm test 125/125 PASS, npm run lint PASS, npm run check PASS, and git diff --check PASS. The manager refresh scenario verifies that a request created after a deduplicated wake remains visible through current-state refresh, and that a specialist cannot inspect manager reports. The hierarchy reconsideration scenario verifies revisioned evidence for one open proposal, refusal of same-window edits, fresh proposals after terminal decisions, and exact-retry idempotence. Direct runCandidateAcceptance on the current checkout passed 38/38 required scenario markers plus test, lint, and syntax gates. This is a working-tree check, not a staged or commit-bound candidate artifact. Tests use temporary Git fixtures and fake runtime/systemd executors. Lifecycle tests now prove hierarchy-derived parent-first startup, bottom-up shutdown/status routing, and fail-closed identity-cycle handling. No provider, Fleet session, host timer/service, or COMBATRIG mutation occurred. Pilot measurement/adoption/reversal, enforceable provider/runtime cost ceilings, live timer qualification, and commit-bound self-host qualification remain open.

Latest local verification before the profile-CLI addition (2026-09-28): npm test 75/75 PASS, npm run lint PASS, npm run check PASS, and git diff --check PASS. TORCH's read-only analyzer and no-provider bootstrap completed against this TORCH checkout and portable-fleet specification. This is a repo-intake smoke test only—not a TORCH install, self-host upgrade, or live provider qualification. The current self-host bootstrap artifact is /tmp/torch-self-bootstrap-20260928-profile-edits.json, bound to working-tree fingerprint c2e96b6cb8f62b703de144c93c445cde231c392fec03f02e357c4e7b6aa6bebc. The baseline remains pending with eight provisional domains; the brief surfaces 19 unassigned components, 15 specification signals, six repository-level shared candidates, and 14 collision candidates for Session Architect/owner review. A new guard now grants each deterministic domain only imported shared contracts evidenced by its dependency edges; unrelated root config and untracked fixtures are not blindly added to every domain's shared_paths. The existing untracked test-torch-config-host-uQKdqL/ remains untouched and is still visible as an analyzer review candidate. No provider was called, nothing was installed, and no agent sessions were started. The profile-CLI addition subsequently passed the full suite at 76/76, lint, syntax checks, and diff hygiene. That code change makes the bootstrap fingerprint and proposal above stale; regenerate the repo-intake artifact after the current code/docs pass is complete, then review the proposed roster without approving or installing it. The hierarchy view remains empty for this not-yet-installed self-host checkout. The completion audit below remains historical and has not been refreshed for this tree. The Pi adapter/MCP bridge and per-identity profile coverage subsequently passed npm test 79/79, npm run lint, npm run check, and git diff --check; Pi's bundled extension path now also resolves correctly when TORCH is installed under a directory containing spaces. This invalidates the earlier profile-edits bootstrap preview; regenerate it after the current code/docs pass, and leave the new proposal pending review. No Pi CLI, AI provider, or fleet session was started. The owner-console stale-evidence surface subsequently passed the full suite at 79/79, lint, syntax checks, and diff hygiene; it consumes existing read-only backlog-health findings and adds no parallel ledger. The Pi-adapter intake preview is stale after this dashboard change. Regenerate a final pending intake after the current code/docs pass, then review it without approving, installing, or starting the Fleet.

Latest local validation (2026-09-28): Codex identities default to gpt-6-luna / high, Claude identities to sonnet, with per-identity and per-runtime CLI overrides; Pi requires an explicit model. Locally installed adapters use a user-local, exact-hash, explicit-approval trust flow. The owner Console now also supports bounded project-scoped saved backlog views in browser storage; these filter the authoritative board and never write project/task state. Review, catalog listing, and doctor do not execute plugin code. The full suite now passes 93/93, with lint, syntax checks, and git diff --check passing. Runtime profiles now also expose adapter-specific launch policies as runtime defaults with per-identity overrides; doctor/start planning reject unsupported, unsafe, and conflicting values, while owner CLI edits require --yes, migrate legacy Codex policy without changing the effective sandbox, and only affect future plans. This is covered by SCN-runtime-launch-policy. Backlog tasks support optional feature/milestone classification by the Session Manager with revision checks and audit history; dashboard rollups derive only task-state progress from those same tasks and keep quality/release gates separate. Saved backlog views can filter both labels. The owner Console supports preview-confirmed priority changes and task proposals with durable audit history. New owner tasks remain proposed and unassigned; selected domains are routing hints, not agent assignments. Fleet and hierarchy proposal decisions now use preview-confirmed owner controls; approval stays staged and cannot activate the organization or launch a runtime. The public site and Console default to a dark theme and use the verified Torch v1 flame mark. The fresh read-only TORCH repo/spec intake is /tmp/torch-self-bootstrap-20260928-launch-policy.json, bound to HEAD d31437a4fb255c1e307bbb70ee9513cc1e0bdf4c and working-tree fingerprint 9fc23334b2a863176ca29c700f2f1859eb497cc118210a759605197f36eed1a0; its analysis reports mutation-free reconnaissance across 84 tracked and 22 untracked files. The baseline remains pending with eight provisional domains, 26 architecture components, and 15 collision candidates for owner/architect review. The checkout still has uncommitted changes, so it is not eligible for clean-commit candidate staging. The local dashboard preview was not listening at 127.0.0.1:4317 on 2026-09-29; it can be started separately for UI review and does not start the TORCH Fleet. Installed Pi 0.80.3 now passes an offline, no-session RPC startup smoke test with the bundled bridge and no model turn; TypeBox 1.1.38 is a declared exact runtime dependency so this also passes offline package distribution. No TORCH self-install or agent session occurred, and no provider was called. Next self-host gates: review/finalize the roster, land a clean Git candidate, and pass candidate acceptance against that committed source. A filtered artifact-mode snapshot passed all 36 candidate scenarios, but it does not substitute for commit-bound qualification or authorize stable self-host installation. COMBATRIG migration and live mixed-provider qualification remain separate owner-authorized gates.

Next safe implementation task

• Harden repository-analysis freshness before trusting a self-host proposal. Analysis now includes unignored, non-symlink regular files from the working tree and records a deterministic content fingerprint. Proposal approval and installation reject any changed fingerprint; the regression scenario proves that adding an untracked source file changes both the inferred design and its approval validity (SCN-analysis-working-tree, included in the 76/76 suite). The older /tmp/torch-self-design-20260928.json preview is stale. The current pending proposal is /tmp/torch-self-design-20260928-artifacts.json, bound to the fingerprint recorded above; inspect it before any approval and keep it outside the repository until owner review. This intake test is not a self-host installation or provider test.
• Keep specification prose from silently expanding repository ownership. The deterministic baseline now merges a responsibility only when its specification signal cites a concrete path present inside the analyzed repository; otherwise the signal remains visible for Session Architect/owner review. Prose-only projects still receive provisional groups with missing-path blockers. SCN-spec-evidence-grounding covers false attribution by keyword overlap.

Planned architecture follow-up

• Add the initial versioned organization-graph schema: it distinguishes owner-facing, program, fleet, domain-coordination, specialist, and independent-review roles; validates reporting links and prevents coordination roles from receiving owner-only approval or implementation owner authority.

• Complete ADR-011 adaptive organization. Implemented so far: initial graph schema; sustained-evidence, deduplicated durable proposals; explicit no-change and process-change alternatives; impact and pilot baseline/success/stop/ reversal fields; owner-only decision; CLI/MCP read/propose/plan surfaces; a project-configured read-only assessment of in-window cross-domain tasks, manager coordination requests, approval waits, and handoffs (SCN-hierarchy-pressure-assessment); a revisioned evidence history for open proposals, exact-retry deduplication, and reconsideration after terminal decisions (SCN-hierarchy-reconsideration-after-new-evidence); separate owner-confirmed CLI pilot activation that applies the graph and manager schedules in one scoped commit without launching sessions or timers; active-graph identity checks in doctor; and a dashboard map of approved roles, identity bindings, reporting, coordination, and implementation surfaces. Proposed roles and evidence must reference the active roster; new persistent identities still use the separate Fleet-evolution approval path. The Session Architect brief now requires an evidence-backed flat-versus- coordination assessment, outcome-based lead proposals, and explicit boundaries for implementation, coordination, fleet operations, priority, review, and owner-only authority. Semantic validation refuses unresolved shapes, unknown evidence, duplicate ownership/owner-approval grants, and manager-only peer routing (SCN-architect-organization-assessment). This recommends future organization only; it does not create or activate roles. Pilot evidence can now be recorded with hierarchy-review-pilot and read with hierarchy-pilot-reviews: exact baseline/criterion coverage, matching units, measured/qualitative/unavailable labels, linked reviewer-reported evidence, full-window adoption-recommendation gates, durable deduplicated history and atomic audit. Reviews do not mutate the graph or start anything. Separate CLI conclusion-plan/confirm paths now implement owner-only adoption and safe reversal. Fresh plan hashes bind tracked and active-work state; adoption needs the latest supporting review. Reversal restores prior relationships at a new revision while preserving owners, identities, worktrees, tasks and messages. Schedules remain for explicit review. Failed commits restore scoped files/index; interrupted local recording reconciles the exact committed receipt without a second commit. Confirmed retries are idempotent. No runtime or timer lifecycle change occurs. The Console now shows the latest five pilot reports per hierarchy proposal, with baseline/observed comparisons, units, evidence quality, interim/full review status, criterion outcomes and references. It explicitly labels these as reviewer-reported recommendations, not owner decisions or verified facts. Snapshot observation leaves history unchanged; the demo includes a qualitative inconclusive pilot for browser qualification. Still needed: collect/assess real fleet pressure, qualify pilot measurements and live adoption/reversal. Console conclusion preview/confirm now reuses the owner-only service path, binds target/operation/action/reason and fresh state, and provides no confirmation token for blocked plans. Same-origin API scenarios verify adoption, reversal, stale/cross-site/altered requests and idempotent replay; Chromium exercises blocked adoption and sample reversal with zero live API traffic. Adoption rechecks current calendar maturity rather than relying solely on a stored report flag. The Console now exposes owner-confirmed activation for an approved pilot through an exact-plan preview, loopback same-origin check, one-use token, and fresh-state revalidation before its scoped commit. It shows active work, manager schedule changes, blockers, and timer reconciliation; it never starts identities or changes systemd state. Current working-tree validation (2026-09-29): 38/38 candidate-acceptance scenarios, 126/126 tests, lint, and syntax checks pass. This is not a clean-commit release receipt and does not qualify a live hierarchy pilot. Invariant: preserve direct peer communication, the single backlog, implementation ownership, active work, and explicit runtime launch. Do not copy COMBATRIG's proposed hierarchy as the default.

• Complete ADR-012 per-identity runtime profiles and portable local adapters. Implemented so far: profiles carry an independently selected Claude, Codex, Pi, or explicitly registered adapter plus model/reasoning values per identity; startup and doctor report unsupported adapter capabilities without provider substitution; custom adapter contracts are testable; mixed-adapter planning has a regression scenario. Profile UX now includes torch profile show, torch profile set, and torch profile defaults; all writes require --yes, validate project config, and affect future launch plans only. Adapter-specific launch-policy validation and argument mapping are now implemented with fail-closed unsupported/unsafe handling. Still needed: supported-version Pi runtime coverage and live mixed-provider resume evidence. Pi now has a built-in resumable-turn adapter and a bundled extension that exposes the TORCH MCP tools through an identity-bound local bridge; local MCP bridge and launch-plan tests are supplemented by an installed Pi 0.80.3 offline/no-session startup test that loads the extension without a provider turn. The typebox dependency is declared and exact-version pinned so offline package installation remains verifiable. Third-party local runtimes can now be explicitly trusted by exact user-reviewed entrypoint hash and selected per identity; synthetic mixed-runtime planning passes without launching a provider. Pi extensions execute with Pi's full OS permissions; TORCH disables project extension discovery/trust and loads only its bundled bridge. Live mixed-provider coordination/resume remains an owner-authorized qualification gate. Built-in defaults are Codex gpt-6-luna / high reasoning and Claude sonnet; installed project config and individual identity entries can override these without changing global provider settings or starting a process. Codex passes reasoning via invocation-local config. Profile inheritance is resolved consistently by startup, doctor, live identity queries, and dashboard snapshots; the active identity surface exposes the effective runtime/model/reasoning profile.

Product experience follow-up

• Complete the adaptive owner dashboard. Implemented so far: a responsive, local read-only project cockpit with attention-first pulse, one authoritative backlog board, per-identity runtime/model/reasoning visibility, durable inter-session communication, exact-commit checks, integration/delivery gates, resource/worktree state, hierarchy proposals, a provenance-backed visual evidence catalog, and read-only backlog-health signals for stale or unreachable observedAt commits. These appear in the project pulse and on affected task cards. Agents may attach bounded images to owned backlog tasks with identity/session/full-commit provenance; bytes are privately stored outside the repository and digest-checked when served. Owners can preview feedback from the CLI and explicitly confirm a durable message to the responsible identity. The Console now offers feedback controls that first display the recipient, task, commit, durable-message effect, and exact message; only a fresh single-use preview token can confirm. Same-origin loopback checks, expiry, replay refusal, and stale-preview checks prevent cross-site or duplicate writes. The snapshot endpoint remains GET-only, and the Console gains no general task/message ledger or lifecycle authority. The view adapts to the observed roster. Saved, customizable project-aware backlog views now use bounded per-project browser preferences and do not create a second ledger. Backlog tasks now support optional feature and milestone labels, the manager can update them through revision-checked classification, and the Console derives progress from those same task records while keeping quality and release gates separate. The owner can now propose backlog tasks through same-origin preview/confirm; each is audited and remains unassigned for Session Manager triage. Fleet and hierarchy proposals now have owner-only, same-origin preview/confirm decisions bound to the exact proposal, reason, active graph, and current repository head. Fleet approval is explicitly only for later activation review; hierarchy approval only approves a pilot plan. Separate explicit hierarchy-activate commits the approved graph, schedules, and pilot record but does not provision a worktree or launch a runtime. Owners can now also send a preview-confirmed request to one approved roster identity, optionally linked to an existing active task; this becomes one audited durable inbox message and does not create/modify work, change ownership, or wake/start a session. Still needed: expose appropriately gated deeper workflow controls. Continue to avoid hard-coded COMBATRIG domains or hierarchy. Target experience:
  • a concise project pulse showing what is moving, what needs owner attention, current blockers, stale evidence, and the next consequential decisions;
  • project-aware kanban/backlog views with dependency, owner, status, resume, and verification evidence, backed by TORCH's single authoritative backlog;
  • an inter-session activity and communication view for durable messages, coordination requests, handoffs, acknowledgements, and decisions—never private model chain-of-thought;
  • a visual review gallery for screenshots and other artifacts, with exact task/session/commit provenance, user comments or annotations, and a clear feedback route into the responsible agent or backlog item;
  • feature and milestone progress with test receipts, integration state, release gates, deployment authority, and live-verification evidence kept as distinct states;
  • an organization/fleet view showing session health, runtime/model profile, work ownership, relationships, resource use, and approved hierarchy-change proposals;
  • safe owner controls to comment, prioritize, create or route work, accept or reject proposals, and request permitted agent actions. Every consequential operation must show its target, effects, evidence, and authority gate before execution; provider launches, spending, worktree removal, integration, release, and deployment remain separately authorized operations. Keep the interface responsive and accessible on desktop and mobile, local- first by default, evidence-linked, and explicit when data is unavailable or stale. Preserve the read-only observation API; expose only individually scoped, previewed owner actions and do not create parallel task/message ledgers.

Owner-authorized qualification still required

• Run a bounded Session Architect call and one live Claude/Codex multi-domain coordination/resume scenario with a fixed provider budget.
• Install and reverse the user-systemd scheduler, verifying one real dispatch and its receipts.
• Install an accepted TORCH version in user-local versioned state and use its stable launcher to manage this source checkout.
• Resolve COMBATRIG's 56 ownership/exclusion blockers, then separately authorize an import/cutover trial. Do not mutate COMBATRIG beforehand.
• Publish the package and deploy the public website only under explicit release scope.

Preserved boundaries

• Legacy branches remain legacy/nostr-torch and legacy/development-network-v2.
• Do not add, edit, or remove the pre-existing untracked test-torch-config-host-uQKdqL/ fixture.
• Do not push, publish, deploy, install persistent services, consume provider quota, or mutate COMBATRIG without renewed authorization.