@c4a/context-cli 0.7.0 → 0.7.1

package/providers/context/resources/procedures/document-classification.md

@@ -1,22 +0,0 @@
----
-id: procedure.document-classification
-kind: procedure
-mediaType: text/markdown
----
-
-# Document classification
-
-Classification chooses the main knowledge collection for a captured document.
-The choice must follow evidence investigation, not the URL, file name, a user
-example, or a fixed content-specific prompt.
-
-Read the current collection-neutral evidence view, explain a short
-evidence-backed recommendation and its output implications, then obtain the
-user decision unless the current session explicitly delegates this gate.
-Read every Route-selected `context.source-body/*` resource in full. Index and
-heading metadata support navigation but are not evidence that the document
-body was read.
-
-After the decision, declare the complete align, compile, and review lifecycle
-for the same canonical source and collection. Re-evaluate instead of assuming
-the declaration closed every document target.

package/providers/context/resources/procedures/document-optimization.md

@@ -1,110 +0,0 @@
----
-id: procedure.document-optimization
-kind: procedure
-mediaType: text/markdown
----
-
-# Source-constrained editorial revisions
-
-This optional phase improves the publication value and readability of approved
-file and document prose without mutating the approved page. It runs only when
-`package.json.context.documentOptimization` is true.
-
-Run the Route-selected plan command. Each fragment is one source-backed Context
-Section and includes mechanical readability signals, allowed actions, exact
-line ranges, and source identity. Read every returned Section and write one
-decision for each fragment to the returned `payload_target`:
-
-- `keep` when it is already useful and readable. If the fragment has any
-  mechanical signal, include a concrete `assessment` that explains why every
-  signal is a false positive or why changing the Section would reduce source
-  fidelity. `high` signals cannot be kept unchanged. Name every remaining
-  `review` signal code in that assessment so the CLI can verify complete
-  coverage; do not use one generic assessment for a batch;
-- `repair` for local typography, Markdown, spacing, or a descriptive link label
-  whose purpose is already stated in the same Section;
-- `reshape` for source-preserving structural changes such as a wide table into
-  a short index plus detail entries, or a long paragraph into stable headings;
-- `omit` only when the plan permits it and the selected reason matches a
-  mechanically identified non-knowledge Section.
-
-An unanswered question set, empty placeholder, decision-free draft, duplicate,
-or obsolete-only Section may be omitted. Questions with answers, limitations
-with impact and action, and deprecations with a replacement remain knowledge.
-Mechanical signals are review leads, not a complete readability verdict. Read
-every fragment even when it has no signal. A mixture of false positives and
-valid repair candidates does not justify keeping the whole batch unchanged.
-Signals marked `high` are deterministic presentation obligations. A repair or
-reshape is rescanned against the effective replacement and cannot complete
-while one of those signals remains. Signals marked `review` require semantic
-inspection and may be kept only with the signal-specific assessment below.
-Every actionable signal must end in a safe edit, an eligible omission, a
-batched input request, or a Section-specific explanation that the signal is a
-false positive or that the edit would damage source fidelity. Time, token or
-compute cost, workload, batch size, deadline, and desire to finish sooner are
-never valid reasons to keep, skip, defer, or reduce an optimization. Do not
-default a batch to `keep` because it contains many fragments; finish the
-complete current batch with the same quality standard as a single fragment.
-Signals that recommend `request-input` identify ambiguous currency, ownership,
-link purpose, or sensitive values. The plan returns all of them in
-`input_requests`: ask one concise, batched question and wait before applying
-the complete optimization payload. Do not convert a required input into
-`keep` merely to avoid a pause. Preserve the exact destination of a volatile
-URL and safely improve its descriptive label or surrounding layout when the
-same Section already states its purpose; ask only for information that cannot
-be recovered from the approved Section or its source evidence.
-
-In fully managed operation, apply every safe `repair`, `reshape`, and eligible
-`omit` autonomously and continue until the optimization status is current.
-Managed authority removes routine review pauses, not quality work or genuine
-missing-input boundaries. A large repair set is expected work, not a blocker.
-If an `input_requests` batch remains after completing all independently safe
-analysis, ask once for that batch and resume from the returned Route.
-
-If the same current-batch quality problem fails three consecutive apply
-attempts, stop the automatic revision loop and follow
-`route.document-optimization.guidance-required`. Present one aggregated report
-for all affected Sections and ask for content-organization, source-fidelity, or
-missing-material direction. Do not restart Sections that already pass. A
-successful complete-batch apply clears the temporary retry record; retry
-history is never knowledge or package content.
-
-Keep all work inside the same source Section. Preserve link destinations,
-images, code, commands, numbers, identifiers, conditions, and source markers
-exactly. Do not introduce facts, infer an answer, or replace a complete
-contract with a summary.
-
-After the complete payload is ready, execute the exact `next_action.command`
-returned by the plan. Context rejects stale, incomplete, duplicate,
-cross-Section, protected-value, semantically broad, or unexplained signaled
-`keep` decisions. It also rescans every repair and reshape against the same
-mechanical analyzer before writing the revision; submitting a decision is not
-proof that the effective Markdown is clean. A repair or reshape that retains a
-review-confidence signal must include a Section-specific assessment naming
-that signal. The apply result reports each signal as `resolved` or `justified`
-with its source and post-revision range. The assessment and rescan detail are
-used only to audit the current decision and are not stored in approved
-knowledge, revisions, or package output. Unchanged
-Sections reuse their previous decision; changed Sections alone return to this
-phase.
-
-Only pages with reader-visible changes are stored. A revision is a full
-Markdown sidecar beside its approved page: `knowledge/guides/setup.md` becomes
-`knowledge/guides/setup__revision.md`. Default knowledge discovery excludes the
-reserved suffix. The filename derives the base page; the revision stores only
-the base digest that cannot be derived. Unchanged Sections inside a full
-revision are inferred. A page with no changes stores one derived negative cache
-key below `.tmp/context-runtime/document-optimization/`; replacement prose and
-Section metadata are never duplicated there. An omitted Section keeps its
-lifecycle marker in the revision so its source identity remains auditable, but
-its reader-visible body and all revision audit state are absent from `dist/`.
-
-For a later user-requested correction, use `context revise "<title or approved
-path>" --format json`. The resulting `route.document-revision.requested` owns
-target selection, revision editing, and validation; it also works when broad
-document optimization was not previously enabled. The compatibility entry
-`context optimize-docs revise` accepts the same selectors. Validation rejects
-lifecycle metadata changes, stale page baselines, protected-value changes,
-cross-Section rewrites, unsupported omissions, and invalid Markdown structure.
-A source change makes the revision a blocking conflict instead of silently
-applying it. Do not create fragment JSON files or another revision namespace.

package/providers/context/resources/procedures/prose-align.md

@@ -1,68 +0,0 @@
----
-id: procedure.prose-align
-kind: procedure
-mediaType: text/markdown
----
-
-# Prose structure alignment
-
-Alignment proposes source-bound knowledge structure. It does not write approved
-knowledge.
-
-Follow the current route's evidence view and input schema. Prefer source heading
-and block boundaries when they preserve coherent reading units; fixed line
-windows are only a fallback for unstructured text. A page may contain multiple
-sections, each with its own continuous evidence span.
-
-The default `read-plan` is the authoring packet for ordinary documents. It
-includes the payload contract, a compact canonical source-ref map, exact source
-body resources, the recommended scratch path, and the direct stage command.
-Do not separately request `schema`, `source-index`, or `existing-knowledge`
-unless the packet reports truncation or the task specifically needs an existing
-approved identity. Those views are diagnostics and large-source fallbacks, not
-mandatory workflow steps.
-
-Every `context.source-body/*` item selected in `workflow.current.resources`
-is source evidence, not supporting metadata. Read the complete Markdown file
-when its `read_state` is `read-required`. A source index, heading tree, token
-count, or successful capture never substitutes for body reading. A matching
-content digest receipt may be reused only while that text remains available in
-the current conversation. After reading every selected direct path, execute the
-single `resources.after_read.command`. For a generated Context View, execute
-its materialization command, read its complete file, then execute its exact
-`next_action.command`. Context carries the merged receipt file forward. A Route
-revision change does not invalidate unchanged bytes, but every lifecycle
-command remains revision-bound.
-
-When the route returns `payload_target`, write the Agent-authored structure input
-to its recommended `.tmp/agent-payloads/` path. This scratch area is separate
-from CLI-owned `.tmp/context-runtime/` and can be discarded after a successful
-stage. The recommendation does not restrict an explicit user-selected path.
-
-Stage all required source/collection slots before batch Review. Structure
-confirmation is an explicit gate. A confirmation applies only to the staged
-slot digest shown by the route; if the digest changes, confirm again.
-
-When the current Route exposes `batch`, author every listed target payload in
-one Agent planning pass, then write the small batch manifest to `batch.input`.
-Use `batch.validate.command` for a read-only all-target check or
-`batch.stage.command` to validate every target before any stage begins and then
-write the ready slots serially. The manifest contains only each `phase_id` and
-its structure payload `input` path; it does not merge document semantics or let
-the CLI choose page structure. A failed preflight writes no slot. If a later
-filesystem write fails, the result identifies completed slots and the Route
-remains recoverable.
-
-`--stage` performs the same validation and deterministic self-repair as
-`--validate`; use the separate validation command only for a diagnostics-only
-pass. In a managed conversation, a valid stage also records structure
-confirmation in the same write. Validation states are literal: `ready` may
-stage, `repair-required` may not, and `invalid` contains errors. `valid` is true
-only for `ready`; `error_free` distinguishes a blocker-only result from one
-containing errors. `self_healed` reports the input and output Section counts,
-how many original Sections were split, and the structural reason codes used by
-the repair.
-
-Independent read-only evidence views may run in parallel. Structure stage,
-confirmation, compile writes, and Review application are serial lifecycle
-mutations; execute them in the order selected by `workflow.current`.

package/providers/context/resources/procedures/prose-compile.md

@@ -1,23 +0,0 @@
----
-id: procedure.prose-compile
-kind: procedure
-mediaType: text/markdown
----
-
-# Source-bound prose compilation
-
-Compile materializes review candidates from confirmed structure and source
-evidence. It never writes directly to approved knowledge.
-
-The CLI derives this projection mechanically from the confirmed section ids,
-kinds, and source spans. Run only the revision-bound compile command returned
-by the current Route. Do not create compile-action payloads or rewrite source
-content.
-
-One compile command validates every owned view first, then atomically
-materializes the source/collection candidate batch. In an explicitly managed
-conversation, the host loop may continue across the remaining deterministic
-compile slots after this procedure has been read; it re-evaluates revision and
-validation state after every write. The current structure view is optional
-inspection context because the CLI consumes the confirmed structure directly.
-Do not open a partial Review while planned views remain.

package/providers/context/resources/semantic/align/candidate-resolution.md

@@ -1,106 +0,0 @@
----
-id: context.semantic.align.candidate-resolution
-kind: procedure
-media-type: text/markdown
-applies-to:
-  - duplicate
-  - conflict
-  - stable_id
-  - path
-  - unresolved
----
-
-# Candidate Resolution Rules
-<!-- Context workflow semantic resource. -->
-
-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` is the required stable filename choice for a
-View. `path` is derived from collection, optional containment, and slug; omit
-it or use the exact CLI-derived value. 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.

package/providers/context/resources/semantic/align/density-profile.md

@@ -1,41 +0,0 @@
----
-id: context.semantic.align.density-profile
-kind: procedure
-media-type: text/markdown
-applies-to:
-  - coverage
-  - reading_density
-  - structure
----
-
-# Evidence Density Selection
-<!-- Context workflow semantic resource. -->
-
-Use density as a private reading and section-planning strategy. It is not a
-separate payload, not a quality score, and not a workflow stage. Persist only
-current `context.structure.v1` fields such as `nodes[]`, `sections[]`,
-`source_refs[]`, `edges[]`, and `unresolved[]`.
-
-Apply this reference when a captured source is long, dense, fragmented, or hard
-to split into stable planned sections. Use the current CLI evidence views
-(`read-plan`, `source-index`, `span-detail`, `span-text`) to inspect material;
-do not invent a separate coarse-read artifact.
-
-| Profile | Use When | Agent Behavior |
-|---|---|---|
-| `macro` | A long source has many headings, sections, or broad topic shifts. | Create section proposals around major headings and preserve document-level anchors so later passes do not flatten scope. |
-| `meso` | Default for normal product, design, or operational documents with several related sections. | Produce section proposals for meaningful local units and preserve evidence anchors. |
-| `micro` | The source is fragmented, note-like, or dense with short independent claims. | Keep section proposals narrow and avoid bundling unrelated blocks into one candidate. |
-| `single_pass` | The source is short enough that one read can safely discover all relevant structure. | Keep anchors minimal and avoid over-segmentation, but still validate the resulting structure. |
-
-Treat Markdown heading changes as section-planning hints, not hard boundaries.
-Sibling sub-headings under a shared parent can remain in one planned section
-when they form one coherent semantic topic for that parent. Headings with no
-shared parent should usually split unless you intentionally want one section to
-span them. When a dense source has many headings, split by heading first, then
-merge adjacent or sibling groups only when the merged section is still one
-coherent fact group.
-
-Do not let density alone choose `node_type`, `tags`, `section.kind`, or body
-content. Action/domain gates are decided from source evidence and the current
-schema, not from density metadata.

package/providers/context/resources/semantic/align/gates.md

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