docs(agents): record that tea 0.14 cannot apply org-level labels #98

Merged
archvillainette merged 1 commits from docs/tea-label-readback-trap into main 2026-08-05 11:38:36 +00:00
Owner

tea issues edit --add-labels and --remove-labels resolve label names against
the repository's own label set only. Every Kind/*, Priority/*, Reviewed/*
and Status/* label lives at the org level, so none of them match: the command
exits 0, prints the issue, and applies nothing. Repo-local labels
(wayfinder:*, ready-for-agent) work normally, which makes the failure look
intermittent instead of categorical.

Upstream tea fixed this in v0.15 — modules/task/labels.go now queries
ListOrgLabels alongside the repo labels. nixpkgs pins 0.14.0, so this note
expires when tea is bumped. tea labels has the same repo-only limitation and
will not show the org set; tea api orgs/ShadowsOverWestgate/labels will.

The second bullet is the more durable half: re-read a label change before
believing it. An earlier version of this branch confidently documented the
opposite cause, because a label that a human had applied by hand was read back
as proof that the CLI had applied it. tea issues ls -o json exposes a labels
field; a zero exit code does not.

Identical addition in all seven repos carrying docs/agents/issue-tracker.md.

`tea issues edit --add-labels` and `--remove-labels` resolve label names against the repository's own label set only. Every `Kind/*`, `Priority/*`, `Reviewed/*` and `Status/*` label lives at the org level, so none of them match: the command exits 0, prints the issue, and applies nothing. Repo-local labels (`wayfinder:*`, `ready-for-agent`) work normally, which makes the failure look intermittent instead of categorical. Upstream tea fixed this in v0.15 — `modules/task/labels.go` now queries `ListOrgLabels` alongside the repo labels. nixpkgs pins 0.14.0, so this note expires when tea is bumped. `tea labels` has the same repo-only limitation and will not show the org set; `tea api orgs/ShadowsOverWestgate/labels` will. The second bullet is the more durable half: re-read a label change before believing it. An earlier version of this branch confidently documented the opposite cause, because a label that a human had applied by hand was read back as proof that the CLI had applied it. `tea issues ls -o json` exposes a `labels` field; a zero exit code does not. Identical addition in all seven repos carrying `docs/agents/issue-tracker.md`.
archvillainette added 1 commit 2026-08-05 10:58:03 +00:00
`tea issues edit --add-labels` and `--remove-labels` resolve names against
the repo's own label set only, so `Kind/*`, `Priority/*` and the rest of
the org set match nothing. The command exits 0, prints the issue and
changes nothing — no error to notice. Repo-local labels work, which makes
the failure look intermittent rather than categorical.

Upstream fixed this in v0.15 (`modules/task/labels.go` also queries
`ListOrgLabels`); nixpkgs pins 0.14.0, so the note expires on a bump.

Also states the general rule the miss came from: re-read a label change
before believing it. Exit 0 is not evidence.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
archvillainette force-pushed docs/tea-label-readback-trap from f958436238 to 27005622e4 2026-08-05 10:58:03 +00:00 Compare
archvillainette changed title from docs(agents): warn that tea label edits are not visible to an immediate read-back to docs(agents): record that tea 0.14 cannot apply org-level labels 2026-08-05 10:58:31 +00:00
archvillainette scheduled this pull request to auto merge when all checks succeed 2026-08-05 11:00:05 +00:00
xtul approved these changes 2026-08-05 11:01:09 +00:00
archvillainette merged commit a02e06d644 into main 2026-08-05 11:38:36 +00:00
archvillainette deleted branch docs/tea-label-readback-trap 2026-08-05 11:38:36 +00:00
Sign in to join this conversation.