“alexvisualmakers”
1c3a81156a
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>
113 lines
2.8 KiB
Markdown
113 lines
2.8 KiB
Markdown
# Feature Specifications
|
||
|
||
Dieser Ordner enthält detaillierte Feature Specs vom Requirements Engineer.
|
||
|
||
## Naming Convention
|
||
`PROJ-X-feature-name.md`
|
||
|
||
Beispiele:
|
||
- `PROJ-1-user-authentication.md`
|
||
- `PROJ-2-kanban-board.md`
|
||
- `PROJ-3-file-attachments.md`
|
||
|
||
## Was gehört in eine Feature Spec?
|
||
|
||
### 1. User Stories
|
||
Beschreibe, was der User tun möchte:
|
||
```markdown
|
||
Als [User-Typ] möchte ich [Aktion] um [Ziel zu erreichen]
|
||
```
|
||
|
||
### 2. Acceptance Criteria
|
||
Konkrete, testbare Kriterien:
|
||
```markdown
|
||
- [ ] User kann Email + Passwort eingeben
|
||
- [ ] Passwort muss mindestens 8 Zeichen lang sein
|
||
- [ ] Nach Registration wird User automatisch eingeloggt
|
||
```
|
||
|
||
### 3. Edge Cases
|
||
Was passiert bei unerwarteten Situationen:
|
||
```markdown
|
||
- Was passiert bei doppelter Email?
|
||
- Was passiert bei Netzwerkfehler?
|
||
- Was passiert bei gleichzeitigen Edits?
|
||
```
|
||
|
||
### 4. Tech Design (vom Solution Architect)
|
||
```markdown
|
||
## Database Schema
|
||
CREATE TABLE tasks (...);
|
||
|
||
## Component Architecture
|
||
ProjectDashboard
|
||
├── ProjectList
|
||
│ └── ProjectCard
|
||
```
|
||
|
||
### 5. QA Test Results (vom QA Engineer)
|
||
Am Ende des Feature-Dokuments fügt QA die Test-Ergebnisse hinzu:
|
||
```markdown
|
||
---
|
||
|
||
## QA Test Results
|
||
|
||
**Tested:** 2026-01-12
|
||
**App URL:** http://localhost:3000
|
||
|
||
### Acceptance Criteria Status
|
||
- [x] AC-1: User kann Email + Passwort eingeben
|
||
- [x] AC-2: Passwort mindestens 8 Zeichen
|
||
- [ ] ❌ BUG: Doppelte Email wird nicht abgelehnt
|
||
|
||
### Bugs Found
|
||
**BUG-1: Doppelte Email-Registrierung**
|
||
- **Severity:** High
|
||
- **Steps to Reproduce:** 1. Register with email, 2. Try again with same email
|
||
- **Expected:** Error message
|
||
- **Actual:** Silent failure
|
||
```
|
||
|
||
### 6. Deployment Status (vom DevOps Engineer)
|
||
```markdown
|
||
---
|
||
|
||
## Deployment
|
||
|
||
**Status:** ✅ Deployed
|
||
**Deployed:** 2026-01-13
|
||
**Production URL:** https://your-app.vercel.app
|
||
**Git Tag:** v1.0.0-PROJ-1
|
||
```
|
||
|
||
## Workflow
|
||
|
||
1. **Requirements Engineer** erstellt Feature Spec
|
||
2. **User** reviewed Spec und gibt Feedback
|
||
3. **Solution Architect** fügt Tech-Design hinzu
|
||
4. **User** approved finales Design
|
||
5. **Frontend/Backend Devs** implementieren (dokumentiert via Git Commits)
|
||
6. **QA Engineer** testet und fügt Test-Ergebnisse zum Feature-Dokument hinzu
|
||
7. **DevOps** deployed und fügt Deployment-Status zum Feature-Dokument hinzu
|
||
|
||
## Status-Tracking
|
||
|
||
Feature-Status wird direkt im Feature-Dokument getrackt:
|
||
```markdown
|
||
# PROJ-1: Feature Name
|
||
|
||
**Status:** 🔵 Planned | 🟡 In Progress | ✅ Deployed
|
||
**Created:** 2026-01-12
|
||
**Last Updated:** 2026-01-12
|
||
```
|
||
|
||
**Status-Bedeutung:**
|
||
- 🔵 Planned – Requirements sind geschrieben, ready for development
|
||
- 🟡 In Progress – Wird gerade gebaut
|
||
- ✅ Deployed – Live in Production
|
||
|
||
**Git als Single Source of Truth:**
|
||
- Alle Implementierungs-Details sind in Git Commits
|
||
- `git log --grep="PROJ-1"` zeigt alle Änderungen für dieses Feature
|
||
- Keine separate FEATURE_CHANGELOG.md nötig!
|