chore(aosguard): move the pin to specgen and umbra v0.175.0 #1320
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!1320
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?
Follows #1316, which pinned v0.173.0. Prerequisite for #1318 / #1105.
Why another bump
#1316 landed while two more umbra fixes were still in flight. Both are needed by #1105's
issue createshadow, and the guardfile is incorrect at runtime without them even though it parses under v0.173.0:issue createwithout--milestonedies with$milestone is not set (an optional input that was not supplied), because the shadow binds the leaf's optional fields.--milestone 16sends the JSON string"16"to anint64field, which is the silently-ignored wrong typeagentic-os#1047is about.v0.173.0 is enough to parse the guardfile, which is why #1316 was green. It is not enough to run it correctly.
Why both files move together
test_specgen_pin_is_owned_by_the_dependency_lockasserts the Dockerfile'sARG SPECGEN_VERSIONequals the lock'scliGuard.Scope
No behaviour change here. The guardfiles are untouched; #1318 carries the shadow. The lock was regenerated with
just aosguard-lockusing the released specgen 0.175.0 from the tap, not a local build.