feat: initial project setup with roadmap, exercise data, and docs

Establish SneakySwole project foundation:
- CLAUDE.md with project overview, stack, and development guidelines
- 5-phase roadmap (scaffold, data layer, workout UI, logging, progression)
- Exercise library YAML with 6 warmups and 20 exercises (form cues, tempo, sets)
- User programs YAML with week 1/4 targets for Phillip and Daughter
- Design doc capturing roadmap, data, and auth model decisions
- Code guidelines, security standards, and .gitignore
- Source workout spreadsheet (workout_plan_v2.xlsx)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

docs/CLAUDE.md

@@ -0,0 +1,22 @@
+# Documentation Folder
+
+This folder contains business planning, architecture decisions, and documentation.
+
+**No application code belongs here.**
+
+## Contents
+
+| Document | Purpose |
+|----------|---------|
+| `code_guidelines.md` | Code creation guidelines and Git strategy |
+| `security.md` | Python focused security code suggestions |
+| `roadmap.md` | 5-phase development roadmap |
+| `plans/` | Design documents and implementation plans |
+
+
+## Guidelines
+
+- Keep documents focused and concise
+- Update docs when architecture decisions change
+- Use markdown tables for structured information
+- Include links to external documentation where relevant

docs/code_guidelines.md

@@ -0,0 +1,120 @@
+### Coding Standards
+
+**Style & Structure**
+- Prefer longer, explicit code over compact one-liners
+- Always include docstrings for functions/classes + inline comments
+- Strongly prefer OOP-style code (classes over functional/nested functions)
+- Strong typing throughout (dataclasses, TypedDict, Enums, type hints)
+- Value future-proofing and expanded usage insights
+
+**Data Design**
+- Use dataclasses for internal data modeling
+- Typed JSON structures
+- Functions return fully typed objects (no loose dicts)
+- Snapshot files in JSON or YAML
+- Human-readable fields (e.g., `scan_duration`)
+
+**Templates & UI**
+- Don't mix large HTML/CSS blocks in Python code
+- Prefer Jinja templates for HTML rendering
+- Clean CSS, minimal inline clutter, readable template logic
+
+**Writing & Documentation**
+- Markdown documentation
+- Clear section headers
+- Roadmap/Phase/Feature-Session style documents
+- Boilerplate templates first, then refinements
+
+**Logging**
+- Use structlog (pip package)
+- Setup logging at app start: `logger = logging.get_logger(__file__)`
+
+**Preferred Pip Packages**
+- API/Web Server: Flask
+- HTTP: Requests
+- Logging: Structlog
+- Scheduling: APScheduler
+
+### Error Handling
+- Custom exception classes for domain-specific errors
+- Consistent error response formats (JSON structure)
+- Logging severity levels (ERROR vs WARNING)
+
+### Configuration
+- Each component has environment-specific configs in its own `/config/*.yaml`
+  - API: `/api/config/development.yaml`, `/api/config/production.yaml`
+  - Web: `/public_web/config/development.yaml`, `/public_web/config/production.yaml`
+- `.env` for secrets (never committed)
+- Maintain `.env.example` in each component for documentation
+- Typed config loaders using dataclasses
+- Validation on startup
+
+### Containerization & Deployment
+- Explicit Dockerfiles
+- Production-friendly hardening (distroless/slim when meaningful)
+- Clear build/push scripts that:
+  - Use git branch as tag
+  - Ask whether to tag `:latest`
+  - Ask whether to push
+  - Support private registries
+
+### API Design
+- RESTful conventions
+- Versioning strategy (`/api/v1/...`)
+- Standardized response format:
+
+```json
+{
+  "app": "<APP NAME>",
+  "version": "<APP VERSION>",
+  "status": <HTTP STATUS CODE>,
+  "timestamp": "<UTC ISO8601>",
+  "request_id": "<optional request id>",
+  "result": <data OR null>,
+  "error": {
+    "code": "<optional machine code>",
+    "message": "<human message>",
+    "details": {}
+  },
+  "meta": {}
+}
+```
+
+### Dependency Management
+- Use `requirements.txt` and virtual environments (`python3 -m venv venv`)
+- Use path `venv` for all virtual environments
+- Pin versions to version ranges
+- Activate venv before running code (unless in Docker)
+
+### Testing Standards
+- Manual testing preferred for applications
+- **API Backend:** Maintain `api/docs/API_TESTING.md` with endpoint examples, curl/httpie commands, expected responses
+- **Unit tests:** Use pytest for API backend (`api/tests/`)
+- **Web Frontend:** If using a web frontend, Manual testing checklist are created in `public_web/docs`
+
+### Git Standards
+
+**Branch Strategy:**
+- `master` - Production-ready code only
+- `dev` - Main development branch, integration point
+- `beta` - (Optional) Public pre-release testing
+
+**Workflow:**
+- Feature work branches off `dev` (e.g., `feature/add-scheduler`)
+- Merge features back to `dev` for testing
+- Promote `dev` → `beta` for public testing (when applicable)
+- Promote `beta` (or `dev`) → `master` for production
+
+**Commit Messages:**
+- Use conventional commit format: `feat:`, `fix:`, `docs:`, `refactor:`, etc.
+- Keep commits atomic and focused
+- Write clear, descriptive messages
+
+**Tagging:**
+- Tag releases on `master` with semantic versioning (e.g., `v1.2.3`)
+- Optionally tag beta releases (e.g., `v1.2.3-beta.1`)
+
+---
+
+## Workflow Preference
+I follow a pattern: **brainstorm → design → code → revise**

docs/plans/2026-02-23-roadmap-and-data-design.md

@@ -0,0 +1,76 @@
+# Design: Roadmap, Exercise Data, and Auth Model
+
+**Date:** 2026-02-23
+**Status:** Approved
+
+## Overview
+
+This document captures the design decisions for the SneakySwole roadmap structure, exercise data management, and authentication model.
+
+## Roadmap Structure
+
+Five phases, each producing a testable milestone:
+
+1. **Scaffold & Infrastructure** — project structure, Docker, base template, logging
+2. **Data Layer & Seeding** — SQLite schema, Alembic migrations, YAML-based exercise/program seeding
+3. **Workout UI** — admin auth, profile management, workout viewer, exercise browser
+4. **Logging & Tracking** — per-exercise logging, session tracking, log history
+5. **Progression & Analytics** — auto-progression, schedule view, progress dashboard
+
+Full details in `docs/roadmap.md`.
+
+## Exercise Data Design
+
+### Separated YAML Files
+
+Exercise data is split into two config files for clean separation of concerns:
+
+- **`config/exercises.yaml`** — Universal exercise library
+  - Exercise name, muscle group, workout day, sets, tempo, form cues
+  - Warmup exercises (name, type, reps/time, form cues)
+  - Rarely changes; defines the available exercise catalog
+
+- **`config/user_programs.yaml`** — Per-user programming
+  - References exercises by name
+  - Week 1 and week 4 reps and weights per user per exercise
+  - Changes when users adjust their programming or new users are added
+
+### Seeding Flow
+
+1. On first run (empty DB), the seed script reads both YAML files
+2. Exercises and warmups are inserted into their respective tables
+3. User profiles are created (admin from `.env`, others from user_programs.yaml)
+4. User-specific programming (reps/weights) is linked to exercises and users
+5. Subsequent runs skip seeding if data already exists
+
+### Why YAML Over Spreadsheet
+
+- Human-readable and version-controllable
+- Easy to update without special tools
+- Can be validated with schema checks
+- Spreadsheet remains source of truth for initial data extraction only
+
+## Authentication Model
+
+### Phase 1: Simple Admin Auth
+
+- Single admin user with credentials stored in `.env` (`ADMIN_USERNAME`, `ADMIN_PASSWORD`)
+- On first run, admin user is created in DB with bcrypt-hashed password
+- Admin logs in via a simple login form (session-based auth)
+- Admin creates user profiles through the UI (no login for profiles)
+- Profile switcher in navigation allows admin to select the active profile
+- All workout logging happens under the selected profile
+
+### Security Considerations
+
+- Passwords hashed with bcrypt (never stored plaintext)
+- `.env` file is gitignored and never committed
+- `.env.example` documents required variables without real values
+- Session tokens with reasonable expiry
+- Admin-only routes protected by auth middleware
+
+### Future Upgrade Path
+
+- Phase 1 auth is designed to be replaceable
+- If multi-user login is needed later, add login credentials to the user profiles table
+- Profile switcher becomes unnecessary when each user logs in independently

docs/roadmap.md

@@ -0,0 +1,59 @@
+# SneakySwole Roadmap
+
+## Phase 1: Scaffold & Infrastructure
+
+Set up the project foundation — everything needed before writing features.
+
+- FastAPI project structure (`app/` with routes, services, models, templates, static, utils)
+- Dockerfile + docker-compose.yaml (SQLite volume, port 8000, `.env` support)
+- Pico CSS dark theme base template (Jinja2 with `data-theme="dark"`)
+- `.env` / `.env.example` with admin credentials (`ADMIN_USERNAME`, `ADMIN_PASSWORD`)
+- `uv` for dependency management, `requirements.txt` with pinned versions
+- Structlog logging setup
+- Basic health check route (`/health`)
+
+## Phase 2: Data Layer & Seeding
+
+Build the database schema and seed it from YAML config files.
+
+- SQLite schema via Alembic migrations
+  - Tables: users, exercises, warmups, workout_days, user_exercise_programs, sets, progress_log
+- `config/exercises.yaml` — exercise library (name, muscle group, workout day, sets, tempo, form cues)
+- `config/user_programs.yaml` — per-user week 1/4 reps and weights for each exercise
+- Seed script that loads YAML into DB on first run
+- Admin user auto-created from `.env` credentials on startup (password hashed with bcrypt)
+- Two initial user profiles seeded: Phillip and Daughter
+- Service layer for all DB access (no direct queries from routes)
+
+## Phase 3: Workout UI
+
+The core user-facing experience — viewing workouts and managing profiles.
+
+- Admin login (simple session-based auth, password hashed)
+- Profile switcher in nav (admin selects active user profile)
+- Admin can create and edit user profiles (name, weight, height, goals)
+- Workout day viewer — warmup routine + main exercises with full form cues
+- Exercise library browser (search/filter by muscle group, workout day)
+- All interactions via HTMX partials (no JSON APIs, no vanilla JS)
+
+## Phase 4: Logging & Tracking
+
+Enable workout logging so users can track what they actually did.
+
+- Per-exercise logging: sets completed, reps, weight used, "felt easy?" toggle
+- Workout session model (date, user profile, workout day)
+- HTMX inline logging — log directly from the workout day view
+- Log history view per user profile
+- Edit/delete past log entries
+
+## Phase 5: Progression & Analytics
+
+Smart suggestions and visual progress tracking.
+
+- Auto-progression engine based on log history
+  - +1-2 reps/week, +5 lbs every 2 weeks
+  - Deload detection at week 5 (-20% weight)
+- 4-week schedule view (calendar-style, shows which day maps to which date)
+- Progress dashboard per user profile
+- Per-exercise progress history and trends
+- Summary stats (total volume, streak tracking)

docs/security.md

@@ -0,0 +1,46 @@
+## Foundational Security Instructions
+
+- Act as a security-aware software engineer generating secure Python code.
+- Produce implementations that are **secure-by-design and secure-by-default**, not merely cosmetically "secured."
+- Focus on **preventing vulnerabilities**, not renaming functions or adding superficial security wrappers.
+- Explicitly identify **trust boundaries** (user input, external systems, internal components) and apply stricter controls at all boundary crossings.
+- Treat **all external input as untrusted by default**, regardless of source, and validate or sanitize it before use.
+- Explicitly consider **data sensitivity** (e.g., public, internal, confidential, regulated) and enforce controls appropriate to the highest sensitivity level involved.
+- Clearly distinguish between **authentication**, **authorization**, and **session management**, and never conflate their responsibilities.
+- Ensure implementations **fail securely**: errors, exceptions, and edge cases MUST NOT expose sensitive data or weaken security guarantees.
+- Use inline comments (when generating code) to clearly highlight critical security controls, assumptions, and security-relevant design decisions.
+- Adhere strictly to OWASP best practices, with particular consideration for the OWASP ASVS.
+- **Avoid slopsquatting and dependency confusion**: never guess package names or APIs; only reference well-known, reputable, and maintained libraries. Explicitly note any uncommon or low-reputation dependencies.
+- Do not hardcode secrets, credentials, tokens, or cryptographic material. Always require secure external configuration or secret management mechanisms.
+
+---
+
+## Common Weaknesses for Python
+
+### CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
+**Summary:** Failure to properly sanitize or encode user input can lead to injection of malicious scripts into web pages, enabling XSS attacks.
+**Mitigation Rule:** All user input rendered in web pages MUST be sanitized and contextually encoded using a secure library such as `bleach` or `html.escape`.
+
+### CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
+**Summary:** Unsanitized user input in SQL queries can allow attackers to execute arbitrary SQL commands, compromising data integrity and confidentiality.
+**Mitigation Rule:** SQL queries MUST use parameterized statements or prepared statements provided by libraries such as `sqlite3` or `SQLAlchemy`. Direct concatenation of user input into queries MUST NOT be used.
+
+### CWE-327: Use of a Broken or Risky Cryptographic Algorithm
+**Summary:** Using outdated or insecure cryptographic algorithms can compromise data confidentiality and integrity.
+**Mitigation Rule:** Cryptographic operations MUST use secure algorithms provided by the `cryptography` library. Deprecated algorithms such as MD5 or SHA-1 MUST NOT be used.
+
+### CWE-798: Use of Hard-coded Credentials
+**Summary:** Hardcoding credentials in source code can lead to unauthorized access if the code is exposed or leaked.
+**Mitigation Rule:** Secrets, credentials, and tokens MUST be stored securely using environment variables, secret management tools, or configuration files outside the source code repository.
+
+### CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
+**Summary:** Improper error handling or logging can expose sensitive data to unauthorized users.
+**Mitigation Rule:** Error messages and logs MUST NOT include sensitive information such as stack traces, database connection strings, or user credentials. Use logging libraries such as `logging` with appropriate log levels and sanitization.
+
+### CWE-502: Deserialization of Untrusted Data
+**Summary:** Deserializing untrusted data can lead to arbitrary code execution or data tampering.
+**Mitigation Rule:** Deserialization MUST only be performed on trusted data sources. Unsafe libraries such as `pickle` MUST NOT be used for deserialization of untrusted input.
+
+### CWE-829: Inclusion of Functionality from Untrusted Control Sphere
+**Summary:** Using dependencies or code from untrusted sources can introduce malicious functionality or vulnerabilities.
+**Mitigation Rule:** Dependencies MUST be sourced from reputable package repositories such as PyPI. Verify the integrity and reputation of packages before use, and pin dependency versions to avoid supply chain attacks.