Mark planned issues with a configurable planned_label #249

Merged

lucas merged 1 commit from agent/issue-248-planned-label into main

2026-11-11 09:39:09 +01:00

omp-deck commented

2026-11-10 22:26:21 +01:00

Collaborator

Closes: #248

What changed

implementation.planned_label joins planning_label in .omp/forgejo.yaml. Both stay optional; with neither configured nothing changes.
A plan-issue session started on an issue adds planning_label once the session exists (a refused start labels nothing). Inbox and free-text seeds have no issue yet and are skipped.
publishPlanIssue adds planned_label and removes planning_label on the issue it wrote — including an issue it just created. A label failure is logged and leaves the publish outcome (and the inbox item's processed flag) untouched.
Abandoning an implementation drops the now-stale planned_label together with the progress label while adding planning_label.
The agent cannot set or clear planned_label by hand: it joins its siblings in session-policy's protected names.
ForgejoDispatcher.swapLabels moved out to apps/server/src/forgejo/issue-labels.ts as applyLabelDelta, widened to lists on both sides (the abandon path removes two labels) and shared with plan-issue sessions. canonicalLabelName moved with it.

Validation: planned_label must differ from planning_label. Equal to intake_label is deliberately legal — "plan done" and "ready to implement" can be the same label, mirroring the existing intake_label == planning_label allowance.

⚠️ The labels do not exist yet in this repository

This branch configures planning_label: agent/planning and planned_label: agent/planned in .omp/forgejo.yaml, but lucas/omp-deck currently has no label matching either name (the pool is Agent/In Progress, Agent/Ready, Agent/Triage, Compat/*, Kind/*, Priority/*, Reviewed/*, Status/*). Until Agent/Planning and Agent/Planned are created in Forgejo, every plan-issue start and publish logs an "unknown label" warning; nothing else breaks and no state is corrupted.

Two decisions for you, neither of which I can make from here (creating labels is not something I can do):

Create Agent/Planning and Agent/Planned (names fold case/separators, so the lowercase config entries resolve to them).
Alternatively, Agent/Ready is already described as "Planned and ready to be picked up by an implementer agent" — which is exactly what planned_label means. Setting planned_label: agent/ready would reuse it and only Agent/Planning would have to be created. Say the word and I'll change the config line.

Verification

bun test apps/server/src → 1282 pass, 0 fail (81 files).
bun run typecheck → clean.

New test coverage: publish swapping planning→planned on an issue seed and on a created issue, a failing label PUT and an unknown label name leaving the outcome and the inbox item alone, no config file meaning no label call at all, startPlanIssue labelling an issue seed but not an inbox seed, and abandon dropping both the progress and planned ids.

Closes: #248 ## What changed - `implementation.planned_label` joins `planning_label` in `.omp/forgejo.yaml`. Both stay optional; with neither configured nothing changes. - A plan-issue session started on an **issue** adds `planning_label` once the session exists (a refused start labels nothing). Inbox and free-text seeds have no issue yet and are skipped. - `publishPlanIssue` adds `planned_label` and removes `planning_label` on the issue it wrote — including an issue it just created. A label failure is logged and leaves the publish outcome (and the inbox item's processed flag) untouched. - Abandoning an implementation drops the now-stale `planned_label` together with the progress label while adding `planning_label`. - The agent cannot set or clear `planned_label` by hand: it joins its siblings in `session-policy`'s protected names. - `ForgejoDispatcher.swapLabels` moved out to `apps/server/src/forgejo/issue-labels.ts` as `applyLabelDelta`, widened to lists on both sides (the abandon path removes two labels) and shared with plan-issue sessions. `canonicalLabelName` moved with it. Validation: `planned_label` must differ from `planning_label`. Equal to `intake_label` is deliberately legal — "plan done" and "ready to implement" can be the same label, mirroring the existing `intake_label == planning_label` allowance. ## ⚠️ The labels do not exist yet in this repository This branch configures `planning_label: agent/planning` and `planned_label: agent/planned` in `.omp/forgejo.yaml`, but `lucas/omp-deck` currently has no label matching either name (the pool is `Agent/In Progress`, `Agent/Ready`, `Agent/Triage`, `Compat/*`, `Kind/*`, `Priority/*`, `Reviewed/*`, `Status/*`). Until `Agent/Planning` and `Agent/Planned` are created in Forgejo, every plan-issue start and publish logs an "unknown label" warning; nothing else breaks and no state is corrupted. Two decisions for you, neither of which I can make from here (creating labels is not something I can do): 1. Create `Agent/Planning` and `Agent/Planned` (names fold case/separators, so the lowercase config entries resolve to them). 2. Alternatively, `Agent/Ready` is already described as *"Planned and ready to be picked up by an implementer agent"* — which is exactly what `planned_label` means. Setting `planned_label: agent/ready` would reuse it and only `Agent/Planning` would have to be created. Say the word and I'll change the config line. ## Verification - `bun test apps/server/src` → 1282 pass, 0 fail (81 files). - `bun run typecheck` → clean. New test coverage: publish swapping planning→planned on an issue seed and on a created issue, a failing label PUT and an unknown label name leaving the outcome and the inbox item alone, no config file meaning no label call at all, `startPlanIssue` labelling an issue seed but not an inbox seed, and abandon dropping both the progress and planned ids.

omp-deck added 1 commit

2026-11-10 22:26:21 +01:00

feat(server): mark planned issues with a configurable planned_label a690585b0c

The planning stage of an issue was invisible: an issue being planned
looked like one nobody had touched, and a finished plan like one still
being written.

A plan-issue session started on an issue now marks it with
`implementation.planning_label`, and writing the approved plan swaps
that for the new optional `implementation.planned_label`; an abandoned
implementation drops the then-stale planned label along with the
progress one. Both labels remain opt-in, label failures are logged
rather than failing planning or publishing, and the agent may not set
either by hand.

The dispatcher's private label-swap moves to `issue-labels.ts` as
`applyLabelDelta`, taking lists on both sides so the abandon path can
remove two labels and plan-issue sessions can share it.

Co-Authored-By: Claude Opus 5 via omp-deck