Pin umbra v0.185.0 so the value-flag guard reaches the build #1408

Merged

coilyco-ops merged 2 commits from aos/claude/ee98-pin185 into main

2026-08-29 12:12:28 +00:00

coilyco-ops commented

2026-08-29 11:47:34 +00:00

Owner

umbra#335 taught execverb that a grant guarding argN/any-arg beside a long flag of unknown arity is a build error, and gave a grant value-flag to declare its own. That reaches aosguard only through the pin: specgen embeds its own compiled copy of the generator, so --umbra-ref alone never moves it. The same shape made #1366 look landed twice while the shipped binary was unchanged.

Both halves move together:

ARG SPECGEN_VERSION 0.184.0 -> 0.185.0 picks the generator
specverb.lock v0.184.0 -> v0.185.0 picks what generated code imports

Verified against the real guardfile, not a fixture

Added the exact trap #1351 describes to can run get in kubectl.kdl:

allow-flag --context
deny-when arg0 matches kube-system

specgen: parse exec guardfile .../kubectl.kdl: execverb: grant "get" guards a
positional (`argN`/`any-arg`) and allows "--context", whose arity is unknown.
If it takes a separate value token, declare `value-flag "--context"` so the
value is not read as a positional. If it is a boolean, declare it anyway to
state that (fail-closed)

Reverted after measuring. A clean build at the new pin still produces a working binary - issue pin keeps its widened <owner> <repo> <index> signature and kubectl get still fails closed without --context.

One thing worth recording

The re-lock reads the vendored specs rather than fetching upstream, so no swagger moved - only specverb.lock did. I had assumed on #1377 that just aosguard-lock would refetch every spec and that assumption was wrong. It does not change #1377's conclusion, since the vendored specs are themselves pruned and genuinely lack issueCreateLabel (88 and 66 ops), but I corrected it on that issue.

Closes #1351

umbra#335 taught execverb that a grant guarding `argN`/`any-arg` beside a long flag of unknown arity is a **build error**, and gave a grant `value-flag` to declare its own. That reaches aosguard only through the pin: specgen embeds its own compiled copy of the generator, so `--umbra-ref` alone never moves it. The same shape made #1366 look landed twice while the shipped binary was unchanged. Both halves move together: * `ARG SPECGEN_VERSION` 0.184.0 -> 0.185.0 picks the generator * `specverb.lock` v0.184.0 -> v0.185.0 picks what generated code imports ## Verified against the real guardfile, not a fixture Added the exact trap #1351 describes to `can run get` in `kubectl.kdl`: ```kdl allow-flag --context deny-when arg0 matches kube-system ``` ``` specgen: parse exec guardfile .../kubectl.kdl: execverb: grant "get" guards a positional (`argN`/`any-arg`) and allows "--context", whose arity is unknown. If it takes a separate value token, declare `value-flag "--context"` so the value is not read as a positional. If it is a boolean, declare it anyway to state that (fail-closed) ``` Reverted after measuring. A clean build at the new pin still produces a working binary - `issue pin` keeps its widened `<owner> <repo> <index>` signature and `kubectl get` still fails closed without `--context`. ## One thing worth recording The re-lock **reads the vendored specs rather than fetching upstream**, so no swagger moved - only `specverb.lock` did. I had assumed on #1377 that `just aosguard-lock` would refetch every spec and that assumption was wrong. It does not change #1377's conclusion, since the vendored specs are themselves pruned and genuinely lack `issueCreateLabel` (88 and 66 ops), but I corrected it on that issue. Closes #1351

coilyco-ops added 1 commit

2026-08-29 11:47:34 +00:00

chore(aosguard): pin umbra v0.185.0, so the value-flag guard reaches the build

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

Details

ci / gate (pull_request) Successful in 1m6s

Details

dev-base-pr / build (pull_request) Failing after 15m25s

Details

9c8d17a2cf

umbra#335 taught execverb that a grant guarding argN or any-arg beside a
long flag of unknown arity is a build error, and gave a grant `value-flag`
to declare its own. That reaches aosguard only through the pin: specgen
embeds its own compiled copy, so `--umbra-ref` alone never moves it. The
same shape made agentic-os#1366 look landed twice.

Both halves move together. ARG SPECGEN_VERSION picks the generator, and
specverb.lock picks what generated code imports.

Verified against the real guardfile rather than a fixture: adding
`allow-flag --context` and `deny-when arg0` to `can run get` in
kubectl.kdl is now refused at build with the flag named and both remedies
spelled. Reverted after measuring.

The re-lock reads the vendored specs rather than fetching, so no spec moved.

Closes coilyco-flight-deck/agentic-os#1351

Co-authored-by: Kai Siren <coilysiren@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>
Agent-Role: platform

coilyco-ops added 1 commit

2026-08-29 12:09:07 +00:00