omp-conductor 0.19.7 → 0.20.0

package/REFERENCE.md

@@ -2811,7 +2811,9 @@ omp-conductor drain status [--project NAME]
 omp-conductor drain cancel [--project NAME]
 omp-conductor stop [--pane] [--project NAME]
 omp-conductor arm [--project NAME]
+omp-conductor arm --reply TEXT [--project NAME]
 omp-conductor disarm [--project NAME]
+omp-conductor console [--project NAME]
 omp-conductor tail <issue> [--project NAME]
 omp-conductor extend <issue> --turns N [--project NAME]
 omp-conductor worker pause <issue> [--project NAME]
@@ -2829,6 +2831,9 @@ omp-conductor decision withdraw <id> [--reason TEXT] [--project NAME]
 omp-conductor decision list [--project NAME] [--json]
 omp-conductor watch add --note TEXT [--blocks TEXT] [--resolves-when COND] [--project NAME]
 omp-conductor watch list [--project NAME] [--json]
+omp-conductor epic approve <issue> [--project NAME]
+omp-conductor epic revoke <issue> [--project NAME]
+omp-conductor epic list [--project NAME] [--json]
 omp-conductor daemon [--once] [--port N] [--project NAME]
 omp-conductor resume [--project NAME]
 omp-conductor brief-upgrade [--migrate|--retrofit] [--apply] [--file PATH] [--project NAME]
@@ -2852,8 +2857,9 @@ omp-conductor help
 | `hold [--keep-ticks] [--project NAME]` | fleet | Soft stop: pause claiming **and** disarm ticks. Daemon and pane stay up. Prefer this when the intent is "stop the conductor" without killing processes. `--keep-ticks` pauses claiming but leaves the arm marker, so the heartbeat keeps reporting and `resume` alone restores the fleet — no fresh arm challenge. See [Stop the conductor](README.md#stop-the-conductor-hold--stop). |
 | `drain start --until ISO\|DURATION [--reason TEXT]` / `drain status` / `drain cancel` | project | Start, inspect, or cancel the project's self-expiring admission fence (#484): a durable, bounded alternative to queue-label churn before a release. `start` writes the project's drain record through the landed `createDrain` — new claims pause while active runs settle, and admission resumes automatically at the absolute deadline even if the orchestrator dies. A successful mediated `conductor_release` also clears the drain once the terminal release act completes — version-bump preparation stays latched until the tag is actually cut — so the release window ends with the release itself rather than latching until the deadline (#791). `--until` takes an ISO instant or a relative duration (`90s`, `45m`, `2h`, `1d`) that must be bounded and in the future; a missing, unparseable, unbounded, or past expiry exits `2` before any state changes. `--reason` (1–500 characters) is persisted on the record. `status` reports inactive, or the active drain's creation time, absolute expiry, reason, and remaining active runs from the structured status snapshot. `cancel` removes only the named project's drain and is idempotent. The drain never touches the pause sentinel, the arm marker, or any queue label — it is a file record, not a hold. |
 | `stop [--pane] [--project NAME]` | fleet | 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]` | fleet | Proof-gated: send a Telegram challenge and write this project's arm marker only after the orchestrator's inbound adapter has acknowledged your reply in conductor's own state — no transcript is read, so where (or whether) a session file lives does not matter (#614). The challenge names the project, so a host running two fleets is not ambiguous. Never auto-armed by `resume` / `hold`. |
+| `arm [--project NAME]` / `arm --reply TEXT [--project NAME]` | fleet | Two mechanical halves, because nothing waits inside a session any more: the operator's reply lands in the console, which runs no tick extension, so the in-session acknowledgement this replaces could never be satisfied. `arm` files a challenge, sends it to the owner, and returns immediately — **nothing is armed yet** — printing the challenge id, how long it stays valid, the markers a reply will write, and the exact follow-up command. `arm --reply "<the operator's message, verbatim>"` verifies that message against the recorded challenge, writes the arm marker for exactly the projects that challenge named, and settles the challenge so the same code can never arm anything twice. Still proof-gated on conductor's own state — no transcript is read, so where (or whether) a session file lives does not matter (#614). A bare or empty `--reply` is refused rather than silently sending a second challenge in place of a verification. One ceremony covers the whole fleet (#991), and the challenge names its projects, so a host running two fleets is not ambiguous; `--project X` is still one project, one challenge, one marker. When the plumbing verdict is `claim-only` no challenge is sent and `arm` arms directly, naming that proof instead. Never auto-armed by `resume` / `hold`. |
 | `disarm [--project NAME]` | fleet | 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. |
+| `console [--project NAME]` | project | Provision the operator console's workspace and print how to launch it: a dedicated cwd at `<state dir>/console/<project>`, this project's rendered console brief as `CONSOLE.md`, and an `AGENTS.md` symlink beside it so a session started there loads that brief. Idempotent — an already-current brief and a correct link are reported and left alone, and a *regular* `AGENTS.md` an operator wrote is never overwritten. It launches nothing: the printed pane command (`cd <cwd> && OMP_TELEGRAM_DM_OWNER=1 omp`, without the env prefix on a host configuring more than one project, which names the others and why) is what `herdr/bin/recover.sh` restores with the fleet, and what you run by hand otherwise. The console cwd deliberately holds no `.conductor-tick.json`, so the heartbeat extension cannot activate in it. |
 | `tail <issue>` | project | 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]` | project | 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>` | project | 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. |
@@ -2869,6 +2875,9 @@ omp-conductor help
 | `decision list [--json]` | project | Open questions, oldest first: id, age, what each blocks, whether its condition is met, and the question. `--json` emits `{ project, decisions }`; the empty state is an empty array. Prints `no open decisions` in text mode when there are none. Watches are not listed here — `watch list` shows those. |
 | `watch add --note TEXT [--blocks TEXT] [--resolves-when COND]` | project | Record a condition or carry note the orchestrator set for itself, with no human in the loop (#459). `--resolves-when` attaches a machine-checkable condition the daemon checks for you; a met watch wakes the next tick exactly as a met question does. Renders under its own "Watches" heading, is never counted in `decisions N open`, and never expires while it is *waiting* — once a condition fires, the ordinary seven-day window runs from that instant (#966). |
 | `watch list [--json]` | project | Open watches, oldest first: id, age, what each blocks, whether its condition is met, and the note. `--json` emits `{ project, watches }`; the empty state is an empty array. Prints `no watches` in text mode when there are none. |
+| `epic approve <issue>` | project | Record standing consent to an epic's scope (#1041): brief-complete children of it pass the promotion ready gate and are queued without a fresh operator decision. Its own durable fact, not a resolved decision row — an approval never expires, and the gate reads a boolean instead of parsing an answer somebody wrote in prose. Idempotent and first-write-wins: re-approving keeps the original timestamp and prints that nothing changed, so a second approve is never mistaken for one that failed to stick. Whether the number really names an epic is not checked here — parents and children are native GitHub sub-issues, which the daemon resolves at promotion time. |
+| `epic revoke <issue>` | project | Withdraw an epic's approval, so its children need a decision again. A no-op on an epic that was never approved, and it exits `0`: `revoke` states what is true afterwards, exactly as `drain cancel` does. |
+| `epic list [--json]` | project | Approved epics, issue-ascending: issue, when it was approved, and who approved it. `--json` emits `{ project, epics }`; the empty state is an empty array. Prints `no approved epics` in text mode when there are none. |
 | `daemon` | host | 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` | host | 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. |

package/agents/to-spec.md

@@ -29,15 +29,70 @@ Exactly one of these five strings, nothing else:
 - `ALREADY DONE` — the work already exists in the source (a later epic retired
   the issue's premise counts as done; prove it with the symbol/file, never the
   title).
-- `PROMOTABLE` — well-specified, fits one worker budget, and the acceptance
-  criteria are checkable; carries the proposed brief.
-- `NEEDS DECOMPOSITION` — the plan is real but too big for one budget; say what
-  slices it splits into and why each is a separate slice.
+- `PROMOTABLE` — well-specified, the acceptance criteria are checkable, and it
+  fits one worker budget *with the sizing evidence below to prove it*; carries
+  the proposed brief.
+- `NEEDS DECOMPOSITION` — the plan is real but does not fit one budget; carries
+  the ordered children it splits into and why each is its own slice.
 - `BLOCKED` — a named open prerequisite, lane, or credential gap stands in the
   way.
 - `NEEDS PRODUCT DECISION` — the issue cannot proceed until a human decides
   product shape, slice order, or scope; state the one question that unblocks it.
 
+## Sizing: the one-budget claim needs a falsifier
+
+`PROMOTABLE` asserts that one worker finishes this slice inside one attempt —
+a single session under the fleet's configured turn ceiling and its 90-minute
+wall clock, with continuations held in reserve for operational restarts and
+not for the rest of the work. That assertion is worth nothing on its own.
+Issue #1035 was groomed `PROMOTABLE` with nine acceptance criteria across four
+files; attempt 1 died at 181 of its 180 turns with the feature half-built. The
+verdict had claimed one-budget fit. What it never carried was evidence that
+could have falsified the claim.
+
+`sizingEvidence` is that evidence, read out of the source you just read:
+
+1. **The distinct behaviours.** Name each behaviour or state transition the
+   slice introduces — not each acceptance-criterion bullet. Two bullets about
+   one transition are one behaviour; one bullet hiding "create it, reconcile
+   it, clean it up" is three.
+2. **What each behaviour costs.** For every behaviour, the production module
+   that implements it and the focused test surface that proves it. A behaviour
+   whose proof needs a new integration harness costs far more than one an
+   existing unit test already reaches.
+3. **The sequencing between them.** Which behaviours write the same file, and
+   so cannot be discovered, implemented and re-proved independently inside one
+   session.
+4. **The conclusion.** Why that inventory fits one attempt — or, when it does
+   not, `NEEDS DECOMPOSITION`.
+
+**The multi-lifecycle shape is the one to refuse.** A candidate bundling core
+topology (creating the thing), lifecycle reconciliation (duplicate, live, dead
+and orphaned states converging) and daemon/restart integration (the same
+behaviour surviving a process restart) is three independently provable slices.
+That candidate is `NEEDS DECOMPOSITION` unless your verdict names the existing
+deep seam that already makes them one bounded change — a single reconciler
+both paths funnel through, say — by file and symbol. "They are related" is not
+a seam.
+
+**A small file count is not a small slice.** Four files can be 28,812 lines
+(that was #1035's own inventory) when they are high-fanout lifecycle modules
+with large integration suites. Weigh the fanout of what you touch and the size
+of the suites you must keep green, never the length of the write lane.
+
+No threshold decides this — not a line count, not a criterion count, not a
+file count. A threshold would be gamed by rewriting prose, and the sizes that
+matter are structural. The judgement is yours; the evidence is what makes it
+reviewable.
+
+**When it does not fit**, `decomposition` is a filing instruction and not a
+regret: the children in the order they must land, each with the title it would
+be filed under, the exact write lane it owns, what it waits on, the silent
+fake it invites and the commands that prove it. Two children writing the same
+core file must be serialised — the later one names the earlier in its
+dependencies — because two workers in one module is the collision the file
+lane exists to prevent.
+
 ## The return contract
 
 Answer in **one fenced JSON block, nothing else after it**. Every field is
@@ -46,10 +101,12 @@ required and no extra keys are accepted:
 - `verdict` — one of the five strings above.
 - `routing` — exactly one `owner/repo`, or `"MULTI"`.
 - `routingSplit` — required iff `routing` is `"MULTI"`: what each slice goes to.
-- `source` — `{ name, ref, freshAt }`: the authoritative source you read, the
-  exact ref, and `freshAt` = epoch milliseconds when you actually observed it.
-  Conductor refuses results whose source is older than 24 hours or missing
-  name/ref/freshAt — an unsourced verdict is not grooming, it is prose.
+- `source` — `{ name, ref }`: the authoritative source you read and the exact
+  ref you read it at. Conductor refuses a result that does not name both — an
+  unsourced verdict is not grooming, it is prose. Do not send a `freshAt`:
+  conductor stamps the observation time itself from the batch window and
+  refuses a batch whose window exceeds 24 hours, so inventing a timestamp is
+  neither required nor read (#1000).
 - `evidence` — the files/symbols that prove the verdict. Required for
   `ALREADY DONE`: name the symbol/file that already does the work, never a
   title match. Welcome on every other verdict.
@@ -69,6 +126,16 @@ required and no extra keys are accepted:
 - `fileLane` — the files and directories this slice writes.
 - `dependencies` — open prerequisite issue numbers, each a bare number
   (`875`) or a string (`"875"`); `[]` when none.
+- `sizingEvidence` — required iff `verdict` is `PROMOTABLE`: the one-budget
+  analysis from the sizing section above — the distinct behaviours, the
+  production module and focused test surface each one needs, the shared-file
+  sequencing between them, and why that fits one attempt.
+- `decomposition` — required iff `verdict` is `NEEDS DECOMPOSITION`, and
+  accepted on no other verdict: the ordered children, first to last. Each is
+  an object with `title`, `writeLane` (its exact write lane), `dependsOn` (an
+  earlier child's title or an existing issue number, `[]` for the first),
+  `likelySilentFake` and `proofCommands`. Children sharing a write-lane path
+  must serialise through `dependsOn`.
 - `proposedBrief` — required iff `verdict` is `PROMOTABLE`: the brief a worker
   would be dispatched with, including the silent fake and the proof commands.
 - `reasonNotToPromote` — required for every other verdict: why this must not
@@ -78,7 +145,7 @@ required and no extra keys are accepted:
 
 - **Prose is not evidence.** A verdict without the source-backed contract is
   refused as malformed: every field above is required, and `source` must name
-  the ref you read and when.
+  the ref you actually read.
 - **Stale source reads like good source.** Judge the candidate against the
   stated ref as it is now; a verdict drawn from memory of a different clone is
   stale and will be refused.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "omp-conductor",
-  "version": "0.19.7",
+  "version": "0.20.0",
   "type": "module",
   "license": "MIT",
   "description": "A 24/7 dispatcher that takes ready GitHub issues to green, mergeable PRs using omp coding sessions, with tiered escalation first to an orchestrator session and then to a human.",

package/schema/config.schema.json

@@ -184,6 +184,10 @@
               }
             ]
           },
+          "groomRole": {
+            "type": "string",
+            "pattern": "^[A-Za-z0-9][A-Za-z0-9._-]*$"
+          },
           "stateLabels": {
             "type": "object",
             "properties": {

package/src/arm-challenge.ts

@@ -1,48 +1,60 @@
 /**
  * Authenticated pending-challenge state for the arming handshake (conductor
- * #415, transaction reworked by #614, storage hardened by review of #896).
+ * #415, transaction reworked by #614, storage hardened by review of #896,
+ * targets recorded when the console took over verification in phase 1 of the
+ * orchestrator-workflow redesign).
  *
  * `armTicks` (fleet.ts) sends a short-lived `FLEET-…` code to the operator and
- * waits for the orchestrator to acknowledge it. The acknowledgement is
- * conductor-owned state: the orchestrator's inbound user-turn adapter
- * (orchestrator-tick.ts) writes it the moment the real reply arrives as a user
- * turn — never the model, and never a transcript scan, so the proof no longer
- * depends on where (or whether) a session file lives.
+ * files the challenge here. Verification is a second, mechanical CLI step:
+ * `omp-conductor arm --reply "<the operator's message>"` classifies the
+ * message against these records and arms the projects the challenge named.
  *
- * This module is the bridge between the two roles without an import cycle:
- * `fleet.ts` imports `daemon.ts`, `daemon.ts` imports `orchestrator-tick.ts`,
- * so `orchestrator-tick.ts` can never import `fleet.ts`. Both already import
- * `config.ts`, so the state lives next to the other state under `stateDir()`
- * and both sides reach it through *this* leaf module.
+ * Nothing waits for the reply any more. The console session owns the operator
+ * DM, and no tick extension runs there — so the in-session acknowledgement
+ * wait `armTicks` used to hold could never be satisfied. What survives is the
+ * durable half: the record that says which code is live, until when, and which
+ * projects it arms.
+ *
+ * This module stays a leaf so both roles can reach the state without an import
+ * cycle: `fleet.ts` imports `daemon.ts`, `daemon.ts` imports
+ * `orchestrator-tick.ts`, so `orchestrator-tick.ts` can never import
+ * `fleet.ts`. Everything here reads only `config.ts`.
  *
  * The handshake keeps no shared mutable state at all — every file is named by
  * its own key, and every deletion is id-addressed, so two processes can
  * neither lose each other's updates nor delete each other's proofs:
  *
  * - `arm-challenges/<project key>.json` — one pending challenge per project:
- *   `{ project, id, hash, sentAt, expiresAt }`. Host-owned: only `armTicks`
- *   writes it (record before the send, settle on consumption/timeout/send
- *   failure), always through the atomic tmp+rename write the admission ack
- *   uses. A re-armed project overwrites its own file — pruning only its own
- *   prior id's acknowledgement; a concurrent arm for a different project
- *   touches a different file.
+ *   `{ project, id, hash, sentAt, expiresAt, targets?, owner? }`. Host-owned:
+ *   only the arm ceremony writes it (record before the send, settle on
+ *   consumption or send failure), always through the atomic tmp+rename write
+ *   the admission ack uses. A re-armed project overwrites its own file —
+ *   pruning only its own prior id's acknowledgement; a concurrent arm for a
+ *   different project touches a different file.
  * - `arm-challenge-acks/<challenge id>.json` — one file per acknowledgement:
- *   `{ challengeId, acknowledgedAt }`. The adapter's acknowledgement is a
+ *   `{ challengeId, acknowledgedAt }`. The reply step's acknowledgement is a
  *   single-file create/overwrite via rename — it never reads or rewrites
- *   another transaction's record. Files that outlive their transaction (a
- *   crash between the adapter's write and the host's settle) are inert by
+ *   another transaction's record, and `doctor` reads it to report a handshake
+ *   that was answered but never settled. Files that outlive their transaction
+ *   (a crash between the acknowledgement and the settle) are inert by
  *   construction and removed only by age, never by membership in any
  *   directory snapshot (see {@link gcAgedAcks}).
  *
+ * `targets` is why the reply step never re-derives what to arm: the challenge
+ * the operator answered named specific projects, and the config could have
+ * changed between the send and the reply. Arming what the record says is the
+ * only reading that matches what the operator was asked. It is optional purely
+ * for backward tolerance — a record written before this field existed still
+ * verifies (see {@link resolveArmReply}).
+ *
  * Only the sha-256 of the code is ever persisted — never the code, whose
- * plaintext appearance in the protected session transcript is already the
- * backend proof and must not leak into a durable report, an issue comment, or
- * a diagnostic line the way a new artifact could. The id is a random UUID cut
- * with the challenge, so acknowledgement records are challenge-specific
- * without carrying anything guessable. Neither side trusts a `FLEET-` prefix:
- * a reply is classified by hashing its whitespace-separated tokens against
- * the pending record, so nothing on the east side of the boundary can arm a
- * fleet with a lookalike.
+ * plaintext appearance in the chat is the whole proof and must not leak into a
+ * durable report, an issue comment, or a diagnostic line the way a new
+ * artifact could. The id is a random UUID cut with the challenge, so
+ * acknowledgement records are challenge-specific without carrying anything
+ * guessable. No `FLEET-` prefix is ever trusted: a reply is classified by
+ * hashing its whitespace-separated tokens against the pending record, so no
+ * lookalike can arm a fleet.
  */
 
 import { createHash, randomUUID } from "node:crypto";
@@ -53,6 +65,21 @@ import { stateDir } from "./config.ts";
 const ARM_CHALLENGES_DIR = "arm-challenges";
 const ARM_ACKS_DIR = "arm-challenge-acks";
 
+/**
+ * One project a challenge arms: recorded with the challenge so the reply step
+ * arms exactly what the operator was asked about, never a re-derivation.
+ */
+export interface ArmTarget {
+  /**
+   * The configured project name, absent only for a legacy unstamped
+   * single-project fleet — the same value `resolveArmState` needs to decide
+   * whether the pre-per-project shared marker still speaks for this project.
+   */
+  project?: string;
+  /** The arm marker path this project's heartbeat reads. */
+  armedFile: string;
+}
+
 interface PendingChallenge {
   /** The project key this pending belongs to, mirrored for read-back checks. */
   project: string;
@@ -64,12 +91,24 @@ interface PendingChallenge {
   sentAt: number;
   /** Unix ms after which a matching reply is no longer an active proof. */
   expiresAt: number;
+  /**
+   * The projects this challenge arms. Absent on a record written before the
+   * field existed; callers fall back rather than crash.
+   */
+  targets?: ArmTarget[];
+  /**
+   * The chat the challenge was actually sent to, so the marker the reply step
+   * writes attributes the arm to the operator who was asked — not to whatever
+   * the paired channel happens to say minutes later. Absent on a pre-targets
+   * record.
+   */
+  owner?: string;
 }
 
 interface ArmAcknowledgement {
   /** The exact challenge id this record satisfies. */
   challengeId: string;
-  /** Unix ms the inbound adapter acknowledged the reply. */
+  /** Unix ms the reply step classified the operator's message as this proof. */
   acknowledgedAt: number;
 }
 
@@ -125,6 +164,31 @@ function writeFileAtomic(path: string, content: string): void {
   }
 }
 
+/**
+ * A recorded target list, validated element by element, or undefined when the
+ * record carries none. `invalid` is deliberately distinct from `absent`: a
+ * torn target list must fail the whole record closed (below) rather than
+ * silently degrade into the legacy fallback, which would arm a project the
+ * challenge may never have named.
+ */
+function readTargets(raw: unknown): { kind: "absent" } | { kind: "invalid" } | { kind: "ok"; targets: ArmTarget[] } {
+  if (raw === undefined) return { kind: "absent" };
+  if (!Array.isArray(raw) || raw.length === 0) return { kind: "invalid" };
+  const targets: ArmTarget[] = [];
+  for (const entry of raw) {
+    if (entry === null || typeof entry !== "object") return { kind: "invalid" };
+    const target = entry as { project?: unknown; armedFile?: unknown };
+    if (typeof target.armedFile !== "string" || target.armedFile.length === 0) return { kind: "invalid" };
+    if (target.project !== undefined && typeof target.project !== "string") return { kind: "invalid" };
+    targets.push(
+      target.project === undefined
+        ? { armedFile: target.armedFile }
+        : { project: target.project, armedFile: target.armedFile },
+    );
+  }
+  return { kind: "ok", targets };
+}
+
 /**
  * This project's pending challenge parsed from its own file, with every field
  * validated. Anything absent, torn, garbage, pre-#614, or naming another
@@ -144,11 +208,17 @@ function readPendingFor(key: string): PendingChallenge | undefined {
     pending.project !== key ||
     typeof pending.id !== "string" ||
     typeof pending.hash !== "string" ||
-    typeof pending.expiresAt !== "number"
+    typeof pending.expiresAt !== "number" ||
+    (pending.owner !== undefined && typeof pending.owner !== "string")
   ) {
     return undefined;
   }
-  return pending as PendingChallenge;
+  const targets = readTargets(pending.targets);
+  if (targets.kind === "invalid") return undefined;
+  return {
+    ...(pending as PendingChallenge),
+    ...(targets.kind === "ok" ? { targets: targets.targets } : {}),
+  };
 }
 
 /** sha-256 hex of the challenge code — the persisted token, never the code. */
@@ -182,14 +252,13 @@ export function looksLikeChallengeCode(token: string): boolean {
 
 /**
  * Acknowledgement files outliving their transaction — a crash between the
- * adapter's write and the host's settle — are inert by construction: no
- * waiter ever polls their id again, and ids are UUIDs, so no future
- * transaction can collide with one. They are therefore not swept by
- * membership (a directory listing captured before another process records is
- * stale the moment it is taken, and acting on it deletes on-time proofs),
- * only by age: a file older than {@link ACK_ORPHAN_GC_AFTER_MS} cannot belong
- * to a live handshake under any configured window, so its mtime alone decides
- * removal.
+ * classification and the settle — are inert by construction: nothing ever
+ * reads their id again, and ids are UUIDs, so no future transaction can
+ * collide with one. They are therefore not swept by membership (a directory
+ * listing captured before another process records is stale the moment it is
+ * taken, and acting on it deletes on-time proofs), only by age: a file older
+ * than {@link ACK_ORPHAN_GC_AFTER_MS} cannot belong to a live handshake under
+ * any configured window, so its mtime alone decides removal.
  */
 const ACK_ORPHAN_GC_AFTER_MS = 24 * 60 * 60 * 1000;
 
@@ -212,6 +281,17 @@ function gcAgedAcks(now: number): void {
   }
 }
 
+/**
+ * What a challenge arms, recorded with it: the projects the operator was told
+ * about and the chat they were asked in.
+ */
+export interface ArmChallengePlan {
+  /** Every project a matching reply arms — one for `arm --project X`, all of them for a fleet ceremony. */
+  targets: readonly ArmTarget[];
+  /** The chat the challenge is being sent to. */
+  owner: string;
+}
+
 /**
  * Register a new active arming challenge for the project — overwriting the
  * project's own pending file — and return the transaction id. Before the
@@ -219,18 +299,31 @@ function gcAgedAcks(now: number): void {
  * acknowledgement is pruned: project-local cleanup with no directory
  * snapshot, so another project's handshake cannot lose its proof here no
  * matter how the calls interleave.
+ *
+ * `plan` is optional only so the pre-targets call shape stays valid for the
+ * surfaces (doctor's fixtures, the CLI's own tests) that record a challenge
+ * without meaning to arm anything through the reply step. The ceremony always
+ * passes one.
  */
 export function recordArmChallenge(
   project: string | undefined,
   code: string,
   sentAt: number,
   expiresAt: number,
+  plan?: ArmChallengePlan,
 ): string {
   const key = projectKey(project);
   // Read the prior record BEFORE the overwrite shadows it.
   const prior = readPendingFor(key);
   const id = randomUUID();
-  const record: PendingChallenge = { project: key, id, hash: challengeHash(code), sentAt, expiresAt };
+  const record: PendingChallenge = {
+    project: key,
+    id,
+    hash: challengeHash(code),
+    sentAt,
+    expiresAt,
+    ...(plan === undefined ? {} : { targets: [...plan.targets], owner: plan.owner }),
+  };
   writeFileAtomic(pendingPath(key), `${JSON.stringify(record)}\n`);
   if (prior !== undefined) rmSync(ackPath(prior.id), { force: true });
   gcAgedAcks(sentAt);
@@ -238,35 +331,53 @@ export function recordArmChallenge(
 }
 
 /**
- * The inbound adapter's acknowledgement (conductor #614): classify the reply
- * against the project's non-expired pending challenge and, on a match,
- * atomically write the challenge-id-specific acknowledgement record the host
- * waits on. Returns whether the reply is an active arming proof, driving the
- * existing deterministic UX path.
- *
- * Writes only this challenge's own file — it never reads or rewrites any other
- * record — so a wrong token, wrong project, expired challenge, or a racing
- * host settle all fail closed without touching anyone else's handshake, and
- * two projects acknowledging concurrently cannot clobber each other.
- */
-/**
- * What an inbound reply was, so the adapter can answer it (#991).
+ * What a reply was, so the console can answer it (#991, retained now that the
+ * console — not a tick session — does the answering).
  *
- * Before this, a non-matching or expired code was simply ignored: the waiter
- * kept waiting and the operator had no idea they had been heard. The fastest
- * way to be sure you held the current code was to scroll the chat, which is
- * exactly the work conductor-owned verification was supposed to end.
+ * Before this, a non-matching or expired code was simply ignored: the operator
+ * had no idea they had been heard, and the fastest way to be sure you held the
+ * current code was to scroll the chat. That is exactly the work
+ * conductor-owned verification exists to end.
  *
  * - `matched` — an active proof; the acknowledgement is written.
  * - `expired` — a code that hashes to a pending record whose window has closed.
  * - `unknown` — a challenge-shaped token that matches nothing readable here.
- * - `none` — no challenge-shaped token at all: ordinary chat, answer nothing.
+ * - `none` — no challenge-shaped token at all: ordinary chat, arm nothing.
  */
 export type ArmReplyVerdict = "matched" | "expired" | "unknown" | "none";
 
+/** The transaction a matching reply proved, and what the challenge said it arms. */
+export interface ArmReplyMatch {
+  /**
+   * The state key the matched record lives under — a project key (possibly the
+   * empty key of an unstamped config) or {@link FLEET_ARM_KEY}. Passed straight
+   * back to {@link clearArmTransaction}, so the settle is addressed to the
+   * record that was actually consumed.
+   */
+  key: string;
+  /** The matched transaction's id; every deletion is addressed by it. */
+  id: string;
+  /**
+   * The projects the challenge recorded. Absent on a record written before
+   * targets existed — the caller falls back rather than crashing.
+   */
+  targets?: ArmTarget[];
+  /** The chat the challenge was sent to. Absent on a pre-targets record. */
+  owner?: string;
+}
+
 /**
- * Classify one inbound reply against this session's own records, writing the
- * acknowledgement on a match.
+ * Discriminated so a caller cannot reach for `match` on a verdict that has
+ * none: only `matched` carries the transaction, and only `matched` may write a
+ * marker.
+ */
+export type ArmReplyResolution =
+  | { verdict: "matched"; match: ArmReplyMatch }
+  | { verdict: Exclude<ArmReplyVerdict, "matched">; match?: undefined };
+
+/**
+ * Classify one operator reply against this host's own records and, on a match,
+ * write the challenge-id-specific acknowledgement.
  *
  * Two records are consulted and no others: this project's, and the fleet-wide
  * one (#991). That bound is the non-disclosure property — a reply that matches
@@ -274,25 +385,35 @@ export type ArmReplyVerdict = "matched" | "expired" | "unknown" | "none";
  * challenge, because no other project's record is ever read.
  *
  * Fail-closed ordering is unchanged: the project's own active challenge wins,
- * then the fleet ceremony, and an expired record is never a proof.
+ * then the fleet ceremony, and an expired record is never a proof. The write
+ * touches only the matched challenge's own file, so a wrong token, a wrong
+ * project, an expired challenge or a racing settle all fail closed without
+ * touching anyone else's handshake.
+ *
+ * The acknowledgement record is no longer something a waiter polls — nothing
+ * waits any more. It is kept because it is the only durable evidence that a
+ * reply was seen, which is what `doctor`'s `arm-ack` finding reports when a
+ * ceremony was answered but never settled.
  */
-export function classifyArmReply(
+export function resolveArmReply(
   project: string | undefined,
   replyText: string,
   now: number,
-): ArmReplyVerdict {
+): ArmReplyResolution {
   // Challenge codes contain no whitespace, so tokenising on whitespace never
   // splits one; empty replies simply yield no token.
   const tokens = replyText.trim().split(/\s+/).filter((token) => token.length > 0);
-  if (tokens.length === 0) return "none";
-  const candidates = [readPendingFor(projectKey(project)), readPendingFor(FLEET_ARM_KEY)].filter(
-    (pending): pending is PendingChallenge => pending !== undefined,
-  );
+  if (tokens.length === 0) return { verdict: "none" };
+  const candidates: { key: string; pending: PendingChallenge }[] = [];
+  for (const key of [projectKey(project), FLEET_ARM_KEY]) {
+    const pending = readPendingFor(key);
+    if (pending !== undefined) candidates.push({ key, pending });
+  }
 
   let expired = false;
   for (const token of tokens) {
     const hash = challengeHash(token);
-    for (const pending of candidates) {
+    for (const { key, pending } of candidates) {
       if (pending.hash !== hash) continue;
       if (now >= pending.expiresAt) {
         // Keep looking: a fresh record for the same code is a proof, and only
@@ -300,27 +421,25 @@ export function classifyArmReply(
         expired = true;
         continue;
       }
-      // Keyed by the challenge id, so replays overwrite the one record the
-      // single live waiter consumes; a stale id's file can never be created
-      // here.
+      // Keyed by the challenge id, so replays overwrite the one record this
+      // transaction owns; a stale id's file can never be created here.
       const record: ArmAcknowledgement = { challengeId: pending.id, acknowledgedAt: now };
       writeFileAtomic(ackPath(pending.id), `${JSON.stringify(record)}\n`);
-      return "matched";
+      return {
+        verdict: "matched",
+        match: {
+          key,
+          id: pending.id,
+          ...(pending.targets === undefined ? {} : { targets: pending.targets }),
+          ...(pending.owner === undefined ? {} : { owner: pending.owner }),
+        },
+      };
     }
   }
-  if (expired) return "expired";
-  // Shape only, and only to decide whether the operator gets an answer. A token
-  // that is not challenge-shaped is ordinary chat.
-  return tokens.some((token) => looksLikeChallengeCode(token)) ? "unknown" : "none";
-}
-
-/**
- * The inbound adapter's acknowledgement (conductor #614), kept as the boolean
- * the availability gate already reads. {@link classifyArmReply} is the same
- * pass with the non-matching cases named.
- */
-export function acknowledgeArmReply(project: string | undefined, replyText: string, now: number): boolean {
-  return classifyArmReply(project, replyText, now) === "matched";
+  if (expired) return { verdict: "expired" };
+  // Shape only, and only to decide how the operator is answered. A token that
+  // is not challenge-shaped is ordinary chat.
+  return { verdict: tokens.some((token) => looksLikeChallengeCode(token)) ? "unknown" : "none" };
 }
 
 /** The acknowledgement record for one exact challenge id, or undefined. */