SovereignStrength is a calm, explainable training product for strength, running, and recovery.
It helps a single user plan training, log sessions, and receive adaptive guidance based on status and available time, without manipulative product loops or default dependence on Google-, Meta-, or similar platform logins.
Most training apps are built to increase engagement, collect data, and push generic motivation loops.
SovereignStrength is built for the opposite:
- local data ownership
- deterministic logic
- explainable decisions
- low technical complexity
- repairable architecture
SovereignStrength is not built around gamified fitness tracking, fixed motivational loops, or opaque "smart coaching".
Its training logic is closest to:
- autoregulated strength training
- fatigue- and readiness-aware session adjustment
- conservative exercise-level progression
- movement-family-aware planning
- system-oriented load management
In practical terms, this means the system asks:
- what is realistic today?
- what does recent training history suggest?
- should the user progress, hold, simplify, or shift variation?
- what can actually be loaded with the available equipment?
- is a related movement family already showing fatigue signals?
The goal is not maximal novelty or entertainment.
The goal is sustainable training guidance that remains:
- explainable
- repeatable
- calm
- realistic
Philosophically, the system has more in common with regulated adaptation and practical load management than with conventional fitness-app design.
It is closer to a decision-support layer for training than to a workout-content platform.
The currently documented system includes:
- daily plan generation
- readiness and fatigue-aware decision logic
- progression logic per exercise
- equipment-aware load recommendations
- movement-pattern-aware exercise metadata
- family-based fatigue interpretation
- controlled variation and substitution logic
- forecast output
- authenticated access
- workout logging
- review-oriented feedback
The documented user flow is:
Forecast -> Check-in -> Plan -> Workout -> Review
Data is stored locally in JSON files.
The system should always be able to explain why it recommends a load, a hold, a lighter session, or a changed variation.
The same inputs should produce the same outputs.
The project aims to stay readable and maintainable:
- HTML
- CSS
- Vanilla JavaScript
- Python
- JSON
No unnecessary framework pile-up. Humanity has suffered enough.
Static PWA-style frontend served from:
/var/www/sovereign-strength/
Primary files:
index.htmlapp.jsstyles.css
Python Flask API served via Gunicorn and systemd from:
Python dependencies are defined authoritatively in app/backend/requirements.txt.
The top-level requirements.txt is only a thin convenience wrapper that references the backend file.
/opt/sovereign-strength-api/app.py
JSON-based local storage in:
/var/www/sovereign-strength/data/
Seed exercise definitions in the repository include movement metadata used by the training engine, including movement patterns, categories, progression modes, and input configuration.
- Architecture
- Data model
- Deployment
- JSON storage integrity rules
- Local protection state contract
- Changelog
Version 1.0 should be considered complete when the system can:
- display the training program
- log sets
- save a workout
- generate a session summary
Not before.
This repository should be the authoritative source for:
- current implementation
- deployment setup
- data contracts
- operating logic
- release history
See LICENSE.
Visible frontend text should resolve through the i18n layer wherever practical.
Guardrails:
- avoid shipping hardcoded user-facing strings in render paths when a translation key should exist
- avoid mixed-language UI output in the same screen
- review suspicious
innerHTML,setText(...), andtextContentchanges carefully - run
python3 scripts/audit_i18n_guardrails.pybefore merging frontend text/rendering changes
This is a lightweight guardrail, not a heavy framework rule.