mitai-jinkendo/docs/TODO_GOAL_SYSTEM.md
Lars 043bed4323
All checks were successful
Deploy Development / deploy (push) Successful in 50s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 13s
docs: Phase 1.5 complete - update roadmap
Phase 1.5 (Flexible Goal System) erfolgreich abgeschlossen:
- 8h Aufwand (geplant 8-12h)
- Alle Tasks 
- System vollständig flexibel
- Phase 0b ready to start

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-27 06:52:18 +01:00

9.1 KiB

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 KOMPLETT (27.03.2026)

Status: ABGESCHLOSSEN Priorität: CRITICAL (blockt Phase 0b) Aufwand: 8h (geplant 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 migriert
  • 🔲 Testing: Alle Goals + Custom Goal erstellen (NEXT)

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: 🔲 BEREIT ZUM START (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) DONE 8h
Phase 0b Goal-Aware Placeholders 🔲 READY 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 ABGESCHLOSSEN) Nächste Aktualisierung: Nach Phase 0b Completion


🎉 Phase 1.5 Completion Report (27.03.2026)

Commits:

  • 65ee5f8 - Phase 1.5 Part 1/2 (Backend, Migration, Universal Fetcher)
  • 640ef81 - Phase 1.5 Part 2/2 (Frontend Dynamic, Admin UI) - COMPLETE

Implementiert:

  1. DB-Registry für Goal Types (8 System Types seeded)
  2. Universal Value Fetcher (8 Aggregationsmethoden)
  3. CRUD API (admin-only, System Types geschützt)
  4. Dynamic Frontend (keine hardcoded Types mehr)
  5. Admin UI (vollständiges CRUD Interface)

System ist jetzt flexibel:

  • Neue Goal Types via UI ohne Code-Deploy
  • Phase 0b Platzhalter nutzen automatisch alle Types
  • Custom Metrics möglich (Meditation, Rituale, etc.)

Ready für Phase 0b: 120+ Goal-Aware Placeholders 🚀