Files
InfiniTower/docs/agents/issue-tracker.md

4.1 KiB

Issue tracker: Gitea

Issues und Specs für dieses Repo leben als Gitea-Issues auf https://gitlab.hive-brain.de (Repo MDietermann/InfiniTower).

Achtung, irreführender Hostname: Die Domain heißt gitlab.hive-brain.de, dahinter läuft aber Gitea, kein GitLab. Nicht glab benutzen — die CLI hier ist tea.

Setup (einmalig)

tea login add --name hive --url https://gitlab.hive-brain.de --token <access-token>

Token in Gitea unter Settings → Applications → Generate New Token mit Scope issue (bzw. repo) erzeugen. tea findet Login und Repo danach selbst, wenn es innerhalb des Clones läuft; sonst explizit --login hive --repo MDietermann/InfiniTower anhängen.

Binary: https://dl.gitea.com/tea/ oder go install code.gitea.io/tea@latest.

Mindestversion: 0.15.0 (tea --version prüfen). Ältere Builds kennen weder --labels beim Anlegen noch issues edit / comment / issues close — damit fällt die halbe Konvention unten aus.

Konventionen

  • Issue anlegen: tea issues create --title "..." --description "...". Für mehrzeilige Beschreibungen ein Heredoc in -d einsetzen. Labels direkt mit --labels a,b, Assignees mit --assignees <user>.
  • Issue lesen: tea issues <index> (Alias tea issue <index>). Kommentare separat mit tea comment list <index>.
  • Issues listen: tea issues list --state open --output json. Filter: --labels, --assignee, --milestones, --keyword. Paginierung über --limit / --page (Default 30 — bei Vollständigkeitsbedarf hochsetzen).
  • Kommentieren: tea comment add <index> --description "...".
  • Labels setzen / entfernen: tea issues edit <index> --add-labels "..." --remove-labels "...". Vorhandene Labels: tea labels list --output json; neue anlegen mit tea labels create --name ... --color ....
  • Schließen: tea issues close <index>. Nimmt keinen Abschlusskommentar entgegen — erst tea comment add <index> --description "...", dann schließen.
  • Pull Requests: Gitea nennt sie wie GitHub „pull requests". tea pulls list|create|view|merge|close, Review-Kommandos tea pulls approve|reject|review.

Bei Unsicherheit über eine Flag: tea <command> --help ausführen statt raten.

PRs als Request-Surface

PRs as a request surface: no. (Auf yes setzen, wenn externe PRs in diesem Repo als Feature-Requests behandelt werden sollen; /triage liest dieses Flag.)

Bei yes laufen PRs durch dieselben Labels und States wie Issues, über die tea pulls-Äquivalente. Gitea nummeriert Issues und PRs in einem gemeinsamen Zähler (wie GitHub, anders als GitLab) — #42 ist also entweder ein Issue oder ein PR, nie beides.

Wenn ein Skill sagt „publish to the issue tracker"

Ein Gitea-Issue anlegen (tea issues create).

Wenn ein Skill sagt „fetch the relevant ticket"

tea issues <index> plus tea comment list <index>.

Wayfinding-Operationen

Für /wayfinder. Die Map ist ein einzelnes Issue, die Tickets sind Child-Issues.

  • Map: ein Issue mit Label wayfinder:map, das den Notes / Decisions-so-far / Fog-Body trägt. tea issues create --labels wayfinder:map.
  • Child-Ticket: ein Issue mit Part of #<map> als erster Zeile der Beschreibung und Label wayfinder:<type> (research/prototype/grilling/task). Beim Claim wird es dem treibenden Dev assigned.
  • Blocking: Gitea hat native Issue-Dependencies („Depends on"), aber tea hat dafür kein Subcommand. Deshalb hier per Konvention eine Blocked by: #<n>, #<n>-Zeile oben in der Beschreibung. Ein Ticket ist unblocked, wenn alle genannten Issues geschlossen sind.
  • Frontier-Query: tea issues list --state open --output json, auf die Children der Map einschränken, dann alles rauswerfen, das einen offenen Blocker in der Blocked by-Zeile oder einen Assignee hat; das erste in Map-Reihenfolge gewinnt.
  • Claim: tea issues edit <n> --add-assignees <user> — der erste Write der Session.
  • Resolve: tea comment add <n> --description "<answer>", dann tea issues close <n>, dann einen Context-Pointer (Gist + Link) an die Decisions-so-far der Map anhängen.