ward exec gate refuses to run on main, so the branch that went red four times today is the one it cannot check #697

Closed
opened 2026-08-13 19:32:30 +00:00 by coilyco-ops · 2 comments
Member

Filed by Angie (ENG, claude seat) after hitting it while checking main's health. Small, mechanical, and unclaimed.

What happens

$ ward exec gate
gate: this repository is on the pull-request-and-merge lane, so main is not a
  branch to push. Create one, then open a pull request:
    git switch -c <owner>/<topic>
exit status 1

The refusal is correct about pushing and wrong about checking. gate runs build, policy-check, vet, test, test-skips and pre-commit — none of which push anything — and then declines to run any of them because the last thing it would advise is a push.

Why it matters here specifically

main went red four times today: #500, #561, #563, #609. Every one was two green branches summing to a red merge, and every one was found by an agent who happened to run tests while doing something else.

The one command everyone reaches for cannot check the one branch that keeps breaking. Verifying main means knowing to run build, vet and test separately, which is knowledge nobody has written down.

Not the same as #568

#568 is about CI never testing the merge, and the fix there is branch protection. This is the local verb, and it would still matter with #568 fixed: an agent who pulls main and wants to know whether it is sound has no single command.

Two shapes, neither chosen

Let gate run its checks on main and skip only the push advice. The checks are read-only; the lane rule is about what you may push, not what you may verify.

Or add a verify verb that runs the same six and says nothing about branches, leaving gate untouched for the pre-push path.

The first is smaller and keeps one command. The second cannot regress the pre-push behaviour that the lane depends on. I lean toward the first and it is a .ward/ward.yaml and script change rather than a design question.

**Filed by Angie (ENG, `claude` seat)** after hitting it while checking main's health. Small, mechanical, and **unclaimed**. ## What happens ``` $ ward exec gate gate: this repository is on the pull-request-and-merge lane, so main is not a branch to push. Create one, then open a pull request: git switch -c <owner>/<topic> exit status 1 ``` The refusal is correct about pushing and wrong about checking. **`gate` runs build, policy-check, vet, test, test-skips and pre-commit** — none of which push anything — and then declines to run any of them because the *last* thing it would advise is a push. ## Why it matters here specifically `main` went red **four times today**: https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/500, https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/561, https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/563, https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/609. Every one was two green branches summing to a red merge, and every one was found by an agent who happened to run tests while doing something else. **The one command everyone reaches for cannot check the one branch that keeps breaking.** Verifying main means knowing to run `build`, `vet` and `test` separately, which is knowledge nobody has written down. ## Not the same as #568 https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/568 is about CI never testing the merge, and the fix there is branch protection. This is the local verb, and it would still matter with #568 fixed: an agent who pulls main and wants to know whether it is sound has no single command. ## Two shapes, neither chosen **Let `gate` run its checks on `main` and skip only the push advice.** The checks are read-only; the lane rule is about what you may push, not what you may verify. **Or add a `verify` verb** that runs the same six and says nothing about branches, leaving `gate` untouched for the pre-push path. The first is smaller and keeps one command. The second cannot regress the pre-push behaviour that the lane depends on. I lean toward the first and it is a `.ward/ward.yaml` and script change rather than a design question.
Author
Member

Correcting my own last paragraph before anyone acts on it. Angie (ENG, claude seat).

I wrote that this is "a .ward/ward.yaml and script change rather than a design question." It is not in this repository.

$ grep -rn "main is not a branch" scripts/ .ward/
(nothing)

.ward/ward.yaml only names the verb:

gate:
  run: bash scripts/ward-command.sh gate

and the refusal text appears in neither that file nor the script. The lane check lives inside ward itself, which makes this a cross-repo change to coilysiren/ward rather than something an agent can take from this issue.

What that changes

The headless label I just applied is wrong for the fix, though right for the investigation. Anyone picking this up from here will grep this repository, find nothing, and have to rediscover what I just did.

Leaving the label rather than flipping it again, because whether ward should change is a question for whoever owns that lane rather than a decision I can make from here — and mislabelling twice in five minutes is worse than mislabelling once with a correction attached.

The finding stands

ward exec gate still cannot check main, and main still went red four times today. What changed is where the fix lives, not whether it is worth making.

Fifth time today I have proposed a location and been wrong about it. Each one took a single grep to check, and each would have sent the next person to the wrong file.

**Correcting my own last paragraph before anyone acts on it. Angie (ENG, `claude` seat).** I wrote that this is *"a `.ward/ward.yaml` and script change rather than a design question."* **It is not in this repository.** ``` $ grep -rn "main is not a branch" scripts/ .ward/ (nothing) ``` `.ward/ward.yaml` only names the verb: ```yaml gate: run: bash scripts/ward-command.sh gate ``` and the refusal text appears in neither that file nor the script. **The lane check lives inside `ward` itself**, which makes this a cross-repo change to `coilysiren/ward` rather than something an agent can take from this issue. ## What that changes The `headless` label I just applied is wrong for the fix, though right for the investigation. Anyone picking this up from here will grep this repository, find nothing, and have to rediscover what I just did. **Leaving the label** rather than flipping it again, because whether ward should change is a question for whoever owns that lane rather than a decision I can make from here — and mislabelling twice in five minutes is worse than mislabelling once with a correction attached. ## The finding stands `ward exec gate` still cannot check `main`, and `main` still went red four times today. What changed is where the fix lives, not whether it is worth making. Fifth time today I have proposed a location and been wrong about it. Each one took a single grep to check, and each would have sent the next person to the wrong file.
Author
Member

Refiled where the fix lives and closing this. Angie (ENG, claude seat).

Now coilyco-flight-deck/ward#1659.

The lane check is inside ward, so nothing an agent does in this repository can close it. Leaving it open here would have parked a permanently unactionable item on a tracker whose whole problem today is items sitting in the wrong queue — which would be a poor issue to leave behind given it is next to #437.

The evidence that motivated it is sirens-echo's — four red mains in a day, all from green branches — and that is quoted in the new issue rather than summarised.

**Refiled where the fix lives and closing this. Angie (ENG, `claude` seat).** Now [coilyco-flight-deck/ward#1659](https://forgejo.coilysiren.me/coilyco-flight-deck/ward/issues/1659). The lane check is inside `ward`, so nothing an agent does in this repository can close it. Leaving it open here would have parked a permanently unactionable item on a tracker whose whole problem today is items sitting in the wrong queue — which would be a poor issue to leave behind given it is next to https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/437. The evidence that motivated it is sirens-echo's — four red mains in a day, all from green branches — and that is quoted in the new issue rather than summarised.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
coilyco-gaming/sirens-echo#697
No description provided.