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

Body Cluster - Restarbeiten & Metadaten-Verifizierung #56

New Issue
Open
opened 2026-04-02 19:37:35 +02:00 by Lars · 0 comments
Lars commented 2026-04-02 19:37:35 +02:00
Owner
Copy Link

Body Cluster - Restarbeiten & Metadaten-Verifizierung

Status: Body Cluster Registration komplett (17/17 Placeholders), aber Metadaten noch nicht final verifiziert

Priorität: Medium

Labels: placeholder-registry, phase-0c, documentation

Zusammenfassung

Die Body Cluster Implementation (17 Placeholders) ist technisch vollständig deployed und funktioniert. Allerdings weisen die Metadaten noch Lücken auf - insbesondere sind kritische Felder noch nicht verifiziert (TO_VERIFY) und benötigen Validation.

Verbleibende Aufgaben

1. Layer 2b - Chart Assignment Verifizierung

Betroffen: Alle 17 Body Placeholders

Feld: layer_2b_reuse_possible

Aktueller Status: TO_VERIFY

Aufgabe:

  • Für jeden Placeholder prüfen, ob er für Chart-Endpoints (Layer 2b) wiederverwendet werden kann
  • Entscheidung dokumentieren (true/false + Begründung)
  • Evidence-Type auf CODE_DERIVED oder DRAFT_DERIVED ändern

Placeholders:

  1. weight_aktuell
  2. weight_trend
  3. weight_7d_median
  4. weight_28d_slope
  5. weight_90d_slope
  6. kf_aktuell
  7. fm_28d_change
  8. lbm_28d_change
  9. waist_hip_ratio
  10. recomposition_quadrant
  11. waist_28d_delta
  12. arm_28d_delta
  13. chest_28d_delta
  14. hip_28d_delta
  15. thigh_28d_delta
  16. caliper_summary
  17. circ_summary

Kontext:

  • Phase 0c Multi-Layer Architecture definiert Layer 2b als Chart-Endpoints
  • Chart-Endpoints wurden bereits implementiert (E1-E5, A1-A8, R1-R5, C1-C4)
  • Frage: Können die registrierten Placeholder-Funktionen direkt für Charts genutzt werden?

Kriterien für Wiederverwendbarkeit:

  • Ist die Datenstruktur Chart-kompatibel?
  • Liefert die Funktion genug Metadaten (confidence, data_points)?
  • Kann die Funktion Zeitfenster-Parameter akzeptieren?
  • Ist die Berechnung identisch mit Chart-Anforderungen?

2. Metadaten-Lücken schließen

Potenzielle Lücken (zu prüfen):

2.1 description Field

Einige Placeholders haben möglicherweise zu kurze/ungenaue Beschreibungen.

Prüfen:

  • Ist die description ausreichend detailliert?
  • Erklärt sie den Use Case?
  • Unterscheidet sie sich klar von ähnlichen Placeholders?

2.2 example_output Field

Nicht alle Placeholders haben realistische Beispiel-Outputs.

Prüfen:

  • Fehlen Beispiele bei komplexen Outputs (Summaries, Quadrants)?
  • Sind die Beispiele aktuell und repräsentativ?

2.3 business_meaning Field

Einige business_meaning Felder könnten präziser sein.

Prüfen:

  • Ist der Business Value klar?
  • Wird erklärt, wer den Placeholder wofür nutzt (KI-Prompts? Charts? User Display?)?

2.4 minimum_data_requirements Field

Teilweise fehlen präzise Angaben zu Mindest-Datenmengen.

Prüfen:

  • Sind die Anforderungen quantifiziert? (z.B. "≥4/7 Messpunkte")
  • Ist klar, was passiert wenn Daten fehlen?

2.5 quality_filter_policy Field

Quality Filter Policy könnte präziser sein.

Prüfen:

  • Welche Daten werden ausgefiltert? (z.B. Duplikate, Outliers)
  • Gibt es Quality Thresholds?

3. Validation Report implementieren

Aktuell: Export hat leeres validation_report: {}

Aufgabe:

  • Validation Report Generator implementieren (placeholder_registry_export.py)
  • Automatische Prüfung auf:
    • Fehlende Pflichtfelder
    • Inkonsistente Units
    • Fehlende Evidence-Tags
    • Widersprüchliche Metadaten (z.B. time_window vs. data_layer_function Parameter)

Output-Format:

{
  "total_placeholders": 31,
  "valid": 28,
  "with_warnings": 3,
  "with_errors": 0,
  "issues": [
    {
      "placeholder": "weight_trend",
      "severity": "warning",
      "field": "time_window",
      "message": "time_window=28d but function accepts days parameter"
    }
  ]
}

4. Nutrition Cluster - UNRESOLVED Fields

Betroffen: 7 Nutrition Placeholders (nicht Body, aber für Vollständigkeit)

Felder: confidence_logic

Placeholders:

  • kcal_avg, protein_avg, carb_avg, fat_avg (Part A)
  • protein_ziel_low, protein_ziel_high, protein_g_per_kg (Part B)
  • protein_days_in_target, protein_adequacy_28d (Part B)

Aufgabe:

  • confidence_logic aus Code ableiten oder definieren
  • Evidence-Type auf CODE_DERIVED/MIXED ängen

Akzeptanzkriterien

  • Alle 17 Body Placeholders: layer_2b_reuse_possible verifiziert (keine TO_VERIFY mehr)
  • Alle 7 Nutrition Placeholders: confidence_logic aufgelöst (keine UNRESOLVED mehr)
  • Validation Report implementiert und funktionsfähig
  • Extended Export zeigt 0 kritische Issues
  • Metadaten-Lücken (description, example_output, business_meaning) geschlossen
  • Dokumentation aktualisiert (Implementation Report)

Aufwandsschätzung

  • Layer 2b Verifizierung: 2-3h (17 Placeholders analysieren + Chart-Code prüfen)
  • Nutrition confidence_logic: 1h (Code-Inspektion data_layer/nutrition_metrics.py)
  • Validation Report: 2-3h (Generator implementieren + Testing)
  • Metadaten-Lücken: 1-2h (Review + Ergänzungen)

Total: 6-9 Stunden

Abhängigkeiten

  • Body Cluster Registration (✅ DONE)
  • Nutrition Cluster Registration (✅ DONE)
  • Phase 0c Chart Endpoints (✅ DONE)

Referenzen

  • .claude/task/rework_0b_placeholder/BODY_CLUSTER_IMPLEMENTATION_REPORT.md
  • .claude/task/rework_0b_placeholder/BODY_EXPORT_VALIDATION.txt
  • backend/placeholder_registrations/body_metrics.py
  • backend/placeholder_registry_export.py
  • .claude/docs/technical/PLACEHOLDER_REGISTRY_FRAMEWORK.md

Nächste Schritte

  1. Issue erstellen in Gitea
  2. Priorisieren: Layer 2b Verifizierung ODER Validation Report zuerst?
  3. Code-Inspektion starten (Charts + Data Layer)
  4. Metadaten aktualisieren
  5. Testing & Final Report
# Body Cluster - Restarbeiten & Metadaten-Verifizierung **Status:** Body Cluster Registration komplett (17/17 Placeholders), aber Metadaten noch nicht final verifiziert **Priorität:** Medium **Labels:** placeholder-registry, phase-0c, documentation --- ## Zusammenfassung Die Body Cluster Implementation (17 Placeholders) ist technisch vollständig deployed und funktioniert. Allerdings weisen die Metadaten noch Lücken auf - insbesondere sind kritische Felder noch nicht verifiziert (TO_VERIFY) und benötigen Validation. --- ## Verbleibende Aufgaben ### 1. Layer 2b - Chart Assignment Verifizierung **Betroffen:** Alle 17 Body Placeholders **Feld:** `layer_2b_reuse_possible` **Aktueller Status:** TO_VERIFY **Aufgabe:** - Für jeden Placeholder prüfen, ob er für Chart-Endpoints (Layer 2b) wiederverwendet werden kann - Entscheidung dokumentieren (true/false + Begründung) - Evidence-Type auf CODE_DERIVED oder DRAFT_DERIVED ändern **Placeholders:** 1. weight_aktuell 2. weight_trend 3. weight_7d_median 4. weight_28d_slope 5. weight_90d_slope 6. kf_aktuell 7. fm_28d_change 8. lbm_28d_change 9. waist_hip_ratio 10. recomposition_quadrant 11. waist_28d_delta 12. arm_28d_delta 13. chest_28d_delta 14. hip_28d_delta 15. thigh_28d_delta 16. caliper_summary 17. circ_summary **Kontext:** - Phase 0c Multi-Layer Architecture definiert Layer 2b als Chart-Endpoints - Chart-Endpoints wurden bereits implementiert (E1-E5, A1-A8, R1-R5, C1-C4) - Frage: Können die registrierten Placeholder-Funktionen direkt für Charts genutzt werden? **Kriterien für Wiederverwendbarkeit:** - Ist die Datenstruktur Chart-kompatibel? - Liefert die Funktion genug Metadaten (confidence, data_points)? - Kann die Funktion Zeitfenster-Parameter akzeptieren? - Ist die Berechnung identisch mit Chart-Anforderungen? --- ### 2. Metadaten-Lücken schließen **Potenzielle Lücken (zu prüfen):** #### 2.1 description Field Einige Placeholders haben möglicherweise zu kurze/ungenaue Beschreibungen. **Prüfen:** - Ist die description ausreichend detailliert? - Erklärt sie den Use Case? - Unterscheidet sie sich klar von ähnlichen Placeholders? #### 2.2 example_output Field Nicht alle Placeholders haben realistische Beispiel-Outputs. **Prüfen:** - Fehlen Beispiele bei komplexen Outputs (Summaries, Quadrants)? - Sind die Beispiele aktuell und repräsentativ? #### 2.3 business_meaning Field Einige business_meaning Felder könnten präziser sein. **Prüfen:** - Ist der Business Value klar? - Wird erklärt, wer den Placeholder wofür nutzt (KI-Prompts? Charts? User Display?)? #### 2.4 minimum_data_requirements Field Teilweise fehlen präzise Angaben zu Mindest-Datenmengen. **Prüfen:** - Sind die Anforderungen quantifiziert? (z.B. "≥4/7 Messpunkte") - Ist klar, was passiert wenn Daten fehlen? #### 2.5 quality_filter_policy Field Quality Filter Policy könnte präziser sein. **Prüfen:** - Welche Daten werden ausgefiltert? (z.B. Duplikate, Outliers) - Gibt es Quality Thresholds? --- ### 3. Validation Report implementieren **Aktuell:** Export hat leeres validation_report: {} **Aufgabe:** - Validation Report Generator implementieren (placeholder_registry_export.py) - Automatische Prüfung auf: - Fehlende Pflichtfelder - Inkonsistente Units - Fehlende Evidence-Tags - Widersprüchliche Metadaten (z.B. time_window vs. data_layer_function Parameter) **Output-Format:** ```json { "total_placeholders": 31, "valid": 28, "with_warnings": 3, "with_errors": 0, "issues": [ { "placeholder": "weight_trend", "severity": "warning", "field": "time_window", "message": "time_window=28d but function accepts days parameter" } ] } ``` --- ### 4. Nutrition Cluster - UNRESOLVED Fields **Betroffen:** 7 Nutrition Placeholders (nicht Body, aber für Vollständigkeit) **Felder:** confidence_logic **Placeholders:** - kcal_avg, protein_avg, carb_avg, fat_avg (Part A) - protein_ziel_low, protein_ziel_high, protein_g_per_kg (Part B) - protein_days_in_target, protein_adequacy_28d (Part B) **Aufgabe:** - confidence_logic aus Code ableiten oder definieren - Evidence-Type auf CODE_DERIVED/MIXED ängen --- ## Akzeptanzkriterien - [ ] Alle 17 Body Placeholders: layer_2b_reuse_possible verifiziert (keine TO_VERIFY mehr) - [ ] Alle 7 Nutrition Placeholders: confidence_logic aufgelöst (keine UNRESOLVED mehr) - [ ] Validation Report implementiert und funktionsfähig - [ ] Extended Export zeigt 0 kritische Issues - [ ] Metadaten-Lücken (description, example_output, business_meaning) geschlossen - [ ] Dokumentation aktualisiert (Implementation Report) --- ## Aufwandsschätzung - Layer 2b Verifizierung: **2-3h** (17 Placeholders analysieren + Chart-Code prüfen) - Nutrition confidence_logic: **1h** (Code-Inspektion data_layer/nutrition_metrics.py) - Validation Report: **2-3h** (Generator implementieren + Testing) - Metadaten-Lücken: **1-2h** (Review + Ergänzungen) **Total: 6-9 Stunden** --- ## Abhängigkeiten - Body Cluster Registration (✅ DONE) - Nutrition Cluster Registration (✅ DONE) - Phase 0c Chart Endpoints (✅ DONE) --- ## Referenzen - `.claude/task/rework_0b_placeholder/BODY_CLUSTER_IMPLEMENTATION_REPORT.md` - `.claude/task/rework_0b_placeholder/BODY_EXPORT_VALIDATION.txt` - `backend/placeholder_registrations/body_metrics.py` - `backend/placeholder_registry_export.py` - `.claude/docs/technical/PLACEHOLDER_REGISTRY_FRAMEWORK.md` --- ## Nächste Schritte 1. Issue erstellen in Gitea 2. Priorisieren: Layer 2b Verifizierung ODER Validation Report zuerst? 3. Code-Inspektion starten (Charts + Data Layer) 4. Metadaten aktualisieren 5. Testing & Final Report
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#56
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?