@c4a/context-cli 0.6.0-beta.8 → 0.6.1-beta.2

package/plugins/codex/skills/continue/references/internal-procedures/skill-prose-compile/references/internal-procedures/compile-actions/references/action-domain-gates.md

@@ -1,52 +0,0 @@
-# Action and Domain gates
-
-Consult this reference when **`node.node_type` is `action` or `domain`**. For
-`entity` Nodes, ignore this file and follow the main SKILL.md procedure.
-
-## Action Nodes (`node.node_type === "action"`)
-
-Treat the confirmed node type and planned sections as the compile boundary for
-procedural claims. An Action Node exists because align confirmed process
-evidence: steps/phases, trigger -> handling -> result, role collaboration, or a
-repeatable plan. Actor, goal/outcome, repeatability, answerability, trigger,
-step, and phase claims **must** come from the selected planned section
-`source_refs[]`; do not invent process semantics from the title alone.
-
-| Evidence pattern | What it authorizes |
-|---|---|
-| Planned section source refs contain ordered steps, phases, or repeatable handling | `spec` or `example` Sections for procedure content. |
-| Planned section source refs explicitly name actor, goal, outcome, or repeatability | Concise `description` / `spec` Sections using those same refs. |
-| No source ref states a trigger | **No trigger Section.** Write goal or applicability if supported, but do not fabricate a trigger sentence. |
-| Existing structure edge or unresolved relation indicates another Node is required for answerability | Mention only what the current source refs support; keep the relation in structure, not in compile action fields or verbatim body. |
-
-If the planned sections for an `action` node do not contain source-backed
-process evidence, treat that as a structural defect and return to align using
-[structural-challenges.md](structural-challenges.md). Do not invent an action
-body just because the node type is `action`.
-
-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` for the
-unsupported planned section, or return to align so the node can be revised. The
-CLI does not auto-downgrade an Action or choose replacement Entity tags.
-
-## Domain Nodes (`node.node_type === "domain"`)
-
-Treat Domain nodes as grouping surfaces. The domain's scope and child grouping
-are expressed by confirmed `edges[]` and by source-backed planned sections; they
-do **not** authorize new reader-facing facts by themselves.
-
-- Source refs on planned sections may orient coverage of the Domain's range, but
-  only those refs can support reader-facing text.
-- Child relations belong to `structure.yaml` typed edges, not active Sections;
-  do not turn a child list into a Section.
-- Align-time grouping rationale is not evidence. Do **not** turn it into a
-  `description` Section unless the planned source refs state the same claim.
-
-Recall the mount matrix limit: Domain Nodes allow only `description`, `warning`, `principle`, `decision`, `faq`. A spec / example / comparison / incident / changelog landing here is a kind/type mismatch — drop down the priority chain or `skip`.
-
-## How this slots into the main procedure
-
-- **Step 1 — Sanity-check**: after the standard `node.id` / mount-matrix check,
-  run the action/domain inspection above.
-- **Step 2 — Classify**: respect the gate's authorization boundary when picking kinds.
-- **Step 5 — Self-verify**: confirm no Section was written from evidence the gate disallowed.

package/plugins/codex/skills/continue/references/internal-procedures/skill-prose-compile/references/internal-procedures/compile-actions/references/notes.md

@@ -1,48 +0,0 @@
-# Note snippets
-
-Consult this reference only when the current CLI exposes note evidence in a
-source-bound phase view. Note evidence carries conversation material
-(revisions, decisions, brainstorms) rather than primary source documents.
-
-## TL;DR
-
-Note snippets are **prioritization hints, not write authority**. `note_intent`, `anchored_to[]`, and `revision_kind` may suggest update / replacement / complement / skip, but they never authorize a write without semantic review.
-
-## How to route a note snippet
-
-When a source evidence entry has `source_type: "note"`:
-
-1. **Compare against the anchor first.** If `anchored_to[]` names this Node or one of its Sections, treat that target as the candidate for `update` / replacement review / `add` (as a complement) / `skip`. **Do not create a new Node** from the note title here — that is an align-time concern.
-
-2. **Use `note_intent` and `revision_kind` to bias the action**:
-
-   | `note_intent` | typical action |
-   |---|---|
-   | `revision` | `update` when meaning stays the same; otherwise replacement review against the anchored Section |
-   | `decision` | `add` a `decision` Section when no equivalent exists; otherwise `update` |
-   | `brainstorm` | usually `skip` unless the brainstorm explicitly confirms a fact the Node should record |
-
-   `revision_kind` (`replace` / `clarify` / ...) refines the choice within `revision`.
-
-3. **No-write reviewed-no-write case.** If the note says "don't modify active
-   knowledge yet" or the correct outcome is no-write after review, emit `skip`
-   with the note's current `source_refs[]` when the CLI exposes them. This lets
-   semantic review record `reviewed_no_write` instead of treating the skip as an
-   unreviewed no-op.
-
-4. **Bare skip is not allowed for notes.** A bare `skip` (no evidence) is only
-   for deterministic no-op cases such as unchanged input or pure navigation.
-   Notes always carry an anchor and an intent; the skip must cite the note's
-   explicit source ref when the current CLI exposes one.
-
-## Where this lives in the main procedure
-
-- **Step 2 — Classify**: run the note-first comparison **before** the generic kind priority chain. If the note resolves to `update` / replacement review / `skip` (reviewed), record the current action or user/structure route and move on; do not also process the same note through the generic chain.
-- **Step 5 — Self-verify**: every note snippet was either consumed by an
-  anchored action or carried into a `skip` with `source_refs[]` when the current
-  CLI exposes citeable refs.
-
-Notes never become compile challenge actions on their own. If a note describes a
-structural problem (missing Action, wrong parent, etc.), capture or cite the
-underlying source evidence and return to the structure gate described in
-`references/structural-challenges.md`.

package/plugins/codex/skills/continue/references/internal-procedures/skill-prose-compile/references/internal-procedures/compile-actions/references/refresh-and-update.md

@@ -1,85 +0,0 @@
-# Refresh and update
-
-Consult this reference when **any** of the following holds:
-
-- `existing.sections[]` is non-empty (Node already has active knowledge; this is a refresh, not a first compile).
-- `incremental.status` is `unchanged` or `full-context` (non-default incremental signals).
-- `incremental.locator_only_changes[]` is non-empty (locator-only deltas without content changes).
-
-For first compile of a fresh Node with `incremental.status === "changed-only"`, skip this file.
-
-## Incremental status handling
-
-| `incremental.status` | What to do |
-|---|---|
-| `changed-only` (default) | Normal path — main SKILL.md procedure applies as written. |
-| `unchanged` | Emit exactly one `skip` action with a brief reason. Do not iterate snippets. |
-| `full-context` | Draft from the full fallback. **Preserve `unknown_inputs[]` reasons** in any abort/retry explanation so the caller sees why the fallback was needed. |
-
-The CLI may deterministically skip unchanged output or update locator-only evidence before writing. **Do not force artificial content changes to bypass fingerprint skip** — those skips are part of the protocol, not a problem to route around.
-
-## Locator-only changes
-
-`incremental.locator_only_changes[]` entries always carry `agent_action: "none"` and `handled_by: "compile-close"`. **Do not emit a draft action for those Sections** unless the same Section also appears in `changed_blocks[]` with a real content change.
-
-## Reconciling with `existing.sections[]`
-
-When `existing.sections[]` is non-empty, every section id you read here is a
-potential same-section `update` target or a signal that the structure/user gate
-must decide a higher-risk replacement or withdrawal. Walk the existing Sections
-in order and decide:
-
-| Raw evidence vs existing Section | op |
-|---|---|
-| Raw still supports the existing claim unchanged | Emit nothing (or one summarising `skip`) |
-| Raw clarifies or rephrases without changing meaning | `update` — same `section-N` stays active |
-| Raw changes meaning (new spec value, reversed decision) | Stop and route to user/structure review; do not emulate a replacement with `update` |
-| Raw removes the supporting evidence | Stop and route to user/structure review; do not hide the previous active section with a compile no-write |
-
-### Replacement vs `update` semantics
-
-Replacement preserves the audit trail so readers can see that the prior policy
-changed — **critical for specs / decisions / principles**. Use `update` only
-for typo / wording fixes / detail additions that do not change meaning. When
-meaning changes or support disappears, do not write a compile action until the
-user/structure gate has chosen the intended disposition.
-
-### Current output mechanics
-
-- `update` keeps the same planned section identity. In the current
-  `context.compile-actions.v1` shape, emit `op: "update"` with `section_id`,
-  `kind` when needed, `summary` when useful, and current `source_refs[]`. Omit
-  `content` so the CLI mirrors the new cited source span. If the intended update
-  requires translation, compression, or reorganization, stop and return to the
-  structure/user gate instead of writing reader-visible content in compile.
-- Fresh replacement content is a new structure/review decision, not a current
-  compile write shape. Preserve the semantic judgment in the user report or
-  unresolved structure discussion and route back to the appropriate gate; do
-  not invent unsupported target fields.
-
-## Output shape (current update path)
-
-```jsonc
-{
-  "schema_version": "context.compile-actions.v1",
-  "view_ref": "architecture:entity/example",
-  "actions": [
-    {
-      "op": "update",
-      "section_id": "retention-policy",
-      "kind": "spec",
-      "summary": "...",
-      "source_refs": ["file:docs/example.md#span:retention L10-14@<span-hash>"]
-    }
-  ]
-}
-```
-
-## How this slots into the main procedure
-
-- **Step 1 — Sanity-check**: when `existing.sections[]` is non-empty, read every section id and status before classifying snippets. When `incremental.status` is `unchanged`, short-circuit with one `skip`.
-- **Step 2 — Classify**: still walk the kind priority chain for each citation-eligible snippet; the reconciliation table above governs which `op` to emit for snippets that map to an existing Section.
-- **Step 5 — Self-verify**: every `update` targets a known planned section id
-  from the confirmed structure. If a replacement or withdrawal judgment has no
-  accepted compile action shape, stop and route back through review/align
-  instead of emitting unsupported fields.

package/plugins/codex/skills/continue/references/internal-procedures/skill-prose-compile/references/internal-procedures/compile-actions/references/structural-challenges.md

@@ -1,73 +0,0 @@
-# Structural and ownership challenges
-
-Consult this reference when the cited evidence **cannot be written as a Section under the current confirmed structure**:
-
-- The evidence describes a coherent process that should be its own `action` Node (not a Section here).
-- The evidence implies a missing `depends_on` edge between Nodes.
-- The evidence belongs under a different parent Node.
-- A finalized shared-block split leaves this Node with only secondary, non-citable evidence.
-- A visible `context_only` or secondary-shared block contains facts that need citation, requiring an ownership upgrade.
-
-In these cases, do **not** force the content into a Section. The current
-`context.compile-actions.v1` schema does not accept challenge actions. Stop the
-compile draft for this Node, report the structure defect, and return to the
-prose align gate so the structure can be revised as `unresolved[]`, a corrected
-node, a corrected section plan, or a typed edge.
-
-## When to challenge vs. when to skip
-
-| Situation | Route |
-|---|---|
-| Evidence is a repeatable procedure with steps that clearly warrant a sub-Action | Return to align and propose a new or corrected `action` node. |
-| Evidence depends on a Node that the current structure does not link to this Node | Return to align and add a source-backed typed edge such as `depends_on`, `prerequisite`, or `applies_to`, or keep it in `unresolved[]` when evidence/target is incomplete. |
-| Evidence belongs under a different parent | Return to align and move the planned section source refs to the correct node. |
-| The planned section has no primary source-backed evidence for this Node | Return to align and revise section ownership/source refs, or remove the node if it should not exist. |
-| The Node should not exist because its evidence belongs elsewhere | Return to align and remove or replace the node before compile. |
-| Background/context evidence holds facts this Node needs to cite | Return to align and make those source refs owned by the correct planned section, or keep the issue unresolved. |
-
-Use challenge labels only as private reasoning labels in your user explanation.
-Do not put them in `context.compile-actions.v1`.
-
-## Report shape
-
-When this reference triggers, do not submit a compile payload for the affected
-Node. Report a compact structure repair request to the user and the align gate:
-
-```jsonc
-{
-  "reason_code": "structure_reconfirmation_required",
-  "issue": "missing_action_node",
-  "view_ref": "<matches selected view_ref>",
-  "summary": "The cited evidence is a repeatable procedure.",
-  "source_refs": ["file:docs/runbook.md#span:ops L40-55@<span-hash>"],
-  "align_repair": "Add a supported action node or keep the issue in unresolved[]."
-}
-```
-
-The actual committed repair is a revised `context.structure.v1` payload. Use
-the align schema and validation diagnostics for that repair; do not invent a
-compile action shape.
-
-## What these are NOT
-
-- **Not a substitute for `skip`** when raw simply has no write-worthy fact for this Node.
-- **Not a Section.** Structure defects never appear in active knowledge.
-- **Not a compile action.** Do not encode them as `op` values in
-  `context.compile-actions.v1`.
-- **Not a free retargeting path.** Do not switch `view_ref`, `section_id`, or
-  `source_refs[]` inside compile merely to make validation pass. The confirmed
-  structure must be repaired first.
-- **Not a free upgrade path.** Exact text views expose visible evidence text for
-  inspection, but they do not change section ownership. If you need to cite
-  background content, return to align and revise ownership/source refs.
-
-## How this slots into the main procedure
-
-- **Step 3 — Build actions**: when evidence implies a missing Action, missing
-  edge, wrong parent, or needed ownership/source-ref repair, stop the compile
-  draft for this Node and return to align instead of writing a Section.
-- **Step 5 — Self-verify**: no Section write cites source refs outside the
-  planned section ownership; if any did, remove the action and return to align.
-- **Review handoff**: if a user asks why compile stopped, explain the structure
-  effect plainly: paths, ownership, and relations are frozen at compile time, so
-  these repairs need a new confirmed structure rather than a draft-page patch.