@c4a/context-cli 0.7.0 → 0.7.4

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

@@ -1,33 +0,0 @@
----
-id: dialogue.document-classification
-kind: procedure
-mediaType: text/markdown
----
-
-# Document-classification dialogue
-
-Do not recommend a collection before reading the collection-neutral evidence
-view and every required source-body resource. Summarize the observed document
-shape, explain one evidence-backed
-recommendation, and describe its package root:
-
-| Collection | Use when the evidence primarily represents | Package root |
-|---|---|---|
-| `business` | business domains, actors, objects, and non-technical domain knowledge | `wikis/` |
-| `product` | requirements, user behavior, user stories, and acceptance intent | `wikis/` |
-| `architecture` | system structure, module design, technical mechanisms, and platform/tooling design | `guides/` |
-| `sop` | procedures, runbooks, operations, maintenance, and troubleshooting steps | `guides/` |
-| `faq` | question-and-answer material intended for issue-oriented retrieval | `guides/` |
-| `standards` | normative rules, constraints, checklists, and quality/compliance requirements | `rules/` |
-| `decision` | explicit alternatives, selected choices, trade-offs, and decision records | `guides/` |
-| `incident` | incident timelines, impact, causes, response, and prevention | `guides/` |
-| `test` | test plans, validation scenarios, matrices, and acceptance cases | `rules/` |
-
-`codeindex` comes from code extraction and `feats` is not a document mainline
-collection. Filenames, URLs, titles, and example collection names are
-insufficient evidence.
-
-Ask the user to confirm exactly one mainline collection for the current source,
-unless session-managed authority resolves this gate. After confirmation,
-declare the complete align, compile, and Review lifecycle for the same source
-and collection, then re-evaluate because other captured targets may remain.

package/providers/context/resources/dialogue/structure-confirmation.md

@@ -1,44 +0,0 @@
----
-id: dialogue.structure-confirmation
-kind: procedure
-mediaType: text/markdown
----
-
-# Structure-confirmation dialogue
-
-Present the staged structure as a proposal, not as approved knowledge. Explain
-that confirmation freezes the current round's:
-
-- knowledge pages and paths;
-- section ownership and source spans;
-- source-backed relationships; and
-- compile order.
-
-The final staged HTML report is the confirmation surface. Open it when the CLI
-returns it, report whether opening succeeded, and provide the file URL/path when
-it did not. Do not confirm from counts alone.
-
-Present these three outcomes in the user's language:
-
-- confirm the current staged structure digest;
-- revise the proposed structure and validate/stage it again; or
-- return to the source boundary when the current evidence scope is wrong.
-
-If staging changed the structure digest, any earlier confirmation no longer
-applies. When `workflow.current.gate.resolution` is `user`, explain the change
-and obtain a new confirmation. When it is `session-authority`, inspect the same
-report and continue without asking again. After resolution, execute only the
-revision-bound command returned by `workflow.current`; never construct or reuse
-a phase-local confirmation command.
-
-Deterministic boundary repairs are internal CLI maintenance and are not
-separate approval rounds. If `workflow.current.gate.resolution` is
-`session-authority`, inspect the final staged report and execute the returned
-resolution command without asking the user again. Otherwise ask for one final
-confirmation of the staged digest. Ask an earlier design question only when
-evidence supports multiple incompatible structures, and say clearly that it is
-not the final confirmation.
-
-One source document may map to one page, but that is still an ordinary
-structure proposal. A multi-source round confirms each source/collection slot;
-do not confuse one slot with completion of the entire document batch.

package/providers/context/resources/dialogue/workflow-mode-after-capture.md

@@ -1,25 +0,0 @@
----
-id: dialogue.workflow-mode-after-capture
-kind: procedure
-mediaType: text/markdown
----
-
-# Workflow mode after source capture
-
-When source capture has completed, ask about execution mode only if the
-conversation still has no explicit choice and no earlier mode question was
-asked. If ordinary review or fully managed operation was already selected,
-continue without a reminder or another confirmation. When a choice is still
-needed, explain in the user's current conversation language that ordinary
-review pauses at review decisions and provides HTML reports for inspection.
-The current product estimate is that ordinary review makes the overall workflow
-about 40% slower, with the exact difference depending on scope and response
-time.
-
-Offer fully managed operation for the rest of the current conversation. Explain
-that it skips delegatable content-review surfaces and is faster, but reduces the
-user's ability to control or adjust intermediate content. It does not bypass
-source boundaries, external permissions, hard validation, evidence checks,
-verification failures, or other non-delegatable safety boundaries. Do not ask
-again after this one-time conversation choice, and never persist it in project
-files.

package/providers/context/resources/manuals/reference/code-extractors.md

@@ -1,152 +0,0 @@
----
-id: manual.reference.code-extractors
-kind: procedure
-mediaType: text/markdown
----
-
-# Code Extractor Selection
-
-Use this manual only when the current code-extraction Route asks the Agent to
-choose or declare an extractor. The CLI reports repository facts; the Agent
-chooses how those facts become source-backed code knowledge.
-
-## Inspect Before Declaring
-
-Run the single batch inspection command returned by the extraction-scope Gate.
-The result identifies every confirmed module, its recognized `manifests`,
-README locations, entry candidates, protocol locators, and lifecycle markers.
-Treat these as deterministic technology signals, not as product semantics:
-
-| Signal | Technology candidate |
-|---|---|
-| `package.json` | TypeScript, TSX, JavaScript, or JSX |
-| `go.mod` | Go |
-| `Cargo.toml` | Rust |
-| `pyproject.toml` or `setup.py` | Python |
-| `pom.xml` or `build.gradle` | Java or JVM |
-| multiple manifests | a mixed module that may need more than one extractor |
-
-Do not select `extractTs()` merely because a repository contains some
-TypeScript. Decide against the exact confirmed module and include boundary. A
-mixed module may compose multiple structural passes; parser selection is not an
-exclusive repository-wide switch.
-
-## Selection Order
-
-Use the narrowest reusable capability that covers the confirmed source:
-
-1. Use a Context-owned phase when its contract matches the source.
-2. Otherwise use a reusable structural package inside `extractCustom()`.
-3. If no reusable package covers the syntax or repository protocol, implement a
-   project-owned adapter and keep it in the Context workspace.
-
-Current reusable capabilities are:
-
-| Source fact | Preferred capability | Lifecycle integration |
-|---|---|---|
-| TypeScript/JavaScript package or TSX/JSX file scope | `extractTs()` | Context-owned phase |
-| Go declarations, imports, calls, and common HTTP routes | `@c4a/extract-go` | call from `extractCustom()` |
-| Rush workspace packages, tags, dependencies, entries, and owners | `@c4a/extract-rush` | call from `extractCustom()`; may complement a language extractor |
-| React Router route declarations | `extractReactRouterRoutes()` from `@c4a/extract-ts` | call from `extractCustom()`; complements ECMAScript symbols |
-| Rust, Python, Java/JVM, or an unsupported framework/protocol | no assumed built-in parser | project-owned `extractCustom()` adapter |
-
-The custom extraction preview verifies this selection mechanically. Context
-detects applicable community capabilities from source manifests and stable path
-signals, then checks that candidate evidence covers every required entry,
-route, implementation boundary, workspace, or protocol probe. One aggregated
-module page is valid when it closes that structural coverage. A callback that
-only hashes a few filenames or renders configured prose does not satisfy the
-probe, even when its Markdown count is small.
-
-The probe does not assign business meaning and does not require one page per
-fact. The project adapter still owns grouping, titles, explanations, and
-cross-module semantics. If the source uses an unsupported language or protocol,
-report a capability gap instead of claiming that a known probe was consumed.
-
-An optional package does not create a new CLI phase. Add it as an explicit
-workspace dependency, then map its structural facts to candidates in the
-project callback. Do not add a parser package when its documented coverage does
-not match the inspected source.
-
-## Read The Contract Before Extending
-
-Before editing `src/index.ts`, read the Route-selected Context lifecycle and
-extractor resources completely. They are the installed contract for
-Context-owned phases such as `extractTs()`; do not require a separate
-workspace copy of an implementation package and do not infer APIs from bundled
-JavaScript.
-
-Only a capability imported directly by a project-owned `extractCustom()`
-adapter requires its package README. Use this matrix to decide whether that
-optional capability is relevant, add only that dependency, then read the
-README from the resolved installed package before implementing the callback.
-Never assume that a transitive or dev-only package is present at a hard-coded
-`node_modules` path.
-
-A project-owned adapter may use an existing parser, compiler API, or command
-whose output is deterministic. It must return source-backed candidates through
-`extractCustom()`; it must not write lifecycle, knowledge, or Review files.
-Framework-specific classification and rendering remain in the project. The CLI
-and structural parser must not infer product meaning.
-
-## Decision To Report
-
-Before the first extraction preview, state briefly:
-
-- the inspected module and manifest signals;
-- the selected Context phase or structural package;
-- whether coverage is complete or which facts remain project-owned; and
-- why another available extractor is not needed.
-
-After preview, use `inspection.structuralProbes` and each index unit's
-`structuralCoverage` as the exact audit result. An uncovered probe is a
-configuration problem, not a Review decision.
-
-If no current capability can parse the source reliably, stop at configuration
-and report the missing generic capability. Do not silently emit an empty
-codeindex or reuse an unrelated parser.
-
-## Plan Before Parsing
-
-Classify the user-visible module before selecting language tooling or reading an
-archetype template: API/service, background runtime, SDK/library, interactive
-application, adapter, CLI/tool, monorepo container, derived source,
-authoritative contract source, or unknown.
-A hybrid module may declare several `moduleTypes` and several behavior `facets`;
-keep one primary `moduleType` for concise reports. Record inspected paths in
-`moduleTypeEvidence`, record every Markdown file actually read in `documents`, then read all matching Route-recommended files below
-`resources/semantic/code-index/templates/` and combine them into one plan.
-After that, choose exactly one closed output profile: `module-map`,
-`application-map`, `protocol-index`, `service-boundary`, `runtime-map`,
-`public-api-reference`, `command-map`, `adapter-contract`, `module-registry`,
-`cross-module-flow`, or `provenance-only`. The profile selects structural probes
-and advisory checks; an invented value is rejected.
-
-Each archetype resource is a working template for an Agent with limited prior
-context. It provides a minimum evidence pass, the reader questions the index
-must answer, suggested knowledge units, Markdown chapter blueprints,
-aggregation and relationship rules, composition examples, and stop conditions.
-The blueprints are illustrative: omit unsupported sections and merge overlap
-across selected templates instead of producing empty headings or duplicate
-pages. They shape content before the batch preview; they do not prescribe or
-override projected page counts.
-
-Extractor shape defines what can be emitted. `extractTs()` creates one page per
-selected symbol and permits one owning index unit per source. Use it for an
-intentional granular public reference. Use `extractCustom()` for module-level
-aggregation, registries, protocol indexes, cross-module flows, or multiple
-candidate owners over one source; each candidate declares its `module` and
-at least one evidence-scoped `section`; there is no page-level Markdown
-fallback. Each section's typed coverage and exact evidence is checked against
-the output profile during preview. Resolve repositories from
-the extractor context's `sources[].absolutePath`, never from a
-machine-specific checkout path. Cross-module flow output must also emit
-source-backed structured edges. Generated clients/models, mirrored sources, legacy
-implementations, and internal helpers should normally be excluded or recorded
-as provenance rather than expanded one symbol per page.
-
-If a repository uses service manifests or protocol registrations that the
-community inspector cannot interpret, keep that interpretation in a generic
-project-owned `inspect` adapter attached to `extractCustom()`. Return findings
-and capability gaps through the public Context contract; do not add internal
-framework names or directory rules to the CLI.

package/providers/context/resources/procedures/code-extraction.md

@@ -1,188 +0,0 @@
----
-id: procedure.code-extraction
-kind: procedure
-mediaType: text/markdown
----
-
-# Code extraction
-
-Code extraction operates on user-confirmed repository modules and source
-patterns. A source registration identifies the repository or module; the
-extraction declaration defines the code scope inside it.
-
-Before declaring a phase, run the Route-selected batch inspection once for all
-confirmed modules. Read their manifests, module documentation, stable entries,
-and dependency/protocol locators. First record an evidence-backed classification
-for every module without reading an archetype template. A module has one primary
-`moduleType`, may declare additional `moduleTypes`, and may combine relevant
-`facets`. Only after classification, read every matching file from the Route's
-recommended `resources/semantic/code-index/templates/` directory and merge them
-into one deduplicated plan per user-visible module or aggregate.
-
-The target is a stable module map, public contract, protocol boundary, or
-runtime map—not a page for every function, variable, constant, or internal type.
-Use the Code Extractor Selection manual to choose `extractTs`, an optional
-structural package inside `extractCustom`, or a project-owned adapter. Read the
-selected package's public SDK/README before editing `src/index.ts`; never infer
-its API from bundled output. `moduleTypeEvidence` must identify the inspected
-paths that support the classification. An `unknown` unit or a unit with no
-classification evidence is an incomplete index plan.
-Record exact source-relative Markdown paths read during classification in
-`indexUnits[].documents`. Context inventories module Markdown independently:
-root README or documentation entry files require complete reading, while other
-related Markdown uses the reported Floor and Target coverage.
-
-For every custom extraction preview, Context probes source paths for known
-community structural capabilities: TypeScript symbols, React Router routes, Go
-symbols, Rush workspace structure, and source-owned protocol schemas. Every
-probe applicable to an index unit's output profile must be represented by the
-candidate evidence for that unit. A project adapter may aggregate and explain
-those facts in one high-value page, but it cannot replace a matched structural
-probe with a static template or a manually listed filename. Missing probe
-coverage is a `material-required` capability gap and uses the same
-non-delegatable capability Gate in ordinary and fully managed conversations.
-
-`include` filters files inside a selected source; it is not a package/module
-selector. Use source declarations to select repository modules. Use configured
-entry patterns when entry-led traversal is meaningful, or scan mode when the
-selected module intentionally has no package entry. Do not require source-code
-rewrites merely to create an extraction entry.
-
-Exports-only single-package TypeScript extraction has a compatible stable
-public-contract plan. Scan mode, repository collections, and custom extraction
-must declare their index units explicitly; an inferred plan is diagnostic only
-and cannot write candidates.
-
-Every index unit must expose one inventory contract. Built-in parsers produce
-it from AST and source traversal; a project adapter returns the same generic
-shape. The inventory separates eligible/analyzed files and non-empty LOC,
-discovered/read Markdown, discovered/analyzed/target/exported symbols, stable
-entries and profile-selected boundaries, plus excluded files and reasons. JSON,
-YAML, lockfiles and assets may be evidence but do not inflate source LOC.
-Evidence-only adapter output is explicitly `unscorable` and cannot pass the
-mechanical quality Gate as a complete module index.
-
-Extractor output shape must match the semantic plan. `extractTs()` projects one
-candidate page per selected symbol and assigns each source to one index unit;
-it is suitable for a deliberately granular public reference. Aggregated module
-maps, registries, protocol indexes, cross-module flows, or multiple units over
-one source require `extractCustom()` with explicit candidate ownership. For a
-monorepo, register independently visible children as separate sources before
-giving them separate `extractTs()` units.
-
-The Route runs one cache-writing batch preview after classification, template
-selection, and configuration, but before any candidate write. Report
-discovered files, AST-analyzed files, skipped files, symbols, and relations
-separately, together with each index unit's output owner, output profile,
-projected Markdown count, total bytes, largest sampled page, and risk flags.
-For custom phases, also report detected structural probes, covered and uncovered
-probe counts, representative evidence paths, and the affected output profile.
-The preview command returns a bounded summary plus one digest-bound item view.
-Follow its `next_action.command` pages until `preview_items_complete` when the
-Route requires semantic scope, ownership, capability, or scale inspection;
-never recover omitted inventory with host-output slicing.
-Use resolved entry files, exported/internal counts, and symbol-kind counts as
-structural scope evidence only. Resolve TypeScript/JavaScript
-configuration and aliases through the extractor rather than guessing paths
-from imports.
-
-Template examples never determine the expected page count. Scale policy is
-applied only to the measured batch preview and is fixed per index unit: at most
-100 pages continues normally,
-101–300 pages continues with a warning, and more than 300 pages stops at the
-non-delegatable extraction-scale Gate. Fully managed authority cannot bypass
-that Gate. Ambiguous output ownership and `material-required` capability gaps
-also stop before candidate writes. Ambiguous ownership returns to project
-configuration without creating another human Gate. Revise all affected units
-together, re-check whether their classification or selected templates changed,
-rerun the batch preview, then process exactly one pending extraction target and
-evaluate again. Do not add a second classification Gate after the page-count
-Gate; a plan revision returns through the same configuration step.
-
-A batch-total page warning remains advisory. After extraction, independent
-mechanical dimensions enforce source analysis, target-boundary coverage,
-facts/explanation, evidence scope, implementation ratio, and page shape.
-Aggregate custom candidates are rendered only from evidence-scoped `sections`;
-free Markdown, empty optional sections, template instructions, and placeholders
-cannot become reader-facing knowledge. A required Section without evidence is a
-material/capability gap instead of an empty heading. Legal scale recovery
-includes narrowing `include`, excluding generated or mirrored directories,
-enabling `exportedOnly`, moving from a symbol catalog to an aggregated
-`extractCustom()` plan, or registering real child sources. Splitting one
-`extractTs()` source into overlapping units is not a valid workaround.
-
-Current previews are cached below `.tmp/context-runtime/extract/previews/` and
-formal extraction reuses their validated structural result. Cache identity is
-bound to source scope, phase/adapter declarations, project `src/`, dependency
-locks, and the preview protocol. Deleting
-`.tmp` only causes a fresh preview. Existing approved knowledge is not
-retroactively rejected solely because it is large.
-
-New workspaces write `knowledge/codeindex/**`. If an old workspace contains
-legacy `knowledge/codegraph/**`, follow the Route-returned
-`context migrate codeindex --format json` action. It rewrites formal collection
-identities and invalidates derived extraction/audit state without requiring
-`.tmp`. Never create a permanent dual-write or move the directory by hand.
-
-Do not open Review while another extraction target in the same batch remains.
-Unchanged approved or rejected symbols do not need another decision; new or
-changed candidates remain subject to the current Review policy.
-
-For TypeScript, JavaScript, TSX, and JSX sources, Context also carries extractor-reported AST relations
-between selected symbols. A relation is projected only when both endpoints
-resolve uniquely inside the selected module; external, unselected, and
-ambiguous endpoints are counted as omissions instead of guessed. The extract
-receipt reports `relationships.detected`, `emitted`, and omission counts.
-Review materializes those source-backed relations with the approved symbol,
-and deterministic close refreshes the typed edge projection.
-
-Project-owned custom edges use `source-backed-explicit` rather than claiming
-AST derivation. They remain subject to the same evidence, endpoint, Review, and
-close projection checks.
-
-Zero edges remain a valid result. Read `close.relationshipCoverage` or the
-package inventory's `structure.relationship_coverage` to distinguish a current
-source-backed extraction that found no approved edges from an older or
-otherwise unknown relationship mode. Never infer missing edges from symbol
-co-occurrence, filenames, or package size.
-
-When the built-in ECMAScript-family extractor cannot represent the code source, use a
-declared `extractCustom` phase. The project-owned callback returns candidate
-semantics plus structured source evidence; Context owns canonical refs,
-fingerprints, candidate storage, Review snapshots, freshness, and rerun cleanup.
-Do not use a generic `customPhase` callback to write lifecycle files directly.
-Large custom adapters may return candidates as an `AsyncIterable`; Context
-retains at most the proof boundary for an over-limit unit instead of collecting
-thousands of full Markdown candidates. A project-owned `inspect` adapter may
-report generic module/protocol findings and capability gaps without putting
-framework-specific rules in the community CLI.
-
-Prefer a reusable structural library over a project-local parser when one
-matches the confirmed source: `@c4a/extract-go` for Go facts,
-`@c4a/extract-rush` for Rush workspace facts, and
-`extractReactRouterRoutes()` from `@c4a/extract-ts` for React Router facts.
-These are optional project dependencies consumed inside `extractCustom()`;
-they are not built-in CLI phases. Keep product-specific classification and
-candidate rendering in the project, and do not ask the CLI or parser to infer
-business meaning.
-
-For Rust, Python, Java/JVM, or another source without a matching reusable
-extractor, keep the lifecycle in `extractCustom()` and implement only the
-missing project adapter. If reliable syntax facts cannot be produced, stop at
-configuration and report the generic capability gap rather than emitting an
-empty or guessed graph.
-# Agent audit after extraction
-
-After every complete code-extraction batch, the Route produces one batch-level
-code-index audit. Mechanical signals cover content depth, evidence scope,
-declared-source coverage, and structured handoffs. A dimension outside its
-absolute bounds is a mechanical rejection and cannot be accepted. Advisory or
-elevated signals inside those bounds remain review evidence: the Agent must
-inspect the affected pages and submit one `accept`, `revise`, or
-`request-input` decision for all index units together.
-
-Do not split this into one confirmation per module. In fully managed operation,
-real issues select `revise` and the Route returns through project configuration,
-batch Preview, extraction, and a new audit until the index is acceptable. A
-false positive may be accepted only with a concrete inspected reason. Ask the
-user only when reliable correction needs unavailable material or access.

package/providers/context/resources/procedures/code-index-audit.md

@@ -1,113 +0,0 @@
----
-id: procedure.code-index-audit
-kind: procedure
-mediaType: text/markdown
----
-
-# Code-index Agent audit
-
-This Route is a required semantic review of the complete proposed code index.
-The CLI reports mechanical signals; the Agent reads the affected candidate
-content and evidence, compares registered sources with the user-confirmed
-scope, and decides whether the index is fit for its declared output profiles.
-Reader metrics exclude Context lifecycle comments and evidence annotations.
-Improve the source-backed knowledge itself; do not change Markdown syntax,
-sentence count, or pagination solely to influence a mechanical counter.
-The complete inventory is evidence, not the default reader-facing output. Do
-not create one sentence, bullet, table row, or page for every discovered file
-or symbol merely to satisfy coverage or density. Group related identities by a
-reader-visible capability, entrypoint, protocol boundary, lifecycle stage, or
-handoff, then explain the group's responsibility, stable inputs and outputs,
-state or failure boundary when applicable, next handoff, and exact supporting
-sources. A granular catalog is appropriate only for a declared public API,
-protocol, or command reference.
-
-When the report shows low density, add source-backed explanation or a complete
-relationship chain. Never add repeated `Observed ...` rows. When symbol
-coverage is low, use a verified evidence-backed group or a profile-appropriate
-catalog instead of copying the inventory into prose. Normalized template
-repetitions do not count as semantic facts, and enumeration-heavy output has a
-profile-specific ceiling.
-
-Identity groups and chain candidates are mechanical contracts, not optional
-notes. A group counts only when its members belong to the target inventory, its
-source files belong to the eligible inventory, and its reader-facing page cites
-those files. Every chain candidate must be documented, merged into a documented
-candidate, excluded with a concrete reason, or routed to missing-material input.
-For each discovered external boundary family, retain a representative
-source-backed chain or an explicit material gap.
-When the boundary inventory contains adjacent families such as operation and
-handler, handler and downstream, command and effect, event and processor, or a
-cross-source handoff, the adapter must return the corresponding candidate
-family. Returning an empty candidate list does not bypass chain review.
-
-The report contains no aggregate score. Every dimension is computed
-independently with its observed value, floor, recommended target, ceiling,
-mechanical score, uncovered identities, and legal repair actions. A dimension
-outside its absolute bounds cannot be accepted or offset by another strong
-dimension. Every elevated signal must receive an assessment tied to inspected
-content. Submit one `context.code-index-audit-decision.v1` payload for the
-complete batch.
-
-Read the complete digest-bound inventory before deciding. The Route-selected
-audit resource returns one budget-safe inspection command. Execute it and then
-each returned `next_action.command` until `audit_items_complete`; do not use
-host output truncation or shell slicing as pagination. The item stream separates
-eligible and analyzed files/LOC, read documents, target and exported symbols,
-stable entries, protocol boundaries, exclusions, and parser gaps. For each
-failed or below-target dimension, use the returned uncovered identities,
-affected pages, recommended template resources, and action vocabulary. Do not
-replace those facts with an inferred file list.
-
-For custom adapters, file and symbol identity arrays are complete denominators,
-not samples: their lengths must match the declared counts, analyzed identities
-must belong to eligible identities, and exported identities must belong to the
-target-symbol set. For a single-source unit, the CLI independently enumerates
-the represented language families plus Markdown/MDX after declared exclusions;
-an adapter cannot make its ratio pass by reporting only hand-picked evidence
-files. Conventional sibling page entries, Go route-register calls, and exported
-operations from a declared Go handler source of truth are also independently
-enumerated; include every discovered identity in the target-symbol and boundary
-denominators even when one aggregate page explains them. Section evidence may
-contain multiple files and may overlap
-another Section when one fact crosses a boundary. It must not be reduced to one
-arbitrary primary file, and every Section must not repeat the complete page
-evidence set merely to satisfy coverage. Distinct structured relationships must
-cite the concrete evidence for their own handoff instead of repeating one whole
-page evidence set across every destination.
-
-## Decisions
-
-- `accept`: the requested scope is represented, every dimension is within its
-  absolute bounds, and every real content-depth, evidence-scope, template, and
-  relationship issue is resolved. A below-target dimension remains visible
-  and needs a concrete reason in ordinary operation.
-- `revise`: one or more real problems remain. Identify the affected units and
-  describe changes to scope, aggregation, sections, evidence, or structured
-  handoffs. The Route returns to `src/index.ts`, Preview, extraction, and a new
-  audit revision.
-- `request-input`: reliable revision requires material unavailable in the
-  registered sources, such as an external protocol or missing source boundary.
-  Ask only for that material, then submit a new decision.
-
-## Fully managed operation
-
-Fully managed authority does not bypass the audit. When an absolute dimension
-fails, choose a returned repair action and continue through configuration,
-Preview, extraction, and audit without asking the user. Aim for the recommended
-target instead of stopping immediately at the floor. The retry ledger is bound
-to unit, source revision, profile, and problem fingerprint; superficial wording
-changes do not reset it. After three unsuccessful revisions of the same
-problem, Context combines all affected modules into one human-guidance Gate.
-Pause earlier only for unavailable material, source access, or missing parser
-capability.
-
-After each decision, briefly tell the user which decision was selected, the
-affected units, and the next Graph path. Do not stop a managed run merely to
-announce a successful automatic revision.
-
-The current `context.code-index-audit-report.v2` is computed from proposed or
-approved knowledge. Only its decision receipt and compact retry metrics stay
-under `.tmp/context-runtime/code-index-audit/`. Package output records only the
-selected report digest and decision; page metrics, exclusions, template
-fingerprints, and repair history are never published.

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.