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”
2026-01-12 14:57:19 +01:00
parent f035934f42
commit 1c3a81156a
12 changed files with 349 additions and 445 deletions
+16 -9
View File
@@ -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)