From a02e06d6442ba19e0ca2b9af83512b4d8cf4352a Mon Sep 17 00:00:00 2001 From: vickydotbat Date: Wed, 5 Aug 2026 11:38:35 +0000 Subject: [PATCH] docs(agents): record that tea 0.14 cannot apply org-level labels (#98) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `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`.Reviewed-on: https://git.westgate.pw/ShadowsOverWestgate/sow-tools/pulls/98 Co-authored-by: vickydotbat --- docs/agents/issue-tracker.md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/docs/agents/issue-tracker.md b/docs/agents/issue-tracker.md index 6c15f20..1ae498c 100644 --- a/docs/agents/issue-tracker.md +++ b/docs/agents/issue-tracker.md @@ -59,6 +59,26 @@ preference — move it. `tea pr create`. - **Apply / remove labels**: `tea api --method PATCH` on the issue, or `tea api repos/ShadowsOverWestgate/sow-tools/issues//labels` endpoints. +- **Org-level labels (`Kind/*`, `Priority/*`, `Reviewed/*`, `Status/*`)**: `tea + issues edit --add-labels` / `--remove-labels` do **not** apply these on tea + 0.14.0, the version nixpkgs pins. Name resolution searches only this repo's + own label set, so an org label matches nothing and the command exits 0, + prints the issue, and changes nothing — no error, no warning. Repo-local + labels (`wayfinder:*`, `ready-for-agent`) are unaffected. PRs no-op the same + way. Upstream fixed it in v0.15 (`modules/task/labels.go` now also queries + `ListOrgLabels`), so this expires when tea is bumped; until then apply org + labels in the web UI. Note `tea labels` lists repo labels only, so it will + not show you the org set either — `tea api orgs/ShadowsOverWestgate/labels` + does. +- **Verify every label change by re-reading it.** `tea issues ls -o json` has a + `labels` field; use it. A label command exiting 0 is not evidence it applied, + and assuming otherwise has already cost one investigation several wrong turns. + `tea issues edit --add-labels` works too, org-level labels (`Kind/*`, + `Priority/*`) included, but a read-back straight afterwards can still show + the old set — `tea issues ls` has returned stale labels for several seconds + after an edit that succeeded. Never conclude an edit failed from a single + immediate list; re-read after a pause, or use the `labels` endpoints above, + whose response *is* the resulting label set and needs no second call. - **Close**: `tea issues close ` `tea` infers the repo from the git remote when run inside the clone.