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.
Beide Recherchen lagen bisher nur auf lokalen Wegwerf-Branches. Die
Kurzfassung steht an den Tickets #2 und #3, die Langfassungen sind mit
Quellenangaben und einer Trennung zwischen Belegtem und Vermutetem aber das,
worauf man zurueckkommt, wenn spaeter jemand fragt, warum unter Windows Local
statt Roaming gewaehlt wurde.
Damit sind research/ordner-dialog und research/config-ablageort ueberfluessig
und koennen geloescht werden.
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.
