fix(release): let the dependency lock own the specgen pin #1057

Merged

coilysiren merged 1 commit from aos/claude/td77 into main

2026-08-14 05:36:51 +00:00

coilyco-ops commented

2026-08-14 05:18:12 +00:00

Owner

The aos-cli-release workflow has been red since #1053, failing at Build binaries and package metadata (run 3321, and 3307 and 3285 before it):

specgen: parse exec guardfile /tmp/.../aosguard-skill-source/guardfiles/aosguard/actions.kdl:
execverb: unknown node "provider" in wrap body (fail-closed)

Why

specgen was pinned twice. #1053 declared provider ssm in the two aosguard guardfiles and moved the lock and the dev-base image to umbra 0.139.0, but aos-cli/release.env still said SPECGEN_VERSION=0.134.0. The release build downloads its own driver from that file, so it fetched a driver five releases behind the guardfiles it was asked to parse and correctly failed closed on a node it had never heard of.

What changes

scripts/aos-release-build.sh - reads cliGuard out of .specgen/guardfiles/specverb.lock instead of sourcing a second pin
aos-cli/release.env - deleted, it held nothing else
tests/test_aos_cli_release.py - holds the remaining ARG SPECGEN_VERSION in the dev-base Dockerfile to the same lock value, and asserts the release script carries no pin of its own

The driver and the lock have to agree on the framework version, so this is one tunable in one owning source rather than three copies that drift apart on the next umbra bump.

Verification

ward exec aos-release-build - exit 0, all 29 artifacts, version: aos-v0.201.0
ward exec test - 523 passed with specgen 0.139.0 on PATH
pre-commit run --all-files - clean
Reproduced the failing step directly: specgen 0.134.0 rejects actions.kdl, 0.139.0 builds the skill and binary

Note, not fixed here

aos-v0.200.0 and aos-v0.201.0 are tagged with no release behind them, left by the runs that failed after tag-bump succeeded. The next green run bumps past them to 0.202.0, so nothing is blocked, but the tags are dangling.

🤖 Generated with Claude Code

The `aos-cli-release` workflow has been red since #1053, failing at **Build binaries and package metadata** ([run 3321](https://forgejo.coilysiren.me/coilyco-flight-deck/agentic-os/actions/runs/3321), and 3307 and 3285 before it): ``` specgen: parse exec guardfile /tmp/.../aosguard-skill-source/guardfiles/aosguard/actions.kdl: execverb: unknown node "provider" in wrap body (fail-closed) ``` ## Why specgen was pinned twice. #1053 declared `provider ssm` in the two aosguard guardfiles and moved the lock and the dev-base image to umbra 0.139.0, but `aos-cli/release.env` still said `SPECGEN_VERSION=0.134.0`. The release build downloads its own driver from that file, so it fetched a driver five releases behind the guardfiles it was asked to parse and correctly failed closed on a node it had never heard of. ## What changes * `scripts/aos-release-build.sh` - reads `cliGuard` out of `.specgen/guardfiles/specverb.lock` instead of sourcing a second pin * `aos-cli/release.env` - deleted, it held nothing else * `tests/test_aos_cli_release.py` - holds the remaining `ARG SPECGEN_VERSION` in the dev-base Dockerfile to the same lock value, and asserts the release script carries no pin of its own The driver and the lock have to agree on the framework version, so this is one tunable in one owning source rather than three copies that drift apart on the next umbra bump. ## Verification * `ward exec aos-release-build` - exit 0, all 29 artifacts, `version: aos-v0.201.0` * `ward exec test` - 523 passed with specgen 0.139.0 on PATH * `pre-commit run --all-files` - clean * Reproduced the failing step directly: specgen 0.134.0 rejects `actions.kdl`, 0.139.0 builds the skill and binary ## Note, not fixed here `aos-v0.200.0` and `aos-v0.201.0` are tagged with no release behind them, left by the runs that failed after `tag-bump` succeeded. The next green run bumps past them to `0.202.0`, so nothing is blocked, but the tags are dangling. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

coilyco-ops added 1 commit

2026-08-14 05:18:12 +00:00

fix(release): let the dependency lock own the specgen pin

ci / aos-cli-tests (pull_request) Successful in 42s

Details

ci / ward-doctor (pull_request) Successful in 14s

Details

ci / gate (pull_request) Successful in 2m2s

Details

b15fd39c08

The aos release build downloaded specgen from its own `aos-cli/release.env`
pin, which sat at 0.134.0 while `.specgen/guardfiles/specverb.lock` and the
dev-base image had moved to 0.139.0. #1053 declared `provider ssm` in the two
aosguard guardfiles, a node only the newer driver knows, so the release build
fetched the stale driver and failed closed:

    specgen: parse exec guardfile .../guardfiles/aosguard/actions.kdl:
    execverb: unknown node "provider" in wrap body (fail-closed)

The driver and the lock have to agree on the framework version, so a second
pin is drift waiting to happen rather than a tunable. `aos-release-build.sh`
now reads `cliGuard` out of the lock and `aos-cli/release.env` is gone. A test
holds the remaining Dockerfile `ARG SPECGEN_VERSION` to the same lock value so
the last copy cannot drift either.

Verified: `ward exec aos-release-build` builds all 29 artifacts, and the full
suite is 523 passed with specgen 0.139.0 on PATH.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Kai Siren <coilysiren@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Kai Siren <coilysiren@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>

coilyco-ops requested review from coilysiren

2026-08-14 05:18:12 +00:00