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>
This commit is contained in:
2026-06-22 21:12:03 +02:00
parent d27a389f0e
commit 5edd84046d

View File

@@ -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
Für jedes Ticket mit `needsUserInfo`:
`PUT /feedback/{id}` mit `{"question": "<konkrete Rückfrage, deutsch>"}` → Status
wird automatisch `NeedsInfo`. Die Züchterin beantwortet es in der App; beim
nächsten Lauf taucht es als `Answered` auf und wird wieder aufgegriffen.
### 3. Rückfragen ordentlich stellen (durch den Triage-Agenten)
Wenn ein Ticket Infos der Züchterin braucht, hängt der Triage-Agent die Rückfrage
**direkt selbst** ans Ticket:
`PUT /feedback/{id}` mit `{"question": "<Rückfrage>"}` → Status wird `NeedsInfo`.
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
Beim Schließen IMMER dokumentieren, **was gefixt wurde**, in einfacher Sprache für
die Züchterin:
### 6. Ticket schließen — MIT Changelog (durch den bearbeitenden Subagenten)
Der Subagent/Cluster, der den Fix umgesetzt hat, schließt **seine** Tickets selbst
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
Benjiro). Bitte Stammbaum neu laden." — keine Code-/Fachbegriffe.
Die `fixNote` ist ein **Changelog für die Züchterin**: einfache, freundliche
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`,