chore: follow umbra's module rename #1050

Merged

coilysiren merged 1 commit from chore/umbra-module-rename into main

2026-08-14 04:02:21 +00:00

coilyco-ops commented

2026-08-14 03:57:46 +00:00

Owner

cli-guard is now forgejo.coilysiren.me/coilyco-flight-deck/umbra (umbra#285, released v0.138.0). This catches AOS up. 28 files.

Mechanical

file	change
`.specgen/guardfiles/specverb.lock`	re-locked, now pins `umbra v0.138.0`
`docker/dev-base/full/Dockerfile`	release URL, and `SPECGEN_VERSION` 0.134.0 -> 0.138.0
`scripts/aos-release-build.sh`	release URL
`scripts/ci/repo-test-gate.sh`	release URL
`aos-cli/repositories/sealed-repos.gitignore`	repo path

The driver bump is not optional. specgen resolves the framework module path from a constant compiled into the binary, so a 0.134 driver against an umbra-pinned lock disagrees about which module to require. This is not theoretical - running the suite against the stale PATH specgen (v0.135.0) fails the aosguard_binary build fixture on 11 tests, and passes once driver and lock match.

Three that would have failed silently

These are the reason this is a real change and not a find-and-replace.

`agentic_os/pre_commit/leak_guard_rules.py`

The umbra->ward dependency-cycle rule is scoped by repos, matched against the slug from remote.origin.url. That slug is now umbra, so the rule simply stopped applying - no error, no warning, just an architectural guard quietly not enforcing. Both slugs are now listed so a checkout still on the old remote keeps matching.

`agentic_os/prod_install_ref.py`

Product.repository builds the Forgejo release URL from the literal "cli-guard". Now "umbra". The old key is retained as an alias so guard / cli-guard keep resolving for anyone who types them.

`scripts/sync-actions-secrets.py`

The secret mapping is keyed by repo slug, so CI_RELEASE_TOKEN and the Telegram creds would have synced to a stale target.

Tests and docs

tests/test_aosguard.py asserted the literal "cli-guard <version>" inside the lock's goMod/goSum lines; that assertion follows the module path. The lock's own cliGuard json key is deliberately unchanged - umbra kept it so existing locks stay readable rather than degrading to a silently empty ref.

Remaining prose renamed across README, AGENTS.md, justfile, docs/, the aosguard .kdl comments and two composed skill references. CLIGUARD_* env vars and the ~/.cli-guard audit path are untouched by design - see umbra#285 for why.

Verification

509 tests pass (tests/test_check_yaml_strict.py skipped: ruamel is not installed in this environment, unrelated)
aosguard builds end to end against umbra v0.138.0
its guards still fire: aosguard ops aws s3 ls s3://prod-tfstate-bucket is denied on arg0 matching *tfstate*

One operator note: the brew-installed specgen on this machine is v0.135.0. Anyone building aosguard locally needs brew upgrade to 0.138.0 or newer, matching the Dockerfile pin.

`cli-guard` is now `forgejo.coilysiren.me/coilyco-flight-deck/umbra` (umbra#285, released v0.138.0). This catches AOS up. 28 files. ## Mechanical | file | change | | --- | --- | | `.specgen/guardfiles/specverb.lock` | re-locked, now pins `umbra v0.138.0` | | `docker/dev-base/full/Dockerfile` | release URL, and `SPECGEN_VERSION` 0.134.0 -> 0.138.0 | | `scripts/aos-release-build.sh` | release URL | | `scripts/ci/repo-test-gate.sh` | release URL | | `aos-cli/repositories/sealed-repos.gitignore` | repo path | **The driver bump is not optional.** specgen resolves the framework module path from a constant compiled into the binary, so a 0.134 driver against an umbra-pinned lock disagrees about which module to require. This is not theoretical - running the suite against the stale PATH specgen (v0.135.0) fails the `aosguard_binary` build fixture on 11 tests, and passes once driver and lock match. ## Three that would have failed silently These are the reason this is a real change and not a find-and-replace. ### `agentic_os/pre_commit/leak_guard_rules.py` The umbra->ward dependency-cycle rule is scoped by `repos`, matched against the slug from `remote.origin.url`. That slug is now `umbra`, so **the rule simply stopped applying** - no error, no warning, just an architectural guard quietly not enforcing. Both slugs are now listed so a checkout still on the old remote keeps matching. ### `agentic_os/prod_install_ref.py` `Product.repository` builds the Forgejo release URL from the literal `"cli-guard"`. Now `"umbra"`. The old key is retained as an alias so `guard` / `cli-guard` keep resolving for anyone who types them. ### `scripts/sync-actions-secrets.py` The secret mapping is keyed by repo slug, so `CI_RELEASE_TOKEN` and the Telegram creds would have synced to a stale target. ## Tests and docs `tests/test_aosguard.py` asserted the literal `"cli-guard <version>"` inside the lock's `goMod`/`goSum` lines; that assertion follows the module path. The lock's own `cliGuard` **json key is deliberately unchanged** - umbra kept it so existing locks stay readable rather than degrading to a silently empty ref. Remaining prose renamed across README, AGENTS.md, justfile, docs/, the aosguard `.kdl` comments and two composed skill references. `CLIGUARD_*` env vars and the `~/.cli-guard` audit path are untouched by design - see umbra#285 for why. ## Verification - **509 tests pass** (`tests/test_check_yaml_strict.py` skipped: `ruamel` is not installed in this environment, unrelated) - `aosguard` **builds end to end** against umbra v0.138.0 - its guards still fire: `aosguard ops aws s3 ls s3://prod-tfstate-bucket` is denied on `arg0` matching `*tfstate*` One operator note: the brew-installed `specgen` on this machine is v0.135.0. Anyone building aosguard locally needs `brew upgrade` to 0.138.0 or newer, matching the Dockerfile pin.

coilyco-ops added 1 commit

2026-08-14 03:57:47 +00:00

chore: follow umbra's module rename

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

Details

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

Details

ci / gate (pull_request) Successful in 1m10s

Details

dev-base-pr / build (pull_request) Successful in 3m48s

Details

872c576e02

cli-guard is now forgejo.coilysiren.me/coilyco-flight-deck/umbra
(umbra#285, released v0.138.0). This catches AOS up.

Mechanical:
  .specgen/guardfiles/specverb.lock  re-locked, now pins umbra v0.138.0
  docker/dev-base/full/Dockerfile    release URL, and SPECGEN_VERSION
                                     0.134.0 -> 0.138.0
  scripts/aos-release-build.sh       release URL
  scripts/ci/repo-test-gate.sh       release URL
  aos-cli/.../sealed-repos.gitignore repo path

The driver bump is not optional. specgen resolves the framework module
path from a constant compiled into the binary, so a 0.134 driver against
an umbra-pinned lock disagrees about which module to require. Verified by
running the suite against the stale PATH specgen (v0.135.0): the aosguard
build fixture fails until driver and lock match.

Three that would have failed silently:

  agentic_os/pre_commit/leak_guard_rules.py
      The umbra->ward dependency-cycle rule is scoped by `repos`, matched
      against the slug from remote.origin.url. That slug is now "umbra",
      so the rule simply stopped applying - no error, just an unenforced
      architectural guard. Both slugs are listed so an old checkout keeps
      matching.

  agentic_os/prod_install_ref.py
      Product.repository built the Forgejo release URL from "cli-guard".
      Now "umbra"; the old key stays as an alias so `guard`/`cli-guard`
      keep resolving for anyone typing them.

  scripts/sync-actions-secrets.py
      The secret mapping is keyed by repo slug, so CI_RELEASE_TOKEN and
      the Telegram creds would have synced to a stale target.

tests/test_aosguard.py asserted the literal "cli-guard <version>" inside
the lock's goMod/goSum lines; that follows the module path. The lock's
own `cliGuard` json key is deliberately unchanged - umbra kept it so old
locks stay readable.

Verified: 509 tests pass, aosguard builds end to end against umbra
v0.138.0, and its guards still fire (`s3 ls s3://prod-tfstate-bucket` is
denied on arg0).

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

coilyco-ops requested review from coilysiren

2026-08-14 03:57:47 +00:00