@c4a/context-cli 0.6.1 → 0.6.3

package/plugins/cursor/skills/skill-prose-align/references/internal-procedures/structure-planning/references/gates.md

@@ -1,263 +0,0 @@
-# Node Classification Gates
-
-Use these gates before every structure draft and before authoring the align
-payload described by the current schema view.
-Align owns Node type, tag, graph, planned Section, and ownership classification. It does **not** write Section prose.
-
-Current schema mapping:
-
-- Treat the action checklist, domain checklist, and inference tables as private
-  working notes unless the current schema view explicitly exposes matching
-  fields.
-- In `context.structure.v1`, persist the outcome through `node_type`, `tags`,
-  `summary`, `ownership`, `sections[].source_refs`, `edges[]`, and
-  `unresolved[]`.
-- Do not add unknown gate fields to the payload just because this procedure uses
-  them for reasoning.
-
-## Node Type Order
-
-Answer in this order and stop at the first match:
-
-1. **Action?** A large executable event / process with both:
-   - scale: can support `planned_sections` with at least two distinct Section kinds, or contains at least one child Action;
-   - process evidence: explicit steps, phases, trigger -> handling -> result, role collaboration, or repeatable plan. Parallel lists such as "three API modes" are not process evidence.
-   Single-section user-story / scenario / incident records may be meaningful to
-   a human reader, but the CLI does not infer that exception from source prose.
-   If the structure cannot express at least two distinct Section kinds or a
-   child Action, keep the material as a Section under the owning Node.
-2. **Entity?** A concrete independent subject with retrieval value: deployable code, product/application/system, library/module/CLI/symbol, or an atomic term/pattern.
-3. **Domain?** A container/scope that groups at least one child Node.
-4. Otherwise do not create a Node; leave the material for compile as a Section under the owning Node.
-
-Good examples:
-
-| Type | Examples |
-|---|---|
-| `domain` | "X business domain", "Y technical area", "Z research topic" |
-| `entity` concrete | `@acme/api-server`, `@acme/ui-kit` `Button`, "X sub-application" |
-| `entity` term | "X identifier", "Y business metric", idempotency |
-| `action` | "user submits X request end-to-end flow", "operator executes Y change flow", "team Z release flow" |
-
-## Title and Source Heading Rules
-
-Classify the Node by the evidence referent, not by the source file title, heading, or local section title. A source title is ordinary evidence just like body prose. It has no automatic right to become `node.title`, `aliases[]`, or `slug`.
-
-After choosing `node_type`, choose the title to fit that type:
-
-| Final type | Title shape |
-|---|---|
-| `entity` concrete | The concrete product, service, library, module, CLI, symbol, application, or system name. |
-| `entity` term | The atomic concept or pattern name, without extra scope/process suffixes. |
-| `domain` | The grouping scope that owns child Nodes. |
-| `action` | The executable process / runbook / flow name that passed the Action Gate. |
-
-Scope/process words in a source title are warning signals when proposed as an Entity title, not hard classification rules. Re-check the type/title when a proposed Entity title contains words such as "方案", "架构", "体系", "演练", "流程", "策略", "能力", "机制", "framework", "architecture", "system", "strategy", "process", or "drill". Keep the wording only when evidence shows it is the formal name of a concrete object or an atomic term.
-
-Do not promote broad architecture/system/方案 content to `domain` just because it sounds like a scope. When the source has writable Sections but no resolvable current/existing child Nodes, use an Entity such as `[system]` or `[application]` and put the architecture facts in Sections. Use `domain` only when it groups child Nodes through supported `edges[]`.
-
-Relation-only sources should not force title copying or dangling graph edges. Decide placeholder handling in this order:
-
-1. If resolved current/existing child Nodes make the page a real grouping scope, keep the relation evidence as supported `edges[]` only when the Domain also has at least one source-backed planned Section.
-2. If an explicit user-facing retrieval need or graph need makes the source/page identity valuable, and the title names an atomic concept or concrete object, keep that identity in `unresolved[]` until it has source-backed section evidence, a valid generated `parent_index` view with source-backed `contains` edges to child views, or a compile-time `skip` decision. Do not submit root-level `planned_sections: []` or ordinary source-bound `sections: []`.
-3. Otherwise, skip navigation-only / placeholder-only material; keep a short
-   `unresolved[]` note only when the deferred relation remains useful.
-
-Do not create a hidden domain-gate object. A kept placeholder needs support:
-source refs, approved graph support, or explicit user-confirmed retrieval value.
-For Domain placeholders, write only resolved current/existing children as typed
-`edges[]`; if all children are unresolved/deferred relation clues, keep those
-target hints in `unresolved[]`. If the source names only an atomic concept and
-that term is useful on its own, prefer a concise term Entity title without
-scope/process suffixes.
-
-For no-write placeholder summaries, describe only the preserved page identity and unresolved navigation clues. Do not say the Node "provides navigation/links/relations to X" unless those targets are resolved graph children or rendered links; say the source contains deferred navigation clues instead.
-
-## Section Promotion Gate
-
-Classify local evidence as a Section before creating a child Node/View. A
-heading, table row, FAQ label, or short sub-topic does not by itself establish a
-standalone page.
-
-Promote a Section to a child View only when at least one condition is supported
-by source evidence:
-
-1. The title is a concrete product/code object/system/module/library, not just a
-   local heading.
-2. The item is an atomic term or pattern that answers standalone lookup
-   questions outside the parent page.
-3. The item clears the Action Gate or Domain Gate.
-4. The source gives it independent article identity: owner/date, lifecycle,
-   timeline, tracking record, or cross-cutting support scope.
-
-Use one content-neutral test for every proposed child View: does cited evidence
-support an independent subject identity, enough context to stand alone, and a
-separate retrieval need? A heading, section kind, collection name, or contains
-edge is not sufficient by itself. The CLI warns when many same-source,
-single-section child Entities look mechanically fragmented, but it does not
-reject a page merely because of its content type.
-
-## Entity Tag Rules
-
-Use `tags` to state what the Entity is. Legal combinations:
-
-| Case | Tags |
-|---|---|
-| Runtime/code object | one A tag: `app`, `service`, `lib`, `cli`, `module`, or `symbol` |
-| Product-analysis object | one B tag: `application` or `system` |
-| Code + product object | one A tag plus one B tag |
-| Pure term / pattern | only `term` |
-
-`term` is mutually exclusive with A/B tags. React is `[lib]`, not `[lib, term]`; if a separate term entry is useful, create another Entity tagged `[term]` and let the structure plan express the relation as a typed edge or unresolved relation with `source_refs[]`.
-
-Do not inherit scope tags mechanically. If a parent Entity is tagged `system` or
-`application`, a child Entity should repeat that tag only when it is itself an
-independent system/application. Local aspects under that parent should either
-use their own shape tag or remain Sections.
-
-## Action Gate
-
-Use `node_type: action` only after the Node Type Order says action. Fill the
-action reasoning checklist in your working notes; persist only fields accepted by
-the current structure schema.
-
-The action probe uses five booleans as a reasoning checklist, but the semantic
-bar is:
-
-| Field | Meaning | Evidence rule |
-|---|---|---|
-| `has_steps_or_phases` | Process evidence exists: steps, phases, trigger -> handling -> result, role collaboration, or repeatable plan. | Hard requirement; support it from span evidence. |
-| `has_actor_or_role` | A user, system, operator, service, or role performs the work. | May be inferred; record the source. |
-| `has_outcome_or_goal` | The process has a target result, acceptance condition, or operational goal. | May be inferred; record the source. |
-| `is_repeatable_or_planned` | The work is repeatable, scheduled, policy-like, or intentionally planned. | May be inferred; record the source. |
-| `queries_answerable_with_refs` | The Node can answer how/when/who/what-to-do questions from cited spans. | May be inferred; record the source. |
-
-Do not emit an Action for a single sentence, a one-off conclusion, a short operation, or a parallel enumeration. Those become Sections under the owning Entity or Domain. The CLI does not infer single-Section Action exceptions from source prose; represent the material with enough structure or keep it as a Section.
-
-Action anti-examples:
-
-| Candidate | Correct routing |
-|---|---|
-| "migrate to X tool" as one conclusion | `decision` Section under the owning Entity |
-| "component X usage" as one sentence | `description` + maybe `example` under X |
-| "submit -> validate -> generate" as one unexpanded sentence | `spec` Section under X/Y |
-| "three API call modes" | `comparison`, `spec`, or `description` Section; not Action |
-
-## Fake Entity Gate
-
-A relationship-style title is only suspicious by itself. Downgrade or change type when at least **two** signals are true:
-
-1. Title contains relationship language such as "X impact on Y", "Y under X", "Y side of X", "X migration", or "X collection".
-2. No legal Entity tag fits.
-3. The Node does not stand alone away from its upstream Node.
-
-Repairs:
-
-| Pattern | Repair |
-|---|---|
-| "X impact on Y" | Section under X plus a typed edge or unresolved relation to Y when the evidence supports it |
-| "Y under X condition" | Section under Y; X is a condition in the Section body |
-| "X subsystem migration" | Action only if it clears the Action Gate; otherwise `decision` Section under X |
-| "X error collection" / "X FAQ collection" | `faq` / `incident` Sections under X |
-
-## Domain Gate
-
-Use `node_type: domain` only for a scope that groups child Nodes. Keep this
-domain reasoning checklist in working notes and persist supported relations through current
-`edges[]` or `unresolved[]`:
-
-| Field | Meaning |
-|---|---|
-| `scope_refs[]` | Source refs that describe the scope boundary or grouping. |
-| `child_refs[]` | Working-note candidate ids, local refs, or final slugs for children in the scope; persist valid ones as `edges[]`. |
-| `grouping_reason` | Why these children belong together under this domain. |
-
-If a domain has no resolvable child refs, no clear grouping reason, or only one same-file child without a broader scope, do not emit a Domain. For navigation-only / placeholder-only sources with only deferred children, skip the Node after ruling out standalone retrieval or graph value for an atomic-term or concrete Entity; keep only useful unresolved relation notes. Emit an Entity only when evidence names an atomic term or concrete object and choose its Entity tag yourself. The CLI rejects invalid Domain gates; it does not auto-downgrade a Domain or choose fallback tags.
-
-Scope-name titles such as "X 业务域", "Y 领域", "business domain", or "technical area" are a warning sign when proposed as Entity. Keep them as Entity only when the subject is an atomic term or concrete object; otherwise use Domain with supported child edges or unresolved relation hints.
-
-## Edge Gate
-
-Use a typed edge only when all four checks pass:
-
-1. Both `from` and `to` nodes exist in the current structure or approved
-   knowledge.
-2. The relation type is in the current closed set (`is_a`, `contains`,
-   `depends_on`, `corresponds_to`, `causes`, `triggers`, `prerequisite`,
-   `applies_to`, `verified_by`, `supersedes`).
-3. `source_refs[]` cite evidence for the relation itself, not just for one
-   endpoint.
-4. The relation is stronger than a vague "related" hint.
-
-If any check fails, write an `unresolved[]` item instead of an edge.
-
-If the source sentence states the relation with uncertainty, keep the edge only
-when the uncertainty is source-authored and preserved through
-`confidence: possible` or `confidence: hypothesis`. Do not use `confidence` for
-Agent uncertainty. If you are uncertain whether the evidence supports the
-relation, write `unresolved[]` instead.
-
-## Inference Sources
-
-Inference sources are working notes for the action reasoning checklist; do not
-persist this object unless the current schema explicitly exposes it:
-
-```yaml
-inference_sources:
-  actor:
-    source_type: explicit-span
-    source_refs: ["file:docs/runbook.md#span:steps L10-18@<span-hash>"]
-    rationale: "The span names the operator role."
-  outcome_or_goal:
-    source_type: inferred-from-span
-    source_refs: ["file:docs/runbook.md#span:steps L10-18@<span-hash>"]
-    rationale: "The span describes recovery as the expected result."
-  repeatability_or_plan:
-    source_type: heading-and-span
-    source_refs: ["file:docs/runbook.md#span:steps L10-18@<span-hash>"]
-    rationale: "The runbook heading and ordered list indicate planned reuse."
-  answerability:
-    source_type: explicit-span
-    source_refs: ["file:docs/runbook.md#span:steps L10-18@<span-hash>"]
-    rationale: "The steps answer how the operation is performed."
-```
-
-Allowed `source_type` values:
-
-| Value | Use when |
-|---|---|
-| `explicit-span` | The evidence span directly states the signal. |
-| `heading-and-span` | The heading plus span text together support the signal. |
-| `ref-node` | An existing or same-decision Node reference supplies the signal. Include `ref_nodes`. |
-| `inferred-from-span` | The signal is inferred from span content. Keep the rationale short and concrete. |
-
-Each source must include `rationale` when inferred and at least one of `source_refs[]` or `ref_nodes[]`.
-
-## Final Reflection
-
-- Entity cannot pick a legal tag, or depends on its upstream title to make sense -> write it as a Section under the upstream Node or change type before submit.
-- Action only supports one Section -> write it as a Section instead of an Action, or add source-backed structure that reaches at least two distinct Section kinds / one child Action. The CLI does not use source prose keywords to grant an exception.
-- Action "steps" are parallel options/configs -> route to Entity `comparison` / `spec` / `description`.
-- Domain has no children -> delete it or merge it into a larger Domain.
-
-## Current CLI Quality Diagnostics
-
-Current `context.structure.v1` validation preserves the old Node quality
-checks as deterministic diagnostics:
-
-| Diagnostic | Meaning | Required response |
-|---|---|---|
-| `schema.section_kind_invalid` | A planned Section uses a kind outside the current prose kind set. | Replace it with a kind from the schema view; do not invent local kind names. |
-| `schema.section_kind_mount_invalid` | A planned Section kind cannot be mounted on the chosen `node_type`. | Choose a kind allowed by the mount matrix, or reclassify the Node before confirming structure. |
-| `tags.term_conflict` | An Entity uses `term` together with concrete runtime/product tags such as `lib`, `service`, `application`, or `system`. | Split the term from the concrete object, or remove the conflicting tag before staging. |
-| `node.description_dominates` | A non-Action Node has at least half of its planned Sections as `description`. | Re-run kind precision. Keep it only when source evidence is genuinely narrative; otherwise split into `example`, `spec`, `comparison`, `faq`, `incident`, `decision`, `warning`, or `principle`. |
-| `node.thin_concrete_entity` | A concrete Entity has one Section and no child Nodes. | Keep it only when it has stable standalone retrieval value; otherwise merge it into the owning Node. |
-| `node.children_should_be_sections` | One parent contains many same-source, single-section child Entities with no stable shape tag. | Merge those children into parent Sections unless the user confirms each child has standalone lookup value. |
-| `node.term_expanded_beyond_definition` | A `term` Entity has grown past a compact definition or owns children. | Move rules, procedures, designs, and examples to the owning Node; keep the term entry narrow. |
-| `node.action_too_thin` | An Action has fewer than two distinct planned Section kinds and no child Action. | Downgrade it to a Section under the owning Node, add a distinct Section kind, or add a child Action; the CLI does not infer a single-section exception from source text. |
-| `node.domain_without_children` | A Domain has no source-backed `contains` child edge. | Add supported children, keep an explicitly confirmed no-write placeholder, or reclassify the Node. |
-| `tags.child_inherits_system` | A child Entity repeats its parent `system` / `application` scope tag. | Retag by the child’s own shape/scope, or keep the child as a Section if it is only a local aspect. |
-| `edge.confidence_invalid` | An edge declares a confidence value outside the current schema. | Use only `possible` or `hypothesis`, or omit the field for source-certain relations. |
-
-Warnings are not automatic blockers, but they are not suggestions to ignore.
-Resolve them or include the user-confirmed rationale when confirming structure.

package/plugins/cursor/skills/skill-prose-compile/SKILL.md

@@ -1,287 +0,0 @@
----
-name: skill-prose-compile
-description: >
-  Internal procedure invoked by the public Context continuation entry; not a user command.
-  Uses confirmed Context document structure to create source-bound draft prose
-  candidates through `context.compile-actions.v1`, without reading raw
-  snapshots directly.
-tools:
-  - Bash
----
-
-# skill-prose-compile
-
-Compile confirmed document structure into reviewable draft knowledge.
-
-## TL;DR
-
-- Use this after `context status` reports `structure-ready` or
-  `needs-prose-compile`, or when the user explicitly asks to compile confirmed
-  prose structure into draft pages.
-- The input is already confirmed `context.structure.v1`; do not redesign node
-  ownership, page paths, or relationships here. Return to prose align if those
-  are wrong.
-- Read compile context through CLI views only: `blockers`, `read-plan`,
-  `node-context`, and `schema`. Start with `blockers` for large or recently
-  repaired structures; if it returns section blockers, return to prose align
-  instead of drafting compile actions. Use align evidence views only when the
-  compile view or validation output gives a specific source ref that needs exact
-  text.
-- Emit `context.compile-actions.v1`; the CLI mirrors source spans, derives
-  `content_mode`, writes review candidates, and enforces source-bound evidence.
-- The `summary` field in each action is the Agent-authored behavior half only:
-  compact source-backed recall text for the cited section. The CLI separately
-  renders the reachability half from confirmed typed edges into review metadata;
-  do not invent edge summaries or relation fields in the action payload.
-- Default to omitted `content` so the CLI mirrors the cited source span.
-  Do not write explicit `content`. If the evidence cannot be represented as a
-  faithful mirrored continuous span, split the section or return to prose align
-  for a confirmed structure change.
-- Before semantic judgment, use the CLI `semantic-rules` View to page through
-  only `semantic_rules.required`; selection `reason` explains why each rule is
-  needed for the current node.
-- Do not produce or validate compile actions from this entry file alone. A
-  ruleset already present in the active context may be reused only when both its
-  `handle` and `digest` match. If the context was compacted, the digest changed,
-  or the rule content is no longer present, resume the CLI rule-page sequence.
-
-<reference>
-
-## User-Facing Gates
-
-Use semantic labels, not SDK function names:
-
-| Gate | Say this | Do not say this first |
-|---|---|---|
-| Compile context | "I will inspect the confirmed structure and each node's planned evidence before drafting sections." | `node-context`, `context.compile-actions.v1` |
-| Source-bound draft | "I will mirror supported source spans into reviewable draft pages and attach summary/kind metadata." | `compileProse` |
-| Non-mirror evidence | "This section cannot be compiled as-is because the evidence is not one faithful source mirror; we need to split or revise the structure." | "The agent can rewrite this automatically." |
-| Structure mismatch | "This compile cannot proceed because the confirmed structure no longer matches the evidence; we need to return to structure confirmation." | Editing `knowledge/` or `unapproved/` directly |
-
-## Runtime Discipline
-
-`skill-continue-workflow` owns global state routing; this Skill owns only the
-compile phase selected by that route. Use CLI context/rule/diagnostic Views and
-their exact continuation commands. Hints are subordinate to `next_action`.
-Never inspect CLI-managed state files as a substitute for a View.
-- Compile `read-plan`, `blockers`, `node-context`, and `schema` Views are
-  workspace-read-only and may be fetched in parallel. `--validate`, `--stage`,
-  structure confirmation, Review apply, and close remain serial mutations.
-- One planned Section produces one compile action. When evidence contains
-  independently retrievable units, split them into sibling Sections in align;
-  do not split one planned Section into several compile actions.
-- One write still means one View, not one human Review. Stage every View in the
-  same confirmed structure sequentially, follow `continue_compile_batch`, and
-  open Review only after the CLI reports that the whole batch is prepared.
-- Compile does not get a second, looser rule set. If a rule conflicts with the
-  current CLI schema or diagnostics, follow the CLI and repair the payload.
-- Write digest/hash flags are stale guards. Use values returned by the CLI; do
-  not parse stdout fragments or host tool-result files to reconstruct them.
-- If a payload is too large for a heredoc, stage it under
-  `.tmp/agent-payloads/<run-id>/...` in the workspace root and redirect stdin
-  from that file. Never reuse fixed `/tmp/c4a-*` names, and never place agent
-  scratch payloads under CLI-managed `.tmp/context-cli/`, `sources/`,
-  `unapproved/`, `knowledge/`, `dist/`, review output, or package output
-  directories.
-
-## Compile Views
-
-Recommended read order:
-
-```bash
-context run compile:<type>:<source>:<collection> --view blockers --format json
-context run compile:<type>:<source>:<collection> --view read-plan --format json
-context run compile:<type>:<source>:<collection> --view node-context --source <view-ref> --format json
-context run compile:<type>:<source>:<collection> --view schema --format json
-```
-
-Use CLI-returned `available_view_refs`, `planned_sections`, `local_sources`, and
-`next_action.command`. If `blockers.section_blockers[]` is non-empty, repair the
-structure through align first; do not inspect every node or hand-split compile
-actions. Do not reconstruct the structure by opening `unapproved/structure.yaml`
-or `knowledge/structure.yaml` directly.
-
-## Procedure References
-
-These are current compile rules for source-bound drafting, judgment, semantic
-repair, and close handoff.
-
-| Decision | Reference |
-|---|---|
-| Compile action drafting, section kind, coverage, summaries, content intent | [references/internal-procedures/compile-actions.md](references/internal-procedures/compile-actions.md) |
-| Action/domain compile gates | [references/internal-procedures/compile-actions/references/action-domain-gates.md](references/internal-procedures/compile-actions/references/action-domain-gates.md) |
-| Notes, refresh/update, and structural challenges | [references/internal-procedures/compile-actions/references/notes.md](references/internal-procedures/compile-actions/references/notes.md), [references/internal-procedures/compile-actions/references/refresh-and-update.md](references/internal-procedures/compile-actions/references/refresh-and-update.md), [references/internal-procedures/compile-actions/references/structural-challenges.md](references/internal-procedures/compile-actions/references/structural-challenges.md) |
-| Support, duplicate, replacement, conflict, weak evidence, and relation judgment | [references/internal-procedures/compile-judgment.md](references/internal-procedures/compile-judgment.md), [references/internal-procedures/semantic-judgment.md](references/internal-procedures/semantic-judgment.md) |
-| Leakage, ownership, temporal evidence, disposition, omit, and user confirmation | [references/internal-procedures/semantic-judgment/references/leakage-and-ownership.md](references/internal-procedures/semantic-judgment/references/leakage-and-ownership.md), [references/internal-procedures/semantic-judgment/references/temporal-and-evidence.md](references/internal-procedures/semantic-judgment/references/temporal-and-evidence.md), [references/internal-procedures/semantic-judgment/references/disposition-semantics.md](references/internal-procedures/semantic-judgment/references/disposition-semantics.md), [references/internal-procedures/semantic-judgment/references/scope-review-and-omit.md](references/internal-procedures/semantic-judgment/references/scope-review-and-omit.md), [references/internal-procedures/semantic-judgment/references/user-confirmation.md](references/internal-procedures/semantic-judgment/references/user-confirmation.md) |
-| Close gate and current close output boundaries | [references/internal-procedures/close-gate.md](references/internal-procedures/close-gate.md) |
-
-## Compile Contract
-
-The compile action payload uses `schema_version: context.compile-actions.v1`.
-Compile may:
-
-- mirror source spans as `verbatim`;
-- emit `skip` decisions when no source-backed body should be written. `skip`
-  does not produce a placeholder candidate; generated parent-index pages use
-  the parent-index compile path, not an action payload placeholder.
-
-Relationships and cross references do not go into verbatim body. In current
-output they stay in `structure.yaml` typed edges; this workflow does not render
-relationship reference blocks.
-
-</reference>
-
-<procedures>
-
-### Step 1 — Open Compile Context
-
-Run:
-
-```bash
-context run compile:<type>:<source>:<collection> --view blockers --format json
-context run compile:<type>:<source>:<collection> --view read-plan --format json
-```
-
-Use the returned blockers, node list, source overview, and next action. If the
-blockers view reports section blockers, return to prose align and repair the
-confirmed structure before compile. If the CLI says the structure is missing,
-unconfirmed, stale, frozen against the wrong snapshot, or invalid, return to
-prose align or source capture as indicated.
-
-### Step 2 — Inspect One Node
-
-For each node that should become draft knowledge, run:
-
-```bash
-context run compile:<type>:<source>:<collection> --view node-context --source <view-ref> --format json
-context run compile:<type>:<source>:<collection> --view schema --format json
-context run compile:<type>:<source>:<collection> --view semantic-rules --source <view-ref> --format json
-```
-
-Follow the semantic-rules `next_action.command` pages before classifying section
-kind, summary, support, skip/update, weak evidence, or structure repair. Do not
-load rules outside the returned required set.
-
-Do not treat those references as optional background. They are the current
-compile drafting, judgment, and semantic-repair procedures.
-
-When exact evidence text is needed, use the CLI-returned source ref with the
-current evidence view. Do not open snapshot files directly.
-
-### Step 3 — Draft And Validate Actions
-
-Create a `context.compile-actions.v1` payload for the selected view. Prefer
-omitted `content` with `source_refs[]` so the CLI mirrors source spans.
-If the source evidence is non-contiguous or contains separable examples,
-configuration blocks, lists, or procedures, split the compile actions when the
-confirmed structure supports that split. If the structure is too coarse, return
-to prose align and ask the user to confirm a section split instead of writing
-summarized body text. Explicit `content` / `content_intent` is not part of the
-current compile contract.
-
-For small payloads, use stdin/heredoc. For larger payloads, write a scratch file
-under `.tmp/agent-payloads/<run-id>/` and pass it through `--input`. Scratch
-files are disposable agent working files; they are never compile state and must
-not be read back as a substitute for CLI views.
-
-Validate:
-
-```bash
-context run compile:<type>:<source>:<collection> --validate --input <compile-actions.yaml> --format json
-```
-
-Repair diagnostics by routing them to the right decision:
-
-- source ref or planned-section mismatch -> reread node-context, or return to
-  structure confirmation if ownership is wrong;
-- unsupported kind or op -> use the schema view and current compile references;
-- explicit content -> omit `content` and mirror source, or return to align for
-  a section split;
-- weak evidence, duplicate, conflict, omit, or scope issue -> use the compile
-  judgment / semantic judgment references and ask the user when required;
-- frozen structure mismatch -> rerun status and return to align/capture as
-  directed.
-
-Use typed diagnostics as the repair contract:
-
-- `reason_code`, `path`, and `missing[]` identify what to fix;
-- warnings are not write blockers unless the response marks them blocking or
-  the next action says so;
-- weak evidence, duplicate, conflict, temporal, leakage, ownership, and scope
-  issues are semantic review issues, not formatting problems;
-- raw/source-ref pointer diagnostics are evidence checks, not content-quality
-  judges.
-
-When validation returns a new `next_action.command`, follow that exact command.
-When it returns blocking diagnostics without a write command, repair and
-validate again. Do not stage a compile payload just because the YAML shape looks
-valid.
-
-### Step 4 — Stage Draft Candidates
-
-Stage only after validation has no errors:
-
-```bash
-context run compile:<type>:<source>:<collection> --stage --input <compile-actions.yaml> --format json
-```
-
-After staging, follow `next_action` exactly:
-
-- `continue_compile_batch` with `human_gate=false`: move to the returned next
-  View and repeat **Step 2–4**. Do not open Review yet.
-- `review_candidates` with `human_gate=true`: every planned View in this
-  confirmed structure slot is prepared; return to `context status`. If
-  `pendingStructureTargets` is non-empty, complete those slots first. Delegate
-  one collection-level Review to
-  `../skill-review-gate/SKILL.md` only when status
-  reports the complete multi-slot round ready.
-- Use `status.structureBatch` as the complete slot overview. Its evidence Views
-  are parallel-safe, its structure mutations are serial, and Review opens once
-  after all declared slots are prepared.
-
-The CLI blocks Review and close while confirmed Views remain unprepared. Do not
-turn sequential View writes into sequential user approvals.
-
-### Step 5 — Close Handoff
-
-After the single collection-level batch review apply, return to `context status`. If status says
-`compile-close-needed`, run deterministic close:
-
-```bash
-context close --format json
-```
-
-Close derives `knowledge/structure.yaml` and edge projection from approved
-knowledge, then runs the final verify gate. It must not rewrite approved
-verbatim body. References, changelog, package index, and section fingerprint
-rebuilds are not current close output.
-
-Then route to package output when status reaches `ready-to-build`.
-
-### Step 6 — Self-verify Checklist
-
-- [ ] Compile started from confirmed structure, not a new structure proposal.
-- [ ] Node context and schema came from compile phase views.
-- [ ] Compile references were read before choosing kind/summary/support.
-- [ ] Actions mirror source by default and do not invent body text.
-- [ ] No explicit reader-visible `content` was written by the Agent.
-- [ ] Relationships are expressed as structure edges, not inserted into
-  verbatim text.
-- [ ] No direct edits were made to `sources/`, `.tmp`, `unapproved/`,
-  `knowledge/`, review HTML, or `dist/`.
-- [ ] Every planned View was staged before opening the one batch Review.
-
-### Final Report
-
-Report in the user's language. Include only:
-
-- view refs compiled in this round;
-- candidate ids staged and whether they contain verbatim or empty sections;
-- validation warnings that still matter for review;
-- whether review, close, verify, or build is the next status route.
-
-Do not report internal payload digests, source-ref hashes, internal workspace
-paths, absolute paths, scratch file paths, or raw CLI JSON unless the user asks
-for debug output.
-
-</procedures>