Merge beta into main — nutrition track joins the trunk

.github/workflows/publish.yml

@@ -1,8 +1,10 @@
 name: Publish image
 
+# main → :latest (the stable stack) · beta → :beta (the nutrition beta stack).
+# The branch name IS the tag except main, so the mapping needs no per-branch jobs.
 on:
   push:
-    branches: [main]
+    branches: [main, beta]
 
 permissions:
   contents: read
@@ -26,6 +28,6 @@ jobs:
           file: server/Dockerfile
           platforms: linux/amd64,linux/arm64
           push: true
-          tags: ghcr.io/${{ github.repository_owner }}/forge:latest
+          tags: ghcr.io/${{ github.repository_owner }}/forge:${{ github.ref_name == 'main' && 'latest' || github.ref_name }}
           cache-from: type=gha
           cache-to: type=gha,mode=max

.gitignore

@@ -12,4 +12,6 @@ ios/**/xcuserdata/
 ios/**/*.xcuserstate
 ios/DerivedData/
 ios/**/.build/
+# the public host never lands in a tracked file — see ServerDefaults.example.plist
+ios/**/ServerDefaults.plist
 *.p8

CLAUDE.md

@@ -18,17 +18,18 @@ live in `docs/`.
 - `ios/` — native SwiftUI app (started Jul 2026, in progress). One app, three modules: Train / Cook / Shop. Design decisions in `docs/native-app-design.md`, setup + phases (N0–N5) in `docs/ios-implementation-plan.md`, iOS-session working rules in `ios/CLAUDE.md`. The server is unchanged by it — the app is another API client. The PWA stays deployed as the fallback and the desktop dashboard, so any API change is checked against both clients.
 - `web/` — React 19 + Vite 7 + TypeScript PWA. TanStack Query for server state; IndexedDB offline set queue in `src/queue.ts`; hand-written `src/styles.css` IS the design system — no Tailwind, keep it that way.
 - Coach: server-side Claude tool-use loop; tools call route handlers directly with `(user=user, db=db)`. `propose_revision` validates content and creates `status='proposed'` revisions the user approves in-app (auto-apply only when `prefs.coach_approval == 'auto'`). Sunday 20:00 Europe/London review scheduler in `main.py` lifespan; `agent_runs` logs token spend. Model via `COACH_MODEL` (default claude-sonnet-5).
-- `/api/week` is a calendar week Mon–Sun: pass any `date` and the server snaps to that week's Monday; the response carries `today` so clients mark the current day and flag past "missed" days. The Plan screen pages weeks with prev/next (capped one week ahead); the current week auto-focuses today. Sessions can pull any strength plan day onto today's date (`plan_day` override on POST /api/sessions). `/api/history` is offset-paginated (`limit`≤100/`offset`) and takes `favorites=true` to return only starred sessions. Session management: `DELETE /api/sessions/{id}` discards a session (drops its sets + cardio series, leaves all-time records — same simplification as edit_set) — used by the unfinished-workout sheet's "Discard" (a `ConfirmSheet` in `ui.tsx`) and History's swipe-to-delete (`data.tsx::SwipeRow`, pointer-events + `touch-action:pan-y`); `PATCH /api/sessions/{id}/favorite` toggles the `WorkoutSession.favorite` star (additive column, migrated in `main.py` lifespan since create_all never alters tables). Destructive actions always route through `ConfirmSheet` (warm `--warn` CTA, never a second accent).
+- `/api/week` (and `/api/food/week`) is a calendar week Mon–Sun: pass any `date` and the server snaps to that week's Monday; the response carries `today` so clients mark the current day and flag past "missed" days. The Plan screen pages weeks with a finger-tracked swipe (three-pane prev/cur/next track in `today.tsx`, `touch-action:pan-y`, prev/next buttons reuse the eased slide; forward cap four weeks) — Food still pages with prev/next capped one week ahead; the current week auto-focuses today. Forward planning: `planned_items` (`POST/PATCH/DELETE /api/plan-items`, surfaced per-day as `planned` in `/api/week`) pencils user-authored workouts and meals onto future dates — the Plan screen renders them as pills with a per-day sheet. Sessions can pull any strength plan day onto today's date (`plan_day` override on POST /api/sessions). `/api/history` is offset-paginated (`limit`≤100/`offset`) and takes `favorites=true` to return only starred sessions. Session management: `DELETE /api/sessions/{id}` discards a session (drops its sets + cardio series, leaves all-time records — same simplification as edit_set) — used by the unfinished-workout sheet's "Discard" (a `ConfirmSheet` in `ui.tsx`) and History's swipe-to-delete (`data.tsx::SwipeRow`, pointer-events + `touch-action:pan-y`); `PATCH /api/sessions/{id}/favorite` toggles the `WorkoutSession.favorite` star (additive column, migrated in `main.py` lifespan since create_all never alters tables). Destructive actions always route through `ConfirmSheet` (warm `--warn` CTA, never a second accent).
 - Phase 4: Withings OAuth+webhooks in `routers/withings.py` (`WITHINGS_CLIENT_ID/SECRET`; webhook needs public ingress). `/api/withings/connect` answers with a **302** to the authorize URL and the button navigates to it directly — never convert this back to fetch-then-`location.href`: a direct navigation to `account.withings.com` triggers the iOS Withings app's universal link and kills the OAuth flow; server-side redirects don't. Ingested Watch workouts reconcile against the planned cardio day (`ingest.py::_match_prescription`) — matched → `status='completed'` with target-vs-actual + `pct_in_zone`; unmatched stay `unplanned`. Zone-2 weekly minutes use the fixed 110–145 band (`ZONE2_BAND`); the per-plan prescription band only drives `pct_in_zone`. Desktop dashboard: `/dashboard` route (same SPA bundle) ← `/api/dashboard`.
 - Run detail (E5.4): HR + GPS series live in `workout_series` (one row per cardio session, downsampled at ingest — a separate table on purpose: create_all can't add columns, and history queries never load the blobs). Re-ingesting an existing day backfills series instead of skipping (`ingest._attach_series`), so HAE manual exports enrich old runs. `/api/sessions/{id}` adds `series` + a five-zone breakdown (`training._zone_breakdown`: `prefs.hr_max`, else estimated and flagged). The route renders on a MapLibre GL basemap (Jul 2026) when a MapTiler key is set (`MAPTILER_KEY`, admin-managed via Settings → Server → Maps; `/api/map/config` hands the publishable key to signed-in clients); styles are built at runtime from the live design tokens in `web/src/routemap.tsx::forgeStyle` so both themes carry through — hosted MapTiler tiles only, never a second tile provider. maplibre-gl is lazy-loaded on the run-detail route and excluded from the PWA precache (`globIgnores` in vite.config); tiles cache via workbox runtime caching (capped, 30 days). The self-contained SVG trace remains and is the automatic fallback — no key, offline, or tile errors — so a run always shows its route. Demo runs get generated Cherry Orchard (Dublin) loops (`demo._run_series`).
+- External MCP (beta): `/mcp` in `routers/mcp_food.py` — a hand-rolled **stateless** Streamable-HTTP JSON-RPC endpoint (single JSON responses, no SSE/sessions, no SDK dependency — keep it that way, it's what makes it testable in the sqlite suite). Auth = the per-user ingest token as `Authorization: Bearer` (same token as `/ingest`; Settings → Connections). Ten tools: six food — `log_food` (eaten-now with venue/cost/currency/photos, `client_id` idempotent, slot inferred from `coach_tz` time when omitted), `get_food_log`, `delete_food_log`, `import_recipe`, `search_recipes`, `get_recipe` — plus four pantry tools that maintain the canonical `ingredients` reference (per-100g macros/aisle/pantry-flag): `list_ingredients` (read, demo-visible), `bulk_import_ingredients` (upsert-by-name, `overwrite` default true, the bulk path), `update_ingredient` (partial patch by name), `delete_ingredient` (reports recipe references). All ingredient writes reject the demo seat and share `_apply_ingredient_fields`/`_new_ingredient` with `import_recipe`'s inline creation. The seeded default pantry (`food_seed.INGREDIENTS`, ~100 items, USDA/McCance per-100g values, insert-missing every boot) is the trusted-source baseline these tools extend. Import rules: `source_url` is the import's identity (re-import updates in place), seed recipes are write-protected, macros are per-serving, steps must be rewritten in done-when voice (never verbatim source prose), and unknown ingredients / difficulty `hard` / zero kcal park the recipe `complete=0` (browsable, never proposable) — except an unknown ingredient supplied with per-100g reference macros (`kcal_100` is the gate, plus optional `aisle`/`pantry`) is added to the canonical `ingredients` table instead of parking. The library is browsable in-app: `GET /api/food/recipes` (everything incl. parked, `q`/`kind` params, shares `food.query_recipes` with the MCP search tool) ← Food → "Recipes ›" (`food.tsx::RecipeLibraryScreen`, client-side as-you-type filter, parked entries badged warm; recipe detail's Back honours `foodFrom`). Recipe seeding is opt-out: `SEED_RECIPES=false` stops the boot from seeding the curated recipes + first food week (the pantry/ingredient reference still seeds so imports complete); `DELETE /api/admin/recipes` (Settings → Server → Recipe library, ConfirmSheet) wipes the library and retires the shared food week for an MCP-populated setup — meal logs and ingredients are kept. Images (recipe heroes, step photos, meal photos) are materialized into `media_blobs` by `app/media.py` (data: URIs or URL fetch, 3 MB cap, keep-remote-URL fallback, deduped by `src_url`) and served at `/api/food/media/{id}` — recipe imagery is household-shared (`user_id` NULL), meal photos are private to their owner. The demo seat can log its own meals but can never write the shared recipe library.
 - Responsive shell (Jul 2026): one DOM, CSS-only adaptation in the "responsive" block at the end of `styles.css` — ≤380px compact type/padding, ≥640px wider bordered column, ≥900px (AND min-height 520px, so landscape phones keep bottom tabs) the tab bar becomes a fixed 88px left rail, all shell bands (`.app > *:not(.tabs)`) cap to a 700px centered column, sheets center as dialogs. Signed-out screens have no rail via `.app:has(> .tabs)`. New footer-bar or shell-band elements are capped automatically — never position screen chrome outside the `.app` children pattern.
 - Web Push: `notify.send_push` is the only send path and hard-rejects kinds outside proposal/reminder (the filming kind was retired with the media pipeline — form media is curated free-exercise-db photos in `web/public/media/exercises/`, wired by `seed.MEDIA_SLUGS`); reminders are once-per-day via the `notification_log` unique constraint, window `REMINDER_HOUR`(16)–`QUIET_END`(21). VAPID keys via `python -m app.vapid` → compose environment; push is silently off until set. SW push handler lives in `web/public/push-listener.js` (workbox `importScripts`).
 
 ## Invariants — do not break
 
 - Fitting: the priority-1 main lift is never trimmed; accessories trim first down to `min_sets`; cooldown shortens 5→2 min but is never dropped.
 - Proposals: known exercise slugs only; exactly one priority-1 main lift per strength day; non-empty mobility-only cooldown; `content.changes` delta list and per-day `why` one-liners required (the UI renders them).
-- Every query is scoped by `user_id` — James and Shelby must never see each other's data (test_user_segregation guards this). The optional demo user (`app/demo.py`, Bruce Willis, `role='demo'`) rides the same scoping; it is excluded from the two-seat cap, admin user list, dev sign-in buttons and the Sunday scheduler, and is created/reset/removed only via `/api/admin/demo` (`test_demo_cannot_reach_member_data` probes API, chat context, coach tools, and admin). Known exposure: the demo's coach runs on the real API key with no rate limit until Phase 6. Household-shared equipment profiles (`user_id IS NULL`) are visible to every user including the demo.
+- Every query is scoped by `user_id` — James and Shelby must never see each other's data (test_user_segregation guards this). The optional demo user (`app/demo.py`, Bruce Willis, `role='demo'`) rides the same scoping; it is excluded from the two-seat cap, admin user list, dev sign-in buttons and the Sunday scheduler, and is created/reset/removed only via `/api/admin/demo` (`/api/admin/demo/enrich` tops up an existing demo with newer-feature data — currently the food beta — without resetting training history; `demo.enrich_demo` is idempotent per block and a full reset runs it too) (`test_demo_cannot_reach_member_data` probes API, chat context, coach tools, and admin). Known exposure: the demo's coach runs on the real API key with no rate limit until Phase 6. Household-shared equipment profiles (`user_id IS NULL`) are visible to every user including the demo.
 - Ingest is idempotent on `(user_id, type, ts, source)` and must honor the payload's `units` field — Health Auto Export sends pounds.
 - Secrets never touch tracked files: the committed `docker-compose.yml` carries `change-me` placeholders only; real values live in `docker-compose.override.yml` (chmod 600, gitignored), the Portainer stack editor, or the `app_settings` table (admin-managed via Settings → Server → `routers/admin.py`; `config.apply_overrides`/`set_override` mutate the cached settings singleton so changes apply live, and DB beats env). Admin API responses mask secrets to a 4-char tail — `ANTHROPIC_API_KEY` never reaches the frontend. Google OAuth is compose-only by design (needed before login). `ALLOWED_USERS` only seeds an empty users table; after that the users table IS the allowlist. Mask tokens when displaying them; rotating an ingest token invalidates the old one instantly.
 - Design system "Void × Volt": bg `#060708`, raised `#121316`, hairlines `#191b1f`, ONE accent at a time via the `--volt` token family (actions, trends, positive status — volt lime `#bce53a` dark / moss `#5c7d0a` light), warm `#e8a360` for warnings only. Volt is fixed — there is no accent-palette picker (removed Jul 2026); the dark volt was eased ~15% off `#c9f73a` because that peak-luminance lime bloomed against the void and dimmed the neutral greys beside it. Never introduce a second simultaneous accent, never hard-code an accent hex outside the `--volt` token block in styles.css (JS reads `getComputedStyle` when it needs the hex). No borders, pill CTAs, thin tabular numerals.
@@ -43,4 +44,4 @@ and falls back to `BASE_URL` otherwise, so Host-header spoofing can't steer redi
 stays anchored to `BASE_URL` (single registered callback). Uvicorn already trusts proxy headers
 (`--proxy-headers --forwarded-allow-ips *` in the Dockerfile).
 
-Runs via Docker Compose on a single home server (`deploy/fresh-install.sh` bootstraps a clean install). As of Jul 2026 the app is on public ingress (`https://www.get-forged.com`, `BASE_URL` in the compose override) with Google OAuth active — dev sign-in buttons only appear when Google is unconfigured (fresh installs). Health Auto Export syncs from anywhere; Withings OAuth round-trips against the public callback URL. Rate limiting is still Phase 6 — the public surface is login + the demo seat.
+Runs via Docker Compose on a single home server (`deploy/fresh-install.sh` bootstraps a clean install). As of Jul 2026 the app is on public ingress with Google OAuth active — the public domain lives ONLY in `BASE_URL` in the gitignored compose override and must never be written into tracked files or commit messages; HTML entry points carry a `__BASE_URL__` token that `main.py::_html_page` substitutes at serve time (OG/share meta needs absolute URLs) — dev sign-in buttons only appear when Google is unconfigured (fresh installs). Health Auto Export syncs from anywhere; Withings OAuth round-trips against the public callback URL. Rate limiting is still Phase 6 — the public surface is login + the demo seat.

LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 James Atkinson
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.