Audit follow-up release result — 2026-09-22

The seven-stage release has passed implementation, integration, exact-commit CI, merge and production acceptance. HeyAira now has a deployed continuity backend plus an explicit supervised execution path through the installed Bridge. It is a credible controlled pilot; this evidence does not establish unattended general-purpose orchestration or arbitrary AI-result correctness.

Plan and completed sequence

The plan and dependencies were recorded in HeyAira memory f76c9ca9-9d26-41b9-97a7-e9904958fd7d under parent task b3257d03-2e13-446e-a317-c3721023b206. Each implementation slice has its own branch, commit, task receipt and RESULT memory.

Stage	Outcome	Task
REL-01	Bounded, UTF-8-safe streamed output, split-marker handling, timeout/error preservation	c412db24-86bb-476f-8a66-9e44a697ae4f
REL-02	Mandatory complete PostgreSQL CI and corrected runtime fixture	27c03dc5-fa2f-470a-bf15-9009efb7743c
REL-03	Enforced lease/fence lifecycle and effective pinned provider profiles	73c76602-2a27-4687-8a8b-f2d38ad82245
REL-04	Authorized execution offers, atomic claims, renewals, cancellation and terminal receipts	774dd8db-1749-4870-b0dd-dee9ae5835e8
REL-05	Real Bridge execution, Git workspace checks and accepted Work Center integration	75c44315-223e-49fc-87d4-77803d66dab4
REL-06	Disconnected MCP-client handoff, negative verification control and real provider acceptance	4fdfeae2-5f25-41ad-b778-b294e62b3862
REL-07	Merged code, guarded production rollout, installed Bridge and live acceptance	c0d93a1e-099f-48e5-b30e-d71b2bdba89c

Two additional defects were reproduced during final acceptance and corrected before merge: concurrent server/backup startup could apply a migration twice, and cancellation could exit the Bridge command before inactive session metadata was persisted. Regression tests cover both observed failures.

Released artifacts

• Server PR #24: merge and deployed revision 99c1b04f2a24c625442316c9273fa0d967b76271; previous production 2fa913a521c01625406d2c80ff8249b2ff362d1c remains the rollback source.
• Bridge PR #2: merge 18c8b14d2bd5379189f558cf9511334601082401 into codex/bridge-project-awareness, installed on the authorized macOS host.
• Installed Rust binary SHA-256: c35a6ac1bb1a697b70aef8fcc236bcd25c4a47aac3725731c9db51d54c17a6ae. It matches the release build. The package's displayed version is still 0.0.9; exact commit and binary digest are the release identifiers here.
• Deployment used the existing immutable guard and mandatory ops/openbao-production-compose.yaml, with a clean standalone exact-SHA source checkout and healthy backup preflight. No DNS, GitHub settings or unrelated infrastructure were changed. The existing retention container was preserved.

This report is a documentation-only follow-up. Its Git commit is not a claim that another backend image was deployed after 99c1b04.

Actual validation

Gate	Actual result
Full server suite, disposable PostgreSQL 16	252 passed in 10.23s locally; zero skipped
Exact merged server CI	Run 35767184598: success; 252 passed in 20.00s
Exact merged documentation CI	Run 35767184402: success; published site checks also passed
Exact merged Bridge macOS CI	Run 35767217363: success; 82 Rust tests, formatting, strict clippy, Swift warnings-as-errors and Work Center model tests
Provider/profile acceptance	Actual authenticated Codex and Claude CLI processes, structured response checks, clean Git base and one receipt per run passed
Real-provider cancellation regression	1 passed in 21.04s; cancellation, nonzero command exit and inactive persisted metadata confirmed
Cold MCP handoff	Separate producer/consumer processes, Git object/digest validation and a negative digest control passed in mandatory server CI
Website consent tests	12 passed
Production deployment	health=passed; runtime_revision=99c1b04f2a24c625442316c9273fa0d967b76271
Public and loopback route canaries	10/10 passed on each surface, including unauthenticated execution-route rejection
Authenticated production execution	Passed through public HTTPS using the installed Rust binary; exit 0, one receipt, task not automatically completed
Synthetic cleanup	synthetic_project_cleanup=passed; only the exact synthetic project UUID/name was deleted
Normal installed Bridge	Doctor, project catalog and Work Center snapshot succeeded; one native app process and one Bridge daemon
Backup health after deployment	healthy=true, all three alerts false, empty reasons at 18:33:47 UTC

Production execution evidence identifier: f2664119-ed55-4bd3-9403-1370bf188166. Its fixture was deleted after readback. The production canary seeds a temporary reviewed identity and short-lived transport token; it does not retest fresh Ed25519 enrollment. It uses the fixed synthetic provider. Real Codex/Claude acceptance was performed against the local real HTTP/PostgreSQL stack before deployment.

The macOS installer initially exited with launchd bootstrap error 5, including its one-second retry. A later bootstrap of the same installed plist succeeded; subsequent checks found exactly one app and daemon and successful authenticated reads. This release did not modify the installer to eliminate that transient failure. Longer bounded retry and better error reporting remain useful operational follow-up work.

Reproduction entry points are scripts/test_postgres.py, scripts/verify_bridge_routes.py, scripts/production_execution_canary.py, acceptance/README.md, and the Bridge repository's documented Rust/Swift checks. The production canary requires explicit production authorization and exact instance/revision arguments; use only synthetic data.

Assessment and next priorities

The strongest part of the solution is explicit, attributable state: project identity, optimistic task versions, Git references and work receipts survive a client session. The new execution path connects this state to an actual local process while preserving operator choice, project/node boundaries and bounded leases. That is a useful foundation for a controlled pilot.

The principal unrealized value is the gap between that foundation and an ordinary user's complete workflow. Starting execution still requires the explicit command/API path. A successful process or stored receipt cannot by itself prove an arbitrary requested result. Historical status documentation also accumulated contradictory deployment claims; the top release matrix in PROJECT_STATE.md now takes precedence over those preserved historical notes.

Recommended order for subsequent work:

1. Complete the existing live ChatGPT-to-Claude MCP acceptance task 635f5069-0529-42e7-aaf1-611a7e6069d5. Deterministic disconnected Python MCP clients and provider CLI tests do not replace those client surfaces.
2. Add an explicit native launch/cancel flow over the already tested execution contract, with a visible profile, workspace and expected outcome. Improve installer retry diagnostics and expose the exact build revision.
3. Define result verification per task type: immutable code reference, actual test evidence and a separately attributable acceptance decision. Start with one narrow workflow before broadening it.
4. Run a measured pilot: time to recover context, handoff success, stale claim rejection, duplicate receipts, cancellation latency and time saved. The current tests prove behaviors, not commercial adoption or quantified ROI.
5. Consider scheduling, routing, multi-node execution and broader mobile workflows only after the pilot identifies demand and the supervised path is easy to operate. These are future capabilities, not delivered features.

The release gates are green. The separate live-client acceptance, generalized verification, native execution launch and automatic routing remain explicitly outside the delivered release; no claim of universal project completeness is made.