refactor: Migrate to Git-based workflow (v1.4.0)
BREAKING CHANGE: Removed FEATURE_CHANGELOG.md and test-reports/ **What changed:** - All 6 agents now use Git commands to check existing features/components - Feature specs include test results and deployment status (no separate files) - Git commits are the single source of truth for implementation details - Git tags for deployment versioning (e.g., v1.0.0-PROJ-1) **Why:** - Prevents context bloat (no growing FEATURE_CHANGELOG.md) - Scales better (Git is built for large projects) - No manual changelog maintenance - Better developer experience (native Git workflow) **Migration:** - Requirements Engineer: Uses `ls features/` and `git ls-files` instead of FEATURE_CHANGELOG - Solution Architect: Uses `git ls-files src/components/` to check existing code - Frontend/Backend Devs: Use `git log --grep="PROJ-X"` to see feature history - QA Engineer: Adds test results directly to feature spec - DevOps: Updates feature spec with deployment status + creates Git tags **Files changed:** - Updated all 6 agent instructions (.claude/agents/*.md) - Deleted FEATURE_CHANGELOG.md - Deleted test-reports/ folder - Updated PROJECT_CONTEXT.md (removed references) - Updated README.md (v1.4.0, updated workflow) - Updated features/README.md (new format with QA + Deployment sections) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This commit is contained in:
“alexvisualmakers”
@@ -10,22 +10,28 @@ agent: general-purpose
|
||||
Du bist ein erfahrener Backend Developer. Du liest Feature Specs + Tech Design und implementierst APIs und Database Logic.
|
||||
|
||||
## Verantwortlichkeiten
|
||||
1. **FEATURE_CHANGELOG.md lesen** - Prüfe welche Tables/APIs bereits existieren
|
||||
1. **Bestehende Tables/APIs prüfen** - Code-Reuse vor Neuimplementierung!
|
||||
2. Database Migrations schreiben (Supabase SQL)
|
||||
3. Row Level Security Policies implementieren
|
||||
4. API Routes erstellen (Next.js Route Handlers)
|
||||
5. Server-Side Logic implementieren
|
||||
6. Authentication & Authorization
|
||||
|
||||
## ⚠️ WICHTIG: Lies zuerst FEATURE_CHANGELOG.md!
|
||||
## ⚠️ WICHTIG: Prüfe bestehende Tables/APIs!
|
||||
|
||||
**Vor der Implementation:**
|
||||
```
|
||||
Lies FEATURE_CHANGELOG.md um zu prüfen:
|
||||
- Welche Database Tables existieren bereits?
|
||||
- Welche Columns können wiederverwendet werden?
|
||||
- Gibt es bereits ähnliche API Endpoints?
|
||||
- Welche RLS Policies sind schon implementiert?
|
||||
```bash
|
||||
# 1. Welche API Endpoints existieren bereits?
|
||||
git ls-files src/app/api/
|
||||
|
||||
# 2. Letzte Backend-Implementierungen sehen
|
||||
git log --oneline --grep="feat.*api\|feat.*backend\|feat.*database" -10
|
||||
|
||||
# 3. Suche nach Database Migrations
|
||||
git log --all --oneline -S "CREATE TABLE" -S "ALTER TABLE"
|
||||
|
||||
# 4. Suche nach ähnlichen APIs
|
||||
git log --all --oneline -S "/api/endpoint-name"
|
||||
```
|
||||
|
||||
**Warum?** Verhindert redundante Tables/APIs und ermöglicht Schema-Erweiterung statt Neuerstellung.
|
||||
@@ -179,7 +185,7 @@ export async function POST(request: Request) {
|
||||
|
||||
Bevor du die Backend-Implementation als "fertig" markierst, stelle sicher:
|
||||
|
||||
- [ ] **FEATURE_CHANGELOG.md gelesen:** Bestehende Tables/APIs geprüft
|
||||
- [ ] **Bestehende Tables/APIs geprüft:** Via Git geprüft
|
||||
- [ ] **Database Migration:** SQL Migration ist in Supabase ausgeführt
|
||||
- [ ] **Tables erstellt:** Alle Tables existieren in Supabase Dashboard
|
||||
- [ ] **Row Level Security:** RLS ist für ALLE Tables aktiviert (`ENABLE ROW LEVEL SECURITY`)
|
||||
|
||||
+29
-43
@@ -15,7 +15,7 @@ Du bist ein erfahrener DevOps Engineer. Du kümmerst dich um Deployment, Environ
|
||||
3. Build-Errors beheben
|
||||
4. Monitoring & Logging einrichten
|
||||
5. Rollback bei Problemen
|
||||
6. **FEATURE_CHANGELOG.md updaten** nach jedem erfolgreichen Deployment
|
||||
6. **Git Commits mit Deployment-Info** erstellen (z.B. "deploy: PROJ-X to production")
|
||||
|
||||
## Workflow
|
||||
1. **Deployment vorbereiten:**
|
||||
@@ -180,58 +180,44 @@ Bevor du zu Production deployst, stelle sicher:
|
||||
- [ ] **Rollback-Plan ready:** Weiß wie man zu vorheriger Version zurückrollt
|
||||
- [ ] **Deployment dokumentiert:** Git Commit Message enthält Feature-Details
|
||||
- [ ] **PROJECT_CONTEXT.md updated:** Feature-Status auf ✅ Done gesetzt
|
||||
- [ ] **FEATURE_CHANGELOG.md updated:** Feature ist dokumentiert (Implementation Details, Files, Database Changes, APIs)
|
||||
- [ ] **Feature-Spec updated:** Status auf ✅ Deployed gesetzt in `/features/PROJ-X.md`
|
||||
- [ ] **Git Tag erstellt:** Version Tag für Deployment (z.B. `v1.0.0-PROJ-X`)
|
||||
|
||||
Erst wenn ALLE Checkboxen ✅ sind → Deployment ist erfolgreich abgeschlossen!
|
||||
|
||||
## ⚠️ WICHTIG: FEATURE_CHANGELOG.md updaten!
|
||||
## ⚠️ WICHTIG: Git als Single Source of Truth!
|
||||
|
||||
**Nach jedem erfolgreichen Deployment:**
|
||||
|
||||
1. Öffne `FEATURE_CHANGELOG.md`
|
||||
2. Füge einen neuen Eintrag hinzu (am Anfang der Datei, chronologisch):
|
||||
|
||||
```markdown
|
||||
## [PROJ-X] Feature-Name (2026-XX-XX)
|
||||
|
||||
### Implementiert ✅
|
||||
- **Status:** Done
|
||||
- **Feature Spec:** `/features/PROJ-X-feature-name.md`
|
||||
- **Implementiert von:** Frontend Dev + Backend Dev
|
||||
- **Getestet von:** QA Engineer
|
||||
- **Deployed:** 2026-XX-XX
|
||||
|
||||
### Was wurde gebaut?
|
||||
[1-2 Sätze Beschreibung des Features]
|
||||
|
||||
### Neue Files
|
||||
- `src/components/NewComponent.tsx` - [Beschreibung]
|
||||
- `src/app/api/new-endpoint/route.ts` - [Beschreibung]
|
||||
|
||||
### Database Changes
|
||||
```sql
|
||||
CREATE TABLE new_table (...);
|
||||
ALTER TABLE existing_table ADD COLUMN new_column ...;
|
||||
```
|
||||
|
||||
### API Endpoints
|
||||
- `GET /api/new-endpoint` - [Beschreibung]
|
||||
- `POST /api/new-endpoint` - [Beschreibung]
|
||||
|
||||
### Abhängigkeiten
|
||||
- Baut auf: [PROJ-1], [PROJ-2] (falls zutreffend)
|
||||
- Wird genutzt von: [wird später ergänzt wenn andere Features darauf aufbauen]
|
||||
```
|
||||
|
||||
3. Speichere die Datei
|
||||
4. **Commit + Push:**
|
||||
1. **Feature Spec updaten:**
|
||||
```bash
|
||||
git add FEATURE_CHANGELOG.md
|
||||
git commit -m "docs: Update FEATURE_CHANGELOG for PROJ-X"
|
||||
# Öffne /features/PROJ-X.md und setze Status:
|
||||
Status: ✅ Deployed (2026-XX-XX)
|
||||
Production URL: https://your-app.vercel.app
|
||||
```
|
||||
|
||||
2. **Git Tag erstellen (optional aber empfohlen):**
|
||||
```bash
|
||||
git tag -a v1.0.0-PROJ-X -m "Deploy PROJ-X: Feature Name to production"
|
||||
git push origin v1.0.0-PROJ-X
|
||||
```
|
||||
|
||||
3. **Deployment Commit:**
|
||||
```bash
|
||||
git add features/PROJ-X.md
|
||||
git commit -m "deploy(PROJ-X): Deploy Feature Name to production
|
||||
|
||||
- Production URL: https://your-app.vercel.app
|
||||
- Deployed: 2026-XX-XX
|
||||
- Status: ✅ All tests passed
|
||||
"
|
||||
git push
|
||||
```
|
||||
|
||||
**Warum?** Zukünftige Features können sehen, was bereits existiert und darauf aufbauen!
|
||||
**Warum Git Tags?**
|
||||
- Schnelles Rollback: `git checkout v1.0.0-PROJ-2`
|
||||
- Deployment History: `git tag -l`
|
||||
- Einfache Versionierung
|
||||
|
||||
## Rollback Instructions (for emergencies)
|
||||
|
||||
|
||||
@@ -10,22 +10,29 @@ agent: general-purpose
|
||||
Du bist ein erfahrener Frontend Developer. Du liest Feature Specs + Tech Design und implementierst die UI.
|
||||
|
||||
## Verantwortlichkeiten
|
||||
1. **FEATURE_CHANGELOG.md lesen** - Prüfe welche Components bereits existieren (Code-Reuse!)
|
||||
1. **Bestehende Components prüfen** - Code-Reuse vor Neuimplementierung!
|
||||
2. React Components bauen
|
||||
3. Tailwind CSS für Styling nutzen
|
||||
4. shadcn/ui Components integrieren
|
||||
5. Responsive Design sicherstellen
|
||||
6. Accessibility implementieren
|
||||
|
||||
## ⚠️ WICHTIG: Lies zuerst FEATURE_CHANGELOG.md!
|
||||
## ⚠️ WICHTIG: Prüfe bestehende Components!
|
||||
|
||||
**Vor der Implementation:**
|
||||
```
|
||||
Lies FEATURE_CHANGELOG.md um zu prüfen:
|
||||
- Existieren bereits ähnliche Components? (z.B. Button, Card, Form)
|
||||
- Welche Styling-Patterns wurden bereits verwendet?
|
||||
- Gibt es wiederverwendbare Hooks? (useAuth, useFetch, etc.)
|
||||
- Welche Utility-Functions existieren schon?
|
||||
```bash
|
||||
# 1. Welche Components existieren bereits?
|
||||
git ls-files src/components/
|
||||
|
||||
# 2. Welche Hooks/Utils existieren?
|
||||
git ls-files src/hooks/
|
||||
git ls-files src/lib/
|
||||
|
||||
# 3. Letzte Frontend-Implementierungen sehen
|
||||
git log --oneline --grep="feat.*component\|feat.*frontend" -10
|
||||
|
||||
# 4. Suche nach ähnlichen Implementierungen
|
||||
git log --all --oneline -S "ComponentName"
|
||||
```
|
||||
|
||||
**Warum?** Verhindert Duplicate Code und sorgt für konsistentes Design.
|
||||
@@ -112,7 +119,7 @@ export function ProjectCard({ id, title, taskCount, onDelete }: ProjectCardProps
|
||||
|
||||
Bevor du die Frontend-Implementation als "fertig" markierst, stelle sicher:
|
||||
|
||||
- [ ] **FEATURE_CHANGELOG.md gelesen:** Bestehende Components/Hooks geprüft
|
||||
- [ ] **Bestehende Components geprüft:** Via Git Components/Hooks geprüft
|
||||
- [ ] **Design gelesen:** Component Architecture vom Solution Architect verstanden
|
||||
- [ ] **Components erstellt:** Alle geplanten Components sind implementiert
|
||||
- [ ] **Tailwind Styling:** Alle Components nutzen Tailwind CSS (kein inline-style)
|
||||
|
||||
@@ -10,22 +10,28 @@ agent: general-purpose
|
||||
Du bist ein erfahrener QA Engineer. Du testest Features gegen die definierten Acceptance Criteria und identifizierst Bugs.
|
||||
|
||||
## Verantwortlichkeiten
|
||||
1. **FEATURE_CHANGELOG.md lesen** - Prüfe welche Features bereits existieren (für Regression Tests!)
|
||||
1. **Bestehende Features prüfen** - Für Regression Tests!
|
||||
2. Features gegen Acceptance Criteria testen
|
||||
3. Edge Cases testen
|
||||
4. Bugs dokumentieren
|
||||
5. Regression Tests durchführen
|
||||
6. Test-Reports erstellen
|
||||
6. Test-Ergebnisse im Feature-Dokument dokumentieren
|
||||
|
||||
## ⚠️ WICHTIG: Lies zuerst FEATURE_CHANGELOG.md!
|
||||
## ⚠️ WICHTIG: Prüfe bestehende Features!
|
||||
|
||||
**Vor dem Testing:**
|
||||
```
|
||||
Lies FEATURE_CHANGELOG.md um zu prüfen:
|
||||
- Welche Features sind bereits implemented?
|
||||
- Gibt es Abhängigkeiten zu anderen Features?
|
||||
- Welche bestehenden Features könnten betroffen sein? (Regression!)
|
||||
- Wurden kürzlich Bugs in ähnlichen Features gefixt?
|
||||
```bash
|
||||
# 1. Welche Features sind bereits implemented?
|
||||
ls features/ | grep "PROJ-"
|
||||
|
||||
# 2. Letzte Implementierungen sehen (für Regression Tests)
|
||||
git log --oneline --grep="PROJ-" -10
|
||||
|
||||
# 3. Letzte Bug-Fixes sehen
|
||||
git log --oneline --grep="fix" -10
|
||||
|
||||
# 4. Welche Files wurden zuletzt geändert?
|
||||
git log --name-only -10 --format=""
|
||||
```
|
||||
|
||||
**Warum?** Verhindert, dass neue Features alte Features kaputt machen (Regression Testing).
|
||||
@@ -45,30 +51,31 @@ Lies FEATURE_CHANGELOG.md um zu prüfen:
|
||||
- Erstelle Bug-Report (was, wo, wie reproduzieren)
|
||||
- Priorität setzen (Critical, High, Medium, Low)
|
||||
|
||||
4. **Test-Report speichern:**
|
||||
- Speichere Report in `/test-reports/PROJ-X-feature-name.md`
|
||||
- Format: `/test-reports/PROJ-1-simple-todo-kanban.md`
|
||||
4. **Test-Ergebnisse dokumentieren:**
|
||||
- Update Feature Spec in `/features/PROJ-X.md` mit Test-Ergebnissen
|
||||
- Füge QA-Section ans Ende des Feature-Dokuments hinzu
|
||||
|
||||
5. **User Review:**
|
||||
- Zeige Test-Report
|
||||
- Zeige Test-Ergebnisse
|
||||
- Frage: "Welche Bugs sollen zuerst gefixt werden?"
|
||||
|
||||
## Output-Format
|
||||
|
||||
### Test Report Location
|
||||
**Speichere Test-Reports in:** `/test-reports/PROJ-X-feature-name.md`
|
||||
### Test Results Location
|
||||
**Dokumentiere Test-Ergebnisse in:** `/features/PROJ-X.md` (am Ende des Feature-Dokuments)
|
||||
|
||||
**Beispiele:**
|
||||
- `/test-reports/PROJ-1-simple-todo-kanban.md`
|
||||
- `/test-reports/PROJ-2-user-authentication.md`
|
||||
**Kein separater test-reports/ Ordner mehr!** Alles bleibt im Feature-Dokument für bessere Übersicht.
|
||||
|
||||
### Test Report Template
|
||||
```markdown
|
||||
# Test Report: PROJ-X Feature-Name
|
||||
Füge diese Section ans Ende von `/features/PROJ-X.md`:
|
||||
|
||||
## Tested: 2024-01-10
|
||||
## Tester: QA Engineer Agent
|
||||
## App URL: http://localhost:3000
|
||||
```markdown
|
||||
---
|
||||
|
||||
## QA Test Results
|
||||
|
||||
**Tested:** 2026-01-12
|
||||
**App URL:** http://localhost:3000
|
||||
|
||||
## Acceptance Criteria Status
|
||||
|
||||
@@ -157,7 +164,7 @@ Fix BUG-1 und BUG-2 vor Deployment.
|
||||
|
||||
Bevor du den Test-Report als "fertig" markierst, stelle sicher:
|
||||
|
||||
- [ ] **FEATURE_CHANGELOG.md gelesen:** Bestehende Features für Regression Tests geprüft
|
||||
- [ ] **Bestehende Features geprüft:** Via Git für Regression Tests geprüft
|
||||
- [ ] **Feature Spec gelesen:** `/features/PROJ-X.md` vollständig verstanden
|
||||
- [ ] **Alle Acceptance Criteria getestet:** Jedes AC hat Status (✅ oder ❌)
|
||||
- [ ] **Alle Edge Cases getestet:** Jeder Edge Case wurde durchgespielt
|
||||
@@ -166,7 +173,7 @@ Bevor du den Test-Report als "fertig" markierst, stelle sicher:
|
||||
- [ ] **Bugs dokumentiert:** Jeder Bug hat Severity, Steps to Reproduce, Priority
|
||||
- [ ] **Screenshots/Videos:** Bei visuellen Bugs Screenshots hinzugefügt
|
||||
- [ ] **Test-Report geschrieben:** Vollständiger Report mit Summary
|
||||
- [ ] **Test-Report gespeichert:** Report ist in `/test-reports/PROJ-X-feature-name.md`
|
||||
- [ ] **Test-Ergebnisse dokumentiert:** QA-Section zu `/features/PROJ-X.md` hinzugefügt
|
||||
- [ ] **Regression Test:** Alte Features funktionieren noch (nichts kaputt gemacht)
|
||||
- [ ] **Performance Check:** App reagiert flüssig (keine langen Ladezeiten)
|
||||
- [ ] **Security Check (Basic):** Keine offensichtlichen Security-Issues
|
||||
|
||||
@@ -10,26 +10,32 @@ agent: general-purpose
|
||||
Du bist ein erfahrener Requirements Engineer. Deine Aufgabe ist es, Feature-Ideen in strukturierte Specifications zu verwandeln.
|
||||
|
||||
## Verantwortlichkeiten
|
||||
1. **FEATURE_CHANGELOG.md lesen** - Prüfe welche Features bereits existieren
|
||||
1. **Bestehende Features prüfen** - Welche Feature-IDs sind vergeben?
|
||||
2. User-Intent verstehen (Fragen stellen!)
|
||||
3. User Stories schreiben
|
||||
4. Acceptance Criteria definieren
|
||||
5. Edge Cases identifizieren
|
||||
6. Feature Spec in /features/PROJ-X.md speichern
|
||||
|
||||
## ⚠️ WICHTIG: Lies zuerst FEATURE_CHANGELOG.md!
|
||||
## ⚠️ WICHTIG: Prüfe bestehende Features!
|
||||
|
||||
**Vor jeder Feature Spec:**
|
||||
```
|
||||
Lies FEATURE_CHANGELOG.md um zu prüfen:
|
||||
- Existiert ein ähnliches Feature bereits?
|
||||
- Auf welchen bestehenden Features können wir aufbauen?
|
||||
- Welche Feature-IDs sind bereits vergeben?
|
||||
- Welche Components/APIs existieren schon?
|
||||
```bash
|
||||
# 1. Welche Features existieren bereits?
|
||||
ls features/ | grep "PROJ-"
|
||||
|
||||
# 2. Welche Components/APIs existieren schon?
|
||||
git ls-files src/components/
|
||||
git ls-files src/app/api/
|
||||
|
||||
# 3. Letzte Feature-Entwicklungen sehen
|
||||
git log --oneline --grep="PROJ-" -10
|
||||
```
|
||||
|
||||
**Warum?** Verhindert Duplikate und ermöglicht Wiederverwendung bestehender Lösungen.
|
||||
|
||||
**Neue Feature-ID vergeben:** Nächste freie Nummer verwenden (z.B. PROJ-3, PROJ-4, etc.)
|
||||
|
||||
## Workflow
|
||||
|
||||
### Phase 1: Feature verstehen (mit AskUserQuestion)
|
||||
@@ -186,6 +192,14 @@ Bevor du die Feature Spec als "fertig" markierst, stelle sicher:
|
||||
- [ ] **File gespeichert:** `/features/PROJ-X-feature-name.md` existiert
|
||||
- [ ] **Status gesetzt:** Status ist 🔵 Planned
|
||||
- [ ] **User Review:** User hat Spec gelesen und approved
|
||||
- [ ] **PROJECT_CONTEXT.md updated:** Feature ist in Roadmap eingetragen
|
||||
|
||||
Erst wenn ALLE Checkboxen ✅ sind → Feature Spec ist ready für Solution Architect!
|
||||
|
||||
## Git Workflow
|
||||
|
||||
Keine manuelle Changelog-Pflege nötig! Git Commits sind die Single Source of Truth.
|
||||
|
||||
**Commit Message Format:**
|
||||
```bash
|
||||
git commit -m "feat(PROJ-X): Add feature specification for [feature name]"
|
||||
```
|
||||
|
||||
@@ -19,21 +19,27 @@ Du bist ein Solution Architect für Produktmanager ohne tiefes technisches Wisse
|
||||
Die technische Umsetzung macht der Frontend/Backend Developer!
|
||||
|
||||
## Verantwortlichkeiten
|
||||
1. **FEATURE_CHANGELOG.md lesen** - Prüfe welche Components/APIs/Database Tables bereits existieren
|
||||
1. **Bestehende Architektur prüfen** - Welche Components/APIs/Tables existieren?
|
||||
2. **Component-Struktur** visualisieren (welche UI-Teile brauchen wir?)
|
||||
3. **Daten-Model** beschreiben (welche Informationen speichern wir?)
|
||||
4. **Tech-Entscheidungen** erklären (warum diese Library/Tool?)
|
||||
5. **Handoff** an Frontend Developer orchestrieren
|
||||
|
||||
## ⚠️ WICHTIG: Lies zuerst FEATURE_CHANGELOG.md!
|
||||
## ⚠️ WICHTIG: Prüfe bestehende Architektur!
|
||||
|
||||
**Vor dem Design:**
|
||||
```
|
||||
Lies FEATURE_CHANGELOG.md um zu prüfen:
|
||||
- Existieren bereits ähnliche Components? (Code-Reuse!)
|
||||
- Welche Database Tables/Columns gibt es schon?
|
||||
- Welche API Endpoints existieren bereits?
|
||||
- Auf welchen Features können wir aufbauen?
|
||||
```bash
|
||||
# 1. Welche Components existieren bereits?
|
||||
git ls-files src/components/
|
||||
|
||||
# 2. Welche API Endpoints existieren?
|
||||
git ls-files src/app/api/
|
||||
|
||||
# 3. Welche Features wurden bereits implementiert?
|
||||
git log --oneline --grep="PROJ-" -10
|
||||
|
||||
# 4. Suche nach ähnlichen Implementierungen
|
||||
git log --all --oneline --grep="keyword"
|
||||
```
|
||||
|
||||
**Warum?** Verhindert redundantes Design und ermöglicht Wiederverwendung bestehender Infrastruktur.
|
||||
@@ -180,7 +186,7 @@ const useProjects = () => {
|
||||
|
||||
Bevor du das Design als "fertig" markierst:
|
||||
|
||||
- [ ] **FEATURE_CHANGELOG.md gelesen:** Bestehende Components/APIs/Tables geprüft
|
||||
- [ ] **Bestehende Architektur geprüft:** Components/APIs/Tables via Git geprüft
|
||||
- [ ] **Feature Spec gelesen:** `/features/PROJ-X.md` vollständig verstanden
|
||||
- [ ] **Component-Struktur dokumentiert:** Visual Tree erstellt (PM-verständlich)
|
||||
- [ ] **Daten-Model beschrieben:** Welche Infos werden gespeichert? (kein Code!)
|
||||
|
||||
@@ -1,207 +0,0 @@
|
||||
# Feature Changelog
|
||||
|
||||
Dieses File trackt alle implementierten Features chronologisch.
|
||||
|
||||
**Warum?** Agents können hier nachschauen, welche Features bereits existieren, um Duplikate zu vermeiden und auf bestehendem Code aufzubauen.
|
||||
|
||||
---
|
||||
|
||||
## Template Initialisiert (2026-01-10)
|
||||
|
||||
### Basis-Setup ✅
|
||||
- **Status:** Done
|
||||
- **Beschreibung:** Next.js 16 Projekt mit TypeScript, Tailwind CSS, und AI Agent System
|
||||
- **Files:**
|
||||
- `src/app/layout.tsx` - Root Layout
|
||||
- `src/app/page.tsx` - Starter Page
|
||||
- `src/app/globals.css` - Global Styles
|
||||
- `src/lib/utils.ts` - Utility Functions
|
||||
- `src/lib/supabase.ts` - Supabase Client (kommentiert, nicht aktiv)
|
||||
|
||||
### Features Ready to Use
|
||||
- ✅ Responsive Starter Page mit Dark Mode
|
||||
- ✅ Tailwind CSS Konfiguration
|
||||
- ✅ TypeScript strict mode
|
||||
- ✅ ESLint
|
||||
- ✅ shadcn/ui ready (components.json vorhanden)
|
||||
|
||||
---
|
||||
|
||||
## Format für neue Einträge
|
||||
|
||||
Wenn ein neues Feature implementiert wird, trage es hier ein:
|
||||
|
||||
```markdown
|
||||
## [PROJ-X] Feature-Name (Datum)
|
||||
|
||||
### Implementiert ✅
|
||||
- **Status:** Done
|
||||
- **Feature Spec:** `/features/PROJ-X-feature-name.md`
|
||||
- **Implementiert von:** Frontend Dev + Backend Dev
|
||||
- **Getestet von:** QA Engineer
|
||||
- **Deployed:** 2026-XX-XX
|
||||
|
||||
### Was wurde gebaut?
|
||||
[1-2 Sätze Beschreibung]
|
||||
|
||||
### Neue Files
|
||||
- `src/components/FeatureComponent.tsx` - [Beschreibung]
|
||||
- `src/app/api/feature/route.ts` - [Beschreibung]
|
||||
|
||||
### Geänderte Files
|
||||
- `src/app/page.tsx` - [Was geändert]
|
||||
- `PROJECT_CONTEXT.md` - Feature Status updated
|
||||
|
||||
### Database Changes
|
||||
```sql
|
||||
-- Neue Tables / Columns
|
||||
CREATE TABLE new_table (...);
|
||||
```
|
||||
|
||||
### API Endpoints
|
||||
- `GET /api/feature` - [Beschreibung]
|
||||
- `POST /api/feature` - [Beschreibung]
|
||||
|
||||
### Abhängigkeiten
|
||||
- Baut auf: [PROJ-1], [PROJ-2]
|
||||
- Wird genutzt von: [PROJ-5]
|
||||
|
||||
### Bekannte Limitationen
|
||||
- [Optional: Was funktioniert noch nicht / ist out of scope]
|
||||
|
||||
---
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Beispiel-Eintrag
|
||||
|
||||
## [PROJ-1] User-Authentifizierung (2026-01-15)
|
||||
|
||||
### Implementiert ✅
|
||||
- **Status:** Done
|
||||
- **Feature Spec:** `/features/PROJ-1-user-authentication.md`
|
||||
- **Implementiert von:** Frontend Dev + Backend Dev
|
||||
- **Getestet von:** QA Engineer
|
||||
- **Deployed:** 2026-01-15
|
||||
|
||||
### Was wurde gebaut?
|
||||
User können sich mit Email + Passwort oder Google OAuth registrieren und einloggen. Session bleibt nach Reload erhalten.
|
||||
|
||||
### Neue Files
|
||||
- `src/components/auth/LoginForm.tsx` - Login Form Component
|
||||
- `src/components/auth/SignupForm.tsx` - Signup Form Component
|
||||
- `src/components/auth/PasswordResetForm.tsx` - Password Reset Component
|
||||
- `src/app/auth/login/page.tsx` - Login Page
|
||||
- `src/app/auth/signup/page.tsx` - Signup Page
|
||||
- `src/app/api/auth/login/route.ts` - Login API
|
||||
- `src/app/api/auth/signup/route.ts` - Signup API
|
||||
|
||||
### Geänderte Files
|
||||
- `src/lib/supabase.ts` - Aktiviert (uncommented)
|
||||
- `src/app/layout.tsx` - Auth Provider hinzugefügt
|
||||
- `PROJECT_CONTEXT.md` - PROJ-1 Status: ✅ Done
|
||||
|
||||
### Database Changes
|
||||
```sql
|
||||
-- Managed by Supabase Auth
|
||||
-- Keine Custom Tables (nutzt auth.users)
|
||||
```
|
||||
|
||||
### API Endpoints
|
||||
- `POST /api/auth/login` - Email + Password Login
|
||||
- `POST /api/auth/signup` - Email + Password Signup
|
||||
- `POST /api/auth/reset-password` - Password Reset Request
|
||||
- `GET /api/auth/callback` - OAuth Callback (Google)
|
||||
|
||||
### Abhängigkeiten
|
||||
- Supabase Auth aktiviert
|
||||
- Environment Variables: `NEXT_PUBLIC_SUPABASE_URL`, `NEXT_PUBLIC_SUPABASE_ANON_KEY`
|
||||
|
||||
### Bekannte Limitationen
|
||||
- Email-Verifizierung noch nicht implementiert (kommt in PROJ-7)
|
||||
- 2FA noch nicht implementiert (geplant für später)
|
||||
|
||||
---
|
||||
|
||||
## Wie Agents dieses File nutzen
|
||||
|
||||
### Requirements Engineer
|
||||
**Vor Feature Spec Erstellung:**
|
||||
```
|
||||
Lies FEATURE_CHANGELOG.md um zu prüfen:
|
||||
- Existiert ein ähnliches Feature bereits?
|
||||
- Auf welchen bestehenden Features können wir aufbauen?
|
||||
- Welche Feature-IDs sind bereits vergeben?
|
||||
```
|
||||
|
||||
### Solution Architect
|
||||
**Vor Tech-Design:**
|
||||
```
|
||||
Lies FEATURE_CHANGELOG.md um zu verstehen:
|
||||
- Welche Database Tables existieren bereits?
|
||||
- Welche API Endpoints sind schon implementiert?
|
||||
- Welche Components können wiederverwendet werden?
|
||||
```
|
||||
|
||||
### Frontend/Backend Devs
|
||||
**Vor Implementation:**
|
||||
```
|
||||
Lies FEATURE_CHANGELOG.md um zu sehen:
|
||||
- Welche Components/APIs existieren bereits?
|
||||
- Welche Patterns wurden bisher genutzt?
|
||||
- Wo finde ich ähnlichen Code (zum Referenzieren)?
|
||||
```
|
||||
|
||||
### QA Engineer
|
||||
**Vor Testing:**
|
||||
```
|
||||
Lies FEATURE_CHANGELOG.md um zu prüfen:
|
||||
- Welche Features hängen zusammen? (Regression Testing)
|
||||
- Welche bekannten Limitationen gibt es?
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
### 1. Immer updaten nach Feature-Completion
|
||||
DevOps Agent sollte FEATURE_CHANGELOG.md nach jedem Deployment updaten.
|
||||
|
||||
### 2. Chronologische Reihenfolge
|
||||
Neueste Features oben (nach diesem Template-Eintrag).
|
||||
|
||||
### 3. Links zu Feature Specs
|
||||
Immer Link zu `/features/PROJ-X.md` für Details.
|
||||
|
||||
### 4. Database Changes dokumentieren
|
||||
Agents können so schnell sehen, welche Tables/Columns existieren ohne in Supabase nachzuschauen.
|
||||
|
||||
### 5. Abhängigkeiten tracken
|
||||
Hilft beim Refactoring ("Wenn ich PROJ-2 ändere, welche Features sind betroffen?")
|
||||
|
||||
---
|
||||
|
||||
## Integration in Agent Workflows
|
||||
|
||||
### DevOps Agent Checklist Update
|
||||
|
||||
Nach erfolgreichem Deployment:
|
||||
|
||||
```markdown
|
||||
## Checklist vor Abschluss
|
||||
|
||||
...
|
||||
|
||||
### Post-Deployment Checks
|
||||
- [ ] User tested Production
|
||||
- [ ] Monitoring setup
|
||||
- [ ] Rollback-Plan ready
|
||||
- [ ] Deployment dokumentiert
|
||||
- [ ] PROJECT_CONTEXT.md updated (Status: ✅ Done)
|
||||
- [ ] **FEATURE_CHANGELOG.md updated** ← NEU!
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**Zuletzt aktualisiert:** 2026-01-10
|
||||
+4
-6
@@ -139,8 +139,6 @@ ai-coding-starter-kit/
|
||||
│ └── agents/ ← 6 AI Agents (Requirements, Architect, Frontend, Backend, QA, DevOps)
|
||||
├── features/ ← Feature Specs (Requirements Engineer creates these)
|
||||
│ └── README.md ← Documentation on how to write feature specs
|
||||
├── test-reports/ ← QA Test Reports (QA Engineer creates these)
|
||||
│ └── README.md ← Documentation on test report format
|
||||
├── src/
|
||||
│ ├── app/ ← Pages (Next.js App Router)
|
||||
│ ├── components/ ← React Components
|
||||
@@ -150,7 +148,6 @@ ai-coding-starter-kit/
|
||||
│ └── utils.ts ← Helper functions
|
||||
├── public/ ← Static files
|
||||
├── PROJECT_CONTEXT.md ← This file - update as project grows
|
||||
├── FEATURE_CHANGELOG.md ← Tracks all implemented features
|
||||
└── package.json
|
||||
```
|
||||
|
||||
@@ -193,9 +190,10 @@ ai-coding-starter-kit/
|
||||
- Requirements → Architecture → Development → QA → Deployment
|
||||
- Each agent knows when to hand off to the next agent
|
||||
|
||||
4. **Update documentation as you go**
|
||||
- `PROJECT_CONTEXT.md` - Add features to roadmap, mark them as done
|
||||
- `FEATURE_CHANGELOG.md` - Automatically updated after deployment
|
||||
4. **Track progress via Git**
|
||||
- Feature specs in `/features/PROJ-X.md` show status (Planned → In Progress → Deployed)
|
||||
- Git commits track all implementation details
|
||||
- Use `git log --grep="PROJ-X"` to see feature history
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -71,9 +71,7 @@ Hey Claude, read .claude/agents/requirements-engineer.md and create a feature sp
|
||||
ai-coding-starter-kit/
|
||||
├── .claude/
|
||||
│ └── agents/ ← 6 AI Agents (Production-Ready)
|
||||
├── features/ ← Feature Specs (Requirements Engineer creates these)
|
||||
│ └── README.md
|
||||
├── test-reports/ ← QA Test Reports (QA Engineer creates these)
|
||||
├── features/ ← Feature Specs (includes specs, test results, deployment status)
|
||||
│ └── README.md
|
||||
├── src/
|
||||
│ ├── app/ ← Pages (Next.js App Router)
|
||||
@@ -87,7 +85,6 @@ ai-coding-starter-kit/
|
||||
│ └── utils.ts
|
||||
├── public/ ← Static files
|
||||
├── PROJECT_CONTEXT.md ← Project Documentation (fill this out!)
|
||||
├── FEATURE_CHANGELOG.md ← Feature Tracking (updated after deployment)
|
||||
├── TEMPLATE_CHANGELOG.md ← Template Version History (v1.0 - v1.3)
|
||||
├── HOW_TO_USE_AGENTS.md ← Agent Usage Guide
|
||||
├── .env.local.example ← Environment Variables Template
|
||||
@@ -152,7 +149,7 @@ Agent designs PM-friendly Tech Design (no code!) → You review
|
||||
"Read .claude/agents/qa-engineer.md and test /features/PROJ-1-feature.md"
|
||||
```
|
||||
|
||||
Agent tests all Acceptance Criteria → Creates Test Report in `/test-reports/`
|
||||
Agent tests all Acceptance Criteria → Adds test results to feature spec
|
||||
|
||||
### 5. Deployment Phase
|
||||
```bash
|
||||
@@ -245,7 +242,7 @@ Agent guides you through deployment + Production-Ready setup (Error Tracking, Se
|
||||
|
||||
### For Small Teams (2-5 people)
|
||||
- **Consistent workflow** – Everyone follows the same agent system
|
||||
- **Code reuse** – FEATURE_CHANGELOG prevents duplicate code
|
||||
- **Code reuse** – Git history shows what exists, prevents duplication
|
||||
- **Knowledge sharing** – All decisions documented in Feature Specs
|
||||
|
||||
---
|
||||
@@ -255,8 +252,8 @@ Agent guides you through deployment + Production-Ready setup (Error Tracking, Se
|
||||
### Template Docs
|
||||
- [HOW_TO_USE_AGENTS.md](HOW_TO_USE_AGENTS.md) – Agent usage guide
|
||||
- [PROJECT_CONTEXT.md](PROJECT_CONTEXT.md) – Project documentation template
|
||||
- [FEATURE_CHANGELOG.md](FEATURE_CHANGELOG.md) – Feature tracking system
|
||||
- [TEMPLATE_CHANGELOG.md](TEMPLATE_CHANGELOG.md) – Template version history
|
||||
- [features/README.md](features/README.md) – Feature spec format
|
||||
|
||||
### External Docs
|
||||
- [Next.js Docs](https://nextjs.org/docs)
|
||||
@@ -279,14 +276,15 @@ npm run lint # Run ESLint
|
||||
|
||||
## Template Versions
|
||||
|
||||
**Current:** v1.3.0 (Production-Ready Essentials)
|
||||
**Current:** v1.4.0 (Git-Based Workflow)
|
||||
|
||||
See [TEMPLATE_CHANGELOG.md](TEMPLATE_CHANGELOG.md) for full version history.
|
||||
|
||||
**Updates:**
|
||||
- v1.4.0 – Git-Based Workflow (removed FEATURE_CHANGELOG, test-reports)
|
||||
- v1.3.0 – Production-Ready Guides (Error Tracking, Security, Performance)
|
||||
- v1.2.0 – FEATURE_CHANGELOG System (Code Reuse)
|
||||
- v1.1.0 – Agent System Improvements (Interactive Questions, PM-Friendly Output)
|
||||
- v1.2.0 – Agent System Improvements (Interactive Questions, PM-Friendly Output)
|
||||
- v1.1.0 – Enhanced Documentation
|
||||
- v1.0.0 – Initial Release
|
||||
|
||||
---
|
||||
|
||||
@@ -6,6 +6,157 @@
|
||||
|
||||
---
|
||||
|
||||
## v1.3.0 - Production-Ready Essentials (2026-01-12)
|
||||
|
||||
### ✅ Changes
|
||||
|
||||
#### 1. Production Guides Added to DevOps Agent
|
||||
|
||||
**New Sections in `.claude/agents/devops.md`:**
|
||||
|
||||
1. **Error Tracking Setup (Sentry)**
|
||||
- 5-minute setup guide with code examples
|
||||
- Environment variables configuration
|
||||
- Alternative: Vercel Error Tracking
|
||||
|
||||
2. **Security Headers (Next.js Config)**
|
||||
- Copy-paste `next.config.js` with security headers
|
||||
- XSS, Clickjacking, MIME-Sniffing protection
|
||||
- HSTS (Strict-Transport-Security)
|
||||
|
||||
3. **Environment Variables Best Practices**
|
||||
- ✅ DO / ❌ DON'T guidelines
|
||||
- `NEXT_PUBLIC_` prefix explanation
|
||||
- Production vs Preview vs Development environments
|
||||
|
||||
4. **Performance Monitoring (Lighthouse)**
|
||||
- Quick check with Chrome DevTools
|
||||
- Common performance killers + fixes
|
||||
- Image optimization with `next/image`
|
||||
|
||||
5. **Production-Ready Checklist**
|
||||
- One-time checks for first deployment
|
||||
- Error Tracking, Security Headers, Performance, SEO, Favicon
|
||||
|
||||
**Benefits:**
|
||||
- ✅ Production-ready in 15 minutes (not days!)
|
||||
- ✅ All guides practical with copy-paste code
|
||||
- ✅ No theory – only actionable steps
|
||||
|
||||
---
|
||||
|
||||
#### 2. Performance & Scalability Guides in Backend Agent
|
||||
|
||||
**New Sections in `.claude/agents/backend-dev.md`:**
|
||||
|
||||
1. **Database Indexing**
|
||||
- When to create indexes (WHERE, ORDER BY, JOIN)
|
||||
- Example: 500ms → <10ms query optimization
|
||||
- Supabase-specific instructions
|
||||
|
||||
2. **Query Performance Optimization**
|
||||
- N+1 Query Problem (Bad vs Good examples)
|
||||
- Supabase joins for efficient queries
|
||||
- Always use `.limit()` for lists
|
||||
|
||||
3. **Caching Strategy**
|
||||
- When to cache (settings, profiles, expensive queries)
|
||||
- Next.js `unstable_cache` examples
|
||||
- Optional: Redis for advanced caching
|
||||
|
||||
4. **Input Validation & Sanitization**
|
||||
- Zod schemas for type-safe validation
|
||||
- Example: Bad vs Good validation
|
||||
- Security: Never trust user input!
|
||||
|
||||
5. **Rate Limiting**
|
||||
- Prevent abuse and DDoS attacks
|
||||
- Upstash Redis example (optional)
|
||||
- Alternative: Vercel Edge Config
|
||||
|
||||
**Quick Reference Checklist:**
|
||||
- Indexing (PFLICHT!)
|
||||
- Query optimization, Input validation, Caching, Rate Limiting (optional but recommended)
|
||||
|
||||
---
|
||||
|
||||
#### 3. Test Reports Directory Added
|
||||
|
||||
**New Directory:** `/test-reports/`
|
||||
|
||||
- QA Engineer now saves test reports here
|
||||
- Naming: `PROJ-X-feature-name.md`
|
||||
- Complete `test-reports/README.md` with:
|
||||
- Report structure guidelines
|
||||
- Production-Ready criteria
|
||||
- Regression testing workflow
|
||||
- Tools (Browser DevTools, Lighthouse, axe DevTools)
|
||||
|
||||
**Updated QA Agent:**
|
||||
- Checklist item: "Test-Report gespeichert in `/test-reports/PROJ-X-feature-name.md`"
|
||||
- Workflow includes saving reports
|
||||
|
||||
---
|
||||
|
||||
#### 4. Template Branding & Clarity
|
||||
|
||||
**README.md:**
|
||||
- Template renamed: "AI Coding Starter Kit" (from "Next.js Agent Starter")
|
||||
- Professional headline: "Build scalable, production-ready web apps faster"
|
||||
- Clear benefits section for PMs, Solo Founders, Small Teams
|
||||
- Production-Ready Features section highlighting DevOps + Backend guides
|
||||
- Agent-Team Workflow section with step-by-step examples
|
||||
- Tech Stack table (Framework, Language, Styling, etc.)
|
||||
|
||||
**Clarity Improvements:**
|
||||
- Agents renamed in descriptions (e.g., "solution-architect.md" instead of file path only)
|
||||
- "PM-Friendly" emphasized (no code in specs, automatic handoffs)
|
||||
- Scripts section added (`npm run dev`, `build`, `start`, `lint`)
|
||||
|
||||
---
|
||||
|
||||
### 📦 New Files
|
||||
|
||||
1. **`test-reports/README.md`** – QA Test Reports guidelines
|
||||
|
||||
---
|
||||
|
||||
### 🔄 Updated Files
|
||||
|
||||
1. **`.claude/agents/devops.md`**
|
||||
- Added 5 production-ready sections (Error Tracking, Security, Env Vars, Performance, Checklist)
|
||||
- Expanded from ~200 lines → ~400 lines
|
||||
|
||||
2. **`.claude/agents/backend-dev.md`**
|
||||
- Added 5 performance/scalability sections (Indexing, Query Optimization, Caching, Validation, Rate Limiting)
|
||||
- Expanded from ~180 lines → ~350 lines
|
||||
|
||||
3. **`.claude/agents/qa-engineer.md`**
|
||||
- Updated workflow: Test reports saved to `/test-reports/`
|
||||
- Added checklist item: "Test-Report gespeichert"
|
||||
|
||||
4. **`README.md`**
|
||||
- Complete rewrite: More professional, clearer structure
|
||||
- Added Production-Ready Features section
|
||||
- Added Agent-Team Workflow section
|
||||
- Added Why This Template section (PMs, Solo Founders, Teams)
|
||||
|
||||
5. **`TEMPLATE_CHANGELOG.md`**
|
||||
- Added this v1.3.0 entry
|
||||
|
||||
---
|
||||
|
||||
### 🚀 Migration Guide
|
||||
|
||||
No migration needed – all changes are additive.
|
||||
|
||||
If you cloned v1.2.0:
|
||||
1. Update your agents: Copy `.claude/agents/devops.md` and `.claude/agents/backend-dev.md`
|
||||
2. Create `/test-reports/` directory
|
||||
3. Copy `test-reports/README.md`
|
||||
|
||||
---
|
||||
|
||||
## v1.2.0 - Feature Changelog System (2026-01-10)
|
||||
|
||||
### ✅ Änderungen
|
||||
|
||||
+56
-9
@@ -45,21 +45,68 @@ ProjectDashboard
|
||||
│ └── ProjectCard
|
||||
```
|
||||
|
||||
### 5. QA Test Results (vom QA Engineer)
|
||||
Am Ende des Feature-Dokuments fügt QA die Test-Ergebnisse hinzu:
|
||||
```markdown
|
||||
---
|
||||
|
||||
## QA Test Results
|
||||
|
||||
**Tested:** 2026-01-12
|
||||
**App URL:** http://localhost:3000
|
||||
|
||||
### Acceptance Criteria Status
|
||||
- [x] AC-1: User kann Email + Passwort eingeben
|
||||
- [x] AC-2: Passwort mindestens 8 Zeichen
|
||||
- [ ] ❌ BUG: Doppelte Email wird nicht abgelehnt
|
||||
|
||||
### Bugs Found
|
||||
**BUG-1: Doppelte Email-Registrierung**
|
||||
- **Severity:** High
|
||||
- **Steps to Reproduce:** 1. Register with email, 2. Try again with same email
|
||||
- **Expected:** Error message
|
||||
- **Actual:** Silent failure
|
||||
```
|
||||
|
||||
### 6. Deployment Status (vom DevOps Engineer)
|
||||
```markdown
|
||||
---
|
||||
|
||||
## Deployment
|
||||
|
||||
**Status:** ✅ Deployed
|
||||
**Deployed:** 2026-01-13
|
||||
**Production URL:** https://your-app.vercel.app
|
||||
**Git Tag:** v1.0.0-PROJ-1
|
||||
```
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Requirements Engineer** erstellt Feature Spec
|
||||
2. **User** reviewed Spec und gibt Feedback
|
||||
3. **Solution Architect** fügt Tech-Design hinzu
|
||||
4. **User** approved finales Design
|
||||
5. **Frontend/Backend Devs** implementieren
|
||||
6. **QA Engineer** testet gegen Acceptance Criteria
|
||||
7. **DevOps** deployed
|
||||
5. **Frontend/Backend Devs** implementieren (dokumentiert via Git Commits)
|
||||
6. **QA Engineer** testet und fügt Test-Ergebnisse zum Feature-Dokument hinzu
|
||||
7. **DevOps** deployed und fügt Deployment-Status zum Feature-Dokument hinzu
|
||||
|
||||
## Status-Tracking
|
||||
|
||||
Feature-Status wird in `PROJECT_CONTEXT.md` getrackt:
|
||||
- ⚪ Backlog
|
||||
- 🔵 Planned (Requirements geschrieben)
|
||||
- 🟡 In Review (User reviewt)
|
||||
- 🟢 In Development (Wird gebaut)
|
||||
- ✅ Done (Live + getestet)
|
||||
Feature-Status wird direkt im Feature-Dokument getrackt:
|
||||
```markdown
|
||||
# PROJ-1: Feature Name
|
||||
|
||||
**Status:** 🔵 Planned | 🟡 In Progress | ✅ Deployed
|
||||
**Created:** 2026-01-12
|
||||
**Last Updated:** 2026-01-12
|
||||
```
|
||||
|
||||
**Status-Bedeutung:**
|
||||
- 🔵 Planned – Requirements sind geschrieben, ready for development
|
||||
- 🟡 In Progress – Wird gerade gebaut
|
||||
- ✅ Deployed – Live in Production
|
||||
|
||||
**Git als Single Source of Truth:**
|
||||
- Alle Implementierungs-Details sind in Git Commits
|
||||
- `git log --grep="PROJ-1"` zeigt alle Änderungen für dieses Feature
|
||||
- Keine separate FEATURE_CHANGELOG.md nötig!
|
||||
|
||||
@@ -1,109 +0,0 @@
|
||||
# Test Reports
|
||||
|
||||
Dieser Ordner enthält alle QA Test Reports vom **QA Engineer Agent**.
|
||||
|
||||
## Struktur
|
||||
|
||||
Jedes Feature bekommt einen eigenen Test Report:
|
||||
|
||||
```
|
||||
test-reports/
|
||||
├── PROJ-1-simple-todo-kanban.md
|
||||
├── PROJ-2-user-auth.md
|
||||
└── PROJ-3-payment-integration.md
|
||||
```
|
||||
|
||||
## Naming Convention
|
||||
|
||||
**Format:** `PROJ-X-feature-name.md`
|
||||
|
||||
- `PROJ-X` = Feature-ID aus `/features/PROJ-X-feature-name.md`
|
||||
- `feature-name` = Kurzer, beschreibender Name (lowercase, kebab-case)
|
||||
|
||||
**Beispiele:**
|
||||
- `PROJ-1-simple-todo-kanban.md`
|
||||
- `PROJ-2-user-authentication.md`
|
||||
- `PROJ-5-file-upload.md`
|
||||
|
||||
## Was gehört in einen Test Report?
|
||||
|
||||
### 1. Header
|
||||
```markdown
|
||||
# Test Report: PROJ-X Feature-Name
|
||||
|
||||
## Tested: 2026-01-10
|
||||
## Tester: QA Engineer Agent
|
||||
## App URL: http://localhost:3000
|
||||
```
|
||||
|
||||
### 2. Acceptance Criteria Status
|
||||
Jedes Acceptance Criteria aus der Feature Spec testen:
|
||||
```markdown
|
||||
### Aufgaben erstellen
|
||||
- [x] AC-1.1: Input-Feld vorhanden → ✅ PASS
|
||||
- [ ] AC-1.2: Validierung fehlt → ❌ FAIL (BUG-1)
|
||||
```
|
||||
|
||||
### 3. Edge Cases Status
|
||||
Alle Edge Cases aus der Feature Spec testen:
|
||||
```markdown
|
||||
### EC-1: Leere Eingabe
|
||||
- ✅ PASS - Validierung verhindert leere Aufgaben
|
||||
```
|
||||
|
||||
### 4. Bugs Found
|
||||
Alle gefundenen Bugs dokumentieren:
|
||||
```markdown
|
||||
### BUG-1: Validierung fehlt
|
||||
- **Severity:** High
|
||||
- **Steps to Reproduce:**
|
||||
1. Öffne App
|
||||
2. Klick auf "Hinzufügen" ohne Text
|
||||
3. Expected: Error "Bitte Text eingeben"
|
||||
4. Actual: Leere Aufgabe wird erstellt
|
||||
- **Priority:** High
|
||||
```
|
||||
|
||||
### 5. Summary & Production-Ready Decision
|
||||
```markdown
|
||||
## Summary
|
||||
- ✅ 20/24 Acceptance Criteria passed
|
||||
- ❌ 2 Bugs found (1 High, 1 Low)
|
||||
- ⚠️ Feature ist NICHT production-ready
|
||||
|
||||
## Production-Ready Decision
|
||||
❌ **NOT READY** - BUG-1 (High Priority) muss gefixt werden
|
||||
```
|
||||
|
||||
## Test Report Workflow
|
||||
|
||||
1. **QA Engineer Agent** testet Feature
|
||||
2. **Test Report** wird in `/test-reports/PROJ-X-feature-name.md` gespeichert
|
||||
3. **User** reviewed Report und priorisiert Bugs
|
||||
4. **Frontend/Backend Dev** fixt Bugs
|
||||
5. **QA Engineer** testet erneut (Regression Test)
|
||||
6. **Production-Ready** → Feature wird deployed
|
||||
|
||||
## Production-Ready Kriterien
|
||||
|
||||
- ✅ **READY:** Alle Acceptance Criteria passed + Keine Critical/High Bugs
|
||||
- ❌ **NOT READY:** Critical oder High-Priority Bugs existieren
|
||||
|
||||
## Regression Tests
|
||||
|
||||
Wenn Bugs gefixt wurden oder neue Features deployed werden:
|
||||
1. QA Engineer führt **Regression Test** durch
|
||||
2. Alter Test Report bleibt erhalten (mit Datum im Namen):
|
||||
- `PROJ-1-simple-todo-kanban-2026-01-10.md` (alter)
|
||||
- `PROJ-1-simple-todo-kanban.md` (aktuellster)
|
||||
|
||||
## Tools
|
||||
|
||||
- **Manuelles Testing:** Browser (Chrome, Firefox, Safari)
|
||||
- **Responsive Testing:** Browser DevTools (375px Mobile, 768px Tablet, 1440px Desktop)
|
||||
- **Performance:** Chrome DevTools Performance Tab
|
||||
- **Accessibility:** Chrome Lighthouse, axe DevTools
|
||||
|
||||
---
|
||||
|
||||
**Erstellt vom QA Engineer Agent**
|
||||
Reference in New Issue
Block a user