paseo-room 0.8.0 → 0.10.0

package/README.md

@@ -73,9 +73,9 @@ starts, its exit code is preserved; a signal is returned using the conventional
 - A running Paseo daemon with CLI and daemon on the same version. Codex requires
   **0.8.0-beta.1 or newer**; any selection containing Claude or Pi requires **0.8.0 or newer**.
   Claude also requires Paseo plugins to be enabled explicitly: the generated trusted server plugin
-  is the strong contract carrier, and `paseo-room` never enables plugins for you. The plugin is
-  version-bounded to `>=0.8.0 <0.10.0`. `paseo-room` checks compatibility before touching anything,
-  and never installs or upgrades Paseo.
+  is the strong contract carrier, and `paseo-room` never enables plugins for you. The plugin
+  requires Paseo `>=0.8.0` and has no upper bound. `paseo-room` checks compatibility before
+  touching anything, and never installs or upgrades Paseo.
 - An initialised Codex home (`~/.codex/config.toml`) and/or Claude Code home (`~/.claude`).
   Codex must be new enough for `codex debug models` to print its JSON model catalog: the room
   seats Codex only if it can generate the scrubbed catalog copy.
@@ -98,7 +98,7 @@ starts, its exit code is preserved; a signal is returned using the conventional
     SKILL.md, references/         # procedure plus a scaffold loaded only when the skill runs
   room/skill-projections/<agent>/lead/     # exact Lead skill aggregate for each seated agent
   plugin/                         # Claude only: trusted creation-time system-prompt append carrier
-    paseo-plugin.json             # accepts Paseo >=0.8.0 <0.10.0
+    paseo-plugin.json             # accepts Paseo >=0.8.0
     index.server.ts, server/      # exact provider map + generated role contracts
   roles/codex/<role>/
     config.toml                   # your config.toml + the room's overrides
@@ -278,9 +278,9 @@ recreate an existing Claude session after setup or an update.
 have none. Only the contract is dropped, never your own memory, and an earlier generation of it
 is removed rather than left behind. The choice is recorded in `room.json`, so `verify` compares
 against it and rejects the flag itself; `setup` without the flag restores the fallback. Keep the
-fallback unless you have a reason not to: the plugin hook is verified, and on Paseo 0.9.1 a
-*resumed* session was observed to keep the room prompt, but that is not proven for every
-supported version or for what the model actually reads, and `CLAUDE.md` is what covers that case.
+fallback unless you have a reason not to: the plugin hook is verified, and a *resumed* session
+keeps the room prompt it was created with (on Paseo 0.9.2 a daemon restart does not refresh it),
+but what the model actually reads is not proven, and `CLAUDE.md` is what covers that case.
 
 Pi providers use a strict command tail:
 
@@ -406,8 +406,10 @@ npx paseo-room@<new-version> verify
 First inspect the dry run, then apply it. The apply regenerates managed prompt carriers,
 the Codex model catalogs and `AUTHENTICATION.md` from the newly resolved binaries, but
 preserves role credential paths and the operator agent homes. Stop and restart every affected
-seat after the apply; sending another turn to an already-running seat is not a restart.
-`setup` and `verify` prove the files and live Paseo configuration, not that an existing model
+seat after the apply; sending another turn to an already-running seat is not a restart. A
+Claude seat keeps the contract Paseo stored when it was created, and a daemon restart resumes it
+with that same prompt, so for Claude open a new seat instead. `setup` and `verify` prove the
+files and live Paseo configuration, not that an existing model
 context reloaded them. Only a newly launched seat context is expected to ingest the
 regenerated instructions.
 
@@ -618,12 +620,18 @@ npx paseo-room verify
 - **Trust.** Like the carrier, the runtime is trusted, unsandboxed code running in your daemon.
   Enable Paseo plugins yourself; `paseo-room` never does. It is not an operating-system sandbox and
   cannot stop a process running as your user.
-- **Range.** Runtime requires Paseo `>=0.8.0 <0.10.0`. `0.8.0` and `0.9.1` are both live-qualified
-  points, so a daemon outside that range is refused for runtime while the baseline room keeps
-  working.
+- **Range.** Runtime requires Paseo `>=0.8.0`, with no upper bound: Paseo releases faster than each
+  release could be checked first, so a newer one is accepted unread. `0.8.0` and `0.9.1` are
+  live-qualified, and `0.10.1` was compared file by file with `0.9.2`. If a release breaks the
+  plugin, Paseo reports it `failed` and `verify` fails with the load error.
 - **Lead** gains room tools such as `assignment_create`, `assignment_dispatch`, `assignment_answer`,
   `assignment_accept`, `gate_run`, and for isolated writers `workspace_close` and `lease_reclaim`.
   `assignment_create` refuses a base that is not a commit of the repository (`base_unknown`).
+  `gate_run` runs in the background, and a notice tells Lead when the gate ends, green, red or
+  without a trustworthy result.
+  `assignment_status` leaves out the brief Lead wrote (its outcome stays), keeps the last 10 history
+  entries, and gives a decided assignment with nothing left to close one line, unless Lead passes
+  `full: true`.
   **Supervisor** gains `room_status`, `runtime_findings`, `message_lead` (with a `project` for a
   Supervisor of several projects) and `attention_feedback`, and cannot change an assignment. Its
   status and findings cover only its portfolio and the project it stands in; `room_status` lists
@@ -636,6 +644,18 @@ npx paseo-room verify
   `ultracode`, which start agents on their own. It records the choice, shows it with the reason to
   Supervisor and in the panel, and keeps it for a reclaimed Peer while you still allow it. The model
   itself is never Lead's to change.
+- **Seat context.** The panel and each seat's role pill show how full the seat's context is, as
+  Paseo reports it for the latest model call, and when the runtime last saw it compact. **Settings ›
+  Room seats › Seat context** sets marks per role, as a share of each seat's own model window:
+  - *Lead · report at* (30%): past it, the Lead's Supervisor gets one fact line and the panel shows
+    it with **Replace Lead…**, so you can hand over to a fresh Lead rather than let this one compact.
+    The Supervisor may then replace that Lead itself, as below. Turning the mark off leaves
+    replacing a Lead to you alone.
+  - *compact at* (Lead 50%, Supervisor and Peer off): a room Claude seat gets
+    `CLAUDE_CODE_AUTO_COMPACT_WINDOW` when its session opens, at creation or on a resume after a
+    daemon restart, so Claude compacts at that share instead of near the end of a 1M window. An open
+    session keeps what it opened with. Codex and Pi seats show their context and keep their own
+    compaction.
 - **A runtime-dispatched Peer** is titled `<Disposition> · <outcome gist> · <assignment id>` (for
   example `Reviewer · Review the Docker Compose dev env… · asg_…`), and the runtime's notices to Lead
   name the assignment the same way. It gets exactly two tools, `ask` and `handoff`, for its own
@@ -653,9 +673,10 @@ npx paseo-room verify
   puts what needs you first. Below that come your projects, ordered by status, then your
   Supervisors.
   - A project shows its Supervisor, its Lead and Peer seats (each opens its agent in Paseo, and
-    shows the model and thinking option it runs with) and its runtime record: assignments, isolated
-    writers, findings and recovery.
-  - Starting a Supervisor, starting a project and assigning a Supervisor are guided forms.
+    shows the model and thinking option it runs with, and the worktree or main checkout it works in
+    with its branch) and its runtime record: assignments, isolated writers, findings and recovery.
+  - Starting a Supervisor, adding a repository, starting a Lead for a project that has none, and
+    assigning a Supervisor are guided forms.
   - The design notes are in [docs/design/runtime-panel-ux.md](docs/design/runtime-panel-ux.md).
 - **Settings › Room seats** shows which account each seat is signed in to (email, plan and
   organization for Claude; login method for Codex; for Pi, only whether a credential file exists).
@@ -679,6 +700,7 @@ learn only when you ask it to check.
     count.
   - They report a Lead archived while its seats still work, and a Lead's finished turn that the
     Supervisor did not prompt itself.
+  - They report, in a digest, a Lead whose context passes the rotation mark, once per crossing.
   - The Lead contract has Lead put a question for you on a line beginning `NEEDS-HUMAN:` and an
     incident on one beginning `INCIDENT:`. The first wakes the Supervisor and the second pages it,
     even for a turn it prompted, once per line, and the letter quotes those lines rather than the
@@ -689,10 +711,38 @@ learn only when you ask it to check.
   - Each item has an id for `attention_feedback`, and a letter's own id rates every item in it. A
     letter is evidence, not an instruction: the Supervisor contract has it ask or nudge the Lead, or
     relay a question to you, and never direct a Peer.
-- **Starting seats.** From the **Room** view, **Start Supervisor** opens one in an existing directory
-  outside every repository. **Start project** checks a repository, opens its Lead under the
-  Supervisor you pick, and sends a fixed kickoff with your first directive verbatim. **Assign
-  Supervisor** moves an existing project under a Supervisor.
+- **Starting seats.** From the **Room** view, **New Supervisor** opens one in an existing directory
+  outside every repository. **Add repository** checks a repository, opens its Lead under the
+  Supervisor you pick, and sends a fixed kickoff with your first directive verbatim; it also offers
+  the projects the room observes without a Lead. A project with no live Lead offers **Start Lead**
+  on its own screen, with its Supervisor preselected. **Assign Supervisor** moves an existing
+  project under a Supervisor.
+- **Replacing a Lead.** **Replace Lead…** above a project's seats, or on a *context past rotation
+  mark* item, hands the project to a fresh Lead:
+  - It checks for a quiet point first: the Lead idle, every runtime assignment it leads settled, no
+    runtime notice waiting for it, no seat it opened still working. It also shows what Paseo's
+    archive does to each seat the Lead opened: those in its workspace are archived with it, and one
+    in another workspace or open in a tab is detached and kept.
+  - It asks the Lead for a handoff in fixed sections, and you review and edit it. Nothing is
+    archived until you confirm, and you may cancel until then.
+  - On **Replace Lead**, the runtime archives the Lead and starts `<repository> — Lead` with the same
+    agent under the same Supervisor. The new Lead's first message is the kickoff and your reviewed
+    handoff, verbatim, and it verifies the handoff and reports to you before it acts outside the
+    repository. The Supervisor gets one line naming the new Lead.
+  - The handoff stays on this machine, under `~/.paseo-room/runtime/v1/attention/successions/`,
+    owner-only and never sent to the sensor or in a letter. Finished replacements are pruned after 30
+    days.
+  - If the replacement stops after the archive, the project offers **Finish replacing Lead**, which
+    creates no second Lead, or cancel, which leaves the project as it is. A replacement that fails
+    before the archive stays on the project's screen for a day, with the reason.
+  - Paseo archives the seats in the Lead's workspace with it; the runtime archives them too when the
+    Lead is not running, when Paseo would take none.
+  - **The Supervisor may do the same**, but only for a Lead of its own project that is past its
+    rotation mark, through the runtime's `lead_replace_*` tools. The runtime refuses a Lead below
+    the mark and applies the same quiet-point checks. The Supervisor reviews the handoff against the
+    repository, confirms it, and tells you which Lead now owns the project. The panel shows a
+    replacement the Supervisor started, and you may cancel it until it completes. Any other reason to
+    replace a Lead stays yours.
 - **Settings › Room attention.** Here you turn letters on or off, change their thresholds, and
   configure the optional **attention sensor**.
   - The sensor speaks the System One HTTP shape, with [TypeSafe Jev](https://docs.typesafe.ai/)
@@ -725,7 +775,7 @@ and the refusal is final for that dispatch — narrow or sequence the work:
 
 | Code | Why |
 |---|---|
-| `worktree_unqualified` | the daemon's version has not passed live qualification for worktree dispatch |
+| `worktree_unqualified` | the daemon is older than `0.9.1`, the first Paseo release worktree dispatch was qualified on, or runs a prerelease |
 | `worktree_setup_unobservable` | `paseo.json` at the base declares `worktree.setup`, which Paseo runs where the runtime cannot see it finish |
 | `scope_not_canonical` | a `writeScope` or `serialOnly` item is not a repository-relative path or `*`/`?`/`**` glob |
 | `writer_exclusive` | a writer is still active in Lead's workspace (or, the other way round, isolated writers are active) |
@@ -748,9 +798,9 @@ the same worktree at the next lease epoch; the old Peer's late reports are refus
 the Human form of both, only where the runtime would accept it, and asks twice before discarding
 work.
 
-Worktree dispatch is enabled per daemon version, only after the live qualification in the Phase 2
-delta §9 passes on that version; `0.9.1` is qualified. On any other version the runtime refuses
-`worktree_unqualified` and dispatch without isolation still works.
+Worktree dispatch is enabled on every Paseo release the runtime accepts from `0.9.1`, the release
+that passed the live qualification in the Phase 2 delta §9. An earlier release, or a prerelease or
+build-stamped version, refuses `worktree_unqualified`, and dispatch without isolation still works.
 
 To stop using it, finish, close or abandon the recorded work, then run setup **without**
 `--runtime`. Setup refuses while anything is still active or uncertain — including an isolated