mitai-jinkendo/docs/TODO_GOAL_SYSTEM.md

Goal System - TODO & Offene Punkte

Erstellt: 27. März 2026 Status: Aktiv Zweck: Zentrale Tracking-Liste für Goal System Entwicklung

---

✅ Erledigt (27.03.2026)

Phase 0a: Minimal Goal System (26.03.2026)

• ✅ Migration 022 (goal_mode, goals, training_phases, fitness_tests)
• ✅ Backend Router goals.py (490 Zeilen)
• ✅ Frontend GoalsPage (570 Zeilen)
• ✅ Navigation Integration (Dashboard + Analysis)

Phase 1: Quick Fixes (27.03.2026)

• ✅ goal_utils.py Abstraction Layer
• ✅ Primary Goal Toggle Fix
• ✅ Lean Mass Berechnung
• ✅ VO2Max Spaltenname Fix

---

🔲 Nächste Schritte (Priorität)

Phase 1.5: Flexibles Goal System - DB-Registry (NEXT - 8-12h) 🆕

Status: 🔲 IN ARBEIT Priorität: CRITICAL (blockt Phase 0b) Aufwand: 8-12h Entscheidung: 27.03.2026 - Option B gewählt

Problem:

• Aktuelles System: Hardcoded goal types (nur 8 Typen möglich)
• Jedes neue Ziel braucht Code-Änderung + Deploy
• Zukünftige Ziele (Meditation, Rituale, Planabweichung) nicht möglich

Lösung: DB-Registry

• Goal Types in Datenbank definiert
• Admin UI: Neue Ziele ohne Code erstellen
• Universal Value Fetcher (konfigurierbar)
• User kann eigene Custom-Metriken definieren

Tasks:

• Migration 024: goal_type_definitions Tabelle
• Backend: Universal Value Fetcher (_fetch_latest, _fetch_avg, _fetch_count)
• Backend: CRUD API für Goal Type Definitions
• Frontend: Dynamisches Goal Types Dropdown
• Admin UI: Goal Type Management Page
• Seed Data: 8 existierende Typen migrieren
• Testing: Alle Goals + Custom Goal erstellen

Warum JETZT (vor Phase 0b)?

• Phase 0b Platzhalter nutzen Goals für Score-Berechnungen
• Flexible Goals → automatisch in Platzhaltern verfügbar
• Später umbauen = 120+ Platzhalter anpassen (Doppelarbeit)

Dokumentation: Siehe unten "Flexibles Goal System Details"

---

Phase 0b: Goal-Aware Placeholders (NACH 1.5 - 16-20h)

Status: 🔲 WARTET AUF PHASE 1.5 Priorität: HIGH (strategisch kritisch) Aufwand: 16-20h Blockt: Intelligente KI-Analysen

Tasks:

• 18 KÖRPER Platzhalter (weight_7d_rolling_median, fm_28d_delta, lbm_28d_delta, recomposition_score, etc.)
• 15 ERNÄHRUNG Platzhalter (protein_g_per_kg, nutrition_adherence_score, energy_availability_status, etc.)
• 25 AKTIVITÄT Platzhalter (activity_quality_avg_28d, activity_strain_28d, ability_balance_score, etc.)
• 12 RECOVERY Platzhalter (recovery_score, sleep_regularity_index, sleep_debt_hours, etc.)
• 8 KORRELATIONEN Platzhalter (corr_energy_weight_lag, plateau_detected, etc.)
• 6 META Platzhalter (goal_mode, data_quality_score, profile_age_years, etc.)
• Score-Gewichtung pro goal_mode (SCORE_WEIGHTS Dictionary)
• Baseline-Berechnungen (7d/28d/90d Referenzwerte)
• Integration in bestehende Prompts

Vorteile:

• System wird "intelligent" (kein Datensammler mehr)
• Ziele werden tatsächlich genutzt
• Basis für automatische Trainingsphasen-Erkennung

Dokumentation: docs/NEXT_STEPS_2026-03-26.md (Zeile 116-300)

---

v2.0 Redesign (SPÄTER - 8-10h)

Status: 📋 KONZEPTION Priorität: MEDIUM (nach Phase 0b & User-Feedback) Aufwand: 8-10h (dank Abstraction Layer)

Probleme zu lösen:

1. ❌ Primärziel zu simplistisch (nur 1 erlaubt)
2. ❌ Goal Mode zu simpel (nur 1 Modus wählbar)
3. ✅ Fehlende Current Values (ERLEDIGT in Phase 1)
4. ❌ Abstrakte Zieltypen (strength, flexibility)
5. ❌ Blutdruck braucht 2 Werte (systolisch/diastolisch)
6. ❌ Keine Guidance für User (Richtwerte fehlen)

Lösung:

• Migration 023: focus_areas Tabelle mit Gewichtungssystem
• UI: Slider für 6 Fokus-Bereiche (Summe = 100%)
• Backend: get_focus_weights() V2 Implementierung (eine Funktion!)
• Compound Goals für BP
• Konkrete Test-basierte Goals (Cooper, Plank, etc.)
• Richtwerte & Normen in UI

Dokumentation: docs/GOAL_SYSTEM_REDESIGN_v2.md

Entscheidung: ⏳ Wartet auf User-Feedback nach Phase 0b

---

🔗 Verwandte Issues

Gitea (http://192.168.2.144:3000/Lars/mitai-jinkendo/issues)

• #49: Prompt-Zuordnung zu Verlaufsseiten (6-8h, Quick Win)
• #47: Wertetabelle Optimierung (4-6h, Polishing)
• #50: Phase 0a Goal System (✅ CLOSED)

Interne Docs

• docs/issues/issue-50-phase-0a-goal-system.md (✅ Completed)
• docs/issues/issue-51-prompt-page-assignment.md (#49 Spec)

---

📊 Roadmap-Übersicht

Phase	Was	Status	Aufwand
Phase 0a	Minimal Goal System	✅ DONE	3-4h
Phase 1	Quick Fixes + Abstraction	✅ DONE	4-6h
Phase 1.5	🆕 Flexibles Goal System (DB-Registry)	🔲 IN ARBEIT	8-12h
Phase 0b	Goal-Aware Placeholders	🔲 BLOCKED	16-20h
Issue #49	Prompt Page Assignment	🔲 OPEN	6-8h
v2.0	Redesign (Focus Areas)	📋 LATER	8-10h

Total Roadmap: ~45-60h bis vollständiges intelligentes Goal System

KRITISCH: Phase 1.5 MUSS vor Phase 0b abgeschlossen sein, sonst Doppelarbeit!

---

💡 Wichtige Notizen

Abstraction Layer (Keine Doppelarbeit!)

Datei: backend/goal_utils.py

get_focus_weights(conn, profile_id)

• V1 (jetzt): Mappt goal_mode → Gewichte
• V2 (v2.0): Liest focus_areas Tabelle
• Vorteil: 120+ Phase 0b Platzhalter müssen NICHT umgeschrieben werden

Testing Checklist (nach jedem Deploy)

• Goal Mode ändern → Gewichtung korrekt?
• Primäres Ziel setzen → Andere auf false?
• Lean Mass Ziel → Current Value berechnet?
• VO2Max Ziel → Kein Server Error?
• Mehrere Ziele → Progress korrekt?

---

📅 Timeline

Datum	Event
26.03.2026	Phase 0a Complete
27.03.2026	Phase 1 Complete (Quick Fixes)
28.03.2026	Phase 0b Start (geplant)
02.04.2026	Phase 0b Complete (geschätzt bei 4h/Tag)
04.04.2026	v2.0 Redesign (wenn validiert)

---

🔧 Flexibles Goal System - Technische Details

Architektur: DB-Registry Pattern

Vorher (Phase 0a/1):

// Frontend: Hardcoded
const GOAL_TYPES = {
  weight: { label: 'Gewicht', unit: 'kg', icon: '⚖️' }
}

// Backend: Hardcoded if/elif
if goal_type == 'weight':
    cur.execute("SELECT weight FROM weight_log...")
elif goal_type == 'body_fat':
    cur.execute("SELECT body_fat_pct FROM caliper_log...")

Nachher (Phase 1.5):

-- Datenbank: Konfigurierbare Goal Types
CREATE TABLE goal_type_definitions (
    type_key VARCHAR(50) UNIQUE,
    label_de VARCHAR(100),
    unit VARCHAR(20),
    icon VARCHAR(10),
    category VARCHAR(50),
    source_table VARCHAR(50),
    source_column VARCHAR(50),
    aggregation_method VARCHAR(20),  -- latest, avg_7d, count_7d, etc.
    calculation_formula TEXT,        -- JSON für komplexe Berechnungen
    is_system BOOLEAN                -- System-Typen nicht löschbar
);

# Backend: Universal Fetcher
def get_current_value_for_goal(conn, profile_id, goal_type):
    """Liest Config aus DB, führt Query aus"""
    config = get_goal_type_config(conn, goal_type)

    if config['calculation_formula']:
        return execute_formula(conn, profile_id, config['calculation_formula'])
    else:
        return fetch_by_method(
            conn, profile_id,
            config['source_table'],
            config['source_column'],
            config['aggregation_method']
        )

// Frontend: Dynamisch
const goalTypes = await api.getGoalTypeDefinitions()
// Lädt aktuell verfügbare Typen von API

Vorteile:

Flexibilität:

• ✅ Neue Ziele via Admin UI (KEIN Code-Deploy)
• ✅ User kann Custom-Metriken definieren
• ✅ Zukünftige Module automatisch integriert

Beispiele neuer Ziele:

• 🧘 Meditation (min/Tag) → meditation_log.duration_minutes, avg_7d
• 📅 Trainingshäufigkeit (x/Woche) → activity_log.id, count_7d
• 📊 Planabweichung (%) → activity_log.planned_vs_actual, avg_30d
• 🎯 Ritual-Adherence (%) → rituals_log.completed, avg_30d
• 💤 Schlafqualität (%) → sleep_log.quality_score, avg_7d

Integration mit Phase 0b:

• Platzhalter nutzen get_current_value_for_goal() → automatisch alle Typen verfügbar
• Neue Ziele → sofort in KI-Analysen nutzbar
• Keine Platzhalter-Anpassungen nötig

---

Letzte Aktualisierung: 27. März 2026 (Phase 1.5 gestartet) Nächste Aktualisierung: Nach Phase 1.5 Completion