A Release Candidate Is a Testable Artifact

Beta 10 passed the longest 1.7 browser run we had performed. A fresh public wheel started a real co ai Host, accepted an invocation-scoped invite, drove O Chat through permission changes, built C and Rust projects, delegated another C project to native Codex, stopped and restarted the Host, reconnected without resending the prompt, and left fourteen screenshots for review.

Then the screenshot review found that the Work Room could still lose the thing that made it a client: its input box. The backend accounting review found a different boundary where measured cache usage could be preserved by the provider and then flattened before it reached the final outcome. Beta 10 was real evidence, but it was evidence for the bytes that existed before those fixes.

We had three tempting choices. We could keep making Betas even though the feature train was frozen. We could call the merged fixes stable because their unit tests passed. Or we could use a release candidate for what it is actually good at: giving every layer one immutable public version to test together.

RC1 takes the third path. Core, the React reader, and O Chat receive exact candidate identities. The Work Room keeps attributed user/provider messages and a provider-targeted composer in every lifecycle state; a blocked composer stays visible and says why. Managed usage keeps its normalized cache-read, cache-write, uncached-input, provider/model, pricing-tier, and server-cost fields. Neither statement counts as accepted merely because the code merged.

The gate now asks the candidate to do more than render reassuring text. A real installed co ai must drive the real co browser command through a catalog search and an actual attachment download. A strict report and fixture-side request log prove both operations independently of the model's prose. The same journey builds C, C++, and Rust work, invokes native Codex, switches modes, stops, restarts, and reconnects. It preserves sanitized logs, workspace checks, and hash-addressed desktop, tablet, and mobile screenshots.

The UI review is a separate gate because green automation cannot say whether a new user understands the page. Every frame is checked for a recognizable remote coding client, visible conversation and input, distinct thinking and active work, readable tool summaries, honest blocked states, and responsive layout. An unresolved Critical or High finding makes the evidence bundle ineligible.

This also explains why RC1 can exist while stable blockers remain. The missing Anthropic live authorization and the private backend repository's stopped GitHub Actions budget still prevent stable promotion. They do not make an immutable candidate less useful; they make one necessary. Once those gates are restored, they can test the same bytes everyone else installed instead of a moving branch.

The version-only checks pass 38 release and cross-repository assertions, the React candidate passes 141 tests, and the O Chat gate passes 183 unit tests plus its browser suite. Those numbers justify creating a candidate, not promoting one. Stable 1.7 is earned only if the exact RC survives the remaining provider, backend, platform, upgrade, rollback, provenance, security, and UI window without another code change.

An RC is therefore not a victory lap between beta and stable. It is a checksum for a claim the whole system still has to prove.