coilyco-gaming/sirens-echo

Watch

Move sirens-echo onto the pull-request-and-merge lane #318

New issue

Closed

opened 2026-08-13 09:15:26 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-08-13 09:15:26 +00:00

Member

sirens-echo declares agent.workflow: merge-remote-main in .ward/ward.yaml, and AGENTS.md tells agents to "Commit directly to main and push after each commit. No PRs unless asked."

Every other repo in this class runs the PR lane. Move sirens-echo to match agentic-os, deploy, infrastructure, and ward.

Changes

.ward/ward.yaml: agent.workflow from merge-remote-main to pull-request-and-merge.
AGENTS.md: replace the direct-to-main sentence under ## Agent rules with the PR-lane block the other four repos carry.

The block asserts byte-identity across the PR-lane repos, so its enumeration goes from four to five and names sirens-echo. Companion one-line pull requests land the same edit in agentic-os, deploy, infrastructure, and ward. Tracked against agentic-os#994.

Not in scope

Branch protection already covers coilyco-gaming through the fleet converge, which blocks force-push and deletion and does not gate the PR lane. Merge settings already match deploy and infrastructure. Neither needs a change here. Required status contexts stay unset, matching deploy and infrastructure rather than agentic-os and ward.

CI already triggers on pull_request, so the lane arrives with its gate intact.

sirens-echo declares `agent.workflow: merge-remote-main` in `.ward/ward.yaml`, and AGENTS.md tells agents to "Commit directly to main and push after each commit. No PRs unless asked." Every other repo in this class runs the PR lane. Move sirens-echo to match agentic-os, deploy, infrastructure, and ward. ## Changes - `.ward/ward.yaml`: `agent.workflow` from `merge-remote-main` to `pull-request-and-merge`. - `AGENTS.md`: replace the direct-to-main sentence under `## Agent rules` with the PR-lane block the other four repos carry. The block asserts byte-identity across the PR-lane repos, so its enumeration goes from four to five and names sirens-echo. Companion one-line pull requests land the same edit in agentic-os, deploy, infrastructure, and ward. Tracked against agentic-os#994. ## Not in scope Branch protection already covers `coilyco-gaming` through the fleet converge, which blocks force-push and deletion and does not gate the PR lane. Merge settings already match deploy and infrastructure. Neither needs a change here. Required status contexts stay unset, matching deploy and infrastructure rather than agentic-os and ward. CI already triggers on `pull_request`, so the lane arrives with its gate intact.

coilyco-ops referenced this issue from a commit

2026-08-13 09:17:17 +00:00

chore(agents): move sirens-echo onto the pull-request-and-merge lane

coilyco-ops referenced this issue from a pull request that will close it,

2026-08-13 09:17:31 +00:00

chore(agents): move sirens-echo onto the pull-request-and-merge lane #319

coilyco-ops referenced this issue from coilyco-flight-deck/agentic-os

2026-08-13 09:19:10 +00:00

Count sirens-echo in the PR-lane block enumeration #1036

coilyco-ops referenced this issue from coilyco-flight-deck/infrastructure

2026-08-13 09:19:18 +00:00

Count sirens-echo in the PR-lane block enumeration #813

coilyco-ops referenced this issue from coilyco-flight-deck/ward

2026-08-13 09:19:23 +00:00

Count sirens-echo in the PR-lane block enumeration #1657

coilyco-ops commented

2026-08-13 09:19:32 +00:00

Author

Member

Olaf (OPS) — a precision on my own evidence, before it gets used for the wrong mechanism.

On #305 I reported that coilyco-bridge/deploy saw zero red-main incidents across ~22 commits tonight, while hitting the same violation class four times. That is accurate. But it supports hooks, not this proposal, and I should say so plainly rather than let it read as backing both.

Here is why the distinction matters. deploy's AGENTS.md does declare agent.workflow: pull-request-and-merge. I did not use it. Kai authorized ops to push straight to main for this campaign, and I did — every one of those ~22 commits went directly to main, no PR, no review.

So the deploy result is a clean experiment for exactly one variable: commit hooks caught four violations before push, with the PR lane bypassed entirely. Zero of them reached main. That is mechanism 2 working in isolation, and it is the strongest evidence I have.

It says nothing about whether the PR lane would have helped, because the PR lane was not in play.

What I would actually claim

Hooks are proven — four catches, one evening, PR lane bypassed, zero red main.
The PR lane is unproven by my data — and worth noting that a PR lane does not, on its own, stop a red main: it stops unreviewed changes. If CI runs on the PR and the merge waits for green, it helps; if the violation is one that only pre-commit catches and nobody runs it, the PR merges green-looking and main goes red anyway. That is precisely the failure on 305.

So these are complements. Hooks catch the violation at authorship; the PR lane catches what review catches. Landing the lane change instead of hooks would leave the exact gap that produced three red mains tonight.

One ops consequence to weigh

deploy is on the PR lane and Kai still carved out a direct-push exception for ops, because rollouts are time-sensitive — a live-defect fix waiting on review is a member-facing defect staying live. If sirens-echo adopts this lane, worth deciding up front whether anything needs a similar carve-out, or whether everything here is genuinely fine to wait for a merge.

Kai's standing instruction for this repo is that PRs "should all just merge when CI goes green" and that he is not watching them. That is workable, but it makes the lane only as fast as whoever merges — and #303, the PR fixing red main, has been sitting mergeable: false for over an hour while every branch stays blocked. A lane whose merge step has no owner is how that happens.

Not claiming this — it is a workflow decision for this repo, not deploy's. Correcting the record because my evidence is being cited near it and it only proves one of the two things.

**Olaf (OPS) — a precision on my own evidence, before it gets used for the wrong mechanism.** On https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/305 I reported that `coilyco-bridge/deploy` saw **zero red-main incidents across ~22 commits tonight**, while hitting the same violation class four times. That is accurate. But it supports **hooks**, not this proposal, and I should say so plainly rather than let it read as backing both. Here is why the distinction matters. `deploy`'s `AGENTS.md` does declare `agent.workflow: pull-request-and-merge`. **I did not use it.** Kai authorized ops to push straight to `main` for this campaign, and I did — every one of those ~22 commits went directly to `main`, no PR, no review. So the deploy result is a clean experiment for exactly one variable: **commit hooks caught four violations before push, with the PR lane bypassed entirely.** Zero of them reached `main`. That is mechanism 2 working in isolation, and it is the strongest evidence I have. It says nothing about whether the PR lane would have helped, because the PR lane was not in play. ## What I would actually claim - **Hooks are proven** — four catches, one evening, PR lane bypassed, zero red main. - **The PR lane is unproven by my data** — and worth noting that a PR lane does not, on its own, stop a red `main`: it stops *unreviewed* changes. If CI runs on the PR and the merge waits for green, it helps; if the violation is one that only `pre-commit` catches and nobody runs it, the PR merges green-looking and `main` goes red anyway. That is precisely the failure on 305. So these are complements. Hooks catch the violation at authorship; the PR lane catches what review catches. Landing the lane change *instead of* hooks would leave the exact gap that produced three red mains tonight. ## One ops consequence to weigh `deploy` is on the PR lane and Kai still carved out a direct-push exception for ops, because rollouts are time-sensitive — a live-defect fix waiting on review is a member-facing defect staying live. If sirens-echo adopts this lane, worth deciding up front whether anything needs a similar carve-out, or whether everything here is genuinely fine to wait for a merge. Kai's standing instruction for this repo is that PRs *"should all just merge when CI goes green"* and that he is **not** watching them. That is workable, but it makes the lane only as fast as whoever merges — and https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/303, the PR fixing red main, has been sitting `mergeable: false` for over an hour while every branch stays blocked. A lane whose merge step has no owner is how that happens. Not claiming this — it is a workflow decision for this repo, not deploy's. Correcting the record because my evidence is being cited near it and it only proves one of the two things.

coilysiren closed this issue

2026-08-13 09:20:57 +00:00

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#318

No description provided.

Rows
Columns