fix(release): emit .zip.sha512 sidecars + close Scoop install gotchas (#2758)#2761
Conversation
…chas to docs Three converging fixes that together close out the user-visible install breakage reported in #2758 (and by two additional users on the scoop-wheels side: zainforbjs#2 and a private report from Michael at PAI). ### 1. release: emit `*.zip.sha512` / `*.zip.md5` instead of `*.sha512` / `*.md5` The scoop-wheels bucket's `autoupdate` config substitutes `$url.sha512` to locate each artifact's checksum sidecar — i.e. for `wheels-core-X.X.X.zip` it looks for `wheels-core-X.X.X.zip.sha512`. The build scripts were emitting `wheels-core-X.X.X.sha512` (no `.zip.` segment), so even if Excavator (or any other autoupdate path) ran post-GA it would 404 on every non-module artifact. wheels-module already used the correct `.zip.sha512` shape; the four other build scripts didn't. Touched: - `tools/build/scripts/build-{base,cli,core,starterApp}.sh`: emit `<artifact>.zip.{md5,sha512}` (was `<artifact>.{md5,sha512}`). - `tools/build/scripts/README.md`: documents the new filename shape. - `.github/workflows/release.yml` + `release-candidate.yml`: update the `actions/upload-artifact` glob patterns to match — 40 line edits across the two files. No consumers grep for the old shape (verified across homebrew-wheels, scoop-wheels, .deb/.rpm builders, framework code). snapshot.yml inherits via `uses: ./.github/workflows/release.yml`. ### 2. docs: add missing `scoop bucket add java` step `scoop install wheels` declares `java/openjdk21` as a dependency but Scoop does not auto-add the `java` bucket on the user's behalf — both real-user reports (Michael, zainforbjs) hit the same "Couldn't find manifest for 'openjdk21' from 'java' bucket" warning before being able to proceed. The docs claimed it was automatic. Updated: - `start-here/installing.mdx` Windows tab (both v4-0-0 and v4-0-1-snapshot) - `command-line-tools/installation.mdx` (both v4-0-0 and v4-0-1-snapshot) ### 3. docs: document `lucli modules install --url=` for standalone-LuCLI users New "Advanced: existing LuCLI install" section under "Manual JAR install" in `command-line-tools/installation.mdx` (both versions). Covers stable and bleeding-edge URLs, and an Aside enumerates what the user gives up vs. the Scoop/Homebrew/.deb/.rpm paths: binary name, LUCLI_HOME isolation, JDK resolution, SQLite shim, channel awareness, upgrade story. Triggered by Jay Dee's report (#2758) of trying `lucli modules install wheels@be` based on inferred channel naming — the `@be` tag doesn't exist in LuCLI's registry, and the bare `wheels` entry points at a stale `wheels-cli-lucli` mirror that hasn't been synced from develop since 2026-04-04. ### Not in this PR (deliberate scope split) - Real sha512 hashes for v4.0.0 in `scoop-wheels/bucket/wheels.json` — that lives in a different repo. Already up as wheels-dev/scoop-wheels#3 and unblocks the immediate install failure. - Deciding whether to register scoop-wheels with Excavator or self-host a cron-driven autoupdate workflow — needs a design call, follow-up after the immediate-fix PRs land. - Updating LuCLI's bundled registry (`local.json:23`) to point at `wheels-dev/wheels` directly instead of the stale `wheels-cli-lucli` mirror — needs Mark's input on the LuCLI side. Refs #2758 Refs wheels-dev/scoop-wheels#2 Signed-off-by: Peter Amiri <peter@alurium.com>
![wheels-bot[bot]](https://avatars.githubusercontent.com/in/3657588?s=60&v=4){kind=small}
There was a problem hiding this comment.
Wheels Bot — Reviewer A
TL;DR: Three-part fix for the Windows install regression in #2758 — checksum filename alignment (*.zip.sha512), Scoop java bucket step, and a new "Advanced: existing LuCLI install" section. The CI workflow and build-script changes are mechanically correct and consistent across all four artifacts and both release workflows. Flagging four nits below; none are blockers, so this is a comment-only review.
Correctness
The core fix is complete:
- All four build scripts (
build-base.sh,build-cli.sh,build-core.sh,build-starterApp.sh) consistently rename their checksum outputs to.zip.md5/.zip.sha512. - Both
release.ymlandrelease-candidate.ymlupdate every glob pattern (upload-artifact sections and the release-publishfiles:block). Count checks out — no missed occurrences. snapshot.ymlcallsrelease.ymlas a reusable workflow (uses: ./.github/workflows/release.yml), so the fix propagates to snapshot builds without a separate edit. The PR body correctly describes this.- The
wheels-moduleartifact already used the.tar.gz.sha512/.zip.sha512shape; the PR leaves those untouched, which is right.
Conventions
tools/build/scripts/README.md still omits wheels-starter-app
The README text says "the three Wheels variants: Core, Base Template, and CLI" and its artifact-structure diagram lists only those three. build-starterApp.sh has existed for a while and is updated here, but the README never mentioned it. This PR touches the README and could close that gap.
# Suggestion — README.md "Two Types of Scripts" section
- **`build-core.sh`** - Builds the Wheels Core framework package
- **`build-base.sh`** - Builds the Wheels Base Template (application starter template)
- **`build-cli.sh`** - Builds the Wheels CLI commands module
+ - **`build-starterApp.sh`** - Builds the Wheels Starter App
# Suggestion — artifact structure block (add after wheels-cli entries)
wheels-starter-app-{version}.zip
wheels-starter-app-{version}.zip.md5
wheels-starter-app-{version}.zip.sha512
Not a blocker (pre-existing), but since the file is being touched anyway it is worth fixing.
Docs
Fragile curl | sed pipeline in the bleeding-edge snippet
web/sites/guides/src/content/docs/v4-0-0/command-line-tools/installation.mdx (and the v4-0-1-snapshot mirror), "Advanced: existing LuCLI install" section:
SNAP_TAG=$(curl -fsSL https://api.github.com/repos/wheels-dev/wheels-snapshots/releases \
| sed -nE 's/.*"tag_name": *"v([^"]+)".*/\1/p' | head -1)
lucli modules install wheels --force \
--url="https://github.com/wheels-dev/wheels-snapshots/releases/download/v${SNAP_TAG}/wheels-module-${SNAP_TAG}.zip"Two concerns:
-
Compact JSON breaks
sed. Thesedregex parses line by line. GitHub's API is currently pretty-printed, but if it ever returns compact JSON (all one line), the greedy.*at the start of the pattern will match the lasttag_nameon the line, which may be wrong.jqor theghCLI are less fragile:gh release list -R wheels-dev/wheels-snapshots --limit 1 --json tagName --jq '.[0].tagName'. -
Silent failure. If the API call fails (network error, rate limit — unauthenticated calls are capped at 60/hr) or returns unexpected JSON,
SNAP_TAGis empty. The subsequentlucli modules installcommand then requests a URL ending in.../download/v/wheels-module-.zip, which will give an unhelpful 404. A simple guard would help:
if [ -z "$SNAP_TAG" ]; then
echo "Error: could not resolve snapshot tag. Check your network or set SNAP_TAG manually." >&2
exit 1
fiNo CHANGELOG entry
The [Unreleased] section in CHANGELOG.md has no ### Fixed entry for either:
- the
.zip.sha512checksum rename (fixes the Scoop autoupdate 404), or - the
scoop bucket add javamissing-step fix.
Both directly unblocked real-user installs reported in #2758. A ### Fixed entry would help users reading the changelog know the issue is resolved.
Commits
fix(release): emit .zip.{sha512,md5} sidecars + add Scoop install gotchas to docs
Type fix, scope release, subject 82 chars, sentence-case — passes commitlint. The "why" is implicit from the issue reference; acceptable.
Tests
No framework code changed — no spec coverage needed. The PR test-plan items are reasonable. One gap: the bleeding-edge curl | sed snippet has no explicit test-plan checkbox, even a manual smoke-test ("run the two-liner on a machine with LuCLI installed and confirm the resolved URL is valid before passing it to lucli"). Low priority, but worth adding.
|
Wheels Bot - Reviewer B (round 1) A's review is accurate and grounded. Every claim I checked against the diff holds. No sycophancy, no false positives, no notable missed issues. A's COMMENTED verdict is consistent with the findings. Aligning on converged-changes so the four actionable items can be addressed before merge. Sycophancy: None detected. A does not approve the PR, correctly choosing COMMENTED over APPROVED despite the core fix being mechanically sound. False positives: None detected. Verified all four of A's claims against the diff: correctness count (build scripts + workflows), README omitting starter-app, fragile curl|sed pipeline (greedy .* yields oldest tag on compact JSON; empty SNAP_TAG silently fails), and CHANGELOG gap. All accurate. Missed issues: None beyond what A flagged. Minor: README artifact diagram also omits wheels-starter-app-be.zip in the unchanged -be.zip context lines, but this is the same pre-existing gap A noted. Verdict alignment: A's COMMENTED state is consistent — all findings are non-blocking ('not a blocker', 'worth adding', 'low priority'), so neither APPROVED nor REQUEST_CHANGES is appropriate. Convergence: Aligned. A's four concrete actionable items (README diagram entries for starter-app, curl|sed to jq/gh with empty-tag guard, CHANGELOG Fixed entry, test-plan checkbox) map to converged-changes per protocol. Bot-address-review can apply all four cleanly. |
- README at tools/build/scripts/: add build-starterApp.sh to the
scripts list and add wheels-starter-app artifact entries to the
output-structure diagram (header text bumped from "three" to "four"
Wheels variants).
- installation.mdx (v4-0-0 + v4-0-1-snapshot): replace the fragile
curl | sed pipeline in the new "Advanced: existing LuCLI install"
section with jq, and add an empty-tag guard so an API failure or
rate-limit miss fails fast with a useful message instead of
silently 404-ing on a malformed URL.
- CHANGELOG.md: add ### Fixed entries under [Unreleased] for the
.zip.{sha512,md5} sidecar rename and the Windows scoop bucket add
java prerequisite.
- PR description: add a manual smoke-test checkbox covering the
bleeding-edge lucli modules install --url= snippet.
Signed-off-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>
Wheels Bot — Address Review (round 1)Applied consensus findings from Reviewer A and Reviewer B's convergence (round 1):
No findings were intentionally skipped — all four converged items from Reviewer A's COMMENTED verdict (which Reviewer B confirmed had zero false positives and zero missed issues) are addressed in commit No The new commit will trigger a fresh Reviewer A run on the updated SHA. Convergence loop continues until reviewers align on |
There was a problem hiding this comment.
Wheels Bot — Reviewer A
TL;DR: Round-1 follow-up commit (a81345ae) addresses four of the five findings from the prior review: README diagram updated to include wheels-starter-app, the fragile curl | sed pipeline in the new "Advanced: existing LuCLI install" section replaced with jq plus an empty-tag guard, CHANGELOG entries added, and the smoke-test checkbox added to the test plan. The core CI/build workflow changes from the original commit remain mechanically correct. Flagging one incomplete fix and one stale word in the README; neither is a blocker.
Correctness
Linux .deb/.rpm bleeding-edge snippets still use the old curl | sed pipeline
The round-1 fix replaced the fragile sed tag-resolver in the "Advanced: existing LuCLI install" section (lines 161-163 in both installation.mdx files) but left the pre-existing Linux snippets untouched. All four instances in both doc trees still read:
# v4-0-0/command-line-tools/installation.mdx, lines 76-77 and 84-85
# v4-0-1-snapshot/command-line-tools/installation.mdx, same line numbers
SNAP_TAG=$(curl -fsSL https://api.github.com/repos/wheels-dev/wheels-snapshots/releases \
| sed -nE 's/.*"tag_name": *"v([^"]+)".*/\1/p' | head -1)The same compact-JSON / silent-empty concerns the prior review raised apply here. If the API rate-limits (60 unauthenticated req/hr) or returns compact JSON, SNAP_TAG becomes empty or wrong; the subsequent curl/dnf command then silently fetches a malformed URL. The deb/rpm snippets also lack the empty-tag guard added to the LuCLI-install section by the round-1 fix. Treating two parallel snippets in the same file differently is confusing to readers. Suggested fix (apply to all four instances in both doc trees):
SNAP_TAG=$(curl -fsSL https://api.github.com/repos/wheels-dev/wheels-snapshots/releases \
| jq -r '.[0].tag_name | sub("^v"; "")')
if [ -z "$SNAP_TAG" ] || [ "$SNAP_TAG" = "null" ]; then
echo "Error: could not resolve snapshot tag. Check your network, GitHub API rate limit, or set SNAP_TAG manually." >&2
exit 1
fi
SNAP_FILENAME_VER="${SNAP_TAG//-/.}"This is the only remaining open item from the prior review; everything else was addressed cleanly.
Docs
tools/build/scripts/README.md line 36 — stale "three" count
The Convenience Scripts section still reads:
- **`build-all.sh`** - Builds all three variants sequentially (useful for local testing)
Line 3 was correctly updated to "four Wheels variants" in this same commit, but line 36 was missed. One-word fix: "three" → "four".
Commits
docs: address Reviewer A/B consensus findings (round 1) — type docs, subject 51 chars, not ALL-CAPS, DCO sign-off present. Passes commitlint.
Tests
No framework code changed. No spec coverage needed.
|
Pushed an additional commit (5144fdb) extending the scope per the scoop-wheels#4 follow-up:
Touches:
No functional change for v4.0.0 (it already shipped). Takes effect on the next snapshot or 4.0.1. The |
Wheels Bot — Reviewer B (round 1)A's review for SHA SycophancyNone detected. A correctly withholds APPROVED with two open items outstanding, using COMMENTED as the appropriate state. False positivesNone detected. Verified both of A's claims directly:
Missed issuesNone beyond what A flagged. One note on scope: the round-1 address-review explicitly called the deb/rpm instances "not in the consensus" (pre-existing, not introduced by this PR). A re-raises them as a remaining open item, which is accurate — the two snippets in the same file now behave inconsistently with the new Advanced section. B treats A's re-raise as a legitimate finding rather than scope creep. Verdict alignmentCOMMENTED is correct. Neither finding is severe enough for REQUEST_CHANGES, and APPROVED would be wrong with two known open items. The verdict is well-calibrated. ConvergenceAligned. A's two findings are accurate and concrete:
Both are clean mechanical edits for bot-address-review. Emitting converged-changes. |
There was a problem hiding this comment.
Wheels Bot — Reviewer A
TL;DR: Round-3 commit (5144fdbb9) swaps the downstream dispatch target from chocolatey-wheels to scoop-wheels in release.yml. The functional change is correct and complete: the dispatch loop, warning message, and all sibling comments are updated consistently. One blocker: the commit type release: is not in the commitlint allowlist. Two items from the round-2 review remain open and unchanged by this commit. Requesting changes on the commitlint violation; the other two are carry-overs.
Commits
release: is not a valid commitlint type
commitlint.config.js extends @commitlint/config-conventional, which enforces a type-enum rule. The allowed types (quoted verbatim in the config's own comment block) are:
feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert
The commit release: dispatch scoop-wheels, retire chocolatey uses release as its type, which is not in that list. The change touches a CI workflow file (.github/workflows/release.yml) and retires a downstream dispatch target — the correct type is ci: or, if read as maintenance cleanup, chore:. Suggested replacement:
ci: dispatch scoop-wheels, retire chocolatey
The commit body and sign-off are otherwise fine: the "why" is clearly explained, subject length is well under 100 chars, and the DCO Signed-off-by: trailer is present.
Correctness (carry-overs from round 2, not introduced by this commit)
Linux bleeding-edge snippets still use the old curl | sed pipeline
Both doc trees (v4-0-0 and v4-0-1-snapshot) still have the un-guarded sed tag-resolver in the apt/dnf bleeding-edge install sections (e.g. installation.mdx lines 76–85 in each tree):
SNAP_TAG=$(curl -fsSL https://api.github.com/repos/wheels-dev/wheels-snapshots/releases \
| sed -nE 's/.*"tag_name": *"v([^"]+)".*/\1/p' | head -1)The round-2 review proposed replacing these four instances (two doc trees × two Linux package types) with jq -r '.[0].tag_name | sub("^v"; "")' plus the empty-tag guard added to the LuCLI section in round 1. These sites were not touched by this commit.
Docs (carry-over from round 2, not introduced by this commit)
tools/build/scripts/README.md line 36 — stale "three" count
- **`build-all.sh`** - Builds all three variants sequentially (useful for local testing)
Line 3 of the same file correctly says "four Wheels variants" (updated in round 1), but line 36 still says "three". One-word fix: "three" → "four". Not introduced by this commit; still unaddressed.
Tests
No framework code changed. No spec coverage needed.
Wheels Bot — Address Review (round 2)Applied consensus findings from Reviewer A and Reviewer B's convergence (round 1 of convergence loop on SHA
Reviewer A's latest review (on No The new commit will trigger a fresh Reviewer A run on the updated SHA. Convergence loop continues until reviewers align on |
Wheels Bot — Reviewer B (round 1)A's review for SHA SycophancyNone detected. A correctly issues CHANGES_REQUESTED rather than APPROVED or COMMENTED despite the round-3 commit being otherwise mechanically clean. False positivesNone detected. Verified all three findings directly:
Missed issuesNone beyond what A flagged. The round-3 commit is a narrow workflow/docs change (dispatch loop swap + sibling comment updates); no CFML code, no security surface, no API changes. Verdict alignmentCHANGES_REQUESTED is correct. The commitlint violation requires a commit amendment before merge; APPROVED or COMMENTED would be wrong here. ConvergenceAligned. Three concrete items for bot-address-review:
All three are clean mechanical edits. Emitting converged-changes. |
There was a problem hiding this comment.
Wheels Bot — Reviewer A
TL;DR: Round-2 follow-up commit (5d0d12b) correctly closes the two carry-overs from the prior review: the stale "three" → "four" in tools/build/scripts/README.md:36 and the fragile sed -nE tag-resolver in the Linux bleeding-edge snippets across both doc trees, both now replaced with jq -r '.[0].tag_name | sub("^v"; "")' plus the same empty-tag guard added in round 1. One blocker remains: commit 5144fdbb9 still carries the release: type, which is not in the commitlint allowlist. That was the sole reason for the round-3 request-changes and it is unchanged.
Commits
release: type in 5144fdbb9 — still a commitlint violation
The commit 5144fdbb9 release: dispatch scoop-wheels, retire chocolatey uses release as its type. commitlint.config.js extends @commitlint/config-conventional with a hard type-enum rule. The allowed types (quoted verbatim from the config's comment block) are:
feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert
This commit touches .github/workflows/release.yml and retires a downstream dispatch target — the correct type is ci (CI/CD workflow change) or chore (maintenance cleanup). Suggested replacement:
ci: dispatch scoop-wheels, retire chocolatey
The commit body and DCO sign-off are otherwise fine. This was the only request-changes finding in round 3 and it is still unresolved. A rebase, interactive squash, or amend + force-push of the one bad commit is the path forward.
Correctness
All carry-overs from rounds 1–3 are resolved:
tools/build/scripts/README.md:36— "three" → "four" ✓v4-0-0/command-line-tools/installation.mdxlines 76–95 —jq+ empty-tag guard ✓v4-0-1-snapshot/command-line-tools/installation.mdxsame lines —jq+ empty-tag guard ✓
The round-2 commit introduces no new functional changes beyond those three targeted fixes.
Commits (round-2 commit 5d0d12b)
docs: address Reviewer A/B consensus findings (round 2) — type docs, subject 51 chars, not ALL-CAPS, DCO Signed-off-by: claude[bot] trailer present. Passes commitlint.
Tests
No framework code changed. No spec coverage needed.
Wheels Bot -- Reviewer B (round 1)A's review for SHA SycophancyNone detected. A correctly withholds APPROVED with one open item remaining. False positivesNone detected. Verified both of A's assertions directly:
Missed issuesNone beyond what A flagged. The diff is docs plus workflow globs plus build script checksum renames -- no CFML code, no cross-engine surface, no security changes. The note in bpamiri's PR comment about the future removal of the Verdict alignmentCHANGES_REQUESTED is correct. The commitlint violation is a blocking concern; COMMENTED or APPROVED would be wrong with a known type violation in the history. ConvergenceAligned. One item for resolution: commit |
Wheels Bot — Address Review (round 3)Applied consensus findings from Reviewer A and Reviewer B's convergence (round 1 of convergence loop on SHA
The other two items in Reviewer B's converged-changes are accounted for:
No The new commit will trigger a fresh Reviewer A run on the updated SHA. Convergence loop continues until reviewers align on |
- Replace remaining `curl | sed -nE` pipelines in the stable Linux
`.deb`/`.rpm` install snippets (lines 60 and 67 in both
`v4-0-0/command-line-tools/installation.mdx` and
`v4-0-1-snapshot/command-line-tools/installation.mdx`) with the
same `jq -r '.tag_name | sub("^v"; "")'` pattern plus empty-tag
guard that round 1 applied to the LuCLI section and round 2
applied to the bleeding-edge `.deb`/`.rpm` snippets. The two
parallel snippet pairs in each file (stable + bleeding-edge) now
use the same resolver and error-handling path.
Reviewer B's round-1 converged-changes on SHA `5144fdbb9` also
listed amending the type of commit `5144fdbb9` from `release:` to
`ci:` to satisfy commitlint. That requires rewriting published git
history, which is outside the bot's allowed git operations
(read-only `git` per `_shared-rails.md`). It is left for a human to
amend, squash-merge with a conforming subject, or override the
DCO/commitlint check at merge time.
Refs PR #2761.
Signed-off-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Wheels Bot — Reviewer A
TL;DR: Round-3 commit (`810c83abf`) closes the last functional gap: the two stable Linux `.deb`/`.rpm` install snippets in both doc trees that still used the fragile `curl | sed -nE` tag-resolver are now replaced with `jq -r '.tag_name | sub("^v"; "")'` and the same empty-tag guard applied to all other snippet pairs in rounds 1 and 2. Every shell snippet across both doc trees is now consistent. All prior findings are resolved. One blocker carries forward from rounds 3–4 and was not touched by this commit: commit `5144fdbb9` still uses the type `release:`, which is not in the `commitlint.config.js` allowlist. That requires human action — the bot's `_shared-rails.md` constraint (read-only git) prevents it from amending or rebasing.
Correctness
All prior carry-overs resolved
- `tools/build/scripts/README.md` line 1 and line 36: "three" → "four" ✓ (round 2)
- `tools/build/scripts/README.md`: `build-starterApp.sh` listed in both the script table and the artifact diagram ✓ (round 1)
- CHANGELOG `[Unreleased] ### Fixed` entries for checksum rename and `scoop bucket add java` prereq ✓ (round 1)
- Bleeding-edge `.deb`/`.rpm` snippets in both doc trees — `jq` + guard ✓ (round 2)
- Advanced LuCLI section — `jq` + guard ✓ (round 1)
- Stable `.deb`/`.rpm` snippets in both doc trees — `jq` + guard ✓ (round 3, this commit)
The six snippet pairs in each `installation.mdx` (stable Debian, stable Fedora, bleeding-edge Debian, bleeding-edge Fedora, LuCLI stable, LuCLI bleeding-edge) are now uniform.
Commits
`5144fdbb9 release:` — commitlint violation, requires human action
Commit `5144fdbb9 release: dispatch scoop-wheels, retire chocolatey` uses `release` as its type. `commitlint.config.js` extends `@commitlint/config-conventional` with a hard `type-enum` rule. The allowlist (reproduced verbatim in the config's own comment block) is:
feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert
`release` is not in that list. The change touches `.github/workflows/release.yml` and retires a downstream dispatch target — the correct type is `ci` (CI/CD change) or `chore` (maintenance). Suggested rewrite:
ci: dispatch scoop-wheels, retire chocolatey
The round-3 commit body (`810c83abf`) correctly notes that amending `5144fdbb9` requires rewriting published history, which is outside the bot's allowed git operations per `_shared-rails.md`. The path forward is one of:
- Human amend + force-push: rebase to squash `5144fdbb9` into the prior commit or `git commit --amend` with the correct type.
- Squash-merge: GitHub's squash-merge dialog lets the merger supply a conforming subject line — confirm the DCO trailer is included in the squash message.
- commitlint override: accept the violation at merge time and address the commit type in the squash message.
No other commits have commitlint issues. `f01ea44cf fix(release):`, `a81345ae5 docs:`, `5d0d12b48 docs:`, and `810c83abf docs:` all pass: correct types from the allowlist, subject ≤ 100 chars, not ALL-CAPS, DCO `Signed-off-by:` trailers present.
Tests
No framework code changed across the entire PR. No spec coverage needed.
Wheels Bot — Reviewer B (round 1)A's review for SHA SycophancyNone detected. A correctly withholds APPROVED with one open item remaining. False positivesNone detected. Verified both of A's assertions directly:
Missed issuesNone beyond what A flagged. The diff is exclusively docs and workflow files — no CFML code, no cross-engine surface, no security or DI changes. No spec coverage gap. Verdict alignmentCHANGES_REQUESTED is correct. A commitlint type violation is a real blocker; COMMENTED or APPROVED would be wrong here. ConvergenceAligned. One item remains: commit |
Wheels Bot — Address Review (round 4)Reviewer A and Reviewer B converged on SHA
No new commit this round. The fix requires rewriting published history, which
So that is what this round does. @bpamiri — your options:
All other prior-round findings are resolved as of
No Since no commit is being pushed, a fresh Reviewer A will not auto-trigger. The convergence loop pauses here until a human resolves the commitlint item via one of the three options above (option 1 retriggers automatically on force-push; options 2 and 3 are merge-time actions). Round 4 of 5 used — one round of bot capacity remains if a fresh issue appears on a future SHA. |
The downstream package-manager dispatch step has fired wheels-released events to wheels-dev/homebrew-wheels and wheels-dev/chocolatey-wheels. Swap chocolatey out for scoop-wheels — the v1.x chocolatey-wheels package is CommandBox-based and can't drive v4, so the Windows install path moved permanently to Scoop in 4.0. scoop-wheels#4 adds the autoupdate workflow on the consumer side that listens for this dispatch event. Touches the dispatch loop, the secret docstring, the in-step warning message, and the three sibling comments (apt/yum dispatch + bump-develop) that referenced the homebrew/chocolatey step as their channel-derivation template. No functional change for stable v4.0.0 (it already shipped). Takes effect on the next snapshot or 4.0.1 release. Refs #2758 Refs wheels-dev/scoop-wheels#4 Signed-off-by: Peter Amiri <peter@alurium.com>
- tools/build/scripts/README.md:36 — "three variants" to "four
variants" in the Convenience Scripts section (line 3 was fixed in
round 1; line 36 was missed).
- web/sites/guides/src/content/docs/v4-0-0/command-line-tools/installation.mdx
(lines 76-77, 84-85) and the matching v4-0-1-snapshot mirror —
replace the `sed -nE` tag-resolver in the bleeding-edge deb/rpm
snippets with `jq -r '.[0].tag_name | sub("^v"; "")'` plus the
same empty-tag guard added to the LuCLI section in round 1.
Both items map to Reviewer B's converged-changes verdict on SHA
a81345a; Reviewer A's review of
the round-1 commit (`a81345ae`) and the round-2 commit (`5144fdbb`)
flagged the same carry-overs.
Refs #2758
Signed-off-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>
- Replace remaining `curl | sed -nE` pipelines in the stable Linux
`.deb`/`.rpm` install snippets (lines 60 and 67 in both
`v4-0-0/command-line-tools/installation.mdx` and
`v4-0-1-snapshot/command-line-tools/installation.mdx`) with the
same `jq -r '.tag_name | sub("^v"; "")'` pattern plus empty-tag
guard that round 1 applied to the LuCLI section and round 2
applied to the bleeding-edge `.deb`/`.rpm` snippets. The two
parallel snippet pairs in each file (stable + bleeding-edge) now
use the same resolver and error-handling path.
Reviewer B's round-1 converged-changes on SHA `5144fdbb9` also
listed amending the type of commit `5144fdbb9` from `release:` to
`ci:` to satisfy commitlint. That requires rewriting published git
history, which is outside the bot's allowed git operations
(read-only `git` per `_shared-rails.md`). It is left for a human to
amend, squash-merge with a conforming subject, or override the
DCO/commitlint check at merge time.
Refs PR #2761.
Signed-off-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>
bpamiri
force-pushed
the
claude/objective-black-3adb90
branch
from
810c83a to
0aef64d
Compare
There was a problem hiding this comment.
Wheels Bot — Reviewer A
TL;DR: All findings from rounds 1–4 are resolved at head 0aef64d40. The last blocker — the release: type in commit 5144fdbb9 — was addressed by the author via rebase (now e0ff7a1af ci: dispatch scoop-wheels, retire chocolatey). The round-3 bot commit (0aef64d40) closes the final carry-over: the two stable Linux .deb/.rpm snippet pairs in both doc trees now use jq -r '.tag_name | sub("^v"; "")' plus the empty-tag guard, consistent with every other shell snippet in the file. The PR is clean; approving.
Correctness
All prior carry-overs resolved:
- Build scripts (
build-{base,cli,core,starterApp}.sh) — checksum outputs renamed to.zip.md5/.zip.sha512✓ release.yml+release-candidate.yml— all artifact glob patterns updated consistently ✓release.ymldispatch loop —chocolatey-wheels→scoop-wheels✓- Stable Linux
.deb/.rpmsnippets in bothv4-0-0andv4-0-1-snapshotdoc trees —sed -nE→jq -r '.tag_name | sub("^v"; "")'+ guard ✓ (round 3,0aef64d40) - Bleeding-edge
.deb/.rpmsnippets in both doc trees —jq+ guard ✓ (round 2) - Advanced LuCLI section —
jq+ guard ✓ (round 1) tools/build/scripts/README.mdline 36 — "three" → "four" ✓ (round 2)tools/build/scripts/README.md—build-starterApp.shlisted in script table and artifact diagram ✓ (round 1)- CHANGELOG
[Unreleased] ### Fixedentries for checksum rename andscoop bucket add javaprereq ✓ (round 1) - Scoop
scoop bucket add javastep added to bothinstalling.mdxfiles ✓
The round-3 commit correctly uses .tag_name (not .[0].tag_name) for the stable snippets, which call the /releases/latest endpoint that returns a single object — consistent with the bleeding-edge snippets that use .[0].tag_name against the /releases list endpoint.
Commits
All five commits pass commitlint:
| SHA | Subject | Type | DCO |
|---|---|---|---|
f01ea44cf |
fix(release): emit .zip.{sha512,md5} sidecars + add Scoop install gotchas to docs |
fix ✓ |
Signed-off-by: Peter Amiri ✓ |
a81345ae5 |
docs: address Reviewer A/B consensus findings (round 1) |
docs ✓ |
Signed-off-by: claude[bot] ✓ |
e0ff7a1af |
ci: dispatch scoop-wheels, retire chocolatey |
ci ✓ |
Signed-off-by: Peter Amiri ✓ |
b22429a6c |
docs: address Reviewer A/B consensus findings (round 2) |
docs ✓ |
Signed-off-by: claude[bot] ✓ |
0aef64d40 |
docs: address Reviewer A/B consensus findings (round 3) |
docs ✓ |
Signed-off-by: claude[bot] ✓ |
The release: type that triggered the rounds 3–4 request-changes is gone. All subjects are ≤ 100 chars, sentence-case, non-empty. DCO trailers present on every commit.
Tests
No framework code changed across the entire PR. No spec coverage needed.
Wheels Bot — Reviewer B (round 1)A's review is well-supported and the verdict is correct. One minor factual gap in the CHANGELOG that A did not catch, but it is harmless — the approval stands. SycophancyNone detected. A's APPROVED verdict is backed by a line-by-line carry-over checklist and a commit-table with type + DCO verification. False positivesNone detected. I re-verified the two claims easiest to get wrong:
Missed issuesOne minor point:
Verdict alignmentA's APPROVED verdict is consistent with the findings. The three fix groups (checksum filename rename across build scripts + both release workflows, ConvergenceAligned. The CHANGELOG imprecision is not worth a request-changes cycle — |
#2762) scoop-wheels#4 inlined OpenJDK 21 in the Scoop manifests, so `scoop install wheels` and `scoop install wheels-be` now work from a fresh shell with no prerequisite buckets. The `scoop bucket add java` step added in #2761 is no longer needed — drop it from both Windows install pages. Also drops the false claim that scoop-wheels autoupdate runs via the community Excavator bot. The bucket now uses its own `.github/workflows/autoupdate.yml` that listens for `repository_dispatch` fired by this repo's `release.yml` (chained via the existing `DOWNSTREAM_DISPATCH_TOKEN` PAT), with a daily cron at 08:30 UTC as fallback. End-to-end latency ~5-7 min from upstream tag to manifest. Updates installing.mdx + command-line-tools/installation.mdx in both v4-0-0 and v4-0-1-snapshot doc trees. Signed-off-by: Peter Amiri <peter@alurium.com>
* docs: drop `scoop bucket add java` step, update autoupdate description scoop-wheels#4 inlined OpenJDK 21 in the Scoop manifests, so `scoop install wheels` and `scoop install wheels-be` now work from a fresh shell with no prerequisite buckets. The `scoop bucket add java` step added in #2761 is no longer needed — drop it from both Windows install pages. Also drops the false claim that scoop-wheels autoupdate runs via the community Excavator bot. The bucket now uses its own `.github/workflows/autoupdate.yml` that listens for `repository_dispatch` fired by this repo's `release.yml` (chained via the existing `DOWNSTREAM_DISPATCH_TOKEN` PAT), with a daily cron at 08:30 UTC as fallback. End-to-end latency ~5-7 min from upstream tag to manifest. Updates installing.mdx + command-line-tools/installation.mdx in both v4-0-0 and v4-0-1-snapshot doc trees. Signed-off-by: Peter Amiri <peter@alurium.com> * docs: add `scoop install git` prerequisite before bucket add A real-user run from a fresh Windows shell on 2026-05-18 surfaced a missing prerequisite: Scoop's installer doesn't ship git, but `scoop bucket add` uses `git clone` under the hood, so adding any third-party bucket fails with: ERROR Git is required for buckets. Run 'scoop install git' and try again. `scoop install git` itself works from a totally fresh shell because the default `main` bucket — where git lives — is bundled with the Scoop installer rather than fetched at runtime. So the corrected sequence is: irm get.scoop.sh | iex scoop install git scoop bucket add wheels https://github.com/wheels-dev/scoop-wheels scoop install wheels Adds the `scoop install git` step (with a brief why-it's-needed note) to both Windows install pages in both v4-0-0 and v4-0-1-snapshot doc trees. The detailed `installation.mdx` reference page gets the explanation inline in the code block as a comment; the `installing.mdx` quick-start gets a numbered step with prose below. Bumps step numbering in the start-here `installing.mdx` Steps blocks (3 → 4 for the verify step). Signed-off-by: Peter Amiri <peter@alurium.com> --------- Signed-off-by: Peter Amiri <peter@alurium.com>
1 participant
Summary
Three converging fixes for the Windows install breakage reported in #2758, with confirming reports from two additional users on scoop-wheels#2 and a private internal report.
*.zip.sha512/*.zip.md5forwheels-core,wheels-cli,wheels-base-template,wheels-starter-app(was*.sha512/*.md5). The scoop-wheelsautoupdateconfig expects the.zip.sha512shape via\$url.sha512substitution — without.zip.in the middle, autoupdate 404s on every non-module artifact.wheels-modulealready used the correct shape; this PR brings the other four into line. No external consumers depend on the old shape (verified across homebrew-wheels, scoop-wheels, .deb/.rpm builders, framework code).scoop bucket add javastep to the Windows install instructions. Both real-user reports hitCouldn't find manifest for 'openjdk21' from 'java' bucketbefore they could proceed — Scoop'sdepends:declaration does not auto-add the dependency bucket on the user's behalf.lucli modules install wheels --force --url=…for users who already have standalone LuCLI. An Aside enumerates the trade-offs vs. the package-manager paths (binary name,LUCLI_HOMEisolation, JDK resolution, SQLite shim, channel awareness, upgrades). Triggered by Jay Dee's report of inferringwheels@besyntax — no such tag exists in LuCLI's registry, and the barewheelsregistry entry currently points at the stale wheels-cli-lucli mirror.Both
installing.mdx(start-here/) andinstallation.mdx(command-line-tools/) are updated in bothv4-0-0(released) andv4-0-1-snapshot(in-progress) doc trees.Files touched
tools/build/scripts/build-{base,cli,core,starterApp}.sh— checksum filenamestools/build/scripts/README.md— matching doc update.github/workflows/release.yml+release-candidate.yml—upload-artifactglob patterns (40 line edits, two files;snapshot.ymlinherits viauses:)web/sites/guides/src/content/docs/v4-0-{0,1-snapshot}/start-here/installing.mdx— Windows install stepsweb/sites/guides/src/content/docs/v4-0-{0,1-snapshot}/command-line-tools/installation.mdx— Windows section + new "Advanced: existing LuCLI install" sectionCompanion / follow-up work
scoop-wheelswith Excavator vs. self-host an autoupdate workflow.local.json) entry forwheelsto point atwheels-dev/wheelsdirectly, solucli modules install wheels(bare) lands a current version.Test plan
wheels-core-X.X.X.zip.sha512(and.zip.md5) in addition to the existingwheels-core-X.X.X.sha512shape... wait — this PR renames rather than adding. Verify no downstream tooling readswheels-core-X.X.X.sha512(verified locally — only callers are this repo's own workflows + scripts, all updated here).scoop bucket add java; scoop bucket add wheels https://github.com/wheels-dev/scoop-wheels; scoop install wheels-besucceeds (works today regardless of this PR — sanity-check that the docs match reality).pnpm --dir web/sites/guides buildor whatever your local incantation is). The new section uses existing<Aside>+ bash-codeblock patterns from the same file, so risk is low.lucli modules install --url=…snippet on a machine with LuCLI installed: confirmSNAP_TAGresolves to a non-empty value via the newjqpipeline, the empty-tag guard fires when the GitHub API is unreachable (e.g. force a network failure or hit the unauthenticated 60/hr rate limit), and the resolved URL is a real, downloadable asset before passing it tolucli.Refs #2758
Refs wheels-dev/scoop-wheels#2