**Backend Safeguards:**
- get_goals_grouped: Added source_table, source_column, direction to SELECT
- create_goal_progress: Check source_table before allowing manual entry
- Returns HTTP 400 if user tries to log progress for automatic goals (weight, activity, etc.)
**Prevents:**
- Data confusion: Manual entries in goal_progress_log for weight/activity/etc.
- Dual tracking: Same data in multiple tables
- User error: Wrong data entry location
**Result:**
- Frontend filter (!goal.source_table) now works correctly
- CustomGoalsPage shows ONLY custom goals (flexibility, strength, etc.)
- Clear error message if manual entry attempted via API
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Implemented progress tracking system for all goals.
**Backend:**
- Migration 030: goal_progress_log table with unique constraint per day
- Trigger: Auto-update goal.current_value from latest progress
- Endpoints: GET/POST/DELETE /api/goals/{id}/progress
- Pydantic Models: GoalProgressCreate, GoalProgressUpdate
**Features:**
- Manual progress tracking for custom goals (flexibility, strength, etc.)
- Full history with date, value, note
- current_value always reflects latest progress entry
- One entry per day per goal (unique constraint)
- Cascade delete when goal is deleted
**API:**
- GET /api/goals/{goal_id}/progress - List all entries
- POST /api/goals/{goal_id}/progress - Log new progress
- DELETE /api/goals/{goal_id}/progress/{progress_id} - Delete entry
**Next:** Frontend UI (progress button, modal, history list)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
These goal types existed but were inactive or misconfigured.
Uses UPSERT (INSERT ... ON CONFLICT DO UPDATE):
- If exists → activate + fix labels/icons/category
- If not exists → create properly
Idempotent: Safe to run multiple times, works on dev + prod.
Both types have no automatic data source (source_table = NULL),
so current_value must be updated manually.
Fixes: flexibility and strength goals not visible in admin
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Enhanced fallback chain for goal display:
1. goal.name (custom name if set)
2. goal.label_de (from backend JOIN)
3. typeInfo.label_de (from goalTypesMap)
4. goal.goal_type (raw key as last resort)
Also use goal.icon from backend if available.
Fixes: Empty goal names showing blank in list
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
goals table doesn't have is_active column.
Removed AND g.is_active = true from WHERE clause.
Fixes: psycopg2.errors.UndefinedColumn: column g.is_active does not exist
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Fixed: column 'date' does not exist in blood_pressure_log
blood_pressure_log uses 'measured_at' instead of 'date'.
Added DATE_COLUMN_MAP for table-specific date columns:
- blood_pressure_log → measured_at
- fitness_tests → test_date
- all others → date
Replaced all hardcoded 'date' with dynamic date_col variable.
Fixes error: [ERROR] Failed to fetch value from blood_pressure_log.systolic
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Fixed SQL error: column g.linear_projection does not exist
Replaced with: g.on_track, g.projection_date (actual columns)
This was causing Internal Server Error on /api/goals/grouped
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Migration 028 failed because goals table doesn't have is_active column yet.
Removed WHERE clause from index definition.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Fixed multiple issues with relative weight sliders:
1. Sanitize focusData on load (ensure all 6 fields are numeric)
2. Sync focusTemp when clicking "Anpassen" button
3. Robust sum calculation filtering only *_pct fields
4. Convert NaN/undefined to 0 in all calculations
5. Safe Number() coercion before normalization
Fixes errors:
- "Gewichtung gesamt: NaN"
- "Input should be a valid integer, input: null"
- Prozent always showing 0%
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
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>
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>
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>
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
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)
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! 🎯
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'
- 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.
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.
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
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>
- 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>
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>
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>
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>
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>
- 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>
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>
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)
