A green release status sounds like a simple answer: the software is ready. In this rollout, it left a question unanswered. Had the release actually produced the coverage report we expected?
It had not. Coverage had run out of memory twice. The workflow then ran the tests without coverage and completed successfully. That fallback had its own purpose, but its success did not establish that a report existed.
“Done” becomes more useful when the next person can see exactly what was demonstrated.
Why this matters outside the build log
A developer needs to know whether a change can be reviewed. A release owner needs to know which image passed which checks. A user needs to know whether the normal interface can turn their saved work into a working application.
Those questions connect, but one status cannot answer all of them. Mixing the answers together makes a handover sound complete while leaving someone else to discover what was never checked.
Find the gap. Keep the standard.
The release workflow built the application before collecting coverage. Generated .next output was entering the coverage collection. A successful report from a clean local checkout therefore had not reproduced the conditions of the release job.
The correction excluded generated build output. It preserved the intended source coverage, test selection and thresholds. We also made an oversized-file test fixture faster to prepare and bounded full-suite CI concurrency to two workers.
The resulting release produced the complete coverage report on its first coverage attempt. It contained 3,114 source, configuration and script paths, with no generated .next entries. The original report archive was retained, its files checked, and the aggregate metrics recomputed from the underlying data.
A complete report can show an incomplete job
Coverage completeness and coverage percentage are different things. The report made the remaining work visible:
| Measure | Observed coverage |
|---|---|
| Lines and statements | 31.52% |
| Functions | 54.28% |
| Branches | 76.22% |
The existing advisory targets for lines, statements and functions remained unmet. Producing the report did not erase those gaps. It gave us a baseline for choosing useful follow-up work.
Follow the artifact into a real user journey
We then used the exact qualified image in two replicas of a disposable local tenant. An ordinary owner submitted a second generation of an application through the project interface. A new job reached LIVE, and the owner opened the application and saw “Generation two.”
The primary container stayed healthy through 30 samples over just more than five minutes, with a stable image and zero restarts. That is a bounded local observation. Shared-environment activation remained open.
What we take forward
The expected benefit is less ambiguity at handover: a specific report, an identified artifact, and an observed user outcome. This run did not measure hours saved, cost reduction or incident reduction.
For an AI-assisted software factory, this is a useful habit to build into the process. Follow a claim from the change, through its checks, to the artifact and the user outcome. Then explain that connection in language the next person can use.
Evidence boundary. This is an author-reported internal rollout case, observed on 7 September 2026. Source logs and acceptance receipts remain in private Odin repositories. They are not independently inspectable from this article. Local live-service failures and an optional evidence-delivery check failure remain in that record; no all-green environment claim is made. The public experiments on this site are separately reproducible fixture runs and do not verify this internal case.