R1: Migration 0010 now writes revision 0 into every ground_dinner job
payload that has none. Jobs queued before the upgrade carry only
dinner_id, so the boot cleanup, which matches a pending dinner to its job
by revision, failed those dinners as interrupted while their jobs were
still queued. The migration runs before the job runner starts. A new test
migrates a database to 0009, adds a pending Regular with a legacy queued
job, upgrades and boots, and checks the dinner stays pending and is then
grounded.
R2: Archiving a dinner, or renaming a pending one, now cancels the
grounding of any ground_dinner job running for it at an older revision,
so no further search, page fetch, photo download or model call is made.
The job is registered before it reads the dinner, so an archive or rename
committed after that read always finds it. A stopped job succeeds and
reports the dinner's current grounding status. The archive and rename
tests now check that the job ends while its search is still held, with
no page fetched and no model call for the stale name.
R3: gen_folds.py writes web/src/dinners/letterFolds.json from the same
table as folds_table.go, and names.ts folds through it instead of a
hand-copied subset. names.ts also lowercases letter by letter, as Go's
strings.ToLower does, rather than by context. TestLetterFoldsMatchPWA
fails when the two tables differ. The shared cases add "Ƈhili", "Ꞔarbanzo
Stew" and "ΜΟΥΣΑΚΑΣ" (final sigma).
Maestro task 5037ff86-181d-448e-927b-c2fd2258a25d.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Grounding (F2–F5):
- Each ground_dinner job carries the dinner's new grounding_revision
(migration 0010). Renaming a pending Regular raises the revision, and a
job only grounds and writes a dinner still at its revision, so a queued
original job no longer grounds the new name or decides the outcome.
- Background grounding keeps a method, minutes or difficulty a member saved
while the Regular was pending, and fills only those left empty.
- Grounding by hand clears the pasted recipe_url, and link deduplication
uses the source_url of the attached recipe, else the pending link.
- Archived dinners are not grounded: the job checks before any search,
fetch or model call, and its final update requires an unarchived row.
Onboarding (F6, F7):
- Step 3 shows "Add Regulars" back to step 2 when the server refuses to
finish with fewer than three Regulars.
- Common picks are hidden by a copy of harness Normalize/Similar, checked
against the same shared cases as the Go code.
Docs (F8): ARCHITECTURE.md covers the three-Regular minimum, step-3
recovery, the grounding revision and the dedupe rules.
F1 was fixed in 1304487; its test now also asserts the old link is never
grounded and recipe_url stays cleared.
Maestro task 5037ff86-181d-448e-927b-c2fd2258a25d.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A Regular added from a recipe link stores recipe_url, and its grounding job
grounds that link. Renaming the dinner while still pending kept the link, so
the job queued for the new name still attached the old link's recipe and
photo. UpdateDinner now sets recipe_url, and renaming a pending dinner
clears it: the fresh job grounds the new name by search, and the household
can give a link by hand to fix up the recipe if they want a specific one.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A background grounding result now applies only while the dinner is still
pending under the normalized name the job searched: GroundPendingDinner and
FailPendingDinnerGrounding match normalized_name, so a rename makes the old
job's success or failure a no-op. Renaming a dinner still pending enqueues
a fresh grounding job for the new name; if that cannot be enqueued, the
dinner's grounding is failed so it is not left pending with no job.
Completing onboarding (PATCH /api/v1/settings/household with
onboarding_completed true) is refused with 400 invalid_settings until the
household has at least three Regulars (status regular; archived and Quest
log dinners do not count), and onboarding_completed_at is set only then.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Feature 03 made the OIDC variables required, so the Feature 04 boot tests'
loadConfig helper now sets them alongside the secret key file.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
dev_agentandClaude Opus 5.5