Tag bug reports with a bug label #33

New issue

Open

opened 2026-07-29 20:44:29 +01:00 by vnprc-agent · 1 comment

vnprc-agent commented

2026-07-29 20:44:29 +01:00

Contributor

Give a bug report a machine-readable mark, so that listing what is broken in a repository does not mean reading every title in the backlog.

Primary goals:

One label, one meaning — bug marks a report that something is broken, and nothing else; the implementation issue that repairs it is not itself a bug.
Recorded beside the shape it applies to — the rule lives in issue-writing.md's Bug reports section rather than in an agent's head.
Applied at creation — forge issue create -l bug is the default path, with forge issue labels <n> --add-label bug for a report already filed.

Current state

issue-writing.md:43 defines the bug-report shape — symptom plus evidence, no diagnosis — but says nothing about tagging one, and no memory file mentions labels at all. The CLI surface has been in place since allod/tools issue #85 landed: forge issue create -l, forge issue edit --add-label, forge issue labels, and forge issue list -l all take labels, and cli-design.md:9 already documents their multi-value shape. So the convention is the only missing piece.

No repository in the forge has a single label defined, so nothing carries the mark yet. forge label create bug succeeds on repositories the caller owns and exits 22 with empty output on org repositories, which is allod/tools issue #100. Until that is understood, creating the label on an org repository is a human act at the forge, and the guidance lands ahead of the label rather than waiting on it.

Scope

In: one paragraph in issue-writing.md's Bug reports section stating when bug applies and when it does not, plus the note that a repository needs the label created once before an issue can carry it.

Out: any further label taxonomy. Priority, area, status, and type labels are a separate decision about classification, not a consequence of this one.

Out: the forge label create failure itself, tracked in allod/tools issue #100, and the creation of the label on org repositories, which the agent token cannot currently perform.

Give a bug report a machine-readable mark, so that listing what is broken in a repository does not mean reading every title in the backlog. Primary goals: - **One label, one meaning** — `bug` marks a report that something is broken, and nothing else; the implementation issue that repairs it is not itself a bug. - **Recorded beside the shape it applies to** — the rule lives in `issue-writing.md`'s Bug reports section rather than in an agent's head. - **Applied at creation** — `forge issue create -l bug` is the default path, with `forge issue labels <n> --add-label bug` for a report already filed. ### Current state `issue-writing.md:43` defines the bug-report shape — symptom plus evidence, no diagnosis — but says nothing about tagging one, and no memory file mentions labels at all. The CLI surface has been in place since `allod/tools` issue #85 landed: `forge issue create -l`, `forge issue edit --add-label`, `forge issue labels`, and `forge issue list -l` all take labels, and `cli-design.md:9` already documents their multi-value shape. So the convention is the only missing piece. No repository in the forge has a single label defined, so nothing carries the mark yet. `forge label create bug` succeeds on repositories the caller owns and exits 22 with empty output on org repositories, which is `allod/tools` issue #100. Until that is understood, creating the label on an org repository is a human act at the forge, and the guidance lands ahead of the label rather than waiting on it. ### Scope In: one paragraph in `issue-writing.md`'s Bug reports section stating when `bug` applies and when it does not, plus the note that a repository needs the label created once before an issue can carry it. Out: any further label taxonomy. Priority, area, status, and type labels are a separate decision about classification, not a consequence of this one. Out: the `forge label create` failure itself, tracked in `allod/tools` issue #100, and the creation of the label on org repositories, which the agent token cannot currently perform.

vnprc-agent commented

2026-07-29 21:00:07 +01:00

Author

Contributor

Correction to one line in Current state above: creation does not split on whether the caller owns the repository — it also succeeds in a personal namespace the calling account does not own. The boundary is which namespaces the token holds write scope for, so the 403 behind exit 22 is correct behavior and allod/tools issue #100 is a diagnostics defect rather than the blocker here. Full analysis on that issue.

The operative conclusion in this issue is unaffected: creating the label on an org repository remains a human act at the forge, and the guidance lands ahead of the label.

Correction to one line in Current state above: creation does not split on whether the caller owns the repository — it also succeeds in a personal namespace the calling account does not own. The boundary is which namespaces the token holds write scope for, so the `403` behind exit 22 is correct behavior and `allod/tools` issue #100 is a diagnostics defect rather than the blocker here. Full analysis on that issue. The operative conclusion in this issue is unaffected: creating the label on an org repository remains a human act at the forge, and the guidance lands ahead of the label.