scripte/archivmail
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

refactor: Migrate to Git-based workflow (v1.4.0)

Browse Source 
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
Download Patch File Download Diff File Expand all files Collapse all files
.claude/agents/backend-dev.md
+15 -9
View File
@@ -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`)
.claude/agents/devops.md
+29 -43
View File
@@ -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`
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:**
1. **Feature Spec updaten:**
```bash
git add FEATURE_CHANGELOG.md
git commit -m "docs: Update FEATURE_CHANGELOG for PROJ-X"
# Öffne /features/PROJ-X.md und setze Status:
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
+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)
.claude/agents/qa-engineer.md
+32 -25
View File
@@ -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:**
```
Lies FEATURE_CHANGELOG.md um zu prüfen:
- Welche Features sind bereits implemented?
- Gibt es Abhängigkeiten zu anderen Features?
- Welche bestehenden Features könnten betroffen sein? (Regression!)
- Wurden kürzlich Bugs in ähnlichen Features gefixt?
```bash
# 1. Welche Features sind bereits implemented?
ls features/ | grep "PROJ-"
# 2. Letzte Implementierungen sehen (für Regression Tests)
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:**
- Speichere Report in `/test-reports/PROJ-X-feature-name.md`
- Format: `/test-reports/PROJ-1-simple-todo-kanban.md`
4. **Test-Ergebnisse dokumentieren:**
- Update Feature Spec in `/features/PROJ-X.md` mit Test-Ergebnissen
- 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
**Speichere Test-Reports in:** `/test-reports/PROJ-X-feature-name.md`
### Test Results Location
**Dokumentiere Test-Ergebnisse in:** `/features/PROJ-X.md` (am Ende des Feature-Dokuments)
**Beispiele:**
- `/test-reports/PROJ-1-simple-todo-kanban.md`
- `/test-reports/PROJ-2-user-authentication.md`
**Kein separater test-reports/ Ordner mehr!** Alles bleibt im Feature-Dokument für bessere Übersicht.
### Test Report Template
```markdown
# Test Report: PROJ-X Feature-Name
Füge diese Section ans Ende von `/features/PROJ-X.md`:
## Tested: 2024-01-10
## Tester: QA Engineer Agent
## App URL: http://localhost:3000
```markdown
---
## 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
+23 -9
View File
@@ -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]"
```
.claude/agents/solution-architect.md
+15 -9
View File
@@ -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!)