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

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

@@ -0,0 +1,235 @@
+# 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 exceptions are allowed only when the collection route and
+   source evidence give the record its own lifecycle or tracking identity:
+   product `user-story`, test `scenario`, or incident `action-item` /
+   incident record. These still need source-backed acceptance, lifecycle,
+   scenario, or tracking evidence; otherwise 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.
+
+## 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[]`.
+
+## 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 only single-Section Action exceptions are source-backed `user-story`, `scenario`, and incident/action-item records with lifecycle, acceptance, or tracking identity.
+
+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, unless it is a source-backed `user-story`, `scenario`, or incident/action-item record with lifecycle, acceptance, or tracking identity. The discriminator is scale or record identity, not the presence of "step" words.
+- 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.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 unless evidence supports a repeatable process or a source-backed `user-story`, `scenario`, or incident/action-item record with lifecycle, acceptance, or tracking identity. |
+| `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. |
+| `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. |
+| `edge.confidence_required` | The cited relation sentence contains source-level uncertainty such as "可能", "疑似", "may", or "might". | Preserve source-authored uncertainty with `confidence: possible` / `confidence: hypothesis`, or move the relation to `unresolved[]`. |
+
+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/claude/skills/skill-prose-align/references/internal-procedures/structure-planning.md

@@ -0,0 +1,243 @@
+---
+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.
+
+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. 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.
+
+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 blocking diagnostics, repair the exact paths it reports and rerun validate. After validation, show the structure to the user with the structure summary and `structure_report.path`. If validation returns `confirmation_blockers[]` or `will_block_confirmation`, repair those blockers before asking the user to confirm. If you stage a draft structure first, the stage result is still a human review gate: show the returned report/summary and ask the user to inspect it before confirming. 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>