omp-conductor 0.14.0 → 0.15.1

package/README.md

@@ -31,20 +31,24 @@ needs a human. It never edits product code and never pushes a branch; whether it
 may merge or release is a setup answer (`authority`), and both default to no. Only
 tier 2 pages you directly.
 
-The package ships three deployables, plus two skills:
+The package ships two deployables:
 
 | Deployable | Entry | What it is for |
 | --- | --- | --- |
-| omp plugin | `/conductor` slash command | Inspect and control the fleet from inside an omp session: status, hold/halt, arm/disarm, pause/resume, setup. |
-| Standalone daemon | `omp-conductor` binary | The dispatch loop, managed as a background process (`start` / `stop` / `restart`) with a `/healthz` endpoint for a supervisor. |
+| Everything an operator does | `omp-conductor` binary | The only operator surface: setup, inspect, control, and the dispatch loop itself as a background process (`start` / `stop` / `restart`) with a `/healthz` endpoint for a supervisor. |
 | Orchestrator heartbeat | omp extension, activated by `.conductor-tick.json` | Prompts a 24/7 orchestrator session on a fixed interval so its standing loop actually runs, and marks the session stalled when its prompts stop being consumed. Inert in every other session — including a second session opened in the fleet's own directory. See [Orchestrator tick](#orchestrator-tick). |
-| Onboarding skill | `skill://conductor-onboarding` | Directs an omp session to interview you, read your repos for real CI gates, and tailor `ORCHESTRATOR.md` — then finish through the wizard. Discovered automatically once the plugin is installed. See [Onboarding](#onboarding). |
-| Update skill | `skill://conductor-update` | Thin natural-language wrapper over the deterministic `omp-conductor upgrade` command. See [Updating](#updating). |
 
-The first two are thin wrappers over the same `daemon.ts`, so the plugin and the
-CLI cannot disagree about what a cap means or where the state lives. Claiming is
-gated by the pause flag; tick sends are gated by the arm marker — they are not
-the same switch. Prefer `hold` when you want both quiet.
+**There is no slash command and no skill.** Earlier releases shipped a
+`/conductor` command and a `skill://conductor-onboarding`; both are gone. The
+interview they wrapped now lives in the binary as `omp-conductor setup`, which is
+the documented path for every operator and agent — see [Onboarding](#onboarding).
+An omp chat session that wants conductor state or wants to change it **shells out
+to `omp-conductor`**, which is why the verb ledger records who asked: a session
+that ran a verb is indistinguishable from an operator who ran the same verb, and
+that is the point.
+
+Claiming is gated by the pause flag; tick sends are gated by the arm marker — they
+are not the same switch. Prefer `hold` when you want both quiet.
 
 ## Your workflow vs. the package
 
@@ -60,7 +64,7 @@ once, on request, and then never reads it back, never rewrites it and never
 enforces a word of it. What you write there binds your orchestrator session and
 nothing else in this package.
 
-`/conductor setup` offers to render the shipped template
+`omp-conductor setup` offers to render the shipped template
 (`src/briefs/orchestrator.md`) to `<workspaceRoot>/ORCHESTRATOR.md` with your
 project's coordinates filled in, and never replaces an existing file without a
 second, explicit confirmation. It is a starting point rather than a contract:
@@ -88,7 +92,7 @@ with the prompt instead of only in a brief the session read hours ago. Explicit
 policies name their actual interrupt categories and digest cadence. The policy is
 re-read from `~/.omp/conductor/config.json` on **every** tick, and escalation,
 direct Telegram, and durable report paths apply it mechanically. Turning the
-volume up or down — `/conductor setup` again, or an edit to the file — therefore
+volume up or down — `omp-conductor setup` again, or an edit to the file — therefore
 binds the next tick without restarting the session.
 
 No config, an unreadable or invalid config, or several unnamed projects fall
@@ -114,7 +118,7 @@ backend would swap in.
 
 You tell the conductor where to look with three keys, all in
 `~/.omp/conductor/config.json` (the [Configuration](#configuration) section has
-the full annotated example, and `/conductor setup` will interview you for these
+the full annotated example, and `omp-conductor setup` will interview you for these
 and create any missing labels):
 
 | Key | Meaning |
@@ -132,6 +136,10 @@ number of code repos, and both label names are yours to configure.
 omp plugin install omp-conductor
 ```
 
+That installs the `omp-conductor` binary and the orchestrator heartbeat extension.
+It registers **no slash command and no skills** — everything an operator does is a
+verb on the binary, starting with `omp-conductor setup`.
+
 From a checkout of the monorepo, `./setup.sh` checks both plugins. It preserves
 an existing npm-managed `omp-conductor` and links only the Herdr half, so running
 setup on a release-based fleet cannot silently switch omp to mutable source.
@@ -261,60 +269,89 @@ The command never publishes npm, edits an install root, or delegates lifecycle
 steps to an AI session. It refuses to run inside a Herdr-managed session because
 an updater that restarts itself cannot verify the result.
 
-The bundled `skill://conductor-update` remains available as a natural-language
-entry point, but it only runs this command; the lifecycle is implemented and
-verified by the CLI.
-
 ## Onboarding
 
-Onboarding this package has two layers, and installing it gives you both.
+`omp-conductor setup` is the whole of it. One command, in a plain terminal, doing
+the two jobs onboarding has always had:
 
-| Layer | What it is | What it owns |
-| --- | --- | --- |
-| **`/conductor setup`** | The deterministic wizard. It shows the label, runtime, and dry-run plans before one consent step. A configured project can amend one area. | **Mechanical setup.** It writes `config.json`, labels, the brief, an external heartbeat config, and a staged systemd unit. It also completes the paused smoke and arm gates. |
-| **`skill://conductor-onboarding`** | A skill bundled in this package (`skills/conductor-onboarding/SKILL.md`). Any omp session can discover it after plugin installation. | **Brief authoring.** It supplies the judgment that fixed prompts cannot. |
+| Half | What it does |
+| --- | --- |
+| **The interview** | Asks the judgment no amount of repo reading produces, then writes it into `POLICY.md` as prose you own and can edit. |
+| **The probes** | Reads your repos and *proposes* the rest — real CI gates, the project context, the release procedure — each a default you edit or a draft you confirm. |
 
-The split exists because the two halves fail differently. A wrong config value is
+The split matters because the two halves fail differently. A wrong config value is
 a run that errors on the next tick; a wrong release boundary is a fleet that
-publishes something at 03:00. The first is worth a text prompt with validation.
-The second is worth an interview.
-
-So the skill does the part a dialog cannot:
-
-- **Interviews you** on release policy — humans release (the default), the agent
-  releases to a named boundary, or the agent releases fully — pressing on the one
-  question that makes a delegated release safe: *where does the agent's leg end?*
-  The answer becomes the [`authority`](#configuration) pair `/conductor setup`
-  records, and the brief is worded from it. Plus escalation taste, and which of
-  the three [`reporting.scope`](#your-workflow-vs-the-package)
-  values your answer actually maps to.
-- **Reads your repos instead of asking about them.** It opens each routing repo's
-  CI workflows, `package.json` scripts and `Makefile`/`justfile`, then *proposes*
-  the exact pre-push [gates](#configuration) with the `cwd` each runs from, so the
-  gates match what CI runs.
-- **Tailors `ORCHESTRATOR.md`** from the shipped template. The template is the
-  floor: it rewrites the Releases and Reporting sections from your answers, adds
-  the hard boundaries only you know about (infra directories, off-limits repos),
-  leaves the fixed sections alone, and shows you the diff before writing.
-- **Verifies the worker brief's assumptions** against reality: default branch per
-  repo, whether the branch names the conductor cuts survive your branch
-  protection, whether each proposed gate exists and exits 0 on a clean checkout,
-  and whether `pull_request` actually fires — a workflow that never triggers on a
-  PR gives a worker no checks to watch and no verdict to reach.
-- **Then finishes through the wizard**, so the dry run and the consent gate still
-  do the writing.
-
-From an omp session with the plugin installed, just say what you want: "help me
-set up conductor", "onboard me", "configure the fleet" all reach it, because that
-is what the skill's description matches on. With `skills.enableSkillCommands`
-turned on you can also invoke it directly:
+publishes something at 03:00. The first is worth a validated prompt. The second is
+worth being asked properly, which is why it is asked and never guessed.
+
+### What only you can answer
+
+Always asked: **where the roadmap lives and what the current priority is.** A
+tracker shows what is *open*, never what *matters*, and an orchestrator that cannot
+rank work grooms by recency — which is how a stale issue outranks the thing you are
+shipping this month.
+
+Asked only when you grant the orchestrator a release shape, because a
+humans-release fleet has no boundary to draw:
+
+- **Where the orchestrator's leg ENDS**, in one sentence. If it cannot be said in
+  one sentence it is not a boundary, and a vague release mandate is what eventually
+  publishes something at 03:00.
+- **What** may be released and from which branch; **when** — batched how, after
+  which *named* checks; **what proof** must be held first, results actually read
+  rather than an impression; **what must still be asked** every time; and **what
+  stays permanently forbidden**.
+- **What makes a release worth cutting** — a sprint, an epic's children all closed,
+  N merged issues. Without it the orchestrator either releases per merge, a stream
+  of meaningless versions burning shared runners, or never releases at all.
+- **Who owns the rollback.** Name a person and setup says so plainly: that person
+  already owns the release, so the honest configuration ends the agent's leg
+  *before* the irreversible step. It offers to move the boundary there; declining
+  is a choice, not a mistake.
+
+Grant every release shape and setup pushes back once — credentials sitting in the
+environment of a session that runs unattended for weeks, and a 03:00 rollback being
+a judgement call under time pressure with partial information — then records what
+you decide. It is your fleet.
+
+### What setup reads for you
+
+Rather than asking about your repos, setup reads them. Each probe is a short,
+confined session in a throwaway shallow clone, and **every answer is a proposal**:
+
+- **Gates.** Reads each routing repo's CI workflows, `package.json` scripts and
+  `Makefile`/`justfile`, then pre-fills the [gates](#configuration) prompt with the
+  exact commands and the `cwd` each runs from, so your gates match what CI runs. It
+  reports the evidence it used, and an honest "this repo has no cheap local check"
+  is a real answer rather than an invented `npm test`.
+- **Project context** and **the release procedure.** Drafted across *every* routing
+  repo — which repo owns which concern, which ship together, where the release
+  machinery actually lives — then shown to you in full and kept **only if you
+  confirm**. `POLICY.md` is re-read on every tick, so a paragraph you never read
+  would become an instruction the orchestrator follows all week.
+
+A probe has **no shell, no editor and no verbs**: it reads files and answers, and a
+tool it was not given is refused rather than allowed. It is not a sandbox — it runs
+as your own user and reads what you can read — which is why it is pointed only at
+repos you configured yourself.
+
+**Setup never fails because a probe did.** No omp peer on the host, a repo it cannot
+clone, a cap reached, prose where JSON was asked for: each costs one warning and
+leaves the shipped stub, which says what belongs there and how to fill it in. Every
+question is still asked.
+
+Skip the reading half entirely with `--no-ai`:
 
-```text
-/skill:conductor-onboarding
+```bash
+omp-conductor setup --no-ai
 ```
 
-Nothing about the wizard changes: `/conductor setup` on its own remains a
-complete, supported path, and the brief it renders is safe unedited.
+To fill in or revise just the brief later — the two `POLICY.md` sections above — run
+the `brief` area, which re-asks the judgment questions and re-runs the probes:
+
+```bash
+omp-conductor setup brief
+```
 
 ### Changing one setting
 
@@ -329,6 +366,8 @@ opens with one question:
     asks one area's questions; every other answer is carried through from the saved config
   Walk every question again
     the full interview, every prompt pre-filled with what is configured now
+  Add another project
+    full interview for a new project; existing projects stay as they are
 ```
 
 Amending is the default. Pick it and the eight areas are listed with what each one
@@ -362,13 +401,45 @@ amending       code graph  —  project platform
 
 A first run, or a project name this config has never seen, never sees either
 question: there is nothing to amend, so it is the full interview exactly as
-before. Choosing *Walk every question again* is also unchanged — every prompt
+before. Choosing *Walk every question again* asks once to confirm the replace
+(so a silent overwrite cannot happen from muscle-memory Enter) — every prompt
 pre-filled with what is configured, Enter to keep it — with one wrinkle worth
 knowing: the two authority confirms and the orchestrator-session confirm cannot
 start on "yes", so Entering through the full interview **revokes** a delegation
 rather than renewing it. Amending the `authority` area names the current grant in
 the question, which is the safer way to leave one alone.
 
+### Adding another project
+
+One daemon serves every configured project. To put a second (or third) fleet on
+the same host without touching the first:
+
+```bash
+omp-conductor setup --project second
+# or pick "Add another project" from the re-run chooser
+```
+
+That is a full interview for the new name only. Defaults land under
+`~/.omp/conductor/projects/<name>/{worktrees,mirrors}` so two fleets never share
+a cwd; the first project's existing flat `worktrees`/`mirrors` paths are never
+migrated. A `workspaceRoot` that collides with another project is refused with
+both names in the error. Re-using an existing name asks amend-or-replace before
+anything is written.
+
+After apply, setup provisions labels, brief, tick config (with `project` +
+`agentName`), topic binding, smoke, and arm for the new project only, then prints:
+
+- `omp-conductor restart --now` — the running daemon picks up the new project
+  only after reload (printed, not auto-run when workers are live)
+- a copy-pasteable **herdr handoff**: `herdr --session conductor workspace create
+  --cwd <workspaceRoot> --label <project> --no-focus`, then `herdr --session
+  conductor agent start <project> --kind omp --pane <pane-id>` into that empty
+  pane (never into a live orchestrator), plus the `FLEET_CWDS` list for
+  multi-fleet recovery
+
+`omp-conductor setup gates --project second` (and every other area) still amends
+only that project.
+
 ### Keeping a brief current
 
 The standing prompt is two layers:
@@ -379,7 +450,6 @@ The standing prompt is two layers:
 | Fleet policy | `POLICY.md` | Yours. Setup writes the scaffold once; the Learning loop edits only this file. |
 | Composed view | `ORCHESTRATOR.md` | Regenerated from floor + `POLICY.md` on each tick (and at setup). Do not hand-amend it for durable policy. |
 | Worker brief | `src/briefs/worker.md` | Read per run from the package. |
-| Onboarding skill | `skills/conductor-onboarding/SKILL.md` | Read from the installed package. |
 
 ```bash
 omp-conductor brief-upgrade                 # report overlay / legacy state
@@ -436,7 +506,7 @@ time Telegram approval, `POLICY.md`-only edit, Hard-boundary prohibition, and
 3. Run the wizard:
 
    ```text
-   /conductor setup
+   omp-conductor setup
    ```
 
    The wizard reads the tracker with the same routing code as the daemon. It shows every issue that the next tick can route.
@@ -506,18 +576,19 @@ The package also ships a generic unit at
 [`systemd/omp-conductor.service.example`](systemd/omp-conductor.service.example).
 
 
-### Stop the conductor (hold / halt)
+### Stop the conductor (hold / stop)
 
-Four control planes used to answer "stop" differently. The package verbs:
+Two words, and one of them takes a flag:
 
 | Verb | Claiming | Tick sends | Dispatch daemon | Conductor pane |
 | --- | --- | --- | --- | --- |
 | `hold` | paused | disarmed | left running | left running |
-| `halt` | paused | disarmed | stopped (systemctl-aware) | left running |
-| `halt --pane` | paused | disarmed | stopped | stopped + recovery pinned off |
-| `pause` | paused | **still armed** | left running | left running |
+| `stop` | paused | disarmed | stopped (systemctl-aware) | left running |
+| `stop --pane` | paused | disarmed | stopped | stopped + recovery pinned off |
+
+`resume` clears pause **and** any `stop --pane` recovery pin, and **never re-arms**. `arm` is proof-gated: it sends a Telegram challenge and writes the arm marker only after your reply appears as a *user* turn in the orchestrator transcript. `stop --pane` targets the configured conductor agent only — it does **not** run `systemctl stop herdr-fleet`. To bounce the daemon without stopping the fleet, use `restart`.
 
-`resume` clears pause only and **never re-arms**. `arm` is proof-gated: it sends a Telegram challenge and writes the arm marker only after your reply appears as a *user* turn in the orchestrator transcript. `halt --pane` targets the configured conductor agent only — it does **not** run `systemctl stop herdr-fleet`.
+**Removed in 0.15.0**, each exiting `2` with a pointer: `halt` (now `stop`), `pause` (use `hold`), `release-pane` (now part of `resume`), and `graph-setup` (now [`setup graph`](#code-graph-discovery)). Dropping `pause` means the CLI no longer offers "stop claiming but keep ticking" — the state still exists internally (`upgrade` passes through it while draining), but as an operator verb the model is now three words instead of five.
 
 `status` prints a layered header (`dispatch` / `ticks` / next tick time / `pane` / `recovery` / `herdr` / `telegram` / `daemon`) so a paused fleet cannot hide an armed orchestrator still spending turns. The Telegram line calls the official `getMe` endpoint to prove the token and API are usable without sending a message, then separately reports whether the inbound bridge is configured.
 
@@ -580,7 +651,7 @@ message on stderr) on every uncertainty:
 - no tick config exists at all — `recover.sh` reads only
   `$FLEET_CWD/.conductor-pane-halted`, and without that file the pane's own
   directory is unknown, so the pin would land somewhere recovery never looks and
-  the agent would be respawned seconds later. `release-pane` refuses for the
+  the agent would be respawned seconds later. `resume` refuses for the
   same reason, and `status` shows `recovery unpinnable` rather than `clear`
 - the tick config does not parse — the agent name would be a guess
 - `herdr agent list` is unreachable, prints nothing, or prints output with no
@@ -600,7 +671,7 @@ The pin is written to the pane's own directory (the one holding
 `.conductor-tick.json`, which is `FLEET_CWD` — the only place `recover.sh` looks),
 including when that tick config is the thing that failed to parse.
 
-Clear the pin with `omp-conductor release-pane` when you want recovery again.
+Clear the pin with `omp-conductor resume` when you want recovery again.
 
 
 ## How one tick works
@@ -619,7 +690,7 @@ Per tick, for the daemon's project:
    [what settles a green PR](#what-settles-a-green-pr).
 2. **Paused?** If the pause sentinel exists, the tick claims nothing and returns.
    Settlement has already run, but no queue or admission work occurs. This makes
-   `omp-conductor pause` take effect without signalling the process.
+   `omp-conductor hold` take effect without signalling the process.
 3. **List the queue.** Open issues in `tracker.repo` labelled `queueLabel`.
 4. **Filter and route.** An issue is eligible only if it carries the queue label
    and none of the three state labels (`inProgress`, `blocked`, `failed`). Eligible
@@ -977,6 +1048,11 @@ inside the service's cgroup, so systemd's Memory peak for
 MCP stdio children those sessions mount. `MemoryMax=` governs that whole total,
 not one process.
 
+The generated unit starts `omp-conductor daemon --port 8787` without a
+`--project` filter, so one daemon serves every configured project. Its automatic
+`MemoryMax=` tier uses the sum of resolved `maxConcurrentWorkers` values across
+all projects: `3G` for a total of one worker, otherwise `5G`.
+
 On the reference deploy that produced [issue #51](https://github.com/TerrifiedBug/conductor/issues/51):
 
 | Shape | Observed |
@@ -995,12 +1071,13 @@ measured in the hundreds of thousands of characters of tool output.
 - Prefer **≥16 GiB RAM** for the default `maxConcurrentWorkers: 2`, and do **not**
   co-locate ClickHouse / other multi-GB services beside that fleet on an ≤8 GiB
   box.
-- On hosts under ~16 GiB, set `maxConcurrentWorkers` to **1**. `/conductor setup`
-  does this automatically when it can read host RAM.
-- Supervise the daemon with a unit that sets `SuccessExitStatus=0 143` and a
-  `MemoryMax=` just above your expected peak. A ready-to-edit example ships as
-  [`systemd/omp-conductor.service.example`](systemd/omp-conductor.service.example)
-  (`MemoryMax=5G` for the two-worker shape).
+- On hosts under ~16 GiB, keep the **sum** of every project's
+  `maxConcurrentWorkers` at **1**. `omp-conductor setup` chooses that default
+  for a new project when it can read host RAM and warns before applying a
+  configuration whose combined capacity exceeds the host recommendation.
+- Supervise the daemon with a unit that sets `SuccessExitStatus=0 143`; setup
+  renders `MemoryMax=3G` for one configured worker and `MemoryMax=5G` for two
+  or more.
 - `omp-conductor status` prints daemon `rss` from `/healthz` when the process is
   up, so you can see pressure without scraping journald.
 
@@ -1028,7 +1105,7 @@ Set `dailySpendUsd` to `null` (wizard: blank) for no money gate — turns and wa
 limit simply defers work to a later tick. The spend cap **pauses the daemon and
 pages at Tier 2**: a loop that is burning money has to halt itself, because
 waiting for someone to notice tomorrow is how a runaway becomes expensive.
-Work resumes only after `omp-conductor resume` (or `/conductor resume`).
+Work resumes only after `omp-conductor resume`.
 
 `workerMaxTurns` and `workerWallClockMs` are enforced inside the session driver.
 The daemon reads a live run's effective turn ceiling at every turn boundary. Use
@@ -1048,7 +1125,7 @@ escalation.
 Pause one live worker cooperatively with
 `omp-conductor worker pause <issue> [--project NAME]`. The daemon aborts the
 active turn to an idle harness state, freezes the remaining wall-clock budget,
-and keeps the run in the Running lane. `omp-conductor worker resume <issue>`
+and keeps the run in the Running lane. `status` overlays `paused`/`pausing` from `/healthz` on that active-run line while the SQLite row stays `running`. `omp-conductor worker resume <issue>`
 continues the same session with a prompt to re-check its last action before
 proceeding. To end that run instead, use
 `omp-conductor worker stop <issue> --reason TEXT [--project NAME]`. Stop works
@@ -1173,21 +1250,21 @@ defined" in one call instead of twenty greps.
 `omp-conductor` never installs, starts, imports, or depends on the indexer for
 dispatch. With `graphProject` unset, nothing about dispatch, caps, escalation, or
 status changes. A fresh host needs both of these before an index is worth
-anything, and `graph-setup` reports them as step 0:
+anything, and `setup graph` reports them as step 0:
 
 1. **`codebase-memory-mcp` on PATH** — a separate project,
    [DeusData/codebase-memory-mcp](https://github.com/DeusData/codebase-memory-mcp).
 2. **Mounted as an MCP server** in `~/.omp/agent/mcp.json`, on the account the
    daemon runs as. Miss this and the failure is silent: every index builds
    correctly, no worker session can read any of them, so workers fall back to
-   grepping and the feature looks like a no-op. `graph-setup` prints the entry.
+   grepping and the feature looks like a no-op. `setup graph` prints the entry.
 
 Say yes and the wizard asks for one root, then derives one clone per routed repo
 underneath it (default `~/.cache/conductor-graph/<org>/<repo>`) and writes it to
 each repo's [`graphProject`](#configuration). The only automatic interaction is
 a bounded, read-only health query; this package never clones, fetches, builds an
 index, or changes systemd. Dispatch, caps and escalation do not depend on graph
-health. On a fleet configured before this key existed, `/conductor setup` and
+health. On a fleet configured before this key existed, `omp-conductor setup` and
 the `code graph` area add it in two prompts — see
 [Changing one setting](#changing-one-setting).
 
@@ -1212,11 +1289,11 @@ edits — orient with it, then read the real file before changing it.
 ### Creating and refreshing them
 
 ```bash
-omp-conductor graph-setup            # print the plan: clones, index commands, units
-omp-conductor graph-setup --write        # stage the script and the two units (no root)
+omp-conductor setup graph --print     # print the plan: clones, index commands, units
+omp-conductor setup graph             # run it: clone, install, enable, seed, verify
 ```
 
-`graph-setup` prints a `git clone` for every clone that does not exist yet, the
+`setup graph --print` prints a `git clone` for every clone that does not exist yet, the
 one-shot index command per repo, and a `cbm-reindex.service` + `cbm-reindex.timer`
 pair built from the project's own repos and branches. `--write` stages all three
 in the state directory and prints the two `sudo` lines that install and enable
@@ -1244,7 +1321,7 @@ Two properties of the generated unit are deliberate:
 The unit spells out `HOME` and an explicit `PATH`, because systemd supplies
 neither usefully: the indexer resolves its store from `HOME`, systemd's default
 `PATH` has no `~/.local/bin`, and the indexer shells out to `git`. Both are the
-user that ran `graph-setup`; the unit sets no `User=`, so check them if that is
+user that ran `setup graph`; the unit sets no `User=`, so check them if that is
 not the account the timer runs as.
 
 ### Seeing whether the graph is usable
@@ -1520,9 +1597,17 @@ conditions, each one something this package can check without asking you:
 | `rate-limit-reset:github` | GraphQL quota on `github` has any remaining capacity again. |
 
 The daemon evaluates them beside each tick, fire-and-forget: a hanging registry
-costs one unevaluated condition, never the tick. A met row is flagged in the next
-digest as `[CONDITION MET — act on this now]`, so the session acts on the answer
-at the moment it becomes actionable rather than when it happens to remember.
+costs one unevaluated condition, never the tick. A row that transitions
+false→true also writes the same `.conductor-tick-requested` poke recover uses,
+so the orchestrator heartbeat fires promptly (mid-interval poll, still gated by
+arm/channel/pending single-flight) instead of waiting a full interval. The poke
+reason and the digest flag `[CONDITION MET — act on this now]` both surface the
+wake so the session acts when the answer becomes actionable. Repeated sweeps
+while the condition stays true do nothing further — the store marks the
+transition once. After a green-but-behind PR is updated through
+`conductor_pr_update_branch`, open a fresh `pr-checks-green` watch on the new
+head so the next green transition can wake merge review the same way; nothing
+here merges on its own.
 
 Anything else exits `2` and lists the six forms. An unparseable condition on an
 existing row is *listed and never treated as met*: a grammar a future release
@@ -1647,7 +1732,22 @@ The file is validated on every read. A malformed config produces one readable er
 listing every fault, and the daemon refuses to start rather than running with half
 a project.
 
-`/conductor setup` is the only thing here that writes this file, and on a project
+The same vocabulary the loader enforces ships as a JSON Schema at
+`schema/config.schema.json` in the installed package (draft 2020-12). Anything
+`saveConfig` writes carries a top-level `"$schema"` reference to that installed
+copy (resolved from the package's own location, so it points at a real file),
+which lets an editor that understands JSON Schema validate a hand-edited config
+as you type; a config without the key is just as valid. Regenerate the shipped
+schema from `ConfigSchema` (`src/config-schema.ts`) with:
+
+```sh
+bun run schema
+```
+
+and commit the resulting `schema/config.schema.json`. CI's `bun test` fails if the
+checked-in schema drifts from what the code renders, so you cannot forget the step.
+
+`omp-conductor setup` is the only thing here that writes this file, and on a project
 it already knows it can rewrite one area of it without re-asking the rest — see
 [Changing one setting](#changing-one-setting).
 
@@ -1713,6 +1813,7 @@ A complete, valid config for one project with two target repos:
       "workerModel": "smol",
       "escalation": {
         "telegramChatId": "123456789",
+        "telegramTopicId": 8713,
         "fallbackToIssueComment": true,
         "orchestrator": "embedded"
       },
@@ -1881,7 +1982,7 @@ policy instead of restating it — no threshold lives in two places.
 | `environments` | any names | `[]` | Deploy targets. **Empty denies** every environment. |
 
 A project with no `policy` block loads as the whole default above, which is the
-strictest reading of the prose it replaced. `/conductor setup` asks for all of
+strictest reading of the prose it replaced. `omp-conductor setup` asks for all of
 it under the **merge & release preconditions** area, so changing one condition
 costs eight prompts rather than a hand-edit — see
 [Changing one setting](#changing-one-setting).
@@ -1917,13 +2018,14 @@ it never gets prompted, so it never runs anything. Installing
 `omp plugin install omp-conductor` also installs a heartbeat that prompts it.
 
 The heartbeat is **inert unless the session cwd contains
-`.conductor-tick.json`**, so an ordinary session has no timer. `/conductor setup`
+`.conductor-tick.json`**, so an ordinary session has no timer. `omp-conductor setup`
 writes this file for external orchestration. A manual configuration has this form:
 
 ```json
 {
   "intervalSeconds": 900,
-  "armedFile": "state/armed",
+  "project": "fleet",
+  "armedFile": "/home/fleet/.omp/conductor/armed-fleet",
   "accessFile": "/home/fleet/.omp/agent/telegram/access.json",
   "message": "Run your standing loop from ORCHESTRATOR.md now."
 }
@@ -1932,11 +2034,65 @@ writes this file for external orchestration. A manual configuration has this for
 | Key | Required | Default | Notes |
 | --- | --- | --- | --- |
 | `intervalSeconds` | yes | — | Whole seconds between ticks, minimum `60`. A tick costs a full turn of a frontier model, so a sub-minute period is refused rather than obeyed. |
+| `project` | no | the only configured project | Which conductor project this fleet session ticks for. `setup host` stamps it, one tick config per fleet cwd, and it is what lets a host with several configured projects resolve *this* fleet's brief, reporting policy, digest ledger and release grants. Omitting it is the pre-multi-project spelling: correct on a single-project host, and on a host with two or more it degrades every tick to the default reporting scope with no release grants — `status` and the tick log then name the one fix (`re-run omp-conductor setup host`). A name no configured project has degrades the same way. |
 | `budgetSeconds` | no | `600` | Seconds a turn may run before the tick guard refuses its remaining tool calls (#189), and before a queued operator message preempts them. An integer ≥ 60; anything else degrades to the default. |
-| `armedFile` | no | none — the gate passes | Path to the arm marker. A tick does nothing while the file is missing. Relative paths resolve against the session cwd, so `state/armed` means `<cwd>/state/armed`. |
+| `armedFile` | no | none — the gate passes | Path to the arm marker. A tick does nothing while the file is missing. Relative paths resolve against the session cwd, so `state/armed` means `<cwd>/state/armed`. `setup host` writes `<state dir>/armed-<project>`, one marker per project, so `arm --project A` cannot arm B. A value it did not generate is left alone as your own choice. |
 | `accessFile` | no | none — the gate passes | Path to the Telegram bridge's `access.json`. Every tick re-reads it and requires `enabled: true` with exactly one entry in `allowFrom`. Relative paths resolve against the session cwd. **Configure this on any fleet deploy** — see below. |
 | `message` | no | `Tick <ISO timestamp>: re-read <workspaceRoot>/ORCHESTRATOR.md from disk, then run your standing loop from it.`, then the reporting-policy line, delivery rule, and mechanical availability state | When set, this text replaces the ordinary reporting-policy line and delivery rule, but the runtime-owned availability state is still appended: a custom prompt cannot infer whether the operator may be interrupted. Re-read from disk on **every** tick, so rewording it binds the next heartbeat instead of waiting for a session restart; a re-read that fails — caught mid-edit, removed, or invalid — keeps the value read at session start rather than stopping the heartbeat. `intervalSeconds` is *not* re-read: rescheduling a live timer still needs a restart. The default *orders* the session to re-read its brief, naming the path resolved from the project's `workspaceRoot`, because a standing prompt drifts out of a long-lived session's context while the file on disk does not. |
-| `agentName` | no | `fleet` | The herdr agent name the orchestrator's pane is registered under. Under herdr this is the whole of the identity check below, and the default matches `AGENT_NAME=${AGENT_NAME:-fleet}` in the recovery plugin's `recover.sh`, so both halves key on one name. Rename the agent and set this to match. |
+| `agentName` | no | the project name, else `fleet` | The herdr agent name the orchestrator's pane is registered under. Under herdr this is the whole of the identity check below. `setup host` writes the project name, so two fleets in one herdr session are distinguishable; when no tick config names one, the fallback matches `AGENT_NAME=${AGENT_NAME:-fleet}` in the recovery plugin's `recover.sh`, so both halves key on one name. Rename the agent and set this to match. |
+
+#### Upgrading from one shared arm marker
+
+Before per-project markers every project was given the same `<state dir>/armed`,
+so arming one fleet armed all of them. `setup host` rewrites that value — and
+only that value — to `armed-<project>`. The old bare marker is honoured for one
+more cycle on a **single-project** host, so the upgrade never silently disarms a
+live fleet, and the next `arm` or `disarm` retires it. On a host with **two or
+more** projects it arms nothing: `status` reports `legacy global arm marker —
+re-run setup host, then arm per project`, and every tick stays disarmed until each
+project is armed on its own marker.
+
+The same restamp renames the identity this pane ticks under: an `agentName` of
+`fleet` — the value every project used to be given — becomes the project name.
+**Under herdr that is an operator step, not a no-op.** Ownership is proved against
+the pane's registered herdr agent, so after re-running `setup host` the live fleet
+pane needs the new name.
+
+**Rename the agent herdr already detects — do not `agent start`.** `herdr agent
+start` submits omp *into* the pane's existing shell and requires a pane sitting at
+a shell prompt with no agent on it; the live orchestrator pane is neither, so it
+is refused at best and starts a second omp in that pane at worst. `rename` touches
+no process and keeps the session as it is:
+
+```sh
+herdr --session <session> agent list                      # find the fleet's pane_id
+herdr --session <session> agent rename <pane-id> <project>
+```
+
+If the name cannot be reassigned in place, stop and resume rather than starting a
+second orchestrator — the same shape `recover.sh` uses, so the omp session is
+preserved rather than replaced:
+
+```sh
+herdr --session <session> agent get <pane-id>   # note agent_session.value — the session ref
+# exit omp in that pane (/exit) so the pane is back at a shell prompt, then:
+herdr --session <session> agent start <project> --kind omp --pane <pane-id> -- --resume=<ref>
+```
+
+Until the pane carries the new name it declines to tick and logs which agent it
+actually is versus the one the tick config names, with the `rename` command in the
+line — the heartbeat fails closed and says so rather than letting two fleets both
+answer to `fleet`. Set `agentName` explicitly if you would rather keep the old
+name; a value that is not the shared default is never rewritten.
+
+Recovery is fail-closed across that window. A restamped `agentName` moves the
+recovery plugin's own state files to per-agent paths that do not exist yet, and
+the live pane is still saved under `fleet`, so the snapshot offers no candidate
+for the new name. `herdr-conductor` treats the pre-rename identity and bootstrap
+marker as proof a fleet has already lived on this host whatever it is called now:
+it pages `no fleet identity to recover for agent <project>` instead of
+provisioning a second workspace beside the live orchestrator. Finish the rename
+and the next pass recovers normally.
 
 A default tick sends one message (`customType` `omp-conductor.tick`, attributed
 to the user): the standing-loop prompt, the reporting-policy constraint re-read
@@ -1975,9 +2131,11 @@ registered agent name: the heartbeat asks `herdr agent list` for the entry whose
 is the *session* — every pane in it shares `HERDR_SESSION` and the cwd — and
 herdr's `agent` field is the *runtime*, `omp` for the orchestrator and for the
 shell beside it, so neither can tell them apart. The registered name can, it is
-what `herdr agent start fleet --kind omp --pane <id>` sets, and it is the same
-identity the recovery plugin keys on. A pane with a different name, or no name at
-all, stays inert.
+what `herdr agent start fleet --kind omp --pane <id>` sets when the recovery plugin
+starts a fleet into an empty pane — and what `herdr agent rename <pane-id> fleet`
+sets on a pane whose agent herdr already detects, which is the only safe spelling
+while omp is running in it. It is the same identity the recovery plugin keys on. A
+pane with a different name, or no name at all, stays inert.
 
 **Without herdr**, the session claims the directory in a sibling
 `.conductor-tick-owner.json` (pid, session file, claim time) and ticks only while
@@ -2039,8 +2197,8 @@ that happens to have a `.conductor-tick.json` has no bridge to check. It is not
 off switch for the check: **a fleet deploy always sets it.**
 
 Every tick — sent or skipped — is logged with its reason (`not armed`,
-`escalation channel down`, `tick already pending`) to the omp log. `/conductor
-pause` is deliberately **not** one of the gates: pause stops the *dispatcher*
+`escalation channel down`, `tick already pending`) to the omp log. `omp-conductor
+hold` is deliberately **not** one of the gates: hold stops the *dispatcher*
 claiming work, and the tick drives a different session — one whose duties
 (grooming the queue, draining escalations, reporting) are exactly what stays
 useful while dispatch is stopped. Its own off switch is the arm marker. Skips
@@ -2126,6 +2284,9 @@ least of all on a fleet whose session lives somewhere else.
 ## CLI reference
 
 ```bash
+omp-conductor setup [area] [--no-ai] [--project NAME]
+omp-conductor setup host [--project NAME]
+omp-conductor setup graph [--no-seed] [--print] [--project NAME]
 omp-conductor start [--port N] [--project NAME]
 omp-conductor --version
 omp-conductor stop
@@ -2135,10 +2296,9 @@ omp-conductor status [--project NAME]
 omp-conductor ledger [--issue N] [--limit N] [--project NAME]
 omp-conductor board [--project NAME]
 omp-conductor hold [--project NAME]
-omp-conductor halt [--pane] [--project NAME]
+omp-conductor stop [--pane] [--project NAME]
 omp-conductor arm [--project NAME]
 omp-conductor disarm [--project NAME]
-omp-conductor release-pane [--project NAME]
 omp-conductor tail <issue> [--project NAME]
 omp-conductor extend <issue> --turns N [--project NAME]
 omp-conductor worker pause <issue> [--project NAME]
@@ -2154,30 +2314,30 @@ omp-conductor decision resolve <id> --answer TEXT [--project NAME]
 omp-conductor decision withdraw <id> [--reason TEXT] [--project NAME]
 omp-conductor decision list [--project NAME]
 omp-conductor daemon [--once] [--port N] [--project NAME]
-omp-conductor pause [--reason TEXT]
-omp-conductor resume
-omp-conductor graph-setup [--project NAME] [--write]
+omp-conductor resume [--project NAME]
 omp-conductor brief-upgrade [--migrate|--retrofit] [--apply] [--file PATH] [--project NAME]
 omp-conductor help
 ```
 
 | Command | Behaviour |
 | --- | --- |
+| `setup [area] [--no-ai] [--project NAME]` | The deterministic interview, in a plain terminal — the same prompts, the same one-writer apply sequence, and the same single consent gate as `omp-conductor setup`, which is now one dialog implementation of the shared surface rather than the only way in. Bare is a full first run, or — when the project already exists — a chooser of which area to amend. Naming an area positionally skips that chooser and amends only that area: `tracker`, `gates`, `caps`, `code-graph`, `authority`, `policy`, `escalation`, `reporting`, `brief`. `host` and `graph` are install subcommands rather than areas and are matched first; anything else exits `2` listing both vocabularies. Every prompt shows its current value as the default, and Enter accepts what you see; `Ctrl-C` at any prompt abandons the run and writes nothing. Setup also **reads your repos to propose answers**: the gates prompt is pre-filled from what CI actually runs, and the brief's `## Project context` and release procedure are drafted from every routing repo and shown for confirmation before anything is written. Each probe is a short session with **no shell, no editor and no verbs** in a throwaway shallow clone, and every answer is a proposal you edit or decline — a probe that cannot clone, cannot reach a model, or answers unusably costs you one warning and the shipped stub. `--no-ai` asks every question with the reading half removed. |
+| `setup host [--project NAME]` | Re-render and stage the systemd unit, then **run** the install: `install -m 0644` into `/etc/systemd/system`, `daemon-reload`, `enable`, `restart`. Every command is shown with its exact argv, one confirm covers the batch, and `sudo` asks for your password once before the first step — or is skipped entirely on a fleet that genuinely runs as root. The first failure stops the rest and prints the un-run remainder verbatim so you can finish by hand. Refuses an *escalated* invocation (`sudo`, or `sudo -i`/`su -` detected by the invoking account disagreeing with the fleet's) before writing anything, naming both accounts, because staging derives the unit's `User=`/`HOME=` from whoever ran it. On a non-Linux host the files are still staged and only the `systemctl` steps are refused. |
+| `setup graph [--no-seed] [--print] [--project NAME]` | The code-graph install end to end, in one preview and one confirm: check the prerequisites read-only and stop before installing anything when `codebase-memory-mcp` is absent or no MCP entry mounts it (printing the entry to add); `git clone` each missing index-only checkout **as you, never through sudo**; install and enable `cbm-reindex.timer` as root; then seed one indexing run so the first fetch happens while you watch, and verify with the same probe `status` uses. A repo that does not verify is a failure with the remediation, not a success — staged-but-not-trusted is how you discover months later that no worker read an index. `--no-seed` enables the timer without the seeding run and says plainly the graph is unusable until it first fires; it never skips the prerequisite or clone steps. `--print` changes nothing. Exits `1` when no repo has [`graphProject`](#configuration). |
 | `start` | Start `herdr-fleet.service` when that optional unit is installed, clearing a previous pane-recovery pin, then spawn the dispatch loop in the background and wait until it answers `GET /healthz` on `:8787`. Without systemd or that unit it keeps the standalone daemon behaviour. It never clears pause or arms ticks. Refuses if a daemon is already live, naming its pid; if the process dies or never serves, it cleans up and quotes the tail of `daemon.log`. |
 | `stop` | Prefer `systemctl stop omp-conductor.service` when that unit's MainPID is the live daemon — systemd then owns the stop and will not schedule a restart for the exit it just requested. Otherwise `SIGTERM`, then `SIGKILL` after a 10-second grace period. Prints `not running` when there is nothing to stop, and tags the confirmation with `(via systemctl)` when the unit path was used. |
 | `restart [--now] [--timeout SECONDS] [--port N] [--project NAME]` | Drains the fleet by default: pause new claims, wait until live workers reach `0 / N` (bounded by `--timeout SECONDS`, default 1800 = 30 min), restart, then restore the prior dispatch state. Prefer `systemctl restart` when the unit owns the live pid so the replacement stays supervised; otherwise `stop` then `start`, inheriting the running daemon's port and project unless a flag overrides them. `--now` skips the drain and restarts immediately, orphaning any live runs (old behaviour). A drain that hits `--timeout` restarts nothing and leaves dispatch paused — `omp-conductor resume` lifts it, or re-run `restart` to keep waiting. The new process **salvages dirty live worktrees before orphaning** those rows — see [Deploying a new package onto a busy fleet](#deploying-a-new-package-onto-a-busy-fleet). |
 | `upgrade [--to VERSION] [--project NAME]` | Deterministically update the Bun-global CLI, omp plugin, Herdr recovery plugin, and managed brief as one release. Resolves the npm version and exact `gitHead`, pauses only new claims, drains active workers, installs all surfaces, reloads Herdr and the daemon, waits for pane recovery, verifies identities and fleet health twice, then restores the original dispatch state. A no-op when already current. Failure leaves dispatch paused. Must run outside a Herdr-managed session. |
-| `status [--project NAME]` | Layered fleet report first: `dispatch` / `ticks` / next scheduled tick / `pane` / `recovery` / `herdr` / `telegram` / `brief` / `decisions` / optional `failure classes` and `code graph` / `daemon`, then the project body. The project body includes the latest completed dispatch timestamp, ready/routed/admitted counts, bounded hold groups, and the GitHub API budget (`graphql` / `core` remaining and reset, in the caps block); API failures are marked `DEGRADED` so queue starvation cannot look idle. The next tick comes from the live heartbeat process, not a guess from log timestamps. Telegram health uses `getMe` to prove API authentication without sending a message and reports inbound bridge configuration separately. Configured graphs report prerequisites, indexed repos, timer state, and refresh freshness without blocking dispatch. A `reports` block lists everything the outbox has not delivered, with its age, and prints `pending` (nobody has it) differently from `SENDING` (outcome unknown, it may already have arrived) — see [Report delivery](#report-delivery-the-outbox). The daemon block includes `rss` from `/healthz`; live workers add a busy-deploy warning. A `.conductor-stalled` marker adds an `orchestrator STALLED since …` line. |
+| `status [--project NAME]` | Layered fleet report first: `dispatch` / `ticks` / next scheduled tick / `pane` / `recovery` / `herdr` / `telegram` / `brief` / `decisions` / optional `failure classes` and `code graph` / `daemon`, then the project body. The project body includes the latest completed dispatch timestamp, ready/routed/admitted counts, bounded hold groups, and the GitHub API budget (`graphql` / `core` remaining and reset, in the caps block); API failures are marked `DEGRADED` so queue starvation cannot look idle. Active-run lines overlay cooperative worker `paused`/`pausing` from `/healthz` without changing SQLite `running` state or the live worker count. The next tick comes from the live heartbeat process, not a guess from log timestamps. Telegram health uses `getMe` to prove API authentication without sending a message and reports inbound bridge configuration separately. Configured graphs report prerequisites, indexed repos, timer state, and refresh freshness without blocking dispatch. A `reports` block lists everything the outbox has not delivered, with its age, and prints `pending` (nobody has it) differently from `SENDING` (outcome unknown, it may already have arrived) — see [Report delivery](#report-delivery-the-outbox). The daemon block includes `rss` from `/healthz`; live workers add a busy-deploy warning. A `.conductor-stalled` marker adds an `orchestrator STALLED since …` line. |
 | `ledger [--issue N] [--limit N]` | The action audit: every [mediated-verb](#the-mediated-verbs-126) mutation and every next-attempt turn budget. Verb entries include the arguments, decision, named refusal, and resulting SHA. Turn-budget entries remain after an override is replaced or consumed. Reads (`conductor_pr_status`) are absent so polling cannot bury the signal. `--issue` narrows both histories; `--limit` defaults to 50. Recent verb refusals and pending turn overrides also appear in `status`. |
 | `board [--project NAME]` | Live keyboard-driven kanban over the same SQLite and `/healthz` truth as `status`, plus the tracker's current labels: Queue, Claimed, Running, Green, Blocked, Failed, Orphaned, the last 24 hours of Merged and Settled, and Parked (an issue the tracker has not confirmed closed — still open, or a label read that failed — so nothing dispatches it until a human labels it). Columns are mutually exclusive and describe current state, not the newest run row, so a requeued issue is queued rather than failed and a closed issue is neither. Refreshes run/spend/turn values every second, and health plus the label read every ten seconds. `Enter` follows the selected transcript in place; `u` invokes the existing unblock workflow on a Blocked, Failed, or Orphaned card; `i` / `p` open the issue / PR; `r` refreshes health; `?` shows all keys. Requires an interactive terminal of at least 50×20. |
-| `hold [--project NAME]` | Soft stop: pause claiming **and** disarm ticks. Daemon and pane stay up. Prefer this over `pause` when the intent is "stop the conductor" without killing processes. See [Stop the conductor](#stop-the-conductor-hold--halt). |
-| `halt [--pane] [--project NAME]` | `hold`, then stop the dispatch daemon (systemctl-aware). Pane stays up unless `--pane` is passed. `halt --pane` also pins herdr-conductor recovery off for the conductor agent only — it does **not** stop `herdr-fleet.service` or any other herdr session. Fail-closed: exits nonzero unless the agent is proven gone. |
-| `arm [--project NAME]` | Proof-gated: send a Telegram challenge and write the arm marker only after your reply appears as a user turn in the orchestrator transcript. Never auto-armed by `resume` / `hold`. |
-| `disarm [--project NAME]` | Remove the arm marker so ticks skip. Processes untouched. |
-| `release-pane [--project NAME]` | Clear the `halt --pane` recovery pin so herdr-conductor may resume the fleet agent again. |
+| `hold [--project NAME]` | Soft stop: pause claiming **and** disarm ticks. Daemon and pane stay up. Prefer this when the intent is "stop the conductor" without killing processes. See [Stop the conductor](#stop-the-conductor-hold--stop). |
+| `stop [--pane] [--project NAME]` | Stop the conductor: pause claiming, disarm ticks, then stop the dispatch daemon (systemctl-aware). Pane stays up unless `--pane` is passed. `stop --pane` also pins herdr-conductor recovery off for the conductor agent only — it does **not** stop `herdr-fleet.service` or any other herdr session. Fail-closed: exits nonzero unless the agent is proven gone. To bounce the daemon without stopping the fleet, use `restart`. |
+| `arm [--project NAME]` | Proof-gated: send a Telegram challenge and write this project's arm marker only after your reply appears as a user turn in the orchestrator transcript. The challenge names the project, so a host running two fleets is not ambiguous. Never auto-armed by `resume` / `hold`. |
+| `disarm [--project NAME]` | Remove this project's arm marker so its ticks skip; another project's ticks keep running. Also clears a pre-per-project shared `armed` marker while that marker is still what holds this fleet's gate open — otherwise the disarm would not disarm. Processes untouched. |
 | `tail <issue>` | Follow the newest run for that issue: the worker's assistant text as `assistant: …` and each tool it calls as `tool: <name>`, printed as they land. Workers are omp sessions inside the daemon rather than terminals, so this is the only way to watch one live — a herdr pane running it becomes an observation window. Starts from the top of the transcript, not the end, so attaching to a run that is already ten turns in shows those ten turns. Exits `1` with `no run recorded for #N` when the issue has never been dispatched, or `no transcript yet (state: …)` when the attempt has not opened one. Otherwise it runs until `Ctrl-C`, or until the run has finished and its transcript has been silent for five seconds, and prints `run ended: <state>`. |
 | `extend <issue> --turns N [--project NAME]` | Raise a live worker's effective turn ceiling through its owning daemon without restarting its session. If the latest run is failed, killed, orphaned, or blocked and has no live controller, store a one-shot ceiling for that issue's next claimed attempt instead. A next-attempt value must exceed the project base, every extension must stay at or below `workerMaxTurnsCeiling`, and live extensions remain monotonic. The pending value appears in `status`, is recorded in `ledger`, and is consumed atomically by one claim. |
-| `worker pause <issue>` / `worker resume <issue>` | Cooperatively park one live worker without changing its run state or lane. Pause aborts the active turn to harness idle and freezes the remaining wall-clock budget; resume continues the same session with a prompt to re-check its last action before repeating it. This is separate from fleet-level `pause`, which refuses new claims and work-starting mutations while allowing pre-pause completion work and releases. |
+| `worker pause <issue>` / `worker resume <issue>` | Cooperatively park one live worker without changing its run state or lane. Pause aborts the active turn to harness idle and freezes the remaining wall-clock budget; resume continues the same session with a prompt to re-check its last action before repeating it. This is separate from fleet-level `hold`, which refuses new claims and work-starting mutations while allowing pre-pause completion work and releases. |
 | `worker stop <issue> --reason TEXT [--project NAME]` | Terminally end a running or cooperatively paused worker. The reason is required (1–500 characters) and persisted on the run. The command waits for settlement, records the distinct `stopped` state, salvages and publishes dirty work, removes `agent:in-progress` through the durable label outbox, and consumes neither failed-attempt nor continuation budget. If salvage fails, the tree holding the only copy stays in place and the command names it. Repeating stop is idempotent and reports the run's already-terminal state. |
 | `unblock <issue> [--force] [--no-requeue]` | Remove that issue's `blocked` and `failed` labels so an answered escalation can be claimed again, and restore the project queue label by default so the dispatcher actually sees it. `agent:in-progress` comes off too, but only when the newest recorded run is terminal — that row is the proof no worker still owns the issue, so a live run keeps the label (and the queue label stays off until that run settles), and so does an issue with no run row at all. Run history remains intact: blocks consume the independent continuation budget, not failed implementation attempts. The output reports both budgets and warns when either will make the next tick escalate instead of dispatch. The label changes go through the [label projection outbox](#the-tick): they are applied inline before the command returns, but **a tracker that refuses them (403, rate limit) no longer fails the verb** — it exits `0`, the intended label state is durable and the daemon retries it, and the output says `label sync queued (N pending) — the daemon retries` instead of claiming the labels were restored. Safety is preserved, but the issue is only claimable once the queue label itself lands: the queue read asks GitHub for issues carrying that label, so a refused queue-label add keeps the issue out of dispatch until projection succeeds. `--no-requeue` clears the state labels only, leaving the queue label untouched — the case where you are about to close the issue. **Refuses, clearing nothing and exiting `3`, when the newest attempt's work could not be committed and its worktree is the only copy** — re-claiming removes that tree. `--force` records the operator's acceptance on the run row and then clears; the salvage failure stays in history. Exits `2` when the issue number is missing or malformed. |
 | `verb <conductor_*> [--arg k=v ...]` | Run one [mediated verb](#the-mediated-verbs-126) as the orchestrator, from the CLI — the external-orchestrator half of the verb surface. Every argument goes in as a `--arg k=v` string; an orchestrator can merge (`conductor_pr_merge`), label (`conductor_label`), release (`conductor_release`), update a branch (`conductor_pr_update_branch`) or title/body (`conductor_pr_update`), or read PR state (`conductor_pr_status`). The daemon applies the same checks and writes the same ledger rows a session's call would; a missing `--arg` is refused exactly as a missing tool argument is, worker-only verbs (`conductor_push`, `conductor_pr_create`) are refused with `role-not-allowed`, and a refusal exits `3`. An unknown verb exits `2`. |
@@ -2190,12 +2350,10 @@ omp-conductor help
 | `daemon` | Run the loop in the **foreground**, ticking every 5 minutes and serving `/healthz`. Admitted workers run in a tracked background pool, so settlement and capacity checks remain periodic while they work; shutdown drains the pool before closing the store. This is what `start` launches and what a systemd unit should call. |
 | `daemon --once` | Run a single tick, wait for workers admitted by that tick, and exit. No HTTP server or pidfile — a drill must not register itself as the daemon, or the next reader believes it and the real daemon's in-flight runs get reconciled as orphans. |
 | `--port N` | Accepted by `start`, `restart` and `daemon`. Both `--port 9000` and `--port=9000` work; missing or out of range exits `2` rather than falling back to the default, because probing the wrong endpoint is worse than a hard failure. |
-| `--project NAME` | Pick the project to service. One daemon process serves exactly one project; with several configured projects the name is required. |
+| `--project NAME` | Optional filter for `start`, `restart`, and `daemon`. Omit it to serve every configured project from one process (the unit path). Pass it only when you deliberately want a single-project daemon. |
 | `pause [--reason TEXT]` | Stop new claims and work-starting mutations only. The running daemon notices on its next tick; runs already in flight finish. The orchestrator may still merge, update, or label runs admitted before the pause, and may release when the release policy's own preconditions hold. The orchestrator heartbeat keeps ticking if armed — its gate is the arm marker, not this flag. Per-worker pause is separate. Prefer `hold` to silence both. `--reason TEXT` is recorded in the pause sentinel, which `status` shows as the pause provenance. |
-| `resume` | Clear pause only — does **not** re-arm. Run `arm` after an inbound Telegram proof to resume ticks. |
+| `resume [--project NAME]` | Clear pause and any `stop --pane` recovery pin — does **not** re-arm. Run `arm` after an inbound Telegram proof to resume ticks. |
 | `--version`, `-V`, `version` | Print the installed `omp-conductor` package version and exit `0`. Works from the global binary and npm/plugin install because it reads the package metadata beside the shipped CLI. |
-| `graph-setup` | Print how to set up the code-graph indexes workers query instead of grepping: a `git clone` for every index-only clone that does not exist yet, the one-shot index command per repo, and a `cbm-reindex.service` + `cbm-reindex.timer` pair generated from the project's own repos and branches. Reads only, so it is safe on a host where you are not root. Exits `1` when no repo in the project has [`graphProject`](#configuration) set, because the fix is a wizard answer rather than a flag. See [Code-graph discovery](#code-graph-discovery). |
-| `--write` | Only for `graph-setup`. Writes the refresh script into the state directory and the two units into `/etc/systemd/system`, then prints the exact `systemctl daemon-reload && systemctl enable --now cbm-reindex.timer` to run. It never runs `systemctl` itself and never enables anything: that needs root, and a package that enables system timers behind your back is one you cannot audit by reading its output. |
 | `brief-upgrade` | Inspect the package-floor + `POLICY.md` overlay. Reports by default; see [Keeping a brief current](#keeping-a-brief-current). |
 | `--migrate` | Only for `brief-upgrade`. Lift a bannered `ORCHESTRATOR.md` owned half into `POLICY.md` and recompose. Dry-run unless `--apply`. |
 | `--retrofit` | Only for `brief-upgrade`. Propose (or with `--apply`, write) a `YOURS TO EDIT` banner before the first owned-topic heading on a hand-written brief. |
@@ -2203,18 +2361,18 @@ omp-conductor help
 | `--file PATH` | Only for `brief-upgrade`. Check a brief that is not where the wizard would have put it, on a host that may have no config at all. |
 | `help`, `--help`, `-h` | Print usage. An unknown or missing verb prints it too, and exits `2`. |
 
-Pause is a flag file under the state directory, so it applies to every project and
-survives a daemon restart. It refuses new claims and work-starting mutations,
-allows completion verbs only for runs admitted before the pause, and leaves
-`conductor_release` to its normal authority, grant, and precondition checks.
-Per-worker pause is independent. Hold also removes the arm marker the heartbeat
-reads, so both brains go quiet without killing processes.
+Pause is a sentinel under the state directory and survives a daemon restart.
+`hold --project NAME` writes `paused-<name>` for that project only; a bare
+`paused` file (legacy / all-projects) pauses every project. It refuses new claims
+and work-starting mutations, allows completion verbs only for runs admitted
+before the pause, and leaves `conductor_release` to its normal authority, grant,
+and precondition checks. Per-worker pause is independent. Hold also removes the
+arm marker the heartbeat reads, so both brains go quiet without killing processes.
 
-These are available in-session as `/conductor setup`, `/conductor status`,
-`/conductor hold`, `/conductor halt [--pane]`, `/conductor arm`, `/conductor disarm`,
-`/conductor release-pane`, `/conductor pause` and `/conductor resume`, each taking
-an optional project name. Background-process management (`start` / `stop` /
-`restart`) is CLI-only: the plugin does not start, stop or restart the daemon.
+Every one of these is a verb on the `omp-conductor` binary, each taking an optional
+`--project NAME`. There is no in-session command: an omp session that wants any of
+them shells out to the binary, which is what keeps one implementation and one ledger
+entry per action.
 
 ### Health endpoint
 
@@ -2225,50 +2383,58 @@ curl -s localhost:8787/healthz
 ```json
 {
   "ok": true,
-  "paused": false,
-  "activeRuns": 1,
-  "project": "demo",
   "rssBytes": 123456789,
-  "dispatch": {
-    "completedAt": 1786185678000,
-    "ready": 8,
-    "routed": 8,
-    "admitted": 0,
-    "degraded": true,
-    "holds": [
-      { "reason": "parent-lookup-error", "count": 8, "issues": [321, 320, 318] }
-    ]
-  },
-  "codeGraph": {
-    "configured": true,
-    "status": "degraded",
-    "checkedAt": "2026-08-08T13:00:00.000Z",
-    "prerequisites": { "indexer": "present", "mcpMount": "missing" },
-    "repos": [
-      {
-        "name": "api",
-        "path": "/home/fleet/.cache/conductor-graph/acme/api",
-        "clone": "present",
-        "index": "present"
+  "projects": [
+    {
+      "ok": true,
+      "paused": false,
+      "activeRuns": 1,
+      "project": "demo",
+      "dispatch": {
+        "completedAt": 1786185678000,
+        "ready": 8,
+        "routed": 8,
+        "admitted": 0,
+        "degraded": true,
+        "holds": [
+          { "reason": "parent-lookup-error", "count": 8, "issues": [321, 320, 318] }
+        ]
+      },
+      "codeGraph": {
+        "configured": true,
+        "status": "degraded",
+        "checkedAt": "2026-08-08T13:00:00.000Z",
+        "prerequisites": { "indexer": "present", "mcpMount": "missing" },
+        "repos": [
+          {
+            "name": "api",
+            "path": "/home/fleet/.cache/conductor-graph/acme/api",
+            "clone": "present",
+            "index": "present"
+          }
+        ],
+        "timer": { "enabled": "enabled", "active": "active" },
+        "refresh": {
+          "result": "success",
+          "fresh": true,
+          "lastSuccessAt": "2026-08-08T12:50:00.000Z",
+          "ageMs": 600000
+        },
+        "reasons": ["worker MCP configuration does not mount the indexer"]
       }
-    ],
-    "timer": { "enabled": "enabled", "active": "active" },
-    "refresh": {
-      "result": "success",
-      "fresh": true,
-      "lastSuccessAt": "2026-08-08T12:50:00.000Z",
-      "ageMs": 600000
-    },
-    "reasons": ["worker MCP configuration does not mount the indexer"]
-  }
+    }
+  ]
 }
 ```
 
-Any other path or method returns `404`. `ok` reports process liveness only.
-Nonfatal admission errors and graph degradation keep it `true` so a supervisor
-does not restart-loop. Inspect `dispatch.degraded` and its bounded reason groups
-for queue starvation; inspect `codeGraph` for configured graph health.
-`activeRuns` counts occupied issues — live workers plus green PRs awaiting merge.
+Any other path or method returns `404`. Top-level `ok` is process liveness across
+every served project; top-level `rssBytes` is the daemon's resident set.
+Per-project blocks keep `paused`, `activeRuns`, `dispatch`, `codeGraph`, and
+`workers`. Nonfatal admission errors and graph degradation keep `ok` `true` so a
+supervisor does not restart-loop. Inspect `dispatch.degraded` and its bounded
+reason groups for queue starvation; inspect `codeGraph` for configured graph
+health. `activeRuns` counts occupied issues — live workers plus green PRs
+awaiting merge.
 
 ## What a worker may and may not do
 
@@ -2390,8 +2556,8 @@ daemon, across a process boundary, not in a prompt the model can rewrite.
 | --- | --- | --- |
 | `conductor_push` | the worker owning the run | The ref is exactly `refs/heads/<that run's branch>`. Fast-forward only; there is no force argument to reject because none is declared. |
 | `conductor_pr_create` | the worker owning the run | The run has no open PR (the same guard admission uses); head is the run branch; base is the repo's configured `defaultBranch`. |
-| `conductor_pr_status` | worker or orchestrator | Read-only. A worker reads only its own run's PR. |
-| `conductor_pr_update_branch` | orchestrator, or the worker owning the run | The PR belongs to this run and project, and is open. |
+| `conductor_pr_status` | worker or orchestrator | Read-only. A worker reads only its own run's PR; an orchestrator may name any open PR in a routed project repo. |
+| `conductor_pr_update_branch` | orchestrator, or the worker owning the run | The PR belongs to this project and is open. A worker may only name its own run's PR. |
 | `conductor_pr_merge` | **orchestrator only** | `authority.merge` equals the caller; `headSha` equals the live head *at execution time*; checks green at that same SHA; the project's single merge slot is free. |
 | `conductor_label` | **orchestrator only** | The label is in the project's own vocabulary. Lifecycle labels stay the daemon's. |
 | `conductor_release` | **orchestrator only** | `authority.release` equals the caller; the per-shape grant permits it; the artefact or environment was declared; the release preconditions hold; the `reason` is in the closed enum. |
@@ -2540,8 +2706,9 @@ Known and deliberate in this version:
   was spent.
 - **GitHub is the only tracker.** The internal `Tracker` port is deliberately
   provider-neutral, but `tracker.kind` accepts only `"github"` today.
-- **One project per daemon process.** Several projects means several processes,
-  each with `--project` and its own `--port`.
+- **One daemon serves every configured project by default.** `setup host` writes a
+  unit without `--project`. Pass `--project NAME` only to filter a foreground or
+  temporary daemon down to one project.
 - **Labels are matched exactly and case-sensitively.** `Ready-For-Agent` is not
   `ready-for-agent`, and the mismatch is silent: the issue is simply never picked
   up.