## Production Validation

Validated and deployed on `sec` on 2026-09-30 through the fail-closed
`deploy_capacity50.ps1` workflow.

- Baseline runtime image: `sha256:46f1cf1b92d1a7d93d06f690309d8c7eca45f64dc45ca310861c70fb419bb035`.
- Deployed runtime image: `sha256:17b21c62f559220cd60e7972826fb439e5538c7c9443c4fdd1c3615751de5f8d`.
- Active config SHA-256: `2cf2ac66b58f1b39c1e45dd0d562b9b6375be42fa2289cc9bbcbd1a310951ee7`.
- Rollback tag: `truf-local:runtime-pre-capacity50-20260930`.
- The additive `20260930_33_remote_assignment_capacity` migration and
  `reserved_bundle_bytes` backfill completed with zero null rows.
- Runtime health was `ACTIVE`/`READY`; runtime and edge had zero restarts and no OOM.
- Runtime control returned to `normal`; all bundle, projection, keycheck,
  quarantine, and unresolved-assignment counters were zero.
- The 64 MiB hard limit, 2 MiB baseline, global cap 50, 131072 keycheck items,
  and 128 MiB keycheck bytes were active.
- A production test user's cap was changed from 2 to 50 through typed admin,
  verified, and restored to 2. No test user retains the expanded cap.
- The active Windows worker contacted the new Worker API after rollout.
- The exact 50th-admitted/51st-refused behavior remains covered by the real
  PostgreSQL integration test; production was not flooded with synthetic work.

The live run also exercised rollback before cutover and after a rejected
migration precondition. Both restored the original image/config, healthy runtime
and edge, normal control state, and zero pipeline debt. The final workflow now
quiesces singleton pipeline workers and releases their exact fenced leases before
the schema migration.