# 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.

## DTO alignment

- 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).

## Breaking changes to watch for

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

## Prioritized Actions (Frontend)

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

## Upcoming backend cleanups (FYI)

- Remove v1 routers; rename `*_v2.py` to canonical; drop `persons/` package.
- Expose user/member DTO for recipe authorship if needed.
- Add invitation email delivery.
- DB indices/FKs polish.