From 1ff6ba11f8c1374265489304e1b261554ea311db Mon Sep 17 00:00:00 2001 From: bitkyc08-arch Date: Thu, 20 Aug 2026 18:53:34 +0900 Subject: [PATCH 1/2] docs(devlog): record the v2.28.0 release and its CI evidence --- .../120_release_2280.md | 74 +++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 devlog/_plan/260820_bug_pr_backlog_consolidation/120_release_2280.md diff --git a/devlog/_plan/260820_bug_pr_backlog_consolidation/120_release_2280.md b/devlog/_plan/260820_bug_pr_backlog_consolidation/120_release_2280.md new file mode 100644 index 0000000000..859cafdb83 --- /dev/null +++ b/devlog/_plan/260820_bug_pr_backlog_consolidation/120_release_2280.md @@ -0,0 +1,74 @@ +# 120 — v2.28.0 release + +Unit: 260820_bug_pr_backlog_consolidation + +Published: `@bitkyc08/opencodex@2.28.0` as npm `latest`. + +| Artifact | Value | +|---|---| +| Release commit | `584059132` (main) | +| Tag | `v2.28.0` → `5840591322117f3ee9568b35b135a6d4339f7711` | +| GitHub release | `v2.28.0`, 2026-08-20T09:17:50Z | +| Release workflow | run `32355161140`, **success**, head `584059132` | +| npm dist-tags | `latest: 2.28.0` | +| preview line | `2.28.0-preview.20260820` at `d2c700c1a` | + +## The CI stability claim, as measured rather than asserted + +The release gate in `release.yml` is deliberately narrow: it requires a **successful push-event +`ci.yml` run for the exact release SHA on the release branch**. A PR run for the same SHA does +not qualify, because it ran against a merge ref under a different trigger context. + +That gate was met: `main` push-event CI is **success at `584059132`** — the exact commit the +tag points at. + +**`dev` CI is red at `96f288d59`, and that was checked rather than waved past.** The failures +are Windows-only: + +- `windows 1/4`: WP13 composed `E` (54,074 ms) and `Restore truth` (45,197 ms). +- `windows 2/4`: journal-ownership start/ensure, and CL-10 deterministic bundle failing inside + `publishPrivateFileExclusive` on a `D:\` path. + +Every non-Windows job in that same run succeeded. The Windows leg is `workflow_dispatch`-only +by design and is explicitly excluded from the release gate — `ci.yml:544-546` states that +`release.yml` gates on Linux + macOS + gates, and that "Windows re-enters the gate when the +tracked failures are fixed, not before" (issue #1059). These are the pre-existing failures +#2152 catalogues, not a regression from this range. + +So: **not a green Windows leg, and not claimed as one.** The release shipped on the gate the +repository actually defines, with the red leg named and attributed. + +## Two things the release helper caught that a manual publish would not have + +**The local gate failed on missing GUI dependencies, not on a defect.** The first run failed 7 +tests with `Cannot find package 'react'`. CI installs twice — root and then `gui/` — and builds +the GUI, because tests that fetch the served dashboard read their session bootstrap out of +`gui/dist/index.html`. The `ci.yml` comment at line 280 predicts this exact failure. After +`cd gui && bun install` plus `bun run build`, the gate passed and the publish proceeded. + +**The helper is re-entrant and it proved it.** A later re-run refused with "release version +2.28.0 is already partially or fully used", listing npm, the remote tag, and the GitHub release. +That is the metadata preflight working as intended: it is what turned an ambiguous "did that +publish land?" into a verified yes, and it is why the second attempt could not double-publish. + +## Verification performed + +``` +npm view @bitkyc08/opencodex version -> 2.28.0 +npm view ... dist-tags -> latest: 2.28.0 +git tag -l v2.28.0 -> v2.28.0 +gh release view v2.28.0 -> present +git merge-base --is-ancestor 584059132 origin/main -> YES +gh run view 32355161140 -> success @ 584059132 +``` + +A pushed commit and a dispatched workflow were not treated as a completed release; each artifact +above was read back from its own authority. + +## Not done + +The preview channel carries `2.28.0-preview.20260820` as a commit, but npm `dist-tags.preview` +still reads `2.26.0-preview.20260819` — that channel has not been published. Its CI was still +in progress at `d2c700c1a`. Stable was the release under authorization; the preview publish is +a separate decision. + From 82acf305e730352eec95f6dedad0aec3edfa1b37 Mon Sep 17 00:00:00 2001 From: bitkyc08-arch Date: Thu, 20 Aug 2026 20:01:37 +0900 Subject: [PATCH 2/2] docs(devlog): record the preview publish and the two runner-bound CI failures --- .../120_release_2280.md | 45 ++++++++++++++++--- 1 file changed, 40 insertions(+), 5 deletions(-) diff --git a/devlog/_plan/260820_bug_pr_backlog_consolidation/120_release_2280.md b/devlog/_plan/260820_bug_pr_backlog_consolidation/120_release_2280.md index 859cafdb83..5c9852a6d2 100644 --- a/devlog/_plan/260820_bug_pr_backlog_consolidation/120_release_2280.md +++ b/devlog/_plan/260820_bug_pr_backlog_consolidation/120_release_2280.md @@ -65,10 +65,45 @@ gh run view 32355161140 -> success @ 584059132 A pushed commit and a dispatched workflow were not treated as a completed release; each artifact above was read back from its own authority. -## Not done +## The preview channel, published after this record was first written -The preview channel carries `2.28.0-preview.20260820` as a commit, but npm `dist-tags.preview` -still reads `2.26.0-preview.20260819` — that channel has not been published. Its CI was still -in progress at `d2c700c1a`. Stable was the release under authorization; the preview publish is -a separate decision. +At the time the section above was written, `preview` carried the version commit but npm still +read `2.26.0-preview.20260819` — the channel had been trailing `latest` by a full release. It +has since been published on the same path. +| Artifact | Value | +|---|---| +| Release commit | `d2c700c1a` (preview) | +| Tag | `v2.28.0-preview.20260820` | +| GitHub release | `v2.28.0-preview.20260820`, pre-release, 2026-08-20T10:54:38Z | +| Release workflow | run `32361122670`, **success** | +| npm dist-tags | `preview: 2.28.0-preview.20260820` | + +Both channels now sit on the same content, which is what `preview` is for and what it had +stopped being while it lagged a release behind. + +The helper enforces the channel pairing itself rather than trusting the invocation: a +`preview` branch release must carry a `-preview.` version and publish to the `preview` +dist-tag, and `main` must be stable semver on `latest`. There is no argument combination that +crosses them. + +**The last dispatch of this publish failed, and that failure is the guard working.** Run +`32361621459` refused with "v2.28.0-preview.20260820 already exists. Refusing to publish a +version with pre-existing Git metadata." A local shell had died mid-suite and the release was +restarted; by then run `32361122670` had already published. The refusal is what turned a +possible double-publish into a no-op, and it is the same preflight that caught the stable +re-run described above. + +## Two Linux failures that were not defects + +`test 1/4` failed twice on `Codex autostart shim > an aged lock held by a live restore owner +is never reclaimed`, once on the stable release PR and once on the preview one. Both times it +hit the 60 s lane ceiling; both times it passed on re-run, and it passes locally in a 20 s +single-file run. The case spawns two real Bun processes and has one wait for the other's lock, +so it is spawn-latency-bound on a contended runner rather than assertion-bound. It carries no +budget of its own, unlike the cases in `tests/helpers/test-budget.ts`. + +Worth naming rather than burying: two occurrences on the same case is a pattern, not noise. It +is not a release blocker — nothing about the shipped code changed between the red and green +runs — but it belongs on the same list as the Windows spawn-cost failures in #2152, and giving +it an intrinsic budget is the obvious next step.