mitai-jinkendo/.claude/docs/audit/platzhalter/audit-report-2026-03-29/REVISIONSPROTOKOLL.md

Revisionsprotokoll: Methodische Korrektur "Ungenutzte Placeholder"

Revisions-Datum: 30. März 2026 Revisions-Grund: Methodische Fehlsteuerung bei Bewertung ungenutzter Placeholder Durchgeführt von: Claude Code (auf Anforderung des Users)

---

1. Kernproblem

Ursprüngliche Bewertung (FEHLERHAFT):

• 67 ungenutzte Placeholder (60%) wurden als "Technical Debt" bewertet
• Deprecation wurde als primäre Maßnahme vorgeschlagen
• "Ungenutzt" wurde gleichgesetzt mit "redundant/überflüssig"

Warum methodisch falsch:

Für dieses Projekt gilt:

• Die Prompt-Bibliothek befindet sich noch im Aufbau (Phase 0b/0c/1/2 Roadmap)
• Aktuelle Nichtnutzung in Prompts ist kein gültiges Kriterium für Redundanz
• Viele Placeholder sind explizit in Roadmap geplant oder fachlich plausibel

Korrektes Prinzip:

Ein Placeholder darf nur als redundant eingestuft werden, wenn keine fachliche Rolle in Roadmap, Konzept oder Datenmodell erkennbar ist.

---

2. Neue Klassifizierung

Entwickelte Klassifizierungs-Schema:

Status	Definition	Kriterien	Anzahl
used_productively	Aktiv in Prompts/Pipelines/Charts	used_by > 0	44
unused_but_planned	Explizit in Roadmap Phase 0c/1/2	Dokumentiert in Roadmap/Konzept	30 (45%)
unused_but_plausible	Fachlich sinnvolle Rolle erkennbar	Data-Layer-Anbindung + plausible Rolle	37 (55%)
unused_and_unclear	Fachliche Rolle unklar	Keine dokumentierte Rolle	0
redundant_or_duplicate	Echte Doppelung oder ersetzt	Keine fachliche Rolle nachweisbar	0

Ergebnis: Alle 67 ungenutzten Placeholder haben fachliche Berechtigung.

---

3. Durchgeführte Änderungen

A. Executive Summary (01_EXECUTIVE_SUMMARY.md)

Geändert:

Abschnitt 5: "60% ungenutzte Platzhalter" (Zeilen 124-142)

VORHER (FALSCH):

### 5. 60% ungenutzte Platzhalter

**Problem:**
- Technical Debt akkumuliert
- Unklare Deprecation-Strategie

**Impact:**
- Neue Features nutzen evtl. falsche/veraltete Platzhalter

**Root Cause:**
- Platzhalter wurden für geplante Features erstellt, aber noch nicht genutzt

NACHHER (KORREKT):

### 5. 67 Platzhalter noch nicht produktiv eingebunden

**Status:**
- **Wichtig:** Dies ist KEIN Technical Debt, sondern erwartbar bei Prompt-Bibliothek im Aufbau

**Fachliche Klassifizierung:**
- **30 Platzhalter (45%):** Explizit in Roadmap Phase 0c/1/2 geplant
- **37 Platzhalter (55%):** Fachlich plausibel, noch nicht in Prompts integriert
- **0 Platzhalter:** Redundant oder deprecation-würdig

**Interpretation:**
- Kein Deprecation-Bedarf – Integration statt Deletion erforderlich

---

Abschnitt 4: "Technical Debt" (Zeilen 217-230)

VORHER (FALSCH):

### 4. Technical Debt (🟡 MEDIUM)

**Indikatoren:**
- 60% ungenutzt → tote Codepfade

NACHHER (KORREKT):

### 4. Fehlende Produktions-Governance (🟡 MEDIUM)

**KEIN Technical Debt:**
- 60% ungenutzte Platzhalter ≠ "tote Codepfade"
- Prompt-Bibliothek ist im Aufbau (Phase 0b/0c/1/2)
- Ungenutzte Platzhalter sind fachlich geplant oder plausibel

---

Maßnahme P2.1 (Zeilen 377-383)

VORHER (FALSCH):

**7. Ungenutzte Platzhalter Deprecation-Review (67)**
- Deliverable: Deprecation-Liste mit Replacement-Platzhaltern

NACHHER (KORREKT):

**7. Ungenutzte Platzhalter - Integration planen (67)**
- Deliverable: Integration-Roadmap, Prompt-Templates (5-10 Quick Wins)

---

B. Offene Entscheidungen (04_OFFENE_ENTSCHEIDUNGEN.md)

Geändert:

E2.1: Komplette Neuformulierung (Zeilen 193-252)

VORHER (FALSCH):

### E2.1: Ungenutzte Platzhalter - Behalten oder Deprecaten?

**Problem:**
60% der Platzhalter haben 0 Verwendungen. Welche sollen gedeprecated werden?

**Sub-Entscheidungen:**
- E2.1.1: Body Deltas - Redundanz reduzieren
- E2.1.2: Ability Balance - Warten oder Deprecaten?
- E2.1.3: Meta-Platzhalter - Redundant, trivial berechenbar → deprecaten

NACHHER (KORREKT):

### E2.1: Ungenutzte Platzhalter - Roadmap-Priorisierung und Integration-Timeline

**Neue Fragestellung:**
Nicht "Behalten oder Deprecaten?", sondern "WANN und WIE integrieren?"

**Fachliche Klassifizierung:**
- **30 Platzhalter (45%):** Explizit in Roadmap Phase 0c/1/2 geplant
- **37 Platzhalter (55%):** Fachlich plausibel, noch nicht in Prompts integriert
- **0 Platzhalter:** Redundant oder deprecation-würdig

**Sub-Entscheidungen:**
- E2.1.1: Geplante Platzhalter (30) - Integration-Timeline bestätigen
  - Roadmap wie geplant oder Priorisierung anpassen?
- E2.1.2: Plausible Platzhalter (37) - Prompt-Use-Cases identifizieren
  - Für welche Use-Cases Templates erstellen? (Quick Wins)

---

Zusammenfassung (Zeile 395)

VORHER: Deprecation-Strategie | 67 ungenutzte prüfen NACHHER: Integration-Timeline | 67 ungenutzte integrieren

---

C. Maßnahmenplan (03_MASSNAHMENPLAN.md)

Geändert:

P2.2: Komplette Neuformulierung (Zeilen 773-813)

VORHER (FALSCH):

### P2.2: Ungenutzte Platzhalter Deprecation-Review

**Severity:** 🟢 LOW (Technical Debt)

**Kategorisierung:**
1. Behalten - Geplant (30) - Keine Action
2. Deprecate - Redundant/Obsolet (15)
3. Unklar - Product-Review (22)

**Deprecation-Beispiel:**
{
  "key": "bmi",
  "deprecated": true,
  "sunset_date": "2026-06-30"
}

**Output:** Deprecation-Liste, 15-20 Deprecated Platzhalter

NACHHER (KORREKT):

### P2.2: Ungenutzte Platzhalter - Integration planen

**Severity:** 🟡 MEDIUM (Prompt-Bibliothek Vollständigkeit)

**Neue Klassifizierung:**
1. unused_but_planned (30) - Timeline bestätigen, Prototyping
2. unused_but_plausible (37) - Prompt-Use-Cases, Templates
3. redundant_or_duplicate (0) - Keine!

**Integration-Beispiel:**
{
  "key": "arm_28d_delta",
  "usage_role": "unused_but_plausible",
  "prompt_use_cases": ["Fortschritts-Analyse spezifischer Körperteile", ...]
}

**Output:** Integration-Roadmap, Prompt-Templates (5-10), Nutzungsrate +10-20%

---

P2 Summary (Zeilen 817-828)

VORHER:

• Deliverables: "15-20 Deprecated Platzhalter"
• Impact: "Technical Debt reduziert"

NACHHER:

• Deliverables: "Integration-Roadmap für 30 geplante, Prompt-Templates für 5-10 Quick Wins"
• Impact: "Placeholder-Integration vorangetrieben, Nutzungsrate 40% → 50-60%"

---

D. Prüfmatrix Summary (06_PRUEFMATRIX_SUMMARY.md)

Geändert:

"Ungenutzte Platzhalter" Abschnitt (Zeilen 199-218)

VORHER (FALSCH):

## UNGENUTZTE PLATZHALTER (67 - 60%)

**Deprecation-Kandidaten:**

### Kategorie A: Behalten - Geplant (30)
### Kategorie B: Deprecate - Redundant/Obsolet (15)
- bmi, waist_hip_ratio (berechenbar)
- Body Deltas (redundant zu waist_28d_delta Pattern)
- monotony_score, strain_score (experimentell)
### Kategorie C: Unklar - Product-Review (22)

NACHHER (KORREKT):

## UNGENUTZTE PLATZHALTER (67 - 60%)

**WICHTIG:** Methodische Korrektur (30.03.2026)
- Nichtnutzung ≠ Deprecation-Bedarf
- Prompt-Bibliothek ist im Aufbau

**Neue Klassifizierung:**

### unused_but_planned (30 - 45%)
- Scores (6), Correlations (5), Ability Balance (5), Goals Details (11), etc.
- Roadmap: Phase 0c/1/2
- Action: Timeline bestätigen

### unused_but_plausible (37 - 55%)
- Body Deltas (5), Nutrition Details (6), Training Quality (3), Focus Category (14), Meta (9)
- Plausibel für: Fortschritts-Prompts, Coaching, Dashboard
- Action: Prompt-Use-Cases identifizieren

### redundant_or_duplicate (0 - 0%)
- Keine - alle 67 haben fachliche Berechtigung

---

E. README (06_README.md)

Geändert:

Zeile 50:

VORHER: E2: Deprecation-Strategie (67 ungenutzte Platzhalter) NACHHER: E2: Integration-Timeline (67 ungenutzte Platzhalter - Roadmap-Priorisierung)

Zeilen 129-133:

VORHER:

**Nach P2 (Week 5):** 65-70%
- 15-20 deprecated Platzhalter
- Technical Debt reduziert

NACHHER:

**Nach P2 (Week 5):** 65-70%
- Integration-Roadmap für 30 geplante Platzhalter
- Prompt-Templates für 5-10 Quick Wins
- Nutzungsrate 40% → 50-60%

---

4. Neue Artefakte

USAGE_ROLE_CLASSIFICATION.md (NEU)

Vollständige fachliche Klassifizierung aller 67 ungenutzten Placeholder:

• 30 unused_but_planned (mit Roadmap-Referenzen)
• 37 unused_but_plausible (mit fachlicher Begründung)
• 0 redundant_or_duplicate

Enthält:

• Detaillierte Gruppierung (Scores, Correlations, Ability Balance, etc.)
• Fachliche Rollen pro Gruppe
• Roadmap-Zuordnungen
• Prompt-Use-Case-Beispiele

---

5. Was sich NICHT geändert hat

Unberührt (technisch korrekt):

• Gap-Cluster-Report (02) - technische Gaps bleiben identisch
• Quellenprotokoll (05) - keine methodische Regel dokumentiert
• Alle technischen Findings (time_window, confidence, data_layer_module)
• P0/P1 Maßnahmen (vollständig technisch)
• Code-Docs-Konflikte (bleibt P0-kritisch)
• Best-Practice-Modelle (nutrition_avg, etc.)

---

6. Zusammenfassung der Revisionslogik

Alt (FALSCH):

ungenutzt → Technical Debt → Deprecation-Review → 15-20 deprecaten

Neu (KORREKT):

ungenutzt → Fachliche Klassifizierung → Integration-Planung → 5-10 aktivieren
                ↓
        45% geplant (Roadmap Phase 0c/1/2)
        55% plausibel (Prompt-Use-Cases)
        0% redundant

---

7. Methodische Regel (verbindlich)

Für alle künftigen Audits:

Ein Placeholder darf nicht als redundant, überflüssig oder Deprecation-Kandidat eingestuft werden, nur weil er aktuell:

• in keinem Prompt verwendet wird
• in keiner Pipeline referenziert wird
• in keinem Chart vorkommt
• derzeit nicht produktiv eingebunden ist

Erlaubte Kriterien für "redundant":

1. Keine fachliche Rolle im Datenmodell
2. Keine Rolle in Roadmap/Konzept
3. Echte inhaltliche Doppelung (2+ Placeholder mit identischer Semantik)
4. Fachlich ersetzt (expliziter Replacement dokumentiert)
5. Explizite Deprecation-Entscheidung (dokumentiert)

"Heute nicht verwendet" allein ist ausdrücklich kein Redundanzbeweis.

---

8. Impact der Revision

Quantitativ:

• Dokumente geändert: 5 von 6 (nur Quellenprotokoll unberührt)
• Abschnitte revidiert: 10 (Executive Summary: 3, Offene Entscheidungen: 2, Maßnahmenplan: 2, Prüfmatrix: 1, README: 2)
• Neue Artefakte: 1 (USAGE_ROLE_CLASSIFICATION.md)
• Gesamttext geändert: ~30% der Audit-Berichte (primär Abschnitte zu ungenutzten Platzhaltern)

Qualitativ:

• Methodische Basis: Roadmap-Konformität statt Nutzungsstatus
• Ton: Von "Problem/Technical Debt" zu "Geplant/Integration erforderlich"
• Maßnahmen: Von "Deprecation-Review" zu "Integration-Planung"
• Ziel: Von "15-20 deprecaten" zu "5-10 aktivieren"

---

Revision abgeschlossen: 30. März 2026 Revisions-Aufwand: ~2h (Klassifizierung + 5 Dokumente + Protokoll) Qualitätssicherung: Cross-Check gegen Roadmap + Diagramm-Konzept v2 + DATA_ARCHITECTURE.md

---

Nächste Schritte:

1. User-Review der revidierten Dokumente
2. Validierung der Klassifizierung (30 geplant / 37 plausibel korrekt?)
3. Bei Approval: Audit als abgeschlossen markieren