@c4a/context-cli 0.5.29-beta.17 → 0.5.29-beta.18

package/package.json

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

package/plugin/commands/align.md

@@ -11,7 +11,7 @@ Run the beta.8 align workflow. `/context:align` is the user entrypoint; internal
 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. Preserve product names, code identifiers, slugs, flags, and citation tokens exactly when needed.
+   - 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. Preserve product names, code identifiers, slugs, flags, `block_id` handles, and citation tokens exactly when needed.
 2. Read schema and payloads through CLI only:
    - `context schema align-segments`
    - `context schema align-coarse-read`
@@ -28,10 +28,11 @@ Keep the prompt shape stable: read fixed schema/protocol first, then existing kn
 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`.
-     Submit coarse-read payloads serially within one workflow; workflow payload writes are not a parallel ingestion API.
+     For multiple sources, submit one envelope with `coarse_reads[]`; single-source payloads remain valid.
    - Submit each candidate batch with `context align --ops - --format json`.
-   - After the first batch, pass the current ledger digest as `--ledger-digest <digest>` so stale batches are rejected.
+   - `--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`:
 
@@ -39,6 +40,19 @@ Keep the prompt shape stable: read fixed schema/protocol first, then existing kn
 context align --finalize - --digest <segments-digest>
 ```
 
+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:
+
+```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 - --payload-digest <draft-digest> --format json`.
+
 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 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.

package/plugin/commands/capture.md

@@ -1,7 +1,7 @@
 ---
 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]"
-allowed-tools: Bash(context:*, brew:*, curl:*, sh:*, scoop:*, choco:*, lark-cli:*), WebFetch
+allowed-tools: Bash(context:*, bun:*, brew:*, curl:*, sh:*, scoop:*, choco:*, lark-cli:*), WebFetch
 ---
 
 <!--
@@ -14,6 +14,18 @@ length exemption for self-contained slash commands.
 
 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.
 
+### Code capture dependency preflight
+
+Before any `context capture --code` command, including `--plan`, refresh, or explicit `--module` runs, verify that the TypeScript extraction plugin is installed in the same global package environment as the `context` executable:
+
+```bash
+sh -c 'CTX_BIN="$(command -v context)" && node -e "const { createRequire } = require(\"node:module\"); createRequire(process.argv[1]).resolve(\"@c4a/extract-ts\");" "$CTX_BIN"'
+```
+
+If the check fails, stop the capture task. Tell the user to install the plugin globally with `bun install -g @c4a/extract-ts` (or the exact version from a CLI `agent_hints[].command` if present), then rerun their original `context capture --code ...` command. Do not inline `@c4a/extract-ts`, do not hand-write code snapshots, and do not continue with partial capture.
+
+Invocation note: code capture does not run through `npx`. `context capture --code` resolves `@c4a/extract` and `@c4a/extract-ts` from the installed `@c4a/context-cli` package using Node package resolution, prepares `.context/.cache/aspect-runners/<cacheKey>/c4a-extract-code.mjs`, and executes that wrapper directly. The plugin must therefore be available to the same global install that provides `context`.
+
 ### Route by argument
 
 - `$ARGUMENTS` starts with `http://` / `https://` → `context capture $ARGUMENTS` (feishu URLs need `lark-cli`).
@@ -59,6 +71,8 @@ Never suggest `/context:compile` when no align plan exists or when the only acti
 
 ### Missing dependency recovery
 
+If the CLI returns `agent_hints[]` with `code: "capture-code-typescript-plugin-missing"`, stop. Surface the hint to the user and use `agent_hints[0].command` as the install command if the user asks you to install it for them.
+
 If the CLI prints a missing-dependency error like `lark-cli not installed`, walk the user through installation:
 
 1. Ask once up-front whether to proceed with install. If no → stop and tell the user to install manually from the tool's official README, then re-run.

package/plugin/commands/compile.md

@@ -26,7 +26,7 @@ Modes:
 - **Default (no flag)** — draft plan + semantic reconciliation + apply writes + close.
 - **`--plan`** (opt-in when `$ARGUMENTS` contains `--plan`) — per Node, run `context compile --draft <slug> --input - --plan` 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.
 
-Language policy: your explanatory prose and final reports follow the user's conversation language. Knowledge drafts, Section `content` / `detail`, and Node-facing summaries follow `NodeContext.generation_policy.language` when the CLI provides it; preserve product names, code identifiers, CLI flags, slugs, `source_ref` tokens, and exact quoted evidence as printed. CLI stdout/stderr, the canonical `processing <slug>` lines, paths, slugs, source refs, issue codes, flags, and command names stay as printed.
+Language policy: your explanatory prose and final reports follow the user's conversation language. Compile draft `body`, Node-facing summaries, and generated knowledge follow `NodeContext.generation_policy.language` when the CLI provides it; 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.
 
 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.
 
@@ -62,14 +62,14 @@ Per-Node loop:
 
 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.
 
-1. For every workset Node, 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 `node_context_payload.scope_id` and `node_context_payload.digest`. First inspect citation handles with `context workflow show --payload node-context --scope <scope-id> --digest <digest> --view source-refs --unwrap --format json` or `context compile --source-refs <slug> --format json`; only read the full durable NodeContext once when you are ready to pass its returned `.value` object to the draft skill. 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. If NodeContext includes `generation_policy`, apply it to every generated title, summary, Section content/detail, and user-facing draft explanation; do not default to English scaffolding when the workspace language is not English. `context compile --context <slug> --request-full-text <block_id> --format json` may expose full text for inspection, but it 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. 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 the compact `source-refs`, `summary`, and coverage views returned by the CLI.
-2. Invoke packaged `context:skill-compile-draft` and follow its procedure to emit draft JSON. Do not reconstruct the draft shape from memory. Cite raw via `source_refs: [...]` chosen from `raw_snippets[].source_ref`; use a single-element array for one citation. The CLI rejects 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.
+1. For every workset Node, 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 `node_context_payload.scope_id` and `node_context_payload.digest`. First inspect citation handles with `context workflow show --payload node-context --scope <scope-id> --digest <digest> --view source-refs --unwrap --format json` or `context compile --source-refs <slug> --format json`; only read the full durable NodeContext once when you are ready to pass its returned `.value` object to the draft skill. 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. If NodeContext includes `generation_policy`, apply it to every generated title, summary, draft `body`, and user-facing draft explanation; do not default to English scaffolding when the workspace language is not English. `context compile --context <slug> --request-full-text <block_id> --format json` may expose full text for inspection, but it 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. 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 the compact `source-refs`, `summary`, and coverage views returned by the CLI.
+2. Invoke packaged `context:skill-compile-draft` and follow its procedure to emit draft JSON. Do not reconstruct the draft shape from memory. Section writes use `body` plus optional `rewrite`; new Sections do not need `section_id`. Cite raw via `source_refs: [...]` chosen from `raw_snippets[].source_ref`; use a single-element array for one citation. The CLI rejects 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.
 3. Fast path: pass the draft to `context compile --node-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: "review-required"`, use the returned `prepare` / `review` handles and continue with the manual path below; do not rerun the earlier context/source-ref reads.
-4. Manual path: pass the draft to `context compile --draft <slug> --input - --plan --prepare --format json`. This validates schema, source refs, and mount matrix, stores the compile draft as a workflow payload, and prepares the semantic reconcile payload without writing active knowledge. Default stdout is a compact prepare summary; use it to inspect readiness and capture `workflow_payload.digest` / `scope_id`. If semantic judgment is needed, load the full prepare payload with `context workflow show --payload prepare --scope <scope-id> --digest <digest> --unwrap --format json` and feed that full payload to packaged `context:skill-semantic-reconcile`. For triage-only inspection, use `context workflow show --payload prepare --scope <scope-id> --digest <digest> --view issues --unwrap --format json`; add `--status unsupported`, `--status weak`, `--item-id <claim-id>`, or `--page-size <n>` instead of expanding huge prepare payloads. If all pending items are mechanically safe defaults, prefer `context reconcile review --prepare-digest <digest> --scope <scope-id> --accept-safe-defaults --view status` instead of invoking the skill. If most items are safe and only a few need explicit decisions, combine `--accept-safe-defaults` with `--decisions -` and submit only those explicit decisions. If the CLI returns draft revision hints, use `context compile --draft-status <slug> --format json` and `context compile --draft-patch <slug> --input - --payload-digest <digest> --plan` so only the affected action is revised, then rerun `context compile --draft ... --plan --prepare`. On hard rejection before a draft session exists, read the error verbatim, fix the draft via the skill's self-verify, and retry up to 3 times.
-5. Review the prepared context before accepting defaults. If it reports unsupported `source_support`, repair/split evidence before review; unsupported items cannot be accepted with `accept_default` or user confirmation. Treat `temporal_prior` and candidate `temporal_disposition` as context for your rationale only; they do not change `default_decision` or make merge/supersede mechanically safe. If the prepare output has `items: []`, use its `next_decisions_template` as the decisions document for review; do not pass the whole prepare context as `--decisions`.
+4. Manual path: pass the draft to `context compile --draft <slug> --input - --plan --prepare --format json`. This validates schema, source refs, and mount matrix, stores the compile draft as a workflow payload, and prepares the semantic reconcile payload without writing active knowledge. Default stdout is a compact prepare summary; use it to inspect readiness and capture `workflow_payload.digest` / `scope_id`. If semantic judgment is needed, load the full prepare payload with `context workflow show --payload prepare --scope <scope-id> --digest <digest> --unwrap --format json` and feed that full payload to packaged `context:skill-compile-judge`. The judge output is the decision input for `context reconcile review`; keep `skill-semantic-reconcile` for refresh/drop or non-compile reconcile flows. For triage-only inspection, use `context workflow show --payload prepare --scope <scope-id> --digest <digest> --view issues --unwrap --format json`; add `--status unsupported`, `--status weak`, `--item-id <claim-id>`, or `--page-size <n>` instead of expanding huge prepare payloads. If all pending items are mechanically safe defaults, prefer `context reconcile review --prepare-digest <digest> --scope <scope-id> --accept-safe-defaults --view status` instead of invoking the skill. If most items are safe and only a few need explicit decisions, combine `--accept-safe-defaults` with `--decisions -` and submit only those explicit decisions. If the CLI returns draft revision hints, use `context compile --draft-status <slug> --format json` and `context compile --draft-patch <slug> --input - --payload-digest <digest> --plan` so only the affected action is revised, then rerun `context compile --draft ... --plan --prepare`. On hard rejection after a draft session is saved, read `context compile --draft-status <slug> --format json`, patch only the failed actions, and retry.
+5. Review the prepared context before accepting defaults. Treat lexical `source_support` as a diagnostic; final support and relation judgment belong to `context:skill-compile-judge`, which must compare only listed candidates and include the same-source-ref multi-kind semantic-role check. Treat `temporal_prior` and candidate `temporal_disposition` as context for your rationale only; they do not change `default_decision` or make merge/supersede mechanically safe. If the prepare output has `items: []`, use its `next_decisions_template` as the decisions document for review; do not pass the whole prepare context as `--decisions`.
    - If `agent_hints[]` contains `compact-source-low-coverage` or `dense-source-low-coverage`, return to the same compile draft and add actions for the suggested uncovered evidence before semantic review. Treat the reported coverage count (`covered/total`, remaining snippets) as a required self-check, not polish. A supported first quote only proves that one action is valid; it does not prove the Node is complete.
-   - If close later reports `coverage-high-signal-unresolved` for a dense document and every unresolved candidate in that node-scoped payload is intentionally excluded for the same reason, use `context compile --coverage-skip-unresolved --coverage-disposition-node <slug> --payload-digest <digest> --reason "<reason>"` instead of hand-writing a long disposition JSON. Use targeted `coverage-disposition` only when candidates need different outcomes.
-6. Pass the skill output to `context reconcile review --prepare-digest <prepare-digest> --decisions - --view status`. Use stdout for compact readiness/issues/questions. If questions are returned, ask the user in business language and convert unresolved `ask_user` items into final actions before applying. For `support_confirmation`, use `question.group_key` when present: group only questions that share that key and are all ordinary summary/compression checks; ask once with a compact list of claims and cited evidence. If the user confirms the group, keep each final write action and add `decided_by: user`. Do not group questions that add new facts, have missing hard facts, or have different source/evidence boundaries. If review reports unsupported evidence, choose or split the draft `source_refs[]` so each action is independently supported (use `source_support.evidence_block_candidates` to pick prepared evidence blocks or split unrelated claims), then rerun review. For `scope_review_required`, run `context:skill-semantic-reconcile` once more over the prepare context and current decisions before asking the user; if it still cannot resolve the scope, ask the user. For `omit_confirmation`, ask the user; only a confirmed no-write answer may become `action: omit` with `decided_by: user`. Never mark `decided_by: user` on your own; auto mode or permission to continue is not user confirmation.
+   - If close later reports unresolved coverage, first use `context compile --context <slug> --cover-uncovered-only --format json` to start a targeted repair draft that contains only unresolved candidates. If every unresolved candidate in that node-scoped payload is intentionally excluded for the same reason, use `context compile --coverage-skip-unresolved --coverage-disposition-node <slug> --payload-digest <digest> --reason "<reason>"` instead of hand-writing a long disposition JSON. Use targeted `coverage-disposition` only when candidates need different outcomes.
+6. Pass the judge skill output to `context reconcile review --prepare-digest <prepare-digest> --decisions - --view status`. Use stdout for compact readiness/issues/questions. If questions are returned, ask the user in business language and convert unresolved `ask_user` items into final actions before applying. For `support_confirmation`, use `question.group_key` when present: group only questions that share that key and are all ordinary summary/compression checks; ask once with a compact list of claims and cited evidence. If the user confirms the group, keep each final write action and add `decided_by: user`. Do not group questions that add new facts, have missing hard facts, or have different source/evidence boundaries. If review reports unsupported evidence, revise the draft or rerun the judge with corrected source_refs rather than forcing a decision. For `scope_review_required`, run `context:skill-semantic-reconcile` once more over the prepare context and current decisions before asking the user; if it still cannot resolve the scope, ask the user. For `omit_confirmation`, ask the user; only a confirmed no-write answer may become `action: omit` with `decided_by: user`. Never mark `decided_by: user` on your own; auto mode or permission to continue is not user confirmation.
 7. Default mode only: run plain `context reconcile apply` after `context reconcile review --prepare-digest ... --view status` returns `ready_to_apply: true`; the CLI applies the unique ready review for the current workflow scope. If questions were answered, rerun review on the updated decisions, then run `context reconcile apply` again. This writes active knowledge, verifies, and records the semantic ledger. In `--plan` mode, stop after review and report the not-written decisions.
 8. Persistent failure → stop and surface the full rejection list; never edit rendered files to bypass.
 
@@ -110,7 +110,7 @@ context compile --draft billing-api --input - --plan --prepare --format json <<'
     {
       "op": "skip",
       "reason": "reviewed; intentionally not written",
-      "source_refs": ["src-1#reviewed-note L12-14@ab12cd34ef56"]
+      "source_refs": ["src-1#reviewed-note L12-14@7a6f4c9d2e10"]
     }
   ]
 }

package/plugin/skills/skill-align-workflow/SKILL.md

@@ -19,7 +19,7 @@ Run the align workflow through the CLI-owned beta.8 payload chain: scan segments
 - Retired payloads include candidate tables, decision patches, and full-tree finalize documents.
 - Existing knowledge is the lookup registry. Use `context mdrive glossary match <name>` / `context mdrive node list --format json` for term/entity reuse; do not read `knowledge/**` and do not create a separate registry file.
 - Keep cache-friendly prompt order: fixed protocol and schemas first, existing knowledge lookup second, source-shared payload views third, current candidate batch last. Preserve CLI JSON order and do not add timestamps, random ids, scratch paths, or host paths to generated payloads.
-- `align-segments.generation_policy` is the workspace language contract for generated Node titles, summaries, rationale prose, and planned Section wording. Preserve product names, code identifiers, slugs, flags, and `source_ref` tokens exactly when needed.
+- `align-segments.generation_policy` is the workspace language contract for generated Node titles, summaries, rationale prose, and planned Section wording. Preserve product names, code identifiers, slugs, flags, `block_id` handles, and `source_ref` tokens exactly when needed.
 - Gate rules for `domain` and `action` proposals are in `references/gates.md`.
 - Coarse-read density and neutral signal rules are in `references/density-profile.md`.
 - Candidate anomaly handling, `label_hint`, and `llm_slug_hint` reference rules are in `references/candidate-resolution.md`.
@@ -33,9 +33,9 @@ Use this only inside `/context:align`.
 1. Start from `align-segments`.
 2. Inspect it through compact CLI views, not shell parsing: `context workflow show --payload align-segments --view segment --unwrap --format json`, `--view blocks`, and `--view windows`. Read and obey `generation_policy` before authoring any title, summary, rationale, or planned Section wording. The default `blocks` view is a structure summary; drill into content with `--window <window-id>`, `--heading <prefix>`, `--range <start:end>`, or `--token-budget <n>`. `--unwrap` only removes the workflow metadata envelope; it does not change summary/detail behavior.
 3. Query existing knowledge for reusable names before proposing new term/service/system/action Nodes. `context mdrive glossary match <name>` returns deterministic `match.kind`, `match.matched`, and `match.rank`; exact title/slug/alias hits should usually become references to the existing Node, not duplicate candidates.
-4. Produce coarse-read anchors and neutral content signals as JSON. Pick `density_profile` using `references/density-profile.md`; content signals describe text shape only, not final Node type. Submit the artifact through stdin with `context align --coarse-read - --format json`. The latest `align-coarse-read` payload is only the most recent checkpoint; durable multi-source reading notes live in `align-candidate-ledger.source_readings`. Submit coarse-read payloads serially within one workflow; workflow payload writes are not a parallel ingestion API.
-5. Produce candidate ops batches as JSON. Before each batch, refresh the Term Entity Boundary in `references/gates.md`; its TTL is one batch or about ten candidates, whichever comes first. Use `local:<name>` only inside the current batch; submit each batch through stdin with `context align --ops - --format json` and pass `--ledger-digest <digest>` after the first batch. The CLI reducer assigns durable candidate ids. For `merge_into`, `supersede`, and `reject`, include the required `*_label_hint` fields from the visible candidate labels.
-6. Read the CLI-written candidate ledger and aggregate 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. Treat aggregate fields as mechanical statistics and warnings, not semantic recommendations. Resolve every `anomaly_signals[]` entry as accept, dismiss, or unresolved before finalizing.
+4. Produce coarse-read anchors and neutral content signals as JSON. Pick `density_profile` using `references/density-profile.md`; content signals describe text shape only, not final Node type. Submit the artifact through stdin with `context align --coarse-read - --format json`. The latest `align-coarse-read` payload is only the most recent checkpoint; durable multi-source reading notes live in `align-candidate-ledger.source_readings`. For multiple sources, submit one envelope with `coarse_reads[]`; single-source payloads remain valid.
+5. Produce candidate ops batches as JSON. Before each batch, refresh the Term Entity Boundary in `references/gates.md`; its TTL is one batch or about ten candidates, whichever comes first. Use `local:<name>` only inside the current batch; submit each batch through stdin with `context align --ops - --format json`. `--ledger-digest <digest>` is optional; usually omit it and pass it only when you intentionally want stale-batch rejection for a high-assurance retry. The CLI reducer assigns durable candidate ids. For `merge_into`, `supersede`, and `reject`, include the required `*_label_hint` fields from the visible candidate labels.
+6. Read the CLI-written candidate ledger and aggregate 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. Treat aggregate fields as mechanical statistics and warnings, not semantic recommendations. Review `anomaly_signals[]`; address clear mistakes with another ops batch, otherwise continue. These signals are warnings and do not by themselves block finalizing.
 7. If the CLI returns `agent_hints[]`, follow them before retrying. Legacy-protocol hints mean the submitted payload/schema is retired; switch to the beta.8 schema named in the hint instead of reshaping old fields.
 8. Before producing `align-structure-decision`, refresh and apply `references/gates.md`: re-run the Term Entity Boundary decision tree, every `action` needs the five action probes plus structured `inference_sources`, and every `domain` needs `scope_blocks`, resolvable `child_refs`, and `grouping_reason`.
 9. Produce `align-structure-decision` as JSON with finalized nodes, `contains_parent`, `depends_on`, and one `block_ownership[]` entry per coverable block. Node titles and summaries must follow the latest `generation_policy` language; do not default to English scaffolding such as "How-To", "Strategy", or "Architecture" when the workspace language is not English. Submit it through stdin with `context align --finalize - --digest <segments-digest>`. Prefer stable `llm_slug_hint` values for `contains_parent_ref`, `from_ref`, `to_ref`, owners, and section owners while the final slug is still being normalized.
@@ -56,6 +56,19 @@ Use this only inside `/context:align`.
 
    After finalize, a second `context align --finalize` is rejected with `workflow-finalize-locked`; follow the returned `remediation_options[]` instead of resubmitting into the finalized workflow. Use `context workflow list --format json` when you need to audit finalize history.
 
+   If finalize returns an `align-finalize-draft` payload, patch the saved draft instead of rewriting the whole finalize document. Use JSON Pointer paths from the returned issues and submit only the corrections:
+
+   ```json
+   {
+     "schema_version": "align.finalize-patch.v1",
+     "operations": [
+       { "op": "replace", "path": "/block_ownership/3/primary_owner", "value": "rspack" }
+     ]
+   }
+   ```
+
+   Submit it with `context align --finalize-patch - --payload-digest <draft-digest> --format json`. If issues remain, patch the remaining issue paths; if validation passes, the CLI commits the finalized workflow artifacts.
+
 Never write raw, cache, knowledge, `/tmp`, or workspace scratch files. Never pipe `context ... --format json` through `jq`, `head`, `tail`, `sed`, `cat`, `2>&1`, Python, Node.js, or shell scripts. Never read host persisted output files such as Claude `tool-results/**`; rerun a narrower `context workflow show` command instead. Never submit old candidate-table, decision-patch, or full-tree payloads.
 
 </procedures>

package/plugin/skills/skill-align-workflow/references/gates.md

@@ -55,19 +55,19 @@ Not `term`:
 inference_sources:
   actor:
     source_type: explicit-block
-    evidence_blocks: [b0001]
+    evidence_blocks: [7a6f4c9d2e10]
     rationale: "The block names the operator role."
   outcome_or_goal:
     source_type: inferred-from-block
-    evidence_blocks: [b0001]
+    evidence_blocks: [7a6f4c9d2e10]
     rationale: "The block describes recovery as the expected result."
   repeatability_or_plan:
     source_type: heading-and-block
-    evidence_blocks: [b0001]
+    evidence_blocks: [7a6f4c9d2e10]
     rationale: "The runbook heading and ordered list indicate planned reuse."
   answerability:
     source_type: explicit-block
-    evidence_blocks: [b0001]
+    evidence_blocks: [7a6f4c9d2e10]
     rationale: "The steps answer how the operation is performed."
 ```
 

package/plugin/skills/skill-compile-close/SKILL.md

@@ -30,9 +30,9 @@ command. It does not hand-edit rendered knowledge.
   - Content / Section issues (`invalid-section-mount`, `body-ad-hoc-heading`, `dangling-source-alias`) → user re-runs `/context:compile` (draft loop fixes its own Section actions; the close stage does not patch)
   - Structural issues (`contains-cycle`, `edge-dangling-node`, `duplicate-slug`, `invalid-node-type`, `domain-same-file-child`) → user runs `/context:align` to revise the plan
   - Source issues (`dropped-source-reference`) → user runs `/context:drop <id>` to complete the drop
-- Exit 0 → summarise node/section totals, verify, `recompiled`, `locator_updates`, `rebuilt`, fingerprint rebuild count, and archive status / archived file count when printed; then stop.
+- Exit 0 → summarise node/section totals, verify, `recompiled`, `locator_updates`, `rebuilt`, fingerprint rebuild count, archive status / archived file count, and any `ready_with_debt` coverage warnings when printed; then stop.
 - Exit 2 → report the full issue list verbatim + point at the right re-entry command above. Do not hand-open the affected rendered article.
-- If exit 2 includes `coverage-high-signal-unresolved`, follow the CLI hint. Read the node-scoped payload with `context workflow show --payload coverage-candidates --scope <node-run-scope> --view coverage`. If all unresolved candidates are intentionally excluded for the same reason, use `context compile --coverage-skip-unresolved --coverage-disposition-node <slug> --payload-digest <digest> --reason "<reason>"`; otherwise inspect `context schema coverage-disposition`. Do not guess workspace-scope payload paths.
+- Coverage warning choice: `ready_with_debt` means close succeeded and unresolved coverage remains visible. You may either continue with the warning recorded, or run an uncovered-only repair/skip round. If all unresolved candidates are intentionally excluded for the same reason, use `context compile --coverage-skip-unresolved --coverage-disposition-node <slug> --payload-digest <digest> --reason "<reason>"`; otherwise inspect `context schema coverage-disposition`.
 - Never re-run `context compile --draft` from close to paper over verify failures. Draft failures belong in the draft loop.
 - Do not use Python, Node.js, shell scripts, `ls`, `find`, `rg`, `cat`, or similar ad-hoc commands to inspect `WORKSPACE_DIR`, `.context`, knowledge files, or `/tmp` workflow artifacts.
 - Derivable files self-heal: missing `_index.md` or `changelog.md` is rebuilt inside `compile --close` before the append, locator-only source moves are refreshed, non-canonical but hash-valid `source_ref` locators are canonicalized, and high-signal coverage candidates already backed by active Sections are marked covered. No pre-check needed.
@@ -62,11 +62,10 @@ Close is one in-process command with one exit code:
 | Outcome | Agent action |
 |---|---|
 | Exit 0, 0 issues | Summarise those counts in the user's language: Nodes touched; Sections added / updated / superseded / deprecated / skipped; `recompiled`; `locator_updates`; `rebuilt`; verify green. Stop. |
-| Exit 0, warnings only | Summarise + list warnings verbatim. Point at `/context:status` or `context cache status` when the warning is incremental-cache-related. Stop. |
+| Exit 0, warnings only | Summarise + list warnings verbatim. For coverage warnings, name both choices: continue with `ready_with_debt`, or run an uncovered-only repair/skip round through `context compile --coverage-skip-unresolved` or `context schema coverage-disposition`. Stop. |
 | Exit 2, Section / content issue | Surface the full issue list; point the user at re-running `/context:compile` (the draft loop owns Section writes). Do NOT Edit the affected rendered article. |
 | Exit 2, structural issue (cycle, duplicate slug, `invalid-node-type`, `domain-same-file-child`) | Surface the full issue list; point the user at `/context:align` to revise structure. Do not re-run compile. |
 | Exit 2, `dropped-source-reference` | Surface the source-id; point the user at `/context:drop <id>` to complete the drop cleanup. |
-| Exit 2, `coverage-high-signal-unresolved` | Read the node-scoped coverage payload named in the CLI hint. If all unresolved candidates are intentionally covered by sibling Nodes or should not be written for this Node for the same reason, run `context compile --coverage-skip-unresolved --coverage-disposition-node <slug> --payload-digest <digest> --reason "<reason>"`; otherwise submit targeted dispositions from `context schema coverage-disposition`. |
 
 The close stage never edits rendered knowledge on the agent side. Every verify error routes back to the correct upstream command (compile / align / drop), never sideways into a hand Edit. Use the CLI issue code and hint printed by `context compile --close` for the error→command mapping.
 

package/plugin/skills/skill-compile-draft/SKILL.md

@@ -4,7 +4,7 @@ description: >
   Packaged skill invoked by `/context:compile`; not a user slash command. For one Node at a time, reads
   the CLI-provided `NodeContext` (planned metadata, raw snippets, and
   existing Sections if any), classifies every raw fragment into a Section
-  kind via the priority chain, writes content + detail + `source_refs[]`,
+  kind via the priority chain, writes `body` + `source_refs[]`,
   and emits a compile draft JSON document. The CLI
   validates the actions via `context compile --draft <slug> --input - --plan`.
   Activates when `/context:compile` iterates across the confirmed align plan.
@@ -35,17 +35,17 @@ deprecate / skip` actions; emit JSON; the CLI performs every write.
 - Pick `kind` from the form of the cited raw block: code / config / command sample → `example`; verifiable rule with a check method → `spec`; stable invariant, design rule, or core mechanism → `principle`; ≥2 subjects × ≥2 dimensions → `comparison`; explicit risk or caveat → `warning`; Q+A pair → `faq`; real incident with timeline → `incident`; versioned change record → `changelog`. Reach `description` only when none of those forms fit — narrative that defines an entity, explains a mechanism, or summarises a stance. First matching form wins.
 - `kind × node.type` must satisfy the CLI Section mount matrix; mismatches get rejected at write time. When the strongest kind is blocked by mount matrix, fall to the next legal kind whose form actually fits — do not collapse to `description` just because it mounts everywhere, and do not invent thin precision (e.g. one-line `spec`) just to avoid `description` either. See [Description anti-abuse gates](#description-anti-abuse-gates) for the classification checks at the description boundary.
 - Every write action cites raw via `source_refs[]`, choosing values from `raw_snippets[].source_ref`. Use a single-element array for one citation. Treat each source ref as an opaque citation token; never fabricate, parse, dereference, or cite navigation-only blocks as evidence for a content Section.
-- `content` ≤256 chars; long prose goes in `detail`. If a cited raw sentence is already short, single-line, and readable, use it with `content_mode: "extract"` instead of asking AI to summarize it. Do not compress 200 readable characters into a 180-character paraphrase just to make it look rewritten.
-- `detail` is not an evidence echo field. Do not copy raw evidence into `detail`, do not prefix detail with labels such as `原文:`, and do not use detail only to show the raw quote. Raw evidence is traceable through `source_refs[]`.
-- For `example` Sections, if the cited raw snippet contains command / config / code fences, keep `content` as a short summary and preserve the relevant fenced block in `detail`; do not collapse copyable examples into prose-only summaries unless semantic review asks the user and the user accepts that compression.
-- Preserve documentation/reference URL blocks. If a cited raw block is primarily links (官网 / docs / reference / related links), create a small `description` Section such as "相关链接" and put every URL in `detail`; do not drop link-only evidence just because it is not prose.
-- For `add` and `supersede.new`, omit optional fields when empty; do not emit `detail: null`. `detail: null` only has "clear existing detail" meaning on `update`.
+- Use one `body` field for Section prose. It may be long and may contain fenced code. Do not emit internal Section fields or retired extractive-contract fields; the CLI derives its internal short claim/detail split before validation.
+- Set `rewrite: false` only when the raw wording is already clear and should be preserved; omit it for normal concise rewriting.
+- For `example` Sections, if the cited raw snippet contains command / config / code fences, include the short summary and the relevant fenced block together in `body`; do not collapse copyable examples into prose-only summaries unless semantic review asks the user and the user accepts that compression.
+- Preserve documentation/reference URL blocks. If a cited raw block is primarily links (官网 / docs / reference / related links), create a small `description` Section such as "相关链接" and keep every URL in `body`; do not drop link-only evidence just because it is not prose.
+- For `add`, `update`, and `supersede.new`, omit optional fields when empty; never emit `detail: null`.
 - `refers_to_nodes[]` only carries slugs present in the context's glossary, existing Sections, or the current align plan; never invent one.
 - `supersede` is for semantic replacement; `update` is for typo / wording fixes; `deprecate` needs a `reason`; `skip` is the honest default when raw adds nothing.
 - If a note or raw snippet was reviewed and should intentionally not write active knowledge, emit `skip` with `source_refs[]` from that exact snippet. This lets semantic review record `reviewed_no_write`; a bare skip is only for deterministic no-op cases such as unchanged input or navigation-only context.
 - Any Node may legitimately compile to no Sections when the provided snippets contain only navigation (`Parent` / `Children` / `Related` / `Relations`) or placeholder text that explicitly says no detailed content is available. Emit `skip`; do not turn align summaries, parent/child lists, sibling links, or placeholders into `description` Sections. The align graph and Node metadata preserve structure; active Sections need citation-eligible content.
 - FAQ collections attach to the most specific finalized Node (Entity → Action → Domain fallback); never create a standalone FAQ container.
-- Output language: `content`, `detail`, Node-facing summaries, and user-facing draft explanations follow `NodeContext.generation_policy.language` when present; otherwise match the raw material. Preserve product names, code identifiers, CLI flags, slugs, `source_ref` tokens, and exact quoted evidence as printed. Kind / confidence / identifier fields stay English.
+- Output language: draft `body`, Node-facing summaries, and user-facing draft explanations follow `NodeContext.generation_policy.language` when present; otherwise match the raw material. Preserve product names, code identifiers, CLI flags, slugs, `block_id` / `source_ref` tokens, and exact quoted evidence as printed. Kind / confidence / identifier fields stay English.
 - Stable output: keep action order aligned with evidence order, keep object fields in the documented schema order, omit empty optional fields, and do not add current timestamps, random ids, scratch paths, or host paths. Fixed rules and schema come from this skill; only the current NodeContext should vary between repeated Node draft calls.
 
 <reference>
@@ -60,21 +60,21 @@ deprecate / skip` actions; emit JSON; the CLI performs every write.
     "sources": ["..."], "aliases": ["..."], "summary": "...",
     "planned_sections": ["spec", "..."],
     "action_gate": {
-      "actor_blocks": ["b0002"],
+      "actor_blocks": ["2f4b8c1e9a03"],
       "trigger_blocks": [],
-      "goal_blocks": ["b0003"],
-      "step_blocks": ["b0004"],
-      "outcome_blocks": ["b0005"],
-      "repeatability_or_plan_blocks": ["b0006"],
+      "goal_blocks": ["c0d4e5f61728"],
+      "step_blocks": ["8b9a0c1d2e3f"],
+      "outcome_blocks": ["4e2d1c0b9a88"],
+      "repeatability_or_plan_blocks": ["9d1e2f3a4b5c"],
       "inference_sources": {
-        "actor": { "source_type": "explicit-block", "evidence_blocks": ["b0002"], "rationale": "..." },
-        "outcome_or_goal": { "source_type": "explicit-block", "evidence_blocks": ["b0003"], "rationale": "..." },
-        "repeatability_or_plan": { "source_type": "explicit-block", "evidence_blocks": ["b0006"], "rationale": "..." },
+        "actor": { "source_type": "explicit-block", "evidence_blocks": ["2f4b8c1e9a03"], "rationale": "..." },
+        "outcome_or_goal": { "source_type": "explicit-block", "evidence_blocks": ["c0d4e5f61728"], "rationale": "..." },
+        "repeatability_or_plan": { "source_type": "explicit-block", "evidence_blocks": ["9d1e2f3a4b5c"], "rationale": "..." },
         "answerability": { "source_type": "ref-node", "ref_nodes": ["..."], "rationale": "..." }
       }
     },
     "domain_gate": {
-      "scope_blocks": ["b0001"],
+      "scope_blocks": ["7a6f4c9d2e10"],
       "child_refs": ["..."],
       "grouping_reason": "..."
     }
@@ -83,22 +83,22 @@ deprecate / skip` actions; emit JSON; the CLI performs every write.
     "language": "Chinese",
     "source": "workspace.language",
     "applies_to": ["node.title", "node.summary", "section.content", "section.detail", "user_facing_report"],
-    "instruction": "Generate knowledge titles, summaries, Section content/detail, and user-facing reports in Chinese; preserve product names, code identifiers, CLI flags, source_ref tokens, slugs, and quoted evidence exactly when needed."
+    "instruction": "Generate knowledge titles, summaries, Section content/detail, and user-facing reports in Chinese; preserve product names, code identifiers, CLI flags, block_id/source_ref tokens, slugs, and quoted evidence exactly when needed."
   },
   "existing": {               // present if the Node already exists
     "sections": [
       { "id": "section-1", "kind": "description", "content": "...",
         "detail": "...", "status": "active|deprecated",
-        "confidence": "...", "source_ref": "src-1#anchor L10-14@ab12cd34ef56",
+        "confidence": "...", "source_ref": "src-1#anchor L10-14@7a6f4c9d2e10",
         "refers_to_nodes": [...] }
     ]
   },
   // Default NodeContext does not expose raw file paths. Copy raw_snippets[].source_ref
-  // into draft source_refs[]; identify blocks via source_id + block_locator_id (or block_hash).
+  // into draft source_refs[]; copy CLI-provided block_id only for ownership challenges.
   "mentions":      [ { "line": 12, "quote": "...", "source_id": "local:billing", "block_locator_id": "h2-api" } ],
   "raw_snippets":  [ { "line": 10,
                        "line_range": [10, 18],
-                       "source_ref": "src-1#api L10-18@ab12cd34ef56",
+                       "source_ref": "src-1#api L10-18@7a6f4c9d2e10",
                        "quote": "...context block...",
                        "mention_quote": "...",
                        "source_type": "local|feishu|note",
@@ -152,43 +152,31 @@ unless citation-eligible raw snippets state the same claim.
   "target_node": "<matches node.slug>",
   "actions": [
     { "op": "add", "kind": "spec",
-      "content": "...", "detail": "...",
+      "body": "...",
+      "rewrite": false,
       "refers_to_nodes": ["..."],
-      "source_refs": ["src-1#api L10-14@ab12cd34ef56"],
-      "content_mode": "extract",
-      "basis_spans": [
-        { "source_ref": "src-1#api L10-14@ab12cd34ef56" }
-      ]
+      "source_refs": ["src-1#api L10-14@7a6f4c9d2e10"]
     },
     { "op": "update", "target_section_id": "section-3",
-      "content": "...", "detail": null,    // null clears detail
+      "body": "...",
       "refers_to_nodes": null,
-      "source_refs": ["src-1#api L18-21@cd34ef56ab78"],
-      "content_mode": "minimal_paraphrase",
-      "paraphrase_reason": "fragment_fix",
-      "basis_spans": [
-        { "source_ref": "src-1#api L18-21@cd34ef56ab78" }
-      ] },
+      "source_refs": ["src-1#api L18-21@c0d4e5f61728"] },
     { "op": "supersede", "target_section_id": "section-5",
       "reason": "raw published a new retention value",
-      "new": { "kind": "spec", "content": "...", "detail": "...",
+      "new": { "kind": "spec", "body": "...",
                "refers_to_nodes": ["..."],
-               "source_refs": ["src-1#limits L30-34@ef56ab78cd90"],
-               "content_mode": "extract",
-               "basis_spans": [
-                 { "source_ref": "src-1#limits L30-34@ef56ab78cd90" }
-               ] } },
+               "source_refs": ["src-1#limits L30-34@9d1e2f3a4b5c"] } },
     { "op": "deprecate", "target_section_id": "section-2", "reason": "..." },
     { "op": "skip", "reason": "no new evidence in raw snippets" },
     { "op": "skip", "reason": "reviewed; intentionally not written",
-      "source_refs": ["src-1#note L4-8@ab12cd34ef56"] },
+      "source_refs": ["src-1#note L4-8@7a6f4c9d2e10"] },
     { "op": "structure_challenge",
       "challenge_id": "ch_0001",
       "kind": "missing_action_node",
       "node_slug": "<matches node.slug>",
       "action_tag": "rollout-runbook",
       "summary": "The cited evidence is a repeatable procedure.",
-      "source_ref": "src-1#ops L40-55@cd34ef56ab78",
+      "source_ref": "src-1#ops L40-55@c0d4e5f61728",
       "reason": "Align must review structure before compile writes process prose." },
     { "op": "structure_challenge",
       "challenge_id": "ch_0002",
@@ -199,7 +187,7 @@ unless citation-eligible raw snippets state the same claim.
     { "op": "pending_ownership_challenge",
       "challenge_id": "och_0001",
       "node_slug": "<matches node.slug>",
-      "block_id": "b0032",
+      "block_id": "2f4b8c1e9a03",
       "requested_role": "shared",
       "reason": "A visible context_only or secondary shared block contains facts that need citation." }
   ]
@@ -209,17 +197,10 @@ unless citation-eligible raw snippets state the same claim.
 `source_refs[]` values are copied from `raw_snippets[].source_ref`; a single
 citation is still written as a single-element array. Submitting singular
 `source_ref` or quoted-evidence fields is rejected with canonical repair hints.
-Every Section write (`add`, `update` with content/detail/source refs, and
-`supersede.new`) must include `content_mode` plus `basis_spans[]`. Use
-`content_mode: "extract"` when the cited raw sentence already fits the
-single-line content contract and you keep the original sentence order. If you reorder
-sentences, merge sentences with new punctuation, or consolidate bullets, use
-`content_mode: "minimal_paraphrase"` with the matching `paraphrase_reason`. Use `content_mode: "minimal_paraphrase"` only
-when direct extract would be malformed, too broad, duplicated, or needs
-multi-span consolidation; include `paraphrase_reason`.
-Do not mark sentence 1 + sentence 3 from the same evidence block as
-`extract`; non-contiguous copies are `minimal_paraphrase` even when every word
-came from raw evidence.
+Every Section write (`add`, `update` with body/source refs, and
+`supersede.new`) uses `body`. Keep one coherent fact group per action; when
+one Section summarizes contiguous multi-block evidence, list every relevant
+source ref in order under `source_refs[]`.
 `structure_challenge` and `pending_ownership_challenge` do not write Sections;
 the CLI stores them as workflow payloads and close exposes them as debt until
 align resolution handles them. Supported structure challenge kinds include
@@ -357,27 +338,21 @@ For each existing Section:
 
 For each change from Steps 2-3:
 
-1. Split the cited block into `content` and `detail` so the Section is independently addressable in retrieval. `content` (≤256 chars) carries the Section's identity — for `example` / `spec` / `incident` that is the load-bearing identifiers the cited block hinges on (command name, key flags, field names, distinguishing values, mode names, error codes); for `principle` / `description` / `decision` / `comparison` / `warning` / `faq` / `changelog` it is the claim itself in raw's own terms. If the raw sentence already fits this shape, keep it as an extract instead of summarizing it. `detail` carries active knowledge that cannot fit in `content`, especially copyable code/config/URL/table material. Prefer splitting prose into separate supported Sections over storing a raw prose quote in `detail`. Do not put the raw evidence itself into `detail` as a "source copy"; the rendered Section already carries source_ref, and the CLI can resolve the raw evidence from that token.
-2. Keep `content` and `detail` faithful to the cited raw terms: do not introduce acronyms, abbreviations, translations, or aliases that do not appear in the cited raw snippet unless raw itself defines the equivalence or the user confirms it later during semantic review.
-3. If the cited block contains documentation/reference URLs, preserve them in `content` or `detail`. Link-only blocks are still useful knowledge; use `kind: description` with a concise "相关链接" identity when no more specific kind applies.
+1. Write `body` as the Section text the reader should see. It can include long prose, URLs, tables, command/config/code fences, or short raw wording. Keep one coherent, cited fact group per action; the CLI derives the internal `content`/`detail` split.
+2. Keep `body` faithful to the cited raw terms: do not introduce acronyms, abbreviations, translations, or aliases that do not appear in the cited raw snippet unless raw itself defines the equivalence or the user confirms it later during semantic review. Use `rewrite: false` when preserving raw expression is the least surprising representation.
+3. If the cited block contains documentation/reference URLs, preserve them in `body`. Link-only blocks are still useful knowledge; use `kind: description` with a concise "相关链接" identity when no more specific kind applies.
 4. Omit `confidence` for ordinary confirmed claims. Assign `confidence` per the [Confidence rubric](#confidence-rubric) only when the evidence is not confirmed.
 5. Fill `refers_to_nodes[]` per [Glossary and refers_to_nodes](#glossary-and-refers_to_nodes).
 6. Cite evidence with `source_refs[]`, picking values from `raw_snippets[].source_ref`. When one Section summarizes contiguous multi-block evidence, list every relevant source ref in order under `source_refs[]`; the CLI verifies that the refs can collapse to one canonical citation token. If the evidence is non-contiguous or contains separable claims, split the draft into separately cited actions instead of stretching one action across unrelated blocks. For `skip`, include `source_refs[]` only when the skip represents reviewed no-write material; omit evidence for purely deterministic no-ops such as unchanged input. Never submit singular `source_ref` or quoted-evidence fields; the CLI rejects them.
-7. Add the extractive contract to every Section write: `content_mode`,
-   `basis_spans[]`, and `paraphrase_reason` when `content_mode` is
-   `minimal_paraphrase`. Each `basis_spans[]` entry contains only
-   `source_ref`; the CLI resolves cited text and computes the audit basis
-   internally. When one short basis span is already a valid `content`, choose
-   `content_mode: "extract"`.
-8. If evidence implies a missing Action, missing `depends_on`, wrong parent, or
+7. If evidence implies a missing Action, missing `depends_on`, wrong parent, or
    needed ownership upgrade from `context_only`, emit the corresponding
    challenge action instead of forcing the content into a Section.
    `pending_ownership_challenge.requested_role` is `owned` or `shared`.
 
-Rendered knowledge uses the short claim as the visible blockquote and renders
-`detail` as a collapsed Details block under that claim. A reader should be able
-to understand the Section from `content` first; `detail` is supporting active
-knowledge, not a hidden evidence copy.
+Rendered knowledge uses a CLI-derived short claim as the visible blockquote and
+renders longer supporting material from `body` as collapsed Details when needed.
+A reader should be able to understand the Section from the short claim first;
+long supporting material is active knowledge, not a hidden evidence copy.
 
 ### Step 5 — Emit the JSON
 
@@ -388,11 +363,10 @@ Emit one compile draft JSON document for the caller to pass to `context compile
 - [ ] `target_node` equals `node.slug` — if not, **Step 5**.
 - [ ] Every `add` / `supersede.new` has a legal kind × type combination — if not, **Step 2**.
 - [ ] Every action's `source_refs[]` entries appear in `raw_snippets[].source_ref` for this NodeContext, and no action carries singular `source_ref` or quoted-evidence fields — if not, **Step 4**; pick the right source ref, split non-contiguous claims, or use `skip` only when raw has no write-worthy fact.
-- [ ] Every Section write has `content_mode` and `basis_spans[]`; every
-      `minimal_paraphrase` has `paraphrase_reason` — if not, **Step 4**.
-- [ ] Short, readable, single-line evidence was not rewritten just for style. If it already fits `content`, switch to `content_mode: "extract"` — if not, **Step 4**.
-- [ ] `content` does not add new hard terms, acronyms, abbreviations, translations, URLs, code literals, versions, or aliases absent from the cited raw snippet — if it does, either use the raw wording, move the extra explanation into a user-confirmed decision later, or **Step 4**.
-- [ ] No `add` / `supersede.new` action contains `detail: null` — omit `detail` instead.
+- [ ] Every Section write uses `body` and cites `source_refs[]`; no action uses `content`, `detail`, singular `source_ref`, extractive-contract fields, or quoted-evidence fields — if not, **Step 4**.
+- [ ] Short, readable, single-line evidence was not rewritten just for style. If it is already clear, keep the raw wording in `body` and set `rewrite: false` — if not, **Step 4**.
+- [ ] `body` does not add new hard terms, acronyms, abbreviations, translations, URLs, code literals, versions, or aliases absent from the cited raw snippet — if it does, either use the raw wording, move the extra explanation into a user-confirmed decision later, or **Step 4**.
+- [ ] No action contains `detail` or `content` — use `body` instead.
 - [ ] No `description` action that would fail the anti-abuse gates — if any, **Step 2**.
 - [ ] Every citation-eligible raw URL block is either preserved in a Section or intentionally skipped with evidence and reason; if not, **Step 4**.
 - [ ] Dense raw material was not collapsed into one broad Section. If `raw_snippets[]` spans many locator areas and only one write action exists, return to **Step 2** unless the remaining snippets are duplicates, navigation-only, or already covered by existing Sections.