Public Access
R1 stabilization: pytest harness with transactional db fixture, smoke + alembic + auth + scrape + approval + swiftly tests, github actions ci yaml. Bearer-token admin auth + signed-cookie session for family ui mutations. Async POST /api/admin/scrape (BackgroundTasks, returns 202). Path canonicalization (no /list, /planned suffixes). DATABASE_URL fail-fast on empty. R2 deferred-risk spikes: live lucky california fetch (R2-A), full email+per-voter approval click round trip with single-use enforcement (R2-B, console email backend, sendgrid stub). R3-0 phase 3 redesign: replaced playwright html scraper with requests based swiftly json api client. 17 categories, ~10k products per scrape, upsert by (source, external_id). 401 surfaces actionable token-refresh message via ScrapeLog.error_message. Pre-existing defects fixed: shopping_list.py syntax error blocking app import, MealPlan.votes orphan relationship, JSONB(astext=True) invalid kwarg, missing requests dep, calorie_target schema drift, every SQLEnum needed values_callable, 0001 had empty downgrade(), seed had duplicate ingredient rows. Migrations added: 0003 grocery_item.description, 0004 family_profile. calorie_target, 0005 grocery_item.external_id + source + composite index. Verified: 31/31 pytest green, alembic upgrade->downgrade->upgrade clean, frontend npm run build clean, live scrape 9,960 grocery_item rows in 36s. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3.1 KiB
3.1 KiB
Recovery Plan — MealPlanner
Goal: bring implementation back into alignment with Review/reviewconcensus.md. Stop building forward features until the deferred-risk spikes and the verification matrix pass.
Phase R1 — Stabilize (parallel-safe)
- R1-A: Verification harness. Add
backend/tests/with pytest config, aconftest.pywith a transactional DB fixture, and smoke tests covering: app import,/health,/health/db, every router's GET list endpoint, Alembicupgrade headround-trip on a throwaway DB. Add.github/workflows/ci.ymlrunning lint + pytest + frontendnpm run build. - R1-B: Auth dependencies on existing routers. Implement an
app.securitymodule with: (1)require_admindep — bearer token compared tosettings.ADMIN_TOKEN, applied to ALL/api/admin/*routes; (2)require_sessiondep — signed-cookie session (itsdangerous, key =SECRET_KEY) for profile/pantry/recipes/meals/shopping-list mutations; reads stay open inside the trusted network. Per-voter approval token flow stays as-is. Update.env.examplewithADMIN_TOKEN. Document the model indocs/SECURITY.md. - R1-C: Make
/api/admin/scrapeasync. Convert the endpoint to enqueue a background job (FastAPIBackgroundTasksfor now; APScheduler later). Endpoint returns 202 +scrape_log_id; status polled via/api/admin/logs/{id}. ScraperService must open its own DB session inside the task (the request-scopeddbis gone by then).
Phase R2 — De-risk deferred work (parallel-safe, must run BEFORE further feature work per review §2.4)
- R2-A: Live-scrape spike. Run
LuckyCaliforniaScraperagainsthttps://luckysupermarkets.comonce, capture the raw HTML/PNG tobackend/tests/fixtures/lucky_ca/, write a unit test that parses the captured fixture (no live network in CI). Document selector decisions in.agent/context.md. If the page can't be parsed, file the schema impact before going further. - R2-B: Email + approval round-trip spike. Implement minimal SendGrid sender (
app/services/email.py), anapp/services/approval.pythat issues per-voter signed tokens (TTL, single-use), the GET confirmation page + POST submit handler (the routes already exist as stubs inmeals.py), and a CLI scriptscripts/send_test_approval.pythat creates a fake meal plan, emails one voter, and verifies the click→POST→DB write path end to end against a sandboxed inbox orMAIL_BACKEND=console. Goal: prove the schema (family_member, approval_token tables) survives one full round trip BEFORE building Phase 4/5/9.
Phase R3 — Resume feature work (sequential, only after R1+R2 green)
- R3-A: Phase 4 Recipe Engine — search, tagging, never-suggest filter.
- R3-B: Phase 9 Meal Planner generation algorithm.
- R3-C: Phase 6 SendGrid templated emails (proposal, reminder, confirmation).
- R3-D: Phase 8 Feedback UI.
- R3-E: APScheduler with
--workers 1for weekly scrape + plan generation + email send. - R3-F: Phase 10 image strategy.
Halt conditions
- R2 spikes fail → stop, propose schema/spec change, await approval.
- Verification matrix in
Review/reviewconcensus.md §6not green → no R3 work begins.