@c4a/context-cli 0.7.0 → 0.7.4

package/providers/context/resources/semantic/code-index/classification.md

@@ -1,270 +0,0 @@
----
-id: semantic.code-index.classification
-kind: procedure
-media-type: text/markdown
----
-
-# Classify code modules before choosing a template
-
-This procedure is the first semantic step for code extraction. Start from the
-Route-selected batch inspection. Do not open an archetype template and then fit
-the module to it. First classify every confirmed module from inspected evidence,
-then read only the matching templates.
-
-Classification determines which reader questions the index must answer. It
-does not grant access to undeclared sources, prove a relationship, or override
-the measured extraction preview.
-
-## 1. Use one batch evidence pass
-
-Use the inspection result for every confirmed module before opening more files.
-It already reports manifests, maintained documentation, entry candidates,
-protocol locators, lifecycle signals, and generic structural capabilities.
-Open source files only for unresolved facts, and follow stable registration or
-executable wiring rather than scanning the whole tree.
-
-Confirm, where applicable:
-
-- the module manifest or workspace registration;
-- its README or nearest maintained operating documentation;
-- build, executable, application, service, or library entrypoints;
-- route, command, service, event, job, plugin, or export registries;
-- authoritative protocol/schema locations and concrete consumer call sites;
-- generated, mirrored, vendored, legacy, test, fixture, and mock boundaries;
-- development, configuration, deployment, and release entrypoints owned by the
-  module.
-
-A language, framework dependency, exported symbol, or folder name does not by
-itself prove a module type.
-
-## 2. Record classification before reading templates
-
-Produce one batch table first:
-
-| module | primary type | additional types | facets | evidence paths | gaps |
-| --- | --- | --- | --- | --- | --- |
-| `customer-portal` | `web-application` | — | `page-routing`, `protocol-consumer` | `package.json`, `src/routes.ts` | upstream schema is external |
-| `edge-gateway` | `api-service` | `adapter` | `protocol-provider`, `protocol-consumer` | `cmd/server.go`, `api/openapi.yaml` | — |
-
-Each module must have:
-
-- one primary `moduleType` for concise reports;
-- every additional applicable type in `moduleTypes`;
-- relevant behavior and boundary `facets`;
-- concrete inspected paths in `moduleTypeEvidence`;
-- exact source-relative Markdown paths already read in `documents`;
-- an explicit gap when available source cannot support a reliable claim.
-
-Choose the primary type from the boundary through which a reader most often
-enters the module. A gateway is normally `api-service`, a plugin-hosting command
-application is normally `cli-tool`, and a generated client is normally
-`sdk-library`; their translation or provenance roles remain additional types.
-
-Supported types are:
-
-- `web-application`: browser, native mobile, desktop, embedded, or cross-platform
-  interactive applications with routes, pages, screens, or host integration;
-- `api-service`: an HTTP, RPC, GraphQL, message-request, or similar inbound
-  protocol surface with dispatch to handlers;
-- `service`: a stable domain/use-case or reusable service boundary whose public
-  operations coordinate implementation or persistence;
-- `background-runtime`: workers, consumers, schedulers, pipelines, functions,
-  or long-running processes driven by triggers rather than interactive calls;
-- `sdk-library`: a reusable package with a deliberately supported consumer API;
-- `cli-tool`: an executable tool organized around commands, flags,
-  configuration, outputs, and exit behavior;
-- `adapter`: a bridge that translates protocols, identities, models, lifecycle,
-  or host capabilities between boundaries;
-- `monorepo-container`: a workspace whose stable value is its child-module,
-  ownership, dependency, build, or release topology;
-- `derived-source`: generated, mirrored, vendored, or legacy source whose
-  authority lives elsewhere;
-- `contract-source`: an authoritative IDL, API description, schema, or contract
-  registry used by providers, consumers, generators, or validators;
-- `unknown`: the source is insufficient to classify without guessing.
-
-`unknown` cannot be combined with a known type. A hybrid module may combine
-several known types. Independent infrastructure definitions, migration sets,
-or data-model projects that do not fit a supported type remain `unknown` and
-use a project-owned inspection/extraction adapter; do not force them into an
-unrelated application type.
-
-## 3. Add composable facets
-
-Facets identify behavior that may cross the primary type:
-
-- `page-routing`: concrete route, page, screen, or navigation registration;
-- `public-api`: a deliberately supported programmatic consumer surface;
-- `protocol-provider` / `protocol-consumer`: inbound or outbound operation
-  boundaries with authoritative locators;
-- `event-producer` / `event-consumer`: asynchronous trigger and delivery flow;
-- `persistence`: repository, datastore, cache, or durable-state boundary;
-- `plugin-extension`: discovery, activation, contribution, or host extension;
-- `configuration-runtime`: configuration or runtime selection that changes
-  observable behavior;
-- `build-release`: module-owned build, packaging, deployment, or release entry;
-- `cross-module-chain`: an evidenced flow joins two or more registered modules;
-- `generated-contract`: generated code represents or locates an upstream
-  schema but is not automatically authoritative.
-
-Require a registration, call site, schema locator, or runtime entry. A matching
-dependency alone is not evidence.
-
-## 4. Read matching templates
-
-After the batch table is complete, read every applicable type template and only
-the applicable facet template:
-
-| Type or facet | Template path |
-| --- | --- |
-| `web-application` | `resources/semantic/code-index/templates/web-application.md` |
-| `api-service` | `resources/semantic/code-index/templates/api-service.md` |
-| `service` | `resources/semantic/code-index/templates/domain-service.md` |
-| `background-runtime` | `resources/semantic/code-index/templates/background-runtime.md` |
-| `sdk-library` | `resources/semantic/code-index/templates/sdk-library.md` |
-| `cli-tool` | `resources/semantic/code-index/templates/cli-tool.md` |
-| `adapter` | `resources/semantic/code-index/templates/adapter.md` |
-| `monorepo-container` | `resources/semantic/code-index/templates/monorepo-container.md` |
-| `derived-source` | `resources/semantic/code-index/templates/derived-source.md` |
-| `contract-source` | `resources/semantic/code-index/templates/contract-source.md` |
-| `protocol-provider`, `protocol-consumer`, `generated-contract` | `resources/semantic/code-index/templates/protocol-boundary.md` |
-| `event-producer`, `event-consumer` | `resources/semantic/code-index/templates/event-flow.md` |
-| `persistence` | `resources/semantic/code-index/templates/persistence-boundary.md` |
-| `plugin-extension` | `resources/semantic/code-index/templates/plugin-extension.md` |
-| `cross-module-chain` | `resources/semantic/code-index/templates/cross-module-chain.md` |
-
-`page-routing` and `public-api` refine their matching application or library
-template. `configuration-runtime` and `build-release` add chapter expectations
-to the selected type template. They do not require duplicate pages.
-
-Templates are question sets and chapter blueprints. Omit unsupported sections,
-merge overlapping output, and retain concrete identifiers and source locators
-for every kept claim.
-
-## 5. Match the plan to the extractor
-
-Extractor shape is part of the plan, not an implementation detail:
-
-- `extractTs()` projects each selected symbol to its own candidate page. It is
-  suitable for a deliberately granular public reference, but it does not
-  produce an aggregated module map, registry, protocol index, or chain page.
-- `extractTs()` assigns ownership by source. A source can belong to only one
-  index unit in a phase. Splitting one source into several units or adding an
-  overlapping cross-source unit causes `ownership-ambiguous`.
-- Use `extractCustom()` for aggregate pages or multiple units over one source.
-  Every candidate must declare its owning `module`, and its evidence must cover
-  the Route-reported structural probes. The custom-candidate contract has no
-  page-level Markdown fallback: every candidate must provide at least one
-  evidence-scoped `section`, and each section declares a coverage kind and the
-  exact source evidence supporting that part of the page. Resolve source roots
-  from the extractor context's `sources[].absolutePath`; never embed a
-  machine-specific checkout path.
-- Register independently visible monorepo children as separate sources before
-  giving them separate `extractTs()` units. An `include` pattern filters files;
-  it does not create a source boundary.
-
-Do not wait for an expensive preview to discover that the chosen extractor
-cannot produce the planned page shape.
-
-## 6. Produce one deduplicated plan
-
-Create one `CodeIndexUnitPlan` per user-visible module or independently useful
-custom cross-module flow. A minimal plan has this shape:
-
-```ts
-{
-  module: "customer-portal",
-  moduleType: "web-application",
-  moduleTypes: ["web-application"],
-  facets: ["page-routing", "protocol-consumer"],
-  moduleTypeEvidence: ["package.json", "src/routes.ts"],
-  documents: ["README.md", "docs/architecture.md"],
-  outputOwner: "customer-portal",
-  outputProfile: "application-map",
-  inputSources: ["repo:customer-portal"],
-  entries: ["src/bootstrap.ts", "src/routes.ts"],
-  protocols: ["api/openapi.yaml"],
-  excludes: ["dist/**", "**/*.test.ts"],
-  lifecycle: "source",
-  pageKinds: ["application-map", "route-registry", "protocol-boundary"],
-  capability: "complete"
-}
-```
-
-`outputProfile` is a closed value and selects structural coverage expectations:
-
-| Profile | Intended output |
-| --- | --- |
-| `module-map` | stable module responsibility and entry map |
-| `application-map` | application entry, route, state, and boundary map |
-| `protocol-index` | provider/consumer operations anchored to contracts |
-| `service-boundary` | service operations, orchestration, and dependencies |
-| `runtime-map` | triggers, processing, state, effects, and recovery |
-| `public-api-reference` | deliberately supported consumer API |
-| `command-map` | commands, options, effects, outputs, and recovery |
-| `adapter-contract` | inbound-to-outbound translation contract |
-| `module-registry` | workspace child modules, ownership, and topology |
-| `cross-module-flow` | evidenced handoffs across registered modules |
-| `provenance-only` | source identity, derivation, consumers, and authority |
-
-The preview also requires these evidence-scoped section kinds:
-
-| Profile | Required section coverage |
-| --- | --- |
-| `module-map` | `responsibility`, `entrypoint` |
-| `application-map` | `entrypoint`, `operation`, `handoff` |
-| `protocol-index` | `contract`, `operation`, `handoff` |
-| `service-boundary` | `operation`, `handoff` |
-| `runtime-map` | `entrypoint`, `operation`, `failure-recovery` |
-| `public-api-reference` | `contract` |
-| `adapter-contract` | `contract`, `handoff` |
-| `command-map` | `entrypoint`, `operation`, `failure-recovery` |
-| `module-registry` | `responsibility`, `source-authority` |
-| `cross-module-flow` | `operation`, `handoff`, plus at least one structured edge |
-| `provenance-only` | `source-authority` |
-
-The `build-release`, `persistence`, `configuration-runtime`, and
-`generated-contract` facets additionally require `delivery`, `state-boundary`,
-`state-boundary`, and `source-authority` respectively. A heading without an
-evidence-scoped section does not satisfy coverage.
-
-The profile affects structural probes and advisory risks. `pageKinds` remains
-free-form so projects can name useful page families, but use stable kebab-case
-tokens consistently within a project. Type templates provide recommended
-tokens.
-
-For a multi-module round, finish all classifications first, read the union of
-matching templates once, and revise affected plans together. Do not create a
-copy of the same operation or plugin record for each selected template.
-
-## 7. Capability gaps and preview
-
-Use `capability: "material-required"` when an unsupported parser, missing
-project adapter, absent evidence, or unresolved source boundary prevents the
-promised output. This typed capability is valid in ordinary and fully managed
-flows and stops both at the same Route Gate.
-
-Missing authority does not always block all output. For generated or mirrored
-source whose upstream schema cannot be located, a `provenance-only` unit may
-still record source identity, known derivation facts, and evidenced consumers.
-Keep field semantics and compatibility claims material-required. Stop the
-whole unit only when those semantics are the confirmed knowledge goal.
-
-Run the Route-selected batch preview after every plan is evidence-backed. Its
-projected Markdown count is authoritative per index unit:
-
-- up to 100 pages: continue;
-- 101–300 pages: report an advisory and continue;
-- more than 300 pages: block and revise, including in fully managed mode.
-
-A large batch also reports a batch-total advisory even when each unit remains
-within its limit. Advisory risks describe quality or cost; they do not become a
-new human Gate. `scale-limit-exceeded`, `ownership-ambiguous`, and
-`material-required` capability gaps remain blocking.
-
-Legal recovery includes narrowing `include`, excluding generated or mirrored
-areas, using `exportedOnly`, changing a symbol catalog into an aggregated
-`extractCustom()` output, or registering real child sources. Splitting one
-`extractTs()` source into overlapping units is not a valid workaround. Group all
-affected modules into one plan revision instead of creating one Gate per
-module.

package/providers/context/resources/semantic/code-index/templates/adapter.md

@@ -1,118 +0,0 @@
----
-id: semantic.code-index.template.adapter
-kind: procedure
-media-type: text/markdown
----
-
-# Adapter, bridge, and integration template
-
-Use for `adapter`: 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.
-
-Recommended `outputProfile`: `adapter-contract`. For an inbound gateway whose
-reader goal is the provided operation surface, use `protocol-index` instead.
-
-## 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`; 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-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/providers/context/resources/semantic/code-index/templates/api-service.md

@@ -1,116 +0,0 @@
----
-id: semantic.code-index.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 select `adapter`.
-
-Recommended `outputProfile`: `protocol-index`. If the reader goal is primarily
-the transformation between inbound and outbound boundaries, use
-`adapter-contract` instead 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.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.
-
-Mark unavailable protocol semantics as `material-required` before preview.

package/providers/context/resources/semantic/code-index/templates/background-runtime.md

@@ -1,109 +0,0 @@
----
-id: semantic.code-index.template.background-runtime
-kind: procedure
-media-type: text/markdown
----
-
-# Background runtime template
-
-Use for `background-runtime`: queue or stream consumers, scheduled jobs,
-pipelines, functions, controllers, watchers, and long-running agents activated
-by a trigger instead of an interactive request.
-
-Recommended `outputProfile`: `runtime-map`.
-
-## Evidence pass
-
-Locate:
-
-- process/runtime bootstrap and worker/job registration;
-- trigger identity: topic, queue, schedule, hook, file, controller event, or
-  platform invocation;
-- payload/schema locator and producer when available;
-- handler dispatch, concurrency, partitioning, ordering, and state changes;
-- downstream services, persistence, emitted events, and side effects;
-- retry, timeout, checkpoint, idempotency, dead-letter, and recovery behavior;
-- configuration, scaling, health, observability, deployment, and ownership;
-- replay/test fixtures and generated payload types that are not authoritative.
-
-Distinguish code defaults from runtime configuration. Do not describe delivery
-guarantees unless registration, framework configuration, or maintained
-documentation proves them.
-
-## Questions the knowledge must answer
-
-1. What activates the runtime and where is that trigger registered?
-2. What input contract is consumed, and who produces it?
-3. How does work move from dispatch through orchestration and side effects?
-4. What are the concurrency, ordering, retry, and idempotency boundaries?
-5. How does the runtime checkpoint, recover, or surface failed work?
-6. How is it configured, operated, observed, scaled, and deployed?
-
-## Suggested knowledge units
-
-- **Runtime map**: bootstrap, trigger families, handler registry, dependencies,
-  state boundaries, and operating model.
-- **Trigger/workflow registry**: stable trigger identity, input contract,
-  handler, downstream effects, retry/idempotency, and source locator.
-- **Processing flow**: focused end-to-end path for a high-value workflow family.
-- **Recovery and operations guide**: checkpointing, failed work, observability,
-  configuration, local execution, deployment, and safe replay where evidenced.
-- **Producer-consumer chain**: only when both registered modules and the event
-  identity are source-backed.
-
-## Chapter blueprints
-
-```markdown
-# <Background runtime> map
-## Responsibility and activation model
-## Bootstrap and trigger registration
-## Workflow or handler families
-## State and downstream side effects
-## Concurrency, ordering, retry, and idempotency
-## Failure recovery and observability
-## Configuration, scaling, and deployment
-## Contract sources and exclusions
-```
-
-For a trigger family:
-
-```markdown
-## <Trigger or workflow>
-- Trigger identity and registration:
-- Input contract and producer:
-- Dispatch and handler:
-- State changes and downstream effects:
-- Retry/idempotency/checkpoint behavior:
-- Failure destination and operator action:
-- Source evidence:
-```
-
-## Granularity and relationships
-
-Prefer one record per stable trigger or coherent workflow family. Do not create
-one page per handler helper, event field, retry branch, or generated payload
-type. Split a page when triggers have different contracts, ownership, delivery,
-or recovery semantics.
-
-Every retained page must name concrete trigger, handler, state, side-effect,
-and recovery identities with source locators. A runtime page that only lists
-directories or says a worker “processes events” is too thin.
-
-Connect producers and consumers only through a concrete topic/trigger/schema
-identity. A shared type name or import is insufficient.
-
-## Template composition examples
-
-- A consumer that invokes a domain boundary reads `domain-service.md`.
-- A scheduler that calls external APIs selects `protocol-consumer` and reads
-  `protocol-boundary.md`.
-- A controller exposing administrative commands may combine this template with
-  `cli-tool.md` or `api-service.md`, but should still produce one runtime map.
-
-## Revise or stop when
-
-- no trigger registry or executable worker entry can be found;
-- delivery, ordering, retry, or idempotency would be guessed;
-- the producer or authoritative payload contract is required but unavailable;
-- the plan expands generated event structures or helpers one symbol per page;
-- runtime configuration cannot be distinguished from test setup.