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/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:**
-```
-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]"
+```