Repository navigation
docs(ops): v2.0.0 is releasable, and two of the four bundles do launch - #123
Merged
Merged
Conversation
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 <info@nightworks.io> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
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 <info@nightworks.io> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
github-actions
Bot
added
the
awaiting-maintainer
github-actions
Bot
removed
the
awaiting-maintainer
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two changes, both from evidence produced today.
1 —
2.0.0.toml→releasableThe last block standing was F8's app-store distribution, and what it waited on was never code: four console records (R4, R15, R16, R26) and two 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 why 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 portal paperwork cannot stop a direct-download release. The provisioning profile is in the signing register as
MAS_PROVISIONING_PROFILE_BASE64and is checkable; the installer certificate is held in the portal.Entries stay where they are. A version that reaches
releasableby deleting the record of what was once unmet has not reached it.manifest_checkclean (373 goals),integrityclean, still the only non-template manifest so one version is staged or releasable at a time.2 — the smoke-test claim, narrowed to what is true
releasing.mdandci-cd.mdsay a hosted runner cannot launch any of the four bundles, naming three causes. Written from the probes removed in May 2026, and right about the outcome, wrong about the reason — which mattered, because each cause had an escape nobody had tried:xvfb-runopenCFBundleExecutableOn
v2.0.0-rc.3the Windows bundle started, served, and answered/health— reporting the wrong version, which is a defect the probe existed to find and did (beatrax#893).macOS was measured, not assumed either way. Its binary executed and cleared every signing gate, so the friction these pages blamed was never reached. Electron then died with:
V8 cannot reserve its code range on a
macos-14runner — a property of the runner, not the bundle. Android was always correct: an.apkinstalls onto a device and has no process a runner can ask.So the claim is narrowed to the two it is true of, with the reason for each written down, because "cannot" without a cause is what stopped anyone trying for four months.
The paragraph that was missing from both versions
Note the requirements themselves were never wrong: OPS-R5 and REPO-R29 both survived the earlier rewrite verbatim, mandating a launch the narrative called impossible. This removes that contradiction by correcting the narrative, not the requirements.