@c4a/context-cli 0.5.35-beta.1 → 0.5.36-beta.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@c4a/context-cli",
-  "version": "0.5.35-beta.1",
+  "version": "0.5.36-beta.1",
   "type": "module",
   "bin": {
     "context": "./cli.js"

package/plugin/README.md

@@ -52,7 +52,7 @@ Then install the plugin matching the agent you use:
 
 | Agent | Install |
 |---|---|
-| Claude Code | `/plugin marketplace add context4ai/context`, then `/plugin install context@context` |
+| Claude Code | `/plugin marketplace add context4ai/context`, then `/plugin install context@c4a` |
 | Cursor | Dashboard → Settings → Plugins → Import → `https://github.com/context4ai/context` |
 | Codex CLI | `codex marketplace add context4ai/context` |
 | Vercel-style skills (Windsurf / OpenCode / Cline / Copilot, etc.) | `npx skills add github:context4ai/context <skill-name>` |
@@ -67,7 +67,7 @@ From your project directory:
 
 1. **Init** — `/context:init` creates the `.context/` workspace;
 2. **Capture** — `/context:capture <url-or-path>` pulls in Feishu docs, local Markdown, code snapshots, and so on;
-3. **Code projection** — for code snapshots, `/context:compile --code <source-slug>` materializes package/category/symbol Nodes such as `pkg`, `pkg/components`, and `pkg/symbol/button`;
+3. **Code projection** — for code snapshots, `/context:compile code <source-slug>` materializes package/category/symbol Nodes such as `pkg`, `pkg/components`, and `pkg/symbol/button`;
 4. **Align** — `/context:align` places prose material onto the Node structure, including docs or examples that should attach to existing code symbol Nodes;
 5. **Compile** — `/context:compile` lets the AI turn prose material into structured Sections;
 6. **Query** — `/context:query <question>` answers from local knowledge, citing Node and Section; code workspaces can filter mixed evidence with `--evidence code|prose|all`;

package/plugin/README_CN.md

@@ -52,7 +52,7 @@ bun add -g @c4a/context-cli
 
 | Agent | 安装方式 |
 |---|---|
-| Claude Code | `/plugin marketplace add context4ai/context`，再执行 `/plugin install context@context` |
+| Claude Code | `/plugin marketplace add context4ai/context`，再执行 `/plugin install context@c4a` |
 | Cursor | Dashboard → Settings → Plugins → Import → `https://github.com/context4ai/context` |
 | Codex CLI | `codex marketplace add context4ai/context` |
 | Vercel-style skills（Windsurf / OpenCode / Cline / Copilot 等） | `npx skills add github:context4ai/context <skill-name>` |
@@ -67,7 +67,7 @@ bun add -g @c4a/context-cli
 
 1. **初始化** — `/context:init` 创建 `.context/` 工作目录；
 2. **采集** — `/context:capture <url-or-path>` 拉取飞书文档、本地 Markdown、代码快照等原始资料；
-3. **代码投影** — 对代码快照执行 `/context:compile --code <source-slug>`，生成 `pkg`、`pkg/components`、`pkg/symbol/button` 这类 package/category/symbol Node；
+3. **代码投影** — 对代码快照执行 `/context:compile code <source-slug>`，生成 `pkg`、`pkg/components`、`pkg/symbol/button` 这类 package/category/symbol Node；
 4. **对齐** — `/context:align` 将文档原料归位至 Node 结构，包括挂靠到已有 code symbol Node 的手册、示例和经验；
 5. **编译** — `/context:compile` 由 AI 将文档原料加工为结构化 Section；
 6. **检索** — `/context:query <问题>` 在本地知识中查询答案，返回 Node 与 Section 级引用；代码工作区可用 `--evidence code|prose|all` 区分代码证据和文档证据；

package/plugin/commands/align.md

@@ -6,102 +6,55 @@ allowed-tools: Bash(context:*)
 
 ## Your Task
 
-Run the beta.8 align workflow. `/context:align` is the user entrypoint; internal stages are workflow payloads, not public slash commands.
-
-If `$ARGUMENTS` contains `--code`, run `context align --code [slug]` and report that dry-run projection plan. This route is CLI-owned, writes no workflow/process files, and is the same deterministic plan implementation used by `context compile --code`.
-
-Keep the prompt shape stable: read fixed schema/protocol first, then existing knowledge lookup, then the current source-specific payload. Do not reorder CLI JSON, add timestamps, or invent scratch paths.
-
-1. Run `context align --scan --format json`. Use the returned workflow payload name, scope id, digest, and `next_command` / `show_command` fields as the continuation handles.
-   - If the align-segments payload includes `generation_policy`, use it as the language contract for generated Node titles, summaries, rationale prose, and planned Section wording. Source-bound Section wording should stay close to the cited source language when it differs from the workspace language. Preserve product names, code identifiers, slugs, flags, `block_id` handles, and citation tokens exactly when needed.
-   - Source titles and headings are ordinary evidence only. Do not automatically copy them into Node titles or aliases; classify the evidence referent first, then choose a title that fits the final Node type.
-2. Read schema and payloads through CLI only:
-   - `context schema align-segments`
-   - `context schema align-coarse-read`
-   - `context schema align-candidate-ops`
-   - `context schema align-candidate-ledger`
-   - `context schema align-candidate-aggregate`
-   - `context schema align-structure-decision`
-   - `context workflow show --payload align-segments --view segment --unwrap --format json`
-   - `context workflow show --payload align-segments --view source-mapping --unwrap --format json`
-   - `context workflow show --payload align-segments --view blocks --token-budget 2000 --unwrap --format json`
-   - `context workflow show --payload align-segments --view windows --unwrap --format json`
-   - Drill into content only with semantic filters such as `--source <source-id>`, `--heading <prefix>`, `--window <window-id|src-N:M>`, or a larger `--token-budget <n>`. `src-N:M` means the M-th window under the `source_alias` shown by `--view windows`. If a budgeted view returns `truncated: true`, follow its `how_to_explore[]` commands before increasing the budget.
-   - `--unwrap` only removes the workflow metadata envelope. It does not turn a summary view into detail output.
-3. Reuse existing knowledge before inventing candidates. For named terms or entities, prefer `context mdrive glossary match <name>` and `context mdrive node list --format json` over direct file reads. Treat `match.kind`, `match.matched`, and `match.rank` as stable lookup hints: exact title/slug/alias hits should usually reuse the existing Node instead of creating another one.
-   - Apply packaged `context:skill-align-workflow` Node classification gates before candidate ops and again before finalize: Action requires scale plus process evidence; Entity requires a concrete A/B tag or pure `term`; Domain requires child Nodes; fake Entities need at least two suspicious signals before downgrade. Scope/process words in a source title, such as "方案", "架构", "流程", "策略", or "演练", are review signals for the title/type choice, not proof that the Node is an Entity.
-   - Code projection Nodes are reusable knowledge handles. When prose evidence should attach to an existing code symbol Node, reuse the code slug (for example `pkg/symbol/button`) instead of creating a parallel document Node. If that code slug is not already in finalized prose ownership, declare it in the current `nodes[]` with the same node type and compatible tags/title, add the desired `planned_sections`, and point `sections[].owner` plus `block_ownership[].owners` at that slug. Do not cite `aspect:code:*` source refs from prose Sections; prose Sections cite only the current document evidence.
-4. Submit generated workflow payloads directly through stdin, preferably as JSON. Use YAML schemas only for reading examples when helpful; generated artifacts should avoid YAML quoting/indentation failure loops. Do not create `/tmp` or workspace scratch files for align payloads. The CLI owns ids, reducer validation, workflow payload storage, and mechanical aggregate. You own semantic discovery, Node type/tag decisions, structure decisions, and user-facing questions.
-   - Save coarse-read with `context align --coarse-read - --format json`.
-     The latest `align-coarse-read` payload is only the most recent checkpoint; durable multi-source reading notes are stored under `align-candidate-ledger.source_readings`.
-     Prefer omitting `schema_version` in generated coarse-read JSON; the CLI infers single-source vs batch from shape. For multiple sources, submit one envelope with `coarse_reads[]`; each entry must use the current coarse-read fields (`source_id`, `density_profile`, `reading_anchors`, `section_proposals`), not retired `reading_notes` / `block_readings`.
-   - Submit each candidate batch with `context align --ops - --format json`. Prefer omitting `schema_version`; the CLI normalizes candidate ops to the current schema. Keep `batch_id`, `ops[]`, and current op field names from `context schema align-candidate-ops`.
-   - `--ledger-digest <digest>` is optional. Usually omit it and let the CLI merge against the current ledger; pass it only when you intentionally want stale-batch rejection for a high-assurance retry.
-   - Read the resulting payloads with `context workflow show --payload align-candidate-ledger --view ledger --unwrap --format json` and `context workflow show --payload align-candidate-aggregate --view aggregate --unwrap --format json`. To revisit one source's coarse-read notes, add `--source <source-id>` to the ledger view; candidates do not carry source ids, so add `--status` or `--candidate-id` only when you also need candidate rows.
-   - Review `anomaly_signals[]` as warnings: fix clear mistakes with another ops batch, otherwise continue to finalize and carry the warning rationale in your final decision/report.
-5. If any CLI command returns `agent_hints[]`, follow those hints before retrying. Legacy-protocol hints mean the submitted payload or schema name is retired; switch to the beta.8 schema named in the hint instead of adapting old fields.
-6. Finalize only with `align-structure-decision`:
-
-```bash
-context align --finalize -
-```
-
-If finalize returns an `align-finalize-draft` payload, patch that saved draft with JSON Pointer paths from the returned issues instead of resubmitting the full document. Patch paths are relative to `raw_decision`, so use `/nodes/...`, `/sections/...`, or `/block_ownership/...` rather than `/raw_decision/...`:
-
-```json
-{
-  "schema_version": "align.finalize-patch.v1",
-  "operations": [
-    { "op": "replace", "path": "/block_ownership/3/primary_owner", "value": "rspack" }
-  ]
-}
-```
-
-Submit the patch with `context align --finalize-patch - --format json`. Add `--payload-digest` only when you intentionally want an explicit stale guard.
-
-After a successful finalize, use a targeted ownership patch for small role corrections only; do not resubmit the whole structure just to move a few blocks between `context_only`, `ignored`, `owned`, or `shared`:
-
-```json
-{
-  "schema_version": "align.ownership-patch.v1",
-  "base_digest": "sha256:<finalized-ownership-digest>",
-  "block_ownership": [
-    {
-      "block_id": "<block-id>",
-      "ownership_role": "owned",
-      "owners": ["<node-slug>"],
-      "visible_to": ["<node-slug>"],
-      "reason": "Why this block is citation evidence for the node."
-    }
-  ]
-}
-```
-
-Submit it with `context align --ownership-patch - --format json`. Keep `base_digest` in the patch body when you want stale ownership rejection. Use `context schema align-ownership-patch` for the exact shape.
-
-If `align-segments.incremental.mode` is `incremental`, the finalize step is a delta merge: submit only the Nodes and block ownership supported by the current scanned sources, and reference previous finalized Nodes when they are parents, dependencies, domain children, owners, or visibility targets. Absence of an old Node or edge is not a delete signal. Do not redeclare an old parent/domain just to attach a new child. `sections[].owner` must be a Node declared in the current payload; previous finalized Nodes can be referenced structurally but do not receive new section plans from this incremental payload. Existing or previously removed Node slugs cannot change `node_type`; `context align --scan --full` does not bypass that guard. Use a new slug for a different type, or retire the old slug through `context drop` or explicit structure correction before re-aligning.
-
-For code-projection Nodes, distinguish "reuse the existing knowledge file" from "previous finalized prose ownership". A freshly projected code Node may exist in `knowledge/` but not yet appear in finalized ownership. To attach current prose evidence to it, declare that same slug in the current finalize payload and plan only prose-owned Sections for the current evidence; the compile step will merge the prose source and Sections into the existing code Node while preserving code metadata and code-owned Sections.
-
-`nodes[].planned_sections` is the distinct set of Section kinds planned for that Node. List each kind at most once; do not copy `sections[].section_kind` one-for-one when a Node has multiple Sections of the same kind.
-
-For large finalize decisions, use `block_ownership_defaults[]` instead of enumerating every block. Each default names a `source_id` plus the same ownership fields as a block-level entry except `block_id`; the CLI expands it across that source's coverable blocks. Put only exceptions in `block_ownership[]`, which override defaults for their `block_id`. Keep the payload on stdin; do not generate temp JSON files just to list hundreds of ownership rows.
-
-If a source is only navigation or placeholder context, keep the Node only when the graph/slug is still useful: set `planned_sections: []`, mark the navigation evidence `context_only` or `ignored` as appropriate, and do not promote relation lines to `owned` just to satisfy citations. Compile close will materialize an empty placeholder Node with no active Sections.
-
-Do not submit legacy candidate tables, old patch payloads, or full-tree proposal files. Do not write `knowledge/`; align finalize writes finalized workflow artifacts and source ownership only.
-
-## Constraints
-
-- Node types are `domain`, `entity`, and `action`.
-- Entity tag `term` is mutually exclusive with concrete A/B tags. If both identities matter, create one concrete Entity and one separate term Entity, then connect them later with Section-local `refers_to_nodes[]`.
-- Document structure uses `nodes[].contains_parent` and `edges[].edge_type = "depends_on"` only.
-- Section-local references stay in `refers_to_nodes[]`; do not project them into Node edges.
-- Semantic boundary failures should become downgrade warnings or unresolved items. Do not retry the same semantic judgment in a loop.
-- Hard reference failures must be repaired at the exact op/path with a valid id/ref from the current payload. Use CLI `agent_hints[]` as the repair contract when present.
-- Do not read or modify source snapshots, caches, or rendered workflow artifacts with generic tools. Use `context workflow show`, schema commands, payload name, scope id, digest, and candidate ids as the workflow contract.
-- Do not pipe `context ... --format json` through `jq`, `head`, `tail`, `sed`, `cat`, `2>&1`, Python, Node.js, or shell scripts. Do not read host persisted output files such as Claude `tool-results/**`. Consume complete CLI stdout directly. Use semantic views plus `--source` / `--heading` / `--window` / `--token-budget` and returned `how_to_explore[]` when the payload is too large.
-
-## Final Report
-
-Report in the user's language. Include final Node counts by type, unresolved ownership count, workflow payload identifiers, and the next step (`/context:compile` or another `/context:align` pass for unresolved structure).
+Run the CLI-guided align workflow. `/context:align` is the user entrypoint; the CLI owns route, stage, validation, workflow payload storage, and the canonical next write. The agent owns semantic Node/Section grouping and any user-facing questions.
+
+If `$ARGUMENTS` starts with `code`, run `context align code [slug]`, report the dry-run projection plan, and stop. This route is CLI-owned and does not enter the prose align workflow.
+
+### Step 1 — Scan
+
+Run `context align scan --format json`.
+
+Use the returned `workflow.next-action-envelope.v2` as the source of truth:
+
+- Follow top-level `next_action.kind` and `next_action.command` for every write.
+- Use `views[].command` for evidence reads, prioritizing entries with `expected: true`.
+- Treat `allowed_actions[]` as permission for read-only insertions such as `show_view`; do not choose a different write path from it.
+- Treat `agent_hints[]`, when present, as a temporary mirror or diagnostic only. If it conflicts with `next_action`, follow `next_action`.
+
+For protocol discovery, prefer narrow commands:
+
+- `context schema workflow.next-action-envelope.v2 --view minimal --format json`
+- `context protocol show align-compile --format json`
+- `context schema align-structure-decision --view minimal --format json`
+
+### Step 2 — Read Evidence Through Views
+
+Run the expected view commands from the envelope. For additional reads, use only budget-safe workflow views such as:
+
+- `context workflow show --payload align-segments --view blocks --page-size 10 --token-budget 8000 --unwrap --format json`
+- `context workflow show --payload align-segments --view windows --page-size 10 --compact-hints --unwrap --format json`
+- `context workflow show --payload align-segments --view source-mapping --unwrap --format json`
+
+When a view returns `page.next_command`, follow that command to continue the same semantic view. Use `--source`, `--heading`, `--window`, or `--token-budget` only as view filters; do not inspect workflow files, cache files, host tool-results, or stdout fragments with generic tools.
+
+### Step 3 — Produce The Semantic Payload
+
+Reuse existing knowledge before inventing new Nodes: use `context mdrive glossary match <name>` and `context mdrive node list --format json` for term/entity reuse.
+
+Apply packaged `context:skill-align-workflow` Node classification gates and structure-decision procedure. Keep generated payloads on stdin. Do not create scratch files under the workspace or `/tmp`.
+
+Use CLI diagnostics instead of static prompt rules:
+
+- `diagnostics.automatic_ownership_adjustments[]` explains mechanical external-reference demotions and the explicit ownership override shape.
+- Validation diagnostics identify contiguity, citation eligibility, ownership, and mount-matrix problems.
+- `views[]` and `diagnostics` distinguish citable evidence from supporting context; do not infer citation eligibility from raw ownership prose.
+
+### Step 4 — Validate And Submit
+
+When the envelope asks for `validate_align_decision`, submit the structure-decision payload to `context align validate --input - --format json` or the exact returned command. If validate returns blocking diagnostics, repair the payload and rerun validate. If validate returns a `submit_structure_decision` next_action, execute that command with the validated payload.
+
+For any other write kind, execute the top-level `next_action.command` exactly. If the command rejects the payload, follow the returned `next_action` and `reason_code`; do not infer a route fallback from memory.
+
+### Final Report
+
+Report in the user's conversation language. Summarize finalized Node counts and meaningful warnings. Do not surface workflow payload digests, scope ids, block hashes, snapshot digests, or absolute paths.

package/plugin/commands/capture.md

@@ -1,6 +1,6 @@
 ---
 description: "Capture URLs, local Markdown, source code, stdin path lists, inbox/refresh sources, or conversation notes as Context sources."
-argument-hint: "[url | ./path.md [./more.md...] | --code [path] | --stdin | --inbox | --refresh | note]"
+argument-hint: "[url | ./path.md [./more.md...] | --code [paths...] | --stdin | --inbox | --refresh | note]"
 allowed-tools: Bash(context:*, bun:*, brew:*, curl:*, sh:*, scoop:*, choco:*, lark-cli:*), WebFetch
 ---
 
@@ -10,7 +10,7 @@ missing-dependency install flow) lives inline here per the slash-command
 length exemption for self-contained slash commands.
 -->
 
-## Your task
+## Your Task
 
 Capture is entirely CLI-driven — your role is to route the right `context capture` invocation and relay its output. Never hand-write captured source snapshots: the CLI owns normalisation (NFC, BOM strip, line endings) and the `content_hash` contract, so any manual edit breaks idempotency.
 
@@ -24,18 +24,14 @@ Invocation note: code capture does not run through `npx`. `context capture --cod
 
 ### Route by argument
 
-- `$ARGUMENTS` starts with `http://` / `https://` → `context capture $ARGUMENTS` (feishu URLs need `lark-cli`).
-- `$ARGUMENTS` is one or more local `.md` paths → local file batch: `context capture <path...>`.
-- User provides a long newline-separated path list → pass it to `context capture --stdin` with a direct heredoc.
+- `$ARGUMENTS` is one or more `http://` / `https://` targets and/or local `.md` paths → `context capture $ARGUMENTS` (Feishu docx/wiki URLs need `lark-cli`; URL and mixed batches are supported). Do not write an Agent-side URL loop.
+- User provides a long newline-separated URL list or local `.md` path list → pass it to `context capture --stdin` with a direct heredoc. Mixed URL + local `.md` batches are supported when the user intentionally provides both.
 - `$ARGUMENTS` contains `--inbox` → `context capture --inbox`.
 - `$ARGUMENTS` contains `--refresh` → `context capture --refresh`. This refreshes active Feishu URL sources and local Markdown sources whose stored origin file still exists; code sources use `context capture --code`.
 - User asks for code capture with explicit `--module` flags → run `context capture --code $ARGUMENTS`, preserving code flags such as `--module`, `--version`, `--version-from`, and `--no-runner-cache`.
 - User asks to refresh/re-capture an already configured code source → run `context capture --code` unless the user explicitly wants to change package selection or version flags. The CLI reuses stored `capture_config`, appends a new snapshot only when code/version content changes, and never overwrites prior snapshots.
-- User provides multiple code target paths → run the code-capture flow once per target path. `context capture --code` accepts only one target path per invocation.
-- User asks for code capture without explicit `--module` flags → first run `context capture --code $ARGUMENTS --plan --format json`.
-  - Present only candidate package name, module path, and version. Do not show file counts or the derived path filter.
-  - If the plan returns exactly one candidate package, run `context capture --code <original-target-if-present> --module <candidate.path> --format json` immediately.
-  - If the plan returns multiple candidate packages, ask the user which package paths to capture. If the host interaction supports multi-select, allow multi-select; otherwise ask the user to reply with one or more package paths/names.
+- User provides one or more code target paths, or asks for code capture without explicit `--module` flags → run `context capture --code $ARGUMENTS --format json` directly. The CLI preflights every target first; if any target is ambiguous it returns candidates without writing, otherwise it captures all selected code targets serially.
+  - If the CLI returns candidate packages, ask the user which package paths to capture.
   - Then run `context capture --code <original-target-if-present>` with one repeated `--module <path>` for every selected package. The CLI derives and stores path filtering silently from that selection.
 - User asks to record conversation material, a decision, a revision intent, or a temporary observation → use note capture:
   - Classify once as `revision`, `decision`, or `brainstorm`; temporary observations are `brainstorm`. If unclear, ask one clarification.
@@ -49,6 +45,7 @@ For stdin batches, use this shape:
 
 ```bash
 context capture --stdin <<'EOF'
+https://example.feishu.cn/wiki/abc
 docs/a.md
 docs/b.md
 EOF
@@ -56,20 +53,35 @@ EOF
 
 Do not pipe the heredoc through another command, and do not discover files with `find` / `ls` when the user already supplied the paths.
 
-### Output handling
+### Output Handling
 
 Report the CLI output verbatim. If the CLI reports `N sources changed`, suggest the right next step:
 
 - Run `context status --format json` and use its `next_step.command` / `workflow.next_step`.
 - If status says aligned knowledge is missing or alignment is required → suggest `/context:align`.
 - If status says compile work is pending for Markdown / evidence-backed knowledge → suggest `/context:compile`. Mention `/context:align` only if the user wants to revise the structure.
-- If the capture was code-only and status reports pending code projection, suggest the CLI-owned code route: `/context:compile --code <source-slug>` or `context compile --code <source-slug>`, followed by `context compile --close` when the CLI asks for close.
+- If the capture was code-only and status reports pending code projection, suggest the CLI-owned code route: `/context:compile code <source-slug>` or `context compile code <source-slug>`, followed by `context compile close` when the CLI asks for close.
 
-Never suggest prose compile or hand-built code knowledge for a code-only source. Code snapshots become active knowledge only through `context compile --code`, which materializes package/category/symbol Nodes deterministically.
+Never suggest prose compile or hand-built code knowledge for a code-only source. Code snapshots become active knowledge only through `context compile code`, which materializes package/category/symbol Nodes deterministically.
 
 If capture is rejected with `agent_hints[].code = "workflow-cross-family-rejected"`, do **not** run `context workflow abandon ...` automatically. First run or ask the user to run `context workflow status --format json` and explain that another workflow is active in this workspace. Continue that workflow when it is the intended task; ask the user before abandoning it when the user wants to discard that in-progress work. If the user expected a different repository/workspace, change to the confirmed workspace root before retrying capture.
 
-### Missing dependency recovery
+## Final Report
+
+Report in the user's conversation language. Translate section headings into the user's language instead of copying the English labels below verbatim. Optimize for human readability: use document titles instead of source ids, package names instead of `aspect:code:*` strings, and human-readable kind labels ("local markdown", "Feishu doc", "code package") instead of internal tokens. Do not surface content hashes, snapshot digests, workflow payload ids, or absolute file paths.
+
+Stable structure:
+
+1. Completion headline. Single line with the action verb plus core counts: how many sources were captured this round, broken down by `new` / `updated` / `unchanged`. Capture data from `context capture ... --format json` `result.summary` (or per-source statuses when no aggregate is returned).
+2. Per-source list grouped by status. Show each captured source under one of three groups (`new` / `updated` / `unchanged`); within each group list the document title (`source.title`), kind label, and a short delta indicator for updated sources (for example added/removed line counts when the CLI returns them; otherwise "content changed"). Cache-hit code packages belong in `unchanged`. Omit groups that are empty.
+3. Pending workflow signals. When `context status --view summary --format json` reports follow-up work tied to this capture (sources pending align, sources pending compile, refreshed sources pending recompile, code sources pending projection), summarize each as a single line naming the work and which sources are affected. Omit the section entirely when there is no pending follow-up.
+4. Next step. Single command suggestion driven by status: `/context:align` when structure work is pending, `/context:compile` when prose compile work is pending, `context compile code <slug>` (or `/context:compile code <slug>`) when code projection is pending. If nothing is pending, say so explicitly.
+
+Do not include raw CLI diagnostics, agent_hints content, schema names, or workflow payload identifiers in the report. Those belong in earlier troubleshooting output, not in the completion summary.
+
+## Reference
+
+### Missing Dependency Recovery
 
 If the CLI returns `agent_hints[]` with `code: "capture-code-typescript-plugin-missing"`, stop and surface the hint. Ask the user once for permission to run `agent_hints[0].command` (the CLI has already picked the correct package manager — `npm install -g` or `bun install -g` — based on how `context` itself was installed). If approved, run that exact command via `Bash` and then retry the original capture; if declined, leave the command visible for manual install. Never substitute a different package manager or version.
 
@@ -81,7 +93,7 @@ If the CLI prints a missing-dependency error like `lark-cli not installed`, walk
 4. Stop on any failure; surface stderr verbatim.
 5. After success, tell the user to re-run their original `/context:*` command themselves.
 
-### Language policy
+### Language Policy
 
 Your prose to the user follows the user's conversation language. CLI commands, flag names, URLs, env-var names, binary names, source-ids stay English.
 
@@ -93,5 +105,5 @@ Your prose to the user follows the user's conversation language. CLI commands, f
 - In `--format json`, code capture runner cache state is authoritative in `result.runner.cacheMode`: `prepared` means a workspace runner was prepared, `cached` means workspace cache hit, and `bypass` means `--no-runner-cache` used a temporary runner directory instead of the workspace runner cache.
 - Aspect snapshots default to `evidence.mode: none`. Prose-like custom aspects must opt in with `evidence: { mode: block }` in `aspects/<name>/aspect.yaml` before they generate evidence manifests. Invalid `evidence.mode` values are reported as `evidence-policy-invalid`; they are not silently treated as `none`.
 - Code aspect snapshots ship with `evidence.mode: none`; symbols/files/edges are indexed inside the code bucket. Do not ask users to inspect or repair a code `.evidence` manifest.
-- Code aspect capture writes raw code snapshots first. Materialize them with `context compile --code <slug>` (or no slug for all actionable code sources) before prose align needs to attach documentation to code Nodes.
+- Code aspect capture writes raw code snapshots first. Materialize them with `context compile code <slug>` (or no slug for all actionable code sources) before prose align needs to attach documentation to code Nodes.
 - On duplicate capture of the same URL: identical `content_hash` → CLI skips with `unchanged`; different hash → CLI appends a new snapshot.