@haystackeditor/cli 0.25.1 → 0.26.0

package/dist/assets/skills/map-cloud-verifier-universe/references/output-contract.md

@@ -1,3411 +0,0 @@
-# Cloud Verifier universe output contract
-
-Use this contract for the four files under `.haystack/cloud-verifier/`. Keep
-records small and evidence-backed. Never store credentials, raw provider
-resource IDs, ARNs, connection strings, or secret values.
-
-The agent reads the repository and nothing else. Haystack builds and operates
-the replicas, under access the customer grants it directly, and that access is
-never routed through this skill. Production IAM roles, provider credentials,
-deletion handles, production mutation APIs, and direct control-plane
-connectivity are never requested here and never recorded here.
-
-Haystack's own drivers use raw provider IDs internally, and the bounded
-`CustomerReplicaPlan` and `GoldenReplicaDescriptor` protocol may carry exact
-stable source and replica identities for alias and isolation validation. Those
-are transient protocol data. Checked-in artifacts use opaque catalog handles and
-never contain raw provider IDs or production endpoints. Later verifier execution
-receives replica identities and short-lived replica-only lease references.
-
-This document describes validator contract revision `39`. Each artifact is
-limited to 33554432 UTF-8 bytes. YAML aliases are bounded, and documents deeper
-than 64 collection levels, containing more than 500000 parsed nodes, or
-forming an alias cycle are invalid.
-
-## Contents
-
-- [Stable identity and updates](#stable-identity-and-updates)
-- [Authority boundary](#authority-boundary)
-- [`universe.yml`](#universeyml)
-- [`behaviors.yml`](#behaviorsyml)
-- [Scope and production authority](#scope-and-production-authority)
-- [Artifacts and exact source](#artifacts-and-exact-source)
-- [Prepared state and hot launch](#prepared-state-and-hot-launch)
-- [Resources and reproduction](#resources-and-reproduction)
-- [`evidence.yml`](#evidenceyml)
-- [`review.yml`](#reviewyml)
-
-## Stable identity and updates
-
-- Use lowercase kebab-case IDs unique within the application.
-- Preserve an ID when the same logical object evolves.
-- Link records only by exact ID. Never join or deduplicate by free text.
-- Preserve roles, deployment profiles, logical databases, buckets, topics,
-  streams, queues, consumer groups, and keyspaces as structured identities.
-- Merge records only when authoritative evidence proves the same structured
-  logical identity. Physical co-location is not a logical join.
-- Preserve separately keyed logical databases, schemas, queues, streams,
-  buckets, namespaces, installed material, generated outputs, and persisted
-  identities as separate resources. They may share a `physical_binding_id`,
-  `state_policy.action`, consistency group, and one materialization action
-  without being collapsed. Do not separately record unaddressed physical
-  children, state the process recreates at boot, scratch or temporary children,
-  write buffers, or immutable bytes already carried by an artifact.
-- Give evidence, missing sources, blockers, and reviewer findings stable IDs.
-
-Record the mapping baseline in `map_revision`. On an update, inspect the source
-diff from the prior commit plus reverse dependencies and any evidence whose
-anchor changed. Preserve stable IDs. Remove or tombstone an object only with
-evidence that it is no longer active. Have the reviewer inspect the changed
-scope blindly before seeing the semantic delta. Fall back to a full bounded
-scan when deployment roots, service catalogs, application scope, or topology
-sources changed. This is the required update protocol; it is not a claim that
-update determinism has already been validated.
-
-`map_revision.mode` is exactly one of two values:
-
-- `full-scan` — the whole bounded scan ran, either for a first map or because one
-  of the four fallback triggers above fired.
-- `incremental` — only the source diff, its reverse dependencies, and evidence
-  whose anchors changed were inspected. This is the value for a routine update,
-  including a re-check at an unchanged commit.
-
-`changed_scope_ids` is the set of **mapped stable IDs whose source scope the diff
-touched** — that is, the scope handed to the reviewer for blind re-inspection. It
-is not the set of records whose field values ended up changing. A commit that
-touches a service's source but leaves the universe semantically identical still
-lists that service's ID here; the correct outcome in that case is a populated
-`changed_scope_ids` with no added, removed, or modified objects. When the diff is
-empty, `changed_scope_ids` is `[]`.
-
-`previous_source_commit` is the `source_commit` of the map being updated. It is
-`null` only on a first map. When a re-check runs at an unchanged commit, it equals
-`source_commit`.
-
-Reading the three prior artifacts under `.haystack/cloud-verifier/` is required to
-perform an update and is exempt from the `.haystack` inspection denylist below.
-That denylist governs discovery of the application and the reviewer's source view;
-it never blocks the primary agent from loading the map it is updating.
-
-## Authority boundary
-
-The minimum customer selection is a stable application ID, stable environment
-ID, and a replica destination policy or approval. The customer supplies that
-selection locally. The destination's provider
-account identity and production-native topology stay on the customer side; the
-artifact records only an opaque approval reference and approved bounds.
-
-Haystack resolves a bounded logical topology and plan summary: resource
-kinds, opaque catalog handles, dependency edges, artifact/config catalog refs,
-secret-reference names, external-integration kinds, replica strategies, and
-capability/consistency/freshness/latency/cost bounds. A `runtime_role_id` in
-this contract is a logical application behavior role, never an IAM role.
-
-The current protocol also carries exact stable `sourceResourceId` values in a
-`CustomerReplicaPlan` and exact stable source/replica identity pairs in a
-`GoldenReplicaDescriptor`. Haystack may compare those bounded identities to
-detect source/replica aliasing, cross-plan mismatches, or broken isolation. They
-are not credentials, deletion handles, or production mutation authority, and
-they must not be copied into checked-in universe, evidence, or review artifacts
-as raw provider IDs. Use customer-issued opaque catalog handles in artifacts.
-
-Do not query cloud-provider discovery APIs or production endpoints from the
-coding CLI, Haystack control plane, reviewer, or sandbox. Provider IDs may be
-used inside Haystack's discovery/materialization drivers and may cross the
-bounded plan/descriptor protocol only for the validation above. Translate them
-to opaque catalog handles before the checked-in artifact boundary.
-
-## `universe.yml`
-
-```yaml
-version: 1
-map_revision:
-  source_commit: 0123456789abcdef0123456789abcdef01234567
-  previous_source_commit: null
-  mode: full-scan
-  changed_scope_ids: []
-application:
-  id: commerce-platform
-  requested_scope: production-checkout
-  selected_production_scope: hosted-checkout
-  scope_status: confirmed
-  evaluation_mode: real-production
-
-production_basis:
-  repository_proven_topology:
-    environment_scope: hosted-production
-    fidelity_ceiling: exact-production-deployment
-    evidence_ids: [ev-prod-checkout-deploy]
-  authoritative_sources:
-    - id: source-prod-deployment
-      kind: kubernetes-service-catalog
-      availability: present
-      environment_scope: hosted-production
-      authority_class: live-production-control-plane
-      evidence_ids: [ev-prod-checkout-deploy]
-  missing_authoritative_sources: []
-  access_request: null
-  alternate_topologies:
-    - id: self-host-demo
-      environment_scope: self-host-reference
-      selected: false
-      evidence_ids: [ev-self-host-compose]
-
-deployment_profiles:
-  - id: prod-checkout
-    environment_scope: hosted-production
-    activation: active
-    evidence_ids: [ev-prod-checkout-deploy]
-
-artifacts:
-  - id: checkout-image
-    kind: container
-    verification_subject: source-changeable
-    used_by_runtime_role_ids: [checkout-http-role]
-    definition_evidence_id: ev-checkout-dockerfile
-    verification_commit:
-      status: proven
-      source_incorporation:
-        status: proven
-        mechanism: built-from-verification-commit
-        evidence_ids: [ev-checkout-image-ci]
-      production_recipe_equivalence:
-        status: proven
-        evidence_ids: [ev-checkout-image-ci, ev-prod-checkout-deploy]
-
-services:
-  - id: checkout-api
-    source_root: apps/checkout
-    runtime_roles:
-      - id: checkout-http-role
-        kind: http-server
-        structured_identity:
-          entrypoint: checkout-server
-          mode: http
-          deployment_unit_identity_key: deployment/checkout-api
-          deployment_control_kind: orchestrator-workload
-          deployment_control_token: Deployment/checkout-api
-        deployment_profile_ids: [prod-checkout]
-        artifact_id: checkout-image
-        entrypoint_evidence_id: ev-checkout-entrypoint
-    config_names: [DATABASE_URL, EVENTS_URL, FLAGS_SDK_KEY]
-    interfaces: [checkout-http, order-events-consumer]
-    depends_on: [orders-db, order-events, feature-flags, payments-api]
-    evidence_ids: [ev-prod-checkout-deploy, ev-checkout-clients]
-
-interfaces:
-  - id: checkout-http
-    runtime_role_id: checkout-http-role
-    kind: http
-    locator_evidence_id: ev-checkout-routes
-  - id: order-events-consumer
-    runtime_role_id: checkout-http-role
-    kind: event-consumer
-    structured_identity:
-      topic: order-events-v2
-      consumer_group: checkout-materializer
-    locator_evidence_id: ev-order-topic
-
-physical_bindings:
-  - id: binding-orders-postgres
-    status: resolved
-    stable_resource_ref: binding-catalog/orders-primary
-    evidence_ids: [ev-orders-prod-binding]
-  - id: binding-order-events
-    status: proven
-    stable_resource_ref: binding-catalog/order-events-v2
-    evidence_ids: [ev-events-prod-binding]
-
-resources:
-  - id: orders-db
-    kind: postgres
-    activation: active
-    activation_basis:
-      kind: selected-profile-required
-      evidence_ids: [ev-prod-checkout-deploy]
-    state_classification: canonical-durable
-    state_owner:
-      basis: application-persistence-boundary
-      evidence_ids: [ev-orders-state-owner]
-    state_policy:
-      action: copy
-    runtime_role_ids: [checkout-http-role]
-    consumer_edges:
-      - runtime_role_id: checkout-http-role
-        activation: active
-        activation_basis:
-          kind: selected-profile-required
-          evidence_ids: [ev-orders-db-consumer]
-    binding_names: [DATABASE_URL]
-    structured_identity:
-      role: transactional-orders
-      logical_database: orders
-      deployment_profile_ids: [prod-checkout]
-      source_owner_identity_key: createOrdersDatabase
-      materialization_root_identity_key: DATABASE_URL
-      state_unit_kind: logical-database
-      address_token: orders
-      reproduction_token: forkOrdersDatabase
-      reproduction_operation_kind: copy
-      key_components: [DATABASE_URL]
-    physical_binding_id: binding-orders-postgres
-    reproduction:
-      source: production-derived
-      strategy: provider-native-fork
-      capability_evidence_ids: [ev-orders-fork-capability]
-      writable: true
-      consistency_group_id: order-state
-    evidence_ids: [ev-orders-db-client, ev-orders-db-iac]
-  - id: order-events
-    kind: event-stream
-    activation: active
-    activation_basis:
-      kind: selected-profile-required
-      evidence_ids: [ev-prod-checkout-deploy]
-    state_classification: in-flight-work
-    state_owner:
-      basis: repository-declared-mutable-state
-      evidence_ids: [ev-order-events-state-owner]
-    state_policy:
-      action: preserve
-      rationale: Preserve accepted events not yet applied to canonical orders state.
-    runtime_role_ids: [checkout-http-role]
-    consumer_edges:
-      - runtime_role_id: checkout-http-role
-        activation: active
-        activation_basis:
-          kind: selected-profile-required
-          evidence_ids: [ev-order-events-consumer]
-    binding_names: [EVENTS_URL]
-    structured_identity:
-      role: order-event-log
-      topic: order-events-v2
-      deployment_profile_ids: [prod-checkout]
-      source_owner_identity_key: publishOrderEvent
-      materialization_root_identity_key: ORDER_EVENTS_TOPIC
-      state_unit_kind: queue-or-stream
-      address_token: order-events-v2
-      reproduction_token: restoreOrderEventsSnapshot
-      reproduction_operation_kind: restore
-      key_components: [ORDER_EVENTS_TOPIC, order-id]
-    physical_binding_id: binding-order-events
-    reproduction:
-      source: production-derived
-      strategy: snapshot-restore
-      capability_evidence_ids: [ev-events-snapshot-capability]
-      writable: true
-      consistency_group_id: order-state
-    evidence_ids: [ev-order-topic, ev-events-iac]
-
-external_dependencies:
-  - id: payments-api
-    kind: third-party-api
-    structured_identity:
-      operation: authorize-payment
-      operation_identity_key: apps/checkout/payments.ts#authorizePayment
-      operation_token: authorizePayment
-      boundary_contract_kind: outbound-operation-family
-      interaction_direction: outbound
-      source_owner_identity_key: submitPayment
-      boundary_trace:
-        kind: direct
-        callsite_identity_key: apps/checkout/payments.ts#authorizePayment
-        callsite_token: authorizePayment
-        boundary_token: authorizePayment
-      key_components: [payments-client, authorize-payment]
-    runtime_role_ids: [checkout-http-role]
-    consumer_edges:
-      - runtime_role_id: checkout-http-role
-        activation: active
-        activation_basis:
-          kind: default-request-path
-          evidence_ids: [ev-payments-consumer]
-    activation: active
-    activation_basis:
-      kind: default-request-path
-      evidence_ids: [ev-payments-prod-config]
-    backing_state:
-      disposition: none
-      basis: interaction-only
-      operation: stateless-exchange
-      evidence_ids: [ev-payments-boundary]
-    reproduction:
-      source: production-derived-interactions
-      strategy: capture-replay
-      capability_evidence_ids: [ev-payments-replay-capability]
-      live_egress: forbidden
-    evidence_ids: [ev-payments-client]
-
-consistency_groups:
-  - id: order-state
-    members: [orders-db, order-events]
-    requirement: same-production-cut
-    evidence_ids: [ev-order-dual-write]
-
-unresolved: []
-
-materialization_plan:
-  # This is the full verifier result SLO, including generated case execution.
-  verifier_total_slo_ms: 60000
-  # This strictly smaller allocation is only for the warm hot-launch path.
-  target_slo_ms: 7000
-  reserved_case_work_ms: 53000
-  generated_case_fanout:
-    target_n: 8
-    hard_max_n: 16
-    required_identity_fields: [generated_case_id, sandbox_id, universe_incarnation_id]
-    parallel_phases: [fork, attach, execute]
-    cleanup_order: [release-all-attachments, revoke-all-leases]
-    cleanup_covers_all_attempts_on_partial_failure: true
-    single_absolute_deadline: true
-  workload_profiles:
-    - id: cloud-verifier-standard-v1
-      template_catalog_ref: template-catalog/cloud-verifier-standard-v1@sha256:1111111111111111111111111111111111111111111111111111111111111111
-      resource_size: e2b-standard
-  compatibility_groups:
-    - id: checkout-prod-v3
-      member_subject_ids: [checkout-image, orders-db, order-events, payments-api]
-  prepared_states:
-    - id: prepared-checkout-source
-      exact_identity:
-        workload_profile_id: cloud-verifier-standard-v1
-        template_catalog_ref: template-catalog/cloud-verifier-standard-v1@sha256:1111111111111111111111111111111111111111111111111111111111111111
-        resource_size: e2b-standard
-        durable_snapshot_ref: prepared-state-catalog/checkout@sha256:2222222222222222222222222222222222222222222222222222222222222222
-        compatibility_group_id: checkout-prod-v3
-        source_cut_ref: production-cut-catalog/checkout-state-2026-08-01
-        artifact_digest_refs: [artifact-catalog/checkout@sha256:3333333333333333333333333333333333333333333333333333333333333333]
-        config_digest_refs: [config-catalog/checkout@sha256:4444444444444444444444444444444444444444444444444444444444444444]
-      evidence_ids: [ev-prepared-checkout-source]
-  cold_preparation:
-    steps:
-      - id: cold-prepare-checkout-state
-        kind: restore-seed-capture-quiesce-and-snapshot
-        subject_ids: [orders-db, order-events, payments-api]
-        capability_evidence_ids: [ev-cold-prepare-checkout]
-        depends_on_step_ids: []
-        produces_prepared_state_ids: [prepared-checkout-source]
-        latency_basis: measured
-        planned_typical_ms: 900000
-        planned_high_ms: 2400000
-    refresh:
-      strategy: on-source-cut-change
-      max_age_seconds: 300
-      freshness_evidence_ids: [ev-checkout-refresh-policy]
-    planned_typical_critical_path_ms: 900000
-    planned_high_critical_path_ms: 2400000
-  hot_launch:
-    consumes_prepared_state_ids: [prepared-checkout-source]
-    steps:
-      - id: hot-fork-checkout-wave
-        kind: parallel-generated-case-universe-fork-wave
-        subject_ids: [prepared-checkout-source]
-        capability_evidence_ids: [ev-hot-fork-checkout-wave]
-        depends_on_step_ids: []
-        latency_basis: measured
-        planned_typical_ms: 987
-        planned_high_ms: 1200
-      - id: hot-inject-checkout-commit
-        kind: inject-arbitrary-verification-commit
-        subject_ids: [checkout-image]
-        capability_evidence_ids: [ev-hot-inject-checkout-commit]
-        depends_on_step_ids: [hot-fork-checkout-wave]
-        latency_basis: measured
-        planned_typical_ms: 1000
-        planned_high_ms: 1500
-      - id: hot-start-checkout
-        kind: start-and-probe-readiness
-        subject_ids: [checkout-http-role]
-        capability_evidence_ids: [ev-hot-start-checkout]
-        depends_on_step_ids: [hot-inject-checkout-commit]
-        latency_basis: measured
-        planned_typical_ms: 2000
-        planned_high_ms: 3000
-    arbitrary_verification_commit_injection:
-      supported: true
-      step_id: hot-inject-checkout-commit
-      production_recipe_equivalence_evidence_ids: [ev-checkout-image-ci]
-    fresh_universe_per_generated_case:
-      enforced: true
-      step_id: hot-fork-checkout-wave
-      parent_write_protected: true
-    achieved_generated_case_fanout: 8
-    latency_basis: measured
-    planned_typical_critical_path_ms: 3987
-    planned_high_critical_path_ms: 5700
-    observed_end_to_end_p95_ms: 5000
-    probe_evidence_ids: [ev-hot-checkout-path-probe]
-  readiness:
-    status: hot-path-proven
-    scope: real-production
-```
-
-Every final runtime role, resource, and external dependency has a nonempty
-operational `kind` and a proof-complete identity tuple. Final arrays never use `trace_status: census-only`.
-Downstream activation, role reachability,
-backing-state, or materialization uncertainty remains explicit and keeps
-closure partial, but does not withhold an exact identity. The identity retains exact deployment unit, logical
-state key, object, operation, or interaction keys rather than a prose family
-label. Each runtime role has a unique `deployment_unit_identity_key`, an allowed
-`deployment_control_kind`, and an exact `deployment_control_token` naming the
-orchestration or host controller that independently restarts it. A thread,
-forked child, generic process, or container inside another deployment unit is
-not a role merely because it can fail or restart internally. Allowed controls
-also include `operator-launched-longrun` for an exact packaged command that
-stays alive for an operator/user session, and
-`application-supervised-process` for a child with an exact independent
-spawn/stop/restart handle. Each
-external dependency additionally sets `interaction_direction` to `outbound`,
-`inbound-required`, `bidirectional`, or `host-mediated`.
-
-Every full resource identity also repeats the logical census row's exact
-`source_owner_identity_key`, `materialization_root_identity_key`, and nonempty
-unique `key_components`; it adds an allowed `state_unit_kind`, exact unique
-`address_token`, exact `reproduction_token`, and an allowed
-`reproduction_operation_kind`. The reproduction token differs from the address
-and materialization-root tokens and names a real independent copy, restore,
-rebuild, reset, preserve, provision, mount, install, write, initialize, build,
-embed, generate, migrate, or pin operation. An exact application write such as a named `setItem`, `WriteFile`, or
-object `Put`, or an exact generate/build/embed/install/migrate operation, proves
-the logical state identity it creates. Cross-environment restore readiness is a
-separate materialization claim. A mount proves parent capacity only: it cannot
-make a parent `canonical-durable` resource unless source proves independently
-preserved content belonging to that parent itself.
-These tokens are never
-placeholders. A final row may use `reproduction.strategy: unresolved` only
-while the matching category remains partial and names that exact frontier; it
-can never support complete closure. Atomic
-state-owner evidence supports all four owner/root/address/reproduction tokens.
-Every full external
-identity records an exact unique `operation_identity_key`, exact source owner,
-exact effectful-call or listener `operation_token`, allowed
-`boundary_contract_kind`, direction, and
-nonempty unique `key_components`. It also records `boundary_trace` as `direct`
-or `wrapper-resolved`, with a concrete application `callsite_identity_key`,
-exact callsite and boundary tokens, and every wrapper token for a resolved
-chain. Generic helper definitions are discovery surfaces, not final operation
-identities. Family labels, client names, providers, and
-transport names alone are not stable operation or destination schemas. A
-constructor, factory, configuration setter, wrapper, or flow label is not an
-effectful operation token.
-
-Runtime roles are resolved by independently restartable deployment unit, not
-merely binary, command, container, or artifact. Independently deployed
-long-running server, worker, scheduler, consumer, maintenance, watch, scheduled,
-injected, sidecar, and host-managed units remain separate roles even when they
-share an executable. Setup, init, migration, configuration, and start commands
-that prepare the same unit are not extra roles.
-A separately launched database, cache, broker, or search process is also a
-runtime role for its exact launch unit and remains a separate stateful resource
-for its reproduced state. A shipped browser application is a
-`host-managed-unit` when source proves its exact document/build entrypoint and
-production serving or packaging path. A missing compiled bundle in retained
-source does not erase that browser-host lifecycle boundary.
-
-Exact HTTP/RPC/socket calls between mapped runtime roles remain operational
-dependencies with `boundary_contract_kind: mapped-role-operation`; their
-placement affects later routing but not their source operation identity. For
-inbound services, retain both the listener and one
-`required-inbound-operation` per exact method/message plus route, topic,
-command, or protocol operation. Merge only exact aliases of the same structured
-operation.
-
-### Scope and production authority
-
-`application.scope_status` is `confirmed` or `provisional`. It is `confirmed`
-only when an authoritative source controls or resolves the selected live
-production scope. A confirmed map has a nonempty
-`selected_production_scope`; a provisional map keeps that field exactly `null`
-and must be blocked. Every authoritative source has nonempty `kind`,
-`availability: present`, a recognized `environment_scope`, one of the declared
-`authority_class` values, and nonempty `evidence_ids`. The
-`repository_proven_topology` mapping is always present with recognized
-environment and fidelity values plus nonempty evidence.
-
-For this contract, live authority is a bounded attestation Haystack obtains
-under access the customer grants it directly. The
-`live-production-control-plane` authority class does not authorize the agent to
-hold a production role, call that control plane, or receive its raw resource
-identities.
-
-`application.evaluation_mode` is `real-production` or `synthetic`. A confirmed
-real-production map requires an authoritative source with
-`authority_class: live-production-control-plane`. A confirmed synthetic map
-requires `authority_class: user-authorized-synthetic-evaluation` and uses
-`materialization_plan.readiness.scope: synthetic-evaluation`. Synthetic
-authority and measurements cannot establish a real-production scope or
-readiness claim.
-
-Use these `environment_scope` values:
-
-- `hosted-production`
-- `production-reference`
-- `self-host-reference`
-- `local-development`
-- `example`
-- `unknown`
-
-Use a `fidelity_ceiling` no higher than the best authority:
-
-- `exact-production-deployment`
-- `production-reference-only`
-- `self-host-reference-only`
-- `local-development-only`
-- `unknown`
-
-Authority has two independent axes, and a map records them separately.
-
-*Scope authority* answers "which live deployment is this?". Without it the map is
-`provisional` and takes the compact receipt below.
-
-*Inventory authority* answers "what is in it?". A deployment catalog often resolves
-the hosted scope and approves a destination while declining to enumerate
-resources, edges, config refs or integrations, because their deployment tooling
-has no resource inventory to return. That is an ordinary position, not a failure,
-and it does **not** make the map provisional.
-
-To record it, keep `scope_status: confirmed` and add the withheld groups to
-`missing_authoritative_sources` with `required_for: complete-bounded-inventory`.
-Entries carrying that exact value are inventory-authority gaps and leave the map
-confirmed; any other `required_for` is treated as a scope-authority gap and
-forces the provisional profile. Alongside them, a confirmed map may carry an
-`access_request` naming only the withheld groups — a non-empty subset of the
-seven, rather than all of them.
-
-Resources whose bindings the catalog withheld retain their exact final identity
-with `reproduction.strategy: unresolved`, while state closure remains partial
-and blocks on the missing binding. The map then says the true thing: the scope
-is known, the inventory is partial, and here is exactly what is missing.
-
-If *scope* authority is private or external, keep discovering and still record
-the repository-evidenced inventory; withhold confirmation, not content. Set
-`scope_status: provisional`, leave `selected_production_scope: null`, terminate
-at the `inventory-complete` phase, and emit one precise access request. Reserve
-`phase: authority-gate` and the compact `scaffold-provisional-universe` receipt
-for the case where the repository evidences no topology at all:
-
-```yaml
-application:
-  id: commerce-platform
-  requested_scope: production-checkout
-  selected_production_scope: null
-  scope_status: provisional
-  evaluation_mode: real-production
-production_basis:
-  repository_proven_topology:
-    environment_scope: self-host-reference
-    fidelity_ceiling: self-host-reference-only
-    evidence_ids: [ev-self-host-compose]
-  authoritative_sources: []
-  missing_authoritative_sources:
-    - id: missing-hosted-production-deployment
-      kind: private-deployment-service-catalog
-      required_for: resolve-selected-hosted-scope
-      status: unavailable-in-repository
-      evidence_ids: [ev-hosted-deployment-private]
-  access_request:
-    id: request-hosted-deployment-catalog
-    access: read-only
-    source: haystack-replication-service
-    fields:
-      - selected-application-id-and-environment-id
-      - approved-replica-destination-policy-and-approval-ref
-      - bounded-resource-kinds-opaque-catalog-handles-and-dependency-edges
-      - artifact-runtime-and-non-secret-config-opaque-catalog-refs
-      - external-integration-kinds-and-secret-reference-names
-      - replica-capabilities-strategies-consistency-freshness-latency-and-cost-bounds
-      - replica-only-golden-descriptor-and-lease-reference-contract
-    reason: authorize-replica-plan-summary
-```
-
-The first two groups are selected or approved by the customer in its local CLI.
-The remaining groups are bounded outputs Haystack resolves. They never
-contain production roles, credentials, raw provider IDs,
-direct endpoints, or secret values. The last group requests the schema and
-policy for later replica-only references, not a production credential or a
-lease before materialization. Exact stable source/replica identities that a
-later bounded protocol response uses for alias and isolation validation are
-transient and are not fields in this checked-in access request.
-
-Do not invent a scope such as `hypothetical-hosted-production`. Keep self-host,
-dev, hobby, and example topology compact under `alternate_topologies`.
-
-When authority is missing and the repository evidences no topology at all,
-stop after the authority gate. Defer the repository-only closure audit because
-closure is partial, and do not launch the full production reviewer. Target at
-most 60 seconds to synthesize and validate the three compact artifacts. Write a
-strict JSON input in private scratch and run:
-
-```bash
-haystack skills scaffold-provisional-universe --input <scratch-input.json>
-```
-
-If the repository does evidence topology, continue repository discovery. A
-repository-only closure audit may prepare the isolated snapshot and run without
-production authority; the production reviewer remains deferred. Use the compact
-scaffold only for the truly empty partial receipt.
-
-Use this input shape. All IDs are supplied explicitly; never derive or join them
-from free text. Evidence sources in this authority-gate profile are repository
-paths with structured anchors. Add `budget.overrunBlockerIds` only for the exact
-budget paths that exceeded their limits.
-
-`budget.overrunBlockerIds` is an **object**, not a list. It has exactly two
-optional keys, each holding the stable ID of the `kind: budget-exhausted` blocker
-for that path:
-
-```json
-"overrunBlockerIds": {
-  "primaryDiscovery": "blocker-primary-discovery-budget-exhausted",
-  "authorityGate": "blocker-authority-gate-budget-exhausted"
-}
-```
-
-Include `primaryDiscovery` if and only if `budget.primaryDiscovery` exceeded its
-48-call or 900-second limit, and `authorityGate` if and only if
-`budget.authorityGate` exceeded its 6-call or 60-second limit. Supplying a key for
-a path that stayed within limits is rejected, and so is omitting one for a path
-that did not. Omit the whole object when neither path overran.
-
-```json
-{
-  "sourceCommit": "0123456789abcdef0123456789abcdef01234567",
-  "application": {
-    "id": "commerce-platform",
-    "requestedScope": "production-checkout",
-    "evaluationMode": "real-production"
-  },
-  "repositoryTopology": {
-    "id": "commerce-repository-census",
-    "environmentScope": "production-reference",
-    "fidelityCeiling": "unknown",
-    "evidenceIds": ["ev-topology-presence-census"],
-    "topologyPresenceCensus": {
-      "status": "no-production-capable-topology",
-      "subjectId": "commerce-repository-census",
-      "inspectedSurfaceKinds": [
-        "runtime-entrypoints",
-        "package-workspace-manifests",
-        "container-descriptors",
-        "deployment-descriptors",
-        "structured-capability-indexes"
-      ],
-      "productionCapableSurfaceCount": 0,
-      "evidenceIds": ["ev-topology-presence-census"]
-    }
-  },
-  "missingAuthority": {
-    "id": "missing-hosted-production-deployment",
-    "kind": "haystack-replication-service",
-    "requiredFor": "authorize-bounded-hosted-replica-plan",
-    "status": "unavailable-in-repository",
-    "evidenceIds": ["ev-hosted-deployment-private"]
-  },
-  "accessRequest": {
-    "id": "request-hosted-deployment-catalog",
-    "source": "haystack-replication-service",
-    "reason": "authorize-replica-plan-summary"
-  },
-  "evidence": [
-    {
-      "id": "ev-topology-presence-census",
-      "subjectIds": ["commerce-repository-census"],
-      "assertion": "The required census found no repository-controlled production-capable topology.",
-      "environmentScope": "production-reference",
-      "authority": "indicative",
-      "confidence": "strong",
-      "claimKind": "topology-presence-census",
-      "sources": [
-        {
-          "path": "README.md",
-          "anchor": "bounded-package-scope",
-          "kind": "repository-documentation",
-          "locatorKind": "exact-snippet"
-        }
-      ]
-    },
-    {
-      "id": "ev-hosted-deployment-private",
-      "subjectIds": ["commerce-platform", "missing-hosted-production-deployment"],
-      "assertion": "The hosted deployment authority is external to this repository.",
-      "environmentScope": "hosted-production",
-      "authority": "indicative",
-      "confidence": "strong",
-      "sources": [
-        {
-          "path": ".github/workflows/deploy.yml",
-          "anchor": "jobs.deploy.uses",
-          "kind": "manifest-key",
-          "locatorKind": "manifest-key"
-        }
-      ]
-    }
-  ],
-  "coverage": {
-    "scannedRoots": [".github/workflows", "docs", "packages"],
-    "sourceKinds": ["repository-documentation", "package-workspace-manifests"]
-  },
-  "budget": {
-    "primaryDiscovery": {
-      "repositoryInspectionCallsUsed": 5,
-      "elapsedSeconds": 43
-    },
-    "authorityGate": {
-      "repositoryInspectionCallsUsed": 5,
-      "elapsedSeconds": 43
-    }
-  },
-  "authorityBlocker": {
-    "id": "blocker-hosted-production-authority",
-    "kind": "missing-authoritative-source",
-    "evidenceIds": ["ev-hosted-deployment-private"]
-  }
-}
-```
-
-The command emits exactly the seven fixed read-only access-request field groups
-shown above, required empty inventory lists, exact budget accounting, deferred
-reviewer, SHA-256 artifact digests, and validator revision. It refuses to
-overwrite an existing artifact directory. Use this minimal `review.yml` as the
-rendered profile for the compact `authority-gate` receipt. A map with
-repository-evidenced inventory terminates at `inventory-complete`; it records a
-completed repository-only closure audit if all three categories are complete,
-or the same short deferral when any category remains partial. Neither case
-instantiates the full production reviewer schema. Omit its protocol fields and
-reviewer-phase lists:
-
-```yaml
-version: 1
-inventory_closure_audit:
-  status: deferred
-  reason: inventory-closure-partial
-reviewer:
-  status: deferred
-  reason: production-authority-required
-budget:
-  primary_discovery:
-    call_limit: 48
-    elapsed_limit_seconds: 900
-    repository_inspection_calls_used: 6
-    elapsed_seconds: 48
-    authority_gate:
-      call_limit: 6
-      elapsed_limit_seconds: 60
-      repository_inspection_calls_used: 6
-      elapsed_seconds: 48
-termination:
-  reason: missing-production-authority
-  phase: authority-gate
-validation:
-  command: haystack skills validate-universe --json
-  status: passed
-  validator_contract_revision: 39
-status: blocked
-blocking_items:
-  - id: blocker-hosted-production-authority
-    kind: missing-authoritative-source
-    evidence_ids: [ev-hosted-deployment-private]
-```
-
-The compact receipt defers its repository-only audit because every closure
-category is partial. A repository-evidenced provisional map may instead record
-a completed repository-only audit, and must do so before claiming all three
-categories complete. The only provisional blockers are `missing-authoritative-source` or
-`production-authority-access-required`. If recorded usage exceeds a limit, add
-the required exception as `kind: budget-exhausted` with `budget_path` set to
-`budget.primary_discovery` or
-`budget.primary_discovery.authority_gate`. Never add reviewer availability,
-snapshot, quota, or isolation blockers before production authority is
-available.
-
-### Artifacts and exact source
-
-For source-changeable application artifacts,
-set `verification_subject: source-changeable`.
-`verification_commit.source_incorporation.status` and
-`production_recipe_equivalence.status` are each `proven` or `unproven`.
-Source incorporation needs a commit-specific build, source mount, or immutable
-digest tied to the commit. Recipe equivalence needs evidence that the same
-builder, flags, generated inputs, and packaging path used for production are
-used for verification.
-
-The aggregate `verification_commit.status` is `proven` only when both claims
-are proven. Otherwise use `unproven` or `bypasses-commit` and add a blocker.
-Starting a prebuilt image does not prove either claim.
-
-A fixed infrastructure artifact can use:
-
-```yaml
-verification_subject: pinned-infrastructure
-verification_commit:
-  status: proven
-  source_incorporation:
-    status: not-applicable
-    reason: pinned-infrastructure-artifact
-  production_recipe_equivalence:
-    status: exempt-pinned-infrastructure
-    immutable_artifact_ref: artifact-catalog/postgres-16
-    configuration_source_ref: config-catalog/orders-postgres
-    evidence_ids: [ev-postgres-prod-identity]
-```
-
-The refs are opaque catalog references, not raw provider IDs. The exemption is
-invalid for application code or mutable generated artifacts. The validator
-rejects the exemption unless `verification_subject` is explicitly
-`pinned-infrastructure`.
-
-### Prepared state and hot launch
-
-`materialization_plan` separates slow, ahead-of-time preparation from the warm
-request path. `verifier_total_slo_ms` covers case generation, hot launch,
-execution, and aggregation. `target_slo_ms` is only the hot-launch allocation
-and must be strictly smaller; `reserved_case_work_ms` is their difference.
-`generated_case_fanout.target_n` is selected for this application.
-`hard_max_n` is an explicit bound and cannot exceed the product ceiling of 64.
-
-Cold preparation is run by Haystack. Its
-customer-local provider drivers install production-derived dependencies once,
-seed and quiesce state, remove credentials and egress, and produce a durable
-exact prepared-state identity. Haystack receives the bounded plan summary,
-including the protocol's exact stable source/replica identities for alias and
-isolation validation, and opaque replica catalog refs for checked-in bindings.
-It receives no provider operations, credentials, deletion handles, or direct
-control-plane connectivity.
-The identity resolves a declared `workload_profiles` ID and
-`compatibility_groups` ID, and binds the exact template catalog reference and
-resource size, durable replica snapshot, production cut, artifact digests, and
-config digests. Its evidence must name the prepared-state ID explicitly. Its
-refresh policy states how stale the prepared state may become. Cold work may
-take minutes; it does not consume the on-demand budget when the required fresh
-prepared state already exists.
-
-Hot launch consumes that state through bounded-TTL replica leases and creates
-one fresh writable universe for each pertinent generated case. Lease grants
-contain credential references resolved by the sandbox broker, never credential
-values, and target replica resources only. Every run is keyed by exact
-`generated_case_id`, `sandbox_id`, and `universe_incarnation_id`; each value is
-unique in the wave. Fork, attach, and execute phases run in parallel. On partial
-failure, release all attempted attachments before revoking all attempted leases
-under the same absolute deadline. Record the step that injects an arbitrary
-verification commit using the production-equivalent recipe; a pinned deployed
-image alone is insufficient. Record measured generated-case fanout and
-end-to-end hot p95 independently of the per-step estimates.
-
-Two fields inside `materialization_plan` are required whenever the plan is
-present, including when `readiness` is `blocked`, and are easy to miss because
-they appear only in the fully-proven example above:
-
-- every `cold_preparation.steps[]` entry carries `produces_prepared_state_ids`,
-  naming the prepared states that step yields (`[]` when it yields none); and
-- `hot_launch.achieved_generated_case_fanout` records the measured fanout, or
-  `0` when nothing has been measured yet.
-
-Omit `materialization_plan` entirely rather than inventing values for it.
-
-Current repository truth is limited: the bounded customer-replica protocol,
-binding store, connector lifecycle, sandbox relay, and generated-case
-request/execution contracts exist. The default hosted generated-case path still
-fails closed until reviewed runtime composition and principal-level network
-isolation are production-qualified. The first S3 copy driver is
-SDK-unit-qualified but not live cross-account qualified. The generic
-deny-by-default interaction replica and stateful Stripe PaymentIntent behavior
-emulator exist, but their production-template and control-plane startup wiring
-remains pending. Provider discovery and end-to-end provider materialization
-also remain pending. Do not promote readiness beyond `proposal` or `blocked`
-from these implementation facts alone.
-
-Both phases are stable-ID DAGs. Each step has integer `planned_typical_ms` and
-`planned_high_ms` inputs. Sum each planning input along serial dependencies and
-take the maximum parallel path as `planned_typical_critical_path_ms` and
-`planned_high_critical_path_ms`. These are deterministic planning estimates:
-the first is not a true expected makespan, and the second is not an observed or
-statistical phase p95. Only `hot_launch.observed_end_to_end_p95_ms`, linked to
-authoritative `probe_evidence_ids`, is an observed hot p95.
-
-For `hot-path-proven`, the union of `subject_ids` across every cold and hot step
-must include every mapped artifact, runtime role, resource, and external
-dependency by exact stable ID. Each mapped artifact must have
-`verification_commit.status: proven`. Each resource and external dependency
-must have a concrete reproduction strategy rather than `unresolved`, with the
-strategy-specific capability evidence and, for physical copies, the exact
-resolved opaque binding required by this contract. This is the mechanical form
-of the production-replication gate: a measured partial launch cannot silently
-omit behavior-affecting inventory.
-
-Readiness is independent of inventory review:
-
-- `proposal`: the plan is structurally mapped but capabilities may be declared.
-- `cold-preparable`: cold steps and freshness are adapter-verified.
-- `hot-path-proven`: the hot path is materialization-probed, supports at least
-  `generated_case_fanout.target_n` without exceeding `hard_max_n`, injects an
-  arbitrary verification commit, enforces one fresh writable universe per
-  generated case, and fits `target_slo_ms`. Its typed probe record must link the
-  observed p95, achieved generated-case fanout, exact case/sandbox/incarnation
-  IDs, exercised commit, parallel phases, parent protection, single deadline,
-  and complete ordered cleanup.
-- `blocked`: include a nonempty reason.
-
-The subject-coverage and concrete-route gate applies only to
-`hot-path-proven`. A complete inventory review may still pass while readiness
-is `proposal`; that separation must not be represented as a materialization
-proof.
-
-Use `readiness.scope: synthetic-evaluation` for a synthetic qualification.
-Its probe evidence uses `environment_scope: production-reference`. A
-real-production proof instead requires authoritative `hosted-production` probe
-evidence from a typed Haystack or provider materialization-probe result catalog;
-repository-local or synthetic measurements never qualify.
-
-### Census-only inventory rows
-
-Inventory presence and semantic closure are separate claims. Under a partial
-category, a repository-proven runtime role, stateful resource, or external
-dependency may be retained before activation, consumer, ownership, state, and
-reproduction decisions finish. Use this exact compact shape:
-
-Unresolved discovery observations remain in `evidence.yml`, never in final
-inventory arrays. Retain each exact source surface under
-`coverage.operational_surface_census`, add its stable closure candidate, keep
-the category partial, and name it in `uncovered` and a blocker. For example:
-
-```yaml
-coverage:
-  operational_surface_census:
-    status: partial
-    surfaces:
-      - id: surface-notification-worker
-        category: runtime_roles
-        surface_kind: runtime-entrypoint
-        frontier: deployment-runtime-units
-        identity_key: apps/notifications/worker.ts#startNotificationWorker
-        disposition: candidate
-        candidate_id: candidate-notification-worker
-        evidence_ids: [ev-notification-worker-census]
-  inventory_closure:
-    runtime_roles:
-      status: partial
-      candidates:
-        - id: candidate-notification-worker
-          disposition: pending
-          unresolved: [deployment-control-token]
-          evidence_ids: [ev-notification-worker-census]
-      uncovered: [candidate-notification-worker]
-```
-
-Final `services[].runtime_roles`, `resources`, and `external_dependencies` rows
-require a proof-complete category identity tuple and never use
-`trace_status: census-only`. Registry or manifest presence must still prove a
-real production-capable surface; a package import, test fixture, documentation
-mention, or arbitrary URL is not inventory evidence. Admit a runtime identity
-when its unit, controller kind/token, and entrypoint are exact; a state identity
-when its owner, address, reproduction kind/token are exact; and an external
-identity when its callsite, wrapper chain, boundary leaf, operation key, and
-destination/scope are exact. Activation, consumer reachability, backing state,
-hosted authority, and materialization readiness may remain unresolved on the
-final row while closure stays partial.
-
-When consumer or activation tracing remains open, use `activation: optional`
-with `activation_basis.kind: unknown-production-state`,
-`runtime_role_ids: []`, and `consumer_edges: []`, then keep the category
-partial. This is an honest downstream unknown, not a claim that the exact
-identity is inactive. External remote ownership may likewise use the unresolved
-`backing_state` form while state closure remains partial.
-
-### Resources and reproduction
-
-Use exactly one `state_classification`:
-
-- `canonical-durable`: authoritative mutable business state.
-- `derived-rebuildable`: indexes or projections rebuildable from canonical
-  state, with the rebuild path evidenced.
-- `ephemeral-coordination`: locks, sessions, presence, and coordination state.
-- `in-flight-work`: queues, streams, retry backlogs, and scheduled work not yet
-  applied to canonical state.
-- `immutable-external-asset`: immutable bytes or models obtained outside the
-  application and pinned by identity.
-
-Classification alone is insufficient. Add `state_policy` with these rules:
-
-- `canonical-durable` uses `action: copy`.
-- `derived-rebuildable` uses `action: rebuild` and nonempty
-  `source_resource_ids` that resolve to the source of truth.
-- `ephemeral-coordination` uses `action: reset`.
-- `in-flight-work` uses `action: preserve`, `drain`, or `discard`, plus a
-  nonempty `rationale` that addresses accepted but unapplied work.
-- `immutable-external-asset` uses `action: pin` plus an opaque
-  `immutable_asset_ref` and evidence of its immutable identity.
-
-`canonical-durable` may never use `reproduction_operation_kind: mount`. A
-volume, bind mount, `VOLUME`, or directory declaration proves writable parent
-capacity, not preservation of independently keyed durable children. Record the
-exact child identities created or restored by source operations. Retain the
-parent as a resource only when source proves its own independently preserved
-content identity.
-
-Every resource also has `state_owner.basis` and nonempty `evidence_ids`. The
-referenced decision-grade atomic `state-owner-boundary` claim has the resource
-as its exact subject set, repeats the basis in `state_owner_basis`, and records
-the matching typed operations in `state_owner_operation` and
-`reproduction_operation_kind`. The latter exactly matches the resource
-identity and the source tokens prove the real reproduction operation, not only
-its address or configuration:
-
-- `application-persistence-boundary` / `open-read-write` identifies the code
-  that opens, loads, or writes application state;
-- `repository-declared-mutable-state` / `named-mutable-namespace` identifies
-  exact mutable tables, objects, topics, schemas, catalogs, identities,
-  policies, registrations, or keys;
-- `operator-provisioned-writable-capacity` / `mount-or-path-provision`
-  identifies separately provisioned writable capacity; and
-- `immutable-asset-identity` / `immutable-digest-or-version` is reserved for
-  `immutable-external-asset`; and
-- `repository-proven-remote-state` / `named-remote-read` or
-  `named-remote-write` identifies an exact typed durable operation on a named
-  remote namespace in repository implementation code; and
-- `authoritative-catalog-state-owner` /
-  `catalog-declared-mutable-resource` uses an opaque authoritative catalog
-  source and `authority: authoritative` when repository code cannot establish
-  the hosted state owner.
-
-Client construction, endpoints, plugin/factory registration, provider names,
-generic API response sets, and discovery target groups do not prove any of these
-operations. A typed operation on the exact remote namespace can prove the
-repository remote-state basis. An exact read of an addressed configuration
-document, workload/instance metadata object, discovery record, identity or
-policy document, catalog, or remote manifest is a `named-remote-read` when its
-fields select topology, identity, routing, or runtime behavior that reproduction
-must preserve; read-only provider ownership does not erase that state concern.
-A resource still needs its independent `state_policy` and
-`reproduction` action. Each `derived-rebuildable` source additionally appears
-once in `state_policy.source_edges`, with a decision-grade atomic
-`rebuild-source-reachability` claim whose exact subjects are the derived
-resource and that source resource. A resolved ID list without those per-edge
-implementation paths is padding, not rebuild proof. Source resource IDs are
-unique; repeating an ID cannot stand in for another rebuild source.
-
-Apply this taxonomy to resources and state, not to arbitrary external APIs.
-
-Classify by reproduction concern, not network location. 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`, including
-when a managed provider hosts it. When the application reaches that resource
-over a network protocol or API, also record an `external_dependency`: routing,
-capture/emulation, and production-isolation control are independent of copying
-the state. Local, embedded, in-process, and file-backed resources remain
-resource-only absent separate application egress.
-
-Every external dependency therefore carries `backing_state` with nonempty
-`evidence_ids` and one disposition. At least one referenced decision-grade
-atomic evidence record must jointly name the exact external dependency ID and
-every linked resource ID as its exact `subject_ids`, use a locatable
-implementation-body source, and repeat the final basis in
-`external_backing_basis`. It also repeats the exact `external_operation` and,
-for named state, `remote_state_identity_key`; separate unlinked facts about a
-client and a store do not prove the boundary. The
-`authoritative-catalog-state-owner` basis requires
-`authority: authoritative` and an opaque catalog source:
-
-- `none` means the entry is only an interaction reproduction concern and omits
-  `resource_ids`; its `basis` is `interaction-only` or
-  `remote-ownership-unproven`.
-- `covered-by-resources` means the interaction fronts application backing state
-  and requires nonempty exact `resource_ids` resolving to the corresponding
-  stateful resources; its `basis` is `repository-declared-state-owner`,
-  `repository-proven-remote-state`, or `authoritative-catalog-state-owner`.
-
-`resource_ids` is an exact set represented without duplicate IDs.
-
-`backing_state.operation` is mandatory and is one of `named-remote-read`,
-`named-remote-write`, `named-remote-read-write`, `stateless-exchange`, or
-`unresolved`. A named operation is valid only with
-`covered-by-resources` and also requires a nonempty exact
-`remote_state_identity_key` naming the addressed object, namespace, or provider
-contract. `none/interaction-only` requires `stateless-exchange` and
-`none/remote-ownership-unproven` requires `unresolved`; those two operations
-omit `remote_state_identity_key`. Classify this operation before the
-disposition so a service client cannot erase the stable response object it
-reads. A remote response becomes mapped backing state only when exact evidence
-also proves an application-owned provision, preserve, reset, restore, replace,
-or recreate operation for that addressed object. Provider metadata, discovery
-records, identity or signing-key documents, downloaded user content, and
-operator-supplied remote inputs remain external interactions when the
-application only consumes them.
-
-The matching claim kind is `state-boundary-link` for
-`covered-by-resources`, `external-interaction-boundary` for
-`none/interaction-only`, and `external-ownership-unresolved` for
-`none/remote-ownership-unproven`. Every resource linked by
-`covered-by-resources` must independently pass its own `state_owner` proof.
-
-A configured endpoint, constructed client, or read operation does not establish
-state ownership or copyability. An exact typed durable operation on a named
-remote namespace may establish `repository-proven-remote-state` only when the
-resource also has a separate application-owned copy/rebuild/reset action.
-Otherwise use `none` with
-`remote-ownership-unproven` and keep stateful-resource closure `partial`; that
-basis records unresolved ownership and cannot support a complete claim.
-`interaction-only` requires evidence that no stable response object relevant to
-application-owned reproduction exists.
-An exact provider interface or factory contract that exposes durable
-create/read/write/delete/list operations over named backups, objects, buckets,
-collections, topics, streams, tables, indexes, identities, policies, or keys is
-a structured state discriminator for every reachable provider entry. Each entry
-creates its own pending state candidate by exact registry identity without
-requiring a repeated host literal or copy of the same interface trace. A
-network/API-backed provider also creates its external-interaction candidate;
-neither becomes final inventory until namespace, consumer, ownership, and
-reproduction semantics close. Join the two pending candidates immediately.
-Once both are closed, the same deterministic pass emits `backing_state:
-covered-by-resources`, links the exact provider-derived resource ID, and adds
-one joint `state-boundary-link` atomic evidence record whose subject set
-contains both IDs.
-Resolve it to `interaction-only` only when evidence establishes that the call
-has no separately reproduced backing state. Repository-selected mutable tables,
-objects, topics, schemas, catalogs, directory identities/groups, authorization
-policies, tenant registrations, and encryption keys do establish a state-owner concern;
-map that state and use `covered-by-resources` for the independently reproduced
-service interaction. Stateless inference, webhook, credential exchange, and
-arbitrary URL calls use `backing_state: none` only when implementation evidence
-shows no retained state relevant to reproduction. Persistent telemetry,
-log/metrics destinations, broker topics, object namespaces, identity/policy/key
-sets, and catalog namespaces remain resources when exact durable operations are
-proven. Ambiguity stays `remote-ownership-unproven`, never silently
-`interaction-only`. Backing-state `none` never means “exclude from egress.”
-
-Top-level external identity follows the exact operation/object contract.
-It has a globally unique exact `operation_identity_key`, exact
-`operation_token`, and `boundary_contract_kind` equal to
-`outbound-operation-family`, `host-operation`, `required-inbound-listener`,
-`required-pull-listener`, or `bidirectional-operation-family`. Its atomic
-boundary evidence supports the exact operation token.
-That same atomic claim supports the concrete callsite token, every wrapper token
-for `wrapper-resolved`, and the leaf boundary token. An import, constructor,
-method declaration, local handle lookup, quoted command argument, or generic HTTP helper definition is
-not callsite proof. Begin from a reachable production consumer and follow its
-exact wrapper chain to the boundary.
-Different provider, scheme, or transport implementations of the same contract
-remain visible in selector registries but do not create duplicate operational
-rows. OS branches, wrappers, and consumers that invoke the same semantic call
-also merge. Different effectful operations remain distinct even when they share
-one client, provider, object family, or user flow. For example list,
-head/metadata, get/download, put/upload, copy, and delete are separate reachable
-object-store contracts; authorization redirect, token exchange, user-info,
-supplemental-data, signing-key, and content-download calls are likewise separate
-when present. A separately opened callback or redirect listener is its own
-required inbound contract. Required inbound clients, pull consumers, host
-services, registries/discovery services, and bidirectional peers are external
-reproduction interactions when exact source or topology evidence makes them
-necessary; interaction direction is not limited to application-opened egress.
-Runtime-invoked one-shot executables are also external dependencies when they
-cross the mapped application-runtime boundary. Managed child RPC wholly inside
-one mapped runtime remains internal.
-
-Every final external row requires an exact boundary-crossing operation. Client
-constructors, authentication/configuration modes, protocol or scheme variants,
-local polling timers, retry loops, and wrappers that only build or call child
-handlers remain selector entries and do not become duplicate top-level
-dependencies. Their category projections are not applicable unless that exact
-branch performs its own independently addressed operation. Candidate identity
-is derived from the exact operation, object, and destination contract—not from
-the selector key or a requirement that every registry entry have a candidate.
-Host-operation rows represent one semantic effect family; do not bundle
-unrelated filesystem, environment, process, and subprocess calls.
-
-Configuration inputs already represented by clone injection, generated logs
-and outputs, child scratch/lock files, and replaceable assets are not state
-resources unless their initial contents need a separate reproduction action.
-However, separately provisioned writable capacity remains a resource when a
-selected spill/cache feature requires its own mount or reset action even if the
-contents start empty. Process-local state also remains a resource when required
-behavior needs an explicit post-launch reload or seed action.
-
-For example, a payment-provider API captured as behavior can use `none`; a
-managed database API recorded separately for protocol behavior must use
-`covered-by-resources` and link the database resource. A mapper may not replace
-the resource with the external entry.
-
-Use only these `reproduction.strategy` values:
-
-- `provider-native-fork`
-- `snapshot-restore`
-- `capture-replay`
-- `side-effect-sink`
-- `isolated-equivalent`
-- `unresolved`
-
-Keep physical bindings as top-level stable records. Each logical resource uses
-`physical_binding_id`. Several logical databases, queues, buckets, or keyspaces
-may reference one physical binding without being collapsed into one logical
-record.
-
-`provider-native-fork` and `snapshot-restore` require:
-
-- nonempty `reproduction.capability_evidence_ids`;
-- a resolvable `physical_binding_id`;
-- binding `status: resolved` or `proven`;
-- nonempty binding `evidence_ids`; and
-- a nonempty binding `stable_resource_ref`.
-
-`stable_resource_ref` is an opaque handle Haystack resolves for this
-checked-in artifact. Haystack may resolve it internally to a provider resource, and the bounded plan or golden
-descriptor may separately carry exact identities for validation, but this field
-must never expose a raw provider resource ID, ARN, production endpoint,
-credential, connection string, hostname containing credentials, or secret
-value.
-
-`capture-replay` and `side-effect-sink` require nonempty capability evidence
-and must forbid live egress. Use `side-effect-sink` for outbound effects such
-as SMTP or push delivery that are captured but never replayed. Do not label a
-non-delivering sink as bidirectional capture/replay. `isolated-equivalent`
-requires both capability evidence and a nonempty `fidelity_gap`, for
-example:
-
-```yaml
-reproduction:
-  source: isolated-fixture
-  strategy: isolated-equivalent
-  fidelity_gap: Does not reproduce provider throttling or regional failover.
-  writable: true
-```
-
-Every ID in `capability_evidence_ids` must resolve to an evidence record with
-`claim_kind: materialization-capability`, `confidence: proven`, the logical
-resource in `subject_ids`, and at least one repository, replication
-catalog, or Haystack-adapter source. Never ingest a direct provider response.
-Evidence that merely proves an SDK client exists is not
-materialization-capability evidence.
-
-Every materialization-capability record also declares:
-
-- `operational_status: declared` for an authoritative catalog statement;
-- `operational_status: adapter-verified` after deterministic adapter
-  qualification; or
-- `operational_status: materialization-probed` after a real isolated probe.
-
-Set `latency_basis: assumed` for catalog estimates and `measured` only for
-measurements. Authority over a synthetic assumption may prove that the catalog
-declared it, but it cannot promote the capability to adapter-verified,
-materialization-probed, or real-production readiness.
-
-Use `unresolved` when capability or binding evidence is missing. A blocked
-review does not permit a false concrete fork or snapshot claim.
-
-An interface owned by one role uses `runtime_role_id`; one shared by multiple
-roles uses `runtime_role_ids`. Declare exactly one. Model caches, queues, object
-stores, search indexes, flags, identity, and event or analytics systems
-explicitly. Group state that needs the same production cut.
-
-`canonical-durable` state may instead use `action: copy-with-transform` when the
-bytes are copied but changed on the way into the golden — masking production
-personal data, or re-keying columns encrypted under a production secret. It
-requires a `transform` mapping with `kind` (`mask`, `re-key`, or
-`mask-and-re-key`), a nonempty `rationale`, and a boolean `deterministic`. A
-non-deterministic transform re-randomizes every identity on each golden refresh,
-so cases that pin an identity break on every refresh:
-
-```yaml
-state_policy:
-  action: copy-with-transform
-  transform:
-    kind: mask-and-re-key
-    deterministic: true
-    rationale: >-
-      Customer email and name columns are format-preserving masked under the
-      golden's mask key; columns encrypted with the production application
-      secret are re-keyed to the golden's sealed value.
-```
-
-### Clone injection
-
-An inventory says what exists. It does not say what a fresh universe needs
-injected in order to boot and behave like production. That material is the
-difference between a parts list and a running system, so `clone_injection` is
-required on every map that records semantically traced inventory, confirmed
-hosted scope or not. The compact authority-gate receipt and maps with no final
-inventory because all discovered candidates remain pending are exempt because
-neither claims that the inventory can yet boot.
-
-It has exactly these eight categories, and each one is answered explicitly:
-
-- `config_slots` — environment variables and config keys per resource
-- `dns_identity` — hostnames and URLs the application must answer to
-- `tls` — certificate, verification, and scheme requirements
-- `filesystem_mounts` — paths that must exist before a process starts
-- `secret_derived_material` — values that other material is derived from
-- `protocol_metadata` — advertised listeners, replica-set names, connection options
-- `runtime_generated_config` — configuration produced at boot or stored in the database
-- `build_time_config` — values frozen into an artifact at build time
-
-Each category is a mapping with `status: declared` and a nonempty `entries`
-list, or `status: none` and a nonempty `reason`. Omitting a category is invalid.
-A category left silent is indistinguishable from one never investigated, and the
-holdout that motivated this section found agents reading a mount command and
-then not recording the mount because no field asked for it.
-
-Every entry carries a stable `id`, nonempty `evidence_ids`, and a `materiality`.
-It may carry `runtime_role_ids`.
-
-`materiality` states what the entry does to the replica, and is one of:
-
-- `boot-required` — the process will not start, or cannot reach a resource,
-  without it.
-- `binds-copied-state` — its value must match the production cut the golden was
-  sealed from. A fresh value makes copied bytes unreadable or unaddressable.
-- `isolation-control` — it governs whether the replica can reach production
-  systems. Getting it wrong causes real-world side effects.
-- `behavioural` — it changes observable behaviour, but the replica still runs.
-- `informational` — a real setting with no replica-relevant effect.
-
-This field exists because coverage alone cannot tell a thorough map from a padded
-one. In one holdout pass a map went from 67 to 440 entries, every declared name
-real, and roughly two thirds of the additions were settings a materializer gains
-nothing from — while the same pass also carried fifteen entries that closed a gap
-no earlier round had closed. Both were true at once and the artifact had no field
-with which a consumer could separate them.
-
-Declare `informational` honestly rather than omitting the entry or inflating its
-class. When the map declares at least one entry, `validate-universe --json`
-reports the mix under
-`summary.clone_injection_materiality`, so a map that is mostly `informational` is
-visible as such to anyone reading the result.
-
-Three rules tie the injection surface to the inventory the map already asserts,
-so the two cannot drift apart:
-
-1. Every name in a resource's `binding_names` must appear as a `config_slots`
-   entry. Those names are how the application is told where the resource lives;
-   listing a datastore and not injecting its connection variables produces a
-   replica that starts and connects to nothing.
-2. Every runtime role must appear in at least one `config_slots` entry's
-   `runtime_role_ids`. A role nothing configures cannot reach any resource.
-
-Every resource and external dependency carries `activation` plus an
-`activation_basis` with nonempty `evidence_ids`:
-
-- `active` — the selected deployment profile needs the store, or a fixed
-  external path is reachable without first supplying configuration or state.
-- `optional` — a concrete gate must first select it. Analytics sinks, secondary
-  audit stores, read replicas, configured providers, and tenant-supplied
-  destinations are usually optional.
-
-For `active`, `activation_basis.kind` is exactly one of:
-
-- `boot-required`
-- `selected-profile-required`
-- `startup-path`
-- `background-default`
-- `default-request-path`
-
-For `optional`, it is exactly one of:
-
-- `profile-excluded`
-- `feature-flag`
-- `driver-selection`
-- `operator-configuration`
-- `administrator-action`
-- `credential`
-- `tenant-state`
-- `user-supplied-destination`
-- `artifact-excluded`
-- `failure-tolerated`
-- `unknown-production-state`
-
-A fixed destination reached when an ordinary request invokes an already-enabled
-capability may use `default-request-path`. A webhook, remote, provider record,
-or URL supplied by a user or tenant uses `user-supplied-destination` or
-`tenant-state`: that destination does not exist until the state is created.
-Registration, a default endpoint constant, or client construction alone never
-proves an active path. Before marking a path optional, inspect the selected
-artifact's baked and default configuration: a shipped default is active even
-when an operator may override it. Use the proximate selecting gate.
-Operator-supplied URIs and implementation enums use `operator-configuration`;
-driver choices use `driver-selection`; `user-supplied-destination` is reserved
-for destinations supplied by an end user or tenant. Do not use `credential`
-when credentials merely authenticate a path already selected by configuration.
-
-For a resource, ask whether the selected profile boots and serves without the
-store, not how important its data looks. For an external dependency, trace
-whether a fixed destination is reached before any profile, credential,
-administrator, tenant-state, or user-supplied-destination gate. `activation`
-and `state_classification` answer different questions: an append-only analytics
-sink can be genuinely `canonical-durable` and still `optional`. Classify state
-honestly and let `activation` carry the reachability decision; do not downgrade
-a durable store to `derived-rebuildable` just to mark it optional.
-
-3. Every `activation: active` deployment profile must have at least one runtime
-   role declaring it. A profile that runs nothing is an empty shell; record it
-   under `alternate_topologies` instead.
-
-`secret_derived_material` additionally requires a `disposition`:
-
-- `seal-with-golden` — the replica must receive the exact value the golden was
-  sealed with, because copied bytes are unreadable without it;
-- `scrub-and-reset` — the protected data is cleared or re-keyed during cold
-  preparation, so a fresh value is safe;
-- `rotate-freely` — nothing durable depends on the value.
-
-The first two also require nonempty `bound_to_resource_ids` naming the resources
-whose copied bytes depend on the value. This is the binding that prevents a
-materializer from minting a fresh secret and silently rendering copied data
-unreadable.
-
-Clone injection records delivery, not ownership. If an exact stable key,
-certificate, salt, or identity must survive to preserve authentication,
-decryption, or signature behavior, map the corresponding durable or immutable
-identity as a resource too. Use `rotate-freely` only when no copied behavior
-depends on the exact value.
-
-```yaml
-clone_injection:
-  config_slots:
-    status: declared
-    entries:
-      - id: inj-database-url
-        name: DATABASE_URL
-        runtime_role_ids: [checkout-http-role]
-        evidence_ids: [ev-checkout-clients]
-        materiality: boot-required
-      - id: inj-events-url
-        name: EVENTS_URL
-        runtime_role_ids: [checkout-http-role]
-        evidence_ids: [ev-checkout-clients]
-        materiality: boot-required
-  dns_identity:
-    status: declared
-    entries:
-      - id: inj-public-url
-        name: URL
-        evidence_ids: [ev-checkout-routes]
-        materiality: isolation-control
-  tls:
-    status: none
-    reason: All datastore connections terminate on a loopback listener inside the sandbox.
-  filesystem_mounts:
-    status: declared
-    entries:
-      - id: inj-config-mount
-        path: /app/pythonpath
-        evidence_ids: [ev-checkout-entrypoint]
-        materiality: boot-required
-  secret_derived_material:
-    status: declared
-    entries:
-      - id: inj-secret-key
-        name: SECRET_KEY
-        disposition: seal-with-golden
-        bound_to_resource_ids: [orders-db]
-        evidence_ids: [ev-orders-column-encryption]
-        materiality: binds-copied-state
-  protocol_metadata:
-    status: none
-    reason: Single-endpoint TCP profile; no broker metadata or replica-set identity.
-  runtime_generated_config:
-    status: none
-    reason: All configuration arrives as environment variables at process start.
-  build_time_config:
-    status: declared
-    entries:
-      - id: inj-asset-manifest
-        name: manifest.json
-        evidence_ids: [ev-checkout-image-ci]
-        materiality: behavioural
-```
-
-## `behaviors.yml`
-
-This file maps the things a customer can actually do. It does not repeat
-runtime processes from `universe.yml`: one mapped interface can expose many
-separate actions. Every action references an exact universe interface and
-repository evidence. Its handler and observable boundaries use the same
-framed SHA-256 identity protocol as runtime instrumentation and blast-radius
-telemetry targets.
-
-```yaml
-version: 1
-schema_version: haystack-behavior-map-v1
-repository: acme/commerce
-source_commit: 0123456789abcdef0123456789abcdef01234567
-actions:
-  - id: action-a5f53f7b206d38cc97db5d53
-    interface_id: checkout-http
-    trigger:
-      kind: http
-      method: POST
-      route_template: /orders
-    handler:
-      symbol_id: symbol-91331f53480d298b9a59162d
-      source_path: apps/checkout/orders.ts
-      qualified_name: Orders.create
-    observable_boundaries:
-      - id: boundary-a439957515ba833bac1c01c5
-        kind: response
-        identity_key: http:POST:/orders:response
-      - id: boundary-84bb30f99b29bb529122adc1
-        kind: state
-        identity_key: database:orders:row
-    evidence_ids:
-      - ev-checkout-create-order-route
-      - ev-orders-write
-```
-
-Supported triggers are `http`, `event`, `job`, `cli`, and `ui`. HTTP triggers
-use `method` plus `route_template`; event triggers use `channel_identity` plus
-`event_type`; the remaining triggers use `job_identity`, `command_identity`,
-or `action_identity` respectively.
-
-Supported observable boundary kinds are `response`, `state`, `event`,
-`external`, `ui`, `cli`, and `job`. An action must name at least one stable
-customer-relevant boundary. Source line numbers are evidence coordinates, not
-identities, and never belong in an identity key.
-
-Run `haystack skills validate-behaviors --json`. It derives every action,
-symbol, and boundary ID again; verifies the source commit matches
-`universe.yml`; and checks interface and evidence references by exact ID.
-Display names and similar-looking text never repair a broken join. The command
-accepts the same 33554432-byte bound as the universe validator and uses the
-current directory when a sealed source archive intentionally has no Git metadata.
-
-## `evidence.yml`
-
-Completion requires a verifier-owned deterministic source census. Run
-`haystack skills census-universe --json` twice on the unchanged retained
-repository. The validator recomputes the result when repository context is
-available. The receipt separately copies the pinned 40-hex `source_commit`,
-source-manifest digest, exact counts, and sorted presumptive record IDs for all
-six operational and registry projections. Every listed operational ID
-appears exactly once in that category's candidates under
-`source_census_record_ids`; the candidate's ordinary mapped/excluded/pending
-contract then decides its semantics. Human-discovered candidates may omit this
-field, but census-produced identities may not.
-
-`.haystack/` is excluded from the retained-source manifest even when generated
-artifacts have been staged or tracked. The census must not observe its own
-outputs. In a source-only snapshot without Git metadata, the command may report
-`source_commit: null`; the receipt uses the already pinned
-`map_revision.source_commit` while retaining the command's exact manifest and
-record digests, counts, and projection IDs.
-
-Revision 39 makes each record's `proof_status` authoritative. A
-`proof-complete` record must have an empty `missing_proof_components`, maps
-exactly once in every declared projection, and cannot share its final with
-another record. Every operational final repeats `source_census_record_id`,
-`semantic_identity_id`, optional `execution_identity_id`, and the exact ordered
-`identity_components` tuple. Operational `discovery-lead` records are
-presumptive and also reconcile exactly once. They map only after the ordinary
-final contract supplies exact source-grounded identity proof, repeat
-`source_census_record_id`, preserve any partial identity components already
-known, and cite repository evidence at the census source path with every
-material token from its source anchor; otherwise they receive an exact evidenced
-exclusion. An operational discovery lead may be excluded only with
-`exclusion_basis: parent-runtime-unreachable` and atomic evidence for the exact
-census source path and tokens. Generic nonproduction, internal, duplicate, or
-non-independent relabeling is invalid. They cannot remain
-pending at `inventory-complete`. A `non-inventory` record cannot justify a final.
-Broad observations never close multiple identities;
-aliases remain separate exact selector rows unless the census supplies an
-explicit stable-ID derivation.
-
-Proof-complete runtime tuples include exact production provenance, controller,
-entrypoint, and lifecycle. Workflow jobs are runtime roles only with
-`controller_kind: workflow`, `production_operational_unit: "true"`, and a
-`production_effect_kind` of `deploy`, `schedule`, or `supervise`; publication
-and build work alone are not application runtimes. External HTTP, process, GUI,
-and host tuples preserve exact target, object, and flow stage. Process tuples
-also preserve executable, ordered `argv`, and wait semantics. Missing values
-keep a row a discovery lead instead of authorizing a broad final.
-
-Revision 39 emits typed `registry_families`, `registry_entries`, and
-`registry_edges`. A typed entry preserves `selector_family_record_id`; an edge
-preserves `parent_selector_entry_record_id`, `child_selector_family_record_id`,
-and `relation_kind`. Use those stable record IDs to retain owner boundaries and
-nested selector structure. Never flatten entries across family IDs or declare a
-leaf when the census gives that entry an outgoing edge. Broad conditional and
-ternary records remain discovery leads; explicit Vue component/directive,
-Java annotation, serialization, Spring bean-alternative, and Maven execution
-records are the authoritative selector identities.
-
-Every proof-complete registry family and entry has exactly one
-`source_census_record_id` join. Entries remain in their census family and keep
-their exact selector and implementation keys. Declared child edges must equal
-the proof-complete census edge set; an empty child list cannot override an
-outgoing edge. For large ledgers, `census_rehydration: exact` allows a family or
-entry to omit duplicated typed-identity and source-evidence fields while the
-validator recomputes them from the pinned census. It may also upgrade discovery
-registry observations after source-wide proof, provided the family preserves
-the census owner and each entry preserves its exact selector and implementation
-keys. Each discovery family and entry also cites atomic evidence for its census
-source path and material tokens. Semantic `category_projections` may remain partial at
-`inventory-complete`; `final-receipt` still requires full category links and a
-child-registry or evidenced leaf decision.
-
-`python-executable-entrypoint-role`, `workflow-controlled-runtime-unit`,
-`python-embedded-configuration-state`, and `python-embedded-template-state`
-remain deterministic census candidates rather than proof-complete finals. Map
-them when exact production provenance proves the runtime or state identity;
-otherwise reconcile each one through an exact evidenced exclusion. In
-particular, an admin/build/test entrypoint and an ordinary constant or rendering
-template must not be promoted solely because the scanner found its syntax.
-
-Other generic call-signature census records remain discovery leads. Map one
-only after exact source establishes its owner, operation, receiver boundary,
-address or object, and stage. A final whose only meaning is "census operation"
-or "host service" is invalid; expand browser-model, SDK, module-loader,
-resource-pull, callback-registration, file/stream, and imported-package calls
-to their exact structured identities.
-
-```yaml
-version: 1
-inspection_policy:
-  test_path_isolation:
-    enforced: true
-    primary_mechanism: path-aware-tool-exclusions
-    reviewer_mechanism: tracked-files-filtered-snapshot-and-filesystem-confinement
-    denied_components:
-      - .haystack
-      - __tests__
-      - test
-      - tests
-      - e2e
-      - cypress
-      - playwright
-      - testdata
-      - test-data
-      - integration-test
-      - integration-tests
-      - integration_test
-      - integration_tests
-      - acceptance-test
-      - acceptance-tests
-      - acceptance_test
-      - acceptance_tests
-      - system-test
-      - system-tests
-      - system_test
-      - system_tests
-      - test-results
-      - playwright-report
-      - .pytest_cache
-      - .nyc_output
-    conditional_component_rules:
-      - id: detected-framework-roots
-        components: [spec, specs, fixtures, __fixtures__, mocks, __mocks__, snapshots, __snapshots__]
-        condition: matching-test-framework-and-test-root-detected
-    activated_conditional_rule_ids: [detected-framework-roots]
-    denied_basename_globs:
-      - "*.test.{js,jsx,ts,tsx,mjs,cjs}"
-      - "*.spec.{js,jsx,ts,tsx,mjs,cjs,rb}"
-      - "*.e2e.{js,jsx,ts,tsx}"
-      - "*.e2e-spec.{js,jsx,ts,tsx}"
-      - "test-*.{js,jsx,ts,tsx,py,rb,go,rs}"
-      - "*-test.{js,jsx,ts,tsx,py,rb,go,rs}"
-      - "*_test.{py,go,rs,cc,cpp}"
-      - "*_tests.{py,rb}"
-      - "test_*.py"
-      - "*_unittest.{cc,cpp,py}"
-      - "*Test.{java,kt,kts,scala,groovy,cs,php,swift}"
-      - "*Tests.{java,kt,kts,scala,groovy,cs,php,swift}"
-      - "*.{snap,golden,approved}"
-      - "{jest,vitest,playwright,cypress}.config.*"
-      - "karma.conf.*"
-      - "mocha.config.*"
-      - "pytest.ini"
-      - "tox.ini"
-      - ".coveragerc"
-      - "junit*.xml"
-    reviewer_snapshot:
-      preparation_command:
-        executable: haystack
-        arguments: [skills, prepare-universe-review, --json]
-        exclude_inactive_submodule_paths: []
-      preparation_status: ready-for-confinement
-      manifest_digest: sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
-      git_metadata_included: false
-      network_disabled: true
-      symlink_audit: passed
-      safe_symlinks_materialized_as_regular_files: true
-      inline_test_detector: language-aware
-      inline_test_audit: passed
-coverage:
-  scanned_roots: [apps, packages, infra, deploy]
-  deterministic_identity_census:
-    schema_version: cloud-verifier-identity-census-v1
-    contract_revision: 39
-    command: haystack skills census-universe --json
-    source_commit: 0123456789abcdef0123456789abcdef01234567
-    source_manifest_digest: sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
-    first_record_digest: sha256:123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0
-    second_record_digest: sha256:123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0
-    tracked_files_total: 412
-    production_files_scanned: 287
-    records_total: 3
-    presumptive_inventory_total: 3
-    projection_record_ids:
-      runtime_roles: []
-      stateful_resources:
-        - census-state-address-declaration-0123456789abcdef0123
-        - census-state-address-declaration-123456789abcdef01234
-      external_dependencies:
-        - census-client-boundary-operation-23456789abcdef012345
-      registry_families: []
-      registry_entries: []
-      registry_edges: []
-  excluded_paths:
-    - path: .haystack/**
-      reason: prior-haystack-artifacts-hidden
-    - path: "**/tests/**"
-      reason: existing-tests-hidden
-  source_kinds: [application-source, terraform, kubernetes, ci-build]
-  external_integration_scope:
-    method: all-repository-supported-capabilities
-    status: complete
-    excluded_optional_profile_ids: []
-    evidence_ids: [ev-external-capability-scope]
-  inventory_closure:
-    runtime_roles:
-      status: complete
-      candidates:
-        - id: candidate-checkout-entrypoint
-          disposition: mapped
-          subject_ids: [checkout-http-role]
-          evidence_ids: [ev-checkout-entrypoint]
-      structured_registry_discovery:
-        status: complete
-        evidence_ids: [ev-checkout-entrypoint]
-        registries: []
-        absence_reason: No structured runtime-role registry is present.
-        uncovered: []
-      uncovered: []
-    stateful_resources:
-      status: complete
-      candidates:
-        - id: candidate-orders-database
-          disposition: mapped
-          subject_ids: [orders-db]
-          evidence_ids: [ev-orders-db-client]
-        - id: candidate-order-event-log
-          disposition: mapped
-          subject_ids: [order-events]
-          evidence_ids: [ev-order-topic]
-      state_surface_discovery:
-        status: complete
-        evidence_ids: [ev-orders-db-client, ev-order-topic]
-        entries:
-          - id: state-surface-orders-database-url
-            surface_kind: config-key
-            identity_key: DATABASE_URL
-            disposition: candidate
-            candidate_id: candidate-orders-database
-            evidence_ids: [ev-orders-db-client]
-          - id: state-surface-order-events-topic
-            surface_kind: config-key
-            identity_key: ORDER_EVENTS_TOPIC
-            disposition: candidate
-            candidate_id: candidate-order-event-log
-            evidence_ids: [ev-order-topic]
-        uncovered: []
-      logical_state_census:
-        status: complete
-        evidence_ids: [ev-logical-state-orders, ev-logical-state-events]
-        entries:
-          - id: logical-state-orders-database
-            logical_kind: configured-state-leaf
-            identity_key: orders-database
-            materialization_root_identity_key: DATABASE_URL
-            source_owner_identity_key: createOrdersDatabase
-            key_components: [DATABASE_URL]
-            mutation_operations: [create, update, delete]
-            state_surface_ids: [state-surface-orders-database-url]
-            contained_identity_disposition: none-proven
-            contained_logical_state_ids: []
-            contained_identity_reason: The database handle exposes no independently keyed child identity at this boundary.
-            contained_identity_evidence_ids: [ev-logical-state-orders-contained]
-            disposition: candidate
-            candidate_id: candidate-orders-database
-            evidence_ids: [ev-logical-state-orders]
-          - id: logical-state-order-events
-            logical_kind: namespace-record
-            identity_key: order-events-v2
-            materialization_root_identity_key: ORDER_EVENTS_TOPIC
-            source_owner_identity_key: publishOrderEvent
-            key_components: [ORDER_EVENTS_TOPIC, order-id]
-            mutation_operations: [append]
-            state_surface_ids: [state-surface-order-events-topic]
-            contained_identity_disposition: none-proven
-            contained_logical_state_ids: []
-            contained_identity_reason: Event payload identity is already the exact row key and contains no nested durable collection.
-            contained_identity_evidence_ids: [ev-logical-state-events-contained]
-            disposition: candidate
-            candidate_id: candidate-order-event-log
-            evidence_ids: [ev-logical-state-events]
-        uncovered: []
-      structured_registry_discovery:
-        status: complete
-        evidence_ids: [ev-orders-db-client, ev-order-topic]
-        registries: []
-        absence_reason: No structured state-resource registry is present.
-        uncovered: []
-      uncovered: []
-    external_dependencies:
-      status: complete
-      candidates:
-        - id: candidate-payments-client
-          disposition: mapped
-          subject_ids: [payments-api]
-          evidence_ids: [ev-payments-client]
-      structured_registry_discovery:
-        status: complete
-        evidence_ids: [ev-payments-client]
-        registries:
-          - id: registry-integration-clients
-            root: true
-            owner_identity_key: integration-client-factory
-            selector_domain: integration-client-kind
-            selection_gate:
-              kind: map-lookup
-              owner_token: integrationClientFactory
-              selector_token: integrationKind
-              dispatch_token: supportedIntegrations[integrationKind]
-              dispatch_semantics: selective-dispatch
-              runtime_consumer_token: createIntegrationClient
-              source_origin: application-owned
-            enumeration_method: static-structure
-            fallback_default: payments
-            status: complete
-            evidence_ids: [ev-integration-client-selection-gate]
-            entries:
-              - id: registry-entry-payments-client
-                selector_key: payments
-                selector_token: '"payments"'
-                selection_predicate: integration-kind == payments
-                implementation_key: payments-client
-                implementation_token: createPaymentsClient
-                category_links:
-                  runtime_roles:
-                    disposition: not-applicable
-                    not_applicable_basis: no-independent-long-running-runtime
-                    reason: The client does not launch another runtime role.
-                    evidence_ids: [ev-payments-runtime-category]
-                  stateful_resources:
-                    disposition: not-applicable
-                    not_applicable_basis: no-independent-persistent-state-identity
-                    reason: The repository declares no independently keyed persistent payment state.
-                    evidence_ids: [ev-payments-state-category]
-                  external_dependencies:
-                    disposition: candidate
-                    candidate_id: candidate-payments-client
-                    evidence_ids: [ev-payments-external-category]
-                child_registry_ids: []
-                child_registry_absence:
-                  reason: No nested selectable client implementation is declared.
-                  evidence_ids: [ev-payments-leaf]
-                evidence_ids: [ev-payments-registry-entry]
-            uncovered: []
-        uncovered: []
-      uncovered: []
-
-  operational_surface_census:
-    status: complete
-    evidence_ids: [ev-operational-surface-checkout, ev-operational-surface-orders, ev-operational-surface-events, ev-operational-surface-payments]
-    frontier_receipts:
-      - frontier: deployment-runtime-units
-        status: complete
-        surface_ids: [surface-checkout-http]
-        evidence_ids: [ev-operational-surface-checkout]
-        uncovered: []
-      - frontier: state-materialization-identities
-        status: complete
-        surface_ids: [surface-orders-logical-database, surface-order-events-stream]
-        evidence_ids: [ev-operational-surface-orders, ev-operational-surface-events]
-        uncovered: []
-      - frontier: outbound-host-operation-contracts
-        status: complete
-        surface_ids: [surface-payments-authorize]
-        evidence_ids: [ev-operational-surface-payments]
-        uncovered: []
-      - frontier: required-inbound-pull-contracts
-        status: complete
-        surface_ids: []
-        evidence_ids: [ev-checkout-routes]
-        absence_reason: No fixed outside actor is required by this example scope.
-        uncovered: []
-    surfaces:
-      - id: surface-checkout-http
-        category: runtime_roles
-        surface_kind: runtime-mode
-        frontier: deployment-runtime-units
-        identity_key: checkout-server/http
-        disposition: candidate
-        candidate_id: candidate-checkout-entrypoint
-        evidence_ids: [ev-operational-surface-checkout]
-      - id: surface-orders-logical-database
-        category: stateful_resources
-        surface_kind: persistent-logical-entity
-        frontier: state-materialization-identities
-        identity_key: orders-database
-        disposition: candidate
-        candidate_id: candidate-orders-database
-        evidence_ids: [ev-operational-surface-orders]
-      - id: surface-order-events-stream
-        category: stateful_resources
-        surface_kind: persistent-logical-entity
-        frontier: state-materialization-identities
-        identity_key: order-events-v2
-        disposition: candidate
-        candidate_id: candidate-order-event-log
-        evidence_ids: [ev-operational-surface-events]
-      - id: surface-payments-authorize
-        category: external_dependencies
-        surface_kind: network-or-sdk-interaction
-        frontier: outbound-host-operation-contracts
-        identity_key: payments-client/authorize
-        disposition: candidate
-        candidate_id: candidate-payments-client
-        evidence_ids: [ev-operational-surface-payments]
-    uncovered: []
-
-  selector_surface_census:
-    status: complete
-    evidence_ids: [ev-selector-surface-integration-clients]
-    discovery_roots:
-      - id: selector-root-integration-clients
-        owner_identity_key: integration-client-factory
-        selector_domain: integration-client-kind
-        source_identity_key: apps/checkout/src/integrations.ts#integrationClientFactory
-        surface_id: selector-surface-integration-clients
-        evidence_ids: [ev-selector-surface-integration-clients]
-    surfaces:
-      - id: selector-surface-integration-clients
-        construct_kind: plugin-provider-factory
-        owner_identity_key: integration-client-factory
-        enumeration_method: static-structure
-        availability_predicates: []
-        observed_selector_keys: [payments]
-        observed_implementation_keys: [payments-client]
-        disposition: registry
-        registry_id: registry-integration-clients
-        evidence_ids: [ev-selector-surface-integration-clients]
-    uncovered: []
-
-evidence_profiles:
-  - id: hosted-indicative-strong
-    environment_scope: hosted-production
-    authority: indicative
-    confidence: strong
-
-evidence_sources:
-  - id: source-checkout-role-identity
-    path: apps/checkout/src/server.ts
-    anchor: startCheckoutServer
-    kind: implementation
-    inspection_scope: implementation-body
-    locator_kind: exact-snippet
-    supporting_tokens: [startCheckoutServer]
-  - id: source-checkout-role-entrypoint
-    path: apps/checkout/src/server.ts
-    anchor: startCheckoutServer
-    kind: call-path
-    inspection_scope: role-call-path
-    locator_kind: symbol
-  - id: source-orders-role-use
-    path: apps/checkout/src/db.ts
-    anchor: createOrdersDatabase
-    kind: call-path
-    inspection_scope: role-call-path
-    locator_kind: symbol
-  - id: source-events-role-use
-    path: apps/checkout/src/events.ts
-    anchor: createOrderEventClient
-    kind: call-path
-    inspection_scope: role-call-path
-    locator_kind: symbol
-  - id: source-payments-role-use
-    path: apps/checkout/src/payments.ts
-    anchor: submitPayment
-    kind: call-path
-    inspection_scope: role-call-path
-    locator_kind: symbol
-  - id: source-orders-state-owner
-    path: apps/checkout/src/db.ts
-    anchor: "createOrdersDatabase\nDATABASE_URL"
-    kind: implementation
-    inspection_scope: implementation-body
-    locator_kind: exact-snippet
-    supporting_tokens: [createOrdersDatabase, DATABASE_URL]
-  - id: source-events-state-owner
-    path: apps/checkout/src/events.ts
-    anchor: "publishOrderEvent\nORDER_EVENTS_TOPIC"
-    kind: implementation
-    inspection_scope: implementation-body
-    locator_kind: exact-snippet
-    supporting_tokens: [publishOrderEvent, ORDER_EVENTS_TOPIC]
-  - id: source-payments-boundary
-    path: apps/checkout/src/payments.ts
-    anchor: "submitPayment\nauthorize-payment"
-    kind: implementation
-    inspection_scope: implementation-body
-    locator_kind: exact-snippet
-    supporting_tokens: [submitPayment, authorize-payment]
-  - id: source-integration-client-selection-gate
-    path: apps/checkout/src/integrations.ts
-    anchor: "integrationClientFactory\nintegrationKind\nsupportedIntegrations[integrationKind]"
-    kind: structured-registry
-    inspection_scope: structured-registry
-    locator_kind: exact-snippet
-    supporting_tokens: [integrationClientFactory, integrationKind, "supportedIntegrations[integrationKind]"]
-  - id: source-payments-registry-entry
-    path: apps/checkout/src/integrations.ts
-    anchor: "payments\npayments-client"
-    kind: structured-registry
-    inspection_scope: structured-registry
-    locator_kind: exact-snippet
-    supporting_tokens: [payments, payments-client]
-
-evidence:
-  - id: ev-checkout-entrypoint
-    subject_ids: [checkout-http-role]
-    claim_kind: runtime-role-identity
-    assertion: The checkout role launches through the exact server entrypoint.
-    profile_id: hosted-indicative-strong
-    source_ids: [source-checkout-role-identity]
-  - id: ev-integration-client-selection-gate
-    subject_ids: [registry-integration-clients]
-    claim_kind: registry-selection-gate
-    assertion: The exact integration lookup dispatches to selectable client implementations.
-    profile_id: hosted-indicative-strong
-    source_ids: [source-integration-client-selection-gate]
-  - id: ev-payments-registry-entry
-    subject_ids: [registry-entry-payments-client]
-    claim_kind: registry-entry-identity
-    assertion: The payments selector resolves to the exact payments client implementation.
-    profile_id: hosted-indicative-strong
-    source_ids: [source-payments-registry-entry]
-  - id: ev-external-capability-scope
-    subject_ids: [commerce-platform]
-    claim_kind: external-capability-scope
-    assertion: All repository-supported external capability surfaces were enumerated.
-    environment_scope: hosted-production
-    authority: indicative
-    sources:
-      - path: apps/checkout/src/integrations.ts
-        anchor: supportedIntegrations
-        kind: implementation
-        inspection_scope: implementation-body
-        locator_kind: symbol
-    confidence: strong
-  - id: ev-operational-surface-checkout
-    subject_ids: [surface-checkout-http]
-    claim_kind: operational-surface-census
-    assertion: The exact packaged HTTP execution mode was retained before role synthesis.
-    profile_id: hosted-indicative-strong
-    source_ids: [source-checkout-role-entrypoint]
-  - id: ev-operational-surface-orders
-    subject_ids: [surface-orders-logical-database]
-    claim_kind: operational-surface-census
-    assertion: The exact logical database identity was retained before resource synthesis.
-    profile_id: hosted-indicative-strong
-    source_ids: [source-orders-state-owner]
-  - id: ev-operational-surface-events
-    subject_ids: [surface-order-events-stream]
-    claim_kind: operational-surface-census
-    assertion: The exact persistent event stream identity was retained before resource synthesis.
-    profile_id: hosted-indicative-strong
-    source_ids: [source-events-state-owner]
-  - id: ev-logical-state-orders
-    subject_ids: [logical-state-orders-database]
-    claim_kind: logical-state-census
-    assertion: The orders database logical identity and mutator owner were enumerated separately from its connection root.
-    profile_id: hosted-indicative-strong
-    source_ids: [source-orders-state-owner]
-  - id: ev-logical-state-events
-    subject_ids: [logical-state-order-events]
-    claim_kind: logical-state-census
-    assertion: The keyed order-event namespace and append operation were enumerated separately from its topic root.
-    profile_id: hosted-indicative-strong
-    source_ids: [source-events-state-owner]
-  - id: ev-logical-state-orders-contained
-    subject_ids: [logical-state-orders-database]
-    claim_kind: logical-state-container-closure
-    assertion: The orders database boundary exposes no independently keyed nested state.
-    profile_id: hosted-indicative-strong
-    source_ids: [source-orders-state-owner]
-  - id: ev-logical-state-events-contained
-    subject_ids: [logical-state-order-events]
-    claim_kind: logical-state-container-closure
-    assertion: The event record boundary exposes no independently keyed nested state.
-    profile_id: hosted-indicative-strong
-    source_ids: [source-events-state-owner]
-  - id: ev-operational-surface-payments
-    subject_ids: [surface-payments-authorize]
-    claim_kind: operational-surface-census
-    assertion: The exact SDK operation was retained before dependency synthesis.
-    profile_id: hosted-indicative-strong
-    source_ids: [source-payments-boundary]
-  - id: ev-selector-surface-integration-clients
-    subject_ids: [selector-surface-integration-clients]
-    claim_kind: selector-surface-census
-    assertion: The exact integration-client factory owner was enumerated.
-    environment_scope: hosted-production
-    authority: indicative
-    sources:
-      - path: apps/checkout/src/integrations.ts
-        anchor: supportedIntegrations
-        kind: implementation
-        inspection_scope: structured-registry
-        locator_kind: symbol
-    confidence: strong
-  - id: ev-orders-db-client
-    subject_ids: [orders-db, checkout-api, checkout-http-role]
-    assertion: checkout-http-role constructs the production orders client
-    environment_scope: hosted-production
-    authority: authoritative
-    sources:
-      - path: apps/checkout/src/db.ts
-        lines: {start: 12, end: 24}
-        anchor: createOrdersDatabase
-        kind: exported-symbol
-        locator_kind: line-span
-      - path: deploy/checkout.yaml
-        anchor: spec.template.spec.containers[name=checkout].env[name=DATABASE_URL]
-        kind: manifest-key
-        locator_kind: manifest-key
-      - source_ref: deployment-catalog/hosted-checkout
-        selector: resource-bindings.orders-primary
-        record_key: orders-primary
-        kind: private-service-catalog-record
-    confidence: proven
-  - id: ev-orders-state-owner
-    subject_ids: [orders-db]
-    claim_kind: state-owner-boundary
-    state_owner_basis: application-persistence-boundary
-    state_owner_operation: open-read-write
-    reproduction_operation_kind: copy
-    assertion: The application opens and mutates the orders database.
-    profile_id: hosted-indicative-strong
-    source_ids: [source-orders-state-owner]
-  - id: ev-order-events-state-owner
-    subject_ids: [order-events]
-    claim_kind: state-owner-boundary
-    state_owner_basis: repository-declared-mutable-state
-    state_owner_operation: named-mutable-namespace
-    reproduction_operation_kind: restore
-    assertion: The repository declares the mutable order-events-v2 event log.
-    profile_id: hosted-indicative-strong
-    source_ids: [source-events-state-owner]
-  - id: ev-payments-boundary
-    subject_ids: [payments-api]
-    claim_kind: external-interaction-boundary
-    external_backing_basis: interaction-only
-    external_operation: stateless-exchange
-    assertion: The payments client reproduces interaction behavior without owned backing state.
-    profile_id: hosted-indicative-strong
-    source_ids: [source-payments-boundary]
-  - id: ev-orders-db-consumer
-    subject_ids: [orders-db, checkout-http-role]
-    claim_kind: role-reachability
-    assertion: checkout-http-role reaches the orders database on its selected profile.
-    profile_id: hosted-indicative-strong
-    source_ids: [source-checkout-role-entrypoint, source-orders-role-use]
-    role_call_path:
-      kind: direct
-      runtime_role_id: checkout-http-role
-      entrypoint_source_index: 0
-      consumer_source_index: 1
-  - id: ev-order-events-consumer
-    subject_ids: [order-events, checkout-http-role]
-    claim_kind: role-reachability
-    assertion: checkout-http-role reaches the order event log on its selected profile.
-    profile_id: hosted-indicative-strong
-    source_ids: [source-checkout-role-entrypoint, source-events-role-use]
-    role_call_path:
-      kind: direct
-      runtime_role_id: checkout-http-role
-      entrypoint_source_index: 0
-      consumer_source_index: 1
-  - id: ev-payments-consumer
-    subject_ids: [payments-api, checkout-http-role]
-    claim_kind: role-reachability
-    assertion: checkout-http-role reaches the fixed payments request path.
-    profile_id: hosted-indicative-strong
-    source_ids: [source-checkout-role-entrypoint, source-payments-role-use]
-    role_call_path:
-      kind: direct
-      runtime_role_id: checkout-http-role
-      entrypoint_source_index: 0
-      consumer_source_index: 1
-  - id: ev-payments-runtime-category
-    subject_ids: [registry-entry-payments-client-link-runtime-roles]
-    claim_kind: registry-category-decision
-    assertion: The client factory launches no independent long-running runtime.
-    environment_scope: hosted-production
-    authority: indicative
-    sources:
-      - path: apps/checkout/src/payments.ts
-        anchor: createPaymentsClient
-        kind: implementation
-        inspection_scope: implementation-body
-        locator_kind: symbol
-    confidence: strong
-  - id: ev-payments-state-category
-    subject_ids: [registry-entry-payments-client-link-stateful-resources]
-    claim_kind: registry-category-decision
-    assertion: The client factory declares no independently keyed persistent state identity.
-    environment_scope: hosted-production
-    authority: indicative
-    sources:
-      - path: apps/checkout/src/payments.ts
-        anchor: createPaymentsClient
-        kind: implementation
-        inspection_scope: implementation-body
-        locator_kind: symbol
-    confidence: strong
-  - id: ev-payments-external-category
-    subject_ids: [registry-entry-payments-client-link-external-dependencies]
-    claim_kind: registry-category-decision
-    assertion: The client factory creates the mapped outbound payments interaction.
-    environment_scope: hosted-production
-    authority: indicative
-    sources:
-      - path: apps/checkout/src/payments.ts
-        anchor: createPaymentsClient
-        kind: implementation
-        inspection_scope: implementation-body
-        locator_kind: symbol
-    confidence: strong
-  - id: ev-payments-leaf
-    subject_ids: [registry-entry-payments-client]
-    claim_kind: registry-leaf-inspection
-    assertion: The payments client implementation has no nested structured selector.
-    environment_scope: hosted-production
-    authority: indicative
-    sources:
-      - path: apps/checkout/src/payments.ts
-        anchor: createPaymentsClient
-        kind: implementation
-        inspection_scope: implementation-body
-        locator_kind: symbol
-    confidence: strong
-  - id: ev-hot-fork-checkout-wave
-    subject_ids: [hot-fork-checkout-wave]
-    assertion: The warm adapter produced eight fresh generated-case universes.
-    environment_scope: hosted-production
-    authority: authoritative
-    claim_kind: materialization-capability
-    operational_status: materialization-probed
-    latency_basis: measured
-    sources:
-      - source_ref: haystack-adapter-catalog/warm-checkout-wave
-        selector: qualification.latest
-        record_key: warm-checkout-wave
-        kind: haystack-adapter-capability-record
-    confidence: proven
-  - id: ev-prepared-checkout-source
-    subject_ids: [prepared-checkout-source]
-    assertion: The sealed replica identity matches the declared profile and cut.
-    environment_scope: hosted-production
-    authority: authoritative
-    sources:
-      - source_ref: prepared-state-catalog/checkout-source
-        selector: identity.latest
-        kind: replication-prepared-state-record
-    confidence: proven
-  - id: ev-hot-checkout-path-probe
-    subject_ids: [prepared-checkout-source, hot-fork-checkout-wave, hot-inject-checkout-commit]
-    assertion: The production-scoped warm probe exercised the declared hot path.
-    environment_scope: hosted-production
-    authority: authoritative
-    claim_kind: materialization-hot-path-probe
-    operational_status: materialization-probed
-    latency_basis: measured
-    sources:
-      - source_ref: haystack-probe-catalog/checkout-production-wave
-        selector: qualification.latest
-        kind: haystack-materialization-probe-result
-        environment_scope: hosted-production
-    probe_results:
-      observed_end_to_end_p95_ms: 5000
-      achieved_generated_case_fanout: 8
-      verification_commit_ref: commit-catalog/checkout-probe-001
-      arbitrary_verification_commit_injection: true
-      fresh_universe_per_generated_case: true
-      parent_write_protected: true
-      parallel_phases: [fork, attach, execute]
-      cleanup_order: [release-all-attachments, revoke-all-leases]
-      cleanup_covers_all_attempts_on_partial_failure: true
-      single_absolute_deadline: true
-      generated_case_runs:
-        - generated_case_id: generated-case-1
-          sandbox_id: sandbox-1
-          universe_incarnation_id: universe-incarnation-1
-        - generated_case_id: generated-case-2
-          sandbox_id: sandbox-2
-          universe_incarnation_id: universe-incarnation-2
-        - generated_case_id: generated-case-3
-          sandbox_id: sandbox-3
-          universe_incarnation_id: universe-incarnation-3
-        - generated_case_id: generated-case-4
-          sandbox_id: sandbox-4
-          universe_incarnation_id: universe-incarnation-4
-        - generated_case_id: generated-case-5
-          sandbox_id: sandbox-5
-          universe_incarnation_id: universe-incarnation-5
-        - generated_case_id: generated-case-6
-          sandbox_id: sandbox-6
-          universe_incarnation_id: universe-incarnation-6
-        - generated_case_id: generated-case-7
-          sandbox_id: sandbox-7
-          universe_incarnation_id: universe-incarnation-7
-        - generated_case_id: generated-case-8
-          sandbox_id: sandbox-8
-          universe_incarnation_id: universe-incarnation-8
-    confidence: proven
-```
-
-`selector_surface_census.discovery_roots` is the append-only first-discovery
-ledger. Add a row as soon as a typed selector field, registration owner,
-command tree, static map, switch, or equivalent exact dispatch root is
-observed—before enumerating entries or tracing semantics. Every row resolves
-to exactly one selector surface, and every surface resolves from exactly one
-row. A known root cannot be left only in `uncovered`; emit its surface and
-registry, retain all observed keys on the selector surface, and keep final
-`entries: []` while selector-to-implementation or nested traces remain partial.
-`uncovered` is only for source ranges or dynamic keys not yet discovered
-exactly. When a known root has zero semantically resolved selector keys, its
-partial registry uses `entries: []`, `fallback_default: none-proven`, and
-`entry_enumeration_blocker: {reason, evidence_ids}` naming the exact dynamic-key
-or uninspected-source boundary. Once a key is observed, replace that with
-`semantic_trace_blocker: {reason, evidence_ids}` while its implementation,
-category-link, or nested-registry trace remains open. Omit both blockers when the
-registry is complete.
-
-Each evidence record declares exactly one complete inline quality tuple
-(`environment_scope`, `authority`, `confidence`) or one `profile_id`, and
-exactly one nonempty inline `sources` list or `source_ids`. Put repeated tuples
-in `evidence_profiles` and repeated typed source locators in
-`evidence_sources`; references resolve by exact stable ID and do not weaken the
-claim's exact subject set. Every repository source has `locator_kind` equal to
-`symbol`, `exact-snippet`, `line-span`, `manifest-key`, or `config-key`.
-Its optional `inspection_scope` is `implementation-body`, `role-call-path`, or
-`structured-registry`; the last is valid for exact structured census and
-projection evidence but does not satisfy a full implementation-trace claim.
-Repository `anchor` values are non-empty strings. An `exact-snippet` anchor is
-a case-sensitive UTF-8 substring that occurs exactly once in the referenced
-repository file; use `line-span` to disambiguate repeated text. Normalized
-selector keys, generated labels, and summaries are not source snippets.
-`line-span` additionally uses an exact two-field `lines` object containing
-positive integer `start` and `end`; the span stays within the referenced file
-and contains the case-sensitive anchor. Padding fields are invalid. When the
-validator has repository context it reads these files and rejects absent
-snippets, out-of-range spans, and anchors outside their declared spans.
-Generated candidate IDs and family labels are not locators.
-
-Material identity sources additionally carry a nonempty unique
-`supporting_tokens` list and use only `exact-snippet` or `line-span`. Each token
-is an exact case-sensitive string inside the declared locator; a material line
-span is at most 80 lines. Runtime-role identity evidence supports the exact
-entrypoint; resource owner evidence supports both the source owner and
-materialization root; external boundary evidence supports the exact source
-owner and operation; registry gate and entry evidence supports their declared
-tokens. Opaque catalog sources never use `supporting_tokens`.
-
-Every full role's `entrypoint_evidence_id` resolves to decision-grade atomic
-`runtime-role-identity` evidence whose only subject is that role and whose
-`implementation-body` source supports the exact entrypoint token. A shebang,
-import, adjacent declaration, comment, or closing brace does not prove a launch
-identity.
-
-Atomic `role-reachability` evidence also carries `role_call_path`. Its
-`runtime_role_id` matches the claim subject; `entrypoint_source_index` and
-`consumer_source_index` are distinct zero-based indexes into the resolved
-source list; and `kind` is `direct`, `registration-dispatch`, or
-`configuration-dispatch`. A non-direct kind also requires a distinct zero-based
-`dispatch_source_index` locating the actual registration or selection gate;
-`direct` omits it. All indexed sources use `inspection_scope: role-call-path`
-and distinct exact repository locators; repeating one source at two indexes,
-padding its locator, or relabelling its locator kind is invalid.
-One source locates a role module or entrypoint and the
-other locates the concrete consumer use site. Plugin packaging or registration
-alone cannot occupy either end.
-
-When external-dependency closure is complete,
-`coverage.external_integration_scope` is mandatory with method
-`all-repository-supported-capabilities`, status `complete`, and an empty
-`excluded_optional_profile_ids`. Its evidence includes an atomic
-`external-capability-scope` claim whose only subject is the application ID and
-whose source uses `inspection_scope: implementation-body`. A profile gate may
-make a supported integration optional but cannot place it in the excluded list.
-
-`coverage.inventory_closure` is mandatory, including on a provisional map and
-on the compact empty receipt. It has exactly the three categories shown above.
-Each category has `status: complete` with `uncovered: []`, or `status: partial`
-with at least one uncovered source-scope description. It also has mandatory
-`structured_registry_discovery`. A complete discovery claim has nonempty
-evidence and `uncovered: []`; a partial claim names its uncovered scope. Each
-stateful-resource category also has mandatory `state_surface_discovery`. It is
-a `complete` or `partial` exact census with nonempty evidence and the same
-`uncovered` rules. Each surface entry has a unique stable `id`, an exact
-`identity_key`, and `surface_kind`: `config-key`, `writable-path`,
-`remote-loader`, `generated-output`, `identity-material`,
-`structured-manifest`, `persistent-entity`, `installed-artifact`,
-`host-persistent-state`, `scheduled-state`, `portable-snapshot`, or
-`packaged-installation-layout`. A `candidate` entry names one
-exact stateful-resource `candidate_id`; a `non-resource` entry omits it and
-records `non_resource_reason`. This retains discovery roots without promoting
-generic loaders, selectors, mounts, or plumbing into resources. If several
-entries reuse one candidate, every reused entry has nonempty
-`shared_binding_evidence_ids` proving the exact common logical binding. A
-complete empty census has an evidenced `absence_reason`; a nonempty stateful
-inventory may never use an empty census.
-
-The stateful-resource category also has mandatory `logical_state_census`.
-Every state closure candidate appears in exactly one row. Each row records a
-unique stable `id`, `logical_kind`, exact `identity_key`, separate
-`materialization_root_identity_key`, exact `source_owner_identity_key`,
-nonempty `key_components`, nonempty `mutation_operations`, the originating
-`state_surface_ids`, and atomic `logical-state-census` evidence whose only
-subject is that row ID. Allowed kinds are `keyed-record`, `leased-record`,
-`namespace-record`, `materialization-container`, `configured-state-leaf`,
-`portable-snapshot`, `installed-layout`, `generated-identity`,
-`scheduled-definition`, and `host-persistent-object`. Keyed, leased, and
-namespace rows include at least a materialization/root discriminator plus a
-record key or prefix, and their logical identity may not equal their container
-identity. Mutation operations are exact lifecycle verbs selected from
-`create`, `update`, `delete`, `append`, `replace`, `install`, `restore`,
-`register`, `lease`, `snapshot`, `export`, `copy`, `import`, `save`, `renew`,
-`revoke`, `compact`, `migrate`, `truncate`, and `rotate`.
-
-`source_owner_identity_key` resolves to an actual declaration or mutator in the
-referenced source. A synthesized convenience name, registry/schema field,
-comment, or non-owning caller is invalid. Unless the materialization root is
-itself the complete independently reproducible identity, `key_components`
-include at least one semantic discriminator beyond the root, such as an object
-or document key, filename, namespace, certificate role, plugin/module version,
-log stream, account, or equivalent exact identity. A root-only component list
-must not erase a more precise identity already proven by the mutator body.
-
-Every logical-state row records `contained_identity_disposition`; nested keyed
-state can live inside a serialized record, session, snapshot, installed layout,
-or host object as well as a physical container. `enumerated` names every
-independently keyed child in `contained_logical_state_ids`; those references
-must resolve to non-container rows. `none-proven` uses an empty child list, a
-specific `contained_identity_reason`, and atomic
-`logical-state-container-closure` evidence. `unresolved` names the frontier and
-is valid only while the logical-state census and state closure are partial.
-Physical co-location, one snapshot action, a bucket/table/root name, or a shared
-key prefix never proves that independently keyed children are absent. Portable
-snapshots and installed layouts are distinct logical rows rather than aliases
-of their live database or build descriptor. A complete empty census requires
-`absence_reason`; a partial census names its uncovered frontier.
-
-Every final resource repeats that logical identity and declares
-`state_unit_kind` as one of `logical-database`, `database-schema`,
-`search-index`, `cache-namespace`, `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
-has an exact unique, non-placeholder `address_token` and `reproduction_token`;
-atomic state-owner evidence supports the owner, root, address, and reproduction
-tokens. An unresolved reproduction strategy requires partial state closure; a
-complete category requires every final resource to have a concrete strategy. A
-portable container and a contained database, generated file, installed
-executable, or packaged asset are both final resources when each has an
-independent address and reproduction operation.
-Tables, projections, fields, indexes, and records inside an already reproduced
-database are not final resources unless exact evidence proves their independent
-address and independent reproduction action. Remote import inputs, provider
-variants, configuration inputs, and discovery responses stay out of final state
-inventory.
-
-`coverage.operational_surface_census` is mandatory. It enumerates exact
-execution facets, persistent logical entities and configured leaves, remote
-state operations, network/SDK interactions, runtime-invoked commands,
-host-service interactions, and required inbound or pull interactions before
-candidate synthesis. Each surface records a unique stable ID, category,
-exact `identity_key`, and `surface_kind`: `runtime-entrypoint`, `runtime-mode`,
-`scheduled-or-injected-workload`, `managed-child-process`,
-`persistent-logical-entity`, `configured-state-leaf`, `installed-artifact`,
-`portable-snapshot-artifact`, `packaged-installation-layout`,
-`generated-or-host-state`, `remote-state-operation`,
-`network-or-sdk-interaction`, `runtime-invoked-command`,
-`host-service-interaction`, or `required-inbound-or-pull-interaction`. It also
-has decision-grade atomic
-`operational-surface-census` evidence whose only subject is that surface ID. A
-`candidate` row names one exact category candidate; a `non-inventory` row omits
-the candidate and explains the source-derived decision. Every closure candidate
-must have at least one exact source surface.
-
-The census also contains exactly four `frontier_receipts`:
-`deployment-runtime-units`, `state-materialization-identities`,
-`outbound-host-operation-contracts`, and
-`required-inbound-pull-contracts`. Every surface repeats its mechanically
-determined `frontier`. Each receipt has `complete` or `partial` status,
-nonempty evidence, an exact duplicate-free `surface_ids` set, and `uncovered`.
-A complete empty frontier gives an `absence_reason`; complete closure requires
-all four receipts complete. Deployment units include separately launched
-database, cache, broker, and search processes as runtime roles in addition to
-their state resources. State identities include independently reproduced
-service certificates, CA bundles, secrets/credentials, configured destination
-objects, logical cache databases or namespaces, and writable, installed,
-cache, database, and report layouts. Outbound contracts enumerate every exact
-effectful leaf in reached wrappers, including filesystem methods, transaction
-stages, object-store methods, mail protocol stages, browser/host APIs, and
-downloads, package fetches, generators, or install commands needed to reproduce
-shipped artifacts. Build-time and install-time boundaries remain external
-dependencies even when they are not steady-state runtime egress. Required inbound/pull contracts
-retain independently reproduced listener boundaries without expanding every
-route.
-
-`coverage.selector_surface_census` is also mandatory. Each exact source owner
-records `construct_kind` as `executable-command-dispatch`,
-`plugin-provider-factory`, `persistence-schema-dispatch`,
-`lifecycle-hook-pipeline`, `behavior-or-config-selector`,
-`finite-behavior-dispatch`, or
-`dynamic-module-or-entrypoint`; `enumeration_method` is `static-structure`,
-`generated-input`, `language-aware-extraction`, or `implementation-trace`.
-It also records `owner_identity_key`, exact `availability_predicates`, exact
-nonempty unique `observed_selector_keys`, exact nonempty unique
-`observed_implementation_keys`, and either one `registry_id` or an evidenced
-`non-registry` decision. The decision-grade `selector-surface-census` evidence
-has the surface ID as its exact subject and a `structured-registry` source.
-Every emitted registry ID resolves from exactly one source-owner row. Its
-owner, enumeration method, selector-key set, and distinct implementation-key
-set exactly match the registry rows. A non-registry selector may record only
-one implementation identity; two or more exact production implementations
-require a registry. Wildcard, family, and sampled-member placeholders do not
-constitute enumeration. `non_registry_reason` is not prose: it is exactly one
-of `single-implementation-no-choice`, `exhaustive-all-members`,
-`declarative-data-only`, `operation-contract-without-dispatch`,
-`generated-without-application-gate`, or `non-production-selector`.
-
-A registry is admitted whenever a runtime selector chooses distinct concrete
-production behaviors or implementations, even when every inventory-category
-link is `not-applicable`. This includes concrete command, UI render/component,
-parser, formatter, field/entity factory, protocol-operation, migration/template,
-and feature-behavior dispatch only when a selector chooses one implementation
-or subset. Ordered migrations, hook pipelines, and generated codec/parser tables
-that execute or expose every member are not selector registries. Plain enums,
-lists, routes, metrics, constants, and flags with no concrete dispatch remain
-non-registries. Large registries are
-fully enumerated by a deterministic extractor; sampling is never completion.
-
-Each
-identified registry has a globally unique stable ID, `root: true` or `false`,
-an exact `owner_identity_key`, `selector_domain`, recognized
-`enumeration_method`, a concrete `selection_gate`, exact `fallback_default` (or `none-proven`), nonempty
-evidence, an enumeration status, exact `entries`, and its own uncovered list.
-`selection_gate.kind` is `map-lookup`, `switch-dispatch`,
-`factory-registration`, `manifest-entrypoint`, `command-dispatch`,
-`generated-dispatch`, or `configuration-dispatch`; it also records exact
-`owner_token`, `selector_token`, `dispatch_token`,
-`dispatch_semantics: selective-dispatch`, the production
-`runtime_consumer_token`, and `source_origin` as `application-owned` or
-`generated`. Generated input additionally records a distinct exact
-`application_gate_token`; generated machinery without that app-owned gate is
-not a registry. Registry evidence includes atomic `registry-selection-gate`
-evidence for all of those tokens. An
-interface or abstract method set is an operation contract, not a registry.
-Every entry has a globally unique stable ID, unique exact `selector_key`,
-exact `selector_token`, nonempty exact `selection_predicate`, nonempty
-`implementation_key`, distinct exact `implementation_token`, exact evidence,
-and exact `category_links` for
-`runtime_roles`, `stateful_resources`, and `external_dependencies`. Each link is
-either `candidate` with one candidate ID from that category, or
-`not-applicable` with evidence, a reason, and the fixed category basis:
-`no-independent-long-running-runtime`,
-`no-independent-persistent-state-identity`, or
-`no-external-reproduction-interaction`. Every category-link evidence record uses
-`claim_kind: registry-category-decision`, has the exact derived link ID as its
-only `subject_ids` value, and cites a repository source with
-`inspection_scope: implementation-body`. Selector keys are unique within a
-registry; implementation keys may repeat when distinct exact selectors are
-aliases for one implementation. Within one registry and category, entries may not reuse a
-candidate or resolve through separate candidates to the same broad inventory
-subject. That anti-collapse rule keeps each independently selectable
-implementation visible across state and service concerns; an evidenced
-redundant alias receives its own excluded candidate.
-
-Every registry entry's own evidence includes atomic
-`registry-entry-identity` evidence whose only subject is that entry and whose
-`structured-registry` source supports its exact selector and implementation
-tokens.
-The gate selector token differs from its dispatch token, and an entry's selector
-key/token differs from its implementation key/token. Constructor expressions,
-handler names, provider names, and classes are implementations, not selectors;
-use the exact literal, enum value, manifest key, command `Use` string, or other
-source token that a caller actually selects.
-
-Discovery may scan literal arrays, mappings, enums, and generated tables as
-candidate surfaces, but an emitted registry requires exact evidence that its
-keys select or dispatch distinct production implementation identities relevant
-to a runtime role, state owner, or external interaction. Platform/facet lists,
-field and entity types, routes, metrics, protocol verbs, constants, discovery
-matchers, and feature flags are not inventory registries merely because they
-are structured. Executable and command dispatch is the exception: packaged
-wrapper maps, command tables, command annotations, and nested subcommand
-indexes are registries when exact keys dispatch distinct production-capable
-implementations. Finite production batches also link to exact runtime-role
-candidates; the registry identity remains separate. Scale-generated registries retain semantic stable
-IDs and selection/dispatch evidence; opaque hashes and one-registry-per-literal
-collection do not satisfy this boundary.
-
-One dominant manifest, plugin, or provider index never substitutes for the full
-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. Each becomes either a genuine inventory registry or an exact evidenced
-non-registry decision. Exhausting the largest registry does not close the
-smaller root-selector frontier.
-
-Language-aware enumeration retains every exact selector identity, not just
-concrete implementation classes. This includes configuration aliases,
-sentinel/default choices, behavior-selecting enum constants, annotated abstract
-command bases and group nodes, and packaged executable keys. A selector alias
-remains an entry when it resolves to a class already present under a different
-key. Annotation addressability is independent of class concreteness, and a
-long-running executable remains in the executable registry even when its launch
-surface also maps to a runtime role. Java/Kotlin subtype scans take the
-transitive concrete closure through subclasses of subclasses and separately
-retain these non-subtype selector forms.
-
-A registry retains every enumerated key on its exact selector surface and every
-exact selector-to-implementation pair in `entries[]`. During a partial phase,
-an identity-complete row uses `trace_status: identity-complete`, structured
-category projections, and an exact `unresolved` list for open category-link or
-nested-registry work. It is valid at `inventory-complete` after the exact
-family, entry, and edge census closes, but invalid at `final-receipt`. The
-registry identity status is partial only while enumeration or an implementation
-identity is open. A full semantic entry requires distinct exact
-`selector_key`/`selector_token` and
-`implementation_key`/`implementation_token`, atomic
-`registry-entry-identity` evidence, all three `category_links`, and either
-`child_registry_ids` or evidenced `child_registry_absence`.
-
-When the registry schema establishes an inventory category for all members,
-every exact positive creates its own closure candidate. Entries in a worker
-launch index, for example, create runtime-role candidates. Mixed integration,
-plugin, or manifest indexes use exact structured per-entry discriminators such
-as I/O class, transport, client, or endpoint declarations. Free-text names and
-summaries are never category discriminators. Keep unresolved candidates
-`pending`; do not project them into final inventory. A positive structured I/O
-declaration remains positive when it describes local/device polling or push:
-locality is destination placement, not proof of an in-process internal link.
-Exact implementation evidence may still exclude a calculated/in-process,
-dead/removal-only, or exact duplicate concern. Exhaust generic syntax- and
-structured-key-derived passes over executable/worker registrations, connection
-schemas, client and transport construction, endpoint and namespace constants,
-migration/schema roots, storage adapters, durable operations, backup providers,
-and generated inputs before stopping. A registry ledger alone does not close
-or preserve scored inventory breadth.
-
-Each entry also has `child_registry_ids`. An empty list requires a
-`child_registry_absence` mapping with a nonempty implementation-specific
-`reason` and nonempty exact `evidence_ids`. Those evidence IDs include an atomic
-`claim_kind: registry-leaf-inspection` record whose only subject is the exact
-entry ID and whose repository source uses
-`inspection_scope: implementation-body`; a bulk installer or registration
-record cannot prove leafhood. Otherwise every referenced child
-resolves to a declared `root: false` registry. Every non-root registry is linked by a parent
-entry, roots are not children, all registries are reachable from a root, and
-the graph is acyclic. This recursive closure prevents a parent connector,
-transport, or provider from hiding nested authentication, catalog, schema,
-storage, or key-management selections. A complete registry with no entries
-explains `empty_reason`; a complete scan
-with no registry surfaces explains `absence_reason`. Every discovered
-candidate has a globally unique stable ID, nonempty `evidence_ids`, and one
-disposition:
-
-- `mapped` requires nonempty `subject_ids` that resolve only to inventory IDs
-  in that category.
-- `pending` is allowed only while the category is `partial`, omits
-  `subject_ids` and all exclusion fields, has a nonempty unique `unresolved`
-  exact-identity-gap list, and is named exactly in the category's `uncovered`
-  list. Runtime gaps are only `runtime-unit-identity`,
-  `deployment-control-kind`, `deployment-control-token`, and
-  `entrypoint-token`. State gaps are only `state-unit-identity`,
-  `state-owner-identity`, `address-token`, `reproduction-operation-kind`, and
-  `reproduction-token`. External gaps are only `operation-identity-key`,
-  `callsite-identity`, `callsite-token`, `boundary-operation-token`,
-  `destination-or-scope-key`, and `wrapper-trace`. Activation, role
-  reachability, backing-state, materialization, production authority, and other
-  downstream closure questions never belong in `unresolved`; carry them on the
-  final identity and keep closure partial.
-- `excluded` omits `subject_ids` and requires a nonempty `exclusion_reason` plus
-  a structured `exclusion_basis`. A `duplicate-inventory` exclusion also names
-  exact `equivalent_subject_ids` and cites an atomic
-  `claim_kind: duplicate-inventory-equivalence` evidence record. That record's
-  exact subjects are the candidate ID plus the equivalent inventory IDs, and
-  its repository source uses `inspection_scope: implementation-body`. The
-  corresponding candidate audit row cites the same exact claim.
-
-A candidate referenced by a structured-registry link may be excluded only as
-`duplicate-inventory`. Repository-supported providers, connectors, clients,
-and backends remain mapped inventory when they are gated by profile, default,
-configuration, flag, credential, or artifact selection; the gate makes their
-inventory entry `activation: optional`, not absent. Build-only, test-only,
-outside-boundary, internal-link, and non-independent-unit bases apply
-only to candidates that are genuinely not supported inventory, never as a
-synonym for “not selected by the default profile.”
-
-Finite production-reachable commands and batches are runtime roles. Duration,
-normal exit, administration, and migration are not exclusion bases. Each exact
-wrapper or entrypoint maps separately; its runtime mapping does not replace its
-executable, command, annotation, or nested-subcommand registry identity.
-
-Every mapped runtime role, resource, and external dependency must be named by
-at least one candidate in its category. This ledger records inspected
-candidates; it is not permission to synthesize candidates from the final map.
-Write it during discovery, before inventory synthesis, so an omitted launch
-surface or backend cannot disappear merely because no output field mentions it.
-A closure category may be `complete` only when its registry discovery is also
-complete. All three categories may be complete only after
-`review.yml.inventory_closure_audit` independently covers every category,
-candidate ID, registry ID, registry-entry ID, derived entry-category link ID,
-and parent-child edge ID. Review status may be `pass` only with complete
-closure; blocked and provisional receipts retain honest `partial` status and
-uncovered scope whenever that exact audit cannot be completed.
-
-Every resource and external dependency also has `consumer_edges`, exactly one
-per `runtime_role_ids` entry. Each edge repeats that role's `activation` and
-`activation_basis`; its evidence has `claim_kind: role-reachability`, exact
-`subject_ids: [<inventory-id>, <runtime-role-id>]`, and a repository source with
-`inspection_scope: role-call-path`. Its typed `role_call_path` identifies that
-role and indexes two distinct locatable sources: a role module/entrypoint and
-the concrete consumer use site. Non-direct paths add a third index for the
-actual dispatch or configuration gate. The indexes must resolve to pairwise
-distinct exact repository locator keys; duplicating a locator does not create a call path.
-Changing only `locator_kind` does not make a location distinct.
-Registration, a plugin factory, or packaging evidence is not a positive
-consumer edge. Top-level activation is `active` when any consumer edge
-is active and `optional` only when every consumer edge is optional. Empty
-consumer sets remain possible only while the affected closure category is
-partial; a complete category must name a positive consumer for every resource
-and dependency.
-
-All atomic closure records—`external-capability-scope`,
-`duplicate-inventory-equivalence`, `registry-category-decision`,
-`registry-leaf-inspection`, `operational-surface-census`,
-`selector-surface-census`, `role-reachability`, `state-owner-boundary`,
-`rebuild-source-reachability`, `state-boundary-link`,
-`external-interaction-boundary`, and `external-ownership-unresolved`—must be
-decision-grade.
-Their authority is `authoritative` or `indicative`, confidence is `proven` or
-`strong`, and environment scope is `hosted-production`,
-`production-reference`, or `self-host-reference`. Tentative, non-production,
-local-development, example, and unknown evidence cannot support these claims.
-
-Use `authority: authoritative` only for a live deployment source or artifact
-pipeline known to control it. Use `indicative` for executable code and
-production-intended config, and `non-production` for self-host, dev, or example
-sources. Prefer code, deployment config, and IaC over prose.
-
-`confidence: proven` means two independent primary sources or one authoritative
-declaration; `strong` means direct executable source; `tentative` creates an
-unresolved item. Every selected object, edge, profile, and consistency group
-must cite evidence. Evidence can support multiple exact subject IDs.
-
-Every evidence record has a nonempty `assertion` and resolves a recognized
-`environment_scope`, `authority` (`authoritative`, `indicative`, or
-`non-production`), `confidence` (`proven`, `strong`, or `tentative`), and at
-least one source through exactly one inline form or stable-ID catalog form.
-Each source has either a normalized repository-relative POSIX `path`, typed
-`locator_kind`, and structured `anchor`, or opaque `source_ref` plus a structured
-`selector` or `record_key`. Use the second form for a deployment catalog
-record or a Haystack adapter qualification
-record. Never use a direct provider response. Its `kind` must identify that
-source type. Opaque catalog sources omit repository-only `anchor`,
-`locator_kind`, and `lines` fields. `source_ref` is an opaque catalog handle,
-never a raw URL, ARN,
-provider resource ID, production endpoint, credential, connection string, or
-secret.
-
-Record every path actually excluded. External discovery enumerates every
-repository-supported provider, connector, client, and backend capability once,
-including capabilities gated off by active profiles. Role reachability decides
-consumer edges and activation, not whether a supported capability exists. Do
-not expand topology permutations, but do not collapse distinct provider
-implementations. Use `status: partial` with uncovered scope when the budget
-prevents a justified enumeration or reachability decision.
-
-Apply component rules and typed basename globs to normalized
-repository-relative POSIX paths. Activate `spec`, `fixtures`, `mocks`, and
-snapshot components only where repository evidence identifies a matching test
-framework and test root; they can otherwise contain product specifications or
-bootstrap adapters. Never use a substring pattern such as `*test*`, which also
-matches `latest`, `contest`, and `attestation`. The reviewer
-snapshot contains only tracked, retained source files and no `.git` directory.
-Filesystem confinement must prevent reads outside it, and network must be off.
-Reject symlinks that escape the retained tree or target an excluded path;
-materialize allowed internal targets as regular files. Run a language-aware
-preflight for co-located test declarations. If retained production files still
-contain tests and no syntax-aware filter can remove them safely, block with
-`reviewer-test-path-isolation-unavailable`. A prompt or isolated working
-directory alone is insufficient.
-
-Record snapshot preparation as a structured executable plus argument list.
-Keep `arguments` exactly `[skills, prepare-universe-review, --json]`; list each
-approved tracked inactive gitlink as an exact normalized path in
-`exclude_inactive_submodule_paths`. That field represents the repeated
-`--exclude-inactive-submodule` option and is an empty list when no omission was
-approved. Never store a shell command string.
-
-Before final validation, lint every `evidence.sources[].path` against the same
-activated policy. A denied path is a blocker, and the validator resolves every
-repository path against the current git root and rejects missing or non-file
-sources.
-
-## `review.yml`
-
-```yaml
-version: 1
-inventory_closure_audit:
-  status: completed
-  mode: customer-cli-subagent
-  read_only: true
-  repository_only: true
-  independent_from_primary: true
-  resumable: true
-  ephemeral: false
-  spawned_subagents: 0
-  primary_plan_hidden_during_inventory: true
-  final_artifacts_unchanged_since_blind_inventory: true
-  session_id_recorded_in_private_scratch: true
-  output_capture: incremental-private-scratch
-  budget:
-    call_limit: 48
-    elapsed_limit_seconds: 600
-    repository_inspection_calls_used: 14
-    elapsed_seconds: 142
-  source_isolation:
-    enforced: true
-    preparation_command:
-      executable: haystack
-      arguments: [skills, prepare-universe-review, --json]
-      exclude_inactive_submodule_paths: []
-    preparation_status: ready-for-confinement
-    manifest_digest: sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
-    haystack_hidden: true
-    git_metadata_included: false
-    network_disabled: true
-    filesystem_confined_to_snapshot: true
-    symlink_audit: passed
-    inline_test_audit: passed
-  reviewed_categories: [runtime-roles, stateful-resources, external-dependencies]
-  reviewed_candidate_ids:
-    - candidate-checkout-entrypoint
-    - candidate-orders-database
-    - candidate-order-event-log
-    - candidate-payments-client
-  reviewed_registry_ids: [registry-integration-clients]
-  reviewed_registry_entry_ids: [registry-entry-payments-client]
-  reviewed_registry_entry_category_link_ids:
-    - registry-entry-payments-client-link-runtime-roles
-    - registry-entry-payments-client-link-stateful-resources
-    - registry-entry-payments-client-link-external-dependencies
-  reviewed_registry_edge_ids: []
-  candidate_reviews:
-    - candidate_id: candidate-checkout-entrypoint
-      declared_disposition: mapped
-      verdict: confirmed
-      reason: The isolated auditor confirmed the packaged checkout entrypoint.
-      evidence_ids: [ev-checkout-entrypoint]
-    - candidate_id: candidate-orders-database
-      declared_disposition: mapped
-      verdict: confirmed
-      reason: The isolated auditor confirmed the orders database state concern.
-      evidence_ids: [ev-orders-db-client]
-    - candidate_id: candidate-order-event-log
-      declared_disposition: mapped
-      verdict: confirmed
-      reason: The isolated auditor confirmed the event-log state concern.
-      evidence_ids: [ev-order-topic]
-    - candidate_id: candidate-payments-client
-      declared_disposition: mapped
-      verdict: confirmed
-      reason: The isolated auditor confirmed the outbound payments interaction.
-      evidence_ids: [ev-payments-client]
-  state_owner_reviews:
-    - resource_id: orders-db
-      declared_basis: application-persistence-boundary
-      verdict: confirmed
-      reason: The isolated auditor confirmed the orders persistence boundary.
-      evidence_ids: [ev-orders-state-owner]
-    - resource_id: order-events
-      declared_basis: repository-declared-mutable-state
-      verdict: confirmed
-      reason: The isolated auditor confirmed the mutable event-log namespace.
-      evidence_ids: [ev-order-events-state-owner]
-  external_backing_state_reviews:
-    - external_dependency_id: payments-api
-      declared_disposition: none
-      declared_basis: interaction-only
-      declared_operation: stateless-exchange
-      verdict: confirmed
-      reason: >-
-        The call reproduces interaction behavior but owns no application
-        backing state.
-      evidence_ids: [ev-payments-boundary]
-  registry_entry_category_link_reviews:
-    - registry_entry_id: registry-entry-payments-client
-      category: runtime_roles
-      declared_disposition: not-applicable
-      declared_not_applicable_basis: no-independent-long-running-runtime
-      verdict: confirmed
-      reason: The isolated auditor found no independent runtime in the client body.
-      evidence_ids: [ev-payments-runtime-category]
-    - registry_entry_id: registry-entry-payments-client
-      category: stateful_resources
-      declared_disposition: not-applicable
-      declared_not_applicable_basis: no-independent-persistent-state-identity
-      verdict: confirmed
-      reason: The isolated auditor found no independently keyed persistent state identity.
-      evidence_ids: [ev-payments-state-category]
-    - registry_entry_id: registry-entry-payments-client
-      category: external_dependencies
-      declared_disposition: candidate
-      declared_candidate_id: candidate-payments-client
-      verdict: confirmed
-      reason: The isolated auditor confirmed the outbound client candidate.
-      evidence_ids: [ev-payments-external-category]
-  registry_leaf_reviews:
-    - registry_entry_id: registry-entry-payments-client
-      verdict: confirmed
-      reason: The isolated auditor inspected the implementation body for nested selectors.
-      evidence_ids: [ev-payments-leaf]
-  consumer_edge_reviews:
-    - subject_id: orders-db
-      runtime_role_id: checkout-http-role
-      declared_activation: active
-      verdict: confirmed
-      reason: The isolated auditor confirmed the orders call path for this role.
-      evidence_ids: [ev-orders-db-consumer]
-    - subject_id: order-events
-      runtime_role_id: checkout-http-role
-      declared_activation: active
-      verdict: confirmed
-      reason: The isolated auditor confirmed the event-log call path for this role.
-      evidence_ids: [ev-order-events-consumer]
-    - subject_id: payments-api
-      runtime_role_id: checkout-http-role
-      declared_activation: active
-      verdict: confirmed
-      reason: The isolated auditor confirmed the payments call path for this role.
-      evidence_ids: [ev-payments-consumer]
-  findings: []
-reviewer:
-  mode: customer-cli-subagent
-  read_only: true
-  resumable: true
-  ephemeral: false
-  spawned_subagents: 0
-  primary_plan_hidden_during_inventory: true
-  session_id_recorded_in_private_scratch: true
-  output_capture: incremental-private-scratch
-  source_isolation:
-    enforced: true
-    mechanism: tracked-files-filtered-snapshot-and-filesystem-confinement
-    preparation_command:
-      executable: haystack
-      arguments: [skills, prepare-universe-review, --json]
-      exclude_inactive_submodule_paths: []
-    preparation_status: ready-for-confinement
-    manifest_digest: sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
-    denied_components:
-      - .haystack
-      - __tests__
-      - test
-      - tests
-      - e2e
-      - cypress
-      - playwright
-      - testdata
-      - test-data
-      - integration-test
-      - integration-tests
-      - integration_test
-      - integration_tests
-      - acceptance-test
-      - acceptance-tests
-      - acceptance_test
-      - acceptance_tests
-      - system-test
-      - system-tests
-      - system_test
-      - system_tests
-      - test-results
-      - playwright-report
-      - .pytest_cache
-      - .nyc_output
-    conditional_component_rules:
-      - id: detected-framework-roots
-        components: [spec, specs, fixtures, __fixtures__, mocks, __mocks__, snapshots, __snapshots__]
-        condition: matching-test-framework-and-test-root-detected
-    activated_conditional_rule_ids: [detected-framework-roots]
-    denied_basename_globs:
-      - "*.test.{js,jsx,ts,tsx,mjs,cjs}"
-      - "*.spec.{js,jsx,ts,tsx,mjs,cjs,rb}"
-      - "*.e2e.{js,jsx,ts,tsx}"
-      - "*.e2e-spec.{js,jsx,ts,tsx}"
-      - "test-*.{js,jsx,ts,tsx,py,rb,go,rs}"
-      - "*-test.{js,jsx,ts,tsx,py,rb,go,rs}"
-      - "*_test.{py,go,rs,cc,cpp}"
-      - "*_tests.{py,rb}"
-      - "test_*.py"
-      - "*_unittest.{cc,cpp,py}"
-      - "*Test.{java,kt,kts,scala,groovy,cs,php,swift}"
-      - "*Tests.{java,kt,kts,scala,groovy,cs,php,swift}"
-      - "*.{snap,golden,approved}"
-      - "{jest,vitest,playwright,cypress}.config.*"
-      - "karma.conf.*"
-      - "mocha.config.*"
-      - "pytest.ini"
-      - "tox.ini"
-      - ".coveragerc"
-      - "junit*.xml"
-    haystack_hidden: true
-    git_metadata_included: false
-    network_disabled: true
-    filesystem_confined_to_snapshot: true
-    symlink_audit: passed
-    inline_test_detector: language-aware
-    inline_test_audit: passed
-
-budget:
-  primary_discovery:
-    call_limit: 48
-    elapsed_limit_seconds: 1800
-    repository_inspection_calls_used: 24
-    elapsed_seconds: 280
-    authority_gate:
-      call_limit: 6
-      elapsed_limit_seconds: 60
-      repository_inspection_calls_used: 5
-      elapsed_seconds: 43
-  blind_inventory:
-    call_limit: 24
-    elapsed_limit_seconds: 240
-    repository_inspection_calls_used: 18
-    elapsed_seconds: 211
-  comparison:
-    call_limit: 10
-    elapsed_limit_seconds: 120
-    repository_inspection_calls_used: 7
-    elapsed_seconds: 104
-  revision:
-    call_limit: 4
-    elapsed_limit_seconds: 60
-    repository_inspection_calls_used: 3
-    elapsed_seconds: 52
-  final_receipt:
-    tool_call_limit: 0
-    elapsed_limit_seconds: 60
-    tool_calls_used: 0
-    elapsed_seconds: 19
-
-reviewer_checkpoints:
-  - id: checkpoint-deployment-artifacts
-    bucket: deployment-artifacts
-    captured_in_private_scratch: true
-    payload_bytes: 8192
-    payload_limit_bytes: 24576
-    observation_ids: [blind-checkout-artifact]
-    coverage_ledger_id: coverage-deployment-artifacts
-    inspection_calls_used: 5
-    elapsed_seconds: 43
-  - id: checkpoint-runtime-state-dependencies
-    bucket: runtime-state-dependencies
-    captured_in_private_scratch: true
-    payload_bytes: 8192
-    payload_limit_bytes: 24576
-    observation_ids: [blind-checkout-runtime]
-    coverage_ledger_id: coverage-runtime-state-dependencies
-    inspection_calls_used: 8
-    elapsed_seconds: 82
-  - id: checkpoint-interfaces-egress
-    bucket: interfaces-egress
-    captured_in_private_scratch: true
-    payload_bytes: 4096
-    payload_limit_bytes: 24576
-    observation_ids: [blind-checkout-interface]
-    coverage_ledger_id: coverage-interfaces-egress
-    inspection_calls_used: 3
-    elapsed_seconds: 31
-  - id: checkpoint-gap-checks
-    bucket: gap-checks
-    captured_in_private_scratch: true
-    payload_bytes: 4096
-    payload_limit_bytes: 24576
-    observation_ids: [blind-checkout-gaps]
-    coverage_ledger_id: coverage-gap-checks
-    inspection_calls_used: 2
-    elapsed_seconds: 25
-
-coverage_ledger:
-  - id: coverage-deployment-artifacts
-    bucket: deployment-artifacts
-    phase: blind-inventory
-    scope: deployment-and-artifact-pipelines
-    status: covered
-    checkpoint_id: checkpoint-deployment-artifacts
-    scanned_roots: [infra, deploy, .github/workflows]
-    evidence_ids: [ev-prod-checkout-deploy, ev-checkout-image-ci]
-    inspection_calls_used: 5
-    uncovered: []
-  - id: coverage-runtime-state-dependencies
-    bucket: runtime-state-dependencies
-    phase: blind-inventory
-    status: covered
-    checkpoint_id: checkpoint-runtime-state-dependencies
-    scanned_roots: [apps/checkout]
-    evidence_ids: [ev-orders-db-client]
-    uncovered: []
-  - id: coverage-interfaces-egress
-    bucket: interfaces-egress
-    phase: blind-inventory
-    status: covered
-    checkpoint_id: checkpoint-interfaces-egress
-    scanned_roots: [apps/checkout]
-    evidence_ids: [ev-order-topic]
-    uncovered: []
-  - id: coverage-gap-checks
-    bucket: gap-checks
-    phase: blind-inventory
-    status: covered
-    checkpoint_id: checkpoint-gap-checks
-    scanned_roots: [apps, infra, deploy]
-    evidence_ids: [ev-prod-checkout-deploy]
-    uncovered: []
-
-blind_observations:
-  - id: blind-checkout-artifact
-    subject_ids: [checkout-image]
-    assertion: The application image is built through the production pipeline.
-    sources:
-      - path: .github/workflows/build.yml
-        anchor: jobs.build-checkout
-        kind: workflow-key
-        locator_kind: manifest-key
-  - id: blind-checkout-runtime
-    subject_ids: [checkout-http-role]
-    assertion: The checkout runtime role reaches the selected state dependencies.
-  - id: blind-checkout-interface
-    subject_ids: [checkout-http]
-    assertion: The selected checkout interface is externally reachable.
-  - id: blind-checkout-gaps
-    subject_ids: [commerce-platform]
-    assertion: The bounded gap scan found no uncovered selected production scope.
-
-comparison_findings:
-  - id: review-prebuilt-image-bypasses-head
-    kind: artifact-bypasses-verification-commit
-    subject_ids: [checkout-image]
-    evidence_ids: [ev-self-host-compose]
-    resolution: accepted
-    resolution_evidence_ids: [ev-checkout-image-ci]
-    note: Replaced the fixed image with the commit-built artifact.
-
-phase_receipts:
-  - id: phase-comparison
-    phase: comparison
-    status: completed
-    budget_path: budget.comparison
-    payload_bytes: 4096
-    payload_limit_bytes: 24576
-  - id: phase-revision
-    phase: revision
-    status: completed
-    budget_path: budget.revision
-    payload_bytes: 2048
-    payload_limit_bytes: 24576
-  - id: phase-final-receipt
-    phase: final-receipt
-    status: completed
-    budget_path: budget.final_receipt
-    payload_bytes: 2048
-    payload_limit_bytes: 24576
-
-termination:
-  reason: completed
-  phase: final-receipt
-  identity_stabilization:
-    source_manifest_digest: sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
-    census_record_digest: sha256:123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0
-    source_files_total: 412
-    source_files_scanned: 412
-    sweeps:
-      - id: identity-sweep-1
-        source_manifest_digest: sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
-        source_files_scanned: 412
-        new_runtime_identity_count: 0
-        new_state_identity_count: 0
-        new_external_identity_count: 0
-        new_selector_family_count: 0
-        new_selector_entry_count: 0
-      - id: identity-sweep-2
-        source_manifest_digest: sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
-        source_files_scanned: 412
-        new_runtime_identity_count: 0
-        new_state_identity_count: 0
-        new_external_identity_count: 0
-        new_selector_family_count: 0
-        new_selector_entry_count: 0
-
-validation:
-  command: haystack skills validate-universe --json
-  status: passed
-  validator_contract_revision: 39
-
-status: pass
-blocking_items: []
-```
-
-`inventory_closure_audit` is independent of production authority and is
-mandatory on every receipt. Use `status: deferred` with a nonempty `reason`
-only while at least one inventory-closure category remains partial; omit all
-completed-audit fields on that path. A completed audit uses one durable,
-read-only, repository-only customer-CLI subagent with no descendants, the same
-mechanically isolated snapshot contract, and at most 48 repository-inspection
-calls or 600 elapsed seconds. `reviewed_categories` is exactly
-`runtime-roles`, `stateful-resources`, and `external-dependencies`.
-`reviewed_candidate_ids`, `reviewed_registry_ids`,
-`reviewed_registry_entry_ids`,
-`reviewed_registry_entry_category_link_ids`, and
-`reviewed_registry_edge_ids` must be exact set matches, not samples. Entry-link
-IDs are derived as `<entry-id>-link-<kebab-category>`; edge IDs are
-`<entry-id>-to-<child-registry-id>`.
-
-The completed receipt also has exactly one `candidate_reviews` row for every
-candidate, one `state_owner_reviews` row for every final resource, one
-`external_backing_state_reviews` row for every final external dependency, one
-`registry_entry_category_link_reviews` row per derived link,
-one `registry_leaf_reviews` row per declared leaf, and one
-`consumer_edge_reviews` row per exact inventory-subject/runtime-role pair.
-Candidate rows repeat the final `mapped` or `excluded` disposition and, when
-excluded, the final `declared_exclusion_basis`. State-owner rows repeat the
-final owner basis and cite the same atomic owner claim. External rows repeat
-the final backing-state disposition, basis, operation, and named remote-state
-identity key when present, and cite the same typed boundary claim. Category-link rows repeat the final
-disposition, candidate ID or not-applicable basis, and leaf and consumer rows
-  repeat their exact structured identities and activation. Every row records a
-  verdict, a nonempty reason, and atomic evidence with the claim kind and
-  inspection scope required by the declaration it reviews. A corrected verdict
-  invalidates that pass: reconcile the artifacts, keep closure partial, and run
-  a new blind audit in a fresh independent session. The completed final receipt
-  sets `final_artifacts_unchanged_since_blind_inventory: true`, contains only
-  `confirmed` rows, and has `findings: []`. The independent auditor reopens the
-  final generated inventory, registry, reproduction, and closure artifacts,
-  rather than certifying only the earlier source census. Artifact immutability
-  never converts an unreviewed or discrepant 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. These rows make the audit
-  decision-bearing rather than an exact-ID checklist. Any remaining
-  `remote-ownership-unproven` result requires partial state closure.
-
-Every finding on a superseded or partial audit has a stable ID, nonempty kind,
-exact candidate, registry, and registry entry ID lists, nonempty evidence, and a
-`resolved` or `unresolved` disposition. When no existing ID can represent a newly
-found gap, the finding instead records nonempty `scope`; reconciliation must add
-the resulting stable IDs before a fresh audit can certify closure. A resolved
-finding includes a concise exact-ID `resolution`. A completed final audit has no
-findings, including historical resolved ones.
-
-`budget.primary_discovery` is required for every receipt. Calls used are
-non-negative integers; elapsed values are non-negative finite numbers. The
-nested authority-gate limits and usage cannot exceed their primary-discovery
-totals. The baseline `call_limit` is 48. Larger limits are selected in 48-call
-waves with a nonempty, unique `extension_triggers` list drawn from
-`unresolved-structured-registry`, `unresolved-launch-surface`,
-`unresolved-state-provider`, `unresolved-egress-client`,
-`retained-source-scale`, `omitted-production-source`, and
-`closure-contradiction`. Omit the list at 48. Passing receipts must remain within
-the selected call limit, the 1800-second total, and the 6-call/60-second authority
-ceilings. Blocked receipts may record an overrun only when each exceeded budget
-path is linked by a `kind: budget-exhausted` blocker as shown above.
-Calls 48, 96, and 192 are checkpoints, not terminal cutoffs for an unresolved
-identity frontier. `inventory-complete` requires a matching deterministic
-identity-census receipt, exact one-time reconciliation of every presumptive
-operational and registry record, no pending inventory candidate, complete
-operational and selector censuses, and complete receipts for all four
-operational frontiers. Materialization and production
-authority and registry semantics may remain partial. `final-receipt`, not
-`inventory-complete`, forbids `trace_status: identity-complete`,
-`category_projections`, and unresolved category-link/child-registry decisions. Its
-`termination.identity_stabilization` binds `source_manifest_digest`,
-`census_record_digest` equal to the deterministic census receipt's
-`second_record_digest`, equal
-`source_files_total` and `source_files_scanned`, and exactly two `sweeps` to the
-same manifest. Each sweep repeats the digest and scanned count and reports zero
-new runtime, state, external, selector-family, and selector-entry identities.
-These are consecutive source-wide sweeps, not repeated reads of one frontier.
-Missing hosted-production authority defers
-production review; it does not authorize early termination of repository
-discovery.
-
-`budget.blind_inventory.call_limit` uses a 24-call baseline and may extend in
-24-call waves. Each selected wave adds up to 240 seconds to its elapsed limit.
-Continue while an exact blind identity frontier is open and finish only after
-two consecutive source-wide blind sweeps add no new exact identity. Persist and
-split stable-ID-sorted checkpoints rather than dropping observations at the
-24 KiB payload boundary.
-
-Coverage status is `covered`, `partial`, or `uncovered`. Keep
-`blind_observations` repository-derived and separate from findings about the
-revealed candidate. Send and persist one blind checkpoint and one compact
-comparison delta per bucket; do not ingest the full candidate YAML in one
-reviewer message. Keep each checkpoint, projection chunk, and delta below
-24 KiB. Split oversized projections by sorted stable ID within the same total
-budget; never fall back to full YAML.
-
-A passing receipt contains one checkpoint and one covered ledger entry for
-each of `deployment-artifacts`, `runtime-state-dependencies`,
-`interfaces-egress`, and `gap-checks`. Each checkpoint is captured in private
-scratch, has positive `payload_bytes` no greater than its declared limit or
-24576, and links to its ledger by stable ID. The ledger links back, has nonempty
-normalized `scanned_roots` and evidence, and has `uncovered: []`. It also
-contains completed, bounded `phase_receipts` for comparison, revision, and the
-final receipt. These records prove that the phases were recorded; they do not
-establish materialization readiness.
-
-Allowed finding kinds include:
-
-- `omitted-service`, `omitted-resource`, `omitted-interface`, `missing-edge`,
-  and `missing-consistency-group`;
-- `phantom-component`, `unstable-id`, `weak-evidence`, and `conflict`;
-- `non-production-topology-promoted`, `missing-authoritative-source`, and
-  `fidelity-ceiling-overstated`;
-- `artifact-bypasses-verification-commit` and
-  `production-recipe-equivalence-unproven`;
-- `optional-profile-promoted`, `collapsed-structured-identity`, and
-  `unbounded-external-enumeration`.
-
-Finding resolution is `accepted`, `rejected`, or `unresolved`. A blocking item
-that comes from review includes exact `finding_ids`; they must resolve to
-`comparison_findings` IDs.
-
-Use `termination.reason: completed` only when the bounded protocol finishes.
-Use `review-budget-exhausted` for an elapsed or call cutoff with material gaps.
-Use `reviewer-quota-exhausted` for a CLI quota, usage, or context limit. Preserve
-partial checkpoints and never replace the reviewer.
-
-Also block on `reviewer-subagent-unavailable`,
-`reviewer-session-not-resumable`, `test-path-isolation-unavailable`,
-`reviewer-test-path-isolation-unavailable`, provisional scope, missing required
-production authority, unresolved findings, unproven artifact claims, or any
-universe unresolved item.
-
-Set `status: pass` only when a real read-only subagent inspected the repository
-in one durable resumable session within all budgets; source isolation was
-mechanically enforced; all ledger scopes are covered; all findings are resolved
-with evidence; application scope is confirmed; artifact and reproduction claims
-meet this contract; and no blocker remains. A passing validator establishes
-contract consistency, not inventory completeness or hermeticity.
-
-Every passing or provisional receipt records the exact command
-`haystack skills validate-universe --json`, `validation.status: passed`, and
-the JSON result's `validator_contract_revision`. A missing field, different
-command, non-passing status, or revision mismatch means the receipt or installed
-validator is stale and validation must not be accepted.
-
-When an independent evaluation reports precision or recall, a zero denominator
-is `undefined`/`null`, never 100%. Keep the numerator and denominator beside the
-rate so an empty mapper output cannot be presented as perfect precision.