@lumoai/cli 1.28.0 → 1.29.0

package/assets/skill/references/sessions.md

@@ -1,225 +0,0 @@
-# Session Management
-
-## Session Management
-
-### 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.
-
-### 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, so they can't be reviewed in the synchronous `session wrap` panel — 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.
-
-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.
-
-### 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.
-
-**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.
-
-```
-## ⚠ Dependency alerts
-
-- This task is blocked by LUM-9 "Fix auth token expiry" (status IN_PROGRESS).
-- This task is blocked by LUM-15 "Upgrade Postgres driver" (status IN_REVIEW, PR #42 not merged).
-
-Consider waiting for the blocker(s) to merge before starting work to avoid a wasted run; if an edge is stale, clean it up with `lumo task deps rm/dismiss`.
-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.
-
-```
-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.
-
-**Agent guidance — 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.
-- 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.
-
-```bash
-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.
-- 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 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.**
-
-#### Overwriting an existing binding (LUM-266)
-
-Re-attaching a session that's already bound to a **different** task no longer silently clobbers the binding. The server returns the current binding instead of overwriting, and the CLI decides what to do:
-
-- **On a TTY** (a human running it directly): prompts `Already bound to LUM-X. Rebind to LUM-Y? [y/N]`. Answering `y`/`yes` re-binds to `LUM-Y`; anything else (including bare Enter) cancels and leaves `LUM-X` bound.
-- **Off a TTY** (the usual agent case — `stdin` is not interactive): the command **refuses** and prints `Session already bound to LUM-X … Re-run with --force …` without overwriting. Exit code is `0` (a safe refusal, not an error).
-- **`--force`**: skips the prompt/refusal and overwrites unconditionally. Re-attaching to the **same** task is always a no-op re-bind (never prompts).
-
-```bash
-lumo session attach LUM-42            # already on LUM-7 → prompts (TTY) / refuses (agent)
-lumo session attach LUM-42 --force    # overwrite without confirmation
-```
-
-**Agent guidance:** when `session attach` reports the session is already bound to a different task, **ask the user** whether to switch before re-running with `--force`. Don't auto-`--force` — the existing binding may be intentional (e.g. a manual attach the user ran earlier). Alternatively run `lumo session detach` first, then a clean `session attach`.
-
-### 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.
-
-### `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.
-
-### `lumo session detach` — clear the current binding
-
-Idempotent — running it twice is fine, the second call reports `already unbound`. Past hook events keep their original `taskId`; only future events on this session will be untagged.
-
-```bash
-lumo session detach
-```
-
-When to suggest: the user wants to stop tagging the current session with the active task (e.g., switching to unrelated exploratory work without binding to a different task).
-
-### `lumo session wrap [--yes] [--dry-run] [--used <indices>]` — wrap-up panel: progress comment + memory review + fragment-usage vote + blocked-tag prompt
-
-Session-end wrap-up panel with **four sections, run in order**:
-
-**1. Progress comment** — reads back the current Claude Code session's per-turn
-`turnSummary` rows (the one-line summaries written each STOP), aggregates
-every turn **since the last progress comment** into one bulleted body, and — after
-a `[y] post / [e] edit / [s] skip` confirmation — posts it as a comment on the
-session's bound task. A server-side watermark (`Session.lastProgressCommentAt`)
-means re-running never re-posts the same turns.
-
-**2. Memory review** — lists the Layer1 memories this session sedimented since the
-last review (deduped by a per-session watermark `Session.lastMemoryReviewAt`).
-Each new memory is shown as `[SCOPE] CATEGORY  headline`, numbered from 1. You
-curate with a single line: `d 1,3` deletes rows 1 and 3, `p 2` promotes row 2 to
-project scope, and they combine (`d 1,3 p 2`). **Enter (empty) keeps all**; `s`
-skips the section. Keeping all (Enter or `--yes`) still **advances the watermark**
-so the next wrap won't re-list reviewed memories; `s` leaves them for next time.
-Out-of-range indices are ignored. Deletes/promotes run server-side, scoped to
-memories this session created (you can't touch other sessions' memories through
-this panel). With no new memories the section prints "(no content)" and does nothing.
-
-**3. Fragment-usage vote (LUM-300)** — lists the context
-fragments this session **consumed** (its lineage edges: memory / slack / web /
-figma / PR / review-todo / session), numbered from 1 with a content snippet
-label. The agent records which it **actually used** via
-`lumo session wrap --used <indices>` (1-based, comma/space separated; `--used
-none` = used nothing). Voted fragments get `used=true`, the rest of the
-session's fragments `used=false`. **Without `--used` the section only lists the
-candidates and writes nothing** (edges stay `null` = not voted — honest, not
-"unused"). A session that already voted (`usedAt` set) is skipped. **Why:** it
-upgrades the flywheel signal from "co-loaded" (constant, no information) to
-"actually used" (varies → discriminative); `task context` then prefers each
-fragment's usage-based merge rate, falling back to the weaker presence rate when
-usage samples are thin. With no consumed fragments the section prints "(no content)".
-
-**4. Blocked check (blocked-tag prompt, LUM-153)** — if the **same kind of failure
-recurred ≥ 3 times** in this session (server-aggregated from
-`POST_TOOL_USE_FAILURE` events grouped by tool name, plus `STOP_FAILURE`
-turn-level failures), the section surfaces the dominant failure (`This session looks repeatedly stuck on <tool> (N failures).` + last error summary) and prompts `[y] tag / [s] skip` whether to
-flag the bound task with a **`blocked` tag**. **Prompt-only — never auto-flips
-status.** It uses a plain tag (no `TaskStatus` enum, no board column, **no
-schema migration**). The prompt is **suppressed** when: there's no bound task,
-the threshold isn't met, or the task **already** carries a `blocked` tag (the
-idempotent gate — there's no watermark, the existing tag is what prevents
-re-nagging). The default on empty input / `s` is **do nothing** (tagging is
-opt-in), so a stray Enter never tags the task. Confirming with an explicit `y`
-attaches the tag idempotently. **`--yes` does NOT auto-tag** — tagging the
-shared board requires an interactive `y`, so `--yes` (and non-TTY) prints the
-suggestion and moves on rather than silently flipping board state. When there's
-nothing to prompt, the section prints "(no content)".
-
-```bash
-lumo session wrap                  # interactive: preview each section, choose per-section
-lumo session wrap --yes            # progress posted + memories kept; blocked tag NOT auto-applied (needs interactive y)
-lumo session wrap --yes --used 1,3 # also record fragments 1 & 3 as used (the rest used=false)
-lumo session wrap --used none      # record that none of the injected fragments were used
-lumo session wrap --dry-run        # print all drafts only; never posts, never mutates, never advances watermarks
-```
-
-The usage vote is a two-step flow for agents: run `lumo session wrap` once to
-see the numbered fragment list, decide which you actually used, then re-run with
-`--used <indices>`. Re-running is safe — the other sections are watermark-guarded
-(progress won't double-post, reviewed memories won't re-list).
-
-- Requires `$CLAUDE_CODE_SESSION_ID` (must run inside Claude Code) and a bound
-  task (`lumo session attach <LUM-N>` first). With no bound task or no new turn
-  summaries, the Progress comment section prints "(no content)" and posts nothing.
-- `[e] edit` (Progress comment) opens `$EDITOR` (fallback vi/nano) on the drafted body;
-  the edited text is posted and the watermark still advances to the turns the
-  draft covered.
-- `--yes` posts the progress comment AND keeps all memories (no
-  deletes/promotes) while advancing the memory-review watermark; for the
-  blocked-tag section it prints the suggestion but does **not** apply the tag.
-- `--dry-run` prints all drafts; never posts, never mutates memories/tags, never
-  advances either watermark.
-- Non-TTY without `--yes`: prints the drafts and does **not** post, mutate, or
-  tag (safe default).
-
-When to suggest: at the end of a working session on a bound task, to record what
-was done as a progress comment — offer `lumo session wrap` rather than composing
-a `task comment` by hand.
-
-### When to suggest session binding
-
-- If the user mentions a task ID (e.g., "let's work on LUM-42") and no session is currently bound, **suggest running `lumo session attach`**.
-- If the user switches tasks mid-session, run `attach` with the new task ID — the server overwrites the existing binding atomically.

package/assets/skill/references/sprints.md

@@ -1,157 +0,0 @@
-# Sprint Management
-
-## Sprint Management
-
-### `lumo sprint list [flags]` — list sprints in a team
-
-Prints fixed-width rows: `<NUMBER>  <STATUS>  <start>  <end>  <name>`, sorted newest-first (server sort).
-
-| Flag                   | Type    | Notes                                                 |
-| ---------------------- | ------- | ----------------------------------------------------- |
-| `--team <ref>`         | string  | Team name or slug. Required in multi-team workspaces. |
-| `-s, --status <value>` | enum    | `draft \| active \| closed`.                          |
-| `-n, --limit <count>`  | integer | Cap output to the first N rows.                       |
-
-```bash
-lumo sprint list
-lumo sprint list --status active
-lumo sprint list --team backend --limit 5
-```
-
-When to suggest: user asks "what sprints do we have", "which sprint is active", "list sprints", "show me the current sprint", "active sprints".
-
-### `lumo sprint create [flags]` — create a sprint
-
-| Flag             | Type   | Notes                                                 |
-| ---------------- | ------ | ----------------------------------------------------- |
-| `--team <ref>`   | string | Team name or slug. Required in multi-team workspaces. |
-| `--start <date>` | string | **Required.** YYYY-MM-DD.                             |
-| `--end <date>`   | string | **Required.** YYYY-MM-DD.                             |
-| `-n, --name <>`  | string | Optional. Server fills a default name when omitted.   |
-
-```bash
-lumo sprint create --start 2026-06-01 --end 2026-06-14
-lumo sprint create --name "Sprint 4" --start 2026-06-01 --end 2026-06-14 --team backend
-```
-
-On success: `Created sprint #<number> "<name>"  <id>`.
-
-When to suggest: user says "create a sprint", "new sprint", "start a new iteration".
-
-### `lumo sprint show <identifier> [--team <ref>]` — show sprint detail + task table
-
-`<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.
-
-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.
-
-```
-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
-  Stale PRs: #12, #15
-```
-
-```bash
-lumo sprint show 3
-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".
-
-### `lumo sprint update <identifier> [flags]` — patch a sprint
-
-Updates sprint metadata. At least one flag required. **No `--status` flag** — use `lumo sprint start` / `lumo sprint close` to transition status.
-
-| Flag             | Type   | Notes                                                           |
-| ---------------- | ------ | --------------------------------------------------------------- |
-| `--team <ref>`   | string | Required when identifier is a number in a multi-team workspace. |
-| `-n, --name <>`  | string | New name. Cannot be empty.                                      |
-| `--start <date>` | string | YYYY-MM-DD. `--start ""` clears.                                |
-| `--end <date>`   | string | YYYY-MM-DD. `--end ""` clears.                                  |
-
-```bash
-lumo sprint update 3 --name "Sprint 4 (extended)"
-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)
-
-Requires `--yes`; no interactive prompt (agent-friendly). Server rejects with an error if the sprint is ACTIVE or CLOSED.
-
-```bash
-lumo sprint delete 3 --yes
-```
-
-When to suggest: user wants to remove a draft sprint that was created by mistake.
-
-### `lumo sprint start <identifier>` — transition DRAFT → ACTIVE
-
-No additional flags. Fails if the sprint is already ACTIVE or CLOSED.
-
-```bash
-lumo sprint start 3
-```
-
-When to suggest: user says "start the sprint", "kick off sprint 3", "activate sprint".
-
-### `lumo sprint close <identifier> [flags]` — transition ACTIVE → CLOSED
-
-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.                          |
-
-```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
-```
-
-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
-
-Prints the AI-generated retrospective summary for the sprint. A 404 response means no summary has been generated yet ("no summary yet").
-
-| Flag      | Type    | Notes                                             |
-| --------- | ------- | ------------------------------------------------- |
-| `--retry` | boolean | Queue a regeneration (async, server returns 202). |
-
-```bash
-lumo sprint summary 3
-lumo sprint summary 3 --retry
-```
-
-When to suggest: user asks "summarize the sprint", "sprint retro", "give me a summary of sprint 3".
-
-### `lumo sprint add <identifier> <task>` — bind a task to a sprint
-
-Adds `<task>` (e.g. `LUM-48`) to the sprint. Same-team check applies — the task's team must match the sprint's team.
-
-```bash
-lumo sprint add 3 LUM-48
-```
-
-When to suggest: user says "add LUM-48 to sprint 3", "put this task in the sprint".
-
-### `lumo sprint remove <identifier> <task>` — unbind a task from a sprint
-
-Removes `<task>` from the sprint. Idempotent — if the task is not in the sprint, the server returns success.
-
-```bash
-lumo sprint remove 3 LUM-48
-```
-
-When to suggest: user says "remove LUM-48 from the sprint", "take this task out of sprint 3", "move task to backlog".

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

@@ -1,136 +0,0 @@
-# Task Context Loading & Context Retrieval
-
-## Task Context Loading
-
-When the user mentions a task identifier or asks for task background, load the context:
-
-```bash
-lumo task context <identifier>
-```
-
-Example: `lumo task context LUM-42`
-
-### Reading the output
-
-The command prints a markdown document to stdout containing:
-
-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.
-
-### 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
-
-## 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`).
-
-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.
-
-### `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)`.
-
-```bash
-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.
-
-```bash
-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.
-
-```bash
-lumo task figma context LUM-42 cfl_abc123
-```
-
-### `lumo task comments list <identifier>` — full comment thread
-
-Prints the **entire** 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)`.
-
-```bash
-lumo task comments list LUM-42
-```
-
-**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.
-
-### `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.
-
-```bash
-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:
-
-- **Totals banner** — distinct sessions, fragment count, edge count,
-  total tokens (input/output/cache split) and loops, and the outcome
-  distribution.
-- **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 per-group outcome summary.
-
-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.
-
-Entry point is the task identifier only; PR-number lookup is a future addition.