@c4a/context-cli 0.7.1 → 0.7.5

package/indexers/bundles/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/indexers/bundles/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]

package/indexers/bundles/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.

package/indexers/bundles/context-code-indexer/references/metrics.md

@@ -1,20 +1,77 @@
 # Profile metric revision guide
 
-Use the current CLI audit as the sole source of actual, recommended, and hard values. This guide explains how to revise a Result; it does not define thresholds or authorize changing a denominator.
+This guide names reader-facing quality problems and explains how to revise a
+Result. It does not define a second readiness check, ask the Agent to score its
+own output, or authorize changing the profile contract.
+
+## What this catalog does not prove
+
+Read this before treating a metric catalog as proof of success. These entries
+describe useful review lenses, but they do not read prose for meaning and they
+do not replace Context's deterministic validation or final Review. A Result can
+look tidy by these measures and still fail to answer a reader's question.
+
+Count entries point to shapes that should normally disappear, coverage entries
+ask whether a known inventory was handled, and ratios help find excessive
+duplication or scaffolding. They interact, so repair the reader problem rather
+than optimizing one number in isolation.
+
+One entry, `discretionary-artifacts-per-logical-unit`, is judged
+comparatively rather than against a fixed ceiling: it reacts to inflation
+relative to the selected Bundle variant. Do not look for a constant here.
+
+Context blocks only facts it can calculate from current authority, including
+workset identity, complete question planning, inventory disposition coverage,
+evidence contracts, layout and currentness. Natural-language usefulness and
+support remain authoring and final-Review responsibilities. No Agent-supplied
+metric value can weaken or satisfy those checks.
+
+## Do not satisfy one entry by breaking another
+
+These conflicts are the common cause of a second failed audit.
+
+The inventory denominator is protected. Reduce
+`narrative-enumeration-ratio` by relocating identities into the deterministic
+catalog, never by dropping them from the Result. A dropped identity converts an
+enumeration finding into an `inventory-disposition-coverage` failure.
+
+Merging is not concatenation. When resolving
+`duplicated-fact-target-ratio`, name one canonical owner and replace the other
+copies with explicit relationships. Pasting several pages together moves the
+duplication into one page and raises its enumeration instead.
+
+A deterministic catalog is not a discretionary Artifact. When enumeration
+moves into a catalog, bind that catalog to the logical unit that owns it. Do
+not create a new optional Artifact to hold it, which trades an enumeration
+finding for artifact inflation.
+
+Re-home facts before removing a target. Satisfying
+`reference-only-reader-targets` means merging an alias or ordinary reference
+into its canonical owner. Deleting the target and its facts loses evidence and
+reopens disposition coverage.
+
+Regrouping must be semantic. Satisfying `unresolved-ordinal-partitions` by
+renaming numbered batches to non-numeric labels changes nothing; the identity
+must come from a boundary a reader can name.
 
 ## inventory-disposition-coverage
 
 ### Meaning
 
-Every identity in the CLI inventory needs an owned, excluded, or unsupported disposition.
+Every identity in the CLI inventory needs an owned, excluded, or unsupported
+disposition.
 
 ### Revise
 
-Return decisions for the reported missing identities, preserving the complete inventory denominator and citing the evidence behind exclusions or unsupported cases.
+Return decisions for the reported missing identities, preserving the complete
+inventory denominator and citing the evidence behind exclusions or unsupported
+cases.
 
 ### Positive example
 
-An internal generated file is retained in the inventory and marked excluded with its generated-source evidence.
+An internal generated file is retained in the inventory and marked excluded
+with its generated-source evidence, so a reader can see it was considered and
+why it carries no reader knowledge.
 
 ### Anti-example
 
@@ -24,11 +81,13 @@ The Result omits files that did not fit the selected template.
 
 ### Meaning
 
-The same reader fact should have one canonical target rather than competing copies across Artifacts.
+The same reader fact should have one canonical target rather than competing
+copies across Artifacts.
 
 ### Revise
 
-Choose the canonical owner, replace other copies with explicit relationships, and keep evidence on the owning fact.
+Choose the canonical owner, replace other copies with explicit relationships,
+and keep evidence on the owning fact.
 
 ### Positive example
 
@@ -42,33 +101,55 @@ Several pages repeat the same behavior paragraph with different headings.
 
 ### Meaning
 
-Reader prose should explain capabilities and boundaries instead of restating a deterministic inventory as sentences.
+Reader prose should explain capabilities and boundaries instead of restating a
+deterministic inventory as sentences.
+
+The measured scope is reader prose only. A deterministic catalog Artifact that
+the Result declares as such is outside both the numerator and the denominator:
+a complete inventory is that Artifact's entire purpose, and counting it as
+narrative enumeration would penalise the Result for holding the catalog it was
+asked to produce. Count an identity once, in the prose that mentions it. An
+identity that lives only in a declared catalog is not counted at all.
 
 ### Revise
 
-Move exhaustive identities into the deterministic catalog, group related items by a reader question, and explain responsibility, differences, and handoffs.
+Move exhaustive identities into the deterministic catalog, group related items
+by a reader question, and explain responsibility, differences, and handoffs.
+
+One allowance serves every profile, because excluding declared catalogs from
+the scope already accounts for the profiles whose reader value lies in a
+complete inventory. A catalog-heavy Result is measured on its prose like any
+other, so a breach here means the prose itself restates the catalog rather than
+explaining it — never that the profile is inherently enumerative. Do not
+rewrite a catalog into prose, and do not move prose into a catalog to change
+the count: relocating an identity is legitimate only when the catalog is where
+the reader should look for it.
 
 ### Positive example
 
-A capability section explains dispatch choices and links to a complete generated route catalog.
+A capability section explains dispatch choices and links to a complete
+generated route catalog.
 
 ### Anti-example
 
-The page turns every discovered symbol into an “observed” bullet.
+The page turns every discovered symbol into an "observed" bullet.
 
 ## normalized-template-repetition-ratio
 
 ### Meaning
 
-Repeated sentence frames with only identity substitutions indicate template residue rather than evidence-specific explanation.
+Repeated sentence frames with only identity substitutions indicate template
+residue rather than evidence-specific explanation.
 
 ### Revise
 
-Merge repeated observations, describe the shared rule once, and record meaningful exceptions with their own evidence.
+Merge repeated observations, describe the shared rule once, and record
+meaningful exceptions with their own evidence.
 
 ### Positive example
 
-A family section states the common lifecycle and separately explains the exceptional member.
+A family section states the common lifecycle and separately explains the
+exceptional member.
 
 ### Anti-example
 
@@ -78,47 +159,58 @@ Every member receives the same sentence with only its name changed.
 
 ### Meaning
 
-Reader knowledge should describe stable behavior without copying implementation bodies, generated payloads, or declaration dumps.
+Reader knowledge should describe stable behavior without copying implementation
+bodies, generated payloads, or declaration dumps.
 
 ### Revise
 
-Replace copied code with an evidence-bound behavioral statement and retain only a small excerpt when it is necessary to explain a contract or failure boundary.
+Replace copied code with an evidence-bound behavioral statement and retain only
+a small excerpt when it is necessary to explain a contract or failure boundary.
 
 ### Positive example
 
-The page explains the validation and rollback sequence and links to the exact implementation locator.
+The page explains the validation and rollback sequence and links to the exact
+implementation locator.
 
 ### Anti-example
 
-The page embeds the complete function or generated type file as its main content.
+The page embeds the complete function or generated type file as its main
+content.
 
 ## reference-only-reader-targets
 
 ### Meaning
 
-A reader target requires a CLI-authorized declaration, registration, public contract, approved Subject, or Partition Subject identity.
+A reader target requires a CLI-authorized declaration, registration, public
+contract, approved Subject, or Partition Subject identity.
 
 ### Revise
 
-Merge aliases and ordinary references into their canonical owner, or remove the target when no authorized identity observation exists.
+Merge aliases and ordinary references into their canonical owner, or remove the
+target when no authorized identity observation exists.
 
 ### Positive example
 
-A re-export alias points to the canonical public target instead of creating another page.
+A re-export alias points to the canonical public target instead of creating
+another page.
 
 ### Anti-example
 
-A frequently imported helper becomes a target solely because it has many references.
+A frequently imported helper becomes a target solely because it has many
+references.
 
 ## unresolved-ordinal-partitions
 
 ### Meaning
 
-Partition identity must come from a stable semantic boundary, not traversal order or a fixed batch label.
+Partition identity must come from a stable semantic boundary, not traversal
+order or a fixed batch label.
 
 ### Revise
 
-Regroup members by capability, entrypoint, lifecycle stage, state owner, protocol boundary, or handoff; if none applies, return the protocol outcome for CLI-owned catalog fallback.
+Regroup members by capability, entrypoint, lifecycle stage, state owner,
+protocol boundary, or handoff; if none applies, return the protocol outcome for
+CLI-owned catalog fallback.
 
 ### Positive example
 
@@ -132,15 +224,18 @@ Files are divided into successive numbered batches to reduce page size.
 
 ### Meaning
 
-Optional Artifacts must answer distinct reader questions allowed by the selected Bundle variant.
+Optional Artifacts must answer distinct reader questions allowed by the
+selected Bundle variant.
 
 ### Revise
 
-Remove unsupported optional Artifacts, merge overlapping ones, or select another CLI-eligible variant when canonical facts justify it.
+Remove unsupported optional Artifacts, merge overlapping ones, or select
+another CLI-eligible variant when canonical facts justify it.
 
 ### Positive example
 
-An examples Artifact is retained because it explains a distinct usage scenario with independent evidence.
+An examples Artifact is retained because it explains a distinct usage scenario
+with independent evidence.
 
 ### Anti-example
 
@@ -150,33 +245,40 @@ The Result creates extra pages to spread the same prose across a larger Bundle.
 
 ### Meaning
 
-Every CLI-discovered example candidate needs one explicit terminal or merge decision.
+Every CLI-discovered example candidate needs one explicit terminal or merge
+decision.
 
 ### Revise
 
-Decide each reported candidate as linked, merged, documentation-only, excluded with reason, or blocked by a material request.
+Decide each reported candidate as linked, merged, documentation-only, excluded
+with reason, or blocked by a material request.
 
 ### Positive example
 
-A duplicate scenario is merged into a canonical example through its full example identity.
+A duplicate scenario is merged into a canonical example through its full
+example identity.
 
 ### Anti-example
 
-Unclear examples disappear from the Result without a disposition.
+A candidate whose purpose was unclear is left out of the Result entirely, so a
+later reader cannot tell whether it was rejected or never examined.
 
 ## example-representative-coverage
 
 ### Meaning
 
-Eligible scenarios need retained representatives that explain setup, key calls, parameters, and expected behavior.
+Eligible scenarios need retained representatives that explain setup, key calls,
+parameters, and expected behavior.
 
 ### Revise
 
-Promote or merge evidence-backed examples for the reported uncovered scenarios and close each required facet explicitly.
+Promote or merge evidence-backed examples for the reported uncovered scenarios
+and close each required facet explicitly.
 
 ### Positive example
 
-A canonical example covers the scenario and records evidence-backed not-applicable facets.
+A canonical example covers the scenario and records evidence-backed
+not-applicable facets.
 
 ### Anti-example
 
@@ -186,16 +288,20 @@ A path is listed as an example without explaining how or why it is used.
 
 ### Meaning
 
-Eligible examples should resolve to the exact public target they demonstrate whenever that target exists.
+Eligible examples should resolve to the exact public target they demonstrate
+whenever that target exists.
 
 ### Revise
 
-Resolve aliases, repair the terminal decision chain, and bind the representative to the CLI-supplied public target identity.
+Resolve aliases, repair the terminal decision chain, and bind the
+representative to the CLI-supplied public target identity.
 
 ### Positive example
 
-A scenario variant merges into a representative whose terminal decision links the canonical public target.
+A scenario variant merges into a representative whose terminal decision links
+the canonical public target.
 
 ### Anti-example
 
-An example is linked to a similarly named internal helper or only to a directory.
+An example is linked to a similarly named internal helper or only to a
+directory.

package/indexers/bundles/context-code-indexer/templates/adapter-integration.md

@@ -90,8 +90,8 @@ helper separately.
 Add structured edges only for concrete registration and call paths. Keep a
 narrative locator when dynamic dispatch prevents an unambiguous edge.
 
-Return `identityGroups` when several target identities share one explained
-adapter responsibility. Return every source-backed adjacency in
+Use one canonical semantic subject when several target identities share one
+explained adapter responsibility. Return every source-backed adjacency in
 `chainCandidates`, then provide one `chainCandidateDecisions` record for each
 candidate. A documented decision names the reader-facing view and emits its
 structured edge; an equivalent candidate merges into that canonical candidate;

package/indexers/bundles/context-code-indexer/templates/component-library.md

@@ -30,6 +30,14 @@ Treat stories and examples as usage evidence, not as authority for unsupported
 props or behavior. When generated declarations disagree with source, identify
 the authoritative source and record the gap.
 
+When the Authorized Workset View supplies a public declaration together with
+structured props, events, defaults, variants, maintained examples, or source
+roles, the corresponding reader section must consume those facts or record an
+explicit supported omission/material-gap disposition. Do not replace available
+contract facts with a generic statement about the component directory. A group
+without any reader-authorizing public declaration remains catalog-only and does
+not produce an empty component page.
+
 ## Questions the knowledge must answer
 
 1. Which component families are public, and how are they imported?

package/indexers/bundles/context-code-indexer/templates/gateway-facade.md

@@ -36,6 +36,22 @@ fields, imports, or transport-library dependencies.
 4. What timeout, retry, compatibility, and failure behavior is source-backed?
 5. Which generated artifacts are locators rather than independent authority?
 
+## Chapter blueprint
+
+```markdown
+# <Gateway or facade boundary>
+## Exposed and translated responsibilities
+## Operations provided or consumed
+## Request, identity, and context mapping
+## Timeout, retry, compatibility, and failure translation
+## Contract authority and generated bindings
+## Source-backed provider-to-consumer relationships
+```
+
+Operations belong under the operations chapter as canonical records. Do not
+promote a single operation to a page heading unless its authority, security, or
+failure semantics differ materially from the rest of the boundary.
+
 ## Canonical operation record
 
 Use this record wherever another selected template asks for an operation,

package/indexers/bundles/context-markdown-indexer/SKILL.md

@@ -1,10 +1,10 @@
 ---
 name: context-markdown-indexer
-description: Context-managed Provider for evidence-bound document knowledge. Use only when the Context Indexer lifecycle selects this Provider, not as a standalone workflow.
+description: Context-managed Provider for source-grounded document 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 Markdown Indexer
@@ -15,6 +15,16 @@ the shared Provider/customization guide before publishing or extending this
 Skill. Those documents are authoring contracts; the current captured evidence,
 workset and Route remain execution authority.
 
-Use this Provider only through the Context Indexer lifecycle. Context supplies exact captured sources, profile authority, worksets, and evidence views; the Provider does not read arbitrary workspace paths or write approved knowledge directly.
+Use this Provider only through the Context Indexer lifecycle. Context supplies exact profile/workset authority and one Authorized Workset View containing the permitted captured evidence. The Provider does not open source-specific readers, manage pagination/receipts, read arbitrary workspace paths, or write approved knowledge directly.
+
+Treat the captured document as reader material, not as pipeline metadata. Every
+reader Artifact must preserve or synthesize the source-backed guidance needed by
+the selected profile. A heading inventory, directory summary, generic document
+description, internal Fact/View/digest count, or a sentence sending the reader
+back to the source is not useful knowledge and must not be emitted. Keep
+execution receipts, content digests, internal refs, and other recovery machinery
+out of reader Markdown. Bind each reader claim only to the smallest relevant
+source span or captured evidence set; never attach a whole document corpus or
+Authorized Workset View to a generic summary.
 
 The machine-readable authority is `context-indexer.yaml`. Context materializes the detailed guidance only after verifying this Bundle's release identity and complete file ledger.