Basti/Bruno
1
0
Fork 0
Code Issues 63 Pull requests Projects Releases Packages Wiki Activity Actions

Post-Merge Verification & Automated Testing: Prüfen ob Fixes wirklich funktionieren #88

New issue
Open
opened 2026-03-30 20:27:56 +00:00 by David · 1 comment
David commented 2026-03-30 20:27:56 +00:00
Collaborator
Copy link

Beschreibung

Nach Claude-Run automatisch Tests ausführen, nach MR-Merge verifizieren
dass der Fix in Produktion wirkt, und eine Confidence-Bewertung der
Lösungsqualität einführen. Aktuell optimiert Bruno auf "MR erstellt" —
nicht auf "Problem gelöst".

Hintergrund

Bruno speichert repo.test_command und repo.lint_command in der DB,
führt sie aber nie aus. kontext.md instruiert Claude "teste mit pytest",
aber niemand prüft ob er es tut. Ebenso existiert die AppSignal-Integration
nur für Ticket-Import, wird aber nicht genutzt um nach dem Merge zu prüfen
ob der Fix das Problem tatsächlich behoben hat.

Abhängigkeit: MR-Outcome-Tracking (#90) muss zuerst implementiert sein,
damit Post-Merge Monitoring und Confidence Scoring auf MR-Daten zugreifen können.

Akzeptanzkriterien

Automated Testing nach Claude-Run

  • Nach jedem Claude-Run wird repo.test_command im Repo ausgeführt
  • Nach jedem Claude-Run wird repo.lint_command im Repo ausgeführt
  • Test-/Lint-Ergebnisse werden in ticket.tests_pass und ticket.lint_pass gespeichert
  • Bei Test-Failure: Fehlermeldung wird als Feedback an Claude übergeben (wie Review-Fix-Loop)
  • Max 2 Test-Fix-Runden bevor Ticket als "failed" markiert wird
  • Test-Coverage-Delta wird gemessen und gespeichert (falls Coverage-Tool konfiguriert)

Post-Merge Monitoring

  • Nach Merge: AppSignal-Integration prüft ob Error-Rate für betroffene App sinkt
  • ticket.post_deploy_status trackt: "healthy" | "error" | "unknown"
  • Timeout von 24h für Post-Merge-Check (danach "unknown")
  • Dashboard zeigt Post-Merge-Status pro Ticket

Confidence Scoring

  • Nach Claude-Run + Tests: ticket.solution_confidence (0-100) berechnen
  • Faktoren: Tests vorhanden? Tests bestanden? Lint bestanden? Diff-Größe? Review-Runden?
  • Confidence < 50: Review-Agent bekommt Warnung "Low confidence — genau prüfen"
  • Confidence > 90: Optionaler Fast-Track (weniger Review-Runden)
  • Stats-API zeigt Confidence-Verteilung

Vereint bestehende Issues

  • Übernimmt #22 (Test-Ausführung nach Claude-Run)
  • Übernimmt #49 (Confidence-Scores)

Technische Hinweise

  • Betroffene Dateien:
    • Neu: backend/services/test_runner.py (Test-Ausführung nach Claude-Run)
    • Neu: backend/services/confidence_scorer.py (Confidence-Berechnung)
    • Ändern: backend/models/ticket.py (+ tests_pass, lint_pass, solution_confidence, post_deploy_status)
    • Ändern: backend/services/pipeline.py (Test-Step nach Claude-Run einbauen, Confidence berechnen)
    • Ändern: backend/services/review_agent.py (Confidence in Review-Prompt einfließen lassen)
    • Ändern: backend/services/appsignal_poller.py (Post-Merge Error-Check)
    • Ändern: backend/main.py (Post-Merge-Check Scheduler-Job)
    • Ändern: backend/api/pipeline.py (Stats um Confidence + Post-Merge erweitern)
    • Ändern: frontend/src/pages/TicketDetail.tsx (Confidence + Post-Merge-Status anzeigen)
  • Ansatz: Pipeline-Erweiterung — nach Claude-Run kommt Test-Step, nach MR kommt Post-Merge-Check.
    Confidence-Score wird aus Test/Lint/Diff-Daten berechnet, nicht via LLM.
  • Migration nötig: Ja (neue Ticket-Felder)
  • Abhängigkeit: #90 (MR-Outcome-Tracking) — liefert mr_outcome/mr_reviewed_at Daten

Aufwand: L

## Beschreibung Nach Claude-Run automatisch Tests ausführen, nach MR-Merge verifizieren dass der Fix in Produktion wirkt, und eine Confidence-Bewertung der Lösungsqualität einführen. Aktuell optimiert Bruno auf "MR erstellt" — nicht auf "Problem gelöst". ## Hintergrund Bruno speichert `repo.test_command` und `repo.lint_command` in der DB, führt sie aber **nie aus**. kontext.md instruiert Claude "teste mit pytest", aber niemand prüft ob er es tut. Ebenso existiert die AppSignal-Integration nur für Ticket-Import, wird aber nicht genutzt um nach dem Merge zu prüfen ob der Fix das Problem tatsächlich behoben hat. **Abhängigkeit:** MR-Outcome-Tracking (#90) muss zuerst implementiert sein, damit Post-Merge Monitoring und Confidence Scoring auf MR-Daten zugreifen können. ## Akzeptanzkriterien ### Automated Testing nach Claude-Run - [ ] Nach jedem Claude-Run wird `repo.test_command` im Repo ausgeführt - [ ] Nach jedem Claude-Run wird `repo.lint_command` im Repo ausgeführt - [ ] Test-/Lint-Ergebnisse werden in `ticket.tests_pass` und `ticket.lint_pass` gespeichert - [ ] Bei Test-Failure: Fehlermeldung wird als Feedback an Claude übergeben (wie Review-Fix-Loop) - [ ] Max 2 Test-Fix-Runden bevor Ticket als "failed" markiert wird - [ ] Test-Coverage-Delta wird gemessen und gespeichert (falls Coverage-Tool konfiguriert) ### Post-Merge Monitoring - [ ] Nach Merge: AppSignal-Integration prüft ob Error-Rate für betroffene App sinkt - [ ] `ticket.post_deploy_status` trackt: "healthy" | "error" | "unknown" - [ ] Timeout von 24h für Post-Merge-Check (danach "unknown") - [ ] Dashboard zeigt Post-Merge-Status pro Ticket ### Confidence Scoring - [ ] Nach Claude-Run + Tests: `ticket.solution_confidence` (0-100) berechnen - [ ] Faktoren: Tests vorhanden? Tests bestanden? Lint bestanden? Diff-Größe? Review-Runden? - [ ] Confidence < 50: Review-Agent bekommt Warnung "Low confidence — genau prüfen" - [ ] Confidence > 90: Optionaler Fast-Track (weniger Review-Runden) - [ ] Stats-API zeigt Confidence-Verteilung ### Vereint bestehende Issues - Übernimmt #22 (Test-Ausführung nach Claude-Run) - Übernimmt #49 (Confidence-Scores) ## Technische Hinweise - Betroffene Dateien: - Neu: `backend/services/test_runner.py` (Test-Ausführung nach Claude-Run) - Neu: `backend/services/confidence_scorer.py` (Confidence-Berechnung) - Ändern: `backend/models/ticket.py` (+ tests_pass, lint_pass, solution_confidence, post_deploy_status) - Ändern: `backend/services/pipeline.py` (Test-Step nach Claude-Run einbauen, Confidence berechnen) - Ändern: `backend/services/review_agent.py` (Confidence in Review-Prompt einfließen lassen) - Ändern: `backend/services/appsignal_poller.py` (Post-Merge Error-Check) - Ändern: `backend/main.py` (Post-Merge-Check Scheduler-Job) - Ändern: `backend/api/pipeline.py` (Stats um Confidence + Post-Merge erweitern) - Ändern: `frontend/src/pages/TicketDetail.tsx` (Confidence + Post-Merge-Status anzeigen) - Ansatz: Pipeline-Erweiterung — nach Claude-Run kommt Test-Step, nach MR kommt Post-Merge-Check. Confidence-Score wird aus Test/Lint/Diff-Daten berechnet, nicht via LLM. - Migration nötig: Ja (neue Ticket-Felder) - **Abhängigkeit: #90 (MR-Outcome-Tracking) — liefert mr_outcome/mr_reviewed_at Daten** ## Aufwand: L
David commented 2026-03-30 20:42:37 +00:00
Author
Collaborator
Copy link

Issue aktualisiert:

  • MR-Outcome-Tracking Section entfernt — gehört jetzt zu #90 (MR-Outcome-Tracking & Scoring-Kalibrierung)
  • Abhängigkeit zu #90 hinzugefügt — Post-Merge Monitoring braucht MR-Outcome-Daten
  • #22 als vereint gelistet (Test-Ausführung nach Claude-Run)
  • mr_tracker.py und mr_merged_at entfernt (sind in #90)
Issue aktualisiert: - **MR-Outcome-Tracking Section entfernt** — gehört jetzt zu #90 (MR-Outcome-Tracking & Scoring-Kalibrierung) - **Abhängigkeit zu #90 hinzugefügt** — Post-Merge Monitoring braucht MR-Outcome-Daten - **#22 als vereint gelistet** (Test-Ausführung nach Claude-Run) - `mr_tracker.py` und `mr_merged_at` entfernt (sind in #90)
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
detached
feature/ui-redesign
No results found.
Labels
Clear labels   
api

API Endpoints betroffen

  
backend

Backend/Python betroffen

  
bug

Fehler/Bug

  
database

Datenbank/Migration betroffen

  
doku

Dokumentation nötig

  
feature

Neues Feature

  
frontend

Frontend/React betroffen

  
improvement

Verbesserung bestehender Funktion

  
in work

Issue wird gerade bearbeitet

  
kritisch

Höchste Priorität

  
L

Large: 1+ Tag, > 5 Dateien

  
M

Medium: halber Tag, 3-5 Dateien

  
niedrig

Niedrige Priorität

  
normal

Normale Priorität

  
review

In Review

  
S

Small: < 1h, 1-2 Dateien

  
service

Service/Pipeline betroffen

  
wichtig

Hohe Priorität

  
XL

Extra Large: mehrere Tage

No labels
api
backend
bug
database
doku
feature
frontend
improvement
in work
kritisch
L
M
niedrig
normal
review
S
service
wichtig
XL
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Basti/Bruno#88
No description provided.