@c4a/context 0.7.0 → 0.7.1

package/README.md

@@ -88,7 +88,7 @@ maintain this declaration from the user's requirements.
 | `source()` and `allSources()` | References registered repo, file, or Lark source boundaries. |
 | `extractTs()` | Extracts TypeScript/JavaScript and TSX/JSX symbols and relationships into `codeindex` candidates. |
 | `extractCustom()` | Runs a project-owned code extractor while Context owns candidate, evidence, freshness, and Review state. |
-| `alignProse()` and `compileProse()` | Structures document evidence and compiles source-bound knowledge candidates. |
+| `alignProse()` and `compileProse()` | Legacy explicit phase factories retained for existing workspace migration and repair. New workspaces use `src/indexers.yaml` and the Context Indexer lifecycle. |
 | `reviewValidity()` | Declares the review gate for one collection or the project. |
 | `customPhase()` | Adds project-specific orchestration when built-in phase factories are not enough. |
 | `kbPackage()` | Builds an Agent knowledge-base package from approved knowledge and templates. |

package/README.zh-CN.md

@@ -82,7 +82,7 @@ Route 会按需选择维护这份声明所需的操作说明、Schema 和手册
 | `source()` 和 `allSources()` | 引用已经登记的代码仓库、本地文件或飞书来源边界。 |
 | `extractTs()` | 从 TypeScript/JavaScript 与 TSX/JSX 中提取符号和关系，生成 `codeindex` 候选。 |
 | `extractCustom()` | 运行项目自有代码提取器，同时由 Context 维护候选、证据、新鲜度和审核状态。 |
-| `alignProse()` 和 `compileProse()` | 整理文档证据，并生成与来源绑定的知识候选。 |
+| `alignProse()` 和 `compileProse()` | 仅为既有工作区迁移和修复保留的显式阶段工厂；新工作区使用 `src/indexers.yaml` 与统一 Indexer 生命周期。 |
 | `reviewValidity()` | 声明单个知识类型或整个项目的审核门禁。 |
 | `customPhase()` | 在内置阶段无法覆盖时增加项目专用编排。 |
 | `kbPackage()` | 使用审核通过的知识和模板构建 Agent 知识库。 |

package/docs/getting-started.md

@@ -81,12 +81,14 @@ processor, confirm the source boundary and add the processor before capture.
 If the selected page is only a runtime shell, capture the rendered-site source
 or project-specific data source explicitly; do not ask the agent to invent
 missing body text. The concrete command shape is available from
-`context source add file --help`; after registration, declare `captureFile`,
-`alignProse`, `compileProse`, and `reviewValidity`.
+`context source add file --help`; after registration, declare `captureFile`
+and `reviewValidity`, then let the Context Indexer lifecycle create the
+confirmed requirements and exact Provider registry in `src/indexers.yaml`.
 
 For a Lark / Feishu document, register a Lark source with exactly one identity
-form, then declare `captureLark`, `alignProse`, `compileProse`, and
-`reviewValidity`.
+form, then declare `captureLark` and `reviewValidity`. Do not add
+`alignProse`/`compileProse` to a new workspace; those factories remain only for
+explicit migration and repair of older declarations.
 
 File and Lark sources use the same date-batch shape as repo sources. Multiple
 documents belong under one date instead of receiving `-2` / `-A` suffixes:
@@ -140,17 +142,17 @@ of returning an unexecutable command. Read every
 semantic rules remain available as files and are loaded only for the route that
 needs them.
 
-After capture, status selects `route.document.classification-required` for
-document modules without an align declaration. Run the Gate's returned
-collection-neutral inspection commands first; only then propose a mainline
-collection and ask for confirmation. Batch read permission does not choose a
-collection.
+After capture, status selects `route.indexer.lifecycle-required`. Follow its
+`run-indexer-lifecycle` resource and the exact `context indexer ...` outcomes:
+confirm the complete requirement set, discover and resolve an exact Markdown
+Provider, execute its evidence-bound worksets, reconcile/layout/audit the
+Result, and compile the current Candidate batch. Batch read permission does
+not choose requirements, a Provider, or a collection.
 
 When the workspace also contains repo sources, Context prioritizes untouched
-code after all document captures finish: the current reason is
-`route.extract.pending-target` until the code extraction round is current,
-then routing returns to document investigation. An existing document
-structure/compile gate is never interrupted.
+code and document owner cells through that same Indexer Route. It does not
+switch to a second extraction or prose lifecycle and does not interrupt an
+accepted workset that is already durably recorded.
 
 For a single component package, use the package directory as the repo source
 boundary:
@@ -221,15 +223,14 @@ current Route rather than duplicating them in the project Skill.
 
 ### Document Source Flow
 
-For source documents, keep the project declaration small and let the CLI guide
-the evidence views, structure confirmation, deterministic compile projection,
-review, and close steps:
+For source documents, keep the project declaration small. `src/index.ts`
+declares the trusted source/capture/review/package surface; the confirmed
+requirements and exact Provider selection live separately in
+`src/indexers.yaml`:
 
 ```ts
 import {
-  alignProse,
   captureFile,
-  compileProse,
   defineProject,
   reviewValidity,
   source,
@@ -241,9 +242,7 @@ export default defineProject({
   sources: [docs],
   phases: [
     captureFile({ source: docs }),
-    alignProse({ source: docs, collection: "architecture" }),
-    compileProse({ source: docs, collection: "architecture" }),
-    reviewValidity({ collection: "architecture" }),
+    reviewValidity({ scope: "all" }),
   ],
   packages: [],
 });
@@ -254,11 +253,18 @@ Then return to the installed Context Agent entry. For maintainer inspection,
 sequence is:
 
 1. capture the source into committed snapshots;
-2. investigate evidence and confirm the CLI-managed lifecycle structure;
-3. compile every source-bound View from confirmed structure;
-4. review/apply the complete candidate batch once;
+2. confirm requirements and resolve exact Code/Markdown Providers through the
+   sole Indexer Route;
+3. execute and reconcile evidence-bound worksets, then derive layout and audit
+   the Result;
+4. compile and review/apply the complete Indexer Candidate batch once;
 5. run close once, then verify and build when packages are declared.
 
+See [Indexer Provider selection and customization](./guides/indexer-provider-and-customization.md)
+for the registry and Provider flow. Existing workspaces that still declare
+`alignProse`/`compileProse` may use their explicit diagnostic commands during
+migration, but Context does not select them as the default workflow.
+
 Do not read `sources/` or raw Markdown directly after entering the Context
 workflow; use the evidence views and `source_ref` values returned by the CLI.
 

package/docs/guides/agent-guide.md

@@ -122,12 +122,11 @@ Present only the current workflow surface:
 |---|---|
 | Register a knowledge boundary | `context source add file/lark/repo ...`, followed by the matching project phase declaration. Source registration is a user-confirmed boundary decision. |
 | Capture document sources | Run the declared `capture:file:<date>/<module>` or `capture:lark:<date>/<module>` phase only after read permission. Capture writes a sibling document file under the matching date directory, updates that directory's single `manifest.json`, and mechanically materializes supported Lark resources. Do not download or rewrite embedded resources outside the CLI. |
-| Investigate captured material | Use `context status` and the returned `context run align:<type>:<source>:<collection> --view ...` commands. Evidence views drive reading; raw directory grep is not the workflow. |
-| Confirm prose structure | `alignProse` validates and stages CLI-managed lifecycle structure. Validation does not equal user confirmation; only confirmed lifecycle state may enter prose compile. |
-| Compile source-bound drafts | `compileProse` turns confirmed structure into source-bound draft pages. It does not approve knowledge. |
-| Review and apply | Use `context review html` and `context review apply`. Approved prose pages are source-mirrored; rewrite/compression problems should return to structure/compile repair before apply. |
+| Investigate captured material | Follow `route.indexer.lifecycle-required` and its `run-indexer-lifecycle` resource. Use only the evidence views and `context indexer ...` commands returned by the current subroute; raw directory grep is not the workflow. |
+| Index documents and code | Confirm requirements, resolve exact Providers, execute/recover worksets, reconcile Results, derive layout, audit, and compile the current Indexer Candidate batch. There is no separate default extraction, classification, align, or structure-confirmation route. |
+| Review and apply | Use `context review html` and `context review apply`. Approved pages retain their exact Indexer Result/evidence binding; quality problems return to the affected Indexer revision before apply. |
 | Close, verify, build | Run `context close`, `context verify`, then `context build`. Close derives `knowledge/structure.yaml`, approved edge projection, and the final verify gate. |
-| Code extraction | Use `context source inspect <source-name>` and the declared extract phase preview before code draft writes. |
+| Code evidence | The Code Indexer uses registered parser capabilities and evidence adapters through the same Indexer Route. Legacy explicit extract phases are migration/repair entrypoints, not the default workflow. |
 | Source retraction | Follow the current status or lifecycle command if one exists. Do not delete `sources/`, `knowledge/`, `dist/`, or `.tmp` to simulate lifecycle actions. |
 
 Judgment behavior is part of evidence views, source span resolvers, repair
@@ -197,9 +196,10 @@ workspace-relative repo root plus `subpath`; do not rewrite it back to an
 absolute machine path. Local Markdown/MDX sources
 are registered with `context source add file [YYYYMMDD] --module <module> --local <path>` plus any
 needed `--include` patterns, captured with `captureFile`, then planned through
-`alignProse` and compiled with
-`compileProse`. A one-file-to-one-page outcome is a degenerate structure plan,
-not a separate content path. Remote Git operations require explicit user approval before any
+the confirmed requirement set and exact Markdown Indexer registry in
+`src/indexers.yaml`. Artifact and Section layout is derived from the validated
+Provider Result; it does not require a default align/structure-confirmation
+round. Remote Git operations require explicit user approval before any
 clone/checkout; clone into an ignored local path, checkout the requested commit,
 then register that local checkout. Do not commit cloned source content. Lark /
 Feishu sources are registered as document modules under a shared date batch,
@@ -238,47 +238,37 @@ revision-bound Context command and read the returned file. Long procedures and
 semantic rules live in these resources; they are loaded progressively, not
 discarded or shortened into the status response.
 
-Status also returns `declarationGraph` and `configurationGaps`. These expose
-capture, align, compile, and Review coverage for each canonical document source
-and declared align collection. Missing declarations are early warnings while
-structure is still being planned; after confirmation, every collection planned
-by the structure must have an exact compile route for the same source. Do not
-run a compile command from another collection as a fallback. A
-`reviewValidity({ scope: "all" })` declaration covers every collection.
-
-When `workflow.current.reason_code` is
-`route.document.classification-required`, execute its read-only
-`inspection_action` commands before adding align/compile declarations. Inspect
-every unclassified target, explain the evidence behind the proposed mainline
-collection, and wait for user confirmation. Filenames, URLs, source titles,
-and collection names are hints, not sufficient classification evidence.
-
-Also inspect `pendingStructureTargets`. A non-empty list means captured document
-work remains outside the active structure snapshots, even if the current package
-is already built. Follow `needs-prose-configuration` first when declarations are
-missing, then run the exact returned align command. Continue in the same
-workspace; do not replace a valid earlier structure round or create a second
-workspace merely to add the next document. Missing declarations are selected
-by `route.prose.configuration-required`; do not branch on an old top-level
-`needs-prose-configuration` state.
-
-Use `structureBatch` for the complete multi-source slot overview. Evidence View
-commands are workspace-read-only and parallel-safe; structure stage/confirm,
-compile stage, Review apply, and close mutate workspace state and must run
-serially.
-
-The confirmation and Review scopes are different: confirm each canonical source
-plus collection structure slot independently, but do not open Review while
-another declared slot remains pending in the same round. Compile every View from
-all slots first, open one collection-level Review, and let deterministic close
-merge the active slots into `knowledge/structure.yaml`.
+Status also returns `declarationGraph` and `configurationGaps`. For new
+workspaces, use them to diagnose source/capture/review/package declarations;
+requirements, owner cells, Provider selection, worksets, audit, and Candidate
+progress come from the Indexer lifecycle. `reviewValidity({ scope: "all" })`
+covers the unified Candidate batch.
+
+When `workflow.current.reason_code` is `route.indexer.lifecycle-required`, read
+the selected lifecycle resource and follow the first structured Indexer
+outcome. Do not invent a collection from filenames, URLs, source titles, or old
+align declarations. The confirmed requirement set and exact Provider registry
+are the durable authority.
+
+Indexer evidence reads may be parallel when the current worksets and Host permit
+it. Ledger transitions, Candidate compile, Review apply, and close mutate
+workspace state and must follow their exact CAS-bound commands. Do not open
+Review until every required owner cell has an accepted current Result and the
+batch audit is ready.
 
 Do not infer permission from the presence of a command. When
 `workflow.current.commands` is empty, do not derive a lifecycle command from
 prose; complete the returned `configuration` action or resolve the returned
 gate, then rerun status.
 
-Extraction scope is also a human gate. If no extract phase is declared, explain
+## Legacy Explicit Code Extraction Commands
+
+The following `extractTs`/`extractCustom` route applies only when maintaining an
+existing project that still declares an explicit extraction phase. New
+workspaces express code ownership and scope as Indexer requirements and use the
+Code Indexer through `route.indexer.lifecycle-required`.
+
+For an existing explicit phase, extraction scope is a human gate. If no extract phase is declared, explain
 what code area and symbol policy will become draft knowledge, then ask which
 registered source and file/symbol range to ingest. Do not inspect the source
 repository to choose packages or globs on the user's behalf. The
@@ -390,10 +380,15 @@ count packages, parse `package.json`, or sample the lifecycle candidate ledger.
   These commands still enforce the scoped candidate-id gate.
 - Do not edit approved Markdown by hand as part of review apply.
 
-## Prose Align And Compile Rules
+## Legacy Prose Migration And Repair Commands
+
+`alignProse` and `compileProse` remain callable for existing workspace
+migration, explicit diagnostics, and repair. They are not selected by the
+default Graph and must not be added to a new project as an alternate indexing
+workflow. Use the commands below only when the current CLI explicitly returns
+one of these legacy phase ids.
 
-After document capture, do not ask the user to choose an SDK path. Explain the
-product sequence:
+For such an existing declaration, the compatibility sequence is:
 
 1. investigate material through Context evidence views;
 2. propose a structure draft with nodes, section plans, supported edges, and

package/docs/reference/code-extractors.md

@@ -102,28 +102,13 @@ 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.
+The root workflow no longer owns module taxonomy or archetype templates. The
+Indexer registry selects the applicable Provider profile, and the resolved
+Provider Bundle supplies the semantic plan, evidence questions, composition
+rules, and output guidance. Context only validates the closed selection,
+digests, inventories, and resulting Candidate contracts. Do not reconstruct a
+parallel profile taxonomy in this reference or route around the Indexer
+lifecycle with an extractor-specific plan.
 
 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

package/docs/reference/indexer-provider-protocol.md

@@ -310,32 +310,20 @@ Graph outcome. Only `selection-validation-required` returns a selection
 proposal input. The Route writes no workspace or runtime state, and neither a
 visible-Skill claim nor the Route report authorizes Bundle materialization.
 
-## Contract overlay validation and trust
+## Contract overlay validation
 
 `validate-indexer-contract-overlays` recomputes the complete data-only overlay
 against the exact CLI base and operator contracts. Invalid DSL, executable
 fields, identity redefinition, threshold weakening, digest drift or a partial
-attestation/trust bundle fails before any authorization Route exists. A
-resolver's self-reported `verified` value is not an accepted input.
-
-A valid detached Ed25519 attestation is checked locally against a matching key
-in the complete Host trust-bundle policy, including key validity and
-revocation, and directly produces the common
-`context.indexer.overlay-trust-receipt/v1`. The receipt binds the exact Host
-adapter identity/version and management-authority digest as well as the policy
-digest, so any policy-envelope drift makes the audit stale. An unsigned overlay, an attestation
-without an installed trust bundle, or an attestation whose issuer/key is absent
-from the canonical bundle returns `authorization-required`; the request binds
-the exact attestation digest (or null) together with the
-project/overlay/base/operator/Provider/conformance digest set. The
-non-delegable `authorize-indexer-contract-overlay` Gate may issue that
-project-exact authorization under the independent
-`context.indexer-contract-overlay` authority; revalidation then produces the
-same trust-receipt protocol with trust class
-`project-authorized-exact-digest`. Cross-project or stale reports cannot be
-reused. Once the bundle contains the declared issuer/key, an invalid signature,
-expired key, revoked key, or malformed policy is a hard trust failure and
-cannot downgrade to project authorization.
+Provider identity fails validation. The selected Provider Bundle integrity is
+an exact input, not a self-reported trust assertion.
+
+Successful validation emits
+`context.indexer.overlay-validation-receipt/v1`. The receipt binds the exact
+project, overlay, base contract, operator contract, Provider Bundle integrity
+and canonical conformance report. There is no signature, KMS, trust-bundle or
+overlay-authorization protocol. Changing any bound digest requires
+revalidation; a stale receipt cannot be reused.
 
 ## Question amendment back-edge
 
@@ -347,8 +335,8 @@ and durable single-file journal. A Skill question ref is guidance only; it
 cannot provide or alter the contract payload.
 
 An overlay-backed question follows a different sequence. Context first
-recomputes overlay DSL conformance and verifies an enterprise or exact-project
-trust receipt. Only then may
+recomputes overlay DSL conformance and verifies the exact validation receipt.
+Only then may
 `context.indexer.overlay-question-amendment/v1` expand namespaced question and
 target-domain additions from that overlay. The target coverage domain must
 already be in scope and have one existing primary owner. The amendment is a
@@ -359,23 +347,24 @@ The executable sequence is
 `propose-overlay-question-amendment`,
 `confirm-overlay-question-amendment`, then
 `rebind-indexer-selection-to-requirement`. Proposal and rebind inputs carry the
-exact trusted overlay validation input and result; Context recomputes and
+exact overlay validation input and result; Context recomputes and
 compares that pair instead of accepting a detached receipt. Confirmation emits
 the exact amendment decision and performs no project write.
 
 The rebind Action then proves that Indexer/provider
 identity, operations, scopes, profile composition, requirement bindings, owner
-closure and read authority are byte-identical. It revalidates overlay trust,
+closure and read authority are byte-identical. It revalidates overlay
+conformance,
 reuses the exact staged Bundles, and reruns both static and final selection
 against the target requirement digest. Provider and SubjectKey authority must
 remain unchanged. Final selection resolves every CLI-base question back to its
-exact selected profile contract and requires one current trust/conformance proof
+exact selected profile contract and requires one current validation proof
 for every overlay question; forged bindings and duplicate, stale, or unused
 proofs fail before the final report is issued. The report binds the resulting
 question authority set digest. The resulting
 `context.indexer.overlay-question-registry-apply-proposal/v1` contains the full
 target `src/indexers.yaml` snapshot and binds the amendment, confirmation,
-overlay trust, rebound selection, SubjectKey schema set and finalized reports.
+overlay validation, rebound selection, SubjectKey schema set and finalized reports.
 The proposal goes through the same `stage-indexer-project-proposal` and
 `apply-indexer-project` Actions as ordinary registry/customization proposals.
 The latter dispatches this typed proposal to one expected-base CAS, project

package/docs/reference/project-api.md

@@ -218,21 +218,18 @@ inventing overlapping file ranges.
 
 ### Status declaration coverage
 
-`context status --format json --view full` includes a `declarationGraph` and
-`configurationGaps` for document workflows. Each row reports capture, align,
-compile, and Review coverage for a canonical source plus collection. Gaps are
-non-blocking before structure confirmation. Once a structure is confirmed,
-compile routing is exact: phase selection uses canonical source plus collection,
-and candidate progress remains bound to the current `structure_digest`. A
-compile phase from another collection is never used as fallback.
-
-Captured align targets that do not yet have an active confirmed structure are
-reported in `pendingStructureTargets`. They remain unfinished even when the
-currently active structures have been closed, verified, and built. Missing
-compile or Review declarations route to `needs-prose-configuration`; once the
-declarations are complete, status returns the exact align investigation command
-for the next target. A built package does not freeze the workspace or require a
-new workspace for later sources.
+`context status --format json --view full` includes `declarationGraph` and
+`configurationGaps` for source/capture/review/package declarations. New
+workspaces do not add align or compile rows: confirmed requirements, owner
+cells, exact Provider selection, workset progress, audit, and Candidate compile
+belong to the Indexer lifecycle selected by
+`route.indexer.lifecycle-required`.
+
+`pendingStructureTargets` and align/compile coverage may still appear while
+diagnosing an existing workspace that explicitly declares legacy prose phases.
+They are compatibility diagnostics, not a second default workflow and not a
+fallback when an Indexer Result is unavailable. A built package does not freeze
+the workspace or require a new workspace for later sources.
 
 `context status --format json` defaults to the compact workflow route, target,
 progress, counts, and aggregated diagnostics. Use `--view full` only when
@@ -392,7 +389,12 @@ const localDocs = source("20260712", "local-manual", { type: "file" });
 
 ### `alignProse`
 
-Open the prose structure gate for document evidence:
+Legacy compatibility factory for an existing workspace that explicitly owns a
+prose structure phase. New projects must use `src/indexers.yaml` and the
+Markdown Indexer lifecycle; the default Graph never selects `alignProse` as an
+alternate authoring route.
+
+For migration or repair of an existing declaration:
 
 ```ts
 alignProse({
@@ -505,19 +507,14 @@ ranges are never structure boundaries. Structure validation blocks repeated
 fixed-width line grids that cut through AST blocks and reports sections that
 cross multiple heading paths, without classifying document topics.
 
-After capture, the capture phase itself exposes collection-neutral `read-plan`,
-`source-index`, `span-detail`, `span-text`, and other read-only evidence views.
-Status selects `route.document.classification-required` until every captured
-target has an evidence-backed, user-confirmed align declaration. Align then
-adds `schema` and `structure-summary` for structure work. Agents should not
-scan `sources/` or `.tmp` to invent evidence. They may read only the exact
-source-body files selected as required resources by the current Route; those
-files carry stable content digests and must be read in full before a receipt is
-reported. Read all required direct paths, then execute the Route's single
-`resources.after_read.command`; the CLI writes and carries the merged receipt
-set without requiring Agent-authored JSON. That acknowledgement response
-already contains the re-evaluated `workflow.current`, so no additional status
-command is needed.
+For a new workspace, capture is followed by
+`route.indexer.lifecycle-required`; the Markdown Provider receives exact
+captured evidence and returns a schema-validated Result from which Context
+derives layout. The align evidence views below apply only when the current CLI
+explicitly selects a legacy phase for migration or repair. Agents must not scan
+`sources/` or `.tmp` to invent evidence. Read only the exact source-body files
+selected as required resources by that Route and execute its
+`resources.after_read.command` after the complete read.
 
 Generated Context Views use the same content-addressed rule. Materialization
 returns a receipt-set path and an exact post-read command. Read the complete
@@ -539,7 +536,11 @@ separate Agent-authored payload or approval step.
 
 ### `compileProse`
 
-Compile confirmed prose structure into reviewable source-bound draft pages:
+Legacy compatibility factory that compiles an already confirmed legacy prose
+structure. New workspaces compile the accepted Indexer Result store through the
+Indexer Candidate compile Route and do not declare this phase.
+
+For migration or repair of an existing declaration:
 
 ```ts
 compileProse({
@@ -982,16 +983,16 @@ prompt. After the user reports that limitation, the exact conversation phrase
 `context review approve-all ... --force` command. Other generic approval or
 continue wording does not invoke it.
 
-The gate is batch-scoped: prose waits for every planned View across all active
-structure slots and every declared `pendingStructureTargets` item in the round;
-codeindex waits for every pending extract phase in the confirmed module round.
+The gate is batch-scoped: the current Indexer Candidate batch waits for every
+required owner cell to have an accepted current Result and a ready audit.
 Candidate count/hash therefore describes the complete current batch rather than
-one page, source slot, or module. Deterministic close later merges all active
-slots into `knowledge/structure.yaml`, retains only their source, collection,
-and consumed snapshot hash as `source_inputs`, then removes the lifecycle slots.
+one page, source slot, or module. Deterministic close projects approved Indexer
+Nodes, Views, Sections, edges, and exact source/Result bindings into
+`knowledge/structure.yaml`.
 
-`status.structureBatch` lists unclassified, configuration-required, pending,
-and active structure slots together with the execution policy for the round.
+`status.structureBatch` is retained only as a diagnostic for an existing
+workspace with explicit legacy prose phases; it does not participate in the
+default Indexer Route.
 
 If the user explicitly asks for an automated or quick approval/rejection path,
 use the scoped quick commands instead of hand-writing a payload:

package/index.d.ts

@@ -18,8 +18,8 @@ export * from "./indexerProviderSelectionProposal.js";
 export * from "./indexerCustomizationLadder.js";
 export { indexerMetricContractSchema, indexerArtifactPolicyVariantSchema, indexerInventoryDomainSchema, indexerOperatorContractDigest, indexerOperatorContractSchema, indexerProfileContractDigest, indexerProfileContractEntrySchema, indexerProfileContractSchema, indexerProfileSubjectKeySchema, indexerQuestionTargetDomainSchema, indexerReaderQuestionContractSchema, indexerSubjectKeyContractSchema, inflationSensitiveHardMaximum, validateIndexerOperatorContract, validateIndexerProfileContract, } from "./indexerProfileContract.js";
 export type { IndexerMetricContract, IndexerOperatorContract, IndexerProfileContract, IndexerProfileContractEntry, IndexerProfileSubjectKey, IndexerReaderQuestionContract, IndexerSubjectKeyContract, } from "./indexerProfileContract.js";
-export { authorizeProjectIndexerOverlay, indexerContractOverlayDigest, indexerContractOverlaySchema, indexerOverlayAttestationDigest, indexerOverlayAttestationSchema, indexerOverlayAttestationSigningPayload, indexerOverlayProjectAuthorizationDigest, indexerOverlayProjectAuthorizationSchema, indexerOverlayTrustBundleDigest, indexerOverlayTrustBundleEnvelopeSchema, indexerOverlayTrustBundleSchema, indexerOverlayTrustReceiptDigest, indexerOverlayTrustReceiptSchema, validateIndexerContractOverlay, validateIndexerOverlayAttestation, validateIndexerOverlayTrustBundleEnvelope, verifyEnterpriseIndexerOverlayTrust, } from "./indexerOverlayTrust.js";
-export type { IndexerContractOverlay, IndexerOverlayAttestation, IndexerOverlayConformanceReport, IndexerOverlayProjectAuthorization, IndexerOverlayTrustBundle, IndexerOverlayTrustBundleEnvelope, IndexerOverlayTrustReceipt, } from "./indexerOverlayTrust.js";
+export { createIndexerOverlayValidationReceipt, indexerContractOverlayDigest, indexerContractOverlaySchema, indexerOverlayValidationReceiptDigest, indexerOverlayValidationReceiptSchema, validateIndexerContractOverlay, validateIndexerOverlayValidationReceipt, } from "./indexerContractOverlay.js";
+export type { IndexerContractOverlay, IndexerOverlayConformanceReport, IndexerOverlayValidationReceipt, } from "./indexerContractOverlay.js";
 export * from "./indexerOverlayQuestionAmendment.js";
 export * from "./indexerOverlayQuestionApplyProposal.js";
 export * from "./indexerBaseQuestionAmendment.js";