250 lines
6.9 KiB
Markdown
250 lines
6.9 KiB
Markdown
|
|
# Implementation Rules – Mitai Jinkendo
|
|||
|
|
|
|||
|
|
> **PFLICHTLEKTÜRE für Claude Code vor jeder Feature-Implementierung.**
|
|||
|
|
> Diese Regeln sind verbindlich und dürfen nicht ohne explizite
|
|||
|
|
> Genehmigung des Nutzers übersprungen werden.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 1. Konzept-basierte Implementierung (MANDATORY)
|
|||
|
|
|
|||
|
|
### 1.1 Wann gilt dieser Prozess?
|
|||
|
|
|
|||
|
|
**PFLICHT bei:**
|
|||
|
|
- Feature-Requests mit verlinktem Konzept/Spec-Dokument
|
|||
|
|
- Gitea Issues mit "Konzept" Label
|
|||
|
|
- User sagt "laut Konzept", "wie im Konzept beschrieben"
|
|||
|
|
- Komplexe Features mit >3 Datenquellen oder >5 Funktionen
|
|||
|
|
- Neue Chart-Endpoints mit spezifischen Anforderungen
|
|||
|
|
|
|||
|
|
**OPTIONAL bei:**
|
|||
|
|
- Einfache Bugfixes (1-2 Zeilen)
|
|||
|
|
- Triviale UI-Änderungen (Text, Farbe, Spacing)
|
|||
|
|
- Code-Cleanup ohne Funktionsänderung
|
|||
|
|
|
|||
|
|
**Bei Unsicherheit:** Prozess anwenden. Lieber einmal zu viel als einmal zu wenig.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 2. Der 5-Stufen-Prozess
|
|||
|
|
|
|||
|
|
### Stufe 1: Anforderungsanalyse (BEFORE ANY CODE)
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
□ Konzept/Spec-Dokument VOLLSTÄNDIG lesen
|
|||
|
|
□ Pro Feature: Checkliste mit ALLEN geforderten Elementen erstellen
|
|||
|
|
□ Datenquellen identifizieren (welche Tabellen, data_layer Funktionen)
|
|||
|
|
□ Fehlende Funktionen dokumentieren (was muss neu gebaut werden)
|
|||
|
|
□ Unklarheiten als Fragen dokumentieren
|
|||
|
|
□ Gap-Analyse: Was existiert bereits? Was fehlt komplett?
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**Output:** Anforderungs-Matrix (Tabelle oder Liste)
|
|||
|
|
|
|||
|
|
**Beispiel für E1 (Energiebilanz Chart):**
|
|||
|
|
```
|
|||
|
|
Gefordert im Konzept:
|
|||
|
|
✓ Kalorienaufnahme täglich (nutrition_log.kcal)
|
|||
|
|
✓ 7d Durchschnitt Aufnahme (berechnen)
|
|||
|
|
✗ Trainingskalorien (activity_log.kcal) → FEHLT
|
|||
|
|
✗ Gewichtstrend 7d geglättet (weight_log) → FEHLT
|
|||
|
|
✗ Lagged comparison 3d/7d/14d → FEHLT
|
|||
|
|
✓ TDEE geschätzt (Profile-basiert oder Formel)
|
|||
|
|
✗ Energiebilanz als Balken → Chart-Typ ändern
|
|||
|
|
|
|||
|
|
Offene Fragen:
|
|||
|
|
- Trainingskalorien: activity_log.kcal oder estimated_kcal?
|
|||
|
|
- TDEE: Aus Profil oder Harris-Benedict berechnen?
|
|||
|
|
- Lag-Korrelation: Pearson oder andere Methode?
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### Stufe 2: Umsetzungskonzept erstellen
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
□ Backend: Welche Endpoints? Welche Parameter?
|
|||
|
|
□ Backend: Welche data_layer Funktionen? (existierend + neu)
|
|||
|
|
□ Backend: Welche Berechnungen? (Formeln dokumentieren)
|
|||
|
|
□ Frontend: Welche Komponenten? Welche Chart-Typen?
|
|||
|
|
□ Frontend: Welche API-Calls?
|
|||
|
|
□ Dependencies: Müssen andere Module angepasst werden?
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**Output:** Strukturiertes Umsetzungskonzept als Markdown
|
|||
|
|
|
|||
|
|
**Beispiel:**
|
|||
|
|
```markdown
|
|||
|
|
## E1: Energiebilanz Chart - Umsetzungskonzept
|
|||
|
|
|
|||
|
|
### Backend
|
|||
|
|
**Endpoint:** `GET /api/charts/energy-balance?days=28`
|
|||
|
|
|
|||
|
|
**Datenquellen:**
|
|||
|
|
- `nutrition_log` (kcal, date)
|
|||
|
|
- `activity_log` (kcal, date) → aggregiert nach Tag
|
|||
|
|
- `weight_log` (weight, date) → 7d gleitend
|
|||
|
|
|
|||
|
|
**Neue data_layer Funktionen:**
|
|||
|
|
- `get_daily_training_calories(profile_id, days)` → Summe kcal pro Tag
|
|||
|
|
- `get_weight_trend_7d(profile_id, days)` → 7d gleitender Durchschnitt
|
|||
|
|
- `calculate_lag_correlation(energy_balance, weight_change, lag_days)` → Pearson
|
|||
|
|
|
|||
|
|
**Berechnungen:**
|
|||
|
|
1. Energie-Bilanz = kcal_intake - (TDEE + training_kcal)
|
|||
|
|
2. 7d avg intake = rolling_mean(kcal_intake, 7)
|
|||
|
|
3. 7d avg bilanz = rolling_mean(bilanz, 7)
|
|||
|
|
4. Lag-Korrelation: bilanz[t] vs. weight_change[t+3/7/14]
|
|||
|
|
|
|||
|
|
**Response Format:**
|
|||
|
|
```json
|
|||
|
|
{
|
|||
|
|
"chart_type": "mixed", // Line + Bar kombiniert
|
|||
|
|
"data": {
|
|||
|
|
"labels": ["2026-01-01", ...],
|
|||
|
|
"datasets": [
|
|||
|
|
{"type": "line", "label": "Kalorien", "data": [...]},
|
|||
|
|
{"type": "line", "label": "7d Ø Kalorien", "data": [...]},
|
|||
|
|
{"type": "line", "label": "Training kcal", "data": [...]},
|
|||
|
|
{"type": "line", "label": "TDEE", "data": [...], "borderDash": [5,5]},
|
|||
|
|
{"type": "bar", "label": "Bilanz", "data": [...], "yAxisID": "y1"},
|
|||
|
|
{"type": "line", "label": "Gewicht (7d)", "data": [...], "yAxisID": "y2"}
|
|||
|
|
]
|
|||
|
|
},
|
|||
|
|
"metadata": {
|
|||
|
|
"avg_intake": 2100,
|
|||
|
|
"avg_balance": -300,
|
|||
|
|
"weight_change_7d": -0.5,
|
|||
|
|
"lag_correlation": {
|
|||
|
|
"3d": 0.42,
|
|||
|
|
"7d": 0.68,
|
|||
|
|
"14d": 0.75
|
|||
|
|
}
|
|||
|
|
}
|
|||
|
|
}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### Frontend
|
|||
|
|
**Component:** `NutritionCharts.jsx` → `renderEnergyBalance()`
|
|||
|
|
|
|||
|
|
**Chart-Typ:** Recharts `ComposedChart` (Line + Bar kombiniert)
|
|||
|
|
|
|||
|
|
**API-Call:** `api.getEnergyBalanceChart(days)`
|
|||
|
|
|
|||
|
|
**Features:**
|
|||
|
|
- Dual Y-Axis (links: kcal, rechts: kg)
|
|||
|
|
- Legende mit Hover-Details
|
|||
|
|
- Tooltips zeigen alle Werte
|
|||
|
|
- Lag-Korrelation in Metadata-Box unter Chart
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### Stufe 3: User-Approval einholen (MANDATORY)
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
□ Umsetzungskonzept dem User zeigen
|
|||
|
|
□ Offene Fragen klären
|
|||
|
|
□ Auf explizites OK warten
|
|||
|
|
□ Bei Änderungswünschen: Konzept anpassen, erneut zeigen
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**Niemals** mit der Implementierung beginnen ohne User-Approval!
|
|||
|
|
|
|||
|
|
### Stufe 4: Implementierung
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
□ Exakt nach genehmigtem Konzept implementieren
|
|||
|
|
□ Niemals "ähnliches" bauen oder Abkürzungen nehmen
|
|||
|
|
□ Bei unvorhergesehenen Problemen: User informieren, Konzept anpassen
|
|||
|
|
□ Commits: Referenz zum Konzept im Commit-Message
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**Commit-Message Format:**
|
|||
|
|
```
|
|||
|
|
feat: E1 Energiebilanz Chart (konzept-konform)
|
|||
|
|
|
|||
|
|
Backend:
|
|||
|
|
- Neue data_layer Funktionen: get_daily_training_calories, get_weight_trend_7d
|
|||
|
|
- Endpoint: /api/charts/energy-balance mit Lag-Korrelation
|
|||
|
|
- Chart-Type: mixed (Line + Bar kombiniert)
|
|||
|
|
|
|||
|
|
Frontend:
|
|||
|
|
- ComposedChart mit Dual Y-Axis (kcal + kg)
|
|||
|
|
- Lag-Korrelation Metadata-Display
|
|||
|
|
|
|||
|
|
Konzept: .claude/docs/functional/mitai_jinkendo_konzept_diagramme_auswertungen_v2.md (E1)
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### Stufe 5: Compliance-Check (BEFORE COMMIT)
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
□ Jedes Feature gegen Konzept prüfen (Checkliste abhaken)
|
|||
|
|
□ Alle geforderten Elemente vorhanden?
|
|||
|
|
□ Berechnungen korrekt nach Konzept?
|
|||
|
|
□ Chart-Typ und Darstellung wie gefordert?
|
|||
|
|
□ Metadata vollständig?
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**Erst nach 100% Compliance: Commit + Push**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 3. Warnsignale für Fehlverhalten
|
|||
|
|
|
|||
|
|
**Wenn der User sagt:**
|
|||
|
|
- "Das steht aber im Konzept"
|
|||
|
|
- "Es fehlt X" (nach Deploy)
|
|||
|
|
- "Überprüfe das Konzept"
|
|||
|
|
- "Das ist nicht wie gefordert"
|
|||
|
|
|
|||
|
|
**→ SOFORT STOPPEN**
|
|||
|
|
- Konzept nochmal vollständig lesen
|
|||
|
|
- Gap-Analyse machen: Was fehlt?
|
|||
|
|
- Nachfragen, nicht raten
|
|||
|
|
- Konzept-konform überarbeiten
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 4. Skill-Integration
|
|||
|
|
|
|||
|
|
Für komplexe Features (>10 Funktionen, >3 Module):
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
/implement-feature <feature-name> <konzept-datei>
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
Der Skill führt automatisch Stufe 1-3 aus und wartet auf Approval.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 5. Ausnahmen
|
|||
|
|
|
|||
|
|
**Einzige erlaubte Ausnahme:**
|
|||
|
|
User sagt explizit: "Ignoriere das Konzept" oder "Mach es anders als im Konzept"
|
|||
|
|
|
|||
|
|
**Alle anderen Fälle:** Prozess anwenden.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 6. Eskalation bei Unklarheiten
|
|||
|
|
|
|||
|
|
**Bei Unklarheiten im Konzept:**
|
|||
|
|
|
|||
|
|
1. **Niemals raten oder "ähnliches" bauen**
|
|||
|
|
2. **Immer nachfragen:**
|
|||
|
|
- "Im Konzept steht X, aber unklar ist Y. Wie soll ich vorgehen?"
|
|||
|
|
- "Option A oder Option B?"
|
|||
|
|
3. **Warten auf Antwort**
|
|||
|
|
4. **Konzept mit Antwort aktualisieren**
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Zusammenfassung: 5-Stufen-Checkliste
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
□ 1. Anforderungsanalyse (Konzept vollständig lesen, Checkliste erstellen)
|
|||
|
|
□ 2. Umsetzungskonzept (Backend + Frontend + Datenquellen dokumentieren)
|
|||
|
|
□ 3. User-Approval (Konzept zeigen, auf OK warten)
|
|||
|
|
□ 4. Implementierung (Exakt nach Konzept, keine Abkürzungen)
|
|||
|
|
□ 5. Compliance-Check (100% Checkliste abhaken vor Commit)
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**Kein Schritt darf übersprungen werden.**
|