docs(devlog): record the v2.28.0 release and its CI evidence

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.
+