Frontend Integration Spec (Household v2)

Date: 2025-11-01

This document summarizes the current backend API surface (post v2 migration) and the prioritized actions to keep the frontend aligned.

Current API Highlights

Auth: JWT bearer via /api/v1/auth/register|login|refresh|logout; refresh via HttpOnly cookie.
Households: create households and list memberships.
Household-scoped resources under /api/v1/households/{householdSlug}:
- Recipes: list/get/create/delete (soft-hide); list supports q, cursor, limit.
- Meals: upcoming/get/create/update/delete; mark consumed.
- Shopping: current aggregate; list-by-id; purchase; request/unrequest meal.
RFC7807 Problem Details standardized for errors.
OpenAPI includes bearerAuth and 403 for protected household routes.

Meals v2 participants (chefs, cleanup, consumers) now use MemberRef:
- { id: number, displayName: string }
- Returned in MealOut; sent in MealIn. No legacy Person in outward schema.
Recipes v2 outward DTO currently omits createdBy in v2 list/create responses; if exposed later, it will use a user/member shape (no Person).

Person removed from meals outward schema; use MemberRef.displayName instead of name.
Household slug is required in all v2 data routes.

Replace any usage of Person in meals UI/state with MemberRef { id, displayName }.
Verify create/update meal payloads send participants in the new format (displayName).
Ensure auth flow relies on JWT bearer and refresh cookie; remove legacy cookie logic if still present.
Align OpenAPI client generation with the updated schema (regenerate clients).