Roadmap

This document owns future work. The implemented baseline is summarized in current_state.md; completed narratives and evidence belong in reviews and CHANGELOG.md.

Product boundary

Trainlog Core owns business truth and canonical desktop persistence.
The TUI administers, inspects, maintains, and imports/exports.
The local Web analyzes, visualizes, and prepares programs/sessions.
Android executes in the field, captures actual work/feedback, and returns data.

Future work must preserve the frozen Trainlog JSON V1 contract, stable identities, actual-versus-planned separation, direct MTP transport, and the distinction between measured values and estimates.

Current baseline

Desktop schema v18, Android schema v17, Notcurses, direct Documents/Trainlog storage, mobile export V3, Training Knowledge V1, Body Zones V1, Training Feedback V1/V2, STATS V1, and Session Generator V1 are implemented. Session Generator V1 is hidden pending V2. AI session-draft exchange and APP_SHELL_V1 retain their explicit manual validation/review gates. TRAINLOG_WEB_V1=CONTRACT_FROZEN / IMPLEMENTATION_NOT_STARTED; its local-only architecture is canonical, but no Web code exists yet.

Current cursor

CURRENT_OPERATIONAL_CURSOR=WEB_CLI_HTTP_INFRASTRUCTURE_V1

WEB_DASHBOARD_CORE_READ_MODEL_V1=PASS/FROZEN and WEB_TUI_READ_MODEL_ADOPTION_V1=PASS/FROZEN. The characterized Dashboard SQL, facts, limits and calculations now live in the typed Core service trainlog_dashboard_load(); the TUI supplies the selected period and current time, then presents the returned snapshot. Adoption was necessary to prove parity and was therefore completed in the extraction tranche rather than left as an empty roadmap step. The next authorized slice is local CLI/HTTP infrastructure; it does not yet authorize React or Dashboard Web metrics.

TRAINLOG_WEB_V1 implementation gate

Implementation order is fixed as:

WEB_DASHBOARD_CHARACTERIZATION_V1
        -> WEB_DASHBOARD_CORE_READ_MODEL_V1 [PASS/FROZEN]
        -> WEB_TUI_READ_MODEL_ADOPTION_V1 [PASS/FROZEN]
        -> WEB_CLI_HTTP_INFRASTRUCTURE_V1
        -> WEB_FRONTEND_SHELL_V1
        -> WEB_DASHBOARD_V1

The Web must not start with React. Characterization proves current behavior; Core extraction establishes one business implementation; TUI adoption proves reuse; only then may trainlog -w, the loopback HTTP adapter, embedded assets, and browser UI be introduced. Initial API delivery is read-only. Later program and session writes require explicit transactional Core command services.

TRAINLOG_WEB_V1 preserves /api/v1/ as an independently versioned boundary, the 127.0.0.1:8080 default, explicit --port, no silent port fallback, a single serialized Core/SQLite owner, build-only Node/npm, and no change to business SQLite or frozen exchange formats. Dashboard Activité and Progression mathematics remain specification gates before their read models.

Gym catalog V1

Build an inventory from the equipment actually available in the user's gym. Keep physical equipment, exercises, movement patterns, muscles, and BODY ZONES distinct. One photographed machine may support several exercises. Record model or manufacturer only when evidence identifies it.

Exercise metadata V1

After the gym inventory is normalized, design any remaining structured metadata such as movement family and laterality. Reuse existing equipment and BODY ZONES identities; do not encode semantics in display names or notes.

Session Generator V2

Replace the hidden V1 product surface with duration-aware construction that can represent warm-up, ramp-up, main work, cool-down, transitions, setup time, and candidate scarcity without claiming unsupported physiological precision.

Session templates V1

Offer editable conveniences built on the real catalogue and planning model. Templates are not rigid prescriptions and never become performed work before normal capture.

Later

evolve training analytics only where sufficient real history supports the metric, without aggregating incomparable loads;
add body baseline and trend comparisons while keeping direct measurements distinct from estimates;
add conservative, editable progression suggestions with correct external-load and assistance interpretation;
support explicit user objectives without mandatory gamification;
add user-controlled dated backup and complete/period-limited exports.

Canonical order

WEB_DASHBOARD_CHARACTERIZATION_V1
        -> WEB_DASHBOARD_CORE_READ_MODEL_V1
        -> WEB_TUI_READ_MODEL_ADOPTION_V1
        -> TRAINLOG_WEB_V1
        -> REAL_DATA_BASELINE_V1
        -> GYM_CATALOG_V1
        -> EXERCISE_METADATA_V1
        -> SESSION_GENERATOR_V2
        -> SESSION_TEMPLATES_V1
        -> ANALYTICS_EVOLUTION
        -> BODY_ANALYTICS_V2
        -> PROGRESSION_ASSIST_V1
        -> OBJECTIVES_V1
        -> BACKUP_EXPORT_V1

Outstanding validation gates

APP_SHELL_V1=IMPLEMENTED_AWAITING_VISUAL_REVIEW_2: complete the recorded human visual/accessibility matrix without redefining product semantics.
TRAINLOG_AI_SESSION_DRAFT_V1=VALIDATION_PENDING: complete one real Drive plus Android-triggered bidirectional synchronization smoke test.

Permanent constraints

Do not regress to SQLite-file synchronization, a mandatory mounted Android filesystem, exercise-name identity heuristics, fake sets for continuous work, synthetic uniform actuals, ordinary training promoted to measured MAX, assistance interpreted as external load, or estimates presented as direct measurements. Incompatible exchange semantics require a new version. Web UI configuration remains outside training data, scientific/AI exports, session synchronization, and business SQLite. Browser, React, TUI, and Android must not query desktop tables or duplicate Core calculations.

5.8 KiB Raw Blame History