Gulum
5edd84046d
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>
131 lines
7.1 KiB
Markdown
131 lines
7.1 KiB
Markdown
---
|
|
name: ticket-triage
|
|
description: >-
|
|
Fehlerberichte (Tickets) der Züchterin abarbeiten: neue Tickets per Subagent
|
|
triagieren, Rückfragen an die Tickets hängen, beantwortete Tickets wieder
|
|
aufgreifen, Fixes gebündelt umsetzen und beim Schließen dokumentieren, was
|
|
gefixt wurde. Nutze diesen Skill, wenn der Nutzer „Tickets abarbeiten /
|
|
triagieren", „Fehlerberichte bearbeiten" o. Ä. verlangt.
|
|
---
|
|
|
|
# Ticket-Triage & Abarbeitung
|
|
|
|
Tickets entstehen über das „Fehler melden"-Feature (`POST /feedback`) und werden
|
|
unter **Hilfe → Meine Tickets** (`/hilfe/tickets`) verwaltet. Dieser Skill
|
|
automatisiert das Triagieren, Rückfragen-Stellen, Umsetzen und Schließen.
|
|
|
|
## Status-Lebenszyklus (Feedback.Status)
|
|
|
|
| Status | Bedeutung | Wer ist dran |
|
|
|---|---|---|
|
|
| `Open` | Neues Ticket, noch nicht triagiert | **KI** (triagieren) |
|
|
| `NeedsInfo` | KI hat eine **Rückfrage** angehängt | Züchterin (antworten) |
|
|
| `Answered` | Züchterin hat geantwortet | **KI** (wieder aufgreifen, umsetzen) |
|
|
| `Resolved` | Erledigt — mit `fixNote` (Changelog) | — |
|
|
|
|
**Zu bearbeiten sind `Open` (neu) und `Answered` (KI wieder dran).** `NeedsInfo`
|
|
wartet auf die Züchterin, `Resolved` ist fertig — beide überspringen.
|
|
|
|
## Voraussetzungen
|
|
|
|
- App läuft (Aspire): `dotnet run --project GerbilManager.AppHost`; API auf
|
|
http://localhost:5179. Siehe `CLAUDE.md` (Architektur, Import→DB-Workflow,
|
|
Domänenwissen: 6-Jahre-Lebensspanne, Geschwisterverpaarung, Genotyp/E-Locus,
|
|
`isResident`).
|
|
- Feedback überlebt den Import-Ingest (FK-freie Spalten) — Tickets bleiben
|
|
erhalten, auch wenn die DB neu befüllt wird.
|
|
|
|
## Ablauf
|
|
|
|
### 1. Tickets holen & einteilen
|
|
`curl -s http://localhost:5179/feedback` (neueste zuerst). Encoding-Falle: über
|
|
eine Datei holen (`curl -o raw.json`) und mit `python … .decode('utf-8')` lesen,
|
|
nicht via Windows-stdin-Pipe (sonst Mojibake). Test-/Dummy-Tickets ausschließen.
|
|
Filtere auf `status in (Open, Answered)`. Bei `Answered` zusätzlich das Feld
|
|
`answer` (Antwort der Züchterin) mitnehmen — darauf basiert die Umsetzung.
|
|
|
|
### 2. Triage per Subagent (ein Agent pro Ticket)
|
|
Nutze die **Workflow-Orchestrierung** (`pipeline`) — einen Triage-Agenten pro
|
|
Ticket. args ASCII-sicher halten (nur id/context/gerbilId/litterId übergeben; die
|
|
deutschen Nachrichten holt der Agent selbst aus `GET /feedback`). Defensive im
|
|
Script: `const tickets = Array.isArray(args) ? args : JSON.parse(args)`.
|
|
|
|
Jeder Triage-Agent:
|
|
1. liest `CLAUDE.md` + `docs/ticket-triage.md` (falls vorhanden),
|
|
2. holt seinen Ticket-Text (+ `answer` bei `Answered`) aus `GET /feedback`,
|
|
3. untersucht die echten Daten über die API (`GET /gerbils/{id}`, `/litters/{id}`,
|
|
Eltern verfolgen; `provenance` zeigt Import-Herkunft inkl. verworfener Werte),
|
|
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`,
|
|
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 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
|
|
**datei-disjunkten Workstreams**, damit parallele Subagenten nicht kollidieren:
|
|
- **Genetik-Engine** → `gerbil-manager-web/src/genetics/**`, `tools/import/genotype.py`.
|
|
- **Stammbaum-Import** (Eltern/Dedup/Gender/`isResident`) → `tools/import/extract.py`,
|
|
`merge_and_resolve.py`, `conflict-decisions.json`.
|
|
- **Frontend-Anzeige** (z. B. Nicht-Bestandstiere ausblenden) → `GerbilDetailPage.tsx`,
|
|
`de.ts`.
|
|
Gemeinsam genutzte Dateien (`de.ts`, `GerbilDetailPage.tsx`) gehören **genau einem**
|
|
Workstream — sonst sequenziell. Datenkorrekturen, die die Züchterin nennt, als
|
|
Override in `conflict-decisions.json` kodieren (data-driven, re-ingest-stabil).
|
|
Subagenten committen NICHT und re-ingesten NICHT — das koordiniert der Haupt-Loop.
|
|
|
|
### 5. Import neu einspielen (bei Daten-/Import-Änderungen)
|
|
`python tools/import/extract.py` → `extract_contracts.py` → `merge_and_resolve.py`,
|
|
dann `POST /import/ingest-resolved` (wischt + lädt neu). Danach betroffene Tickets
|
|
gegen die API verifizieren.
|
|
|
|
### 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>"}`.
|
|
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`,
|
|
`dotnet build`/`dotnet test`, Python-`test_*.py` — grün.
|
|
- Daten-Fixes: in `resolved_import.json` stichprobenartig prüfen, dann re-ingest +
|
|
API-Check des konkreten Tiers/Wurfs.
|
|
- Jedes erledigte Ticket auf `Resolved` mit `fixNote` gesetzt.
|
|
|
|
## Hinweise
|
|
- Pro Ticket genau ein Triage-Agent; Umsetzung gebündelt nach Cluster.
|
|
- Encoding: deutsche Texte als UTF-8 (Datei, nicht stdin-Pipe).
|
|
- Nichts committen, bis der Haupt-Loop verifiziert hat; auf `main` arbeiten.
|