Merge pull request 'Release: Feature 24 (Automated deploys)' (#211) from release/2026-10-12b into main

Reviewed-on: #211
Reviewed-by: The Reviewer <18+review_agent@code.cubecraftcreations.com>

AGENTS.md

@@ -78,18 +78,17 @@ behaviour, exercise it (hit the endpoint, render the page).
 | Path | Purpose |
 | --- | --- |
 | `cmd/server` | Entry point. Wiring only — no business logic. |
-| `cmd/vapidgen` | Prints a new VAPID key pair for Web Push. |
 | `internal/config` | `MEALQUEST_*` environment config; secrets from `*_FILE`. |
 | `internal/server` | HTTP server, routes, `/health`. |
 | `internal/frontend` | `go:embed` of the built PWA with SPA fallback. |
-| `internal/*` | `auth`, `forwarded`, `secureurl`, `db`, `store`, `secretbox`, `household`, `dinners`, `recipes`, `ai/llm`, `ai/harness`, `ai/skills`, `ai/aisettings`, `suggest`, `plan`, `shopping`, `ideas`, `home`, `gcal`, `notify`, `push`, `chat`, `vapid`, `jobs`, `scheduler` — one line each in [ARCHITECTURE.md](docs/ARCHITECTURE.md#repository-layout). |
-| `migrations/` | SQL migrations, embedded and applied at boot by `internal/store`; sqlc queries in `migrations/queries/`. |
+| `internal/*` (planned) | `auth`, `db`, `store`, `secretbox`, `household`, `dinners`, `recipes`, `ai/llm`, `ai/harness`, `ai/skills`, `suggest`, `plan`, `shopping`, `ideas`, `gcal`, `notify`, `push`, `chat`, `jobs`, `scheduler`. |
+| `migrations/` | SQL migrations (planned). |
 | `web/` | React PWA source. |
 | `deploy/` | Deployment files: compose stack, systemd units, [deploy runbook](deploy/RUNBOOK.md) and the automated deploy (`auto-deploy.sh` with `systemd/mealquest-auto-deploy.*`). |
 | `docs/` | Project documentation, including [ARCHITECTURE.md](docs/ARCHITECTURE.md). |
 | `design/` | Requirements and UI handoff. **Read-only reference** — do not edit. |
 | `Dockerfile` | Multi-stage image build, at the repository root. |
-| `Makefile` | `dev`, `test`, `build`, `docker`; `sqlc` and `sqlc-check` regenerate and check `internal/db`. |
+| `Makefile` | `dev`, `test`, `build`, `docker`. |
 | `.gitea/workflows/ci.yml` | CI quality floor. |
 
 Design references:
@@ -105,10 +104,7 @@ Design references:
 - **Task branches:** `task/<slug>_<task-uuid>`, branched from the feature branch.
 - Task pull requests **squash-merge into the feature branch**.
 - The feature pull request merges into `dev`.
-- **Only `overseer` merges `dev` → `main`** (a release). On the production
-  host, `mealquest-auto-deploy.timer` then deploys the new `main` once its
-  CI passes ([deploy/RUNBOOK.md](deploy/RUNBOOK.md) "Automated deploys");
-  nothing deploys `dev` or a feature branch.
+- **Only `overseer` merges `dev` → `main`** (a release).
 - Never push directly to `dev` or `main`.
 - Authors never review, approve, merge or close their own work.
 - Never store credentials in the repository; environment or ignored files only.

README.md

@@ -7,27 +7,9 @@ builds a weekly plan, pushes it to Google Calendar, and generates a shopping
 list grouped by dinner, kept as a browsable weekly history. It ships as a
 single Go service with the React PWA embedded in the binary.
 
-Production runs at <https://mealquest.cubecraftlabs.com> for one household,
-signed in through Authentik.
-
-## Stack
-
-- **Backend:** Go 1.25 (`CGO_ENABLED=0`, one static binary), chi router,
-  SQLite through `modernc.org/sqlite` with sqlc queries and embedded
-  migrations, Authentik OIDC, `log/slog`. AI calls go to an
-  OpenAI-compatible, Anthropic or Ollama endpoint over plain HTTP; recipes
-  come from SearXNG or Brave search and the recipe page's schema.org data.
-  Google Calendar, Google Chat and Web Push are the integrations.
-- **Frontend:** React 19, TypeScript, Vite, React Router 7, TanStack Query 5,
-  `vite-plugin-pwa`, CSS Modules over the design tokens; tests with Vitest,
-  Testing Library and jsdom.
-- **Deployment:** a Docker Compose stack (the service, Litestream
-  replication to the NAS, a SearXNG sidecar) behind Traefik, with systemd
-  units for the firewall, nightly media backup and the automated deploy of
-  `main`.
-
-The approved dependency list is in [AGENTS.md](AGENTS.md); nothing else is
-added without the owner's approval.
+> Status: this repository is the Feature 01 scaffold (Go service with
+> `/health`, embedded PWA skeleton, Makefile, Dockerfile, CI). The planned
+> application is described in [docs/ARCHITECTURE.md](docs/ARCHITECTURE.md).
 
 ## Running it locally
 
@@ -46,15 +28,6 @@ invalid variable.
 | `make test`    | `gofmt` check, `go vet`, `go test -race`, web typecheck and tests. |
 | `make build`   | Build the PWA, embed it, build the static binary `bin/mealquest`. |
 | `make docker`  | Build the container image from the root `Dockerfile`.           |
-| `make sqlc-check` | Regenerate `internal/db` with sqlc and fail if it drifted.   |
-
-## Deploying and operating
-
-[deploy/RUNBOOK.md](deploy/RUNBOOK.md) is the deploy runbook: build, ship and
-restart, verifying the deployed version, rollback and the automated deploy.
-Database restore, the boot configuration and other host procedures are in
-CTXD: project `mealquest`, file `RUNBOOKS.MD`. Only `overseer` releases, by
-merging `dev` into `main`.
 
 ## Where to read next
 

docs/ARCHITECTURE.md

@@ -2,8 +2,10 @@
 
 This mirrors the architecture section of `CONTEXT.MD` in the CTXD project
 `mealquest`, which is the source of record; if the two disagree, CTXD wins and
-this file should be updated. It describes the application as built; nothing
-it names is still only planned.
+this file should be updated. It describes the **planned** application. The
+repository today is the Feature 01 scaffold: `cmd/server`, `internal/config`,
+`internal/server` (`/health`), `internal/frontend` (embedded PWA with SPA
+fallback), the `web/` skeleton, `Makefile`, `Dockerfile` and CI.
 
 Decision numbers (D-NNN) refer to `DECISIONS.MD` in CTXD.
 
@@ -44,22 +46,20 @@ headers, so sign-in works whichever peer the request arrives from.
 | `cmd/vapidgen` | Prints a new VAPID key pair for Web Push. |
 | `internal/config` | Env-only `MEALQUEST_*` config; secrets from `*_FILE`. |
 | `internal/server` | HTTP server, router, middleware. |
-| `internal/forwarded` | Client IP and scheme from `X-Forwarded-*`, trusted only from `MEALQUEST_TRUSTED_PROXY`. |
-| `internal/secureurl` | The transport rule for URLs that carry credentials (`secureurl.Check`). |
 | `internal/frontend` | Embedded PWA, SPA fallback. |
 | `internal/auth` | Authentik OIDC, sessions, CSRF. |
-| `internal/db`, `internal/store` | sqlc-generated queries; SQLite connections, migrations at boot, transactions. |
+| `internal/db`, `internal/store` | SQLite connections, sqlc queries. |
 | `internal/secretbox` | AES-256-GCM encryption for `_ct` columns. |
-| `internal/household`, `internal/dinners`, `internal/recipes` | Domain: household settings and local time, dinners (grounding, photo backfill), recipe search, fetch and grounding. |
-| `internal/ai/llm`, `internal/ai/harness`, `internal/ai/skills`, `internal/ai/aisettings` | AI provider adapters, skill harness, skills, AI settings. |
-| `internal/suggest`, `internal/plan`, `internal/shopping`, `internal/ideas`, `internal/home` | Feature services. |
+| `internal/household`, `internal/dinners`, `internal/recipes` | Domain. |
+| `internal/ai/llm`, `internal/ai/harness`, `internal/ai/skills` | AI provider adapters, skill harness, skills. |
+| `internal/suggest`, `internal/plan`, `internal/shopping`, `internal/ideas` | Feature services. |
 | `internal/gcal`, `internal/notify`, `internal/push`, `internal/chat` | Integrations. |
 | `internal/vapid` | VAPID key generation and validation. |
 | `internal/jobs`, `internal/scheduler` | Background jobs and schedules. |
-| `migrations/` | SQL migrations, embedded and applied at boot by `internal/store` (no goose or golang-migrate); sqlc queries in `migrations/queries/`. |
+| `migrations/` | SQL migrations (no goose or golang-migrate). |
 | `web/` | React PWA. |
-| `deploy/` | Production compose stack, systemd units, the [deploy runbook](../deploy/RUNBOOK.md) and the automated deploy (see Deployment). |
-| `docs/` | Documentation (this file). |
+| `deploy/` | Deployment files. |
+| `docs/` | Documentation. |
 | `design/` | Requirements and UI handoff (read-only reference). |
 
 ## Backend stack and conventions
@@ -811,20 +811,6 @@ purge are fixed and not configurable.
 
 Runs are recorded in `schedule_runs` and executed through `jobs`.
 
-Job kinds (`internal/jobs`; each registered when `cmd/server` builds the
-service named, before the runner starts). `POST /api/v1/jobs` refuses a
-service-only kind; `GET /api/v1/jobs/{id}` reports any job.
-
-| Kind | Registered by | Enqueued by | Service-only |
-| --- | --- | --- | --- |
-| `noop` | `jobs.RegisterBuiltins` | `POST /api/v1/jobs` (does nothing; proves the runner works) | no |
-| `ground_dinner` | `dinners.Service` | Adding or renaming a `pending` dinner | no |
-| `backfill_dinner_photos` | `dinners.Service` | `POST /api/v1/settings/photo-backfill` | yes |
-| `suggestion_batch` | `suggest.Service` | `POST /api/v1/suggestions/batches`, a deck decision (replenish), `suggestions_weekly` | no |
-| `draft_week` | `plan.Service` | `POST /api/v1/plans/{weekStart}/draft`, `plan_draft` | yes |
-| `title_supply_run` | `shopping.Service` | Generating an untitled Supply run | yes |
-| `ideas_from_ingredients`, `quick_ideas` | `ideas.Service` | `POST /api/v1/ideas/from-ingredients`, `POST /api/v1/ideas/quick` | yes |
-
 `internal/scheduler` runs them. A schedule registers a name, a rule read
 from the settings (`scheduler.Daily`, `Weekly` or `WeeklyForNextWeek`, or `DailyAt` for a time read from data) and a
 run function; settings changes reach it through `SettingsService.Subscribe`
@@ -1333,12 +1319,10 @@ fewer the server answers 400 `invalid_settings` naming
 `onboarding_completed` and changes nothing. Step 3 can be reached with
 fewer — by its URL, or after another member removes a Regular — so it then
 shows the server's reason with an "Add Regulars" button back to step 2.
-Notification permission is never asked for on page load. "Turn on
-notifications" subscribes this device to Web Push from the tap and says
-how it ended — on, blocked by the browser, or unsupported (on iPhone and
-iPad, until MealQuest is on the Home Screen) — then offers only "Finish
-setting up" (which completes onboarding as above); a dismissed permission
-prompt can be asked again. Offline on the
+Notification permission is never asked for on page load; until Feature 19
+wires Web Push, "Turn on notifications" asks for nothing and says plainly
+that notifications are not on yet, offering "Finish setting up" (which
+completes onboarding as above) instead of a silent success. Offline on the
 saved pages the settings cannot be read (the service worker never caches `/api/v1/settings`),
 so the saved pages open as they are.
 
@@ -1355,41 +1339,6 @@ are undone if the server refuses them. While any Regular is `pending`, the
 list is read again every 3 seconds (not while a change is in flight), and
 polling stops once none is.
 
-## Deployment
-
-Production is the compose project `mealquest` on 10.60.1.14
-([`deploy/compose.yaml`](../deploy/compose.yaml)): the `mealquest` image built
-from the root `Dockerfile`, `litestream` replicating the database to the
-NAS over SFTP, and `searxng` on the internal network only. Configuration is
-`deploy/.env` and file secrets in `deploy/secrets/`, neither committed. The
-services never restart themselves; systemd units in `deploy/systemd/` own
-the host:
-
-| Unit | Does |
-| --- | --- |
-| `mealquest-firewall.service` | Restricts port 8090 to Traefik in `DOCKER-USER`; required before the stack starts. |
-| `mealquest.service` | Starts and stops the compose stack. |
-| `mealquest-media-backup.timer` / `.service` | Backs up cached photos to the NAS nightly at 03:30. |
-| `mealquest-auto-deploy.timer` / `.service` | Automated deploy of `main` (below). |
-
-Releases: only `overseer` merges `dev` into `main`. The image carries its
-version (`git describe`: a release tag, else the short SHA), which
-`/health` reports. A deploy follows
-[`deploy/RUNBOOK.md`](../deploy/RUNBOOK.md) — build, pre-deploy restore
-point, boot-config check, ship and restart, verify the deployed SHA and a
-real screen — with rollback to the previous release. The automated deploy
-([`deploy/auto-deploy.sh`](../deploy/auto-deploy.sh), installed as
-`/usr/local/sbin/mealquest-auto-deploy`) runs those same steps unattended:
-its timer checks every quarter hour (plus up to 5 minutes' random delay),
-and deploys `refs/remotes/origin/main` only when it differs from the last
-SHA in the deploy record `/home/overseer/mealquest-auto-deploy.log`, its
-Gitea CI status is `success`, its last attempt did not fail, and
-`mealquest.service` is active. It stops at the first failure and never
-retries a failed SHA; `--ref <ref>` is the manual override. Installing,
-seeding the record and enabling the timer are host steps in the runbook's
-"Automated deploys". Database restore and the boot configuration are in
-CTXD `RUNBOOKS.MD`.
-
 ## Boundaries and gotchas
 
 - **Secrets never reach the client** — API keys, OAuth tokens and the Chat