story-110: A filed brief carries its classification

[jerodw]

Story

A filed brief carries its classification.

Every brief the Inspector writes is classified — a category, a severity, a confidence, an effort, and the workflow it should be planned under — and none of it reached a person looking at the tracker. It was filed, in a base64 blob in an HTML comment, where only l5-plan --brief reads it. On the board a brief was prose and a single l5 label, and a developer choosing what to plan next could not tell a correctness defect from documentation drift without opening each one.

What it ships, and why both

The sync script now adds a category label beside the l5 label it already applied, and sets five single-select project fields — Category, Severity, Confidence, Effort and Workflow — from values the payload already carries.

The two answer different questions. Fields sort, group and filter on the board, and a single-select sorts by the option order the field declares rather than alphabetically, so a Severity field listed 3, 2, 1 puts the worst first. They are invisible outside the project. A label travels with the issue, shows in the issue list and is searchable everywhere, but a label set has no order, so it filters and never sorts.

Confidence ships as a field, which the brief had left undecided. The argument for omitting it is that severity already carries the consequence and a brief may not be severity 3 unless its confidence is high, so the two correlate where sorting matters most. The argument that won is the one the separate axis exists for: a severity-2 guess and a severity-2 certainty are different things to pick up next.

A label and a field are treated differently on purpose. gh can create a label and cannot create a project field, so a category filed for the first time labels its own issue without anyone setting anything up, while a field the board does not have costs that field and nothing else.

Evidence

• Suite: 5184 passed, 1 skipped (exit 0)
• Clean clone with the story committed: exit 0
• Verification passed, no blocking issues
• 0 retries, 0 self-routes, no correction pass, $21.16
• 6 files changed, +1162 / −105

The one unverified note is settled, and both halves hold

The verifier could not reach a live tracker, so it recorded that the stub gh encodes two behaviours the story rests on and that a divergence would be invisible from this repository. Checked against the real gh and this deployment's project:

• label create --force updates rather than fails on an existing label. A probe label was created, re-created with --force and a different colour and description, and it changed rather than erroring. The probe was deleted afterwards.
• project item-list --format json keys an item's field by the field name lowercased with spaces removed. The real output carries category, confidence, effort, severity, status and workflow, exactly as the stub does.

Notes for review

This deployment is already wired. .harness/sync/github.sh names all five fields and the l5- prefix, so the next brief filed carries its label and fields with no further setup.

The 35 briefs already on the board were backfilled by hand before this merged, at the developer's request — the same five fields set from each brief's own payload, and the same seven l5-<category> labels at the same colour. Nothing diverges from what this story will produce, but the backfill used gh label create without --force, so it would not have corrected a pre-existing label that differed. None did.

The second unverified note is trivial: the claim-support check reported no claims to settle, so nothing there was judged.

🤖 Generated with Claude Code

https://claude.ai/code/session_019WkxmJ5ArLEaC2RDPGkbRU