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

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

@@ -1,48 +1,53 @@
 ---
 name: skill-semantic-reconcile
 description: >
-  Packaged skill invoked by `/context:compile` and `/context:drop`; not a user slash command. Consumes only
-  `context reconcile prepare` output, judges semantic relation/action for each
-  item, and emits a schema_version 1.0 semantic decision document for
-  `context reconcile review`; apply consumes the current workflow's ready review
-  artifact.
+  Packaged skill used by `/context:drop`, refresh/non-compile reconcile flows,
+  and compile scope-review fallback; not a user slash command. Ordinary compile
+  prepare judgment uses `skill-compile-judge`. This skill consumes only
+  `context reconcile prepare` output, judges semantic relation/action for each item,
+  and emits a schema_version 1.0 semantic decision document for `context reconcile review`;
+  apply consumes the current workflow's ready review artifact.
 tools:
   - Bash
 ---
 
 # skill-semantic-reconcile — decide Section reconciliation
 
-Judge duplicate, merge, conflict, reanchor, and unsupported cases from the
-CLI-prepared context. Emit decisions only; the CLI performs every write.
+Judge duplicate, merge, conflict, reanchor, and unsupported cases for refresh,
+drop, non-compile reconcile, or compile scope-review fallback. Emit decisions
+only; the CLI performs every write.
 
 ## TL;DR — Non-negotiables
 
-- Input is only the full `context reconcile prepare` payload. Do not Read, Glob, Grep, or Write workspace `raw/`, `knowledge/`, `archive/`, or `decisions/`.
-- Compact prepare summaries and `--view issues` payloads are inspection aids, not enough for semantic decisions. If the caller provided compact `context compile --draft ... --prepare` stdout, use its `workflow_payload.digest` and `scope_id` to load the full payload with `context workflow show --payload prepare --scope <scope-id> --digest <digest> --unwrap --format json` before deciding.
-- Do not use Python, Node.js, shell, or other ad-hoc scripts to preprocess, filter, summarize, or inspect ReconcileContext. Consume the prepared context and review output directly; temporary files are only CLI input/output handoff points.
-- Output exactly one YAML or JSON document with `schema_version: "1.0"` and `decisions[]`.
-- Source refs, Section kinds, mount rules, and verify terms follow the CLI schema, prepare payload, and verify output.
-- Use canonical relations: `exact_duplicate`, `strong_equivalent`, `near_duplicate`, `complement`, `supersedes`, `conflicts`, `reanchor`, `unsupported`, `keep_separate`, `ask_user`.
-- Use canonical actions: `duplicate_skip`, `merge_update`, `supersede`, `reanchor`, `remove_unsupported`, `keep_separate`, `split_then_reanchor`, `omit`, `ask_user`.
-- If prepare returns `items: []`, no semantic decision is needed; the caller may skip review/apply or pass `decisions: []` as an explicit no-op. If items exist and one includes `default_decision`, accepting it still requires one compact decision object for that exact `item_id` with `accept_default: true` and optional `decided_by` / `rationale`; `context reconcile review` hydrates the prepared `target` and `proposed` fields. Do not send `decisions: []` to accept defaults. `--accept-safe-defaults` only auto-accepts mechanically safe no-candidate supported writes and reviewed-no-write skips; when review is required, accept an appropriate complement/keep_separate default with `{ item_id, accept_default: true }` instead of echoing the full object. If you change the action, include the fields required by the table below.
-- Never use `omit` as an automatic escape hatch. If an item looks redundant, low-value, or non-knowledge, run the Scope Review pass below first. If it is still unclear, emit `ask_user`; only a user-confirmed no-write outcome may become `action: omit` with `decided_by: user`.
-- `no-op` is not a decision action. For unchanged refresh items, emit no decision or `duplicate_skip`. For compile draft `skip` items that already carry a `source_ref`, the CLI may produce a safe reviewed-no-write default; accept it with `accept_default: true` or `--accept-safe-defaults` instead of asking the user.
-- Never expose `src-N`, Section ids, or source refs as the user-facing choice. They may appear only in the structured payload.
-- `merge_update` is legal only when the final Section content is supported by one valid `source_ref`; otherwise use `keep_separate`, `split_then_reanchor`, or `ask_user`.
-- Unresolved conflicts and low-confidence support questions must be `action: ask_user`.
-- `context reconcile review` may return `support_confirmation` for a weakly supported `keep_separate`. Ask the user. If review provides the same `group_key` on several ordinary summary/compression questions, group them into one compact confirmation; do not group missing hard facts, new facts, or different evidence boundaries. If the user confirms, emit the same final write actions with `decided_by: user`; do not apply an `ask_user` decision.
-- Auto mode, long-running authorization, or permission to proceed is not user confirmation. Never use it as a reason to write `decided_by: user`.
-- If review returns `context-only-leakage-high`, stop before apply and follow its `agent_hints[]`: use `rewrite_with_owned_basis` only when owned or shared-primary citation evidence can support the same claim, `skip_for_node` when no citation-eligible basis exists and the claim is not core to that Node, or `pending_ownership_challenge` when a context-only or secondary shared block should be upgraded into owned/shared-primary evidence.
-- The caller applies a ready review by running plain `context reconcile apply` against the current workflow scope. Apply has no input-file path; do not extract `apply_document` with scripts.
-- Stable output: preserve prepared item order, keep decision object fields in the documented order, omit empty optional fields, and do not add current timestamps, random ids, storage paths, or host absolute paths. The fixed protocol and action table come first; only the prepared context should vary between repeated review calls.
+- Input is the full `context reconcile prepare` payload. If the caller handed you a compact prepare summary or `--view issues` payload, load the full payload first with `context workflow show --payload prepare --unwrap --format json` (add `--digest` only as an explicit stale guard). 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.
+- 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.
+
+## Edge cases — consult references when:
+
+| Condition | Reference |
+|---|---|
+| `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_*`, 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`.
 
 <reference>
 
 ## Decision Shape
 
-When accepting a prepared `default_decision`, this compact form is valid. Repeat
-one entry per accepted `item_id`; an empty `decisions: []` document is only a
-no-op when prepare returned zero items and does not accept defaults.
+Accept a prepared `default_decision` with the compact form:
 
 ```yaml
 schema_version: "1.0"
@@ -51,7 +56,7 @@ decisions:
     accept_default: true
 ```
 
-For a changed action or a hand-authored decision, emit the full shape:
+For a changed action or hand-authored decision, emit the full shape with the action's required fields (see Action Rules below):
 
 ```yaml
 schema_version: "1.0"
@@ -69,132 +74,21 @@ decisions:
     rationale: "The new evidence clarifies the same claim."
 ```
 
-## Action Rules
+`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 still awaiting input.
+
+## Action Rules — main path
+
+Edge-case actions (`reanchor`, `split_then_reanchor`, `remove_unsupported`, `omit`) and their required fields live in the matching reference; consult them when triggered.
 
 | 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. |
-| `reanchor` | `target`, `proposed.source_ref`, `proposed.confidence` | Use only when target content is still supported by the new source. |
-| `remove_unsupported` | `target` | Use when no active source supports the target claim in this mode. |
-| `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`). |
-| `split_then_reanchor` | `target`, `proposed.sections[]` with each Section carrying `kind`, `content`, `source_ref`, and `detail` when present in prepare | Each split Section must be independently supported by its cited evidence. |
-| `omit` | `target`, `rationale`, `decided_by: user` | User-confirmed no-write result after broader scope review and user confirmation. Never emit as an automatic decision. Do not use for conflicts, unsupported evidence, reanchor/drop cases, or schema/source_ref failures. |
-| `ask_user` | `user_confirmation.required: true` | Use only when business meaning or support cannot be decided from prepared evidence. |
-
-For `merge_update`, `supersede`, `keep_separate`, and
-`split_then_reanchor`, the final Section content must be supported by the cited
-evidence in `proposed.source_ref` / `proposed.source_refs`. Final executable decisions must
-include `proposed.source_ref`; review can hydrate a missing `source_ref` from
-the current prepare item only when the decision is still the same prepared
-claim. If you changed the content, kind, or evidence selection, rerun
-`context reconcile prepare` instead of reusing an old prepare file. Content
-should retain the raw evidence's key domain terms,
-numbers, code literals, and named entities. Do not introduce acronyms,
-abbreviations, translations, or aliases that the cited evidence does not
-contain or define; use the raw wording, split the claim, or ask the user instead.
-Do not turn sparse raw evidence into a broad summary, and do not cite a title, `Relations`, `Parent`,
-`Children`, or `Related` navigation line as the only support for a substantive
-claim.
-
-Preserve prepared `proposed.detail` exactly when it is present. `detail` carries
-long-form prose, examples, and code blocks; dropping it silently loses
-knowledge. If you intentionally want to remove detail from an existing Section,
-emit `detail: null` only on an update-style decision where that clearing is the
-chosen outcome.
-
-If review returns `example_detail_preservation`, the cited example evidence
-contains a command / config / code fence that was not preserved in
-`proposed.detail`. Prefer regenerating the decision with the relevant fenced
-block in `proposed.detail`; only keep a prose-only example summary after asking
-the user and marking the final decision `decided_by: user`. Auto mode or
-permission to continue is not that confirmation.
-
-The support gate exists to prevent orphan claims and false evidence links, not
-to optimize retrieval. Prefer preserving a precise raw-backed claim over
-rewriting content into a smoother summary. If a useful reader summary would
-combine adjacent evidence, first broaden `proposed.source_ref` so the cited
-range covers every sentence. If one range cannot honestly support the final
-claim, split the claim or ask the user instead of forcing it into an incorrect
-`source_ref`.
-
-Prepared items may include `source_support.evidence_block_source_ref`,
-`source_support.evidence_block_line_range`, and
-`source_support.evidence_block_locator_id`, plus optional
-`source_support.evidence_block_candidates[]`. These are repair hints for
-evidence boundaries, not automatic permission to broaden. Use the block-level
-`source_ref` only when that whole block honestly supports the final claim, then
-rerun `context reconcile review`; review revalidates the changed range against
-the workspace raw before apply. If a proposed summary actually combines several
-candidate blocks and no single range honestly supports every sentence, split it
-into separately supported claims instead of keeping one unsupported summary.
-
-Prepared compile items may include `temporal_prior`, proposed
-`source_captured_at`, and candidate `source_captured_at` /
-`last_reconciled_at` / `temporal_disposition`. Treat these as review priors
-only. They can explain why an older candidate may be stale relative to the new
-evidence, but they do not change `default_decision` and they are never enough
-to auto-supersede or auto-merge. If you accept or override a temporal prior,
-state the business reason in `rationale`; do not copy temporal fields into the
-executable `proposed` patch.
-
-Weak support means hard facts match but the ordinary lexical overlap is low.
-It is acceptable only for a user-confirmed `keep_separate` summary. It is not
-acceptable for `merge_update`, `supersede`, `reanchor`, or
-`split_then_reanchor`, because those actions overwrite, replace, or move an
-existing evidence boundary. When review asks `support_confirmation`, present
-the business claim and cited evidence to the user. If questions share the same
-review `group_key`, you may ask one compact grouped question; otherwise ask
-separately. If confirmed, regenerate the same executable decision with
-`decided_by: user`; if not confirmed, choose stricter evidence or leave an
-`ask_user` item unresolved and stop before apply. User confirmation only
-permits weak support; it does not permit unsupported evidence or missing hard
-facts. Auto mode or permission to continue is not user confirmation.
-
-`decided_by` is a top-level decision field, not a `proposed` field:
-
-```yaml
-schema_version: "1.0"
-decisions:
-  - item_id: claim-008
-    relation: complement
-    action: keep_separate
-    decided_by: user
-    target:
-      node: runtime-kit
-    proposed:
-      kind: example
-      content: "The host app maps remote modules through the runtime config."
-      source_ref: "src-1#example L32-40@7a6f4c9d2e10"
-```
+| `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. |
 
-Final executable decisions must not carry `user_confirmation.required: true`.
-Use that flag only on `action: ask_user` items that still require user input.
-
-If you are tempted to omit an item, do not emit `omit` immediately. First run a
-Scope Review pass over the full prepared context and the current draft
-decisions:
-
-- If the item is covered by another decision in the same batch, convert it to a
-  precise executable action such as `duplicate_skip` and explain the covered-by
-  item in `rationale`.
-- If the item should be merged into another write action, revise that write
-  action instead of dropping the item silently.
-- If the item is low-value/non-knowledge but you cannot prove that from the
-  prepared context, emit `ask_user` with `question_type: omit_confirmation` and
-  a business-language prompt.
-- If several items look low-value or the Node boundary/draft scope looks wrong,
-  emit `ask_user` with `question_type: scope_review_required` and stop before
-  apply.
-- Only after the user confirms a no-write outcome may you emit `action: omit`
-  with `decided_by: user`. `omit` is not recorded in the semantic ledger.
-
-`remove_unsupported` has mode-specific write behavior. In compile/refresh
-apply it deprecates the target Section so the unsupported claim remains visible
-as inactive history. In drop apply it physically removes the Section from active
-knowledge after the CLI-managed archive captures the pre-drop snapshot. Use the
-same action only when this mode-specific outcome is intended.
+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.
 
 </reference>
 
@@ -202,50 +96,41 @@ same action only when this mode-specific outcome is intended.
 
 ### Step 1 — Consume Prepared Context
 
-Use the caller-provided `context reconcile prepare` output. For each item,
-compare `proposed`, `candidates`, `previous_decisions`, and `evidence`.
+Use the caller-provided `context reconcile prepare` payload. For each item, compare `proposed`, `candidates`, `previous_decisions`, and `evidence`.
+
+If `prepare.mode` is `drop` or `refresh`, or any item carries the special signals listed in the routing table above, read the relevant reference **before** classifying — those references explain how the corresponding conditions modify Step 2.
+
+If prepare returns `items: []`, no decision is needed; the caller may skip review/apply or pass `decisions: []` as an explicit no-op.
 
-### Step 2 — Reuse Stable Priors
+If `previous_decisions[]` shows the same boundary and the prepared item still matches, emit the same final action. If the target changed, treat the previous decision as a prior only and continue judging.
 
-If `previous_decisions[]` shows the same boundary and the prepared item still
-matches, emit the same final action. If the target changed, treat the previous
-decision as a prior only and continue judging.
+### Step 2 — Decide Relation And Action
 
-### Step 3 — Decide Relation And Action
+Classify each item against the prepared evidence:
 
-Classify each item:
+- Exact same claim already active → `exact_duplicate` + `duplicate_skip`.
+- Same claim with a raw-supported correction or refinement from one supporting source → `strong_equivalent` or `near_duplicate` + `merge_update`.
+- Additional but separate boundary → `complement` + `keep_separate`.
+- New material replaces old rule → `supersedes` + `supersede`.
+- Direct contradiction → `conflicts` + `ask_user`.
+- Evidence is close but not enough → `ask_user`; for `keep_separate`, review may turn this into `support_confirmation` (see [references/user-confirmation.md](references/user-confirmation.md)).
+- Item appears redundant or not worth writing → run the Scope Review pass in [references/scope-review-and-omit.md](references/scope-review-and-omit.md); never auto-`omit`.
 
-- Exact same claim already active -> `exact_duplicate` + `duplicate_skip`.
-- Same claim with a raw-supported correction or refinement from one supporting source -> `strong_equivalent` or `near_duplicate` + `merge_update`.
-- Additional but separate boundary -> `complement` + `keep_separate`.
-- Item appears redundant or not worth writing -> run Scope Review first; if still unresolved, `ask_user` (`omit_confirmation` or `scope_review_required`). Use `omit` only after user confirmation.
-- New material replaces old rule -> `supersedes` + `supersede`.
-- Direct contradiction -> `conflicts` + `ask_user`.
-- Drop item still fully supported elsewhere -> `reanchor` + `reanchor`.
-- Drop item partly supported -> `reanchor` + `split_then_reanchor`.
-- No surviving support -> `unsupported` + `remove_unsupported`.
-- Evidence is close but not enough -> `ask_user`; for `keep_separate`, review may turn this into `support_confirmation` and require explicit user confirmation before apply.
+Drop-mode-only branches (`reanchor`, `split_then_reanchor`, `remove_unsupported`) live in [references/mode-semantics.md](references/mode-semantics.md).
 
-### Step 4 — Emit Decisions
+### Step 3 — Emit Decisions
 
-Emit only executable final decisions plus unresolved `ask_user` questions.
-Do not include prose outside the document.
+Emit one document with `schema_version: "1.0"` and `decisions[]`. Include only executable final decisions plus unresolved `ask_user` questions. Do not include prose outside the document.
 
-If the latest review rejected the batch with `context-only-leakage-high`, do
-not convert it into a generic `ask_user`. Regenerate the affected decision using
-one of the review hint's explicit repair options and cited item ids, then rerun
-`context reconcile review`. A context-only block may provide background only; it
-must not become the support basis for a written Section unless ownership is
-challenged and upgraded by the workflow.
+If the latest review rejected the batch with `context-only-leakage-high`, do not convert it into a generic `ask_user`. Follow [references/leakage-and-ownership.md](references/leakage-and-ownership.md): regenerate the affected decision using one of the review hint's explicit repair options and cited item ids, then rerun `context reconcile review`.
 
-### Step 5 — Self-verify
+### Step 4 — Self-verify
 
-- [ ] Every decision uses canonical relation/action values. If not, **Step 3**.
-- [ ] No `no-op` action appears. If not, **Step 3**.
-- [ ] Every write action has the required fields from [Action Rules](#action-rules). If not, **Step 4**.
-- [ ] No automatic `omit` appears. If any item is being skipped without proof, run Scope Review or ask the user.
-- [ ] Prepared `proposed.detail` is preserved on executable write decisions. If not, **Step 4**.
-- [ ] `decided_by: user` appears only after the user explicitly confirmed a review question. If not, remove it and ask the user.
-- [ ] No workspace files were read or written directly. If violated, restart from **Step 1**.
+- [ ] Every decision uses canonical `relation` / `action` values per `context schema semantic-decisions`. If not, return to **Step 2**.
+- [ ] Every write action carries the required fields from Action Rules (or, for edge-case actions, the rules in the matching reference). If not, **Step 3**.
+- [ ] `decided_by: user` corresponds to a specific recent user message answering this specific question for this specific item. If not, downgrade to `ask_user`.
+- [ ] No `action: omit` was emitted without `decided_by: user` and a business `rationale`. If any, run Scope Review per [references/scope-review-and-omit.md](references/scope-review-and-omit.md).
+- [ ] If any edge case condition applies (drop/refresh mode, review confirmation request, leakage, temporal/evidence signals, omit), the relevant reference's Self-verify items were also satisfied.
+- [ ] No workspace files were read or written directly; no `--format json` stdout was sliced with shell tools. If violated, restart from **Step 1**.
 
 </procedures>

package/plugin/skills/skill-semantic-reconcile/references/leakage-and-ownership.md

@@ -0,0 +1,31 @@
+# Context-only leakage and ownership upgrades
+
+Consult this reference when `context reconcile review` returns `agent_hints[]` with `code: "context-only-leakage-high"`. For runs without that hint, ignore this file.
+
+## What the hint means
+
+A decision's `proposed.source_ref` cites a block that is **`context_only`** for this Node, or a **secondary-shared** block (the Node is in `owners[]` but not `primary_owner`). Those blocks may inform context but cannot be the support basis for a written Section — that breaks the ownership boundary set during align finalize.
+
+`context-only-leakage-high` is a **hard rejection**. Do not convert it into a generic `ask_user` and do not retry the same decision unchanged.
+
+## Three repair options
+
+The review hint names which one applies per item. Pick exactly one:
+
+| Hint repair option | When | What to emit |
+|---|---|---|
+| `rewrite_with_owned_basis` | An owned or shared-primary citation block in the same prepare item supports the same claim | Regenerate the decision citing the owned/primary block; resubmit to `context reconcile review`. |
+| `skip_for_node` | No citation-eligible owned/primary evidence exists in this prepare batch, and the claim is not load-bearing for the Node | Emit `action: ask_user` with `question_type: skip_for_node_confirmation` and the cited evidence; only after user confirms, emit `duplicate_skip` or `omit` (`decided_by: user`). |
+| `pending_ownership_challenge` | The context-only/secondary-shared block contains facts the Node legitimately needs; align must upgrade ownership | Stop the reconcile loop; emit the challenge through the compile draft side (see `plugin/skills/skill-compile-draft/references/structural-challenges.md`) and let the align workflow resolve the split. |
+
+## What not to do
+
+- Do not paraphrase the offending block into different wording while still citing it — the CLI hashes the cited block, not the prose, so paraphrasing does not lift the leakage flag.
+- Do not promote the block through `request_full_text` — that command exposes visible evidence text for inspection but does not change citation eligibility.
+- Do not silently `duplicate_skip` to make the warning disappear; the hint may indicate a real evidence gap.
+- Do not regenerate the decision with a different `target` to dodge the rule.
+
+## How this slots into the main procedure
+
+- **Step 4 — Emit**: when review returns `context-only-leakage-high`, treat the affected items as not-yet-decided. Apply the chosen repair option per item, then rerun `context reconcile review` before considering apply.
+- **Step 5 — Self-verify**: no `proposed.source_ref` points at a block whose ownership role for the target Node is `context_only` or secondary-shared. The CLI re-checks at apply time, but catching it here saves a round trip.

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

@@ -0,0 +1,41 @@
+# Mode-specific semantics
+
+Consult this reference when **`prepare.mode` is `drop` or `refresh`**. For the default `compile` mode, ignore this file and follow the main SKILL.md procedure.
+
+## Available actions per mode
+
+| Action | `compile` | `refresh` | `drop` | `restore` |
+|---|---|---|---|---|
+| `duplicate_skip` / `merge_update` / `supersede` / `keep_separate` / `ask_user` | ✓ | ✓ | (rare) | ✓ |
+| `reanchor` | — | — | **drop-only** | — |
+| `split_then_reanchor` | — | — | **drop-only** | — |
+| `remove_unsupported` | ✓ deprecate | ✓ deprecate | **physical remove** | — |
+
+## `remove_unsupported` — mode-dependent write behavior
+
+The action is the same, the on-disk effect is not.
+
+| Mode | What happens on apply |
+|---|---|
+| `compile` / `refresh` | Target Section's `status` flips to `deprecated`; the unsupported claim stays visible as inactive history. |
+| `drop` | The Section is physically removed from active knowledge after the CLI-managed archive captures the pre-drop snapshot. |
+
+Only emit `remove_unsupported` when this mode's outcome is the intended one. A claim that should remain visible-but-stale belongs in `compile`/`refresh`; a claim that the workspace must lose belongs in `drop`.
+
+## `reanchor` and `split_then_reanchor` — drop-only
+
+These appear only in drop prepare items. They handle "a Section that the drop would remove still has supporting evidence in another source."
+
+| 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` / 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`.
+
+## How this slots into the main procedure
+
+- **Step 1 — Consume Prepared Context**: read `prepare.mode` first. If `drop` or `refresh`, the Step 3 classification table extends with the mode-specific rows above.
+- **Step 3 — Decide Relation And Action**: for drop items, use the `reanchor` / `split_then_reanchor` / `remove_unsupported` branches from the table here rather than forcing the items into compile-mode actions.
+- **Step 5 — Self-verify**: confirm no compile-mode action was emitted on a drop item (and vice versa) — the CLI rejects with a clear hint, but catching it here saves a round trip.

package/plugin/skills/skill-semantic-reconcile/references/scope-review-and-omit.md

@@ -0,0 +1,60 @@
+# Scope Review and `omit` discipline
+
+Consult this reference when **you are tempted to emit `action: omit`**, or when an item looks redundant / low-value / non-knowledge. For runs without such items, ignore this file.
+
+## Core rule
+
+`omit` is **never an automatic decision**. It records a no-write outcome **after** broader scope review and **after** explicit user confirmation. Emitting `omit` without both is a protocol violation.
+
+`omit` is also **not the right tool** for:
+
+- Conflicts → use `ask_user`.
+- Unsupported evidence → use `unsupported` + `remove_unsupported` (mode-aware; see `references/mode-semantics.md`).
+- Reanchor/drop cases → use `reanchor` or `split_then_reanchor`.
+- Schema / source_ref failures → fix the decision, do not omit.
+
+`omit` is **not recorded in the semantic ledger**. There is no audit trail; this is why the confirmation gate exists.
+
+## Scope Review pass
+
+Before emitting `omit` or `ask_user` with `question_type: omit_confirmation`, run this pass over the full prepared context and the current draft decisions:
+
+1. **Covered-by check** — is the item already covered by another decision in the same batch?
+   - Yes → convert it to a precise executable action such as `duplicate_skip` and explain the covered-by item in `rationale`. Do not omit.
+
+2. **Mergeable check** — should this item's content be merged into another write action?
+   - Yes → revise the other write action to incorporate this evidence. Drop the standalone item only after the merged action survives review. Do not omit silently.
+
+3. **Provable low-value check** — can you prove from the prepared context that the item is low-value / non-knowledge?
+   - Yes (prepared context contains the proof) → emit `ask_user` with `question_type: omit_confirmation` and a business-language prompt.
+   - No (you only have a hunch) → emit `ask_user` with `question_type: omit_confirmation` and present the claim + evidence so the user can judge.
+
+4. **Scope-wide miscope check** — do several items look low-value, or does the Node boundary / draft scope look wrong?
+   - Yes → emit `ask_user` with `question_type: scope_review_required` and **stop before apply**. Do not paper over a scope problem with a series of `omit` decisions.
+
+5. **User-confirmed no-write** — only after the user has explicitly answered the `omit_confirmation` or `scope_review_required` question saying "do not write," may you emit:
+
+   ```yaml
+   - item_id: claim-007
+     relation: keep_separate    # or whatever the prepared relation was
+     action: omit
+     target:
+       node: ...
+     decided_by: user
+     rationale: "<business reason from the user reply>"
+   ```
+
+   `decided_by: user` must reflect a specific recent user message answering this specific question (see `references/user-confirmation.md`).
+
+## Common anti-patterns
+
+- Emitting `omit` because the item "looks redundant" without running Scope Review.
+- Emitting `omit` because review returned `ask_user` and you want to clear the queue.
+- Treating auto mode / earlier "continue" as user confirmation.
+- Using `omit` to dodge a `remove_unsupported` decision in drop mode (the physical-remove behavior is the **point** of drop).
+
+## How this slots into the main procedure
+
+- **Step 3 — Decide**: when tempted to skip an item, treat that temptation as a signal to run Scope Review **before** writing the decision.
+- **Step 4 — Emit**: only emit `omit` when a specific user reply confirms the no-write outcome; otherwise emit `ask_user`.
+- **Step 5 — Self-verify**: no `action: omit` appears without `decided_by: user` and a `rationale` that names the business reason.

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

@@ -0,0 +1,66 @@
+# Temporal priors and evidence boundary signals
+
+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
+- 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.
+
+## Temporal priors — review-only signals
+
+Compile prepare items may include:
+
+- `proposed.source_captured_at` — when the new evidence was captured.
+- Each candidate's `source_captured_at`, `last_reconciled_at`, and `temporal_disposition` (`stale` / `recent` / `concurrent`).
+- A top-level `temporal_prior` summary.
+
+Treat these as **priors that explain context, never as license to act**:
+
+- They can justify why an older candidate may be stale relative to new evidence.
+- They **do not** change `default_decision`.
+- They are **never** enough on their own to auto-supersede or auto-merge.
+
+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
+
+When `source_support.verdict` is `weak` or `unsupported` and the prepare item contains:
+
+- `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).
+
+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.
+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.
+
+The support gate exists to prevent orphan claims and false evidence links, not to optimize retrieval. Prefer preserving a precise raw-backed claim over rewriting content into a smoother summary.
+
+## Long `proposed.content` / `proposed.summary` preservation
+
+When the prepare item carries long `proposed.content` or a `proposed.summary`, treat both as load-bearing:
+
+- `content` carries the active Section knowledge, including long-form prose, examples, URLs, tables, commands, config, and code blocks.
+- `summary` is the short reader/query aid for long content.
+- Dropping either field silently loses knowledge or query UX.
+- 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 repair
+
+If review reports that a cited example evidence contains a command / config / code fence missing from `proposed.content`, repair:
+
+- **Preferred**: regenerate the decision with the relevant fenced block included in `proposed.content` (preserve language, fences, and exact code).
+- **Fallback only after user confirmation**: keep a prose-only example summary, mark the final decision `decided_by: user` per `references/user-confirmation.md`. Auto mode is not user confirmation.
+
+## 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 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

@@ -0,0 +1,71 @@
+# User confirmation paths
+
+Consult this reference when `context reconcile review` returns any of:
+
+- `support_confirmation` (weak support questions)
+- `omit_confirmation` (no-write outcome under Scope Review)
+- `scope_review_required` (item set looks miscoped)
+- any other `ask_user` question that needs user input before apply
+
+For runs where review emits no questions, ignore this file.
+
+## What counts as "user confirmation"
+
+Only **explicit user reply to a question your agent asked**. The following are **not** confirmation:
+
+- Auto mode being active
+- Delegated mode being active (`--delegated` lets the CLI make scoped low-risk review decisions; it is not user confirmation for a specific question)
+- A blanket "continue" / "yes go ahead" earlier in the session
+- Permission to run shell commands
+- A previous decision applied with `decided_by: user` for a different item
+
+If you cannot point at a specific user message answering the specific question for this specific item, **do not emit `decided_by: user`**.
+
+## 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`.
+
+Rules:
+
+- Weak support is **only** acceptable on `keep_separate`. It is **not** acceptable on `merge_update`, `supersede`, `reanchor`, or `split_then_reanchor` — those overwrite, replace, or move an existing evidence boundary and need stronger backing.
+- When review asks `support_confirmation`, present the business claim and cited evidence to the user in business language. Do not expose `src-N` / Section ids / source refs as the user-facing choice.
+- If the user confirms, regenerate the same executable decision with `decided_by: user` and rerun review. If they decline, choose stricter evidence, broaden the cited range honestly, or leave the item as `ask_user` and stop before apply.
+
+## Grouping `support_confirmation`
+
+When review provides the **same `group_key`** on several questions that are all ordinary summary / compression checks, group them into one compact confirmation:
+
+- One question to the user listing all grouped claims and their cited evidence.
+- If confirmed, emit `decided_by: user` on each grouped decision.
+
+**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 whose evidence boundaries differ (different sources / different blocks).
+
+When in doubt, ask separately.
+
+## `omit_confirmation` and `scope_review_required`
+
+These are escape hatches from the omit gate. See `references/scope-review-and-omit.md` for when to emit them.
+
+When review returns either as an unresolved `ask_user` item, ask the user, capture the answer, and act:
+
+- User confirms no-write → final decision is `action: omit` with `decided_by: user` and a business `rationale`. `omit` is not recorded in the semantic ledger.
+- User declines → revise the item to a concrete write action or to `ask_user` with a sharper question.
+
+## Final-decision invariants
+
+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`.
+- `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
+
+- **Step 3 — Decide**: keep `support_confirmation` / `omit_confirmation` / `scope_review_required` candidates as `ask_user` with the right `question_type` until the user replies.
+- **Step 4 — Emit**: only after a user reply may you upgrade an `ask_user` to an executable decision with `decided_by: user`.
+- **Step 5 — Self-verify**: every `decided_by: user` corresponds to a specific recent user message; if not, downgrade back to `ask_user`.