@c4a/context-cli 0.6.19 → 0.7.1

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/TSX package or 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 TypeScript 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,184 +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.
-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 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 TypeScript 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,83 +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 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 inventory before deciding. It 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.

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

@@ -1,91 +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. Name every reported 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.
-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.
-
-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. The assessment is used only to audit the current decision and
-is 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.