The tracker doc said labels that don't exist are created on first use. They aren't: `tea issues create --labels` and `issues edit --add-labels` silently drop unknown names (the command succeeds, the issue stays unlabelled) — observed filing #151/#152 while the repo had no labels. Document creating them with `tea labels create` and checking the result. The five triage labels now exist on the server; the wayfinder:* family still has to be created before first use. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
4.9 KiB
Issue tracker: Gitea (self-hosted)
Issues and specs for this repo live as issues on Gitea
(https://git.crkc.xyz/Apps/ImageApi). Use the tea CLI for all operations.
Conventions
- Create an issue:
tea issues create --title "..." --description-file -(read the body from a heredoc on stdin), or--description "..."for a one-liner. Add labels at creation with--labels "..."(the labels must already exist — see below). - Read an issue:
tea issues <index> --comments. Usetea issues list -f index,title,body,labels,comments -o jsonfor machine-readable output. - List issues:
tea issues list --state open(default state is open) with appropriate--labels/--keywordfilters. - Comment on an issue:
tea comments add <index> "..."(alias:tea comments <index> "..."). - Apply / remove labels:
tea issues edit <index> --add-labels "..."/--remove-labels "...". - Labels must exist first. Neither
issues create --labelsnorissues edit --add-labelscreates a missing label: an unknown name is silently dropped — the command succeeds and the issue ends up unlabelled (verified against this server, tea 0.16). Check withtea labels list; create withtea labels create --name "..." --color "#rrggbb" --description "...", then apply. After labelling, confirm it stuck (tea issues <index>). The triage labels (triage-labels.md) exist; thewayfinder:*labels below must be created before first use. - Close:
tea issues close <index>. It does not accept a closing comment, so post the explanation first withtea comments add <index> "...", then close. - Raw API access (for anything the
teasubcommands don't cover):tea api <endpoint>makes an authenticated request to the Gitea API (prefixes/api/v1/when the path doesn't start with/api/). Placeholders{owner}and{repo}are replaced from the current repo context. Use-Ffor typed fields (numbers, booleans) and-dfor raw JSON bodies.
Infer the repo from the git remote (-R lets tea discover the Gitea
login from the remote); tea does this automatically when run inside a
clone. Confirm the acting user with tea whoami.
Unlike GitHub, Gitea numbers issues and pull requests separately, so a bare
#42 is unambiguous once you know which surface it refers to.
Pull requests as a triage surface
PRs as a request surface: no. (Set to yes if this repo treats
external PRs as feature requests; /triage reads this flag.)
When set to yes, PRs run through the same labels and states as issues,
using the tea pulls equivalents (tea pulls list/view/edit,
tea pulls close, plus tea comments which covers PRs). Keep only PRs
from outside collaborators (drop the repo owner and team members) when
listing external PRs for triage.
When a skill says "publish to the issue tracker"
Create a Gitea issue.
When a skill says "fetch the relevant ticket"
Run tea issues <index> --comments.
Wayfinding operations
Used by /wayfinder. The map is a single issue with child issues
as tickets.
- Map: a single issue labelled
wayfinder:map, holding the Notes / Decisions-so-far / Fog body.tea issues create --title "..." --labels wayfinder:map --description-file -. - Child ticket: an issue carrying
Part of #<map>at the top of its description, labelledwayfinder:<type>(research/prototype/grilling/task). Once claimed, the ticket is assigned to the driving dev. - Blocking: Gitea's native issue dependencies (enabled on this
server), the canonical, UI-visible representation. Add an edge with
tea api --method POST repos/{owner}/{repo}/issues/<child>/dependencies -d '{"index": <blocker-index>, "owner": "<owner>", "repo": "<repo>"}'(201 on success). Gotchas, verified against Gitea 1.27:- The route is
.../dependencies— there is noblocked_bysubpath (that 404s). - The JSON body must name the blocker's repo (
owner+repo); omitting them yields a misleading404 repository does not existeven though the child's path is correct. indexis the visible#number, not an internal database id. Verify withtea api repos/{owner}/{repo}/issues/<child>/dependencies(lists blockers); remove with--method DELETEand the same body. Where dependencies aren't available, fall back to aBlocked by: #<n>, #<n>line at the top of the child description. A ticket is unblocked when every blocker is closed.
- The route is
- Frontier query: list the map's open children (issues whose
description carries
Part of #<map>), drop any with an open blocker (dependency orBlocked byline) or an assignee; first in map order wins. - Claim:
tea issues edit <n> --add-assignees <username>(the session's first write;<username>fromtea whoami). - Resolve:
tea comments add <n> "<answer>", thentea issues close <n>, then append a context pointer (gist + link) to the map's Decisions-so-far.