Die Doku stellte fest, tea sei installiert - was auf jedem anderen Geraet
falsch ist und dazu fuehrt, dass saemtliche Kommandos darunter fehlschlagen,
ohne dass der Grund dabeisteht.
Mit dem noetigen Token-Scope, damit gleich klar ist, warum Wartungs-API und
Organisations-Repos nicht funktionieren.
tea issues edit --add-assignees ruft POST /issues/<index>/assignees auf, den
Gitea nicht kennt - der Aufruf endet in einem nackten 404, ohne dass tea das
als Fehlbedienung kenntlich macht. Assignees werden stattdessen per PATCH auf
das Issue gesetzt.
Betrifft direkt den Claim-Schritt jeder Wayfinder-Session, deshalb an beiden
Stellen korrigiert.
Der Endpoint war als ungeprueft markiert. Beim Verdrahten der ersten
Wayfinder-Map hat sich gezeigt: owner und repo muessen im Body wiederholt
werden, der Pfad allein reicht nicht. Ohne sie schlaegt der Aufruf mit
"repository does not exist [owner_name: ]" fehl, was in eine falsche Richtung
zeigt. Die von tea dokumentierten {owner}/{repo}-Platzhalter werden hier
ebenfalls nicht ersetzt.
Die Engineering-Skills (wayfinder, triage, to-tickets, to-spec) erwarten pro
Repo eine Tracker-Beschreibung. Hier ist das Gitea, nicht GitHub oder GitLab -
der Host heisst zwar gitlab.hive-brain.de, spricht aber die Gitea-API, also
tea statt glab.
Issue-Dependencies und Sub-Issues kann tea 0.15 nicht abbilden; beides ist in
der Doku als ungeprueft bzw. mit Body-Konvention als Fallback vermerkt, damit
keine Session sich auf ungetestete Kommandos verlaesst.
