Retained deployed baseline
The October 20 rollout record identifies v0.10.2, sourceb1f7aa9, with two ready API
replicas and two ready dashboard replicas. Its checks covered health, database/signing,
public rendering, and unauthenticated private-route denial. They submitted no partner
orders and did not establish a real signed-in customer journey or ERP acceptance.
These images were locally built/pushed through the maintained fallback. They are not
GitHub OIDC-signed release artifacts. Hosted release CI remained blocked by account
billing/spending limits in the retained record.
The database reached migration 71 after an isolated logical restore and upgrade check.
Rollback used a separately tested compatibility image containing the newer migration
files; the previous unmodified image is not the qualified rollback target. Keep the expanded
schema rather than assuming migrations can be reversed.
Newer release-assurance source
Commits after that deployed tag add migration-before-rollout enforcement, backup failure handling, and exact-image release promotion. The maintained deploy helper verifies the requested release identity and digests;--verify-only does not deploy or migrate.
stateset-edi migrate needs a nonempty DATABASE_URL;
a failed migration is not a successful file-mode startup.
The prepared hosted workflow gates publication on CI, builds a candidate once, scans its
immutable digest, runs a sustained capacity profile, signs/verifies that digest, and promotes
the same manifest. Source implementation is not evidence that the hosted workflow ran or
that the deployed fallback images gained signatures.
Capacity evidence
An isolated five-minute run used the exact digest-pinned deployed API image: two API containers at two CPUs/512 MiB each, plus PostgreSQL 16 at two CPUs/1 GiB. It accepted 7,500 synthetic orders across two tenants at 25/s, with 1/10/100-line payloads, p95 scheduled offer latency 18.142 ms, and a 4.758-second backlog drain. Duplicate/billing and tenant-key checks passed. Durability settings remained enabled. The host was shared; an earlier development-binary run failed the same offered workload and is retained. These results do not establish maximum throughput, production capacity, ERP performance, or a customer SLO. The test used synthetic effects and no partner/ERP accounts. Later harness safeguards have separate smoke evidence.Recovery and secrets
Retained drills cover process loss, logical restoration, and isolated physical PITR with 58 tables and encrypted credential revisions. Recover the matching connection-encryption key, signing identity, transport credentials, and retained revisions alongside the database. A green health check cannot establish that encrypted pending work can be resumed. The optional logical-backup CronJob template validates a private custom-format archive before atomic publication and keeps seven completed archives. The retained production inspection found that optional CronJob absent; CloudNativePG base backup/WAL and the verified pre-upgrade logical snapshot are the production recovery evidence. A template change does not install a schedule or measure production RPO/RTO.Remaining qualification
Actual partner-guide acceptance, ERP create/change/cancel and remote-commit recovery, independent WorkOS signup/revocation, production failure/load/restore objectives, independent security review, and staffed support/on-call commitments need their own evidence. Console response-loss/401/reload recovery in source3f6b5c0 is locally qualified,
not established as deployed. See orders and recovery.