@c4a/context-cli 0.5.41-beta.7 → 0.6.0-alpha.6

package/plugin/skills/skill-drop/SKILL.md

@@ -1,189 +0,0 @@
----
-name: skill-drop
-description: >
-  Packaged skill invoked by `/context:drop`; not a user slash command. Source retraction through CLI-owned planning and application. The agent
-  calls `context drop --plan` for a structured impact plan, presents the
-  user-facing summary for confirmation, runs semantic reconciliation when the
-  plan archives affected Sections, then calls `context drop --apply-plan` so
-  the CLI archives raw and removed knowledge, cleans active knowledge, applies
-  source alias reindexing, source stamp, changelog append, consumes the current
-  ready immutable review when semantic decisions are required, writes the
-  semantic ledger, and runs verify.
-  Activates when `/context:drop` is invoked with a source-id or URL.
-tools:
-  - Bash
----
-
-# skill-drop — retract a source without losing the audit trail
-
-Ask the CLI for a structured cleanup plan, confirm the user-visible impact,
-run semantic reconciliation on affected knowledge items when required, then ask
-the CLI to apply the plan. Do not inspect or mutate workspace files directly.
-
-## TL;DR — Non-negotiables
-
-- Plan + semantic prepare/review + apply are CLI-owned. The agent only presents the plan, asks semantic questions when required, and waits for confirmation.
-- Drop removes affected raw / unsupported knowledge from the active workspace and keeps a CLI-managed restorable archive for audit.
-- Do not Read / Glob / Grep / Write workspace storage; all impact analysis and mutation must go through `context drop --plan`, `context reconcile prepare --mode drop`, `context reconcile review`, and `context drop --apply-plan`.
-- Do not use Python, Node.js, shell scripts, `ls`, `find`, `rg`, `cat`, or similar ad-hoc commands to inspect or preprocess workspace storage or temporary workflow artifacts.
-- `context drop --plan <source-id|url> --format json` resolves source-id, computes affected topics / knowledge items, reports alias reindex impact, and stores the exact plan as the current workflow's `drop-plan` payload. `--save-output` is only for an explicit human-readable scratch copy; do not use it as a handoff.
-- `context drop --apply-plan --reason "<text>" --yes` reads the current workflow `drop-plan` payload, archives affected active content, consumes the current workflow's ready immutable review when the plan archives Sections, removes unsupported Sections / empty Nodes from active knowledge, applies source alias reindexing, writes the source stamp, changelog append, semantic ledger when decisions exist, and verify. Do not pass plan or decisions files to drop apply.
-- User confirmation required unless `--yes` was passed; abort on any non-`y` answer without writing. `--yes` does not skip semantic `ask_user` questions.
-- Confirmation prose describes affected topics and claims, not source-ref mechanics.
-- Source evidence, section, and verify rule meanings stay anchored to the CLI plan, reconcile, and verify outputs.
-- Output language: impact plan + report match the user's language; CLI commands, flag names, source-ids, comment attributes stay English.
-
-<reference>
-
-## Plan fields
-
-The JSON plan has:
-
-| Field | Meaning |
-|---|---|
-| `source_id` | Canonical source id resolved from user input |
-| `resolved_from.kind` | `source-id` or `url` for the production Agent flow |
-| `affected_nodes[]` | Topics whose source list contains the dropped source |
-| `affected_nodes[].sections[]` | Knowledge items that require semantic reconciliation before the source is dropped |
-| `affected_nodes[].reindex_sections[]` | Knowledge items whose internal source alias will be renumbered after the source is removed |
-| `affected_nodes[].will_be_sourceless` | Topic has no remaining source ids after cleanup |
-| `affected_nodes[].will_be_empty` | Topic has no remaining Section/body/children/contains after cleanup and may be archived even if another source id remains |
-| `affected_graph_edges[]` | Explicit graph edges that will be removed if one endpoint is archived by apply |
-| `references_will_be_pruned[]` | Surviving Sections whose `refers_to_nodes[]` will lose archived node slugs; the Section itself is not removed |
-| `summary` | Counts for confirmation and changelog |
-
-If a non-domain Node would keep an active source id but lose all of its own Sections while still carrying child Nodes, contains links, or body text, do not rely on verify to catch it after mutation. Produce a semantic reanchor/split decision that preserves a supported Section, or expect `drop --apply-plan` to reject before writing.
-
-## User-facing impact summary shape
-
-```
-Affected: N topics · M knowledge items
-
-  <topic title>
-    "short claim preview" → remove from active knowledge and archive
-    "short claim preview" → keep, supported by another source document
-  <topic title>
-    "short claim preview" → remove from active knowledge and archive
-
-Proceed? [y/N]
-```
-
-Keep the internal node slug, Section id, and source-ref patch data in your
-working notes for Step 4; show them only if the user asks for implementation
-details.
-
-## CLI shapes
-
-```
-context drop --plan <source-id|url> --format json
-context reconcile prepare --mode drop --format json
-context reconcile review --decisions - --view status
-context drop --apply-plan --reason "<text>" --yes
-```
-
-The apply command writes a source-specific restorable archive,
-moves affected raw out of the active source set, consumes the current workflow's ready immutable review for
-reanchor / remove_unsupported / split_then_reanchor when affected Sections are archived, removes unsupported
-Sections / empty Nodes from active knowledge, flips the source registry entry to
-`status: dropped`, stamps `drop_reason`, `dropped_at`, and a semantic archive status,
-appends a `[drop]` changelog line, records the semantic ledger when decisions exist,
-and runs verify. It exits
-non-zero if the source-id is unknown, already dropped, plan shape is invalid,
-the plan is stale, semantic decisions are unresolved/invalid, or verify reports errors.
-In drop mode, `remove_unsupported` means physical removal from active knowledge
-after the archive captures the before snapshot; compile/refresh apply uses the
-same action name for Section deprecation.
-
-</reference>
-
-<procedures>
-
-### Step 1 — Parse arguments
-
-From `$ARGUMENTS`: `<source-id|url>` (required), `--reason <text>` (optional), `--yes` (optional). If the target is missing, stop and ask for the source id or URL. If the reason is missing but the user's wording gives a clear reason, infer a concise reason such as `用户主动撤回`; otherwise collect it before Step 4.
-
-### Step 2 — Ask CLI for a plan
-
-Run `context drop --plan <source-id|url> --format json`.
-The CLI stores the plan in the current workflow and prints the plan JSON for
-the impact summary. Use `--save-output` only when the user explicitly wants a
-readable copy; it is not a workflow input.
-Do not inspect workspace files yourself. If the CLI reports source-not-found or
-source-already-dropped, relay the error and stop.
-
-### Step 3 — Present the impact plan
-
-Render the [User-facing impact summary shape](#user-facing-impact-summary-shape)
-from the plan JSON in the user's language. Make clear that dropping a source
-removes listed content from active knowledge but keeps it restorable until
-`context purge`. Mention conditional graph edge cleanup when
-`affected_graph_edges[]` is non-empty; these edges are removed only if the
-endpoint leaves active knowledge after reconciliation. Include the reason that will be stamped; if
-it is still unknown, ask for the reason before continuing. If `--yes`, log
-"auto-confirmed per --yes" and continue. Otherwise wait for `y`; abort on
-anything else without writing.
-
-### Step 4 — Reconcile affected knowledge
-
-If the plan summary has `archive_sections: 0`, skip semantic reconcile and continue to Step 5. The apply path is review-free only for this no-op archive case.
-
-Use the current workflow plan created by Step 2. Do not pass a plan file. Then run:
-
-```
-context reconcile prepare --mode drop --format json
-```
-
-Invoke the packaged semantic reconcile procedure with that prepare payload. Use
-Pass the semantic reconcile decision document directly to review, preferably
-through stdin:
-
-```
-context reconcile review --decisions - --view status
-```
-
-The review command persists the ready immutable review artifact for the current
-drop workflow scope when `ready_to_apply: true`. Do not extract
-`apply_document`, and do not pass the decisions file to drop apply.
-If review returns any `questions[]`, ask the user and convert those decisions
-from `ask_user` into one of `reanchor`, `remove_unsupported`, or
-`split_then_reanchor` before continuing. Do not let `--yes` bypass this step.
-Weak evidence support is not a drop safety bypass: `reanchor` and
-`split_then_reanchor` still need clearly supported surviving evidence. If
-review cannot confirm that support, choose `remove_unsupported` or stop for
-user input instead of forcing a weak reanchor.
-
-### Step 5 — Apply the plan
-
-Use the current workflow plan from Step 2. If Step 4 ran semantic review, make
-sure the latest `context reconcile review` result returned `ready_to_apply:
-true`; the CLI will load that ready review artifact itself. Then call:
-
-```
-context drop --apply-plan --reason "<text>" --yes
-```
-
-Do not call `context mdrive section ...` or `context mdrive node ...` for the
-standard drop flow; `drop --apply-plan` owns cleanup, ledger write when
-decisions exist, and verify. If the CLI rejects for missing ready review, rerun
-Step 4 and then retry apply without changing the apply command shape.
-
-### Step 6 — Report
-
-The apply command already verifies. Run `context source get <source-id>` and
-report in the user's language: topics affected, knowledge items marked
-archived/removed from active knowledge, source alias reindex count, archive
-status, changelog timestamp.
-
-### Step 7 — Self-verify
-
-- [ ] No Read / Glob / Grep / Write was used against workspace storage — if any was used, restart from **Step 2** with CLI-only flow.
-- [ ] No ad-hoc script or shell file traversal was used against workspace storage or temporary workflow artifacts — if any was used, restart from **Step 2** with CLI-only flow.
-- [ ] `context drop --plan` succeeded before asking the user — if not, **Step 2**.
-- [ ] `context reconcile prepare --mode drop` read the current workflow drop-plan payload — if not, **Step 2**.
-- [ ] `context reconcile review` returned zero `questions[]` before apply; if any question remains, ask the user and regenerate the decisions document.
-- [ ] User confirmed unless `--yes` was passed — if not, abort without writing.
-- [ ] `context drop --apply-plan` exited 0 — if not, surface the CLI error and stop.
-- [ ] `context source get <source-id>` shows the source as dropped — if not, surface the mismatch.
-- [ ] The reported source entry includes semantic archive status when the source was archived — if missing, surface the mismatch.
-
-</procedures>

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

@@ -1,136 +0,0 @@
----
-name: skill-semantic-reconcile
-description: >
-  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 `semantic-decisions.v2` 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 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 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 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.
-- `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 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`, 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`.
-
-<reference>
-
-## Decision Shape
-
-Accept a prepared `default_decision` with the compact form:
-
-```yaml
-schema_version: "semantic-decisions.v2"
-decisions:
-  - item_id: claim-001
-    accept_default: true
-```
-
-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: "semantic-decisions.v2"
-decisions:
-  - item_id: claim-001
-    relation: near_duplicate
-    action: merge_update
-    target:
-      node: payment-runtime
-      section_id: section-3
-    proposed:
-      content: "Runtime isolation uses sandboxing to avoid state pollution."
-      confidence: confirmed
-      source_ref: "src-2#runtime L12-14@7a6f4c9d2e10"
-    rationale: "The new evidence clarifies the same claim."
-```
-
-`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.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. |
-
-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>
-
-<procedures>
-
-### Step 1 — Consume Prepared Context
-
-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.
-
-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
-
-Classify each item against the prepared evidence:
-
-- 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`.
-
-Drop-mode-only branches (`reanchor`, `split_then_reanchor`, `remove_unsupported`) live in [references/mode-semantics.md](references/mode-semantics.md).
-
-### Step 3 — Emit Decisions
-
-Emit one document with `schema_version: "semantic-decisions.v2"` 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`. Follow [references/leakage-and-ownership.md](references/leakage-and-ownership.md): regenerate the affected decision using the review diagnostic's explicit repair options and cited item ids, then rerun `context reconcile review`.
-
-### Step 4 — Self-verify
-
-- [ ] 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

@@ -1,31 +0,0 @@
-# Context-only leakage and ownership upgrades
-
-Consult this reference when `context reconcile review` returns diagnostics or cutover hints with `code: "context-only-leakage-high"`. For runs without that code, 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

@@ -1,41 +0,0 @@
-# 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

@@ -1,60 +0,0 @@
-# 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

@@ -1,58 +0,0 @@
-# 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`
-- 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.
-
-## 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
-
-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:
-
-- 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 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.
-
-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.
-
-## 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; 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

@@ -1,71 +0,0 @@
-# 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 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:
-
-- 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 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.
-
-## `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 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`.

package/scripts/build-aspect-runtime.ts

@@ -1,45 +0,0 @@
-import { existsSync } from "node:fs";
-import { mkdir, readFile, writeFile } from "node:fs/promises";
-import { basename, join } from "node:path";
-
-const outdir = join(process.cwd(), "templates", "aspect-runtime");
-await mkdir(outdir, { recursive: true });
-
-const result = await Bun.build({
-  entrypoints: [join(process.cwd(), "src", "aspect-runtime", "index.ts")],
-  outdir,
-  naming: "aspectRunnerSdk.js",
-  target: "node",
-  format: "esm",
-  external: [
-    "remark-gfm",
-    "remark-mdx",
-    "remark-parse",
-    "remark-stringify",
-    "typescript",
-    "unified",
-  ],
-});
-
-if (!result.success) {
-  for (const log of result.logs) {
-    console.error(log);
-  }
-  process.exit(1);
-}
-
-for (const output of result.outputs) {
-  console.log(`  ${basename(output.path)}  ${(output.size / 1024).toFixed(1)} KB`);
-}
-
-const target = join(outdir, "aspectRunnerSdk.js");
-if (!existsSync(target)) {
-  throw new Error(`aspect runtime build did not emit ${target}`);
-}
-
-let content = await readFile(target, "utf8");
-content = [
-  "/* Generated by packages/context-cli/scripts/build-aspect-runtime.ts. Do not edit directly. */",
-  content,
-].join("\n");
-await writeFile(target, content);