@c4a/context-cli 0.5.39 → 0.5.41-beta.5

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

@@ -1,6 +1,6 @@
 # Node Classification Gates
 
-Use these gates before every candidate batch and immediately before `align-structure-decision`.
+Use these gates before every candidate batch and before authoring the align payload requested by `next_action.input_schema`.
 Align owns Node type, tag, graph, planned Section, and ownership classification. It does **not** write Section prose.
 
 ## Node Type Order
@@ -38,7 +38,15 @@ After choosing `node_type`, choose the title to fit that type:
 
 Scope/process words in a source title are warning signals when proposed as an Entity title, not hard classification rules. Re-check the type/title when a proposed Entity title contains words such as "方案", "架构", "体系", "演练", "流程", "策略", "能力", "机制", "framework", "architecture", "system", "strategy", "process", or "drill". Keep the wording only when evidence shows it is the formal name of a concrete object or an atomic term.
 
-Relation-only sources should not force title copying. If a relation block has resolvable children and the graph node is useful, prefer an explicit Domain placeholder with `planned_sections: []`. If the source names only an atomic concept such as SSR/CSR, prefer a term Entity title such as "SSR" or "CSR" instead of "SSR 方案" / "CSR 方案".
+Do not promote broad architecture/system/方案 content to `domain` just because it sounds like a scope. When the source has writable Sections but no resolvable current/existing child Nodes, use an Entity such as `[system]` or `[application]` and put the architecture facts in Sections. Use `domain` only when it groups child Nodes through `domain_gate.child_refs`.
+
+Relation-only sources should not force title copying or dangling graph edges. Decide placeholder handling in this order:
+
+1. If resolved current/existing child Nodes make the page a real grouping scope, preserve it as a no-write Domain.
+2. If an explicit user-facing retrieval need or graph need makes the source/page identity valuable, and the title names an atomic concept or concrete object, preserve it as a no-write Entity with root-level `planned_sections: []`. This priority still applies when all child refs are unresolved/deferred; keep those target hints pending rather than writing dangling graph refs.
+3. Otherwise, skip navigation-only / placeholder-only material and classify its coverable blocks, usually as `ignored`.
+
+Do not put `planned_sections` inside `domain_gate`. A kept placeholder needs support: `context_only` block(s) with `visible_to`, owned/shared evidence, or finalized graph support. `ignored` blocks only dispose unused material and do not support close materialization by themselves. For Domain placeholders, write only resolved current/existing children in `domain_gate.child_refs`; if all children are unresolved/deferred relation clues, use `child_refs: []` and keep those target hints in pending relation refs. If the source names only an atomic concept and that term is useful on its own, prefer a concise term Entity title without scope/process suffixes.
 
 ## Entity Tag Rules
 
@@ -105,7 +113,7 @@ Use `node_type: domain` only for a scope that groups child Nodes. Fill:
 | `child_refs[]` | Candidate ids, local refs, or final slugs for children in the scope. |
 | `grouping_reason` | Why these children belong together under this domain. |
 
-If a domain has no resolvable child refs, no clear grouping reason, or only one same-file child without a broader scope, emit an Entity instead.
+If a domain has no resolvable child refs, no clear grouping reason, or only one same-file child without a broader scope, do not emit a Domain. For navigation-only / placeholder-only sources with only deferred children, skip the Node after ruling out standalone retrieval or graph value for an atomic-term or concrete Entity; still classify that source's coverable blocks with a source-wide `ownership_groups[]` rule, usually `ignored` for pure placeholders. Emit an Entity only when evidence names an atomic term or concrete object and choose its Entity tag yourself. The CLI rejects invalid Domain gates; it does not auto-downgrade a Domain or choose fallback tags.
 
 Scope-name titles such as "X 业务域", "Y 领域", "business domain", or "technical area" are a warning sign when proposed as Entity. Keep them as Entity only when the subject is an atomic term or concrete object; otherwise use Domain with `domain_gate.child_refs`.
 
@@ -146,7 +154,7 @@ Each source must include `rationale` when inferred and at least one of `evidence
 
 ## Final Reflection
 
-- Entity cannot pick a legal tag, or depends on its upstream title to make sense -> downgrade to Section or change type.
-- Action only supports one Section -> downgrade to Section. The discriminator is scale, not the presence of "step" words.
+- Entity cannot pick a legal tag, or depends on its upstream title to make sense -> write it as a Section under the upstream Node or change type before submit.
+- Action only supports one Section -> write it as a Section instead of an Action. The discriminator is scale, not the presence of "step" words.
 - Action "steps" are parallel options/configs -> route to Entity `comparison` / `spec` / `description`.
 - Domain has no children -> delete it or merge it into a larger Domain.

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

@@ -34,8 +34,8 @@ command. It does not hand-edit rendered knowledge.
 - 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 warnings are CLI-owned diagnostics. `ready_with_debt` means close succeeded and unresolved coverage remains visible. For severely low coverage, recommend one `--cover-uncovered-only` repair pass unless the user explicitly accepts the debt; otherwise report the warning and follow returned coverage view commands / `available_actions[]` only if the user chooses a repair or skip round.
 - Coverage and engagement denominators count primary citable content evidence. URL/reference-only, marker, frontmatter, embed, navigation, and context-only evidence is excluded or bucketed as non-blocking bookkeeping by the CLI.
-- User-accepted hard-fact risk is carried as `review_debt`; report it from close/status when present, but do not treat review-debt count as a close failure.
 - 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.
+- If close is blocked only because finalized block ownership/support is wrong, use `context compile repair ownership --input - --format json` with `align.ownership-patch.v2`. This keeps the active compile workflow and completed node progress. Do not abandon compile just to run `context align patch ownership`.
 - 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 `context 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.
@@ -67,7 +67,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 severely low coverage, recommend the CLI-returned `--cover-uncovered-only` repair command before final acceptance; for other coverage warnings, surface returned coverage view commands / `available_actions[]` instead of inventing a local decision matrix. |
 | 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, `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 and only block ownership/support is wrong, use `context compile repair ownership --input - --format json` to make support explicit with `context_only` + `visible_to` or owned/shared evidence. `ignored` blocks do not support the placeholder by themselves. If the Node itself is structurally wrong, route back to `/context:align` after the active compile workflow is resolved. |
 | 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. |
 
@@ -103,7 +103,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.
+- `compile-close-finalized-node-missing-knowledge` → content Nodes go back through `/context:compile`; ownership-only placeholder support fixes use `context compile repair ownership --input - --format json`; structural Node changes still go through `/context:align` after the active compile workflow is resolved.
 - 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,8 @@ 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` + optional `summary` + `source_block_ids[]`,
+  kind via the priority chain, writes source-bound actions with `kind`,
+  optional `summary` / `content`, and `source_block_ids[]`,
   and emits a compile draft JSON document for the caller to submit to the current envelope's
   `next_action.command`.
   Activates when `/context:compile` iterates across the confirmed align plan.
@@ -20,22 +21,23 @@ Classify raw evidence for one Node into `add` / `skip` (and on refresh: `update`
 
 - One Node per invocation — `node_slug` MUST equal `node.slug`; no cross-Node writes. Finish the current Node's draft quality checks before the caller moves to another Node's review/apply loop.
 - Agent emits JSON only; no markdown, no direct workspace file writes. The caller submits the JSON to the current envelope's `next_action.command`; the CLI validates and stores workflow payloads.
-- Evidence boundary: treat the CLI-provided NodeContext and evidence views as complete. Cite only block ids surfaced as citation-eligible in `source-refs-index` `items[]`, `citable_source_refs[]`, or `raw_snippet_indexes.citation_eligible`; treat `supporting_context_refs[]`, `context_only`, and secondary-shared snippets as background. `request_full_text` may expose visible text for inspection through the narrow text view (`context compile context <slug> --request-full-text <block_id> --view text --format json`), and it does not change citation eligibility. If supporting/context-only evidence is needed as a citation, emit `pending_ownership_challenge` or `structure_challenge` — see [references/structural-challenges.md](references/structural-challenges.md). Never `grep` / `sed` / `jq` / `cat` / `head` raw `--format json` stdout or workflow scratch files in `/tmp` or `.context/.cache/`; use semantic views and follow returned `next_command` / `how_to_explore[]`. For write commands that take `--payload-digest`, omit the flag unless the CLI explicitly asks for a stale guard.
+- Evidence boundary: treat the CLI-provided NodeContext and evidence views as complete. Cite only block ids surfaced as citation-eligible in `source-refs-index` `items[]`, `citable_source_refs[]`, or `raw_snippet_indexes.citation_eligible`; treat `supporting_context_refs[]`, `context_only`, and secondary-shared snippets as background. `request_full_text` may expose visible text for inspection through the narrow text view (`context compile context <slug> --request-full-text <block_id> --view text --format json`), and it does not change citation eligibility. If supporting/context-only evidence is needed as a citation, emit `pending_ownership_challenge` or `structure_challenge` — see [references/structural-challenges.md](references/structural-challenges.md). Never `grep` / `sed` / `jq` / `cat` / `head` raw `--format json` stdout or workflow scratch files in `/tmp` or `.context/.cache/`; use semantic views and follow returned `next_command` / `how_to_explore[]`. For write commands that take `--payload-digest`, omit the flag unless the CLI explicitly asks for a stale guard. When an explicit digest is needed, use `context workflow show --payload <name> --digest-only --format text`; do not parse JSON stdout to recover it.
 - Actions are candidate write actions, not final semantic decisions; `context reconcile prepare` re-derives near-duplicate / conflict / merge relations from `candidates[]` on its own. Op naming is scoped by schema: compile-draft `actions[]` already targets Sections, so Section lifecycle ops are verb-only (`add`, `update`, `supersede`, `deprecate`, `skip`). Do not use align-style names such as `add_section`, `write_section`, or `propose_section`.
-- Source support passing is not completion. Before emitting, estimate coverage from the provided `raw_snippets[]`: if there are 3+ citation-eligible snippets, a one-action draft is valid only when the later snippets are duplicates, navigation, placeholders, or continuations of the same fact. Small dense docs still need multiple actions when later snippets state distinct capabilities, constraints, examples, risks, FAQ, or usage notes. Large manuals/design docs should compile to several orthogonal actions in the same draft. Do not switch into "speed mode" because the first action validates; coverage is part of the draft task.
-- Pick `kind` from the CLI's `context schema compile-draft` contract, especially `section_kind_priority` and the mount matrix. Treat kind precision as a drafting quality preference, not a reason to loop forever when the CLI accepts the write. A `decision` needs at least two surfaced alternatives plus a reason; bare "we use X because Y" is usually `spec`. Reach `description` only after every more specific kind fails.
+- Citation validation passing is not completion. Before emitting, estimate coverage from the provided `raw_snippets[]`: if there are 3+ citation-eligible snippets, a one-action draft is valid only when the later snippets are duplicates, navigation, placeholders, or continuations of the same fact. Small dense docs still need multiple actions when later snippets state distinct capabilities, constraints, examples, risks, FAQ, or usage notes. Large manuals/design docs should compile to several orthogonal actions in the same draft. Do not switch into "speed mode" because the first action validates; coverage is part of the draft task.
+- Pick `kind` from the CLI's `context schema compile-draft` contract, especially `section_kind_priority` and the mount matrix. Treat kind precision as a drafting quality preference, not a reason to loop forever when the CLI accepts the write. A `decision` fits when the source explicitly records a choice, tradeoff, adopted path, or policy conclusion with a reason; multiple surfaced alternatives are a strong signal but not required. Bare rules or checks without a recorded choice are usually `spec`. Reach `description` only after every more specific kind fails.
 - `node.planned_sections[]` is an align-time scaffold hint, not a hard completion gate. Prefer a planned kind when the evidence fits; if a source-backed stronger kind differs, emit it and let the CLI warning guide review.
 - `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_block_ids[]` from `source-refs-index` `items[].block_id` or `citable_source_refs[].block_id`; the CLI expands it to canonical `source_refs[]` before saving. Use explicit `source_refs[]` only when the CLI gives no block id for the needed citation. Never mix both fields in one action, fabricate ids, or cite navigation-only blocks as evidence for a content Section.
-- For large source-ref views, prefer the returned `source_refs_index_command` / `source_refs_command` / `--view source-refs-index` when you only need block ids; open `source_refs_detail_command` only when you need quote preview or explicit `source_refs[]`.
-- 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` for long content or when it helps readers/query output; omit it when content is short. Summary quality checks are warning hints only, not schema or evidence failures. 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 user-facing Markdown structure from cited raw when it carries meaning: inline code/code fences, Markdown links and URLs, blockquotes, list nesting, tables, and emphasis around key terms. Summary remains plain text; content may keep raw Markdown when that is the clearest faithful Section text. If the CLI later reports URL, example, section-kind, or summary-style issues as advisory/debt, do not patch solely for those unless the cited source meaning is materially lost.
-- Preserve literals surfaced by the CLI when they are part of the user-facing knowledge. When source-refs or scaffold output lists `required_preserved_literals[]`, keep source-backed URL, code identifier, `source_ref`, or `block_id` literals visible in the relevant `content`, `summary`, skip reason, or repair challenge when doing so carries meaning. Do not rely on memorized URL rules; let CLI literal fields and citation diagnostics define what matters, and treat URL/style preservation warnings as advisory unless the next action is blocking.
-- `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 evidence) is only for deterministic no-ops such as unchanged input, pure navigation, or context-only/background snippets. When a citation-eligible snippet was reviewed and intentionally not written, emit `skip` with `source_block_ids[]` from `source-refs-index` `items[].block_id` or `citable_source_refs[].block_id` so semantic review can record `reviewed_no_write`. Never attach `context_only` / supporting block ids to skip; raise a challenge if they should become citation evidence.
-- 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.
+- Every write action cites raw via `source_block_ids[]` from `source-refs-index` `items[].block_id` or `citable_source_refs[].block_id`; the CLI expands it to canonical `source_refs[]` before saving. Use explicit `source_refs[]` only when the CLI gives no block id for the needed citation. Multiple ids/refs in one action must be one contiguous citation-eligible run from the same source; split around any intervening citation-eligible block used by another action. Never mix both fields in one action, fabricate ids, or cite navigation-only blocks as evidence for a content Section.
+- For large source-ref views, prefer the returned `source_refs_index_command` / `source_refs_command` / `--view source-refs-index` when you only need block ids; open `source_refs_detail_command` only when you need quote preview or explicit `source_refs[]`. Treat `--draft-scaffold` as a compact action skeleton for large Nodes; use returned full-text/detail commands for only the blocks an action needs.
+- `content` is optional and omitted by default on source-backed writes. If the cited raw block is already the right reader-visible text, cite it with `source_block_ids[]` / `source_refs[]` and let the CLI mirror raw into content. Write `content` only for an intentional source-faithful reader-surface rewrite, such as translation, structural reorganization, or preserving a table, list, command, config, or code fence that would otherwise be unclear. Add `summary` when it helps readers/query output; summary is recall text, not evidence. 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 user-facing Markdown structure from cited raw when it carries meaning: inline code/code fences, Markdown links and URLs, blockquotes, list nesting, tables, and emphasis around key terms. Summary remains plain text; content may keep raw Markdown when that is the clearest faithful Section text. Do not patch solely for style cleanup unless the cited source meaning is materially lost.
+- Do not synthesize a user-facing prefix by concatenating `heading_path` values (for example, `Parent - Child:`) when that prefix is not in the cited raw. Use headings only to choose grouping and framing; if a heading's wording is itself useful, keep it as sourced content only when it appears in the cited block text.
+- Preserve source-backed URLs, code identifiers, `source_ref`, or `block_id` literals when they are part of the reader-facing knowledge or a repair challenge. Do not rely on memorized URL rules, and do not add literals only for scoring or traceability.
+- `refers_to_nodes[]` only carries known slugs. Prefer already materialized or compiled target Nodes; in first-pass compile, skip a slug that is only known from the current align plan and not yet materialized unless the CLI explicitly surfaces it as safe or needed. Never invent a slug.
+- `skip` is the honest default when raw adds nothing. Bare `skip` (no evidence) is only for deterministic no-ops such as unchanged input, pure navigation, or context-only/background snippets; empty `source_block_ids[]` / `source_refs[]` on skip is treated as bare skip. When a citation-eligible snippet was reviewed and intentionally not written, emit `skip` with `source_block_ids[]` from `source-refs-index` `items[].block_id` or `citable_source_refs[].block_id` so semantic review can record `reviewed_no_write`. Never attach `context_only` / supporting block ids to skip; raise a challenge if they should become citation evidence.
+- 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; narrow context-only navigation/reference blocks may be rendered later as a `References` auto-block, while active Sections still 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. Section `summary` may follow either the workspace language or the source-bound `content` language; do not rewrite it only to switch languages. 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.
+- Output language: Node-facing summaries and user-facing draft explanations follow `NodeContext.generation_policy.language` when present; otherwise match the raw material. Section `summary` is reader/query aid: write Chinese summary prose for clearly Chinese cited evidence or mirrored content; English summary prose is acceptable for clearly English evidence; mixed technical evidence may keep concise mixed-language terms. Do not patch an already clear stored summary solely to switch language, but do not draft English prose summaries for Chinese evidence. 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:
@@ -65,7 +67,7 @@ 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>", content: "...", source_block_ids: ["<block_id>"] }`; 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_block_ids[]` only from citation-eligible `source-refs-index` `items[].block_id` or `citable_source_refs[].block_id`.
+Main-path ops are **`add`** and **`skip`**. A typical new Section action is `{ op: "add", kind: "<chain-picked>", summary: "...", source_block_ids: ["<block_id>"] }`; omit `content` unless this action intentionally rewrites the cited raw for the reader. 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_block_ids[]` only from citation-eligible `source-refs-index` `items[].block_id` or `citable_source_refs[].block_id`.
 
 Minimal valid draft envelope:
 
@@ -79,7 +81,7 @@ Minimal valid draft envelope:
 
 `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_block_ids[]` is a mechanical shorthand over the same citation-eligible evidence; a single citation is still a single-element array. When one Section summarises contiguous multi-block evidence, list only the block ids the `content` actually consumes. If using explicit `source_refs[]`, copy them verbatim from `raw_snippets[].source_ref`. 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`.
+`source_block_ids[]` is a mechanical shorthand over the same citation-eligible evidence; a single citation is still a single-element array. Treat `planned_section_groups[].draft_action_templates` as the align section scaffold. Keep hard citation-gap templates separate because non-contiguous evidence cannot form one source_ref; `heading_spans` and `local_headings` are facts for your judgment, not split commands. When one Section summarises contiguous multi-block evidence, list only the block ids the action actually consumes, and only when no citation-eligible block between them belongs to another action. If using explicit `source_refs[]`, copy them verbatim from `raw_snippets[].source_ref`. 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 padding. For `example` Sections that cite command / config / code fences, include the relevant fenced block in `content` only when writing reader-visible content. Inline command/code spans are not fences; if the cited raw is a numbered list or prose with inline code, keep that shape and do not synthesize a ```bash``` block or shell commands.
 
 ## Section Kind Choice
 
@@ -96,18 +98,18 @@ Confidence is optional. Omit it for ordinary confirmed claims; set it only when
 `description` is the kind for narrative claims that do not match any other form. Before locking in `kind: description` for a snippet, run three classification checks against the cited block:
 
 1. **Atomicity**: single narrative, or multi-step / multi-row / multi-config? Multi → split into the right kinds — each step into its own `spec` / `warning`, each row into a `comparison` Section, each config block into `example` (sample) or `spec` (constraint with a check method).
-2. **Kind-precision**: does a higher-priority kind fit better? A code / config / command block belongs in `example`; a comparison table belongs in `comparison`; a Q+A pair belongs in `faq`; a real incident with timeline belongs in `incident`; a versioned change record belongs in `changelog`; a multi-option choice (≥ 2 surfaced candidates + rationale) belongs in `decision`; a verifiable rule with a check method belongs in `spec`; explicit risks belong in `warning`; a stable design rule or core mechanism without surfaced alternatives or check method belongs in `principle`.
+2. **Kind-precision**: does a higher-priority kind fit better? A code / config / command block belongs in `example`; a comparison table belongs in `comparison`; a Q+A pair belongs in `faq`; a real incident with timeline belongs in `incident`; a versioned change record belongs in `changelog`; an explicit source-backed choice / tradeoff / adopted path with rationale belongs in `decision` even when only one chosen option is surfaced; a verifiable rule with a check method belongs in `spec`; explicit risks belong in `warning`; a stable design rule or core mechanism without a recorded choice or check method belongs in `principle`.
 3. **Action threshold**: multi-step fragments that clear the Action bar → emit `op: skip` with a note "evidence warrants sub-Action; re-align needed"; do not create Nodes from this skill.
 
 A Node whose raw is genuinely narrative — definitions, summaries, plain prose without enumerations or normative wording — legitimately ends with description-dominant output. The smell fires the other way: when raw contained enumerations, normative rules, or code blocks, and the draft collapsed them to `description`. Redraft from Step 2 in that case, not from a percentage threshold. Navigation-only evidence is handled separately by the TL;DR navigation rule and Step 2 — the gates above are not the right place to second-guess that path.
 
 ## Glossary and `refers_to_nodes`
 
-When raw mentions a name that overlaps the workspace glossary, put that name's slug in `refers_to_nodes[]` for the Section that discusses it — do NOT substitute it into the prose. This preserves explicit cross-Node references for query answers and citations without rewriting the claim. Slugs come from existing Sections, the context glossary, or Nodes already declared by the current align plan; never invent one. A Section can reference multiple Nodes (common on `comparison` / `decision`).
+When a Section meaningfully discusses another known Node, or should be discoverable through that Node in query/navigation, put that known slug in `refers_to_nodes[]` — do NOT substitute it into the prose. This preserves explicit cross-Node anchors for query answers and citations without rewriting the claim. Slugs come from existing Sections or the context glossary. Slugs that are only declared by the current align plan but not yet materialized are pending targets: skip them on first-pass draft unless the CLI explicitly surfaces the relationship as safe or needed. Do not remove an existing valid ref just because verify says the target is pending; continue compiling the target or let the CLI refresh renderer blocks. A Section can reference multiple Nodes (common on `comparison` / `decision`). Do not add a slug for incidental product-name mentions that add no Section-local relationship or navigation value.
 
-If the CLI returns `compile-missing-refers-to-node`, treat it as advisory: add the suggested slug only when the Section actually depends on that Node; otherwise leave the draft unchanged and rely on the cited `source_ref`.
+If the CLI returns `compile-missing-refers-to-node`, treat it as a relation-recall check, not a style advisory. Add the suggested slug when the drafted Section text meaningfully discusses that known Node or should be discoverable through it. Omit it only for incidental mentions, code/package names inside examples, or navigation-only evidence that should remain no-write.
 
-If the CLI returns source-ref narrowing, candidate hard-fact, summary quality, or low-coverage advisories with `agent_recommended_action: ignore`, do not patch solely to satisfy the advisory. Patch only when the cited source actually loses meaning, a confirmed hard fact is unsupported, or the returned `next_action` asks for a draft patch.
+If the CLI returns summary quality or low-coverage advisories with `agent_recommended_action: ignore`, do not patch solely to satisfy the advisory and do not inspect every folded detail row by default. Patch only when the cited source meaning is lost, the user asks for cleanup, or the returned `next_action` asks for a draft patch.
 
 ## FAQ attachment priority
 
@@ -149,19 +151,18 @@ For dense documents, group nearby snippets by their `block_locator_id` heading p
 
 For each classified snippet:
 
-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.
-   - Preserve meaningful Markdown formatting from the cited raw: inline code markers, fenced blocks, Markdown link targets, blockquote markers, nested list structure, tables, and emphasis on key terms. Do not flatten these into plain prose unless the formatting is purely decorative.
-   - `source_support` is advisory lexical diagnostics, not the final semantic judge or a keyword gate. Do not stuff raw text into `content` just to raise matched-term counts, and do not patch a clear draft only to satisfy a lexical term mismatch.
+1. Decide whether `content` is needed. The default for source-backed writes is no `content`: cite `source_block_ids[]` / `source_refs[]` and let the CLI mirror raw into the Section content. Add explicit `content` only when the cited raw needs an intentional reader-surface rewrite, such as translation, structural reorganization, or preserving Markdown/code/table shape that the mirror path would not express clearly. Keep one coherent, cited fact group per action.
+2. When you do write `content`, keep it 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.
+   - Do not lightly rewrite same-language prose for fluency, casing, entity-name consistency, or sentence cleanup. If the raw text is already clear, omit `content` instead of writing a near-copy.
+   - Preserve meaningful Markdown formatting from the cited raw when explicit `content` is necessary: inline code markers, fenced blocks, Markdown link targets, blockquote markers, nested list structure, tables, and emphasis on key terms. Do not flatten these into plain prose unless the formatting is purely decorative.
    - 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.
-   - For `example` Sections that cite a code, config, or command fence, keep `content` centered on the cited fenced block. Put framing prose such as "basic configuration example" in `summary`, or cite a separate prose block in a separate action when that prose is itself source-backed knowledge.
-3. For long `content`, add `summary` when it helps readers or query output. Summary is LLM-authored reader/query aid: one plain paragraph, no Markdown, and should stay compact. The CLI only reports advisory hints for missing summaries on long content, Markdown/multi-paragraph formatting, or clearly overlong summaries; it does not enforce a content-length ratio and does not treat summary quality as an evidence failure. Lexical `source_support` checks `content` (and legacy `detail` when present), not `summary`; keep summaries faithful to `content`, but do not copy raw-only keywords into `summary` for lexical scoring.
-4. Preserve `required_preserved_literals[]` from the CLI evidence view when the literal is part of the source-backed knowledge. For link-heavy citation-eligible evidence, keep meaningful URLs in `content` when the action writes knowledge; for supporting-only literals, keep them in the repair/challenge context instead of citing them. Do not patch only to satisfy non-blocking URL or style advisories.
+   - For `example` Sections that cite a code, config, or command fence, keep `content` centered on the cited fenced block. Put framing prose such as "basic configuration example" in `summary`, or cite a separate prose block in a separate action when that prose is itself source-backed knowledge. If the source only has prose/list text with inline code, preserve prose/list plus inline code; do not turn it into a fenced script.
+3. For long `content`, add `summary` when it helps readers or query output. Summary is LLM-authored reader/query aid: one plain paragraph, no Markdown, and should stay compact. In YAML payloads, write `summary` as a plain single-line scalar; reserve literal block scalars for multi-line `content`. If you cannot write a meaningful summary, omit the field entirely; generic placeholders like "description section covering N evidence blocks" are worse than no summary. The CLI reports advisory hints for missing or weak summaries; it does not treat summary quality as an evidence failure. Keep summaries faithful to the source-backed action, but do not copy raw-only keywords into `summary` for scoring.
+4. Preserve meaningful source-backed literals in `content`, `summary`, skip reason, or repair challenge when they are part of the knowledge. Do not patch only to satisfy non-blocking URL or style advisories.
 5. Omit `confidence` for ordinary confirmed claims. Assign it only when the evidence is clearly verified, inferred, or speculative according to the schema enum.
 6. Fill `refers_to_nodes[]` per [Glossary and refers_to_nodes](#glossary-and-refers_to_nodes).
-7. Cite evidence with `source_block_ids[]`, picking values from `source-refs-index` `items[].block_id` or `citable_source_refs[].block_id`. When one Section summarizes contiguous multi-block evidence, list only the block ids consumed by that Section content; the CLI expands and 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_block_ids[]` only when the skip represents reviewed no-write material from citation-eligible evidence; omit evidence for purely deterministic no-ops, navigation, and context-only/background snippets. Never submit singular `source_ref`, mix `source_block_ids` with `source_refs`, or use quoted-evidence fields; invalid evidence references remain blocking.
+7. Cite evidence with `source_block_ids[]`, picking values from `source-refs-index` `items[].block_id` or `citable_source_refs[].block_id`. Use CLI-provided `planned_section_groups[].draft_action_templates` as the starting scaffold; hard citation-gap templates stay separate, while heading/local-heading annotated evidence may stay together or be split by semantic knowledge unit. When one Section summarizes contiguous multi-block evidence, list only the block ids consumed by that Section action. 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_block_ids[]` only when the skip represents reviewed no-write material from citation-eligible evidence; omit evidence for purely deterministic no-ops, navigation, and context-only/background snippets. Never submit singular `source_ref`, mix `source_block_ids` with `source_refs`, or use quoted-evidence fields; invalid evidence references remain blocking.
 
 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`.
 
@@ -169,6 +170,6 @@ Rendered knowledge starts with optional `c4a:summary`, then the active `content`
 
 Emit one compile draft JSON document for the caller to submit to the current envelope's `next_action.command`. No markdown wrapper, no leading prose, no trailing commentary.
 
-Before returning, ensure `schema_version` is `compile.draft.v2`, `node_slug` matches `node.slug`, fields conform to `context schema compile-draft`, `required_preserved_literals[]` are preserved or carried into an evidence-backed skip/repair challenge, and NodeContext was the only evidence source.
+Before returning, ensure `schema_version` is `compile.draft.v2`, `node_slug` matches `node.slug`, fields conform to `context schema compile-draft`, citations point only at CLI-provided evidence, and NodeContext was the only evidence source.
 
 </procedures>

package/plugin/skills/skill-compile-draft/references/action-domain-gates.md

@@ -15,7 +15,7 @@ Treat `node.action_gate` as the compile boundary for procedural claims. An Actio
 
 If `action_gate` is absent on a Node whose `type` is `action`, treat it as a structural defect — emit a `structure_challenge` (see `references/structural-challenges.md`) instead of inventing process semantics.
 
-If the current evidence can only support one thin Section or only a parallel option/config list, do not stretch it into procedure prose. Emit `skip` or `structure_challenge` so align can downgrade it to the owning Entity/Domain Section.
+If the current evidence can only support one thin Section or only a parallel option/config list, do not stretch it into procedure prose. Emit `skip` or `structure_challenge` so align can revise the structure; the CLI does not auto-downgrade an Action or choose replacement Entity tags.
 
 ## Domain Nodes (`node.type === "domain"`)
 

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

@@ -41,8 +41,8 @@ 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 new `content` (optional `summary`, optional new `source_block_ids[]`) but do not include `kind` unless the kind itself is changing.
-- `supersede.new` is a fresh Section; it needs `kind`, `content`, `source_block_ids[]`, and may carry `summary`, `refers_to_nodes[]`, and `confidence` per the same rules as `add`.
+- `update` keeps the same `section-N` id; provide `source_block_ids[]` / `source_refs[]` for changed evidence and omit `content` when the new cited raw should be mirrored. Include `content` only for an intentional reader-surface rewrite. Do not include `kind` unless the kind itself is changing.
+- `supersede.new` is a fresh Section; it needs `kind` plus citation evidence. Omit `content` when cited raw should be mirrored; include `content` only for an intentional reader-surface rewrite. It 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`, `source_block_ids[]`, or `source_refs[]`.
 
 ## Output schema (refresh ops)
@@ -51,12 +51,12 @@ When `existing.sections[]` is non-empty, every `section-N` id you read here is a
 	{
 	  "actions": [
 	    { "op": "update", "target_section_id": "section-3",
-	      "content": "...",
+	      "summary": "...",
 	      "refers_to_nodes": null,
 	      "source_block_ids": ["c0d4e5f61728"] },
 	    { "op": "supersede", "target_section_id": "section-5",
 	      "reason": "raw published a new retention value",
-	      "new": { "kind": "spec", "content": "...",
+	      "new": { "kind": "spec", "summary": "...",
 	               "refers_to_nodes": ["..."],
 	               "source_block_ids": ["9d1e2f3a4b5c"] } },
     { "op": "deprecate", "target_section_id": "section-2", "reason": "..." }

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

@@ -2,7 +2,7 @@
 name: skill-compile-judge
 description: >
   Packaged skill invoked by `/context:compile`; not a user slash command. Consumes the budget-safe compile prepare summary
-  and candidate detail views, judges each draft action's source support and relation to listed candidates,
+  and candidate detail views, judges each draft action's raw evidence support and relation to listed candidates,
   and emits a compile.judge-decisions.v2 document for `context reconcile review`.
 tools:
   - Bash
@@ -16,11 +16,13 @@ decisions only; the CLI reviews, applies, and writes every workspace change.
 
 ## TL;DR — Non-negotiables
 
-- Invoke this skill only when the caller's top-level envelope has `next_action.kind: "review_reconcile_decisions"` or the prepare payload contains `judge_handoff`. If the active envelope asks for `patch_compile_draft`, `continue_compile_cycle`, or another action, stop and follow that `next_action.command` instead.
-- Input is the budget-safe compile prepare summary. For items with candidates, load only that item's candidate detail view with `context workflow show --payload prepare --view candidates --item-id <item-id> --unwrap --format json`.
-- Do not inspect workspace storage directly or run ad-hoc scripts to reconstruct candidates. Use only `items[]`, `evidence[]`, `source_support` diagnostics, `candidates[]`, `previous_decisions[]`, and `judge_handoff`.
+- Invoke this skill only when the active prepare summary contains `judge_handoff` or the returned diagnostics explicitly ask for compile support/relation judgment. A `review_reconcile_decisions` envelope by itself is not enough: if the command is accepting safe defaults or the remaining work is compact `{ item_id, accept_default: true }`, follow that review path instead. If the active envelope asks for `patch_compile_draft`, `continue_compile_cycle`, or another action, stop and follow that `next_action.command` instead.
+- Input is the budget-safe compile prepare summary. If `page.has_more` is true, follow `next_command` until every prepare item is listed.
+- The summary is an index: use `item_detail_command` only when the full proposed content, raw evidence, or source_ref details are needed.
+- For items with candidates, load only that item's candidate detail view with `context workflow show --payload prepare --view candidates --item-id <item-id> --unwrap --format json`.
+- Do not inspect workspace storage directly or run ad-hoc scripts to reconstruct candidates. Use only `items[]`, `evidence[]`, raw/source_ref diagnostics, `candidates[]`, `previous_decisions[]`, and `judge_handoff`.
 - Output exactly one JSON or YAML document with `schema_version: "compile.judge-decisions.v2"` and `decisions[]`.
-- Keep one decision per prepared `item_id`, preserving prepare order.
+- Keep one decision per `judge_handoff.items[].item_id`, preserving prepare order. Do not emit decisions for mechanical safe-default items that the caller will pass through `--accept-safe-defaults`.
 - For support, output `support_verdict: supported | weak | unsupported` plus `support_reason`.
 - For relation, output `relation_verdict: new | duplicate | supersede | conflict | merge_into` plus `relation_reason`.
 - Compare only the candidates listed on that item. Do not perform workspace-wide BM25, grep, or source-file searches.
@@ -28,8 +30,8 @@ decisions only; the CLI reviews, applies, and writes every workspace change.
 - Escape hatch: when an item has no candidates, `relation_verdict: new` with `compared_section_ids: []` and `compared_count: 0` is valid and expected.
 - For `duplicate`, `supersede`, `conflict`, or `merge_into`, set `target_section_id` to the matched candidate Section id.
 - Same `source_ref` can support different Section kinds only when the semantic role differs. Detect and explain same-source-ref multi-kind cases instead of treating them as automatic duplicates.
-- `source_support` is advisory lexical diagnostics, not a keyword gate. A supported judge verdict may override low lexical `source_support` when the cited raw evidence semantically covers the claim.
-- Evidence-boundary errors and unsupported confirmed hard facts remain blocking evidence issues. Missing URLs, section kind precision, example formatting, summary style, and lexical hard-term spelling/casing/punctuation/paraphrase mismatches are advisory unless the active CLI `next_action` explicitly blocks on them.
+- Raw/source_ref diagnostics are mechanical evidence checks, not a keyword gate. A supported judge verdict comes from the cited raw evidence semantically covering the claim.
+- Evidence-boundary errors remain blocking evidence issues. Section kind precision, example formatting, and summary style are advisory unless the active CLI `next_action` explicitly blocks on them.
 - Weak support is a warning-level verdict, not permission to invent missing facts. Unsupported support should normally pair with `conflict` or a later user question rather than a write decision.
 
 <reference>
@@ -69,7 +71,7 @@ decisions:
 
 | field | value | Meaning |
 |---|---|---|
-| `support_verdict` | `supported` | Cited raw evidence covers the claim's hard facts. |
+| `support_verdict` | `supported` | Cited raw evidence covers the claim. |
 | `support_verdict` | `weak` | The evidence plausibly supports an ordinary summary, but review may ask for confirmation. |
 | `support_verdict` | `unsupported` | The claim adds facts or boundaries not present in cited raw evidence. |
 | `relation_verdict` | `new` | No listed candidate already covers the proposed knowledge. |
@@ -91,8 +93,8 @@ candidates from memory or bypass the candidate detail view.
 ### Step 2 — Judge Support
 
 For each item, read the proposed content and cited evidence. Use
-`source_support` only as a diagnostic hint; final support is your semantic
-verdict from the cited raw evidence.
+Use raw/source_ref diagnostics only as evidence pointers; final support is your
+semantic verdict from the cited raw evidence.
 
 ### Step 3 — Judge Relation
 

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

@@ -24,6 +24,7 @@ of local knowledge; never read workspace files directly.
 - **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.
 - **Cite structure**: Every conclusion cites `[node/slug]` or `[node/section]`. If evidence does not support a claim, mark as gap.
+- **Expand raw when needed**: Query summaries help recall and scope choice; factual answers should rely on returned Section content or CLI-provided raw/source_ref expansion commands when a hit is marked raw-assisted or raw-expandable.
 - **Handle diagnostics**: If CLI returns `select`, `miss`, `broad`, `raw-only`, or `truncated`, follow the hint: show user structure to choose from, ask for narrower scope, or suggest workflow.
 
 <reference>
@@ -42,6 +43,7 @@ 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 |
+| `raw_expand_command` / `raw_evidence_preview` | Pointer to expand raw/source_ref evidence when the hit needs factual confirmation |
 | `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:

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

@@ -22,7 +22,7 @@ only; the CLI performs every write.
 - Input is the budget-safe `context reconcile prepare` summary or issues view. When an item lists candidates, load that item's candidate detail view with `context workflow show --payload prepare --view candidates --item-id <item-id> --unwrap --format json`; request broader detail only when a CLI `next_action` or detail command explicitly asks for it. Never `grep` / `sed` / `jq` / `cat` / `head` workflow scratch files or `--format json` stdout to recover prepare fields, and do not Read / Glob / Grep / Write workspace `raw/` / `knowledge/` / `archive/` / `decisions/` — the prepare payload and review output are the only inputs.
 - Ordinary compile prepare judgment belongs to `skill-compile-judge`. Use this skill for refresh/drop/non-compile reconcile, or when compile review asks for scope/omit/user-confirmation reasoning that is outside the judge handoff.
 - Output: one YAML or JSON document conforming to `context schema semantic-decisions --format yaml`. The schema defines canonical `relation` and `action` enums and the per-action required fields; do not memorise the enum list from this skill.
-- Accept a prepared `default_decision` with the compact form `{ item_id, accept_default: true }` (optionally `decided_by` / `rationale`); the CLI hydrates `target` / `proposed`. Empty `decisions: []` means "no items in prepare," not "accept all defaults." Without `--accept-safe-defaults`, emit one compact accept entry per safe default you intend to accept. With `--accept-safe-defaults`, the CLI auto-accepts mechanically safe no-candidate supported writes and reviewed-no-write skips, so emit only the manual decisions that still need judgment.
+- Accept a prepared `default_decision` with the compact form `{ item_id, accept_default: true }` (optionally `decided_by` / `rationale`); the CLI hydrates `target` / `proposed`. Empty `decisions: []` means "no items in prepare," not "accept all defaults." Without `--accept-safe-defaults`, emit one compact accept entry per safe default you intend to accept. With `--accept-safe-defaults`, the CLI auto-accepts mechanically safe defaults: no-candidate writes, reviewed-no-write skips, and low-risk `keep_separate` relation candidates only when the active compile workflow was created with user-authorized `--delegated`. Emit only the manual decisions that still need judgment.
 - 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.
@@ -38,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 diagnostics or cutover hints returned `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_*`, or prepared long `proposed.content` / `proposed.summary` | [references/temporal-and-evidence.md](references/temporal-and-evidence.md) |
+| items carry `temporal_prior` / `source_captured_at` / `temporal_disposition`, raw/source_ref boundary diagnostics, 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`.
@@ -88,7 +88,7 @@ Edge-case actions (`reanchor`, `split_then_reanchor`, `remove_unsupported`, `omi
 | `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.
+Evidence boundary 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 boundary repair hints.
 
 </reference>
 

package/plugin/skills/skill-semantic-reconcile/references/temporal-and-evidence.md

@@ -1,9 +1,9 @@
-# Temporal priors and evidence boundary signals
+# Temporal priors and evidence boundary pointers
 
 Consult this reference when prepare items carry **any** of:
 
 - `temporal_prior` / `proposed.source_captured_at` / candidate `source_captured_at` / `last_reconciled_at` / `temporal_disposition`
-- `source_support.evidence_block_candidates[]` or `source_support.evidence_block_*` repair hints
+- raw/source_ref boundary diagnostics or nearby source_ref pointers
 - prepared long `proposed.content` / `proposed.summary`, especially with command / config / code fence content
 
 For prepare items that have none of the above, ignore this file.
@@ -24,18 +24,17 @@ Treat these as **priors that explain context, never as license to act**:
 
 If you accept or override a temporal prior, state the business reason in `rationale`. **Do not copy temporal fields into the executable `proposed` patch** — the CLI strips them.
 
-## Evidence boundary repair hints
+## Evidence boundary repair
 
-When `source_support.verdict` is `weak` or `unsupported` and the prepare item contains:
+When review reports that the cited source_ref is invalid, stale, too narrow, or otherwise cannot support the proposed write, use only CLI-rendered evidence text and canonical source_ref values:
 
-- `source_support.evidence_block_source_ref` — the canonical block-level source_ref the cited claim falls in.
-- `source_support.evidence_block_line_range` — the block's line range.
-- `source_support.evidence_block_locator_id` — the block's locator id.
-- `source_support.evidence_block_candidates[]` — adjacent candidate blocks (optional).
+- canonical `source_ref` / `source_refs[]` values from the current view
+- block ids and line ranges surfaced by the CLI
+- nearby source_ref pointers included in diagnostics
 
 These are **repair hints**, not automatic broadening permission. Rules:
 
-1. Use the block-level `source_ref` **only when the whole block honestly supports the final claim**. Rerun `context reconcile review` after broadening — review revalidates the new range against workspace raw before apply.
+1. Use a broader `source_ref` **only when the whole range honestly supports the final claim**. Rerun `context reconcile review` after broadening — review revalidates the new range against workspace raw before apply.
 2. If the proposed summary actually combines several candidate blocks and **no single range honestly supports every sentence**, split the claim into separately supported decisions instead of forcing one unsupported summary through.
 3. Do not invent ranges that include unrelated content just to get the verdict to pass.
 
@@ -51,16 +50,9 @@ When the prepare item carries long `proposed.content` or a `proposed.summary`, t
 - Preserve prepared `content` and `summary` on executable write decisions (`merge_update`, `supersede.new`, `keep_separate`, `split_then_reanchor` sub-Sections) unless the decision intentionally rewrites the user-facing content.
 - The only legitimate way to clear `summary` is an update-style decision that explicitly emits `summary: null` as the chosen outcome.
 
-## Example content preservation advisory
-
-If review reports that a cited example evidence contains a command / config / code fence missing from `proposed.content`, first check the CLI issue severity and next action.
-
-- **When blocking**: regenerate the decision with the relevant fenced block included in `proposed.content` (preserve language, fences, and exact code), then rerun review.
-- **When advisory/debt**: do not patch solely for formatting. Patch only if the missing command/config/code changes the user-facing meaning or the user asks for fidelity cleanup.
-
 ## How this slots into the main procedure
 
 - **Step 1 — Consume**: scan prepare items for the signal fields above; flag affected items for the relevant repair path.
 - **Step 3 — Decide**: temporal priors inform `rationale` but never the action choice; evidence-block hints may justify broadening the cited range.
-- **Step 4 — Emit**: rerun `context reconcile review` after broadening ranges or restoring missing example content; only then proceed to apply.
+- **Step 4 — Emit**: rerun `context reconcile review` after broadening ranges; only then proceed to apply.
 - **Step 5 — Self-verify**: no executable write strips prepared `content` or `summary`; no temporal field leaks into `proposed`; every broadened `source_ref` has been re-reviewed.

package/plugin/skills/skill-semantic-reconcile/references/user-confirmation.md

@@ -23,7 +23,7 @@ If you cannot point at a specific user message answering the specific question f
 
 ## Weak support handling
 
-A prepare item is "weakly supported" when hard facts match between `proposed` and `evidence`, but lexical overlap is low. `context reconcile review` flags these and may return `support_confirmation`.
+A prepare item is "weakly supported" when cited evidence plausibly covers a compressed or rewritten claim, but review requires human confirmation before applying it. `context reconcile review` flags these and may return `support_confirmation`.
 
 Rules:
 
@@ -40,8 +40,8 @@ When review provides the **same `group_key`** on several questions that are all
 
 **Do not group**:
 
-- Questions that introduce new facts (the user is making a fact-level call, not a wording call).
-- Questions where one item has missing hard facts that the others have.
+- Questions that introduce new claims (the user is making a fact-level call, not a wording call).
+- Questions where one item lacks evidence that the others have.
 - Questions whose evidence boundaries differ (different sources / different blocks).
 
 When in doubt, ask separately.
@@ -61,7 +61,7 @@ After user confirmation:
 
 - `decided_by` is a **top-level** decision field, not a `proposed` sub-field.
 - Final executable decisions must not carry `user_confirmation.required: true`. That flag belongs only on `action: ask_user` items that still need input.
-- User confirmation permits weak support and omit. It does **not** permit unsupported evidence, missing hard facts, or contradictory claims — those still need stricter evidence or stay `ask_user`.
+- User confirmation permits weak support and omit. It does **not** permit unsupported evidence or contradictory claims — those still need stricter evidence or stay `ask_user`.
 - `decided_by: delegated_agent` is reserved for CLI-generated decisions inside a delegated compile workflow. Do not emit it from this skill.
 
 ## How this slots into the main procedure