vault: session notes 2026-07-14

journal/2026-07-14.md

@@ -79,3 +79,10 @@ tags: [scope/global, type/log]
 **Reason:** prompt_input_exit
 **Vault notes touched:**
 (none)
+
+## Session — 2026-07-14T17:36:58Z
+
+**Project:** /home/jared/dev/cc-os
+**Reason:** prompt_input_exit
+**Vault notes touched:**
+(none)

reference/tea-cli-assignee-gotchas.md

@@ -0,0 +1,55 @@
+---
+type: reference
+subtype: api-integration
+title: "tea CLI: assignees are invisible in issue view"
+summary: How to assign and verify assignees with the tea (Forgejo/Gitea) CLI — `tea issues <N>` never renders assignees, so verifying a claim needs `tea issues list --fields`.
+tags:
+  - type/reference
+  - tool/tea
+  - tool/forgejo
+  - domain/issue-tracking
+scope: global
+last_updated: 2026-07-14
+date: 2026-07-14
+last_reviewed: 2026-07-14
+source: cc-os
+---
+
+# tea CLI: assignees are invisible in issue view
+
+Discovered while claiming a wayfinder ticket on Forgejo (`jared/cc-os`), where the claim *is*
+the assignee — so a claim you can't verify is a claim you don't have.
+
+## The gotcha
+
+`tea issues <N>` renders title, author, labels, and body — **but never the assignees**, even
+when the issue has them. Reading the issue back is therefore useless as verification: an
+assignment that succeeded and one that silently did nothing look identical.
+
+## Correct commands
+
+```bash
+# assign (only valid on `edit`; the flag is --add-assignees, NOT --assignees)
+tea issues edit <N> --repo <owner>/<repo> --add-assignees <user>
+
+# verify — the only view that shows them
+tea issues list --repo <owner>/<repo> --fields index,title,assignees --output simple
+```
+
+Failure modes seen:
+
+- `tea issues <N> --add-assignees <user>` → `flag provided but not defined` (the view
+  subcommand takes no edit flags).
+- `tea issues list --assigned-to <user>` → `flag provided but not defined` (no such filter;
+  use `--fields assignees` and filter locally).
+- A successful `tea issues edit` prints the issue body back, which **looks** like a no-op
+  confirmation and shows no assignee — do not read that as failure, and do not read it as
+  success either. Verify with `list --fields`.
+
+## Why it matters beyond one repo
+
+Any workflow where assignment carries meaning — wayfinder claim-before-work, "who owns this
+ticket" triage — needs a verification step that is not the issue view. Budget one extra
+`list --fields` call.
+
+See [[cc-os-plugin-skill-naming-convention]] for the sibling convention set used on that repo.