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:**
-```
-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`)