@lumoai/cli 1.60.0 → 1.62.0

package/assets/skill/SKILL.md

@@ -145,7 +145,7 @@ The command catalog below is a **map**: it lists every command grouped by domain
 - `lumo milestone summary [--retry]` — AI retro
 - `lumo milestone changelog <id> [--json]` — structured changelog from DONE tasks + merged PRs + frozen claimSnapshot (pure assembly, no LLM; runs on any status). Headline counts carry a baseline vs prior completed milestones (LUM-508); each claim shows provenance, no-PR/no-claim rendered explicitly (LUM-649)
 - `lumo milestone reorder/move` — manual ordering
-- `lumo milestone criteria set/list/verdict` — milestone-level **exit criteria** (LUM-643): the close contract, drafted & adjudicated (裁定) by the steward (LUM-640) or a human. Unresolved criteria (pending or NOT_MET) block `--status completed` **and** the LUM-624 auto-rollup with 409/fail-closed; human override is web-only (`?force=1`, stamped as a persistent trail). `verdict --met` on `EXTERNAL_FACT` requires `--evidence` (422); `PENDING_OUTCOME` can never be MET
+- `lumo milestone criteria set/list/verdict` — milestone-level **exit criteria** (LUM-643): the close contract, drafted & adjudicated (裁定) by the steward (LUM-640) or a human. Unresolved criteria (pending or NOT_MET) hold the LUM-714 derived completion fail-closed (no `completedAt`, no retro); human override is web-only, stamped as a persistent trail. `verdict --met` on `EXTERNAL_FACT` requires `--evidence` (422); `PENDING_OUTCOME` can never be MET
 
 ### Documents — CRUD/sharing → [docs.md](references/docs.md); **editing live docs** (raw/section/patch/append/diff/rebuild) → [doc-editing.md](references/doc-editing.md)
 

package/assets/skill/references/confirmation.md

@@ -98,12 +98,13 @@ What the CLI does instead: when `task update <id> --status done --confirm` is re
 }
 ```
 
-| Field         | Meaning                                                                                                                                                                                                                                                                                                        |
-| ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `message`     | The server's 409 text, verbatim.                                                                                                                                                                                                                                                                               |
-| `blockers`    | One entry per item holding the gate: `SEND_BACK` (criterionId, statement, failedAtRound, rejectionReason), `BOUNDARY_CROSSING` (id, severity, category, detail), `SECURITY_FINDING` (findingId, severity, ruleId, filePath, line, prNumber, statement). Built from the same read models as `lumo task status`. |
-| `unconfirmed` | Enrichment reads that failed (`boundary-crossings read failed: HTTP 500`). Non-empty means the blocker list may be incomplete — it never silently shrinks.                                                                                                                                                     |
-| `remediation` | One line per blocker kind present, naming only human-side, append-only or user-approved paths: re-run `lumo verify`, `lumo crossing explain`, `lumo crossing disposition` (exit-4 envelope, the user rules), fix-and-push, the web disposition panel. Never a ready-to-run approval flag.                      |
+| Field         | Meaning                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
+| ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `message`     | The server's 409 text, verbatim.                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
+| `blockers`    | One entry per item holding the gate: `SEND_BACK` (criterionId, statement, failedAtRound, rejectionReason), `BOUNDARY_CROSSING` (id, severity, category, detail), `SECURITY_FINDING` (findingId, severity, ruleId, filePath, line, prNumber, statement). Built from the same read models as `lumo task status`. A `BOUNDARY_CROSSING` entry appears only for crossings the server gate counts (LUM-771): advisory crossings never, and with the workspace gate off only HIGH ones. |
+| `nonBlocking` | Open crossings the gate does NOT count (id, severity, category, detail, advisory) — awareness only; do not ask the user to disposition them to get past DONE_BLOCKED. Rendered as a separate `Also open, not blocking DONE` list in the terminal (LUM-771).                                                                                                                                                                                                                       |
+| `unconfirmed` | Enrichment reads that failed (`boundary-crossings read failed: HTTP 500`). Non-empty means the blocker list may be incomplete — it never silently shrinks.                                                                                                                                                                                                                                                                                                                        |
+| `remediation` | One line per blocker kind present, naming only human-side, append-only or user-approved paths: re-run `lumo verify`, `lumo crossing explain`, `lumo crossing disposition` (exit-4 envelope, the user rules), fix-and-push, the web disposition panel. Never a ready-to-run approval flag.                                                                                                                                                                                         |
 
 **Exit 4 vs exit 5:** 4 means "the user must approve, then you can proceed"; 5 means "a human must adjudicate — nothing on this command moves it". On exit 5, relay `blockers` and `remediation` to the user. Do not retry `task update`, do not look for a flag on it, and do not reword or delete a failed criterion to get past a send-back (that is tampering and is audited). For a `BOUNDARY_CROSSING` blocker the adjudication can happen in the terminal — `lumo crossing disposition <id> …` is itself an exit-4 command, so the user's ruling still comes through the protocol, never from you. Once every blocker is cleared, re-run the original `task update … --confirm` (its envelope was already approved). A 409 that is not a DONE gate (e.g. a permission refusal) keeps the plain exit-1 text on stderr.
 

package/assets/skill/references/milestones.md

@@ -28,7 +28,7 @@ Use `--search <text>` to filter to milestones whose **name or description** cont
 - `ON-TRACK` — on schedule (or all tasks done)
 - `AT-RISK` — completion lags elapsed time, or (no start date) the target is within ~7 days with work remaining
 - `OVERDUE` — past the target date with tasks still open
-- `-` — no light applies (status `COMPLETED`/`CANCELLED`, or no target date)
+- `-` — no light applies (the milestone is completed or archived, or has no target date)
 
 ```bash
 lumo milestone list                  # one-project workspace (non-archived only)
@@ -71,9 +71,9 @@ On success: `Created milestone "Q3 Launch"  <id>`.
 
 Accepts UUID or name. With a name, `--project <ref>` is required when the workspace has >1 project.
 
-Prints a key:value header (name, status, **health**, dates, project, description), task counts, and the full task table under the milestone. The `Health:` line shows the same target-date risk light as `milestone list` (`ON-TRACK` / `AT-RISK` / `OVERDUE`, or `-` when none applies).
+Prints a key:value header (name, state, **health**, dates, project, description), task counts, and the full task table under the milestone. The `Health:` line shows the same target-date risk light as `milestone list` (`ON-TRACK` / `AT-RISK` / `OVERDUE`, or `-` when none applies).
 
-**Staleness hints (LUM-624):** the `Status:` line is annotated `(stale — task progress indicates <STATUS>; auto-updating)` when the stored status lags the task-derived one (the server self-heals the drift in the background — a re-read shows the corrected status), and the `Target:` line is annotated `(no target date — schedule health unavailable)` for an in-flight milestone with no target date.
+**Staleness hints (LUM-624/LUM-714):** the `State:` line is annotated `(stale — task progress indicates completed|active; auto-updating)` when the stored `completedAt` disagrees with the task counts (the server self-heals the drift in the background — a re-read shows the corrected state), and the `Target:` line is annotated `(no target date — schedule health unavailable)` for an in-flight milestone with no target date.
 
 It also prints a **Sprint coverage** section (above the task table) listing which
 sprints the milestone's tasks span — each row shows the sprint number, status, name,
@@ -111,7 +111,6 @@ lumo milestone show 11111111-2222-3333-4444-555555555555
 | `--project <ref>`      | string | Required when identifier is a name and workspace has >1 project.               |
 | `-n, --name <text>`    | string | Cannot be empty.                                                               |
 | `-d, --description <>` | string | `--description ""` clears.                                                     |
-| `-s, --status <value>` | enum   | `planned \| active \| completed \| cancelled`.                                 |
 | `--start <date>`       | string | `--start ""` clears.                                                           |
 | `--target <date>`      | string | `--target ""` clears.                                                          |
 | `--token-budget <n>`   | int    | Advisory token budget (LUM-644), positive integer; `--token-budget ""` clears. |
@@ -122,12 +121,16 @@ At least one field required.
 
 **When to suggest**: when the user wants to cap/track token spend on a milestone ("给这个 milestone 设 token 预算 / budget"), or asks why the Overview shows an over-budget alert.
 
-**Status rolls up automatically (LUM-624):** milestone status follows task completion — PLANNED → ACTIVE when any task starts, → COMPLETED when every task is DONE (stamps `completedAt`, triggers the retro summary), and COMPLETED → ACTIVE when a non-DONE task (re)appears. A manual `--status planned/active/completed` that contradicts task reality gets reconciled back on the next task event or detail read; `--status cancelled` and archived milestones are human terminal choices the rollup never touches. You normally don't need `--status completed` by hand anymore.
+**There is no status flag — state is derived (LUM-714).** A milestone is `active`, `completed`, or `archived`, and only one of those is a choice:
 
-**The close is gated by exit criteria (LUM-643):** when the milestone has exit criteria (see `milestone criteria` below), any row not adjudicated MET — unadjudicated (PENDING) **or** NOT_MET — refuses `--status completed` with **409**, and holds the LUM-624 auto-rollup fail-closed (all tasks DONE keeps the milestone ACTIVE, no retro fires). There is **no CLI/agent override**: the only escape hatch is a human closing via the web with an explicit override (`?force=1` + optional note), stamped on the milestone as a persistent trail (`completedOverride*` — who/when/note, never auto-cleared). To open the gate legitimately, adjudicate the contract with `lumo milestone criteria verdict`.
+- **completed** follows task completion. Every task DONE → the rollup stamps `completedAt` and triggers the retro summary; a non-DONE task (re)appearing clears the stamp. Nothing you can pass to `update` moves it.
+- **archived** is the one explicit human state (`milestone archive` / `unarchive`). Archived milestones are left alone by the rollup and hidden from the default list.
+
+The old `PLANNED` / `ACTIVE` split is gone — a milestone whose tasks have not started is simply active — and `CANCELLED` is expressed by archiving (a milestone archived while incomplete reads as dropped, not delivered).
+
+**The close is gated by exit criteria (LUM-643):** when the milestone has exit criteria (see `milestone criteria` below), any row not adjudicated MET — unadjudicated (PENDING) **or** NOT_MET — holds the LUM-714 derived completion fail-closed: all tasks DONE leaves the milestone active, `completedAt` unstamped, no retro. There is **no CLI/agent override**: the only escape hatch is a human overriding via the web (`POST /api/milestones/<id>/close-override`, Clerk identity only), stamped on the milestone as a persistent trail (`completedOverride*` — who/when/note, never auto-cleared). To open the gate legitimately, adjudicate the contract with `lumo milestone criteria verdict`.
 
 ```bash
-lumo milestone update "Q3 Launch" --status active
 lumo milestone update "Q3 Launch" --target 2026-09-15
 lumo milestone update "Q3 Launch" --description ""
 lumo milestone update "Q3 Launch" --token-budget 50000000
@@ -162,7 +165,7 @@ lumo milestone criteria set "Q3 Launch" --file exit-criteria.json --human
 
 ### `lumo milestone criteria list <identifier>` — print the exit contract
 
-One line per criterion — `<id>  [MET|NOT_MET|PENDING]  SOURCE ⟨REFERENT⟩  statement` — plus an indented `↳` detail line (date · evidence · note) for adjudicated rows, and a trailing gate-state line: either `All exit criteria MET — the close gate is open.` or `N unresolved (pending or NOT_MET) — the close gate refuses status→COMPLETED until adjudicated (human override only via web).`
+One line per criterion — `<id>  [MET|NOT_MET|PENDING]  SOURCE ⟨REFERENT⟩  statement` — plus an indented `↳` detail line (date · evidence · note) for adjudicated rows, and a trailing gate-state line: either `All exit criteria MET — the close gate is open.` or `N unresolved (pending or NOT_MET) — the close gate withholds the derived completion until adjudicated (human override only via web).`
 
 ```bash
 lumo milestone criteria list "Q3 Launch"
@@ -189,7 +192,7 @@ lumo milestone criteria verdict "Q3 Launch" cmexit0002 --unmet --note "read mode
 ### When to suggest `milestone criteria`
 
 - A steward session planning a milestone ("what does done mean for this milestone", "draft exit criteria") → `criteria set`.
-- Before recommending `milestone update --status completed`, or when it just bounced with 409 → `criteria list` to see what holds the gate, then `verdict` per criterion.
+- When a milestone's tasks are all DONE but it has not completed → `criteria list` to see what holds the gate, then `verdict` per criterion.
 - User asks "can we close this milestone / what's blocking the close" → `criteria list` (the gate-state line answers it).
 
 ### `lumo milestone delete <identifier>` — delete a milestone
@@ -287,7 +290,7 @@ Agent-Native Milestones: 1 marked claimable, 1 skipped
 
 Prints the AI-generated retrospective summary for a milestone (mirrors `sprint summary`). `<identifier>` accepts a milestone name or UUID; `--project <ref>` is required when the identifier is a name and the workspace has more than one project. When no summary exists yet the command prints `(no summary generated yet)`.
 
-A summary is generated automatically when a milestone transitions to `COMPLETED` (e.g. via `lumo milestone update <id> --status completed`). The generated report has sections `## Summary`, `## Delivered`, `## Outstanding` plus a one-line `tldr`. Use `--retry` to queue regeneration (e.g. after a failed generation) before fetching — regeneration is async, so the printed result may still be the previous summary or `(no summary generated yet)`.
+A summary is generated automatically when a milestone completes (the LUM-714 derived transition: its last open task turns DONE, with the exit-criteria gate open). The generated report has sections `## Summary`, `## Delivered`, `## Outstanding` plus a one-line `tldr`. Use `--retry` to queue regeneration (e.g. after a failed generation) before fetching — regeneration is async, so the printed result may still be the previous summary or `(no summary generated yet)`.
 
 | Flag              | Type    | Notes                                                                                                  |
 | ----------------- | ------- | ------------------------------------------------------------------------------------------------------ |
@@ -304,7 +307,7 @@ When to suggest: user asks "summarize the milestone", "milestone retro", "give m
 
 ### `lumo milestone changelog <identifier> [--project <ref>] [--json]` — structured changelog (LUM-649)
 
-Assembles a **structured changelog** from the milestone's **DONE tasks + merged PRs + frozen claimSnapshot**. Pure deterministic assembly — **no LLM**, and (unlike `summary`) **no COMPLETED gate**: it runs on a milestone of any status, so an ACTIVE milestone reports "what has shipped so far". Only DONE tasks ever appear. `<identifier>` accepts a milestone name or UUID; `--project <ref>` is required when the identifier is a name and the workspace has >1 project.
+Assembles a **structured changelog** from the milestone's **DONE tasks + merged PRs + frozen claimSnapshot**. Pure deterministic assembly — **no LLM**, and (unlike `summary`) **no completion gate**: it runs on a milestone in any state, so an active milestone reports "what has shipped so far". Only DONE tasks ever appear. `<identifier>` accepts a milestone name or UUID; `--project <ref>` is required when the identifier is a name and the workspace has >1 project.
 
 Honest-reporting contract (why this is more than a task list):
 

package/assets/skill/references/verify.md

@@ -145,9 +145,10 @@ what's unmet and why (the exact failure tails), and how many rounds are left.
 - **Next actions** — the unmet criteria (latest verdict is not a pass: failed or never verified, HUMAN ones included) followed by any **undispositioned PR security findings** (LUM-737) as `• [SECURITY] [SEVERITY] PROVENANCE ruleId — file:line — title (PR #n · blocks DONE | advisory[ — <cause>, downgraded])`. The trailing **downgrade cause** appears only on deterministic `secret:*` rows the scanner lowered to LOW — `placeholder value` (the matched string looks like `…EXAMPLE`, `YOUR_…`, `CHANGEME`…) or `test/fixture/doc path`. Downgrading is **not** suppression: the row is still reported so a human decides, and the cause is what lets you tell a recognised test fixture from a real leak without opening the file. Absent on rows scanned before the cause was recorded, and on any row that was not downgraded — silence means "not downgraded", never "cause unknown". This list IS the plan — recomputed from the event log + the latest scan per linked PR on every read, never maintained separately. The header counts them separately: `Next actions (N unmet · M security findings)`. A finding is **not** a criterion: fix it and push (a fixed fingerprint disappears from the next scan) or a human dispositions it in the web delivery panel — there is no CLI path to clear one, and a `blocks DONE` finding refuses DONE with 409. Empty + rounds recorded = awaiting human adjudication.
   - **Per-PR scan status** (LUM-735): before the unconfirmed-PR lines, one line per linked PR that has a latest scan (open or closed alike): `PR #945 · scan CLEAN · Secrets: checked · Code scan: checked (2 external findings) · Dependencies: checked (1 dependency finding, 1 already on main) · AI review: checked · Exploit paths: ⚠ incomplete` — stage segments only for keys present, in secrets/external/supplyChain/judge/hunt order. **The stage keys are internal; what prints is their display label** (LUM-763, `shared/src/security-scan.ts`, shared with the GitHub PR summary so the two cannot drift): `secrets`→Secrets, `external`→Code scan, `supplyChain`→Dependencies, `judge`→AI review, `hunt`→Exploit paths; states render as `RAN`→checked, `SKIPPED`→skipped, `NOT_CONFIGURED`→off, `PENDING`→scanning, `PARTIAL`→⚠ incomplete, `SUPERSEDED`→⚠ superseded, `FAILED`→✗ failed. "checked" means the layer completed, **not** that it found nothing — findings are counted in their own segments and in the next-actions list (`hunt` = the L3 vulnerability hunt, LUM-739: absent when `LUMO_SECURITY_HUNT=off`, `SKIPPED` when no trigger fired, `PENDING` while the workflow runs, `RAN` / `PARTIAL` (budget hit, a planned task that never finished, or more surviving candidates than the falsifier cap) / `FAILED`; its findings are `LLM_JUDGE` advisory, never `blocks DONE`); `(N external findings)` (singular at 1) decorates only the Code scan segment, and only when N > 0; `(N dependency findings[, M already on main])` (LUM-738; singular at 1) decorates only the Dependencies segment, only when N > 0, and prints bare `Dependencies: <state>` against an older server without the counts; ` · partial` appended when the scan is partial; and, when `stages.external === 'FAILED'` and a **scrubbed scanner reason** was recorded (the `error` column carries the `external: ` provenance prefix), an appended ` — <reason without the prefix, tail 200 chars>` — an unprefixed `error` (stage A's own raw crash text) is never printed here, same P8 rule as the web panel and the PR summary (LUM-756). Fed by the additive `securityFindings.scans` array; omitted entirely (no lines) against an older server that doesn't send it.
   - **Hunt coverage line** (LUM-762): indented under its scan line whenever the server sends the L3 hunt's per-category audit — `Exploit paths 2/3 done · t1 idor 41.2s done · t2 injection 72.0s done (2 attempts) · t3 race skipped`. `<n>/N done` is how many planned tasks finished (where N is the number of tasks the planning step selected for this scan, typically 0–3). Rows persisted before LUM-758 lack a planned-task count and fall back to the historical 6-category denominator (reading as `/6` instead). Each segment is `[taskId ]<category> <elapsed>s <stop>` — the `taskId` prefix (`t1`, `t2`, …) appears only on current rows where the task graph is present (post-LUM-758), and is omitted on pre-task-graph audit rows, so they render exactly as they always did. Elapsed is summed over the task's attempts; `(N attempts)` when the workflow retried it; no elapsed for a `skipped` task (the scan's budget ran out before its turn). Stop values: `done` · `steps` · `budget` · `timeout` · `error` · `skipped`. Headed by the same display label as the layer's own segment (LUM-763), so the detail line and the line above it never name the layer two different ways. This is the only surface that reads `huntAudit`, so it is where you answer "how long does a healthy task take" and "which tasks never ran" without paging through deploy logs. Absent on an older server and on scans with no usable audit (pre-LUM-739 rows, or a hunt that failed before its first batch) — no line, never a guess.
+  - **Queue exit** (LUM-775): a merged / closed PR's line ends with ` · N left the queue (a resolved on main, b merged unreviewed, c PR closed)` when any undispositioned row has left the queue — derived at read time, never stored. `resolved on main` = an external-tool finding whose fingerprint is absent from a default-branch baseline that can testify (landed, whole, requested after the merge, ran that tool); `merged unreviewed` = an advisory row whose PR merged without a decision (a policy-blocking row never exits this way — it stays a next action and keeps blocking DONE until a human decides, or until a fresh baseline shows it gone); `PR closed` = closed without merging, nothing landed (reopening the PR puts the rows back). Exited rows are not next actions, are not counted in `openFindings`, and show muted with the reason in the web panel. Absent on an older server. The workspace-wide read-out with per-row reasons is `scripts/analysis/lum775-finding-queue/report.ts`.
   - **Persisting findings** (LUM-738): a finding whose fingerprint is already on the repository's default-branch baseline (`persisting`) is not this PR's — it never appears as a next action, is not counted in `openFindings`, and shows muted (_already on the default branch_) in the web panel. Dependency findings (`kind=DEPENDENCY`, from osv-scanner) are advisory: they never block DONE.
   - **Fails closed:** `⚠ Security-scan check failed — could not confirm …` when the scan read errored, and one `⚠ PR #n: … — could not confirm it is clean.` line per open PR whose latest scan is missing / FAILED / still running. Silence means a successful read with nothing open, never a failed check.
-- **Open boundary crossings** — a trailing safety block when the task has ≥1 OPEN (undispositioned) forbidden-action crossing: a count, then one line per crossing `• [SEVERITY] CATEGORY — <clipped detail>` (highest-severity first), each followed by a read-only **attribution** line `↳ by model=<m> · agent=<type>[/branch] · session=<8-char prefix>` (who/what crossed; any dimension that couldn't be resolved server-side prints `unknown`, never a fabricated value), then a pointer to `lumo crossing disposition` and the web acceptance panel. Silent when there are none, so it never overshadows the criteria.
+- **Open boundary crossings** — a trailing safety block when the task has ≥1 OPEN (undispositioned) forbidden-action crossing: a count split the way the server DONE gate counts it — `(N undispositioned: B blocking DONE, A advisory / non-blocking)` (LUM-771) — then one line per crossing, blocking rows first as `• [SEVERITY] CATEGORY — <clipped detail>` (highest-severity first) and non-blocking rows as `◦ [SEVERITY] CATEGORY (advisory — does not block DONE)` / `(below the workspace gate — does not block DONE)`; only the `•` rows need a ruling before DONE, each followed by a read-only **attribution** line `↳ by model=<m> · agent=<type>[/branch] · session=<8-char prefix>` (who/what crossed; any dimension that couldn't be resolved server-side prints `unknown`, never a fabricated value), then a pointer to `lumo crossing disposition` and the web acceptance panel. Silent when there are none, so it never overshadows the criteria.
   - **Read-only awareness** — this block surfaces crossings detected elsewhere and clears nothing itself. The ruling is the user's: `lumo crossing disposition <id> --false-positive | --confirmed` (exit-4 envelope you relay, LUM-769 — see below) or the web panel. You never self-approve.
   - **The check fails closed:** if the crossings read itself errors (network / server / parse), the block prints `⚠ Boundary-crossing check failed (network/server error) — could not confirm whether any are undispositioned` instead of staying silent. Silence means a successful read with zero open crossings, never a failed check — a hiccup can no longer masquerade as "all clear".
 

package/dist/cli/src/commands/milestone-changelog.js

@@ -83,7 +83,7 @@ function formatEntry(entry) {
 }
 function formatMilestoneChangelog(cl) {
     const lines = [
-        `# Changelog — ${(0, sanitize_1.sanitizeField)(cl.milestone.name)} (${cl.milestone.status})`,
+        `# Changelog — ${(0, sanitize_1.sanitizeField)(cl.milestone.name)} (${cl.milestone.state})`,
     ];
     const window = formatWindow(cl.milestone.startDate, cl.milestone.targetDate);
     if (window)

package/dist/cli/src/commands/milestone-list.js

@@ -19,23 +19,30 @@ function formatDate(iso) {
         return '-';
     return iso.slice(0, 10);
 }
+/** LUM-714: the milestone's state, folded from its two timestamps. */
+function rowState(r) {
+    if (r.archivedAt)
+        return 'ARCHIVED';
+    return r.completedAt ? 'COMPLETED' : 'ACTIVE';
+}
 /**
  * Render milestones as fixed-width rows:
- *   <STATUS>  <HEALTH>  <target-date or ->  <name>
+ *   <STATE>  <HEALTH>  <target-date or ->  <name>
  *
+ * STATE is ACTIVE / COMPLETED / ARCHIVED (LUM-714) — derived, never stored.
  * HEALTH is the target-date risk light (ON-TRACK / AT-RISK / OVERDUE), or `-`
- * when no light applies (terminal status or no target date).
+ * when no light applies (completed, archived, or no target date).
  *
  * Sorted server-side by targetDate asc nulls last, createdAt asc.
  */
 function formatMilestoneList(rows) {
     if (rows.length === 0)
         return 'No milestones.';
-    const statusW = Math.max(...rows.map(r => r.status.length));
+    const stateW = Math.max(...rows.map(r => rowState(r).length));
     const healthW = Math.max(...rows.map(r => formatHealth(r.health).length));
     const dateW = Math.max(...rows.map(r => formatDate(r.targetDate).length));
     return rows
-        .map(r => `${r.status.padEnd(statusW)}  ${formatHealth(r.health).padEnd(healthW)}  ${formatDate(r.targetDate).padEnd(dateW)}  ${r.archivedAt ? `${(0, sanitize_1.sanitizeField)(r.name)} (archived)` : (0, sanitize_1.sanitizeField)(r.name)}`)
+        .map(r => `${rowState(r).padEnd(stateW)}  ${formatHealth(r.health).padEnd(healthW)}  ${formatDate(r.targetDate).padEnd(dateW)}  ${(0, sanitize_1.sanitizeField)(r.name)}`)
         .join('\n');
 }
 async function milestoneList(options) {

package/dist/cli/src/commands/milestone-show.js

@@ -65,15 +65,25 @@ function formatMilestoneShow(m, tasks) {
         m.taskCounts.IN_PROGRESS +
         m.taskCounts.IN_REVIEW +
         m.taskCounts.DONE;
-    const statusLine = m.staleness?.statusDrift
-        ? `Status:       ${m.status}  (stale — task progress indicates ${(0, sanitize_1.sanitizeField)(m.staleness.statusDrift)}; auto-updating)`
-        : `Status:       ${m.status}`;
+    // LUM-714: state is derived, so the line reports what the two timestamps
+    // say — and, when the tasks disagree with the stored stamp, what the rollup
+    // is about to do about it.
+    const state = m.archivedAt
+        ? 'archived'
+        : m.completedAt
+            ? 'completed'
+            : 'active';
+    const drift = m.staleness?.completionDrift;
+    const stateLine = drift
+        ? `State:        ${state}  (stale — task progress indicates ${drift === 'complete' ? 'completed' : 'active'}; auto-updating)`
+        : `State:        ${state}`;
     const targetLine = m.staleness?.datesMissing
         ? `Target:       ${fmtDate(m.targetDate)}  (no target date — schedule health unavailable)`
         : `Target:       ${fmtDate(m.targetDate)}`;
     const lines = [
         `Milestone:    ${(0, sanitize_1.sanitizeField)(m.name)}`,
-        statusLine,
+        stateLine,
+        `Completed:    ${m.completedAt ? m.completedAt.slice(0, 10) : 'no'}`,
         `Archived:     ${m.archivedAt ? m.archivedAt.slice(0, 10) : 'no'}`,
         `Health:       ${fmtHealth(m.health)}`,
         `Start:        ${fmtDate(m.startDate)}`,
@@ -156,7 +166,7 @@ async function milestoneShow(identifier, opts) {
     process.stdout.write(formatMilestoneShow({
         id: milestone.id,
         name: milestone.name,
-        status: milestone.status,
+        completedAt: milestone.completedAt,
         startDate: milestone.startDate,
         targetDate: milestone.targetDate,
         archivedAt: milestone.archivedAt,

package/dist/cli/src/commands/milestone-update.js

@@ -1,6 +1,5 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.normalizeMilestoneStatus = normalizeMilestoneStatus;
 exports.normalizeTokenBudget = normalizeTokenBudget;
 exports.buildMilestoneUpdatePayload = buildMilestoneUpdatePayload;
 exports.formatMilestoneUpdateSummary = formatMilestoneUpdateSummary;
@@ -9,20 +8,6 @@ const config_1 = require("../lib/config");
 const api_1 = require("../lib/api");
 const resolve_1 = require("../lib/resolve");
 const sanitize_1 = require("../lib/sanitize");
-const ALLOWED_STATUSES = [
-    'PLANNED',
-    'ACTIVE',
-    'COMPLETED',
-    'CANCELLED',
-];
-function normalizeMilestoneStatus(value) {
-    if (!value)
-        return null;
-    const upper = value.toUpperCase().replace(/-/g, '_');
-    return ALLOWED_STATUSES.includes(upper)
-        ? upper
-        : null;
-}
 /**
  * LUM-644: '' clears the budget (→ null, the nullable-flag convention);
  * otherwise the value must be a positive integer within Postgres INT range.
@@ -49,10 +34,6 @@ function buildMilestoneUpdatePayload(opts) {
         payload.description = opts.description === '' ? null : opts.description;
         flagsGiven.push('--description');
     }
-    if (opts.status !== undefined) {
-        payload.status = opts.status;
-        flagsGiven.push('--status');
-    }
     if (opts.start !== undefined) {
         payload.startDate = opts.start === '' ? null : opts.start;
         flagsGiven.push('--start');
@@ -85,9 +66,6 @@ function formatMilestoneUpdateSummary(before, after) {
     if (after.description !== undefined) {
         changes.push(after.description === null ? 'description → ∅' : 'description updated');
     }
-    if (after.status !== undefined && after.status !== before.status) {
-        changes.push(`status ${before.status} → ${after.status}`);
-    }
     if (after.startDate !== undefined) {
         changes.push(`start → ${fmtDate(after.startDate)}`);
     }
@@ -102,28 +80,15 @@ function formatMilestoneUpdateSummary(before, after) {
     return `Updated milestone "${beforeName}": ${changes.join(', ')}`;
 }
 async function milestoneUpdate(identifier, opts) {
-    // Validate status flag eagerly.
-    let normalizedStatus;
-    if (opts.status !== undefined) {
-        const n = normalizeMilestoneStatus(opts.status);
-        if (!n) {
-            console.error(`Error: invalid status "${opts.status}". Allowed: planned, active, completed, cancelled`);
-            return 1;
-        }
-        normalizedStatus = n;
-    }
     // Validate token budget eagerly (LUM-644): positive integer, or '' to clear.
     if (opts.tokenBudget !== undefined &&
         normalizeTokenBudget(opts.tokenBudget) === undefined) {
         console.error(`Error: invalid token budget "${opts.tokenBudget}". Provide a positive integer (e.g. 5000000), or "" to clear.`);
         return 1;
     }
-    const { payload, flagsGiven } = buildMilestoneUpdatePayload({
-        ...opts,
-        ...(normalizedStatus !== undefined && { status: normalizedStatus }),
-    });
+    const { payload, flagsGiven } = buildMilestoneUpdatePayload(opts);
     if (flagsGiven.length === 0) {
-        console.error('Error: provide at least one field to update (--name, --description, --status, --start, --target, --token-budget)');
+        console.error('Error: provide at least one field to update (--name, --description, --start, --target, --token-budget)');
         return 1;
     }
     const creds = (0, config_1.readCredentials)();

package/dist/cli/src/commands/task-context.js

@@ -64,7 +64,7 @@ function formatTaskContextMarkdown(data, now) {
         const target = data.task.milestone.targetDate
             ? `, target ${data.task.milestone.targetDate.slice(0, 10)}`
             : '';
-        lines.push(`**Milestone**: ${(0, sanitize_1.sanitizeField)(data.task.milestone.name)} (${data.task.milestone.status}${target})`);
+        lines.push(`**Milestone**: ${(0, sanitize_1.sanitizeField)(data.task.milestone.name)} (${data.task.milestone.state}${target})`);
         const milestoneGoal = data.task.milestone.description;
         if (milestoneGoal && milestoneGoal.trim().length > 0) {
             lines.push(`**Milestone goal**: ${(0, sanitize_1.sanitizeField)(milestoneGoal)}`);

package/dist/cli/src/commands/task-status.js

@@ -65,7 +65,9 @@ const SCAN_STAGE_ORDER = security_scan_1.SCAN_STAGE_KEYS;
 /** LUM-735 — one line per linked PR's latest scan: `PR #945 · scan CLEAN ·
  *  Secrets: checked · Code scan: checked (2 external findings) ·
  *  Dependencies: checked (1 dependency finding, 1 already on main) ·
- *  AI review: checked · Exploit paths: checked`.
+ *  AI review: checked · Exploit paths: checked`, plus, on a merged / closed
+ *  PR, ` · 3 left the queue (2 resolved on main, 1 merged unreviewed)`
+ *  (LUM-775).
  *  Stage segments only for keys present, in
  *  secrets/external/supplyChain/judge/hunt order (LUM-739 added the hunt
  *  layer); the `(N external findings)` count only decorates the Code scan
@@ -101,6 +103,12 @@ function formatScanSummaryLine(s) {
         line += ` · ${segments.join(' · ')}`;
     if (s.partial)
         line += ' · partial';
+    // LUM-775: what left the queue because the PR merged / closed, and why —
+    // so a merged PR's line explains where its findings went instead of
+    // silently listing fewer next actions than the scan found.
+    const exits = (0, security_scan_1.formatQueueExits)(s.queueExits);
+    if (exits)
+        line += ` · ${exits}`;
     // LUM-756 (P8): `error` has two writers — only the prefixed, scrubbed
     // scanner reason may be printed, and only the text after the prefix. Stage
     // A's raw crash text carries no prefix and is never shown here (same rule
@@ -611,12 +619,21 @@ function pushOpenCrossings(lines, extras) {
     const open = result.crossings;
     if (open.length === 0)
         return;
+    // LUM-771: say which rows the server DONE gate actually counts — advisory
+    // rows (and, with the gate off, non-HIGH rows) are awareness, not blockers.
+    const blocking = open.filter(c => c.blocking);
+    const rest = open.filter(c => !c.blocking);
     lines.push('');
-    lines.push(`⚠ Open boundary crossings (${open.length} undispositioned):`);
+    lines.push(`⚠ Open boundary crossings (${open.length} undispositioned: ${blocking.length} blocking DONE, ${rest.length} advisory / non-blocking):`);
     for (const c of open) {
         const detail = oneLineDetail(c.detail);
         const tail = detail ? ` — ${detail}` : '';
-        lines.push(`  • [${c.severity}] ${(0, sanitize_1.sanitizeField)(c.category)}${tail}`);
+        const gate = c.blocking
+            ? ''
+            : c.advisory
+                ? ' (advisory — does not block DONE)'
+                : ' (below the workspace gate — does not block DONE)';
+        lines.push(`  ${c.blocking ? '•' : '◦'} [${c.severity}] ${(0, sanitize_1.sanitizeField)(c.category)}${gate}${tail}`);
         lines.push(`    ${formatAttribution(c.attribution)}`);
     }
     lines.push("  Disposition is the user's call: relay each crossing, then `lumo crossing disposition <id> --false-positive | --confirmed` (exit-4 envelope; never self-approve), or the web acceptance panel:");

package/dist/cli/src/commands/task-update.js

@@ -391,7 +391,7 @@ async function runTaskUpdate(identifier, opts, collected) {
             if (res.status === 409 &&
                 status === 'DONE' &&
                 (0, blocked_error_1.isDoneGateRefusal)(serverMsg)) {
-                const { blockers, unconfirmed } = await (0, blocked_error_1.collectDoneBlockers)({
+                const { blockers, unconfirmed, nonBlocking } = await (0, blocked_error_1.collectDoneBlockers)({
                     base,
                     token: creds.token,
                     identifier,
@@ -401,6 +401,7 @@ async function runTaskUpdate(identifier, opts, collected) {
                     message: serverMsg,
                     blockers,
                     unconfirmed,
+                    nonBlocking,
                     apiUrl,
                     workspaceSlug: creds.workspaceSlug ?? '',
                 }));

package/dist/cli/src/index.js

@@ -756,11 +756,10 @@ milestoneCmd
     .action(wrap((identifier, options) => (0, milestone_show_1.milestoneShow)(identifier, options)));
 milestoneCmd
     .command('update <identifier>')
-    .description('Update a milestone. Provide at least one of --name, --description, --status, --start, --target, --token-budget. Use "" to clear nullable fields.')
+    .description('Update a milestone. Provide at least one of --name, --description, --start, --target, --token-budget. Use "" to clear nullable fields. Completion is derived from task completion (LUM-714) — there is no status flag.')
     .option('--project <ref>', 'Project name or slug (when identifier is a name)')
     .option('-n, --name <text>', 'New name')
     .option('-d, --description <text>', 'New description (empty string to clear)')
-    .option('-s, --status <value>', 'New status: planned | active | completed | cancelled (case-insensitive)')
     .option('--start <date>', 'Start date YYYY-MM-DD (empty string to clear)')
     .option('--target <date>', 'Target date YYYY-MM-DD (empty string to clear)')
     .option('--token-budget <tokens>', 'Advisory token budget, positive integer (empty string to clear). Overview shows burn vs budget; over-budget raises a risk-queue alert — never a hard gate.')

package/dist/cli/src/lib/blocked-error.js

@@ -46,6 +46,7 @@ async function collectDoneBlockers(args) {
     const { base, token, identifier } = args;
     const blockers = [];
     const unconfirmed = [];
+    const nonBlocking = [];
     const headers = { Authorization: `Bearer ${token}` };
     // Send-backs + blocking security findings: the acceptance-status read model.
     try {
@@ -91,17 +92,30 @@ async function collectDoneBlockers(args) {
         unconfirmed.push(`boundary-crossings read failed: ${crossings.reason}`);
     }
     else {
+        // LUM-771: mirror the server gate — an open row is a blocker only when
+        // the gate counts it; the rest are surfaced separately, never as blockers.
         for (const c of crossings.crossings) {
-            blockers.push({
-                kind: 'BOUNDARY_CROSSING',
-                id: c.id,
-                severity: c.severity,
-                category: c.category,
-                detail: c.detail,
-            });
+            if (c.blocking) {
+                blockers.push({
+                    kind: 'BOUNDARY_CROSSING',
+                    id: c.id,
+                    severity: c.severity,
+                    category: c.category,
+                    detail: c.detail,
+                });
+            }
+            else {
+                nonBlocking.push({
+                    id: c.id,
+                    severity: c.severity,
+                    category: c.category,
+                    detail: c.detail,
+                    advisory: c.advisory,
+                });
+            }
         }
     }
-    return { blockers, unconfirmed };
+    return { blockers, unconfirmed, nonBlocking };
 }
 /**
  * One line per blocker kind present. Every line names a human-side path, the
@@ -138,6 +152,7 @@ function buildBlockedError(args) {
         task: args.identifier,
         message: args.message,
         blockers: args.blockers,
+        nonBlocking: args.nonBlocking ?? [],
         unconfirmed: args.unconfirmed,
         remediation: buildRemediation(args.blockers, args.unconfirmed, {
             identifier: args.identifier,
@@ -166,6 +181,13 @@ function renderBlocked(err, isTTY) {
         '',
         err.blockers.length > 0 ? 'Blockers:' : 'Blockers: (none listed)',
         ...err.blockers.map(b => `  • ${(0, sanitize_1.sanitizeField)(blockerLine(b))}`),
+        ...(err.nonBlocking.length > 0
+            ? [
+                '',
+                'Also open, not blocking DONE (advisory / below the workspace gate):',
+                ...err.nonBlocking.map(c => `  ◦ [${c.severity}${c.advisory ? ' advisory' : ''}] ${(0, sanitize_1.sanitizeField)(c.category)} ${c.id}: ${(0, sanitize_1.sanitizeField)(c.detail)}`),
+            ]
+            : []),
         ...(err.unconfirmed.length > 0
             ? ['', ...err.unconfirmed.map(u => `  ⚠ ${u}`)]
             : []),

package/dist/cli/src/lib/git-deleted-test-files.js

@@ -0,0 +1,99 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.collectDeletedTestFiles = collectDeletedTestFiles;
+exports.looksLikeDeleteCommand = looksLikeDeleteCommand;
+const child_process_1 = require("child_process");
+const test_file_path_1 = require("../../../shared/src/test-file-path");
+/**
+ * LUM-779 — the local half of the TEST_FILE_DELETED net-deletion verdict.
+ *
+ * The server's matcher only sees command TEXT, and text lies: a restore from
+ * HEAD, a `cp` back from a .bak, or an `rm` of a scratch probe the agent wrote
+ * seconds earlier all look like "deleted a test file" and none of them did.
+ * What settles it is repo state — is a tracked test file missing now — and
+ * only the hook, running on the agent's machine, can ask git that question.
+ *
+ * `collectDeletedTestFiles` answers with the tracked test files that are gone:
+ *   - working tree + index vs HEAD (`git diff HEAD --diff-filter=D`) — a plain
+ *     `rm` or a `git rm` of a tracked file, not yet committed
+ *   - commits on top of the base branch (`git log --diff-filter=D base..HEAD`)
+ *     — an `rm … && git commit` chained in one command would otherwise be
+ *     invisible to the first probe
+ * Filtered by the shared test-path pattern, sorted, de-duplicated.
+ *
+ * `null` means the probe could not answer (not a repository, git missing, a
+ * timeout) — the caller omits the field and the server keeps its fail-closed
+ * blocking behaviour. `[]` is a verdict: the probe ran and nothing is missing.
+ */
+/** Base-branch candidates, in order. The first that resolves wins. */
+const BASE_REF_CANDIDATES = [
+    'refs/remotes/origin/HEAD',
+    'refs/remotes/origin/main',
+    'refs/remotes/origin/master',
+    'refs/remotes/origin/develop',
+];
+const GIT_TIMEOUT_MS = 2000;
+function runGit(args, cwd) {
+    try {
+        const r = (0, child_process_1.spawnSync)('git', args, {
+            cwd,
+            encoding: 'utf8',
+            timeout: GIT_TIMEOUT_MS,
+            stdio: ['ignore', 'pipe', 'ignore'],
+        });
+        if (r.error || r.status !== 0)
+            return { ok: false, stdout: '' };
+        return { ok: true, stdout: r.stdout ?? '' };
+    }
+    catch {
+        return { ok: false, stdout: '' };
+    }
+}
+/** NUL-separated path list → paths (empty entries dropped). */
+function splitPaths(stdoutZ) {
+    return stdoutZ.split('\0').filter(p => p.length > 0);
+}
+function resolveBaseRef(cwd) {
+    for (const ref of BASE_REF_CANDIDATES) {
+        if (runGit(['rev-parse', '--verify', '-q', ref], cwd).ok)
+            return ref;
+    }
+    return null;
+}
+function collectDeletedTestFiles(cwd) {
+    // Working tree + index vs HEAD. Also the "is this a repo with a HEAD"
+    // probe: a non-repository, or git itself missing, fails here → null.
+    const uncommitted = runGit(['diff', 'HEAD', '--diff-filter=D', '--name-only', '-z'], cwd);
+    if (!uncommitted.ok)
+        return null;
+    const missing = new Set(splitPaths(uncommitted.stdout));
+    // Deletions already committed on top of the base branch. Best-effort: no
+    // resolvable base (a repo with no remote) just skips this half.
+    const base = resolveBaseRef(cwd);
+    if (base) {
+        const committed = runGit([
+            'log',
+            '--diff-filter=D',
+            '--name-only',
+            '--format=',
+            '-z',
+            `${base}..HEAD`,
+        ], cwd);
+        if (committed.ok) {
+            for (const p of splitPaths(committed.stdout))
+                missing.add(p);
+        }
+    }
+    return [...missing].filter(test_file_path_1.isTestFilePath).sort();
+}
+/**
+ * Cheap pre-filter deciding whether the probe is worth running at all: an
+ * `rm` / `git rm` token anywhere in the command, including inside a `bash -c`
+ * wrapper string. Deliberately a SUPERSET of the server's matcher — a probe
+ * that runs for an `rm` of a non-test file costs two git calls and nothing
+ * else, whereas a probe that is skipped for a command the server does flag
+ * leaves the server fail-closed on a possible false positive.
+ */
+function looksLikeDeleteCommand(command) {
+    return /(?:^|[\s(;&|"'`])(?:rm|git\s+rm)\b/.test(command);
+}

package/dist/cli/src/lib/hook-runner.js

@@ -4,6 +4,7 @@ exports.formatHookStdoutLines = formatHookStdoutLines;
 exports.formatSuggestLine = formatSuggestLine;
 exports.resolveSessionStartStdout = resolveSessionStartStdout;
 exports.augmentBodyWithUsage = augmentBodyWithUsage;
+exports.augmentBodyWithDeletedTestFiles = augmentBodyWithDeletedTestFiles;
 exports.runHook = runHook;
 exports.runHookWithBody = runHookWithBody;
 const config_1 = require("./config");
@@ -16,6 +17,7 @@ const transcript_usage_1 = require("./transcript-usage");
 const resolve_project_1 = require("./resolve-project");
 const resolve_bound_task_1 = require("./resolve-bound-task");
 const memory_auto_1 = require("./memory-auto");
+const git_deleted_test_files_1 = require("./git-deleted-test-files");
 /**
  * Hard timeout for the hook POST. On timeout the request is aborted,
  * logged, and `runHook` exits 0 — Claude Code is never blocked beyond
@@ -261,6 +263,54 @@ function augmentBodyWithUsage(path, body) {
         _lumo_usage: { ...usage.total, byModel: usage.byModel },
     });
 }
+/**
+ * LUM-779: for a post-tool-use Bash event whose command carries an `rm` /
+ * `git rm`, ask local git which tracked test files are actually missing now
+ * and fold the answer into the body under `_lumo_deleted_test_files`. The
+ * server judges TEST_FILE_DELETED by this list — not by the command text —
+ * so a restore or an `rm` of an untracked scratch probe is recorded advisory
+ * while a real deletion of a tracked test still blocks.
+ *
+ * The three wire states matter: a non-empty list (blocking), an EMPTY list
+ * (probe ran, nothing missing → advisory), and NO field (probe skipped or
+ * git could not answer → the server fails closed). So the field is only ever
+ * attached when the probe returned an array, and a probe that throws leaves
+ * the body untouched. Never blocks or fails the hook.
+ */
+function augmentBodyWithDeletedTestFiles(path, body, probe = git_deleted_test_files_1.collectDeletedTestFiles) {
+    if (path !== 'post-tool-use')
+        return body;
+    let parsed;
+    try {
+        parsed = JSON.parse(body || '{}');
+    }
+    catch {
+        return body;
+    }
+    if (!parsed || typeof parsed !== 'object')
+        return body;
+    if (parsed['tool_name'] !== 'Bash')
+        return body;
+    const input = parsed['tool_input'];
+    const command = input && typeof input === 'object'
+        ? input['command']
+        : undefined;
+    if (typeof command !== 'string' || !(0, git_deleted_test_files_1.looksLikeDeleteCommand)(command))
+        return body;
+    const cwd = typeof parsed['cwd'] === 'string' && parsed['cwd']
+        ? parsed['cwd']
+        : process.cwd();
+    let deleted;
+    try {
+        deleted = probe(cwd);
+    }
+    catch {
+        return body;
+    }
+    if (deleted === null)
+        return body;
+    return JSON.stringify({ ...parsed, _lumo_deleted_test_files: deleted });
+}
 /**
  * POST the hook body to /api/hooks/<path> with a short timeout. All errors
  * — credential missing, network failure, timeout, non-2xx — are routed to
@@ -309,7 +359,8 @@ async function runHookWithBody(path, body, agentToken) {
         const agentEnum = agentToken ? (0, agent_1.normalizeAgent)(agentToken) : null;
         if (agentEnum)
             headers['X-Lumo-Agent'] = agentEnum;
-        const outgoingBody = augmentBodyWithUsage(path, body) || '{}';
+        const outgoingBody = augmentBodyWithDeletedTestFiles(path, augmentBodyWithUsage(path, body)) ||
+            '{}';
         try {
             const res = await fetch(url, {
                 method: 'POST',

package/dist/cli/src/lib/open-crossings.js

@@ -1,8 +1,17 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
+exports.blocksDone = blocksDone;
 exports.fetchOpenCrossings = fetchOpenCrossings;
 exports.dispositionUrl = dispositionUrl;
 const api_1 = require("./api");
+/**
+ * LUM-771: the server's DONE-gate predicate for one open crossing (mirrors
+ * `assertNoUnacknowledgedBoundaryCrossings` and the panel): an advisory row
+ * never blocks; with the workspace gate disabled only HIGH rows block.
+ */
+function blocksDone(c, gateEnabled) {
+    return !c.advisory && (gateEnabled || c.severity === 'HIGH');
+}
 const SEVERITY_RANK = {
     HIGH: 3,
     MEDIUM: 2,
@@ -62,17 +71,28 @@ async function fetchOpenCrossings(apiUrl, token, taskIdentifier) {
         return { status: 'error', reason: 'invalid response body' };
     }
     const rows = Array.isArray(data.crossings) ? data.crossings : [];
+    // LUM-771: only an explicit `false` disables the gate — absent (older server)
+    // or malformed reads as enabled, so a hiccup can never hide a blocker.
+    const gateEnabled = data.gateEnabled !== false;
     const crossings = rows
         .filter(c => c.disposition == null)
-        .map(c => ({
-        id: c.id,
-        category: c.category,
-        severity: normalizeSeverity(c.severity),
-        detail: c.detail,
-        attribution: normalizeAttribution(c.attribution),
-    }))
-        .sort((a, b) => SEVERITY_RANK[b.severity] - SEVERITY_RANK[a.severity]);
-    return { status: 'ok', crossings };
+        .map(c => {
+        const severity = normalizeSeverity(c.severity);
+        const advisory = c.advisory === true;
+        return {
+            id: c.id,
+            category: c.category,
+            severity,
+            detail: c.detail,
+            attribution: normalizeAttribution(c.attribution),
+            advisory,
+            blocking: blocksDone({ advisory, severity }, gateEnabled),
+        };
+    })
+        // Blocking rows first, then by severity — what the human must act on leads.
+        .sort((a, b) => Number(b.blocking) - Number(a.blocking) ||
+        SEVERITY_RANK[b.severity] - SEVERITY_RANK[a.severity]);
+    return { status: 'ok', crossings, gateEnabled };
 }
 /**
  * The web deep link where a human dispositions crossings in the panel — the

package/dist/shared/src/security-scan.js

@@ -1,10 +1,11 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.SECRET_DOWNGRADE_LABELS = exports.SCAN_STAGE_STATE_LABELS = exports.SCAN_STAGE_LABELS = exports.SCAN_STAGE_STATES = exports.SCAN_STAGE_KEYS = exports.EXTERNAL_ERROR_PREFIX = void 0;
+exports.QUEUE_EXIT_LABELS = exports.QUEUE_EXIT_REASONS = exports.SECRET_DOWNGRADE_LABELS = exports.SCAN_STAGE_STATE_LABELS = exports.SCAN_STAGE_LABELS = exports.SCAN_STAGE_STATES = exports.SCAN_STAGE_KEYS = exports.EXTERNAL_ERROR_PREFIX = void 0;
 exports.externalFailureReason = externalFailureReason;
 exports.scanStageLabel = scanStageLabel;
 exports.scanStageStateLabel = scanStageStateLabel;
 exports.secretDowngradeNote = secretDowngradeNote;
+exports.formatQueueExits = formatQueueExits;
 /**
  * PR security scan — the one `PrSecurityScan.error` shape that may be shown
  * as an external-scanner reason (spec P8). Shared by the web panel, the PR
@@ -123,3 +124,57 @@ function secretDowngradeNote(reason) {
         return '';
     return ` — ${exports.SECRET_DOWNGRADE_LABELS[reason] ?? reason}, downgraded`;
 }
+/**
+ * LUM-775 — why an undispositioned finding is no longer in the queue.
+ *
+ * A PR finding's review window is the PR. Once the PR is merged or closed
+ * the question changes from "what did this change introduce" to "what is on
+ * main now", and only the default-branch baseline (LUM-738) may answer that.
+ * The exit is DERIVED at read time from PR state × baseline × policy — never
+ * written to the row, so `disposition` stays a human-only column.
+ *
+ * - `RESOLVED_ON_MAIN`: an external-tool finding whose fingerprint is absent
+ *   from a baseline that can testify (landed, whole, requested after the
+ *   merge, ran that tool). The one exit with evidence.
+ * - `MERGED_UNREVIEWED`: the window closed without a decision. Advisory rows
+ *   only — a policy-blocking row stays until a human decides.
+ * - `PR_CLOSED`: closed without merging; nothing landed. Reopening the PR
+ *   puts the row straight back (derived, not stored).
+ */
+exports.QUEUE_EXIT_REASONS = [
+    'RESOLVED_ON_MAIN',
+    'MERGED_UNREVIEWED',
+    'PR_CLOSED',
+];
+/** One wording per exit on every surface (CLI scan line, analysis report). */
+exports.QUEUE_EXIT_LABELS = {
+    RESOLVED_ON_MAIN: 'resolved on main',
+    MERGED_UNREVIEWED: 'merged unreviewed',
+    PR_CLOSED: 'PR closed',
+};
+/**
+ * `3 left the queue (2 resolved on main, 1 merged unreviewed)`, or null when
+ * nothing left — the caller omits the segment rather than printing a zero.
+ * Reasons print in the declared order; an unknown key (a newer server) is
+ * counted in the total and printed as itself, never dropped.
+ */
+function formatQueueExits(counts) {
+    if (!counts)
+        return null;
+    const parts = [];
+    let total = 0;
+    const keys = [
+        ...exports.QUEUE_EXIT_REASONS.filter(k => k in counts),
+        ...Object.keys(counts).filter(k => !exports.QUEUE_EXIT_REASONS.includes(k)),
+    ];
+    for (const key of keys) {
+        const n = counts[key] ?? 0;
+        if (n <= 0)
+            continue;
+        total += n;
+        parts.push(`${n} ${exports.QUEUE_EXIT_LABELS[key] ?? key}`);
+    }
+    if (total === 0)
+        return null;
+    return `${total} left the queue (${parts.join(', ')})`;
+}

package/dist/shared/src/test-file-path.js

@@ -0,0 +1,18 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.TEST_FILE_TARGET = void 0;
+exports.isTestFilePath = isTestFilePath;
+/**
+ * What counts as a test file / test tree for the TEST_FILE_DELETED session
+ * guard (LUM-736): `*.test.*`, `*.spec.*`, or anything under a `__tests__/`
+ * segment. Single-sourced here (LUM-779) because two sides must agree on it:
+ * the server's command matcher (lib/services/boundary-detector.service.ts)
+ * and the CLI's local-git probe (cli/src/lib/git-deleted-test-files.ts) that
+ * reports which tracked test files are actually missing. A pattern that
+ * drifted between the two would let a real deletion slip through as "nothing
+ * missing" — so there is exactly one pattern.
+ */
+exports.TEST_FILE_TARGET = /(?:\.(?:test|spec)\.|(?:^|\/)__tests__(?:\/|$))/;
+function isTestFilePath(path) {
+    return exports.TEST_FILE_TARGET.test(path);
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lumoai/cli",
-  "version": "1.60.0",
+  "version": "1.62.0",
   "description": "Lumo CLI — manage tasks and sessions from the terminal",
   "license": "MIT",
   "author": "cli@uselumo.ai",