[krishhgg]

What changes

• docs/release-validation.md now opens with a v0.1.0 section. It lists the 16 real-Mac checks from the v0.1.0 tag, each marked passed. The maintainer ran them before the October 10, 2026 release on a MacBook with an Apple M5 (Mac17,2), 32 GB, macOS 26.2 (25C56). The tested build is the release's Insomnia.app with the scripts from the tag, ea5ce15. The section also keeps the release snapshot notes from the tag: hand-packaged, no attestation, and the executable compared against b05652c. The audit history stays.
• docs/releasing.md gets a "Real-Mac checks before a release" section. It holds the checks for the next release as a plain list: 76 from the old table, plus 3 launchd and installer checks that were written as prose before. The safety notes and a summary of what swift test covers with fakes come with it. Release step 4 and "What is not automated" point at this list.
• The Greptile rule real-mac-checks-need-hardware-evidence replaces release-validation-rows-need-hardware-evidence. New real-Mac behavior adds an item to the list in releasing.md. A release's results name the commit, the Mac, the macOS version, the date and the result. Tests, source review and CI never count as results.
• References: CONTRIBUTING, docs/spec.md, docs/recovery.md, .greptile/files.json, the scripts/simulate-lid.sh header and a LoginItemTests comment now point at the new list.

The v0.1.0 zip check from the old table is left out of the list, since the v0.1.0 table covers it. App code is unchanged. The only Swift edit is a comment.

Open PRs that add rows to the old table (#18, #20, #32, #34, #58, #61, #64) move their rows into the new list when they next merge main.

Codex review

Codex (gpt-6.1-sol, xhigh, read-only) reviewed three heads.

• 297c6f5, P2: the release steps ran the real-Mac checks after the tag push had published the release. Fixed in 3e0d228. Step 2 now tests a manual workflow build of the release commit and records the results, and the tag goes on that tested commit afterwards.
• 3e0d228, P2: the manual run neither attests nor publishes, so step 2 could not cover the release channel checks. Greptile found the same thing (4240665717). Fixed in 9eb3c84. The stable channel check is step 5, after publishing, and the nightly one follows a nightly run.
• 9eb3c84: no findings. It confirmed that the 16 v0.1.0 scenarios match the tag, that the 76 kept scenarios keep their wording, and that the JSON, links and anchors are valid.

🤖 Generated with Claude Code

Confidence Score: 5/5

The PR appears safe to merge; the release checklist no longer requires publication before its pre-release checks can finish.

Summary

Records v0.1.0's real-Mac results and moves future checks to docs/releasing.md.

• The v0.1.0 record names the real-Mac checks that passed.
• Maintainers check a release candidate before they tag it.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Commit release version] --> B[Build manually and run hardware checks]
  B --> C[Record results]
  C --> D[Tag tested commit]
  D --> E[Publish release]
  E --> F[Verify and install published download]
  F --> G[Record stable channel result]

Loading

_{Reviews (3) · Last reviewed commit: "Releasing: run the release channel check..." · Reviewed by Greptile}