omp-conductor 0.3.23 → 0.3.25

package/README.md

@@ -167,14 +167,20 @@ Also required on the host:
     dispatch is only defensible while a tier-2 page can reach a person.
   - **Approving a Learning-loop amendment from a heartbeat tick** needs one more
     setting than pairing: a notify destination. `/telegram notify` writes
-    `notifyMode` and `notifyChat` into the same `access.json`; `/telegram topics`
-    does it with a forum topic instead. omp-telegram mounts its `telegram_ask`
-    tool only for a turn that resolves a notify target, and a locally injected
-    tick resolves one only through that setting — so without it the orchestrator
-    can page you but cannot put a yes/no question in front of you, which is the
-    one thing the Learning loop's approval step requires. `omp-conductor status`
-    reports this on the `telegram` row, and a tick that finds the tool missing
-    says so in its own prompt and falls back to `telegram_send`.
+    `notifyMode` and `notifyChat` into the same `access.json`. omp-telegram
+    mounts its `telegram_ask` tool only for a turn that resolves a notify target,
+    and a locally injected tick resolves one only through that setting — so
+    without it the orchestrator can page you but cannot put a yes/no question in
+    front of you, which is the one thing the Learning loop's approval step
+    requires. `omp-conductor status` reports this on the `telegram` row, and a
+    tick that cannot ask says so in its own prompt and falls back to
+    `telegram_send`.
+
+    Set `notifyChat` even on a forum fleet. `/telegram topics` routes to a topic
+    this session claims at runtime, and that claim is not visible in
+    `access.json` — so a file carrying only `topicsChat` is reported as
+    unconfigured rather than guessed at, on the grounds that a health row which
+    reads green over a broken contract is worse than one that overstates a fault.
 
   With neither, tier 2 degrades to a comment on the issue. Nothing is broken in
   that configuration: it is supported, just slower to reach you.
@@ -611,7 +617,7 @@ Then, per admitted issue:
    | --- | --- | --- | --- |
    | `pushed-pending` | `agent:in-progress` stays while the daemon rechecks GitHub | removed | none |
    | `pushed-green` | `agent:in-progress` stays while the PR is open | removed | none |
-   | `blocked` | swapped to `agent:blocked` | removed | Tier 1 |
+   | `blocked` | swapped to `agent:blocked` | dirty tree committed to the branch, then removed | 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 |
 
@@ -624,18 +630,38 @@ Then, per admitted issue:
    leaves a window in which the issue carries no state label at all, which is
    exactly the shape eligibility reads as fresh work.
 
-   **A non-graceful end salvages the tree first.** A turns-cap kill, a
-   wall-clock kill and a crash are all external and unannounced: they land
-   mid-edit, and only the run's *branch* is preserved across attempts — the tree
-   is removed `--force` by the next one. So before the escalation is written,
-   a dirty tree is committed to the run's own branch as
-   `wip(#<issue>): attempt <n> killed by <reason> — auto-salvaged` (everything,
-   including files git has never seen) and pushed, and the escalation says where
-   it went: `WIP committed to <branch> @ <sha>`. A push that is refused leaves
-   the commit in this host's mirror and says so; a salvage that fails outright
-   says that, loudly, naming the tree that now holds the only copy. A `blocked`
-   run is deliberately *not* salvaged — it stopped on purpose, with turns still
-   in hand to commit for itself.
+   **Every continuable end salvages the tree first.** A turns-cap kill, a
+   wall-clock kill, a crash and a graceful block all leave a tree the next
+   attempt removes `--force` — only the run's *branch* is preserved across
+   attempts. So before the escalation is written, a dirty tree is committed to
+   the run's own branch as `wip(#<issue>): attempt <n> <ending> — auto-salvaged`
+   (everything, including files git has never seen) and pushed, and the
+   escalation says where it went: `WIP committed to <branch> @ <sha>`. A push
+   that is refused leaves the commit in this host's mirror and says so.
+
+   Blocking was excluded from this until #118, on the argument that a worker
+   which stops on purpose has turns left to commit for itself. It cost a
+   34-file refactor: the worker blocked to ask whether a failing test was
+   obsolete — which is precisely a worker declining to commit a half-migrated
+   tree — and the daemon removed the tree seconds later, leaving the run branch
+   and `origin/main` on the same commit. A `pushed-green` or `pushed-pending`
+   run is now the only end that does not salvage: its deliverable is already on
+   a remote branch, and appending a WIP commit would turn the PR the daemon
+   just verified red.
+
+   **A salvage that fails keeps the tree and stops the issue.** If git refuses
+   the commit, the worktree is the only copy in existence, so it is retained
+   whatever the run's outcome was, the row records the failure, and the issue
+   is held out of dispatch with the `unsalvaged-wip` reason — because claiming
+   it is what would finally destroy the tree. `status` shows it under `wip` as
+   `UNSALVAGED`, and `omp-conductor unblock <n>` refuses. Recover the tree by
+   hand, then `unblock <n> --force` records that you accepted it and releases
+   the hold.
+
+   **A preserved tip is named to the next worker.** The sha is written to the
+   run row, shown by `status` and the board, and the continuation brief tells
+   the resuming worker the exact commit it is building on and that it is the
+   only copy.
 
    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
@@ -714,12 +740,15 @@ Run history is untouched. A PR closed without merging becomes a concrete failed
 attempt; a merge does not spend failure or continuation budget. A settled row also
 loses `agent:in-progress` from its issue: the row transition and the label are one
 fact, and a terminal answer about the PR proves no worker process owns the issue,
-so the duplicate-dispatch guard it exists for is spent. Rows that did not settle
-keep the label, and a tracker that refuses the removal is logged rather than
-allowed to abort the sweep — `omp-conductor unblock` clears it by hand in that
-rare case. Anything beyond that one release — a re-queue, a `blocked` marker —
-is still the orchestrator's drain-duty judgement. One unreachable PR costs its own
-row and nothing else; the rest of the sweep still settles.
+so the duplicate-dispatch guard it exists for is spent. The label comes off
+*before* the row is written terminal, because this sweep is the only thing that
+revisits a `pushed-*` row: a tracker that refuses the removal therefore leaves the
+row pending and the next tick tries again, rather than stranding the label on an
+issue nothing will look at twice. The issue stays in the busy set while it waits,
+so nothing is dispatched onto it in between. Anything beyond that one release — a
+re-queue, a `blocked` marker — is still 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
@@ -1259,13 +1288,26 @@ start: the bridge is reconfigured out-of-band, and a heartbeat that trusted a
 startup snapshot would keep dispatching for days after the channel went away. A
 stale arm marker must not outlive the channel that makes running unattended safe.
 
-The check passes only when the file parses to an object with `enabled: true` and
-exactly one `allowFrom` entry. Everything else stops the heartbeat: file missing,
+The check passes only when a bot token is resolvable — `TELEGRAM_BOT_TOKEN` in
+the environment, or in the `.env` beside `accessFile` — and the file parses to an
+object with `enabled: true` and exactly one `allowFrom` entry. Everything else
+stops the heartbeat: no token, so nothing outbound works at all; file missing,
 unreadable or truncated; not JSON, or JSON that is not an object; `enabled`
 absent or false; zero owners paired (nobody to page) or more than one (ambiguous:
 the conductor refuses to guess which human is on the hook). Failure modes are
 deliberately not distinguished in the decision: each one means a page lands
-nowhere.
+nowhere. `omp-conductor status` is where they are told apart — its `telegram` row
+names the specific fault.
+
+One caveat the file cannot express: omp-telegram binds its own copy of the token
+in `startBot()` at session start, and only when the bridge is switched on. It
+rebinds only on `/telegram token` or `/telegram on`. So writing a token into
+`.env` out-of-band — or flipping `enabled` to true by hand — restores tier-2
+paging immediately, because conductor sends those itself, while the bridge's own
+tools, `telegram_send` and `telegram_ask`, stay dead until you reload it. After
+either edit, run `/telegram on` in the orchestrator session. Until you do, ticks
+carry an explicit note that an amendment cannot be approved on this surface, and
+the conductor never assumes an answer it did not receive.
 
 Leaving `accessFile` unset passes the gate, because an ordinary developer session
 that happens to have a `.conductor-tick.json` has no bridge to check. It is not an
@@ -1373,7 +1415,7 @@ 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 unblock <issue> [--force] [--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
@@ -1398,7 +1440,7 @@ omp-conductor help
 | `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>`. |
 | `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` comes off too, but only when the newest recorded run is terminal — that row is the proof no worker still owns the issue, so a live run keeps the label, and so does an issue with no run row at all. Run history remains intact: blocks consume the independent continuation budget, not failed implementation attempts. The output reports both budgets and warns when either will make the next tick escalate instead of dispatch. Exits `2` when the issue number is missing or malformed. |
+| `unblock <issue> [--force]` | Remove that issue's `blocked` and `failed` labels so an answered escalation can be claimed again. `agent:in-progress` comes off too, but only when the newest recorded run is terminal — that row is the proof no worker still owns the issue, so a live run keeps the label, and so does an issue with no run row at all. Run history remains intact: blocks consume the independent continuation budget, not failed implementation attempts. The output reports both budgets and warns when either will make the next tick escalate instead of dispatch. **Refuses, clearing nothing and exiting `3`, when the newest attempt's work could not be committed and its worktree is the only copy** — re-claiming removes that tree. `--force` records the operator's acceptance on the run row and then clears; the salvage failure stays in history. Exits `2` when the issue number is missing or malformed. |
 | `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. |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "omp-conductor",
-  "version": "0.3.23",
+  "version": "0.3.25",
   "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/src/approval-surface.ts

@@ -0,0 +1,253 @@
+/**
+ * Can a *locally injected* turn ask its operator a yes/no question?
+ *
+ * One predicate, shared by the tick that has to warn about the answer and the
+ * status row that has to report it, because two spellings of it would drift and
+ * the whole point is that the health line and the tick agree.
+ *
+ * It is deliberately a question about **configuration**, not about the mounted
+ * tool set, and that distinction is the correction to a first attempt that got
+ * it wrong. omp-telegram mounts `telegram_ask` in `before_agent_start` and
+ * removes it again in `agent_end` (`restorePromptTools`), so the tool exists
+ * only *during* a turn. Anything that looks at `getActiveTools()` between turns
+ * — which is exactly where a heartbeat composes its prompt — sees the base set
+ * and would report the tool missing on every tick, including a correctly
+ * configured fleet. A false alarm every interval is worse than no alarm: it
+ * trains the operator to ignore the line that is supposed to mean something.
+ *
+ * What actually decides the mounting is knowable ahead of the turn. omp-telegram
+ * resolves a prompt target from the turn's own `<telegram-message>` wrapper, or
+ * failing that from `notifyTarget()`, which needs `notifyMode` set to "away" or
+ * "always" *and* a destination it can reach. A locally injected tick never has a
+ * wrapper, so for ticks the predicate reduces to config keys readable before the
+ * turn starts — with one deliberate narrowing, documented at the destination
+ * check below: only `notifyChat` counts, because a forum topic depends on live
+ * per-session state no file can evidence.
+ *
+ * That is exactly what failed on 2026-08-09 06:17Z: the fleet's access.json had
+ * no `notifyMode`, so the locally injected tick could not ask the Learning-loop
+ * yes/no question the package floor requires — while the status line reported
+ * `telegram  ok  (@tbcoder_bot; inbound configured)` throughout (#114). A health
+ * row that stays green through a broken contract is worse than no row.
+ *
+ * The legacy `away: true` boolean counts: `loadAccess()` migrates it to
+ * `notifyMode: "away"` on read, so a fleet still carrying it resolves a target
+ * and must not be reported as broken.
+ */
+
+import { readFileSync } from "node:fs";
+import { dirname, join } from "node:path";
+
+/** The tool the package floor names for the Learning-loop yes/no amendment
+ *  approval (`## Learning loop`, step 2, in `briefs/orchestrator.md`). Held as
+ *  a constant because the prose that tells a turn to call it and the check that
+ *  says whether it can be called must name the same thing. */
+export const TELEGRAM_APPROVAL_TOOL = "telegram_ask";
+
+export type ApprovalSurface = { kind: "ready" } | { kind: "missing"; reason: string };
+
+/** One checked read of a JSON property, so nothing below asserts a shape the
+ *  parse never proved. Anything that is not a plain object, or a key that is
+ *  absent, answers undefined — which every caller here already treats as
+ *  "unconfigured". */
+function field(value: unknown, key: string): unknown {
+  if (value === null || typeof value !== "object" || Array.isArray(value)) return undefined;
+  return Object.hasOwn(value, key) ? Reflect.get(value, key) : undefined;
+}
+
+/**
+ * Whether omp-telegram would find a bot token — its rule, not a reasonable one.
+ *
+ * This gates the heartbeat, so it has to predict another package's answer, and
+ * anywhere it is more generous than that package the gate fails *open*: it would
+ * report a token, let the tick fire, and leave the fleet dispatching with an
+ * outbound channel that never worked. So it mirrors `resolveToken()` in
+ * omp-telegram's `access.ts` exactly — process environment first, then the first
+ * line of `<state dir>/.env` matching `/^TELEGRAM_BOT_TOKEN=(.*)$/` after a
+ * trim, first match winning even when its value is empty.
+ *
+ * That regex is deliberately strict where a dotenv reader would not be:
+ * `export TELEGRAM_BOT_TOKEN=…` and `TELEGRAM_BOT_TOKEN = …` are both files
+ * omp-telegram reads no token from, so both must close this gate.
+ *
+ * `escalate.ts` parses the same file more permissively on purpose, and the two
+ * are not a contradiction to be tidied away: that one asks "can *conductor* send
+ * a page with this", and it can, because it does the parsing and the request
+ * itself. This one asks "will *omp-telegram* have a token", and only omp-telegram
+ * decides that.
+ */
+export function hasBotToken(stateDir: string): boolean {
+  const fromEnv = process.env["TELEGRAM_BOT_TOKEN"];
+  if (fromEnv !== undefined && fromEnv.length > 0) return true;
+  let raw: string;
+  try {
+    raw = readFileSync(join(stateDir, ".env"), "utf8");
+  } catch {
+    return false;
+  }
+  for (const line of raw.split("\n")) {
+    const match = /^TELEGRAM_BOT_TOKEN=(.*)$/.exec(line.trim());
+    if (match === null) continue;
+    // First match wins even when empty, exactly as `resolveToken()` returns on
+    // its first hit — a file whose first token line is blank has no token, and
+    // reading past it would disagree with the package this predicts.
+    return (match[1] ?? "").length > 0;
+  }
+  return false;
+}
+
+/**
+ * Whether omp-telegram would have *bound* a token, which is what its own tools
+ * depend on and is strictly narrower than the token existing.
+ *
+ * `startBot()` is the only thing that assigns `token`, and `session_start` calls
+ * it only when the bridge is switched on:
+ *
+ * ```js
+ * if (pi.getFlag("telegram") === true || process.env.OMP_TELEGRAM === "1" || access.enabled) await startBot(ctx);
+ * ```
+ *
+ * So a token sitting beside a bridge that was disabled at start was never
+ * picked up, and flipping `enabled` to true in the file afterwards does not pick
+ * it up either — only `/telegram on` or a restart does. Both halves therefore
+ * have to be true *at the same moment*, which is why this is sampled once rather
+ * than re-read.
+ *
+ * `pi.getFlag("telegram")` is omp's own launch flag and is not visible to this
+ * extension, so a session started with it but with `enabled: false` on disk
+ * reads as unbound here. That is the conservative direction: the cost is a
+ * fallback instruction the orchestrator can carry out, against an amendment
+ * recorded as approved that nobody answered.
+ */
+export function bridgeTokenBound(accessPath: string): boolean {
+  if (!hasBotToken(dirname(accessPath))) return false;
+  if (process.env["OMP_TELEGRAM"] === "1") return true;
+  let access: unknown;
+  try {
+    access = JSON.parse(readFileSync(accessPath, "utf8"));
+  } catch {
+    return false;
+  }
+  return field(access, "enabled") === true;
+}
+
+/** Reads the omp-telegram access file and answers whether a locally injected
+ *  turn would resolve an answerable destination.
+ *
+ *  A bot token is *not* checked here, deliberately: without one nothing outbound
+ *  works at all, so it is a whole-channel fault rather than an approval-surface
+ *  one. Both callers settle it first — the tick through its escalation-channel
+ *  gate, which refuses to fire at all, and `probeTelegramHealth` through a
+ *  `getMe` that has already succeeded. This function is only ever asked about a
+ *  bridge that can send. Never throws: an unreadable or malformed file is a
+ *  missing surface with the path named, not an exception taken out of a
+ *  heartbeat. */
+export function readApprovalSurface(path: string): ApprovalSurface {
+  let access: unknown;
+  try {
+    access = JSON.parse(readFileSync(path, "utf8"));
+  } catch {
+    return { kind: "missing", reason: `${TELEGRAM_APPROVAL_TOOL} unavailable on local ticks: cannot read ${path}` };
+  }
+  if (access === null || typeof access !== "object" || Array.isArray(access)) {
+    return {
+      kind: "missing",
+      reason: `${TELEGRAM_APPROVAL_TOOL} unavailable on local ticks: ${path} is not an object`,
+    };
+  }
+  const mode = field(access, "notifyMode");
+  const active = mode === "away" || mode === "always" || field(access, "away") === true;
+  if (!active) {
+    return {
+      kind: "missing",
+      reason:
+        `${TELEGRAM_APPROVAL_TOOL} unavailable on local ticks: no notifyMode in ${path} — ` +
+        `set it to "always" and set notifyChat to the paired owner id`,
+    };
+  }
+  // Only `notifyChat` counts, and `topicsChat` deliberately does not, even
+  // though omp-telegram can resolve a forum topic. `notifyTarget()` is handed a
+  // topic destination only when `ownTopic && access.topicsChat`, and `ownTopic`
+  // is per-session runtime state — the thread this process actually claimed —
+  // assigned during topic setup and cleared on failure. A file cannot prove it.
+  // So a fleet carrying `topicsChat` alone may or may not have the tool mounted,
+  // and this check answers the safe way: #114 exists because a health signal
+  // said "ok" through a broken contract, and repeating that with a stale
+  // `topicsChat` would be the same bug wearing a different key. `notifyChat` is
+  // resolvable from the file alone, so it is what "configured" means here.
+  const destination = field(access, "notifyChat");
+  if (typeof destination !== "string" || destination.length === 0) {
+    const topicsChat = field(access, "topicsChat");
+    const viaTopic =
+      typeof topicsChat === "string" && topicsChat.length > 0
+        ? " — topicsChat only resolves once this session has claimed its forum topic, which this file cannot show"
+        : "";
+    return {
+      kind: "missing",
+      reason:
+        `${TELEGRAM_APPROVAL_TOOL} unavailable on local ticks: notifyMode is set but ${path} names no notifyChat` +
+        `${viaTopic} — set notifyChat to the paired owner id`,
+    };
+  }
+
+  // Naming a destination is not the same as being able to answer in it, and
+  // `buildPromptTarget()` applies two more gates before a target exists. Both
+  // are decidable from this file, so both belong here — a `ready` that skipped
+  // them would say the approval works while a stale or wrong chat id silently
+  // reproduces #114.
+  //
+  // First, `pairedOwnerId()` is the single entry of `allowFrom`; anything else
+  // yields no responder and therefore no target.
+  const allowFrom = field(access, "allowFrom");
+  const owner = Array.isArray(allowFrom) && allowFrom.length === 1 ? String(allowFrom[0]) : undefined;
+  if (owner === undefined) {
+    return {
+      kind: "missing",
+      reason:
+        `${TELEGRAM_APPROVAL_TOOL} unavailable on local ticks: ${path} has no single paired owner in allowFrom, ` +
+        "so no one is authorised to answer",
+    };
+  }
+
+  // Then `canAnswerPrompt()`, which is the same DM/group policy inbound turns
+  // use. `isDmChat()` calls anything not starting with "-" a DM, and a DM only
+  // authorises the owner's *own* chat — a DM chat id equals its user id, so a
+  // notifyChat pointing at any other person is unanswerable by the paired owner.
+  if (!destination.startsWith("-")) {
+    if (destination !== owner) {
+      return {
+        kind: "missing",
+        reason:
+          `${TELEGRAM_APPROVAL_TOOL} unavailable on local ticks: notifyChat ${destination} in ${path} is a DM that ` +
+          `is not the paired owner's (${owner}), and only the owner's own DM authorises an answer — ` +
+          "set notifyChat to the paired owner id",
+      };
+    }
+    return { kind: "ready" };
+  }
+
+  // A group destination needs a policy entry, and that policy must admit the
+  // owner: an empty or absent `allowFrom` means everyone in the group, else the
+  // owner has to be listed.
+  const policy = field(field(access, "groups"), destination);
+  if (policy === null || typeof policy !== "object") {
+    return {
+      kind: "missing",
+      reason:
+        `${TELEGRAM_APPROVAL_TOOL} unavailable on local ticks: notifyChat ${destination} in ${path} is a group with ` +
+        "no entry under groups, so no answer from it is authorised",
+    };
+  }
+  const groupAllow = field(policy, "allowFrom");
+  const admitted =
+    !Array.isArray(groupAllow) || groupAllow.length === 0 || groupAllow.map(String).includes(owner);
+  if (!admitted) {
+    return {
+      kind: "missing",
+      reason:
+        `${TELEGRAM_APPROVAL_TOOL} unavailable on local ticks: group ${destination} in ${path} does not admit the ` +
+        `paired owner (${owner}) in its allowFrom, so their answer would be rejected`,
+    };
+  }
+  return { kind: "ready" };
+}

package/src/board.ts

@@ -418,7 +418,12 @@ function runCardLines(run: RunRecord, snapshot: BoardSnapshot): string[] {
     `attempt ${run.attempt} · ${run.turns}/${run.maxTurns}t`,
     `$${run.spendUsd.toFixed(2)} · ${duration}`,
   ];
-  if (run.state === "pushed-pending") lines.push("checks pending");
+  // Ordered by what needs a human first. An unsalvaged tree outranks even a
+  // last error: the error describes a run that is over, the tree is work that
+  // is still at risk and an issue that will not dispatch (#118).
+  if (run.salvageError !== undefined && run.salvageAckAt === undefined) lines.push("UNSALVAGED WIP");
+  else if (run.state === "pushed-pending") lines.push("checks pending");
+  else if (run.salvageSha !== undefined) lines.push(`wip @ ${run.salvageSha.slice(0, 7)}`);
   else if (run.lastError !== undefined) lines.push(run.lastError.replace(/\s+/g, " "));
   else if (run.prUrl !== undefined) lines.push(run.prUrl.replace(/^https?:\/\//, ""));
   else lines.push(run.branch);

package/src/briefs/orchestrator.md

@@ -125,6 +125,14 @@ which in its output: a run that is genuinely still live, where declining is the
 correct answer, and no run row at all to prove the worker is gone. In that second
 case, escalate the stuck issue rather than editing its labels.
 
+`unblock` refuses outright, clearing nothing, when the newest attempt's work
+could not be committed and its worktree is the only copy of it — re-claiming the
+issue force-removes that tree. Its output names the directory and offers
+`--force`. **`--force` is never yours to pass.** It records that a human
+inspected the tree and accepted the loss, which is a judgement about work you
+cannot see, and the daemon has already paged the operator about it. Report the
+refusal and move on to the next issue.
+
 Never leave an orphan holding a slot "to be safe": a label nobody is working under
 is not safety, it is a deadlocked fleet that looks busy.
 

package/src/cli.ts

@@ -94,7 +94,7 @@ usage:
   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 unblock <issue> [--force] [--project NAME]
   omp-conductor daemon [--once] [--port N] [--project NAME]
   omp-conductor pause
   omp-conductor resume
@@ -150,6 +150,9 @@ usage:
            and why the brief's "never hand-edit a state label" rule can stay
            absolute. Run history is kept; answered blocks consume the separate
            operational-continuation budget, not failed implementation attempts.
+           Refuses when the newest attempt's work could not be committed and
+           its worktree is the only copy: re-claiming removes that tree. Use
+           --force once you have recovered it or accepted the loss.
   friction record a bounded observation the daemon cannot classify itself:
            an escalation that belonged in a digest, or a tick report that was
            noise/surprising. Repeated observations feed the existing Learning
@@ -636,8 +639,12 @@ try {
       const project = findProject(cfg, flag(argv, "project"));
       const store = openStore(dbPath());
       try {
-        const outcome = await unblockIssue(project, makeTracker(project), store, issue);
+        const outcome = await unblockIssue(project, makeTracker(project), store, issue, {
+          force: argv.includes("--force"),
+        });
         process.stdout.write(`${formatUnblock(issue, outcome, project, resolveCaps(project, cfg.defaults))}\n`);
+        // A refusal must not read as success to a script or a board keypress.
+        if (outcome.refused !== undefined) process.exitCode = 3;
       } finally {
         store.close();
       }