infinity-harness 2.6.6 → 2.8.0

package/CHANGELOG.md

@@ -4,6 +4,86 @@ All notable changes to this project are documented here.
 Format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/); versions follow
 [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [2.8.0] — 2026-08-30
+
+The harness stops shipping its own run. The repo is the driver, not the project.
+
+### Changed
+
+- **`harness/` is now driver-only.** Runtime state (`harness/config.json`, `harness/plan.json`, `harness/features/feature-list.json`, `harness/progress.md`, `harness/session-handoff.md`, `harness/sprint-contract.md`, `harness/lessons-decisions.md`, `harness/capability/index.json`, `harness/run.json`, `harness/daemon.json`, `harness/supervisor.json`, `harness/activity.json`, `harness/rework.json`, `harness/replan.json`, `harness/loop-state.json`, `harness/next-session.json`, `harness/daemon.log`, `harness/.run-prompt.md`, `harness/.preflight`, `harness/run-journal.jsonl`, `harness/**/*.bak`, `harness/**/*.lock`, `harness/**/*.ilock`, `harness/worktrees/`) is git-ignored and deleted. Fresh clone shows no `SHIP 37/37` widget until `/infinity:init` creates a local (ignored) harness. Templates (`harness/docs`, `harness/skills`, `harness/features/feature-list.schema.json`, `harness/model-router.json`, `harness/ci`, `harness/scripts`) stay tracked. Fixes the dogfooding leak where every clone rendered its builder's SHIP bar.
+
+- **Refactored and simplified without changing behaviour.** Removed dead helpers (`migrateModelRouterTiers`, `tiersFromLegacyModelRouter`, `writeCanonicalWithLockSync`), replaced 11 inline `require()` calls with static imports, extracted `scheduler.ts` helpers (`isBudgetFull`, `hasSerializeTask`, `pickSerializeTask`, `isSerializeBlocked`, `eligibleTasks`, `groupKeyFor`, `roundRobin`), removed unused `WorkerSnapshot`/`tailWorkerOutput`/`listWorkers`/`nextModelForTask` exports, cleaned `goalState.ts`/`core/config.ts`/`modelRouter.ts` dead imports and empty blocks. Net −115 lines. `tsc --noEmit` clean and 35/35 tests pass.
+
+### Verified
+
+- `tsc --noEmit` clean · 35 unit tests pass · `harness/` on disk equals `harness/` tracked · fresh clone renders no legacy `SHIP 37/37`
+
+## [2.7.0] — 2026-08-29
+
+The work leaves your session. A run is driven by background pi processes on the models you
+routed them to, and the session you started it from becomes a control panel.
+
+### Fixed
+
+- **The run used your own session, your own model and your own tokens.** The loop pushed the brief
+  back into the session the human was typing in (`pi.sendUserMessage`), so that session's model did
+  every task whatever the router said, its context window carried the whole run, and a "session
+  handoff" replaced the human's terminal. Difficulty tiers had nowhere to be applied, because a
+  session has one model and it was yours. Work now runs in **separate `pi --mode rpc` child
+  processes**, one per unit, each started with `--model` from its tier. `src/supervisor.ts` drives
+  them from the extension's own process — plain JavaScript, no LLM, zero tokens in your session.
+
+- **Model routing did nothing.** `applyRouting` called `ctx.setModel` on the *live* session, which
+  is only ever right when that session is the worker. It now applies only under the legacy engine;
+  under the default engine the model is chosen when the worker is spawned, and the model that
+  actually answered is recorded (`servedModel`) and shown, so a reference that silently fell back
+  to pi's default is visible instead of invisible.
+
+- **Session handoff was not a handoff.** It replaced the human's session via `ctx.newSession`. The
+  handoff level now names the *unit* — goal, phase, sprint, feature, task, subtask — and one worker
+  owns one unit from start to finish. Crossing a unit boundary closes that worker and starts a new
+  one; because the model is chosen at spawn, **the session boundary and the model boundary are the
+  same boundary by construction.** A feature-level handoff really is one session for the whole
+  feature, and its tasks share that feature's hardest tier — which the wizard now says out loud in
+  the question that sets it.
+
+- **A fire-and-forget `spawnWorkers` in `decideNext` created empty attempt directories on every
+  failing gate** — litter in the project tree, an unawaited promise outliving its caller, and no
+  work done. Removed; background execution belongs to the supervisor.
+
+### Added
+
+- **`execution.engine`** — `background` (default) or `main-session` (the pre-2.7 behaviour, for a
+  machine that cannot spawn a second pi). Configurable from `/infinity:config`.
+- **`/infinity:workers`** — which background sessions exist, which unit and model each has, what it
+  is doing, and the recent log. Prints; never costs a turn.
+- **A background section in the widget and a Background panel on the dashboard** — a live worker
+  rail with unit, tier, model and context pressure, over a reverse-chronological log.
+- **`harness/supervisor.json` and `harness/activity.json`** — what is running and what has happened,
+  on disk, so a run that spans days outlives every terminal that watched part of it.
+- **Worker sessions are real sessions.** They are stored under `tmp/infinity-harness/sessions/`, so
+  `/resume` opens any of them, and each worker's prompt, event stream and output are kept beside it.
+
+### Reliability
+
+- **One driver per project.** A second pi window on the same project is refused the wheel and stays
+  a viewer — two supervisors would put two workers in one working tree.
+- **Orphaned workers are reaped.** A `SIGKILL`ed pi cannot close its child; the next session finds
+  the recorded pid and ends it.
+- **`stop()` is bounded.** Halting races every long await against a stop signal, so a wedged worker
+  cannot make the run unstoppable.
+- **A worker that did not discover the harness is restarted with it loaded**, so it can never edit
+  code it has no way to record.
+- **Windows**: the `pi.cmd` shim is resolved to the script it wraps and run with node directly;
+  a shell is used only when there is no alternative.
+
+### Verified
+
+`tsc --noEmit` clean · 36 unit test files · 16/17 e2e scenarios (live skipped), including a new
+**`background`** scenario that drives real `pi` and proves a child process is spawned on the routed
+model, that a unit boundary swaps both, that a coarser level does not, and that the main session's
+own model is asked for nothing the whole time.
+
 ## [2.6.6] — 2026-08-28
 
 Every phase shows its tracked work, tabs isolate it, and autopilot actually drives.

package/README.md

@@ -186,6 +186,35 @@ A rejection is pinned to the state of the project when you made it, so the run w
 same question again until the agent has actually changed something in response. If it never does,
 the run stops and says so instead of nagging forever.
 
+## Your session is a control panel
+
+The work does not happen in the pi session you start the harness from. That session shows you the
+plan, the background log and the commands; the run itself happens in **separate `pi` processes**,
+each with its own model, its own context window and its own session file.
+
+```
+  your pi session ──── widget · background log · /infinity:*      (no tokens spent on the run)
+        │
+        └── supervisor  plain JavaScript in the extension, no LLM
+              │
+              └── worker   pi --mode rpc --model <the tier's model>   ← the work happens here
+```
+
+That is what makes the difficulty tiers mean anything. A session has exactly one model, so if the
+run happens in *your* session, your model does every task however carefully you routed them — which
+is precisely what used to happen. Now the model is chosen when a worker is started.
+
+Set it with `/infinity:config` → **Execution** → *Where work runs*:
+
+| `execution.engine` | |
+|---|---|
+| `background` *(default)* | one background pi session per unit of work, on that unit's model |
+| `main-session` | the pre-2.7 behaviour — everything runs in your session, on your model |
+
+`/infinity:workers` prints which sessions exist, which unit and model each has, what it is doing and
+the recent log. It reads files; it never costs a turn. Workers keep their session files under
+`tmp/infinity-harness/sessions/`, so you can `/resume` any of them and read the whole transcript.
+
 ## One run, many sessions
 
 A harness that never starts a new pi session is a harness whose context window only ever grows.
@@ -197,18 +226,27 @@ Nothing the harness knows lives in the conversation. The plan, the phase, the ga
 retry budgets and the escalation ladder are all files under `harness/`, so a session boundary
 costs one thing: the brief — which is what the agent should have been working from anyway.
 
-So the run hands itself to a fresh session at each boundary, and the replacement picks up
-exactly where the last one stopped:
+`session.handoff` names one level of the plan, and that level is the **unit**: one worker owns one
+unit from start to finish, in one session, on one model. Crossing a unit boundary closes that
+worker and starts a new one — that is the handoff.
 
-| Setting | Fresh session when |
+| Setting | A fresh session, and a fresh model choice, when |
 |---|---|
-| `phase` *(default)* | the pipeline advances a phase, or a goal pass finishes |
-| `task` | that, plus every time the run moves to a different task |
-| `off` | never — one session for the whole run |
-
-Any of them also hands off early once the context passes `session.contextThreshold` (0.7 by
-default), because a handoff that arrives after compaction has arrived too late to be the thing
-that prevented it.
+| `off` / `goal` | never — one session for the whole run |
+| `phase` | the pipeline advances a phase |
+| `sprint` | the active sprint changes (or coarser) |
+| `feature` | the active feature changes (or coarser) |
+| `task` *(default)* | the active task changes (or coarser) |
+| `subtask` | the active subtask changes (or coarser) |
+
+**The model boundary is the session boundary.** Because a worker's model is chosen when it starts,
+whatever you pick here is also how often the model can change — so the difficulty that matters is
+the difficulty of the *unit*, not of the task. At `feature`, a feature runs on its hardest task's
+model and the easy tasks inside it get that model too. At `task`, each task gets its own tier. The
+wizard says which of those you are choosing in the question that sets the models.
+
+Any level also replaces the worker early once its context passes `session.contextThreshold`, because
+a handoff that arrives after compaction has arrived too late to be the thing that prevented it.
 
 The run itself — its id, its wall-clock budget, its iteration ceiling, its no-progress strikes
 and its position on the escalation ladder — lives in `harness/run.json` and is the same run
@@ -474,7 +512,14 @@ task.modelHint → byTask → byDifficulty → byFeature → bySprint → byPhas
 ```
 
 `master` is never assigned directly; it's reachable only through one-step consultation after the
-normal ladder is exhausted.
+normal ladder is exhausted. An escalation that names a stronger model is also a session boundary —
+the worker is replaced rather than switched, because putting a stronger model in front of the weaker
+one's failed reasoning is the context the escalation exists to get away from.
+
+An empty slot means "whatever model pi is on", and a background worker cannot inherit that by magic:
+the harness reads the model your session is on and passes it to the child explicitly. The widget and
+`/infinity:workers` show both what was asked for and what actually answered, so a reference that
+quietly fell back to a default is visible rather than invisible.
 
 **Reasoning models need headroom.** A reasoning model emits nothing on the content channel until it
 has finished thinking — measured at ~370 reasoning tokens to answer "reply with one word". If you
@@ -497,6 +542,10 @@ that looks like a broken endpoint but is only a small cap.
 | `infinity_spawn_worker` | Attempt one task in a clean-room worker |
 | `infinity_goal` | State a goal, review it, or check which pass it is on |
 
+Commands worth knowing: `/infinity:run` starts the run, `/infinity:workers` shows the background
+sessions and their log, `/infinity:halt` stops everything and closes them, `/infinity:approve` signs
+a phase that is waiting for you, and `/infinity:dashboard` opens the web view.
+
 ## Layout
 
 ```
@@ -509,6 +558,8 @@ infinity-harness/
 │   ├── ui/                        theme · planTree (the five levels, once)
 │   │                              · display (what to draw, and the templates)
 │   │                              · widget (terminal) · dashboard (web) · wizard · config
+│   ├── supervisor.ts              the orchestrator: which unit, which model, which session
+│   ├── exec/piWorker.ts           one background pi process, driven over RPC
 │   ├── loop.ts                    the continuous-run driver and its stop conditions
 │   ├── runState.ts                is a run armed, and which run is it — on disk, across sessions
 │   ├── handoff.ts                 when to continue in a fresh session, and what to tell it
@@ -526,16 +577,18 @@ infinity-harness/
 │   ├── features/feature-list.json the plan
 │   ├── config.json                pipeline state and settings
 │   ├── run.json                   the armed run — survives every session it spans
+│   ├── supervisor.json            which unit and which worker, right now
+│   ├── activity.json              the background log the widget and dashboard read
 │   ├── model-router.json          optional routing
 │   ├── docs/                      architecture · decisions · phase and role docs
 │   └── skills/                    28 craft skills the brief points at
 │
 │   ~/.pi/agent/infinity-harness/  the workflows and display templates you saved —
 │                                  they belong to you, not to a project
-├── tests/                         33 files, plain node:assert
+├── tests/                         36 files, plain node:assert
 └── scripts/
     ├── run-tests.mjs
-    ├── e2e.mjs                    16 scenarios, including one against a real pi process
+    ├── e2e.mjs                    17 scenarios, two of them against real pi processes
     └── rig/                       the real-pi driver: a scripted model + the RPC protocol
 ```
 
@@ -547,8 +600,8 @@ there is one implementation, and the adapter calls it.
 ```bash
 npm install
 npm run check                    # tsc --noEmit, strict
-npm test                         # 33 test files
-npm run e2e                      # 16 end-to-end scenarios
+npm test                         # 36 test files
+npm run e2e                      # 17 end-to-end scenarios
 npm run e2e -- --only realpi     # just the ones that drive a real pi process
 npm run e2e -- --list            # what the scenarios are
 ```