@c4a/context-cli 0.7.1 → 0.7.4

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,11 +115,11 @@ 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
 
@@ -158,15 +132,11 @@ 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
+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. Report those bundled entries
+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,
@@ -180,9 +150,7 @@ 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
+Provider. Keep different versions separate; 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
@@ -191,36 +159,23 @@ write it to `src/`, `package.json`, lifecycle state, receipts, audit output, or
 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.
+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 +183,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,11 +114,11 @@ 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
 
@@ -157,15 +131,11 @@ 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
+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. Report those bundled entries
+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,
@@ -179,9 +149,7 @@ 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
+Provider. Keep different versions separate; 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
@@ -190,36 +158,23 @@ write it to `src/`, `package.json`, lifecycle state, receipts, audit output, or
 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.
+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 +182,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.1"
 ---
 
 # 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.1
 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]

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

@@ -1,6 +1,13 @@
 # Code Indexer authoring contract
 
-Consume only the current workset, normalized parser facts, verified layer input, and scoped evidence views supplied by Context.
+Consume only the current workset authority and the single Authorized Workset View supplied by Context. Normalized parser facts, verified layer fragments, document evidence, and tool observations all arrive through that View; do not open source-specific evidence channels or manage their pagination and receipts.
+
+The reader is outside the indexed module. Give that reader a reliable route to
+the module's responsibility, supported entrypoints and interfaces, downstream
+handoffs, and the core state, failure, operation, ownership, and source-of-truth
+facts needed to use or attribute the capability correctly. Judge coverage by
+whether supported profile questions and stable capability boundaries are
+actually explained, never by symbol, file, relation, or evidence counts.
 
 ## Classify before selecting templates
 
@@ -16,14 +23,77 @@ Use only the ordered partition strategy materialized by Context for the current
 
 Group related identities by a capability, entrypoint, protocol boundary, lifecycle stage, state owner, or handoff. A granular catalog is appropriate only when the selected profile and reader goal require a public API, protocol, command, or registry reference. A cross-module chain requires an explicit trigger, source-backed joins on both sides of every boundary, transformations or state handoffs, and a terminal outcome; imports or similar names do not prove execution order.
 
+A module-level overview may be one logical unit, but it must not own every
+member of a large application or service when current facts expose stable route
+families, public capability families, protocol surfaces, runtime workers, or
+storage boundaries. Give those boundaries separate semantic groups and keep the
+overview limited to navigation and shared lifecycle. This keeps each Author View
+bounded enough to inspect and prevents a catch-all page from replacing useful
+knowledge. Never split by traversal order, member count, or numbered batches.
+Renaming a fact-kind bucket such as all relations or all symbols is not semantic
+partitioning; assign cross-boundary facts to the smallest capability, protocol,
+runtime, or state boundary that they actually explain.
+
 Create a reader target only from a CLI-supplied declaration, public export, contract declaration, runtime registration, approved Subject, or Partition Subject identity. Import/re-export aliases, ordinary references, internal helpers, and lightweight evidence may enrich their canonical owner but cannot independently authorize a target. Normalize aliases into the supplied canonical identity. Never promote a name merely because it appears in prose or has many inbound references.
 
+## Durable identity and reader-output boundary
+
+Keep durable locator identities compact and semantic. A locator may contain a
+normalized file coordinate, declaration identity, relation kind, line and a
+content digest, but never a raw call expression, implementation body, complete
+configuration value, remote response, secret, token, or credential-like source
+text. Full source material belongs only in the bounded process-local Fact payload;
+reader prose consumes its verified meaning, not the internal carrier.
+
+The selected profile templates are mandatory authoring guidance. Use current
+facts to answer their reader questions about responsibility, entrypoints,
+contracts, state, handoffs, failure behavior, configuration and operation. Omit
+unsupported sections. Do not replace those answers with a generic introduction,
+an exhaustive or representative symbol/path list, Parser/Indexer ownership text,
+selected-Fact counts, View/receipt/digest metadata, or claims about what the
+pipeline did. Those details neither help a reader nor recover production state.
+
+State caller-visible contracts directly when current facts support them:
+required inputs, defaults, quantity or size limits, and asymmetric rules between
+operations or variants. Naming an internal validator, mapper, hook, or generic
+"validation" step does not explain the contract. Omit details that current facts
+cannot prove rather than inferring them from an implementation name.
+
 ## Author Result and evidence
 
 For author work, produce exactly one Result for the supplied logical unit. Keep deterministic catalogs separate from explanatory prose, bind every declaration and Section to current evidence, and select only an Artifact policy variant listed in the workset. Missing material must become a canonical question disposition; never invent an answer or emit placeholder knowledge.
 
+Before authoring, identify the concrete selected-profile question that the
+logical unit answers. Formal question refs are used only when the workset
+authorizes them, but their absence does not permit generic prose: do not turn the
+Partition Subject, group label, or available Fact volume into an implied reader
+purpose. Close the group as catalog-only when no profile question applies, or
+return to requirement/registry planning when required coverage lacks authority.
+
+An inventory group with no reader-authorizing public export, contract, runtime registration, approved Subject, or Partition Subject is catalog-only. Close its inventory dispositions and return no reader Artifact; do not publish a page that merely says the unit exists. Conversely, when the workset supplies current contract facts such as public signatures, properties, events, defaults, variants, examples, or source roles, consume each applicable fact in the matching template question or give it an explicit legal disposition. A generic directory summary is not a substitute for supplied contract facts.
+
+For every Section, select the exact `document_kind`, `reader_goal`, and `artifact_kind` tuple declared by the current profile's unique layout mapping. Do not invent a tuple or return a collection name; Context resolves the collection mechanically from that mapping.
+
+When the same Authorized Workset View contains CLI-authorized captured documents or tool snapshots, treat them as ordinary input evidence for the current logical unit. Use that material to answer a supplied question only when its evidence contract permits; otherwise keep the canonical material-gap disposition. Do not create a second answer flow or inspect registered sources outside the View.
+
 Treat the CLI inventory as the complete denominator, not a sample. Parser facts may prove files, declarations, entries, contracts, and relationships; they do not by themselves prove business meaning, runtime defaults, failure behavior, or ownership. Every relationship must cite the concrete evidence for its own handoff. Do not repeat one whole-page evidence set across unrelated facts, and do not reduce a multi-source fact to one arbitrary primary file.
 
+Inventory closure is not a license to attach a convenient fallback binding to
+unrelated members. A `boundary-only` member still needs evidence that places
+that member in the current semantic boundary; otherwise use the legal catalog,
+exclusion, unsupported, or material-gap disposition that describes its actual
+state. Denominator completeness with false attribution is invalid.
+
+Before declaring a dependency or handoff unverified, inspect the complete authorized
+source identity inventory for `code-relation` members and join their caller/callee
+identity to the supplied source spans. Relationship members can enrich a logical
+unit even when they are not primary partition members and do not need to be copied
+into the Result fact inventory. A large relation inventory is not evidence absence:
+select the few relations that cross a stable module, protocol, runtime, store, or
+generated-client boundary, then explain that boundary from the corresponding code
+span. Request material only when those authorized relations and spans still cannot
+establish the handoff.
+
 Close every CLI-supplied example candidate with exactly one decision: link it to its public target, merge it into a canonical example for the same target and scenario, retain it as a documentation example, exclude it with a reason, or request missing material. A retained representative must decide setup, key calls, parameters, and expected behavior as either extracted facts or evidence-backed not-applicable facets. Merge only by the full example identity supplied by Context; filenames and basenames are not identities. Do not omit an unresolved candidate from the decision set, and do not treat a material request as completed linkage.
 
 Explain stable responsibility, inputs, outputs, state and failure boundaries, the next handoff, and the evidence that supports each claim. Keep implementation bodies, generated payloads, exhaustive internal helper lists, and normalized template repetition out of reader prose. Empty Results are valid only when every target receives a legal disposition.
@@ -36,14 +106,47 @@ If a declared primary fact or Artifact requirement is absent, or the view does n
 
 ## Mechanical audit and revision
 
-Context independently validates inventory closure, owner closure, parser coverage, Artifact completeness, evidence scope, relationship candidates, semantic density, template repetition, enumeration, and implementation-body limits. These dimensions are independent; one strong dimension cannot offset a hard failure in another. Do not alter wording, Markdown syntax, sentence counts, or partitions solely to influence a counter.
+Context independently validates production invariants it can derive from current
+inputs, including inventory and owner closure, parser coverage, Artifact
+completeness, source scope, identity, layout, and currentness. These failures
+block the current Result and must be fixed at their source.
+
+Profile metrics are authoring guidance, not a second readiness protocol. Use
+`references/metrics.md` when the Result exhibits a real reader problem, but do
+not alter wording, Markdown syntax, sentence counts, or partitions merely to
+influence a counter. Context does not accept an Agent-supplied score as proof
+that a Result is ready.
+
+## Two classes of evidence in a template Evidence pass
+
+A template Evidence pass lists what to locate. Those entries do not all resolve the same way, and the difference decides whether an assertion can be written at all.
+
+The parsers name structural identity and declarative contracts: files and symbols, imports and call relations, configuration values, source spans, page and redirect routes, workspace and release units, protocol services, methods and types, contract endpoints and operations, maintained examples and public target links, stylesheet modifiers, tables, views and indexes, and generated-source boundaries. When an Evidence pass entry falls in this set, a fact carries it and the assertion binds to that fact.
+
+Nothing in the parser layer is named for operational behavior. There is no fact for a retry, a timeout, a lifecycle transition, a permission, a schedule, a topic or queue identity, idempotency, concurrency, ordering, a cache, a transaction, observability, a CLI command or flag, an exit code, or a component prop, slot, or variant. Templates still ask you to locate these, because they are what the reader needs — but they resolve only through a configuration value, a source span, or a relation that literally states them.
 
-For a failed metric, follow the matching entry in `references/metrics.md`. Each entry explains the denominator-preserving repair, a positive example, and an anti-example. It deliberately contains no numeric threshold: use the current CLI audit for actual, recommended, and hard values.
+So for this second class: base the assertion on the configuration value or
+source span that states the behavior, and name the identity it uses. If nothing
+in the authorized view states it, the behavior is a material gap. Write the
+gap. Do not convert a library dependency, a symbol name, or a familiar
+framework convention into a behavioral claim. Context validates structured
+references, but final Review remains responsible for rejecting unsupported
+prose.
 
-The reference-only reader-target metric is a zero-count hard gate. Context joins the proposed reader-target projection to its own current identity observations and separately rejects targets with no identity observation at all. Provider prose, display titles, filenames, inbound-reference counts, and self-reported target authority cannot satisfy this gate.
+Every profile template ends with a `Revise or stop when` condition. Stopping means recording the material gap that blocks the question — the evidence that is missing and what would resolve it — and never silently dropping the question from the Result. A template that tells you to stop when discovery is inferred is telling you not to guess, not to omit. Dropping the question satisfies no entry and fails question closure.
 
-Context recomputes example candidate decision coverage over the complete example inventory. Representative coverage and public-target linkage keep undecided and material-request candidates in their denominator, while only a confirmed exclusion removes a candidate. A scenario variant inherits coverage only when its canonical decision chain terminates at a retained representative; it inherits public-target linkage only when that terminal decision links the exact public target.
+The complete reader-question set and canonical inventory are production
+obligations rather than quality scores. A PartitionPlan must cover the current
+question set, dispositions must cover the inventory, and an answered question
+must satisfy its evidence contract. Natural-language sentences are not checked
+one by one by a metric engine; keep them grounded in the supplied material and
+use final Review to remove unsupported interpretation. Excluding inventory may
+close a disposition, but it does not manufacture an answer to a reader
+question.
 
-When the current audit reports a repairable profile failure, revise the complete affected logical-unit set and return a new Result under the same stable problem lineage. Use the reported uncovered identities, failed metric ids, evidence locators, and legal actions. Request material only when reliable correction requires a source, contract, protocol, or access boundary absent from the registered scope. Three failed revisions produce one complete human report; only the explicit non-delegable profile-risk Gate may accept that runtime profile risk, and no baseline integrity failure is bypassable.
+A required question with no authorized supporting material remains a material request and cannot be published. Repairable content feedback reopens the owning Author or Composer through the same `context revise` lifecycle. Context does not keep a profile retry ledger and does not provide a profile-risk override Gate.
 
-Do not return output paths, collection names, quality thresholds, pass/fail decisions, extra owners, ad hoc question contracts, or facts outside the supplied authority. Context validates structure, evidence, layout, metrics, freshness, reconciliation, and final Review independently.
+Do not return output paths, collection names, quality thresholds, pass/fail
+decisions, extra owners, ad hoc question contracts, or facts outside the
+supplied authority. Context validates deterministic structure, references,
+layout, freshness, reconciliation, and final Review independently.