@c4a/context-cli 0.6.1 → 0.6.2

package/plugins/cursor/skills/skill-prose-compile/references/internal-procedures/close-gate.md

@@ -1,132 +0,0 @@
----
-name: close-gate
-description: >
-  Internal procedure invoked by the current compile/continue flow; not a user
-  slash command. Runs after review apply. Triggers `context close --format json`,
-  which derives knowledge/structure.yaml, projects approved edges, and runs the
-  final verify gate. Agent intervention is limited to interpreting CLI output
-  and routing verify errors back to source capture, align structure, compile
-  actions, or review as appropriate. The skill never hand-edits rendered
-  knowledge.
-tools:
-  - Bash
----
-
-# close-gate — approved structure projection + final verify
-
-Close a compile run. The CLI does the work; the skill reads the
-CLI's output and routes any failure back to the correct upstream
-command. It does not hand-edit rendered knowledge.
-
-## TL;DR — Non-negotiables
-
-- CLI-driven. `context close --format json` derives `knowledge/structure.yaml`,
-  projects approved edges, and verifies the final workspace including edge
-  source refs. Use the command's stdout + exit code; that's the close's full
-  output.
-- **Agent NEVER edits rendered knowledge from the close stage.** The CLI is the
-  sole writer for approved structure projection. If verify reports an error
-  here, route it back, not around:
-  - Content / Section issues → re-run the current compile gate for the affected
-    node after fixing compile actions.
-  - Structural issues → return to the align structure gate and reconfirm.
-  - Source/evidence issues → recapture the affected source, then rerun align or
-    compile as status instructs.
-- Exit 0 → summarise approved node count, approved edge count, structural edge
-  contract status, and verify status. References, changelog, package index,
-  section fingerprints, and full incremental cache rebuilds are not current
-  close output.
-- Exit 2 → report the full issue list verbatim + point at the right re-entry command above. Do not hand-open the affected rendered article.
-- Materialized knowledge means approved Markdown plus its approved
-  `knowledge/structure.yaml` projection. A compile skip action records reviewed
-  evidence, but it does not by itself materialize an arbitrary finalized Node.
-- Never re-run compile actions from close to paper over verify failures. Draft
-  failures belong in the compile loop.
-- Do not use Python, Node.js, shell scripts, `ls`, `find`, `rg`, `cat`, or similar ad-hoc commands to inspect `sources/`, `unapproved/`, `knowledge/`, or `dist/` files.
-- Current close can self-heal stale or malformed `knowledge/structure.yaml`
-  projection by deriving it again from approved Markdown and approved edge
-  sources. It must not rewrite verbatim section body.
-- LLM-assisted repair (`--fix-with-llm`) is not a current close action.
-- Output language: summary prose matches the user's language; CLI output, issue codes, file paths stay as printed.
-- Current align state is internal CLI state, not a file protocol. The CLI owns
-  this lifecycle — the agent must not move, delete, or archive workspace output
-  files by hand.
-- Semantic decisions are applied and recorded before close. Compile-close does
-  not judge or rewrite semantic decisions; it only verifies the already-applied
-  workspace and rebuilds approved structure projection.
-
-<reference>
-
-## Stages inside `context close --format json`
-
-Close is one in-process command with one exit code:
-
-1. **Approved knowledge scan** — reads approved Markdown only through CLI
-   project readers.
-2. **Structure projection** — writes deterministic `knowledge/structure.yaml`
-   with nodes, approved edge projection, input hash, and structural edge
-   contract status.
-3. **Workspace verify** — runs the final verify gate. Any error prevents close
-   readiness.
-4. **Status receipt** — reports whether close is ready and which upstream gate
-   owns any failure.
-
-## Outcome routing
-
-| Outcome | Agent action |
-|---|---|
-| Ready, verify pass | Summarise approved nodes, approved edges, structural edge contract, and verify status. Stop. |
-| Ready, verify warnings only | Summarise warning codes and state that build may proceed when warnings are allowed by status/build gate. |
-| Verify error in approved section content/evidence | Surface the issue list and route back to compile actions or source recapture as indicated by status. Do not edit approved Markdown. |
-| Verify error in approved structure projection | Run `context close --format json` once more only when status says the projection is close-repairable; otherwise return to align structure. |
-| Source/evidence stale or missing | Route to source capture/refresh, then rerun align/compile as status instructs. |
-
-The close stage never edits rendered knowledge on the agent side. Every verify
-error routes back to the correct upstream gate (source capture, align
-structure, compile actions, or review), never sideways into a hand Edit. Use
-the CLI issue code and hint printed by `context close --format json` for the
-error→command mapping.
-
-References, changelog, section fingerprints, and package index rebuilds are not
-current close outputs.
-
-</reference>
-
-<procedures>
-
-### Step 1 — Invoke close
-
-Run `context close --format json`. The caller may have already invoked it;
-check for existing output before re-running.
-
-### Step 2 — Interpret
-
-Use stdout + stderr. The exit code selects the path via [Outcome routing](#outcome-routing).
-
-### Step 3 — Route errors to the correct upstream command
-
-For each error in the CLI's report, classify via [Outcome routing](#outcome-routing) and name the re-entry command in your report. Do NOT hand-edit rendered knowledge — that violates the CLI-sole-writer principle and masks the real upstream fix. Specifically:
-
-- Section / content issue → rerun the current compile gate for that node.
-- Structure issue → return to align structure and user confirmation.
-- Source/evidence issue → recapture the affected source, then rerun align or
-  compile as status instructs.
-
-One pass. If the CLI reports multiple errors, list them all and let the user choose the order; do not loop the close stage itself.
-
-### Step 4 — Report
-
-Summarise in the user's language:
-
-- Approved node count.
-- Approved edge count and structural edge contract status.
-- Verify result: pass / pass-with-unverifiable-evidence / fail, with issue
-  codes verbatim.
-
-Stop. Do not auto-invoke follow-on commands.
-
-### Step 5 — Final guardrails
-
-Run close once, surface every error with its re-entry command, and never inspect or edit rendered knowledge outside the CLI.
-
-</procedures>

package/plugins/cursor/skills/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/cursor/skills/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/cursor/skills/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/cursor/skills/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.