docs(agents): warn that tea label edits are not visible to an immediate read-back

`tea issues edit --add-labels` applies org-level labels correctly, but `tea issues ls` can return the pre-edit label set for several seconds afterwards. Reading that stale result as a failed edit sent one investigation down three wrong paths (missing token, tea too old, switch to curl) before the original command turned out to have worked. Recorded next to the existing `</dev/null` trap; both are tea behaviours that read as breakage to a non-interactive caller. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-05 12:53:46 +02:00
1 changed files with 6 additions and 0 deletions
@@ -59,6 +59,12 @@ preference — move it.
  `tea pr create`.
 - **Apply / remove labels**: `tea api --method PATCH` on the issue, or
  `tea api repos/ShadowsOverWestgate/sow-tools/issues/<number>/labels` endpoints.
+  `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 <number>`

 `tea` infers the repo from the git remote when run inside the clone.