No description
  • Go 92.8%
  • CSS 6.8%
  • Dockerfile 0.2%
  • Makefile 0.2%
Find a file
2026-04-10 00:01:09 -04:00
cmd/coach added: weight trendlines and analysis 2026-03-28 17:37:39 -04:00
internal added: stats panel 2026-04-10 00:01:09 -04:00
.dockerignore added: docker 2026-04-07 23:34:14 -04:00
.gitignore initial commit 2026-03-08 22:50:10 -04:00
compose.yaml added: docker 2026-04-07 23:34:14 -04:00
Dockerfile added: docker 2026-04-07 23:34:14 -04:00
go.mod initial commit 2026-03-08 22:50:10 -04:00
go.sum initial commit 2026-03-08 22:50:10 -04:00
Makefile added: ui changes and simple auth 2026-03-09 14:59:01 -04:00
README.md added: /api/summary endpoint 2026-03-26 11:21:01 -04:00

Coach

Coach is a small single-binary Go web app for tracking calorie intake and body weight.

It is intentionally simple:

  • log meals with calorie counts
  • log weight entries
  • view a chronological journal
  • view a graph with cumulative calorie budget vs. actual intake
  • overlay weight on the all-time graph

The app is server-rendered with Go templates, uses HTMX for UI interactions, and stores all data in a single SQLite file.

High-Level Shape

  • cmd/coach/
    • CLI entrypoint and serve command
  • internal/service/
    • domain types, validation, journal assembly, chart generation
  • internal/database/
    • SQLite open/init, migrations, store implementation
  • internal/app/
    • HTTP handlers, request context parsing, view models, templates, static assets
  • internal/testutil/
    • shared test setup helpers

Runtime Model

  • single process
  • single SQLite database file
  • no external services
  • no frontend build step
  • mobile-first SSR UI with HTMX-loaded modals

Optional private access gate:

  • set COACH_AUTH_TOKEN (or pass --auth-token) to require a one-field login
  • successful login sets a browser cookie used on later requests

The default local development flow uses:

  • ./bin/coach for the built binary
  • ./data/coach.sqlite3 for runtime data

Request Flow

Most interactions follow the same shape:

  1. HTTP handler parses form input or query state
  2. service layer validates and applies domain rules
  3. database layer persists or loads SQLite state
  4. app layer rebuilds view models from persisted state
  5. templates render either a full page or HTMX fragment

The server remains the source of truth after every write.

UI Model

  • pinned graph at the top of the screen
  • scrollable journal below it
  • journal header actions for adding meal and weight entries
  • chart header settings action beside the mode switch
  • modal forms for create/edit flows
  • week and all-time graph modes

Meal and weight timestamps are intentionally normalized to the hour.

Development

  • make build builds ./bin/coach
  • make run builds and runs against ./data/coach.sqlite3
  • make test runs the test suite

Meal Summary API

The server also exposes a plain-text summary endpoint intended for LLM-friendly analysis:

  • GET /api/summary/meals
  • Optional query params:
    • start_date=YYYY-MM-DD
    • end_date=YYYY-MM-DD
  • If no query params are provided, all logged meal dates are included.
  • If auth is enabled (--auth-token or COACH_AUTH_TOKEN), /api/* routes require Authorization: Bearer <token>.

Example:

curl -H "Authorization: Bearer example-password" \
  "http://127.0.0.1:8080/api/summary/meals?start_date=2026-03-01&end_date=2026-03-31"

Notes For Developers

  • templates and static files are embedded into the binary
  • chart rendering is done server-side as SVG
  • persisted timestamps are stored as Unix seconds in SQLite
  • the database package implements the service-owned store interface
  • tests are in-process and exercise the app without starting a real listener