orbitmap 0.6.0 → 0.8.0

package/dist/agent-instructions.js

@@ -1,8 +1,8 @@
 // Single source of truth for all OrbitMap agent-facing instruction text.
 //
 // THIS FILE IS THE CANONICAL HOME of the skills. `orbitmap init` installs them; the
-// copies under `~/.claude/skills/` (or a project's `.claude/skills/`) are INSTALLS,
-// not sources. Edit here, then re-install — never the other way around.
+// copies under `~/.claude/skills/`, `~/.codex/skills/` (or a project's `.claude/skills/`)
+// are INSTALLS, not sources. Edit here, then re-install — never the other way around.
 //
 // Two layers, mirroring how the OrbitMap MCP server works:
 //   1. THIN_HOOK      — always-on, injected into CLAUDE.md / AGENTS.md (~10 lines).
@@ -29,16 +29,18 @@
 //                                               workers read INSTEAD of the skill
 //                                               (see SkillDef.references).
 //                         orbitmap-docs       — documents
-//                       Shipped two ways:
-//                         - Claude:     one `.claude/skills/<name>/SKILL.md` per skill,
-//                                       plus any `references/*` files, loaded on demand
-//                                       (zero per-turn context cost).
-//                         - non-Claude: all skill BODIES concatenated into the agent
-//                                       config file (no skill ecosystem to lean on).
-//                                       Reference files are not inlined: without
-//                                       subagent dispatch, Flow A runs serially and the
-//                                       worker contract folds into the executor's own
-//                                       rules.
+//                       Shipped two ways, chosen by what the agent CAN DO, never by its
+//                       name (see AgentDef.skillsDirName in commands/setup-agent.ts):
+//                         - skills-capable agents (Claude Code and Codex today): one
+//                                       `<skills dir>/<name>/SKILL.md` per skill, plus
+//                                       any `references/*` files, loaded on demand (zero
+//                                       per-turn context cost).
+//                         - agents with no skill ecosystem: all skill BODIES concatenated
+//                                       into the agent config file, because there is
+//                                       nothing on-demand to lean on. Reference files are
+//                                       not inlined: without subagent dispatch, Flow A
+//                                       runs serially and the worker contract folds into
+//                                       the executor's own rules.
 //
 // History: the original four skills (orbitmap, orbitmap-execute, orbitmap-plan,
 // orbitmap-docs) were transcribed from §8 of `docs/local-mode-poc-spec.md`, itself a
@@ -174,9 +176,12 @@ ${c}task records why every decision was made and never what was built.`;
 export const SKILL_ORBITMAP_FRONTMATTER = `---
 name: orbitmap
 description: >
-  OrbitMap project management via the orbitmap CLI. Use when the user mentions OrbitMap,
-  orbit, tasks, backlog, missions, intents, ideas, issues, vibes, or asks to track,
-  plan, or log work. Entry point: object model, context resolution, command reference.
+  OrbitMap project management via the orbitmap CLI — the entry point other orbitmap-*
+  skills require. Use whenever the user wants to build, add, change or fix something, in
+  whatever words they use — do not wait for OrbitMap vocabulary — as well as when they
+  mention OrbitMap, orbit, tasks, backlog, missions, intents, ideas, issues, vibes, or ask
+  to track, plan, or log work. Covers the object model, context resolution, and command
+  reference.
 ---`;
 export const SKILL_ORBITMAP_BODY = `# OrbitMap CLI — core
 
@@ -197,10 +202,9 @@ MCP tool schemas are the authority. Never edit the workspace data files directly
 ## General behaviour
 - Always prioritise the user's direct request. If the user asks you to do something
   (read a file, write code, answer a question), handle that first.
-- Only interact with OrbitMap when the user explicitly asks you to (e.g. "check my
-  tasks", "start a task", "what's on my backlog", "log this idea").
 - When the user mentions OrbitMap, orbit, task, backlog, or project-management concepts
-  in the context of tracking work, use \`orbitmap\` commands to handle the request.
+  in the context of tracking work — in whatever words they use — use \`orbitmap\` commands
+  to handle the request.
 
 ## Object model
 - Workspace = team level. Area = repo-level scope (formerly Project) — tasks, vibes and
@@ -210,6 +214,14 @@ MCP tool schemas are the authority. Never edit the workspace data files directly
   outside a task. Task (TS-) = unit of work.
 - Entity numbers (TS-xxxxxx etc.) are accepted by every command that takes an id.
 
+## Naming workitems in output
+Refer to a workitem by its NAME together with its key, at first mention in any message,
+summary or report — "Align skills and validators (IN-b2h63q)". NEVER a bare key: a key
+alone is unreadable to the user, who tracks the work by name. Keep no key-to-name mapping
+anywhere — not in a file, not in memory. Every list, \`show\` and context response already
+pairs the two, so take the name from the response you already have; if you do not have it,
+fetch the item rather than emitting the key on its own.
+
 ${SESSION_FOCUS_SECTION}
 
 ${FRESHNESS_SECTION}
@@ -222,10 +234,9 @@ ${FRESHNESS_SECTION}
   lists and no bodies — fetch deeper on demand (\`orbitmap intent show IN-x\`,
   \`orbitmap tasks --intent IN-x\`, \`orbitmap doc <slug>\`). Never list areas and never
   ask the user "which area?" before you have read it.
-- You work in a WORKSPACE, not inside a single area. Missions, intents
-  and documents are workspace-level and take no area — a document is exactly ONE copy,
-  global to the workspace, never per-area. Tasks, vibes, issues and ideas are
-  AREA-scoped.
+- You work in a WORKSPACE, not inside a single area. Missions and intents are
+  workspace-level and take no area. Documents live at area OR workspace level.
+  Tasks, vibes, issues and ideas are AREA-scoped.
 - Missions and intents outrank individual tasks. Asked to work on "what matters", take the
   active mission and open intents from context and pick work that serves them.
 - The area follows from the directory, never from a question to the user:
@@ -281,7 +292,7 @@ backlog, todo, in_progress, in_review, review_changes, done, blocked.
 - Tasks: \`orbitmap tasks [--status s1,s2] [--intent IN-x]\`, \`orbitmap task TS-x\`,
   \`orbitmap get <ID>\`,
   \`orbitmap start [TS-x]\`, \`orbitmap status TS-x <status> [--delivery <d>]\`,
-  \`orbitmap create "title" [--intent IN-x|--mission MS-x] [--priority p]\`,
+  \`orbitmap create "title" [--intent IN-x] [--priority p]\`,
   \`orbitmap subtask TS-parent "title"\`, \`orbitmap assign TS-x [agent]\`,
   \`orbitmap dep add|remove TS-a TS-b\`, \`orbitmap log TS-x "msg" --type <t>\`
 - Issues: \`orbitmap issue register|list|show|status|resolve\`
@@ -309,7 +320,7 @@ description: >
   the user's), and "work on TS-x" runs a single tracked task (starting/resuming,
   logging, finishing with the correct status, git branches and delivery status). Use
   whenever executing a planned intent or implementing, resuming, or finishing a
-  tracked task.
+  tracked task. Requires the \`orbitmap\` core skill.
 ---`;
 export const SKILL_EXECUTE_BODY = `# Executing OrbitMap work
 
@@ -430,9 +441,12 @@ MCP tool schemas are the authority. Never edit the workspace data files directly
    branch — the intent branch is named in the report, not left underfoot. Report in
    chat: what shipped, what was decided, what is blocked and why, deviations from the
    plan, gate results vs baseline. Write ONE resume
-   point: \`orbitmap log IN-x "Resume point: …" --type note\`. Then end the run:
+   point: \`orbitmap log IN-x "Resume point: …" --type note\`. Before the transition, run
+   \`orbitmap intent show IN-x --slim\` and verify every task is \`in_review\`, \`done\`, or
+   \`blocked\` with a logged blocker — an \`in_progress\` task means a fold step was
+   skipped; fix it before moving on. Then end the run:
    \`orbitmap intent update IN-x --status in_review --log <entries>\` — the transition's
-   response carries an Instructions section (it will ask for release notes); FOLLOW it.
+   response carries an Instructions section (it will ask you to verify the outcome lines); FOLLOW it.
    Merging and closing to \`done\` are the USER'S. The merge EVENT — whoever performs
    it — is what later flips the tasks to \`--delivery merged\`.
 
@@ -652,7 +666,7 @@ description: >
   cross-task notes in the intent plan field, and a doc-update-after-green step; then creates
   the tasks and hands off to orbitmap-execute. Use for "plan this intent", "break this down
   into tasks", an intent entering \`plan\` status — and for general planning (missions,
-  intents, promoting ideas, triaging issues).
+  intents, promoting ideas, triaging issues). Requires the \`orbitmap\` core skill.
 ---`;
 export const SKILL_PLAN_BODY = `# Planning a design into executable tasks
 
@@ -776,8 +790,10 @@ ${worklogKeepDropTest('   ')}
    add or fix tasks and re-check. Do NOT proceed while a gap remains.
 7. Write cross-task PLANNING NOTES + a short SUMMARY to the intent \`plan\` field —
    \`orbitmap intent update IN-x --plan "<notes>"\`: decisions valid for all tasks,
-   sequencing rationale, and the coverage argument. This REPLACES any seed notes that were
-   in the field — you have already absorbed them.
+   sequencing rationale, and the coverage argument. Start the field with "# Summary"
+   — a paragraph summing up the whole field — then the body. The server reads that section
+   as the field's TL;DR and flags a field written without one.
+   This REPLACES any seed notes that were in the field — you have already absorbed them.
 8. Ensure a final DOC-UPDATE task exists: after the implementation is done and all tests
    are green, update the OrbitMap documentation (see the \`orbitmap-docs\` skill).
 9. SELF-REVIEW the plan with fresh eyes (see the Self-review section) and fix issues inline.
@@ -868,12 +884,15 @@ triaging issues):
 - **Missions:** \`orbitmap mission list|show MS-x\`; \`orbitmap mission create "name"
   [--outcome "…"] [--start d] [--end d]\`; \`orbitmap mission status MS-x
   active|completed|cancelled\` (activating fails while another is active — complete/cancel
-  it first); \`orbitmap mission link|unlink MS-x IN-y|TS-y|IS-y|ID-y\`. A mission status
+  it first); \`orbitmap mission link|unlink MS-x --type task|issue|idea|intent --id <uuid>\`
+  (the linked object goes by UUID — this endpoint rejects display numbers). A mission status
   change takes the same repeatable \`--log <type>:<content>\` and is refused (422) without
   at least one entry — \`cancelled\` above all needs its \`decision:"<why abandoned>"\`.
   \`orbitmap log MS-x "…" --type …\` logs against a mission outside a transition.
-- **Intents:** \`orbitmap intent create "name" [--outcome "…"] [--design "…"] [--plan "…"]
-  [--mission MS-x]\`, statuses new → design → plan → build → done (or cancelled). The
+- **Intents:** \`orbitmap intent create "name" [--outcome "…"] [--design "…"] [--plan "…"]\`
+  (there is no \`--mission\` flag — attach after creation with \`orbitmap mission link MS-x
+  --type intent --id <uuid>\`), statuses new → design → plan → build → done (or
+  cancelled). The
   \`outcome\` is the north star, \`design\` the agreed solution, \`plan\` the agreed build
   plan — produced by the \`orbitmap-brainstorm\` / \`orbitmap-design\` / \`orbitmap-plan\`
   gates respectively.
@@ -918,7 +937,8 @@ description: >
   time until the outcome is AGREED, writes that outcome to the intent's outcome field, and
   files useful asides to the design (and, when relevant, plan) fields for the later gates.
   Use for "I have an idea", "brainstorm this", "let's think through X", "what should we
-  build/do about X", shaping an intent's outcome, or an intent at \`new\` status.
+  build/do about X", shaping an intent's outcome, or an intent at \`new\` status. Requires
+  the \`orbitmap\` core skill.
 ---`;
 export const SKILL_BRAINSTORM_BODY = `# Framing an idea into an outcome
 
@@ -964,6 +984,9 @@ you hand to \`orbitmap-design\` (and, through the plan field, to \`orbitmap-plan
   ONE question. Prefer proposing a sensible default for the user to correct over an open
   interrogation. Aim for the few highest-leverage questions — "one question at a time" sets
   the pace, not the total count.
+- **Answer before asking.** When the user's turn contains a question, answer it first —
+  completely — before asking your own. Never return a question with a question; an
+  unanswered user question makes every next question feel like an interrogation.
 - **Lead with a recommendation.** Present options and the outcome conversationally, leading
   with the option you recommend and WHY — never a flat, neutral menu with no steer.
 - **YAGNI.** Cut every want that does not serve the outcome; a smaller outcome ships.
@@ -986,6 +1009,57 @@ you hand to \`orbitmap-design\` (and, through the plan field, to \`orbitmap-plan
   validation) into the design notes, never into the agreed outcome. Do not slip into
   solutioning.
 
+## Outcome lines
+
+One promise per line, written as the user would read it in release notes. Subject is
+the user, a named role, or the product acting for the user — never "you", "we", "I",
+the team, the code or the field. Shape: "(user) can (do what)" or
+"(product) no longer (pain)".
+
+Sources: the outcome field first; when it is thin, the work log's decision and
+release-note entries; never the design or plan.
+
+Each line passes six tests, or is rewritten / moved:
+  NOTICE    — would a user notice it without reading code, tests or the tracker?
+              (nothing changes → Out of scope)
+  STRANGER  — would a new customer understand it? (no keys, dates, "decided by")
+  CODE      — no file, class, column, endpoint, flag, or surface list shown for
+              coverage; one surface may be named when the behaviour lives only there
+              (mechanism → What changes or design)
+  ONE-THING — one promise; a second clause may only say why it matters or what it
+              replaces — "and", a semicolon joining two promises, a second field or
+              view → split or drop
+  ACTOR     — every verb has one unambiguous doer (the user accepts, the system
+              tests); no "opens/gets/begins" where a person or the system could be meant
+  REFERENT  — nothing points outside the line: no "this", "it", "lists", "the field"
+              without naming which
+
+1–7 lines, ≤160 chars each: title, one line of description, the user type in brackets
+at the end. Highest impact to the user or product first. More than 7 on a new intent →
+propose a second intent; on an already-built intent → merge the lowest-impact lines.
+
+User type: [user] anyone working in OrbitMap; [customer] the account owner's view —
+security, data, billing, upgrade notices; [internal] only the OrbitMap team notices.
+An all-[internal] list is allowed; never force a user line.
+
+Examples:
+  Bad:  "TaskDetail's unlocked taskId allowing cross-account read+write (IS-x4uxur) closes"
+  Good: "No one can open or edit a task from another account, even with its link. [customer]"
+  Bad:  "DB enum + Postgres triggers, Agent API + fixtures, UI, CLI, MCP carry 'cancelled'"
+  Good: "A task can be cancelled instead of being marked done with a disclaimer. [user]"
+  Bad:  "You can write work-log entries on an issue, same as on a task."
+  Good: "A user can write work-log entries on an issue, same as on a task. [user]"
+
+If the user's shorthand can be read two ways, still propose the line and end it with
+"? <question>"; a "?" line never enters the field. No input to work from → say so and
+ask what should change and for whom; never invent.
+
+Propose the list in the terminal in this exact format. The user accepts or comments;
+refine and re-propose until the user accepts the whole list. Then re-read each
+accepted line as a customer reading the changelog email; flag any line that can still
+be read two ways. Write only the accepted lines, as the first paragraph of the outcome
+field.
+
 ## Flow
 1. Gather context.
    - Ensure session focus (see Session focus in the \`orbitmap\` skill): a valid focus
@@ -1023,13 +1097,22 @@ ${worklogKeepDropTest('   ')}
    - \`note\` is the CATCH-ALL — anything useful that is not \`code_change\` / \`decision\` /
      \`blocker\` goes in as \`note\`, with \`--meta\` for unusual structure. There is deliberately
      NO \`other\` type. NEVER write \`status_change\`: the server authors it on every transition.
-3. Present the outcome as a short, concrete statement that also names what is explicitly
-   OUT of scope and how success will be measured or checked. Refine it with the user until
-   they AGREE — never proceed on a vague or assumed outcome.
+3. Propose the OUTCOME LINES in the terminal (see Outcome lines) together with what is
+   explicitly OUT of scope and how success will be checked. The user accepts or comments;
+   refine and re-propose until the user accepts the whole list — never proceed on a vague
+   or assumed outcome, and never write a line the user has not accepted.
 4. Persist (create or refine). Update an existing unprocessed intent, or create one:
    \`orbitmap intent update IN-x --outcome "<agreed outcome>" [--design "<design notes>"] [--plan "<plan notes>"]\`
    / \`orbitmap intent create "<name>" --outcome "<agreed outcome>" [--design "…"] [--plan "…"]\`.
-   The agreed **outcome** goes in the outcome field. Route the captured notes by type —
+   Write the outcome field in the template: "# Outcomes list" holding ONLY the accepted
+   lines (see Outcome lines), "# Why", then the chapters — What changes and Alternatives
+   rejected optional; Out of scope, Success check and Source obligatory — ending with
+   "## Source" carrying "Outcomes accepted by <who> on <YYYY-MM-DD>". Soft ceiling
+   ~1,500 words: above it, move material to design or plan. Design and plan notes start
+   with "# Summary", a paragraph summing up the whole field, then the body. The server
+   returns the outcomes list as the intent's TL;DR and refuses \`new → design\` without an
+   accepted list.
+   Route the captured notes by type —
    HOW / tech / UX → the **design** field; build-order / task ideas / execution risks → the
    **plan** field (OPTIONAL — only if the conversation produced any). Mark the user's notes
    as the user's in both fields; you may add your own, kept separate. The design gate reads
@@ -1055,9 +1138,9 @@ digraph orbitmap_brainstorm {
     "Clarify idea into an outcome, one question at a time" [shape=box];
     "Log decisions passing the keep/drop test, as they land" [shape=box];
     "Capture user opinions / context as notes" [shape=box];
-    "Present the outcome" [shape=box];
-    "User agrees the outcome?" [shape=diamond];
-    "Create or refine intent: agreed outcome" [shape=box];
+    "Propose outcome lines in the terminal" [shape=box];
+    "User accepts the whole list?" [shape=diamond];
+    "Create or refine intent: accepted lines + template chapters" [shape=box];
     "Route notes to design/plan fields by type (marked as the user's)" [shape=box];
     "Promote referenced idea to used" [shape=box];
     "Advance status new to design, with --log entries (refused if none)" [shape=box];
@@ -1066,11 +1149,11 @@ digraph orbitmap_brainstorm {
     "Gather context: Orb (intents / idea) + repo (files, docs, commits)" -> "Clarify idea into an outcome, one question at a time";
     "Clarify idea into an outcome, one question at a time" -> "Log decisions passing the keep/drop test, as they land";
     "Log decisions passing the keep/drop test, as they land" -> "Capture user opinions / context as notes";
-    "Capture user opinions / context as notes" -> "Present the outcome";
-    "Present the outcome" -> "User agrees the outcome?";
-    "User agrees the outcome?" -> "Clarify idea into an outcome, one question at a time" [label="no, refine"];
-    "User agrees the outcome?" -> "Create or refine intent: agreed outcome" [label="yes"];
-    "Create or refine intent: agreed outcome" -> "Route notes to design/plan fields by type (marked as the user's)";
+    "Capture user opinions / context as notes" -> "Propose outcome lines in the terminal";
+    "Propose outcome lines in the terminal" -> "User accepts the whole list?";
+    "User accepts the whole list?" -> "Propose outcome lines in the terminal" [label="comments, refine"];
+    "User accepts the whole list?" -> "Create or refine intent: accepted lines + template chapters" [label="yes"];
+    "Create or refine intent: accepted lines + template chapters" -> "Route notes to design/plan fields by type (marked as the user's)";
     "Route notes to design/plan fields by type (marked as the user's)" -> "Promote referenced idea to used";
     "Promote referenced idea to used" -> "Advance status new to design, with --log entries (refused if none)";
     "Advance status new to design, with --log entries (refused if none)" -> "Offer orbitmap-design (review or design?)";
@@ -1080,7 +1163,9 @@ digraph orbitmap_brainstorm {
 ## After the outcome
 Before handing off, review the agreed outcome with fresh eyes:
 - **Vague or assumed?** Is it concrete and in the user's words, or did you fill gaps? Fix.
-- **Unmeasurable?** Can you tell when it is met? If not, sharpen the success criteria.
+- **Unmeasurable?** Can you tell when it is met? If not, sharpen the Success check.
+- **Every line clean?** Re-run the six tests on each accepted line; a line that fails is
+  rewritten and re-accepted, never silently changed.
 - **Too big?** If it needs several independent designs, decompose into sibling intents and
   frame the first — do not hand design an outcome that is really three outcomes.
 Then write it (Flow step 4), advance \`new → design\`, and hand the baton to
@@ -1104,8 +1189,10 @@ Then write it (Flow step 4), advance \`new → design\`, and hand the baton to
 - Create-or-refine: reuse an existing unprocessed intent instead of creating a duplicate.
 - Ground the outcome in verified repo/tracker reality, not the plan doc or a stated claim —
   check it is still needed and still undone before framing.
-- Keep the outcome WHAT/WHY: name what is OUT of scope and how success is measured; push
-  HOW answers into the design notes.
+- Keep the outcome WHAT/WHY: the accepted lines say WHAT, the Why chapter says WHY; name
+  what is OUT of scope and how success is checked; push HOW answers into the design notes.
+- Only accepted lines enter the field — no proposed lines, no "?" lines, no
+  proposed/accepted marks; the acceptance record under Source is the user's consent.
 - If the intent already has an agreed outcome (status \`design\` or later), step aside and
   point at \`orbitmap-design\` — do not re-frame a settled outcome.
 - Never auto-chain into designing after framing — always ask first.`;
@@ -1118,7 +1205,8 @@ description: >
   technical spec, and UX (when there's UI), one question at a time, then writes the
   result to the intent's design field. Use for "design this intent", "let's design X", or
   an intent entering \`design\` status. Use it once the outcome is agreed; if the outcome is
-  still missing or vague, step aside to \`orbitmap-brainstorm\` first.
+  still missing or vague, step aside to \`orbitmap-brainstorm\` first. Requires the
+  \`orbitmap\` core skill.
 ---`;
 export const SKILL_DESIGN_BODY = `# Designing an intent's solution
 
@@ -1151,6 +1239,11 @@ holds a real design doc instead of raw notes, treat it as existing design to ref
 ## Key principles
 - **Serve the outcome.** Every question and every section traces back to the outcome; if
   it does not, cut it or go fix the outcome first.
+- **Anchor every question to an outcome.** Open each question with the outcome it
+  serves, quoted by number and short title — "For outcome 3 (verified outcomes get a
+  done check): what does the mark mean at review, and what does done require?" — so
+  the user always knows which promise the decision shapes. A question that fits no
+  outcome is a sign the outcome list is incomplete: raise that, do not ask the question.
 - **One question at a time.** Refine by dialogue, never a questionnaire dump.
 - **Prefer multiple choice — open questions are a LAST RESORT.** When a question's options
   can be enumerated, ALWAYS offer them as a multiple choice with a recommended default; ask
@@ -1162,6 +1255,9 @@ holds a real design doc instead of raw notes, treat it as existing design to ref
   ONE question. Prefer proposing a sensible default for the user to correct over an open
   interrogation. Aim for the few highest-leverage questions — "one question at a time" sets
   the pace, not the total count.
+- **Answer before asking.** When the user's turn contains a question, answer it first —
+  completely — before asking your own. Never return a question with a question; an
+  unanswered user question makes every next question feel like an interrogation.
 - **Lead with a recommendation.** When you propose approaches or technical options, lead
   with the one you recommend and WHY — never a flat, neutral menu with no steer.
 - **YAGNI.** Cut every part of the design that does not serve the outcome; a smaller
@@ -1248,7 +1344,10 @@ ${worklogKeepDropTest('   ')}
 5. Present the draft in sections scaled to their complexity (a few sentences when simple,
    more when nuanced); after each section ask whether it looks right, and get the user's
    approval before writing anything.
-6. Write it: \`orbitmap intent update IN-x --design "<doc>"\`. This REPLACES any framing
+6. Write it: \`orbitmap intent update IN-x --design "<doc>"\`. Start the field with "# Summary"
+   — a paragraph summing up the whole field — then the body. The server reads that section
+   as the field's TL;DR and flags a field written without one.
+   This REPLACES any framing
    notes that were in the field — you have already absorbed them into the doc. When the
    spec names the repos the build will touch, declare them on the intent in the same
    update — \`--areas <slug>,<slug>\` — so session-focus matching works from declared data.
@@ -1346,14 +1445,14 @@ name: orbitmap-docs
 description: >
   Reading and updating OrbitMap documents (specs, architecture, guides, decisions).
   Use when the user asks to read, import, or update project documentation tracked in
-  OrbitMap.
+  OrbitMap. Requires the \`orbitmap\` core skill.
 ---`;
 export const SKILL_DOCS_BODY = `# OrbitMap documents
 
-Documents are workspace-level: exactly ONE copy per workspace, never per-area. No document
-command takes an area, and their metadata (slug, when to use) already rides the context
-payload your session focus was matched from (see Session focus in the \`orbitmap\` skill —
-ensure, don't re-call).
+Documents live at area or workspace level: \`orbitmap docs\` lists every document you can
+reach — your areas' documents plus the workspace-level ones — and their metadata (slug,
+when to use) already rides the context payload your session focus was matched from (see
+Session focus in the \`orbitmap\` skill — ensure, don't re-call).
 
 ## Goal
 Read and update OrbitMap documents efficiently: pull only the context you need (TOC →
@@ -1378,22 +1477,22 @@ for the full content, read that file instead of printing the content into the
 conversation.
 
 ## Editing
-- Import a new document: \`orbitmap doc-import <file.md> --title "…" --type
-  spec|architecture|api|guide|decision|changelog|other [--context "…"]\`.
+- Import a new document: \`orbitmap doc-import <title> --file <file.md> --type
+  spec|architecture|api|guide|decision|changelog|other [--context "…"]\`. It lands
+  area-level, resolved from the current directory; add \`--workspace-id <slug-or-uuid>\`
+  to create it workspace-level instead.
 - Update: \`orbitmap doc-update <slug> --file <file.md>\` (replaces content, bumps
   version).
 - To change an OrbitMap document, ALWAYS go through these commands — NEVER edit files
   inside the OrbitMap workspace/cache directories directly.
 
-## Editing safely — documents have NO revert (known server defects: IS-8wwkb9)
-- Prefer section ops (\`doc-patch --replace-section/--insert-section\`); use line-based
-  ops only when no section op can express the change — line coordinates are shifted
-  server-side assuming ASCENDING order, and blank edges of op content get trimmed.
-- The section parser is not fence-aware: a line-start \`#\` INSIDE a code block is taken
-  for a heading and becomes a section boundary. Keep code-block comments inline
-  (\`cmd  # comment\`), and check target sections for this hazard BEFORE replacing them.
-- Never read a document between a \`doc-update\` upload and its confirm — a cached read
-  makes the confirm silently re-save the OLD content while still bumping the version.
+## Editing safely — documents have NO revert
+- Section ops are the only ops (\`doc-patch --replace-section/--insert-section/
+  --delete-section/--append\`); the line-based ones are gone. On a document with an
+  unclosed code fence every patch op is REFUSED — repair it with a full \`doc-update\`.
+  \`doc-patch --dry-run\` reports the boundaries each op would touch, without writing.
+- The section parser is fence-aware: a line-start \`#\` inside a code block is never a
+  section boundary, and a patch whose result would leave an unclosed fence is refused.
 - After ANY write, re-read the changed section (or TOC for structure) and verify the
   result actually matches what you sent. A bumped version number is not proof.`;
 export const SKILLS = [
@@ -1430,8 +1529,12 @@ export const SKILLS = [
     },
 ];
 // ── The thin always-on hook (CLAUDE.md / AGENTS.md) ────────────────────────────
-// Claude variant — §8.2, verbatim (without the markers, which buildClaudeBlock adds).
-export const THIN_HOOK_CLAUDE = `## OrbitMap
+// The hook for every agent that can LOAD skills — Claude Code and Codex today, whichever
+// agent gains a skills directory next. §8.2, verbatim (without the markers, which
+// buildSkillsBlock adds). It was written for Claude and used to be named after it, but
+// nothing in the text is Claude-specific: it only says WHEN to load the skills, and any
+// agent that discovers `<name>/SKILL.md` can act on it.
+export const THIN_HOOK_SKILLS = `## OrbitMap
 
 Work is tracked in OrbitMap via the \`orbitmap\` CLI. You work in a WORKSPACE, which can span
 several repositories: each repo is an AREA, while missions, intents and documents belong to
@@ -1439,14 +1542,15 @@ the workspace itself, not to any one repo.
 Load the OrbitMap skills whenever the user wants to build, add, change or fix something, in
 whatever words they use — do not wait for OrbitMap vocabulary. Load them too when they talk
 about tracking work (backlog, tasks, missions, intents, ideas, issues, documents, planning).
+Load the core skill 'orbitmap' first, before any other orbitmap-* skill — they all build on it.
 Nothing gets built before it is framed: a feature, component or behaviour change gets an intent
 — outcome (brainstorm) → design → plan → build (execute), one gate at a time, written to the
 intent as you go. Small self-contained work (a typo, an obvious one-file fix) is just a task.
 NEVER finish a task, intent or mission without a final \`orbitmap log\` entry and a status update;
 the final entry closes a record that already exists. Finished work defaults to \`in_review\`, not \`done\`.
 OrbitMap tool responses may carry an Instructions section — act on it before continuing.`;
-// Non-Claude variant: same rules, but points at the inlined sections below instead of
-// skills that these agents cannot load.
+// The variant for agents with NO skill ecosystem: same rules, but it points at the
+// inlined sections below, because there are no skill files for these agents to load.
 export const THIN_HOOK_GENERIC = `## OrbitMap
 
 Work is tracked in OrbitMap via the \`orbitmap\` CLI. You work in a WORKSPACE, which can span
@@ -1462,34 +1566,46 @@ NEVER finish a task, intent or mission without a final \`orbitmap log\` entry an
 the final entry closes a record that already exists. Finished work defaults to \`in_review\`, not \`done\`.
 OrbitMap tool responses may carry an Instructions section — act on it before continuing.`;
 // ── Assembly helpers ───────────────────────────────────────────────────────────
-/** Build one SKILL.md file (frontmatter + body) for Claude. */
+/**
+ * Build one SKILL.md file (frontmatter + body). The layout is the same for every
+ * skills-capable agent — Claude Code and Codex read identical frontmatter — so one
+ * renderer serves all of them.
+ */
 export function buildSkillFile(skill) {
     return `${skill.frontmatter}\n\n${skill.body}\n`;
 }
 /**
- * One extra line appended to the Claude hook when the skills were installed at PROJECT
+ * One extra line appended to the thin hook when the skills were installed at PROJECT
  * scope. `CLAUDE.md` is inherited by every sub-directory, but a project-level
  * `.claude/skills/` directory is not: a session started in a sibling or child repository
  * reads this hook and cannot load the skills it names. The hook must therefore say where
  * the skills actually are, and how to make them visible everywhere. At user scope the
  * skills are visible wherever the hook is, so no caveat is needed.
+ *
+ * It names `.claude/skills/` because Claude Code is the only agent that can reach it:
+ * project scope installs skills only for an agent that READS them at project scope, and
+ * Codex — the other skills-capable agent — discovers skills under `$CODEX_HOME` only.
  */
 export const SKILL_SCOPE_CAVEAT_PROJECT = 'These skills are installed at PROJECT scope, in this directory\'s `.claude/skills/`. ' +
     'If you cannot load them (e.g. this session started in a different directory), do not ' +
     'guess the workflow — ask the user to run `orbitmap setup-agent --scope user`, which ' +
     'installs them into `~/.claude/skills/` where every session can see them.';
 /**
- * Build the thin always-on block for a Claude config file (CLAUDE.md).
+ * Build the thin always-on block for ANY skills-capable agent's config file — `CLAUDE.md`
+ * for Claude Code, `AGENTS.md` for Codex. Both get the same block, because both load the
+ * skills the block points at; the file it lands in is the installer's business, not this
+ * function's.
+ *
  * `scope` is where the accompanying skill files were installed — see
  * {@link SKILL_SCOPE_CAVEAT_PROJECT}.
  */
-export function buildClaudeBlock(scope = 'user') {
-    const body = scope === 'project' ? `${THIN_HOOK_CLAUDE}\n${SKILL_SCOPE_CAVEAT_PROJECT}` : THIN_HOOK_CLAUDE;
+export function buildSkillsBlock(scope = 'user') {
+    const body = scope === 'project' ? `${THIN_HOOK_SKILLS}\n${SKILL_SCOPE_CAVEAT_PROJECT}` : THIN_HOOK_SKILLS;
     return `${MARKER_START}\n${body}\n${MARKER_END}`;
 }
 /**
- * Build the markdown fallback block for non-Claude agents: the thin hook plus every
- * skill body inlined (no skill ecosystem to lean on).
+ * Build the markdown fallback block for agents with no skill ecosystem: the thin hook plus
+ * every skill body inlined, because there is nothing to load on demand.
  */
 export function buildGenericBlock() {
     const bodies = SKILLS.map((skill) => skill.body).join('\n\n---\n\n');

package/dist/agent-instructions.js.map

@@ -1 +1 @@
-{"version":3,"file":"agent-instructions.js","sourceRoot":"","sources":["../src/agent-instructions.ts"],"names":[],"mappings":"AAAA,yEAAyE;AACzE,EAAE;AACF,oFAAoF;AACpF,oFAAoF;AACpF,wEAAwE;AACxE,EAAE;AACF,2DAA2D;AAC3D,oFAAoF;AACpF,oFAAoF;AACpF,oFAAoF;AACpF,+EAA+E;AAC/E,qEAAqE;AACrE,6EAA6E;AAC7E,oFAAoF;AACpF,4DAA4D;AAC5D,8EAA8E;AAC9E,6EAA6E;AAC7E,kFAAkF;AAClF,8EAA8E;AAC9E,qFAAqF;AACrF,sFAAsF;AACtF,uFAAuF;AACvF,uFAAuF;AACvF,yFAAyF;AACzF,mFAAmF;AACnF,qFAAqF;AACrF,4EAA4E;AAC5E,oFAAoF;AACpF,kFAAkF;AAClF,2EAA2E;AAC3E,0DAA0D;AAC1D,0CAA0C;AAC1C,wFAAwF;AACxF,wFAAwF;AACxF,sEAAsE;AACtE,qFAAqF;AACrF,qFAAqF;AACrF,iFAAiF;AACjF,wFAAwF;AACxF,sFAAsF;AACtF,+CAA+C;AAC/C,EAAE;AACF,gFAAgF;AAChF,qFAAqF;AACrF,qFAAqF;AACrF,qFAAqF;AACrF,2EAA2E;AAE3E,OAAO,EAAE,aAAa,EAAE,MAAM,aAAa,CAAC;AAE5C;;;;GAIG;AACH,MAAM,CAAC,MAAM,WAAW,GACtB,aAAa,CAAC,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC,iBAAiB,CACjD,CAAC,OAAO,CAAC;AAEV;;;;;;GAMG;AACH,MAAM,CAAC,MAAM,mBAAmB,GAAG,qBAAqB,CAAC;AAEzD;;;GAGG;AACH,MAAM,CAAC,MAAM,YAAY,GAAG,GAAG,mBAAmB,KAAK,WAAW,MAAM,CAAC;AAEzE,6EAA6E;AAC7E,MAAM,CAAC,MAAM,UAAU,GAAG,uBAAuB,CAAC;AAElD;;;;;;GAMG;AACH,MAAM,UAAU,2BAA2B,CAAC,OAAe;IACzD,MAAM,KAAK,GAAG,OAAO,CAAC,KAAK,CAAC,0CAA0C,CAAC,CAAC;IACxE,IAAI,CAAC,KAAK;QAAE,OAAO,SAAS,CAAC;IAC7B,OAAO,KAAK,CAAC,CAAC,CAAC,IAAI,IAAI,CAAC;AAC1B,CAAC;AAED,2EAA2E;AAC3E,MAAM,CAAC,MAAM,UAAU,GAAG,UAAU,CAAC;AAErC,kFAAkF;AAClF,EAAE;AACF,mFAAmF;AACnF,wFAAwF;AACxF,qFAAqF;AACrF,oFAAoF;AACpF,EAAE;AACF,oFAAoF;AACpF,oFAAoF;AACpF,mFAAmF;AACnF,gDAAgD;AAChD,MAAM,CAAC,MAAM,qBAAqB,GAAG;;;;;;;;;;;;;;;;;;;;;;wDAsBmB,CAAC;AAEzD,kFAAkF;AAClF,EAAE;AACF,uFAAuF;AACvF,wFAAwF;AACxF,yCAAyC;AACzC,MAAM,CAAC,MAAM,iBAAiB,GAAG;;;;;;;;;;;;;;;qDAeoB,CAAC;AAEtD,kFAAkF;AAClF,EAAE;AACF,uFAAuF;AACvF,oFAAoF;AACpF,sFAAsF;AACtF,oFAAoF;AACpF,mFAAmF;AACnF,qFAAqF;AACrF,+CAA+C;AAC/C,EAAE;AACF,qFAAqF;AACrF,sFAAsF;AACtF,MAAM,UAAU,mBAAmB,CAAC,MAAM,GAAG,EAAE;IAC7C,MAAM,CAAC,GAAG,GAAG,MAAM,IAAI,CAAC;IAExB,OAAO,GAAG,MAAM;EAChB,CAAC;EACD,CAAC;EACD,CAAC;EACD,CAAC;EACD,CAAC;EACD,CAAC;EACD,CAAC;EACD,CAAC;EACD,CAAC;EACD,CAAC;EACD,CAAC;EACD,CAAC;EACD,CAAC;EACD,CAAC;EACD,CAAC;EACD,CAAC;EACD,CAAC,oEAAoE,CAAC;AACxE,CAAC;AAED,kFAAkF;AAElF,MAAM,CAAC,MAAM,0BAA0B,GAAG;;;;;;IAMtC,CAAC;AAEL,MAAM,CAAC,MAAM,mBAAmB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAgCjC,qBAAqB;;EAErB,iBAAiB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;gEAqF6C,CAAC;AAEjE,qFAAqF;AAErF,MAAM,CAAC,MAAM,yBAAyB,GAAG;;;;;;;;;;;IAWrC,CAAC;AAEL,MAAM,CAAC,MAAM,kBAAkB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAwMhC,mBAAmB,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;sCAiEe,CAAC;AAEvC,oFAAoF;AACpF,qFAAqF;AACrF,oCAAoC;AACpC,MAAM,CAAC,MAAM,wBAAwB,GAAqC;IACxE,+BAA+B,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;gFA0D6C;CAC/E,CAAC;AAEF,8EAA8E;AAE9E,MAAM,CAAC,MAAM,sBAAsB,GAAG;;;;;;;;;;;IAWlC,CAAC;AAEL,MAAM,CAAC,MAAM,eAAe,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAqG7B,mBAAmB,CAAC,KAAK,CAAC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;yEAuJ6C,CAAC;AAE1E,+FAA+F;AAE/F,MAAM,CAAC,MAAM,4BAA4B,GAAG;;;;;;;;;;;IAWxC,CAAC;AAEL,MAAM,CAAC,MAAM,qBAAqB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EA6FnC,mBAAmB,CAAC,KAAK,CAAC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;oEA+FwC,CAAC;AAErE,2FAA2F;AAE3F,MAAM,CAAC,MAAM,wBAAwB,GAAG;;;;;;;;;IASpC,CAAC;AAEL,MAAM,CAAC,MAAM,iBAAiB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAiG/B,mBAAmB,CAAC,KAAK,CAAC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;8EA0HkD,CAAC;AAE/E,kFAAkF;AAElF,MAAM,CAAC,MAAM,sBAAsB,GAAG;;;;;;IAMlC,CAAC;AAEL,MAAM,CAAC,MAAM,eAAe,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;+EA+CgD,CAAC;AA0BhF,MAAM,CAAC,MAAM,MAAM,GAAwB;IACzC;QACE,IAAI,EAAE,UAAU;QAChB,WAAW,EAAE,0BAA0B;QACvC,IAAI,EAAE,mBAAmB;KAC1B;IACD;QACE,IAAI,EAAE,kBAAkB;QACxB,WAAW,EAAE,yBAAyB;QACtC,IAAI,EAAE,kBAAkB;QACxB,UAAU,EAAE,wBAAwB;KACrC;IACD;QACE,IAAI,EAAE,eAAe;QACrB,WAAW,EAAE,sBAAsB;QACnC,IAAI,EAAE,eAAe;KACtB;IACD;QACE,IAAI,EAAE,qBAAqB;QAC3B,WAAW,EAAE,4BAA4B;QACzC,IAAI,EAAE,qBAAqB;KAC5B;IACD;QACE,IAAI,EAAE,iBAAiB;QACvB,WAAW,EAAE,wBAAwB;QACrC,IAAI,EAAE,iBAAiB;KACxB;IACD;QACE,IAAI,EAAE,eAAe;QACrB,WAAW,EAAE,sBAAsB;QACnC,IAAI,EAAE,eAAe;KACtB;CACO,CAAC;AAEX,kFAAkF;AAElF,sFAAsF;AACtF,MAAM,CAAC,MAAM,gBAAgB,GAAG;;;;;;;;;;;;;yFAayD,CAAC;AAE1F,sFAAsF;AACtF,wCAAwC;AACxC,MAAM,CAAC,MAAM,iBAAiB,GAAG;;;;;;;;;;;;;yFAawD,CAAC;AAE1F,kFAAkF;AAElF,+DAA+D;AAC/D,MAAM,UAAU,cAAc,CAAC,KAAe;IAC5C,OAAO,GAAG,KAAK,CAAC,WAAW,OAAO,KAAK,CAAC,IAAI,IAAI,CAAC;AACnD,CAAC;AAED;;;;;;;GAOG;AACH,MAAM,CAAC,MAAM,0BAA0B,GACrC,uFAAuF;IACvF,uFAAuF;IACvF,sFAAsF;IACtF,0EAA0E,CAAC;AAE7E;;;;GAIG;AACH,MAAM,UAAU,gBAAgB,CAAC,QAA4B,MAAM;IACjE,MAAM,IAAI,GACR,KAAK,KAAK,SAAS,CAAC,CAAC,CAAC,GAAG,gBAAgB,KAAK,0BAA0B,EAAE,CAAC,CAAC,CAAC,gBAAgB,CAAC;IAChG,OAAO,GAAG,YAAY,KAAK,IAAI,KAAK,UAAU,EAAE,CAAC;AACnD,CAAC;AAED;;;GAGG;AACH,MAAM,UAAU,iBAAiB;IAC/B,MAAM,MAAM,GAAG,MAAM,CAAC,GAAG,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,IAAI,CAAC,aAAa,CAAC,CAAC;IACrE,OAAO,GAAG,YAAY,KAAK,iBAAiB,OAAO,MAAM,KAAK,UAAU,EAAE,CAAC;AAC7E,CAAC"}
+{"version":3,"file":"agent-instructions.js","sourceRoot":"","sources":["../src/agent-instructions.ts"],"names":[],"mappings":"AAAA,yEAAyE;AACzE,EAAE;AACF,oFAAoF;AACpF,0FAA0F;AAC1F,sFAAsF;AACtF,EAAE;AACF,2DAA2D;AAC3D,oFAAoF;AACpF,oFAAoF;AACpF,oFAAoF;AACpF,+EAA+E;AAC/E,qEAAqE;AACrE,6EAA6E;AAC7E,oFAAoF;AACpF,4DAA4D;AAC5D,8EAA8E;AAC9E,6EAA6E;AAC7E,kFAAkF;AAClF,8EAA8E;AAC9E,qFAAqF;AACrF,sFAAsF;AACtF,uFAAuF;AACvF,uFAAuF;AACvF,yFAAyF;AACzF,mFAAmF;AACnF,qFAAqF;AACrF,4EAA4E;AAC5E,oFAAoF;AACpF,kFAAkF;AAClF,2EAA2E;AAC3E,0DAA0D;AAC1D,wFAAwF;AACxF,sFAAsF;AACtF,qFAAqF;AACrF,uFAAuF;AACvF,yFAAyF;AACzF,gEAAgE;AAChE,0FAA0F;AAC1F,qFAAqF;AACrF,0FAA0F;AAC1F,uFAAuF;AACvF,yFAAyF;AACzF,kEAAkE;AAClE,EAAE;AACF,gFAAgF;AAChF,qFAAqF;AACrF,qFAAqF;AACrF,qFAAqF;AACrF,2EAA2E;AAE3E,OAAO,EAAE,aAAa,EAAE,MAAM,aAAa,CAAC;AAE5C;;;;GAIG;AACH,MAAM,CAAC,MAAM,WAAW,GACtB,aAAa,CAAC,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC,iBAAiB,CACjD,CAAC,OAAO,CAAC;AAEV;;;;;;GAMG;AACH,MAAM,CAAC,MAAM,mBAAmB,GAAG,qBAAqB,CAAC;AAEzD;;;GAGG;AACH,MAAM,CAAC,MAAM,YAAY,GAAG,GAAG,mBAAmB,KAAK,WAAW,MAAM,CAAC;AAEzE,6EAA6E;AAC7E,MAAM,CAAC,MAAM,UAAU,GAAG,uBAAuB,CAAC;AAElD;;;;;;GAMG;AACH,MAAM,UAAU,2BAA2B,CAAC,OAAe;IACzD,MAAM,KAAK,GAAG,OAAO,CAAC,KAAK,CAAC,0CAA0C,CAAC,CAAC;IACxE,IAAI,CAAC,KAAK;QAAE,OAAO,SAAS,CAAC;IAC7B,OAAO,KAAK,CAAC,CAAC,CAAC,IAAI,IAAI,CAAC;AAC1B,CAAC;AAED,2EAA2E;AAC3E,MAAM,CAAC,MAAM,UAAU,GAAG,UAAU,CAAC;AAErC,kFAAkF;AAClF,EAAE;AACF,mFAAmF;AACnF,wFAAwF;AACxF,qFAAqF;AACrF,oFAAoF;AACpF,EAAE;AACF,oFAAoF;AACpF,oFAAoF;AACpF,mFAAmF;AACnF,gDAAgD;AAChD,MAAM,CAAC,MAAM,qBAAqB,GAAG;;;;;;;;;;;;;;;;;;;;;;wDAsBmB,CAAC;AAEzD,kFAAkF;AAClF,EAAE;AACF,uFAAuF;AACvF,wFAAwF;AACxF,yCAAyC;AACzC,MAAM,CAAC,MAAM,iBAAiB,GAAG;;;;;;;;;;;;;;;qDAeoB,CAAC;AAEtD,kFAAkF;AAClF,EAAE;AACF,uFAAuF;AACvF,oFAAoF;AACpF,sFAAsF;AACtF,oFAAoF;AACpF,mFAAmF;AACnF,qFAAqF;AACrF,+CAA+C;AAC/C,EAAE;AACF,qFAAqF;AACrF,sFAAsF;AACtF,MAAM,UAAU,mBAAmB,CAAC,MAAM,GAAG,EAAE;IAC7C,MAAM,CAAC,GAAG,GAAG,MAAM,IAAI,CAAC;IAExB,OAAO,GAAG,MAAM;EAChB,CAAC;EACD,CAAC;EACD,CAAC;EACD,CAAC;EACD,CAAC;EACD,CAAC;EACD,CAAC;EACD,CAAC;EACD,CAAC;EACD,CAAC;EACD,CAAC;EACD,CAAC;EACD,CAAC;EACD,CAAC;EACD,CAAC;EACD,CAAC;EACD,CAAC,oEAAoE,CAAC;AACxE,CAAC;AAED,kFAAkF;AAElF,MAAM,CAAC,MAAM,0BAA0B,GAAG;;;;;;;;;IAStC,CAAC;AAEL,MAAM,CAAC,MAAM,mBAAmB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAuCjC,qBAAqB;;EAErB,iBAAiB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;gEAoF6C,CAAC;AAEjE,qFAAqF;AAErF,MAAM,CAAC,MAAM,yBAAyB,GAAG;;;;;;;;;;;IAWrC,CAAC;AAEL,MAAM,CAAC,MAAM,kBAAkB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EA2MhC,mBAAmB,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;sCAiEe,CAAC;AAEvC,oFAAoF;AACpF,qFAAqF;AACrF,oCAAoC;AACpC,MAAM,CAAC,MAAM,wBAAwB,GAAqC;IACxE,+BAA+B,EAAE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;gFA0D6C;CAC/E,CAAC;AAEF,8EAA8E;AAE9E,MAAM,CAAC,MAAM,sBAAsB,GAAG;;;;;;;;;;;IAWlC,CAAC;AAEL,MAAM,CAAC,MAAM,eAAe,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAqG7B,mBAAmB,CAAC,KAAK,CAAC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;yEA4J6C,CAAC;AAE1E,+FAA+F;AAE/F,MAAM,CAAC,MAAM,4BAA4B,GAAG;;;;;;;;;;;;IAYxC,CAAC;AAEL,MAAM,CAAC,MAAM,qBAAqB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAmJnC,mBAAmB,CAAC,KAAK,CAAC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;oEA4GwC,CAAC;AAErE,2FAA2F;AAE3F,MAAM,CAAC,MAAM,wBAAwB,GAAG;;;;;;;;;;IAUpC,CAAC;AAEL,MAAM,CAAC,MAAM,iBAAiB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAyG/B,mBAAmB,CAAC,KAAK,CAAC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;8EA6HkD,CAAC;AAE/E,kFAAkF;AAElF,MAAM,CAAC,MAAM,sBAAsB,GAAG;;;;;;IAMlC,CAAC;AAEL,MAAM,CAAC,MAAM,eAAe,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;+EA+CgD,CAAC;AA6BhF,MAAM,CAAC,MAAM,MAAM,GAAwB;IACzC;QACE,IAAI,EAAE,UAAU;QAChB,WAAW,EAAE,0BAA0B;QACvC,IAAI,EAAE,mBAAmB;KAC1B;IACD;QACE,IAAI,EAAE,kBAAkB;QACxB,WAAW,EAAE,yBAAyB;QACtC,IAAI,EAAE,kBAAkB;QACxB,UAAU,EAAE,wBAAwB;KACrC;IACD;QACE,IAAI,EAAE,eAAe;QACrB,WAAW,EAAE,sBAAsB;QACnC,IAAI,EAAE,eAAe;KACtB;IACD;QACE,IAAI,EAAE,qBAAqB;QAC3B,WAAW,EAAE,4BAA4B;QACzC,IAAI,EAAE,qBAAqB;KAC5B;IACD;QACE,IAAI,EAAE,iBAAiB;QACvB,WAAW,EAAE,wBAAwB;QACrC,IAAI,EAAE,iBAAiB;KACxB;IACD;QACE,IAAI,EAAE,eAAe;QACrB,WAAW,EAAE,sBAAsB;QACnC,IAAI,EAAE,eAAe;KACtB;CACO,CAAC;AAEX,kFAAkF;AAElF,yFAAyF;AACzF,kFAAkF;AAClF,uFAAuF;AACvF,wFAAwF;AACxF,wDAAwD;AACxD,MAAM,CAAC,MAAM,gBAAgB,GAAG;;;;;;;;;;;;;;yFAcyD,CAAC;AAE1F,mFAAmF;AACnF,qFAAqF;AACrF,MAAM,CAAC,MAAM,iBAAiB,GAAG;;;;;;;;;;;;;yFAawD,CAAC;AAE1F,kFAAkF;AAElF;;;;GAIG;AACH,MAAM,UAAU,cAAc,CAAC,KAAe;IAC5C,OAAO,GAAG,KAAK,CAAC,WAAW,OAAO,KAAK,CAAC,IAAI,IAAI,CAAC;AACnD,CAAC;AAED;;;;;;;;;;;GAWG;AACH,MAAM,CAAC,MAAM,0BAA0B,GACrC,uFAAuF;IACvF,uFAAuF;IACvF,sFAAsF;IACtF,0EAA0E,CAAC;AAE7E;;;;;;;;GAQG;AACH,MAAM,UAAU,gBAAgB,CAAC,QAA4B,MAAM;IACjE,MAAM,IAAI,GACR,KAAK,KAAK,SAAS,CAAC,CAAC,CAAC,GAAG,gBAAgB,KAAK,0BAA0B,EAAE,CAAC,CAAC,CAAC,gBAAgB,CAAC;IAChG,OAAO,GAAG,YAAY,KAAK,IAAI,KAAK,UAAU,EAAE,CAAC;AACnD,CAAC;AAED;;;GAGG;AACH,MAAM,UAAU,iBAAiB;IAC/B,MAAM,MAAM,GAAG,MAAM,CAAC,GAAG,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,IAAI,CAAC,aAAa,CAAC,CAAC;IACrE,OAAO,GAAG,YAAY,KAAK,iBAAiB,OAAO,MAAM,KAAK,UAAU,EAAE,CAAC;AAC7E,CAAC"}

package/dist/commands/context.js

@@ -150,6 +150,19 @@ function statusTag(status, closed) {
 function intentTldr(intent) {
     return intent.outcome_tldr ?? intent.design_tldr ?? intent.plan_tldr;
 }
+/**
+ * A TL;DR line under a handle, indented, respecting multiple lines verbatim (design
+ * IN-wazu8k Key decisions: "slim and context return the whole list, no truncation, no
+ * cap in the CLI either"). `TldrParser::extract()` now returns the full outcomes list
+ * (or a `# Summary` paragraph) joined by `\n` rather than a single collapsed line, so
+ * every line of a multi-line TL;DR prints, each at the same indent.
+ */
+function printIndentedTldr(tldr, indent) {
+    if (!tldr)
+        return;
+    for (const line of tldr.split('\n'))
+        console.log(`${indent}${line}`);
+}
 function printMissions(missions) {
     if (missions.length === 0)
         return;
@@ -158,8 +171,7 @@ function printMissions(missions) {
         // The active mission is the session's likeliest frame — marked so it reads first.
         const marker = mission.status === 'active' ? '▸' : ' ';
         console.log(`  ${marker} ${mission.number} ${mission.name} ${statusTag(mission.status, CLOSED_MISSION_STATUSES)}`);
-        if (mission.outcome_tldr)
-            console.log(`      ${mission.outcome_tldr}`);
+        printIndentedTldr(mission.outcome_tldr, '      ');
     }
 }
 /**
@@ -176,9 +188,7 @@ function printIntents(intents, missions) {
         printed.add(intent);
         const areas = intent.areas.length > 0 ? ` (${intent.areas.join(', ')})` : '';
         console.log(`${indent}${intent.number} ${intent.name} ${statusTag(intent.status, CLOSED_INTENT_STATUSES)}${areas}`);
-        const tldr = intentTldr(intent);
-        if (tldr)
-            console.log(`${indent}    ${tldr}`);
+        printIndentedTldr(intentTldr(intent), `${indent}    `);
     };
     for (const mission of missions) {
         const group = intents.filter((i) => i.mission === mission.number && !printed.has(i));