coilyco-flight-deck/ward

Fork 0

fix(broker): route ops forgejo issue-label DIRECT (read/direct tier), not through the broker write tier #625

New issue

Closed

opened 2026-07-07 03:02:09 +00:00 by coilysiren · 3 comments

coilysiren commented

2026-07-07 03:02:09 +00:00

Owner

Corrected scope (supersedes the broker-completion plan below the fold)

Labeling is a trivial mutation and must not route through the credential broker (Kai: "issue labeling should not go through the broker at all - it can, but it is trivial - it belongs in the KDL-generated read tier"). The earlier broker-completion scope (executor LabelIssue + mapForgejoWriteOp arm + cli-guard pin bump) is the overkill #618 was closed for. Drop it.

Do this instead (one focused change)

Route ward ops forgejo issue-label add|set|remove direct, the same path the read verbs take, so a director/advisor surface labels with the session token and never touches the broker.

cmd/ward/broker_client.go - in brokerForgejoAction, before the write-op mapping, return direct(ctx, cmd) when resource == "issue-label" (all of add/set/remove/list). Today only forgejoReadVerbs (get/list/search/view, keyed on the verb tail) routes direct - issue-label needs a resource-level direct arm because its mutating verbs share generic names (add/set/remove).
No cli-guard change. No executor change. No new broker op.

Acceptance

From a director surface (WARD_BROKER_SOCK set), ward ops forgejo issue-label add <owner> <repo> <index> --labels headless succeeds direct (no broker, no --force), label lands.
remove / set behave the same. issue-label list still routes direct as before.
ward exec test / ward exec vet green.

Note

This is the interim/trivial form. The proper home is the KDL-generated read/write/admin tier (ward#614), where ward stops hardcoding forgejoReadVerbs and derives routing from the spec - and the broader label-semantics ownership inversion lands in the taxonomy redesign (filed separately). This issue is just the small routing fix.

In-flight run warning

An engineer was dispatched against the OLD (broker-completion) scope before this correction and could not be cleanly stopped from the read-only director surface. If that run lands a broker route, it is superseded by this corrected scope - stop it host-side or revert its change.

## Corrected scope (supersedes the broker-completion plan below the fold) Labeling is a **trivial mutation and must not route through the credential broker** (Kai: "issue labeling should not go through the broker at all - it can, but it is trivial - it belongs in the KDL-generated read tier"). The earlier broker-completion scope (executor `LabelIssue` + `mapForgejoWriteOp` arm + cli-guard pin bump) is the overkill #618 was closed for. Drop it. ### Do this instead (one focused change) Route `ward ops forgejo issue-label add|set|remove` **direct**, the same path the read verbs take, so a director/advisor surface labels with the session token and never touches the broker. - **`cmd/ward/broker_client.go`** - in `brokerForgejoAction`, before the write-op mapping, return `direct(ctx, cmd)` when `resource == "issue-label"` (all of add/set/remove/list). Today only `forgejoReadVerbs` (get/list/search/view, keyed on the verb tail) routes direct - issue-label needs a resource-level direct arm because its mutating verbs share generic names (`add`/`set`/`remove`). - No cli-guard change. No executor change. No new broker op. ### Acceptance - From a director surface (`WARD_BROKER_SOCK` set), `ward ops forgejo issue-label add <owner> <repo> <index> --labels headless` succeeds direct (no broker, no `--force`), label lands. - `remove` / `set` behave the same. `issue-label list` still routes direct as before. - `ward exec test` / `ward exec vet` green. ### Note This is the interim/trivial form. The proper home is the KDL-generated read/write/admin tier (ward#614), where ward stops hardcoding `forgejoReadVerbs` and derives routing from the spec - and the broader label-semantics ownership inversion lands in the taxonomy redesign (filed separately). This issue is just the small routing fix. ### In-flight run warning An engineer was dispatched against the OLD (broker-completion) scope before this correction and could not be cleanly stopped from the read-only director surface. If that run lands a broker route, it is superseded by this corrected scope - stop it host-side or revert its change.

coilyco-ops commented

2026-07-07 03:02:35 +00:00

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-625 on host KAI-DESKTOP-TOWER is carrying this issue (reserved 2026-07-07T03:02:32Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh — that is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-flight-deck/ward#625 · branch issue-625 · driver claude · workflow direct-main
Run: engineer-claude-ward-625 · ward v0.417.0 · dispatched 2026-07-07T03:02:32Z
Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

Issue body as seeded:

## Root cause (a director surface cannot label - blocks the whole triage-apply pipeline)

A `warded director` read-only surface proxies every forgejo write through the root credential broker, so it never holds the bot token. The broker write tier serves file / edit / comment / close / reopen. It does **not** route label ops, so `ward ops forgejo issue-label add|set|remove` is refused ("out of tier") from a director/advisor surface. That strands the already-decided triage labels in infra#471 (tier axis), infra#472 (mode axis), and ward#621 (relabel-down) - roughly 128 open issues across all three orgs that carry a decision but cannot have it applied from the surface that made it.

## Why this is now a small catch-up, not new broker complexity (re: closed #618 "overkill")

The hard part already shipped. **cli-guard v0.74.0** (commit b8e3e63, cli-guard#193) landed the broker op end to end: `OpLabelIssue`, the `add` / `set` / `remove` modes, the fail-closed `labelInvariants` authz, `client.LabelIssue`, the `Executor.LabelIssue` interface method, and the server dispatch arm. ward just never caught up - it still pins **cli-guard v0.73.0**, one release behind the op. So completing this is a dependency bump plus two ward functions, with zero new protocol or security surface. That is the reframe from #618: the broker op is not overkill because it is not new. It is done and sitting unused.

## Scope (ward-only)

1. **`go.mod`** - bump `forgejo.coilysiren.me/coilyco-flight-deck/cli-guard` from `v0.73.0` to `v0.75.0` (latest, carries `OpLabelIssue`), then `ward exec tidy`.
2. **`cmd/ward/broker_exec.go`** - add `wardKdlWriteExecutor.LabelIssue(ctx, target, mode, labels)` shelling `ward-kdl-write ops forgejo issue-label <mode> <owner> <repo> <index> --labels <a,b,...>`, matching the existing FileIssue / EditIssue / CommentIssue pattern. Add `broker.OpLabelIssue: true` to the write-op allowlist map (currently lines 162-163, only edit + comment).
3. **`cmd/ward/broker_client.go`**

… (truncated to 2000 chars; full body is on this issue)

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.417.0).

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-625` on host `KAI-DESKTOP-TOWER` is carrying this issue (reserved 2026-07-07T03:02:32Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh** — that is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/ward#625` · branch `issue-625` · driver `claude` · workflow `direct-main` - **Run:** `engineer-claude-ward-625` · ward `v0.417.0` · dispatched `2026-07-07T03:02:32Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). **Issue body as seeded:** ``` ## Root cause (a director surface cannot label - blocks the whole triage-apply pipeline) A `warded director` read-only surface proxies every forgejo write through the root credential broker, so it never holds the bot token. The broker write tier serves file / edit / comment / close / reopen. It does **not** route label ops, so `ward ops forgejo issue-label add|set|remove` is refused ("out of tier") from a director/advisor surface. That strands the already-decided triage labels in infra#471 (tier axis), infra#472 (mode axis), and ward#621 (relabel-down) - roughly 128 open issues across all three orgs that carry a decision but cannot have it applied from the surface that made it. ## Why this is now a small catch-up, not new broker complexity (re: closed #618 "overkill") The hard part already shipped. **cli-guard v0.74.0** (commit b8e3e63, cli-guard#193) landed the broker op end to end: `OpLabelIssue`, the `add` / `set` / `remove` modes, the fail-closed `labelInvariants` authz, `client.LabelIssue`, the `Executor.LabelIssue` interface method, and the server dispatch arm. ward just never caught up - it still pins **cli-guard v0.73.0**, one release behind the op. So completing this is a dependency bump plus two ward functions, with zero new protocol or security surface. That is the reframe from #618: the broker op is not overkill because it is not new. It is done and sitting unused. ## Scope (ward-only) 1. **`go.mod`** - bump `forgejo.coilysiren.me/coilyco-flight-deck/cli-guard` from `v0.73.0` to `v0.75.0` (latest, carries `OpLabelIssue`), then `ward exec tidy`. 2. **`cmd/ward/broker_exec.go`** - add `wardKdlWriteExecutor.LabelIssue(ctx, target, mode, labels)` shelling `ward-kdl-write ops forgejo issue-label <mode> <owner> <repo> <index> --labels <a,b,...>`, matching the existing FileIssue / EditIssue / CommentIssue pattern. Add `broker.OpLabelIssue: true` to the write-op allowlist map (currently lines 162-163, only edit + comment). 3. **`cmd/ward/broker_client.go`** ``` … (truncated to 2000 chars; full body is on this issue) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.417.0). </details>  — Claude (she/her), via `ward agent`

coilysiren referenced this issue

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

feat(ops): route issue-label add/set/remove through the broker (consumes cli-guard#193) #618

coilysiren referenced this issue

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

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

coilysiren commented

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

Author

Owner

SCOPE CORRECTION (Kai): labeling should NOT go through the broker. It is a trivial mutation and belongs in the KDL-generated read/direct tier that bypasses the broker, not in the broker write tier. Disregard the broker-completion scope in the body above (executor.LabelIssue + mapForgejoWriteOp + cli-guard pin bump) - that is the overkill #618 was closed for. Correct fix: route ops forgejo issue-label add/set/remove DIRECT (like the read verbs in broker_client.go forgejoReadVerbs), using the session token, so a director surface labels without the broker. Trivial form: a resource == "issue-label" direct arm in brokerForgejoAction. Proper form: fold into #614 (KDL per-verb read/write/admin trifecta) so the tier is spec-driven, not the hardcoded forgejoReadVerbs map. Holding final disposition of this issue pending Kai's call on where the fix lands.

SCOPE CORRECTION (Kai): labeling should NOT go through the broker. It is a trivial mutation and belongs in the KDL-generated read/direct tier that bypasses the broker, not in the broker write tier. Disregard the broker-completion scope in the body above (executor.LabelIssue + mapForgejoWriteOp + cli-guard pin bump) - that is the overkill #618 was closed for. Correct fix: route `ops forgejo issue-label add/set/remove` DIRECT (like the read verbs in broker_client.go forgejoReadVerbs), using the session token, so a director surface labels without the broker. Trivial form: a `resource == "issue-label"` direct arm in brokerForgejoAction. Proper form: fold into #614 (KDL per-verb read/write/admin trifecta) so the tier is spec-driven, not the hardcoded forgejoReadVerbs map. Holding final disposition of this issue pending Kai's call on where the fix lands.

coilysiren referenced this issue from a commit

2026-07-07 03:13:19 +00:00

feat(broker): route issue-label ops through the write tier (closes #625)

coilysiren closed this issue

2026-07-07 03:13:19 +00:00

coilysiren commented

2026-07-07 03:13:48 +00:00

Author

Owner

WARD-OUTCOME: done - broker now serves issue-label add/set/remove, so a director surface can apply its own triage labels through the write tier.

This one lived up to its "small catch-up, not new complexity" framing. The hard part genuinely was already in cli-guard v0.74.0 - OpLabelIssue, the fail-closed labelInvariants, the client/executor/server dispatch - so ward's side was a dependency bump plus mirroring the existing FileIssue/EditIssue/CommentIssue pattern one more time. The executor and client both had a clean groove to slot into, and the label argv matched the pre-existing addIssueLabels shell-out exactly.

Two small things fought back. First, adding the switch arm tipped mapForgejoWriteOp over the cyclop complexity-12 ceiling, so I split it into per-resource helpers - arguably cleaner than the flat switch anyway. Second, the code-comments hook caps contiguous comment blocks at 2 lines, which trimmed a few of my explanatory comments. Both were mechanical.

Confidence is high: the argv shaping, op mapping, authorizer (including unknown-mode and empty-set rejection), and the full brokered round-trip over a real socket are all unit-tested and green. The one caveat is I could not exercise the true end-to-end acceptance (a live director surface labeling a real issue through a running broker daemon) from inside this container - that path is covered structurally by TestExecutorWriteArgvHitsRealLeaves resolving the argv against the real generated leaf, but a live smoke test would be the final proof.

One pre-existing rough edge I noticed but left alone: TestReadBootstrapEnvDefaults fails on clean main in this container (CodexModel default "gpt-5.4-mini" vs the test's "gpt-5.4") - a roster-config/test drift unrelated to this issue, worth a separate follow-up.

WARD-OUTCOME: done - broker now serves issue-label add/set/remove, so a director surface can apply its own triage labels through the write tier. This one lived up to its "small catch-up, not new complexity" framing. The hard part genuinely was already in cli-guard v0.74.0 - OpLabelIssue, the fail-closed labelInvariants, the client/executor/server dispatch - so ward's side was a dependency bump plus mirroring the existing FileIssue/EditIssue/CommentIssue pattern one more time. The executor and client both had a clean groove to slot into, and the label argv matched the pre-existing `addIssueLabels` shell-out exactly. Two small things fought back. First, adding the switch arm tipped `mapForgejoWriteOp` over the cyclop complexity-12 ceiling, so I split it into per-resource helpers - arguably cleaner than the flat switch anyway. Second, the code-comments hook caps contiguous comment blocks at 2 lines, which trimmed a few of my explanatory comments. Both were mechanical. Confidence is high: the argv shaping, op mapping, authorizer (including unknown-mode and empty-set rejection), and the full brokered round-trip over a real socket are all unit-tested and green. The one caveat is I could not exercise the true end-to-end acceptance (a live director surface labeling a real issue through a running broker daemon) from inside this container - that path is covered structurally by TestExecutorWriteArgvHitsRealLeaves resolving the argv against the real generated leaf, but a live smoke test would be the final proof. One pre-existing rough edge I noticed but left alone: `TestReadBootstrapEnvDefaults` fails on clean main in this container (CodexModel default "gpt-5.4-mini" vs the test's "gpt-5.4") - a roster-config/test drift unrelated to this issue, worth a separate follow-up.

coilysiren changed title from ~~feat(broker): complete the ward-side issue-label route so a director surface labels in-tier (cli-guard v0.74.0 OpLabelIssue already shipped)~~ to fix(broker): route ops forgejo issue-label DIRECT (read/direct tier), not through the broker write tier

2026-07-07 03:21:46 +00:00

coilysiren referenced this issue

2026-07-07 03:21:47 +00:00

design: score-bearing scoped labels + invert label-semantics ownership (aos owns taxonomy, ward gets an alias contract) #626

coilysiren referenced this issue

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

feat(dispatch-broker): let a director stop a running engineer (stop-only, engineer-role-only) #627