Repository navigation
docs: record the 0.7.0 release, and the ClawHub push that did not land - #32
Merged
Merged
Conversation
npm and the GitHub release are out and were checked from outside the run: dist-tags latest 0.7.0, attestations endpoint 200, shasum 553872addc83db7101f9c366919ed9e93ab1e85e, and a temp-prefix install running euthyna --lang en with the PR #28 declaration and both skill editions inside the tarball. The registry listing is the part that failed, twice on CI (InternalServerError at Log in, then at Publish) and twice locally with the pinned CLI (timeout, direct and through the proxy). Reads never broke, which is what lets the record say the listing is still 0.6.0 with no partial submission rather than guessing — and the step log masking the token as *** is the evidence the secret is populated, which gh secret list cannot provide and has previously misrepresented. Also recorded, because it is the reason the release came within a minute of failing: publish.yml had not parsed since PR #23. A runner context in a job-level env: invalidates the whole file, and the only symptom was 0-second red runs nobody was looking at, with the real message reserved for the dispatch call. The non-publishing rehearsal is now named as the standing first step of a release.
|
Sorry @modusensus, you've used your own review budget of 250,000 diff characters for the last 7 days. You can request another review in 5 days by commenting |
Reviewer's GuideConsolidates the 0.7.0 release evidence in one place, explicitly documents that ClawHub was skipped because of registry failures rather than repository state, and records a workflow-rehearsal safeguard for catching release-path failures earlier. File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
modusensus
changed the title
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 release record for 0.7.0, plus the failure that came with it. Docs only, one file.
What is recorded
The release happened, checked from outside the run colour — the convention AGENTS.md already sets for 0.6.0:
The ClawHub listing did not move, and the record says why rather than guessing. CI failed
Log in, then — after a re-run of just that job —Publish, both with{"code":"InternalServerError","message":"Your request couldn't be completed. Try again later."}. The re-run's own fail-closed pre-read printedeuthyna currently lists 0.6.0; candidate 0.7.0 compares: newer, so nothing was pushed blind. Pushing locally with the workflow's own CLI pin (0.23.3) and its identical flag set timed out twice, direct and through the proxy. Reads worked throughout, which is how the record can state the actual state — both slugspass | clean | 0.6.0, no partial submission,latestuntouched — instead of leaving the next agent to infer it. A retry is scheduled on the operator's machine; the entry notes that after any successful push the listing must be re-read until it settles, because one read immediately after a push is a known false negative here.The fact this release nearly proved nothing about:
gh secret listcannot distinguish a set secret from an empty one (the 2026-09-23 entry is the precedent that started this). The step log masking the value asCLAWHUB_TOKEN: ***can, so that is written down as the evidence, and it also retires the doubt from the 0.6.0 entry rather than restating it.The lesson worth a pitfall row
publish.ymlhad not parsed sinceb795569(PR #23). One illegal expression —${{ runner.temp }}in a job-levelenv:, where onlysecretsandvarsare legal — invalidates the entire file, and the only symptoms were 0-second red runs nobody was looking at, because no release had been cut to read the actual reason. It surfaced asHTTP 422 … Unrecognized named-value: 'runner'when the 0.7.0 rehearsal tried to dispatch, i.e. one minute before the tag push would have failed the release.So the row names the non-publishing rehearsal (
gh workflow run publish.yml --ref <branch> -f publish=false) as a standing first step of every release: it costs a minute and it is the only exercise that path gets between releases. That rehearsal is also what caught it — nothing was found by reading the file.Verification
node --test→ tests 246 / pass 245 / fail 0 / skipped 1 (unchanged: this adds no test, and the diff is 33 added lines with no deletions —git diff --stat).