@lumoai/cli 1.60.0 → 1.61.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

@@ -147,7 +147,7 @@ what's unmet and why (the exact failure tails), and how many rounds are left.
   - **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.
   - **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

@@ -611,12 +611,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/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/package.json

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