coilyco-flight-deck/ward

Archived

Watch

chore(triage): apply the 2026-07-06 backlog re-triage relabel-downs (label-only, no code) #621

Closed

opened 2026-07-06 19:34:49 +00:00 by coilysiren · 3 comments

coilysiren commented

2026-07-06 19:34:49 +00:00

Owner

Label-only maintenance (NO code)

This is a forge-label-only task from the 2026-07-06 backlog re-triage. Write zero code. Push nothing. Touch no files. Implement nothing. Open no branch. Your entire job is to run the label mutations below with the in-container ward ops forgejo issue-label surface - your container holds a write-capable FORGEJO_TOKEN and that surface (see ward#619) - then close this issue. There is no clone to edit and no main to land.

1. Relabel `headless` -> `consult` on nine issues

For each of #112, #124, #145, #367, #407, #453, #477, #556, #602 in coilyco-flight-deck/ward, run:

ward ops forgejo issue-label remove coilyco-flight-deck ward <N> --labels headless
ward ops forgejo issue-label add    coilyco-flight-deck ward <N> --labels consult

then comment on it: Relabeled headless->consult in the 2026-07-06 backlog re-triage (stale headless label over a standing human-gate).

Leave each issue's existing P-tier label (P1-P4) untouched. This is relabel-down only - never add headless to anything.

If issue-label remove --labels headless rejects the flag form, use the label identifier the API wants (name or id); the intent is: drop headless, add consult, keep the tier.

2. Handle #161 (verify first)

ward#239 ("freeze the raw Forgejo-token surface") merged to main on 2026-07-06, after this re-triage's code snapshot. #161 ("point the container git-over-HTTPS push token at the coilyco-ops bot") may now be partly or wholly resolved by it. Read #161 and #239's landed change:

If #161's premise is now void (the token identity work landed), close #161 with a one-line note citing #239.
Otherwise relabel #161 headless -> interactive (it needs a human org-admin grant to make the bot a collaborator on the targets) and comment why.

Done-condition

The nine relabels + comments applied, #161 handled, and this issue closed. No branch, no commit, no push - if your harness expects a push to land, that expectation does not apply here; closing this issue is the completion signal.

## Label-only maintenance (NO code) This is a forge-label-only task from the 2026-07-06 backlog re-triage. **Write zero code. Push nothing. Touch no files. Implement nothing. Open no branch.** Your entire job is to run the label mutations below with the in-container `ward ops forgejo issue-label` surface - your container holds a write-capable `FORGEJO_TOKEN` and that surface (see ward#619) - then close this issue. There is no clone to edit and no `main` to land. ### 1. Relabel `headless` -> `consult` on nine issues For each of **#112, #124, #145, #367, #407, #453, #477, #556, #602** in `coilyco-flight-deck/ward`, run: ward ops forgejo issue-label remove coilyco-flight-deck ward <N> --labels headless ward ops forgejo issue-label add coilyco-flight-deck ward <N> --labels consult then comment on it: `Relabeled headless->consult in the 2026-07-06 backlog re-triage (stale headless label over a standing human-gate).` Leave each issue's existing P-tier label (P1-P4) untouched. This is relabel-**down** only - never add `headless` to anything. If `issue-label remove --labels headless` rejects the flag form, use the label identifier the API wants (name or id); the intent is: drop `headless`, add `consult`, keep the tier. ### 2. Handle #161 (verify first) ward#239 ("freeze the raw Forgejo-token surface") merged to `main` on 2026-07-06, after this re-triage's code snapshot. #161 ("point the container git-over-HTTPS push token at the coilyco-ops bot") may now be partly or wholly resolved by it. Read #161 and #239's landed change: - If #161's premise is now void (the token identity work landed), **close #161** with a one-line note citing #239. - Otherwise **relabel #161 `headless` -> `interactive`** (it needs a human org-admin grant to make the bot a collaborator on the targets) and comment why. ### Done-condition The nine relabels + comments applied, #161 handled, and **this issue closed**. No branch, no commit, no push - if your harness expects a push to land, that expectation does not apply here; closing this issue is the completion signal.

coilyco-ops commented

2026-07-06 19:43:21 +00:00

Owner

🔎 ward agent advisor

ward agent advisor --driver claude ran a one-shot standard research pass on this question:

Execute the label-only maintenance task described in this issue body - do NOT merely recommend it. Using your in-container write-capable FORGEJO_TOKEN and the 'ward ops forgejo issue-label' surface, run the nine headless->consult relabels (#112 #124 #145 #367 #407 #453 #477 #556 #602) with their comments, verify-and-handle #161 as described, then close this issue #621. Write no code, push nothing.

Outcome: task could NOT be completed from this surface — the forge broker blocks all label mutations

I attempted to execute the label-only maintenance directly (I do hold a write-capable FORGEJO_TOKEN and the ward ops forgejo issue-label surface exists). But this container's Forgejo writes route through a broker that serves only the issue write tier — create / edit / comment / close / reopen issue. Every label operation was refused as out of tier:

refused - the broker serves the write tier only (create / edit / comment / close / reopen issue); issue-label remove is out of tier

So issue-label add, issue-label remove, and issue-comment delete are all unavailable here. The issue body's premise (that this container can drive ward ops forgejo issue-label, per ward#619) does not hold on this broker-gated read-only surface. I did not route around the broker with a raw curl $FORGEJO_TOKEN — the tier gate is a deliberate policy control (the raw-token surface was frozen in #239), and bypassing it would defeat exactly the boundary that refusal enforces.

What actually happened (full, faithful record)

The nine relabels did NOT apply. #112 #124 #145 #367 #407 #453 #477 #556 #602 all still carry headless (tiers untouched). Verified after the fact.
I mistakenly posted the "Relabeled headless->consult…" comment on all nine before discovering the label calls were refused (comment is in-tier, so it posted while the relabel it described was rejected). Those nine comments were therefore false.
I could not delete them (issue-comment delete is also out of tier), so I posted a correction comment on each of the nine stating plainly that the relabel did not apply, the issue still carries headless, and why (broker tier). Comment ids: corrections 23243–23251.
#621 was left OPEN — its done-condition (relabels applied) was not met, so closing it would have falsely signalled completion.

#161 — verified, and the verdict is definitive

#161's premise is NOT void; #239 did not resolve it. #239 (commit e516e07, "audit + freeze the raw Forgejo-token surface") touched only cmd/ward/forgejo_token_guard_test.go + docs (FEATURES.md, README.md, broker.md, forgejo-token-audit.md). It did not touch cmd/ward/container.go, where forgejoTokenSSMPath still reads "/forgejo/api-token" (the operator's personal PAT, user coilysiren) — not the coilyco-ops bot. #239's own commit message confirms it: "The full token-drop cutover (#608 Unit D, #161) stays blocked on a cli-guard read op."

So the correct disposition (per the issue's own branch logic) is relabel headless -> interactive — #161 needs a human org-admin grant to make coilyco-ops a collaborator with write on the target repos (its load-bearing prereq). I posted that disposition + verification as a comment on #161 (23252) and left #161 open. The headless->interactive relabel itself is also blocked by the same broker tier, so it is deferred alongside the nine.

What's needed to actually finish this task

The blocker is a real capability gap, single-repo (all coilyco-flight-deck/ward), so I did not fan out child issues. One of these unblocks it:

Extend the broker's write tier to include issue-label add/remove (and arguably issue-comment delete), so a headless/consult container can drive relabel-only re-triage tasks at all. This is itself a ward change worth an issue if the fleet intends label-ops to run through this surface. This is the load-bearing fix — without it, no in-container agent can execute a relabel task.
Or re-dispatch this task to a role/surface that already holds the issue-label tier (an operator-run ward ops forgejo issue-label … from a non-broker context, or a direct maintainer action).

Then the concrete remaining work (unchanged from the issue): remove headless(id 323) + add consult(id 325) on #112 #124 #145 #367 #407 #453 #477 #556 #602 keeping each P-tier; and remove headless(323) + add interactive(id 324) on #161 keeping P1. Labels confirmed to exist as org-level labels: headless=323, consult=325, interactive=324.

Net: zero labels changed, nine issues + #161 carry accurate correction/disposition comments, #621 and #161 remain open, and the true blocker (broker write tier excludes label mutations) is documented for a re-dispatch.

Researched and posted automatically by ward agent advisor --driver claude (ward#179). This is one-shot research, not a carried change - verify before acting on it.

— Claude (she/her), via ward agent

### 🔎 ward agent advisor `ward agent advisor --driver claude` ran a one-shot **standard** research pass on this question: > Execute the label-only maintenance task described in this issue body - do NOT merely recommend it. Using your in-container write-capable FORGEJO_TOKEN and the 'ward ops forgejo issue-label' surface, run the nine headless->consult relabels (#112 #124 #145 #367 #407 #453 #477 #556 #602) with their comments, verify-and-handle #161 as described, then close this issue #621. Write no code, push nothing. --- ## Outcome: task could NOT be completed from this surface — the forge broker blocks all label mutations I attempted to execute the label-only maintenance directly (I do hold a write-capable `FORGEJO_TOKEN` and the `ward ops forgejo issue-label` surface exists). But this container's Forgejo **writes route through a broker that serves only the issue write tier** — `create / edit / comment / close / reopen issue`. Every label operation was **refused as out of tier**: ``` refused - the broker serves the write tier only (create / edit / comment / close / reopen issue); issue-label remove is out of tier ``` So `issue-label add`, `issue-label remove`, **and** `issue-comment delete` are all unavailable here. The issue body's premise (that this container can drive `ward ops forgejo issue-label`, per ward#619) does **not hold on this broker-gated read-only surface**. I did **not** route around the broker with a raw `curl $FORGEJO_TOKEN` — the tier gate is a deliberate policy control (the raw-token surface was frozen in #239), and bypassing it would defeat exactly the boundary that refusal enforces. ### What actually happened (full, faithful record) 1. **The nine relabels did NOT apply.** `#112 #124 #145 #367 #407 #453 #477 #556 #602` all **still carry `headless`** (tiers untouched). Verified after the fact. 2. **I mistakenly posted the "Relabeled headless->consult…" comment on all nine before discovering the label calls were refused** (comment *is* in-tier, so it posted while the relabel it described was rejected). Those nine comments were therefore **false**. 3. **I could not delete them** (`issue-comment delete` is also out of tier), so I posted a **correction comment on each of the nine** stating plainly that the relabel did not apply, the issue still carries `headless`, and why (broker tier). Comment ids: corrections `23243–23251`. 4. **#621 was left OPEN** — its done-condition (relabels applied) was not met, so closing it would have falsely signalled completion. ### #161 — verified, and the verdict is definitive **#161's premise is NOT void; #239 did not resolve it.** #239 (commit `e516e07`, *"audit + freeze the raw Forgejo-token surface"*) touched only `cmd/ward/forgejo_token_guard_test.go` + docs (`FEATURES.md`, `README.md`, `broker.md`, `forgejo-token-audit.md`). It did **not** touch `cmd/ward/container.go`, where `forgejoTokenSSMPath` still reads `"/forgejo/api-token"` (the operator's personal PAT, user `coilysiren`) — **not** the `coilyco-ops` bot. #239's own commit message confirms it: *"The full token-drop cutover (#608 Unit D, #161) stays blocked on a cli-guard read op."* So the correct disposition (per the issue's own branch logic) is **relabel `headless` -> `interactive`** — #161 needs a human org-admin grant to make `coilyco-ops` a collaborator with write on the target repos (its load-bearing prereq). I posted that disposition + verification as a comment on #161 (`23252`) and left **#161 open**. The `headless`->`interactive` relabel itself is **also blocked** by the same broker tier, so it is deferred alongside the nine. ### What's needed to actually finish this task The blocker is a real capability gap, single-repo (all `coilyco-flight-deck/ward`), so I did not fan out child issues. One of these unblocks it: - **Extend the broker's write tier to include `issue-label add`/`remove`** (and arguably `issue-comment delete`), so a headless/consult container can drive relabel-only re-triage tasks at all. This is itself a ward change worth an issue if the fleet intends label-ops to run through this surface. **This is the load-bearing fix** — without it, no in-container agent can execute a relabel task. - **Or** re-dispatch this task to a role/surface that already holds the issue-label tier (an operator-run `ward ops forgejo issue-label …` from a non-broker context, or a direct maintainer action). Then the concrete remaining work (unchanged from the issue): remove `headless`(id 323) + add `consult`(id 325) on `#112 #124 #145 #367 #407 #453 #477 #556 #602` keeping each P-tier; and remove `headless`(323) + add `interactive`(id 324) on `#161` keeping `P1`. Labels confirmed to exist as **org-level** labels: `headless`=323, `consult`=325, `interactive`=324. **Net:** zero labels changed, nine issues + #161 carry accurate correction/disposition comments, #621 and #161 remain open, and the true blocker (broker write tier excludes label mutations) is documented for a re-dispatch. --- Researched and posted automatically by `ward agent advisor --driver claude` (ward#179). This is one-shot research, not a carried change - verify before acting on it.   — Claude (she/her), via `ward agent`

coilysiren commented

2026-07-06 19:53:25 +00:00

Author

Owner

Status: relabel BLOCKED - broker write tier excludes label ops (#615/#618)

A ref-mode advisor dispatched at this issue could NOT apply the relabels: its Forgejo writes route through the same broker that gates the director surface, and every issue-label add/remove was refused out of tier. So no role dispatched from the read-only director surface can relabel - #619 Piece 1's "engineers/advisors relabel with their own token" does not hold on this broker-mediated path. The load-bearing unblock is #618 (route issue-label through the broker), or a maintainer running the batch from a non-broker context (host ward + token).

Confirmed by that run: label ids are org-level headless=323, consult=325, interactive=324. And #161's premise is NOT void - #239 froze the raw-token surface but did not touch container.go's forgejoTokenSSMPath (still the personal PAT, not the coilyco-ops bot), so #161 stays open and its disposition is headless->interactive (needs a human org-admin collaborator grant).

Batch to run from a non-broker context (label ids)

for n in 112 124 145 367 407 453 477 556 602; do
  ward ops forgejo issue-label remove coilyco-flight-deck ward $n --labels 323
  ward ops forgejo issue-label add    coilyco-flight-deck ward $n --labels 325
done
ward ops forgejo issue-label remove coilyco-flight-deck ward 161 --labels 323
ward ops forgejo issue-label add    coilyco-flight-deck ward 161 --labels 324

(Nine headless->consult keeping each P-tier, plus #161 headless->interactive.) Note: the advisor left a premature 'relabeled' comment + a correction on each of the nine; cosmetic noise, safe to ignore or clean. Leaving #621 open until the relabels actually land.

## Status: relabel BLOCKED - broker write tier excludes label ops (#615/#618) A ref-mode advisor dispatched at this issue could NOT apply the relabels: its Forgejo writes route through the same broker that gates the director surface, and every `issue-label add/remove` was refused `out of tier`. So no role dispatched **from the read-only director surface** can relabel - #619 Piece 1's "engineers/advisors relabel with their own token" does not hold on this broker-mediated path. The load-bearing unblock is **#618** (route issue-label through the broker), or a maintainer running the batch from a **non-broker** context (host ward + token). Confirmed by that run: label ids are org-level `headless`=323, `consult`=325, `interactive`=324. And **#161's premise is NOT void** - #239 froze the raw-token surface but did not touch `container.go`'s `forgejoTokenSSMPath` (still the personal PAT, not the coilyco-ops bot), so #161 stays open and its disposition is `headless`->`interactive` (needs a human org-admin collaborator grant). ### Batch to run from a non-broker context (label ids) ``` for n in 112 124 145 367 407 453 477 556 602; do ward ops forgejo issue-label remove coilyco-flight-deck ward $n --labels 323 ward ops forgejo issue-label add coilyco-flight-deck ward $n --labels 325 done ward ops forgejo issue-label remove coilyco-flight-deck ward 161 --labels 323 ward ops forgejo issue-label add coilyco-flight-deck ward 161 --labels 324 ``` (Nine `headless`->`consult` keeping each P-tier, plus #161 `headless`->`interactive`.) Note: the advisor left a premature 'relabeled' comment + a correction on each of the nine; cosmetic noise, safe to ignore or clean. Leaving #621 open until the relabels actually land.

coilysiren referenced this issue

2026-07-06 19:53:25 +00:00

design: default-headless intake + tri-role relabel-down discipline #619

coilysiren commented

2026-07-07 03:03:07 +00:00

Author

Owner

Unblock now tracked by #625. The relabel-downs here are still stranded because a director/advisor surface cannot apply labels in-tier (the #615/#618 story), but the root fix is #625 - ward catching up to cli-guard v0.74.0's already-shipped OpLabelIssue broker op. Once #625 lands, a director drain applies these relabel-downs in-tier (no --force, no mis-dispatched advisor). Do NOT re-dispatch this as an advisor - an advisor is broker-gated and will fail the same way the 2026-07-06 run did.