Fleet sweep: 4 repos on merge-remote-main are live with a pr-guard pinned below the lane exemption, and 10 more are latent #1383

New issue

Closed

opened 2026-08-29 06:11:26 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-08-29 06:11:26 +00:00

Owner

Handed over by the science seat after pr-guard refused a lane-legitimate push to main on housecast. Their diagnosis is correct in every particular I checked, and they corrected an earlier wrong read of their own before handing it on. #1330 fixed the logic; this is the rollout half.

Verified

The exemption cutoff is exactly where they said:

aos-precommit-v0.48.0   NO exemption
aos-precommit-v0.49.0   NO exemption
aos-precommit-v0.50.0   HAS lane exemption     <- 3d80e355 lands here
aos-precommit-v0.55.0   HAS lane exemption     <- current latest

git tag --contains 3d80e355 returns aos-precommit-v0.50.0 as the first packaging tag. .pre-commit-hooks.yaml:49 already documents the exemption, so the declaration, the guard, and the doc all agree. Only the shipped script on a stale pin does not.

The sweep, refined by whether the hook is actually installed

The pre-push hook has to be installed for any of this to bite, and apply-agentic-os-hooks.py installs pre-commit, commit-msg, and prepare-commit-msg only. So the practical set is much smaller than the pinned set, and splits three ways.

Live and wrong - merge-remote-main, pin below v0.50.0, pre-push installed. These refuse their own declared lane today:

coilyco-flight-deck/agent-proxy - v0.49.0
coilyco-gaming/eco-mods - v0.33.0
coilyco-gaming/eco-ops - v0.35.0
coilyco-gaming/factorio-mods - v0.24.0
coilyco-gaming/housecast - v0.49.0, not resident here, reported live

Correct - the only repo both installed and fixed:

coilyco-bridge/agentic-os-kai - v0.50.0

Latent - merge-remote-main and a stale pin, but no pre-push hook. Each becomes live the moment anyone runs pre-commit install, which is exactly what the science seat did:

agentic-os-hardware v0.18.0, agentic-os-xxx v0.49.0, agent-compose v0.24.0, eco-app v0.35.0, factory-game-v3 v0.49.0, galaxy-gen v0.18.0, steam-ops v0.43.0, lore v0.31.0, voice-corpus v0.49.0, and coilysiren/coilysiren which pins nothing at all.

Repos on another lane are unaffected by design: deploy, infrastructure, and this repo run pull-request-and-merge, sirens-echo runs pull-request, and the guard is correct for all of them.

Why this was invisible

The old refusal reads:

[pr-guard] refusing to push directly to 'main'. Branch and open a PR.
       Deliberate override: git push --no-verify

The fixed one appends a sentence naming the lane and saying the guard stands down. So the absence of that sentence is the only tell that a stale pin, rather than policy, produced the refusal. An agent reading the old text has nothing to distinguish the two, and the documented escape is --no-verify, which is a fleet-wide never. The science seat branched instead, which was the right call under a wrong message.

Recommended staging, not yet done

Splitting on jump size rather than doing one blanket --rev latest:

The four live ones plus housecast. agent-proxy, factory-game-v3, agentic-os-xxx, voice-corpus, and housecast sit at v0.49.0, one tag below, so a bump is nearly a no-op on validator content. eco-mods (v0.33.0), eco-ops (v0.35.0), and factorio-mods (v0.24.0) are longer jumps and want checking per repo.
The latent ten, as a separate pass, because v0.18.0 to v0.55.0 crosses 37 releases of new validators and will surface pre-existing violations that are real work rather than a pin edit. That is the same class of thing that had umbra's main red on code-comments before any of tonight's work touched it.

A blanket bump would convert a silent lane override into a wall of unrelated hook failures across nine repos at once, which trades one invisible problem for a loud one nobody scheduled.

Not established

Whether any repo has actually been pushed with --no-verify because of this. The refusal names that as the deliberate override, and an agent under time pressure could reasonably have taken it. That is worth a reflog or audit sweep, and I have not run one.

Also unswept: repos not resident on this host. I enumerated from on-disk checkouts under the projects root, so the count is a floor rather than the fleet total.

#1382 - a fresh clone installs no hooks at all, so the local gate usually does not bind. The two interact: that issue is why only 5 of 15 merge-remote-main repos have the hook, and this one is why 4 of those 5 are wrong when it does run.

Handed over by the science seat after `pr-guard` refused a lane-legitimate push to `main` on `housecast`. Their diagnosis is correct in every particular I checked, and they corrected an earlier wrong read of their own before handing it on. `#1330` fixed the logic; this is the rollout half. ## Verified The exemption cutoff is exactly where they said: ``` aos-precommit-v0.48.0 NO exemption aos-precommit-v0.49.0 NO exemption aos-precommit-v0.50.0 HAS lane exemption <- 3d80e355 lands here aos-precommit-v0.55.0 HAS lane exemption <- current latest ``` `git tag --contains 3d80e355` returns `aos-precommit-v0.50.0` as the first packaging tag. `.pre-commit-hooks.yaml:49` already documents the exemption, so the declaration, the guard, and the doc all agree. Only the shipped script on a stale pin does not. ## The sweep, refined by whether the hook is actually installed The pre-push hook has to be installed for any of this to bite, and `apply-agentic-os-hooks.py` installs `pre-commit`, `commit-msg`, and `prepare-commit-msg` only. So the practical set is much smaller than the pinned set, and splits three ways. **Live and wrong** - `merge-remote-main`, pin below v0.50.0, pre-push installed. These refuse their own declared lane today: * `coilyco-flight-deck/agent-proxy` - v0.49.0 * `coilyco-gaming/eco-mods` - v0.33.0 * `coilyco-gaming/eco-ops` - v0.35.0 * `coilyco-gaming/factorio-mods` - v0.24.0 * `coilyco-gaming/housecast` - v0.49.0, not resident here, reported live **Correct** - the only repo both installed and fixed: * `coilyco-bridge/agentic-os-kai` - v0.50.0 **Latent** - `merge-remote-main` and a stale pin, but no pre-push hook. Each becomes live the moment anyone runs `pre-commit install`, which is exactly what the science seat did: * `agentic-os-hardware` v0.18.0, `agentic-os-xxx` v0.49.0, `agent-compose` v0.24.0, `eco-app` v0.35.0, `factory-game-v3` v0.49.0, `galaxy-gen` v0.18.0, `steam-ops` v0.43.0, `lore` v0.31.0, `voice-corpus` v0.49.0, and `coilysiren/coilysiren` which pins nothing at all. Repos on another lane are unaffected by design: `deploy`, `infrastructure`, and this repo run `pull-request-and-merge`, `sirens-echo` runs `pull-request`, and the guard is correct for all of them. ## Why this was invisible The old refusal reads: ``` [pr-guard] refusing to push directly to 'main'. Branch and open a PR. Deliberate override: git push --no-verify ``` The fixed one appends a sentence naming the lane and saying the guard stands down. So the absence of that sentence is the only tell that a stale pin, rather than policy, produced the refusal. An agent reading the old text has nothing to distinguish the two, and the documented escape is `--no-verify`, which is a fleet-wide never. The science seat branched instead, which was the right call under a wrong message. ## Recommended staging, not yet done Splitting on jump size rather than doing one blanket `--rev latest`: 1. **The four live ones plus housecast.** `agent-proxy`, `factory-game-v3`, `agentic-os-xxx`, `voice-corpus`, and `housecast` sit at v0.49.0, one tag below, so a bump is nearly a no-op on validator content. `eco-mods` (v0.33.0), `eco-ops` (v0.35.0), and `factorio-mods` (v0.24.0) are longer jumps and want checking per repo. 2. **The latent ten**, as a separate pass, because `v0.18.0` to `v0.55.0` crosses 37 releases of new validators and will surface pre-existing violations that are real work rather than a pin edit. That is the same class of thing that had umbra's `main` red on `code-comments` before any of tonight's work touched it. A blanket bump would convert a silent lane override into a wall of unrelated hook failures across nine repos at once, which trades one invisible problem for a loud one nobody scheduled. ## Not established Whether any repo has actually been pushed with `--no-verify` because of this. The refusal names that as the deliberate override, and an agent under time pressure could reasonably have taken it. That is worth a reflog or audit sweep, and I have not run one. Also unswept: repos not resident on this host. I enumerated from on-disk checkouts under the projects root, so the count is a floor rather than the fleet total. ## Related `#1382` - a fresh clone installs no hooks at all, so the local gate usually does not bind. The two interact: that issue is why only 5 of 15 `merge-remote-main` repos have the hook, and this one is why 4 of those 5 are wrong when it does run.