@c4a/context-cli 0.6.18 → 0.7.0

package/providers/context/provider.yaml

@@ -1,12 +1,13 @@
 schema: agent-graph.provider.v1
 id: c4a/context
-version: 0.6.18
+version: 0.7.0
 name: Context workflow
 description: Internal work contract for Context knowledge workspaces.
 graphs:
   - graphs/workspace.yaml
+  - graphs/indexer.yaml
 catalogs:
   codes: codes.yaml
 compatibility:
-  agentGraph: ^0.2.6
+  agentGraph: ^0.2.7
   node: ">=20"

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

@@ -55,6 +55,12 @@ Treat those fields as structural scope evidence, not a semantic ranking. Stop
 when the preview crosses the confirmed module boundary or the module
 identity/path shape is wrong.
 
+Also report the unit inventory: eligible/analyzed file and LOC counts,
+discovered/read Markdown, target/exported symbols, stable entry and boundary
+targets, exclusions and parser gaps. After extraction, read every independent
+audit dimension and the exact uncovered identities. Use the CLI-selected
+repair actions and matching templates; do not invent a total score.
+
 Apply the per-index-unit policy exactly: up to 100 pages proceeds; 101–300 pages
 warns and proceeds; more than 300 pages stops even in fully managed mode. Group
 all oversized or capability-gap units into one explanation and one plan-revision
@@ -69,6 +75,12 @@ or mirrored areas, enable `exportedOnly`, change to an aggregate
 `extractTs()` source into overlapping index units. Report a batch-total page
 advisory as a cost signal, not a new Gate.
 
+In fully managed mode, revise absolute failures automatically and aim for each
+recommended target. After three attempts with the same unit/problem fingerprint,
+stop at the single aggregated guidance Gate and report all failed modules,
+dimensions, attempted actions, and likely missing material together. Ordinary
+mode also makes one batch decision; it does not create one user Gate per module.
+
 For a multi-module round, finish every pending extraction target before opening
 one Review. For an unchanged repeat run, explain that no added, changed, or
 removed symbols need a decision. Mention `extractTs`, `include`, `entries`,

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

@@ -23,7 +23,7 @@ recommendation, and describe its package root:
 | `incident` | incident timelines, impact, causes, response, and prevention | `guides/` |
 | `test` | test plans, validation scenarios, matrices, and acceptance cases | `rules/` |
 
-`codegraph` comes from code extraction and `feats` is not a document mainline
+`codeindex` comes from code extraction and `feats` is not a document mainline
 collection. Filenames, URLs, titles, and example collection names are
 insufficient evidence.
 

package/providers/context/resources/dialogue/knowledge-review.md

@@ -18,6 +18,12 @@ The user does not need to create a payload file; the Agent may write the pasted
 payload to ignored scratch storage for the CLI command. Never derive a payload
 from HTML, candidate ids, snapshots, or a default decision.
 
+When the user completes a decision from the report, retain the exact report URL
+or local report path and reviewed scope in the current conversation for the
+final completion summary. Do not persist a separate workspace ledger or count a
+report as user-reviewed when it was inaccessible, fully managed, or bypassed by
+force approval.
+
 Do not mention force approval when first presenting Review. If the user replies
 without a Payload that they approve or want to continue, explain that the
 report Payload remains the normal path. Only at that point, when the report is
@@ -28,7 +34,7 @@ that exact phrase appears in the current conversation. Phrases such as `我批
 `继续`, or `全部通过` do not invoke this escape path.
 
 Do not open Review for one page or module while another confirmed item in the
-same round is still being generated. If a repeat codegraph run has no delta,
+same round is still being generated. If a repeat codeindex run has no delta,
 state that existing approvals were preserved and no Review gate remains.
 
 When the user explicitly requested fully managed operation, use only the

package/providers/context/resources/dialogue/source-boundary.md

@@ -17,11 +17,19 @@ Explain the observable impact:
 - every confirmed source is a module inside that batch;
 - several code and document modules may share the date;
 - `date/module` appears in source refs and phase ids; and
-- stable codegraph knowledge paths use the module name without the date.
+- stable codeindex knowledge paths use the module name without the date.
 
 Do not invent `-A`, `-B`, or sequence suffixes. If today's batch exists, append
 the newly confirmed module to it.
 
+When the current request already lists exact local modules or documents, do not
+repeat the source-boundary question in either ordinary or fully managed mode.
+Resolve each named module to one unique existing local path inside the
+user-scoped root, then pass that path in the batch payload. Repository paths are
+relative to the Context project root; the CLI may mechanically read their Git
+root, `origin`, and current commit. Ask only when a name is ambiguous, no
+matching path exists, or selecting one match would broaden the requested scope.
+
 When inspection finds several package boundaries, show their paths and ask
 which concrete boundaries should become sources. Explain that `include`
 filters files inside a source and cannot select a monorepo package. Only after

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

@@ -6,17 +6,20 @@ mediaType: text/markdown
 
 # Workflow mode after source capture
 
-When source capture has completed and the conversation is still using ordinary
-review mode, remind the user in their current conversation language that the
-remaining workflow will pause at review decisions and provide 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 user response time.
+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 when fully managed authority is already active, and never persist the
-choice in project files.
+again after this one-time conversation choice, and never persist it in project
+files.

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

@@ -6,9 +6,10 @@ mediaType: text/markdown
 
 # Workflow mode after workspace creation
 
-After the workspace is created, briefly explain the two execution modes in the
-user's current conversation language unless they already selected fully managed
-operation in this conversation.
+After the workspace is created, explain the two execution modes only when the
+conversation has not already selected a mode and no earlier mode question was
+asked. If the entry plan or initialization confirmation already resolved this
+choice, continue without asking again.
 
 - Ordinary review mode is the default. Context pauses at review decisions and
   provides HTML reports for the user to inspect. The current product estimate is
@@ -22,4 +23,5 @@ Make clear that fully managed mode does not bypass source boundaries, external
 permissions, hard validation, evidence checks, verification failures, or other
 non-delegatable safety boundaries. Ask whether the user wants to keep the
 default ordinary review mode or authorize fully managed operation for the
-current conversation. Do not persist the choice in project files.
+current conversation. This is a one-time conversation choice: do not repeat it
+after capture or resume, and do not persist it in project files.

package/providers/context/resources/manuals/guides/lark-resources.md

@@ -39,6 +39,13 @@ resources remain explicit in the capture report. Unknown non-empty XML blocks
 stay auditable in the raw XML and receive a warning; the CLI does not infer
 their meaning.
 
+Document and resource reads share one access identity. Context first uses the
+user identity; it falls back to the bot identity only when user credentials
+are unavailable, never when the source denies permission or reports missing
+scopes. This prevents a capture from mixing document text read by one identity
+with attachments read by another. A bot fallback is reported in the capture
+result and remains subject to the bot's own access boundary.
+
 ## Storage lifecycle
 
 Resources have three distinct locations:

package/providers/context/resources/manuals/guides/package-outputs.md

@@ -111,8 +111,8 @@ capture reports are never distributed as reader assets. See
 [Lark Resource Materialization](./lark-resources.md).
 
 The same inventory exposes `structure.relationship_coverage`. It records
-whether selected codegraph pages have current source-backed AST relationship
-metadata, how many codegraph views were selected, and how many package-visible
+whether selected codeindex pages have current source-backed AST relationship
+metadata, how many codeindex views were selected, and how many package-visible
 edges were emitted. An empty edge list is therefore explicit evidence of a
 coverage state, not permission to invent a dependency.
 
@@ -136,7 +136,7 @@ Current collection mapping:
 
 | Internal collection | Package path | Role |
 |---|---|---|
-| `codegraph` | `wikis/codegraph/` | Structured code entities and relationships. |
+| `codeindex` | `wikis/codeindex/` | Source-backed code indexes with optional structured relationships. |
 | `business` | `wikis/business/` | Structured business entities and relationships. |
 | `product` | `wikis/product/` | Structured product entities, behavior, and relationships. |
 | `architecture` | `guides/architecture/` | Architecture explanations and design narratives. |

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

@@ -44,10 +44,10 @@ Current reusable capabilities are:
 
 | Source fact | Preferred capability | Lifecycle integration |
 |---|---|---|
-| TypeScript/TSX package or file scope | `extractTs()` | Context-owned phase |
+| 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 TypeScript symbols |
+| 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
@@ -104,7 +104,7 @@ 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
-codegraph or reuse an unrelated parser.
+codeindex or reuse an unrelated parser.
 
 ## Plan Before Parsing
 
@@ -114,7 +114,7 @@ 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`, then read all matching Route-recommended files below
+`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`,
@@ -136,8 +136,9 @@ 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
-evidence-scoped `sections`. Each section's typed coverage and exact evidence is
-checked against the output profile during preview. Resolve repositories from
+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

package/providers/context/resources/manuals/reference/package-templates.md

@@ -47,7 +47,7 @@ kbPackage({
 llmsPackage({
   name: "component-lib-llms",
   template: "src/package-templates/llms",
-  select: { include: ["codegraph/component-lib/**"] },
+  select: { include: ["codeindex/component-lib/**"] },
 });
 ```
 
@@ -265,7 +265,7 @@ its pages instead of producing one index per path segment.
 The generated
 `dist/<package-name>/wikis/` tree is the required default
 KB entry surface. Internal collections are mapped into OKF roots during build:
-`codegraph`, `business`, and `product` go to `wikis/`; `architecture`, `sop`,
+`codeindex`, `business`, and `product` go to `wikis/`; `architecture`, `sop`,
 `faq`, `decision`, and `incident` go to `guides/`; `standards` and `test` go to
 `rules/`; and `feats` goes to `feats/`. Treat `wikis/` as the structured
 entity-and-relationship layer. Guides and rules may explain, operationalize,
@@ -313,17 +313,25 @@ wants project-specific behavior beyond knowledge lookup.
 
 ## Context OKF Profiles
 
-Approved Markdown under `knowledge/` is the production source of truth:
+Approved Markdown under `knowledge/` and its deterministic
+`knowledge/structure.yaml` projection form the authoring source of truth:
 
 - top-level YAML frontmatter uses OKF fields such as `type`, `title`,
   `description`, `tags`, `timestamp`, and `resource`;
-- Context production metadata such as `sources`, `node_type`, `visibility`,
-  `code_symbols`, relationship records, and `candidate_fingerprint` also lives
-  at the top level;
+- each Markdown page keeps reader fields, stable page identity, `sources`, and a
+  small recovery capsule (`resource`, `node_type`, containment fields, and
+  relationship mode);
+- large or repeated machine state such as complete `code_symbols`, code
+  evidence, relationship records, candidate fingerprints, and optimization
+  decisions lives once in the corresponding `structure.yaml` view record;
+- Context readers hydrate that machine state in memory before verify, audit,
+  revision, or build. Do not copy a compact page as a new page without using a
+  Context authoring command;
 - do not nest Context production metadata under `context`; fields such as
   `context.sources` and `context.code_symbols` are not part of the 0.6 profile;
 - section provenance lives in `<!-- context:section ... source_ref="..." -->`
-  comments;
+  comments. When a Section needs more than one citation, the CLI preserves the
+  complete set in its adjacent `context:source_refs` block;
 - do not add frontmatter `source_refs`; page-level provenance is derived from
   section source refs when needed;
 - do not add `context` or `schema` fields.
@@ -346,7 +354,7 @@ src-N#span:<heading-hint> L<start>-<end>@<span-hash>
 
 The code symbol form includes the source-relative file so same-name symbols in
 different files resolve to one exact symbol-index row. Consumers should still
-treat the complete `source_ref` as opaque. Production codegraph pages keep
+treat the complete `source_ref` as opaque. Production codeindex pages keep
 `candidate_fingerprint` at the top level and do not duplicate this evidence in
 `code_origin`.
 
@@ -398,8 +406,8 @@ current closed state.
 
 Before writing output, `context build` validates that rendered template paths
 are safe, unique, and do not collide with copied knowledge paths. For example,
-a template file that renders to `wikis/codegraph/foo.md` is rejected if
-selected knowledge such as `knowledge/codegraph/foo.md` maps to that same OKF
+a template file that renders to `wikis/codeindex/foo.md` is rejected if
+selected knowledge such as `knowledge/codeindex/foo.md` maps to that same OKF
 output path. Rename the template file or use `select.exclude` when the
 collision is intentional.
 

package/providers/context/resources/manuals/reference/project-api.md

@@ -35,7 +35,7 @@ the date:
 ```text
 knowledge/<collection>/<slug>.md
 knowledge/<collection>/<containment>/<slug>.md  # only for an intentional hierarchy
-knowledge/codegraph/<module>/symbol/<slug>.md
+knowledge/codeindex/<module>/symbol/<slug>.md
 repo:<date>/<module>#symbol:...
 file:<date>/<module>/<document>#span:...
 lark:<date>/<module>/<document>#span:...
@@ -47,12 +47,12 @@ dist/<source-name>-kb/...
 Choose the module boundary before extraction. In a monorepo, register each
 confirmed package/subdirectory under the same date batch. A repo root that
 resolves to multiple modules is for inspection; it is not an extraction unit.
-Approved codegraph paths use the stable module name; the date remains only in
+Approved codeindex paths use the stable module name; the date remains only in
 source selectors, phase ids, and evidence refs:
 
 ```text
-knowledge/codegraph/module-a/...
-knowledge/codegraph/module-b/...
+knowledge/codeindex/module-a/...
+knowledge/codeindex/module-b/...
 ```
 
 For prose Views, provide a stable filename `slug` and omit `path`; the CLI
@@ -63,7 +63,7 @@ it is not a required source/module wrapper.
 
 The registry stores this as one date entry containing several `modules` entries,
 and materializes each module at `sources/repo/<date>/<module>`.
-Repo module names are project-wide codegraph identities and therefore cannot be
+Repo module names are project-wide codeindex identities and therefore cannot be
 reused under another date batch. Refresh an existing module through its original
 date/module selector.
 When a repo module and the Context workspace share the same Git root, the CLI
@@ -408,7 +408,7 @@ alignProse({
 ```
 
 `collection` is an internal knowledge classification, not a package directory.
-Package build maps `codegraph`/`business`/`product` to `wikis/`,
+Package build maps `codeindex`/`business`/`product` to `wikis/`,
 `architecture`/`sop`/`faq`/`decision`/`incident` to `guides/`,
 `standards`/`test` to `rules/`, and `feats` to `feats/`. The complete output
 contract is documented in [Package Outputs](../guides/package-outputs.md).
@@ -593,12 +593,12 @@ does not infer relationships or inject relation markers into verbatim body.
 
 ### `extractTs`
 
-Extract exported TypeScript / TSX symbols into draft candidates:
+Extract exported TypeScript / JavaScript / TSX / JSX symbols into draft candidates:
 
 ```ts
 extractTs({
   source: componentLib,
-  collection: "codegraph",
+  collection: "codeindex",
 });
 ```
 
@@ -607,8 +607,8 @@ Options:
 | Field | Meaning |
 |---|---|
 | `source` | `source("date", "module")` for one repo module |
-| `collection` | Code extraction uses `"codegraph"` |
-| `include` | Optional glob list inside the selected source; default is `["src/**/*.{ts,tsx}"]` |
+| `collection` | Code extraction uses `"codeindex"` |
+| `include` | Optional glob list inside the selected source; default is `["src/**/*.{ts,tsx,mts,cts,js,jsx,mjs,cjs}"]` |
 | `mode` | `"exports"` (default) traces public exports from automatic or configured entries; `"scan"` uses every file matched by `include` as an entry root |
 | `entries` | Optional source-relative entry files for `"exports"` mode. They override `package.json` entry detection and live only in the Context project configuration |
 | `exportedOnly` | Defaults to `true` in `"exports"` mode and `false` in `"scan"` mode |
@@ -620,7 +620,7 @@ An explicit index unit records production intent rather than parser settings:
 ```ts
 extractTs({
   source: componentLib,
-  collection: "codegraph",
+  collection: "codeindex",
   indexUnits: [{
     id: "component-public-api",
     inputSources: ["20260712/component-lib"],
@@ -629,6 +629,7 @@ extractTs({
     moduleTypes: ["sdk-library"],
     facets: ["public-api", "plugin-extension"],
     moduleTypeEvidence: ["package.json exports and src/index.ts public entry"],
+    documents: ["README.md", "docs/public-api.md"],
     outputProfile: "public-api-reference",
     responsibility: "Document stable exported component contracts.",
     entries: ["src/index.ts"],
@@ -655,6 +656,9 @@ behaviors such as routing, protocol consumption, events, persistence, plugins,
 release, or cross-module chains. `moduleTypeEvidence` records the inspected
 paths that support the classification. Classify first, then read the matching
 Route-provided code-index templates, and only then finish the extraction plan.
+`documents` contains exact source-relative Markdown paths read for that plan;
+Context compares it with discovered module documents instead of treating a
+source-code comment as documentation coverage.
 `lifecycle` is `"authoritative"`, `"generated"`, `"mirrored"`, `"legacy"`,
 or `"vendored"`; derived sources normally use `"provenance-only"` rather
 than duplicating reader-facing pages. These are generic project facts, not
@@ -680,7 +684,7 @@ editing the source repository:
 ```ts
 extractTs({
   source: componentLib,
-  collection: "codegraph",
+  collection: "codeindex",
   include: ["src/**/*.ts"],
   entries: ["src/api.ts"],
 });
@@ -740,7 +744,7 @@ remain report signals and do not create another Gate.
 Phase id shape:
 
 ```text
-extract:<source-name-or-repo>:codegraph
+extract:<source-name-or-repo>:codeindex
 ```
 
 Codegraph extraction has two execution policies:
@@ -751,7 +755,7 @@ Codegraph extraction has two execution policies:
   the Agent re-evaluates `context status --format json`; only
   `workflow.current` decides whether Review is now required.
 - `context run <phase-id> --auto-promote` is the explicit CI/CD path. It is valid
-  only for `phase.extract.ts` codegraph phases, applies deterministic code deltas
+  only for `phase.extract.ts` codeindex phases, applies deterministic code deltas
   without Review, refreshes deterministic close when approved knowledge changed,
   then runs project verification. Close or verification errors make the command
   fail; JSON output reports applied/materialized/removed counts plus a `close`
@@ -763,7 +767,7 @@ other semantic knowledge. Agents must not infer a human gate from a phase-local
 result. Human gates and their inspection/resolution Actions are exposed only by
 `workflow.current`.
 
-Approved codegraph sections use the local evidence form
+Approved codeindex sections use the local evidence form
 `src-N#symbol:<file>:<symbol>:<kind>@<digest>`. The file segment makes reverse
 lookup exact when multiple files contain the same symbol name, kind, and digest;
 the complete ref remains opaque to agents. New pages keep only top-level
@@ -779,7 +783,7 @@ aggregated repository protocol:
 extractCustom({
   id: "extract:service:protocol",
   sources: [service],
-  collection: "codegraph",
+  collection: "codeindex",
   indexUnits: [{
     id: "service-protocol",
     inputSources: ["20260811/service"],
@@ -850,6 +854,12 @@ least one source-backed structured edge. `context status` therefore treats this
 pending code extraction target, and Review can verify snapshot freshness
 without a placeholder `extractTs` phase.
 
+Each `sections[].markdown` value is Section body content only; do not copy the
+template heading into it. Context renders `sections[].title` and rejects nested
+reader headings at the SDK boundary so empty template chapters cannot leak into
+knowledge. Evidence `symbol` and `kind` are canonical-ref tokens and cannot
+contain `:` or `@`; exact qualified signatures remain reader-facing prose.
+
 `indexUnits` is also the batch scale and ownership contract. Candidate
 `module` must match one declared unit id or output owner. Older callbacks that
 omit `indexUnits` remain compatible: Context groups candidates by `module` and
@@ -879,6 +889,21 @@ output profile. Coverage is based on source-backed evidence paths, not Markdown
 page count, so one aggregate page can pass while an entry-only static module
 card cannot.
 
+For a single-source index unit, Context also scans every represented language
+family and Markdown/MDX file after the unit's declared exclusions. The adapter's
+`eligibleFileTargets` and `eligibleLoc` must cover that independent baseline.
+Configuration files may be evidence, but a hand-picked evidence list cannot be
+reused as the source or LOC denominator. Cross-module-flow units remain scored
+against their declared entry, protocol, operation, and handoff boundaries rather
+than treating several repositories as one source-code page.
+
+The same baseline discovers conventional sibling page entries, route-register
+calls in Go router files, and exported receiver operations when a Go handler is
+the declared service source of truth. Every discovered identity must appear in
+the target-symbol and boundary denominators. An aggregate page may summarize
+these identities, but an adapter cannot list one representative sibling and
+silently omit the rest.
+
 The extractor returns knowledge semantics (`nodeRef`, rendered Markdown,
 Review summary and source-backed evidence). It must not write `knowledge/`,
 `.tmp/context-runtime/lifecycle/candidates.jsonl`, extraction fingerprints or
@@ -899,9 +924,9 @@ import { indexGoRepository } from "@c4a/extract-go";
 import { extractCustom } from "@c4a/context";
 
 extractCustom({
-  id: "extract:service:codegraph",
+  id: "extract:service:codeindex",
   sources: [service],
-  collection: "codegraph",
+  collection: "codeindex",
   extract: async ({ projectRoot }) => {
     const facts = await indexGoRepository(resolveServiceCheckout(projectRoot));
     return { candidates: buildServiceCandidates(facts) };
@@ -927,7 +952,7 @@ and its evidence coverage auditable before candidate writes.
 Declare the review step for a collection:
 
 ```ts
-reviewValidity({ collection: "codegraph" });
+reviewValidity({ collection: "codeindex" });
 ```
 
 Declare one review gate for all current draft collections:
@@ -939,7 +964,7 @@ reviewValidity({ scope: "all" });
 Phase id:
 
 ```text
-review:codegraph:validity
+review:codeindex:validity
 review:all:validity
 ```
 
@@ -965,7 +990,7 @@ 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;
-codegraph waits for every pending extract phase in the confirmed module round.
+codeindex waits for every pending extract phase in the confirmed module round.
 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,
@@ -995,13 +1020,13 @@ const sample = source("20260712", "sample");
 
 customPhase("custom:20260712/sample:review", async (ctx) => {
   await ctx.ensureSources({ source: sample });
-  await ctx.extract.ts(extractTs({ source: sample, collection: "codegraph" }));
-  await ctx.review.html(reviewValidity({ collection: "codegraph" }));
+  await ctx.extract.ts(extractTs({ source: sample, collection: "codeindex" }));
+  await ctx.review.html(reviewValidity({ collection: "codeindex" }));
 });
 ```
 
 Custom phases are an orchestration escape hatch. Use `extractCustom()` instead
-when project code needs to publish codegraph candidates. The supported runtime
+when project code needs to publish codeindex candidates. The supported runtime
 helpers are:
 
 - `ctx.ensureSources(...)` for repo source readiness.

package/providers/context/resources/procedures/close-and-build.md

@@ -6,14 +6,20 @@ mediaType: text/markdown
 
 # Close and build
 
-Close deterministically derives `knowledge/structure.yaml` from approved
-Markdown and the confirmed structure snapshots. It validates the rebuilt
-projection. When an approved page still points at a captured source asset,
+Close deterministically reconciles approved Markdown, existing durable machine
+metadata, and confirmed structure snapshots into `knowledge/structure.yaml`.
+It then compacts repeated machine fields out of each Markdown page and validates
+the hydrated result. When an approved page still points at a captured source asset,
 close may mechanically replace that target with its content-addressed
 `knowledge/assets` path; it does not rewrite reader-visible prose. Before
 removing the transient snapshots, it retains only each closed prose target's
 source, collection, and consumed snapshot hash under `source_inputs`.
 
+Do not hand-edit, duplicate, or move fields between Markdown and
+`structure.yaml`. The CLI owns compaction and hydration. A compact Markdown page
+remains readable and keeps enough identity for projection diagnostics; complete
+code and optimization metadata is intentionally not duplicated.
+
 Build runs only after close and verification are current. It writes declared
 packages under `dist/` and records an inventory receipt with added, updated,
 removed, and index changes.
@@ -26,11 +32,20 @@ package inventory. Revision sidecars are never emitted as separate knowledge.
 Run only the current route command, then evaluate again. A successful build
 means the currently declared scope is current; newly captured or newly declared
 targets can reopen earlier graph nodes.
+
+The final completion summary must cover the built outputs, validation status,
+knowledge scale, and unresolved issues. Add a compact `Review reports` section with every
+exact HTML report URL or local report path that the user actually used for a
+review decision in this conversation, together with its reviewed scope. Omit
+the section when no report was user-reviewed. Do not reconstruct it by scanning
+`.tmp`, invent a shareable URL, or classify fully managed or force approval as
+user review.
 # Code-index audit record
 
-When a package selects approved `codegraph` pages, build requires the current
-batch-level Agent audit to be accepted. The complete report remains in the
-Context workspace at `knowledge/code-index-audit.json` and is not copied into
-`dist/` or uploaded with the package. `context-build-inventory.json` stores only
-the report digest, decision, and compact package summary needed to identify the
-audited build.
+When a package selects approved `codeindex` pages, build requires the current
+batch-level Agent audit to be accepted. The complete report and decision state
+are runtime data below `.tmp/context-runtime/code-index-audit/`; deleting
+`.tmp/` causes Context to recompute and re-audit them. They are not copied into
+`dist/`, uploaded with the package, or committed as knowledge. The package
+inventory stores only the report digest, decision, and compact summary needed
+to identify the audited build.