Commit Graph

302 Commits

Author SHA1 Message Date
92cc309489 feat: relative weight sliders for focus areas
All checks were successful
Deploy Development / deploy (push) Successful in 44s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 13s
Improved UX for focus area configuration:
- Sliders now use relative weights (0-10) instead of percentages
- System automatically normalizes to percentages (sum=100%)
- Live preview shows "weight → percent%" (e.g., "5 → 50%")
- No more manual balancing required from user

User sets: Kraft=5, Ausdauer=3, Flexibilität=2
System calculates: 50%, 30%, 20%

Addresses user feedback: "Summe muss 100% sein" not user-friendly

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-27 12:10:56 +01:00
1fdf91cb50 fix: Migration 027 - health mode missing dimensions
All checks were successful
Deploy Development / deploy (push) Successful in 51s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 13s
Fixed health mode calculation to include all 6 dimensions.
Simplified CASE statements (single CASE instead of multiple additions).

Before: health mode only set flexibility (15%) + health (55%) = 70% 
After:  health mode sets all dimensions = 100% 
  - weight_loss: 5%
  - muscle_gain: 0%
  - strength: 10%
  - endurance: 20%
  - flexibility: 15%
  - health: 50%

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-27 10:56:53 +01:00
80d57918ae fix: Migration 027 constraint violation - health mode sum
All checks were successful
Deploy Development / deploy (push) Successful in 48s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 14s
Fixed health mode calculation in focus_areas migration.
Changed health_pct from 50 to 55 to ensure sum equals 100%.

Before: 0+0+10+20+15+50 = 95% (constraint violation)
After:  0+0+10+20+15+55 = 100% (valid)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-27 10:53:39 +01:00
d97925d5a1 feat: Focus Areas Slider UI (Goal System v2.0 complete)
All checks were successful
Deploy Development / deploy (push) Successful in 47s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 14s
Replaces single goal mode cards with weighted multi-focus system

UI Features:
- 6 sliders for focus dimensions (5% increments)
- Live sum calculation with visual feedback
- Validation: Sum must equal 100%
- Color-coded sliders per dimension
- Edit/Display mode toggle
- Shows derived values if not customized

UX Flow:
1. Default: Shows focus distribution (bars)
2. Click 'Anpassen': Shows sliders
3. Adjust percentages (sum = 100%)
4. Save → Updates backend + reloads

Visual:
- Active dimensions shown as colored cards (display mode)
- Gradient sliders with percentage labels (edit mode)
- Green box when sum = 100%, red when != 100%
- Info message if derived from old goal_mode

Complete v2.0:
 Backend (Migration 027, API, get_focus_weights V2)
 Frontend (Slider UI, state management, validation)
 Auto-migration (goal_mode → focus_areas)

Ready for: KI-Integration with weighted scoring
2026-03-27 10:36:42 +01:00
4a11d20c4d feat: Goal System v2.0 - Focus Areas with weighted priorities
All checks were successful
Deploy Development / deploy (push) Successful in 46s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 14s
BREAKING: Replaces single 'primary goal' with weighted multi-goal system

Migration 027:
- New table: focus_areas (6 dimensions with percentages)
- Constraint: Sum must equal 100%
- Auto-migration: goal_mode → focus_areas for existing users
- Unique constraint: One active focus_areas per profile

Backend:
- get_focus_weights() V2: Reads from focus_areas table
- Fallback: Uses goal_mode if focus_areas not set
- New endpoints: GET/PUT /api/goals/focus-areas
- Validation: Sum=100, range 0-100

API:
- getFocusAreas() - Get current weights
- updateFocusAreas(data) - Update weights (upsert)

Focus dimensions:
1. weight_loss_pct   (Fettabbau)
2. muscle_gain_pct   (Muskelaufbau)
3. strength_pct      (Kraftsteigerung)
4. endurance_pct     (Ausdauer)
5. flexibility_pct   (Beweglichkeit)
6. health_pct        (Allgemeine Gesundheit)

Benefits:
- Multiple goals with custom priorities
- More flexible than single primary goal
- KI can use weighted scores
- Ready for Phase 0b placeholder integration

UI: Coming in next commit (slider interface)
2026-03-27 08:38:03 +01:00
2303c04123 feat: filtered goal types - count specific training types
All checks were successful
Deploy Development / deploy (push) Successful in 49s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 14s
NEW FEATURE: Filter conditions for goal types
Enables counting/aggregating specific subsets of data.

Example use case: Count only strength training sessions per week
- Create goal type with filter: {"training_type": "strength"}
- count_7d now counts only strength training, not all activities

Implementation:
- Migration 026: filter_conditions JSONB column
- Backend: Dynamic WHERE clause building from JSON filters
- Supports single value: {"training_type": "strength"}
- Supports multiple values: {"training_type": ["strength", "hiit"]}
- Works with all 8 aggregation methods (count, avg, sum, min, max)
- Frontend: JSON textarea with example + validation
- Pydantic models: filter_conditions field added

Technical details:
- SQL injection safe (parameterized queries)
- Graceful degradation (invalid JSON ignored with warning)
- Backward compatible (NULL filters = no filtering)

Answers user question: 'Kann ich Trainingstypen wie Krafttraining separat zählen?'
Answer: YES! 🎯
2026-03-27 08:14:22 +01:00
2c978bf948 feat: dynamic schema dropdowns for goal type admin UI
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 14s
Admin can now easily create custom goal types:
- New endpoint /api/goals/schema-info with table/column metadata
- 9 tables documented (weight, caliper, activity, nutrition, sleep, vitals, BP, rest_days, circumference)
- Table dropdown with descriptions (e.g., 'activity_log - Trainingseinheiten')
- Column dropdown dependent on selected table
- All columns documented in German with data types
- Fields optional (for complex calculation formulas)

UX improvements:
- No need to guess table/column names
- Clear descriptions for each field
- Type-safe selection (no typos)
- Cascading dropdowns (column depends on table)

Closes user feedback: 'Admin weiß nicht welche Tabellen/Spalten verfügbar sind'
2026-03-27 08:05:45 +01:00
210671059a debug: comprehensive error handling and logging for list_goals
All checks were successful
Deploy Development / deploy (push) Successful in 45s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 13s
- try-catch around entire endpoint
- try-catch for each goal progress update
- Detailed error logging with traceback
- Continue processing other goals if one fails
- Clear error message to frontend

This will show exact error location in logs.
2026-03-27 07:58:56 +01:00
1f4ee5021e fix: robust error handling in goal value fetcher
All checks were successful
Deploy Development / deploy (push) Successful in 44s
Build Test / lint-backend (push) Successful in 1s
Build Test / build-frontend (push) Successful in 13s
Prevents crashes when:
- Goal types have NULL source_table/column (lean_mass, inactive placeholders)
- Old goals reference inactive goal types
- SQL queries fail for any reason

Changes:
- Guard clause checks table/column before SQL
- try-catch wraps all aggregation queries
- Returns None gracefully instead of crashing endpoint
- Logs warnings for debugging

Fixes: Goals page not loading due to /api/goals/list crash
2026-03-27 07:55:19 +01:00
1e758696fd feat: Migration 025 - automatic cleanup and seed for goal_type_definitions
All checks were successful
Deploy Development / deploy (push) Successful in 46s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 14s
Fixes cases where Migration 024 partially ran:
- Removes created_by/updated_by columns if they exist
- Re-inserts seed data with ON CONFLICT DO NOTHING
- Fully automated, no manual intervention needed
- Production-safe (idempotent)

This ensures clean deployment to production without manual DB changes.
2026-03-27 07:49:09 +01:00
a039a0fad3 fix: Migration 024 - remove problematic FK constraints created_by/updated_by
Some checks failed
Build Test / lint-backend (push) Waiting to run
Build Test / build-frontend (push) Waiting to run
Deploy Development / deploy (push) Has been cancelled
Goal type definitions are global system entities, not user-specific.
System types seeded in migration cannot have created_by FK.

Changes:
- Remove created_by/updated_by columns from goal_type_definitions
- Update CREATE/UPDATE endpoints to not use these fields
- Migration now runs cleanly on container start
- No manual intervention needed for production deployment
2026-03-27 07:48:23 +01:00
b3cc588293 fix: make Migration 024 idempotent + add seed data fix script
All checks were successful
Deploy Development / deploy (push) Successful in 50s
Build Test / lint-backend (push) Successful in 1s
Build Test / build-frontend (push) Successful in 14s
2026-03-27 07:40:42 +01:00
c9e4b6aa02 debug: diagnostic script for Migration 024 state 2026-03-27 07:39:18 +01:00
8be87bfdfb fix: Remove broken table_exists check
All checks were successful
Deploy Development / deploy (push) Successful in 48s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 13s
Removed faulty EXISTS check that was causing "0" error.
Added debug logging and better error messages.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-27 07:34:29 +01:00
484c25575d feat: manual migration 024 runner script
All checks were successful
Deploy Development / deploy (push) Successful in 44s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 13s
Allows running Migration 024 manually if auto-migration failed.

Usage: python backend/run_migration_024.py

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-27 07:28:43 +01:00
bbee44ecdc fix: Better error handling for goal types loading
Some checks failed
Build Test / lint-backend (push) Waiting to run
Build Test / build-frontend (push) Waiting to run
Deploy Development / deploy (push) Has been cancelled
- Check if goal_type_definitions table exists
- Detailed error messages
- Fallback if goalTypes is empty
- Prevent form opening without types

Helps debugging Migration 024 issues.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-27 07:28:14 +01:00
043bed4323 docs: Phase 1.5 complete - update roadmap
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
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
640ef81257 feat: Phase 1.5 - Flexible Goal System (DB-Registry) Part 2/2 - COMPLETE
Some checks failed
Build Test / lint-backend (push) Waiting to run
Build Test / build-frontend (push) Waiting to run
Deploy Development / deploy (push) Has been cancelled
Frontend dynamic goal types + Admin UI komplett implementiert.

Frontend GoalsPage:
- HARDCODED GOAL_TYPES entfernt
- Dynamic loading von goal_type_definitions via API
- goalTypes state + goalTypesMap für quick lookup
- Dropdown zeigt alle aktiven Types aus DB
- Vollständig flexibel - neue Types sofort verfügbar

Admin UI:
- AdminGoalTypesPage.jsx (400+ Zeilen)
  → Übersicht aller Goal Types (System + Custom)
  → Create/Edit/Delete Forms
  → CRUD via api.js (admin-only)
  → Validierung: System Types nur deaktivierbar, nicht löschbar
  → 8 Aggregationsmethoden im Dropdown
  → Category-Auswahl (body, mind, activity, nutrition, recovery, custom)
- Route registriert: /admin/goal-types
- Import in App.jsx

Phase 1.5 KOMPLETT:
 Migration 024 (goal_type_definitions)
 Universal Value Fetcher (goal_utils.py)
 CRUD API (goals.py)
 Frontend Dynamic Dropdown (GoalsPage.jsx)
 Admin UI (AdminGoalTypesPage.jsx)

System ist jetzt VOLLSTÄNDIG FLEXIBEL:
- Neue Goal Types via Admin UI ohne Code-Deploy
- Beispiele: Meditation, Trainingshäufigkeit, Planabweichung
- Phase 0b Platzhalter können alle Types nutzen
- Keine Doppelarbeit bei v2.0 Redesign

Nächster Schritt: Testing + Phase 0b (120+ Platzhalter)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-27 06:51:46 +01:00
65ee5f898f feat: Phase 1.5 - Flexible Goal System (DB-Registry) Part 1/2
All checks were successful
Deploy Development / deploy (push) Successful in 43s
Build Test / lint-backend (push) Successful in 1s
Build Test / build-frontend (push) Successful in 13s
KRITISCHE ARCHITEKTUR-ÄNDERUNG vor Phase 0b:
Ermöglicht dynamische Goal Types ohne Code-Änderungen.

Backend:
- Migration 024: goal_type_definitions Tabelle
  → 8 existierende Typen als Seed-Data migriert
  → Flexible Schema: source_table, aggregation_method, calculation_formula
  → System vs. Custom Types (is_system flag)
- goal_utils.py: Universal Value Fetcher
  → get_current_value_for_goal() ersetzt hardcoded if/elif chain
  → Unterstützt: latest, avg_7d, avg_30d, sum_30d, count_7d, etc.
  → Komplexe Formeln (lean_mass) via calculation_formula JSON
- goals.py: CRUD API für Goal Type Definitions
  → GET /goals/goal-types (public)
  → POST/PUT/DELETE /goals/goal-types (admin-only)
  → Schutz für System-Types (nicht löschbar)
- goals.py: _get_current_value_for_goal_type() delegiert zu Universal Fetcher

Frontend:
- api.js: 4 neue Funktionen (listGoalTypeDefinitions, create, update, delete)

Dokumentation:
- TODO_GOAL_SYSTEM.md: Phase 1.5 hinzugefügt, Roadmap aktualisiert

Part 2/2 (nächster Commit):
- Frontend: Dynamic Goal Types Dropdown
- Admin UI: Goal Type Management Page
- Testing

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

Zukünftige Custom Goals möglich:
- 🧘 Meditation (min/Tag)
- 📅 Trainingshäufigkeit (x/Woche)
- 📊 Planabweichung (%)
- 🎯 Ritual-Adherence (%)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-27 06:45:05 +01:00
27a8af7008 debug: Add logging and warnings for Goal System issues
All checks were successful
Deploy Development / deploy (push) Successful in 47s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 13s
Based on test feedback - 3 issues addressed:

1. Primary Toggle (Frontend Debug):
   - Add console.log in handleSaveGoal
   - Shows what data is sent to backend
   - Helps debug if checkbox state is correct

2. Lean Mass Display (Backend Debug):
   - Add error handling in lean_mass calculation
   - Log why calculation fails (missing weight/bf data)
   - Try-catch for value conversion errors

3. BP/Strength/Flexibility Warning (UI):
   - Yellow warning box for incomplete goal types
   - BP: "benötigt 2 Werte (geplant für v2.0)"
   - Strength/Flexibility: "Keine Datenquelle"
   - Transparent about limitations

Next: User re-tests with debug output to identify root cause.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-27 06:24:40 +01:00
14d80fc903 docs: zentrale TODO-Liste für Goal System erstellt
All checks were successful
Deploy Development / deploy (push) Successful in 51s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 13s
Tracking-Dokument für alle offenen Punkte:
- Phase 0b Tasks (120+ Platzhalter)
- v2.0 Redesign Probleme
- Gitea Issues Referenzen
- Timeline & Roadmap

Verhindert dass wichtige Punkte vergessen werden.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-27 06:17:57 +01:00
87464ff138 fix: Phase 1 - Goal System Quick Fixes + Abstraction Layer
All checks were successful
Deploy Development / deploy (push) Successful in 53s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 14s
Behebt 4 kritische Bugs in Phase 0a und schafft Basis für Phase 0b
ohne spätere Doppelarbeit.

Backend:
- NEW: goal_utils.py mit get_focus_weights() Abstraction Layer
  → V1: Mappt goal_mode zu Gewichten
  → V2 (später): Liest aus focus_areas Tabelle
  → Phase 0b Platzhalter (120+) müssen NICHT umgeschrieben werden
- FIX: Primary goal toggle in goals.py (is_primary im GoalUpdate Model)
  → Beim Update auf primary werden andere Goals korrekt auf false gesetzt
- FIX: lean_mass current_value Berechnung implementiert
  → weight - (weight * body_fat_pct / 100)
- FIX: VO2Max Spaltenname vo2_max (statt vo2max)
  → Internal Server Error behoben

CLAUDE.md:
- Version Update: Phase 1 Fixes (27.03.2026)

Keine Doppelarbeit:
- Alle zukünftigen Phase 0b Platzhalter nutzen get_focus_weights()
- v2.0 Redesign = nur eine Funktion ändern, nicht 120+ Platzhalter

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-27 06:13:47 +01:00
e3f1e399c2 docs: Goal System Redesign v2.0 - comprehensive concept
All checks were successful
Deploy Development / deploy (push) Successful in 46s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 14s
Created comprehensive redesign document addressing all identified issues:

Problems addressed:
1. Primary goal too simplistic → Weight system (0-100%)
2. Single goal mode too simple → Multi-mode with weights
3. Missing current values → All goal types with data sources
4. Abstract goal types → Concrete, measurable goals
5. Blood pressure single value → Compound goals (systolic/diastolic)
6. No user guidance → Norms, examples, age-specific values

New Concept:
- Focus Areas: Weighted distribution (30% weight loss + 25% endurance + ...)
- Goal Weights: Each goal has individual weight (not binary primary/not)
- Concrete Goal Types: cooper_test, pushups_max, squat_1rm, etc.
- Compound Goals: Support for multi-value targets (BP: 120/80)
- Guidance System: Age/gender-specific norms and examples

Schema Changes:
- New table: focus_areas (replaces single goal_mode)
- goals: Add goal_weight, target_value_secondary, current_value_secondary
- goals: Remove is_primary (replaced by weight)

UI/UX Redesign:
- Slider interface for focus areas (must sum to 100%)
- Goal editor with guidance and norms
- Weight indicators on all goals
- Special UI for compound goals

Implementation Phases: 16-21h total
- Phase 2: Backend Redesign (6-8h)
- Phase 3: Frontend Redesign (8-10h)
- Phase 4: Testing & Refinement (2-3h)

Status: WAITING FOR USER FEEDBACK & APPROVAL

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-26 22:05:05 +01:00
3dd10d3dc7 docs: Phase 0a completion - comprehensive documentation
All checks were successful
Deploy Development / deploy (push) Successful in 51s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 14s
CLAUDE.md:
- Version updated to v9e+ (Phase 0a Goal System Complete)
- Added Phase 0a feature section with full details
- Updated 'Letzte Updates' with Phase 0a completion
- Links to new documentation files

docs/issues/issue-50-phase-0a-goal-system.md (NEW):
- Complete Phase 0a implementation documentation
- Technical details: Migration 022, goals.py, GoalsPage
- 4 commits documented (337667f to 5be52bc)
- Lessons learned section
- Basis for Phase 0b documented
- Testing checklist + acceptance criteria

docs/NEXT_STEPS_2026-03-26.md (NEW):
- Comprehensive planning document
- Option A: Issue #49 - Prompt Page Assignment (6-8h)
- Option B: Phase 0b - Goal-Aware Placeholders (16-20h)
- Option C: Issue #47 - Value Table Refinement (4-6h)
- Recommendation: Szenario 1 (Quick Wins first)
- Detailed technical breakdown for both options
- Timeline estimates (4h/day vs 8h/day)
- 120+ placeholder categorization for Phase 0b

All documentation reflects current state post Phase 0a.
Next decision: Choose between Issue #49 or Phase 0b.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-26 21:49:07 +01:00
5be52bcfeb feat: goals navigation + UX improvements
All checks were successful
Deploy Development / deploy (push) Successful in 44s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 14s
Analysis Page:
- Add 'Ziele' button next to page title
- Direct navigation to /goals from analysis page
- Thematic link: goals influence AI analysis weighting

Goals Page:
- Fix text-align for text inputs (name, date, description)
- Text fields now left-aligned (numbers remain right-aligned)
- Better UX for non-numeric inputs

Navigation strategy: Goals accessible from Analysis page where
goal_mode directly impacts score calculation and interpretation.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-26 16:50:22 +01:00
75f0a5dd6e refactor: mobile-friendly goal form design
All checks were successful
Deploy Development / deploy (push) Successful in 46s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 13s
- Full-width inputs throughout the form
- Labels above inputs (mobile best practice)
- Section headers with emoji (🎯 Zielwert)
- Consistent spacing (marginBottom: 16)
- Read-only unit display as styled badge
- Primary goal checkbox in highlighted section
- Full-width buttons (btn-full class)
- Scrollable modal with top padding
- Error display above form

Matches VitalsPage design pattern for consistency.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-26 16:32:37 +01:00
906a3b7cdd fix: Migration 022 - remove invalid schema_migrations tracking
All checks were successful
Deploy Development / deploy (push) Successful in 47s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 13s
The migration system tracks migrations via filename automatically.
Removed manual DO block that used wrong column name (version vs filename).

Also removed unused json import from goals.py.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-26 16:26:48 +01:00
337667fc07 feat: Phase 0a - Minimal Goal System (Strategic + Tactical)
All checks were successful
Deploy Development / deploy (push) Successful in 51s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 14s
- Strategic Layer: Goal modes (weight_loss, strength, endurance, recomposition, health)
- Tactical Layer: Concrete goal targets with progress tracking
- Training phases (manual + auto-detection framework)
- Fitness tests (standardized performance tracking)

Backend:
- Migration 022: goal_mode in profiles, goals, training_phases, fitness_tests tables
- New router: routers/goals.py with full CRUD for goals, phases, tests
- API endpoints: /api/goals/* (mode, list, create, update, delete)

Frontend:
- GoalsPage: Goal mode selector + goal management UI
- Dashboard: Goals preview card with link
- API integration: goal mode, CRUD operations, progress calculation

Basis for 120+ placeholders and goal-aware analyses (Phase 0b)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-26 16:20:35 +01:00
ae93b9d428 docs: goal system priority analysis - hybrid approach
All checks were successful
Deploy Development / deploy (push) Successful in 47s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 14s
Key Decision: Minimal Goal System BEFORE Placeholders

Critical Finding:
- Same data = different interpretation per goal
- Example: -5kg FM, -2kg LBM
  - weight_loss: 78/100 (good!)
  - strength: 32/100 (LBM loss critical!)
  - Without goal: 50/100 (generic, wrong for both)

Recommended Approach (Hybrid):
1. Phase 0a (2-3h): Minimal Goal System
   - DB: goal_mode field
   - API: Get/Set Goal
   - UI: Goal Selector
   - Default: health

2. Phase 0b (16-20h): Goal-Aware Placeholders
   - 84 placeholders with goal-dependent calculations
   - Scores use goal_mode from day 1
   - No rework needed later

3. Phase 2+ (6-8h): Full Goal System
   - Goal recognition from patterns
   - Secondary goals
   - Goal progression tracking

Why Hybrid Works:
 Charts show correct interpretations immediately
 No rework of 84 placeholders later
 Goal recognition can come later (needs placeholders anyway)
 System is "smart coach" from day 1

File: docs/GOAL_SYSTEM_PRIORITY_ANALYSIS.md (650 lines)
2026-03-26 16:08:00 +01:00
8398368ed7 docs: comprehensive functional concept analysis
All checks were successful
Deploy Development / deploy (push) Successful in 44s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 14s
Analysis Results:
- 84 new placeholders needed from Fachkonzept
- Issues #26 & #27 too narrow (complementary, not conflicting)
- Recommend 4-phase approach: Placeholders → Charts → Rules → KI
- Transform: Data Collector → Active Coach

Key Findings:
- Fachkonzept defines 3 levels (Deskriptiv, Diagnostisch, Präskriptiv)
- 18 dedicated charts (K1-K5, E1-E5, A1-A8, C1-C6)
- Goal-mode dependent interpretation
- Lag-based correlations mandatory
- Confidence & data quality essential

Recommended Actions:
- Create Issues #52-55 (Baseline, Scores, Correlations, Metrics)
- Expand #26 & #27 based on Fachkonzept
- Start Phase 0: Implement 84 placeholders

File: docs/KONZEPT_ANALYSE_2026-03-26.md (385 lines)
2026-03-26 15:26:12 +01:00
cd2609da7c feat: Feature Request #49 - Prompt-Zuordnung zu Verlaufsseiten
All checks were successful
Deploy Development / deploy (push) Successful in 48s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 14s
UX Enhancement: Kontextbezogene KI-Analysen

Features:
- Prompts auf Verlaufsseiten verfügbar machen
- Mehrfachauswahl: Prompt auf mehreren Seiten
- Inline-Analyse via Modal
- Wiederverwendbare PagePrompts Komponente

Technisch:
- DB: available_on JSONB column
- API: GET /api/prompts/for-page/{page_slug}
- UI: Page-Auswahl im Prompt-Editor

Aufwand: 6-8h, Priority: Medium
Gitea: Issue #49
2026-03-26 15:12:39 +01:00
39db23d417 docs: comprehensive status report 26.03.2026
All checks were successful
Deploy Development / deploy (push) Successful in 51s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 13s
Audit Results:
- 2 Issues closed: #28 (AI-Prompts), #44 (Delete bug)
- 1 Issue created: #47 (Value Table Refinement)
- 12 commits today, 3 major features completed
- All documentation synchronized with Gitea

Next: Testing on dev, then Production deployment
2026-03-26 14:53:45 +01:00
582f125897 docs: comprehensive status update and Gitea sync
Some checks failed
Deploy Development / deploy (push) Successful in 57s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Has been cancelled
Updates:
- Clarify Gitea issue references (prefix with 'Gitea #')
- Mark #28 (AI-Prompts) as CLOSED
- Mark #44 (Delete insights) as CLOSED
- Update #47 reference (Wertetabelle Optimierung)
- Add 'Letzte Updates' section for 26.03.2026
- Document Issue-Management responsibility

Gitea Actions:
- Closed Issue #28 with completion comment
- Closed Issue #44 with fix details
- Created Issue #47 (Wertetabelle Optimierung)
2026-03-26 14:52:44 +01:00
21bdd9f2ba docs: add Claude Code responsibilities section
All checks were successful
Deploy Development / deploy (push) Successful in 43s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 13s
- Issue-Management via Gitea API
- Dokumentation pflegen
- Entwicklungs-Workflow
2026-03-26 14:46:20 +01:00
713f7475c9 docs: create Issue #50 - Value Table Refinement
All checks were successful
Deploy Development / deploy (push) Successful in 43s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 13s
- Normal-Modus: Nur Einzelwerte (übersichtlich)
- Experten-Modus: Zusätzlich Stage-Rohdaten
- Beschreibungen für alle Platzhalter vervollständigen
- Schema-basierte Beschreibungen für extrahierte Werte

Aufwand: 4-6h, Priority: Medium
2026-03-26 14:43:23 +01:00
6e651b5bb5 fix: include stage outputs in debug info for value table
All checks were successful
Deploy Development / deploy (push) Successful in 45s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 13s
- stage_debug now includes 'output' dict with all stage outputs
- Fixes empty values for stage_X_outputkey in expert mode
- Stage outputs are the actual AI responses passed to next stage
2026-03-26 14:33:00 +01:00
f37936c84d feat: show all stage outputs as collapsible JSON in expert mode
All checks were successful
Deploy Development / deploy (push) Successful in 43s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 13s
Backend:
- Add ALL stage outputs to metadata (not just referenced ones)
- Format JSON with indent for readability
- Description: 'Zwischenergebnis aus Stage X'

Frontend:
- Stage raw values shown in collapsible <details> element
- JSON formatted in <pre> tag with syntax highlighting
- 'JSON anzeigen ▼' summary for better UX

Fixes: Stage X - Rohdaten now shows intermediate results
2026-03-26 13:17:58 +01:00
159fcab17a feat: circ_summary with best-of-each strategy and age annotations
All checks were successful
Deploy Development / deploy (push) Successful in 42s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 14s
- Each circumference point shows most recent value (even from different dates)
- Age annotations: heute, gestern, vor X Tagen/Wochen/Monaten
- Gives AI better context about measurement freshness
- Example: 'Brust 105cm (heute), Nacken 38cm (vor 2 Wochen)'
2026-03-26 13:09:38 +01:00
d06d3d84de fix: circ_summary now checks all 8 circumference points
All checks were successful
Deploy Development / deploy (push) Successful in 48s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 13s
- Previously only checked c_chest, c_waist, c_hip
- Now includes c_neck, c_belly, c_thigh, c_calf, c_arm
- Fixes 'keine Daten' when entries exist with only non-primary measurements
2026-03-26 13:06:37 +01:00
b0f80e0be7 docs: document Issue #47 completion in CLAUDE.md
All checks were successful
Deploy Development / deploy (push) Successful in 48s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 14s
- Added comprehensive documentation for Value Table feature
- Expert mode, category grouping, stage output extraction
- Updated version header to reflect #28 and #47 completion
2026-03-26 13:03:49 +01:00
adb5dcea88 feat: category grouping in value table (Issue #47)
All checks were successful
Deploy Development / deploy (push) Successful in 52s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 14s
FEATURE: Gruppierung nach Kategorien
- Wertetabelle jetzt nach Modulen/Kategorien gruppiert
- Bessere Übersicht und Zuordnung der Werte

BACKEND: Category Metadata
- Für normale Platzhalter: Kategorie aus Catalog (Profil, Körper, Ernährung, etc.)
- Für extrahierte Werte: "Stage X - [Output Name]"
- Für Rohdaten: "Stage X - Rohdaten"
- Fallback: "Sonstiges"

FRONTEND: Grouped Display
- sortedCategories: Sortierung (Normal → Stage Outputs → Rohdaten)
- Section Headers: Grauer Hintergrund mit Kategorie-Name
- React.Fragment für Gruppierung

SORTIERUNG:
1. Normale Kategorien (Profil, Körper, Ernährung, Training, etc.)
2. Stage Outputs (Stage 1 - Body, Stage 1 - Nutrition, etc.)
3. Rohdaten (Stage 1 - Rohdaten, Stage 2 - Rohdaten)
4. Innerhalb: Alphabetisch

BEISPIEL:
┌────────────────────────────────────────────┐
│ PROFIL                                     │
├────────────────────────────────────────────┤
│ name       │ Lars    │ Name des Nutzers   │
│ age        │ 55      │ Alter in Jahren    │
├────────────────────────────────────────────┤
│ KÖRPER                                     │
├────────────────────────────────────────────┤
│ weight_... │ 85.2 kg │ Aktuelles Gewicht  │
│ bmi        │ 26.6    │ Body Mass Index    │
├────────────────────────────────────────────┤
│ ERNÄHRUNG                                  │
├────────────────────────────────────────────┤
│ kcal_avg   │ 1427... │ Durchschn. Kalorien│
│ protein... │ 106g... │ Durchschn. Protein │
├────────────────────────────────────────────┤
│ STAGE 1 - BODY                             │
├────────────────────────────────────────────┤
│ ↳ bmi      │ 26.6    │ Aus Stage 1 (body) │
│ ↳ trend    │ sinkend │ Aus Stage 1 (body) │
├────────────────────────────────────────────┤
│ STAGE 1 - NUTRITION                        │
├────────────────────────────────────────────┤
│ ↳ kcal_... │ 1427    │ Aus Stage 1 (nutr.)│
└────────────────────────────────────────────┘

Experten-Modus zusätzlich:
├────────────────────────────────────────────┤
│ STAGE 1 - ROHDATEN                         │
├────────────────────────────────────────────┤
│ 🔬 stage...│ {"bmi"..│ Rohdaten Stage 1   │
└────────────────────────────────────────────┘

version: 9.10.0 (feature)
module: prompts 2.5.0, insights 1.8.0
2026-03-26 12:59:52 +01:00
da803da816 feat: extract individual values from stage outputs (Issue #47)
All checks were successful
Deploy Development / deploy (push) Successful in 46s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 13s
FEATURE: Basis-Analysen Einzelwerte
Vorher: stage_1_body → {"bmi": 26.6, "weight": "85.2kg"} (1 Zeile)
Jetzt:  bmi → 26.6 (eigene Zeile)
        weight → 85.2kg (eigene Zeile)

BACKEND: JSON-Extraktion
- Stage outputs (JSON) → extract individual fields
- extracted_values dict sammelt alle Einzelwerte
- Deduplizierung: Gleiche Keys nur einmal
- Flags:
  - is_extracted: true → Wert aus Stage-Output extrahiert
  - is_stage_raw: true → Rohdaten (JSON) nur Experten-Modus

BEISPIEL Stage 1 Output:
{
  "stage_1_body": {
    "bmi": 26.6,
    "weight": "85.2 kg",
    "trend": "sinkend"
  }
}

→ Metadata:
{
  "bmi": {
    value: "26.6",
    description: "Aus Stage 1 (stage_1_body)",
    is_extracted: true
  },
  "weight": {
    value: "85.2 kg",
    description: "Aus Stage 1 (stage_1_body)",
    is_extracted: true
  },
  "stage_1_body": {
    value: "{\"bmi\": 26.6, ...}",
    description: "Rohdaten Stage 1 (Basis-Analyse JSON)",
    is_stage_raw: true
  }
}

FRONTEND: Smart Filtering
Normal-Modus:
- Zeigt: Einzelwerte (bmi, weight, trend)
- Versteckt: Rohdaten (stage_1_body JSON)
- Filter: is_stage_raw === false

Experten-Modus:
- Zeigt: Alles (Einzelwerte + Rohdaten)
- Rohdaten: Grauer Hintergrund + 🔬 Icon

VISUAL Indicators:
↳ bmi        → Extrahierter Wert (grün)
  weight     → Normaler Platzhalter (accent)
🔬 stage_1_* → Rohdaten JSON (grau, klein, nur Experten)

ERGEBNIS:
┌──────────────────────────────────────────┐
│ 📊 Verwendete Werte (8) (+2 ausgeblendet)│
│ ┌────────────────────────────────────────┐│
│ │ weight_aktuell │ 85.2 kg   │ Gewicht ││ ← Normal
│ │ ↳ bmi          │ 26.6      │ Aus St..││ ← Extrahiert
│ │ ↳ trend        │ sinkend   │ Aus St..││ ← Extrahiert
│ └────────────────────────────────────────┘│
└──────────────────────────────────────────┘

Experten-Modus zusätzlich:
│ 🔬 stage_1_body │ {"bmi":...│ Rohdaten││ ← JSON

version: 9.9.0 (feature)
module: prompts 2.4.0, insights 1.7.0
2026-03-26 12:55:53 +01:00
e799edbae4 feat: expert mode + stage outputs in value table (Issue #47)
All checks were successful
Deploy Development / deploy (push) Successful in 44s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 14s
FEATURE: Experten-Modus 🔬
- Toggle-Button in Wertetabelle
- Normal: Nur gefüllte Werte anzeigen
- Experten: Alle Platzhalter inkl. leere/technische
- Anzeige: "(+X ausgeblendet)" wenn Werte gefiltert
- Button-Style: Accent wenn aktiv

FILTER: Leere Werte ausblenden (Normal-Modus)
- Filtert: '', 'nicht verfügbar', '[Nicht verfügbar]'
- Zeigt nur relevante Nutzer-Daten
- Experten-Modus zeigt alles

FEATURE: Stage-Outputs in Wertetabelle 
ROOT CAUSE: stage_N_key Platzhalter hatten keine Werte
- Stage-Outputs (z.B. stage_1_body) sind Basis-Analysen-Ergebnisse
- Wurden nicht in cleaned_values gefunden (nur statische Platzhalter)
FIX:
- Collect stage outputs aus result.debug.stages[].output
- Store als stage_N_key dict
- Lookup: erst stage_outputs, dann cleaned_values
- Description: "Output aus Stage X (Basis-Analyse)"
- JSON-Werte automatisch serialisiert

BEISPIEL Pipeline-Wertetabelle:
┌──────────────────────────────────────────────┐
│ 📊 Verwendete Werte (8) (+3 ausgeblendet) 🔬│
│ ┌──────────────────────────────────────────┐ │
│ │ weight_aktuell  │ 85.2 kg   │ Gewicht  │ │
│ │ stage_1_body    │ {"bmi":...│ Output...│ │ ← Stage output!
│ │ stage_1_nutr... │ {"kcal"...│ Output...│ │
│ └──────────────────────────────────────────┘ │
└──────────────────────────────────────────────┘

AKTIVIERUNG Experten-Modus:
1. Analyse öffnen
2. "📊 Verwendete Werte" aufklappen
3. Button "🔬 Experten-Modus" klicken
4. Zeigt alle Platzhalter (auch leere stage outputs)

version: 9.8.0 (feature)
module: prompts 2.3.0, insights 1.6.0
2026-03-26 12:44:28 +01:00
15bd6cddeb feat: untruncated values + smart base prompt display (Issue #47)
All checks were successful
Deploy Development / deploy (push) Successful in 43s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 13s
FEATURE: Volle Werte (nicht abgeschnitten)
- Backend holt ungekürzten Werte direkt von placeholder_resolver
- get_placeholder_example_values() statt debug.resolved_placeholders
- Debug bleibt gekürzt (100 chars), Metadata ungekürzt

FEATURE: Smart Display für Basis-Prompts
- Basis-Prompts mit JSON-Output: Nur Wertetabelle anzeigen
- JSON-Output in Collapsible "Technische Daten" verschoben
- Wertetabelle auto-expanded bei Basis-Prompts
- Pipeline + Text-Prompts: Wie bisher (Content + Wertetabelle)

UI: Bessere Wertetabelle
- Werte: word-break + max-width (400px) → kein Overflow
- Alle Spalten: verticalAlign top für bessere Lesbarkeit
- Platzhalter: nowrap (keine Umbrüche)

BEISPIEL:
┌─────────────────────────────────────────┐
│ ℹ️ Basis-Prompt Rohdaten                │
│ [Technische Daten anzeigen ▼]           │
│                                          │
│ 📊 Verwendete Werte (8) ▼  ← expanded  │
│ ┌──────────────────────────────────────┐│
│ │ Platzhalter │ Vollständiger Wert... ││
│ │ kcal_avg    │ 1427 kcal/Tag (Ø 30...││ ← ungekürzt
│ └──────────────────────────────────────┘│
└─────────────────────────────────────────┘

version: 9.7.0 (feature)
module: prompts 2.2.0, insights 1.5.0
2026-03-26 12:37:52 +01:00
19414614bf fix: add metadata to newResult for immediate value table display
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
BUG: Wertetabelle wurde nicht angezeigt bei neuer Analyse
ROOT CAUSE: newResult hatte nur {scope, content}, kein metadata
FIX: Build metadata from result.debug.resolved_placeholders
- Für Base: direkt aus resolved_placeholders
- Für Pipeline: collect aus allen stages
- Metadata structure: {prompt_type, placeholders: {key: {value, description}}}

NOTE: Immediate preview hat keine descriptions (nur values)
Saved insights (nach loadAll) haben full metadata with descriptions aus DB

version: 9.6.2 (bugfix)
2026-03-26 12:29:05 +01:00
4a2bebe249 fix: value table metadata + |d modifier + cursor insertion (Issues #47, #48)
All checks were successful
Deploy Development / deploy (push) Successful in 52s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 13s
BUG: Wertetabelle wurde nicht angezeigt
FIX: enable_debug=true wenn save=true (für metadata collection)
- metadata wird nur gespeichert wenn debug aktiv
- jetzt: debug or save → metadata immer verfügbar

BUG: {{placeholder|d}} Modifier funktionierte nicht
ROOT CAUSE: catalog wurde bei Exception nicht zu variables hinzugefügt
FIX:
- variables['_catalog'] = catalog (auch wenn None)
- Warning-Log wenn catalog nicht geladen werden kann
- Debug warning wenn |d ohne catalog verwendet

BUG: Platzhalter in Pipeline-Stages am Ende statt an Cursor
FIX:
- stageTemplateRefs Map für alle Stage-Textareas
- onClick + onKeyUp tracking für Cursor-Position
- Insert at cursor: template.slice(0, pos) + placeholder + template.slice(pos)
- Focus + Cursor restore nach Insert

TECHNICAL:
- prompt_executor.py: Besseres Exception Handling für catalog
- UnifiedPromptModal.jsx: Refs für alle Template-Felder
- prompts.py: enable_debug=debug or save

version: 9.6.1 (bugfix)
module: prompts 2.1.1
2026-03-26 12:04:20 +01:00
c0a50dedcd feat: value table + {{placeholder|d}} modifier (Issue #47)
All checks were successful
Deploy Development / deploy (push) Successful in 48s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 15s
FEATURE #47: Wertetabelle nach KI-Analysen
- Migration 021: metadata JSONB column in ai_insights
- Backend sammelt resolved placeholders mit descriptions beim Speichern
- Frontend: Collapsible value table in InsightCard
  - Zeigt: Platzhalter | Wert | Beschreibung
  - Sortiert tabellarisch
  - Funktioniert für base + pipeline prompts

FEATURE #48: {{placeholder|d}} Modifier
- Syntax: {{weight_aktuell|d}} → "85.2 kg (Aktuelles Gewicht in kg)"
- resolve_placeholders() erkennt |d modifier
- Hängt description aus catalog an Wert
- Fein-granulare Kontrolle pro Platzhalter (nicht global)
- Optional: nur wo sinnvoll einsetzen

TECHNICAL:
- prompt_executor.py: catalog parameter durchgereicht
- execute_prompt_with_data() lädt catalog via get_placeholder_catalog()
- Catalog als _catalog in variables übergeben, in execute_prompt() extrahiert
- Base + Pipeline Prompts unterstützen |d modifier

EXAMPLE:
Template: "Gewicht: {{weight_aktuell|d}}, Alter: {{age}}"
Output:   "Gewicht: 85.2 kg (Aktuelles Gewicht in kg), Alter: 55"

version: 9.6.0 (feature)
module: prompts 2.1.0, insights 1.4.0
2026-03-26 11:52:26 +01:00
c56d2b2201 fix: delete insights + placeholder cursor insertion (Issue #44)
BUG #44: Analysen löschen schlug fehl (kein Auth-Token)
FIX:
- api.deleteInsight() in api.js hinzugefügt
- Analysis.jsx nutzt jetzt api.js mit Error-Handling
- Nicht mehr raw fetch() ohne Token

BUG: Platzhalter wurden am Ende eingefügt statt an Cursor-Position
FIX:
- useRef für baseTemplateRef hinzugefügt
- Cursor-Position tracking (onClick + onKeyUp)
- Insert at cursor: template.slice(0, pos) + placeholder + template.slice(pos)
- Focus + Cursor-Position nach Insert wiederhergestellt

version: 9.5.2 (bugfix)
module: prompts 2.0.2, insights 1.3.1
2026-03-26 11:40:19 +01:00
7daa2e40c7 fix: sleep quality calculation using wrong key (stage vs phase)
All checks were successful
Deploy Development / deploy (push) Successful in 44s
Build Test / lint-backend (push) Successful in 0s
Build Test / build-frontend (push) Successful in 13s
BUG: sleep_avg_quality showed 0% despite valid sleep data
ROOT CAUSE: sleep_segments use 'phase' key, not 'stage'
FIX: Changed s.get('stage') to s.get('phase') in get_sleep_avg_quality()

version: 9.5.1 (bugfix)
module: prompts 2.0.1
2026-03-26 10:31:39 +01:00
ae6bd0d865 docs: Issue #28 completion documentation (v9e)
- Marked Issue #28 as complete
- Documented all 4 original phases
- Documented debug tools added 26.03.2026
- Documented placeholder enhancements (6 new functions, 7 reconstructed)
- Documented bug fixes (PIPELINE_MASTER, SQL columns, type errors)
- Listed related Gitea issues (#43, #44, #45, #46)
- Updated version status to v9e Ready for Production

version: 9.5.0 (documentation update)
2026-03-26 10:28:42 +01:00