Promote dev to main: Feature 16 (Google Calendar Sync) + pending release corrections
⚠️ DEPLOYMENT PREREQUISITE — READ BEFORE DEPLOYING
MEALQUEST_GOOGLE_CLIENT_ID and MEALQUEST_GOOGLE_CLIENT_SECRET_FILE are required at boot (fail-fast, like the OIDC variables). The service will not start on this release until the owner creates the Google OAuth web client and sets the secret on the host. Steps are in the runbook section "Google Calendar OAuth client"; deploy/compose.yaml mounts the secret and deploy/.env.example documents the variables. Provision those first, then deploy.
Trigger
Automatic, per RELEASE_PREPARATION_POLICY = AUTO: Feature 16 became task-complete and its reviewed merge into dev was verified at 7003ff9.
Release branch release/2026-10-08 was cut from that exact dev tip and then merged with origin/main, producing head 8e33b7b82466a9d97d1520d367daeb7833ec6a54, which contains both tips.
What is included
Feature 16 — Google Calendar Sync. All five tasks done, each independently reviewed at its exact head:
Feature-level review of the merged head APPROVED (081ad75), confirming migration 0015_google_reconnect_required.sql is safe to apply at boot and that nothing reads events back from Google.
Release corrections round 4 (Maestro 008c0a8a, PR #124, approved at a7b079c) — these landed in dev after the Feature 14 promotion was merged, so they ride with this release. They harden the operator's own deploy/rollback procedure: a required, verified pre-deploy backup step before the restart that applies migrations; rollback decisions made from a consistent SQLite online-backup snapshot; fail-fast, status-preserving blocks throughout the deploy, rollback and restore procedures; a media restore that verifies content against a SHA-256 NAS manifest; and WAL-sidecar ownership guidance. Worth having on mainbefore the Feature 16 deploy, which applies migration 0015.
Release checks at the release head 8e33b7b82466a9d97d1520d367daeb7833ec6a54
gofmt -l . — empty; go vet ./... — clean
go test -race -count=1 ./... — 26 packages ok, 0 failures
CGO_ENABLED=0 go build ./... — ok
make sqlc-check SQLC=$(go env GOPATH)/bin/sqlc — no drift
cd web && npm run typecheck — PASS; npm test — PASS 46 files / 804 tests; npm run build — PASS
make test, make build, docker build . — PASS
Migrations this release applies at boot
0015_google_reconnect_required.sql — makes integrations_google.refresh_token_ct nullable with a CHECK that a row without a token carries a last_sync_error. Reviewed as safe against the existing household database (transactional, preserves the row, no inbound foreign keys).
Outstanding, recorded items (not blockers)
The real "Dinners" calendar production push and its screenshot: Maestro 9a4d2601 in Feature 22 (owner-dependent — needs the OAuth client above and the deployed service).
Deferred low/medium findings: Maestro d21e4a83 in Feature 22.
The plan-screen and calendar UI behaviour is covered by Vitest plus headless-Chrome checks; the push click flow is Vitest-only.
Only Joshua merges this
Per the repository policy and the release rules this promotion stops here: the final merge into main is the owner's step, and the deploy that follows needs the prerequisite above.
# Promote dev to main: Feature 16 (Google Calendar Sync) + pending release corrections
## ⚠️ DEPLOYMENT PREREQUISITE — READ BEFORE DEPLOYING
`MEALQUEST_GOOGLE_CLIENT_ID` and `MEALQUEST_GOOGLE_CLIENT_SECRET_FILE` are **required at boot** (fail-fast, like the OIDC variables). **The service will not start on this release until the owner creates the Google OAuth web client and sets the secret on the host.** Steps are in the runbook section "Google Calendar OAuth client"; `deploy/compose.yaml` mounts the secret and `deploy/.env.example` documents the variables. Provision those first, then deploy.
## Trigger
Automatic, per `RELEASE_PREPARATION_POLICY = AUTO`: Feature 16 became task-complete and its reviewed merge into `dev` was verified at `7003ff9`.
Release branch `release/2026-10-08` was cut from that exact `dev` tip and then merged with `origin/main`, producing head `8e33b7b82466a9d97d1520d367daeb7833ec6a54`, which contains both tips.
## What is included
1. **Feature 16 — Google Calendar Sync.** All five tasks done, each independently reviewed at its exact head:
| Task | Maestro | PR | Reviewed head |
| --- | --- | --- | --- |
| Google OAuth connect and disconnect | 1e9d7850 | #125 | 2cd2e5a |
| Calendar list and selection | 0fe3f1f2 | #126 | d23d30e |
| Push plan to Google Calendar | 5885d2b1 | #127 | fb7d8dd |
| Token failure handling | b8d8da5a | #128 | ee67d52 |
| Calendar settings screen and plan sync status | 677261bc | #129 | 3a1884d |
Feature-level review of the merged head APPROVED (`081ad75`), confirming migration `0015_google_reconnect_required.sql` is safe to apply at boot and that nothing reads events back from Google.
2. **Release corrections round 4** (Maestro `008c0a8a`, PR #124, approved at `a7b079c`) — these landed in `dev` after the Feature 14 promotion was merged, so they ride with this release. They harden the operator's own deploy/rollback procedure: a required, verified pre-deploy backup step before the restart that applies migrations; rollback decisions made from a consistent SQLite online-backup snapshot; fail-fast, status-preserving blocks throughout the deploy, rollback and restore procedures; a media restore that verifies content against a SHA-256 NAS manifest; and WAL-sidecar ownership guidance. Worth having on `main` **before** the Feature 16 deploy, which applies migration 0015.
## Release checks at the release head `8e33b7b82466a9d97d1520d367daeb7833ec6a54`
- `gofmt -l .` — empty; `go vet ./...` — clean
- `go test -race -count=1 ./...` — 26 packages ok, 0 failures
- `CGO_ENABLED=0 go build ./...` — ok
- `make sqlc-check SQLC=$(go env GOPATH)/bin/sqlc` — no drift
- `cd web && npm run typecheck` — PASS; `npm test` — PASS 46 files / 804 tests; `npm run build` — PASS
- `make test`, `make build`, `docker build .` — PASS
## Migrations this release applies at boot
- `0015_google_reconnect_required.sql` — makes `integrations_google.refresh_token_ct` nullable with a CHECK that a row without a token carries a `last_sync_error`. Reviewed as safe against the existing household database (transactional, preserves the row, no inbound foreign keys).
## Outstanding, recorded items (not blockers)
- The real "Dinners" calendar production push and its screenshot: Maestro `9a4d2601` in Feature 22 (owner-dependent — needs the OAuth client above and the deployed service).
- Deferred low/medium findings: Maestro `d21e4a83` in Feature 22.
- The plan-screen and calendar UI behaviour is covered by Vitest plus headless-Chrome checks; the push click flow is Vitest-only.
## Only Joshua merges this
Per the repository policy and the release rules this promotion stops here: the final merge into `main` is the owner's step, and the deploy that follows needs the prerequisite above.
Orchestrator note — independent release review outcome for this promotion.
The read-only Codex gpt-6-sol review of the exact head 8e33b7b824 returned APPROVED: the base is an ancestor of the head; the delta is Feature 16 plus the stated documentation corrections; migration 0015 is transactional and rebuilds at most the single-row integrations_google table with no referencing tables or indexes; the Google secret is the only new mount; build files and dependency manifests are unchanged; Google calls use oauth2 and REST, events are pushed one way, refresh tokens stay server-side; the Production consent-screen instruction is present; and the refused-grant, missing-calendar, transient-failure and partial-push paths all surface errors with a retry. It also confirmed a verified pre-deploy Litestream restore point is required before the restart, and that if the release must be rolled back after migration 0015 the older binary needs that restore.
One MEDIUM (R1) is dispositioned rather than fixed, not waived: the runbook documents the Google OAuth prerequisite but its routine deploy steps have no explicit configuration check immediately before the restart, so a missed prerequisite leaves the site down because the unit does both down and up. For this deploy, verify MEALQUEST_GOOGLE_CLIENT_ID and a non-empty, readable Google client secret in deploy/.env and deploy/secrets/ before running the restart. The fix is tracked as a Maestro hardening task in Feature 22 and will land in the next release corrections.
Recorded, non-blocking: the real Dinners calendar production push and screenshot (Maestro 9a4d2601, Feature 22, owner-dependent); and the deferred low findings on Maestro d21e4a83.
Orchestrator note — independent release review outcome for this promotion.
The read-only Codex gpt-6-sol review of the exact head 8e33b7b82466a9d97d1520d367daeb7833ec6a54 returned APPROVED: the base is an ancestor of the head; the delta is Feature 16 plus the stated documentation corrections; migration 0015 is transactional and rebuilds at most the single-row integrations_google table with no referencing tables or indexes; the Google secret is the only new mount; build files and dependency manifests are unchanged; Google calls use oauth2 and REST, events are pushed one way, refresh tokens stay server-side; the Production consent-screen instruction is present; and the refused-grant, missing-calendar, transient-failure and partial-push paths all surface errors with a retry. It also confirmed a verified pre-deploy Litestream restore point is required before the restart, and that if the release must be rolled back after migration 0015 the older binary needs that restore.
One MEDIUM (R1) is dispositioned rather than fixed, not waived: the runbook documents the Google OAuth prerequisite but its routine deploy steps have no explicit configuration check immediately before the restart, so a missed prerequisite leaves the site down because the unit does both down and up. **For this deploy, verify MEALQUEST_GOOGLE_CLIENT_ID and a non-empty, readable Google client secret in deploy/.env and deploy/secrets/ before running the restart.** The fix is tracked as a Maestro hardening task in Feature 22 and will land in the next release corrections.
Recorded, non-blocking: the real Dinners calendar production push and screenshot (Maestro 9a4d2601, Feature 22, owner-dependent); and the deferred low findings on Maestro d21e4a83.
overseer
was assigned by orchestrator-agent2026-10-08 03:38:54 -04:00
Orchestrator note — owner directive received during this promotion: all RUNBOOK information must live in CTXD, never in the repository.
Consequence for this release: deploy/RUNBOOK.md is being removed from the repository in favour of CTXD project mealquest, file RUNBOOKS.MD (which will carry the full deploy, rollback, restore, count-check, media-restore, secret-rotation, Google Calendar OAuth client and troubleshooting procedures, including the release corrections this PR would otherwise have updated). This PR's head still updates deploy/RUNBOOK.md; the removal lands on dev and rides the next promotion, so after merging this promotion the runbook file will be gone from main in the following release.
The deployment prerequisite for this release is unchanged and still applies:MEALQUEST_GOOGLE_CLIENT_ID and MEALQUEST_GOOGLE_CLIENT_SECRET_FILE are required at boot, so provision the Google OAuth client and the secret before deploying a release containing Feature 16. The steps will live in CTXD RUNBOOKS.MD (Google Calendar OAuth client section) and are also recorded in this PR's first section. Verify them (and a restorable pre-deploy Litestream point) before restarting, because the systemd unit stops and then starts the stack.
Tracked as Maestro task e81ed994-a510-48e6-9cf6-e76d5d81f56c; the runbook-hardening follow-up task c3179fd9 has been re-pointed at CTXD.
Orchestrator note — owner directive received during this promotion: **all RUNBOOK information must live in CTXD, never in the repository.**
Consequence for this release: `deploy/RUNBOOK.md` is being **removed from the repository** in favour of CTXD project `mealquest`, file `RUNBOOKS.MD` (which will carry the full deploy, rollback, restore, count-check, media-restore, secret-rotation, Google Calendar OAuth client and troubleshooting procedures, including the release corrections this PR would otherwise have updated). This PR's head still updates `deploy/RUNBOOK.md`; the removal lands on `dev` and rides the next promotion, so after merging this promotion the runbook file will be gone from `main` in the following release.
**The deployment prerequisite for this release is unchanged and still applies:** `MEALQUEST_GOOGLE_CLIENT_ID` and `MEALQUEST_GOOGLE_CLIENT_SECRET_FILE` are required at boot, so provision the Google OAuth client and the secret before deploying a release containing Feature 16. The steps will live in CTXD `RUNBOOKS.MD` (Google Calendar OAuth client section) and are also recorded in this PR's first section. Verify them (and a restorable pre-deploy Litestream point) before restarting, because the systemd unit stops and then starts the stack.
Tracked as Maestro task `e81ed994-a510-48e6-9cf6-e76d5d81f56c`; the runbook-hardening follow-up task `c3179fd9` has been re-pointed at CTXD.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
review_agent
Promote dev to main: Feature 16 (Google Calendar Sync) + pending release corrections
⚠️ DEPLOYMENT PREREQUISITE — READ BEFORE DEPLOYING
MEALQUEST_GOOGLE_CLIENT_IDandMEALQUEST_GOOGLE_CLIENT_SECRET_FILEare required at boot (fail-fast, like the OIDC variables). The service will not start on this release until the owner creates the Google OAuth web client and sets the secret on the host. Steps are in the runbook section "Google Calendar OAuth client";deploy/compose.yamlmounts the secret anddeploy/.env.exampledocuments the variables. Provision those first, then deploy.Trigger
Automatic, per
RELEASE_PREPARATION_POLICY = AUTO: Feature 16 became task-complete and its reviewed merge intodevwas verified at7003ff9.Release branch
release/2026-10-08was cut from that exactdevtip and then merged withorigin/main, producing head8e33b7b82466a9d97d1520d367daeb7833ec6a54, which contains both tips.What is included
2cd2e5ad23d30efb7d8ddee67d523a1884dFeature-level review of the merged head APPROVED (
081ad75), confirming migration0015_google_reconnect_required.sqlis safe to apply at boot and that nothing reads events back from Google.008c0a8a, PR #124, approved ata7b079c) — these landed indevafter the Feature 14 promotion was merged, so they ride with this release. They harden the operator's own deploy/rollback procedure: a required, verified pre-deploy backup step before the restart that applies migrations; rollback decisions made from a consistent SQLite online-backup snapshot; fail-fast, status-preserving blocks throughout the deploy, rollback and restore procedures; a media restore that verifies content against a SHA-256 NAS manifest; and WAL-sidecar ownership guidance. Worth having onmainbefore the Feature 16 deploy, which applies migration 0015.Release checks at the release head
8e33b7b82466a9d97d1520d367daeb7833ec6a54gofmt -l .— empty;go vet ./...— cleango test -race -count=1 ./...— 26 packages ok, 0 failuresCGO_ENABLED=0 go build ./...— okmake sqlc-check SQLC=$(go env GOPATH)/bin/sqlc— no driftcd web && npm run typecheck— PASS;npm test— PASS 46 files / 804 tests;npm run build— PASSmake test,make build,docker build .— PASSMigrations this release applies at boot
0015_google_reconnect_required.sql— makesintegrations_google.refresh_token_ctnullable with a CHECK that a row without a token carries alast_sync_error. Reviewed as safe against the existing household database (transactional, preserves the row, no inbound foreign keys).Outstanding, recorded items (not blockers)
9a4d2601in Feature 22 (owner-dependent — needs the OAuth client above and the deployed service).d21e4a83in Feature 22.Only Joshua merges this
Per the repository policy and the release rules this promotion stops here: the final merge into
mainis the owner's step, and the deploy that follows needs the prerequisite above.Independent Codex gpt-6-sol review: APPROVED for this exact commit.
Orchestrator note — independent release review outcome for this promotion.
The read-only Codex gpt-6-sol review of the exact head
8e33b7b824returned APPROVED: the base is an ancestor of the head; the delta is Feature 16 plus the stated documentation corrections; migration 0015 is transactional and rebuilds at most the single-row integrations_google table with no referencing tables or indexes; the Google secret is the only new mount; build files and dependency manifests are unchanged; Google calls use oauth2 and REST, events are pushed one way, refresh tokens stay server-side; the Production consent-screen instruction is present; and the refused-grant, missing-calendar, transient-failure and partial-push paths all surface errors with a retry. It also confirmed a verified pre-deploy Litestream restore point is required before the restart, and that if the release must be rolled back after migration 0015 the older binary needs that restore.One MEDIUM (R1) is dispositioned rather than fixed, not waived: the runbook documents the Google OAuth prerequisite but its routine deploy steps have no explicit configuration check immediately before the restart, so a missed prerequisite leaves the site down because the unit does both down and up. For this deploy, verify MEALQUEST_GOOGLE_CLIENT_ID and a non-empty, readable Google client secret in deploy/.env and deploy/secrets/ before running the restart. The fix is tracked as a Maestro hardening task in Feature 22 and will land in the next release corrections.
Recorded, non-blocking: the real Dinners calendar production push and screenshot (Maestro 9a4d2601, Feature 22, owner-dependent); and the deferred low findings on Maestro d21e4a83.
Orchestrator note — owner directive received during this promotion: all RUNBOOK information must live in CTXD, never in the repository.
Consequence for this release:
deploy/RUNBOOK.mdis being removed from the repository in favour of CTXD projectmealquest, fileRUNBOOKS.MD(which will carry the full deploy, rollback, restore, count-check, media-restore, secret-rotation, Google Calendar OAuth client and troubleshooting procedures, including the release corrections this PR would otherwise have updated). This PR's head still updatesdeploy/RUNBOOK.md; the removal lands ondevand rides the next promotion, so after merging this promotion the runbook file will be gone frommainin the following release.The deployment prerequisite for this release is unchanged and still applies:
MEALQUEST_GOOGLE_CLIENT_IDandMEALQUEST_GOOGLE_CLIENT_SECRET_FILEare required at boot, so provision the Google OAuth client and the secret before deploying a release containing Feature 16. The steps will live in CTXDRUNBOOKS.MD(Google Calendar OAuth client section) and are also recorded in this PR's first section. Verify them (and a restorable pre-deploy Litestream point) before restarting, because the systemd unit stops and then starts the stack.Tracked as Maestro task
e81ed994-a510-48e6-9cf6-e76d5d81f56c; the runbook-hardening follow-up taskc3179fd9has been re-pointed at CTXD.