Lars/mitai-jinkendo
1
0
Fork 0
Code Issues 33 Pull Requests Actions Packages Projects Releases 5 Wiki Activity

Placeholder Registry: UNRESOLVED & TO_VERIFY Metadaten pr�fen #54

New Issue
Open
opened 2026-04-02 15:38:47 +02:00 by Lars · 0 comments
Lars commented 2026-04-02 15:38:47 +02:00
Owner
Copy Link

Betroffen: Ernährungs-Cluster (14 Placeholders)
Status: Nach Abschluss Part A/B/C

Betroffene Felder

UNRESOLVED (5 Felder)

Part A (kcal_avg, protein_avg, carb_avg, fat_avg):

  • minimum_data_requirements: Nicht explizit im Code dokumentiert
  • quality_filter_policy: Nicht implementiert

Part B:

  • protein_g_per_kg.confidence_logic: Nicht explizit dokumentiert
  • protein_days_in_target.confidence_logic: Nicht dokumentiert
  • protein_adequacy_28d.confidence_logic: Nicht dokumentiert

TO_VERIFY (21 Felder)

Alle 14 Placeholders (systematisch):

  • layer_1_decision: Muss Phase 0c Architektur verifizieren
  • layer_2a_decision: Muss Resolver-Layer Separation verifizieren
  • layer_2b_reuse_possible: Muss Chart-Reuse-Möglichkeiten prüfen

Betroffene Placeholders:

  • Part A: kcal_avg, protein_avg, carb_avg, fat_avg
  • Part B: protein_ziel_low, protein_ziel_high, protein_g_per_kg, protein_days_in_target, protein_adequacy_28d
  • Part C: macro_consistency_score, energy_balance_7d, energy_deficit_surplus, intake_volatility, nutrition_days

Aufgaben

1. UNRESOLVED Fields klären

Für Part A (4 Placeholders):

  • minimum_data_requirements aus Code/Tests ableiten oder dokumentieren
  • quality_filter_policy prüfen ob implementiert oder als "none" dokumentieren

Für Part B:

  • confidence_logic für protein_g_per_kg dokumentieren
  • confidence_logic für protein_days_in_target dokumentieren
  • confidence_logic für protein_adequacy_28d dokumentieren

Ziel: EvidenceType.UNRESOLVED → CODE_DERIVED oder DRAFT_DERIVED

2. TO_VERIFY Fields verifizieren

Phase 0c Architektur-Review:

  • Für alle 14 Placeholders prüfen:
    • Layer 1 (Data Layer): Korrekt zugeordnet?
    • Layer 2a (Resolver): Nur Formatting?
    • Layer 2b (Charts): Reuse möglich?

Dokumentation:

  • Issue #53 (Phase 0c) Review
  • Chart-Endpoints prüfen (wenn implementiert)
  • Bestätigung dass Architektur-Alignment korrekt

Ziel: EvidenceType.TO_VERIFY → CODE_DERIVED (wenn verifiziert)

Acceptance Criteria

  • Alle 5 UNRESOLVED Felder sind aufgelöst
  • Alle 21 TO_VERIFY Felder sind verifiziert oder bleiben begründet TO_VERIFY
  • Registry-Files (nutrition_part_*.py) sind aktualisiert
  • Commit mit Message "fix: Nutrition Registry - Evidence Review"
  • Export-Test: Metadaten weiterhin konsistent

Betroffene Files

backend/placeholder_registrations/nutrition_part_a.py
  Lines 73-77: UNRESOLVED (minimum_data_requirements, quality_filter_policy)
  Lines 73: TO_VERIFY (layer_2b_reuse_possible)

backend/placeholder_registrations/nutrition_part_b.py
  Lines 107, 183, 261, 338, 421: TO_VERIFY (layer_2b_reuse_possible)
  Lines 256, 333, 416: UNRESOLVED (confidence_logic)

backend/placeholder_registrations/nutrition_part_c.py
  Lines 95-97: TO_VERIFY (layer_1_decision, layer_2a_decision, layer_2b_reuse_possible) - macro_consistency_score
  Lines 177-179: TO_VERIFY (layer_*) - energy_balance_7d
  Lines 256-258: TO_VERIFY (layer_*) - energy_deficit_surplus
  Lines 334-336: TO_VERIFY (layer_*) - intake_volatility
  Lines 416-418: TO_VERIFY (layer_*) - nutrition_days

Empfohlener Workflow

Phase 1: Code-Inspektion (1-2h)

  1. Confidence Logic dokumentieren:

    • backend/data_layer/nutrition_metrics.py reviewen
    • Confidence-Berechnung für protein_* Funktionen identifizieren
    • In Registry dokumentieren

  2. Quality Filter prüfen:

    • get_nutrition_average_data() Funktion prüfen
    • Filter-Policy dokumentieren oder "none" setzen

  3. Minimum Requirements:

    • Aus Code ableiten (z.B. "mindestens X Tage mit Daten")
    • In Registry dokumentieren

Phase 2: Architektur-Verifizierung (1h)

  1. Phase 0c Review:

    • .claude/docs/issues/issue-53-phase-0c-multi-layer-architecture.md lesen
    • Bestätigen dass Layer-Separation korrekt

  2. Für jeden Placeholder prüfen:

    • Layer 1: Ist Berechnung in data_layer/?
    • Layer 2a: Macht Resolver nur Formatting?
    • Layer 2b: Ist Chart-Reuse sinnvoll?

  3. Chart-Endpoints:

    • backend/routers/charts.py prüfen
    • Bestehende Chart-Implementierungen als Referenz

Phase 3: Update & Test (30min)

  1. Registry-Files aktualisieren:

    • Evidence-Tags ändern
    • Dokumentation ergänzen

  2. Commit:

    git add backend/placeholder_registrations/
git commit -m "fix: Nutrition Registry - Evidence Review

Resolved UNRESOLVED fields:
- minimum_data_requirements documented from code analysis
- quality_filter_policy clarified
- confidence_logic for protein_* placeholders documented

Verified TO_VERIFY fields:
- Phase 0c architecture alignment confirmed
- Layer separation verified for all 14 placeholders
- Chart reuse possibilities evaluated

Evidence-Tags updated:
- 5 UNRESOLVED → CODE_DERIVED/DRAFT_DERIVED
- 21 TO_VERIFY → CODE_DERIVED (where verified)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>"

  3. Test:

    # Deploy & Test Export
curl "https://dev.mitai.jinkendo.de/api/prompts/placeholders/export-values-extended" \
  -H "X-Auth-Token: $(token)" | jq '.registry_metadata.evidence_report'

Referenzen

Framework & Docs:

  • .claude/docs/technical/PLACEHOLDER_REGISTRY_FRAMEWORK.md
  • .claude/docs/issues/issue-53-phase-0c-multi-layer-architecture.md

Implementation Reports:

  • .claude/task/rework_0b_placeholder/NUTRITION_PART_A_IMPLEMENTATION_REPORT.md
  • .claude/task/rework_0b_placeholder/NUTRITION_PART_B_IMPLEMENTATION_REPORT.md
  • .claude/task/rework_0b_placeholder/NUTRITION_PART_C_IMPLEMENTATION_REPORT.md

Guide:

  • .claude/task/rework_0b_placeholder/NEXT_CLUSTER_GUIDE.md

Abschluss:

  • .claude/task/rework_0b_placeholder/NUTRITION_CLUSTER_ABSCHLUSS.md

Hinweise

Nicht kritisch für Produktivbetrieb

Diese Metadaten-Review ist nicht blocker für:

  • ✅ Produktiv-Nutzung der Placeholders (alle funktionieren)
  • ✅ Export (alle Metadaten vollständig)
  • ✅ Weitere Cluster-Implementierungen

Aber wichtig für:

  • Dokumentations-Vollständigkeit
  • Evidence-Transparenz
  • Architektur-Verifizierung
  • Framework-Beispiel für weitere Cluster

Evidence-Tag Philosophie

UNRESOLVED ist OK wenn:

  • Information aktuell nicht verfügbar
  • Mehr Kontext nötig als vorhanden
  • Field optional und nicht kritisch

TO_VERIFY ist OK wenn:

  • Annahme getroffen wurde
  • Architektur-Entscheidung noch nicht final
  • Weitere Tests erforderlich

Nicht alles muss CODE_DERIVED sein!

Issue erstellt von: Claude Opus 4.6
Datum: 2026-04-02
Basis: Nutrition Cluster Abschluss

**Betroffen:** Ernährungs-Cluster (14 Placeholders) **Status:** Nach Abschluss Part A/B/C --- ## Betroffene Felder ### UNRESOLVED (5 Felder) **Part A (kcal_avg, protein_avg, carb_avg, fat_avg):** - `minimum_data_requirements`: Nicht explizit im Code dokumentiert - `quality_filter_policy`: Nicht implementiert **Part B:** - `protein_g_per_kg.confidence_logic`: Nicht explizit dokumentiert - `protein_days_in_target.confidence_logic`: Nicht dokumentiert - `protein_adequacy_28d.confidence_logic`: Nicht dokumentiert ### TO_VERIFY (21 Felder) **Alle 14 Placeholders (systematisch):** - `layer_1_decision`: Muss Phase 0c Architektur verifizieren - `layer_2a_decision`: Muss Resolver-Layer Separation verifizieren - `layer_2b_reuse_possible`: Muss Chart-Reuse-Möglichkeiten prüfen **Betroffene Placeholders:** - **Part A:** kcal_avg, protein_avg, carb_avg, fat_avg - **Part B:** protein_ziel_low, protein_ziel_high, protein_g_per_kg, protein_days_in_target, protein_adequacy_28d - **Part C:** macro_consistency_score, energy_balance_7d, energy_deficit_surplus, intake_volatility, nutrition_days --- ## Aufgaben ### 1. UNRESOLVED Fields klären **Für Part A (4 Placeholders):** - [ ] `minimum_data_requirements` aus Code/Tests ableiten oder dokumentieren - [ ] `quality_filter_policy` prüfen ob implementiert oder als "none" dokumentieren **Für Part B:** - [ ] `confidence_logic` für protein_g_per_kg dokumentieren - [ ] `confidence_logic` für protein_days_in_target dokumentieren - [ ] `confidence_logic` für protein_adequacy_28d dokumentieren **Ziel:** `EvidenceType.UNRESOLVED` → `CODE_DERIVED` oder `DRAFT_DERIVED` ### 2. TO_VERIFY Fields verifizieren **Phase 0c Architektur-Review:** - [ ] Für alle 14 Placeholders prüfen: - Layer 1 (Data Layer): Korrekt zugeordnet? - Layer 2a (Resolver): Nur Formatting? - Layer 2b (Charts): Reuse möglich? **Dokumentation:** - [ ] Issue #53 (Phase 0c) Review - [ ] Chart-Endpoints prüfen (wenn implementiert) - [ ] Bestätigung dass Architektur-Alignment korrekt **Ziel:** `EvidenceType.TO_VERIFY` → `CODE_DERIVED` (wenn verifiziert) --- ## Acceptance Criteria - [ ] Alle 5 UNRESOLVED Felder sind aufgelöst - [ ] Alle 21 TO_VERIFY Felder sind verifiziert oder bleiben begründet TO_VERIFY - [ ] Registry-Files (nutrition_part_*.py) sind aktualisiert - [ ] Commit mit Message "fix: Nutrition Registry - Evidence Review" - [ ] Export-Test: Metadaten weiterhin konsistent --- ## Betroffene Files ``` backend/placeholder_registrations/nutrition_part_a.py Lines 73-77: UNRESOLVED (minimum_data_requirements, quality_filter_policy) Lines 73: TO_VERIFY (layer_2b_reuse_possible) backend/placeholder_registrations/nutrition_part_b.py Lines 107, 183, 261, 338, 421: TO_VERIFY (layer_2b_reuse_possible) Lines 256, 333, 416: UNRESOLVED (confidence_logic) backend/placeholder_registrations/nutrition_part_c.py Lines 95-97: TO_VERIFY (layer_1_decision, layer_2a_decision, layer_2b_reuse_possible) - macro_consistency_score Lines 177-179: TO_VERIFY (layer_*) - energy_balance_7d Lines 256-258: TO_VERIFY (layer_*) - energy_deficit_surplus Lines 334-336: TO_VERIFY (layer_*) - intake_volatility Lines 416-418: TO_VERIFY (layer_*) - nutrition_days ``` --- ## Empfohlener Workflow ### Phase 1: Code-Inspektion (1-2h) 1. **Confidence Logic dokumentieren:** - `backend/data_layer/nutrition_metrics.py` reviewen - Confidence-Berechnung für protein_* Funktionen identifizieren - In Registry dokumentieren 2. **Quality Filter prüfen:** - `get_nutrition_average_data()` Funktion prüfen - Filter-Policy dokumentieren oder "none" setzen 3. **Minimum Requirements:** - Aus Code ableiten (z.B. "mindestens X Tage mit Daten") - In Registry dokumentieren ### Phase 2: Architektur-Verifizierung (1h) 1. **Phase 0c Review:** - `.claude/docs/issues/issue-53-phase-0c-multi-layer-architecture.md` lesen - Bestätigen dass Layer-Separation korrekt 2. **Für jeden Placeholder prüfen:** - **Layer 1:** Ist Berechnung in data_layer/? - **Layer 2a:** Macht Resolver nur Formatting? - **Layer 2b:** Ist Chart-Reuse sinnvoll? 3. **Chart-Endpoints:** - `backend/routers/charts.py` prüfen - Bestehende Chart-Implementierungen als Referenz ### Phase 3: Update & Test (30min) 1. **Registry-Files aktualisieren:** - Evidence-Tags ändern - Dokumentation ergänzen 2. **Commit:** ```bash git add backend/placeholder_registrations/ git commit -m "fix: Nutrition Registry - Evidence Review Resolved UNRESOLVED fields: - minimum_data_requirements documented from code analysis - quality_filter_policy clarified - confidence_logic for protein_* placeholders documented Verified TO_VERIFY fields: - Phase 0c architecture alignment confirmed - Layer separation verified for all 14 placeholders - Chart reuse possibilities evaluated Evidence-Tags updated: - 5 UNRESOLVED → CODE_DERIVED/DRAFT_DERIVED - 21 TO_VERIFY → CODE_DERIVED (where verified) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>" ``` 3. **Test:** ```bash # Deploy & Test Export curl "https://dev.mitai.jinkendo.de/api/prompts/placeholders/export-values-extended" \ -H "X-Auth-Token: $(token)" | jq '.registry_metadata.evidence_report' ``` --- ## Referenzen **Framework & Docs:** - `.claude/docs/technical/PLACEHOLDER_REGISTRY_FRAMEWORK.md` - `.claude/docs/issues/issue-53-phase-0c-multi-layer-architecture.md` **Implementation Reports:** - `.claude/task/rework_0b_placeholder/NUTRITION_PART_A_IMPLEMENTATION_REPORT.md` - `.claude/task/rework_0b_placeholder/NUTRITION_PART_B_IMPLEMENTATION_REPORT.md` - `.claude/task/rework_0b_placeholder/NUTRITION_PART_C_IMPLEMENTATION_REPORT.md` **Guide:** - `.claude/task/rework_0b_placeholder/NEXT_CLUSTER_GUIDE.md` **Abschluss:** - `.claude/task/rework_0b_placeholder/NUTRITION_CLUSTER_ABSCHLUSS.md` --- ## Hinweise ### Nicht kritisch für Produktivbetrieb Diese Metadaten-Review ist **nicht blocker** für: - ✅ Produktiv-Nutzung der Placeholders (alle funktionieren) - ✅ Export (alle Metadaten vollständig) - ✅ Weitere Cluster-Implementierungen **Aber wichtig für:** - Dokumentations-Vollständigkeit - Evidence-Transparenz - Architektur-Verifizierung - Framework-Beispiel für weitere Cluster ### Evidence-Tag Philosophie **UNRESOLVED ist OK wenn:** - Information aktuell nicht verfügbar - Mehr Kontext nötig als vorhanden - Field optional und nicht kritisch **TO_VERIFY ist OK wenn:** - Annahme getroffen wurde - Architektur-Entscheidung noch nicht final - Weitere Tests erforderlich **Nicht alles muss CODE_DERIVED sein!** --- **Issue erstellt von:** Claude Opus 4.6 **Datum:** 2026-04-02 **Basis:** Nutrition Cluster Abschluss
Lars added the
feature
high
 labels 2026-04-02 15:38:47 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
bug

Bug/Fehler

  
develop

Betrifft develop Branch

  
feature

Feature Request

  
high

Hohe Priorit�t

  
low

Niedrige Priorit�t

No Label
bug
develop
feature
high
low
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Lars/mitai-jinkendo#54
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?