@lumoai/cli 1.58.0 → 1.59.0

package/assets/skill/references/sprints.md

@@ -42,15 +42,12 @@ When to suggest: user says "create a sprint", "new sprint", "start a new iterati
 
 `<identifier>` accepts a sprint number (e.g. `3`) or a UUID. `--team` is required when using a number in a multi-team workspace.
 
-Output: key:value header (number, name, status, dates, team), then a `Progress:` line, then a **`Health:` line** with the sprint's risk level (`HEALTHY` / `WATCH` / `AT-RISK`), then a task table listing every task in the sprint.
+Output: key:value header (number, name, status, dates, team), then a `Progress:` line, then a `Blockers:` section, then a task table listing every task in the sprint.
 
-The risk level reuses the same engine as project/workspace stats, fed the sprint's task set (thresholds come from the workspace risk config — sprints have no per-sprint overrides). When the engine flags reasons they print as `- <detail>` lines under `Health:`, and a `Blockers:` section lists the top offenders per category (`Overdue` / `Stalled` / `Agent fail` / `Stale PRs`). A healthy sprint with no blockers shows just the `Health:` line.
+`Blockers:` lists the top offenders per category (`Overdue` / `Stalled` / `Agent fail` / `Stale PRs`) — a task counts as stalled after 7 days untouched, a PR as stale after 3 days awaiting review. A sprint with nothing in any category prints no `Blockers:` section at all. (There is no risk score or `Health:` line — LUM-709 removed the risk-assessment layer.)
 
 ```
 Progress:  4 / 10
-Health:    AT-RISK
-  - 4/10 tasks overdue (40%)
-  - 3 tasks with no progress in 7 days
 Blockers:
   Overdue:   LUM-1 Fix login, LUM-8 Wire API
   Stalled:   LUM-5 Add tests
@@ -63,7 +60,7 @@ lumo sprint show 3 --team backend
 lumo sprint show 11111111-2222-3333-4444-555555555555
 ```
 
-When to suggest: user asks "what's in sprint 3", "show me the current sprint", "what tasks are in this sprint", "is this sprint at risk", "sprint health".
+When to suggest: user asks "what's in sprint 3", "show me the current sprint", "what tasks are in this sprint", "what's blocking this sprint".
 
 ### `lumo sprint update <identifier> [flags]` — patch a sprint
 
@@ -83,12 +80,13 @@ lumo sprint update 3 --end 2026-06-21
 
 When to suggest: user wants to rename a sprint, extend dates, or fix sprint metadata.
 
-### `lumo sprint delete <identifier> --yes` — delete a sprint (DRAFT only)
+### `lumo sprint delete <identifier> --confirm` — delete a sprint (DRAFT only)
 
-Requires `--yes`; no interactive prompt (agent-friendly). Server rejects with an error if the sprint is ACTIVE or CLOSED.
+Without `--confirm` the CLI exits **4** with a confirmation envelope (`Will delete sprint #3 "Sprint 3"` · `N tasks under it keep their data; only sprintId is cleared`) and deletes nothing — relay it to the user, re-run `confirmCommand` on approval ([confirmation.md](confirmation.md)). `--yes` is a legacy alias. Server rejects with an error if the sprint is ACTIVE or CLOSED.
 
 ```bash
-lumo sprint delete 3 --yes
+lumo sprint delete 3            # exit 4 + envelope
+lumo sprint delete 3 --confirm  # after the user approved
 ```
 
 When to suggest: user wants to remove a draft sprint that was created by mistake.
@@ -107,18 +105,21 @@ When to suggest: user says "start the sprint", "kick off sprint 3", "activate sp
 
 Handles unfinished tasks based on flags. Without flags: closes only if all tasks are done; otherwise prints a list of unfinished tasks and refuses.
 
-| Flag            | Type    | Notes                                                                            |
-| --------------- | ------- | -------------------------------------------------------------------------------- |
-| `--move-all`    | boolean | Move all unfinished tasks to the next sprint. Requires `--yes`.                  |
-| `--backlog-all` | boolean | Remove all unfinished tasks from the sprint (send to backlog). Requires `--yes`. |
-| `--yes`         | boolean | Required when `--move-all` or `--backlog-all` is given.                          |
+| Flag            | Type    | Notes                                                                                                                                                       |
+| --------------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `--move-all`    | boolean | Move all unfinished tasks to the next sprint. Gated by `--confirm`.                                                                                         |
+| `--backlog-all` | boolean | Remove all unfinished tasks from the sprint (send to backlog). Gated by `--confirm`.                                                                        |
+| `--confirm`     | boolean | The user approved the envelope. Without it a mode flag exits 4 with a confirmation envelope listing every task that would move (`--yes` is a legacy alias). |
 
 ```bash
-lumo sprint close 3                          # fails if unfinished tasks exist
-lumo sprint close 3 --move-all --yes         # move unfinished to next sprint
-lumo sprint close 3 --backlog-all --yes      # send unfinished to backlog
+lumo sprint close 3                               # fails (exit 1) if unfinished tasks exist — pick a mode
+lumo sprint close 3 --move-all                    # exit 4 + envelope: "2 unfinished tasks move to the next sprint: LUM-3, LUM-4"
+lumo sprint close 3 --move-all --confirm          # move unfinished to next sprint (after the user approved)
+lumo sprint close 3 --backlog-all --confirm       # send unfinished to backlog
 ```
 
+See [confirmation.md](confirmation.md) for the envelope shape and the relay rules.
+
 When to suggest: user says "close the sprint", "end sprint 3", "wrap up the sprint". If they haven't decided what to do with unfinished tasks, ask before adding `--move-all` or `--backlog-all`.
 
 ### `lumo sprint summary <identifier> [--retry]` — fetch AI-generated sprint retro

package/assets/skill/references/task-deps.md

@@ -82,12 +82,13 @@ lumo task deps dismiss LUM-42 e5f6a7b8
 
 Use `dismiss` for false positives. Use `rm` only when you want the pair eligible for re-detection again.
 
-## `lumo task deps rm <LUM-N> <edge> --yes` — delete an edge
+## `lumo task deps rm <LUM-N> <edge> --confirm` — delete an edge
 
-Hard-deletes the edge row. **Requires `--yes`** — the CLI refuses without it (no interactive prompt exists).
+Hard-deletes the edge row. Without `--confirm` it resolves the edge, then exits **4** with a confirmation envelope describing it (`Will delete dependency edge [a1b2c3d4] from LUM-42: blocked by LUM-9 "…" (CONFIRMED, manual)`) and sends nothing — relay `changes` to the user and re-run the envelope's `confirmCommand` on approval (see [confirmation.md](confirmation.md)). `--yes` is a legacy alias of `--confirm`.
 
 ```bash
-lumo task deps rm LUM-42 a1b2c3d4 --yes
+lumo task deps rm LUM-42 a1b2c3d4            # exit 4 + envelope, nothing deleted
+lumo task deps rm LUM-42 a1b2c3d4 --confirm  # after the user approved
 # Removed [a1b2c3d4] from LUM-42
 ```
 

package/assets/skill/references/tasks.md

@@ -120,14 +120,46 @@ The server's transition matrix (`lib/task/state-machine.ts`):
 
 Practical rules:
 
-- **One call suffices.** `--status done` straight from TODO or IN_PROGRESS is legal — never walk `in_progress → in_review → done` as a ritual; it just wastes calls.
+- **One call suffices.** `--status done` straight from TODO or IN_PROGRESS is legal — never walk `in_progress → in_review → done` as a ritual; it just wastes calls. That one call **walks the confirmation protocol** (see below): without `--confirm` it exits 4 with an envelope, never a prompt.
 - **Under the verify flow you don't set `in_review`/`done` at all** — `lumo verify` moves the task to IN_REVIEW on all-pass and the DONE adjudication is human-only.
 - **A DONE task can be reopened** — to IN_REVIEW, IN_PROGRESS, or TODO. Reopening is a plain status change and does not alter any recorded acceptance verdict; verdict adjudication is human-only and has no CLI path. To attach context without reopening, `lumo task comment` works.
 
+### `--status done` requires `--confirm` — the confirmation envelope (LUM-755)
+
+DONE is the one status move that needs a human's sign-off. It no longer prompts (LUM-731's interactive yes/no question is gone): run without `--confirm`, the CLI looks the task up, prints a **confirmation envelope** on stdout and exits **4** with nothing sent — no PATCH, and no tag resolution either. The envelope's `changes` carry everything the old prompt showed, including a trailing `⚠` line when a linked PR has not merged (that line replaces the old second prompt — the protocol is one step, and you relay the whole block). Full protocol: [confirmation.md](confirmation.md).
+
+```bash
+lumo task update LUM-48 --status done
+# exit 4, stdout (JSON when piped; the same lines as text on a TTY):
+# {
+#   "status": "confirmation_required",
+#   "command": "task update",
+#   "changes": [
+#     "Will move LUM-48 \"Title\" to DONE",
+#     "Status: IN_REVIEW → DONE",
+#     "#926  merged   refactor: panel  https://github.com/o/r/pull/926",
+#     "#930  open     feat: wip        https://github.com/o/r/pull/930",
+#     "⚠ 1 linked pull request not merged: #930 open"
+#   ],
+#   "confirmCommand": "lumo task update LUM-48 --status done --confirm"
+# }
+```
+
+With no linked PR the PR lines collapse to `Pull requests: none linked` and there is no `⚠` line. Other flags on the same call (`--title`, `--add-tag`…) are preserved in `confirmCommand`.
+
+- **Show `changes` to the user and wait for an explicit yes**, then run `confirmCommand` unchanged. `--confirm` means the user confirmed — never add it on your own.
+- With `--confirm` the PATCH goes out directly. The server's own DONE gates still apply on top — an unresolved send-back, an undispositioned boundary crossing or a blocking security finding refuses with **409**, which the CLI turns into a structured **`DONE_BLOCKED` error on stdout with exit 5**: the 409 text verbatim, a `blockers[]` with ids (built from `task status` + the crossings read model), and `remediation` lines that only name human-side paths. There is no CLI path to clear any of them — relay, don't retry. See [confirmation.md](confirmation.md) "When the gate is human-only". Any other 409 stays plain text, exit 1.
+- `--confirm` is the only flag: there is no `--yes` or `--force` on `task update`. Every other status (`todo` / `in_progress` / `in_review`) PATCHes directly and ignores `--confirm`.
+- A failed lookup (404, network) exits 1 before any envelope.
+
+```bash
+lumo task update LUM-48 --status done --confirm   # only after the user approved the envelope
+```
+
 ### When to suggest `task update`
 
 - The user describes a state change in natural language (e.g. "mark LUM-48 as in progress", "rename LUM-12 to ...", "assign LUM-30 to me", "bump the priority on LUM-7").
-- After the agent finishes a task and the user confirms — offer to move it to `done`.
+- After the agent finishes a task and the user confirms — tell the user to run `lumo task update LUM-N --status done` in their terminal (it prompts for confirmation; an agent shell is non-TTY and is refused).
 - Multiple status changes in a row should each be a separate `update` invocation rather than batched.
 
 ### Sprint output format

package/assets/skill/references/verify.md

@@ -21,22 +21,19 @@ lumo verify LUM-42 --note "…"            # explicit task (overrides the sessio
 lumo verify --note "…" --timeout 900     # per-checkpointer timeout in seconds (default 600)
 ```
 
-**`--note` is required (LUM-597)** whenever a round will actually be posted (the
-task has MACHINE criteria). It is your one-line self-report — what you did and
-why it is ready ("我改了 X,因为 Y 可验收"). When the round all-passes and the
-task flips to IN*REVIEW, the note is frozen as the task's **claim** (provenance
-`AGENT` — the汇报者's own voice, not a summarizer paraphrase) and is checked
-against the diff for faithfulness. Capturing the claim is deterministic ("不填不
-让 post"); whether it is \_truthful* is the faithfulness audit's job — so don't
-under- or over-state it. A missing/blank note is refused **before** the round is
-posted, so no round is burned; just re-run with one. (An old CLI that omits it
-still verifies — the claim degrades to the synthesized run-summary fallback.)
+**`--note` is optional (LUM-733).** It is your one-line self-report — what
+you did and why it is ready ("我改了 X,因为 Y 可验收"). When given and the round
+all-passes into IN_REVIEW, it is frozen as the task's claim (source `AGENT`) and
+judged for faithfulness in the background; when omitted the round still posts
+and the claim degrades to the synthesized run summary. It is never a
+precondition for verifying — don't hold a round back to word it.
 
 ## What one round does
 
 1. Loads the task's acceptance contract and picks out MACHINE criteria.
-2. Runs each checkpointer locally (shell, cwd = current directory), one at a
-   time, echoing PASS/FAIL as it goes.
+2. Runs each checkpointer locally (shell, cwd = current directory, env = the
+   CLI's own minus its private `LUMO_NO_HINTS` mute — `--no-hints` never
+   reaches a checkpointer), one at a time, echoing PASS/FAIL as it goes.
 3. POSTs the structured verdicts; the server records one VerificationRun per
    criterion at round = previous max + 1 and mirrors each verdict as a
    TaskActivity event.
@@ -64,16 +61,15 @@ errors.
 
 ## Edge cases
 
-| Case                                            | Behavior                                                                                                                                                                                                                                                                                                                                                                                                                                 |
-| ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **No contract yet**                             | Error pointing at `lumo task criteria set`; draft the contract first (criteria.md golden rule).                                                                                                                                                                                                                                                                                                                                          |
-| **HUMAN-only contract** (zero MACHINE criteria) | Nothing to run; CLI says so and suggests `lumo task update <id> --status in_review` for human review. No server write happens.                                                                                                                                                                                                                                                                                                           |
-| **Partial round**                               | A round must cover every MACHINE criterion; the CLI always runs all of them and the server rejects partial rounds.                                                                                                                                                                                                                                                                                                                       |
-| **`REVIEW_ADDED` criteria**                     | Criteria added during review appear in the contract and are picked up automatically by the next round.                                                                                                                                                                                                                                                                                                                                   |
-| **Session bound to a different task**           | Server returns 409, surfaced as an error. No advisory printed; the verify round is rejected outright.                                                                                                                                                                                                                                                                                                                                    |
-| **Ungrounded EXTERNAL_FACT PASS** (LUM-605)     | A reported PASS on a criterion declared `EXTERNAL_FACT` whose checkpointer doesn't invoke external tooling (e.g. `npx jest …`) is blocked with **422 — no round burned**; the task does **not** move to IN_REVIEW. Fix it for free: re-ground the checkpointer against a real external fact, or honestly re-declare `referentKind` as `AGENT_CONSTRUCTED_STATE` (`lumo task criteria set`), then re-run. See criteria.md "referentKind". |
-| **Provably-unbound session**                    | Response carries `bindingAdvisory: 'unbound'`; prints `⚠ Working unbound — this verify ran from a Claude Code session not attached to the task.` Recorded as a `SESSION_BINDING_MISSING` boundary crossing (visible in `lumo task status` open crossings). Run `lumo session attach <LUM-N>` before the next verify.                                                                                                                     |
-| **Unconfirmed session binding**                 | `bindingAdvisory: 'unconfirmed'` → softer advisory `⚠ Could not confirm this session is attached to the task.` Same remediation: `lumo session attach <LUM-N>`.                                                                                                                                                                                                                                                                          |
+| Case                                            | Behavior                                                                                                                                                                                                                                                                                                             |
+| ----------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **No contract yet**                             | Error pointing at `lumo task criteria set`; draft the contract first (criteria.md golden rule).                                                                                                                                                                                                                      |
+| **HUMAN-only contract** (zero MACHINE criteria) | Nothing to run; CLI says so and suggests `lumo task update <id> --status in_review` for human review. No server write happens.                                                                                                                                                                                       |
+| **Partial round**                               | A round must cover every MACHINE criterion; the CLI always runs all of them and the server rejects partial rounds.                                                                                                                                                                                                   |
+| **`REVIEW_ADDED` criteria**                     | Criteria added during review appear in the contract and are picked up automatically by the next round.                                                                                                                                                                                                               |
+| **Session bound to a different task**           | Server returns 409, surfaced as an error. No advisory printed; the verify round is rejected outright.                                                                                                                                                                                                                |
+| **Provably-unbound session**                    | Response carries `bindingAdvisory: 'unbound'`; prints `⚠ Working unbound — this verify ran from a Claude Code session not attached to the task.` Recorded as a `SESSION_BINDING_MISSING` boundary crossing (visible in `lumo task status` open crossings). Run `lumo session attach <LUM-N>` before the next verify. |
+| **Unconfirmed session binding**                 | `bindingAdvisory: 'unconfirmed'` → softer advisory `⚠ Could not confirm this session is attached to the task.` Same remediation: `lumo session attach <LUM-N>`.                                                                                                                                                      |
 
 ## Round discipline
 
@@ -105,8 +101,9 @@ nothing and burns no round. Defaults to the session-bound task; an explicit
 identifier overrides.
 
 ```bash
-lumo task status            # session-bound task
+lumo task status            # session-bound task (core: criteria / next actions / open crossings)
 lumo task status LUM-42     # explicit task
+lumo task status --full     # + verification rollup, history, cost, struggle trail, trend
 lumo task status --json     # versioned machine-readable payload
 ```
 
@@ -125,19 +122,16 @@ what's unmet and why (the exact failure tails), and how many rounds are left.
 ### What it prints
 
 - **Header** — task identifier/title/status + `verification round N/M` (`M` = the workspace's `verificationMaxRounds`; round 0 = never verified) + an escalation warning when the machine loop is exhausted.
-- **Claim vs verification** — 规律 2 声称vs核验: the headline contrast, printed right after the header (whenever the contract exists), so the report shows **both** columns instead of only the verification one. Two sides:
-  - **Claim** — what the agent _says_ it did: an **unverified self-report** (`agent self-report · estimated, not verification`), estimate-tier provenance (估, not 测). Sourced by layering (LUM-597, preference `AGENT > RUN_SUMMARY > DIGEST > null`): if you supplied a `lumo verify --note`, that **own self-report** is the claim (`↳ source: agent self-report (verify --note)`) — the汇报者's voice, what faithfulness judges. Absent a self-report (old CLI / non-verify path) it degrades to the summarizer paraphrase, labelled honestly (`↳ source: synthesized run summary (no self-report)`). **Fail-closed**: when only a raw STOP turn digest exists it prints `generating — the formal run summary is still being synthesized` and **withholds the raw digest**; with no material at all it prints `not generated yet — …`, never a fabricated claim.
-  - **Verification** — what was actually _confirmed_ (measured): the machine-verification rollup `N machine-verified / M human override (of T MACHINE criteria)` over the active MACHINE criteria (relocated here from its old standalone line under `Criteria`), plus `X of Y criteria met by their latest verdict`. **Fail-closed**: before any round runs it prints `no verification has run yet — the claim is unconfirmed` rather than implying a pass.
-  - **Faithfulness** — the third state over the two columns: whether the CLAIM itself is _true_, read from the persisted faithfulness verdict (no LLM at read time), printed as `▸ Faithfulness — does the claim match the delivery`. One of `faithful` / `overstated` (claim says more than the diff/PR shows) / `under-reported` (claim says less) / `unjudgeable`, with an `· evidence: PR #N · <sha>` pointer when the judge cited one. **Fail-closed**: `not yet judged` (no verdict — distinct from a real `unjudgeable` verdict) and `… (stale — re-checked on the next batch)` (judged against an older claim snapshot, the verdict still shown) are surfaced explicitly. Omitted only against an older server that doesn't emit it.
-  - Carried in `--json` as `claim { text, source }` (`source: 'AGENT' | 'RUN_SUMMARY' | 'DIGEST' | null`; `AGENT` = the verify self-report, `RUN_SUMMARY`/`DIGEST` = the synthesized fallback; `text: null` = none generated) and `faithfulness { state, verdict, evidence, diffShas, prNumbers, judgedAt, judgedClaimAt }` (`state` adds `PENDING`/`STALE` over the four verdicts). Omitted only against an older server that doesn't emit the field. The machine-verification rollup is still carried top-level as `machineVerification`.
+- **Default = the self-check core (LUM-733):** header, Criteria, Last round failures, Next actions, Open boundary crossings. The dashboard sections below (**Verification**, **History**, **Cost**, **Struggle**, **Trend**) print only with `--full` — they are human-dashboard material and cost context. The claim text and faithfulness verdict are no longer rendered in the terminal (`--json` still carries `claim` / `faithfulness` for scripts).
+- **Verification** (`--full`) — the measured rollup `N machine-verified / M human override (of T MACHINE criteria)` plus `X of Y criteria met by their latest verdict`; before any round it prints `no verification has run yet`.
 - **Criteria** — every criterion as `<glyph> <id>  [TYPE]  SOURCE@rN statement` (✓ latest verdict passed / ✗ failed / ○ no verdict yet) with its checkpointer and latest verdict line (failure tail on fail). `REVIEW_ADDED@rN` provenance is visible per row.
   - A passing **MACHINE** criterion's verdict line carries a machine-state tag derived from the read model's `machinePassed` flag, NOT the latest verdict: `· machine-verified` when a checkpointer actually passed it (even after a human later signs the task off), or `· human override (no machine pass)` when it passes only on a human sign-off with no machine run underneath. This keeps the terminal honest with web — a machine-verified criterion that a human co-signed no longer reads as a plain human pass.
   - A verdict's **evidence is drillable**, rendered as an indented `↳ evidence:` line under the verdict (PASS _and_ FAIL) instead of the inert raw pointer that used to ride the verdict line — so a conclusion points at real proof you can act on, not just the `check:` command: a `cmd:` pointer prints the actual command + exit code (`ran \`…\` → exit N · re-run to reproduce`), a `file:`pointer prints a terminal-clickable`path:line`, and a `commit:` pointer prints a navigable web URL (`<repo>/commit/<hash>`, resolved from the local git `origin`remote) or a`git show <hash>`fallback when no remote resolves. A criterion that **requires evidence but has none recorded yet** (e.g. a HUMAN evidence criterion before sign-off) renders an explicit`↳ evidence: pending — no reference recorded yet`(fail-closed) instead of a bare, dead`[evidence]` tag.
   - A pass can carry a **`⚠ pre-edit version`** note: the criterion was changed after that verdict (reworded, or its checkpointer was swapped so the recorded evidence ran a different command). The pass still counts as met (a stale pass does not block DONE — render-only signal), but it vouches for an older version — **re-run `lumo verify` to re-confirm against the current criterion.** This is the habit whenever you edit a MACHINE criterion's checkpointer mid-task: change the check, then re-verify so the green is honest.
-- **History** — one line per recorded round: `rN · timestamp · X PASS / Y FAIL`.
+- **History** (`--full`) — one line per recorded round: `rN · timestamp · X PASS / Y FAIL`.
 - **Last round failures** — the most recent round's FAIL verdicts with their rejection reasons (why the last round bounced).
-- **Cost** — 规律 1: the costs a human should weigh, on the same report as the verdict instead of scattered across the web delivery card and `task lineage`. Three lines: **Tokens** (total input+output+cache across the task's sessions), **Active time** (non-idle agent seconds — Σ per-turn `STOP − prompt`), and **Rework rounds** (verify rounds that recorded a FAIL). Read from the **same** server-side source the web delivery card consumes (`retrospectiveRepository.loadActuals`), so the two reports cannot drift. Token cost is **fail-closed**: when no session usage was recorded it prints `Tokens: not recorded (no session usage captured)`, kept distinct from a measured `0` (没测到 vs 花了0). Carried in `--json` as `cost { tokenCost, activeTimeSec, reworkRounds }` (`tokenCost: null` = not measured). Omitted only against an older server that doesn't emit the field.
-- **Struggle / rework / outstanding** — the anti-mum-and-deaf block: **always printed when the contract exists, even on a clean 0-unmet task** so a passing task still shows its scars instead of wiping them to a single PASS count. Lists, when present:
+- **Cost** (`--full`) — 规律 1: the costs a human should weigh, on the same report as the verdict instead of scattered across the web delivery card and `task lineage`. Three lines: **Tokens** (total input+output+cache across the task's sessions), **Active time** (non-idle agent seconds — Σ per-turn `STOP − prompt`), and **Rework rounds** (verify rounds that recorded a FAIL). Read from the **same** server-side source the web delivery card consumes (`retrospectiveRepository.loadActuals`), so the two reports cannot drift. Token cost is **fail-closed**: when no session usage was recorded it prints `Tokens: not recorded (no session usage captured)`, kept distinct from a measured `0` (没测到 vs 花了0). Carried in `--json` as `cost { tokenCost, activeTimeSec, reworkRounds }` (`tokenCost: null` = not measured). Omitted only against an older server that doesn't emit the field.
+- **Struggle / rework / outstanding** (`--full`) — the anti-mum-and-deaf block: **always printed when the contract exists, even on a clean 0-unmet task** so a passing task still shows its scars instead of wiping them to a single PASS count. Lists, when present:
   - **rework rounds** — verify rounds that had a FAIL;
   - **send-backs** — criteria sent back by a human/agent verdict (a MACHINE verify-loop FAIL is not a 打回), with their open/resolved lifecycle, preserved even for since-removed criteria;
   - **leftover follow-ups** — criteria whose latest verdict is `PASS_WITH_FOLLOWUP`;
@@ -146,9 +140,12 @@ what's unmet and why (the exact failure tails), and how many rounds are left.
 
   When the trail is genuinely empty it states the **basis** (`None recorded — N rounds run, 0 FAIL, no send-backs, no reopens, no leftover follow-ups`); when nothing has been verified yet it says so (`No verification has run yet — cannot confirm there were no difficulties`) rather than rendering an implicitly-clean slate. Carried in `--json` as `struggleTrail` (incl. `pullRequests` + `reopens`).
 
-- **Trend** — 规律 7 趋势非快照: the _movement_ of the key quantities across the task's attempts, not a single snapshot. Where History/Cost/Struggle list current values, this shows direction: **Pass rate** across verification rounds (`r1 60% → r2 100% (↑ +40pts)`), **Cost/session** across the task's sessions (`4.2K → 1.1K tokens (↓), 5.3K total` — per-session spend from the same source as the **Cost** total, so the trajectory's points sum to it), and **Rework** accrual (`3 accrued — 1 FAIL round, 1 reopen, +1 PR cycle (↑ from 0)`). **Honest about a single point:** with only one round and one session every quantity is one data point, so it prints `Single attempt so far — no trajectory yet (a trend needs ≥2 rounds or sessions)` rather than drawing a fake arrow off one value. When nothing was verified and no cost was measured it says `No verification rounds or measured cost yet — nothing to trend`. Carried in `--json` as `trend { passRate[], cost[], rework{} }`. Omitted only against an older server.
+- **Trend** (`--full`) — 规律 7 趋势非快照: the _movement_ of the key quantities across the task's attempts, not a single snapshot. Where History/Cost/Struggle list current values, this shows direction: **Pass rate** across verification rounds (`r1 60% → r2 100% (↑ +40pts)`), **Cost/session** across the task's sessions (`4.2K → 1.1K tokens (↓), 5.3K total` — per-session spend from the same source as the **Cost** total, so the trajectory's points sum to it), and **Rework** accrual (`3 accrued — 1 FAIL round, 1 reopen, +1 PR cycle (↑ from 0)`). **Honest about a single point:** with only one round and one session every quantity is one data point, so it prints `Single attempt so far — no trajectory yet (a trend needs ≥2 rounds or sessions)` rather than drawing a fake arrow off one value. When nothing was verified and no cost was measured it says `No verification rounds or measured cost yet — nothing to trend`. Carried in `--json` as `trend { passRate[], cost[], rework{} }`. Omitted only against an older server.
 
-- **Next actions** — the unmet criteria (latest verdict is not a pass: failed or never verified, HUMAN ones included). This list IS the plan — recomputed from the event log on every read, never maintained separately. Empty + rounds recorded = awaiting human adjudication.
+- **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)`. 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 RAN · external RAN (2 external findings) · supplyChain RAN (1 dependency finding, 1 already on main) · judge RAN · hunt PARTIAL` — stage segments only for keys present, in secrets/external/supplyChain/judge/hunt order (`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 or subgraph cap hit) / `FAILED`; its findings are `LLM_JUDGE` advisory, never `blocks DONE`); `(N external findings)` (singular at 1) decorates only the external segment, and only when N > 0; `(N dependency findings[, M already on main])` (LUM-738; singular at 1) decorates only the supplyChain segment, only when N > 0, and prints bare `supplyChain <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.
+  - **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 the web acceptance panel. Silent when there are none, so it never overshadows the criteria.
   - **Read-only awareness** — this surfaces crossings detected elsewhere; there is no CLI path to disposition or clear one. Disposition stays web + human-only: an agent/CLI bearer cannot clear its own crossing from the terminal.
   - **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".
@@ -181,50 +178,33 @@ fields don't. Pin on `version` when scripting against it.
 - the payload carries a top-level `machineVerification` aggregate `{ total, machineVerified, humanOverridden }` over the active MACHINE criteria — read these, not `latestVerdict` alone, to tell a machine-verified criterion from a human override;
 - open boundary crossings ride along as an additive top-level `openCrossings`, each entry `{ id, category, severity, detail, attribution }` where `attribution` is `{ workspaceMemberId, sessionId, agent, worktreeBranch, model }` with every field nullable — null = unknown, never fabricated; the array length is the count. Same read-only awareness, no write path;
 - **`openCrossings` is `null` when the crossings check failed** — distinct from `[]` (a successful read with zero open crossings). Script consumers must treat `null` as "unknown / could not confirm", **not** "safe".
+- `nextActions` entries carry a `kind` discriminator (LUM-737): `CRITERION` (the pre-737 shape: `criterionId`, `statement`, `verifierType`, `checkpointer`, `judgeSteps`, `source`, `addedAtRound`, `rejectionReason`) or `SECURITY_FINDING` (`findingId`, `statement`, `severity`, `provenance`, `blocking`, `prNumber`, `ruleId`, `filePath`, `line`). Additive — a missing `kind` means `CRITERION`; do not index every entry by `criterionId`;
+- a top-level `securityFindings` summary `{ open, blocking, unconfirmedPrs: [{ number, reason: NONE|FAILED|PENDING|RUNNING }], scans?: [{ prNumber, status, stages, partial, error, externalFindings, openFindings }] }`; **`null` means the scan read failed** — treat as "unknown / could not confirm", not "safe". `scans` is additive (LUM-735) — absent against an older server, one entry per linked PR with a latest scan otherwise.
 
 `status` reads; `verify` judges. Running status never starts a round, never
 escalates, and never changes task state — loop rules (the workspace round cap,
 IN_REVIEW on all-pass, human-only DONE) live entirely in `lumo verify` and the
 server.
 
-## lumo verdict — the three verdict channels
+## Verdict channels
 
-`lumo verify` is the MACHINE channel. `lumo verdict` covers the other two — the
-HUMAN pass and the AGENT send-back — under one red line: **no passing data row is
-ever agent-produced.**
-
-```bash
-lumo verdict --pass
-lumo verdict LUM-42 --pass
-lumo verdict --fail --reason CRITERION_UNMET --note "the retry path is still missing"
-lumo verdict LUM-42 --fail --reason scope_mismatch --criterion c-abc123
-```
-
-### --pass — a deep link, never a write
-
-This resolves the task, then opens the browser to its verdict bar focused on
-Pass. **The CLI writes nothing** — PASS only ever lands from a human's own click
-(Clerk session). Use this to hand a finished task to a human for the final pass;
-it carries them one click from recording it.
-
-### --fail — the AGENT send-back
-
-`--fail --reason <enum>` records a real verdict row server-side with
-verifierType=AGENT (a channel distinct from MACHINE and HUMAN, so "machine
-all-pass but human FAIL" stays an uncontaminated signal). The verdict is
-hard-coded FAIL — there is no agent path to a passing verdict. It:
-
-- `--reason <enum>` required (case-insensitive): `CRITERION_UNMET | EVIDENCE_INSUFFICIENT | CHECK_EXECUTION_ERROR | SCOPE_MISMATCH | OTHER` — the agent pays the structured tax a human send-back is spared;
-- `--note <text>` optional, posted as a task comment (@mentions and images for free) and summarized onto the verdict row;
-- `--criterion <id>` repeatable, narrows the send-back; omitted, it fans out to the whole contract;
-- `round` = the current max (not a new round); bounces the task back to IN_PROGRESS, with the unmet criteria surfacing through `lumo task status`.
+`lumo verify` is the MACHINE channel. The only other channel is the **human**
+one: a person records PASS or a send-back (FAIL) in the web verdict bar (Clerk
+session). There is no agent-facing verdict command — the former
+`lumo verdict --fail` AGENT send-back was removed in LUM-733 (17 rows all-time,
+none in the last 30 days); when the machine loop runs out of rounds the task is
+escalated to a human instead. **No passing data row is ever agent-produced.**
 
 ### The DONE gate
 
-Once any criterion's latest verdict is FAIL — machine, AGENT, or human — moving
+Once any criterion's latest verdict is FAIL — machine or human — moving
 the task to DONE on the agent/CLI path is refused with **409** and the unresolved
 items listed. Clear the send-back (fix + re-verify, or a human PASS) before
-`lumo task update <id> --status done`.
+`lumo task update <id> --status done` — which itself walks the confirmation
+protocol: without `--confirm` it exits 4 with an envelope for the user to
+approve, and when the server gate still refuses it exits 5 with a structured
+`DONE_BLOCKED` error listing every blocker (LUM-755, see [tasks.md](tasks.md)
+and [confirmation.md](confirmation.md)).
 
 - A task with no criteria, or whose criteria were never adjudicated, transitions freely — **the gate only blocks an actual send-back, never an un-adjudicated criterion.**
 - When the machine loop has left a task IN_REVIEW with no send-back standing, the agent may move it to DONE directly; a human-PASS row is a provable manual override, not a required ticket.
@@ -259,9 +239,7 @@ When someone reports a defect in conversation, your action depends on whether th
 task has **ever entered IN_REVIEW**:
 
 - **Not yet** (still your first working pass) → just fix it and continue. No verdict needed — nothing was claimed complete, so there's nothing to contradict.
-- **Already submitted** (entered IN_REVIEW / DONE / merged) → **do not silently fix and re-pass.** Either:
-  - record your own send-back `lumo verdict --fail` (noting it was human-reported — this is _your_ honest concurrence, not a forged human verdict), or
-  - ask the reporter to record a human FAIL via the web UI / Slack (the only channel that can attribute it to a human).
+- **Already submitted** (entered IN_REVIEW / DONE / merged) → **do not silently fix and re-pass.** Ask the reporter to record a human send-back (FAIL) via the web verdict bar / Slack — the only channel that can attribute it to a human — then fix in place and re-run `lumo verify` so the fix lands as a fresh machine round on the record.
 
 If the defect is a **new requirement** not covered by any criterion, first
 transcribe it with `lumo task criteria set --human`, then proceed. You can never

package/assets/skill/references/worktree.md

@@ -55,15 +55,21 @@ Errors if the target dir already exists; reuses the branch if it already exists
 
 ## `lumo worktree rm <LUM-N>`
 
-Removes the worktree for a task. Requires `--yes`. Refuses a dirty worktree
-unless `--force`. Keeps the branch by default (it may hold unpushed work / an
-open PR); `--delete-branch` removes it with `git branch -d` (which itself
-refuses an unmerged branch).
+Removes the worktree for a task. Gated by the confirmation protocol
+([confirmation.md](confirmation.md)): without `--confirm` — or with
+uncommitted changes and no `--force` — it exits **4** with an envelope naming
+the path and branch, a `⚠ … uncommitted changes … discarded` line when dirty,
+and whether the branch is kept or deleted; nothing is removed. A dirty tree's
+`confirmCommand` carries `--force --confirm`. `--yes` is a legacy alias of
+`--confirm`. Keeps the branch by default (it may hold unpushed work / an open
+PR); `--delete-branch` removes it with `git branch -d` (which itself refuses
+an unmerged branch).
 
 ```bash
-lumo worktree rm LUM-267 --yes
-lumo worktree rm LUM-267 --yes --force            # discard uncommitted changes
-lumo worktree rm LUM-267 --yes --delete-branch    # also delete lumo/LUM-267…
+lumo worktree rm LUM-267                              # exit 4 + envelope
+lumo worktree rm LUM-267 --confirm                    # after the user approved (clean tree)
+lumo worktree rm LUM-267 --force --confirm            # dirty tree: discard uncommitted changes
+lumo worktree rm LUM-267 --confirm --delete-branch    # also delete lumo/LUM-267…
 ```
 
 ## `lumo worktree list`

package/dist/cli/src/commands/doc-delete.js

@@ -1,18 +1,23 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
+exports.describeDocDelete = describeDocDelete;
 exports.docDelete = docDelete;
 const config_1 = require("../lib/config");
 const api_1 = require("../lib/api");
-const resolve_doc_1 = require("../lib/resolve-doc");
 const resolve_doc_id_1 = require("../lib/resolve-doc-id");
 const sanitize_1 = require("../lib/sanitize");
+const confirmation_1 = require("../lib/confirmation");
+/** The changes[] block for the confirmation envelope. */
+function describeDocDelete(id, title) {
+    const escaped = (0, sanitize_1.sanitizeField)(title).replace(/"/g, '\\"');
+    return [
+        `Will delete document ${id} "${escaped}"`,
+        'Every document nested under it is deleted with it; task bindings and shares are dropped',
+    ];
+}
 async function docDelete(reference, opts) {
     if (!reference) {
-        console.error('Error: missing <doc>. Usage: lumo doc delete <doc> --yes');
-        return 1;
-    }
-    if (!opts.yes) {
-        console.error('Error: Refusing to delete without --yes');
+        console.error('Error: missing <doc>. Usage: lumo doc delete <doc> --confirm');
         return 1;
     }
     const creds = (0, config_1.readCredentials)();
@@ -21,26 +26,33 @@ async function docDelete(reference, opts) {
         return 1;
     }
     const apiUrl = (0, api_1.resolveAuthedApiUrl)(creds.apiUrl);
-    // For a cuid reference we don't have the title; for a title we look up id+title at once.
-    let id;
-    let title = '';
-    if ((0, resolve_doc_1.isLikelyCuid)(reference)) {
-        id = reference;
+    const base = (0, api_1.trimTrailingSlash)(apiUrl);
+    const headers = { Authorization: `Bearer ${creds.token}` };
+    const id = await (0, resolve_doc_id_1.lookupDocId)(apiUrl, creds.token, reference);
+    if (!id) {
+        console.error(`Error: Document not found: ${reference}`);
+        return 1;
+    }
+    // Always fetch the doc first: the envelope needs its real title, and the
+    // same GET confirms it exists before anything destructive happens.
+    const showRes = await fetch(`${base}/api/documents/${id}`, { headers });
+    if (!showRes.ok) {
+        const text = await showRes.text();
+        console.error(`Error: ${showRes.status} ${showRes.statusText}: ${(0, sanitize_1.sanitizeField)(text)}`);
+        return 1;
     }
-    else {
-        const fetched = await (0, resolve_doc_id_1.lookupDocId)(apiUrl, creds.token, reference);
-        if (!fetched) {
-            console.error(`Error: Document not found: ${reference}`);
-            return 1;
-        }
-        id = fetched;
-        // Pick up the title from the lookup payload by repeating the GET — small extra cost.
-        // (Alternative: change lookupDocId to return the full DocLike. For now keep it simple.)
-        title = reference;
+    const { document } = (await showRes.json());
+    const title = document.title ?? '';
+    // LUM-755: no --confirm → envelope, no DELETE.
+    if (!(0, confirmation_1.isConfirmed)(opts)) {
+        return (0, confirmation_1.emitConfirmation)({
+            command: 'doc delete',
+            changes: describeDocDelete(id, title),
+        });
     }
-    const res = await fetch(`${(0, api_1.trimTrailingSlash)(apiUrl)}/api/documents/${id}`, {
+    const res = await fetch(`${base}/api/documents/${id}`, {
         method: 'DELETE',
-        headers: { Authorization: `Bearer ${creds.token}` },
+        headers,
     });
     if (!res.ok) {
         const text = await res.text();

package/dist/cli/src/commands/doc-rebuild-source.js

@@ -5,6 +5,7 @@ const config_1 = require("../lib/config");
 const api_1 = require("../lib/api");
 const resolve_doc_id_1 = require("../lib/resolve-doc-id");
 const sanitize_1 = require("../lib/sanitize");
+const confirmation_1 = require("../lib/confirmation");
 /**
  * `lumo doc rebuild-source <doc>` (LUM-446).
  *
@@ -13,7 +14,9 @@ const sanitize_1 = require("../lib/sanitize");
  * re-enabling `doc show --raw` / `diff` / `patch` / `append`. The rebuilt source
  * is structure-guarded server-side: any table/tr/heading shrink is rejected 422
  * (zero silent flattening — LUM-410 口径) unless --allow-shrink is passed. A doc
- * that already has a source is refused 409 unless --force re-derives it.
+ * that already has a source is refused 409 unless --force re-derives it —
+ * that refusal is surfaced as a confirmation envelope (LUM-755): exit 4 with
+ * the server's reason and a confirmCommand carrying `--force --confirm`.
  */
 async function docRebuildSource(reference, opts) {
     if (!reference) {
@@ -57,11 +60,20 @@ async function docRebuildSource(reference, opts) {
     if (!res.ok) {
         const text = await res.text();
         const message = (0, api_1.extractErrorMessage)(text);
+        if (res.status === 409 && !opts.force) {
+            // The --force gate: nothing was written. Hand back the protocol
+            // envelope so the agent shows the user what --force would replace.
+            return (0, confirmation_1.emitConfirmation)({
+                command: 'doc rebuild-source',
+                changes: [
+                    (0, sanitize_1.sanitizeField)(message),
+                    `Will replace the existing (byte-faithful) markdown source of ${id} with a freshly serialized one — inspect it first with \`lumo doc show ${reference} --raw\``,
+                ],
+                extraFlags: ['--force'],
+            });
+        }
         if (res.status === 409) {
             console.error(`Error: ${(0, sanitize_1.sanitizeField)(message)}`);
-            console.error('Hint: the doc already has a markdown source. Inspect it with ' +
-                `\`lumo doc show ${reference} --raw\`; pass --force only if you intend ` +
-                'to replace it with a freshly serialized one.');
             return 1;
         }
         if (res.status === 422) {