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

package/plugin/skills/skill-init-workspace/SKILL.md

@@ -1,74 +0,0 @@
----
-name: skill-init-workspace
-description: >
-  Internal procedure invoked by the public Context init entry; not a user slash command.
-  Initializes a Context knowledge workspace, executes only safe setup follow-up,
-  then hands off to the next-step workflow until the first human gate.
-tools:
-  - Bash
----
-
-# skill-init-workspace
-
-Initialize a Context workspace. The CLI creates files; the agent follows safe
-setup hints and stops before source/scope choices.
-
-## TL;DR
-
-- Use `context init`; do not add any extra project-local agent setup.
-- If init prints the standard setup `next:` command, run it instead of only
-  repeating it.
-- After the setup command succeeds, enter the workspace and read `AGENTS.md`
-  before running `context status`.
-- After setup, use `${CLAUDE_PLUGIN_ROOT}/skills/skill-continue-workflow/SKILL.md`
-  for status-driven continuation.
-- Stop at source registration, extraction scope, review, package output, or any
-  external repo operation that needs user choice.
-- Explain in the user's conversation language. Keep CLI commands, flags, paths,
-  status values, JSONL keys, and copied CLI tokens unchanged.
-
-<procedures>
-
-### Step 1 — Run Init
-
-1. If the user gave no directory, run `context init`.
-2. If the user gave a directory, run `context init <project-dir>`.
-3. If the user supplied a project name option, pass it as `--name <name>`.
-4. Read the CLI feedback block and preserve the project root path.
-
-### Step 2 — Execute Safe Setup
-
-1. If CLI prints `next: cd "<project-root>" && bun install`,
-   execute that command.
-2. If install fails, report the failure and stop.
-3. If setup succeeds, read `<project-root>/AGENTS.md`.
-4. After reading `AGENTS.md`, run `context status` from `<project-root>` and
-   treat that output as the current workspace state.
-
-### Step 3 — Handoff Or Stop
-
-1. If status is ready for a safe mechanical step, continue with
-   `${CLAUDE_PLUGIN_ROOT}/skills/skill-continue-workflow/SKILL.md`.
-2. If status is `missing-source`, `Human gate:`, or contains placeholders such as
-   `<name>`, `<repo-or-subdir>`, `<phase-id>`, or `<collection>`, ask for the
-   missing human choice and stop. For missing sources, ask for the knowledge
-   source boundary first; do not ask for a raw source name as an isolated
-   parameter.
-3. Do not infer repo source, source boundary, source name, package, or
-   extraction scope from cwd, parent directories, package names, monorepo
-   layout, or git remote.
-
-### Step 4 — Report
-
-Summarize what was initialized, what setup command ran, current status, and the
-human choice needed next. Do not paste a long raw CLI transcript unless the user
-asks for exact output.
-
-### Step 5 — Self-verify Checklist
-
-- [ ] Safe setup was executed when CLI provided the standard setup `next:`. If
-  not, return to **Step 2**.
-- [ ] No repo source or extraction scope was inferred. If not, stop and ask the
-  user to confirm the source boundary and scope.
-
-</procedures>

package/plugin/skills/skill-package-output/SKILL.md

@@ -1,180 +0,0 @@
----
-name: skill-package-output
-description: >
-  Internal procedure invoked by the public Context continuation entry; not a user slash command.
-  Explains package output choices, prefers kb packages, declares selected
-  package builders, builds, and inspects generated package structure.
-tools:
-  - Bash
----
-
-# skill-package-output
-
-Choose and build a package output from approved knowledge.
-
-## TL;DR
-
-- Package output is a human choice. Do not add package builders just because an
-  example exists.
-- In explicitly authorized current-conversation fully managed mode, resolve
-  this choice from the user's stated deliverable: use an agent knowledge-base
-  package for an Agent-facing knowledge workspace, an LLM text bundle only
-  when a text/RAG bundle was requested, and skip only when the user asked to
-  keep approved Markdown without a package. Do not persist this preference.
-- Recommend an agent knowledge-base package first for agent consumption.
-- Present an LLM text bundle as an alternative for a single text/RAG import
-  bundle.
-- Do not use `kbPackage()` or `llmsPackage()` as user-facing option labels.
-  Mention those API names only after the user chooses an output shape.
-- Do not offer `both` as a shortcut. Add one output, build, inspect, then ask
-  before adding another.
-- Build happens after review and deterministic close. If status says
-  `compile-close-needed`, run `context close --format json` before build.
-- Package templates may customize navigation and query guidance, but coverage,
-  gap, scope, or known-limit claims must cite approved knowledge,
-  `knowledge/structure.yaml`, or `context-build-inventory.json`.
-- Generated package structure, not `context build` alone, proves usability.
-
-<reference>
-
-## Output Shapes
-
-Recommended first output:
-
-```text
-dist/<name>-kb/
-├── AGENTS.md
-├── skills/
-│   └── knowledge-query/
-│       └── SKILL.md
-└── wikis/
-    ├── index.md
-    ├── <group>/
-    │   ├── index.md
-    │   └── ...
-    └── ...
-```
-
-Alternative:
-
-```text
-dist/<name>-llms/
-└── llms.txt
-```
-
-</reference>
-
-<procedures>
-
-### Step 1 — Read Package Docs
-
-Before editing package declarations or templates, read:
-
-```text
-node_modules/@c4a/context/docs/guides/package-outputs.md
-node_modules/@c4a/context/docs/reference/package-templates.md
-```
-
-### Step 2 — Explain The Choice
-
-Explain in the user's conversation language:
-
-- an agent knowledge-base package creates copied approved knowledge pages and
-  reusable query guidance under `dist/<name>-kb/`;
-- the default `knowledge-query` skill teaches agents how to query and cite those
-  copied approved knowledge pages;
-- the kb template must keep `wikis/index.md` as the OKF bundle entry page;
-- the default `wikis/index.md` is intentionally shallow: it describes the
-  bundle and links to next-level directories;
-- `context build` maps internal production collections into OKF roots and
-  generates child directory indexes such as `<okf-root>/<group>/index.md`, so
-  users can browse from OKF root -> group -> page; `wikis/index.md` is the
-  required default OKF root entry, while selected `guides/`, `rules/`, or
-  `feats/` roots get their own indexes too;
-- the exact mapping is `codegraph`/`business`/`product` -> `wikis/`,
-  `architecture`/`sop`/`faq`/`decision`/`incident` -> `guides/`,
-  `standards`/`test` -> `rules/`, and `feats` -> `feats/`;
-- `wikis/` is the structured entity-and-relationship layer; guides and rules
-  may explain, operationalize, or constrain it, but co-location does not prove
-  a relationship;
-- an LLM text bundle creates one text/RAG import bundle under
-  `dist/<name>-llms/`;
-- the user can customize `src/package-templates/kb/` before build;
-- template variables and examples are documented in
-  `node_modules/@c4a/context/docs/reference/template-variables.md`;
-- build writes a package inventory such as `context-build-inventory.json`, which
-  templates may cite when describing package coverage. Its edge section reports
-  the structural edge contract and the evidence status from `context verify`;
-- the user can skip package output for now and keep only `knowledge/`.
-
-Outside managed mode, ask which single output to create first using the host's
-native multi-choice tool when available. Use semantic option labels:
-
-- Agent knowledge-base package: for agents to query and cite approved knowledge pages.
-- LLM text bundle: for one text/RAG import bundle.
-- Skip package output for now: keep approved Markdown only.
-
-### Step 3 — Declare The Selected Package
-
-After the user chooses, read the template variable guide if the template needs
-navigation changes:
-
-```text
-node_modules/@c4a/context/docs/reference/template-variables.md
-```
-
-Then edit `src/index.ts` and package templates according to the SDK docs. For
-kb output, prefer a clear package name such as `<source-name>-kb`.
-
-### Step 4 — Build And Inspect
-
-If status says close is required, run:
-
-```bash
-context close --format json
-```
-
-Do not build from unclosed approved knowledge.
-
-Run:
-
-```bash
-context build
-```
-
-Inspect the generated `dist/<name>-kb/` or `dist/<name>-llms/` structure against
-[Output Shapes](#output-shapes). For kb packages, inspect every selected
-OKF root that appears in `context-build-inventory.json`, not only
-`wikis/`.
-If templates are placeholders or knowledge pages are thin, say that plainly and
-stop for user direction.
-
-If build reports that a template path collides with copied knowledge, do not
-retry blindly. Explain that template files and selected knowledge cannot render
-to the same path, then rename the template file or ask whether to exclude that
-knowledge path.
-
-If build reports a template-boundary diagnostic, repair the template by
-referencing approved knowledge, `knowledge/structure.yaml`, or
-`context-build-inventory.json` for coverage/gap/scope/known-limit statements.
-Do not patch `dist/` as the durable fix; edit the template under
-`src/package-templates/`.
-
-### Step 5 — Self-verify Checklist
-
-- [ ] The user selected the package output, or explicit current-conversation
-  managed mode resolved it from the stated deliverable. If not, return to
-  **Step 2**.
-- [ ] Only one output was added first. If not, ask before continuing with more.
-- [ ] A kb package template contains `wikis/index.md` and at least one
-  `SKILL.md`.
-- [ ] For kb output, the generated OKF root indexes link to next-level
-  directories, and child directory indexes exist when selected knowledge has
-  subdirectories.
-- [ ] Template paths do not collide with copied knowledge paths.
-- [ ] Template coverage/gap/scope/known-limit claims cite approved knowledge,
-  `knowledge/structure.yaml`, or build inventory.
-- [ ] Generated structure was inspected after build. If not, return to
-  **Step 4**.
-
-</procedures>

package/plugin/skills/skill-prose-align/SKILL.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
-  `${CLAUDE_PLUGIN_ROOT}/skills/skill-prose-compile/SKILL.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 | [references/internal-procedures/structure-planning.md](references/internal-procedures/structure-planning.md) |
-| Node type, title, tags, fake entity, action/domain gates, edge gates | [references/internal-procedures/structure-planning/references/gates.md](references/internal-procedures/structure-planning/references/gates.md) |
-| Source density and coarse reading judgment | [references/internal-procedures/structure-planning/references/density-profile.md](references/internal-procedures/structure-planning/references/density-profile.md) |
-| Candidate anomalies, stable ids, paths, duplicates, and conflicts | [references/internal-procedures/structure-planning/references/candidate-resolution.md](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:
-
-- [references/internal-procedures/structure-planning.md](references/internal-procedures/structure-planning.md)
-- [references/internal-procedures/structure-planning/references/gates.md](references/internal-procedures/structure-planning/references/gates.md)
-- [references/internal-procedures/structure-planning/references/density-profile.md](references/internal-procedures/structure-planning/references/density-profile.md)
-- [references/internal-procedures/structure-planning/references/candidate-resolution.md](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
-${CLAUDE_PLUGIN_ROOT}/skills/skill-prose-compile/SKILL.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>

package/plugin/skills/skill-prose-align/references/internal-procedures/structure-planning/references/candidate-resolution.md

@@ -1,91 +0,0 @@
-# Candidate Resolution Rules
-
-Use these rules after reading the current align evidence views and before
-authoring `context.structure.v1`. They define how current anomaly diagnostics
-map to supported structure outcomes.
-
-## Anomaly Signals
-
-Anomaly diagnostics are mechanical warnings. Do not ignore them and do not treat
-them as recommendations.
-
-For each anomaly, choose one current outcome and record the reasoning in the
-structure payload or user-facing explanation:
-
-| Outcome | Use When |
-|---|---|
-| Accept the correction | The anomaly points to a real structure fix. Apply a concrete node, section, edge, or ownership correction supported by source refs. |
-| Dismiss with rationale | The warning is mechanically true but semantically harmless. Keep the structure and state why in the confirmation summary. |
-| Keep unresolved | The warning changes structure but source evidence is insufficient. Add an `unresolved[]` item instead of guessing. |
-
-Known anomaly kinds:
-
-| Kind | Meaning | Required handling |
-|---|---|---|
-| Missing evidence | A proposed node, section, or edge has no source-backed evidence. | Add source refs, remove it, or keep the issue unresolved. |
-| Structure churn | A node was renamed, split, merged, replaced, or rejected during investigation. | Confirm the final id/title/target with the user or keep the ambiguity unresolved. |
-| Duplicate evidence | The same source ref appears more than once for the same semantic role. | Deduplicate it or explain why the repeated ref supports different roles. |
-| Broad review needed | The CLI collapsed many anomalies or reports aggregate risk. | Review the affected structure broadly; do not finalize solely from ordering. |
-
-## Stable References
-
-Use stable `node_ref`, `view_ref`, and `section_ref` values from the current
-`context.structure.v1` payload for in-payload references. A NodeRef should be
-safe, lower-case, and path-shaped, such as `entity/rspack` or
-`domain/build-tooling`. `slug` and `path` are derived fields in the current
-flow; do not invent alternate reference aliases.
-
-When an edge or section points at knowledge:
-
-- use the schema ref that matches the target layer:
-  `node_ref` for a conceptual Node, `view_ref` for a collection view, and
-  `section_ref` for a planned section;
-- ensure the target NodeRef, ViewRef, or SectionRef exists in the current
-  structure or approved knowledge;
-- keep relation hints unresolved when the target does not exist;
-- follow CLI diagnostics if a ref is unknown or stale.
-
-Do not create alternate alias fields or non-schema candidate ledger fields.
-They are not part of the current structure contract.
-
-## Visible Labels And Audit Rationale
-
-Humans need to understand merge, reject, rename, and replacement choices
-without decoding temporary ids. Keep that discipline in the current structure
-flow through current fields:
-
-- use `title` and `summary` to name the final node in user-facing language;
-- explain renamed/split/merged candidates in the confirmation summary, not by
-  adding non-schema label fields;
-- when a relation or rename cannot be settled from evidence, put the visible
-  title/target clue in `unresolved[]`;
-- when asking the user, phrase the choice with business labels ("Rspack build
-  tool page" vs "Webpack page"), not with source refs or internal section ids.
-
-NodeRef is the stable conceptual identity. ViewRef is the collection-specific
-view identity and is the durable approved-page identity. SectionRef is the
-stable planned-section identity under a ViewRef. Package paths are derived from
-the approved ViewRef plus containment/slug; do not treat paths as an alternate
-identity contract. Visible labels help humans review the choice, but they do
-not authorize a different NodeRef, ViewRef, edge, or section ownership without
-source-backed evidence and user confirmation.
-
-## Duplicate And Conflict Handling
-
-- Exact duplicate structure -> keep one node/section/edge and explain the
-  duplicate in the confirmation summary.
-- Same topic but different evidence boundary -> keep separate sections only
-  when each section has a distinct source-backed role.
-- Conflicting facts -> ask the user or keep an `unresolved[]` item. Do not
-  pick a winner from title order or source order.
-- Replacement or rename -> ask the user when it changes NodeRef, ViewRef,
-  containment, slug, or the derived approved path. These are durable user-facing
-  identities, not disposable labels.
-
-## Self-verify
-
-- [ ] Every accepted node, section, and edge has source-backed support.
-- [ ] Every unresolved relation or conflict is explicit in `unresolved[]`.
-- [ ] No non-schema candidate ledger fields or alias fields appear in the payload.
-- [ ] NodeRef, ViewRef, and SectionRef values, not temporary labels or paths,
-  are used for current references.