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

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@c4a/context-cli",
3
- "version": "0.5.35-beta.3",
3
+ "version": "0.5.36-beta.1",
4
4
  "type": "module",
5
5
  "bin": {
6
6
  "context": "./cli.js"
package/plugin/README.md CHANGED
@@ -52,7 +52,7 @@ Then install the plugin matching the agent you use:
52
52
 
53
53
  | Agent | Install |
54
54
  |---|---|
55
- | Claude Code | `/plugin marketplace add context4ai/context`, then `/plugin install context@context` |
55
+ | Claude Code | `/plugin marketplace add context4ai/context`, then `/plugin install context@c4a` |
56
56
  | Cursor | Dashboard → Settings → Plugins → Import → `https://github.com/context4ai/context` |
57
57
  | Codex CLI | `codex marketplace add context4ai/context` |
58
58
  | Vercel-style skills (Windsurf / OpenCode / Cline / Copilot, etc.) | `npx skills add github:context4ai/context <skill-name>` |
@@ -52,7 +52,7 @@ bun add -g @c4a/context-cli
52
52
 
53
53
  | Agent | 安装方式 |
54
54
  |---|---|
55
- | Claude Code | `/plugin marketplace add context4ai/context`,再执行 `/plugin install context@context` |
55
+ | Claude Code | `/plugin marketplace add context4ai/context`,再执行 `/plugin install context@c4a` |
56
56
  | Cursor | Dashboard → Settings → Plugins → Import → `https://github.com/context4ai/context` |
57
57
  | Codex CLI | `codex marketplace add context4ai/context` |
58
58
  | Vercel-style skills(Windsurf / OpenCode / Cline / Copilot 等) | `npx skills add github:context4ai/context <skill-name>` |
@@ -6,124 +6,55 @@ allowed-tools: Bash(context:*)
6
6
 
7
7
  ## Your Task
8
8
 
9
- Run the beta.8 align workflow. `/context:align` is the user entrypoint; internal stages are workflow payloads, not public slash commands.
9
+ 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.
10
10
 
11
- 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`.
12
-
13
- 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.
11
+ 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.
14
12
 
15
13
  ### Step 1 — Scan
16
14
 
17
- 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.
18
- - Read `align_route.next_command` before choosing any write path. Direct routes finalize immediately; batched routes are the only routes that use coarse-read and candidate ops.
19
- - If the align-segments payload includes `generation_policy`, use it as the language contract for generated Node titles, Node 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. Section summaries may later follow either the workspace language or the source-bound content language. Preserve product names, code identifiers, slugs, flags, `block_id` handles, and citation tokens exactly when needed.
20
- - 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.
21
- ### Step 2 — Read Schemas And Views
22
-
23
- Read schema and payloads through CLI only:
24
- - `context schema align-segments`
25
- - `context schema align-structure-decision`
26
- - If `align_route.next_command` points to `context align --coarse-read -`, also read `context schema align-coarse-read`, `context schema align-candidate-ops`, `context schema align-candidate-ledger`, and `context schema align-candidate-aggregate`.
27
- - `context workflow show --payload align-segments --view segment --unwrap --format json`
28
- - `context workflow show --payload align-segments --view source-mapping --unwrap --format json`
29
- - `context workflow show --payload align-segments --view blocks --token-budget 8000 --unwrap --format json`
30
- - `context workflow show --payload align-segments --view windows --page-size 10 --compact-hints --unwrap --format json`
31
- - Default `source-mapping` is a compact per-source index; add `--source <source-id>` only when you need that source's block id map. `blocks` is the text-bearing view: budgeted rows include full block `text` plus `text_preview`, so do not call another full-text path just to read selected align blocks.
32
- - Drill into content only with semantic filters such as `--source <source-id>`, `--heading <prefix>`, `--window <window-id|src-N:M[,selector...]>`, or a larger `--token-budget <n>`. `src-N:M` means the M-th window under the `source_alias` shown by `--view windows`; comma-separated selectors fetch several windows in one call. When a paged blocks view returns `page.next_token` or `next_command`, follow `next_command` to continue the same view. Use `window_read_plan`, `windows[].read_strategy`, `windows[].content_size`, `windows[].selector`, and `windows[].batch_selector` to skip low-signal windows, use inline tiny windows, batch neighboring small windows, or drill only selected large windows. The preferred agent reading band is roughly 15K-30K chars / 4K-8K tokens; 50K chars / 12K tokens is an acceptable upper band for a single focused read. Rerun the windows view without `--compact-hints` only when exact per-row commands are needed.
33
- - `--unwrap` only removes the workflow metadata envelope. It does not turn a summary view into detail output.
34
- ### Step 3 — Reuse Existing Knowledge
35
-
36
- 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.
37
- - Apply packaged `context:skill-align-workflow` Node classification gates before finalize; in batched routes, also apply them before candidate ops. 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.
38
- - 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.
39
- ### Step 4 — Follow The Route
40
-
41
- 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.
42
- - If `align_route.next_command` points to `context align --finalize -`, skip coarse-read, candidate ops, ledger, and aggregate. Build the `align-structure-decision` and submit the returned finalize command.
43
- - If `align_route.next_command` points to `context align --coarse-read -`, 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`.
44
- - Only after batched coarse-read is stored, 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`.
45
- - `--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.
46
- - For batched routes, 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.
47
- - 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.
48
- ### Step 5 — Follow Hints
49
-
50
- 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.
51
-
52
- ### Step 6 — Finalize
53
-
54
- Finalize only with `align-structure-decision`:
55
-
56
- ```bash
57
- context align --finalize -
58
- ```
59
-
60
- 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/...`:
15
+ Run `context align scan --format json`.
61
16
 
62
- ```json
63
- {
64
- "schema_version": "align.finalize-patch.v1",
65
- "operations": [
66
- { "op": "replace", "path": "/block_ownership/3/primary_owner", "value": "rspack" }
67
- ]
68
- }
69
- ```
17
+ Use the returned `workflow.next-action-envelope.v2` as the source of truth:
70
18
 
71
- Submit the patch with `context align patch draft --input - --format json`. Add `--payload-digest` only when you intentionally want an explicit stale guard.
19
+ - Follow top-level `next_action.kind` and `next_action.command` for every write.
20
+ - Use `views[].command` for evidence reads, prioritizing entries with `expected: true`.
21
+ - Treat `allowed_actions[]` as permission for read-only insertions such as `show_view`; do not choose a different write path from it.
22
+ - Treat `agent_hints[]`, when present, as a temporary mirror or diagnostic only. If it conflicts with `next_action`, follow `next_action`.
72
23
 
73
- 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`:
24
+ For protocol discovery, prefer narrow commands:
74
25
 
75
- ```json
76
- {
77
- "schema_version": "align.ownership-patch.v1",
78
- "base_digest": "sha256:<finalized-ownership-digest>",
79
- "block_ownership": [
80
- {
81
- "block_id": "<block-id>",
82
- "ownership_role": "owned",
83
- "owners": ["<node-slug>"],
84
- "visible_to": ["<node-slug>"],
85
- "reason": "Why this block is citation evidence for the node."
86
- }
87
- ]
88
- }
89
- ```
26
+ - `context schema workflow.next-action-envelope.v2 --view minimal --format json`
27
+ - `context protocol show align-compile --format json`
28
+ - `context schema align-structure-decision --view minimal --format json`
90
29
 
91
- Submit it with `context align patch ownership --input - --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.
30
+ ### Step 2 Read Evidence Through Views
92
31
 
93
- 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.
32
+ Run the expected view commands from the envelope. For additional reads, use only budget-safe workflow views such as:
94
33
 
95
- 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.
34
+ - `context workflow show --payload align-segments --view blocks --page-size 10 --token-budget 8000 --unwrap --format json`
35
+ - `context workflow show --payload align-segments --view windows --page-size 10 --compact-hints --unwrap --format json`
36
+ - `context workflow show --payload align-segments --view source-mapping --unwrap --format json`
96
37
 
97
- `nodes[].planned_sections` is the distinct set of Section kinds used as compile scaffolding for that Node, not a hard completion gate. 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.
38
+ 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.
98
39
 
99
- Each `sections[].block_ids` entry must be one contiguous run of citation-eligible blocks from one source. If one conceptual Section spans gaps, split it into multiple `sections[]` plans or include the intervening citation-eligible blocks. The CLI rejects non-contiguous plans at finalize so compile does not have to rediscover the split later.
40
+ ### Step 3 Produce The Semantic Payload
100
41
 
101
- 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.
42
+ Reuse existing knowledge before inventing new Nodes: use `context mdrive glossary match <name>` and `context mdrive node list --format json` for term/entity reuse.
102
43
 
103
- 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.
44
+ 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`.
104
45
 
105
- 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.
46
+ Use CLI diagnostics instead of static prompt rules:
106
47
 
107
- ## Constraints
48
+ - `diagnostics.automatic_ownership_adjustments[]` explains mechanical external-reference demotions and the explicit ownership override shape.
49
+ - Validation diagnostics identify contiguity, citation eligibility, ownership, and mount-matrix problems.
50
+ - `views[]` and `diagnostics` distinguish citable evidence from supporting context; do not infer citation eligibility from raw ownership prose.
108
51
 
109
- - Node types are `domain`, `entity`, and `action`.
110
- - 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[]`.
111
- - Document structure uses `nodes[].contains_parent` and `edges[].edge_type = "depends_on"` only.
112
- - Section-local references stay in `refers_to_nodes[]`; do not project them into Node edges.
113
- - Semantic boundary failures should become downgrade warnings or unresolved items. Do not retry the same semantic judgment in a loop.
114
- - 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.
115
- - 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.
116
- - 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`, returned `next_command`, and returned `how_to_explore[]` when the payload is too large.
117
-
118
- ## Final Report
52
+ ### Step 4 Validate And Submit
119
53
 
120
- 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 Node titles instead of slugs in prose, human-readable Node types (`domain` / `entity` / `action`) instead of internal flags, and Section kind names instead of mount-matrix identifiers. Do not surface workflow payload digests, scope ids, block hashes, snapshot digests, or absolute file paths.
54
+ 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.
121
55
 
122
- Stable structure:
56
+ 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.
123
57
 
124
- 1. Completion headline. Single line with total Node count and the breakdown by Node type (for example "12 Nodes: 2 domain · 8 entity · 2 action"). Capture data from the finalize result's `summary`.
125
- 2. Node structure tree. Render the finalized Node graph as a tree grouped by domain when domains exist (`domain` Node → its `entity` / `action` children; standalone Nodes appear at root). Show the Node title and Node type for each entry, and mark `[new]` / `[modified]` / `[reused]` per Node based on the finalize delta against the previous finalized ownership. Use the same tree for incremental delta finalize; do not omit reused Nodes referenced as parents or dependencies of changed Nodes.
126
- 3. Variance summary. Bullet list of counts: new Nodes, modified Nodes, reused Nodes, removed Nodes (when any), planned Sections (total across `nodes[].planned_sections`), unresolved ownership items, and any structure-decision warnings. Show every counter so the user can verify nothing unexpected fired, including zeros for new/modified/removed.
127
- 4. Next step. Single command suggestion: `/context:compile` when there is compile work to do; another `/context:align` pass only when unresolved structure remains.
58
+ ### Final Report
128
59
 
129
- Do not include raw `align-segments` digests, scope ids, or workflow payload identifiers in the report. Those belong in earlier troubleshooting output, not in the completion summary.
60
+ 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.
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  description: "Capture URLs, local Markdown, source code, stdin path lists, inbox/refresh sources, or conversation notes as Context sources."
3
- argument-hint: "[url | ./path.md [./more.md...] | --code [path] | --stdin | --inbox | --refresh | note]"
3
+ argument-hint: "[url | ./path.md [./more.md...] | --code [paths...] | --stdin | --inbox | --refresh | note]"
4
4
  allowed-tools: Bash(context:*, bun:*, brew:*, curl:*, sh:*, scoop:*, choco:*, lark-cli:*), WebFetch
5
5
  ---
6
6
 
@@ -24,18 +24,14 @@ Invocation note: code capture does not run through `npx`. `context capture --cod
24
24
 
25
25
  ### Route by argument
26
26
 
27
- - `$ARGUMENTS` starts with `http://` / `https://` → `context capture $ARGUMENTS` (feishu URLs need `lark-cli`).
28
- - `$ARGUMENTS` is one or more local `.md` pathslocal file batch: `context capture <path...>`.
29
- - User provides a long newline-separated path list → pass it to `context capture --stdin` with a direct heredoc.
27
+ - `$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.
28
+ - 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.
30
29
  - `$ARGUMENTS` contains `--inbox` → `context capture --inbox`.
31
30
  - `$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`.
32
31
  - 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`.
33
32
  - 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.
34
- - 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.
35
- - User asks for code capture without explicit `--module` flags first run `context capture --code $ARGUMENTS --plan --format json`.
36
- - Present only candidate package name, module path, and version. Do not show file counts or the derived path filter.
37
- - If the plan returns exactly one candidate package, run `context capture --code <original-target-if-present> --module <candidate.path> --format json` immediately.
38
- - 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.
33
+ - 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.
34
+ - If the CLI returns candidate packages, ask the user which package paths to capture.
39
35
  - 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.
40
36
  - User asks to record conversation material, a decision, a revision intent, or a temporary observation → use note capture:
41
37
  - 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:
49
45
 
50
46
  ```bash
51
47
  context capture --stdin <<'EOF'
48
+ https://example.feishu.cn/wiki/abc
52
49
  docs/a.md
53
50
  docs/b.md
54
51
  EOF
@@ -1,170 +1,89 @@
1
1
  ---
2
- description: "Compile the confirmed align plan into knowledge articles: draft, semantic reconciliation, apply, then close."
2
+ description: "Compile the confirmed align plan into source-linked knowledge through CLI-guided workflow steps."
3
3
  argument-hint: "[--plan|code <slug>]"
4
4
  allowed-tools: Bash(context:*)
5
5
  ---
6
6
 
7
- <!--
8
- This command is slightly over the 30-line default because it carries
9
- the default-mode vs `--plan`-mode comparison inline; the mode contrast
10
- belongs here rather than split across skill references.
11
- The agent protocol itself still delegates to internal packaged procedures.
12
- -->
13
-
14
7
  ## Your Task
15
8
 
16
- Synthesise the finalized align plan into knowledge through semantic CLI operations. If the user explicitly authorized托管/全自动/delegated mode at the start of this conversation, create the compile workflow with `--delegated`; otherwise stay in manual/default mode. The agent produces compile draft JSON per Node; the CLI owns storage, rendering, verification, and workflow payload persistence. Read workflow payloads with `context workflow show`; write through `context compile`, `context reconcile`, and `context mdrive` operations, never through direct workspace file tools.
9
+ Synthesize finalized align structure into knowledge. The CLI owns workflow routing, validation, reconciliation, apply, close, payload storage, and recovery commands. The agent reads evidence and emits semantic payloads only when `next_action` asks for them.
17
10
 
18
11
  Naming convention:
19
12
 
20
13
  - `/context:*` names user slash commands.
21
14
  - `context ...` names CLI primitives.
22
- - Internal packaged procedures invoked by slash workflows are not user slash commands. Do not invent extra slash-command entrypoints for draft or close stages.
15
+ - `context:skill-*` names packaged internal procedures, not user slash commands.
23
16
 
24
17
  ### Modes
25
18
 
26
- - **Default (no flag)** — draft plan + semantic reconciliation + apply writes + close.
27
- - **`--plan`** (opt-in when `$ARGUMENTS` contains `--plan`) — per Node, run `context compile draft <slug> --input -` so the CLI validates stdin draft content without writing active knowledge; surface a user-facing change list (new knowledge, replaced knowledge, unchanged knowledge, and why) while keeping internal Section ids / source refs in details only when needed, then **stop at the end of the per-Node loop — do NOT run close**. The user re-runs `/context:compile` without `--plan` to apply; that run does the real writes + close.
28
- - **`code [slug]`** — run the CLI-owned code projection route directly with `context compile code [slug]`, report its output, then stop. This route does not enter doctor/draft/reconcile and uses the same deterministic implementation as `context align --code`. It materializes code snapshots into package/category/symbol Nodes; run `context compile close` afterward only when the CLI asks for close.
29
-
30
- ### Delegated Workflow Mode
19
+ - **Default** — follow `context compile scan --format json` and the returned `next_action` until compile is closed or no work remains.
20
+ - **`--plan`** validate per-Node draft changes without closing or writing active knowledge; stop after the planned changes are reported.
21
+ - **`code [selector]`** — run `context compile code [selector]`, report the CLI result, and stop unless the CLI asks for a follow-up close. The selector may be omitted to process all actionable code sources; when present, the CLI resolves source slug, package name, or module path.
22
+ - **Delegated** — add `--delegated` only when the user explicitly authorized delegated/automatic mode at the start of this conversation. Do not infer it from vague "continue" permission.
31
23
 
32
- - If the user explicitly authorized托管/全自动/delegated mode at the start of this conversation, add `--delegated` to the first compile workflow-creating command, preferably `context compile scan --delegated --format json`. Do not add it for vague "continue" / "继续" permission.
33
- - `--delegated` is a workflow-level authorization, not a per-review override. It only lets the CLI auto-accept low-risk defaults: weak lexical support with empty `source_support.missing_hard_terms`, or supported `keep_separate` decisions whose candidates have no duplicate/conflict/archive/reanchor risk and no pinned target Section. Missing hard facts, type drift, schema errors, ownership/structure challenges, user-confirmation gates, and destructive gates still block.
34
- - Never hand-author `decided_by: delegated_agent`; the CLI injects it only inside a delegated compile workflow.
24
+ ### Core Rules
35
25
 
36
- ### Shared Policies
26
+ - Follow top-level `next_action.kind` and `next_action.command` for every write.
27
+ - Use `views[].command` for evidence reads, prioritizing `expected: true`.
28
+ - Treat `allowed_actions[]` as permission for read-only insertions; it is not a menu of alternate write paths.
29
+ - Treat `agent_hints[]`, when present, as a temporary mirror or diagnostic. If it conflicts with `next_action`, follow `next_action`.
30
+ - Do not use direct file tools, shell scripts, `jq`, `sed`, `cat`, `head`, `tail`, Python, or Node.js to inspect workspace storage, workflow payload files, or `--format json` stdout.
37
31
 
38
- Language policy: your explanatory prose and final reports follow the user's conversation language. Node titles, Node summaries, and user-facing draft explanations follow `NodeContext.generation_policy.language` when the CLI provides it. Source-bound compile draft `content` should stay close to the cited source language when it differs from the workspace language; do not translate cited English facts into Chinese just to match the workspace. Section `summary` is a compact reader/query aid derived from `content` and may follow either the workspace language or the source-bound `content` language; do not patch it merely to switch languages. source_support hard-term matching checks `content`, not `summary`. For `example` Sections that cite a code/config/command fence, keep `content` centered on the cited fenced block and put framing prose in `summary`; split prose into a separate action only when it cites its own evidence. Preserve product names, code identifiers, CLI flags, slugs, `block_id` / `source_ref` tokens, and exact quoted evidence as printed. CLI stdout/stderr, the canonical `processing <slug>` lines, paths, slugs, block ids, source refs, issue codes, flags, and command names stay as printed.
32
+ Protocol discovery:
39
33
 
40
- Stable prompt/output policy: keep fixed protocol, schema, mount matrix, and workspace lookup context before per-Node payloads. For repeated Nodes, use the same command order and consume CLI JSON as-is. Do not add current timestamps, random ids, storage paths, or host absolute paths to draft payloads or reports unless the CLI explicitly returned them as semantic workspace facts.
34
+ - `context schema workflow.next-action-envelope.v2 --view minimal --format json`
35
+ - `context protocol show align-compile --format json`
36
+ - command-specific `context schema <name> --view minimal --format json`
41
37
 
42
38
  ## Preflight
43
39
 
44
- 1. Run `context doctor`; output-align group must be green. If it reports missing aligned knowledge, tell the user to run `/context:align` and stop. Incremental cache group warnings are informational here; only output-align errors block compile.
45
- 2. Run `context mdrive workspace stats --format json`, `context source list --format json`, and `context status --format json`; record the before counts and `STATUS.semantic.refreshed_source_pending_compile.source_ids[]`. This status means newer raw snapshots exist; it does not mean finalized ownership or `node.sources[]` are already refreshed.
46
- 3. Run `context compile scan --format json` and parse the JSON as `COMPILE_WORKSET`. If delegated workflow mode is explicitly authorized, run `context compile scan --delegated --format json` for this first scan instead. `context compile scan` is the only workset scan entrypoint; `/context:compile --plan` controls whether the workflow stops before writing.
47
- - If `COMPILE_WORKSET.compile_route` is present, treat it as the current advisory route. It does not replace evidence inspection: for every Node that needs a draft, read that Node's source-refs view before writing content, then use `context compile cycle` as the default write path. Enter manual review only when cycle returns it.
48
- - If `context workflow status --format json` has `current: null` but `last_published` is present, continue with `context compile scan`; the published finalized ownership is still the workspace structure truth. Use `context workflow list --format json` only when you need lineage/history diagnostics.
49
- - Compile JSON may include `source_finalize`; use it as lineage for the finalized ownership that produced the current Node set and citation ownership.
50
- - If `COMPILE_WORKSET.reason` is `no-changed-nodes` and there are no refreshed sources pending compile, report `no changed nodes`; stop before invoking the draft procedure, running any draft command, or running close.
51
- - If `COMPILE_WORKSET.status` is `unknown-input`, continue conservatively using the Nodes listed in `COMPILE_WORKSET.nodes`; keep the `unknown_inputs[]` reasons in the final report.
52
- - Otherwise process only `COMPILE_WORKSET.nodes`, preserving the CLI order. Per-Node `processing <slug>` echoes must match this order.
53
-
54
- Review input rule: normal compile flow reads the current prepare payload automatically: pass decisions with `context reconcile review --decisions - --view status`. Add `--prepare-digest` only when you intentionally want an explicit stale guard. Never pass prepare files or hand-edited review output to apply; once review writes a ready artifact for the current workflow scope, plain `context reconcile apply` consumes it.
55
-
56
- Semantic decision schema discovery: run `context schema semantic-decisions` for JSON, or `context schema semantic-decisions --format yaml` for readable YAML. Do not infer it from memory, and do not hand-edit review output; once `context reconcile review` writes a ready review artifact for the current workflow scope, plain `context reconcile apply` consumes it without re-reading any decisions file.
57
-
58
- `source_ref` values are opaque citation tokens. Copy them from CLI payloads into draft/reconcile decisions exactly as printed; do not parse, normalize, or dereference them as file paths.
59
-
60
- Do not use Python, Node.js, shell, or other ad-hoc scripts to preprocess, filter, summarize, or inspect ReconcileContext / review payloads. Do not use `ls`, `find`, `rg`, `cat`, or similar ad-hoc commands to inspect workspace storage or temporary workflow artifacts. Consume the structured output from `context reconcile prepare` and `context reconcile review` directly, and pass agent-authored draft/decision payloads through stdin rather than scratch files. Never extract `review.apply_document` manually; the CLI applies the ready review artifact stored under the current workflow scope.
61
-
62
- ## Refreshed Source Loop
63
-
64
- Skip this section unless `STATUS.semantic.refreshed_source_pending_compile.source_ids[]` is non-empty or `context compile scan` returns a refresh-related next action. This is a real recovery path, not the default compile path.
65
-
66
- For each refreshed source id, run `context reconcile prepare --mode refresh --source <source-id> --format json`, pass the payload to packaged `context:skill-semantic-reconcile`, review with `context reconcile review --decisions - --view status`, then apply with plain `context reconcile apply` when ready. If the prepare output says the source is unchanged, report no refresh decisions and continue. After applying refreshed sources in default mode, rerun `context compile scan --format json --ignore-source <source-id>` for each refresh-applied source and use that filtered workset for the per-Node loop.
67
-
68
- ## Per-Node Loop
69
-
70
- Process Nodes sequentially. `/context:compile` may cover a multi-Node workset, but each Node must finish its own `context draft prepare review → apply` loop before you apply another Node. Do not run multiple Node draft/reconcile/apply chains in parallel or bury several Node failures inside one shell batch. Capture/align can be broad; compile write decisions must be per-Node and complete.
71
-
72
- 1. Prepare evidence for every workset Node.
73
- - **1a. Get NodeContext.** Run `context compile context <slug> --format json`. If the refreshed-source loop applied any source, append the same `--ignore-source <source-id>` flags used for the filtered workset. The JSON stdout is a compact summary with workflow payload handles; do not extract digests by hand. Only expand the durable NodeContext when you are ready to pass its returned `.value` object to the draft skill.
74
- - **1b. Inspect citation refs.** First inspect citation handles with `context compile context <slug> --view source-refs --token-budget 2000 --format json` or `context workflow show --payload node-context --view source-refs --token-budget 2000 --unwrap --format json`; this source-refs view is only a projection of `NodeContext.raw_snippets[]`, not a separate data source. Planned Section rows may include `quote_full_text` for example code fences and long paragraph/table evidence already counted in the view budget; use it directly instead of doing a second full-text request for the same row. If the view returns `page.next_token` or `next_command`, follow `next_command` to continue the same source-refs view. If it returns `truncated: true`, follow `how_to_explore[]` to narrow by `--source` / `--heading` or expand the budget.
75
- - **1c. Request full text only when needed.** `context compile context <slug> --request-full-text <block_id> --view text --format json` exposes visible evidence text through the narrow text view; read expanded page text from `items[].text`. Long blocks are returned as line-bounded pages with `items[].next_command`; follow that command to continue reading the same block. `request_full_text.pages[].text` and `raw_snippets[].quote` may appear in full NodeContext outputs as mirrors, but the agent-facing expansion path is `--view text`. Do not use file tools to bypass the page.
76
- - **1d. Respect evidence boundaries.** NodeContext is derived only from finalized ownership: `primary_evidence` and citation-eligible `shared_evidence` may be cited; `context_only` and every secondary shared snippet are background only and must not be cited. Full-text inspection does not promote secondary shared evidence into citation eligibility; if the block should support this Node, emit `pending_ownership_challenge` or `structure_challenge` instead of writing a Section. If NodeContext includes `generation_policy`, apply it to generated titles, summaries, and user-facing explanations; for source-bound draft `content`, prefer the cited source language when it differs. Do not default Node titles/summaries to English scaffolding such as "How-To", "Strategy", or "Architecture" when the workspace language is not English.
77
- - **1e. Use workflow views instead of files.** When the workset requires full context, the NodeContext payload has `incremental.status: "full-context"` with the `unknown_inputs[]` reasons from the same entrypoint. `incremental.locator_only_changes[]` entries with `agent_action: "none"` are close-time maintenance only; do not draft them. The CLI stores the durable NodeContext and coverage candidates as workflow payloads, not root scratch files. Do not expand the context with direct file tools; the NodeContext payload is the evidence boundary. Prefer citation-eligible refs for citeable evidence and treat `context_only` as background. Do not repeatedly slice saved NodeContext JSON manually; use source-refs, coverage-summary, coverage detail filters, and returned `how_to_explore[]`.
78
- 2. Invoke packaged `context:skill-compile-draft` and follow its procedure to emit draft JSON. Do not reconstruct the draft shape or Section classification rules from memory; the draft skill carries the canonical kind priority, mount matrix, examples, and reflection gates. Section writes use `content` plus optional `summary`; new Sections do not need `section_id`, and the op is exactly `op: "add"` because compile-draft `actions[]` already targets Sections. Do not use align-style op names such as `add_section` or `propose_section`. Cite raw via `source_refs: [...]` chosen from `raw_snippets[].source_ref`; use a single-element array for one citation, and use multiple refs only when the Section content actually consumes all of them. The CLI may report over-wide citation narrowing; `removed_lead_in_source_refs` are framing/navigation refs to keep unless you verify they add no meaning, while `removed_redundant_source_refs` are cleanup candidates. The CLI rejects retired `body` / `detail` / `raw`, singular `source_ref`, and quoted-evidence fields with canonical repair hints. If a note or changed raw snippet should be reviewed but intentionally not written, emit `op: "skip"` with the relevant `source_refs: [...]`; a bare skip is only for deterministic no-op cases. If a NodeContext contains only navigation or placeholder evidence (`Parent` / `Children` / `Related` / `Relations`, "no detailed content", etc.), emit `skip`; do not create a low-value `description` Section from that navigation line just to satisfy the workflow.
79
- 3. Fast path: pass the draft to `context compile cycle <slug> --input - --accept-safe-defaults --format json`. This validates the draft, prepares reconcile, reviews mechanically safe defaults, and applies only when no semantic judgment remains. If stdout returns `status: "applied"`, continue to the next Node. If it returns `status: "partial-applied"` or `status: "review-required"`, use the returned `prepare` / `review` handles and continue with the manual path below for only the remaining questions/issues; do not rerun the earlier context/source-ref reads. When you need to patch a remaining action after prepare, run `context compile draft-status <slug> --format json`; each action backed by the latest prepare payload includes `reconcile_item_id` and `source_support`, so use that claim id instead of guessing. To patch and continue in one call, pass a compile draft-patch payload to the same node-cycle command; use `op: "replace_action"`, `action_id`, and `action`, not align-style `op/path/value`.
80
- 4. Conditional manual path: enter this only when `cycle` returns `partial-applied`, `review-required`, a draft revision hint, or a coverage/source-support issue that cannot be resolved by a compile draft-patch. Use the returned `prepare` / `review` handles and CLI `agent_hints[]`; do not restart the Node from context reads. If semantic judgment is needed, load `context workflow show --payload prepare --unwrap --format json`, feed it to packaged `context:skill-compile-judge`, then pass the judge decisions to `context reconcile review --decisions - --view status`. Apply with plain `context reconcile apply` only when review says `ready_to_apply: true`. If questions are returned, ask the user in business language; never mark `decided_by: user` on your own.
81
- 5. Coverage repair: if compile or close reports uncovered required evidence, first inspect `context workflow show --payload coverage-candidates --view coverage-summary --token-budget 2000 --unwrap --format json`, then narrow with `--view coverage` filters. Use `context compile context <slug> --cover-uncovered-only --format json` for targeted repair drafts. Use coverage skip/disposition only when the candidate is intentionally excluded and the CLI exposes that action.
82
- 6. Persistent failure → stop and surface the full rejection list; never edit rendered files to bypass.
83
-
84
- ## Close
85
-
86
- Default mode only — skip entirely in `--plan` mode.
87
-
88
- 1. Invoke packaged `context:skill-compile-close`; it triggers `context compile close`, which refreshes locator-only evidence, canonicalizes source refs, compacts derived knowledge files, verifies the final workspace, rebuilds section fingerprints, and refreshes the incremental cache.
89
- 2. Run `context verify` as a second pass if the skill escalated any issue. Run `context mdrive workspace stats --format json` and `context source list --format json` and diff against the before counts.
90
- 3. Run `context mdrive node list --format json` to collect semantic node handles for the final report. Use `node_class` to keep concrete entities, term definitions, domains, and actions visibly separated. If the user explicitly asks for file links, use an explicit human/report view when available; those links are user inspection aids, not workflow inputs.
91
-
92
- `context compile close` may archive explicit debug scratch files through the CLI-owned output lifecycle. Normal compile state lives in workflow-scoped payloads. Current align state is internal CLI state, not a file protocol. Do not move, delete, or archive workspace output files yourself; the CLI owns that lifecycle.
93
-
94
- Close only projects finalized Nodes that materialize as a CLI-written knowledge article or as an explicit no-write placeholder declared by align with `planned_sections: []`. A compile skip action records reviewed no-write evidence, but it does not by itself turn an arbitrary finalized Node into a placeholder.
95
-
96
- In plan mode, your final report is the aggregated user-facing change list across all Nodes + "re-run `/context:compile` without `--plan` to apply"; do not run `context compile close` or `context verify` (they only make sense against a real write).
97
-
98
- Never claim success unless `context compile close` exited 0 and `context verify` is green. The only exception is the `no-changed-nodes` gate, where you report that compile stopped before draft and no files were written. Never hand-write rendered knowledge, index, or changelog files — the CLI is the sole writer.
99
- Never use Read / Glob / Grep / Write against workspace storage; use `context workflow`, `context compile`, `context reconcile`, `context source`, `context query`, and `context mdrive`.
100
- For large draft payloads, feed stdin directly into the `context compile` command with a heredoc. Do not pipe a heredoc through another command and do not redirect generated content into workspace files. Do not pipe `context ... --format json` through `python3`, `node`, `jq`, `sed`, `cat`, `2>&1`, or shell fallback wrappers. For draft schema discovery, run `context schema compile-draft` for readable YAML or `context schema compile-draft --format json` for machine-readable JSON:
101
-
102
- ```bash
103
- context compile draft billing-api --input - --prepare --format json <<'JSON'
104
- {
105
- "schema_version": "compile.draft.v2",
106
- "target_node": "billing-api",
107
- "actions": [
108
- {
109
- "op": "add",
110
- "kind": "description",
111
- "content": "Billing API exposes invoice lookup and payment capture endpoints.",
112
- "source_refs": ["src-1#billing-api L10-18@7a6f4c9d2e10"]
113
- }
114
- ]
115
- }
116
- JSON
117
- ```
118
-
119
- For reviewed no-write material, keep the evidence in the skip action so semantic review can record it:
120
-
121
- ```bash
122
- context compile draft billing-api --input - --prepare --format json <<'JSON'
123
- {
124
- "schema_version": "compile.draft.v2",
125
- "target_node": "billing-api",
126
- "actions": [
127
- {
128
- "op": "skip",
129
- "reason": "reviewed; intentionally not written",
130
- "source_refs": ["src-1#reviewed-note L12-14@7a6f4c9d2e10"]
131
- }
132
- ]
133
- }
134
- JSON
135
- ```
136
-
137
- For navigation-only or placeholder-only context, no active Section is the correct result:
138
-
139
- ```bash
140
- context compile draft billing-api --input - --prepare --format json <<'JSON'
141
- {
142
- "schema_version": "compile.draft.v2",
143
- "target_node": "billing-api",
144
- "actions": [
145
- {
146
- "op": "skip",
147
- "reason": "navigation-only context; align graph already preserves parent/child/related structure"
148
- }
149
- ]
150
- }
151
- JSON
152
- ```
153
-
154
- ## Final Report Contract
155
-
156
- - Report in the user's conversation language.
157
- - Keep a stable structure with these semantic sections; translate section headings into the user's conversation language instead of copying these English labels verbatim:
158
- 1. Completion headline.
159
- 2. Semantic apply table. Include refreshed-source rows first in source-id order when the refreshed-source loop ran, then one row per Node in align frontmatter order. Columns: target (source id or Node title/slug), type (`refresh` or Node type), and the `context reconcile apply --format json` counts: `applied`, `skipped`, `merged`, `superseded`, `kept_separate`, `omitted`, and `questions_resolved`. Include `reanchored`, `removed_unsupported`, and `split_then_reanchored` only when non-zero.
160
- 3. Close stage with `context compile close` result, final node/section totals, verify status, changelog stamp, incremental counts (`recompiled`, `locator_updates`, `canonical_source_ref_updates`, `rebuilt`), section fingerprint rebuild count, and archive status / archived file count when reported by CLI. Do not use close output as the semantic apply summary; aggregate the per-Node `context reconcile apply` results from Step 6.
161
- 4. Before/after status diff table with at least total nodes, node counts by type, total sections, and last compile time.
162
- 5. Knowledge objects by semantic handle. Include every Node slug and `node_class` returned by `context mdrive node list --format json`; group or label term definitions separately from concrete entities when useful. Include human-readable links only when an explicit human/report view returns them, and state that they are not workflow inputs.
163
- 6. Optional next step only when there is a concrete useful follow-up (for example recapture stale material or run `/context:align` to revise structure).
164
- - Do not say the user can inspect files without providing links.
165
-
166
- ## Plan Mode Final Report Contract
167
-
168
- - Use the same stable shape where possible, but make the headline clearly indicate that this was a plan-only run.
169
- - Replace the close-stage section with a not-written section and tell the user to re-run `/context:compile` without `--plan` to apply.
170
- - Do not include knowledge file links for files that were not written.
40
+ 1. Run `context doctor`. If output-align errors block compile, tell the user to run `/context:align` and stop.
41
+ 2. Run `context status --format json` and `context mdrive workspace stats --format json` for before/after reporting.
42
+ 3. Run `context compile scan --format json` (or `context compile scan --delegated --format json` only for explicit delegated mode).
43
+ 4. If the scan returns `stop_noop` or no changed work, report that compile stopped before draft and no files were written.
44
+
45
+ ## Main Loop
46
+
47
+ Repeat until the CLI returns `stop_noop`, `close_compile` succeeds, or a blocking user question remains.
48
+
49
+ ### Step 1 — Read Expected Views
50
+
51
+ Run expected view commands from the envelope before writing. For compile evidence, prefer the CLI-returned source-ref/scaffold views. They may expose:
52
+
53
+ - `citable_source_refs[]` — the only refs eligible for draft `source_refs`.
54
+ - `supporting_context_refs[]` background/framing only.
55
+ - `required_preserved_literals[]` — URL, code identifier, `source_ref`, or `block_id` literals that must stay visible in the generated content or repair report.
56
+ - diagnostics such as citation eligibility, source support, coverage, engagement, and advisory foldbacks.
57
+
58
+ Follow `page.next_command` for pagination. Use `how_to_explore[]` for narrow reads. Do not expand workflow payloads through host tool-results. Node-cycle receipts are compact by default; `actions_meta[]` exposes current draft action handles for patching without an extra status read.
59
+
60
+ ### Step 2 Produce Payloads Only When Requested
61
+
62
+ For `submit_compile_cycle`, load the Node evidence via the returned command/views, invoke packaged `context:skill-compile-draft` for exactly one Node, and pass the emitted JSON on stdin to the returned `next_action.command`.
63
+
64
+ For `continue_compile_cycle`, do not invoke the draft skill and do not attach `--input`; execute the returned `next_action.command` exactly. `--continue` resumes a saved draft session. If it returns `status: "noop"`, follow the returned `close_compile` next action.
65
+
66
+ For `patch_compile_draft`, submit only the patch schema requested by the CLI. Use `actions_meta[].action_id` for `replace_action` / `remove_action`, or `add_action` with `before` / `after`; do not use generic `op/path/value` aliases.
67
+
68
+ For `review_reconcile_decisions`, load the prepare payload through CLI views such as `context workflow show --payload prepare --unwrap --format json`, invoke packaged `context:skill-compile-judge` when semantic judgment is needed, run `context reconcile validate --mode compile --node <slug> --decisions - --format json`, repair any blocking diagnostics, then pass validated decisions to the returned review command.
69
+
70
+ Invoke `context:skill-compile-judge` only when the top-level `next_action.kind` is exactly `review_reconcile_decisions`. If `questions` are present but `next_action.kind` is `patch_compile_draft`, patch the draft first; do not infer judge mode from question counts.
71
+
72
+ For `apply_reconcile_review`, `close_compile`, `finish_current_node`, `submit_coverage_disposition`, or `abandon_or_rescan`, execute the returned command exactly. If it rejects, follow the new `next_action` and `reason_code`.
73
+
74
+ ### Step 3 Repair From Diagnostics
75
+
76
+ Use typed diagnostics as the repair contract:
77
+
78
+ - `reason_code`, `path`, and `missing[]` identify what to fix.
79
+ - `diagnostics.auto_repaired[]` records mechanical repairs; warning severity must be surfaced in the final report.
80
+ - `diagnostics.warnings[]` with info/advisory severity are not write blockers unless `blocking: true` or the next action says so.
81
+ - stale prepare refresh returns `review_reconcile_decisions` with `reason_code: "prepare_refreshed"`; reread the new prepare result before reviewing.
82
+
83
+ Do not recover by replaying an old manual path, editing rendered files, or guessing schema aliases.
84
+
85
+ ## Close And Report
86
+
87
+ When `next_action.kind` is `close_compile`, execute `context compile close` through packaged `context:skill-compile-close` or the returned command. Never claim success unless close exits 0 and verify is green, except the explicit no-work path.
88
+
89
+ Report in the user's conversation language. Include semantic apply counts, close/verify status, warning-level `auto_repaired[]`, and before/after workspace totals. Do not surface internal workflow payload digests, source-ref hashes, archive paths, or absolute file paths unless a user-facing report view explicitly returns them.
@@ -70,7 +70,10 @@ Q. What will this workspace mainly hold?
70
70
  Interpret the answer:
71
71
  - Chose A–D → generate a 2–3 line focus description in the user's language. Phrase it as
72
72
  "primarily X; supporting materials such as Y may also be filed here" rather than exclusion
73
- language — workspaces absorb auxiliary material in practice. Pass it as `--focus "..."`.
73
+ language — workspaces absorb auxiliary material in practice. Show the exact generated focus
74
+ text to the user and ask for one confirmation before running `context init`. If the user
75
+ approves, pass it as `--focus "..."`; if the user edits it, pass the edited text as
76
+ `--focus "..."`; if the user declines or says to skip, run without `--focus`.
74
77
  - Chose E or described freely → pass the user's text verbatim as `--focus "..."`.
75
78
  - User says "skip" / "don't care" → run `context init` without `--focus`.
76
79
  - `$ARGUMENTS` already contains `--focus "..."` → skip this step entirely.