Release: Feature 17 — Shopping List and Supply Archive
Promoting dev into main. Content delta: one feature (Feature 17) plus the runbook-to-CTXD rider; deploy/RUNBOOK.md is the only file deleted.
What this release actually does — and what it does not
Ships and works now: the weekly Supply run generated deterministically from the plan's dinners and normalized ingredients, grouped by dinner, with unchecking as the only pantry mechanism; item toggles and counts, including the offline queue that replays them; the AI-written archive title (archive_title, run as a job that never blocks the list); the Supply archive API and screen grouping posts by week/month/year with the current-week highlight; frozen lists are read-only — a frozen list rejects edits with 409 and serves read-only; the Push to Calendar hook that generates the week's list and reports every outcome honestly (a Supply run that was not made is reported as not made, with its recovery).
Does not ship yet — stated plainly so this release record does not overstate it: nothing freezes a week automatically. Freeze is implemented and tested, but its caller is the week_rollover schedule, which is Feature 20 (Scheduler and Weekly Automation) in this project's plan — Feature 20's scope includes "week_rollover (Mon 00:05 → freeze last week's list into the archive)". Until Feature 20 lands, a week is frozen only when Freeze is invoked directly, so in normal operation no past week becomes read-only. Archive posts can still appear before Feature 20: the archive query returns a week's Supply run through the current week regardless of whether it was frozen, so an unfrozen run can be listed there and presented read-only by the archive screen while it remains editable through the ordinary Supply run route until the rollover exists. "Send to Google Chat" is likewise disabled until Feature 19, as its feature guardrails specify.
An independent release reviewer raised this as its blocking finding: the earlier wording of this description claimed "week-rollover freeze" among what ships. That wording was wrong and this section replaces it. The question the owner may want to weigh is a product one, not a code one: whether to promote Feature 17 with automatic archival deferred to Feature 20 (planned ordering: 17 → 19 → 20), or to hold this promotion until Feature 20 wires the rollover. The orchestrator's reading is that the feature split is deliberate and recorded in both features' descriptions, so the correct fix was to correct this record rather than pull Feature 20's scheduler forward into a Feature 17 promotion.
Included
Feature 17, merged to dev as PR #140 (feature head e903e5e, reviewed read-only and approved at that exact head; dev's squash commit cb451ba has a byte-identical tree). A remediation round on the Calendar-push seam (task e75db0f0, PR #141, four review rounds) closed a HIGH in which a Supply run that was never made was reported as a successful push. The rider deletes deploy/RUNBOOK.md (1417 lines) and re-points references at CTXD project mealquest, file RUNBOOKS.MD (published version 6), per the owner's binding directive; it was reviewed and approved separately (task e81ed994, PR #137).
Release checks
At the release content (cb451ba, log /tmp/opencode/release-suite.log): gofmt -l . empty, go vet ./... clean, go test -race -count=1 ./..., CGO_ENABLED=0 go build ./..., make sqlc-check no drift, make test, make build, make docker — all rc=0. The identical content passed the full feature-level suite at e903e5e (log /tmp/opencode/feature17-suite2.log): every gate rc=0, 27 Go packages ok, 49 web test files / 882 tests. The branch then merges origin/main in, changing no content (git diff --stat cb451ba e0574b1 empty), so main is an ancestor and nothing on main is dropped.
Migration and deploy notes
0016_shopping_list_untitled.sql is the first migration main does not already have. An independent reviewer concluded it is safe for the live Feature 16 database: the shopping tables had no application write path, the rebuild is transactional, upgrade tests cover populated valid rows plus rollback for an undated group, and applied migrations are untouched. Two ordering constraints for the deploy: main already requires Feature 16's configuration at boot (MEALQUEST_GOOGLE_CLIENT_ID, MEALQUEST_GOOGLE_CLIENT_SECRET_FILE), and once 0016 applies the older binary will refuse the newer schema, so take a restorable Litestream point first, per the runbook. The deploy procedure lives in CTXD RUNBOOKS.MD; its verification must check the reported version and at least one real screen, not just /health returning 200 (the live site is currently a Feature 06-era build — Maestro 3abfb643).
Findings carried, none blocking
A release reviewer (R-02, MEDIUM) also noted that the archive query returns a week's run whether or not it was frozen, so an unfrozen run can be listed and shown read-only while still editable through the Supply run route; that is recorded as a Feature 22 follow-up. It is a transitional consequence of deferring the rollover to Feature 20, not a code defect in this release.
Feature 22 22f80eb6 (archived posts join the current dinner name; deferred because the fix changes migration 0016 in the deploy path) and 4d299127 (a late in-flight Supply run read can overwrite a just-made list; deferred by policy with the reviewer's correction recorded).
Only overseer merges into main.
## Release: Feature 17 — Shopping List and Supply Archive
Promoting `dev` into `main`. Content delta: one feature (Feature 17) plus the runbook-to-CTXD rider; `deploy/RUNBOOK.md` is the only file deleted.
## What this release actually does — and what it does not
**Ships and works now:** the weekly Supply run generated deterministically from the plan's dinners and normalized ingredients, grouped by dinner, with unchecking as the only pantry mechanism; item toggles and counts, including the offline queue that replays them; the AI-written archive title (`archive_title`, run as a job that never blocks the list); the Supply archive API and screen grouping posts by week/month/year with the current-week highlight; **frozen lists are read-only** — a frozen list rejects edits with 409 and serves read-only; the Push to Calendar hook that generates the week's list and reports every outcome honestly (a Supply run that was not made is reported as not made, with its recovery).
**Does not ship yet — stated plainly so this release record does not overstate it:** nothing freezes a week automatically. `Freeze` is implemented and tested, but its caller is the `week_rollover` schedule, which is **Feature 20 (Scheduler and Weekly Automation)** in this project's plan — Feature 20's scope includes "week_rollover (Mon 00:05 → freeze last week's list into the archive)". Until Feature 20 lands, a week is frozen only when `Freeze` is invoked directly, so in normal operation no past week becomes read-only. Archive posts can still appear before Feature 20: the archive query returns a week's Supply run through the current week regardless of whether it was frozen, so an unfrozen run can be listed there and presented read-only by the archive screen while it remains editable through the ordinary Supply run route until the rollover exists. "Send to Google Chat" is likewise disabled until Feature 19, as its feature guardrails specify.
An independent release reviewer raised this as its blocking finding: the earlier wording of this description claimed "week-rollover freeze" among what ships. That wording was wrong and this section replaces it. The question the owner may want to weigh is a product one, not a code one: whether to promote Feature 17 with automatic archival deferred to Feature 20 (planned ordering: 17 → 19 → 20), or to hold this promotion until Feature 20 wires the rollover. The orchestrator's reading is that the feature split is deliberate and recorded in both features' descriptions, so the correct fix was to correct this record rather than pull Feature 20's scheduler forward into a Feature 17 promotion.
## Included
Feature 17, merged to `dev` as PR #140 (feature head `e903e5e`, reviewed read-only and approved at that exact head; `dev`'s squash commit `cb451ba` has a byte-identical tree). A remediation round on the Calendar-push seam (task `e75db0f0`, PR #141, four review rounds) closed a HIGH in which a Supply run that was never made was reported as a successful push. The rider deletes `deploy/RUNBOOK.md` (1417 lines) and re-points references at CTXD project `mealquest`, file `RUNBOOKS.MD` (published version 6), per the owner's binding directive; it was reviewed and approved separately (task `e81ed994`, PR #137).
## Release checks
At the release content (`cb451ba`, log `/tmp/opencode/release-suite.log`): `gofmt -l .` empty, `go vet ./...` clean, `go test -race -count=1 ./...`, `CGO_ENABLED=0 go build ./...`, `make sqlc-check` no drift, `make test`, `make build`, `make docker` — all rc=0. The identical content passed the full feature-level suite at `e903e5e` (log `/tmp/opencode/feature17-suite2.log`): every gate rc=0, 27 Go packages ok, 49 web test files / 882 tests. The branch then merges `origin/main` in, changing no content (`git diff --stat cb451ba e0574b1` empty), so `main` is an ancestor and nothing on `main` is dropped.
## Migration and deploy notes
`0016_shopping_list_untitled.sql` is the first migration `main` does not already have. An independent reviewer concluded it is safe for the live Feature 16 database: the shopping tables had no application write path, the rebuild is transactional, upgrade tests cover populated valid rows plus rollback for an undated group, and applied migrations are untouched. Two ordering constraints for the deploy: `main` already requires Feature 16's configuration at boot (`MEALQUEST_GOOGLE_CLIENT_ID`, `MEALQUEST_GOOGLE_CLIENT_SECRET_FILE`), and once `0016` applies the older binary will refuse the newer schema, so take a restorable Litestream point first, per the runbook. The deploy procedure lives in CTXD `RUNBOOKS.MD`; its verification must check the reported version and at least one real screen, not just `/health` returning 200 (the live site is currently a Feature 06-era build — Maestro `3abfb643`).
## Findings carried, none blocking
A release reviewer (R-02, MEDIUM) also noted that the archive query returns a week's run whether or not it was frozen, so an unfrozen run can be listed and shown read-only while still editable through the Supply run route; that is recorded as a Feature 22 follow-up. It is a transitional consequence of deferring the rollover to Feature 20, not a code defect in this release.
Feature 22 `22f80eb6` (archived posts join the current dinner name; deferred because the fix changes migration `0016` in the deploy path) and `4d299127` (a late in-flight Supply run read can overwrite a just-made list; deferred by policy with the reviewer's correction recorded).
Only `overseer` merges into `main`.
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
Release: Feature 17 — Shopping List and Supply Archive
Promoting
devintomain. Content delta: one feature (Feature 17) plus the runbook-to-CTXD rider;deploy/RUNBOOK.mdis the only file deleted.What this release actually does — and what it does not
Ships and works now: the weekly Supply run generated deterministically from the plan's dinners and normalized ingredients, grouped by dinner, with unchecking as the only pantry mechanism; item toggles and counts, including the offline queue that replays them; the AI-written archive title (
archive_title, run as a job that never blocks the list); the Supply archive API and screen grouping posts by week/month/year with the current-week highlight; frozen lists are read-only — a frozen list rejects edits with 409 and serves read-only; the Push to Calendar hook that generates the week's list and reports every outcome honestly (a Supply run that was not made is reported as not made, with its recovery).Does not ship yet — stated plainly so this release record does not overstate it: nothing freezes a week automatically.
Freezeis implemented and tested, but its caller is theweek_rolloverschedule, which is Feature 20 (Scheduler and Weekly Automation) in this project's plan — Feature 20's scope includes "week_rollover (Mon 00:05 → freeze last week's list into the archive)". Until Feature 20 lands, a week is frozen only whenFreezeis invoked directly, so in normal operation no past week becomes read-only. Archive posts can still appear before Feature 20: the archive query returns a week's Supply run through the current week regardless of whether it was frozen, so an unfrozen run can be listed there and presented read-only by the archive screen while it remains editable through the ordinary Supply run route until the rollover exists. "Send to Google Chat" is likewise disabled until Feature 19, as its feature guardrails specify.An independent release reviewer raised this as its blocking finding: the earlier wording of this description claimed "week-rollover freeze" among what ships. That wording was wrong and this section replaces it. The question the owner may want to weigh is a product one, not a code one: whether to promote Feature 17 with automatic archival deferred to Feature 20 (planned ordering: 17 → 19 → 20), or to hold this promotion until Feature 20 wires the rollover. The orchestrator's reading is that the feature split is deliberate and recorded in both features' descriptions, so the correct fix was to correct this record rather than pull Feature 20's scheduler forward into a Feature 17 promotion.
Included
Feature 17, merged to
devas PR #140 (feature heade903e5e, reviewed read-only and approved at that exact head;dev's squash commitcb451bahas a byte-identical tree). A remediation round on the Calendar-push seam (taske75db0f0, PR #141, four review rounds) closed a HIGH in which a Supply run that was never made was reported as a successful push. The rider deletesdeploy/RUNBOOK.md(1417 lines) and re-points references at CTXD projectmealquest, fileRUNBOOKS.MD(published version 6), per the owner's binding directive; it was reviewed and approved separately (taske81ed994, PR #137).Release checks
At the release content (
cb451ba, log/tmp/opencode/release-suite.log):gofmt -l .empty,go vet ./...clean,go test -race -count=1 ./...,CGO_ENABLED=0 go build ./...,make sqlc-checkno drift,make test,make build,make docker— all rc=0. The identical content passed the full feature-level suite ate903e5e(log/tmp/opencode/feature17-suite2.log): every gate rc=0, 27 Go packages ok, 49 web test files / 882 tests. The branch then mergesorigin/mainin, changing no content (git diff --stat cb451ba e0574b1empty), somainis an ancestor and nothing onmainis dropped.Migration and deploy notes
0016_shopping_list_untitled.sqlis the first migrationmaindoes not already have. An independent reviewer concluded it is safe for the live Feature 16 database: the shopping tables had no application write path, the rebuild is transactional, upgrade tests cover populated valid rows plus rollback for an undated group, and applied migrations are untouched. Two ordering constraints for the deploy:mainalready requires Feature 16's configuration at boot (MEALQUEST_GOOGLE_CLIENT_ID,MEALQUEST_GOOGLE_CLIENT_SECRET_FILE), and once0016applies the older binary will refuse the newer schema, so take a restorable Litestream point first, per the runbook. The deploy procedure lives in CTXDRUNBOOKS.MD; its verification must check the reported version and at least one real screen, not just/healthreturning 200 (the live site is currently a Feature 06-era build — Maestro3abfb643).Findings carried, none blocking
A release reviewer (R-02, MEDIUM) also noted that the archive query returns a week's run whether or not it was frozen, so an unfrozen run can be listed and shown read-only while still editable through the Supply run route; that is recorded as a Feature 22 follow-up. It is a transitional consequence of deferring the rollover to Feature 20, not a code defect in this release.
Feature 22
22f80eb6(archived posts join the current dinner name; deferred because the fix changes migration0016in the deploy path) and4d299127(a late in-flight Supply run read can overwrite a just-made list; deferred by policy with the reviewer's correction recorded).Only
overseermerges intomain.Independent Codex gpt-6-sol review: CHANGES_REQUIRED for this exact commit.
Independent Codex gpt-6-sol review: APPROVED for this exact commit.