@lumoai/cli 1.41.0 → 1.42.0

package/assets/skill/references/sessions.md

@@ -4,53 +4,50 @@
 
 ### Suggest-on-start from local git (no auto-bind)
 
-When a session starts **without** a bound task, the `session-start` hook tries to
-infer the task from local git so it can **suggest** one — it never binds for you
-(LUM-302):
-
-- It reads the **current branch name** first (e.g. `lumo/LUM-145-...`), then the
-  **most recent commit subjects** (e.g. `... [LUM-145]`), extracting the first
-  task identifier. Detection is **prefix-agnostic** (LUM-419): any team prefix
-  matches — `SPEC-12` as much as `LUM-145` — using the same pattern the server
-  uses to link PR branches to tasks. Well-known acronym-number tokens
-  (`UTF-8`, `SHA-256`, `ISO-8601`, …) are skipped, never suggested.
-- On a hit it prints a single suggestion line and stops — the session stays
-  **unbound** and no context is injected yet:
-  `Detected LUM-145 (from branch name). Run lumo session attach LUM-145 to bind.`
-  (the basis reads `from recent commits` when the hit came from commit subjects instead of the branch name)
-  No task title is shown here because nothing was fetched; the title, memory,
-  and PR-review todos appear only once you actually attach.
-- No match (detached HEAD, a branch with no identifier and no tagged commits,
-  not a git repo) → it degrades to the normal unbound prompt.
-
-**Agent guidance:** when you see a suggestion line, confirm the inferred task is
-the one the user wants, then run `lumo session attach <LUM-N>` (followed by
-`lumo task context <LUM-N>` to load the background). `session attach` is the
-**only** path that binds — there is nothing to "undo" if the inference is wrong;
-just attach the correct task instead.
+When a session starts **without** a bound task, the `session-start` hook infers a task from local git and **suggests** it — it never binds for you (LUM-302).
+
+Detection order and rules:
+
+- `current branch name` first (e.g. `lumo/LUM-145-...`), then the `most recent commit subjects` (e.g. `... [LUM-145]`), extracting the first task identifier.
+- `prefix-agnostic` (LUM-419) — any team prefix matches (`SPEC-12` as much as `LUM-145`), using the same pattern the server uses to link PR branches to tasks.
+- `well-known acronym-number tokens` (`UTF-8`, `SHA-256`, `ISO-8601`, …) are skipped, never suggested.
+
+On a hit it prints one suggestion line and stops — the session stays **unbound**, no context injected yet:
+
+```
+Detected LUM-145 (from branch name). Run lumo session attach LUM-145 to bind.
+```
+
+- The basis reads `from recent commits` when the hit came from commit subjects instead of the branch name.
+- No task title is shown here (nothing was fetched); title, memory, and PR-review todos appear only once you attach.
+- No match (detached HEAD; a branch with no identifier and no tagged commits; not a git repo) → degrades to the normal unbound prompt.
+
+#### When to suggest
+
+You see a suggestion line. Confirm the inferred task is the one the user wants, then run `lumo session attach <LUM-N>` followed by `lumo task context <LUM-N>` to load the background. `session attach` is the **only** path that binds — there is nothing to "undo" if the inference is wrong; just attach the correct task instead.
 
 ### Layer 2 project-memory review at session start
 
 When the session is bound, session-start may inject a **"🆕 Review needed: project memories auto-consolidated by the previous session"** section alongside the memory / PR-review blocks (LUM-165). It lists the **PROJECT-scope** memories that the member's **immediately-preceding session** auto-consolidated (Layer 2 runs asynchronously when a task is marked `done`). Each item shows its `id`.
 
-- **Why it's here:** Layer 2 promotions land async (after the task hits DONE), so they're surfaced at the _next_ session-start instead, when they've definitely landed.
-- **Show-once:** the section appears only at the session that immediately follows the one that produced the memories. It does **not** re-nag on later sessions, so act on it now or it scrolls off.
-- **Agent guidance:** briefly sanity-check each listed memory against the codebase/context. If one is wrong or over-generalized, remove it with `lumo memory rm <id> --yes` (ideally confirm with the user first). If they all look right, ignore the section and continue.
+- **Why async / next-session:** Layer 2 promotions land after the task hits DONE, so they surface at the _next_ session-start, when they've definitely landed.
+- **Show-once:** the section appears only at the session immediately following the one that produced the memories. It does **not** re-nag later, so act now or it scrolls off.
+- **Attribution:** `lumo task update <id> --status done` automatically sends `CLAUDE_CODE_SESSION_ID` (via `X-Lumo-Session-Id`) so the Layer 2 memories are attributed to the session. Marking done from the **web UI** leaves them unattributed (they won't surface for review) — expected.
 
-Attribution requires the CC session id to reach the server: `lumo task update <id> --status done` automatically sends `CLAUDE_CODE_SESSION_ID` (via an `X-Lumo-Session-Id` header) so the resulting Layer 2 memories are attributed to the session. Marking a task done from the **web UI** leaves them unattributed (they won't surface for review) — that's expected.
+#### When to suggest
+
+Briefly sanity-check each listed memory against the codebase/context. If one is wrong or over-generalized, remove it with `lumo memory rm <id> --yes` (ideally confirm with the user first). If they all look right, ignore the section and continue.
 
 ### Blocker alert injected at `session attach` / session-start
 
-When the bound task has live blockers or SUGGESTED dependency candidates, the attach output and session-start hook context inject a dependency warning block. The warning is built by `buildBlockerWarningSectionForTask` and is **omitted entirely** (empty string) when nothing is actionable — no output appears when there are no live blockers and no SUGGESTED candidates.
+When the bound task has live blockers or SUGGESTED dependency candidates, the attach output and session-start hook context inject a dependency warning block. Built by `buildBlockerWarningSectionForTask`; **omitted entirely** (empty string) when nothing is actionable — no output when there are no live blockers and no SUGGESTED candidates. The function never throws — on failure it silently returns an empty string, leaving session start unaffected.
 
-**Trigger conditions (OR — either or both may appear):**
+Trigger conditions (OR — either or both may appear):
 
 1. At least one CONFIRMED "blocked by" edge where the blocking task's status is not DONE.
 2. At least one SUGGESTED (unconfirmed) dependency candidate on the task.
 
-**Output form A — live blockers exist (with or without SUGGESTED candidates):**
-
-Starts with the `## ⚠ Dependency alerts` header, followed by one line per live blocker, then the advice line. If there are also SUGGESTED candidates the candidate-hint line is appended after the advice line.
+**Form A — live blockers exist (with or without SUGGESTED candidates):** `## ⚠ Dependency alerts` header, one line per live blocker, then the advice line. If SUGGESTED candidates also exist, the candidate-hint line is appended after the advice line.
 
 ```
 ## ⚠ Dependency alerts
@@ -62,28 +59,28 @@ Consider waiting for the blocker(s) to merge before starting work to avoid a was
 Detected 3 candidate dependencies awaiting confirmation: run `lumo task deps list LUM-42`.
 ```
 
-**Output form B — NO live blockers, but SUGGESTED candidates exist:**
-
-Output is **only** the hint line — no `## ⚠ Dependency alerts` header, no advice line. Design rationale: pure candidates are a hint, not an alert — they don't get the ⚠ header, so real alerts aren't diluted.
+**Form B — NO live blockers, but SUGGESTED candidates exist:** the hint line **only** — no `## ⚠ Dependency alerts` header, no advice line. Rationale: pure candidates are a hint, not an alert, so they don't get the ⚠ header and real alerts aren't diluted.
 
 ```
 Detected 3 candidate dependencies awaiting confirmation: run `lumo task deps list LUM-42`.
 ```
 
-- Each blocker line shows: identifier, title, current status. If the blocking task has an open pull request, a `, PR #N not merged` note is appended — `, PR #N (draft) not merged` for draft PRs.
-- The guidance line ("Consider waiting for the blocker(s) to merge…") appears only when there is at least one live blocker (form A).
-- The function never throws — if it fails it silently returns an empty string, leaving the session start unaffected.
+- Each blocker line shows: identifier, title, current status. An open PR on the blocking task appends `, PR #N not merged` — `, PR #N (draft) not merged` for draft PRs.
+- The advice line ("Consider waiting for the blocker(s) to merge…") appears only when there is at least one live blocker (form A).
+
+#### When to suggest
 
-**Agent guidance — watch for EITHER the `## ⚠ Dependency alerts` header (form A) OR the standalone hint line (form B):**
+Watch for EITHER the `## ⚠ Dependency alerts` header (form A) OR the standalone hint line (form B).
 
-- **Form A — live blockers:** Evaluate whether to wait. If the blocking task's work overlaps with yours (same files, same API surface), starting immediately risks rework. Read the blocker's status and open PR note before deciding.
-- **Stale or wrong edge?** Run `lumo task deps list <LUM-N>` to inspect the full edge list, then `lumo task deps rm <LUM-N> <edge> --yes` (if manually added and now obsolete) or `lumo task deps dismiss <LUM-N> <edge>` (if a false positive from detection).
-- **Candidate hint present (form A or B)?** Run `lumo task deps list <LUM-N>` and review each SUGGESTED edge — confirm real ones, dismiss false positives. Leaving SUGGESTED edges unreviewed means repeated hints every session.
+- `lumo task deps list <LUM-N>` — inspect the full edge list (run for any candidate hint, form A or B; confirm real SUGGESTED edges, dismiss false positives — unreviewed edges mean repeated hints every session).
+- `lumo task deps rm <LUM-N> <edge> --yes` — drop a manually-added, now-obsolete edge.
+- `lumo task deps dismiss <LUM-N> <edge>` — dismiss a false positive from detection.
+- Form A live blockers: evaluate whether to wait — overlapping work (same files, same API surface) risks rework; read the blocker's status and open-PR note before deciding.
 - Do **not** blindly start work on a task whose live blocker is still IN_PROGRESS or IN_REVIEW unless the user explicitly decides to proceed in parallel.
 
 ### `lumo session attach <identifier>` — bind the current session to a task
 
-Use this whenever the user mentions a task ID. The command is the only way to bind a session to a task.
+Use this whenever the user mentions a task ID. It is the only way to bind a session to a task.
 
 ```bash
 lumo session attach LUM-42
@@ -91,17 +88,22 @@ lumo session attach LUM-42
 
 What it does:
 
-- Reads `CLAUDE_CODE_SESSION_ID` from the environment (Claude Code sets this automatically). If it is not set, the command errors out — it must run from inside a Claude Code session.
-- Calls `POST /api/sessions/<session_id>/bind-task` on the Lumo server, which sets the Session row's `taskId` and re-tags previously-untagged HookEvent rows in this session.
+- Reads `CLAUDE_CODE_SESSION_ID` from the environment (Claude Code sets it automatically); errors out if unset — must run from inside a Claude Code session.
+- Calls `POST /api/sessions/<session_id>/bind-task`, which sets the Session row's `taskId` and re-tags previously-untagged HookEvent rows in this session.
 - The binding lives entirely on the server (`Session.taskId`); subsequent hooks read it back via the session row. The CLI keeps no local sentinel.
+- Prints the task's **acceptance contract** (`## Acceptance criteria (contract)`, LUM-342) right after the bind confirmation — or, when a still-open task has none, the draft reminder to draft 3–7 criteria before the first line of code (see [criteria.md](criteria.md)). The same section is auto-injected at session start when already bound (highest priority in the injection budget, ahead of memory).
 
-- Prints the task's **acceptance contract** (`## Acceptance criteria (contract)`, LUM-342) right after the bind confirmation — or, when a still-open task has none, the draft reminder telling you to draft 3–7 criteria before the first line of code (see [criteria.md](criteria.md)). The same section is auto-injected at session start when the session is already bound (highest priority in the injection budget, ahead of memory).
-
-**After attaching, always run `lumo task context <identifier>` to load the task background.**
+After attaching, always run `lumo task context <identifier>` to load the task background.
 
 #### Auto-downsync on attach (LUM-551)
 
-A successful `session attach` also runs a **best-effort team-memory downsync** for the bound task's project — the same work as `lumo memory sync` (including the P4b code-anchor staleness check), so the team's memory lands in your local Claude Code memory store without a separate command. It is **throttle-gated**: the network is skipped entirely if this repo already synced within `LUMO_SYNC_THROTTLE_HOURS` (default **12h**), so re-attaches and same-day sessions are cheap. A sync failure is swallowed — it **never** changes the bind outcome. On a non-trivial sync the CLI prints one extra line (`memory sync → +N ~M -K`). Manual `lumo memory sync` stays unthrottled. Set `LUMO_DISABLE_MEMORY_AUTO=1` to turn the auto-downsync (and the hook auto-upsync — see [memory.md](memory.md)) off entirely; `--no-anchor-check` on `lumo memory sync` is unchanged.
+A successful `session attach` also runs a **best-effort team-memory downsync** for the bound task's project — the same work as `lumo memory sync` (including the P4b code-anchor staleness check), landing the team's memory in your local Claude Code memory store without a separate command.
+
+- **Throttle-gated:** network is skipped entirely if this repo already synced within `LUMO_SYNC_THROTTLE_HOURS` (default **12h**), so re-attaches and same-day sessions are cheap.
+- **Non-blocking:** a sync failure is swallowed — it **never** changes the bind outcome.
+- **Output:** on a non-trivial sync the CLI prints one extra line, `memory sync → +N ~M -K`.
+- Manual `lumo memory sync` stays unthrottled.
+- `LUMO_DISABLE_MEMORY_AUTO=1` turns off the auto-downsync (and the hook auto-upsync — see [memory.md](memory.md)) entirely; `--no-anchor-check` on `lumo memory sync` is unchanged.
 
 #### Lifetime lock (LUM-459)
 
@@ -113,63 +115,48 @@ Error: this session is permanently bound to LUM-7 "Other task". A session works
 
 There is no `--force` and no `session detach`. To work on a different task, open a new terminal / Claude Code session and run `lumo session attach <new-task>` there.
 
-**Agent guidance:** if `session attach` returns 409, do not retry or look for a workaround — start a fresh Claude Code session for the target task.
+#### When to suggest
+
+If `session attach` returns 409, do not retry or look for a workaround — start a fresh Claude Code session for the target task.
 
 ### Parallel sessions
 
-Each Claude Code session has its own `CLAUDE_CODE_SESSION_ID`. Two terminals running `claude code` and binding to different tasks will not interfere with each other — the bindings are scoped per session row server-side.
+Each Claude Code session has its own `CLAUDE_CODE_SESSION_ID`. Two terminals running `claude code` and binding to different tasks will not interfere — bindings are scoped per session row server-side.
 
 ### `lumo session status` — show current binding
 
-Prints which task the current Claude Code session is bound to, or "(no task)" if none. Requires `$CLAUDE_CODE_SESSION_ID` (i.e. must run inside Claude Code).
-
 ```bash
 lumo session status
 ```
 
-When to suggest: the user asks "which task am I on", "what's this session bound to", or you need to decide whether to suggest `session attach` for a mentioned task ID.
+Prints which task the current Claude Code session is bound to, or "(no task)" if none. Requires `$CLAUDE_CODE_SESSION_ID` (must run inside Claude Code).
+
+#### When to suggest
+
+The user asks "which task am I on", "what's this session bound to", or you need to decide whether to suggest `session attach` for a mentioned task ID.
 
 ### Automatic end-of-session housekeeping (no command — LUM-544)
 
-The old end-of-session command was **removed in LUM-544**. The three passes it
-used to run interactively now happen **automatically server-side**, all
-evidence-gated, best-effort, and silent — there is nothing for the agent to run
-or confirm. Two fire when the bound task reaches **DONE** (`lumo task update <id>
---status done`, which threads `CLAUDE_CODE_SESSION_ID` so attribution lands), one
-runs continuously off the failure/progress hooks.
-
-**1. Layer-1 memory curation (on DONE).** An LLM judge reviews the Layer-1
-memories each of the task's sessions recorded, against that session's event log,
-and **soft-invalidates only the clearly-wrong / self-contradictory ones**
-(invalidate-not-delete: the row flips to `INVALIDATED` and is excluded from
-injection but **kept for audit — never hard-deleted**). **Uncertain memories are
-left untouched** — the judge defaults to keeping. Promotion to project scope is
-**not** done here; that stays with the Layer-2 flow (surfaced at the next
-session-start, see above).
-
-**2. Fragment-usage audit (LUM-314, on DONE).** An LLM judge sees the fragments
-this session consumed (its lineage edges) plus the session's event log and votes
-which were **actually used**: confidently-used edges → **`used=true`**,
-confidently-unused → **`used=false`**, and **genuinely-uncertain edges stay
-`null`** (honest "not voted", not "unused"). Already-voted sessions are skipped;
-a cron backstop drains any backlog. **Why:** it upgrades the flywheel signal from
-"co-loaded" (constant) to "actually used" (discriminative); `task context` then
-prefers each fragment's usage-based merge rate, falling back to the presence rate
-when usage samples are thin.
-
-**3. Blocked-tag automation (LUM-544 §3, server-side).** When a session crosses
-the same-tool failure threshold (**≥ 3** same-type failures, aggregated from
-`POST_TOOL_USE_FAILURE` grouped by tool name + `STOP_FAILURE` turn-level
-failures), the server **auto-applies the shared `blocked` tag** to the bound
-task. This **inverts the old LUM-153 manual `y` gate** — no prompt, no human in
-the loop — and is safe because of three safeguards: **(idempotent)** at most one
-active auto-block per task, so re-crossing is a no-op; **(auto-untag on
-progress)** the next observable progress on the task (a successful tool call or a
-non-failure turn end) removes the tag; **(attribution)** the triggering session +
-model are recorded. A **human-applied** `blocked` tag has no auto-block record and
-is **never** auto-removed by progress.
-
-When to suggest: nothing to suggest — these run on their own. If a teammate asks
-why a task shows `blocked`, explain it's the auto-block (repeated same-tool
-failures) and that it clears itself once the task makes progress; a human can also
-remove the tag manually from the board.
+The old end-of-session command was **removed in LUM-544**. The three passes it ran interactively now happen **automatically server-side** — all evidence-gated, best-effort, and silent. There is nothing for the agent to run or confirm. Two fire when the bound task reaches **DONE** (`lumo task update <id> --status done`, which threads `CLAUDE_CODE_SESSION_ID` so attribution lands); one runs continuously off the failure/progress hooks.
+
+**1. Layer-1 memory curation (on DONE).** An LLM judge reviews the Layer-1 memories each of the task's sessions recorded, against that session's event log, and **soft-invalidates only the clearly-wrong / self-contradictory ones**: the row flips to `INVALIDATED` and is excluded from injection but **kept for audit — never hard-deleted**. **Uncertain memories are left untouched** (the judge defaults to keeping). Promotion to project scope is **not** done here — that stays with the Layer-2 flow (surfaced at the next session-start, see above).
+
+**2. Fragment-usage audit (LUM-314, on DONE).** An LLM judge sees the fragments this session consumed (its lineage edges) plus the session's event log and votes which were **actually used**:
+
+- confidently-used edges → `used=true`
+- confidently-unused → `used=false`
+- genuinely-uncertain edges stay `null` (honest "not voted", not "unused")
+
+Already-voted sessions are skipped; a cron backstop drains any backlog. **Why:** upgrades the flywheel signal from "co-loaded" (constant) to "actually used" (discriminative); `task context` then prefers each fragment's usage-based merge rate, falling back to the presence rate when usage samples are thin.
+
+**3. Blocked-tag automation (LUM-544 §3, server-side).** When a session crosses the same-tool failure threshold (**≥ 3** same-type failures, aggregated from `POST_TOOL_USE_FAILURE` grouped by tool name + `STOP_FAILURE` turn-level failures), the server **auto-applies the shared `blocked` tag** to the bound task. This **inverts the old LUM-153 manual `y` gate** — no prompt, no human in the loop — and is safe via three safeguards:
+
+- **idempotent:** at most one active auto-block per task, so re-crossing is a no-op.
+- **auto-untag on progress:** the next observable progress (a successful tool call or a non-failure turn end) removes the tag.
+- **attribution:** the triggering session + model are recorded.
+
+A **human-applied** `blocked` tag has no auto-block record and is **never** auto-removed by progress.
+
+#### When to suggest
+
+Nothing to suggest — these run on their own. If a teammate asks why a task shows `blocked`, explain it's the auto-block (repeated same-tool failures) and that it clears itself once the task makes progress; a human can also remove the tag manually from the board.

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

@@ -2,67 +2,56 @@
 
 ## Task Context Loading
 
-When the user mentions a task identifier or asks for task background, load the context:
+Load context when the user mentions a task identifier or asks for task background:
 
 ```bash
-lumo task context <identifier>
+lumo task context LUM-42
 ```
 
-Example: `lumo task context LUM-42`
-
 ### Reading the output
 
-The command prints a markdown document to stdout containing:
+The command prints a markdown document to stdout with these sections, in order:
+
+1. **Task header** — identifier, title, status, description.
+2. **`## Acceptance criteria (contract)`** (LUM-342) — shown right after the header. Each line `[MACHINE|HUMAN] statement`, with a `↳ check:` line for MACHINE checkpointers; HUMAN_EDIT / REVIEW_ADDED provenance tagged inline. A still-open task with none shows a draft reminder instead — draft 3–7 criteria **before writing code** (see [criteria.md](criteria.md)).
+3. **Memory section** — cross-session learnings; trusted background context that persists, so you avoid re-learning decisions/constraints.
+4. **Inline source cards** — Slack / web / Figma / artifacts / documents / comments / Pull Requests (see "Context Retrieval" below).
+5. **`## PR review todos`** — mirrored PR review comments as a checkbox todo list. Each line-level comment shows `` `file:line` `` + reviewer's ask + GitHub comment link; each `changes_requested` review summary shows "🛑 Changes requested (whole PR)". Present only when the task's PR(s) have review comments. Each unchecked box is a TODO: resolve it, then reply on the PR (a Lumo comment mirrors back to GitHub).
+6. **`## Previous sessions`** — newest-first; each has a headline summary of what was done plus unresolved items (carry-over TODOs).
+7. **`## Flywheel signal · historical merge contribution`** — appended at the very end. Per context fragment with enough history, a one-line signal (e.g. `appeared in 5 resolved tasks · 4 merged (80%)`) computed from lineage edges. Denominator = distinct tasks where the fragment appeared with a resolved (non-UNKNOWN) outcome; only fragments with ≥3 such tasks show (cold-start gate), so the block is often absent early on. **Historical correlation, not causation** — don't read it as a prediction.
 
-1. **Task header** — identifier, title, status, description
-2. **Acceptance criteria (contract)** — the task's acceptance criteria (LUM-342), shown right after the header as the `## Acceptance criteria (contract)` section. Each line: `[MACHINE|HUMAN] statement` with a `↳ check:` line for MACHINE checkpointers; HUMAN_EDIT / REVIEW_ADDED provenance is tagged inline. If a still-open task has none, a draft reminder appears instead — draft 3–7 criteria **before writing code** (see [criteria.md](criteria.md))
-3. **Memory section** — cross-session learnings accumulated over prior sessions; treat as trusted background context
-4. **Inline source cards** — Slack / web / Figma / artifacts / documents / comments / Pull Requests (see "Context Retrieval" below)
-5. **PR review todos** — mirrored PR review comments as a checkbox todo list under the `## PR review todos` header: each line-level reviewer comment (shown as `` `file:line` `` + the reviewer's ask + a link to the GitHub comment) and each `changes_requested` review summary (shown as "🛑 Changes requested (whole PR)"). Present only when the task's PR(s) have review comments. This same block is **auto-injected at session start** (alongside the memory section) when the session is bound to a task — so reviewer asks surface without re-running `task context`.
-   - The **inline source cards** (Slack / web / Figma / PR) are likewise **auto-injected at session start** when the session is bound, under a single global token budget shared with the memory section (priority: criteria > memory > PR > Slack > Figma > web). Cards that don't fit the budget are degraded to a one-line manifest carrying just the title and its `lumo task … show` retrieval command — so you still know they exist and can pull the full content on demand.
-6. **Previous sessions** — ordered newest-first, each with:
-   - A headline summary of what was done
-   - Unresolved items (carry-over TODOs from that session)
-7. **Flywheel signal · historical merge contribution** — appended at the very end as the `## Flywheel signal · historical merge contribution` section. For each context fragment with enough history, a one-line historical merge-contribution signal (e.g. `appeared in 5 resolved tasks · 4 merged (80%)`), computed from accumulated lineage edges. Denominator = distinct tasks where the fragment appeared with a resolved (non-UNKNOWN) outcome; only fragments with ≥3 such tasks are shown (cold-start gate), so the block is often absent early on. This is **historical correlation, not causation** — don't read it as a prediction.
+**Auto-injected at session start** (when the session is bound to a task, so they surface without re-running `task context`):
+
+- `## PR review todos` — injected alongside the memory section.
+- **Inline source cards** (Slack / web / Figma / PR) — injected under a single global token budget shared with the memory section. Priority: criteria > memory > PR > Slack > Figma > web. Cards that don't fit degrade to a one-line manifest (title + its `lumo task … show` retrieval command) so you know they exist and can pull full content on demand.
 
 ### How to use the context
 
-- **Unresolved items** from the most recent session are the highest-priority carry-overs — address them before starting new work unless the user says otherwise
-- **PR review todos** items are reviewer-requested changes — treat each unchecked box as a TODO to resolve, then reply on the PR (a Lumo comment mirrors back to GitHub)
-- **Memory section** provides validated context that persists across sessions — use it to avoid re-learning decisions or constraints
-- Focus on the **most recent 1–2 sessions** for relevant state; older sessions are for historical reference only
-- If there are **no prior sessions**, this is a fresh start — read the task description carefully and ask clarifying questions if needed
+- **Unresolved items** from the most recent session are the highest-priority carry-overs — address them before new work unless the user says otherwise.
+- Focus on the **most recent 1–2 sessions**; older sessions are historical reference only.
+- **No prior sessions** = fresh start — read the task description carefully and ask clarifying questions if needed.
 
 ## Context Retrieval (full text on demand)
 
-LUM-122 split task context injection into tiers. `lumo task context <LUM-N>`
-now emits a **cheap inline card** for each source — a short summary or just
-metadata — instead of dumping full bodies. Slack, docs, artifacts, and comments
-get an **LLM summary**; web links, Figma, and PRs get **metadata only**. Each
-card ends with the **retrieval command** you run to pull the heavy content on
-demand.
-
-**How to use it:** when the inline card is not enough and you need the full
-Slack thread, the web page body, the Figma metadata, the entire comment thread,
-or the PR detail — run the matching command below. Pass the same identifier
-(`LUM-N`) plus the id the card shows for that source (a Slack `contextId`, a web
-`linkId`, a Figma `linkId`, or a PR `number`).
-
-**Output budget (LUM-428):** the whole `task context` handoff is capped to the
-output-token budget (25,000 tokens). If a memory-rich task with a long thread
-overflows, the output is truncated and ends in a pointer to the precise
-sub-commands (`lumo task status` / `task comments list --full` / `task lineage`
-/ `doc show`) to pull any dropped section just-in-time.
-
-All five are **read-only** (no live Slack/GitHub/Figma calls except the web body
-fetch). Web/Figma/PR are v1 metadata-degraded: they print a `note:` explaining
-that live content needs an external integration.
+LUM-122 split context injection into tiers: `lumo task context <LUM-N>` emits a **cheap inline card** per source instead of dumping full bodies. Slack/docs/artifacts/comments get an **LLM summary**; web/Figma/PR get **metadata only**. Each card ends with the **retrieval command** for the heavy content.
+
+Run the matching command below when the card isn't enough. Pass the same `LUM-N` plus the id the card shows for that source:
+
+| source         | retrieval command                       | id from card |
+| -------------- | --------------------------------------- | ------------ |
+| Slack thread   | `lumo task slack show <id> <contextId>` | `contextId`  |
+| Web link body  | `lumo task web show <id> <linkId>`      | `linkId`     |
+| Figma metadata | `lumo task figma context <id> <linkId>` | `linkId`     |
+| Comment thread | `lumo task comments list <id>`          | —            |
+| PR detail      | `lumo task pr show <id> <number>`       | `number`     |
+
+All five are **read-only** (no live Slack/GitHub/Figma calls except the web body fetch). Web/Figma/PR are v1 metadata-degraded: they print a `note:` saying live content needs an external integration.
+
+**Output budget (LUM-428):** the whole `task context` handoff is capped to the output-token budget (25,000 tokens). On overflow, output is truncated and ends in a pointer to the precise sub-commands (`lumo task status` / `task comments list --full` / `task lineage` / `doc show`) to pull any dropped section just-in-time.
 
 ### `lumo task slack show <identifier> <contextId>` — full Slack thread snapshot
 
-Prints the **stored** thread snapshot (no live Slack call), one line per message
-as `author: text`. Author falls back to `@<userId>` when the display name is
-missing. Empty snapshot prints `(no messages in stored snapshot)`.
+Prints the **stored** snapshot (no live Slack call), one line per message as `author: text`. Author falls back to `@<userId>` when the display name is missing. Empty snapshot prints `(no messages in stored snapshot)`.
 
 ```bash
 lumo task slack show LUM-42 ctx_abc123
@@ -70,9 +59,7 @@ lumo task slack show LUM-42 ctx_abc123
 
 ### `lumo task web show <identifier> <linkId>` — fetched web link body
 
-Fetches the page body on demand behind the SSRF guard (cached after first read)
-and prints it as plain text. Empty body prints `(empty body)`. Fetch failures
-(blocked host, timeout) print the server's error message.
+Fetches the page body on demand behind the SSRF guard (cached after first read), printed as plain text. Empty body prints `(empty body)`. Fetch failures (blocked host, timeout) print the server's error message.
 
 ```bash
 lumo task web show LUM-42 wl_abc123
@@ -80,10 +67,7 @@ lumo task web show LUM-42 wl_abc123
 
 ### `lumo task figma context <identifier> <linkId>` — Figma link metadata
 
-**v1 metadata fallback.** Prints the cached design metadata as `file:` /
-`frame:` / `url:` / `synced:` (and `syncError:` if the last sync failed) lines.
-Live design context (layers, variables, code connect) requires the Figma MCP
-server, so the command ends with a `note:` saying so.
+**v1 metadata fallback.** Prints cached design metadata as `file:` / `frame:` / `url:` / `synced:` lines (plus `syncError:` if the last sync failed). Live design context (layers, variables, code connect) requires the Figma MCP server, so the command ends with a `note:` saying so.
 
 ```bash
 lumo task figma context LUM-42 cfl_abc123
@@ -91,35 +75,21 @@ lumo task figma context LUM-42 cfl_abc123
 
 ### `lumo task comments list <identifier>` — comment thread
 
-Prints the comment thread: each comment as `author · createdAt` followed by its
-plain-text body (comment bodies are stored as HTML and stripped to text).
-Replies are indented two spaces under their parent. Author falls back to
-`unknown`. No comments prints `(no comments)`.
+Prints the thread: each comment as `author · createdAt` then its plain-text body (bodies stored as HTML, stripped to text). Replies indent two spaces under their parent. Author falls back to `unknown`. No comments prints `(no comments)`.
 
-**Output budget (LUM-428).** By default the thread is capped to the
-output-token budget (25,000 tokens — every line you print spends from your
-context). When it overflows, the output is truncated to the budget and ends in
-a fetch-more pointer (`… +N more comments not shown (output capped at 25,000
-tokens) — read the whole thread with: lumo task comments list <id> --full`).
-Pass **`--full`** to print every comment uncapped — only when you actually need
-the whole thread.
+- `lumo task comments list LUM-42` — capped to the output budget (LUM-428: 25,000 tokens; every printed line spends from your context). On overflow, truncates and ends in a fetch-more pointer: `… +N more comments not shown (output capped at 25,000 tokens) — read the whole thread with: lumo task comments list <id> --full`.
+- `lumo task comments list LUM-42 --full` — every comment, uncapped. Use only when you actually need the whole thread.
 
 ```bash
 lumo task comments list LUM-42          # capped to the output budget
 lumo task comments list LUM-42 --full   # every comment, no cap
 ```
 
-**Plural, and distinct from `task comment`.** `task comments list` _reads_ the
-whole thread (this retrieval command). `task comment <identifier> <body>`
-_writes_ a single new comment (see Task Management). Don't confuse the two —
-the plural `comments` is read-only.
+**Plural, and distinct from `task comment`** — `task comments list` _reads_ the whole thread (this read-only retrieval command); `task comment <identifier> <body>` _writes_ a single new comment (see Task Management). Don't confuse the two.
 
 ### `lumo task pr show <identifier> <number>` — synced PR metadata
 
-**v1 metadata fallback.** Prints the synced PR record: a `#<number> (repo)
-title` header, then `state:` (with ` · draft` when draft), `ci:`, `author:`,
-`branch: <head> → <base>`, and `url:` lines. The live diff + review comments
-require the GitHub integration, so the command ends with a `note:` saying so.
+**v1 metadata fallback.** Prints the synced PR record: a `#<number> (repo) title` header, then `state:` (` · draft` when draft), `ci:`, `author:`, `branch: <head> → <base>`, and `url:` lines. Live diff + review comments require the GitHub integration, so the command ends with a `note:` saying so.
 
 ```bash
 lumo task pr show LUM-42 128
@@ -127,71 +97,30 @@ lumo task pr show LUM-42 128
 
 ## `lumo task lineage <id>`
 
-Read-only audit view over the task's `LineageEdge` rows. Given a task
-identifier (`LUM-N`), prints the causal trail:
+Read-only audit view over the task's `LineageEdge` rows. Entry point is the task identifier only (PR-number lookup is a future addition).
 
 ```bash
 lumo task lineage LUM-42            # per-session causal trail + cost
-lumo task lineage LUM-42 --signal   # append workspace-level usage signal-health; used-vs-base merge rate uses iteration-taint fold (send-back/reopen/PR-close = negative class even if later merged); shows negative-class size per side; prints "metric cannot discriminate" when no failure outcomes exist yet
+lumo task lineage LUM-42 --signal   # append workspace-level usage signal-health
 ```
 
-- **Totals banner** — distinct sessions, fragment count, edge count,
-  total tokens (input/output/cache split) and loops, and the outcome
-  distribution. After the outcome summary, one funnel line is appended:
-  `- Disclosure funnel: N impressions · M INDEX (X%) · K pulled (Y% of INDEX) · J used (Z%)`
-  where impressions = edge count, INDEX% and used% are over impressions,
-  pull% is over INDEX only (FULL fragments have no pull opportunity).
-  Divide-by-zero is guarded (zero impressions or zero INDEX renders `0%`).
-  When per-fragment token weights have been collected (LUM-522), the line also
-  appends `· ~T tokens saved` = Σ(fullTokens − indexTokens) over un-pulled INDEX
-  edges (the token cost the index-only injection avoided); the suffix is omitted
-  cleanly when no edge carries token data yet (older edges predate the columns).
-- **One block per session** — the group's cost shown **once** (token/loop),
-  the date it consumed context, then each context fragment as
-  `[OUTCOME] TYPE — <source label>`, plus a disclosure annotation suffix:
-  `· INDEX pulled` (INDEX fragment, `pulledAt` is set) /
-  `· INDEX not-pulled` (INDEX fragment, never pulled) /
-  `· FULL` (injected in full at session-start).
-  Per-group outcome summary follows.
-
-Cost is attributed once per session (a session that injected many fragments is
-not double-counted). Fragment ids are canonical — MEMORY fragments survive
-consolidation drift.
-
-**`--signal` workspace funnel:** the workspace-level usage signal-health block
-appended by `--signal` ends with a workspace-wide disclosure funnel in the
-same format: `- Disclosure funnel: N impressions · M INDEX (X%) · K pulled (Y% of INDEX) · J used (Z%)`
-aggregated over all edges in the workspace (not just this task) — including the
-same `· ~T tokens saved` suffix when token data exists (LUM-522).
-
-**Cold start:** a task with no edges prints a friendly note (lineage is captured
-when a session-bound run consumes the task's context), not an error.
-
-**When to suggest:** the user wants to audit "what context did the AI actually
-use, and what did it cost" for a task / merged PR — CFO / compliance / trust
-narratives.
-
-Entry point is the task identifier only; PR-number lookup is a future addition.
-
-**Top operations by token cost (LUM-523):** the lineage totals also append a
-per-task **"Top operations by token cost"** Top-5 — the most expensive tools by
-attributed token cost (`<tool> — N tokens`), ending with the pointer
-`(full breakdown: lumo cost --task <id>)`. The block is omitted when no
-per-operation cost has been attributed yet.
+- `lumo task lineage <id> --signal` — appends the workspace-level usage signal-health block. Used-vs-base merge rate uses iteration-taint fold (send-back / reopen / PR-close = negative class even if later merged); shows negative-class size per side; prints "metric cannot discriminate" when no failure outcomes exist yet. The block ends with a workspace-wide disclosure funnel (same format as the totals funnel below, aggregated over **all** workspace edges, not just this task) including the same `· ~T tokens saved` suffix when token data exists (LUM-522).
+
+Output sections:
+
+- **Totals banner** — distinct sessions, fragment count, edge count, total tokens (input/output/cache split), loops, and outcome distribution. After the outcome summary, one funnel line: `- Disclosure funnel: N impressions · M INDEX (X%) · K pulled (Y% of INDEX) · J used (Z%)`. Impressions = edge count; INDEX% and used% are over impressions; pull% is over INDEX only (FULL fragments have no pull opportunity). Divide-by-zero guarded (zero impressions or zero INDEX renders `0%`). With per-fragment token weights collected (LUM-522), appends `· ~T tokens saved` = Σ(fullTokens − indexTokens) over un-pulled INDEX edges (the token cost index-only injection avoided); omitted cleanly when no edge carries token data (older edges predate the columns).
+- **One block per session** — the group's cost shown **once** (token/loop), the date it consumed context, then each fragment as `[OUTCOME] TYPE — <source label>` plus a disclosure suffix: `· INDEX pulled` (INDEX, `pulledAt` set) / `· INDEX not-pulled` (INDEX, never pulled) / `· FULL` (injected in full at session-start). Per-group outcome summary follows.
+- **Top operations by token cost (LUM-523)** — the totals also append a per-task Top-5 of the most expensive tools by attributed token cost (`<tool> — N tokens`), ending with `(full breakdown: lumo cost --task <id>)`. Omitted when no per-operation cost has been attributed yet.
+
+Cost is attributed once per session (a session that injected many fragments is not double-counted). Fragment ids are canonical — MEMORY fragments survive consolidation drift. **Cold start:** a task with no edges prints a friendly note (lineage is captured when a session-bound run consumes the task's context), not an error.
+
+### When to suggest
+
+The user wants to audit "what context did the AI actually use, and what did it cost" for a task / merged PR — CFO / compliance / trust narratives.
 
 ## `lumo cost`
 
-Per-operation (per-tool) token cost read-out. Where `task lineage` answers
-"what context fed this task and what did the run cost," `lumo cost` answers
-"which _operations_ (tools) burned the tokens." It attributes each model step's
-token delta to the tool(s) that ran in it — **per-step** where the
-`POST_TOOL_BATCH` hook captured the tool list, **per-turn fallback** otherwise
-(a parallel-tool step splits its tokens evenly across the tools, hence the
-"heuristic" note). Each ranking row breaks the cost into four columns —
-`output` (generation), `input`, `cache_create`, `cache_read` (~95%, structural —
-turns × context) — plus `total`. `output` and `cache_read` attribute cleanly
-per step; `input` and `cache_create` are bursty (prompt + cache checkpoints), so
-their per-tool figures are coarser.
+Per-operation (per-tool) token cost read-out. Where `task lineage` answers "what context fed this task and what did the run cost," `lumo cost` answers "which _operations_ (tools) burned the tokens." It attributes each model step's token delta to the tool(s) that ran in it — **per-step** where the `POST_TOOL_BATCH` hook captured the tool list, **per-turn fallback** otherwise (a parallel-tool step splits its tokens evenly across the tools, hence the "heuristic" note). Each ranking row breaks cost into `output` (generation), `input`, `cache_create`, `cache_read` (~95%, structural — turns × context), plus `total`. `output` and `cache_read` attribute cleanly per step; `input` and `cache_create` are bursty (prompt + cache checkpoints), so their per-tool figures are coarser.
 
 ```bash
 lumo cost --task LUM-42
@@ -199,24 +128,11 @@ lumo cost --session <session-id> --by model
 lumo cost --since 2026-06-01 --by member --json
 ```
 
-- **Scope (mutually exclusive)** — `--task <id>` scopes to one task,
-  `--session <id>` to one Claude Code session, `--since <ISO-date>` to a
-  workspace window from that date. With none given, the default is a
-  **workspace last-30-days** window. (If more than one is passed, the CLI
-  picks task > session > since.)
-- **`--by tool|model|member|session`** (default `tool`) — only changes which
-  grouping is the **headline** table; the other groupings are still printed
-  below when non-trivial (member/session tables appear only when there is more
-  than one). Case-insensitive.
-- **`--json`** — emit the versioned payload (`version: 1`, scope, grandTotal,
-  coverage, and `byTool` / `byModel` / `byMember` / `bySession` row arrays)
-  instead of the rendered tables.
-- **Coverage line** — `Per-step attribution: X% of N tool-using turns` tells
-  you how much of the report is precise per-step attribution vs the per-turn
-  fallback. `n/a` when there were no tool-using turns.
-
-**When to suggest:** the user asks where their tokens went _by operation_ —
-"which tools are most expensive," cost attribution by model / teammate /
-session, or a workspace cost window. For the quick per-task Top-5 inline, point
-them at `lumo task lineage <id>` instead; reach for `lumo cost` for the full
-breakdown or any non-task scope.
+- `--task <id>` / `--session <id>` / `--since <ISO-date>` — **mutually-exclusive** scope: one task / one Claude Code session / a workspace window from that date. None given = default **workspace last-30-days**. If more than one is passed, the CLI picks task > session > since.
+- `--by tool|model|member|session` (default `tool`, case-insensitive) — only changes which grouping is the **headline** table; other groupings still print below when non-trivial (member/session tables appear only when >1).
+- `--json` — emit the versioned payload (`version: 1`, scope, grandTotal, coverage, and `byTool` / `byModel` / `byMember` / `bySession` row arrays) instead of rendered tables.
+- **Coverage line** `Per-step attribution: X% of N tool-using turns` — how much of the report is precise per-step attribution vs per-turn fallback. `n/a` when there were no tool-using turns.
+
+### When to suggest
+
+The user asks where their tokens went _by operation_ — "which tools are most expensive," cost attribution by model / teammate / session, or a workspace cost window. For the quick per-task Top-5 inline, point them at `lumo task lineage <id>` instead; reach for `lumo cost` for the full breakdown or any non-task scope.