chore(aosguard): pin specgen and umbra to v0.173.0 #1316
No reviewers
Labels
No labels
burndown-2026-06
burndown-2026-08
autonomy
async-consult
autonomy
epic
autonomy
headless
autonomy
live-collab
coherence-core
priority
P0
priority
P1
priority
P2
priority
P3
priority
P4
qa-fixture
role/advocate
role/director
role/exec
role/frontend
role/gamedev
role/human
role/platform
role/qa
role/science
role/sysadmin
state
ambient
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
coilyco-flight-deck/agentic-os!1316
Loading…
Reference in a new issue
No description provided.
Delete branch "aos/1105-pin-specgen-0172"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Prerequisite for #1105, split out so it can land on its own. Supersedes the first shape of #1311.
Why this is separate
#1105 needs
matcheson an action input, which umbra ships in v0.172.0 (umbra#322) with its alternation fix in v0.173.0 (umbra#324). The guardfile that uses it cannot build in CI until the image carries a specgen that can parse it.scripts/ci/repo-test-gate.shbootstraps the pinned specgen only when none is on PATH, and the:releasecontainer thegatejob runs in bakes one in atARG SPECGEN_VERSION. Measured on the first attempt, where the image's specgen 0.167.0 met the new syntax:So the pin lands first and republishes the image, then the guardfile change goes green against it. Two landings rather than one red merge.
Why v0.173.0 and not v0.172.0
The branch first pinned v0.172.0 and went green there. umbra#324 landed while it sat:
matchesnow takes alternative globs, which #1105's guardfile needs so it can enumerate the label vocabulary rather than wildcard it. Wildcarding is unsafe here - the labels endpoint drops an unknown name silently with a 200, sopriority/*would acceptpriority/p2, let the write through, and apply nothing.Moving the pin now means one image republish instead of two.
Why both files move together
test_specgen_pin_is_owned_by_the_dependency_lockasserts the Dockerfile'sARG SPECGEN_VERSIONequals the lock'scliGuard, so the lock bump and the ARG bump are one change by construction.Scope
No behaviour change. The guardfiles are untouched, so this is the dependency bump alone. The lock was regenerated with
just aosguard-lockusing the released specgen 0.173.0 from the tap, not a local build.chore(aosguard): pin specgen and umbra to v0.172.0to chore(aosguard): pin specgen and umbra to v0.173.0