@c4a/context-cli 0.7.1 → 0.7.5

package/plugins/cursor/.cursor-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "c4a",
   "displayName": "C4A Context",
-  "version": "0.7.1",
+  "version": "0.7.5",
   "description": "Start or continue a project-local knowledge workspace through one graph-routed entry.",
   "author": { "name": "Context4AI", "email": "support@context4ai.dev" },
   "homepage": "https://github.com/context4ai/c4a",

package/plugins/cursor/commands/c4a-context.md

@@ -43,11 +43,8 @@ managed work, or no further review already resolves this choice.
 Use the user's explicit language choice when present; otherwise pass `zh-CN`
 for a Chinese conversation and `en` for an English conversation. Pass
 `project-dir`, `--name`, `--dev`, or `--debug` only when the user explicitly
-requested that initialization choice. New workspaces enable conservative
-document compilation optimization by default. Pass `--no-optimize-docs` only
-when the user explicitly asks to disable it during initialization. Pass
-`--managed` only after the user explicitly authorizes fully managed operation
-in this conversation.
+requested that initialization choice. Pass `--managed` only after the user
+explicitly authorizes fully managed operation in this conversation.
 
 If the `context` process itself cannot start because the command is missing
 (`ENOENT`, or shell exit 127 explicitly identifying `context` as the missing
@@ -76,23 +73,18 @@ Execute only `next_action.command` returned by `context entry`:
   init`, enter the project root, read the generated `AGENTS.md`, and run this
   entry again.
 
-If the user explicitly asks to correct or revise an existing approved or built
-knowledge page, first let `context entry` relocate into the existing workspace
-and evaluate its current Route once. Resolve a blocking workspace diagnostic,
-evidence-maintenance action, or already-pending Review batch first; these may
-change the approved baseline. Before continuing unrelated capture, extraction,
-package configuration, or build work, start the correction with:
+If the user asks to correct a current Candidate before approval, first let
+`context entry` relocate into the workspace and evaluate its current Route.
+Start the correction with:
 
 ```bash
-context revise "<the user's page title, approved path, ViewRef, or wording>" --format json
+context revise "<candidate title, path, or id>" --instruction "<requested correction>" --format json
 ```
 
-When the target is unique, run the returned status command and follow
-`route.document-revision.requested`. When candidates are returned, select one
-only if the conversation identifies it uniquely; otherwise ask which page the
-user means. Never edit the approved base page or `dist/` for this operation.
-After the Route validates the revision, continue normally: Context will offer
-the package build when the correction makes its output stale.
+When the target is unique, Context invalidates only its derived outputs and
+reopens the owning Author workset. Run the returned status command and follow
+the current Route. If the target is ambiguous, ask which Candidate the user
+means. Never edit `knowledge/`, `dist/`, or create a side-channel revision page.
 
 ### Conversation modes
 
@@ -104,24 +96,6 @@ before workflow evaluation. Debugging records traces below
 `.tmp/context-runtime/debug/` but does not grant workflow authority or provide
 source evidence.
 
-Document optimization is enabled by default for newly initialized workspaces.
-It performs source-constrained editorial revision: the CLI identifies
-readability and knowledge-value signals, and the Agent may keep, repair,
-reshape, or safely omit content only inside its existing source Section. It
-must preserve facts, link targets, images, code, numbers, identifiers, and
-source evidence. Approved pages remain source-faithful; only changed full-page
-revisions are stored beside them as `knowledge/**/*__revision.md`. Default
-knowledge discovery excludes those reserved sidecars, and internal editorial
-audit state is not included in package output.
-
-For an existing workspace, respect its current `package.json` setting. Run
-`context optimize-docs enable` or `context optimize-docs disable` only when the
-user explicitly changes that preference. If initialization is required and the
-user opts out, pass `--no-optimize-docs` through `context entry`; otherwise let
-the default initialization command enable it.
-Follow the resulting Route instead of editing approved knowledge or package
-output by hand.
-
 For explicitly authorized fully managed operation, use:
 
 ```bash
@@ -141,13 +115,13 @@ that returned Route; never reconstruct a command from an earlier step.
 
 Code knowledge is published under `codeindex`. Context mechanically audits each
 module's input analysis, stable boundaries, facts, explanation, evidence scope,
-and page shape without producing a total score. In fully managed operation,
-follow returned repair actions automatically; after three failed revisions of
-the same module problem, stop at the one aggregated human-guidance Gate. If a
-legacy workspace returns `route.extract.codeindex-migration-required`, execute
-only its migration command; do not rename `codegraph` paths manually.
+and page shape without producing a total score. Blocking mechanical failures
+reopen the owning Author or Composer workset; advisory metrics remain warnings
+and do not create a retry ledger or override Gate. If a legacy workspace returns
+`route.extract.codeindex-migration-required`, execute only its migration
+command; do not rename `codegraph` paths manually.
 
-### Discover Indexer Providers before selection
+### Select Indexer Providers
 
 For `indexer-provider-required`, `indexer-provider-unavailable`,
 `indexer-customization-required`, `indexer-customization-invalid`, or
@@ -158,69 +132,40 @@ default, six-level customization ladder, upgrade conflict handling, debugging
 commands, and the exit condition for each level. Do not replace it with a
 remembered or host-specific workflow.
 
-When the current Route starts a new Code or Markdown indexing task, run this
-read-only command once before creating or changing any Provider registry entry:
-
-```bash
-context indexer catalog --format json
-```
-
-Report the returned CLI-bundled entry Skills together with every other Indexer
-Skill already visible through the current host. The conversational report must
-include each Skill name, readable exact version when available, and source type
-(CLI-bundled community, workspace, installed plugin, or authorized marketplace
-result). When the host already exposes an exact Skill root or `SKILL.md` path,
-read only its YAML frontmatter and sibling `context-indexer.yaml` during
-discovery. The manifest version is authoritative;
-`metadata.context-provider-version` is a readable copy that must match it. Do
-not load the Provider body or other guidance until the Route selects it. If the
-host exposes no readable root or exact version, report the version as
-unavailable rather than guessing it.
-
-Group observations with the same Skill name and exact version into one
-conversational item and list all observed source types on that item. An
-installed projection of an identical CLI-bundled identity is not a second
-Provider. Keep different versions separate. The route input still preserves
-each distinct source observation as its own `visible_skills` entry because
-`source_type` is singular; never use source count or discovery order as
-selection precedence. Do not search arbitrary directories, infer host cache
-paths, install a plugin, or query a marketplace unless the user separately
-authorizes it. Keep this discovery report only in the conversation: do not
-write it to `src/`, `package.json`, lifecycle state, receipts, audit output, or
-`dist/`. Do not repeat it during an unchanged task resume; repeat it only for a
-new indexing task, a changed host-visible Skill set, or an explicit diagnostic
-request.
-
-After the requirements are applied, author one
-`context.indexer.provider-route-input/v1` payload whose `registry` preserves
-the applied `requirements` block exactly and whose `visible_skills` contains
-only the just-reported path-free identities. Route it before any Host resolves
-or reads an external Provider:
-
-```bash
-context indexer route-indexer-provider-selection --input <payload.yaml-or-json> --format json
-```
-
-On `community-fallback-required`, retry with the applicable CLI-bundled profile
-and set `community_fallback_attempted: true`. Read-scope overlap is allowed, but
-an exact primary owner-cell conflict must be resolved explicitly; do not use
-array or discovery order as precedence. If fallback leaves a required owner
-cell uncovered, preserve the returned `capability_gap_proof`. Only the Route's
-following `propose-indexer-customization` Agent Action may turn that exact proof
-into a dependency-free minimal `extend` draft; do not weaken the requirement,
-write source, add dependencies, or claim the draft is applied.
-
-Only `selection-validation-required` returns a
-`selection_proposal_input`. Pass that exact object to:
-
-```bash
-context indexer validate-indexer-selection-proposal --input <payload.yaml-or-json> --format json
-```
-
-Use only the returned `next_provider_requests` for resolution. A successful
-static report does not authorize materialization, installation, execution, or
-writing the proposal into `src/indexers.yaml`; continue through the Route's
-resolver, staging, final validation, confirmation, and apply Actions.
+When the current Route starts a new Code or Markdown indexing task, its
+`configure-indexer-providers` Action input already contains the exact applied
+requirements and CLI-bundled Provider catalog. Select applicable Providers from
+the Skills already visible to the Host and that supplied catalog. Do not add a
+catalog command, installation preflight, discovery report, or discovery-only
+confirmation to the normal workflow. The main entry being visible is not proof
+that every Provider is available; the CLI checks the selected distribution
+when it is used and returns any missing/version-conflict recovery.
+
+Use the supplied CLI-bundled identity for a selected shipped Provider, including
+when the same Skill/version is also visible as an installed projection. Do not
+resolve that copy through the Host or re-read its installed metadata. For a
+relevant external Skill, read only the exact Host-exposed frontmatter and
+sibling `context-indexer.yaml` needed for selection; do not guess a version or
+scan caches. Different versions remain distinct. Read Provider guidance only
+when selected. Discovery is not a durable workspace artifact.
+
+Return only `stage: provider-selection`, the non-CLI
+`host_visible_skills`, and the selected semantic `indexers` through the exact
+`context action complete-current` command returned by the Route. The CLI owns
+construction of the full registry payload, fallback/conflict checks, static
+validation, Provider resolution and staging, final validation, and atomic
+application of `src/indexers.yaml`. Do not call their low-level commands as a
+second production workflow.
+
+If a selected external Provider needs Host resolution, the next current Route
+contains one `context.resolve-indexer-provider/v1` Host Action and its exact
+request. Invoke that Host Action once, then submit
+`stage: provider-resolution` with the returned Host result through the Route's
+`complete-current` command. If the Bundle carries a non-allowlisted program,
+the following current Route presents the existing program-execution Gate; wait
+for its user/session-authority decision and submit that decision through
+`complete-current`. A recovered `provider-finalization` Route consumes
+only its fixed Action input; it must not resolve or install the Provider again.
 
 ### Follow the current Route
 
@@ -228,8 +173,12 @@ Treat `workflow.current` as the current-step authority:
 
 1. Read every `resources.required` item whose `read_state` is `read-required`.
    Read a returned `path` completely, or execute a returned resource `command`
-   and read its complete output file. Materializing a resource is not reading
-   it. Keep the merged receipts only in this conversation and submit them with
+   and read its complete output file. For a current Indexer Partition, Author,
+   Composer or structure-review Route, read the materialized files and then use
+   the Route's immediate completion command; do not create or submit a read
+   receipt. Other workflow resources may still require the returned receipt
+   command. Materializing a resource is not reading it. Keep those receipts only
+   in this conversation and submit them with
    the exact returned `context status --resource-receipts @<file>` command. Use
    `after_read_receipts` only after the full resource has been read. The exact
    `resources.after_read.command` already returns the re-evaluated

package/plugins/skills/context/SKILL.md

@@ -42,11 +42,8 @@ managed work, or no further review already resolves this choice.
 Use the user's explicit language choice when present; otherwise pass `zh-CN`
 for a Chinese conversation and `en` for an English conversation. Pass
 `project-dir`, `--name`, `--dev`, or `--debug` only when the user explicitly
-requested that initialization choice. New workspaces enable conservative
-document compilation optimization by default. Pass `--no-optimize-docs` only
-when the user explicitly asks to disable it during initialization. Pass
-`--managed` only after the user explicitly authorizes fully managed operation
-in this conversation.
+requested that initialization choice. Pass `--managed` only after the user
+explicitly authorizes fully managed operation in this conversation.
 
 If the `context` process itself cannot start because the command is missing
 (`ENOENT`, or shell exit 127 explicitly identifying `context` as the missing
@@ -75,23 +72,18 @@ Execute only `next_action.command` returned by `context entry`:
   init`, enter the project root, read the generated `AGENTS.md`, and run this
   entry again.
 
-If the user explicitly asks to correct or revise an existing approved or built
-knowledge page, first let `context entry` relocate into the existing workspace
-and evaluate its current Route once. Resolve a blocking workspace diagnostic,
-evidence-maintenance action, or already-pending Review batch first; these may
-change the approved baseline. Before continuing unrelated capture, extraction,
-package configuration, or build work, start the correction with:
+If the user asks to correct a current Candidate before approval, first let
+`context entry` relocate into the workspace and evaluate its current Route.
+Start the correction with:
 
 ```bash
-context revise "<the user's page title, approved path, ViewRef, or wording>" --format json
+context revise "<candidate title, path, or id>" --instruction "<requested correction>" --format json
 ```
 
-When the target is unique, run the returned status command and follow
-`route.document-revision.requested`. When candidates are returned, select one
-only if the conversation identifies it uniquely; otherwise ask which page the
-user means. Never edit the approved base page or `dist/` for this operation.
-After the Route validates the revision, continue normally: Context will offer
-the package build when the correction makes its output stale.
+When the target is unique, Context invalidates only its derived outputs and
+reopens the owning Author workset. Run the returned status command and follow
+the current Route. If the target is ambiguous, ask which Candidate the user
+means. Never edit `knowledge/`, `dist/`, or create a side-channel revision page.
 
 ### Conversation modes
 
@@ -103,24 +95,6 @@ before workflow evaluation. Debugging records traces below
 `.tmp/context-runtime/debug/` but does not grant workflow authority or provide
 source evidence.
 
-Document optimization is enabled by default for newly initialized workspaces.
-It performs source-constrained editorial revision: the CLI identifies
-readability and knowledge-value signals, and the Agent may keep, repair,
-reshape, or safely omit content only inside its existing source Section. It
-must preserve facts, link targets, images, code, numbers, identifiers, and
-source evidence. Approved pages remain source-faithful; only changed full-page
-revisions are stored beside them as `knowledge/**/*__revision.md`. Default
-knowledge discovery excludes those reserved sidecars, and internal editorial
-audit state is not included in package output.
-
-For an existing workspace, respect its current `package.json` setting. Run
-`context optimize-docs enable` or `context optimize-docs disable` only when the
-user explicitly changes that preference. If initialization is required and the
-user opts out, pass `--no-optimize-docs` through `context entry`; otherwise let
-the default initialization command enable it.
-Follow the resulting Route instead of editing approved knowledge or package
-output by hand.
-
 For explicitly authorized fully managed operation, use:
 
 ```bash
@@ -140,13 +114,13 @@ that returned Route; never reconstruct a command from an earlier step.
 
 Code knowledge is published under `codeindex`. Context mechanically audits each
 module's input analysis, stable boundaries, facts, explanation, evidence scope,
-and page shape without producing a total score. In fully managed operation,
-follow returned repair actions automatically; after three failed revisions of
-the same module problem, stop at the one aggregated human-guidance Gate. If a
-legacy workspace returns `route.extract.codeindex-migration-required`, execute
-only its migration command; do not rename `codegraph` paths manually.
+and page shape without producing a total score. Blocking mechanical failures
+reopen the owning Author or Composer workset; advisory metrics remain warnings
+and do not create a retry ledger or override Gate. If a legacy workspace returns
+`route.extract.codeindex-migration-required`, execute only its migration
+command; do not rename `codegraph` paths manually.
 
-### Discover Indexer Providers before selection
+### Select Indexer Providers
 
 For `indexer-provider-required`, `indexer-provider-unavailable`,
 `indexer-customization-required`, `indexer-customization-invalid`, or
@@ -157,69 +131,40 @@ default, six-level customization ladder, upgrade conflict handling, debugging
 commands, and the exit condition for each level. Do not replace it with a
 remembered or host-specific workflow.
 
-When the current Route starts a new Code or Markdown indexing task, run this
-read-only command once before creating or changing any Provider registry entry:
-
-```bash
-context indexer catalog --format json
-```
-
-Report the returned CLI-bundled entry Skills together with every other Indexer
-Skill already visible through the current host. The conversational report must
-include each Skill name, readable exact version when available, and source type
-(CLI-bundled community, workspace, installed plugin, or authorized marketplace
-result). When the host already exposes an exact Skill root or `SKILL.md` path,
-read only its YAML frontmatter and sibling `context-indexer.yaml` during
-discovery. The manifest version is authoritative;
-`metadata.context-provider-version` is a readable copy that must match it. Do
-not load the Provider body or other guidance until the Route selects it. If the
-host exposes no readable root or exact version, report the version as
-unavailable rather than guessing it.
-
-Group observations with the same Skill name and exact version into one
-conversational item and list all observed source types on that item. An
-installed projection of an identical CLI-bundled identity is not a second
-Provider. Keep different versions separate. The route input still preserves
-each distinct source observation as its own `visible_skills` entry because
-`source_type` is singular; never use source count or discovery order as
-selection precedence. Do not search arbitrary directories, infer host cache
-paths, install a plugin, or query a marketplace unless the user separately
-authorizes it. Keep this discovery report only in the conversation: do not
-write it to `src/`, `package.json`, lifecycle state, receipts, audit output, or
-`dist/`. Do not repeat it during an unchanged task resume; repeat it only for a
-new indexing task, a changed host-visible Skill set, or an explicit diagnostic
-request.
-
-After the requirements are applied, author one
-`context.indexer.provider-route-input/v1` payload whose `registry` preserves
-the applied `requirements` block exactly and whose `visible_skills` contains
-only the just-reported path-free identities. Route it before any Host resolves
-or reads an external Provider:
-
-```bash
-context indexer route-indexer-provider-selection --input <payload.yaml-or-json> --format json
-```
-
-On `community-fallback-required`, retry with the applicable CLI-bundled profile
-and set `community_fallback_attempted: true`. Read-scope overlap is allowed, but
-an exact primary owner-cell conflict must be resolved explicitly; do not use
-array or discovery order as precedence. If fallback leaves a required owner
-cell uncovered, preserve the returned `capability_gap_proof`. Only the Route's
-following `propose-indexer-customization` Agent Action may turn that exact proof
-into a dependency-free minimal `extend` draft; do not weaken the requirement,
-write source, add dependencies, or claim the draft is applied.
-
-Only `selection-validation-required` returns a
-`selection_proposal_input`. Pass that exact object to:
-
-```bash
-context indexer validate-indexer-selection-proposal --input <payload.yaml-or-json> --format json
-```
-
-Use only the returned `next_provider_requests` for resolution. A successful
-static report does not authorize materialization, installation, execution, or
-writing the proposal into `src/indexers.yaml`; continue through the Route's
-resolver, staging, final validation, confirmation, and apply Actions.
+When the current Route starts a new Code or Markdown indexing task, its
+`configure-indexer-providers` Action input already contains the exact applied
+requirements and CLI-bundled Provider catalog. Select applicable Providers from
+the Skills already visible to the Host and that supplied catalog. Do not add a
+catalog command, installation preflight, discovery report, or discovery-only
+confirmation to the normal workflow. The main entry being visible is not proof
+that every Provider is available; the CLI checks the selected distribution
+when it is used and returns any missing/version-conflict recovery.
+
+Use the supplied CLI-bundled identity for a selected shipped Provider, including
+when the same Skill/version is also visible as an installed projection. Do not
+resolve that copy through the Host or re-read its installed metadata. For a
+relevant external Skill, read only the exact Host-exposed frontmatter and
+sibling `context-indexer.yaml` needed for selection; do not guess a version or
+scan caches. Different versions remain distinct. Read Provider guidance only
+when selected. Discovery is not a durable workspace artifact.
+
+Return only `stage: provider-selection`, the non-CLI
+`host_visible_skills`, and the selected semantic `indexers` through the exact
+`context action complete-current` command returned by the Route. The CLI owns
+construction of the full registry payload, fallback/conflict checks, static
+validation, Provider resolution and staging, final validation, and atomic
+application of `src/indexers.yaml`. Do not call their low-level commands as a
+second production workflow.
+
+If a selected external Provider needs Host resolution, the next current Route
+contains one `context.resolve-indexer-provider/v1` Host Action and its exact
+request. Invoke that Host Action once, then submit
+`stage: provider-resolution` with the returned Host result through the Route's
+`complete-current` command. If the Bundle carries a non-allowlisted program,
+the following current Route presents the existing program-execution Gate; wait
+for its user/session-authority decision and submit that decision through
+`complete-current`. A recovered `provider-finalization` Route consumes
+only its fixed Action input; it must not resolve or install the Provider again.
 
 ### Follow the current Route
 
@@ -227,8 +172,12 @@ Treat `workflow.current` as the current-step authority:
 
 1. Read every `resources.required` item whose `read_state` is `read-required`.
    Read a returned `path` completely, or execute a returned resource `command`
-   and read its complete output file. Materializing a resource is not reading
-   it. Keep the merged receipts only in this conversation and submit them with
+   and read its complete output file. For a current Indexer Partition, Author,
+   Composer or structure-review Route, read the materialized files and then use
+   the Route's immediate completion command; do not create or submit a read
+   receipt. Other workflow resources may still require the returned receipt
+   command. Materializing a resource is not reading it. Keep those receipts only
+   in this conversation and submit them with
    the exact returned `context status --resource-receipts @<file>` command. Use
    `after_read_receipts` only after the full resource has been read. The exact
    `resources.after_read.command` already returns the re-evaluated

package/plugins/skills/context-code-indexer/SKILL.md

@@ -1,10 +1,10 @@
 ---
 name: context-code-indexer
-description: Context-managed Provider for evidence-bound code knowledge. Use only when the Context Indexer lifecycle selects this Provider, not as a standalone workflow.
+description: Context-managed Provider for source-grounded code knowledge. Use only when the Context Indexer lifecycle selects this Provider, not as a standalone workflow.
 metadata:
   context-role: "indexer-provider"
   context-public-entry: "false"
-  context-provider-version: "1.0.0"
+  context-provider-version: "1.1.2"
 ---
 
 # Context Code Indexer
@@ -15,6 +15,33 @@ shared Provider/customization guide before publishing or extending this Skill.
 Those documents are authoring contracts; the current workset and Route remain
 execution authority.
 
-Use this Provider only through the Context Indexer lifecycle. The workspace registry selects an exact profile, version, integrity, scope, and operation. Do not scan outside the supplied workset or write project files directly.
+Use this Provider only through the Context Indexer lifecycle. The workspace registry selects an exact profile, version, integrity, scope, and operation. Consume evidence only from the single Context-supplied Authorized Workset View; do not scan outside the supplied workset, construct pagination/receipt requests, or write project files directly.
+
+Keep machine identity and reader content deliberately small. A durable Fact
+locator may identify a relation or declaration, but must never embed a source
+expression, implementation body, complete tool response, credential-like value,
+or other source text; keep such material in the process-local protected payload.
+Write for a consumer outside the indexed module: show what the module is
+responsible for, when and how to enter it through stable interfaces, where it
+hands off, and which core state, failure, operation, or source-of-truth facts are
+needed for correct use and attribution. Effective coverage means answering these
+supported reader questions across stable capabilities, not maximizing the number
+of symbols or paths mentioned.
+Every reader Artifact must answer the selected profile's concrete questions from
+current facts. A symbol/path list, generic module summary, workflow explanation,
+or internal Fact/View/digest count is not useful knowledge and must not be emitted.
+Before emitting an Artifact, identify the concrete selected-profile question
+that its logical unit answers. Formal question refs may close required coverage,
+but a group label, Partition Subject, or large Fact volume alone is not a reader
+purpose; a unit with no applicable profile question is catalog-only.
+Bind each reader claim only to the smallest relevant evidence set; never attach
+an entire workset inventory to a generic summary.
+Close inventory members with their actual boundary evidence or a legal
+catalog/exclusion disposition. Never reuse one unrelated fallback evidence
+binding merely to make the disposition denominator appear complete.
+When a large module exposes stable route, capability, protocol, runtime, or
+storage boundaries, partition on those boundaries before authoring. Do not put
+the whole module in one catch-all logical unit, and do not replace semantic
+partitioning with numbered batches.
 
 The machine-readable authority is `context-indexer.yaml`. Detailed authoring guidance is materialized by Context from the registered Bundle after its file ledger and integrity have been verified.

package/plugins/skills/context-code-indexer/context-indexer.yaml

@@ -1,6 +1,6 @@
 protocol: context.indexer.provider/v1
 id: context-code-indexer
-version: 1.0.0
+version: 1.1.2
 domains: [code]
 
 activation:
@@ -62,14 +62,9 @@ provides:
       priority: 200
   operations:
     - id: main-index
-      consumes: context.indexer.main-workset/v1
+      consumes: context.indexer.main-workset/v2
       produces: context.indexer.main-result/v1
       accepts_layer_fragments: [fact-enrichment, template-variables]
-    - id: material-answer
-      consumes: context.indexer.material-question-workset/v1
-      produces: context.indexer.material-answer-result/v1
-      supported_evidence_kinds: [code, contract, configuration, documentation, runbook, test-result, runtime-observation]
-      accepts_layer_fragments: [fact-enrichment]
   layer_fragments:
     - kind: derived-artifact-proposal
       phase: post-author
@@ -209,7 +204,7 @@ provider:
     - { id: contract-source, profile: contract-source, path: templates/contract-source.md }
     - { id: derived-generated-source, profile: derived-generated-source, path: templates/derived-generated-source.md }
   forbidden_fallbacks: [one-page-per-symbol, ordinal-batch-pages, inferred-runtime-chain]
-  completion_checks: [inventory-disposition-closure, subject-owner-closure, evidence-binding]
+  completion_checks: [inventory-disposition-closure, subject-owner-closure, source-coverage]
 
 customization:
   supports: [config, instructions-append, template-override, program-extend]