Binary-plane deployment rehearsal

The standalone devops/compose/docker-compose.binary-fold.scratch.yml runs PostgreSQL, a local fixture HTTP server, Vulnerabilities Web and Vulnerabilities Worker. It has no retiring BinaryIndex or Symbols host. Its internal network has no external route. An owned host relay binds ephemeral loopback listeners and forwards raw HTTP and PostgreSQL bytes through docker exec on the fixture container. Docker itself publishes no ports: internal bridge networks can suppress those bindings. Supply immutable local image IDs for all four services. The PostgreSQL 18 data directory uses tmpfs; symbol CAS and public fixtures use explicitly owned directories below the primary checkout’s devops/data/.

Use tools/scripts/deploy/rehearse-binary-fold.ps1 with an explicit PrimaryRoot, SourceRoot and unique bin8-* prefix. Run its phases in this order:

  1. prepare provisions private custody through Stella Ops cryptography and writes a measured ELF, APK and repository index. It refuses existing preparation directories.
  2. start takes SourceCommit, WebImage, WorkerImage, PostgresImage and FixtureImage. It checks clean source provenance in both application images and runs the Compose isolation checker before starting exactly four owned containers and their loopback relay. connect attaches the relay to an already running owned stack.
  3. arrange-posture writes the controlled sealed-installation fixture through the existing catalog replica store. restart-worker then recreates only the pinned scratch Worker to apply the fixture-only egress policy and start an ingestion cycle. This is explicit test data, outside runtime migrations; it does not prove Platform custody or authenticated catalog replication. The production posture reader and egress enforcement remain active and permit only fixtures:8080. This one-package rehearsal configures a ten-second analysis interval: ingestion and analysis have independent workers, so a first analysis pass can precede the first completed source generation. The standing estate retains its own cadence.
  4. verify runs real HTTP authentication rejection, Worker package ingestion, signed CLI index export, Scanner native matching, issuer fact admission and symbol CAS upload/catalog/query/address-resolution checks. Full failure details stay in the private directory; ordinary logs contain sanitized failure phases.
  5. restart-web, followed by verify, checks the original fact and symbol payload before replaying any writes. This prevents replay from concealing lost state.
  6. stop stops the owned relay and removes only the exact owned containers and network. It does not delete volumes or filesystem inputs.

The selected source checkout must already contain the current compiled CLI test driver. The lifecycle script runs Compose from the durable primary checkout. Never recreate a standing service from a worktree: Docker records the Compose chain path, which must remain usable after that worktree is retired. A new image requires force recreation; restarting an old container does not load rebuilt code or embedded migrations.

Worker liveness is /health/liveness; readiness is /health/readiness. Readiness executes a bounded query against its own configured PostgreSQL data source. It does not claim that upstream ingestion succeeded; the separate rehearsal proves actual corpus rows and consumer results. Existing estate health settings must be updated together with a compatible Worker image.

The host-side PostgreSQL fixture explicitly disables GSS encryption negotiation and uses its generated database password. Otherwise Windows can wait in ambient Kerberos negotiation before opening this isolated password-authenticated connection. No standing database authentication setting changes.

This rehearsal does not authorize changes to the standing estate or old-schema drops. Retirement follows the reviewed deployment plan after the consumer and persistence checks pass. The controlled fictional CVE in the fixture is a mechanics check and does not establish accuracy for a real vulnerability.