Refresh the npm payload to the v0.6.0 CLI, as one set - #242
Merged
Conversation
boundary-exception: refresh the v0.6.0 npm B payload from frozen core-A. Both vendored binaries and all four digests in vendor/manifest.json move to the v0.6.0 release, together with cli_version, package.json, and both package-lock.json version fields. test_v0_6_0_version_activation.py holds those four as one value — 1d23604 moved three and was reverted for it — so they move as a set here. Bytes come from release run 33325655578 on tag v0.6.0, source commit 8adda91, bound in docs/validation/v0-6-0-release-promotion.md. Not from a local build: the runbook forbids it, and cli-draft-artifacts builds once without comparing, so a local build could not reproduce these digests anyway. prepare:vendor assembled and verified the darwin binary end to end on macOS arm64 — archive digest, extracted-binary digest, --help grounding support, the new --version binding, and the destination digest after copying. It correctly refused the linux binary here, because it executes what it copies. That binary came from the same verified archive with its digest checked against the manifest, and its version is evidenced by the release run's own Linux smoke step, which recorded version_stdout: ethos 0.6.0 against archive c12772255ba8...78f2. Recorded plainly because it is weaker than the darwin path: that binding ran on CI's Linux runner, not here. Three surfaces asserted the vendored binaries report ethos 0.5.0, and all three derived it from the published npm version: the npm README and QUICKSTART (both shipped inside the tarball), test_package_registry_source_consistency.py, and docs/public-boundary-claims.json. A refreshed payload would have published a README stating something false about the bytes beside it. The two sentences describe different things — the package on the registry is still 0.5.0, the vendored binaries are already 0.6.0 — so the publication sentence still follows docs/release-state.json and the vendored-binary sentence now follows vendor/manifest.json's cli_version. The activation gate's trailing assertNotIn(ACTIVATED, claims) is narrowed for the same reason. Its six explicit install-command checks already cover every installable form; the catch-all forced the claims registry to misdescribe its own payload. The activated version may now appear only in the vendored-binary claim. Verified the narrowed rule still fails when an install command is advanced. test_npm_binary_package_scaffold.py's SUPPORTED_TARGETS is rebound from the v0.5.0 closeout to the v0.6.0 run; test/platform-selection.test.js follows cli_version. docs/release-state.json is untouched: version stays 0.5.0 because nothing is published, and activated already reads 0.6.0. make release-gates exits 0. npm test, light-check, registry-surface-check, and the Action contract all pass. The four-field set is {0.6.0} and both vendored binaries hash to their manifest entries. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: docushell-dev <hello@docushell.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.
The last blocking piece before publication.
1d23604attempted this and was reverted for moving three of the four version fields; they move together here.The payload
Bytes from release run 33325655578 on tag
v0.6.0, source commit8adda91, bound indocs/validation/v0-6-0-release-promotion.md. Not a local build — the runbook forbids it, andcli-draft-artifactsbuilds once without comparing, so a local build could not reproduce these digests.{0.6.0}— manifestcli_version,package.json, both lock fields038bfd4f…matches manifestba9c648e…matches manifestversion0.5.0— untouched, nothing published yetactivated0.6.0prepare:vendorverified the darwin binary end to end on macOS arm64: archive digest, extracted-binary digest,--helpgrounding support, the new--versionbinding, and the destination digest after copying.Stated plainly: it correctly refused the linux binary on this host, because it executes what it copies. That binary came from the same verified archive with its digest checked against the manifest, and its version is evidenced by the release run's own Linux smoke step (
version_stdout: ethos 0.6.0). That binding ran on CI's Linux runner, not here — weaker than the darwin path, and recorded as such.The README would have shipped a false claim
Three surfaces said the vendored binaries report
ethos 0.5.0, all derived from the published npm version: the npm README and QUICKSTART (both inside the tarball), the consistency gate, anddocs/public-boundary-claims.json.The two sentences describe different things. The package on the registry is still
0.5.0; the vendored binaries are already0.6.0. The publication sentence still followsrelease-state.json; the vendored-binary sentence now followscli_version.One gate narrowed
The activation gate's trailing
assertNotIn(ACTIVATED, claims)forced the claims registry to misdescribe its own payload. Its six explicit install-command checks already cover every installable form, so the catch-all is narrowed: the activated version may appear only in the vendored-binary claim. Verified it still fails when an install command is advanced to0.6.0.Verification
make release-gatesexits 0.npm test,light-check,registry-surface-check, and the Action contract all pass.🤖 Generated with Claude Code