Role boundary unrecorded: every open item in this repo is manual-only, so 3 bounced PRs carry findings no lane can ever act on #26

New Issue

pbwraith · 2026-08-26T23:54:29+02:00

pbwraith commented

2026-08-26 23:54:29 +02:00

The measurement

Run of the deployed candidate survey (~/.hermes/scripts/gitea-worker-lane.py,
survey_candidates()) against the live API, 2026-08-26:

LANE WOULD SEE 1 CANDIDATES, in pick order:
   bounced_pr gitea-worker-ops 41 | feat(#40): WSL exec watchdog ...

gopher64-netplay candidates: 0

One claimable item on the entire 23-repo board, and it is a PR I bounced 20 minutes
earlier. gopher64-netplay contributes zero, and it is the largest single block of open
work on the board: 6 open issues (#3 #4 #5 #6 #7 #25) and 3 open PRs (!9 !11 !18) — 9 items,
all 9 carrying manual-only.

Why zero, mechanically

manual-only is an unconditional worker exclusion — three separate sites, and the last
one is the surprising one:

gitea-worker-lane.py:148   if 'manual-only' in labels: continue   # inside the `bounced` PR branch
gitea-worker-lane.py:151   src = api(...linked issue...)          # ...and inherited from
gitea-worker-lane.py:152   if 'manual-only' in {...}: continue     #    the linked source issue
gitea-worker-lane.py:159   if 'manual-only' in labels: continue    # issues, even orphaned in-review

So bounced does not rescue a manual-only PR. That is deliberate — gitea-worker-ops#7
("Dispatcher: never claim manual-only issues or PR repairs") specifies exactly this, and
defines the label as:

manual-only means operator/reviewer execution only, not dependency blocking and not
needs-guidance.

The mechanism is working as designed. The question is whether it is pointed at the right
objects here.

The concrete cost

!9, !11 and !18 are all bounced with specific, implementable findings — the
2026-08-26 14:52 ordering note ("land !9 first, and one conflict hunk is a trap") names an
exact resolution. Those bounces are undeliverable by construction:

PR	last commit	bounce comments	can a lane claim it?
!9	2026-08-25 00:37 CDT	2026-08-26 13:27, 14:52	no — `manual-only`
!11	2026-08-25 00:48 CDT	2026-08-26 13:27, 14:52	no — `manual-only`
!18	2026-08-25 16:21 CDT	2026-08-26 13:27, 14:52	no — `manual-only`

No commits since 2026-08-25 on any of them, and none is possible from a lane. The bounce
text reads as a request for rework addressed to nobody.

What is actually missing: the reason

I checked every issue and PR in this repo (state=all, paginated) plus the full comment
threads of all six gated issues. No body and no comment anywhere in gopher64-netplay
records why manual-only is applied. #4, #7 and #25 have no stated gating reason of any
kind. (#3 and #6 do record a blocked prerequisite — "!18 must merge", "!11 must
merge" — and those are correct and separate from this.)

That matters because manual-only is the strongest gate in the system, and an unexplained
instance of it cannot be audited: a sweep cannot tell a deliberate role boundary from a
label that got copied across a cluster.

There is a plausible correct reason — netplay desync/resume verification needs two peers
and a real ROM, which no lane can do. But that argument covers the verification step,
not the Rust rework: resolving a merge conflict in src/netplay.rs, or rebasing issue-4
onto current main, is ordinary automatable work, and the repo already has a headless
build gate that runs cargo test --lib without a second peer.

The decision I need from you

Pick one and record it here; I will not change these labels unilaterally, because this is a
role-ownership decision, not a defect.

Option A — gopher64 rework is yours, by hand. manual-only stays on all 9 items. Then
the three PRs should stop being bounced with lane-shaped instructions; I will re-word those
comments as owner runbooks and stop re-bouncing them each sweep. Say so and I will do that.

Option B — only the live verification is manual. manual-only moves off the three code
PRs (and off #4/#7/#25 if their remaining work is code), leaving it on whatever step needs
two peers and a ROM. The three PRs then become claimable at lane priority 0 and the existing
findings become actionable immediately. blocked on #3/#6 is unaffected either way.

Option C — something else, e.g. the whole repo is parked for now. Also fine; just record
it, so the next sweep does not re-derive this.

Acceptance

A comment on this issue naming A, B or C.
If B: manual-only removed from the specific items you name, with the reason for the
remaining instances written down in the issue body, not only here.
Either way, the rationale ends up recorded in-repo so this is auditable next sweep.

Explicitly out of scope

I am not stripping manual-only from anything as part of filing this.
Not re-reviewing the technical content of !9/!11/!18 — their existing findings stand and
are unchanged by this issue.
Not proposing any change to gitea-worker-lane.py. The exclusion logic matches
gitea-worker-ops#7 and is correct; only the labelling of these nine items is in question.
The blocked labels on #3 and #6 are correct (their named prerequisite PRs are still
open) and I am not touching them.

## The measurement Run of the **deployed** candidate survey (`~/.hermes/scripts/gitea-worker-lane.py`, `survey_candidates()`) against the live API, 2026-08-26: ``` LANE WOULD SEE 1 CANDIDATES, in pick order: bounced_pr gitea-worker-ops 41 | feat(#40): WSL exec watchdog ... gopher64-netplay candidates: 0 ``` One claimable item on the entire 23-repo board, and it is a PR I bounced 20 minutes earlier. **gopher64-netplay contributes zero**, and it is the largest single block of open work on the board: 6 open issues (#3 #4 #5 #6 #7 #25) and 3 open PRs (!9 !11 !18) — 9 items, **all 9 carrying `manual-only`**. ## Why zero, mechanically `manual-only` is an *unconditional* worker exclusion — three separate sites, and the last one is the surprising one: ```python gitea-worker-lane.py:148 if 'manual-only' in labels: continue # inside the `bounced` PR branch gitea-worker-lane.py:151 src = api(...linked issue...) # ...and inherited from gitea-worker-lane.py:152 if 'manual-only' in {...}: continue # the linked source issue gitea-worker-lane.py:159 if 'manual-only' in labels: continue # issues, even orphaned in-review ``` So `bounced` does **not** rescue a `manual-only` PR. That is deliberate — gitea-worker-ops#7 ("Dispatcher: never claim manual-only issues or PR repairs") specifies exactly this, and defines the label as: > `manual-only` means operator/reviewer execution only, not dependency blocking and not > `needs-guidance`. The mechanism is working as designed. The question is whether it is pointed at the right objects here. ## The concrete cost `!9`, `!11` and `!18` are all `bounced` **with specific, implementable findings** — the 2026-08-26 14:52 ordering note ("land `!9` first, and one conflict hunk is a trap") names an exact resolution. Those bounces are undeliverable by construction: | PR | last commit | bounce comments | can a lane claim it? | |----|-------------|-----------------|----------------------| | !9 | 2026-08-25 00:37 CDT | 2026-08-26 13:27, 14:52 | no — `manual-only` | | !11 | 2026-08-25 00:48 CDT | 2026-08-26 13:27, 14:52 | no — `manual-only` | | !18 | 2026-08-25 16:21 CDT | 2026-08-26 13:27, 14:52 | no — `manual-only` | No commits since 2026-08-25 on any of them, and none is possible from a lane. The bounce text reads as a request for rework addressed to nobody. ## What is actually missing: the reason I checked every issue and PR in this repo (`state=all`, paginated) plus the full comment threads of all six gated issues. **No body and no comment anywhere in gopher64-netplay records why `manual-only` is applied.** #4, #7 and #25 have no stated gating reason of any kind. (#3 and #6 do record a `blocked` prerequisite — "`!18` must merge", "`!11` must merge" — and those are correct and separate from this.) That matters because `manual-only` is the strongest gate in the system, and an unexplained instance of it cannot be audited: a sweep cannot tell a deliberate role boundary from a label that got copied across a cluster. There is a plausible correct reason — netplay desync/resume verification needs **two peers and a real ROM**, which no lane can do. But that argument covers the *verification* step, not the Rust rework: resolving a merge conflict in `src/netplay.rs`, or rebasing `issue-4` onto current `main`, is ordinary automatable work, and the repo already has a headless build gate that runs `cargo test --lib` without a second peer. ## The decision I need from you Pick one and record it here; I will not change these labels unilaterally, because this is a role-ownership decision, not a defect. **Option A — gopher64 rework is yours, by hand.** `manual-only` stays on all 9 items. Then the three PRs should stop being bounced with lane-shaped instructions; I will re-word those comments as owner runbooks and stop re-bouncing them each sweep. Say so and I will do that. **Option B — only the live verification is manual.** `manual-only` moves off the three code PRs (and off #4/#7/#25 if their remaining work is code), leaving it on whatever step needs two peers and a ROM. The three PRs then become claimable at lane priority 0 and the existing findings become actionable immediately. `blocked` on #3/#6 is unaffected either way. **Option C — something else**, e.g. the whole repo is parked for now. Also fine; just record it, so the next sweep does not re-derive this. ## Acceptance - A comment on this issue naming A, B or C. - If B: `manual-only` removed from the specific items you name, with the reason for the remaining instances written down **in the issue body**, not only here. - Either way, the rationale ends up recorded in-repo so this is auditable next sweep. ## Explicitly out of scope - I am **not** stripping `manual-only` from anything as part of filing this. - Not re-reviewing the technical content of !9/!11/!18 — their existing findings stand and are unchanged by this issue. - Not proposing any change to `gitea-worker-lane.py`. The exclusion logic matches gitea-worker-ops#7 and is correct; only the labelling of *these nine items* is in question. - The `blocked` labels on #3 and #6 are correct (their named prerequisite PRs are still open) and I am not touching them.

pbwraith added the

p1

needs-guidance

labels 2026-08-26 23:54:29 +02:00

pbwraith closed this issue

2026-08-27 01:36:59 +02:00

This repo is archived. You cannot comment on issues.