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>

.claude/agents/backend-dev.md

@@ -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:**
-```
+```bash
-Lies FEATURE_CHANGELOG.md um zu prüfen:
+# 1. Welche API Endpoints existieren bereits?
-- Welche Database Tables existieren bereits?
+git ls-files src/app/api/
-- Welche Columns können wiederverwendet werden?
+
-- Gibt es bereits ähnliche API Endpoints?
+# 2. Letzte Backend-Implementierungen sehen
-- Welche RLS Policies sind schon implementiert?
+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`)

.claude/agents/devops.md

@@ -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`
+1. **Feature Spec updaten:**
-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:**
    ```bash
-   git add FEATURE_CHANGELOG.md
+   # Öffne /features/PROJ-X.md und setze Status:
-   git commit -m "docs: Update FEATURE_CHANGELOG for PROJ-X"
+   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)
 

.claude/agents/frontend-dev.md

@@ -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:**
-```
+```bash
-Lies FEATURE_CHANGELOG.md um zu prüfen:
+# 1. Welche Components existieren bereits?
-- Existieren bereits ähnliche Components? (z.B. Button, Card, Form)
+git ls-files src/components/
-- Welche Styling-Patterns wurden bereits verwendet?
+
-- Gibt es wiederverwendbare Hooks? (useAuth, useFetch, etc.)
+# 2. Welche Hooks/Utils existieren?
-- Welche Utility-Functions existieren schon?
+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)

.claude/agents/qa-engineer.md

@@ -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:**
-```
+```bash
-Lies FEATURE_CHANGELOG.md um zu prüfen:
+# 1. Welche Features sind bereits implemented?
-- Welche Features sind bereits implemented?
+ls features/ | grep "PROJ-"
-- Gibt es Abhängigkeiten zu anderen Features?
+
-- Welche bestehenden Features könnten betroffen sein? (Regression!)
+# 2. Letzte Implementierungen sehen (für Regression Tests)
-- Wurden kürzlich Bugs in ähnlichen Features gefixt?
+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:**
+4. **Test-Ergebnisse dokumentieren:**
-   - Speichere Report in `/test-reports/PROJ-X-feature-name.md`
+   - Update Feature Spec in `/features/PROJ-X.md` mit Test-Ergebnissen
-   - Format: `/test-reports/PROJ-1-simple-todo-kanban.md`
+   - 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
+### Test Results Location
-**Speichere Test-Reports in:** `/test-reports/PROJ-X-feature-name.md`
+**Dokumentiere Test-Ergebnisse in:** `/features/PROJ-X.md` (am Ende des Feature-Dokuments)
 
-**Beispiele:**
+**Kein separater test-reports/ Ordner mehr!** Alles bleibt im Feature-Dokument für bessere Übersicht.
-- `/test-reports/PROJ-1-simple-todo-kanban.md`
-- `/test-reports/PROJ-2-user-authentication.md`
 
 ### Test Report Template
-```markdown
+Füge diese Section ans Ende von `/features/PROJ-X.md`:
-# Test Report: PROJ-X Feature-Name
 
-## Tested: 2024-01-10
+```markdown
-## Tester: QA Engineer Agent
+---
-## App URL: http://localhost:3000
+
+## 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

.claude/agents/requirements-engineer.md

@@ -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:**
-```
+```bash
-Lies FEATURE_CHANGELOG.md um zu prüfen:
+# 1. Welche Features existieren bereits?
-- Existiert ein ähnliches Feature bereits?
+ls features/ | grep "PROJ-"
-- Auf welchen bestehenden Features können wir aufbauen?
+
-- Welche Feature-IDs sind bereits vergeben?
+# 2. Welche Components/APIs existieren schon?
-- 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]"
+```

.claude/agents/solution-architect.md

@@ -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:**
-```
+```bash
-Lies FEATURE_CHANGELOG.md um zu prüfen:
+# 1. Welche Components existieren bereits?
-- Existieren bereits ähnliche Components? (Code-Reuse!)
+git ls-files src/components/
-- Welche Database Tables/Columns gibt es schon?
+
-- Welche API Endpoints existieren bereits?
+# 2. Welche API Endpoints existieren?
-- Auf welchen Features können wir aufbauen?
+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!)

FEATURE_CHANGELOG.md

@@ -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

PROJECT_CONTEXT.md

@@ -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**
+4. **Track progress via Git**
-   - `PROJECT_CONTEXT.md` - Add features to roadmap, mark them as done
+   - Feature specs in `/features/PROJ-X.md` show status (Planned → In Progress → Deployed)
-   - `FEATURE_CHANGELOG.md` - Automatically updated after deployment
+   - Git commits track all implementation details
+   - Use `git log --grep="PROJ-X"` to see feature history
 
 ---
 

README.md

@@ -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)
+├── features/                ← Feature Specs (includes specs, test results, deployment status)
-│   └── README.md
-├── test-reports/            ← QA Test Reports (QA Engineer creates these)
 │   └── 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.2.0 – Agent System Improvements (Interactive Questions, PM-Friendly Output)
-- v1.1.0 – Agent System Improvements (Interactive Questions, PM-Friendly Output)
+- v1.1.0 – Enhanced Documentation
 - v1.0.0 – Initial Release
 
 ---

TEMPLATE_CHANGELOG.md

@@ -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

features/README.md

@@ -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
+5. **Frontend/Backend Devs** implementieren (dokumentiert via Git Commits)
-6. **QA Engineer** testet gegen Acceptance Criteria
+6. **QA Engineer** testet und fügt Test-Ergebnisse zum Feature-Dokument hinzu
-7. **DevOps** deployed
+7. **DevOps** deployed und fügt Deployment-Status zum Feature-Dokument hinzu
 
 ## Status-Tracking
 
-Feature-Status wird in `PROJECT_CONTEXT.md` getrackt:
+Feature-Status wird direkt im Feature-Dokument getrackt:
-- ⚪ Backlog
+```markdown
-- 🔵 Planned (Requirements geschrieben)
+# PROJ-1: Feature Name
-- 🟡 In Review (User reviewt)
+
-- 🟢 In Development (Wird gebaut)
+**Status:** 🔵 Planned | 🟡 In Progress | ✅ Deployed
-- ✅ Done (Live + getestet)
+**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!

test-reports/README.md

@@ -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**