@haystackeditor/cli 0.25.1 → 0.27.0

package/dist/assets/skills/map-cloud-verifier-universe/SKILL.md

@@ -1,2051 +0,0 @@
----
-name: map-cloud-verifier-universe
-description: Discover, document, and update the production-derived hermetic universe that Haystack Cloud Verifier needs for an application. Use when onboarding or repairing a repository for on-demand Cloud Verifier, mapping runtime services and stateful or external dependencies, or reviewing whether an existing universe map is complete. Produce a stable-ID universe plan and evidence map, and require an independent, bounded, read-only reviewer subagent spawned by the customer's coding CLI before declaring the map complete.
----
-
-# Map a Cloud Verifier Universe
-
-Map how Haystack can reproduce the application as a production-derived,
-disposable universe. Cloud Verifier generates change-specific test cases and
-runs them across many isolated universes. Do not discover or select existing
-tests.
-
-Read [references/output-contract.md](references/output-contract.md) completely
-before producing artifacts.
-
-## Rev39 non-negotiable recall floor
-
-This section has precedence if later guidance appears narrower. Source identity
-coverage and downstream semantic closure are separate decisions.
-
-1. Before manual discovery, run `haystack skills census-universe --json` twice
-   against the retained repository. The two `record_digest` values must match.
-   The census deliberately excludes `.haystack/`; generated maps are verifier
-   outputs, not retained application source. If the isolated source view omits
-   Git metadata and reports `source_commit: null`, copy the already pinned
-   `map_revision.source_commit` into the receipt while preserving every census
-   digest, count, and ID byte-for-byte.
-   Persist the exact receipt under `coverage.deterministic_identity_census` and
-   reconcile every presumptive runtime-role, stateful-resource, and
-   external-dependency record
-   exactly once through a candidate's `source_census_record_ids`. A candidate
-   is mapped or receives an exact evidence-backed exclusion; it is never
-   silently dropped. A presumptive discovery lead may be excluded only as
-   `parent-runtime-unreachable`, with atomic repository evidence bound to the
-   exact census source path and tokens. Generic build/test/internal/duplicate/
-   non-independent relabeling cannot close it. Repeat both runs after any
-   retained-source change.
-2. `termination.phase: inventory-complete` or `final-receipt` is valid only after the operational
-   and selector censuses are `complete`, every operational frontier receipt is
-   `complete`, and two full retained-source sweeps over the same manifest add no
-   runtime, state, external-operation, selector-family, or selector-entry
-   identities. Bind both sweeps to the same `source_manifest_digest` and bind
-   `census_record_digest` to the deterministic receipt's final
-   `second_record_digest`. Broad
-   `uncovered` prose is not a census. Missing production
-   authority may defer activation, comparison, and review; it never permits a
-   partial source identity census to terminate. No candidate may remain
-   `pending` at `inventory-complete`: finish its exact identity as a mapped
-   final or give it an exact evidence-backed exclusion. Carry activation,
-   reachability, backing-state, and other downstream semantic uncertainty on
-   the admitted final instead of using it to defer identity admission.
-3. The verifier-owned census is mandatory at every repository size. For a
-   retained source with at least 100 production files or any selector family
-   with at least 25 keys, supplement it with batched language-aware extraction.
-   Feed both the complete retained-source manifest. Search entrypoints and
-   process launches; listeners and routes; file,
-   object, keychain, defaults, generated, build, install, and packaging writes;
-   network/SDK/subprocess/browser/host operations; and selector-to-
-   implementation dispatch. The extractor may write to stdout or private
-   scratch and must derive stable IDs from exact path, owner, operation, and
-   structured key. Never encode a repository name or a holdout-specific answer.
-4. A user- or operator-launched command that stays alive is an
-   `operator-launched-longrun`. A child with its own spawn/stop/restart handle is
-   an `application-supervised-process`. Map both as runtime roles when exact
-   source proves their lifecycle and entrypoint. A host-managed browser or
-   desktop application remains its own runtime role.
-   A production-reachable script with an exact `__main__` guard is also a
-   separately executable `direct-batch-entrypoint`, even when it exits after a
-   finite batch. Duration is not an exclusion basis. Keep a workflow job and
-   the batch script it invokes as separate roles because their controllers are
-   distinct stable identities.
-5. Enumerate exact inbound and outbound operations one-for-one by method/message
-   plus route,
-   topic, command, or protocol operation. Keep the listener as a separate
-   boundary when it has its own address. Emit each exact inbound operation as a
-   `required-inbound-operation`; do not collapse routes into one HTTP listener.
-   Also retain exact HTTP/RPC/socket operations between mapped runtime roles as
-   `mapped-role-operation`; being inside one proposed universe affects routing,
-   not source operation identity.
-6. Treat the census `proof_status` as authoritative. Project every
-   `proof-complete` identity exactly once in every one of its six typed
-   projections. Repeat its exact `source_census_record_id`,
-   `semantic_identity_id`, optional `execution_identity_id`, and ordered typed
-   `identity_components` tuple on the final. A `discovery-lead` is presumptive
-   operational inventory and must also be reconciled exactly once. It may map
-   only after exact source proof fills its missing identity fields; the final
-   repeats its `source_census_record_id` and preserves every component the lead
-   already established. Its final evidence cites the exact census source path
-   and every material census token visible in that source anchor. A
-   `non-inventory` observation cannot justify a final. Unknown
-   activation or downstream semantics may keep closure partial, but cannot
-   erase or group a proof-complete identity.
-7. Every discovered operational surface creates a stable candidate or an exact
-   evidenced non-inventory decision immediately. Every discovered selector
-   owner creates a discovery root and surface immediately, and every exact
-   selector-to-implementation pair creates an identity-complete registry entry
-   with `trace_status: identity-complete` while discovery remains partial. At
-   `inventory-complete`, an
-   identity-complete registry row may retain explicit `category_projections`
-   and semantic debt after its exact family, entry, and edge identities are
-   closed. At `final-receipt`, every entry must instead have all three
-   `category_links` and an explicit child-registry or leaf decision. Omission,
-   `entries: []`, and false leaf declarations are never substitutes for census
-   identities.
-8. Treat independently keyed process memory and installed runtime mutations as
-   state: queues, caches, registries, sessions, configuration objects,
-   interpreter patches, host callbacks, production distributions, executable
-   entrypoints, and generated wrappers. Exclude ordinary locals, unkeyed
-   scratch buffers, temporary-directory contents, tests, dev-only installs, and
-   editable developer checkouts. A lockfile or raw manifest is source input,
-   not reproduced state by itself. Preserve each production lock entry by its
-   exact install location and artifact identity, including nested locations;
-   exclude `dev: true` entries. Split methods, routes, grant types, formats,
-   signals, messages, and package identities into exact rows; grouped variants
-   do not satisfy recall or precision.
-9. A deterministic census record with `package_artifact_url`,
-   `package_artifact_hash`, `package_artifact_filename`, and
-   `package_artifact_kind` is already an exact proof-complete identity. Map its
-   state record to one installed-distribution-variant final and its pull record
-   to one external artifact-pull final. Never group artifacts by package name,
-   version, platform, wheel/sdist class, or installation command, and never map
-   two artifact census IDs to one final subject. Preserve the URL, full hash,
-   filename, version, artifact kind, and installation stage in structured
-   identity and evidence.
-10. Treat the base Python installation and each production-capability extra as
-    separate installation-profile state. Exclude dev, test, docs, lint, typing,
-    benchmark, CI, and release-only groups. An extra such as `all`, `save`, a
-    database/backend integration, or another runtime capability remains in
-    scope; do not run or describe installs as `--all-extras` when that would
-    pull developer-only groups.
-11. A generic census call signature is a presumptive discovery lead, not
-    permission to invent a generic final or leave it pending at inventory
-    completion. Before mapping it, resolve the exact source owner,
-    method or message, route/address/object, stage, and receiver boundary. Map
-    exact browser-model, SDK, host, file/stream, module-loader, resource-pull,
-    callback-registration, and imported-package calls one-for-one. Exclude a
-    workflow or developer-tool call unless exact source proves it belongs to
-    the selected build or runtime path.
-12. An `exact-operation-matrix-member` is proof-complete. Map every record to
-    exactly one final external subject, preserve `source_census_record_id`,
-    `operation_identity_key`, and ordered `matrix_axis_item_identity_keys`, and
-    never replace its members with plural destination/object variant arrays.
-    Finite destination, nameserver, object, method, stage, or port axes multiply
-    identities; retry and attempt counts remain metadata on one identity.
-    A `python-executable-entrypoint-role`,
-    `workflow-controlled-runtime-unit`, embedded configuration, or embedded
-    template is instead a deterministic candidate: map it only when exact
-    production provenance establishes the category, and otherwise record the
-    exact evidenced exclusion. This keeps admin/build/test scripts and ordinary
-    code constants from becoming fabricated finals.
-13. Treat each production requirements manifest as one installation profile and
-    each requirement line as a profile-scoped variant. The same normalized
-    package in two profiles is two state identities. Emit an external install
-    operation only when executable source actually runs that command. Optional
-    imports, exception messages, logs, comments, and documentation never prove
-    installed state or an install boundary. If no command exists, use the exact
-    `manifest-derived:<manifest-path>` reproduction token and
-    `reproduction_operation_kind: manifest-derived`; do not substitute a raw
-    version or requirement fragment.
-
-## Keep the boundary clear
-
-- Map repository-proven logical runtime roles, config, stores, streams, queues,
-  caches, object storage, flags, identity, RPC, scheduled work, and third-party
-  APIs that affect the selected application. A logical runtime role is never a
-  production IAM role or credential.
-- Mark every resource and external dependency `activation: active` or
-  `activation: optional`. For a resource, ask whether the application starts
-  without the store, not whether its data looks important: an analytics sink or
-  secondary audit store the app boots without is `optional`. Classify its state
-  honestly regardless; a store can be both
-  `canonical-durable` and `optional`, and downgrading it to
-  `derived-rebuildable` to justify the marking asserts a rebuild path nothing
-  can evidence.
-- Prove `activation: active` at the call site before claiming it. A default
-  endpoint constant is not proof: follow the call and check whether it returns
-  early without a key, sits behind a flag that defaults off, or runs only under
-  an admin-guarded path. Persist an `activation_basis` with exact evidence for
-  every resource and external dependency. Default-on code reached on startup,
-  in a background loop, or through a fixed ordinary request path is `active`;
-  a concrete profile, credential, feature, driver, administrator, tenant-state,
-  artifact, or user-supplied-destination gate makes it `optional`. Invoking an
-  already-enabled fixed capability is not a gate, but creating a webhook,
-  remote, subscription, provider record, or URL-backed integration is: the
-  destination does not exist until that state is supplied. Do not transfer the
-  resource boot test to external calls: a store the application can boot
-  without is optional, while a fixed external destination reached by a default
-  request path can be active even when the request happens after boot. A
-  default-selected local engine, mount, or cache is active even when ordinary
-  use populates it only after boot. When one grouped entry includes both a
-  default-reachable variant and gated variants, split it so each activation
-  decision remains truthful. A wrong `active` makes a materializer stand up
-  something the application never reaches; an unsupported `optional` silently
-  drops default behavior.
-  Before calling anything optional, inspect the selected artifact's baked and
-  default configuration. A default selected there is active even when an
-  operator can override it later. Name the proximate selecting gate:
-  `operator-configuration` for an operator URI or implementation enum,
-  `driver-selection` for a driver choice, and `user-supplied-destination` only
-  when an end user or tenant actually supplies the destination. Do not use
-  `credential` merely because an already selected path later authenticates.
-- Resolve reachability separately for every consuming runtime role. Each
-  resource and external dependency keeps `runtime_role_ids` as its compact
-  index and emits one matching `consumer_edges` row per role, with that edge's
-  activation and proximate basis. Cite atomic `role-reachability` evidence whose
-  exact subjects are `[inventory-subject-id, runtime-role-id]` and whose
-  repository sources use `inspection_scope: role-call-path`. Its
-  `role_call_path` names the role and two distinct source indexes: a role module
-  or entrypoint and the concrete consumer use site. For
-  `registration-dispatch` or `configuration-dispatch`, it also names a third,
-  distinct `dispatch_source_index` at the actual registration or selection gate;
-  omit that index only for `direct`. All sources use distinct typed, locatable
-  string anchors; repeating or padding one locator at two indexes or relabelling
-  its locator kind is invalid. Build a role-by-subject matrix from each role's
-  entrypoint. Never copy a service-level `depends_on` set onto every role.
-  Packaging, registration, a plugin factory, or shared
-  configuration vocabulary does not prove that a role can reach the
-  capability. If a role-specific gate rejects a capability, omit
-  that positive consumer edge instead of copying another role's edge. Aggregate
-  activation is active when any consumer edge is active and optional only when
-  all consumer edges are optional.
-- Resolve `activation` against the deployment profile you selected, not against
-  source defaults alone. Three things decide it, in this order: what that
-  profile's shipped configuration actually sets, whether that profile's image
-  or package even contains the runtime needed to reach it, and only then the
-  code default. A checked-in compose or chart that enables a feature makes it
-  `active` even when the code default is off; a provider that loads only under
-  a profile you did not select is `optional`; and a registry or integration
-  whose interpreter, driver, or client is absent from the selected image is
-  `optional` no matter what the source says.
-- Selection gates never erase supported inventory. If a packaged or
-  repository-loadable registry entry creates a real resource or outbound
-  interaction, map it once and mark it `optional` when a profile, default,
-  configuration key, feature flag, credential, driver, or artifact choice gates
-  it. Do not resolve that candidate as excluded merely because the selected
-  profile leaves it inactive. For a candidate referenced by a structured
-  registry, the only permitted exclusion is `duplicate-inventory`, joined to
-  exact `equivalent_subject_ids`. Its evidence includes a decision-grade atomic
-  `duplicate-inventory-equivalence` claim whose exact subjects are the candidate
-  ID plus those equivalent inventory IDs and whose source inspects the
-  implementation body. Everything else is either mapped optional inventory or
-  was never category-applicable and belongs in the category link.
-- Preserve every independently keyed logical state owner even when several
-  owners share one physical copy, reset, or restore action. Logical inventory
-  identity and materialization identity are separate: distinct databases,
-  schemas, queues, streams, buckets, namespaces, persisted identities, and
-  generated outputs remain distinct resource rows, while shared
-  `physical_binding_id` and reproduction/consistency groups tell the
-  materializer to perform one physical action. Do not separately map an
-  unaddressed table inside an already mapped logical database, an in-process
-  boot cache, a scratch child, or immutable bytes already covered by an
-  artifact. The stable structured state key—not similar text and not physical
-  co-location—decides logical identity.
-  Every resource also carries `state_owner` with an atomic
-  `state-owner-boundary` claim for that exact resource. The claim names one
-  typed ownership operation: an application open/read/write boundary, a
-  repository-declared mutable namespace, operator-provisioned writable
-  capacity, immutable digest/version identity, or an exact repository-proven
-  named remote read/write operation. A client, endpoint, plugin registration,
-  provider name, API response, or discovery target group is not state-owner
-  proof. For `derived-rebuildable`, give one atomic
-  `rebuild-source-reachability` claim per exact source-resource edge.
-  A live authoritative catalog may instead prove an
-  `authoritative-catalog-state-owner`; that evidence uses
-  `authority: authoritative` and keeps the catalog reference opaque.
-- Prefer a production fork or snapshot. Use capture/replay or an isolated
-  equivalent only when the dependency cannot be copied and the capability is
-  evidenced.
-- Treat the universe as writable and disposable. Haystack must later prove
-  that it cannot reach or mutate production.
-- Record config and secret names, never values. Do not change infrastructure
-  or invent production identifiers.
-- Read the repository and nothing else. Do not call provider APIs, cloud CLIs,
-  production endpoints, or any control plane, and do not ask for production
-  credentials, IAM roles, connection strings, or deletion handles. Haystack
-  operates the replicas under access the customer grants it directly; that
-  access is never routed through this skill.
-- Never persist raw provider IDs, endpoints, or secret values in checked-in
-  artifacts. Record stable IDs, config and secret *names*, and opaque catalog
-  handles.
-- Ask the user only to select the stable application ID, environment ID, and
-  replica destination policy or approval. Do not ask them to inventory their
-  system or design its reproduction: describing the system is your job, and
-  reproducing it is Haystack's.
-
-## Current implementation status
-
-- Haystack builds and operates the replicas. The customer's coding agent
-  produces the map and nothing else: it does not implement drivers, package an
-  adapter, or run a replication process.
-- Treat every map as a proposal. Nothing here has been materialized or probed,
-  so keep readiness at `proposal` or `blocked` unless direct current probes
-  prove more, and never claim hermeticity, isolation, or materialization
-  readiness from repository evidence alone.
-- Provider discovery and end-to-end materialization are Haystack-side work.
-  Do not describe them as customer deliverables or block the map on them.
-
-## Produce exactly four artifacts
-
-Create or update:
-
-1. `.haystack/cloud-verifier/universe.yml` — the logical production universe.
-2. `.haystack/cloud-verifier/evidence.yml` — evidence for every claim.
-3. `.haystack/cloud-verifier/review.yml` — the independent review receipt.
-4. `.haystack/cloud-verifier/behaviors.yml` — each meaningful customer action,
-   its exact handler identity, and the customer-relevant boundaries that a
-   replay can observe.
-
-The behavior map is finer-grained than the universe map. A single HTTP server
-interface may own many actions such as `POST /orders` and `GET /orders/:id`.
-Derive actions from route registration, event handlers, jobs, CLI dispatch,
-and UI action registration. Join to universe interfaces and evidence only by
-exact stable ID. Derive action, symbol, and boundary IDs with the installed
-validator; never make them from display prose or source line numbers.
-
-Treat them as a proposal until Haystack materializes and probes it. Review can
-check inventory coverage; it cannot prove hermeticity.
-
-Keep each artifact below 33554432 UTF-8 bytes. Do not use cyclic or expansion-heavy
-YAML aliases. Reuse `evidence_sources` and `evidence_profiles` by exact stable ID
-instead of repeating identical source and quality mappings across atomic claims.
-Follow validator contract revision `39` from the output contract. Behavior
-validation accepts the same 33554432-byte artifact envelope and runs from the
-current source directory when a sealed archive intentionally omits Git metadata.
-
-## Run the rev39 identity-admission gate first
-
-Run the verifier-owned census before the four semantic passes and again after
-them:
-
-```bash
-haystack skills census-universe --json
-haystack skills census-universe --json
-```
-
-The command is repository-generic and read-only. Copy its schema and contract
-revision, pinned `source_commit`, separate source-manifest digest and file
-counts, total and presumptive counts,
-and identical first/second record digests into
-`coverage.deterministic_identity_census`. Copy the sorted IDs for every
-`presumptive_inventory: true` record projected to `runtime_roles`,
-`stateful_resources`, `external_dependencies`, `registry_families`,
-`registry_entries`, or `registry_edges` into the corresponding
-`projection_record_ids` list. Never put the manifest digest in the commit
-field.
-For each category, attach every listed ID to exactly one closure candidate using
-`source_census_record_ids`. Then trace that exact record to a final subject or
-an evidenced exclusion. Do not create a blanket candidate or exclusion for a
-whole file, method family, package group, registry, signal family, message
-family, or endpoint family. The validator recomputes the census from the current
-repository and rejects changed digests, missing IDs, extra IDs, and duplicate
-reconciliation.
-
-The rev39 census returns typed `registry_families`, `registry_entries`,
-and `registry_edges`. Preserve each entry's `selector_family_record_id` and each
-edge's exact parent-entry and child-family record IDs while building structured
-registries. Do not merge families by similar labels, move an entry to another
-owner, or use leaf evidence to override a verifier-emitted child edge. Qualified
-documentation, sample, fixture, and benchmark module roots are outside the
-production census even when they contain manifests or lockfiles.
-
-For large registries, use `source_census_record_id` plus
-`census_rehydration: exact` on a family or entry instead of duplicating its
-typed identity and source evidence. This also upgrades a discovery registry
-lead after source-wide proof, but it must preserve the exact census family
-owner and each entry's selector and implementation keys, with atomic evidence
-for the exact census source path and material tokens. The validator
-recomputes and rehydrates that exact record. Keep semantic category projections
-and child-registry decisions explicit. Every selector surface joins its family
-with `source_census_record_id`; use only the contract's fixed
-`non_registry_reason` enum for a non-registry surface.
-
-Finish these four deterministic source-wide passes before tracing activation or
-reproduction semantics. Record each pass under
-`coverage.operational_surface_census.frontier_receipts`; a complete receipt
-lists the exact surface IDs it produced or gives evidence-backed absence.
-
-1. **Deployment runtime units.** Enumerate every independently started,
-   stopped, or restarted steady-state service, process, scheduled workload,
-   supervisor child, database, cache, broker, proxy, and host-managed unit in
-   production-capable deployment and packaging sources. Merge setup, init,
-   migration, configuration, and start commands that prepare the same deployed
-   unit; they are not extra runtime roles unless they launch independently and
-   remain alive. Give every final role an exact
-   `deployment_unit_identity_key`, `deployment_control_kind`, and
-   `deployment_control_token`. Admit a child process, thread, or sidecar only
-   when exact deployment source proves its own lifecycle controller can restart
-   it independently; a process name or internal supervisor restart loop is not
-   that controller. A separately launched database or cache is
-   both a runtime role (its launch unit) and a resource (its state); do not let
-   one category erase the other.
-   Treat a shipped browser application as a `host-managed-unit` when exact
-   source proves its document/build entrypoint and production serving or
-   packaging path. The browser host owns that lifecycle boundary; a missing
-   compiled bundle in the retained source does not erase the source-proven
-   browser role.
-2. **State materialization identities.** Enumerate every independently
-   reproduced logical database, database schema, cache namespace, queue or
-   stream, credential/trust/TLS file, object bucket or prefix, persistent
-   volume or directory, portable snapshot, installed or packaged layout,
-   generated host state, immutable packaged asset, and other repository-proven
-   independent object. Include application-created data roots, generated source
-   or declaration files, installed executables, and embedded shipped assets.
-   When a portable root and one or more children each have distinct exact
-   content-reproduction operations, retain both only when the root itself has
-   an independently preserved content identity. A `VOLUME`, mount, or directory
-   declaration proves writable parent capacity, not canonical durable content;
-   do not promote that parent over exact child identities. Physical containment
-   does not erase an independent reproduction identity. Tables,
-   projections, fields, indexes, and records inside
-   an already copied database are not separate final units unless the repository
-   proves an independent address and preserve/copy/rebuild/reset/restore action.
-   Every final resource declares an allowed `state_unit_kind`, exact
-   `address_token`, exact `reproduction_token`, and typed
-   `reproduction_operation_kind`. The reproduction token must be an actual
-   copy, restore, rebuild, reset, preserve, provision, mount, install, write,
-   initialize, build, embed, generate, migrate, or pin operation and must differ
-   from the address and materialization-root
-   tokens. For identity admission, reproduction is the exact source operation
-   that creates or restores this exact addressed unit: application writes such
-   as `setItem`, `WriteFile`, or a named object `Put`; deterministic generation,
-   build, embed, copy, install, initialization, or migration all qualify when
-   tied to the exact address. A separate cross-environment backup/restore plan
-   is materialization readiness, not a prerequisite for recording the logical
-   state identity. A URL, environment variable, namespace name, declaration,
-   generic parent mount, or generic CRUD interface without the exact addressed
-   child does not prove independent reproduction. Enumerate nested tables,
-   records, indexes, projections, cache
-   keys, and provider objects in the census, then keep them out of final
-   resources unless source proves a separate reproduction operation for that
-   exact child.
-3. **Outbound and host operation contracts.** Starting from each runtime role,
-   shipped browser/client surface, packaged one-shot command, and artifact
-   build/install/generation path, enumerate
-   exact reachable SDK, HTTP/RPC, storage, identity, telemetry, proxy,
-   subprocess, and host-service call sites. Start at concrete production
-   consumers and trace inward to the leaf boundary; never start from generic
-   HTTP helpers, shared SDK wrappers, imports, constructors, factories, local
-   handles, or client method definitions and emit those definitions as rows.
-   Admit one final row per exact
-   outside-universe boundary operation, with a stable `operation_identity_key`,
-   exact `operation_token`, and allowed `boundary_contract_kind`. Merge provider
-   variants, OS branches, wrappers, or consumers sharing the same semantic call
-   identity; exclude calls between mapped runtime roles. Split distinct calls
-   within one client or user flow—for example authorize, exchange, fetch, list,
-   read, write, copy, and delete—when they cross the boundary independently.
-   Record `boundary_trace.kind: direct` when the application call is the leaf
-   effect, or `wrapper-resolved` with the concrete application
-   `callsite_identity_key`, `callsite_token`, every `wrapper_token`, and the
-   final `boundary_token`. Batch-enumerate concrete call sites first, resolve
-   wrappers second, then deduplicate only by exact structured operation
-   identity. Sweep every effectful leaf inside each reached wrapper: filesystem
-   methods, transaction stages, object-store methods, mail-protocol commands,
-   browser/host APIs, build downloads, package fetches, generators, and install
-   commands are separate operations when the leaf effect differs. Build-time
-   and install-time boundaries required to reproduce shipped artifacts remain
-   external dependencies even though they are not steady-state runtime egress.
-   The operation token is the effectful call or listener, never a client
-   constructor, import, factory, configuration setter, local handle, helper
-   definition, quoted command argument, or flow label. For subprocesses, cite
-   the spawn/exec invocation and full command identity rather than one array
-   element. A reachable
-   provider interface method is an operational dependency, not merely a
-   selector-registry entry.
-4. **Required inbound and pull contracts.** Enumerate independently reproduced
-   listeners and service interfaces whose production behavior requires an
-   ingress, browser/client, controller, puller, registry, or other outside
-   actor. Keep the top-level listener or pull boundary, group routes and protocol
-   variants behind it, and do not omit the listener merely because application
-   code did not open the first connection.
-
-Final arrays are exact identity conclusions, not claims that every downstream
-semantic is closed. Admit a runtime role as soon as its independent controller,
-controller token, and entrypoint token are proved. Admit a resource as soon as
-its exact owner, address, typed reproduction operation, and distinct
-reproduction token are proved. Admit an external dependency as soon as its
-exact callsite, boundary leaf, operation identity, and destination/scope are
-proved. Missing hosted authority, selected activation, role reachability,
-backing-state classification, cross-environment materialization, or closure
-review must stay explicit and keep the category partial, but none may strand a
-proof-complete identity as a pending candidate. Use the contract's honest
-unknown/optional fields and empty consumer edges where necessary.
-
-`disposition: pending` is reserved only for a missing exact identity component:
-runtime-unit/controller kind/controller token/entrypoint; state-unit/owner/
-address/reproduction kind/reproduction token; or external operation key/
-callsite/callsite token/boundary token/destination/wrapper trace. Never put
-activation, runtime consumer, hosted authority, materialization strategy,
-backing state, reproduction readiness, or downstream closure in `unresolved`.
-Missing hosted-production authority may defer comparison, but it never relaxes
-or blocks source-only identity admission.
-
-When consumer or activation tracing is still open, represent the exact final
-resource or external identity with `activation: optional`,
-`activation_basis.kind: unknown-production-state`, `runtime_role_ids: []`, and
-`consumer_edges: []`; keep the matching category partial. For unresolved remote
-ownership, use the contract's `backing_state` unresolved form. These are honest
-downstream unknowns, not claims that the identity is inactive or stateless.
-
-For every full runtime role, resource, external dependency, registry family,
-and registry entry, reopen the cited exact snippet or line span before closure.
-Repository evidence for a material identity uses `supporting_tokens`; each
-token must occur inside that exact locator. A comment, shebang, import,
-declaration header, adjacent line, or closing brace cannot support a launch,
-owner/root, operation, or dispatch identity unless that exact token-bearing
-text is the claim. Keep material line spans at 80 lines or fewer.
-
-A registry is a concrete finite selection gate: a map lookup, switch dispatch,
-factory registration, manifest entrypoint, command dispatch, generated
-dispatch, or configuration dispatch. An interface or abstract method set is
-not a registry. Every registry records `selection_gate` with its exact owner,
-selector, and dispatch tokens and cites atomic `registry-selection-gate`
-evidence. The gate must declare `dispatch_semantics: selective-dispatch`, its
-exact production `runtime_consumer_token`, and whether its source is
-`application-owned` or `generated`. Generated parser, codec, protocol, schema,
-or framework tables are not registries unless a distinct application-owned
-production gate selects among their entries; record that gate as
-`application_gate_token`. Ordered migrations, exhaustive lifecycle pipelines,
-and hook lists that execute every member are not registries because no selector
-chooses one implementation. Every entry cites atomic `registry-entry-identity` evidence for its
-exact selector and implementation tokens. The selector literal, enum value,
-manifest key, or command `Use` token must be distinct from the selected
-constructor, handler, class, or implementation token. Trace and emit every
-parent-entry-to-child-registry edge; an enum, interface method set, route list,
-or constant collection with no concrete dispatch is not a registry.
-
-## Preserve census breadth before proving semantics
-
-Inventory recall comes before semantic closure. First retain every exact
-repository-proven launch surface, state candidate, egress candidate, and
-structured-registry entry by stable ID. Then trace activation, ownership,
-consumer roles, backing state, nested registries, and reproduction semantics.
-Never make the candidate disappear because the second pass is unfinished.
-
-For a partial resource or dependency category, an evidenced inventory subject
-may honestly use `runtime_role_ids: []`, `consumer_edges: []`,
-`activation: optional`, and `activation_basis.kind: unknown-production-state`
-until its role call path is resolved. An external dependency may likewise use
-`backing_state.basis: remote-ownership-unproven`. Keep the category partial and
-name those IDs in `uncovered`. Unresolved role or ownership semantics are not
-evidence that the capability does not exist.
-
-When an exact identity component is not yet defensible, retain the observation
-in `coverage.operational_surface_census` and retain its stable closure candidate
-with `disposition: pending`. Its `unresolved` values must use only the exact
-identity-gap names allowed by rev39. Cite atomic census evidence, keep the
-category partial, name the candidate in `uncovered` and an aggregate blocker,
-and continue the source trace. Once the category-specific identity tuple is
-proved, project it to final inventory immediately; carry unresolved activation,
-reachability, backing, and materialization semantics on that final row and in
-closure blockers.
-
-When a registry is too large to trace entry-by-entry in one pass, retain every
-enumerated exact key in `coverage.selector_surface_census` with exact census
-evidence. Keep the registry partial and name the implementation and nested-
-registry traces in `semantic_trace_blocker`; do not create a final registry
-`entries[]` row until the exact selector-to-implementation dispatch and child-
-registry decision are proved. Apply structured per-entry category discriminators to create closure
-candidates, but keep unresolved projections in coverage rather than final
-inventory. Free-text names and summaries are not discriminators. Do not sample
-a registry, claim it empty, or omit its tail to save output space.
-
-A registry ledger is not a substitute for top-level inventory. When the
-registry schema establishes that every member belongs to a category—such as a
-worker registry or storage-backend registry—create a closure candidate for
-every real entry, then project only semantically closed candidates into full
-top-level rows.
-For a mixed integration, plugin, or manifest index, apply a structured per-entry
-discriminator such as an I/O class, transport declaration, client declaration,
-or endpoint declaration. Project every positive entry and record every
-structured negative as `not-applicable`; use `undetermined` only for entries
-whose exact structured metadata has no category discriminator, then prioritize
-their batched implementation trace. Never decide by fuzzy text. Generate
-exact selector-census and candidate claims while reusing the same
-evidence-source/profile IDs.
-
-## Use command outputs as checkpoints
-
-Drive the workflow through the customer's CLI. Keep each command's exact
-machine-readable output in private scratch; prose is not a checkpoint. Use:
-
-1. `haystack skills scaffold-provisional-universe --input <scratch-input.json>`
-   only when production authority is missing **and** the topology-presence
-   census proves the repository contains no production-capable topology;
-2. `haystack skills prepare-universe-review --json` before an authorized review;
-3. the customer CLI's real subagent-spawn and resume records; and
-4. `haystack skills validate-universe --json` before publishing.
-5. `haystack skills validate-behaviors --json` before publishing.
-
-Stop for unavailable, nonzero, stale, or wrong-schema output. Never infer that a
-missing command passed or promote an unsupported capability because it seems likely.
-
-## Workflow
-
-### 1. Check production authority first
-
-Default the target to the hosted production application. Choose one application
-and deployment scope. In a monorepo with confirmed authority, include only roles
-in that scope. If authority is missing and no selection is available, use the
-repository-defined product boundary: inventory every independently shipped,
-production-capable component as a role, capability, or compact alternative
-profile. Exclude unrelated development, test, documentation, and example
-packages. This is not permission to map the whole monorepo. Record one precise
-scope blocker instead of arbitrarily narrowing the product to one plausible
-package.
-
-Before deciding that the compact zero-inventory path applies, run one batched
-repository topology-presence census inside the authority-gate budget. Inspect
-tracked production entrypoints, package/workspace manifests, container and
-deployment descriptors, and structured plugin/provider/integration indexes.
-The absence of hosted deployment authority is never evidence that repository
-topology is absent. If this census finds any production-capable runtime,
-resource, client, plugin, provider, or integration surface, the compact path is
-forbidden: continue through inventory discovery even though scope remains
-provisional.
-
-The compact scaffold requires the canonical five `inspectedSurfaceKinds`,
-`productionCapableSurfaceCount: 0`, and exact decision-grade
-`claimKind: topology-presence-census` evidence for the census subject. It
-refuses a missing or nonzero census. Never declare zero after finding a surface;
-do not call the scaffold in that case.
-
-Before broad discovery, spend at most 6 repository-inspection calls and 60
-seconds checking deployment manifests, artifact pipelines, and repository
-documentation for a source that controls or resolves the live hosted
-deployment. This tells you how much the repository can prove; it does not
-confirm the hosted scope. Nothing you can call resolves which deployment is
-really production, so leave `application.scope_status: provisional` and let
-Haystack confirm the scope on its side. Never call provider APIs or accept
-direct production access. Executable source and production-intended or
-self-host config may describe a provisional topology, but cannot confirm the
-hosted scope.
-
-If hosted deployment authority lives elsewhere or remains missing, the hosted
-*scope* stays unconfirmed, but the map still owes Haystack an inventory. Do not
-stop discovery. Deployment commonly lives in a separate private repository, and
-that fact alone says nothing about what the system is made of. Continue through
-the normal budget and record every runtime role, stateful resource, external
-dependency, and edge the repository itself evidences. Then set
-`termination.reason: missing-production-authority` at the `inventory-complete`
-phase.
-
-What is withheld on this path is confirmation, never content. Keep
-`application.scope_status: provisional`, `selected_production_scope: null`, the
-  production reviewer deferred, `review.status: blocked` on the authority blocker, and
-exactly one `production_basis.access_request`. Never promote a repository-proven
-topology to a confirmed hosted scope, and never claim hermeticity,
-materialization readiness, or isolation without authority. Record what the
-repository proves and mark it as exactly that.
-
-Do not launch the production-scope reviewer or run its comparison and revision
-phases: that review requires authority. The repository-only inventory-closure
-audit is separate and does not require production authority. Run it whenever
-the repository closure is otherwise complete. If no independent subagent or
-isolated source snapshot is available, keep the affected closure categories
-`partial` and set `inventory_closure_audit.status: deferred`; never preserve a
-`complete` claim that nobody independently challenged. Include only
-authority/access blockers, plus an honestly linked budget blocker if a limit
-was exceeded. Do not turn a deferred repository-only audit into a production
-authority or reviewer-isolation blocker.
-
-Use the compact receipt only when the repository evidences no topology at all,
-meaning not one runtime role, stateful resource, or external dependency. In that
-single case, terminate at the `authority-gate` phase, and within 60 seconds
-write the strict provisional JSON input from the output contract into private
-scratch, then run:
-
-```bash
-haystack skills scaffold-provisional-universe --input <scratch-input.json>
-```
-
-The command deterministically creates and validates the compact three-artifact
-receipt. Do not hand-author repetitive empty inventory or reviewer sections. An
-empty inventory is a claim that the repository shows nothing, so do not emit one
-to avoid the work of discovery.
-
-The map records repository-proven boundaries and exactly one
-`production_basis.access_request`. That request is a statement of what Haystack
-still needs, not a call you make. Ask the customer to make the application,
-environment, and replica-destination selection locally; Haystack resolves the
-remaining groups through its own access:
-
-1. selected application ID and environment ID;
-2. approved replica destination policy and opaque approval reference;
-3. resource kinds, opaque catalog handles, and dependency edges;
-4. artifact/runtime and non-secret config opaque catalog references;
-5. external integration kinds and secret-reference names;
-6. replica capabilities, strategies, consistency, freshness, latency, and cost
-   bounds, including provider fork/snapshot/copy/capture capabilities; and
-7. the replica-only golden-descriptor and lease-reference contract.
-
-The last group defines replica-only sandbox identity bootstrap; it grants no
-production identity or access.
-
-Never request production roles, credentials, raw provider IDs, endpoints, or
-direct connectivity for the checked-in access request. Exact stable identities
-that Haystack resolves later are transient validation inputs, not artifact
-fields. Never invent a hypothetical hosted
-scope, resource, or activation state. Use the compact profile in the output
-contract; do not instantiate the full reviewer schema.
-
-After continuing beyond the authority gate, record `budget.primary_discovery`
-with a 48-call baseline and a 1800-second total, plus a nested `authority_gate`
-with the 6-call/60-second limit. The scaffold-generated compact authority-gate
-receipt retains its fixed 48-call/900-second profile because discovery stopped
-at that gate.
-Calls 48, 96, and 192 are reporting checkpoints, not terminal ceilings. When a
-recorded allowed `extension_triggers` value identifies unresolved structured
-registries, launch surfaces, state providers, egress clients, retained-source
-scale, omitted production source, or a closure contradiction, extend the
-selected call limit in 48-call waves and target the open frontier. Stop only
-after two consecutive source-wide identity sweeps add no new exact operational
-identity or selector family. Semantic uncertainty may keep downstream closure
-partial, but it cannot shorten the census. A passing receipt must stay within
-the selected limit and elapsed ceiling. A blocked receipt that records an
-overrun links a `kind: budget-exhausted` blocker to the exact `budget_path`.
-
-Never substitute a local, dev, example, hobby, or self-host topology for hosted
-production. Keep it as a compact alternative unless the user explicitly
-selects it. Do not expand inactive or optional profiles into provider-by-provider
-topology variants, but still record every repository-proven logical role,
-resource, and optional capability once. Provisional scope is not permission to
-discard a repository-proven launch surface: attach it to the compact
-repository-proven topology or an alternative profile and record the uncertainty.
-
-On updates, preserve IDs by exact existing ID or structured source identity,
-never fuzzy text. Do not collapse roles, profiles, logical databases, buckets,
-topics, streams, queues, or keyspaces because their names or technologies look
-similar. Merge only when authoritative evidence proves the same structured
-logical identity; a shared physical binding and reproduction action only groups
-materialization.
-
-Record a `map_revision.source_commit` baseline. On rerun, inspect the source
-diff plus reverse dependencies and evidence whose anchors changed. Tombstone or
-remove an object only with evidence that it is no longer active. Have the
-reviewer inspect changed scope blindly before seeing the semantic delta. Fall
-back to a full bounded scan when deployment roots, service catalogs, selected
-scope, or topology sources changed. Treat this as required protocol, not a
-claim that update determinism has already been validated.
-
-### 2. Enforce the inspection boundary before independent repository review
-
-Apply this section whenever an independent repository-only closure audit or the
-full production review will run. Skip it only for a compact or partial receipt
-whose `inventory_closure_audit` is honestly deferred. Omit the
-`inspection_policy` block from `evidence.yml` only on that deferred path; a map
-must not claim a reviewer snapshot that was never prepared.
-
-Apply the exact denied components, conditional component rules, and typed
-basename globs from the output contract to every primary and reviewer search,
-listing, read, and context-building operation.
-
-Match globs against normalized repository-relative POSIX paths. For the
-primary, use path-aware exclusions on every tool call. Before any deep scan,
-detect retained source files containing language/framework inline-test
-declarations. The detector may emit only paths and counts, not matching test
-text. If tests are co-located with production source and cannot be removed by a
-syntax-aware filter, stop rather than expose them. Never use a substring rule
-such as `*test*`; it incorrectly matches names such as `latest`, `contest`, and
-`attestation`.
-
-For the reviewer, create a tracked-files-only filtered snapshot outside the
-repository, excluding every denylisted path and `.git`. Confine the reviewer
-filesystem to that snapshot and disable network access. Enumerate symlinks
-before launch: reject targets outside the retained tree or into excluded paths,
-and materialize safe internal targets as regular files. Audit the snapshot for
-denylist matches and inline tests before launch. A working directory or prompt
-saying “ignore tests” is not enforcement.
-
-Create and audit that source view with:
-
-```bash
-haystack skills prepare-universe-review --json
-```
-
-Record its returned snapshot path and manifest digest in private scratch. The
-command must return `status: ready-for-confinement`; a `blocked` result stops
-review.
-
-A first run commonly blocks on tracked gitlinks, because a submodule's contents
-cannot be inspected and approving its omission has to be deliberate. That is an
-expected step, not a dead end: take the exact paths from the receipt's
-`submodules_omitted`, pass each back as a separate
-`--exclude-inactive-submodule <path>` option, and re-run. The receipt then
-records them under `approved_inactive_submodule_omissions`.
-
-Symlinks whose target is not a retained tracked file are omitted from the
-snapshot rather than blocking it, and the receipt lists them under
-`omitted_symlinks`; the resolver never materializes them, so nothing is exposed.
-
-A retained production file that carries an inline-test declaration, or a text
-file too large to scan, blocks by default: the contract will not silently hand
-the reviewer a file that might contain tests. When that is the only thing left
-blocking, re-run with `--omit-unscannable-files`. Those files are then left out
-of the snapshot entirely and listed under `omitted_unscannable`, which satisfies
-the same guarantee — the reviewer still never sees a test — while letting the
-review proceed. Carry both counts into `evidence.yml` and the coverage ledger,
-because they are scope the reviewer did not see. The command prepares the view; the customer's CLI must still confine
-reviewer filesystem access to that path and disable reviewer network access.
-In the receipt, record this as the structured executable and arguments from the
-output contract, plus the exact normalized paths passed through
-`--exclude-inactive-submodule`; do not record a shell command string.
-
-Record the mechanism, exact activated component rules and typed globs, symlink
-result, inline-test detector, and audit result in `evidence.yml` and
-`review.yml`. If the primary cannot enforce the boundary, stop with
-`test-path-isolation-unavailable`. If the reviewer CLI cannot enforce it, stop
-with `reviewer-test-path-isolation-unavailable`; do not launch an unrestricted
-reviewer. Never copy `.haystack/**` into a reviewer's source view.
-
-Before final validation, lint every `evidence.sources[].path` against the same
-normalized policy. A denied evidence path is a blocker, even if it was read
-before the policy was installed.
-
-### 3. Create a recoverable private draft
-
-Create a task-specific directory outside the repository under the OS temporary
-directory, keyed by a deterministic repository identifier and restricted to
-the current user. Print its path for recovery, but never reveal it to the
-reviewer.
-
-Create every planned scratch subdirectory before the first extractor command.
-Run one no-output preflight against a single retained production file and
-verify that the expected output file or record count exists before launching a
-batch. A command that fails before opening repository source because its script,
-scratch directory, dependency, quoting, or output path is broken is a setup
-failure, not a repository-inspection call: repair it and retry once without
-charging the discovery budget. Record the failed preflight separately. Once a
-command opens source, it consumes the call even if later processing fails.
-
-After each phase, save candidate artifacts, a progress ledger, and compact
-reviewer projections there. Do not write the candidate under `.haystack/`
-while a review is still expected to run. Save the reviewer session ID immediately
-after spawn, and append each reviewer response to a separate scratch file. Never
-depend on one final output file or message. Delete scratch only after final
-artifacts are safely written; preserve and report it if interrupted or blocked.
-
-Once review has terminated — passed, or blocked on `reviewer-subagent-unavailable`,
-`reviewer-session-not-resumable`, `reviewer-quota-exhausted`, or a reviewer
-isolation blocker — write the four complete-map artifacts under `.haystack/cloud-verifier/`
-and validate them there. A terminally blocked review still produces a validated
-blocked receipt; it does not mean withholding the artifacts. Reading those
-artifacts back on a later update is likewise expected and is not a denylist
-violation.
-
-For the compact provisional authority path, save the strict scaffold input and
-ledger, defer the repository-only closure audit because closure is partial,
-skip full-review projections, and let the scaffold command atomically write and
-validate the three artifacts within the 60-second synthesis target.
-
-### 4. Discover primary sources within an adaptive budget
-
-The primary baseline is 48 repository-inspection calls, including the authority
-gate. Suggested allocation: 6 authority calls, 14 launch-surface and structured-
-registry census calls, 18 state/egress implementation calls, 6 clone-injection
-calls, and 4 final closure checks. Batch related reads. Calls 48, 96, and 192 are
-reporting checkpoints, not terminal ceilings. At each checkpoint, record the
-exact generic extension trigger and continue in 48-call waves while any retained
-source, boundary leaf, state identity, browser/host surface, or selector family
-remains uninspected. Stop only after two consecutive source-wide identity sweeps
-add no new exact operational identity or selector family. At termination, mark
-remaining downstream semantic closure partial and add a blocker; semantic
-uncertainty is never a reason to stop the identity census.
-
-Do not record `termination.phase: inventory-complete` with partial inventory
-before completing and recording the two no-new-identity stabilization sweeps.
-Missing hosted-production authority defers the review and production comparison;
-it does not end repository discovery. Likewise, `undetermined` is an
-intermediate census disposition, not a reason to stop early. Continue
-deterministic batched implementation tracing until exact identity discovery has
-stabilized, even when downstream semantic decisions remain partial.
-
-Spend the allocation. Calls are the budget, and stopping early is not thrift: an
-under-spent budget shows up as missing inventory or an unanswered injection
-category, both of which block the map. The injection allocation is additional to
-the inventory allocation, not carved out of it — do not drop resources, external
-dependencies or edges in order to answer the injection categories.
-
-Budget repository inspections, not files. A deterministic extractor that
-walks the already-enumerated retained file list is one inspection call; never
-spawn one tool call per file when a single read-only batch can emit stable
-path/symbol records. Pre-create its output directory, preflight one file, then
-run the source-wide batch. At a cutoff, every exact identity already discovered
-must be retained in the relevant census and closure-candidate ledger; every
-semantically closed identity must also be emitted as a full final row.
-`uncovered` may name an uninspected range or unresolved dynamic key source; it
-may not hide already-discovered selector owners, state roots, or egress calls
-that were omitted from the census.
-
-`budget.primary_discovery.elapsed_seconds` records repository tool-execution
-time, not your own wall clock; model latency is not a property of the map. Its
-1800-second ceiling is a backstop, not a target.
-
-Before deep implementation reads, census all structured discovery surfaces:
-arrays, maps, factories, manifests, generated tables and their inputs, feature
-enums, module indexes, CLI command registries, package entrypoints, and launch
-registries. A surface becomes a structured-registry ledger only when exact
-registration, factory, dispatch, manifest, or entrypoint evidence proves that
-its keys select distinct production behavior or implementation identities.
-Inventory-category relevance is not an admission condition: a registry whose
-entries all link `not-applicable` to runtime, state, and external inventory still
-belongs in the registry census. Command dispatch, UI component/render dispatch,
-parser and formatter factories, field/entity factories, protocol-operation
-dispatch, migration/template dispatch, feature-behavior gates, and constant maps
-that select concrete implementations are registries. Plain enums, lists, route
-declarations, metrics, constants, and feature flags with no concrete dispatch
-are not registries merely because they are structured collections.
-Batch-enumerate every exact key of each proven registry first, then trace
-implementations. Do not spend the final closure
-allocation while a known registry still lacks a stable-ID entry ledger. An
-optional profile or unselected default does not justify sampling or omitting
-provider entries.
-
-Freeze `selector_surface_census.discovery_roots` during this first pass. Add one
-row immediately for every exact typed selector field, registration owner,
-command tree, static dispatch map, switch/if dispatch, generated table, decoder,
-or lifecycle selector before enumerating its entries. Give it the exact owner,
-selector domain, source identity, and eventual selector-surface ID. Every known
-root becomes exactly one selector surface even if its final entries remain
-empty under partial closure; never leave a discovered root only in `uncovered`.
-A partial family with no semantically resolved key yet uses `entries: []`,
-`fallback_default: none-proven`, and either an `entry_enumeration_blocker` with
-exact evidence naming the dynamic-key or uninspected-source boundary, or a
-`semantic_trace_blocker` when observed keys await implementation, category-link,
-or nested-registry closure. Remove the enumeration blocker as soon as the first
-key is observed; remove the semantic blocker only after every observed key is
-admitted or evidenced non-registry.
-
-Join a discovered source record to a root only by its exact normalized path and
-enclosing declaration identity. Never assign records by scan order, nearest
-line, shared vocabulary, family label, or a path-only bucket. A comment,
-generated helper, parser support call, lock, cache, or getter inside the same
-file is not owned by a registry merely because it is nearby. If the enclosing
-owner does not equal the root's `source_identity_key`, keep the source record
-unjoined until its exact owner is emitted, or record an exact non-registry
-decision. Before generation, assert that every mapped raw selector record lies
-inside the full source region of its mapped owner and that no record is reused
-across unrelated owner facets.
-
-Treat 25 or more entries, 100 or more candidate modules/manifests, or a retained
-source tree too large to enumerate reliably by hand as scale mode. In scale
-mode, use a deterministic read-only extraction script in private scratch to
-enumerate tracked structured keys and source paths into stable-ID-sorted data.
-Generate repetitive candidate and artifact rows from that data, then validate
-the generated YAML. Do not manually transcribe, sample, summarize to one family
-record, or spend one tool call per entry. The extractor must derive from generic
-repository structure; never encode repository names or a sealed holdout answer
-key.
-
-The scale extractor must preserve the decision-bearing gate. It may use broad
-syntax scans to *find* candidate collections, but it must not emit each literal
-list or mapping as a registry. For every emitted registry, retain exact evidence
-of the selection/dispatch relationship and derive a semantic stable ID from that
-relationship. An opaque hash is not a substitute for identifying what production
-implementation choice the registry makes.
-
-Do not flatten a global registration table into one family when production
-lookup sites constrain distinct namespaces, typed fields, subcommands, config
-blocks, or lifecycle stages. The physical table is one discovery source, but
-each independently consumed owner-plus-selector-domain is its own logical
-registry family. Reuse exact implementation keys across those families when the
-same leaf is selectable in several domains. For each entry whose selected
-implementation owns another selector root, emit the exact parent-entry to child-
-family edge; partial semantic tracing does not justify dropping a structurally
-proven edge.
-
-Do not let one dominant manifest, plugin, or provider index stand in for the
-surface census. Before artifact generation, separately resolve every discovered
-package executable or entrypoint map, dynamic module-import selector, registered
-factory or provider interface, and configuration-driven implementation dispatch
-table. Emit each genuine inventory registry or preserve an exact evidenced
-non-registry decision. Finding and exhaustively enumerating the largest registry
-does not close the smaller root-selector frontier.
-
-In scale mode, emit both the selector census and every category-known closure
-candidate in the same deterministic generation pass. For a mixed registry,
-retain an exact non-applicable decision for every key excluded by a per-entry
-category discriminator and an unresolved candidate only where exact structured
-metadata cannot decide. Stable-ID sort both outputs and generate their paired
-atomic census evidence; do not finish after producing only the selector ledger.
-
-A positive structured discriminator is authoritative for census breadth until
-contradicted by stronger exact evidence. Implementation tracing refines
-activation, consumers, ownership, and padding; the absence of a direct import,
-literal host, or client constructor does not erase a positive manifest or
-registration decision because transport may be transitive. In particular, a
-structured I/O declaration is an external-interaction positive whether it says
-local/device polling, local/device push, cloud polling, or cloud push. `local`
-describes destination placement, not an in-process internal link. Project the
-entry first, then exclude only with exact evidence that it is calculated,
-in-process plumbing, dead/removal-only code, or duplicate reproduction identity.
-Before final generation, apply those exact counterevidence decisions across the
-whole extracted set; do not leave an entry as an external census positive when
-its reachable production body proves that it is only a tombstone, migration or
-error shim, or process-internal transformation with no boundary crossing.
-
-Before leaving a scale registry with `undetermined` projections, exhaust generic
-read-only signature passes over the retained production sources. Derive exact
-identities from syntax and structured keys—not names or summaries—and batch at
-least these surfaces when the repository's languages expose them: executable
-and worker registrations; configuration schemas and connection fields; client,
-SDK, transport, producer, and consumer construction; URL, host, endpoint, topic,
-bucket, and namespace constants; migration and schema roots; storage adapters
-and durable read/write calls; backup providers; and generated registry inputs.
-Every exact positive becomes a category candidate even when activation,
-consumer, or backing-state semantics remain unresolved. It becomes a final
-top-level row only after those semantics close.
-
-Make that surface pass language-aware instead of relying on broad vocabulary.
-For Java or Kotlin, batch `META-INF/services`, service-loader calls,
-reflection/class-name construction, factory/provider maps, configuration fields
-that carry implementation classes or type keys, annotation-driven command or
-plugin dispatch, and the transitive concrete subtype closure of every selected
-provider interface or abstract base. Follow subclasses of subclasses; do not
-stop at direct implementers, configured defaults, or example values. Retain
-configuration aliases and sentinel/default selectors as exact entries even when
-they resolve to a class already present under another key. Treat behavior-
-selecting enum constants as a registry family, not as ordinary constants.
-Annotation closure includes annotated abstract bases and command-group nodes as
-well as concrete leaves: addressability comes from the dispatch annotation, not
-from class concreteness. A packaged executable remains an entry in an
-executable registry even when the same launcher is also the mapped long-running
-runtime role. Treat a
-packaged command table, command annotation index, or executable dispatch map as
-a registry when exact keys select distinct production-capable implementations,
-even when every implementation is a finite batch that is also a runtime role.
-For Go, batch `init` registration calls,
-factory maps, blank-import plugin sets, and interface-backed config selectors.
-For Rust, batch enum dispatch plus `inventory`, `typetag`, feature-gated module
-registrations, and trait-object constructors. For Python, batch packaging entry
-points, import-string selectors, plugin managers, command groups, and provider
-dictionaries. For JavaScript or TypeScript, batch package entrypoints, command
-and adapter maps, dependency-injection tokens, and exact dynamic-import tables.
-Equivalent mechanisms in other languages receive the same treatment. Record
-each positive surface as an emitted registry or an evidenced non-registry
-decision before declaring the root-selector frontier closed.
-
-Prioritize production IaC, deployment manifests, checked-in deployment or
-service catalog descriptors, container builds, artifact pipelines, entry points, client
-construction, connection config names, migrations, schemas, producers,
-consumers, workers, scheduled jobs, routes, RPC, messages, browser entry points,
-observable outputs, and declared network destinations. Do not use cloud CLIs,
-provider discovery APIs, production endpoints, or production credentials.
-
-Config-declared destinations are the easy half. Sweep for the ones reached from
-code before closing discovery, because a destination named nowhere in
-configuration is the one most often missed:
-
-- host literals and URLs written in source rather than in config or env defaults;
-- client or SDK constructors carrying a vendor default endpoint used when no
-  override is set;
-- assets fetched at startup or on first use, such as model weights, geo
-  databases, word lists, or template and font bundles;
-- authentication strategy and identity-provider registrations, which name a
-  destination the customer supplies rather than a fixed host; and
-- telemetry exporters constructed in code, including one handed a
-  caller-supplied endpoint.
-
-A destination that appears only in code is still an external dependency. When a
-flag or feature gate selects it, record it once with `activation: optional`
-rather than dropping it because no configuration names it.
-
-Before synthesis, build `evidence.yml`'s topology closure ledger, keyed only by
-stable candidate and subject IDs. Enumerate every long-running launch surface
-from Compose services, Kubernetes workloads, Helm templates, systemd units,
-Procfiles, process-manager and supervisor configuration, container `CMD` and
-`ENTRYPOINT`, package scripts, shell launchers, and application service
-metadata. Follow wrappers to the executable entrypoint. Resolve every
-discovered command or process to either a runtime role ID or an explicit
-exclusion with exact evidence and a reason such as build-only, test-only, or
-non-production-only. A finite production-reachable CLI, admin command,
-migration, or batch is a runtime role; duration and normal exit are not
-exclusion bases. Keep every exact wrapper or entrypoint identity separate, and
-never summarize multiple launchers with a family exclusion. The deterministic
-launcher census binds each wrapper to its own role candidate. A runtime mapping
-never substitutes for registry census. Follow
-nested command groups and annotation-driven subcommands even though their
-top-level category projections are all `not-applicable`.
-Do not finish while a launch surface is unaccounted for.
-
-Resolve at independently restartable deployment-unit granularity, not merely
-container, command, or profile granularity. A PID 1 supervisor that stays alive
-and manages multiple named longruns is one runtime role, and each child that is
-independently started/stopped and remains alive is another, even when they share
-one image. Do not split setup/init/migration commands, an inseparable
-master/worker pool, or a web/static facet served by an already-recorded process.
-  A separately launched database, cache, broker, or search-engine process is
-  also a pinned-infrastructure runtime role even when its application purpose
-  is to realize a mapped stateful resource; preserve both its launch unit and
-  its state concern. A Compose service,
-alternative-profile label, interface, or external-dependency entry cannot close
-a launch surface; the ledger must point to an exact
-`services[].runtime_roles[]` ID. Include concrete optional companions from
-production-intended or supported self-host recipes. Exclude a companion whose
-only launch evidence is local development, test, CI, an example, or a worktree
-helper.
-
-Use this long-running role checklist to challenge the ledger, even when a role
-is implemented in the same repository or image as the main application:
-
-- edge proxy, static server, reverse proxy, and load balancer;
-- web, API, realtime, and WebSocket server;
-- queue consumer, task processor, search or full-text indexer;
-- scheduler, cron runner, and asynchronous task worker;
-- lifecycle, expiry, retention, compaction, and garbage-collection daemon;
-- process supervisor, watchdog, and auto-heal process;
-- SSH daemon, monitoring server or exporter, and managed backend-plugin child;
-- network relay, privacy proxy, tunnel, or other separately launched egress helper;
-- mount, block-device, filesystem, network-namespace, DNS, or virtual-machine helper;
-- replication, mirroring, synchronization, import, or export process;
-- cluster application coordinator or separately launched control process;
-- sandbox, agent, code runner, or other isolated execution runtime; and
-- a separately launched documentation or static-site server that is inside the
-  selected application boundary.
-
-A separately executable production-capable proxy, gateway, worker, or helper is
-an optional runtime role even when the default container, packaging manifest,
-or selected hosted profile does not launch it. Exclude it only with evidence
-that it is build-only, test-only, documentation-only, or outside the selected
-application boundary; “not the default artifact” is not an exclusion.
-
-Also resolve exact execution facets inside a packaged executable. Distinct
-server, worker, scheduler, consumer, maintenance-daemon, and watch modes are
-separate runtime roles only when each is independently deployed or restarted
-and stays alive, even if they share a binary and artifact. Scheduled, injected,
-sidecar, and host-managed long-running production processes receive the same
-treatment. An init or setup command that prepares another unit is not an extra
-role. Preserve the exact mode, task, schedule, and a unique
-`deployment_unit_identity_key` in `structured_identity`.
-
-Close state in the same way. Enumerate databases and logical databases, search
-indexes, caches, brokers, queues and streams, object-storage buckets, backups,
-embedded databases, remote filesystems, and mounted storage. Resolve each
-candidate by exact structured identity to one resource ID or to an evidenced
-exclusion; never merge or suppress it by similar text.
-
-Admit only independent reproduction units. `structured_identity.state_unit_kind`
-is one of `logical-database`, `database-schema`, `cache-namespace`,
-`search-index`, `queue-or-stream`, `credential-file`, `trust-material-file`, `tls-keypair`,
-`object-bucket-or-prefix`, `persistent-volume-or-directory`,
-`portable-snapshot`, `installed-artifact`, `packaged-installation-layout`,
-`generated-host-state`, `immutable-packaged-asset`, or
-`repository-proven-independent-object`. It also records an exact unique
-`address_token` and exact `reproduction_token`, both supported by the atomic
-state-owner evidence. Neither token may be a placeholder. A final row may use
-`reproduction.strategy: unresolved` only while the matching category remains
-partial and names that exact reproduction frontier; it can never support
-complete closure. Include a portable container and a contained
-file, database, generated artifact, installed binary, or packaged asset when
-each has its own exact address and reproduction operation. Do not promote an
-unaddressed table, projection, index,
-field, or record inside an already copied database, nor a remote import object,
-provider option, operator-supplied input, or discovery response. A finer-grained
-child becomes a resource only when exact repository evidence proves that it is
-independently addressed and independently preserved, copied, rebuilt, reset,
-restored, installed, replaced, or launched.
-
-Network location does not decide the category. A database, directory, broker,
-queue, stream, object store, registry, secret store, model store, or search/log
-index that owns application-relevant state is a `resource` even when a managed
-provider hosts it. When a runtime reaches that resource over a network protocol
-or API, also map the service interaction as an `external_dependency`; routing,
-emulation, and production-isolation control are a separate reproduction action.
-Link both concerns. A local, embedded, in-process, or file-backed resource stays
-resource-only unless it has separate application egress. Every external entry
-must state whether `backing_state` is
-`none` or `covered-by-resources`; the latter links exact resource IDs so a
-network API cannot silently replace its state reproduction concern. Its
-`evidence_ids` must include one decision-grade atomic evidence record whose
-exact `subject_ids` jointly name that dependency and every linked resource.
-Use `state-boundary-link` for `covered-by-resources`,
-`external-interaction-boundary` for `interaction-only`, or
-`external-ownership-unresolved` for `remote-ownership-unproven`; its
-`external_backing_basis` and `external_operation` repeat the final decision,
-and named state also repeats `remote_state_identity_key`. Evidence that mentions
-only the client or only the store does not prove their boundary. Also
-record `basis: interaction-only` or `remote-ownership-unproven` with `none`, and
-use `repository-declared-state-owner`, `repository-proven-remote-state`, or
-`authoritative-catalog-state-owner` with `covered-by-resources`. A configured
-endpoint, constructed SDK client, or provider name alone does not establish a
-state owner. Exact implementation evidence that performs a typed durable
-operation on a named remote namespace does; record it as
-`repository-proven-remote-state` with `named-remote-read` or
-`named-remote-write`.
-
-A named remote read establishes a state resource only when repository evidence
-also proves an exact application-owned provision, preserve, reset, restore,
-replace, or recreate operation for the addressed object. Provider metadata,
-discovery records, identity documents, signing-key documents, downloaded user
-content, and operator-supplied remote inputs remain external interactions when
-the application only consumes them. Do not invent ownership merely because a
-response affects behavior. If state ownership or independent identity is
-unresolved, retain the observation and pending candidate, keep state closure
-partial, and do not emit a final state row. If only the materialization strategy
-is unresolved, the exact final identity may remain while closure stays partial.
-
-Classify the exact operation before choosing the backing-state disposition.
-Every external dependency records `operation` as `named-remote-read`,
-`named-remote-write`, `named-remote-read-write`, `stateless-exchange`, or
-`unresolved`. A named operation also records an exact
-`remote_state_identity_key` for the addressed object, namespace, or provider
-contract and must use `covered-by-resources`. `stateless-exchange` is the only
-operation compatible with proven `interaction-only`; uncertainty uses
-`unresolved` with `remote-ownership-unproven`. The boundary evidence repeats
-both the operation and remote-state identity key. This decision order prevents
-a discovered service client from hiding the state payload it reads.
-
-Inventory remote reads and writes at exact boundary-operation identity.
-Distinct effectful methods remain distinct external contracts even when one
-client, provider, or user flow owns them. Conversely, provider, scheme, OS,
-wrapper, and consumer variants of the same semantic operation are one top-level
-operational subject, with variants retained in evidence or selector registries.
-Emit a resource/external pair only when the addressed object also passes the
-independent application-owned reproduction test; otherwise emit only the
-external operation. Never use one broad flow row for several calls or split one
-call by provider or consumer.
-
-Before projecting an external candidate, reopen the selected implementation
-body and prove the exact boundary-crossing call. Constructors, authentication
-and client-configuration modes, retry or polling timers, protocol selectors,
-and wrappers that only build or call child handlers are not separate external
-operations. Keep those choices in their selector registries and mark their
-external category projection not applicable unless the branch itself performs
-a distinct addressed operation. Group candidate call sites by exact operation,
-object identity, and destination contract; if two candidates differ only by
-scheme, transport, client-construction mode, or wrapper strategy, retain one
-top-level dependency and never manufacture variant-specific subjects merely to
-make category candidates unique.
-
-Apply that test at registry-contract granularity as well as per implementation.
-When an exact provider interface or factory contract exposes durable
-create/read/write/delete/list operations over backups, objects, buckets,
-collections, topics, streams, tables, indexes, identities, policies, keys, or
-other named namespaces, the contract is a positive state discriminator for each
-reachable provider entry. Create a state candidate for every provider keyed by
-its exact registry identity; do not wait for a provider-specific host literal or
-duplicate the same interface trace in every implementation. If the provider is
-reached through a network protocol or service API, also create its external-
-interaction candidate. Close the concrete namespace, consumer, and reproduction
-strategy before admitting either candidate to final inventory.
-
-When that same exact provider contract is network- or API-backed, join its state
-and interaction candidates by stable ID in the same deterministic generation
-pass. Once both are semantically closed, emit `backing_state:
-covered-by-resources` on the external row, link the exact provider-derived
-resource ID, and add one joint `state-boundary-link` atomic record whose subject
-set contains both IDs. A partial closure may retain the joined candidates, but
-it may not emit either as an unresolved final row.
-
-`remote-ownership-unproven` is an unresolved state-boundary result, not proof
-that no state exists. If any external dependency retains that basis, mark
-stateful-resource closure `partial` and name the unresolved dependency IDs.
-Only `interaction-only` may support a complete state ledger with
-`backing_state: none`.
-
-Judge ownership from interaction semantics as well as location. Repository
-declarations that select mutable tables, objects, topics, schemas, catalog
-metadata, directory identities/groups, authorization policies, tenant/client
-registrations, or encryption keys establish a state-owner concern even when
-the bytes live behind a remote protocol. Map that concern as a resource and
-link the service interaction with `covered-by-resources`. A stateless inference
-call, webhook receiver, credential exchange, or arbitrary URL still uses
-`backing_state: none` only when implementation evidence proves the exchange has
-no retained state relevant to reproduction. Persistent telemetry/log/metrics
-destinations, broker topics, object namespaces, identity/policy/key sets, and
-catalog namespaces are resources when exact typed durable operations are proven.
-If ownership remains ambiguous, use `remote-ownership-unproven` and keep state
-closure partial; do not default it to `interaction-only`. `none` here describes
-only backing state: a reachable token,
-credential, identity, telemetry, webhook, inference, or URL call is still an
-`external_dependency` and must not be excluded from egress inventory.
-
-Close state on two axes: every persisted mount or path, and every supported
-engine or provider selected behind it. A broad filesystem or application-data
-volume does not cover an embedded database, persistent queue, or on-disk search
-index inside it unless the resource entry explicitly names that engine, state
-semantics, and reproduction action. Enumerate the default local engine and each
-supported mutually exclusive engine; one polymorphic resource may cover them
-only when its kind, strategy, and evidence explicitly span every variant.
-Separately mounted model, cache, metrics, and dashboard data count when they
-require their own provision, bind, rebuild, or reset action, even if
-rebuildable. Continue excluding in-memory boot caches, unmounted scratch, and
-state already reproduced by an identical parent action.
-
-Provisioned writable capacity counts when a selected feature requires a
-separate mount, directory, or reset action even if spill/cache contents may
-start empty. Process-local state counts when required behavior needs an
-explicit reload or seed action after launch. Do not promote a scratch or lock
-file that is merely a child of already provisioned capacity, and do not turn a
-remote service client into local state.
-
-As a separate state-frontier pass, enumerate every production configuration
-field that names a writable directory, database, queue/topic, archive/export or
-restore command, key/trust/password file, or generated log/output destination.
-Trace the consumer for each exact field. Keep independently provisioned paths
-and independently invoked command hooks as distinct candidates even when they
-serve one feature; merge them only through the exact reproduction-action test
-below. Disabled-by-default audit, query-log, backup, export, and restore paths
-remain optional inventory rather than disappearing from the census.
-
-In the same batched pass, enumerate mutable production roots that survive one
-request, event, or callback: module/global registries, maps, sets, keyed slices,
-atomics, counters, metric vectors, listener/connection pools, buffer or writer
-pools, caches, session/ticket/key rings, subscription tables, in-flight
-coordination, timers/schedules, locks and leases, generated identities, and
-nested child collections. Retain each exact owner/root/key identity first;
-semantic tracing may later exclude a truly request-local temporary, but a broad
-parent container or shared physical file may not erase independently keyed
-children.
-
-Write this pass into
-`stateful_resources.state_surface_discovery` before synthesizing resources.
-Include exact configured keys, persisted entity declarations, installed
-artifacts, scheduled state, host-persistent state, remote loaders, writable
-paths, generated outputs, and identity-material slots. Give every exact surface
-its own ID. Mark it `candidate` only when it establishes an independently
-preserved logical identity; otherwise retain it as `non-resource` with the
-implementation-based reason. Generic config roots, loader directories,
-selector values, WAL children, mount plumbing, and ambient metadata are not
-automatically resources. Multiple true surfaces may resolve through one
-candidate only with exact `shared_binding_evidence_ids`.
-
-Then write `stateful_resources.logical_state_census`. Do not stop at the
-physical database, bucket, table, directory, topic, prefix, volume, or remote
-namespace. Starting from every persistent write, update, delete, append,
-install, snapshot, export, restore, registration, and lease operation,
-enumerate the exact logical identity it mutates. Record its materialization
-root separately from its independently keyed identity, the exact source owner,
-all key/discriminator/prefix/path components, mutation operations, and the
-state-surface rows that led to it. A bucket name, table name, namespace root,
-or key prefix cannot stand in for records addressed by a member ID, user/role
-name, object key, tenant, lease, contender, candidate, registration, version,
-or other record component.
-
-Give every logical row exactly one state candidate. Physical containers remain
-separate `materialization-container` rows when reproducing the container is an
-independent action. Each container must either enumerate all of its keyed child
-rows, prove from exact implementation evidence that it has no independently
-keyed children, or keep logical-state and stateful-resource closure partial.
-Never use `none-proven` merely because the bytes share one database file or
-snapshot action. Shared physical copy actions belong in materialization
-grouping; they do not merge logical resource identities.
-
-Treat portable snapshot/export files and packaged installation layouts as
-explicit state frontiers. If production-capable code can create, save, export,
-restore, import, install, unpack, or launch from a durable artifact or layout,
-emit the exact `portable-snapshot` or `installed-layout` logical identity and
-its source surface. A generated snapshot is not covered only by the live
-database it captured, and an installed executable/config/unit layout is not
-covered only by its build artifact or container descriptor.
-
-Apply the independent-reproduction-unit test before promoting physical state.
-A full resource needs both an independently addressed stable logical key and an
-independent preserve, copy, rebuild, reset, restore, install, replace, or launch
-action. Physical blocks, indexes, rotation generations, transport files,
-temporary staging IDs, memory-only variants, and implementation leaves copied
-or reset only with their logical parent stay non-resource rows. Represent
-storage engines, encodings, and file-versus-memory choices in selector
-registries instead of splitting one logical identity into backend-specific
-resources.
-
-Expand installed layouts to each independently installable, replaceable, or
-launchable shipped identity: executable, service/unit definition, container
-image, host registration, or equivalent. A directory or package family is not
-one logical identity when those members can be installed or replaced
-separately. Give portable snapshots and exports a content digest, version,
-manifest, or other durable content identity; never key them by an invocation,
-temporary path, staging token, or generated run ID.
-
-For every logical-state row—not only a materialization container—inspect the
-serialized value and every nested map, set, repeated child, session member,
-binding, or record collection. Set `contained_identity_disposition` to
-`enumerated` and list every independently keyed child, `none-proven` with exact
-implementation evidence, or `unresolved` while closure is partial. A record
-that serializes a keyed child collection is itself a container boundary for
-this check even when its `logical_kind` is not `materialization-container`.
-
-Repeat each mapped logical row's exact `source_owner_identity_key`,
-`materialization_root_identity_key`, and `key_components` in its top-level
-resource `structured_identity`. These fields must match mechanically. This
-prevents a broad resource label from surviving after the census discovered a
-more precise owner, root, or record key.
-
-Resolve `source_owner_identity_key` to the real declaration or mutator present
-in source; never synthesize a convenient method name or point at a registry,
-schema, comment, or caller that does not own the state operation. Except when
-the materialization root is itself the complete independently reproducible
-identity, `key_components` must include a semantic discriminator beyond that
-root: filename, document/object key, provider namespace, certificate role,
-plugin/module version, log stream, account, or equivalent exact identity.
-Before closure, challenge every row whose components contain only the root and
-every owner symbol that the language-aware declaration census cannot resolve.
-
-Use exact logical identity as the inventory deduplication gate and physical
-reproduction identity as the materialization grouping gate. Keep separately
-keyed logical queues, databases, namespaces, indexes, installed material,
-outputs, and persisted identities as separate resources even when their
-`physical_binding_id`, state cut, and copy/rebuild/reset action are identical.
-Collapse only exact aliases of the same logical identity. Similar consumers,
-semantic labels, paths, providers, or physical co-location do not prove an
-alias.
-
-Close egress from call sites, not configuration vocabulary. Trace constructed
-HTTP, RPC, SDK, telemetry, error-reporting, update, status, push, certificate,
-and authentication clients. A config name or URL constant without a reachable
-client call is only a candidate and must not become an entry. Conversely, a
-reachable default endpoint with no concrete gate belongs in the inventory even
-when no deployment file names it. Reconcile the result against each subject's
-persisted `activation_basis` before classifying activation.
-
-Record both the caller and interaction direction for every external candidate
-in `structured_identity.interaction_direction`: `outbound`,
-`inbound-required`, `bidirectional`, or `host-mediated`. Required inbound
-clients, pull consumers, registries/discovery services, and host services are
-external reproduction interactions even when application code does not open
-the first connection. A route by itself, a destination handed to an unrelated
-actor, or a browser-facing URL rewrite is not enough; require source or topology
-evidence that the external actor is necessary for the selected application.
-Record a configured outbound proxy when selected application calls traverse it.
-Do not let a broad remote, plugin, or provider-family entry cover a distinct API
-client unless their call path, transport semantics, and reproduction action are
-the same. A passive hyperlink or rendered URL is not a dependency merely because
-navigation may leave the application. Code that invokes an OS/browser launcher
-is a host-mediated operation; an authorization redirect whose callback is
-consumed is an outbound operation plus the separately opened inbound listener.
-Traffic to another incarnation of the same mapped runtime role that jointly
-realizes the same in-universe service or state resource is an internal runtime
-link, not an external dependency. Map it externally only when exact topology
-evidence selects a separate outside-universe service or cluster.
-
-Do not create one external dependency per route or count same-universe cluster
-peers, configuration/environment/filesystem reads, signals, ordinary DNS
-resolution, or process-local system calls. Do retain each independently
-reproduced listener or service interface when production behavior requires an
-outside ingress, browser/client, controller, puller, registry, or peer at that
-boundary; the listener is an `inbound-required` contract even though
-application code accepts rather than opens the connection. Runtime-invoked
-executables and persistent host services remain external interactions. Keep one
-row for the top-level listener or pull contract, not its routes, upgrade modes,
-or protocol variants. Group provider/configuration variants that share one
-call-site identity and exclude calls whose target is another mapped runtime
-role. Every external structured identity records a unique exact
-`operation_identity_key`, exact source owner, exact `operation_token`, direction,
-allowed `boundary_contract_kind` (`outbound-operation-family`,
-`host-operation`, `required-inbound-listener`, `required-pull-listener`, or
-`bidirectional-operation-family`), and nonempty destination or scope key
-components. A protocol, provider, or client-family label is not enough.
-
-Apply operation granularity consistently. Object stores and similar SDKs expose
-list, head/metadata, get/download, put/upload, copy, and delete as distinct
-contracts when those calls are reachable. Authentication or identity clients
-may independently redirect, exchange tokens, fetch user information, fetch
-supplemental data or signing keys, and download content. Merge the same call
-across providers and consumers; do not bundle these distinct effects into one
-storage, OAuth, host, or browser “operations” row. A separately opened redirect
-or callback listener is its own required inbound contract. Host-operation rows
-likewise represent one semantic effect family, not an arbitrary bundle of
-filesystem, environment, process, and subprocess capabilities.
-
-If a source manifest, registration record, client constructor, or implementation
-body proves a real optional interaction but the exact consuming role is not yet
-traced, keep the dependency in `external_dependencies` with empty role and edge
-lists and unknown-production-state activation. If remote ownership is unclear,
-use `remote-ownership-unproven` and keep state closure partial. Never drop the
-interaction while waiting for those semantic decisions.
-
-Sweep runtime-invoked executables as external interactions too. A subprocess,
-shell command, package tool, credential helper, media converter, or other
-one-shot executable invoked by a mapped role is an external dependency when it
-crosses the application runtime boundary, even though the executable itself is
-not a long-running runtime role. Keep managed child RPC that remains inside one
-mapped runtime internal; distinguish the two with exact call-path and lifecycle
-evidence.
-
-At the start of discovery, build
-`coverage.selector_surface_census` from exact source owners before synthesizing
-registries. Census executable dispatch, plugin/provider factories,
-persistence/schema/snapshot dispatch, lifecycle pipelines, behavior enums and
-allow-lists, configuration selectors, dynamic modules, packaging entry points,
-and generated inputs. Each source-owner row records its exact construct kind,
-owner identity, enumeration method, availability predicates, and either one
-emitted registry ID or an evidenced `non-registry` decision. Do not use `*`,
-"all", family prose, or a sampled member as a substitute for enumerating exact
-structured selector values. Every emitted registry family must resolve from
-exactly one selector-owner row.
-
-The census begins with the append-only `discovery_roots` ledger. Every root has
-an exact owner identity, selector domain, repository path-plus-symbol source
-identity, evidence, and one surface ID. Every surface has exactly one root. A
-known typed field or switch cannot be deferred as prose: emit the family and
-retain every observed key on its selector surface. As soon as an exact key maps
-to an exact implementation, also emit an `entries[]` row with
-`trace_status: identity-complete` while discovery remains partial; category-link
-or child-registry uncertainty does not erase it. Final receipt upgrades that row
-to full category links and a child-registry decision. Zero known keys require the family's exact
-`entry_enumeration_blocker`; the blocker is not a substitute for already known
-keys.
-
-Run this as a deterministic source-wide pass, including fixed scalar config
-keys, enum/tag decoders, switch dispatch, build/platform selectors, generated
-tables, command keys, type selectors, defaults, and fallbacks that choose
-production implementations, commands, or lifecycle paths. Record exact
-`observed_selector_keys` and distinct `observed_implementation_keys` on every
-surface. A `non-registry` decision is valid only when exact source structure
-selects at most one production implementation. Free-text explanation cannot
-hide a multi-implementation decision family.
-
-Then inventory each category's structured registry surfaces. Look
-for arrays, maps, generated tables, module indexes, provider or plugin
-registrations, factory dispatch, driver catalogs, manifest lists, and code
-generation inputs that enumerate implementations. Record each surface under
-that category's `structured_registry_discovery.registries` with a stable ID,
-exact evidence, enumeration status, and the exact entries it produced.
-Enumerate entries from structure, never by fuzzy matching names or summaries.
-A complete empty registry needs an evidenced `empty_reason`; a category with no
-registry surfaces needs an evidenced `absence_reason`. If a generated file,
-dynamic loader, submodule, build input, or budget boundary prevents exhaustive
-enumeration, mark both registry discovery and the category `partial` and name
-the uncovered scope. One broad “plugin system” candidate never closes a
-registry containing independently selectable integrations. Under every
-registry, emit one final `entries[]` record per semantically traced structured
-key, symbol, module, or manifest entry. Give it a stable ID, exact unique
-`selector_key`, exact `selector_token`, exact `selection_predicate`, exact
-`implementation_key`, distinct exact `implementation_token`, and evidence.
-Untraced observed keys remain on the selector surface and keep the registry
-partial. Registry
-families also retain the exact source-owner identity, selector domain,
-enumeration method, and fallback/default. Preserve aliases as separate selector
-entries even when several keys resolve to one implementation; implementation
-keys therefore may repeat, while selector keys may not.
-Executable and command dispatch are a deliberate case: shipped wrapper maps,
-command tables, command annotations, and nested subcommand indexes are
-registries when their exact keys dispatch distinct production-capable command
-implementations. Retain them alongside exact runtime-role candidates for every
-finite production-reachable command; the registry and runtime identities do
-not replace one another.
-A configuration-provided entry map that is empty does not make its registry
-empty when the factory instantiates a built-in default or fallback; enumerate
-that exact fallback as an entry. A complete `empty_reason` must prove that no
-configured, registered, generated, default, or fallback implementation can be
-selected—it must never cite the existence of a default implementation as the
-reason for zero entries.
-When the census is complete but semantic tracing is not, retain the observed
-selector and implementation keys on the selector surface, record the exact
-implementation, category-link, or nested-registry gap in
-`semantic_trace_blocker`, and keep the
-registry partial. Do not emit a compact census-only final entry. Upgrade the
-observation to the full form only after exact identity evidence, all three
-`category_links`, and either `child_registry_ids` or evidenced
-`child_registry_absence` are complete.
-Reconcile every entry
-against all three inventory categories under `category_links`: use
-`disposition: candidate` with one exact category candidate, or
-`disposition: not-applicable` with evidence and a category-specific reason.
-This means a connector or storage driver commonly produces both a state
-candidate and a separate service-interaction candidate; mapping the store does
-not erase its network dependency. Within one registry and category, two
-entries may not reuse the same candidate or resolve to the same inventory
-subject. Preserve separate candidates and subjects for independently
-selectable systems; do not replace a concrete connector list with one family
-record. If two registrations truly are aliases for one logical inventory
-identity, link each to its own evidenced excluded candidate instead of hiding
-both behind one mapped candidate.
-
-Make every category decision atomic. A `not-applicable` link carries exactly
-the fixed basis for its category: `no-independent-long-running-runtime`,
-`no-independent-persistent-state-identity`, or
-`no-external-reproduction-interaction`. Every link,
-candidate or not-applicable, cites `registry-category-decision` evidence whose
-only subject is the exact derived `<entry-id>-link-<kebab-category>` ID and whose
-repository source uses `inspection_scope: implementation-body`. A registry or
-installer declaration cannot prove that an implementation has no state action,
-egress, or long-running child.
-
-Registry closure is recursive. Mark top-level surfaces with `root: true` and
-nested surfaces with `root: false`. For each entry, inspect its implementation
-for another structured selector—transport, provider, authentication mode,
-catalog type, schema supplier, key manager, or equivalent. Link every such
-surface through `child_registry_ids`; otherwise provide an evidenced
-`child_registry_absence` mapping with a specific `reason` and nonempty exact
-`evidence_ids` from the implementation/configuration body inspected for nested
-selection. At least one record uses `claim_kind: registry-leaf-inspection`, has
-exactly `[entry-id]` as `subject_ids`, and cites a repository source with
-`inspection_scope: implementation-body`. Evidence shared across several entry
-IDs is not atomic leaf proof. A registry-entry declaration alone does not prove
-leafhood. Every
-non-root registry must be linked by a
-parent entry, roots may not be children, and the graph must be acyclic and
-reachable from roots. Do not stop at a parent plugin merely because it already
-has a candidate: its independently selectable child implementations require
-their own entries and three-way category reconciliation.
-
-Before claiming any category complete, write
-`coverage.operational_surface_census`. Enumerate exact execution facets,
-persistent logical entities and configured leaves, remote operations, network
-or SDK interactions, runtime-invoked commands, host-service interactions, and
-required inbound or pull interactions. Each source surface has a stable ID,
-category, kind, exact `identity_key`, and exact
-`operational-surface-census` evidence. Resolve it to one closure candidate or
-retain an evidenced `non-inventory` decision. Every closure candidate must be
-derived from at least one exact source-surface row; broad family prose cannot
-close this ledger.
-For state, operational surfaces and `logical_state_census` must agree
-one-for-one on candidate identities. Include explicit
-`portable-snapshot-artifact` and `packaged-installation-layout` surfaces; a
-container root, selector family, or prefix-only row cannot close a keyed record
-frontier.
-
-State-operation closure uses the same exact-owner rule. Map an operation only
-to the resource whose stable source identity names the operation's enclosing
-state owner or exact logical leaf. Do not distribute operations by array order,
-path prefix, resource family, or a nearby getter. When an operation proves a
-new durable logical owner, retain a new closure candidate rather than joining
-it to an unrelated existing resource; admit it only when its independent state
-unit identity is closed. Exclude comments, synchronization locks,
-ephemeral caches, and generic support code with their own exact stable IDs and
-structured reasons. Run an exact post-join audit that reopens every mapped
-operation's full source region and proves its target resource identity.
-
-Spend all remaining calls on these closure ledgers. For all three categories,
-write every candidate to `coverage.inventory_closure` as either `mapped` to
-exact inventory IDs or `excluded` with evidence and a reason. Stopping below the
-selected call limit is valid only when every candidate is resolved, every
-category is `complete`, every structured registry is exhaustively enumerated,
-and the repository-only closure audit below is completed; otherwise use the next
-allowed extension when a trigger applies, or set the affected category to
-`partial`, record its uncovered scope, and add the exact blocker.
-
-Every excluded candidate also records a structured `exclusion_basis`: one of
-`build-only`, `test-only`, `non-production-only`,
-`outside-application-boundary`, `parent-runtime-unreachable`,
-`not-independent-reproduction-unit`, `internal-runtime-link`, or
-`duplicate-inventory`. Only the last basis carries nonempty exact
-`equivalent_subject_ids` and exact `duplicate-inventory-equivalence` evidence.
-The corresponding candidate audit row must cite that same atomic equivalence
-claim. For a candidate referenced by a structured registry, only
-`duplicate-inventory` is valid; a profile/default/configuration gate is an
-optional activation basis on mapped inventory, never an exclusion basis.
-
-After primary discovery, run one bounded independent repository-only closure
-audit before declaring any category complete. This audit is permitted even
-when hosted-production authority is absent because it reads only the isolated
-repository snapshot and makes no production claim. Use a real read-only
-customer-CLI subagent, hide the primary candidate during its blind inventory,
-disable network, allow no descendants, and keep it within 48 repository calls
-and 10 elapsed minutes. Challenge root discovery, every declared leaf, recursive
-registry edges, and all three category links before launch
-surfaces, state engines/providers, egress direction, and external
-`backing_state` edges. Reveal only compact stable-ID projections after blind
-inventory. If it finds a correction, keep closure partial, reconcile the final
-artifacts, and run one new blind audit in a fresh independent session. Never let
-the correcting session certify the revision it influenced.
-
-Record the receipt as `review.yml.inventory_closure_audit`. A completed audit
-must cover exactly all three category names, every closure candidate ID, and
-every structured-registry and registry-entry ID, every derived entry-category
-link ID, and every parent-child registry edge ID. A completed final receipt sets
-`final_artifacts_unchanged_since_blind_inventory: true`, contains only
-`confirmed` decision rows, and has an empty `findings` list. Corrections and
-historical resolved findings belong to the superseded audit kept in private
-scratch, never the clean final receipt. The auditor reopens and reviews the
-final generated inventory, registry, reproduction, and closure artifacts, not
-only the earlier source census. Artifact immutability never converts an
-unreviewed or discrepant final row into a confirmed one. Any pending candidate,
-partial selector family, unresolved reproduction, uncovered range, corrected
-verdict, or remaining finding keeps the matching category partial. Challenge
-every `not-applicable` category link, especially stateful connectors marked as
-non-egress and remote identity,
-policy, schema, catalog, or key services marked as stateless. During the state
-challenge, do not promote configuration files already handled by clone
-injection, generated logs or outputs, scratch/lock files, or replaceable assets
-into resources unless their initial contents require a separate
-copy/rebuild/reset action. During the backing-state challenge, reject remote
-ownership inferred only from an endpoint or client.
-
-The receipt is decision-bearing: emit exactly one `candidate_reviews` row per
-candidate, one `state_owner_reviews` row per resource, and one
-`external_backing_state_reviews` row per external dependency.
-Each row repeats the final declared disposition (and backing-state basis where
-applicable), records the independent verdict, and gives an evidence-backed
-reason. A `corrected` verdict invalidates that pass and requires reconciliation
-plus a fresh audit; only `confirmed` appears in the final completed receipt. An
-exact-ID checklist without those decisions does not establish an audit. For
-every `remote-ownership-unproven` edge, the only honest results are
-a correction to `interaction-only` or `covered-by-resources`, or partial state
-closure.
-
-Also emit exactly one `registry_entry_category_link_reviews` row for every
-derived entry-category link, one `registry_leaf_reviews` row for every declared
-leaf entry, and one `consumer_edge_reviews` row for every exact
-inventory-subject/runtime-role pair. Link rows repeat the final disposition,
-candidate ID or not-applicable basis; consumer rows repeat the edge activation.
-Each verdict cites the same atomic claim kind, exact subject set, and
-implementation-body or role-call-path inspection scope required by the final
-declaration. Exact-ID checklist coverage without these decisions cannot support
-complete closure.
-
-Atomic closure claims are decision-grade: `authority` is `authoritative` or
-`indicative`, `confidence` is `proven` or `strong`, and `environment_scope` is
-`hosted-production`, `production-reference`, or `self-host-reference`. A
-`tentative`, `non-production`, local, example, or unknown record cannot support
-an equivalence, registry link, leaf, consumer edge, or complete external scope.
-
-If the audit is unavailable or cannot cover the exact sets, record a
-short deferred reason and downgrade at least one affected category to
-`partial`. Never use production authority as the reason to defer this
-repository-only audit.
-
-Classify every topology source by environment and authority. Local/dev,
-example, and self-host material proves only itself. Record the topology's
-fidelity ceiling and any missing production authority. Enumerate every
-repository-supported provider, connector, client, and backend capability once,
-including capabilities gated off by the selected profile. Use role reachability
-to assign `consumer_edges` and activation; do not use it to erase supported
-capabilities. Avoid expanding deployment/topology permutations, but never
-collapse distinct structured-registry entries or provider implementations.
-
-For every selected artifact, prove two separate claims:
-
-1. How the exact source commit is mounted or built.
-2. Whether that build uses the production build recipe.
-
-Building the checked-out commit does not prove production-recipe equivalence.
-A fixed infrastructure binary may be exempt from source incorporation only
-when it is explicitly classified as `verification_subject:
-pinned-infrastructure` and its immutable artifact identity and configuration
-source are proven. Application artifacts use `source-changeable` and cannot
-claim this exemption.
-Otherwise add a blocker.
-
-Give every object a durable lowercase kebab-case ID. Link only by exact ID.
-Cite paths and structured anchors such as manifest keys, Terraform addresses,
-symbols, and config names. Record scanned roots and exclusions.
-
-Spend part of the runtime/state budget on the clone-injection surface, not only
-on the inventory. Knowing a Postgres exists does not let anyone start a copy of
-it. For the selected scope, answer all eight `clone_injection` categories from
-the output contract: config slots, DNS identity, TLS, filesystem mounts,
-secret-derived material, protocol metadata, runtime-generated configuration, and
-build-time configuration. Each is either declared with entries or marked `none`
-with a reason; leaving one out is invalid.
-
-Give every injection entry a `materiality`: `boot-required`,
-`binds-copied-state`, `isolation-control`, `behavioural`, or `informational`. Ask
-of each one what actually happens to the replica if a materializer does not know
-it. Answer honestly — `informational` is a legitimate answer and a better one
-than inflating an entry's class. A long list of real-but-inert settings is not a
-better map than a short list of load-bearing ones, and the validator reports the
-mix, so padding shows up rather than scoring.
-
-The validator ties injection to inventory: every `binding_names` value on a
-resource must also be a `config_slots` entry, every runtime role must be named by
-at least one config slot, and an `activation: active` deployment profile must run
-at least one role. Work outward from the inventory you built — for each resource,
-declare the variables that point the application at it; for each role, declare
-what it needs to start.
-
-Two of these are routinely missed and are worth a deliberate pass. First, trace
-every application secret to what depends on it: if a value encrypts or signs
-anything that lives in copied state, it is `seal-with-golden` or
-`scrub-and-reset` and must name the resources it is bound to. A materializer
-that mints a fresh value for such a secret makes the copied data unreadable, and
-the resulting failures look like application bugs. If an exact stable key,
-certificate, salt, or identity must survive to preserve authentication,
-decryption, or signature behavior, map that durable or immutable identity as a
-resource as well. Clone injection records how its value is delivered; it does
-not replace the inventory concern. Use `rotate-freely` only when no copied
-behavior depends on the exact value. Second, follow the process
-entrypoint to see how configuration actually arrives: a mounted file, a rendered
-template, a value baked into an artifact at build time, or a setting read from
-the database at boot. Record the mechanism, not just the variable name.
-
-Classify each resource as `canonical-durable`, `derived-rebuildable`,
-`ephemeral-coordination`, `in-flight-work`, or
-`immutable-external-asset`. Also record its action: copy canonical state;
-rebuild derived state from named source IDs; reset coordination state; preserve,
-drain, or discard in-flight work with a rationale; or pin an immutable asset by
-opaque immutable reference. Do not treat queues, caches, derived indexes, and
-immutable assets as interchangeable durable databases.
-
-### 5. Separate cold preparation from the on-demand path
-
-Omit `materialization_plan` entirely while authority is missing: every field in
-it would have to be invented, and an invented plan is worse than an absent one.
-When authority exists, add the top-level `materialization_plan` from the output
-contract. Treat the
-user's verifier SLO as the end-to-end budget for case generation, launch,
-execution, and aggregation. Give hot launch its own smaller allocation and
-reserve the remainder for the actual verification work. Select
-`generated_case_fanout.target_n` for the application and set an explicit
-`hard_max_n` no greater than 64; do not hardcode one universal fanout.
-
-Model cold preparation as a stable-ID DAG that Haystack runs before a
-verification request. You describe it; you never execute any part of it. The
-preparation may seed, quiesce, scrub, and snapshot production-derived state,
-and it yields bounded plan summaries, exact stable source and replica
-identities for alias and isolation validation, and opaque replica catalog
-references for checked-in bindings. Deletion handles and provider operations
-stay with Haystack and never appear in these artifacts.
-Resolve every prepared state's workload profile and compatibility group to
-declared stable-ID records. Bind it to the exact template catalog reference and
-resource size, durable snapshot, production cut, and artifact and config
-digests. Require its evidence to name the prepared-state ID explicitly. Add a
-refresh strategy, maximum age, and freshness evidence so a stale prepared state
-cannot silently enter the hot path.
-
-Model hot launch as a second stable-ID DAG that consumes an exact prepared
-state through short-lived replica-only leases. Reopen it once with production
-egress denied, inject the arbitrary verification commit with the
-production-equivalent recipe, then create one fresh writable universe for each
-pertinent generated case. Key every run by the exact `generatedCaseId`,
-`sandboxId`, and `universeIncarnationId`. Fork, attach, and execute the bounded
-N cases in parallel. On any partial failure, release every attempted attachment
-before revoking every attempted lease, under one absolute deadline.
-
-Record integer typical and high planning durations per step. Compute each
-phase's planning path by summing serial dependencies and taking the longest
-parallel path. Never label either result as a true expected makespan, observed
-p95, or statistical p95 bound. Only declare `hot-path-proven` when an
-authoritative, scope-compatible, typed probe record links the measured
-end-to-end hot p95, achieved generated-case fanout, exact case/sandbox/universe
-identity triples, exercised verification commit, fresh-universe isolation,
-parallel phases, parent protection, and complete ordered cleanup.
-Real-production readiness requires hosted-production probe evidence;
-repository-local or synthetic evidence cannot qualify it.
-
-Before declaring `hot-path-proven`, take the exact-ID union of every cold and
-hot step's `subject_ids`. It must cover every mapped artifact, runtime role,
-resource, and external dependency. Every artifact must have a proven
-verification-commit route, and every resource or external dependency must use a
-concrete replication, rebuild, or emulation strategy; physical copy strategies
-must also resolve their opaque binding. A measured partial launch is not a
-proof of the mapped universe. Do not apply this coverage gate to `proposal`:
-inventory review may pass while materialization readiness remains a proposal.
-
-Use `proposal`, `cold-preparable`, `hot-path-proven`, or `blocked` independently
-of inventory review status. A review may pass while launch readiness remains a
-proposal. Mark capability evidence `declared`, `adapter-verified`, or
-`materialization-probed`, and latency `assumed` or `measured`. Synthetic
-qualification uses synthetic scope and never proves real-production readiness.
-
-### 6. Continue with the full production review after authority is confirmed
-
-Never enter this phase for a provisional authority receipt. This is distinct
-from the repository-only closure audit, which runs before this gate whenever
-closure would otherwise be complete.
-
-Use the customer's coding CLI subagent mechanism. Do not use a Haystack-side
-review agent, simulate the review, or allow descendants. If no real subagent
-exists, write a blocked receipt with `reviewer-subagent-unavailable`.
-
-Create one durable, resumable reviewer session and reuse it for all phases.
-Record its session ID in private scratch. Forbid ephemeral mode, including CLI
-flags such as `--ephemeral`. If the CLI cannot resume it, stop with
-`reviewer-session-not-resumable`; do not create a replacement.
-
-Use read-only permissions. Enforce the test and `.haystack/**` denylist before
-launch. Hide the candidate, scratch path, and prior conclusions during blind
-inventory. Instruct the reviewer to make no edits, commits, network writes, or
-infrastructure changes. If the CLI reports a quota, usage, or context limit,
-preserve completed checkpoints, set `reviewer-quota-exhausted`, and stop. Do
-not replace the reviewer.
-
-Use this task:
-
-```text
-Independently inventory this repository for the production behavior needed by
-a production-derived isolated universe for one selected hosted-production
-application. Your source view mechanically excludes .haystack/** and the
-declared test-path denylist; do not bypass it. Cite exact evidence. Do not
-substitute self-host, hobby, local/dev, or example topology for production.
-Check source-commit incorporation separately from production build-recipe
-equivalence. Preserve structured resource identities and classify state.
-
-Omission is not the cure for padding. An in-tree integration that a
-configuration switch, feature flag, or provider module can turn on is a type of
-thing Haystack may have to reproduce, so record it once with
-`activation: optional` and say what selects it. Dropping it because it is not
-active in the profile you selected is a recall failure, not restraint. Suppress
-duplication by exact structured identity instead: retain separately keyed
-logical state owners even when they share one physical binding and reproduction
-action, and collapse only proven aliases of the same logical identity. Do not
-promote generic roots, loaders, selector values, or physical plumbing into
-inventory merely because they configure or contain a real resource.
-
-Challenge every positive consumer edge at the exact runtime-role call path;
-shared packaging is not reachability. Challenge every registry category link
-and leaf from the implementation body, not from the installer, manifest, or
-registration table. A profile or default that leaves a supported provider
-inactive makes it optional inventory; it does not justify excluding the
-registry candidate.
-
-Audit these seven failure classes explicitly:
-
-1. optional or default backends selected without authoritative runtime evidence;
-2. one physical resource split, or distinct resources merged, without exact structured identity;
-3. missing consumers, dependency edges, consistency groups, or clone material;
-4. raw-TCP, fork, multi-endpoint, protocol, or readiness claims without direct evidence;
-5. external dependencies asserted from weak, broad-token, or empty evidence;
-6. semantic labels used where repository-qualified structured source IDs are required; and
-7. omitted blockers for the full under-one-minute result target, mutable images,
-   DNS/TLS, privileged surfaces, or build-time/runtime-generated configuration.
-
-Then perform three closure challenges: independently running supervisors and
-support processes hidden inside one service or image; embedded or alternate
-state engines hidden by a broad volume or provider abstraction; and dependency
-direction, including inbound clients and work delegated to a separate actor.
-For activation, distinguish invoking a fixed default-on path from first
-supplying tenant state or a destination. The former is reachable default
-behavior; the latter is an optional gate.
-
-Independently rebuild four exact-ID frontiers before comparing the candidate:
-all steady-state deployment units (including separately launched databases and
-caches), all state materialization identities (including per-service TLS,
-secret/credential, config-layout, cache/database-namespace, and destination
-objects), all reachable boundary-crossing operation contracts, and all required
-inbound/pull interfaces. Compare those sets one-to-one with the candidate's
-frontier receipts. Treat reachable provider/interface methods as operations,
-not registry families. Accept a registry only when a concrete lookup, switch,
-registration, entrypoint, or configuration dispatch selects implementations.
-
-For each retained material identity, reopen the cited exact snippet or line
-span and verify every declared `supporting_tokens` value occurs inside it.
-Reject adjacent comments, shebangs, imports, declarations, and closing braces
-that merely sit near the real operation.
-
-Independently census exact source-owned selector families—command dispatch,
-factories, schemas, lifecycle pipelines, behavior enums, allow-lists, and
-dynamic module tables—and compare that census to the emitted registry IDs.
-Reject wildcard or family placeholders as enumeration.
-
-Block every unsupported claim. Preserve one stable blind observation ID and one
-exact structured source identity for every join; never correlate by prose.
-
-Use 24 repository-inspection tool calls and 4 elapsed minutes as the first blind
-inventory wave: 6 for deployment/artifacts, 10 for runtime/state/dependency
-edges, 4 for interfaces/egress, and 4 for gap checks. Do not spawn subagents. At
-the end of each bucket, immediately return one compact checkpoint with the
-bucket, stable observation IDs, subject IDs, assertions, source anchors,
-uncovered scope, calls used, and elapsed time. Label observations
-blind_observations; the candidate is hidden, so do not make comparison findings.
-If an exact frontier remains open, persist the checkpoint and continue in
-24-call waves. Finish only after two consecutive source-wide blind sweeps add no
-new exact identity. Keep each checkpoint under 24 KiB; if it does not fit, split
-the stable-ID-sorted observations across checkpoints instead of dropping them.
-```
-
-The reported call usage includes shell, search, read, and repository-inspection
-calls, even when no evidence is found. The CLI must enforce the selected wave
-limit and elapsed backstop; a prompt is not a timer. Append each checkpoint to
-scratch before sending the next bucket. Do not wait for one large answer or
-request a long no-tools synthesis pass.
-
-### 7. Compare compact projections and reconcile once
-
-Always compare after blind checkpoints. Do not send full candidate YAML. Build
-a compact projection grouped by the same four buckets. Include only stable IDs,
-kinds, structured identities, edges, state classes and actions, reproduction and physical
-binding claims, evidence IDs with source anchors, scope/authority claims, and
-unresolved IDs. Send one bucket at a time to the same reviewer and capture a
-compact semantic delta before sending the next. Keep projections and deltas in
-private scratch; final output remains exactly four artifacts for a complete
-map. A deliberately blocked provisional scaffold may retain its existing
-three-file missing-authority receipt until repository behavior synthesis runs.
-
-Keep each projection and delta under 24 KiB. If a bucket does not fit, split it
-into stable-ID-sorted chunks while staying inside the same aggregate time and
-call budget. Never send the full YAML as a fallback.
-
-Allow 10 targeted repository-inspection calls and 2 elapsed minutes total for
-comparison. Require separately labeled `comparison_findings` for omitted or
-phantom objects and edges; missing consistency groups; promoted non-production
-or optional topology; missing authority or overstated fidelity; commit or
-recipe gaps; collapsed identities; unbounded integrations; and weak,
-conflicting, stale, or unstable evidence. Also require findings for every one of
-the seven explicit failure classes from the blind inventory task. An unsupported
-transport, provider fork, external dependency, or readiness claim is blocking;
-the reviewer must not rewrite it into a plausible implementation.
-
-Reconcile every finding by stable ID as `accepted`, `rejected` with stronger
-evidence, or `unresolved`. Partial blind coverage can still reveal candidate
-defects; retain its gaps.
-
-Send one compact material-revision delta back to the reviewer. Allow 4 targeted
-inspection calls and 1 elapsed minute. Then request one final structured
-receipt with tools disabled, based only on captured checkpoints, comparison
-deltas, and the revision delta. Use the lowest reasoning setting supported for
-this formatting-only receipt and allow at most one minute. Never loop.
-
-If a phase exceeds budget, retain partial work, set
-`termination.reason: review-budget-exhausted`, and block on material uncovered
-scope. Keep `blind_observations` separate from `comparison_findings`.
-
-### 8. Write and validate artifacts
-
-Copy the reconciled artifacts from scratch to the repository. Run:
-
-```bash
-haystack skills validate-universe --json
-haystack skills validate-behaviors --json
-```
-
-This uses a YAML parser and checks stable IDs, references, and required semantic
-claims. A visual read or regex is not a substitute. Fix every error and rerun
-until it exits zero. Every receipt, including a deferred provisional receipt,
-records `validation.command: haystack skills validate-universe --json`,
-`validation.status: passed`, and a `validator_contract_revision` matching the
-JSON result; a missing, failed, or stale tuple is not a valid receipt. Preserve
-scratch on failure. A zero exit proves contract consistency, not inventory
-completeness or isolation.
-
-Before reporting completion, check that:
-
-- no final inventory or registry entry has `trace_status: census-only`;
-- every runtime role is one independently restartable deployment unit, with no
-  setup/init/start padding, a unique `deployment_unit_identity_key`, and exact
-  independently controlling deployment token;
-- every resource is an allowed independent state unit, with exact owner, root,
-  address, typed reproduction operation, and distinct reproduction token, and no database-internal or configuration-
-  input padding;
-- every external dependency is one exact outside-universe operation or listener
-  contract traced from a concrete production call site through every wrapper to
-  the leaf effect, with provider variants, internal role calls, routes, generic
-  helper definitions, and protocol variants merged or excluded;
-- every registry has a concrete decision-bearing gate, distinct exact selector
-  and implementation tokens, selective dispatch, a production consumer,
-  complete category links, and every proven nested edge; enum/interface/route,
-  exhaustive pipeline, and generated-table-only collections are excluded;
-- all IDs and references are exact and evidence-backed;
-- structured roles, profiles, databases, buckets, topics, queues, and keyspaces
-  remain distinct;
-- each artifact separately proves source incorporation and production-recipe
-  equivalence, or a valid pinned-infrastructure exemption;
-- provider forks and restores reference an opaque catalog binding plus
-  replication capability evidence, never a raw provider ID;
-- the cold and hot DAGs are acyclic, their planning paths are reproducible, and
-  prepared-state identity and freshness are explicit;
-- any `hot-path-proven` DAG covers every mapped artifact, runtime role,
-  resource, and external dependency by exact `subject_ids`, with no unresolved
-  reproduction route;
-- any `hot-path-proven` claim has measured end-to-end hot p95 and fanout proof
-  within its hot-launch allocation;
-- every resource has one state classification;
-- no production role, credential, deletion handle, raw provider ID, direct
-  endpoint, or secret value appears in a checked-in artifact;
-- every finding is resolved or blocking; and
-- review is `pass` only after independent review with no blocker.
-
-Summarize scope, fidelity, reviewer corrections, uncovered scope, and only the
-irreducible user question. Do not claim readiness until Haystack materializes
-the universe and proves isolation.