@c4a/context-cli 0.6.19 → 0.7.0

package/plugins/skills/context-code-indexer/references/composers/development-and-delivery.md

@@ -0,0 +1,22 @@
+---
+id: context.code-indexer.composer.development-and-delivery
+kind: procedure
+media-type: text/markdown
+---
+
+# Development and delivery composer
+
+Run only for an effective `development-and-delivery` workset. It supplements
+the primary target and cannot own repository scope, release authority, or the
+final Indexer Result.
+
+Require an evidenced `development-entry` fact and primary `content` Artifact.
+Propose derived `content` only for module-owned setup, build, test, packaging,
+deployment, release, rollback, or recovery behavior that answers a stable
+reader question. Distinguish local commands from CI orchestration and record
+configuration inputs without copying secret-like values.
+
+Use the existing Node, `standard` policy, and view evidence. Workspace-wide
+processes belong on a container target, not every module. If the required input
+is absent or the view contains no module-owned development/delivery contract,
+return `fragments: []` in the ordinary structured result.

package/plugins/skills/context-code-indexer/references/composers/event-flow.md

@@ -0,0 +1,21 @@
+---
+id: context.code-indexer.composer.event-flow
+kind: procedure
+media-type: text/markdown
+---
+
+# Event flow composer
+
+Run only from an effective `event-flow` workset. The supplied primary view is
+the complete authority boundary for this invocation.
+
+Require an evidenced `event-binding` fact and primary `content` Artifact.
+Propose derived `content` only when a stable event identity connects producer,
+transport or dispatch, consumer, state effect, retry/idempotency behavior, and
+failure handling. Timers and scheduled triggers qualify only when their
+registration and downstream behavior are explicit.
+
+Keep the current target Node, use `standard`, and cite view evidence. Do not
+invent a producer from a consumer name or infer delivery guarantees from a
+library default. Missing requirements, an unpaired boundary, or no additional
+reader value must return the normal result envelope with `fragments: []`.

package/plugins/skills/context-code-indexer/references/composers/examples-and-documentation.md

@@ -0,0 +1,22 @@
+---
+id: context.code-indexer.composer.examples-and-documentation
+kind: procedure
+media-type: text/markdown
+---
+
+# Examples and documentation composer
+
+Run only when selected for the current profile. The workset-scoped primary
+view is the sole input; documentation files outside that view are not implicit
+authority.
+
+Require an evidenced `example-candidate` fact and primary `content` Artifact.
+Propose an `examples` Artifact only for maintained usage that demonstrates a
+supported public target, meaningful setup, expected outcome, and important
+constraints. Merge scenario variants and exclude fixtures, generated samples,
+and demos that do not represent supported use.
+
+Use the existing target Node and `standard` policy. Evidence must come from the
+view. When no representative example closes the reader question, or either
+required input is missing, return the structured empty fragment-set result;
+never invent tutorial steps.

package/plugins/skills/context-code-indexer/references/composers/persistence-boundary.md

@@ -0,0 +1,21 @@
+---
+id: context.code-indexer.composer.persistence-boundary
+kind: procedure
+media-type: text/markdown
+---
+
+# Persistence boundary composer
+
+Run only for an effective `persistence-boundary` selection. Consume the exact
+`PrimaryResultView` and keep all proposals subordinate to its Node and Result.
+
+Require an evidenced `persistence-binding` fact and primary `content`
+Artifact. Derived `content` may connect the domain operation to repository or
+store, model/schema authority, transaction or consistency boundary, caching,
+migration, failure, and recovery. Separate authoritative schema sources from
+generated models and runtime observations.
+
+Use `standard` and existing evidence. Do not infer storage semantics from a
+driver dependency or method name. If the binding, required Artifact, or a
+source-backed persistence question is absent, return a valid empty fragment
+set rather than reading outside the workset.

package/plugins/skills/context-code-indexer/references/composers/protocol-boundary.md

@@ -0,0 +1,22 @@
+---
+id: context.code-indexer.composer.protocol-boundary
+kind: procedure
+media-type: text/markdown
+---
+
+# Protocol boundary composer
+
+Run only for an effective `protocol-boundary` composer workset and consume its
+exact `PrimaryResultView`. Never discover new scope or claim final Result
+authority.
+
+Require an evidenced `protocol-operation` fact and a primary `contract`
+Artifact. A derived `contract` proposal may connect a stable operation identity
+to transport, request/response or message shapes, provider and consumer,
+errors, compatibility, and authoritative schema evidence. Keep generated
+clients and bindings pointed at their source contract.
+
+Use the existing target Node and `standard` policy. Do not infer operations
+from names or import adjacency. If the required fact/Artifact is missing, the
+provider/consumer pairing is ambiguous, or the primary contract already
+answers the reader question, return a valid result with `fragments: []`.

package/plugins/skills/context-code-indexer/references/composers/public-contract.md

@@ -0,0 +1,23 @@
+---
+id: context.code-indexer.composer.public-contract
+kind: procedure
+media-type: text/markdown
+---
+
+# Public contract composer
+
+Run only for an effective `public-contract` composer workset. Consume the
+workset-scoped `PrimaryResultView`; do not inspect a broader repository or
+replace the primary Result.
+
+Require an evidenced `public-surface` fact and its owning primary `content`
+Artifact. Propose a `contract` Artifact only when the view establishes stable
+consumer identities, entrypoints, behavior, constraints, and evidence. Group
+related exports, commands, routes, or extension points by the public concept a
+consumer uses; do not enumerate incidental symbols.
+
+Every proposal must retain the existing target Node, use the `standard`
+Artifact policy variant, and cite evidence already present in the view. Return
+only a post-author `derived-artifact-proposal` fragment. If either required
+input is absent or no independent reader question is supported, return the
+normal layer-fragment result with `fragments: []`.

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

@@ -0,0 +1,49 @@
+# Code Indexer authoring contract
+
+Consume only the current workset, normalized parser facts, verified layer input, and scoped evidence views supplied by Context.
+
+## Classify before selecting templates
+
+Classify each requested module from current manifests, stable entries, public contracts, runtime registration, maintained documentation, and source-backed boundary evidence. Select one primary profile and only the additional profiles supplied by the current workset. A directory name, framework dependency, class suffix, or generated file is not sufficient classification evidence.
+
+Read only the templates materialized for the selected profiles. Combine their questions into one deduplicated plan for the reader-visible capability; a template is guidance, not a source of facts, page counts, output paths, thresholds, or authority. Keep a repository container, public contract, runtime boundary, event flow, persistence boundary, adapter, generated-source provenance, and cross-module handoff separate when they answer different reader questions. Do not copy a template outline when source evidence does not support its sections.
+
+## Partition and identity
+
+For partition work, close every inventory member as owned, excluded, or unsupported and use stable semantic subjects. Each member has exactly one primary owner; extension layers may enrich but cannot claim final authority. Do not create ordinal batches or infer identity from display titles, filenames, headings, or traversal order. If no defensible semantic grouping exists, return the protocol failure that permits the CLI-owned catalog fallback.
+
+Use only the ordered partition strategy materialized by Context for the current workset. The order is project-first and authority-bound; do not skip to a CLI builtin, substitute another strategy id, or recalculate an implementation digest. A strategy may group only the canonical members and profiles supplied with that workset.
+
+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.
+
+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.
+
+## 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.
+
+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.
+
+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.
+
+## Post-author composer result
+
+For a post-author workset, use only the effective composer named by Context and the matching composer instruction materialized beside this contract. Consume the complete workset-scoped `PrimaryResultView`; do not reopen discovery, expand scope, change Subject identity or ownership, or return another complete main Result. A composer may emit only the declared `derived-artifact-proposal` kind and Artifact policy.
+
+If a declared primary fact or Artifact requirement is absent, or the view does not support an independent reader question, return the ordinary `context.indexer.layer-fragment-result/v1` with `fragments: []` and the exact consumed view digest. This is a successful structured empty invocation, not a license to inspect temporary files or infer missing content.
+
+## 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.
+
+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.
+
+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.
+
+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.
+
+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.
+
+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.

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

@@ -0,0 +1,201 @@
+# 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.
+
+## inventory-disposition-coverage
+
+### Meaning
+
+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.
+
+### Positive example
+
+An internal generated file is retained in the inventory and marked excluded with its generated-source evidence.
+
+### Anti-example
+
+The Result omits files that did not fit the selected template.
+
+## duplicated-fact-target-ratio
+
+### Meaning
+
+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.
+
+### Positive example
+
+One contract Artifact owns the request semantics while the overview links to it.
+
+### Anti-example
+
+Several pages repeat the same behavior paragraph with different headings.
+
+## narrative-enumeration-ratio
+
+### Meaning
+
+Reader prose should explain capabilities and boundaries instead of restating a deterministic inventory as sentences.
+
+### Revise
+
+Move exhaustive identities into the deterministic catalog, group related items by a reader question, and explain responsibility, differences, and handoffs.
+
+### Positive example
+
+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.
+
+## normalized-template-repetition-ratio
+
+### Meaning
+
+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.
+
+### Positive example
+
+A family section states the common lifecycle and separately explains the exceptional member.
+
+### Anti-example
+
+Every member receives the same sentence with only its name changed.
+
+## implementation-body-ratio
+
+### Meaning
+
+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.
+
+### Positive example
+
+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.
+
+## reference-only-reader-targets
+
+### Meaning
+
+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.
+
+### Positive example
+
+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.
+
+## unresolved-ordinal-partitions
+
+### Meaning
+
+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.
+
+### Positive example
+
+Handlers are grouped by the reader-visible protocol capability they implement.
+
+### Anti-example
+
+Files are divided into successive numbered batches to reduce page size.
+
+## discretionary-artifacts-per-logical-unit
+
+### Meaning
+
+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.
+
+### Positive example
+
+An examples Artifact is retained because it explains a distinct usage scenario with independent evidence.
+
+### Anti-example
+
+The Result creates extra pages to spread the same prose across a larger Bundle.
+
+## example-candidate-decision-coverage
+
+### Meaning
+
+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.
+
+### Positive example
+
+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.
+
+## example-representative-coverage
+
+### Meaning
+
+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.
+
+### Positive example
+
+A canonical example covers the scenario and records evidence-backed not-applicable facets.
+
+### Anti-example
+
+A path is listed as an example without explaining how or why it is used.
+
+## example-public-target-linkage
+
+### Meaning
+
+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.
+
+### Positive example
+
+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.

package/plugins/skills/context-code-indexer/templates/adapter-integration.md

@@ -0,0 +1,119 @@
+---
+id: context.code-indexer.template.adapter-integration
+kind: procedure
+media-type: text/markdown
+---
+
+# Adapter, bridge, and integration template
+
+Use for `adapter-integration`: BFFs, protocol bridges, host integrations, plugin adapters,
+compatibility layers, gateways, and translators whose stable responsibility is
+to connect two boundaries. An ordinary internal helper that converts one object
+is not automatically an adapter module.
+
+Use the exact profile and Artifact policy variant supplied by the workset. For
+an inbound operation surface, combine this template with the selected gateway
+or protocol evidence without creating a second operation registry.
+
+## Evidence pass
+
+Locate both sides of the boundary and the code that joins them:
+
+- inbound operation, event, command, host hook, or extension registration;
+- outbound operation, client, plugin contribution, or runtime capability;
+- authoritative input and output contract locations;
+- identity, field, enum, version, and lifecycle mappings;
+- authentication, authorization, credential, and context propagation;
+- validation, normalization, batching, caching, fallback, and compatibility;
+- timeout, retry, partial failure, and error/status translation;
+- configuration, feature selection, ownership, and release entrypoints;
+- generated DTOs/clients and converter helpers that should remain evidence.
+
+Sample representative paths from each mapping family. Do not claim a mapping
+from matching field names alone.
+
+## Questions the knowledge must answer
+
+1. Which two boundaries does the adapter connect, and who owns each one?
+2. What triggers the mapping and where is it registered?
+3. Which fields, identities, versions, or lifecycle states are transformed?
+4. Which values pass through unchanged, default, or intentionally disappear?
+5. How are credentials, context, errors, retries, and fallbacks translated?
+6. Which contracts are authoritative and which artifacts are generated?
+7. What compatibility obligation makes the adapter stable knowledge?
+
+## Suggested knowledge units
+
+- **Adapter contract**: responsibility, inbound/outbound boundaries,
+  registration, ownership, and authoritative contracts.
+- **Operation mapping registry**: use the canonical operation record from
+  `protocol-boundary.md` and add only adapter-specific transformation fields.
+- **Data or identity mapping**: only stable, non-trivial mappings that readers
+  must understand; summarize generated field copies.
+- **Lifecycle and failure translation**: when activation, cancellation,
+  retries, partial failure, or compatibility behavior is material.
+- **Cross-module execution path**: when both connected modules are registered
+  sources and the chain is source-backed.
+
+## Chapter blueprints
+
+```markdown
+# <Adapter> contract
+## Responsibility and connected boundaries
+## Activation or registration
+## Inbound contracts
+## Outbound contracts
+## Data, identity, and lifecycle mapping
+## Authentication and context propagation
+## Error, retry, fallback, and compatibility behavior
+## Configuration, ownership, and release
+## Evidence and exclusions
+```
+
+For adapter-specific detail attached to a canonical operation record:
+
+```markdown
+## Adapter transformation
+- Mapper/handler entry:
+- Field/identity/default transformations:
+- Context and credential propagation:
+- Error and fallback mapping:
+```
+
+## Granularity and relationships
+
+Group mappings that share the same boundary pair and transformation policy.
+Split when protocol authority, ownership, lifecycle, or failure semantics
+differ. Do not publish every DTO, converter, generated client, or transport
+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
+`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;
+false positives and missing external material use `exclude` or `request-input`
+with a concrete reason. Read `contracts-and-chains.md` for the complete generic
+contract.
+
+## Template composition examples
+
+- An HTTP endpoint backed by an RPC client is `api-service` + `adapter-integration`; combine
+  one operation registry with one mapping contract rather than duplicating the
+  route facts.
+- A host plugin bridge reads `plugin-extension.md` and may also be `sdk-library`
+  when consumers import
+  a supported extension API.
+- A compatibility wrapper over generated clients also reads
+  `derived-generated-source.md` and identifies the authoritative schemas.
+
+## Revise or stop when
+
+- either side of the adapter cannot be identified;
+- mappings are inferred only from same-named types or fields;
+- credential, identity, or error behavior would be guessed;
+- generated DTOs are replacing authoritative contracts in the plan;
+- the adapter page would merely say that one module “calls” another.

package/plugins/skills/context-code-indexer/templates/api-service.md

@@ -0,0 +1,118 @@
+---
+id: context.code-indexer.template.api-service
+kind: procedure
+media-type: text/markdown
+---
+
+# API service and gateway template
+
+Use after classifying an inbound HTTP, RPC, GraphQL, message-request, or similar
+surface as `api-service`. A module that only calls a remote API is a protocol
+consumer, not automatically an API service. Gateways that translate to another
+protocol normally also selects `adapter-integration`.
+
+Use the exact profile and Artifact policy variant supplied by the workset. If
+the reader goal is primarily the transformation between inbound and outbound
+boundaries, use the selected adapter-integration profile and retain one
+canonical operation registry.
+
+## Evidence pass
+
+Locate and connect:
+
+- process/server entry and service startup;
+- route, method, resolver, or service registration;
+- middleware, authentication, authorization, validation, and request context;
+- handler dispatch and the first stable domain/downstream boundary;
+- authoritative IDL, OpenAPI, schema, service definition, or registration;
+- response/error mapping, retry, timeout, and compatibility behavior;
+- configuration, local run, test, deployment, and release entrypoints;
+- generated models or clients and their actual source of truth.
+
+Prefer explicit registrations over handler filenames. Sample enough operations
+from each registration family to verify that the proposed aggregation is real.
+
+## Questions the knowledge must answer
+
+1. What protocol does the module provide, and where is it registered?
+2. Which operations are stable and who handles each one?
+3. What authentication, validation, middleware, or request context applies?
+4. Where does each operation hand off to domain logic or a downstream system?
+5. How are successful responses and failures translated?
+6. Which schema is authoritative, and which files are generated projections?
+7. How is the service run, configured, observed, and released?
+
+## Suggested knowledge units
+
+- **Service boundary**: responsibility, startup, supported protocols,
+  middleware order, downstream systems, and ownership.
+- **Operation registry**: use the canonical operation record from
+  `protocol-boundary.md`, adding handler and middleware detail from this
+  template rather than creating a second registry.
+- **Dispatch and dependency map**: route/service registration to handler to
+  domain/RPC/repository boundary, grouped by coherent operation family.
+- **Error and compatibility contract**: only when status/error mapping,
+  versioning, fallback, or compatibility is stable and source-backed.
+- **Runtime and delivery guide**: configuration, startup, diagnostics,
+  deployment, and release entrypoints owned by this service.
+
+Do not create a page per generated request/response model, constant, converter,
+pack/unpack helper, or handler-local function.
+
+## Chapter blueprints
+
+A service-boundary page may use:
+
+```markdown
+# <Service> boundary
+## Responsibility and consumers
+## Startup and protocol registration
+## Middleware and request lifecycle
+## Operation families
+## Domain and downstream dependencies
+## Error, timeout, and compatibility behavior
+## Configuration, observability, and release
+## Exclusions and authoritative schemas
+```
+
+A focused execution-path page may use:
+
+```markdown
+# <Operation> execution path
+## Inbound contract
+## Middleware and validation
+## Handler orchestration
+## Domain/downstream handoff
+## Response and error mapping
+## Source-backed edges
+```
+
+## Granularity and relationships
+
+Aggregate operations that share registration, middleware, handler family, and
+downstream ownership. Split when operation families have different contracts,
+owners, or execution paths—not merely because they are separate methods.
+
+Record a route-to-handler or handler-to-downstream edge only when the route
+table, registration, call site, or parser evidence is unambiguous. Generated
+types can locate fields but do not prove runtime behavior.
+
+## Template composition examples
+
+- A gateway that receives HTTP and calls RPC reads `adapter-integration.md` and
+  `protocol-boundary.md` in addition to this template.
+- An RPC service containing stable domain orchestration also reads
+  `domain-service.md`.
+- An event-triggered endpoint may require `event-flow.md`; background consumers
+  use `background-runtime.md`.
+
+## Revise or stop when
+
+- no registration or authoritative operation identity is available;
+- the plan lists handlers without connecting them to provided operations;
+- the only contract source is generated code with an unknown upstream schema;
+- security or error behavior would be guessed from names;
+- scan mode would expand models and helpers into hundreds of pages.
+
+Return a `request-material` disposition tied to a blocking material-question
+proposal when required protocol semantics remain unavailable before preview.