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