Push the Forgejo aosguard policy and its pruned swagger to deploy, so a vendored copy stays pinned without deploy fetching upward #1376

New issue

Closed

opened 2026-08-29 04:55:41 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-29 04:55:41 +00:00

Owner

Deferred from the #1365 arc. The umbra and mcp-beaver halves are landed (umbra v0.181.0, mcp-beaver 1350f95); this is the cross-repo transport that has not been built.

What is needed

coilyco-bridge/deploy has to hold a vendored, pinned copy of two files so its Forgejo MCP guardfile can inherit them:

.specgen/guardfiles/aosguard/forgejo.kdl - the operator policy
.specgen/guardfiles/aosguard/forgejo.swagger.v1.json.gz - the pruned API document, 17,492 bytes on disk

Why it must be a push

Kai's config-placement rule: config lives at the lowest layer that fully determines it, is consumed only by that layer or higher, and is never fetched downward. A shipped product does not reach up into a reference repo for its own runtime config.

So deploy must not pull these at deploy time or runtime, and a CI-time fetch is the same coupling wearing a different hat: it makes deploy's build depend on reaching this repo. The vendored copy has to arrive by a push that deploy then commits and pins, which is the authoring-vs-rollout split already in force - authored here, rolled out by a push.

Shape

A workflow here that fires when .specgen/guardfiles/aosguard/forgejo.* changes on the release ref, and opens a PR in deploy updating services/forgejo-mcp/vendor/aosguard/ plus the pin it records. aos-cli-release.yml already watches .specgen/guardfiles/** for its own trigger, so the path filter is proven; what is new is a cross-repo PR and the credential that opens it.

Deploy runs pull-request-and-merge, so the bump arrives as a reviewable PR rather than a direct push, which is also what makes an upstream policy change visible instead of silent.

Blocked on

The vocabulary decision in #1365. Vendoring the operator policy is only useful once it is settled whether the MCP adopts the aosguard resource nouns, keeps its own, or the two get mapped. Building the transport before that would pin a copy nobody can inherit yet.

Not established

Whether a release asset would serve better than a bot PR. An asset keeps this repo from needing write access to deploy, at the cost of deploy fetching it, which is the thing the rule forbids. I have not looked for a third shape where the artifact is pushed to a registry both repos already use.

Deferred from the `#1365` arc. The umbra and mcp-beaver halves are landed (`umbra v0.181.0`, `mcp-beaver 1350f95`); this is the cross-repo transport that has not been built. ## What is needed `coilyco-bridge/deploy` has to hold a vendored, pinned copy of two files so its Forgejo MCP guardfile can `inherit` them: * `.specgen/guardfiles/aosguard/forgejo.kdl` - the operator policy * `.specgen/guardfiles/aosguard/forgejo.swagger.v1.json.gz` - the pruned API document, 17,492 bytes on disk ## Why it must be a push Kai's config-placement rule: config lives at the lowest layer that fully determines it, is consumed only by that layer or higher, and is never fetched downward. A shipped product does not reach up into a reference repo for its own runtime config. So deploy must not pull these at deploy time or runtime, and a CI-time fetch is the same coupling wearing a different hat: it makes deploy's build depend on reaching this repo. The vendored copy has to arrive by a push that deploy then commits and pins, which is the authoring-vs-rollout split already in force - authored here, rolled out by a push. ## Shape A workflow here that fires when `.specgen/guardfiles/aosguard/forgejo.*` changes on the release ref, and opens a PR in deploy updating `services/forgejo-mcp/vendor/aosguard/` plus the pin it records. `aos-cli-release.yml` already watches `.specgen/guardfiles/**` for its own trigger, so the path filter is proven; what is new is a cross-repo PR and the credential that opens it. Deploy runs `pull-request-and-merge`, so the bump arrives as a reviewable PR rather than a direct push, which is also what makes an upstream policy change visible instead of silent. ## Blocked on The vocabulary decision in `#1365`. Vendoring the operator policy is only useful once it is settled whether the MCP adopts the aosguard resource nouns, keeps its own, or the two get mapped. Building the transport before that would pin a copy nobody can inherit yet. ## Not established Whether a release asset would serve better than a bot PR. An asset keeps this repo from needing write access to deploy, at the cost of deploy fetching it, which is the thing the rule forbids. I have not looked for a third shape where the artifact is pushed to a registry both repos already use.

coilyco-ops added the

role/platform

autonomy

async-consult

labels

2026-08-29 07:01:53 +00:00

coilyco-ops added this to the Rules that do not hold: silent guards, full budgets, second writers milestone

2026-08-29 07:55:38 +00:00

coilyco-ops referenced this issue

2026-08-29 11:12:10 +00:00

#1349 breaks 65 existing aosguard ops kubectl call sites at rebuild, including two live-mutation scripts #1352

coilyco-ops referenced this issue