foodster/PRD.md

# Foodster — Product Requirements Document

## 1. Overview

Foodster is a self-hosted web app that helps a single household decide what to
eat for the next seven dinners. Given a database of meals the family already
likes, the app proposes a week's worth of dinners (main dish, optional side
dishes) using their eating history as input. The proposal is a *suggestion*,
not a schedule — the user can swap items, ignore the suggestions entirely, or
log what was actually eaten after the fact.

The project is built for one family's use. If it matures into something
polished, it may be released as FOSS under MIT.

## 2. Goals

- Reduce weekly "what's for dinner?" decision fatigue.
- Keep meal variety high while still leaning on family favorites.
- Capture a history of what was actually eaten (not what was planned) so the
  suggester gets better over time.
- Stay boring to run: a single `docker compose up` on a home server.

## 3. Non-goals (MVP)

- No grocery list generation (possible future add-on).
- No per-recipe ingredient tracking — meals are just names.
- No calendar/scheduling with times, reminders, or calendar exports.
- No user accounts, per-person profiles, or permissions *in the app*.
  Authentication is the reverse proxy's job (§9).
- No nutrition tracking, calorie counting, or dietary-goal optimization.
- No mobile-native apps. Web only (mobile-friendly responsive is enough).
- No per-user accounts or sessions in the app. It *is* reachable from the
  internet (§9, §10), behind Authelia at the proxy.

## 4. Delivery stages

The app ships in two stages. The suggester needs real eating history to
produce useful weightings, so history capture comes first and the family
seeds the database by logging meals for a few weeks before the suggester
has anything meaningful to do.

### Stage 1 — Eating history

Everything needed to manage the meal catalog and log what was eaten.
Concretely:

- Domain model: main dishes (with `categories` and `has_sides`), side
  dishes, meal log entries (§6).
- Admin view: add / edit / delete mains and sides, JSON mass import (§7.3).
- Meal log view ("Mark"): date picker, main + sides selector, recent
  entries list with edit/delete (§7.2).
- Deployment scaffolding: `compose.yaml`, SQLite, schema applied on app
  start (§9, §10).

At the end of stage 1 the app is useful as a "what did we eat?" journal
even without any suggestions. There is no Plan view yet.

### Stage 2 — Meal suggester

Layered on top of the stage 1 foundation:

- Current suggestion cache (§6) persisted server-side.
- Plan view with seven suggested meals, two swap modes per slot, and
  regenerate-all (§7.1).
- Suggestion algorithm: cooldown, category coverage with multi-category
  mains, favorites-biased weighting with a floor, side attachment rules
  (§8).
- Settings page for the cooldown window (§7.3).

Stage 2 can start once stage 1 has collected enough history for the
weighting to be meaningful (a few weeks of logged meals).

## 5. Users

A single household. One shared instance, no per-person accounts. Everyone who
gets past Authelia sees and edits the same log; the app draws no distinction
between them.

The interface is written in **Finnish** — every user of this instance is a
Finnish speaker, so there is no i18n layer and no language switcher. Strings
are hardcoded in the templates. This PRD, the source, and code comments stay
in English.

## 6. Domain model

### Main dish (stage 1)
- `id`
- `name` — stored in sentence case: the server collapses whitespace and
  capitalizes the first letter only, leaving the rest as typed. Finnish
  capitalizes just the first word of a phrase, so "Keitetyt perunat" is
  correct and "Keitetyt Perunat" is not. Existing capitals are preserved, so
  "BBQ-kylkeä" and "Kotipizza" survive.
- `categories` — non-empty set drawn from `meat`, `chicken`, `fish`,
  `vegetarian`. Most mains will have a single category. Dishes where each
  diner builds their own plate from a shared spread (e.g., tortillas,
  build-your-own pizza) list every category present at the meal; one
  appearance of such a main simultaneously covers **all** its listed
  categories for that week, because all the proteins are actually served at
  the same meal.
- `has_sides` — boolean. If `false`, the suggester never attaches side dishes
  to this main (covers casseroles, one-pot meals, etc.).
- `created_at`
- `deleted_at` — nullable. Soft-delete marker: soft-deleted mains are hidden
  from the admin list and all pickers, but remain resolvable when displaying
  historical log entries.

### Side dish (stage 1)
- `id`
- `name` — stored in sentence case, as for mains.
- `created_at`
- `deleted_at` — nullable. Same soft-delete semantics as mains.

Side dishes live in their own table and have no category. The pool is
expected to stay small.

### Tähteet — leftovers (stage 1)

A single built-in entry, flagged `special` on the main dish table. It is
**not food**: it exists so a day can be recorded as "we ate what was already
there" without inventing a meal that was never cooked.

- No category, which is why it cannot be an ordinary main: those must have
  at least one.
- Created by a migration. The household does not add, edit or delete it, and
  it never appears in the Ruuat catalog.
- Loggable exactly like any other entry, and shown on the log board apart
  from the categories.
- **The stage 2 suggester must never propose it.** It is excluded from the
  eligible pool outright, so cooldown, category coverage (§8.1) and
  frequency weighting (§8.2) all skip it — despite it being among the
  most-logged entries.

### Meal log entry ("what was actually eaten") (stage 1)
- `id`
- `date` — SQL `DATE`, day granularity only. There is no time-of-day field
  and no timezone concern; the cooldown and display logic compare dates as
  pure calendar days.
- `main_dish_id`
- `side_dish_ids` (zero or more)
- `created_at`

A unique constraint enforces **one log entry per date** — editing an
existing entry replaces it; no second meal can be logged for the same day.

The log entry is the source of truth for history. Foreign keys to mains
and sides are preserved even after the referenced item is soft-deleted, so
old entries still display their meal names.

### Current suggestion (cache) (stage 2)

To survive accidental tab/browser closes and crashes, the seven-meal
suggestion is persisted server-side until the user regenerates it. A single
row keyed by "current suggestion" is enough — there's only ever one active
list. Reopening the app shows the same seven meals until the user explicitly
regenerates or swaps.

- `id`
- `slots` — ordered list of `{ main_dish_id, side_dish_ids[] }`
- `updated_at`

## 7. Features

### 7.1 Suggestion view ("Plan") (stage 2)

- Displays seven suggested meals.
- Each meal = one main dish + zero or more side dishes (sides only if the
  main's `has_sides` flag is true).
- Each meal position has two swap controls:
  - **Swap (same category)** — default. Replaces the main with a different
    main of the same category.
  - **Swap (any category)** — replaces the main with any eligible main
    regardless of category. May break category coverage; see §8.1.
  - Both honor the cooldown.
- A **regenerate all** action produces a fresh list of seven and overwrites
  the cached current suggestion.
- No dates, no ordering beyond "these are the next seven." Order is not
  tied to calendar days.
- The suggestion list is the front page / default view, and is restored from
  the server-side cache on page load so a browser crash doesn't lose it.

### 7.2 Meal log view ("Mark") (stage 1)

- Form to record what was actually eaten:
  - Date picker (defaults to today).
  - Main dish selector.
  - Side dish selector (multi-select, optional).
- List of recent log entries with edit/delete.
- Entries are editable and deletable — history is not sacred, typos happen.

### 7.3 Admin (stage 1 — catalog; stage 2 — settings)

- Add / edit / delete main dishes (with categories and `has_sides`). Names
  are normalized to sentence case on save. Delete is a soft-delete.
- Add / edit / delete side dishes. Same sentence-case normalization and
  soft-delete behavior.
- Duplicate detection on create/edit is **case-insensitive** against the
  set of non-soft-deleted items ("chicken curry" and "Chicken Curry" are
  treated as the same name).
- **Mass import** of mains and sides via JSON paste or file upload.
  - JSON shape (proposed):
    ```json
    {
      "mains": [
        {"name": "Spaghetti Bolognese", "categories": ["meat"], "has_sides": false},
        {"name": "Chicken Curry", "categories": ["chicken"], "has_sides": true},
        {"name": "Tortillas", "categories": ["meat", "chicken", "fish", "vegetarian"], "has_sides": false}
      ],
      "sides": [
        {"name": "Green salad"},
        {"name": "Rice"}
      ]
    }
    ```
  - Import is **best-effort, not atomic**: valid rows are inserted, invalid
    rows (bad categories, missing fields, duplicates) are skipped and
    reported back to the user in a per-row summary. Names are normalized to
    sentence case on import; duplicate detection is case-insensitive.
- Settings page for the cooldown window (default **14 days**, configurable).
  *(Stage 2 — only relevant once the suggester exists.)*

### 7.4 Appearance (stage 1)

- A light / dark theme switch, remembered **per device**. The instance is
  shared and has no accounts, so this is a device preference in
  `localStorage`, never a server-side setting — the phone in the kitchen and
  the laptop must be able to disagree.
- Two states only, **dark by default**. Following the system was considered
  and dropped: a third state costs a control that is harder to read than the
  choice is worth.
- One button, and its icon **is the theme that is currently on** — a moon
  while dark, a sun while light. Not the state a click would produce. A
  lightswitch does not read "off" while the lights are on. The accessible
  label names the state first and the action second: "Tumma teema. Vaihda
  vaaleaan."
- Implementation is `color-scheme` on the root element: `only light` or
  `only dark`. The default is in the server-rendered markup, so it survives
  having no JavaScript. Because the palette is built from `light-dark()`
  custom properties, no other CSS changes.

## 8. Suggestion algorithm (stage 2)

Produce seven mains, then attach sides per meal.

### 8.1 Hard constraints (mains)

1. **Cooldown**: exclude any main dish that appears in the meal log within
   the last *N* days, where *N* is configurable (default 14).
2. **Category coverage**: the union of all seven mains' `categories` sets
   must include `meat`, `chicken`, `fish`, and `vegetarian`. A
   multi-category main covers every category in its set at once, so a
   single tortillas appearance can satisfy several requirements
   simultaneously.
3. If a category cannot be covered by any eligible main (including
   multi-category ones) after cooldown, the UI surfaces a clear warning and
   that category is **excluded from this round's list**. The seven meals
   are drawn from the remaining mains. Cooldown is never silently relaxed.

### 8.2 Weighting (mains)

Within the eligible pool, each main's probability of being picked is
proportional to how often it appears in the meal log — favorites are picked
**more often**, not less. This is a deliberate inversion of the typical
"recommend what you haven't tried" heuristic: the household wants to keep
eating what they already like.

To prevent the list from being dominated by the top few favorites, the
weight is clamped so that no eligible main has a zero or near-zero
probability. Concretely (MVP):

```
weight(main) = max(base_weight, times_eaten)
```

where `base_weight` is a small positive floor (e.g., `1`). Sampling is
without replacement within the seven-meal list.

This is tunable later; the important invariant is **no dead meals**.

### 8.3 Sides

- Only mains with `has_sides = true` get sides attached. Mains with
  `has_sides = false` (casseroles, one-pots) always get zero sides.
- For eligible mains, pick 1–2 side dishes uniformly at random from the
  side pool. No cooldown, no frequency weighting on sides.

### 8.4 Swap action

Two swap modes, exposed as separate controls on each slot:

- **Swap within same category** (default). The replacement main's
  `categories` must be a superset of the slot's current `categories`, so
  the week's coverage cannot be weakened by the swap.
  - For a single-category slot, any main sharing that category qualifies.
  - For a multi-category slot (e.g., tortillas), only mains covering the
    same full set qualify — often only other wildcards. If nothing
    qualifies, the button is disabled and the user falls back to "any
    category".
- **Swap any category**. The replacement can be any eligible main. If this
  breaks coverage (e.g., removes the only fish), the UI warns but allows
  it — the user is explicitly asking for freedom.

Both modes honor the cooldown. After a swap, the cached current suggestion
is updated in place.

## 9. Tech stack

The whole app is one static Go binary. There is no Node.js anywhere in the
build and no asset bundler.

- **Language**: Go 1.27. No `toolchain` directive is pinned in `go.mod`, so
  moving to a newer Go is a one-line change.
- **HTTP**: standard library `net/http` with `http.ServeMux`. Its method +
  path patterns cover the ~15 routes this app needs; no third-party router.
- **Views**: [templ](https://templ.guide) components, rendered server-side.
  `templ` is a `go tool` dependency and runs at build time; the generated
  `*_templ.go` files are not committed.
- **Interactivity**: [Datastar](https://data-star.dev). One ~11 kB script
  supplies both the reactive client state and the server-driven DOM patching,
  replacing what would otherwise be htmx *and* Alpine.js. Its reference SDK
  is Go (`github.com/starfederation/datastar-go`): handlers read client state
  with `datastar.ReadSignals` and reply over SSE with `PatchElements`.
- **Styling**: hand-written CSS, one file, no framework and no build step.
  Light and dark themes come from `color-scheme: light dark` plus
  `light-dark()` custom properties, which also gets native form controls,
  scrollbars, and focus rings themed for free. Explicitly not Pico, not
  Tailwind, not SCSS.
- **Fonts**: self-hosted `woff2` under `static/`. No external font CDN — the
  app has to work with no internet access at all.
- **Database**: SQLite through `modernc.org/sqlite`, which is pure Go and so
  keeps `CGO_ENABLED=0` and a fully static binary. One file on a named
  volume; there is no separate database service. A single household writing
  one row per day does not need Postgres.
- **Data access**: `database/sql` and hand-written SQL. No ORM.
- **Migrations**: numbered `.sql` files under `cmd/foodster/migrations`,
  embedded with `embed.FS` and applied in filename order on startup. Each one
  runs inside a transaction and is recorded in a `schema_migrations` table, so
  it applies exactly once. No migration library — the runner is about sixty
  lines of `database/sql`. There are no down-migrations: restoring the
  database file is the rollback for a single-household app.
- **Bundle import**: the §7.3 mass import is a live feature of the running
  app, on the Ruuat tab — paste JSON or upload a file, get a per-row report
  back. A plain multipart form rather than a Datastar round trip, since the
  response is a whole-page report and a form needs no client code. Uploads
  are capped at 1 MiB. The same importer is also reachable as
  `foodster -import <file.json>` for repopulating a scratch database without
  starting the server; `seeds/testi.json` is the committed fixture. One code
  path serves both, so the format is exercised twice.
- **Time**: the `TZ` environment variable, defaulting to `Europe/Helsinki`,
  loaded via `time.LoadLocation` and fatal on a bad value — a silent fallback
  to UTC would shift logged dinners to the wrong calendar day. `time/tzdata`
  is imported because the runtime image carries no zoneinfo. All date logic
  uses that location explicitly and never `time.Local`.
- **Auth**: none in the app. Every route is served unauthenticated, because
  the only client that can reach the app is Traefik, which forwards each
  request to **Authelia** first. Sessions, brute-force protection and
  multi-factor are configured there once for every service on the host.
  Deliberately not reimplemented per app: the earlier in-app HTTP Basic layer
  meant two prompts for one door, and the weaker of the two was the one
  holding a shared password.
- **Exposure**: served on a public hostname behind Traefik, which terminates
  TLS. Two invariants carry the whole security model, and both are asserted
  in `compose.yaml`. The router names the Authelia middleware through `AUTH`
  — unset or misspelt, Traefik takes the router out of service, so a typo
  fails shut. And the container publishes no ports, so it is reachable only
  over the shared proxy network; publishing `8080` would expose an
  unauthenticated plaintext copy on the host. `/healthz` returns only the
  version and is safe to bypass in Authelia for monitoring.
- **Containers**: built with Podman in development, run under Docker Compose
  in production. Images are OCI, so one image works with both engines.

Explicitly *not* React.

## 10. Deployment

Images are built by CI, pushed to a private container registry, then pulled on
the server and run with Docker Compose.

- **Branches**: `main` carries released versions only, so its history is the
  deployment history and every release tag points into it. Development happens
  on `dev`, and `main` is protected on the remote: it accepts no direct
  pushes, so a release arrives as a pull request from `dev`. The release
  workflow runs only on `main`, so a release cannot be built from anywhere
  else and nothing needs to check for it.
- **Versioning**: CalVer `vYYYYMMDD-N`, where `N` is the Nth build of that
  day. The release workflow derives `N` by counting the day's existing git
  tags, creates the new tag, and bakes the version into the binary through
  `-ldflags -X main.version`.
- **CI**: Gitea Actions, workflows in `.gitea/workflows/`. `check.yaml` runs
  `make check` on every push to `dev`; `release.yaml` builds and pushes the
  image when a pull request merges into `main`. Merging is the release —
  there is no local build step.
- **Tooling**: a `Makefile` covers development — `make` on its own lists every
  target. Build, test, lint, format and compose commands live there rather
  than in loose scripts. Commands run a handful of times a year are written
  out in the README instead of earning a target.
- **Image**: a two-stage `Containerfile`. `golang:1.27-alpine` compiles a
  static binary; the runtime stage is `FROM scratch` holding only that
  binary, running as UID 65534.
- **Compose**: a single service. No database container — SQLite lives at
  `/data/foodster.db`, bind-mounted from `./data` on the host rather than
  kept in a named volume, so the file can be listed and copied without going
  through the container engine. Backup is `cp -r data`. Because the image
  runs as UID 65534, compose sets `user:` from `PUID`/`PGID`
  to match whoever owns that directory. `restart: unless-stopped`.
- **Configuration**, entirely through environment variables (see
  `.env.example`):
  Names carry no application prefix: the container namespaces them already.
  - `REPO` and `TAG` — image coordinates.
  - `AUTH` — the Traefik middleware that authenticates the app, e.g.
    `authelia@docker`. Required; it is the app's only access control.
  - `HOST` and `CERTRESOLVER` — the hostname Traefik matches on and the
    resolver that issues its certificate.
  - `DB` — database file path, default `./data/foodster.db`. The directory is
    created on startup if missing.
  - `ENV` — anything but `prod` is prefixed to the browser tab title, so a
    dev instance open beside the real one can be told apart.
  - `PUID` / `PGID` — host owner of `./data`. Not `UID`, which is read-only
    in bash and would be replaced by the invoking shell's own value.
  - `TZ` — default `Europe/Helsinki`.
- The registry hostname exists only in `.env`, which is gitignored, because
  §11 leaves open the possibility of publishing this repository.
- **Routing**: Traefik on an external `traefik` network, matching on
  `HOST` and terminating TLS. The container publishes no ports —
  doing so would put an unencrypted copy of the app on the host, bypassing
  the proxy. The hostname lives in `.env` rather than `compose.yaml`, so no
  infrastructure detail is committed.
- **Health**: `GET /healthz` returns the build version and nothing else, so it
  is safe to exempt in Authelia. There is no Docker `HEALTHCHECK` directive,
  because a `scratch` image
  has no shell to run one and `restart: unless-stopped` already covers a dead
  process. Adding one would mean giving the binary a `-healthcheck` flag that
  calls its own endpoint.
- Pending migrations are applied on app start.
- The Datastar client is vendored at `cmd/foodster/static/datastar.js` and
  served from the app's own origin — the SDK ships no browser asset, and a
  CDN link would break an offline LAN. The README says how to refresh it; the pinned
  version lives in the `Makefile` and in the file's first line.
- No internet exposure; the server binds to the LAN.

## 11. Licensing

MIT from the outset — see `LICENSE`, copyright Kessinen. The repository stays
private during build-out, so releasing it later is a matter of flipping
visibility rather than relicensing.

This is why no infrastructure detail (registry hostname, server name, port
mapping) may be committed: those live in `.env`, which is gitignored.

## 12. Open questions / future work

- Grocery list generation from the seven-meal suggestion (requires adding
  ingredients to the meal model — out of scope for MVP).
- Tags on mains (e.g., "quick", "summer", "comfort") to filter suggestions.
- Seasonal biasing (e.g., soups in winter).
- Optional "pin" on a suggested slot so `regenerate all` doesn't replace it.
- Backup / export of the meal log (JSON dump).
- Telemetry-free analytics: a stats page showing most-eaten mains, category
  distribution over time, etc.