Both cdk-cli build paths are broken, and the justfile carried a drifted cdk pin #28

New issue

Open

opened 2026-10-07 18:08:31 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-10-07 18:08:31 +01:00

Collaborator

Both paths that build cdk-cli are broken, and neither has been able to run for some time, so just balance and any other ecash CLI check have no working way to produce the binary they depend on.

Primary goals:

One working way to build cdk-cli — a single path, so the pin it uses cannot drift from the pins the mint and proxy build against.
The dead path removed, not left as a decoy — whichever of the two is not kept is deleted, so a reader cannot follow a recipe that silently cannot work.
Its cdk pin travels with the others — whatever remains is listed wherever the cdk pin sites are enumerated, so a re-pin cannot miss it again.

Current state and specifics

There are two separate implementations and both are non-functional.

The justfile recipe. justfile:104 defines build-cdk-cli as ./scripts/build-cdk-cli.sh. That script does not exist — scripts/ contains patch-cdk-path.sh but no build-cdk-cli.sh, on master or on any open branch. The recipe therefore fails immediately. just balance (justfile:108) depends on bin/cdk-cli and instructs the reader to run just build-cdk-cli first, so the balance check is unreachable too.

The devenv task. devenv.nix defines a build:cdk:cli task that clones cdkRepo, checks out cdkCommit and builds --bin cdk-cli inline. It has no trigger: its before list named devenv:processes:* tasks that this devenv version does not define, and those dead dependencies were removed when devenv shell was repaired, leaving the task reachable only by an explicit devenv tasks run. devenv tasks list shows it as a root.

The drifted pin. justfile:100-101 carried its own pin, independent of the four sites normally kept in step:

CDK_REPO := "https://github.com/vnprc/cdk.git"
CDK_COMMIT := "9523a003"

9523a003 is not a ref tip on the forge or on github.com/vnprc/cdk and is not present in any local object store — a third lost cdk revision, alongside the two recorded on vnprc/hashpool#21. The update-cdk recipe does try to keep this value in step (justfile:44 seds it), so the drift was unintended rather than deliberate. The URL and commit have since been pointed at the forge and at the branch's real revision on the open branches, which removes the drift trap but does not make the recipe work.

Scope

In scope: decide which of the two build paths survives, delete the other, and either add the missing script or drop the recipe that calls it. If the justfile path is kept, its pin must be enumerated alongside protocols/Cargo.toml, roles/Cargo.toml, devenv.nix and roles/Cargo.lock wherever that list is written down, because this issue exists precisely because it was not.

Out of scope: cdk-ehash's own [patch] pin, which also needs moving to the forge and is a separate repository.

Validation

From a clean tree with no bin/cdk-cli present, the chosen path produces a working binary, and just balance then runs without the "CDK CLI not built" error. Then confirm the binary was built from the same cdk revision the mint and proxy are pinned to, rather than from whatever the surviving pin happened to say — comparing the revisions is the check, not that the build succeeded.

Both paths that build `cdk-cli` are broken, and neither has been able to run for some time, so `just balance` and any other ecash CLI check have no working way to produce the binary they depend on. Primary goals: - **One working way to build `cdk-cli`** — a single path, so the pin it uses cannot drift from the pins the mint and proxy build against. - **The dead path removed, not left as a decoy** — whichever of the two is not kept is deleted, so a reader cannot follow a recipe that silently cannot work. - **Its cdk pin travels with the others** — whatever remains is listed wherever the cdk pin sites are enumerated, so a re-pin cannot miss it again. ### Current state and specifics There are two separate implementations and both are non-functional. **The justfile recipe.** `justfile:104` defines `build-cdk-cli` as `./scripts/build-cdk-cli.sh`. That script does not exist — `scripts/` contains `patch-cdk-path.sh` but no `build-cdk-cli.sh`, on master or on any open branch. The recipe therefore fails immediately. `just balance` (`justfile:108`) depends on `bin/cdk-cli` and instructs the reader to run `just build-cdk-cli` first, so the balance check is unreachable too. **The devenv task.** `devenv.nix` defines a `build:cdk:cli` task that clones `cdkRepo`, checks out `cdkCommit` and builds `--bin cdk-cli` inline. It has no trigger: its `before` list named `devenv:processes:*` tasks that this devenv version does not define, and those dead dependencies were removed when `devenv shell` was repaired, leaving the task reachable only by an explicit `devenv tasks run`. `devenv tasks list` shows it as a root. **The drifted pin.** `justfile:100-101` carried its own pin, independent of the four sites normally kept in step: ``` CDK_REPO := "https://github.com/vnprc/cdk.git" CDK_COMMIT := "9523a003" ``` `9523a003` is not a ref tip on the forge or on github.com/vnprc/cdk and is not present in any local object store — a third lost cdk revision, alongside the two recorded on vnprc/hashpool#21. The `update-cdk` recipe does try to keep this value in step (`justfile:44` seds it), so the drift was unintended rather than deliberate. The URL and commit have since been pointed at the forge and at the branch's real revision on the open branches, which removes the drift trap but does not make the recipe work. ### Scope In scope: decide which of the two build paths survives, delete the other, and either add the missing script or drop the recipe that calls it. If the justfile path is kept, its pin must be enumerated alongside `protocols/Cargo.toml`, `roles/Cargo.toml`, `devenv.nix` and `roles/Cargo.lock` wherever that list is written down, because this issue exists precisely because it was not. Out of scope: `cdk-ehash`'s own `[patch]` pin, which also needs moving to the forge and is a separate repository. ### Validation From a clean tree with no `bin/cdk-cli` present, the chosen path produces a working binary, and `just balance` then runs without the "CDK CLI not built" error. Then confirm the binary was built from the same cdk revision the mint and proxy are pinned to, rather than from whatever the surviving pin happened to say — comparing the revisions is the check, not that the build succeeded.