Context
When a coder gives up on an issue by returning DESIGN-DECISION or NO-TECHNICAL-FIX, the bridge parks it by setting status/backlog. That is a question addressed to the operator, sitting in the same board column as work that was never groomed in the first place. There is no way to tell the two apart on the board.
Fifteen issues were parked this way over two days. None were visible as needing attention; they were found by querying the API, not by looking at the board.
The board columns come from a hardcoded union in src/types/index.ts:102:
exporttypeStatusLabel="status/backlog"|"status/ready"|"status/in-progress"|"status/in-review"|"status/done";
BOARD_COLUMNS (src/types/index.ts:115) is built from it and STATUS_LABELS is derived from BOARD_COLUMNS. Lanes are configurable via LaneConfig (docs/configurable-lanes.md), but statuses are not, so there is no way to add this without a code change.
Note the repo already has blocked and needs-human labels. A label does not create a column, so neither surfaces on the board today.
Scope note: this is about the issue board only. PR-fix items that go BLOCKED are already surfaced — src/app/automation/pr-fix-queue/page.tsx:61 filters them into their own section. Their problem is that they cannot be requeued once blocked, which is #771, not this issue.
The ask (one imperative sentence)
Add a status/blocked board column for issues that need human attention, and keep it out of the active and claimable statuses.
Expected files
src/types/index.ts
src/app/api/issues/status/route.ts
src/lib/agent-queue.ts
src/mcp/server.ts
Acceptance criteria
status/blocked exists in the StatusLabel union and in BOARD_COLUMNS (src/types/index.ts), so it renders as a board column.- It is not in
ACTIVE_STATUS_LABELS (src/types/index.ts:128). A blocked issue is not in flight and must not count as active. src/lib/agent-queue.ts does not serve an issue in status/blocked to an agent. Moving an issue there takes it out of circulation until a human moves it back, the way status/done does.- The status API (
src/app/api/issues/status/route.ts) accepts blocked as a valid target status. set_issue_status (src/mcp/server.ts) accepts blocked, so the status can be set from the MCP as well as the UI.- Moving an issue from
status/blocked to status/ready returns it to normal circulation with no residue. - Existing issues are not migrated automatically. Which of today's backlog items are genuinely blocked is a judgement call, not a mechanical one.
Out of scope, worth doing next
Having the bridge's human-escalation path set status/blocked instead of status/backlog is what makes this column fill up on its own, but that is a foreman-dispatch-bridge change. This issue only asks for the column to exist and behave correctly.
Context
When a coder gives up on an issue by returning
DESIGN-DECISIONorNO-TECHNICAL-FIX, the bridge parks it by settingstatus/backlog. That is a question addressed to the operator, sitting in the same board column as work that was never groomed in the first place. There is no way to tell the two apart on the board.Fifteen issues were parked this way over two days. None were visible as needing attention; they were found by querying the API, not by looking at the board.
The board columns come from a hardcoded union in
src/types/index.ts:102:BOARD_COLUMNS(src/types/index.ts:115) is built from it andSTATUS_LABELSis derived fromBOARD_COLUMNS. Lanes are configurable viaLaneConfig(docs/configurable-lanes.md), but statuses are not, so there is no way to add this without a code change.Note the repo already has
blockedandneeds-humanlabels. A label does not create a column, so neither surfaces on the board today.Scope note: this is about the issue board only. PR-fix items that go
BLOCKEDare already surfaced —src/app/automation/pr-fix-queue/page.tsx:61filters them into their own section. Their problem is that they cannot be requeued once blocked, which is #771, not this issue.The ask (one imperative sentence)
Add a
status/blockedboard column for issues that need human attention, and keep it out of the active and claimable statuses.Expected files
Acceptance criteria
status/blockedexists in theStatusLabelunion and inBOARD_COLUMNS(src/types/index.ts), so it renders as a board column.ACTIVE_STATUS_LABELS(src/types/index.ts:128). A blocked issue is not in flight and must not count as active.src/lib/agent-queue.tsdoes not serve an issue instatus/blockedto an agent. Moving an issue there takes it out of circulation until a human moves it back, the waystatus/donedoes.src/app/api/issues/status/route.ts) acceptsblockedas a valid target status.set_issue_status(src/mcp/server.ts) acceptsblocked, so the status can be set from the MCP as well as the UI.status/blockedtostatus/readyreturns it to normal circulation with no residue.Out of scope, worth doing next
Having the bridge's human-escalation path set
status/blockedinstead ofstatus/backlogis what makes this column fill up on its own, but that is aforeman-dispatch-bridgechange. This issue only asks for the column to exist and behave correctly.