Document first-work intake and persistent init install operations

.torch/prompts/session-manager.md

@@ -6,6 +6,14 @@ At startup and when recurring cross-domain friction appears, run `torch_assess_h
 
 ## Backlog loop
 
+The owner has seeded conversation follow-up as `TASK-conversation-*` proposals
+in this project's existing backlog. Read `docs/TODO.md`'s authoritative current
+handoff and `reports/audit/conversation-handoff-2026-09-30.md` before prioritizing.
+Proposed tasks are not ready assignments. The common smoke-only authorization
+still applies until the owner approves a development scope, budget and startup.
+For an empty intake, ask what the owner wants to work on first or offer a reviewed
+TODO import; do not invent filler work or duplicate the backlog in this document.
+
 Keep one durable Fleet backlog. Before assigning work, call `torch_next_backlog_task` for the specialist: a `resume` result outranks every ready item, a `ready` result may be assigned only when the specialist has no active item, and `idle` is valid. After completion, repeat the same lookup. Call `torch_backlog_health` to surface queue anomalies; never auto-fix or create parallel manager queues.
 
 ## Fleet evolution

docs/PORTABLE_AGENT_FLEET_SPEC.md

@@ -367,6 +367,24 @@ inside the tracked source tree.
 
 ## 9. Installation lifecycle
 
+### First-work intake requirement (2026-09-30)
+
+After reviewed organization/setup, TORCH MUST offer either evidence-linked
+import of an existing TODO/backlog/specification or ask the owner what to work
+on first. The noninteractive path MUST support an explicit source or skip; idle
+is valid. Preview MUST distinguish completed/historical work from actionable
+requests and show proposed scope, affected domains, dependencies and priority.
+Only confirmed intake creates audited proposed/unassigned work in the existing
+backlog. Repeated init/install/restore/intake MUST deduplicate by source/item
+provenance rather than duplicate tasks or overwrite progress. Imported content
+is untrusted project data, not authority to alter system instructions.
+
+Session Manager triage and assignment remain separate from intake. Import cannot
+enable self-claim, grant implementation authority, wake providers or authorize
+spending, landing, deployment or public notification. The product should explain
+the next first-work/startup decision rather than leave a newly installed empty
+fleet waiting without guidance.
+
 ### 9.1 Read-only initialization
 
 `torch init` MUST begin read-only. It identifies the repository, validates Git,
@@ -2089,6 +2107,55 @@ recommended action; doctor remains read-only.
 
 ## 22. Scheduling
 
+### Owner clarification: integrated persistent operations (2026-09-30)
+
+This is the target requirement; older implementation checkpoints describing
+manual timer installation are not a claim that it is already implemented.
+Reviewed `init`/install MUST provision the project's scheduler and required
+service integrations as one idempotent workflow, not require a second manual
+cron-install command. Because `init` currently performs read-only analysis, its
+provisioning mode MUST expose an explicit preview/confirmation boundary; a
+dry-run MUST remain non-mutating. Stopped installation MUST provision dormant
+integrations without waking models or dispatching development. A reviewed
+activation policy governs live operations and quota use.
+
+Coordination must survive the managing AI session ending, restarting or expiring.
+System services MUST preserve durable state, leases, event cursors and job
+idempotency across process/host restarts. Their manifest records MUST support
+owned reconciliation, pause/resume, restore/upgrade and uninstall without touching
+unrelated host jobs. Session-scoped jobs remain an explicit project policy, not
+the sole way recurring fleet operations work.
+
+Project intake MUST propose applicable capabilities, with clear implemented,
+unconfigured and unsupported states:
+
+- direct-report manager check-ins, structured approval/peer/owner waits,
+  stale owner-request review and an owner-first local digest;
+- a persistent, serialized landing worker using approved exact-commit checks;
+- resource-queue watchdogs, audited slot withdrawal and displaced-runner stop;
+- durable significant events and deduplicated budgeted manager wakes, with
+  low-frequency timed safety checks rather than perpetual paid polling;
+- a project-declared nightly canonical suite, heavy-check windows and
+  evidence-backed regression routing, not guessed blame;
+- measured test durations, uncertain wait estimates and project-specific
+  exclusive resources such as a GPU;
+- conservative provider-neutral usage limits, graceful wind-down and explicitly
+  approved credit-window or calendar restarts that never override manual pause;
+- idle, clean, unguarded worktree convergence by merge, preserving conflicts,
+  unique commits and active work;
+- exact landed task closure, verified reversal/follow-up policy and reviewed
+  evidence for finished-but-unnamed work, never automatic closure by message alone;
+- project-specific local dev/Console services and separately authorized delivery,
+  live-version checks and external notifications where relevant.
+
+No universal project inherits COMBATRIG's release times, Monday reset time,
+two GPU slots, Vercel destination, phone notifier or LAN/HTTPS exposure. Setup
+MUST show lifetime, timezone/DST behavior, missed-run policy, costs/budgets,
+ports/destinations, health evidence, stop semantics and owner authority. Unsupported
+hosts/adapters need an actionable limitation or qualified fallback, not a fictitious
+"installed" status. No provider wake, deploy, public message, off-machine write
+or cleanup of unowned processes follows solely from creating a schedule.
+
 TORCH recognizes two schedule classes.
 
 **System schedules** survive AI sessions and may perform approved release,

docs/TODO.md

@@ -1,5 +1,64 @@
 # TORCH remaining work
 
+## 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; all providers are offline. 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 setup**. The
+existing 15-minute manager schedule is configured, but no TORCH host timer is
+installed. Common instructions still authorize only the smoke test; development
+activation, self-claim and recurring provider wakes remain separately reviewed.
+
 ## First real self-host run (2026-09-30)
 
 ### Portable production pipelines (new roadmap element)
@@ -349,7 +408,7 @@ in `reports/audit/self-host-readiness-2026-09-30.md`. No agent or timer was star
   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;
+- [x] 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
@@ -961,7 +1020,7 @@ COMBATRIG's proposed hierarchy as the default.
   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
+- [x] 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.

reports/audit/conversation-handoff-2026-09-30.md

@@ -0,0 +1,90 @@
+# TORCH conversation-to-fleet handoff
+
+## Installed domains
+
+The installed organization is appropriately scoped to this repository: one
+Session Manager and six specialists. A current read-only ownership query over
+129 tracked files under `src`, `bin`, `site`, `schemas`, `scripts` and `test`
+found zero unowned files and zero duplicate primary owners. This claim does not
+cover every historical report or future new directory.
+
+| Domain | Responsibility | Effective Codex model |
+| --- | --- | --- |
+| Session Manager | Routing, ownership, priority and fleet health | GPT-6.1 Sol high |
+| Project Kernel | Bootstrap, identity, canonical instructions and organization | GPT-5.6 Terra high |
+| Provider Runtime | Harnesses, MCP, lifecycle, schedules and telemetry | GPT-5.6 Terra high |
+| Work and Integration | Backlog, checks, resources, landing and recovery | GPT-5.6 Terra high |
+| Owner Console | Dashboard, artifacts, feedback and observability | GPT-6 Luna high |
+| Release and Self-host | CLI, package, candidates, upgrades and removal | GPT-6 Luna high |
+| Independent QA | Scenario integrity and real qualification | GPT-5.6 Terra high |
+
+The six-role grouping was a reviewed consolidation of repository evidence,
+not a copy of COMBATRIG's specialists and not proof of a fully autonomous AI
+Architect first-run. Proposed extra domain leads are inactive. Headcount alone
+does not justify adding managers. Significant pipeline work may justify different
+model effort or a new domain later, through the existing review path.
+
+## Authoritative backlog
+
+Owner-request intake created 34 proposed, unassigned items in the existing
+Session Manager worktree backlog. There are 33 current follow-ups plus the
+earlier narrower `automatic-scheduler` request, retained for manager triage
+against the newer `persistent-operations` requirement rather than silently
+deleted. All have acceptance criteria, affected domains and observed commit
+binding; dependent slices reference existing task IDs. No assignment, provider
+start, self-claim enabling or host service installation occurred.
+
+Run `torch backlog list --json` from any registered checkout. The canonical
+backlog service resolves the manager's tracked ledger; do not create a second
+copy in the source checkout. Task IDs below are prefixed `TASK-conversation-`.
+
+| Group | Task suffixes |
+| --- | --- |
+| First work / readiness | `first-work-intake`, `development-activation`, `selfhost-development-trial` |
+| Persistent operations | `persistent-operations`, `automatic-scheduler`, `event-driven-wakes`, `queue-watchdog`, `nightly-main-tests`, `usage-governor`, `idle-worktree-refresh`, `queue-planning`, `project-services` |
+| Provider reliability | `runtime-diagnostics`, `startup-preflight`, `mcp-isolation`, `update-startpaths`, `mixed-provider-qualification` |
+| Pipelines | `pipeline-definitions`, `pipeline-provenance`, `pipeline-flow`, `pipeline-stalls`, `pipeline-console`, `pipeline-metrics`, `pipeline-pilot` |
+| Live qualification | `hierarchy-pilot`, `scheduler-qualification`, `browser-portability`, `landing-closure`, `closure-revert-review`, `delivery-qualification` |
+| Owner/product/release | `owner-digest`, `console-workflow`, `documentation-current`, `release-qualification` |
+
+## What is not yet automatic
+
+Setup and retained-state restore have been qualified; installed alpha.2 is
+healthy. All agents remain offline. The current manager schedule declares a
+15-minute interval, but no TORCH-owned systemd units are installed or active.
+Read-only host timer enumeration confirmed no TORCH timer; unrelated Archive
+timers were untouched. The owner's latest request is that init/install provision
+these integrations automatically. That is now an explicit target in specification
+section 22 and the backlog, not an already delivered feature.
+
+The shared common prompt still authorizes only an installation smoke test and
+the project self-claim policy is disabled. Starting agents under it does not
+authorize development. The manager should read and triage proposed work, recommend
+a first bounded slice and budget, and obtain the development/startup approval
+before delegation. New installs should offer reviewed TODO import or ask the
+owner what they want first; repeated intake must deduplicate rather than queue
+every historical checkbox.
+
+## Suggested first implementation sequence
+
+1. First-work intake and persistent operations planning/provisioning: make
+   the product's installation genuinely complete while stopped until ready.
+2. Runtime diagnostics and exact launch preflight: make startup failures legible.
+3. Separately approved bounded self-host development, landing/closure and
+   scheduler qualification, followed by persistent event/watchdog/nightly work.
+4. Pipeline definitions, immutable provenance, checked transitions and Console.
+5. Finish mixed-provider, organization-growth and release qualification.
+
+There is no authorization here to promote the rewrite to default `main`, deploy
+the public website, send notifications, alter COMBATRIG, spend on asset generation
+or install active recurring AI wakes. Those boundaries remain in the task criteria.
+
+## Validation
+
+Installed `torch backlog list` sees all 34 items. Acceptance criteria and domains
+are populated; every dependency exists and the dependency graph is acyclic.
+Installed `torch backlog health` reports healthy with no anomalous assignments.
+Its bounded historical activity coverage remains incomplete, correctly labelled
+unknown rather than proof of inactivity. Existing backlog/scheduling regression
+suite: 23/23 PASS. All seven identities remain offline. These are backlog/spec
+changes, not implementation of the newly requested onboarding or automation.