docs: the cosign floor was wrong in two more places, one of them the release page - #180
Merged
Conversation
…release page #175 measured the floor and corrected README.md. It corrected only README.md — I grepped one file instead of the repo, on a change whose whole subject was a claim repeated across surfaces. Two instances survived: - `.github/release-body.md:36` — **this becomes the GitHub release page body** (`release.yml:235` runs it through envsubst into `body_path`). It is the copy every person downloading v0.4.0 would have read, and it would have shipped with tomorrow's tag telling them to go get cosign 3. - `docs/releases.md:62` — the pipeline plan, stating the same floor as fact. Both now say 2.5, the measured floor: 2.4.0 cannot read the bundle format, 2.5.0 and up verify a real release with both negative controls refusing. Found by a `consult` on the release branch, run as a live end-to-end check of the 0.17.1 shell before tagging. It caught `docs/releases.md`; the repo-wide grep I ran to verify its citation caught the release page, which is the one that mattered. Neither the review nor the grep alone would have found both. Also here, same family — prose the recent changes left stale: - `docs/sandbox-probes.md:24` promised "paths outside the mount resolve to nothing" in the summary at the top, which 0.17.1's walkable prefix directories made too broad. Battery C already carved out the exception a hundred lines down; the headline now says what it means (a file read) and points at C. The changelog bullet moves from naming README to naming the floor, since the release page carried it too. Not taken from the same review: it also reported CHANGELOG.md's "kaish upgraded to 0.17.1 (from 0.14.0)" as stale against AGENTS.md's "from 0.14.1". The changelog is right. `git show v0.3.0:Cargo.toml` pins the last release at kaish-kernel 0.14.0, and a changelog's baseline is the last release; AGENTS.md's 0.14.1 is the pre-bump working pin, a different and internal baseline. Reviewed-by: kaibo cast `crusoe` (DeepSeek-V4-Flash explorer, GLM-5.2 synth) Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
Release-blocking. #175 measured the cosign floor and corrected
README.md. Itcorrected only
README.md— I grepped one file instead of the repo, on a change whoseentire subject was a claim repeated across surfaces. That is the "an idiom is never in one
file" lesson, and I did not apply it.
Two instances survived:
.github/release-body.md:36— this becomes the GitHub release page body.release.yml:235runs it throughenvsubstintobody_path, so it is the copy everyperson downloading v0.4.0 reads. It would have shipped with tomorrow's tag telling them
to go install cosign 3 to verify a signature that 2.5 verifies.
docs/releases.md:62— the pipeline plan, asserting the same floor as fact.Both now say 2.5, the measured floor: 2.4.0 cannot read the bundle format; 2.5.0,
2.6.0 and 2.6.4 verify a real release, with a tampered file and a wrong tag identity both
refusing.
How it was found — and why neither half alone would have
A
consulton the release branch, run as a live end-to-end exercise of the 0.17.1 shellbefore tagging. It found
docs/releases.md:62and missed the release page. The repo-widegrepI ran to verify its citation found the release page — the one that actuallymattered.
So the review caught what my grep in #175 missed, and my grep caught what the review
missed. Worth recording as an argument for doing both rather than either.
Also here — same family, prose the recent changes left stale
docs/sandbox-probes.md:24promised "paths outside the mount ... resolve to nothing" inthe summary at the top of the runbook. 0.17.1's walkable prefix directories made that too
broad. Battery C already carves out the exception a hundred lines down, so this is the
headline catching up: it now says what it means (a file read) and points at C.
Not taken from the same review
It also reported
CHANGELOG.md:72's "kaish upgraded to 0.17.1 (from 0.14.0)" as staleagainst AGENTS.md's "from 0.14.1", and recommended changing the changelog.
The changelog is right.
git show v0.3.0:Cargo.tomlpins the last release atkaish-kernel 0.14.0, and a changelog's baseline is the last release. AGENTS.md's
0.14.1 is the pre-bump working pin — a different, internal baseline. Changing it would
have reintroduced exactly the error #178 fixed.
Verified before declining, not assumed.
Docs only — no code.
🤖 Generated with Claude Code