@c4a/context-cli 0.6.1 → 0.6.3

package/plugins/codex/skills/continue/references/internal-procedures/skill-prose-align/references/internal-procedures/structure-planning.md

@@ -1,282 +0,0 @@
----
-name: structure-planning
-description: "Internal procedure for the current align gate. Reads CLI-guided align evidence, applies semantic Node classification gates, and emits context.structure.v1 payloads for CLI validation/stage."
----
-
-# Structure Planning Procedure
-
-## TL;DR
-
-Run `context run align:<type>:<source>:<collection> --view read-plan --format json`, follow the top-level `next_action.command` to read the CLI-selected evidence path, produce a `context.structure.v1` structure payload, and continue following top-level `next_action`. The CLI owns route, validation, repair commands, and stage guards; this skill owns only semantic classification and source-bound structure judgment.
-
-<reference>
-
-## Canonical Data
-
-- The current phase view result is authoritative. Branch on `next_action.kind`,
-  execute `next_action.command`, and treat listed views as detail reads rather
-  than a checklist.
-- `allowed_actions[]` describes capabilities on the current view result; it is
-  not a menu of alternate write paths and does not override `next_action`.
-- `agent_hints[]`, when present, are diagnostics. Do not prefer them over
-  top-level `next_action`.
-- Schema names and enum values come from
-  `context run align:<type>:<source>:<collection> --view schema --format json`. Use
-  that schema as the authoring contract for `context.structure.v1`.
-- Existing approved knowledge and `knowledge/structure.yaml` are the lookup
-  registry exposed through current CLI/status/query views. Do not read
-  `knowledge/**` or create a separate registry file.
-- Code projection Nodes are reusable knowledge handles. When document evidence belongs on a code symbol, reuse the code slug instead of creating a parallel document Node.
-- Validation diagnostics are the mechanical structure ownership source of
-  truth. Non-content spans such as navigation references, placeholders, front
-  matter, marker quotes, embed tags, and embedded assets should not become
-  reader-facing Sections unless the evidence itself is the cited knowledge.
-- When relation hints are present, inspect them before finalizing graph
-  structure. Use existing/current matches for typed `edges[]`; keep unresolved
-  target ref/title hints deferred in `unresolved[]` and do not write dangling
-  parent, child, or edge refs. Ordinary source-bound views require at least one
-  source-backed planned section. The only empty-section exception is a generated
-  parent index view: it must use `generated: parent_index`, `sections: []`, and
-  source-backed `contains` edges to child views. For navigation-only /
-  placeholder-only sources, keep useful source/page identities as `unresolved[]`
-  notes until there is source-backed section evidence, a supported edge target,
-  a valid parent-index container, or a later compile `skip` decision. If a
-  placeholder/relation source is skipped entirely, leave its relation clues in
-  `unresolved[]` only when they still matter; otherwise omit them.
-- `views[]` and diagnostics distinguish citable evidence from supporting context. Do not promote supporting/context-only material into cited Sections unless a later ownership correction makes it citation-eligible.
-- Keep cache-friendly prompt order: fixed protocol/schema first, existing knowledge lookup second, source evidence views third, current semantic payload last. Preserve CLI JSON order and do not add timestamps, random ids, scratch paths, or host paths to generated payloads.
-- Structure digests and snapshot hashes are stale guards. Follow returned
-  `next_action.command` and do not invent digest values.
-- Node type, tag, fake-Entity, `domain`, and `action` gates are in `structure-planning/references/gates.md`.
-- Coarse reading density and neutral signal rules are in `structure-planning/references/density-profile.md`.
-- Candidate anomaly handling, stable references, duplicate handling, and
-  conflict handling are in
-  `structure-planning/references/candidate-resolution.md`.
-
-</reference>
-
-<procedures>
-
-Use this only inside the current align gate.
-
-### Step 1 — Start From The Envelope
-
-Run `context run align:<type>:<source>:<collection> --view read-plan --format json`.
-Confirm the response is the current prose align view result, then identify
-`next_action`, available views, source metadata, and diagnostics.
-
-If the host truncates a view result but the preview includes top-level
-`next_action.command`, run that command. If `next_action` is not visible, rerun
-the current view command; do not recover host tool-result files.
-
-If no current phase view result is present, stop and surface the CLI output; do
-not reconstruct an align route from prior prompt memory.
-
-### Step 2 — Follow The Evidence Read Path
-
-Run the returned `next_action.command`. For structural align work this is
-normally `read-plan`; after that, follow the evidence view's `next_action.command`
-or `next_command`.
-
-`read-plan` is the navigation surface. It chooses whether the next evidence read
-is `source-index`, `span-detail`, `span-text`, or another current evidence view.
-Read those views and then author the requested
-`context.structure.v1` payload yourself. Never pipe evidence text into validate.
-
-If an evidence view is truncated, `page.has_more: true`, or the CLI returns a
-`next_command`, run that command before authoring.
-
-Read evidence through semantic CLI views, not shell parsing. Follow `page.next_command` for pagination. If the command contains `--read-cursor`, treat it as opaque continuation state and run it exactly; do not replace it with hand-written `--source`, `--heading`, `--window`, or `--range` selectors. Use `--source`, `--heading`, `--window`, `--range`, and `--token-budget` as view filters only. `--unwrap` removes workflow metadata; it does not expand a compact view into full detail.
-
-If an evidence view returns `page.has_more`, `truncated: true`, or a
-view-specific incomplete-read diagnostic, treat that response as a partial
-read. Do not decide source-wide ownership or dense planned Sections from
-headings alone; continue the current detail view only when `page.next_command`
-is explicitly needed, otherwise return to the CLI-designated navigation view.
-
-### Step 3 — Reuse Existing Knowledge
-
-Query existing knowledge for reusable names before proposing new term/service/system/action Nodes. Exact title/slug/alias hits should usually become references to the existing Node, not duplicate candidates.
-
-When a code projection Node already represents the object, reuse its slug for prose evidence and plan only prose-owned Sections for the current source evidence.
-
-### Step 4 — Route Collection, Then Classify Semantic Structure
-
-Before choosing Node type or Section kind, route each evidence unit to its
-internal collection. The phase `<collection>` is only the entry profile for the
-current run; it is not a cap on what this structure may contain. A mixed source
-can produce multiple `views[]` in one confirmed structure when source evidence
-supports them.
-
-Use collection routing first:
-
-- product intent, user story, requirement, roadmap, or product scenario ->
-  `product`;
-- architecture, service/module/system design, runtime dependency, code-adjacent
-  prose -> `architecture`; if an existing code projection already owns the
-  object, reuse its NodeRef/ViewRef instead of creating a `codegraph` prose
-  view;
-- SOP, runbook, operation drill, workflow, or how-to procedure -> `sop`;
-- FAQ, question/answer, support notes -> `faq` only when the evidence is an
-  independent FAQ page or cross-cutting support knowledge; a single Q&A or
-  scattered support note stays as a `faq` Section under the owning view;
-- standards, policy, rules, conventions, reusable constraints -> `standards`;
-- decision record, trade-off, migration conclusion -> `decision` only when it
-  is an independent decision record with owner/date/lifecycle or cross-cutting
-  decision scope; one-off conclusions stay as `decision` Sections under the
-  owning view;
-- incident, postmortem, outage, fault timeline, action item -> `incident` only
-  when it has incident identity, timeline, follow-up, or tracking lifecycle;
-  isolated warnings/failures/action items stay as `incident` or `warning`
-  Sections under the owning view;
-- test plan, validation scenario, acceptance case -> `test`;
-
-Do not route prose align views to `codegraph` or `feats`: `codegraph` is
-produced by code extraction / AST projection, and `feats` is reserved for the
-dedicated feature workflow. For section-vs-collection overlap, keep a local
-`faq`, `decision`, or `incident` as a Section kind under the owning view unless
-the source is independently queryable across the package and has its own
-lifecycle, ownership, timeline, or cross-cutting scope.
-
-After collection routing, apply `structure-planning/references/gates.md` before
-authoring Nodes: classify Node type in order (`action` scale + process evidence,
-then concrete/term `entity`, then child-bearing `domain`), reject fake Entities
-only when at least two suspicious signals match, keep `term` separate from
-concrete tags, and provide required gate evidence.
-
-Preserve shared-source intent when the same source span legitimately supports
-multiple views. Do not copy the span text into multiple rewritten bodies; cite
-the same CLI `source_ref` in each supported view and let structure-summary mark
-the shared evidence.
-
-Source titles and headings are ordinary evidence, not structural authority. Choose titles and summaries that fit the final Node type and the CLI-provided generation policy.
-
-Plan source material as Sections first. A source heading only becomes a child
-Node/View when the cited evidence names a concrete independent subject, an
-atomic term, a gated Action, or a child-bearing Domain. A `contains` edge only
-states hierarchy; it does not prove that a thin child page has standalone
-retrieval value.
-
-Avoid same-source fragmentation. If one parent would contain many single-section
-child Entities from the same source document, keep them as Sections unless each
-child has an independent product/code object, atomic term, Action, or Domain
-identity. Also avoid copying the parent `system` / `application` scope tag onto
-local child aspects; tag a child by what it independently is.
-
-Do not promote a source fragment into a child page solely because it has a
-heading or a recognized section kind. Judge every proposed child with the same
-source-backed criteria: independent subject identity, sufficient context, and
-standalone retrieval value. The CLI may warn about repeated same-source thin
-children, but page granularity remains an evidence-backed structure decision
-for the review report rather than a content-type-specific hard gate.
-
-For `node.title` and `node.summary`, follow the workspace/source language
-surfaced by the current view or the user's instruction. In Chinese workspaces,
-translate descriptive scaffold words such as architecture, strategy, lifecycle,
-overview, scheduling, high availability, and warning into Chinese while
-preserving product names, code identifiers, CLI flags, slugs, source_ref tokens,
-and citation tokens exactly when needed. Do not copy an English source title
-into `node.title` merely because the source is English.
-
-Do not classify a broad architecture/system/方案 source as `domain` just because the title sounds like a scope. If it has writable Sections but no resolvable current/existing child Nodes, use an `entity` tag such as `system` or `application`; reserve `domain` for grouping child Nodes through typed `edges[]` with supported child targets.
-
-For large or batched payloads, use
-`structure-planning/references/density-profile.md` and
-`structure-planning/references/candidate-resolution.md` as judgment aids.
-They do not create additional workflow stages or alternate payloads.
-
-### Step 5 — Build The Payload Requested By `next_action`
-
-Use `context run align:<type>:<source>:<collection> --view schema --format json` to
-shape the payload. Treat that schema as the authoring contract.
-
-Produce one `context.structure.v1` document with semantic Nodes, planned
-Sections, typed edges, unresolved items, lifecycle state, sources, and evidence
-snapshot hash. Section identities are part of the structure gate: choose stable
-section ids such as `overview`, `behavior`, `constraints`, or a source-backed
-domain-specific name when the evidence supports it.
-
-Use only CLI-provided `source_refs[]` for section and edge evidence. Continuity
-is a per-Section constraint, not a per-View constraint: one View may contain
-many independently retrievable Sections, each with its own continuous mirror.
-Do not invent heading/range/window selectors inside the structure. Treat source
-heading changes as section-planning signals: sibling sub-headings under a shared parent
-may stay in one Section when they form one coherent semantic topic; headings
-with no shared parent should usually split unless you intentionally want one
-Section to span them. If a semantic section would require non-contiguous or
-cross-source evidence, split it during align or return the issue to the
-structure gate. Current compile writes approved knowledge by mirroring source
-spans; it does not use rewritten multi-ref sections to compress unrelated
-evidence.
-
-Validate will surface source mirror blockers before confirmation. Treat
-`section.source_mirror_split_required`,
-`section.source_mirror_repair_required`, and
-`section.source_mirror_source_refs_missing` as structure problems, not compile
-drafting problems. Use the returned `repair.suggested_splits[]` when present;
-otherwise repair source refs from CLI evidence views or move unsupported
-material to `unresolved[]`.
-
-For pure suggested-split repairs, prefer the CLI repair view before hand-editing:
-`context run align:<type>:<source>:<collection> --repair suggested-splits --input <structure.yaml> --format json`.
-It splits non-contiguous Section mirrors and can expand a broad cross-heading
-Section into Markdown structural groups within the same View. Apply the
-non-blocking repair hint when the groups should be independently retrievable;
-otherwise keep the Section and explain the grouping in structure review.
-Oversized Views still require the Agent to apply the returned child-View and contains-edge suggestions while
-classifying every child Node from evidence. The repair command does not resolve
-orphan ownership, unsupported evidence, or competing semantic groupings.
-
-When the cited source sentence itself is uncertain, preserve that uncertainty on
-the edge with `confidence: possible` or `confidence: hypothesis`. This is only
-for source-authored uncertainty such as "可能", "疑似", "may", or "might". If
-you are unsure whether the source supports the relation, do not add an uncertain
-edge; move the relation to `unresolved[]`.
-
-No-write/navigation-only/placeholder-only material should become `unresolved`
-at align time when it has retrieval or graph value but lacks source-backed
-section evidence. Do not turn relation-only navigation into a factual Section.
-Do not submit `sections: []` for an ordinary source-bound view. Use
-`sections: []` only for a generated parent index view, and only when it has
-`generated: parent_index` plus source-backed `contains` edges to child views.
-If the relationship matters but evidence or a target node is missing, keep it
-unresolved instead of writing a dangling edge.
-
-Emit `depends_on` edges only when cited source refs explicitly say one Node
-consumes, requires, calls, is configured by, or is downstream of another Node as
-a prerequisite, capability provider, upstream input, runtime dependency, or
-data-flow source. Direction is consumer/downstream -> provider/upstream. Do not
-create `depends_on` for parent/child containment, `Related`/`See also` lists,
-sibling co-occurrence, shared table membership, name similarity, or a plain
-mention without a dependency predicate. `edges[].source_refs[]` must include the
-source ref that states the dependency; if the relationship matters but evidence
-is missing, leave the edge unresolved instead of guessing.
-
-Prefer the strongest source-backed `section_kind` using the current schema's `section_kind_priority` and `section_kind_triggers`; avoid planning an entire dense source as `description` when the evidence clearly contains fenced examples, comparison tables, Q&A, decisions, specs, warnings, or principles. Use `example` for fenced command/config/code or literal sample blocks, not ordinary scenario prose. Use `incident` only for dated or timestamped failure evidence with impact scope plus root cause, mitigation, or handling record. Use `decision` only when the source surfaces two or more alternatives or options plus the chosen path and rationale. Treat kind precision as a drafting quality preference, not a reason to block an otherwise source-backed write. Keep only raw-backed semantic decisions in the payload; leave mechanical repair and patch routing to CLI diagnostics.
-
-There is no parallel candidate-body authoring path. Emit only the
-`context.structure.v1` payload accepted by the current schema view.
-
-### Step 6 — Validate And Submit
-
-Before staging, run `context run align:<type>:<source>:<collection> --validate --input - --format json` with the `context.structure.v1` payload. If validate returns `repair_confirmation_blockers`, follow its repair route and rerun validate without asking for preliminary approval. `--repair suggested-splits` handles non-contiguous source mirror Sections. For oversized Views, apply the returned child-View and contains-edge suggestions while classifying child Nodes from evidence. Resolve other blockers from evidence; ask the user only when evidence supports multiple incompatible semantic choices, and state that this is not final review. Stage only after `confirmation_ready=true`. The stage result opens the final HTML report and is the human review gate: show the structure to the user through `structure_report.file_url`, `structure_report.absolute_path`, and the compact summary before asking for confirmation. Only write `lifecycle.state: confirmed` only after explicit confirmation; then run `context run align:<type>:<source>:<collection> --confirm --format json` or pass an explicit file with `--confirm --input <structure.yaml> --format json`.
-
-After stage succeeds, do not rerun the same write command to confirm success.
-Use `context status --format json` or the returned result for read-only
-confirmation; then continue with the returned `next_action.command`, normally
-`context run compile:<type>:<source>:<collection> --view read-plan --format json`.
-
-If any write is rejected, follow the returned `next_action` and `reason_code`.
-Do not retry by guessing direct/batched stages, forcing route bypasses, or
-editing CLI-managed files.
-
-### Step 7 — Self-verify
-
-- [ ] All writes followed top-level `next_action.command`. If not, return to **Step 1**.
-- [ ] Evidence was read through returned `next_action.command`, `next_command`, or current CLI schema/view commands only. If not, return to **Step 2**.
-- [ ] Node classification used the semantic gates in `structure-planning/references/gates.md`. If not, return to **Step 4**.
-- [ ] URL/reference ownership followed CLI diagnostics, not static prompt rules. If not, return to **Step 5**.
-- [ ] The requested align payload passed `context run align:<type>:<source>:<collection> --validate --input - --format json` before stage. If not, return to **Step 6**.
-- [ ] No `sources/`, `unapproved/`, `knowledge/`, `dist/`, `.tmp`, host tool-results, or CLI-managed files were read or written with generic tools. If violated, restart from **Step 1**.
-
-</procedures>

package/plugins/codex/skills/continue/references/internal-procedures/skill-prose-align.md

@@ -1,322 +0,0 @@
----
-name: skill-prose-align
-description: >
-  Internal procedure invoked by the public Context continuation entry; not a user slash command.
-  Uses Context document evidence views to propose, validate, and confirm
-  `unapproved/structure.yaml` without reading raw snapshots directly.
-tools:
-  - Bash
----
-
-# skill-prose-align
-
-Turn captured document evidence into confirmed structure.
-
-## TL;DR
-
-- Use this after document capture, or when the user asks to split, merge,
-  reorganize, classify, or relate document evidence.
-- When status is `captured-ready-to-classify`, run every returned capture-phase
-  evidence command before editing `src/index.ts`. Use the collection-neutral
-  title tree, span index, and exact text to propose a mainline collection; wait
-  for user confirmation, then declare matching align/compile/review phases.
-- The first product output is a structure draft, not final page body.
-- Read source material only through CLI evidence views: `read-plan`,
-  `source-index`, `span-detail`, `span-text`, `schema`, and
-  `structure-summary`. Additional views are diagnostic surfaces; use the route
-  and view set returned by the CLI.
-- Write and validate `context.structure.v1` into `unapproved/structure.yaml`.
-  Stop for user confirmation before compile.
-- Before semantic judgment, use the CLI `semantic-rules` View to page through
-  only `semantic_rules.required`. Use each selection `reason` to keep unrelated
-  rules out of the current judgment.
-- Plan source evidence as Sections before promoting any heading to a Node/View.
-  Promotion depends on source-backed standalone retrieval identity, not on a
-  hard-coded section kind or collection name.
-- Do not produce or validate a structure payload 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.
-- When status reaches `structure-ready` or `needs-prose-compile`, hand off to
-  `skill-prose-compile.md`.
-- Compile, review, close, verify, and build remain separate gates.
-
-<reference>
-
-## User-Facing Gates
-
-Use semantic labels, not SDK function names:
-
-| Gate | Say this | Do not say this first |
-|---|---|---|
-| Collection classification | "I have inspected the captured evidence. Based on these source characteristics, I recommend this knowledge category; please confirm before I configure compilation." | Guessing from a filename, URL, or SDK collection enum before investigation |
-| Material investigation | "I will read the evidence index and source spans through Context, then propose a structure draft." | `alignProse`, `source-index`, `context.structure.v1` |
-| Structure confirmation | "Confirming this structure freezes page paths, section ownership, and relationships for this compile round." | `unapproved/structure.yaml` as a raw parameter |
-| Compile handoff | "The structure is confirmed; I will switch to source-bound compile for draft pages." | Continuing to edit structure in compile |
-
-## Runtime Discipline
-
-`skill-continue-workflow` owns global state routing; this Skill owns only the
-align phase selected by that route. Use CLI evidence/rule/diagnostic Views,
-follow their exact continuation commands, and treat hints as subordinate to
-`next_action`. Evidence reads may be parallel; stage, confirm, Review apply,
-close, and build writes remain serial. Never reconstruct digest values or
-inspect CLI-managed state files as a substitute for a View.
-- 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/`, or package output directories.
-- If a validation or view response includes `reason_code`, `path`, `missing[]`,
-  `diagnostics`, `repair_hints`, or `agent_hints`, treat those fields as the
-  repair contract. Do not recover by replaying a stale manual route, editing
-  rendered files, or guessing schema aliases.
-
-## Evidence Views
-
-Recommended read order:
-
-```bash
-context run align:<type>:<source>:<collection> --view read-plan --format json
-context run align:<type>:<source>:<collection> --view source-index --compact --format json
-context run align:<type>:<source>:<collection> --view span-detail --span <source-ref> --format json
-context run align:<type>:<source>:<collection> --view span-text --span <source-ref> --format json
-context run align:<type>:<source>:<collection> --view schema --format json
-context run align:<type>:<source>:<collection> --view structure-summary --input <structure.yaml> --format json
-```
-
-Use CLI-returned `next_command` values for pagination. Do not reconstruct
-documents with ad hoc `cat`, `grep`, or scripts against `sources/` or `.tmp`.
-
-## Structure Contract
-
-The structure draft uses `schema_version: context.structure.v1` and lives at
-`unapproved/structure.yaml` after staging. It contains:
-
-- lifecycle state such as validated/confirmed and frozen snapshot metadata;
-- concept `nodes[]` with stable `node_ref`, `node_type`, title/summary, and
-  ownership;
-- materialized `views[]` with `view_ref`, collection, path, section plans, and
-  evidence refs;
-- typed edges using the closed set defined by the CLI;
-- unresolved items when evidence is weak, conflicting, or the target node is
-  missing.
-
-Confirmed structure is a human gate. Validation passing is not the same as
-confirmation. Do not write `lifecycle.state: confirmed`, `confirmed_by`,
-`confirmed_at`, or `structure_digest` until the user has explicitly confirmed
-the structure proposal in the conversation.
-
-When the current conversation explicitly authorizes fully managed operation,
-use the CLI-returned `--stage --managed` command after successful validation.
-The CLI records `confirmed_by: managed-session`; validation errors and unresolved
-evidence still block confirmation. Never persist managed mode in `defineProject`
-or reuse it in another conversation.
-
-## Procedure References
-
-These are current structure planning rules. They define the source-bound
-semantic gates for Node planning, section ownership, and relationship handling.
-
-| Decision | Reference |
-|---|---|
-| Structure planning, Node ownership, density, candidate resolution | [skill-prose-align/references/internal-procedures/structure-planning.md](skill-prose-align/references/internal-procedures/structure-planning.md) |
-| Node type, title, tags, fake entity, action/domain gates, edge gates | [skill-prose-align/references/internal-procedures/structure-planning/references/gates.md](skill-prose-align/references/internal-procedures/structure-planning/references/gates.md) |
-| Source density and coarse reading judgment | [skill-prose-align/references/internal-procedures/structure-planning/references/density-profile.md](skill-prose-align/references/internal-procedures/structure-planning/references/density-profile.md) |
-| Candidate anomalies, stable ids, paths, duplicates, and conflicts | [skill-prose-align/references/internal-procedures/structure-planning/references/candidate-resolution.md](skill-prose-align/references/internal-procedures/structure-planning/references/candidate-resolution.md) |
-
-</reference>
-
-<procedures>
-
-### Step 1 — Open Material Investigation
-
-Run:
-
-```bash
-context run align:<type>:<source>:<collection> --view read-plan --format json
-```
-
-Use the returned views, budgets, snapshot hash, and next actions. If the CLI
-reports a missing or stale snapshot, route back to source capture/refresh. Do
-not read the snapshot file yourself.
-
-### Step 2 — Read Evidence Through The Index
-
-Read a compact index before requesting exact spans:
-
-```bash
-context run align:<type>:<source>:<collection> --view source-index --compact --format json
-```
-
-For exact evidence, copy CLI-returned source refs or next commands:
-
-```bash
-context run align:<type>:<source>:<collection> --view span-detail --span <source-ref> --format json
-context run align:<type>:<source>:<collection> --view span-text --span <source-ref> --format json
-```
-
-Keep a short note of what evidence supports each proposed node, section, and
-edge. If the evidence is weak or conflicting, keep it as unresolved instead of
-turning it into a fact.
-
-Before drafting structure, read:
-
-- [skill-prose-align/references/internal-procedures/structure-planning.md](skill-prose-align/references/internal-procedures/structure-planning.md)
-- [skill-prose-align/references/internal-procedures/structure-planning/references/gates.md](skill-prose-align/references/internal-procedures/structure-planning/references/gates.md)
-- [skill-prose-align/references/internal-procedures/structure-planning/references/density-profile.md](skill-prose-align/references/internal-procedures/structure-planning/references/density-profile.md)
-- [skill-prose-align/references/internal-procedures/structure-planning/references/candidate-resolution.md](skill-prose-align/references/internal-procedures/structure-planning/references/candidate-resolution.md)
-
-Do not treat this as optional background. These files contain the current
-semantic gates for source-bound structure planning. A structure payload drafted
-without the applicable references is incomplete, even if the CLI schema accepts
-its shape.
-
-### Step 3 — Draft And Validate Structure
-
-Request the schema:
-
-```bash
-context run align:<type>:<source>:<collection> --view schema --format json
-```
-
-Create a `context.structure.v1` YAML file. The draft may include a one-page-per
-source shape, but that is represented as ordinary nodes and sections; it does
-not bypass structure confirmation.
-
-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 phase state and
-must not be read back as a substitute for CLI views.
-
-Validate:
-
-```bash
-context run align:<type>:<source>:<collection> --validate --input <structure.yaml> --format json
-```
-
-Validation returns a compact summary and writes a temporary HTML report under
-`.tmp/context-runtime/reports/`. A validation report with
-`confirmation_ready=false` is an Agent repair artifact, not a user review gate:
-do not ask the user to approve it. The staged report produced after
-`confirmation_ready=true` is the final review surface; use its
-`structure_report.file_url` as the primary user-facing link and include
-`structure_report.absolute_path` as a copyable fallback.
-If the user needs a focused view, run:
-
-```bash
-context run align:<type>:<source>:<collection> --view structure-summary --input <structure.yaml> --format json
-```
-
-The explicit `structure-summary` View returns the full summary for focused
-debugging. For user confirmation, prioritize the default first-screen fields:
-`review_notice`, `structure_report`, and `structure_summary_compact`. A valid
-user-facing confirmation prompt must include the report `file_url`, the absolute
-path fallback, and a compact summary of collections/views/unresolved/diagnostics.
-Do not ask the user to confirm from counts alone.
-
-Repair diagnostics by routing them to the right decision:
-
-- source ref or snapshot mismatch -> reread evidence views or refresh capture;
-- unsupported node/section/edge -> remove it or mark unresolved;
-- duplicate/conflict -> ask the user which structure should win;
-- illegal edge type, missing target node, or edge without source refs -> fix the
-  structure or keep the relation unresolved;
-- stale structure -> regenerate from the current snapshot hash.
-
-When validation returns `repair_confirmation_blockers`, follow its exact repair
-route without stopping for human confirmation. `--repair suggested-splits`
-mechanically splits non-contiguous source mirror Sections; write its
-`repaired_payload` to a scratch YAML file and validate again. For oversized
-Views, use the returned child-View and contains-edge suggestions, but classify
-each child Node from evidence instead of mechanically inheriting the parent
-type. Repair other diagnostics from evidence and validate again. Ask the user only when evidence
-supports multiple incompatible semantic choices, and label that question as a
-structure-design choice rather than final review. Do not stage until
-`confirmation_ready=true`.
-
-### Step 4 — Review Structure Before Confirmation
-
-After validation reports `confirmation_ready=true`, stage the draft. The stage
-command opens the final report. Then show the user:
-
-- node list and planned paths;
-- section ownership;
-- typed edges and unresolved relation candidates;
-- expected compile order;
-- downstream impact: these choices freeze paths, section ownership, and
-  relationships for this compile round.
-- the `structure_report.file_url` generated by validate or `--view
-  structure-summary`;
-- the `structure_report.absolute_path` fallback in case the host cannot click
-  file URLs.
-
-If the CLI stage result includes `next_action.human_gate: true`, treat it as a
-hard stop for structure review. Do not ask for a blind "confirm structure"
-reply. Surface the report `file_url`, absolute path, and enough structured
-summary for the user to inspect what will be confirmed.
-
-Do not turn `confirmation_blockers` into a preliminary approval round. A
-validator-required page split, continuous-source split, ref repair, or
-structure-spine connection is work to resolve before staging. If a genuinely
-ambiguous semantic choice needs the user, ask only that choice and then resume
-repair; it does not replace the final report-based confirmation.
-
-Use the host's multi-choice question tool when available. If unavailable, use a
-short Markdown fallback. Good options are:
-
-- Confirm this structure and continue to compile.
-- Revise the structure with additional guidance.
-- Go back to source scope or capture because the evidence set is wrong.
-
-Only after confirmation, run the CLI confirmation command, normally:
-
-```bash
-context run align:<type>:<source>:<collection> --confirm --format json
-```
-
-If confirming a structure file other than `unapproved/structure.yaml`, pass it
-with `--input <structure.yaml>`. A draft stage in `unapproved/structure.yaml` is
-not confirmation. Do not edit `unapproved/structure.yaml` after confirmation to
-change meaning; return to this gate instead.
-
-### Step 5 — Handoff To Compile
-
-After the user confirms the structure and the CLI reports `structure-ready` or
-`needs-prose-compile`, stop this procedure and follow:
-
-```text
-skill-prose-compile.md
-```
-
-Do not keep editing structure while compiling. If compile diagnostics show the
-planned structure is wrong, return to this align gate and ask the user to
-confirm the corrected structure.
-
-### Step 6 — Self-verify Checklist
-
-- [ ] Evidence came only from Context evidence views.
-- [ ] `context.structure.v1` was validated before user confirmation.
-- [ ] User confirmed the structure before compile.
-- [ ] Compile was delegated to `skill-prose-compile`; this procedure did not
-  write draft page body.
-- [ ] Relationships are expressed as structure edges or unresolved items.
-- [ ] No direct edits were made to `sources/`, `.tmp`, `unapproved/`,
-  `knowledge/`, review HTML, or `dist/`.
-
-### Final Report
-
-Report in the user's language. Include only:
-
-- evidence views actually read;
-- proposed and confirmed node count, section count, edge count, and unresolved
-  count;
-- user confirmation outcome;
-- validation warnings that still matter for compile;
-- next route reported by status or the align phase.
-
-Do not report payload digests, snapshot hashes, source-ref hashes, absolute
-paths, or scratch file paths unless the CLI explicitly asks the user to repair
-one.
-
-</procedures>