Brummel
c9025065d7
Empirical observation after one day of running with the Gitea
backlog: P1 was permanently empty (same pattern as the old
docs/roadmap.md — anything that becomes "next-up" instantly
moves to in-progress, never sits in P1), and P3 was 6-of-8
identical to `kind:idea`. Three prio-stages were theatre; the
real distinction is "ja, irgendwann" vs "may be cut", and
`kind:idea` already carries the latter.
`prio:p1` / `prio:p2` / `prio:p3` deleted from Gitea (Tea
auto-removed them from all 24 issues). Remaining labels:
`kind:{milestone,feature,todo,idea}` + `state:in-progress`.
Issue distribution: 3 feature + 16 todo + 5 idea = 24.
In-tree changes:
- CLAUDE.md (project): Gitea-issues bullet rewritten — no
formal priority axis, "what's next" is orchestrator
judgement per session, `kind:idea` flagged as the
may-be-cut marker.
- skills/boss/SKILL.md: Step 1 rewritten — `tea issues ls
--state open` walks every open issue; selection is by
orchestrator judgement, not by reading prio:p1 first.
Cross-references "Queue:" updated to match.
- skills/brainstorm/SKILL.md: Step 7.5 no-override BLOCK
template drops `prio:p2` from the `tea issues create`
--labels argument.
Why not keep one stage (e.g. `prio:next`): no in-flight need;
a `pinned` boolean label can be added later if "next-up" ever
becomes a real distinct state. The cost of adding a label
later is one `tea labels create`; the cost of carrying dead
labels is constant cognitive load on every new issue.
Verification: cargo test --workspace 647/0/2, architect_sweeps
exit 0, zero residual prio:p* refs outside docs/specs/ and
docs/plans/ (historical, unchanged per the JOURNAL-cut
precedent).