omp-conductor 0.3.18 → 0.3.19

package/README.md

@@ -18,11 +18,11 @@ authority are chosen during setup and default to `human`. Granting either action
 to the orchestrator never grants it to a worker or the dispatch daemon. Releases
 remain batched from coherent groups of merged work, never cut one per worker PR.
 
-Code counts every limit that decides whether work starts: concurrency, dollars per
-day, turns and wall clock per worker, attempts per issue. None of it is left to the
-model. A worker asked to respect a budget eventually talks itself out of it, so the
-dispatcher enforces the budget before anything is claimed and kills anything over
-the line.
+Code counts every limit that decides whether work starts: concurrency, dollars
+per day, turns and wall clock per worker, failed implementation attempts, and
+operational continuations per issue. None is left to the model. The dispatcher
+enforces these budgets before anything is claimed and kills workers that exceed
+their per-run limits.
 
 When a run does get stuck, the first responder is not you. A tier-1 escalation is
 injected into a long-lived **orchestrator session** that can read the issue and the
@@ -39,7 +39,7 @@ The package ships three deployables, plus two skills:
 | Standalone daemon | `omp-conductor` binary | The dispatch loop, managed 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` | Treats the Bun-global CLI, omp plugin, and Herdr plugin as one operation: pause claims, drain, install one pinned release, reload, verify twice, and restore the prior pause state. See [Updating](#updating). |
+| 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
@@ -134,8 +134,11 @@ number of code repos, and both label names are yours to configure.
 omp plugin install omp-conductor
 ```
 
-From a checkout of the monorepo, `./setup.sh` links this plugin and the Herdr half
-after checking everything below.
+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.
+`./setup.sh install --force-link` is the explicit opt-in to link both checkout
+directories.
 
 ### Prerequisites
 
@@ -168,25 +171,39 @@ Also required on the host:
 
 ## Updating
 
-Say “update conductor” from an operator shell or maintenance omp session outside
-the target `herdr-fleet.service`. That is the whole operator interface. The bundled
-`skill://conductor-update` discovers the installed and registry versions, pauses
-new claims while active work drains, and pins one release across the Bun-global
-CLI, omp plugin, and Herdr plugin. It converts an old local Herdr link to a managed
-checkout when necessary, reloads the Herdr service and dispatch daemon, verifies
-the layered status twice, and restores the original dispatch state.
+Run one command from a shell outside the target `herdr-fleet.service`:
+
+```bash
+omp-conductor upgrade
+```
+
+It resolves the latest published npm release, pauses new claims, drains active
+workers, and pins that exact release across the Bun-global CLI, omp plugin, and
+Herdr plugin. It also recomposes the conductor-owned brief floor, restarts Herdr
+and the daemon, waits for pane recovery, verifies the installed identities and
+layered fleet status twice, then restores the original dispatch state.
+
+Use `omp-conductor upgrade --to X.Y.Z` for an explicit published version. The
+command exits without changing anything when all three surfaces already use that
+release, the Herdr plugin is pinned to its exact `gitHead`, and the brief is
+current.
+
+When a daemon is live, the command drains and restarts its recorded project.
+An explicit `--project` that names a different project is rejected before pause
+or installation, so an operator cannot drain one queue and kill another queue's
+workers.
 
 Ticks remain in their existing armed or disarmed state, so an ordinary update
 does not halt the exact pane or require another Telegram arm challenge. Any
 installation, reload, or verification failure leaves dispatch paused instead of
-bringing up a mixed fleet. The skill does not publish npm or edit an install root.
-It also refuses to run from the fleet pane that Herdr must restart: an updater
-that kills itself cannot verify the result. With skill commands enabled, invoke
-it directly with:
+bringing up a mixed fleet. 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.
 
-```text
-/skill:conductor-update
-```
+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
 
@@ -194,8 +211,8 @@ Onboarding this package has two layers, and installing it gives you both.
 
 | Layer | What it is | What it owns |
 | --- | --- | --- |
-| **`/conductor setup`** | The deterministic wizard. Closed questions, a label plan, a dry run, one confirm. On a project it already knows, it offers to amend one area instead of re-asking everything — see [Changing one setting](#changing-one-setting). | **Mechanical config.** It is the only thing that writes `config.json`, and it mutates nothing before you confirm. |
-| **`skill://conductor-onboarding`** | A skill bundled in this package (`skills/conductor-onboarding/SKILL.md`), discovered automatically by any omp session once the plugin is installed. | **Brief authoring.** The judgement the wizard cannot prompt for. |
+| **`/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. |
 
 The split exists 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
@@ -313,75 +330,113 @@ omp-conductor brief-upgrade --retrofit --apply
 ```
 
 - **Overlay already active** (`POLICY.md` present): protocol updates need no brief-upgrade.
-- **Legacy bannered brief**: `--migrate` lifts the owned half into `POLICY.md` and recomposes, with backups.
+- **Legacy bannered brief**: `--migrate` lifts the owned half into `POLICY.md`
+  and recomposes. Previous brief and policy versions go to
+  `$OMP_CONDUCTOR_HOME/backups/briefs/` (default
+  `~/.omp/conductor/backups/briefs/`), named with their source filename and
+  timestamp.
 - **Hand-written brief** (no banner): `--retrofit` inserts the banner before the first Releases / Project context / Reporting / Amendments heading; then `--migrate`.
 - **Legacy `--apply`**: still merges a bannered single-file brief when you need the old path.
+- **Existing sidecars**: a composed refresh relocates conductor-generated
+  `ORCHESTRATOR.md.bak-<timestamp>` and `POLICY.md.bak-<timestamp>` files into
+  that backup directory. Other `.bak` files stay untouched.
 
 `--file PATH` checks a brief that is not where the wizard would have put it.
 
-The **Learning loop** proposes diffs against `POLICY.md` for you to approve over Telegram.
+The **Learning loop** proposes diffs against `POLICY.md` for you to approve over
+Telegram. It also learns from repeated operational friction. The daemon
+automatically rolls up repairable admission holds; the orchestrator records
+judgments code cannot make with:
+
+```bash
+omp-conductor friction escalation-digest --detail "routine retry belonged in the digest" [--issue N]
+omp-conductor friction report-noise --detail "green status repeated with no operator action"
+omp-conductor friction report-surprise --detail "a material failure was missing from the report"
+```
+
+Three observations within seven days make a bounded signal eligible for one
+tick. After it is surfaced, that signal cools down for seven days. A signal is
+evidence to investigate, never an automatic policy edit: the existing one-at-a-
+time Telegram approval, `POLICY.md`-only edit, Hard-boundary prohibition, and
+**Amendments** log still apply.
 
 ## Quick start
 
-1. Write a config (see [Configuration](#configuration)) at
-   `~/.omp/conductor/config.json`.
-2. From an omp session:
+1. Install `omp-conductor` and `omp-telegram`. Pair the Telegram bot and enable its bridge.
+2. Open the long-lived omp session in the fleet workspace.
+
+   The default workspace is `~/.omp/conductor/worktrees`. The wizard shows the actual path before it writes files.
+
+3. Run the wizard:
 
    ```text
    /conductor setup
    ```
 
-   This is a **dry run first**. It reads the tracker through the same routing code
-   the loop uses and prints exactly what the next tick would pick up, which repo
-   each issue routes to, the branch it would cut, and every issue that cannot be
-   routed. **Nothing is mutated** — no label written, no run row, no worktree —
-   until you answer the "Arm omp-conductor?" confirmation. Arming does exactly two
-   things: create the state database, and clear the pause flag. Declining leaves
-   the machine untouched.
+   The wizard reads the tracker with the same routing code as the daemon. It shows every issue that the next tick can route.
+
+   Nothing changes before the consent step. After consent, setup does these actions:
+
+   - creates the required labels;
+   - writes `config.json` and the selected brief;
+   - writes `.conductor-tick.json` for external orchestration;
+   - stages `omp-conductor.service` under the conductor state directory;
+   - runs `daemon --once` while dispatch is paused;
+   - starts a temporary daemon and proves `/healthz` and stored status;
+   - stops the temporary daemon;
+   - proves the current inbound Telegram path before it arms or resumes an external heartbeat;
+   - clears the dispatch pause only after all required gates pass.
+
+   If the arm proof cannot complete, setup keeps dispatch paused. The result shows the exact recovery commands.
 
-   Two of its questions are about you rather than the fleet: how loud the
-   orchestrator should be (`reporting.scope`), and whether to write an
-   `ORCHESTRATOR.md` you then own. See
-   [Your workflow vs. the package](#your-workflow-vs-the-package). If you would
-   rather be interviewed through those two, and have the brief tailored and your
-   gates read out of your CI config, start from
-   [Onboarding](#onboarding) instead.
+4. On a systemd host, run the install commands that setup prints.
 
-3. Start the daemon in the background:
+   The commands install the staged unit, reload systemd, enable the unit, and restart it. The generated unit contains the current user, paths, project, port, and memory ceiling.
+
+   On a host without systemd, start the daemon directly:
 
    ```bash
    omp-conductor start
    ```
 
-   `start` first starts `herdr-fleet.service` when that optional unit is installed,
-   clearing a previous `halt --pane` recovery pin so Herdr can resume the exact
-   conductor pane. Hosts without systemd or without that unit keep the standalone
-   daemon behaviour. It then waits until the daemon actually answers
-   `GET /healthz`; spawning is not starting. A daemon whose config is broken,
-   whose port is taken or whose database is locked exits within a second, and the
-   command fails with the tail of `daemon.log` instead of printing a false
-   success. It refuses to start a second daemon, naming the live pid. Starting
-   processes does not clear `pause` or arm ticks; those remain explicit operator
-   decisions.
-
-   Pane recovery spans two separately installed plugins: npm ships the omp
-   heartbeat/status half, while `herdr-conductor` supplies `recover.sh`. After an
-   npm upgrade, refresh the Herdr plugin from `TerrifiedBug/conductor/herdr` as
-   well; publishing or installing npm alone cannot add the recovery-side tick
-   request.
-
-   For a first run, take a single tick in the foreground and watch it:
+5. Read the layered status:
 
    ```bash
-   omp-conductor daemon --once
+   omp-conductor status
    ```
 
-The loop ticks every 5 minutes. `omp-conductor stop` shuts the loop down after
-the current tick rather than mid-run. When the live process is the MainPID of
-`omp-conductor.service`, stop goes through `systemctl stop` so a unit with
-`Restart=on-failure` cannot bring it straight back; otherwise it is a raw
-`SIGTERM` (then `SIGKILL` after 10 seconds). An example unit (with
-`SuccessExitStatus=0 143` and `MemoryMax=5G`) ships as
+   The result must show a running daemon, a healthy `/healthz`, armed ticks for external orchestration, and the configured project.
+
+### First worker drill
+
+Use a disposable target repository for this drill. Replace the values below with labels that the wizard showed.
+
+```bash
+TRACKER=acme/planning
+QUEUE=ready-for-agent
+ROUTE=repo:api
+
+gh issue create --repo \"$TRACKER\" \
+  --title \"Conductor setup drill: add a marker file\" \
+  --body $'Add `conductor-smoke.txt` to the target repository.\\n\\nAcceptance: the file contains `setup path verified` and the pull request checks pass.' \
+  --label \"$ROUTE\" \
+  --label \"$QUEUE\"
+```
+
+The daemon claims the issue, creates a worktree, runs the configured gates, and opens a pull request. Follow it with:
+
+```bash
+omp-conductor status
+omp-conductor tail <issue-number>
+```
+
+Merge the green pull request. Then make sure that status moves the run to `merged` and frees its worker slot.
+
+The loop ticks every 5 minutes while workers remain active. Merge settlement and capacity checks do not wait for the longest worker.
+
+`omp-conductor stop` drains active workers before it stops. On systemd, it uses `systemctl stop` to prevent an automatic restart.
+
+The package also ships a generic unit at
 [`systemd/omp-conductor.service.example`](systemd/omp-conductor.service.example).
 
 
@@ -400,6 +455,25 @@ Four control planes used to answer "stop" differently. The package verbs:
 
 `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.
 
+`omp-conductor board [--project NAME]` opens the same facts as a live terminal
+kanban instead of a scrolling wall of status text. Its columns are Queue,
+Claimed, Running, Green, Blocked, Failed, and Merged. Queue cards are the
+bounded per-issue hold sample recorded by the latest dispatch; the Queue count
+is the authoritative ready count even when there are more ready issues than
+sampled cards. Run columns show the newest attempt for each issue. Merged keeps
+only the last 24 hours so the board stays operational rather than becoming an
+analytics archive.
+
+The board refreshes run, spend, turn, and dispatch values from SQLite every
+second. It refreshes the slower daemon, Herdr, Telegram, and code-graph health
+layer every ten seconds or immediately with `r`. Use arrow keys or `h/j/k/l` to
+select a card, `Enter` to inspect and follow its worker transcript, `u` to run
+the normal unblock workflow, `i` / `p` to open the issue / pull request, `?` for
+help, and `q`, `Esc`, or `Ctrl-C` to go back and quit. Narrow terminals show a
+sliding subset of columns around the selection; terminals below 50×20 get a
+single resize instruction instead of a broken layout. The board is read-only
+except for the explicit `u` action: it never claims work or changes stages.
+
 `halt --pane` is **fail-closed**: it exits `0` only when the conductor agent is
 *proven* gone. It writes the recovery pin first, so a failed stop still cannot be
 undone by `herdr-conductor` respawning the agent, and then refuses (nonzero exit,
@@ -435,16 +509,18 @@ Clear the pin with `omp-conductor release-pane` when you want recovery again.
 
 Per tick, for the daemon's project:
 
-1. **Paused?** If the pause sentinel exists, the tick claims nothing and returns.
-   Pause is checked first, so `omp-conductor pause` takes effect on the next tick
-   without signalling the process.
-2. **Settle the green PRs.** For every run in `pushed-green`, ask the tracker
-   what became of its PR. Merged → the row becomes `merged`; closed without
-   merging → `failed`, with the PR named in the row's `lastError`. Still open, or
-   an answer that could not be obtained at all → the row is left exactly as it
-   is. Bounded by the number of green PRs awaiting a merge, which is a handful by
-   construction. This runs above admission so a row settled here frees its issue
-   in the same tick. See [what settles a green PR](#what-settles-a-green-pr).
+1. **Verify and settle pushed PRs.** For every run in `pushed-pending`, repeat
+   the independent head/check verification; green → `pushed-green`, red →
+   `failed`, and still pending stays occupied. For every verified
+   `pushed-green` run, ask what became of its PR. Merged → `merged`; closed
+   without merging → `failed`. Unknown answers leave the row unchanged. This
+   maintenance runs even while dispatch is paused or workers are active, so
+   status converges on the five-minute tick cadence. It also runs above admission
+   so a row settled here frees its issue in the same tick. See
+   [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.
 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
@@ -454,26 +530,31 @@ Per tick, for the daemon's project:
 6. **Check spend.** If spend since local midnight has reached `dailySpendUsd`, the
    daemon **pauses itself**, pages at Tier 2, and returns.
 7. **Check capacity.** `maxConcurrentWorkers` minus *live* workers (runs in
-   `claimed` or `running`) gives the free slots. A green PR awaiting a human
-   merge occupies its issue but not a slot: its worker is finished, and counting
-   it would let two green PRs stop the fleet. If no slot is free, the tick logs
-   and returns.
+   `claimed` or `running`) gives the free slots. A pending or green PR occupies
+   its issue but not a slot: its worker is finished, and counting pushed PRs
+   would let two completed workers stop the fleet.
+   If no slot is free, the tick logs and returns.
 8. **Admit issues** up to the free slots, skipping any issue that already has
-   an active run — including a green PR, so a second attempt can never land on a
-   live PR. An issue that has used `maxAttemptsPerIssue` escalates at Tier 1
-   instead of being admitted.
+   an active run — including a pending or green PR, so a second attempt cannot
+   land on a live PR. Repeated implementation failures consume
+   `maxAttemptsPerIssue`; cap kills, daemon orphans and answered blocks consume
+   the independent `maxContinuationsPerIssue`. Exhausting either escalates.
 9. **Ask the tracker whether the work already exists.** For each candidate that
    survived step 8 — so at most one API call per free slot, never one per queued
-   issue — the daemon asks whether an **open** PR already closes the issue. If one
-   does, the issue is skipped with its PR named in the log. Drafts count: a draft
-   PR's branch still holds the only copy of the work. This is the guard the store
-   cannot provide, because a store younger than the PRs (a migration, a wiped or
-   relocated state directory, a restore onto a new host) has no row to object
-   with. If the check itself fails, the candidate is **held**, not admitted, and
+   issue — the daemon asks whether an **open** PR already closes it. An open PR
+   normally holds the issue. One narrow exception permits a routed continuation:
+   the PR URL must match the latest terminal run's retained PR exactly. Drafts
+   count because their branch can hold the only copy of the work.
+   The tracker also finds work missing from a new, moved, restored, or cleared
+   store. If the check fails, the candidate is **held**, not admitted, and
    retried next tick: the cost of holding is five minutes, the cost of admitting
    on an unknown is a burned attempt and a duplicate PR. Only that candidate is
    held, so a flaky API cannot stall the rest of the queue.
-10. **Dispatch** the admitted issues concurrently.
+10. **Record the pass.** Persist ready/routed/admitted counts and group every hold
+    under a stable reason code with at most five sample issue numbers. Tracker
+    failures mark the summary `DEGRADED`; capacity, sibling, open-PR and budget
+    holds remain normal policy state.
+11. **Dispatch** the admitted issues concurrently.
 
 Then, per admitted issue:
 
@@ -496,13 +577,15 @@ Then, per admitted issue:
 
    | Outcome | Labels | Worktree | Escalation |
    | --- | --- | --- | --- |
+   | `pushed-pending` | `agent:in-progress` stays while the daemon rechecks GitHub | removed | none |
    | `pushed-green` | `agent:in-progress` stays until the merge closes the issue | removed | none |
    | `blocked` | swapped to `agent:blocked` | removed | Tier 1 |
-   | `failed` / `killed` | swapped to `agent:failed` | dirty tree committed to the branch, then **kept** as evidence | Tier 1 |
+   | `failed` / `killed` | swapped to `agent:failed` | dirty tree committed to the branch, then retained until the PR or issue is terminal | Tier 1 |
    | unexpected error | swapped to `agent:failed` | same | Tier 1 |
 
-   `pushed-green` is not the end of the row: a later tick settles it once the PR
-   resolves. See [what settles a green PR](#what-settles-a-green-pr).
+   `pushed-pending` and `pushed-green` are not the end of the row: later ticks
+   verify outstanding checks and settle the PR once it resolves. See
+   [what settles a green PR](#what-settles-a-green-pr).
 
    Label swaps add the new label before removing the old one: the reverse order
    leaves a window in which the issue carries no state label at all, which is
@@ -521,6 +604,13 @@ Then, per admitted issue:
    run is deliberately *not* salvaged — it stopped on purpose, with turns still
    in hand to commit for itself.
 
+   Later ticks reap retained failure trees in bounded batches after the tracker
+   proves their PR merged/closed or their issue closed, provided no live run or
+   queued continuation owns the issue. Cleanup fetches remote refs first and
+   keeps any dirty tree or branch with uniquely local commits. Only then does it
+   remove the physical tree, prune registrations, and delete the obsolete local
+   mirror branch. Unknown tracker, network, repo, or git state is a no-op.
+
 ### What a restart does to runs that were in flight
 
 A `claimed` or `running` row is a promise that a worker process exists, and a
@@ -538,8 +628,9 @@ label is the crash guard against double-dispatch — and deciding what the dead
 worker's remains are worth is the orchestrator's drain-duty judgement, spelled
 out in its brief: an open green PR goes to the merge path, a salvaged sha is a
 continuation hand-off, and a clean orphan has its label released so the next
-tick re-claims it. Orphaned attempts still count toward `maxAttemptsPerIssue`,
-so a crash loop escalates instead of redispatching forever.
+tick re-claims it. Orphans consume `maxContinuationsPerIssue`, not failed
+implementation attempts, so crashes cannot starve the retry needed for a real
+code or CI failure — and a crash loop still escalates.
 
 ### Deploying a new package onto a busy fleet
 
@@ -548,34 +639,36 @@ this version is installed: startup salvage commits dirty trees before orphaning
 rows, and salvage rewrites the mirror's managed `info/exclude` to the package's
 current list before `git add` so a narrowed ignore cannot hide deliverables.
 
-It is still disruptive for **in-flight sessions** (the worker process dies; the
-attempt is spent). Prefer draining when you can wait:
+It is still disruptive for **in-flight sessions** because the worker process dies
+and the attempt is spent. Update through the lifecycle command rather than
+hand-installing or restarting individual surfaces:
 
-1. `omp-conductor pause` — stop new claims; live workers finish.
-2. Wait until `omp-conductor status` shows `workers 0 / N` (no `deploy` hint line).
-3. Install the new package (`bun add -g omp-conductor@…`, `omp plugin install …`).
-4. `systemctl restart omp-conductor` (or `omp-conductor restart`).
-5. `omp-conductor resume` if you left it paused.
-
-If you cannot wait:
+```bash
+omp-conductor upgrade
+```
 
-1. `omp-conductor pause` (optional but keeps new claims off during the swap).
-2. Install.
-3. Restart — salvage runs on boot for every live worktree, then rows go `orphaned`.
-4. Resume; the pane orchestrator triages `agent:in-progress` orphans (continuation
-   / merge / release label). Status prints a `deploy` line while live workers > 0
-   so you can see the risk before you restart.
+It pauses new claims, drains workers, installs one pinned release across all
+surfaces, restarts, verifies twice, and resumes only if dispatch was initially
+running. If an install, restart, or verification step fails, dispatch remains
+paused and the command exits nonzero.
 
 Do **not** edit files under the running install and expect the daemon to keep
-dispatching — the integrity tripwire pauses and pages. Install, then restart, so
-the new process records a fresh baseline.
+dispatching — the integrity tripwire pauses and pages. Upgrade by whole release
+so the new process records a fresh baseline.
 
 ### What settles a green PR
 
-`pushed-green` means the worker finished, pushed, and watched the checks go green.
-What happens next is a human's decision, taken minutes to days later and never
-announced to the daemon — so every tick asks the tracker about every green PR it
-is still holding, and settles the ones that resolved:
+The worker watches CI, then reports the PR URL and the exact remote head SHA it
+observed. The daemon independently reads the PR again and requires it to be open,
+non-draft, still at that head, and backed by a non-empty check rollup in which
+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`.
+
+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
+every pushed PR it is still holding:
 
 | PR | Row becomes | Why |
 | --- | --- | --- |
@@ -584,12 +677,12 @@ is still holding, and settles the ones that resolved:
 | 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. |
 
-The attempt counter is untouched either way, because both were real attempts. Run
-rows are the only thing that changes: a merge normally closes the issue, and a
-human who closed a PR is already looking at it, so what an issue's labels should
-say next is the orchestrator's drain-duty judgement — the same division of labour
-as a restart, above. One unreachable PR costs its own row and nothing else; the
-rest of the sweep still settles.
+Run history is untouched. A PR closed without merging becomes a concrete failed
+attempt; a merge does not spend failure or continuation budget. A merge normally
+closes the issue, and a human who closed a PR is already looking at it, so what
+an issue's labels should say next remains the orchestrator's drain-duty
+judgement. One unreachable PR costs its own row and nothing else; the rest of
+the sweep still settles.
 
 Until this existed, nothing ever revisited a `pushed-green` row: the startup
 reconciler only settles rows that held a process, and `merged` went unwritten. On
@@ -687,9 +780,10 @@ rest. `0` is a real value (a hard stop), not "unset".
 | --- | --- | --- |
 | `maxConcurrentWorkers` | `2` (setup may write `1` on &lt;16 GiB hosts) | Parallel in-process omp sessions inside the daemon PID. Two, because **CI runner slots, not model tokens, are the usual throughput ceiling** — a third worker would starve its own PR checks on a small self-hosted runner pool. On hosts under ~16 GiB RAM, prefer `1` so the unit stays out of swap ([host sizing](#host-sizing-and-memory)). Raise it only if you actually have the runners *and* the RAM. |
 | `dailySpendUsd` | `25` | Rolling-day spend ceiling in USD, or `null` for no spend gate. `0` is a hard stop. Metered from assistant `usage.cost.total`. |
-| `workerMaxTurns` | `120` | Turn ceiling for one worker. Catches a session looping without converging. |
+| `workerMaxTurns` | `120` | Startup ceiling for each new worker. Catches a session looping without converging; use `omp-conductor extend` to raise one live run without changing this default. |
 | `workerWallClockMs` | `5400000` (90 minutes) | Wall-clock ceiling for one worker. A session that is merely stuck spends no turns, so turns alone cannot detect it. |
-| `maxAttemptsPerIssue` | `2` | Retries per issue before it escalates. One clean retry recovers from flaky CI; a third attempt almost always means the issue itself is underspecified. |
+| `maxAttemptsPerIssue` | `2` | Failed implementation or CI attempts before escalation. Operational stops do not consume this budget, so salvage can continue without stealing the retry needed for a real failure. |
+| `maxContinuationsPerIssue` | `2` | Cap-kill, daemon-orphan and answered-block resumes before escalation. This independently bounds crash/resume loops. |
 
 Days are counted from **local midnight**, matching how a human reads "today".
 
@@ -699,8 +793,15 @@ 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`).
 
-`workerMaxTurns` and `workerWallClockMs` are enforced inside the session driver: the
-run is aborted, recorded as `killed`, and the escalation names which ceiling fired.
+`workerMaxTurns` and `workerWallClockMs` are enforced inside the session driver.
+The daemon reads a live run's effective turn ceiling at every turn boundary. Use
+`omp-conductor extend <issue> --turns N [--project NAME]` to raise it without
+restarting or reconstructing the session. Extension is monotonic: equal or lower
+values are refused, as are runs whose live controller has already settled. The
+effective value is persisted and shown beside that active run in `status`; editing
+`config.json` changes defaults for future daemon starts, not workers already in
+flight. A cap that fires aborts the run, records it as `killed`, and names the
+ceiling in the escalation.
 
 ## Worker model
 
@@ -736,10 +837,10 @@ defined" in one call instead of twenty greps.
 
 ### Two things this package does not do for you
 
-`omp-conductor` never installs, spawns, imports or depends on the indexer — with
-`graphProject` unset, nothing about dispatch, caps or escalation changes. That
-means a fresh host needs both of these before an index is worth anything, and
-`graph-setup` reports them as step 0:
+`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:
 
 1. **`codebase-memory-mcp` on PATH** — a separate project,
    [DeusData/codebase-memory-mcp](https://github.com/DeusData/codebase-memory-mcp).
@@ -750,11 +851,11 @@ means a fresh host needs both of these before an index is worth anything, and
 
 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). Nothing else changes: this package
-never runs an indexer, never imports one, and behaves identically with the graph
-server absent — dispatch, caps and escalation do not know it exists. On a fleet
-that was configured before this key existed, `/conductor setup` and the `code
-graph` area add it in two prompts — see
+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
+the `code graph` area add it in two prompts — see
 [Changing one setting](#changing-one-setting).
 
 ### Why the clone, and not your checkout or the worktree
@@ -813,6 +914,18 @@ neither usefully: the indexer resolves its store from `HOME`, systemd's default
 user that ran `graph-setup`; the unit sets no `User=`, so check them if that is
 not the account the timer runs as.
 
+### Seeing whether the graph is usable
+
+When at least one routed repo has `graphProject`, `omp-conductor status` adds a
+`code graph` block. It proves the indexer is on `PATH`, the worker MCP config
+mounts it, every configured clone exists and exactly matches an indexed
+`root_path`, the refresh timer is enabled and active, and the last service run
+succeeded within 45 minutes. A running daemon refreshes this evidence every
+minute and publishes the cached result through `/healthz`; status probes the host
+directly when that cache is unavailable. Every command is read-only, runs with a
+one-second timeout, and graph degradation never changes `/healthz.ok` or blocks
+dispatch. Unconfigured projects omit the block entirely.
+
 ## Escalation tiers
 
 | Tier | Meaning | Raised by | Delivered to |
@@ -873,7 +986,10 @@ The config lives at `$OMP_CONDUCTOR_HOME/config.json`, or
 `~/.omp/conductor/config.json` when that variable is unset. It is written with mode
 `0600` in a directory created `0700`, because it carries chat ids and clone URLs.
 That same directory holds the SQLite store (`conductor.db`), the `paused` sentinel,
-the `sessions/` worker transcripts and the `orchestrator/` session directory.
+the `sessions/` worker transcripts, the `orchestrator/` session directory,
+`backups/briefs/` for timestamped brief and policy safety copies, and
+`release-policy-blocks.jsonl`, the append-only audit of mechanically rejected
+release/deploy calls.
 
 Runtime state lives elsewhere, under `$OMP_CONDUCTOR_RUNTIME_DIR` (default
 `~/.omp/run/daemons/omp-conductor`): `daemon.json`, a mode-`0600` pidfile written
@@ -909,7 +1025,8 @@ A complete, valid config for one project with two target repos:
     "dailySpendUsd": 25,
     "workerMaxTurns": 120,
     "workerWallClockMs": 5400000,
-    "maxAttemptsPerIssue": 2
+    "maxAttemptsPerIssue": 2,
+    "maxContinuationsPerIssue": 2
   },
   "projects": [
     {
@@ -959,6 +1076,7 @@ A complete, valid config for one project with two target repos:
         "merge": "human",
         "release": "human"
       },
+      "releasePolicy": "none",
       "reporting": {
         "scope": "material"
       },
@@ -986,6 +1104,7 @@ Field notes:
 | `escalation.fallbackToIssueComment` | Defaults to `true`. Absent means "yes, still tell me". |
 | `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.scope` | Optional; `"material"` (default) or `"escalations"`. Every orchestrator tick appends the matching constraint line to its prompt, re-read from this file each tick — see [Your workflow vs. the package](#your-workflow-vs-the-package). It constrains what the session is told to report; it is not an outbound filter. A config written without the key keeps reporting material events. Any other value is an error, never folded to the default. |
 | `workspaceRoot` / `mirrorRoot` | Optional; default to `worktrees/` and `mirrors/` under the state directory. `~` is expanded. |
 
@@ -1000,9 +1119,9 @@ running its loop. A 24/7 omp session with a standing brief and nobody typing int
 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's cwd contains
-`.conductor-tick.json`**, so it costs an ordinary session nothing. Drop the file
-in the orchestrator's working directory:
+The heartbeat is **inert unless the session cwd contains
+`.conductor-tick.json`**, so an ordinary session has no timer. `/conductor setup`
+writes this file for external orchestration. A manual configuration has this form:
 
 ```json
 {
@@ -1199,14 +1318,18 @@ omp-conductor start [--port N] [--project NAME]
 omp-conductor --version
 omp-conductor stop
 omp-conductor restart [--port N] [--project NAME]
+omp-conductor upgrade [--to VERSION] [--project NAME]
 omp-conductor status [--project NAME]
+omp-conductor board [--project NAME]
 omp-conductor hold [--project NAME]
 omp-conductor halt [--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 unblock <issue> [--project NAME]
+omp-conductor friction <escalation-digest|report-noise|report-surprise> --detail TEXT [--issue N] [--project NAME]
 omp-conductor daemon [--once] [--port N] [--project NAME]
 omp-conductor pause
 omp-conductor resume
@@ -1220,16 +1343,20 @@ omp-conductor help
 | `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` | 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. 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). |
-| `status [--project NAME]` | Layered fleet report first: `dispatch` / `ticks` / next scheduled tick / `pane` / `recovery` / `herdr` / `telegram` / `daemon`, then the project body. The next time 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. The daemon block includes `rss` from `/healthz`; live workers add a busy-deploy warning. A `.conductor-stalled` marker adds an `orchestrator STALLED since …` line. |
+| `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` / optional `code graph` / `daemon`, then the project body. The project body includes the latest completed dispatch timestamp, ready/routed/admitted counts, and bounded hold groups; 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. The daemon block includes `rss` from `/healthz`; live workers add a busy-deploy warning. A `.conductor-stalled` marker adds an `orchestrator STALLED since …` line. |
+| `board [--project NAME]` | Live keyboard-driven kanban over the same SQLite and `/healthz` truth as `status`: Queue, Claimed, Running, Green, Blocked, Failed, and the last 24 hours of Merged. Refreshes run/spend/turn values every second and slower health every ten seconds. `Enter` follows the selected transcript in place; `u` invokes the existing unblock workflow; `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. |
 | `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>`. |
-| `unblock <issue>` | Remove that issue's `blocked` and `failed` state labels through the tracker, so the next tick can claim it again. This is the supported way back for an escalation you answered: eligibility disqualifies any issue carrying a state label, so an answered issue that keeps one is never re-claimed and the answer is inert. Removing a label the issue does not carry is a no-op, so both are always cleared and neither has to be looked up first. `agent:in-progress` is deliberately not touched — it means a worker process exists, which is not something an answer changes. The run history is left exactly as it is: an answered block still spent a worker, so it still counts toward `maxAttemptsPerIssue`, and the output says how many attempts remain — or warns that the next tick will escalate instead of dispatching, when none do. Exits `2` with `unblock needs an issue number` on a missing or malformed positional. |
-| `daemon` | Run the loop in the **foreground**, ticking every 5 minutes and serving `/healthz`. This is what `start` launches, and what a systemd unit should call. Writes the pidfile itself, and refuses with `another daemon is alive (pid N); stop it first` rather than becoming a second dispatcher. |
-| `daemon --once` | Run a single tick and exit. No HTTP server, and no 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. |
+| `extend <issue> --turns N [--project NAME]` | Monotonically raise that live worker's effective turn ceiling through its owning daemon. The current omp session keeps running; no restart or continuation is created. The daemon persists the new ceiling for `status` and rejects missing, settled, cap-killed, equal, or lower requests instead of implying that an immutable session changed. |
+| `unblock <issue>` | Remove that issue's `blocked` and `failed` labels so an answered escalation can be claimed again. `agent:in-progress` is never touched. 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. Exits `2` when the issue number is missing or malformed. |
+| `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. |
+| `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. |
 | `pause` | Stop claiming new work only. The running daemon notices on its next tick; runs already in flight finish. The orchestrator heartbeat keeps ticking if armed — its gate is the arm marker, not this flag. Prefer `hold` to silence both. |
@@ -1261,17 +1388,52 @@ curl -s localhost:8787/healthz
 ```
 
 ```json
-{ "ok": true, "paused": false, "activeRuns": 1, "project": "demo" }
+{
+  "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"
+      }
+    ],
+    "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`. Note that `ok` reports only that the
-process is serving. It does not report that the fleet is doing work: read
-`paused` to tell those apart.
-
-`activeRuns` counts occupied issues — live workers plus green PRs still awaiting a
-merge — and each of those is settled by the tick once its PR resolves, so the
-number goes back down on its own. A count that only ever grows is the bug this
-used to have: read [what settles a green PR](#what-settles-a-green-pr).
+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.
 
 ## What a worker may and may not do
 
@@ -1287,11 +1449,11 @@ dispatcher. The brief is explicit about the boundary:
 | Run the repo's configured cheap gates, each from its listed `cwd`, over the whole tree. | Run docker or image builds, production builds, browser/e2e suites, or the full test suite on the shared host — CI owns the heavy gates. |
 | Review its whole diff, then commit and **push once**. One corrective push if CI is red. | Force-push, `git add -f`, or add AI/co-author attribution. Red twice means stop and report, not push a third time. |
 | Open a PR that links the issue, and watch CI to a verdict with `gh pr checks --watch`. | Run `gh pr merge`. **A worker never merges** — that one is absolute, whoever else holds the authority — so PRs land one at a time with a freshness re-check; two workers merging concurrently is how agent PRs clobber each other. Who *may* merge is the [`authority`](#configuration) answer, and it is never the worker. |
-| Escalate: ambiguity, a cross-repo contract, a needed credential, a product or data-migration decision, a blocking existing test, CI red twice, or most of the wall-clock budget burned. | **Cut a release**, push a tag, publish to npm, edit a deployment pin, deploy, or touch infrastructure or secrets — permanently out of scope. Releases are batched and decided outside this loop, so "this needs releasing" is a thing to report, never a task to take on. |
+| Escalate: ambiguity, a cross-repo contract, a needed credential, a product or data-migration decision, a blocking existing test, CI red twice, or most of the wall-clock budget burned. | **Under the default `releasePolicy: "none"`:** cut a release, push a tag, publish to npm, edit a deployment pin, deploy, or touch infrastructure or secrets. The harness blocks recognised release/deploy tool calls before they run and audits the attempt. A project may deliberately set `operator-brief` only after its operator-owned brief contains the exact release procedure; that opens the tool gate but does not change `authority.release`. |
 
-The worker ends with a six-line evidence report (issue, pr, state, gates, changed,
-next). `pushed-green` means it watched the checks go green rather than expecting
-them to.
+The worker ends with a seven-line evidence report (issue, PR, observed head SHA,
+state, gates, changed, next). A textual `pushed-green` claim is not success: the
+daemon repeats the PR/head/check verification before it records that state.
 
 ### Worker confinement and the integrity tripwire
 
@@ -1303,10 +1465,11 @@ which installs an inline harness extension that blocks `write` / `edit` /
 `routing.repos` is ever checked out — and the caps still bound *how much* work
 happens.
 
-**`bash` is not gated.** Its argument is an opaque shell string; pretending to
-parse it would be a false sense of security. The brief still forbids escaping
-via the shell, and the deploy-level answer is a least-privilege worker uid
-(below).
+General shell access is not confined to the worktree. Its argument is an opaque
+program, so the brief still forbids path escape and the deploy-level answer is a
+least-privilege worker uid (below). The narrower release-policy tripwire does
+inspect explicit command shapes such as `git tag`, `npm publish`, and deploy
+verbs; it blocks those before execution when `releasePolicy` is `none`.
 
 #### Integrity tripwire (package self-hash)
 
@@ -1378,25 +1541,27 @@ Known and deliberate in this version:
 - **No cross-process lock on the mirrors.** Two dispatch loops fetching the same
   repo at the same instant can collide on git's ref locks; the run fails and is
   retried rather than corrupted.
-- **Mirrors grow one branch ref per run.** Unpushed work is never discarded, so
-  refs accumulate until you reap them.
-- **`stop` is a deadline, not a clean drain.** Whether it goes through
-  `systemctl` or a raw signal, the loop is asked to finish the tick it is on, and
-  a tick with a worker in flight can run for that worker's whole wall clock; the
-  signal path escalates to `SIGKILL` after 10 seconds. There is no "stop once the
-  current worker lands". A unit that supervises the daemon should set
-  `SuccessExitStatus=0 143` (belt-and-braces for a handled `SIGTERM` exit) and
-  operators should prefer `omp-conductor stop` / `systemctl stop` over a raw
-  `kill`, so `Restart=on-failure` cannot misread a deliberate stop as a crash.
+- **Uniquely local mirror branches are retained.** Terminal runs are reaped
+  automatically only after every commit exists on a remote ref. A failed salvage
+  push deliberately leaves its branch and tree for an operator rather than
+  trading disk hygiene for data loss.
+- **`stop` is a bounded best-effort drain.** A signal stops new ticks and the
+  daemon waits for its active worker pool before closing the store. The CLI
+  escalates to `SIGKILL` after 10 seconds, so a worker that needs longer is
+  orphaned and salvaged on restart. Use `pause`, wait for `workers 0 / N`, then
+  stop when a clean drain matters. A supervising unit should set
+  `SuccessExitStatus=0 143`, and operators should prefer `omp-conductor stop` /
+  `systemctl stop` over raw `kill`, so `Restart=on-failure` cannot misread a
+  deliberate stop as a crash.
 - **A failed orchestrator degrades quietly.** The daemon logs a warning and keeps
   running, but tier-1 escalations then land in issue comments — which is exactly the
   "nobody reads it until morning" path the orchestrator exists to avoid. The warning
   is in `daemon.log`; nothing pages you about it.
-- **Workers are not terminal panes, so you cannot watch them.** A worker is an
-  in-process omp session inside the daemon, started by `createSession` and driven
-  concurrently via `Promise.allSettled`. Herdr therefore shows exactly one pane
-  (the orchestrator's) no matter how many workers are running, and no amount of
-  `maxConcurrentWorkers` changes that.
+- **Workers are not terminal panes, so you cannot watch them there.** Each
+  worker is an in-process omp session started by `createSession`. The resident
+  daemon tracks workers in a background pool so the five-minute loop keeps
+  settling PRs and checking capacity; shutdown waits for that pool. Herdr still
+  shows exactly one pane (the orchestrator's) regardless of concurrency.
 
   The cap does work. The admission loop (`admitCandidates` in `src/daemon.ts`) computes
   `slots = maxConcurrentWorkers - live workers`, admits at most that many issues