mitai-jinkendo/.claude/rules/IMPLEMENTATION_RULES.md
Lars 7940dc7560 docs: Struktur .claude/docs versionieren, working/, Gitea-Index, Regeln
- .gitignore: .claude/docs, rules, commands tracken; settings.local weiter ignorieren
- DOCUMENTATION.md: verbindliche Ablage functional/technical/working/issues
- .claude/README.md: Agent-Einstieg; GITEA_ISSUES_INDEX aus MCP (Stand 2026-04-08)
- Arbeitspapiere von docs/ nach .claude/docs/working/ verschoben
- docs/MEMBERSHIP_SYSTEM.md als Stub; kanonisch technical/MEMBERSHIP_SYSTEM.md
- CLAUDE.md Pflichtlektüre und Links angepasst; docs/README.md vereinfacht

Made-with: Cursor
2026-04-08 13:01:49 +02:00

250 lines
6.9 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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.**