@c4a/context-cli 0.5.29-beta.20 → 0.5.29-beta.21

package/package.json

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

package/plugin/commands/align.md

@@ -22,7 +22,7 @@ Keep the prompt shape stable: read fixed schema/protocol first, then existing kn
    - `context workflow show --payload align-segments --view segment --unwrap --format json`
    - `context workflow show --payload align-segments --view blocks --unwrap --format json` (summary only)
    - `context workflow show --payload align-segments --view windows --unwrap --format json`
-   - Drill into content only with semantic filters such as `--window <window-id>`, `--heading <prefix>`, `--range <start:end>`, or `--token-budget <n>`.
+   - Drill into content only with focused filters such as `--window <window-id|src-N:M>`, `--heading <prefix>`, `--range <start:end>`, or `--token-budget <n>`. `src-N:M` means the M-th window under the `source_alias` shown by `--view windows`.
    - `--unwrap` only removes the workflow metadata envelope. It does not turn a summary view into detail output.
 3. Reuse existing knowledge before inventing candidates. For named terms or entities, prefer `context mdrive glossary match <name>` and `context mdrive node list --format json` over direct file reads. Treat `match.kind`, `match.matched`, and `match.rank` as stable lookup hints: exact title/slug/alias hits should usually reuse the existing Node instead of creating another one.
    - Apply packaged `context:skill-align-workflow` Node classification gates before candidate ops and again before finalize: Action requires scale plus process evidence; Entity requires a concrete A/B tag or pure `term`; Domain requires child Nodes; fake Entities need at least two suspicious signals before downgrade.
@@ -76,6 +76,8 @@ Submit it with `context align --ownership-patch - --format json`. Keep `base_dig
 
 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.
 
+`nodes[].planned_sections` is the distinct set of Section kinds planned for that Node. List each kind at most once; do not copy `sections[].section_kind` one-for-one when a Node has multiple Sections of the same kind.
+
 For large finalize decisions, use `block_ownership_defaults[]` instead of enumerating every block. Each default names a `source_id` plus the same ownership fields as a block-level entry except `block_id`; the CLI expands it across that source's coverable blocks. Put only exceptions in `block_ownership[]`, which override defaults for their `block_id`. Keep the payload on stdin; do not generate temp JSON files just to list hundreds of ownership rows.
 
 If a source is only navigation or placeholder context, keep the Node only when the graph/slug is still useful: set `planned_sections: []`, mark the navigation evidence `context_only` or `ignored` as appropriate, and do not promote relation lines to `owned` just to satisfy citations. Compile close will materialize an empty placeholder Node with no active Sections.

package/plugin/commands/capture.md

@@ -41,7 +41,7 @@ Invocation note: code capture does not run through `npx`. `context capture --cod
   - Then run `context capture --code` with one repeated `--module <path>` for every selected package. The CLI derives and stores path filtering silently from that selection.
 - User asks to record conversation material, a decision, a revision intent, or a temporary observation → use note capture:
   - Classify once as `revision`, `decision`, or `brainstorm`; temporary observations are `brainstorm`. If unclear, ask one clarification.
-  - For `revision` or `decision`, require an existing target. If missing, run `context query --intent node_search <user words>` and ask the user to confirm a Node or Section before writing.
+  - For `revision` or `decision`, require an existing target. If missing, run `context query --intent node_lookup --query "<user words>"` and ask the user to confirm a Node or Section before writing.
   - Write the body to `context capture --note --intent <intent> --anchor <node-slug>[#<section-id>] --input -` for anchored notes, or omit `--anchor` for brainstorm.
   - For `revision`, organize the stdin Markdown with headings: `旧上下文`, `修改意图`, `新内容`, `验证条件`.
   - For `decision`, organize the stdin Markdown with headings: `议题`, `选项`, `决议`, `理由`.

package/plugin/commands/compile.md

@@ -13,7 +13,7 @@ The agent protocol itself still delegates to internal packaged procedures.
 
 ## Your task
 
-Synthesise the finalized align plan into knowledge through semantic CLI operations. 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.
+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.
 
 Naming convention:
 
@@ -26,7 +26,13 @@ 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. Node titles, summaries, and user-facing draft explanations follow `NodeContext.generation_policy.language` when the CLI provides it. Source-bound compile draft `body` 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. 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.
+Delegated workflow mode:
+
+- 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-changes --delegated --format json`. Do not add it for vague "continue" / "继续" permission.
+- `--delegated` is a workflow-level authorization, not a per-review override. It only lets the CLI auto-accept low-risk weak support when hard facts are present; unsupported evidence, missing hard facts, type drift, schema errors, ownership/structure challenges, and destructive gates still block.
+- Never hand-author `decided_by: delegated_agent`; the CLI injects it only inside a delegated compile workflow.
+
+Language policy: your explanatory prose and final reports follow the user's conversation language. Node titles, 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. 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.
 
@@ -34,7 +40,7 @@ Preflight:
 
 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.
 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[]`.
-3. Run `context compile --scan-changes --format json` and parse the JSON as `COMPILE_WORKSET`. `--scan-changes` is the only workset scan flag; `--plan` is reserved for draft validation.
+3. Run `context compile --scan-changes --format json` and parse the JSON as `COMPILE_WORKSET`. If delegated workflow mode is explicitly authorized, run `context compile --scan-changes --delegated --format json` for this first scan instead. `--scan-changes` is the only workset scan flag; `--plan` is reserved for draft validation.
    - If `context workflow status --format json` has `current: null` but `last_published` is present, continue with `context compile --scan-changes`; the published finalized ownership is still the workspace structure truth. Use `context workflow list --format json` only when you need lineage/history diagnostics.
    - Compile JSON may include `source_finalize`; use it as lineage for the finalized ownership that produced the current Node set and citation ownership.
    - 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.
@@ -62,11 +68,11 @@ 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 workflow payload handles; do not extract digests by hand. First inspect citation handles with `context compile --source-refs <slug> --format json` or `context workflow show --payload node-context --view source-refs --unwrap --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 generated titles, summaries, and user-facing explanations; for source-bound draft `body`, 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. `context compile --context <slug> --request-full-text <block_id> --format json` may expose full visible evidence text for inspection, including primary evidence, 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 or Section classification rules from memory; the draft skill carries the canonical kind priority, mount matrix, examples, and reflection gates. Section writes use `body` plus optional `rewrite`; 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 body actually consumes all of them. The CLI may auto-narrow over-wide citations and leaves removed refs uncovered. 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.
+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 workflow payload handles; do not extract digests by hand. First inspect citation handles with `context compile --source-refs <slug> --format json` or `context workflow show --payload node-context --view source-refs --unwrap --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 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. `context compile --context <slug> --request-full-text <block_id> --format json` may expose full visible evidence text for inspection, including primary evidence, 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 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 auto-narrow over-wide citations and leaves removed refs uncovered. 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.
+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: "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.
 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. If semantic judgment is needed, load the full prepare payload with `context workflow show --payload prepare --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 --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 --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 - --plan` so only the affected action is revised, then rerun `context compile --draft <slug> --plan --prepare --format json` with no `--input`; it reloads the saved patched draft. 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. Do not copy raw text into Section detail merely to raise matched-term counts; there is no separate default `evidence-echo` warning, and preserved prose/bullets are valid only when they are active user-facing knowledge. 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`.
+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. Do not copy raw text merely to raise matched-term counts; there is no separate default `evidence-echo` warning, and preserved prose/bullets are valid only when they are active user-facing knowledge. 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 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> --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 --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.
@@ -81,6 +87,8 @@ Close (default mode only — skip entirely in `--plan` mode):
 
 `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.
 
+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.
+
 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).
 
 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.
@@ -96,7 +104,7 @@ context compile --draft billing-api --input - --plan --prepare --format json <<'
     {
       "op": "add",
       "kind": "description",
-      "body": "Billing API exposes invoice lookup and payment capture endpoints.",
+      "content": "Billing API exposes invoice lookup and payment capture endpoints.",
       "source_refs": ["src-1#billing-api L10-18@7a6f4c9d2e10"]
     }
   ]

package/plugin/commands/query.md

@@ -15,7 +15,7 @@ Naming convention:
 Use packaged `context:skill-context-query` end to end for `$ARGUMENTS`.
 
 This command is intentionally a thin entrypoint. Do not duplicate the query protocol here; the skill owns the hit/miss/select handling, supplemental lookup, citation, gap, and broad-query rules.
-The packaged skill also owns scoped orientation filters such as `context query --intent orientation --tag <tag>` / `--domain <slug>` and Node keyword lookup through `context query --intent node_search --query "<keyword>"`.
+The packaged skill also owns scoped orientation filters such as `context query --intent orientation --tag <tag>` / `--domain <slug>`, Node lookup through `context query --intent node_lookup --query "<keyword>"`, Node views through `context query --intent node_view --scope <slug>`, and Section search through `context query --intent section_search --scope <slug> --query "<keywords>"`.
 
 Never use direct workspace file tools for local knowledge. Workspace evidence must come from `context query` commands only; the packaged skill may run its documented `context query --intent orientation` or empty `context query` command before querying, but that output is not evidence.
 Never use Python, Node.js, shell scripts, `ls`, `find`, `rg`, `cat`, or similar ad-hoc commands to inspect `WORKSPACE_DIR`, `.context`, or `/tmp` workflow artifacts while answering a query.

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

@@ -31,7 +31,7 @@ Run the align workflow through the CLI-owned beta.8 payload chain: scan segments
 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.
+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|src-N:M>` (`src-N:M` means the M-th window under `source_alias` src-N from `--view windows`), `--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`. 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 Node classification gates in `references/gates.md`; their 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.
@@ -42,9 +42,11 @@ Use this only inside `/context:align`.
 
    If `align-segments.incremental.mode` is `incremental`, finalize is a delta merge. Submit only the Nodes and ownership supported by the current scanned sources; 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.
 
+   `nodes[].planned_sections` is the distinct set of Section kinds planned for that Node. List each kind at most once; do not copy `sections[].section_kind` one-for-one when a Node has multiple Sections of the same kind.
+
    For large finalize decisions, use `block_ownership_defaults[]` instead of enumerating every block. Each default names a `source_id` plus the same ownership fields as a block-level entry except `block_id`; the CLI expands it across that source's coverable blocks. Put only exceptions in `block_ownership[]`, which override defaults for their `block_id`. Keep the payload on stdin; do not generate temp JSON files just to list hundreds of ownership rows.
 
-   If a finalized Node is intentionally navigation-only or placeholder-only, set `planned_sections: []` and keep its relation/placeholder blocks as `context_only` or `ignored`; do not assign `owned` evidence or plan a description solely to keep the Node alive. Compile close will create an empty placeholder Node with no active Sections.
+   If a finalized Node is intentionally navigation-only or placeholder-only, set `planned_sections: []` and keep its relation/placeholder blocks as `context_only` or `ignored`; do not assign `owned` evidence or plan a description solely to keep the Node alive. This is the expected placeholder-domain shape when the graph/slug is useful but the source has no citation-worthy body content. Compile close will create an empty placeholder Node with no active Sections.
 
    Each `block_ownership[]` entry sets `ownership_role` to one of five values, and the **shape of the rest of the entry depends on the role**. Set `ownership_role` first and only include the fields that role requires; surplus fields trigger schema errors. The CLI returns `agent_hints[].correct_shape` with the canonical JSON skeleton on any role/field mismatch — reshape that entry to match it instead of guessing.
 

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

@@ -33,6 +33,7 @@ command. It does not hand-edit rendered knowledge.
 - 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.
 - 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> --reason "<reason>"`; otherwise inspect `context schema coverage-disposition`.
+- Materialized knowledge means either a CLI-written knowledge article, or an explicit no-write placeholder from align: `planned_sections: []` plus source/context/graph support. A compile skip action records reviewed evidence, but it does not by itself materialize an arbitrary finalized Node.
 - 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.
@@ -64,6 +65,7 @@ Close is one in-process command with one exit code:
 | 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. 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, `compile-close-finalized-node-missing-knowledge` | If the missing Node has real citation evidence, point the user at `/context:compile` for that Node. If it is intentionally navigation-only or placeholder-only, point the user at `/context:align` to make it explicit no-write with `planned_sections: []` and context-only/ignored relation or placeholder blocks. |
 | 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. |
 
@@ -99,6 +101,7 @@ Use stdout + stderr. The exit code selects the path via [Outcome routing](#outco
 For each error in the CLI's report, classify via [Outcome routing](#outcome-routing) and name the re-entry command in your report. Do NOT hand-edit rendered knowledge — that violates the CLI-sole-writer principle and masks the real upstream fix. Specifically:
 
 - Section / content issue → user re-runs `/context:compile` (draft loop produces new Section actions; the CLI re-writes).
+- `compile-close-finalized-node-missing-knowledge` → content Nodes go back through `/context:compile`; navigation-only or placeholder-only Nodes go back through `/context:align` so they become explicit no-write placeholders.
 - Structural issue → user runs `/context:align` (revise the plan; re-compile afterwards).
 - `dropped-source-reference` → user runs `/context:drop <id>` to finish drop cleanup.
 

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 `body` + `source_refs[]`,
+  kind via the priority chain, writes `content` + optional `summary` + `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.
@@ -26,13 +26,13 @@ Classify raw evidence for one Node into `add` / `skip` (and on refresh: `update`
 - Pick `kind` by the [Section Kind Canon](#section-kind-canon), also exposed as `section_kind_priority` in `context schema compile-draft`. First matching form wins. A `decision` needs at least two surfaced alternatives plus a reason; bare "we use X because Y" is `spec`. Reach `description` only after every more specific kind fails.
 - `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.
-- Use one `body` field for Section prose; it may be long and may contain fenced code. The CLI derives the internal short claim/detail split and rejects retired fields (`content`, `detail`, singular `source_ref`, quoted-evidence) with canonical repair hints — read those hints rather than memorising the blacklist. Omit optional fields when empty.
-- Preserve documentation/reference URL blocks. If a citation-eligible 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. If the URL block is only `context_only`, keep it as background and emit an ownership/structure challenge instead of citing it.
+- Use `content` for the Section text the reader should see. It may be long and may contain URLs, tables, commands, config, or code fences. Add `summary` only when content is long; omit it when content is short. The CLI rejects retired fields (`body`, `detail`, `raw`, singular `source_ref`, quoted-evidence) with canonical repair hints — read those hints rather than memorising the blacklist. Omit optional fields when empty.
+- Preserve documentation/reference URL blocks. If a citation-eligible raw block is primarily links (官网 / docs / reference / related links), create a small `description` Section such as "相关链接" and keep every URL in `content`; do not drop link-only evidence just because it is not prose. If the URL block is only `context_only`, keep it as background and emit an ownership/structure challenge instead of citing it.
 - `refers_to_nodes[]` only carries slugs present in the context's glossary, existing Sections, or the current align plan; never invent one.
 - `skip` is the honest default when raw adds nothing. Bare `skip` (no `source_refs[]`) is only for deterministic no-ops such as unchanged input or pure navigation. When a snippet was reviewed and intentionally not written, emit `skip` with `source_refs[]` from that snippet so semantic review can record `reviewed_no_write`.
 - 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: Node-facing summaries and user-facing draft explanations follow `NodeContext.generation_policy.language` when present; otherwise match the raw material. Draft `body` is source-bound: prefer the cited source language when it differs from the workspace language, and do not translate quoted English facts into Chinese just to satisfy workspace language. 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.
+- Output language: Node-facing summaries and user-facing draft explanations follow `NodeContext.generation_policy.language` when present; otherwise match the raw material. Draft `content` is source-bound: prefer the cited source language when it differs from the workspace language, and do not translate quoted English facts into Chinese just to satisfy workspace language. 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 — that ordering is the only stability concern the CLI cannot enforce. The CLI rejects unknown fields (timestamps, random ids, host/scratch paths) and canonicalises stored payloads; fixed rules and schema come from this skill, so only the current NodeContext should vary between repeated Node draft calls.
 
 ## Edge cases — consult references when:
@@ -62,11 +62,11 @@ Boundary recap (rules not captured by the schema enums):
 
 Canonical shape: `context schema compile-draft --format yaml` (or `--format json`). The CLI is the source of truth for fields, enums, and validation — do not memorise the shape from this file.
 
-Main-path ops are **`add`** and **`skip`**. A typical new Section action is `{ op: "add", kind: "<chain-picked>", body: "...", source_refs: ["src-1#... L10-14@..."] }`; never spell that as `add_section` because the `actions[]` array already names the target object. A bare skip is `{ op: "skip", reason: "..." }`; a reviewed-no-write skip carries `source_refs[]` from the cited snippet.
+Main-path ops are **`add`** and **`skip`**. A typical new Section action is `{ op: "add", kind: "<chain-picked>", content: "...", source_refs: ["src-1#... L10-14@..."] }`; never spell that as `add_section` because the `actions[]` array already names the target object. A bare skip is `{ op: "skip", reason: "..." }`; a reviewed-no-write skip carries `source_refs[]` from the cited snippet.
 
 `update` / `supersede` / `deprecate` ops live in [references/refresh-and-update.md](references/refresh-and-update.md). `structure_challenge` / `pending_ownership_challenge` ops live in [references/structural-challenges.md](references/structural-challenges.md). Do not emit them from the main path.
 
-`source_refs[]` values are copied verbatim from `raw_snippets[].source_ref`; a single citation is still a single-element array. When one Section summarises contiguous multi-block evidence, list only the source refs the `body` actually consumes. If the CLI reports `compile-source-refs-auto-narrowed`, it safely reduced an over-wide citation; removed refs are still uncovered, so add separate actions for distinct knowledge or leave them to an evidence-carrying `skip`. Set `rewrite: false` only when the raw wording is already clear and should be preserved. Preserving a cited prose/bullet list as the Section's user-facing content is allowed when that list is the actual knowledge; the anti-pattern is copying raw text into long detail only as traceability or lexical-score padding. For `example` Sections that cite command / config / code fences, include the relevant fenced block alongside the short summary in `body`.
+`source_refs[]` values are copied verbatim from `raw_snippets[].source_ref`; a single citation is still a single-element array. When one Section summarises contiguous multi-block evidence, list only the source refs the `content` actually consumes. If the CLI reports `compile-source-refs-auto-narrowed`, it safely reduced an over-wide citation; removed refs are still uncovered, so add separate actions for distinct knowledge or leave them to an evidence-carrying `skip`. Preserve raw wording in `content` when it is already clear. Preserving a cited prose/bullet list as the Section's user-facing content is allowed when that list is the actual knowledge; the anti-pattern is copying raw text only as traceability or lexical-score padding. For `example` Sections that cite command / config / code fences, include the relevant fenced block in `content`.
 
 ## Section Kind Canon
 
@@ -77,7 +77,7 @@ example -> comparison -> faq -> incident -> changelog ->
 decision -> spec -> warning -> principle -> description
 ```
 
-| kind | Use when | `body` should contain | Positive / negative boundary |
+| kind | Use when | `content` should contain | Positive / negative boundary |
 |---|---|---|---|
 | `example` | fenced code, config, or command sample | what the sample does plus the full snippet when useful | `<AppProvider />` sample or `bun run build`; plain "wrap with AppProvider" is `description` |
 | `comparison` | at least two subjects across at least two dimensions | compared subjects, dimensions, and table/matrix | `X vs Y vs Z` table; "two options have tradeoffs" is `description`; "choose X over Y" is `decision` |
@@ -182,17 +182,19 @@ For dense documents, group nearby snippets by their `block_locator_id` heading p
 
 For each classified snippet:
 
-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.
-   - `source_support` is a lexical diagnostic, not the final semantic judge. Do not stuff raw text into `body` just to raise matched-term counts.
-   - There is no separate default `evidence-echo` warning. Treat "echo" as an anti-pattern: raw copied into detail merely to show basis/evidence, while `source_ref` already provides traceability.
+1. Write `content` 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.
+2. Keep `content` 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.
+   - Default to raw wording. Only make semantic-preserving edits for formatting, typo fixes, casing, entity/alias consistency, or sentence cleanup. If the raw text is already clear, `content` should equal the raw text.
+   - `source_support` is a lexical diagnostic, not the final semantic judge. Do not stuff raw text into `content` just to raise matched-term counts.
+   - There is no separate default `evidence-echo` warning. Treat "echo" as an anti-pattern: raw copied only to show basis/evidence, while `source_ref` already provides traceability.
    - For `description` / `spec`, a concise summary plus the cited bullet list is acceptable when the bullets are the useful user-facing knowledge. It becomes echo only when the copied text is not meant to be read as active knowledge.
-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 only the source refs consumed by that Section body; the CLI verifies that the refs can collapse to one canonical citation token and may auto-narrow over-wide citations. 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.
+3. If `content` is longer than 200 characters, add `summary`. Summary is LLM-authored reader/query aid: one plain paragraph, no Markdown, about `content.length / 10`, minimum 10 characters, recommended maximum 120. The CLI warns on missing or odd summaries; it does not auto-generate them.
+4. If the cited block contains documentation/reference URLs, preserve them in `content`. Link-only blocks are still useful knowledge; use `kind: description` with a concise "相关链接" identity when no more specific kind applies.
+5. Omit `confidence` for ordinary confirmed claims. Assign `confidence` per the [Confidence rubric](#confidence-rubric) only when the evidence is not confirmed.
+6. Fill `refers_to_nodes[]` per [Glossary and refers_to_nodes](#glossary-and-refers_to_nodes).
+7. Cite evidence with `source_refs[]`, picking values from `raw_snippets[].source_ref`. When one Section summarizes contiguous multi-block evidence, list only the source refs consumed by that Section content; the CLI verifies that the refs can collapse to one canonical citation token and may auto-narrow over-wide citations. 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.
 
-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.
+Rendered knowledge starts with optional `c4a:summary`, then the active `content`. If `content` differs from the cited raw, the CLI may render a debug-only `c4a:raw` block for audit; agents must not emit `raw`.
 
 ### Step 4 — Emit the JSON
 
@@ -200,7 +202,7 @@ Emit one compile draft JSON document for the caller to pass to `context compile
 
 ### Step 5 — Self-verify
 
-- [ ] Every action's `target_node` equals `node.slug`, with a legal `kind × node.type` combination and `body` + `source_refs[]` only (no singular `source_ref`, no `content` / `detail`, no quoted-evidence or extractive-contract fields, no new terms absent from the cited raw). If not, return to **Step 2** for kind/mount-matrix issues, otherwise **Step 3**.
+- [ ] Every action's `target_node` equals `node.slug`, with a legal `kind × node.type` combination and `content` + optional `summary` + `source_refs[]` only (no singular `source_ref`, no `body` / `detail` / `raw`, no quoted-evidence or extractive-contract fields, no new terms absent from the cited raw). If not, return to **Step 2** for kind/mount-matrix issues, otherwise **Step 3**.
 - [ ] Every `description` action survives the [Description anti-abuse gates](#description-anti-abuse-gates). If not, **Step 2** to split or `skip`.
 - [ ] Coverage matches evidence density: dense raw with one broad action returns to **Step 2** unless remaining snippets are duplicates / navigation / placeholders / already covered. Citation-eligible URL blocks are either preserved or `skip`-with-evidence.
 - [ ] `skip` semantics: bare `skip` only for deterministic no-op (unchanged input or pure navigation); reviewed-no-write `skip` carries `source_refs[]` from the cited snippet. When raw adds nothing, exactly one `op: skip` with a reason — not `actions: []`. If not, **Step 3**.

package/plugin/skills/skill-compile-draft/references/refresh-and-update.md

@@ -41,24 +41,24 @@ When `existing.sections[]` is non-empty, every `section-N` id you read here is a
 
 ### `update` / `supersede.new` mechanics
 
-- `update` keeps the same `section-N` id; provide a new `body` (and optional new `source_refs[]`) but do not include `kind` unless the kind itself is changing.
-- `supersede.new` is a fresh Section; it needs `kind`, `body`, `source_refs[]`, and may carry `refers_to_nodes[]` and `confidence` per the same rules as `add`.
-- `deprecate` only needs `target_section_id` and `reason`. Do not pass `body` or `source_refs[]`.
+- `update` keeps the same `section-N` id; provide new `content` (optional `summary`, optional new `source_refs[]`) but do not include `kind` unless the kind itself is changing.
+- `supersede.new` is a fresh Section; it needs `kind`, `content`, `source_refs[]`, and may carry `summary`, `refers_to_nodes[]`, and `confidence` per the same rules as `add`.
+- `deprecate` only needs `target_section_id` and `reason`. Do not pass `content` or `source_refs[]`.
 
 ## Output schema (refresh ops)
 
 ```jsonc
-{
-  "actions": [
-    { "op": "update", "target_section_id": "section-3",
-      "body": "...",
-      "refers_to_nodes": null,
-      "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", "body": "...",
-               "refers_to_nodes": ["..."],
-               "source_refs": ["src-1#limits L30-34@9d1e2f3a4b5c"] } },
+	{
+	  "actions": [
+	    { "op": "update", "target_section_id": "section-3",
+	      "content": "...",
+	      "refers_to_nodes": null,
+	      "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": "...",
+	               "refers_to_nodes": ["..."],
+	               "source_refs": ["src-1#limits L30-34@9d1e2f3a4b5c"] } },
     { "op": "deprecate", "target_section_id": "section-2", "reason": "..." }
   ]
 }

package/plugin/skills/skill-context-query/SKILL.md

@@ -2,9 +2,9 @@
 name: skill-context-query
 description: >
   Packaged skill invoked by `/context:query`; not a user slash command. 
-  Uses structure-first strategy: explore Node structure via node_search/orientation first,
-  then narrow to specific Nodes, then explore relationships. Semantic queries are secondary
-  and only when structure queries cannot find the target Node. Always cite Node slug and Section id.
+  Uses structure-first strategy: inspect orientation, resolve unknown Nodes with node_lookup,
+  open known Nodes with node_view, then query Section details with section_search. Always
+  cite Node slug and Section id.
   Activates when `/context:query` is invoked or when an agent needs to
   answer a question using local Context workspace knowledge with citations.
 tools:
@@ -19,7 +19,7 @@ of local knowledge; never read workspace files directly.
 
 ## TL;DR — Non-negotiables
 
-- **Structure first**: When problem is vague, don't do semantic search—explore Node structure via `node_search` or `orientation` to let user choose which Node to focus on.
+- **Structure first**: When problem is vague, don't do semantic search; inspect `orientation`, use `node_lookup` only to find a slug, and use `node_view` to open a known Node.
 - **CLI only**: Use only `context query` output as evidence. Never Read/Glob/Grep/Write workspace files.
 - **Route by intent**: Classify problem intent (vague / clear Node / relationship / detail) and choose the right command; see Query Route table below.
 - **Orientation is navigation**: `context query --intent orientation` returns a budgeted `[Slug Map]` plus optional `[Summary]` hints for scope choice only; it is not direct answer evidence.
@@ -42,14 +42,15 @@ returned row as a small evidence card.
 | `refers_to_nodes` | Optional supplemental anchors when present |
 | `slug` | Candidate handle when the output is asking you to choose a Node |
 | `message` | Miss, broad-query, blocked, or narrowing guidance |
+| `visibility` / `visible:` footer | Completeness signal for `node_view`; when `complete=true` / `visible: complete`, the shown Node Sections are exhaustive and there is no pagination |
 
 Supplemental context can come from:
 
 ```text
-context query --intent node_search --scope <slug>
+context query --intent node_view --scope <slug>
 context query --intent impact_analysis --scope <slug>
-context query --intent node_search --refers-to <slug>
-context query --intent description_search --scope <slug> --query "<keywords>"
+context query --intent node_view --refers-to <slug>
+context query --intent section_search --scope <slug> --query "<keywords>"
 ```
 
 ## Query Route Decision Table
@@ -58,10 +59,10 @@ Choose the `context query` command based on problem intent. **Structure queries
 
 | Problem intent | Primary command | When to use |
 |---|---|---|
-| **Vague question, no Node named** User asks "what is X" / "what are the X types" | `context query --intent orientation` or `context query --intent node_search --query "<keyword>"` | User unsure which Node to focus on; show structure first |
-| **Node explicitly named** User mentions a specific service/system | `context query --intent node_search --scope <slug>` | User wants to explore a specific known Node |
+| **Vague question, no Node named** User asks "what is X" / "what are the X types" | `context query --intent orientation` or `context query --intent node_lookup --query "<keyword>"` | User unsure which Node to focus on; show structure first |
+| **Node explicitly named** User mentions a specific service/system | `context query --intent node_view --scope <slug>` | User wants to open a specific known Node |
 | **Relationship / impact** User asks what depends on X / impact of changing X | `context query --intent impact_analysis --scope <slug>` | User asks about how a Node connects to others |
-| **Detail within known scope** (only after Node chosen) User asks for specific feature/behavior within chosen Node | `context query --intent description_search --scope <slug> --query "<detail>"` | User wants specific detail within an already-chosen Node |
+| **Detail within known scope** (only after Node chosen) User asks for specific feature/behavior within chosen Node | `context query --intent section_search --scope <slug> --query "<detail>"` | User wants specific detail within an already-chosen Node |
 | **Very specific fact** (fallback, rarely needed) User asks for exact implementation location | `context query "$ARGUMENTS"` | Semantic fallback when structure queries don't suffice |
 | **Archive / reconciliation** User asks "find duplicates" / "check coverage" | `context query --intent recall --profile <reconcile-dedupe\|reconcile-support\|reconcile-refresh> --query "..."` | Only when user explicitly asks for audit/reconciliation |
 
@@ -73,13 +74,13 @@ Choose the `context query` command based on problem intent. **Structure queries
 - Text output targets about 2000 tokens total. It prints `[Slug Map]` first, then `[Summary]`.
 - `[Slug Map]` uses finalized structure relationships and is for choosing the next `--scope <slug>`. If the workspace is too large, deeper layers are folded first.
 - `[Summary]` is truncated before the map. If output is still over budget, the command prints a continuation note. Drill down with scoped queries; there is no page-token pagination.
-- Use `context query --intent node_search --scope <slug>` for a Node overview, or `context query --intent description_search --scope <slug> --query "<keywords>"` for details inside that Node.
+- Use `context query --intent node_view --scope <slug>` for a Node overview, or `context query --intent section_search --scope <slug> --query "<keywords>"` for details inside that Node.
 - Use `context query --intent orientation --tag <tag>` or `context query --intent orientation --domain <slug>` to reduce the map before choosing a scope.
 - When `slug` and `title` are equivalent after normalization (for example `payment-api` and `Payment API`), text output shows only the slug.
 
 ## BM25 Search Strategy
 
-When using `description_search`, `recall`, or `node_search --query`, the CLI uses BM25 (keyword-based, not embedding-based) for matching. BM25 requires explicit keyword coverage, so queries must be precise:
+When using `section_search`, `recall`, or `node_lookup`, the CLI uses BM25 (keyword-based, not embedding-based) for matching. BM25 requires explicit keyword coverage, so queries must be precise:
 
 - **Mix bilingual keywords**: Include both Chinese and English terms when querying—e.g., `"<chinese-term> <english-equivalent>"`, `"<product-name> <alternate-name>"`
 - **Include synonyms & aliases**: BM25 is keyword-literal, so if your query doesn't match Section content exactly, try related terms
@@ -87,12 +88,12 @@ When using `description_search`, `recall`, or `node_search --query`, the CLI use
 - **Scope to reduce noise**: Use `--scope <slug>` to focus on a single Node; broad queries may be blocked or produce low-quality matches
 
 Query intents that use BM25:
-- `context query --intent node_search --query "<short-keyword>"` — find candidate Nodes from slug, title, summary, aliases, and tags when direct slug/title/alias matching does not resolve the query
-- `context query --intent description_search --scope <slug> --query "<keywords>"` — find Section details using keyword matching within a known Node
+- `context query --intent node_lookup --query "<short-keyword>"` — find candidate Nodes from slug, title, summary, aliases, and tags when direct slug/title/alias matching does not resolve the query
+- `context query --intent section_search --scope <slug> --query "<keywords>"` — find Section details using keyword matching within a known Node
 - `context query --intent recall --profile <profile> --query "<keywords>"` — archive audit and reconciliation queries using keyword matching
 
 Do NOT use BM25 strategy for:
-- `context query --intent node_search --scope <slug>` or `--node <slug>` — uses structure, not keywords
+- `context query --intent node_view --scope <slug>` or `--node <slug>` — uses structure, not keywords
 - `context query --intent orientation` — uses structure, not keywords  
 - `context query --intent impact_analysis` — uses structure, not keywords
 
@@ -135,11 +136,11 @@ Determine what the user is trying to learn. Choose the appropriate command from
 - **Vague problem** — user unsure which Node to focus on
   - Indicators: asks "what is X", "what are the X types", "how to understand X", or question without Node anchor
   - Action: Run `context query --intent orientation` to show available Nodes and structure; then pick a Node or ask for narrower scope
-  - **Note**: `node_search` uses structure not BM25; orientation always works regardless of workspace content
+  - **Note**: `node_lookup` resolves unknown Node names; `node_view` opens known Node structure; orientation always works regardless of workspace content
 
 - **Node explicitly named** — user mentions a specific service/system/concept
   - Indicators: user names a specific Node or system, "tell me about X", "show me X"
-  - Action: Run `context query --intent node_search --scope <slug>` to explore that Node
+  - Action: Run `context query --intent node_view --scope <slug>` to explore that Node
 
 - **Relationship / impact** — user asks how Nodes relate or what breaks if X changes
   - Indicators: "what depends on X", "impact of X", "relationship between X and Y"
@@ -147,7 +148,7 @@ Determine what the user is trying to learn. Choose the appropriate command from
 
 - **Detail within known scope** — user already chose a Node, now asking for specific detail
   - Indicators: (comes after Node is selected) user asks "how does X handle [feature]", "what features does X support"
-  - Action: Run `context query --intent description_search --scope <slug> --query "<detail-keywords>"` — use BM25 keywords for precise matching
+  - Action: Run `context query --intent section_search --scope <slug> --query "<detail-keywords>"` — use BM25 keywords for precise matching
 
 - **Archive / reconciliation** — user explicitly asks for dedup/audit/coverage
   - Indicators: "find duplicates", "check source coverage"
@@ -170,6 +171,7 @@ Run the command from Step 1. Read the CLI output carefully.
   - Only suggest `/context:align` + `/context:compile` if user wants it compiled
 - ⚠️ **`truncated`** (entries cut off) → Mark answer as "non-exhaustive"
   - Proceed to Step 3; ask for narrowing only if user needs complete inventory
+- ✓ **`node_view` says `visible: complete` / `visibility.complete=true`** → Do not run `section_search` merely to check completeness; use `section_search` only when you need keyword narrowing or ranking inside the Node
 - ✓ **Entries returned** → Proceed to Step 3
 
 ## Step 3: Compose answer from returned structure
@@ -202,7 +204,7 @@ To dive deeper into any system, ask me for more details or let me know which Nod
 ```
 
 **Why show structure first?** Even when you know keywords, structure queries reveal the full landscape.
-Agents should explore Nodes first, then use description_search for details within a chosen Node.
+Agents should explore Nodes first, then use section_search for details within a chosen Node.
 
 ## Step 4: Explore further (if user requests)
 
@@ -211,10 +213,10 @@ Once Node scope is clear, user may ask for deeper exploration.
 **Supplemental query triggers:**
 
 - User asks about Node's relationships/dependencies → `context query --intent impact_analysis --scope <slug>`
-- User asks for full Node content after partial answer → `context query --intent node_search --scope <slug>`
-- User asks specific detail within chosen Node → `context query --intent description_search --scope <slug> --query "<keywords>"` 
+- User asks for full Node content after partial answer → `context query --intent node_view --scope <slug>`
+- User asks specific detail within chosen Node → `context query --intent section_search --scope <slug> --query "<keywords>"` 
   - **Use BM25 strategy**: mix Chinese and English keywords for better matching (e.g., mix synonym or translated forms of the search term)
-- User names another Node in `refers_to_nodes` and asks about its relationship → `context query --intent node_search --refers-to <slug>`
+- User names another Node in `refers_to_nodes` and asks about its relationship → `context query --intent node_view --refers-to <slug>`
 
 **BM25 tips for supplemental queries:**
 - When searching for a detail, include both native and translated forms of terms

package/plugin/skills/skill-semantic-reconcile/SKILL.md

@@ -26,6 +26,7 @@ only; the CLI performs every write.
 - Every `merge_update` / `supersede` / `keep_separate` / `split_then_reanchor` write must be supported by **one** valid `proposed.source_ref` covering the final content. Preserve raw evidence's domain terms, numbers, code literals, and named entities; do not introduce acronyms, translations, or aliases the cited evidence does not define. Do not cite a title, `Relations` / `Parent` / `Children` / `Related` navigation line as the sole support for a substantive claim.
 - Unresolved conflicts and low-confidence support → `action: ask_user`. Never expose `src-N`, Section ids, or source refs as the user-facing choice; they belong only in the structured payload.
 - `decided_by: user` only after a specific recent user message answering the specific question for the specific item. Auto mode, blanket "continue," and long-running permissions are **not** user confirmation. Never mark yourself.
+- `decided_by: delegated_agent` is CLI-owned. Do not emit it manually; it appears only when the current compile workflow was created with user-authorized `--delegated`.
 - `omit` is never an automatic decision. If an item looks redundant or low-value, follow the Scope Review pass in [references/scope-review-and-omit.md](references/scope-review-and-omit.md); only a user-confirmed no-write outcome may become `action: omit` with `decided_by: user`.
 - `apply` consumes the ready review artifact for the current workflow scope: run plain `context reconcile apply`. There is no input file; do not extract `apply_document` with scripts.
 - Stable output: preserve prepared item order; the CLI rejects unknown fields (timestamps, random ids, storage paths, host absolute paths) and canonicalises stored payloads. Fixed rules and schema come from this skill; only the prepared context varies between repeated review calls.
@@ -37,7 +38,7 @@ only; the CLI performs every write.
 | `prepare.mode` is `drop` or `refresh` (covers `remove_unsupported` mode semantics, `reanchor`, `split_then_reanchor`) | [references/mode-semantics.md](references/mode-semantics.md) |
 | review returned `support_confirmation`, `omit_confirmation`, `scope_review_required`, or any `ask_user` you need to upgrade to an executable decision | [references/user-confirmation.md](references/user-confirmation.md) |
 | review returned `agent_hints[]` with `code: "context-only-leakage-high"` | [references/leakage-and-ownership.md](references/leakage-and-ownership.md) |
-| items carry `temporal_prior` / `source_captured_at` / `temporal_disposition`, `source_support.evidence_block_*`, `proposed.detail`, or review returned `example_detail_preservation` | [references/temporal-and-evidence.md](references/temporal-and-evidence.md) |
+| items carry `temporal_prior` / `source_captured_at` / `temporal_disposition`, `source_support.evidence_block_*`, or prepared long `proposed.content` / `proposed.summary` | [references/temporal-and-evidence.md](references/temporal-and-evidence.md) |
 | considering `action: omit`, or items look redundant / low-value / scope-wrong | [references/scope-review-and-omit.md](references/scope-review-and-omit.md) |
 
 If none of the above hold, you are on this skill's main path: refresh/drop/non-compile reconcile, or compile scope-review fallback with no special review-time signals. Ordinary compile prepare relation/support judgment remains `skill-compile-judge`.
@@ -82,9 +83,9 @@ Edge-case actions (`reanchor`, `split_then_reanchor`, `remove_unsupported`, `omi
 | action | Required fields | Validation |
 |---|---|---|
 | `duplicate_skip` | `target` | Exact duplicate or already-applied no-op only. |
-| `merge_update` | `target`, `proposed.content`, `proposed.source_ref`, `proposed.detail` when present in prepare | Final content must be supported by cited evidence; `proposed.kind`, when present, must match target kind. |
-| `supersede` | `target`, `proposed.kind`, `proposed.content`, `proposed.source_ref`, `proposed.detail` when present in prepare | New Section claim must be supported by cited evidence. |
-| `keep_separate` | `target`, `proposed.kind`, `proposed.content`, `proposed.source_ref`, `proposed.detail` when present in prepare | New orthogonal claim must be supported by cited evidence. Weak support is allowed only after explicit user confirmation (`decided_by: user`). |
+| `merge_update` | `target`, `proposed.content`, `proposed.source_ref`, `proposed.summary` when present in prepare | Final content must be supported by cited evidence; `proposed.kind`, when present, must match target kind. |
+| `supersede` | `target`, `proposed.kind`, `proposed.content`, `proposed.source_ref`, `proposed.summary` when present in prepare | New Section claim must be supported by cited evidence. |
+| `keep_separate` | `target`, `proposed.kind`, `proposed.content`, `proposed.source_ref`, `proposed.summary` when present in prepare | New orthogonal claim must be supported by cited evidence. Weak support is allowed only after explicit user confirmation (`decided_by: user`). |
 | `ask_user` | `user_confirmation.required: true` | Use when business meaning or support cannot be decided from prepared evidence. |
 
 Source-support gate: if the proposed claim cannot honestly point at one range covering every sentence, split the claim or ask the user instead of forcing it into an incorrect `source_ref`. If a useful reader summary would combine adjacent evidence, first broaden `proposed.source_ref` so the cited range covers every sentence; if that broadening would require unrelated content, split. See [references/temporal-and-evidence.md](references/temporal-and-evidence.md) for evidence-block repair hints.

package/plugin/skills/skill-semantic-reconcile/references/mode-semantics.md

@@ -29,7 +29,7 @@ These appear only in drop prepare items. They handle "a Section that the drop wo
 | Item shape | Decision |
 |---|---|
 | Drop item still **fully** supported by surviving source | `reanchor` + `reanchor` — repoint `proposed.source_ref` at the surviving evidence, keep target unchanged. |
-| Drop item **partly** supported (one fact survives, another does not) | `reanchor` + `split_then_reanchor` — split into `proposed.sections[]`, each with independent `kind` / `content` / `source_ref` / `detail`. |
+| Drop item **partly** supported (one fact survives, another does not) | `reanchor` + `split_then_reanchor` — split into `proposed.sections[]`, each with independent `kind` / `content` / optional `summary` / `source_ref`. |
 | No surviving support | `unsupported` + `remove_unsupported` (physical remove on drop apply). |
 
 `split_then_reanchor` requires each split Section to be independently supported by its own cited evidence. The CLI rejects splits where any sub-Section's `source_ref` does not cover its `content`.