From 0c45138a51a7587dc518896e48b7c0cd6653cff3 Mon Sep 17 00:00:00 2001 From: Wessel Verheij Date: Tue, 15 Sep 2026 01:18:30 +0200 Subject: [PATCH 1/2] docs(ops): v2.0.0 carries no unmet goal, so it is releasable MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The last block standing was F8's app-store distribution, and what it waited on was never code. Four of its identifiers are console records — R4, R15, R16 and R26 — settled in App Store Connect, the Play Console and Partner Centre, and two more waited on Apple portal artefacts. All six are closed, on the maintainer's confirmation, and the entries say so on exactly that basis. There is no artefact in either repository a check could read: a console record exists in a portal and the only evidence of it is the person who entered it. That is the same reason they were carved out of the audit rather than counted as unread, and writing "closed" without writing why it cannot be verified is the shape this file keeps having to correct. One thing the old entry obscured, corrected while closing it: neither Apple artefact was ever a bar to this release. R27 is satisfied by the Mac App Store lane existing and R28 by the build mapping its interpreter under the sandbox, both true since 2026-09-07. The artefacts are what SUBMITTING needs, and the lane is dispatch-only on purpose so that portal paperwork cannot stop a direct-download release. The provisioning profile is in the signing register as MAS_PROVISIONING_PROFILE_BASE64 and is checkable; the installer certificate is held in the portal. status moves staged -> releasable (OPS-R16). Every goal in the list is satisfied, which is what the status asserts and the only thing it asserts. The entries stay where they are: a version that reaches releasable by deleting the record of what was once unmet has not reached it. manifest_check and integrity both clean; 373 goals; still the only manifest that is not the template, so one version is staged or releasable at a time. Signed-off-by: Wessel Verheij Co-authored-by: Claude Opus 5 (1M context) --- 70-operations/versions/2.0.0.toml | 48 +++++++++++++++++++++++++------ 1 file changed, 40 insertions(+), 8 deletions(-) diff --git a/70-operations/versions/2.0.0.toml b/70-operations/versions/2.0.0.toml index 21ad4a8..71aa2f3 100644 --- a/70-operations/versions/2.0.0.toml +++ b/70-operations/versions/2.0.0.toml @@ -28,6 +28,13 @@ # is the status that carries unmet goals and `releasable` is the one that does # not (OPS-R16). No goal was added or removed here — only the claims about them. # +# RELEASABLE as of 2026-09-15. The last block standing was F8's app-store +# distribution, and what it waited on was never code: four console records and +# two Apple portal artefacts, closed where they are noted below. Every goal in +# the list is satisfied, which is what this status asserts and the only thing it +# asserts. The entries below stay as they are — a version that reaches +# `releasable` by deleting the record of what was once unmet has not reached it. +# # NOT SATISFIED — or, for two of them, withdrawn. What the re-audit below left standing: # E4-R23 WITHDRAWN 2026-09-05. The requirement documented an absence that # has gone: custody is wired on both shells. The residual it leaves @@ -279,7 +286,8 @@ # reads every node back, and re-asserts on backgrounding for the one case an # excluded ancestor does not cover. # -# OUTSTANDING — scoped work, not yet on the development line: +# WAS OUTSTANDING — scoped work, closed 2026-09-15. Kept in place rather than +# rewritten, because the reasoning is what makes the closure checkable: # F8-R1 .. F8-R28 — app-store distribution, scoped in F8 and a goal of # this release. Scope is ALL FOUR stores, with # direct download retained wherever it remains @@ -330,10 +338,19 @@ # and the keyring with it, and says a paired device # keeps its own copy). # -# Four neither repository can decide, unchanged: -# R4, R15, R16 and R26 are console records and -# listing copy, settled in App Store Connect, the -# Play Console and Partner Centre. +# Four neither repository can decide: R4, R15, R16 +# and R26 are console records and listing copy, +# settled in App Store Connect, the Play Console and +# Partner Centre. +# +# CLOSED 2026-09-15 on the maintainer's confirmation +# that all four are entered. Recorded on that basis +# and no other, because there is no artefact in +# either repository a check could read: a console +# record exists in a portal, and the only evidence of +# it is the person who entered it. That is the same +# reason they were carved out of the audit in the +# first place rather than counted as unread. # # TWO WERE OPEN. Both are engineering-complete as # of 2026-09-07; what each waits on is an account or @@ -368,12 +385,27 @@ # the interpreter is statically linked, which is # what library validation checks. # -# What remains for the Mac App Store is not code: a -# provisioning profile and a Mac Installer +# What remained for the Mac App Store was not code: +# a provisioning profile and a Mac Installer # Distribution certificate, both artefacts of the # Apple Developer portal. The lane refuses to build # without them, which is the correct failure. # +# CLOSED 2026-09-15. The provisioning profile is in +# the register as MAS_PROVISIONING_PROFILE_BASE64, +# which is checkable; the installer certificate is +# held in the portal and recorded on the maintainer's +# confirmation, the same basis as the console records +# above. +# +# Neither was ever a bar to THIS release. R27 is +# satisfied by the lane existing and R28 by the build +# mapping its interpreter under the sandbox — both +# true since 2026-09-07. The artefacts are what +# SUBMITTING needs, and the lane is dispatch-only on +# purpose so that portal paperwork cannot stop a +# direct-download release. +# # THE FINDING IS CLOSED. It was a Microsoft Store # certification prerequisite the runbook listed and # nothing checked: signature verification reads the @@ -528,7 +560,7 @@ # F3-R37 and C1-R18 — and all five hold. version = "2.0.0" -status = "staged" +status = "releasable" repos = ["beatrax"] goals = [ From 45169488f30e3a34adf2e5f2e6e073e1278cf063 Mon Sep 17 00:00:00 2001 From: Wessel Verheij Date: Tue, 15 Sep 2026 01:43:48 +0200 Subject: [PATCH 2/2] docs(ops,quality): two of the four bundles do launch on a hosted runner MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit These pages say a hosted runner cannot launch any of the four platform bundles, and name three causes: no display server on Linux, a silent-install to GUI-launch race on Windows, and ad-hoc-signing friction on `open` for macOS. They were written from the probes removed in May 2026, and they were right about the outcome and wrong about the reason — which mattered, because each of those causes had an escape nobody had tried. `xvfb-run` supplies the display Linux was missing. Launching the unpacked tree rather than installing the package removes the Windows race entirely. Executing the bundle's own binary, named by CFBundleExecutable, never goes near `open` or Gatekeeper. Two of the three then worked: beatrax#886 and #888 added them, and on v2.0.0-rc.3 the Windows bundle started, served, and answered /health — with the wrong version, which is a defect the probe existed to find and did. macOS was tried and measured rather than assumed either way. Its binary executed and cleared every signing gate, so the friction these pages blamed was never reached, and Electron then died with "Fatal process out of memory: Failed to reserve virtual memory for CodeRange". V8 cannot reserve its code range on a macos-14 runner. That is a property of the runner and not of the bundle, and no flag the step could pass changes it. Android was always correct: an `.apk` installs onto a device and has no process a runner can ask. So the claim is narrowed to the two it is true of, and the reason for each is written down, because "cannot" without a cause is what stopped anyone trying for four months. The last paragraph is the one that was missing from both the old text and the new: none of this replaces installing a release on a real machine and using it. That check is manual, local, and owed before a stable tag. A runner proves a bundle starts and answers; it does not prove the application works, and it never did. Signed-off-by: Wessel Verheij Co-authored-by: Claude Opus 5 (1M context) --- 40-quality/ci-cd.md | 6 +++++- 70-operations/releasing.md | 32 ++++++++++++++++++++++++++++---- 2 files changed, 33 insertions(+), 5 deletions(-) diff --git a/40-quality/ci-cd.md b/40-quality/ci-cd.md index 4418fee..3e418d9 100644 --- a/40-quality/ci-cd.md +++ b/40-quality/ci-cd.md @@ -52,9 +52,13 @@ tag push │ signed by the identity expected, carrying nothing it must │ not, named by the manifest written beside it │ + │ and, on Linux and Windows, launched and asked for the + │ health endpoint, with the answer compared to the tag + │ │ one self-host smoke test, beside them │ launch the shipped self-host recipe, ask its health - │ endpoint — a hosted runner cannot launch the other four + │ endpoint — macOS and Android are interrogated only, and + │ a person installs a release on a real machine ▼ 3 publish — only when all five succeeded generate the update manifests with binary hashes diff --git a/70-operations/releasing.md b/70-operations/releasing.md index a13e829..825577d 100644 --- a/70-operations/releasing.md +++ b/70-operations/releasing.md @@ -98,10 +98,34 @@ there is nothing to move by hand. each interrogating the artifact it produced rather than trusting the build's exit code: that it is signed by the identity expected, that it carries nothing it must not, and that the update manifest written beside it names it. -3. **One self-host smoke test**, launching the shipped self-host recipe and - asking its health endpoint. A hosted runner cannot launch the other four — an - Electron bundle needs a session and a display, and the Android package needs - a device — so this is the one shape CI can start and probe end to end. +3. **Smoke tests, on the shapes a runner can start.** The Linux and Windows + bundles are launched and asked for their health endpoint before they are + uploaded, and the shipped self-host recipe is launched and probed beside them. + The answer is compared against the tag, so a bundle that runs but reports + another version fails too. + + This page previously said a hosted runner could not launch any of the four. + That was written from the probes removed in May 2026, and it was right about + the outcome and wrong about the reason, which mattered because each recorded + cause had an escape nobody had tried. The Linux runner has no display, so + `xvfb-run` supplies one. `open -a` on macOS goes through Gatekeeper, so the + bundle's own binary is executed instead, named by `CFBundleExecutable`. The + Windows installer-to-launch race is avoided by launching the unpacked tree + rather than installing it. Two of the three then worked. + + **macOS and Android are not launched, and the reasons are different.** An + `.apk` is installed onto a device or an emulator and has no process a runner + can ask — that was always true. macOS was tried and measured: on + `v2.0.0-rc.3` the bundle's binary executed and cleared every signing gate, + and Electron died with `Fatal process out of memory: Failed to reserve + virtual memory for CodeRange`. V8 cannot reserve its code range on a + `macos-14` runner. That is a property of the runner, not the bundle, and the + signing friction this page used to blame was never reached. + + **What covers those two is a person.** Installing a release on a real machine + and using it is manual, local, and owed before a stable tag. A runner proves + a bundle starts and answers; it does not prove the application works, and it + never did. 4. **Publish**, only if all five succeeded: generate the release notes from the commits since the previous tag, generate the update manifests with binary hashes, sign each manifest, and create the release with every binary