Push the Forgejo policy down to deploy instead of it fetching up #1410

Merged

coilyco-ops merged 1 commit from aos/claude/ee98-vendorpolicy into main

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

coilyco-ops commented

2026-08-29 12:04:03 +00:00

Owner

coilyco-bridge/deploy needs a vendored copy of forgejo.kdl and its pruned spec so its MCP guardfile can inherit them.

Config lives at the lowest layer that fully determines it and is never fetched downward, and a CI-time fetch is the same coupling wearing a different hat - it makes deploy's build depend on reaching this repo. So the bytes arrive by a push, which is the authoring-vs-rollout split already in force everywhere else.

Shape

vendor-forgejo-policy.yml fires on a release push touching either file. The script copies both into services/forgejo-mcp/vendor/aosguard/ beside a SOURCE file naming the source commit, pushes a branch, and opens a pull request.

It never merges. Deploy reviews and lands its own vendored copy, so nothing here writes deploy's main. A test asserts /merge appears nowhere in the script.

The credential is not part of this, deliberately

DEPLOY_WRITE_TOKEN does not exist. Minting and placing an Actions secret is an operator step on a hosted surface, outside what I should do.

Until it exists the job is inert rather than broken: the script warns and exit 0s on an absent token, the same guard aos-cli-release.sh uses for its tap and scoop pushes. tests/test_vendor_forgejo_policy.py holds that guard in place, because the two failure modes are asymmetric - a job that fails every release gets disabled, and one that pushes on a token nobody reviewed is worse.

So this is safe to land now and starts working the moment the secret lands.

What it unblocks

Once deploy carries the vendored pair, services/forgejo-mcp/forgejo.mcp.kdl can inherit it rather than restating grants. That is the deduplication #1365 was originally after - and per my finding there, it is available only for this rung, since the sirens-echo tier fixes every path to one repository and cannot inherit a parameterized one.

It is also the prerequisite for #1377: that leaf needs issueCreateLabel in the vendored spec, which neither pruned copy carries today.

769 tests pass, full pre-commit suite green.

Closes #1376

`coilyco-bridge/deploy` needs a vendored copy of `forgejo.kdl` and its pruned spec so its MCP guardfile can `inherit` them. Config lives at the lowest layer that fully determines it and is never fetched downward, and a CI-time fetch is the same coupling wearing a different hat - it makes deploy's build depend on reaching this repo. So the bytes arrive by a **push**, which is the authoring-vs-rollout split already in force everywhere else. ## Shape `vendor-forgejo-policy.yml` fires on a `release` push touching either file. The script copies both into `services/forgejo-mcp/vendor/aosguard/` beside a `SOURCE` file naming the source commit, pushes a **branch**, and opens a pull request. It never merges. Deploy reviews and lands its own vendored copy, so nothing here writes deploy's `main`. A test asserts `/merge` appears nowhere in the script. ## The credential is not part of this, deliberately `DEPLOY_WRITE_TOKEN` does not exist. Minting and placing an Actions secret is an operator step on a hosted surface, outside what I should do. Until it exists the job is **inert rather than broken**: the script warns and `exit 0`s on an absent token, the same guard `aos-cli-release.sh` uses for its tap and scoop pushes. `tests/test_vendor_forgejo_policy.py` holds that guard in place, because the two failure modes are asymmetric - a job that fails every release gets disabled, and one that pushes on a token nobody reviewed is worse. So this is safe to land now and starts working the moment the secret lands. ## What it unblocks Once deploy carries the vendored pair, `services/forgejo-mcp/forgejo.mcp.kdl` can `inherit` it rather than restating grants. That is the deduplication #1365 was originally after - and per my finding there, it is available only for **this** rung, since the sirens-echo tier fixes every path to one repository and cannot inherit a parameterized one. It is also the prerequisite for #1377: that leaf needs `issueCreateLabel` in the vendored spec, which neither pruned copy carries today. 769 tests pass, full pre-commit suite green. Closes #1376

coilyco-ops added 1 commit

2026-08-29 12:04:03 +00:00

feat(ci): push the Forgejo policy down to deploy instead of it fetching up

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

Details

ci / gate (pull_request) Successful in 1m55s

Details

3cf90334c0

deploy needs a vendored copy of forgejo.kdl and its pruned spec so its MCP
guardfile can inherit them. Config lives at the lowest layer that fully
determines it and is never fetched downward, and a CI-time fetch is the
same coupling wearing a different hat, so the bytes arrive by a push.

The workflow fires on a release push touching either file. The script
copies both into services/forgejo-mcp/vendor/aosguard/ beside a SOURCE
file naming the commit, pushes a branch, and opens a pull request. It
never merges: deploy reviews and lands its own copy.

DEPLOY_WRITE_TOKEN does not exist yet, and minting it is an operator step
on a hosted surface. Until it does the job is inert rather than broken -
the script warns and exits 0, the same guard aos-cli-release.sh uses for
its tap and scoop pushes. A test holds that guard, because a job failing
every release gets disabled and one pushing on an unreviewed token is
worse.

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

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

coilyco-ops merged commit 0122c850d1 into main

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

coilyco-ops deleted branch aos/claude/ee98-vendorpolicy

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

coilyco-ops referenced this pull request from a commit

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

Push the Forgejo policy down to deploy instead of it fetching up (#1410)