paseo-room 0.9.0 → 0.11.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
@@ -620,9 +620,10 @@ 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`).
@@ -648,6 +649,8 @@ npx paseo-room verify
   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
@@ -667,18 +670,28 @@ npx paseo-room verify
   cleans or stashes, and releases a writer only after Paseo proves the Peer archived.
 - **State** lives under `~/.paseo-room/runtime/v1` as append-only event files. Setup never edits it.
 - **The Room runtime panel** (sidebar item, and a workspace panel that opens on its own project)
-  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.
+  puts what needs you first. Below that come your projects, then your Supervisors.
+  - Each project is one line: a status mark whose shape says it (needs a look, working, idle, or
+    asleep — its sessions closed, resumed by opening one or a message), then what it is doing, such
+    as *Lead idle · 1 of 2 Peers working · 3 open · 1 waiting on Lead*, and when it last did
+    something. Projects needing a look come first, then working, idle and asleep ones, the most
+    recently active first. Projects with no live seat fold into one *inactive* line, unless
+    dispatched work there is still undecided or a Lead replacement is in progress.
+  - A project shows who watches it, its Lead and Peer seats (each opens its agent in Paseo, and
+    shows the model and thinking option it runs with, the worktree or main checkout it works in, and
+    its context as a bar with a tick at its mark), recent activity (dispatches, handbacks, gates and
+    decisions, with who did them), and its assignments: open ones first, the most recently updated on
+    top, and finished ones by day with when they settled and how long they took, twenty at a time.
+    An assignment shows its brief, Peer, evidence and history.
   - Starting a Supervisor, adding a repository, starting a Lead for a project that has none, and
-    assigning a Supervisor are guided forms.
+    assigning a Supervisor are guided forms. The bell and people icons open the two settings
+    screens.
   - 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).
   It runs each seat's own `claude auth status` or `codex login status` when you open it or press
-  Refresh, and never reads a credential file. A seat linked to another home's login is flagged.
+  Refresh, and never reads a credential file. A seat linked to another home's login is flagged, and
+  when seats sign in as more than one account, each gets a letter (*account A*, *account B*).
 
 ### Room attention: what reaches a Supervisor
 
@@ -734,8 +747,17 @@ learn only when you ask it to check.
     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.
-- **Settings › Room attention.** Here you turn letters on or off, change their thresholds, and
-  configure the optional **attention sensor**.
+  - **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, see what reached Supervisors in
+  the last 24 hours (letters by level, incidents, Lead turns by what was decided, and the ratings you
+  or a Supervisor gave), change when a Supervisor is told and how often, and configure the optional
+  **attention sensor** in the order it is set up: mode and state, connection, privacy, then the
+  shadow evaluation beside the switch that lets it assist.
   - The sensor speaks the System One HTTP shape, with [TypeSafe Jev](https://docs.typesafe.ai/)
     first and any compatible or self-hosted endpoint after it. It is `off` by default.
   - Without a TypeSafe key, use Jev through OpenRouter: endpoint
@@ -766,7 +788,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) |
@@ -789,9 +811,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