omp-conductor 0.13.0 → 0.15.0

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:
@@ -75,34 +79,31 @@ Reporting is the one half of that the config also knows about, because the wizar
 has to ask something in order to seed the brief, and it is the one half the
 runtime acts on:
 
-| `reporting.scope` | What the orchestrator says unprompted | The line every tick carries |
+| Setup choice | What may interrupt | What waits |
 | --- | --- | --- |
-| `material` (default) | Escalations, plus every material event: a run reaching a green PR, a run that failed twice, an issue pulled off the queue, a cap that stopped the fleet. | `Report material events per your brief.` |
-| `escalations` | Escalations when they happen, plus one daily digest. Silent otherwise. | `Report NOTHING this turn except a Tier 1 or Tier 2 escalation; everything else -- releases included -- waits for the daily digest.` |
-| `decisions` | Tier-2 decisions and fleet-stopping conditions immediately; every other material event is held and ships with the next tick report, as one message. | `Reporting scope decisions: interrupt only for a decision you need (tier-2) or a condition that stops the fleet. Every other material event accumulates and ships as ONE message with this tick's report via omp-conductor report -- a merge, a green PR, a pulled issue wait for the tick; nothing between ticks.` |
+| `material` | Every configured material event, when operator availability permits. | Non-bypass events outside configured hours wait for the next configured digest or opening. |
+| `escalations` | Tier-2 escalations, when operator availability permits. | Everything else waits for the configured digest. |
+| `decisions` (recommended) | Tier-2 decisions and fleet-stopping conditions, when operator availability permits. | Every other material event is recorded durably and ships with the configured digest as one message. |
+| `quiet` | Tier-2 escalations, fleet stops, and confirmed failures, when operator availability permits. | Everything else waits for one daily rollup. |
 
 **What the scope does:** the [orchestrator heartbeat](#orchestrator-tick) appends
-that line to every tick it sends, so the reporting contract arrives with the
-prompt instead of only in a brief the session read hours ago. It is re-read from
-`~/.omp/conductor/config.json` on **every** tick, so turning the volume up or
-down — `/conductor setup` again, or an edit to the file — binds the next tick
-without restarting the session. Three cases fall back to `material`: no config
-yet, an unreadable or invalid one, and several projects with none named (the same
-ambiguity `status` refuses to guess through). Stopping the heartbeat over a
-reporting preference would be the worse trade, so it ticks on the default and
-logs the reason once.
-
-**What it does not do:** there is no hard outbound filter. Nothing inspects the
-orchestrator's messages and drops the ones your scope did not ask for, so a
-session that ignores its constraint line still reaches you. Scope is a
-constraint the model is handed each turn. It is not a gate the model is held to.
-The enforcement roadmap (a tool-call tripwire, and config-versus-behaviour drift
-in the daily digest) is
-[issue #11](https://github.com/TerrifiedBug/conductor/issues/11).
-
-Changing the key later does not rewrite an `ORCHESTRATOR.md` you already have:
-the tick line changes, the brief does not. Edit its Reporting section too, or the
-session is carrying two versions of your policy.
+the current constraint to every tick it sends, so the reporting contract arrives
+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 — `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
+back to the legacy `material` scope for the heartbeat and log the reason once.
+An invalid live availability policy blocks autonomous Telegram fail-closed; it
+does not guess that the operator is awake.
+
+Changing the key later does not rewrite an `ORCHESTRATOR.md` you already have.
+The generated `POLICY.md` describes every scope without pinning the current
+choice; the tick constraint remains derived from live config. Keep any
+operator-owned reporting additions in `ORCHESTRATOR.md` consistent with it.
 
 ## Where issues come from
 
@@ -117,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 |
@@ -135,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.
@@ -264,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
 
@@ -332,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
@@ -365,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:
@@ -382,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
@@ -439,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.
@@ -509,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 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`.
+`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`.
+
+**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.
 
@@ -583,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
@@ -603,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
@@ -622,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
@@ -808,6 +876,10 @@ every check succeeded or was skipped. Missing or nonterminal checks become
 `pushed-pending` and are rechecked on later ticks; red or cancelled checks become
 `failed` with a bounded job/log digest. Only verified evidence becomes
 `pushed-green`.
+If a failed report mentions PRs only in prose, the daemon retains the last URL
+whose `owner/repo` matches the run's repository; links to other repositories are
+ignored. This preserves the continuation target without trusting an unrelated
+PR mentioned in the same report.
 
 What happens after verification is a human's decision, taken minutes to days
 later and never announced to the daemon — so every tick asks the tracker about
@@ -816,14 +888,15 @@ every pushed PR it is still holding:
 | PR | Row becomes | Why |
 | --- | --- | --- |
 | merged | `merged` | The work landed. This is the state `merged` was reserved for. |
-| closed without merging | `failed`, with the PR in `lastError` | A human read the work and said no. Leaving it `pushed-green` strands the issue forever behind a PR nobody will merge, and calling it `merged` is a lie about code that is not on the base branch. `failed` is true, and it releases the issue so a re-queue can be attempted again. |
+| closed without merging | `failed`, class `returned-for-revision`, with the PR in `lastError` | A human read the work and asked for another pass. Leaving it `pushed-green` strands the issue forever behind a PR nobody will merge, and calling it `merged` is a lie about code that is not on the base branch. `failed` is the honest row state; the class preserves the review decision and releases the issue so a re-queue can be attempted again. |
 | still open | unchanged | The normal steady state. Its issue must stay occupied, or a second attempt lands on the live PR. |
 | could not be determined | unchanged | A flaky network, a revoked token, a deleted PR. An unknown answer never settles a row; the next tick asks again for free. |
 
-Run history is untouched. A PR closed without merging becomes a concrete failed
-attempt; a merge does not spend failure or continuation budget. A settled row also
-loses `agent:in-progress` from its issue: the row transition and the label are one
-fact, and a terminal answer about the PR proves no worker process owns the issue,
+Run history is untouched. A PR closed without merging consumes one continuation,
+not a failed implementation attempt; a merge spends neither budget. A settled
+row also loses `agent:in-progress` from its issue: the row transition and label
+removal are one fact, and a terminal answer about the PR proves no worker
+process owns the issue,
 so the duplicate-dispatch guard it exists for is spent. The removal is *enqueued
 on the label projection outbox in the same breath as the terminal write* — a
 durable local write that cannot fail on the tracker — so the row settles at once
@@ -848,6 +921,30 @@ issues carrying `agent:in-progress`, which eligibility reads as "a worker owns
 this" — with the brief forbidding the orchestrator from editing a state label and
 `unblock` declining to clear that one, neither issue could ever be claimed again.
 
+### Base-branch health after merge
+
+The daemon records two different facts after a merge:
+
+- The **post-merge audit** attributes a regression to one merge. For up to 24
+  hours, it checks only push-triggered workflow runs for the exact merge SHA and
+  base branch. A new red result adds `base-branch-red` evidence and escalates.
+- **Current health** drives `status` and release policy. On every sweep, the
+  daemon resolves the live head of each branch it merged into during the last
+  seven days, then reads only push-triggered runs for that head and branch. The
+  status row includes the head SHA and run count.
+
+Current health is `green` only when every observed run completed successfully,
+neutrally, or skipped. A failing conclusion is `red`; an in-progress or
+unrecognised conclusion is `pending`; and a head with no push-triggered run is
+`unknown`, never green. Pending and unknown heads are rechecked. Green and red
+heads are read again when the branch moves, so an old verdict cannot describe a
+new commit. If GitHub cannot return the head or its runs, the daemon keeps the
+last honest row instead of replacing evidence with a network failure.
+
+The `base-branch-green` release requirement reads this current live-head row for
+the repository being released. Red, pending, unknown, and absent evidence all
+refuse the release.
+
 ### The settlement audit
 
 Verifying `state: pushed-green` left two lines of the same report still taken on
@@ -868,6 +965,7 @@ change a run's state, hold a merge, or spend an attempt.
 | `undisclosed-file` | The PR touched a file the `changed:` line never named. Lockfiles are exempt — they are derived from a manifest the report did disclose. |
 | `changed-line-missing` | The report had no usable `changed:` line at all. One flag, not one per file. |
 | `unmatched-claim` | `changed:` named a path the PR never touched. The weaker direction, and reported as such. |
+| `report-format-unparsed` | The same file appeared as both claimed-but-untouched and touched-but-unclaimed, so the `changed:` line's format defeated the parser. Read the diff directly; this is not a trust signal against the worker. |
 | `test-file-deleted` | A test file left the tree with no rename to account for it. |
 | `test-disabled` | A `.skip` / `.only` / `xit` / `@pytest.mark.skip` / `t.Skip` marker appears on a line the PR added. |
 | `assertions-removed` | An assertion was commented out, or a test file lost more assertions than it gained. |
@@ -950,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 |
@@ -968,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.
 
@@ -1001,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
@@ -1021,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
@@ -1146,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).
 
@@ -1185,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
@@ -1217,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
@@ -1298,20 +1402,72 @@ a report reached you only if the model remembered to call `telegram_send`. On
 none of the three arrived, and nothing anywhere recorded that fact — an undelivered
 report and a quiet tick look identical.
 
+### Material events survive the session
+
+A deferred digest does not use the session transcript as its source of truth.
+Record each ordinary outcome when it happens:
+
+```bash
+omp-conductor event record \
+  --category merge \
+  --summary "#42 merged" \
+  --evidence "https://github.com/acme/api/pull/42"
+```
+
+`--category` is a short lowercase slug. `--summary` states the outcome, and
+`--evidence` names the issue, PR, release, run, commit, or URL that proves it.
+Use `--occurred-at <ISO timestamp>` when the event happened earlier; otherwise,
+the command uses the current time. The command writes one row to SQLite and
+sends nothing. The row survives later ticks, session compaction, session
+replacement, and daemon restarts.
+
+When a digest is due, its tick prompt lists a bounded, oldest-first set of
+owed material events and deferred escalations. Each line includes its ledger id.
+The prompt gives the exact handoff shape:
+
+```bash
+omp-conductor report \
+  --kind digest \
+  --events EVENT_ID_1,EVENT_ID_2 \
+  --notices NOTICE_ID_1,NOTICE_ID_2 \
+  --text "<the whole digest>"
+```
+
+Remove the id of any row you did not use. Omitted rows stay owed. The report row
+and the named ledger rows are associated in one SQLite transaction. If the
+handoff fails, no row is consumed. If a daily report deduplicates against a
+daily report already queued that day, newly named rows also stay owed. If
+delivery exhausts its retry budget and the report becomes `failed`, its rows
+return to the owed backlog, where a replacement digest can claim them.
+`omp-conductor status` always shows the
+material-event and held-escalation backlog counts, including the age of the
+oldest row when one exists.
+
+This accumulator does not poll GitHub and does not infer outcomes from tracker
+state. The orchestrator still decides what is material and records the evidence.
+The mechanism only makes that decision durable until a non-failed digest owns it.
+
 Authorship still needs judgement the daemon does not have, so it stays with the
 model. Delivery does not, so it moved:
 
 ```bash
-omp-conductor report --text "<the whole report>"                 # one material event
-omp-conductor report --text "<the whole digest>" --kind digest   # the daily digest
+omp-conductor report --text "<the whole report>"  # immediate report, when policy permits
+omp-conductor report \
+  --text "<the whole digest>" --kind digest \
+  --events EVENT_IDS --notices NOTICE_IDS          # use row ids from its tick
 ```
 
-The command writes the text into a `reports` table in the store and prints a
-report id. Nothing has been sent at that point, and that is the guarantee: the
-report survives the session being compacted, interrupted or restarted, and it
-survives the daemon being restarted under it. The daemon then delivers it over
-the same bot token tier 2 uses, with bounded retries, and `omp-conductor status`
-lists anything that has not landed.
+The command persists the text before anything is sent and prints a durable
+handoff id. An immediate report admitted during quiet hours is stored as a held
+notice and prints that id; the daemon includes it in the next digest or in a
+catch-up report when the configured window opens. Otherwise it writes a
+`reports` row and prints its report id. Both survive the session being
+compacted, interrupted or restarted,
+and the daemon being restarted under it. The daemon delivers over the same bot
+token tier 2 uses, with bounded retries, and `omp-conductor status` lists
+anything it still owes. If availability closes after a material report was
+queued but before its first attempt, the outbox atomically converts that row to
+the same held-notice path instead of leaking the update through quiet hours.
 
 ### Delivery is at-least-once, and the docs will not pretend otherwise
 
@@ -1374,14 +1530,16 @@ then the only surface — a report has no tracker issue, so there is no issue
 comment to fall back to. The page goes through the ordinary escalation ledger and
 carries the report id, so one undeliverable report pages exactly once.
 
-### The daily digest is deduplicated from the ledger
+### Daily digests are deduplicated from the ledger
 
-`--kind digest` is accepted at most once per **local** day, per project. The
-second hand-over on the same day is refused and told which report already holds
-the slot, including when that report has already been delivered. This is decided
-from the `reports` table, not from the model's memory of the last tick — a
-restarted or compacted session cannot send a second digest by forgetting the
-first. Material reports carry no such key: two events in a day are two events.
+With `digest.cadence: "daily"`, `--kind digest` is accepted at most once per
+**local** day, per project. The second hand-over on the same day is refused and
+told which report already holds the slot, including when that report has already
+been delivered. This is decided from the `reports` table, not from the model's
+memory of the last tick — a restarted or compacted session cannot send a second
+daily digest by forgetting the first. A `per-tick` digest carries no daily key,
+so later ticks can hand off newly accumulated rows. Material reports carry no
+dedupe key either: two events in a day are two events.
 
 ### What `status` shows
 
@@ -1439,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
@@ -1477,6 +1643,7 @@ persists the class on the row, and performs the one recovery that class names.
 | --- | --- | --- | --- |
 | `env-start-failure` | turn 0 plus an explicit harness start error (`No model selected`, a rejected key) | escalate — the session never read the issue | none |
 | `settlement-stuck` | a row carrying a PR that has since merged | settle: release the label, mark the row merged | none |
+| `returned-for-revision` | a `pushed-green` or `pushed-pending` PR was closed without merging | none — preserve the review decision for a human re-queue | continuation |
 | `merge-conflict` | `pushed-green`, PR open, GitHub reports conflicting | requeue for a rebase continuation | continuation |
 | `question` | the worker stopped to ask something (`blocked`) | escalate, carrying the worker's own report as evidence | none |
 | `orphan-dirty` | orphaned with a failed salvage and no operator ack | hold — recorded only; the tree is the only copy | none |
@@ -1486,7 +1653,9 @@ persists the class on the row, and performs the one recovery that class names.
 | `admin-kill` | killed *below* its own ceiling — a restart or a drain | requeue | none |
 | `ci-infra` | PR open, every unresolved check cancelled / timed out / stale | re-run the failed jobs | none |
 | `ci-deterministic` | PR open, a check genuinely reports `FAILURE` | escalate with the failing check names and links | failed attempt |
+| `dispatch-infra` | the conductor's own Git path failed before the worker's first turn | requeue, bounded by per-class strikes | none |
 | `provider-credit` | the provider refused the run for credit (HTTP 402, or its own out-of-credit text read off the transcript) | pause the fleet and require `omp-conductor resume` once the provider has credit | none |
+| `provider-transient` | the provider aborted a request stream before the run produced a verdict | requeue, bounded by per-class strikes | none |
 | `unknown` | anything unrecognised | escalate | as recorded |
 
 **Unknown escalates; it never silently retries.** A shape this table does not
@@ -1496,13 +1665,14 @@ cause nobody has named — the behaviour this exists to end.
 ### The budgets follow the cause
 
 `failuresFor` (implementation attempts) excludes `ci-infra`, `settlement-stuck`,
-`env-start-failure` and `provider-credit`; `continuationsFor` excludes
-`admin-kill`, `settlement-stuck`, `env-start-failure` and `provider-credit`. An
-environment fault charges neither: the session never started, so nothing about
-the issue was attempted, and nor does a provider-credit refusal, which is a
-billing state rather than an implementation failure. A merge conflict *is*
-charged as a continuation, because a rebase is real work — just never as a
-failed implementation attempt.
+`env-start-failure`, `dispatch-infra`, `provider-credit`, `provider-transient`
+and `returned-for-revision`. `continuationsFor` excludes `admin-kill`,
+`settlement-stuck`, `env-start-failure`, `dispatch-infra`, `provider-credit`
+and `provider-transient`, but explicitly counts a failed
+`returned-for-revision` row. Environment, dispatch and provider faults charge
+neither budget because the issue did not receive a valid implementation
+attempt. A merge conflict and a returned review both charge a continuation:
+each asks for more work, but neither is a failed implementation attempt.
 
 An **unclassified** row (every row written before 0.4.3) counts exactly as it
 did before classification existed. Upgrading therefore changes no existing
@@ -1562,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).
 
@@ -1628,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"
       },
@@ -1686,7 +1872,7 @@ Field notes:
 | `escalation.orchestrator` | Optional; `"embedded"` (default) or `"external"`. `external` means an orchestrator session already runs elsewhere: the daemon starts none, and tier-1 escalations post as issue comments for that session to drain. Any other value is an error. |
 | `authority` | Optional; `{ "merge": …, "release": … }`, each `"human"` (default) or `"orchestrator"`. It grants nothing to the daemon — it words the orchestrator's standing orders and the Releases paragraph of the rendered brief, so the config and the prompt cannot disagree about who holds the merge button. Unknown keys and any other value are errors, never folded to the default. |
 | `releasePolicy` | Optional; `"none"` (default) or `"operator-brief"`. `none` installs a pre-tool-call tripwire in worker, embedded-orchestrator and external-orchestrator sessions. It blocks `git tag`, tag pushes, package publishing, GitHub release creation and recognised deploy commands before execution. `operator-brief` opens that gate only for the procedure in the operator-owned brief. Unknown values are errors. Every rejection is written to `release-policy-blocks.jsonl`; the heartbeat carries that day's count into the daily digest so configured intent and observed behaviour cannot drift silently. This is the mechanical gate; `authority.release` still says who owns the decision. |
-| `reporting` | Optional; a **legacy scope preset** (`reporting.scope` — `"material"` default, `"decisions"`, `"escalations"`) or the **explicit form** `{ "interruptOn": [...], "digest": { ... } }`. The preset writes which categories may page the operator (`interruptOn`) and when the rollup happens (`digest.cadence`); the explicit form sets both directly and the two forms are mutually exclusive in one config. See [Reporting policy](#reporting-policy-reporting). |
+| `reporting` | Optional; a **legacy scope preset** (`reporting.scope` — `"material"` default, `"decisions"`, `"escalations"`) or the **explicit form** `{ "interruptOn": [...], "digest": { ... }, "availability": { ... } }`. The preset writes which categories may page the operator (`interruptOn`) and when the rollup happens (`digest.cadence`); the explicit form sets both directly and may add a weekly operator-availability window. The two forms are mutually exclusive in one config. See [Reporting policy](#reporting-policy-reporting). |
 | `orchestratorReadPaths` | **Retired in 0.4.3.** Still accepted in a config and ignored, so a fleet carrying it upgrades without an edit. It widened the orchestrator's file-tool allowlist; there is no allowlist any more — the orchestrator is [unconfined by design](#the-orchestrator-is-unconfined-deliberately). |
 | `policy` | Optional; the gating conditions a merge or a release must satisfy, in two sections — `policy.merge` and `policy.release`. Any member may be omitted and the loader fills it from the strict default; an unknown key in either section, or a value outside its vocabulary, is an error naming the field, never a silent downgrade. See [Merge and release preconditions](#merge-and-release-preconditions-policy). |
 | `workspaceRoot` / `mirrorRoot` | Optional; default to `worktrees/` and `mirrors/` under the state directory. `~` is expanded. |
@@ -1708,13 +1894,66 @@ spellings, mutually exclusive in one config (the loader rejects a `scope` next t
 - **Explicit** — `reporting: { "interruptOn": ["tier2", "fleet-stopped", ...], "digest": { "cadence": "none" | "per-tick" | "daily" } }`.
   `interruptOn` must be a non-empty array of known categories (`tier2`, `decision-needed`, `fleet-stopped`, `confirmed-failure`, `material`), each an escalation's tier-2 category. `daily` may add `at` (`HH:MM`, 24h) and `timezone` (a known IANA zone, defaulting to the host zone) — both only valid with `daily`.
 
+The explicit form may add a weekly local-time window:
+
+```json
+{
+  "reporting": {
+    "interruptOn": ["tier2", "fleet-stopped"],
+    "digest": { "cadence": "daily", "at": "17:00", "timezone": "Europe/London" },
+    "availability": {
+      "timezone": "Europe/London",
+      "days": ["mon", "tue", "wed", "thu", "fri"],
+      "start": "09:00",
+      "end": "17:00",
+      "bypass": ["fleet-stopped"]
+    }
+  }
+}
+```
+
+`timezone` must be a known IANA zone. For a daily digest, its timezone defaults
+to this value and must match it when both are set.
+
+`days` is a non-empty set of `mon` through `sun`; `start` is inclusive and
+`end` is exclusive. A start later than the end defines an overnight window on
+the day it opens. `bypass` is an explicit list of known interrupt categories
+that may still page outside the window; it may be empty. For ordinary notices,
+a bypass has no effect on a category omitted from `interruptOn`. Urgent recovery
+notices may bypass category batching when the digest loop itself is unavailable,
+but they still require the configured availability bypass outside the window.
+
+The setup wizard offers this as **Weekly availability window** and asks for the
+zone, days, start/end, bypass categories, and digest schedule: every tick,
+model-timed daily, disabled, or a fixed daily `HH:MM`. Re-running setup or
+amending reporting preselects and preserves the configured `none`, `per-tick`,
+or `daily` cadence. Choosing **Continuous (24-hour interrupts)** is the explicit
+opt-out and preserves the behavior of every existing config; an absent
+`availability` key also means continuous operation.
+
+Outside the window, an otherwise interruptible escalation is stored durably
+instead of sent. A daily digest may consume it first. Otherwise the daemon
+atomically queues one working-hours catch-up report when the window opens,
+including after downtime; associating the held rows before delivery prevents a
+later tick from authoring a duplicate. Each heartbeat prompt names the
+mechanically computed current mode and next transition. `status` shows the same
+state plus the next digest opportunity (`due now`, every tick, disabled, or its
+next operator-local timestamp). Config, escalation routing, and report transport
+are re-read at tick or send time, so changing the window or Telegram target
+does not require a daemon restart.
+
+Attachment-bearing autonomous Telegram sends cannot be replayed by the text
+digest, so they are blocked with an explicit “nothing sent or held” error rather
+than silently dropping their files.
+
 A tier-2 escalation whose category is **not** in `interruptOn` is not dropped: it
 is held (`held_notices`) and the next accepted digest is its delivery authority.
-The digest itself is at-most-once per local day (`digest:<YYYY-MM-DD>` in the
-configured zone), which remains the delivery authority across restarts. A
-scheduled `daily` digest is only sent on a day it has not already run, once the
-local clock has passed `at`; a restart after `at` still sends today's (one
-catch-up), and a fully missed day is skipped, never sent late.
+A `daily` digest is at-most-once per local day (`digest:<YYYY-MM-DD>` in the
+configured zone), which remains the delivery authority across restarts.
+`per-tick` digests are not daily-deduplicated, so a later tick can claim newly
+accumulated rows. A scheduled `daily` digest is only sent on a day it has not
+already run, once the local clock has passed `at`; a restart after `at` still
+sends today's (one catch-up), and a fully missed day is skipped, never sent late.
 
 ### Merge and release preconditions (`policy`)
 
@@ -1737,13 +1976,13 @@ policy instead of restating it — no threshold lives in two places.
 
 | Field | Values | Default | Means |
 | --- | --- | --- | --- |
-| `requires` | `runs-settled`, `no-open-prs`, `queue-drained`, `base-branch-green`, `epic-children-closed` | `["runs-settled"]` | What must already have landed. `base-branch-green` requires the newest observed post-merge workflow verdict for that routed repository to be green; pending, unknown, red, or no observation refuses release. Order and duplicates do not matter; the loader canonicalises. |
+| `requires` | `runs-settled`, `no-open-prs`, `queue-drained`, `base-branch-green`, `epic-children-closed` | `["runs-settled"]` | What must already have landed. `base-branch-green` requires the current live head's push-triggered workflow verdict for that routed repository to be green; pending, unknown, red, or no observation refuses release. Order and duplicates do not matter; the loader canonicalises. |
 | `requiredChecks` | any check names | `[]` | Checks that must be green on the branch being released. Empty means every check it reports. |
 | `artefacts` | any names | `[]` | The packages or images this project releases. **Empty denies**: nothing has been authorised to ship. |
 | `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).
@@ -1779,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."
 }
@@ -1794,16 +2034,71 @@ 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.scope` line, then the delivery rule | Sent verbatim when set — and then it owns the whole contract: neither the scope line nor the delivery rule is appended to a prompt you wrote yourself. 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. |
+| `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 | 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>
+```
 
-A tick sends one message (`customType` `omp-conductor.tick`, attributed to the
-user): the standing-loop prompt, the one constraint line the project's
-[`reporting.scope`](#your-workflow-vs-the-package) resolves to, re-read from the
-conductor config on every tick, and a delivery rule. That last line is there
+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
+from conductor config on every tick, the delivery rule, and the mechanically
+computed operator-availability state. A configured `message` replaces the first
+three parts but not that clock state. The delivery rule is there
 because end-of-turn text reaches the operator's Telegram only on a turn that
 *began* as an inbound Telegram message: a tick is injected locally, so anything
 the session merely writes at the end of one is read by nobody, and a reportable
@@ -1836,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
@@ -1900,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
@@ -1987,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
@@ -1996,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]
@@ -2008,41 +2307,42 @@ omp-conductor worker stop <issue> --reason TEXT [--project NAME]
 omp-conductor unblock <issue> [--force] [--no-requeue] [--project NAME]
 omp-conductor verb <conductor_*> [--project NAME] [--arg k=v ...]
 omp-conductor friction <escalation-digest|report-noise|report-surprise> --detail TEXT [--issue N] [--project NAME]
-omp-conductor report --text TEXT [--kind material|digest] [--project NAME]
+omp-conductor event record --category NAME --summary TEXT --evidence REF [--occurred-at ISO] [--project NAME]
+omp-conductor report --text TEXT [--kind material|digest] [--events IDS] [--notices IDS] [--project NAME]
 omp-conductor decision open --question TEXT [--blocks TEXT] [--resolves-when COND] [--project NAME]
 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`. |
 | `friction <kind> --detail TEXT [--issue N]` | Record one bounded judgment the daemon cannot infer: an escalation belonged in a digest, or a tick report was noise/surprising. The detail is limited to 160 characters. One event never changes policy; three observations inside seven days make the aggregate eligible for one Learning-loop prompt, followed by a seven-day cooldown. |
-| `report --text TEXT [--kind material|digest]` | Hand a rendered report to the daemon's durable outbox. The text is persisted **before** anything is sent and the command prints a report id; the daemon then owns delivery, retries on a bounded backoff, and records the Telegram message id it actually got back. Delivery is [at-least-once](#report-delivery-the-outbox) — a crash mid-send is retried and the retry says it may be a repeat — so `delivered` is never proof of exactly one message. `--kind digest` is accepted at most once per local day, decided from the ledger rather than from what the session remembers sending; an unknown `--kind` exits `2` rather than quietly becoming a material report. Anything undelivered shows in `status` with its age. |
+| `report --text TEXT [--kind material|digest]` | Hand a rendered report to the daemon's durable outbox. The command persists the text **before** anything can send and prints a durable handoff id. A material report submitted during quiet hours becomes a held notice until the window opens; otherwise it becomes a report whose delivery the daemon owns, retries with bounded backoff, and records. Delivery is [at-least-once](#report-delivery-the-outbox), so a crash mid-send is retried as a possible repeat and `delivered` never proves exactly one message. `--kind digest` is accepted at most once per local day, decided from the ledger; an unknown `--kind` exits `2`. Anything still owed appears in `status` with its age. |
 | `decision open --question TEXT [--blocks TEXT] [--resolves-when COND]` | Record a question the orchestrator has put to you, and print its id. A question that lives only in a session's context is lost at the next compaction — after which it is either asked twice or dropped silently. `--resolves-when` attaches a machine-checkable condition: `pr-merged:<https url>`, `pr-checks-green:<https url>`, `pr-mergeable:<https url>`, `issue-closed:<n>`, `npm-version:<pkg>@<version>`, or `rate-limit-reset:github`; anything else exits `2` listing the six forms. See [The decision ledger](#the-decision-ledger-resolves-when). |
 | `decision resolve <id> --answer TEXT` | Record what you decided. Exits `1` naming the id when it is unknown or no longer open, so a second answer cannot overwrite the first. |
 | `decision withdraw <id> [--reason TEXT]` | Close a question the session stopped needing, with why. Same guard as `resolve`. |
@@ -2050,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. |
@@ -2063,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
 
@@ -2085,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
 
@@ -2250,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. |
@@ -2261,6 +2567,14 @@ role must equal the configured holder.** `authority` has exactly two values, so
 a `!== "human"` test would have let a *worker* release. A worker is refused
 every release shape under the most permissive config there is.
 
+For Git-backed releases, `git-tag` is idempotent when the named tag exists
+locally but has not been pushed: it re-points the tag to the verified live
+default-branch head. `git-push-tags` performs the same re-point immediately
+before pushing if the default branch moved between the two calls. A tag already
+published on origin is immutable: an identical tag is accepted as already
+complete, while a different published target is refused and must use a new tag
+name.
+
 ### The transport
 
 Identity is never an argument. `project`, `run`, `issue` and the caller's role
@@ -2392,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.