docs(skill): Triage-Subagenten schließen Tickets terminal ab (Changelog/Rückfrage)

Skill präzisiert: jeder bearbeitende Subagent schließt seinen Vorgang selbst ab —
Rückfrage ordentlich stellen (eine konkrete Frage, einfache Sprache, Kontext →
NeedsInfo) ODER nach verifiziertem + eingespieltem Fix mit verständlichem
fixNote-Changelog schließen (Resolved). Abschluss-Regel ergänzt: kein
Open/Answered-Ticket bleibt offen liegen — Endzustand immer NeedsInfo oder Resolved.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

.claude/skills/ticket-triage/SKILL.md

@@ -58,17 +58,27 @@ Jeder Triage-Agent:
 4. liefert strukturiert (StructuredOutput-Schema): `ticketId, title, category,
    rootCause, recommendation, fixLayer (import-data|import-logic|backend|frontend|
    genetics-engine), affectedAreas[], overlapKey (Cluster-Slug), effort (S/M/L),
-   confidence, needsUserInfo`.
+   confidence, needsUserInfo`,
+5. **terminale Aktion am Ticket selbst** (jeder Triage-Agent schließt seinen
+   Vorgang ab, lässt nichts offen liegen): braucht es Infos von der Züchterin →
+   **Rückfrage ordentlich stellen** (siehe 3); ist die Ursache rein eine Daten-/
+   Code-Korrektur ohne Rückfrage → an den passenden Umsetzungs-Cluster (4)
+   übergeben (NICHT selbst querschnittlich Dateien ändern).
 
 Sammle alle Ergebnisse in **eine Datei** `docs/ticket-triage.md` (Cluster-/
 Überschneidungs-Matrix + offene Rückfragen) — token-schonend per Python aus dem
 Workflow-Ergebnis generieren, nicht 70 KB in den Kontext laden.
 
-### 3. Rückfragen an die Tickets hängen
+### 3. Rückfragen ordentlich stellen (durch den Triage-Agenten)
-Für jedes Ticket mit `needsUserInfo`:
+Wenn ein Ticket Infos der Züchterin braucht, hängt der Triage-Agent die Rückfrage
-`PUT /feedback/{id}` mit `{"question": "<konkrete Rückfrage, deutsch>"}` → Status
+**direkt selbst** ans Ticket:
-wird automatisch `NeedsInfo`. Die Züchterin beantwortet es in der App; beim
+`PUT /feedback/{id}` mit `{"question": "<Rückfrage>"}` → Status wird `NeedsInfo`.
-nächsten Lauf taucht es als `Answered` auf und wird wieder aufgegriffen.
+Anforderungen an eine gute Rückfrage: **eine konkrete Frage** (kein Sammelsurium),
+in **einfacher, freundlicher Sprache** für die Züchterin (keine Code-/Fachbegriffe),
+mit dem nötigen Kontext (welches Tier/welcher Wurf, was unklar ist), und mit einer
+klaren Handlungsaufforderung (z. B. „Wie heißt die Mutter von X?"). Die Züchterin
+beantwortet es in der App; beim nächsten Lauf erscheint es als `Answered` und wird
+wieder aufgegriffen.
 
 ### 4. Umsetzen — gebündelt nach Cluster (Überschneidungen vermeiden!)
 Die Triage-Matrix zeigt, welche Tickets sich Dateien teilen. Bündele nach
@@ -88,13 +98,24 @@ Subagenten committen NICHT und re-ingesten NICHT — das koordiniert der Haupt-L
 dann `POST /import/ingest-resolved` (wischt + lädt neu). Danach betroffene Tickets
 gegen die API verifizieren.
 
-### 6. Ticket schließen — MIT Changelog
+### 6. Ticket schließen — MIT Changelog (durch den bearbeitenden Subagenten)
-Beim Schließen IMMER dokumentieren, **was gefixt wurde**, in einfacher Sprache für
+Der Subagent/Cluster, der den Fix umgesetzt hat, schließt **seine** Tickets selbst
-die Züchterin:
+ab — aber erst **nachdem der Fix verifiziert und (bei Daten-/Import-Fixes) live
+eingespielt ist** (Schritt 5), damit „erledigt" auch stimmt:
 `PUT /feedback/{id}` mit `{"status": "Resolved", "fixNote": "<verständliche
 Erklärung, was korrigiert wurde>"}`.
-Beispiel: „Die Mutter von Yuki wurde auf Izumi korrigiert (vorher fälschlich
+Die `fixNote` ist ein **Changelog für die Züchterin**: einfache, freundliche
-Benjiro). Bitte Stammbaum neu laden." — keine Code-/Fachbegriffe.
+Sprache, keine Code-/Fachbegriffe, sagt was korrigiert wurde und ggf. was sie tun
+soll. Beispiel: „Die Mutter von Yuki wurde auf Izumi korrigiert (vorher fälschlich
+Benjiro). Bitte den Stammbaum neu laden."
+
+### Abschluss-Regel (wichtig)
+**Kein bearbeitetes Ticket bleibt offen liegen.** Jedes `Open`/`Answered`-Ticket
+endet nach einem Lauf in genau einem Endzustand:
+- **`NeedsInfo`** — Rückfrage wurde ordentlich gestellt (Info fehlt), oder
+- **`Resolved`** — Fix umgesetzt + verifiziert, mit `fixNote`-Changelog.
+Kann ein Ticket weder gefixt noch sinnvoll erfragt werden, stelle trotzdem eine
+klärende Rückfrage (NeedsInfo) statt es offen zu lassen.
 
 ## Verifikation vor „fertig"
 - Code-Fixes: `npx tsc --noEmit`, `npx vitest run`, betroffene `npx playwright test`,