Files

T

MeeJayandClaude Opus 5 93f0689c1e Initial import: LifeTrack v1 (santé, vape, finances)

Tracker de vie auto-hébergé : suivi poids/calories/sport avec planning de
pesées, sevrage tabac (vape) avec modèle de coût DIY et économies, et
finances personnelles avec import de relevés bancaires.

Architecture : FastAPI + SQLAlchemy 2.0 + PostgreSQL 16, React 18 + TS +
Vite + Tailwind + ECharts, déploiement Docker Compose. Modules
auto-découverts des deux côtés (pkgutil / import.meta.glob) et framework
de connecteurs à deux voies (importeurs de fichiers + ingestion JSON)
pour brancher de nouvelles sources sans toucher au noyau.

Validé : 292 tests pytest, tsc + vite build, contrat API/web vérifié
contre le schéma OpenAPI, et déploiement Docker réel sur PostgreSQL 16
(28 tables, SPA servie par nginx, wizard de premier démarrage).

Documentation : README.md, docs/GUIDE.md, CONVENTIONS.md, et les
documents de conception et de recherche dans docs/.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-14 10:48:57 +02:00

2.7 KiB

Raw Permalink Blame History

Addendum — Planning de suivi (jours de pesée, séances, journal)

Demande utilisateur : « pour le suivi calorique/poids/sport il faut un genre de planning avec les jours de pesée, pouvoir noter la pesée du jour, etc. »

Concept

Un planning hebdomadaire par habitude (pesée, séance de sport, journal alimentaire) + une checklist du jour + un suivi d'assiduité (streaks, calendrier, %). Le « fait / pas fait » est dérivé des données existantes — aucune double saisie :

Habitude	Jour « fait » si…
`weigh_in` (pesée)	une `WeightEntry` existe ce jour local
`workout` (séance)	un `Workout` existe ce jour local
`food_log` (journal)	≥ 1 `FoodEntry` ce jour local

Modèle (module `health`)

tracking_schedules : id, user_id, kind enum (weigh_in|workout|food_log, native_enum=False), weekdays JSON (liste d'entiers, 0 = lundi … 6 = dimanche), enabled bool — une ligne max par (user, kind) (contrainte unique). Pas de table de check-ins en v1 (dérivation ci-dessus) ; habitudes personnalisées = v2.

API (module `health`)

GET /api/health/schedules → liste des 3 plannings (avec défauts désactivés si absents) ; PUT /api/health/schedules/{kind} → upsert {weekdays, enabled}.
GET /api/health/today?tz= → { date, items: [{kind, planned, done, value}], streaks } — value : poids saisi (kg) / nb de séances / kcal saisies du jour.
GET /api/health/stats/adherence?from&to&tz&kind= → données prêtes pour un calendar heatmap ECharts (par jour : planned/done/missed) + % d'assiduité (fait ÷ planifié), streak courant et record par habitude (le streak ne compte que les jours planifiés).

UX

Accueil : carte « Aujourd'hui » en tête — checklist du jour : « Pesée » (✓ + valeur si faite, sinon bouton « Noter ma pesée » ouvrant la modale rapide), « Séance », « Journal alimentaire » (kcal saisies) ; badge streak « 🔥 n jours ». Les habitudes non planifiées aujourd'hui sont grisées (« Repos »).
Page Poids & Objectif : éditeur de planning (cases L M M J V S D + interrupteur), carte « Pesée du jour » (planifiée / faite / manquée + CTA), calendrier heatmap des pesées (vert = faite, contour = planifiée manquée), KPI « Assiduité 30 j » + streak.
Page Activité & Sport : même motif pour les jours de séance planifiés.
Réglages → Objectif : raccourci vers l'éditeur de planning.

Empty states (français)

Planning vide : « Aucun jour planifié. Choisis tes jours de pesée pour suivre ton assiduité. »
Aujourd'hui, rien de planifié : « Rien de prévu aujourd'hui. Profites-en bien ! »

2.7 KiB Raw Permalink Blame History