Recipe app · Spring Boot 4 · PostgreSQL · Self-hosted · Single machine
+
+
+ v1.3
+ Style: REST + JSON
+ Framework: Spring Boot 4.0
+ Auth: Spring Security 7 (session)
+ Endpoints: 33
+ Designed by: Nexus
+
+
+
+
+
v1.3 changes from v1.2
+
+
Ingredient category is now a reference table.ingredient.category varchar(30) replaced by ingredient.category_id FK → ingredient_category. New ingredient_category table (id, household_id, name). API responses now return "category": { "id": "...", "name": "meat" } instead of "category": "meat". Two new endpoints: GET /v1/ingredient-categories and POST /v1/ingredient-categories.
Everything runs on one machine. No managed services, no per-request pricing, no vendor lock-in. A single JAR, a single database, a single deployment target.
+
+
+
+
API framework
+
Spring Boot 4.0
+
Spring Framework 7 underneath. Modular starters (smaller JARs). JSpecify null-safety. Built-in API versioning. Java 17+ baseline, first-class Java 25 support. Embedded Tomcat — one executable JAR.
+
+
+
Database
+
PostgreSQL 16
+
Same machine. 1:1 mapping to JPA entities. Flyway for migrations (Atlas's SQL directly). HikariCP connection pool built in.
+
+
+
Auth
+
Spring Security 7 (sessions)
+
Default session-based auth. HttpOnly + Secure + SameSite=Lax cookie. No tokens, no refresh flow, no extra libraries. bcrypt password hashing built in.
Click any endpoint row to expand request/response bodies
+
Every endpoint below has a collapsible detail panel showing the exact JSON shapes. Fields marked required are validated with Bean Validation annotations. Fields marked optional can be omitted. All responses are wrapped in the standard envelope above — the examples below show the data payload only.
// code is in the URL path
+// no request body needed
+
Response · 200 OK
{
+ "householdId": "7c9e6679-...",
+ "householdName": "Smith family",
+ "role": "member"
+}
+// 409 if code already used
+// 422 if code expired
+// 409 if user already in a household
// full RecipeDetail (same shape as GET /recipes/{id})
+{
+ "id": "a1b2c3d4-...",
+ "name": "Spaghetti Bolognese",
+ ...
+}
++ Location: /v1/recipes/a1b2c3d4-...
+
Ingredients can reference an existing ingredientId or create a new ingredient inline via newIngredientName. Tags must include at least the effort level tag plus one category tag.
+
+
+
+
+ PUT
+
/v1/recipes/{id}
Full replace. Same shape as POST body. Replaces all children.
+ planner
+ J1
+
+
+
Request body
// identical shape to POST /v1/recipes
+// sends the complete new state
+// server deletes old children, inserts new
+{
+ "name": "Spaghetti Bolognese (updated)",
+ "serves": 4,
+ "cookTimeMin": 40,
+ "effort": "medium",
+ "ingredients": [ ... ],
+ "steps": [ ... ],
+ "tagIds": [ ... ]
+}
+
Response · 200 OK
// full RecipeDetail with updated data
+{
+ "id": "a1b2c3d4-...",
+ "name": "Spaghetti Bolognese (updated)",
+ ...
+}
Full list with items. Both roles. Pull-to-refresh target.
+ auth
+ J5
+
+
+
Request
// no body — GET
+// this is the refresh action:
+// pull-to-refresh calls this endpoint
+
Response · 200 OK
// same shape as POST response above
+{
+ "id": "shl-01-...",
+ "status": "published",
+ "items": [ ... ]
+}
+
+
+
+
+
+ POST
+
/v1/shopping-lists/{id}/publish
Publish (draft → published). Live for members.
+ planner
+ J5
+
+
+
Request body
// empty — action endpoint
+
Response · 200 OK
{
+ "id": "shl-01-...",
+ "status": "published",
+ "publishedAt": "2026-04-06T09:00:00Z"
+}
+// 422 if already published
+
+
+
+
+
+ PATCH
+
/v1/shopping-lists/{listId}/items/{itemId}
Check/uncheck item. Both roles.
+ auth
+ J5
+
+
+
Request body
{
+ "isChecked": true
+}
+
Response · 200 OK
{
+ "id": "si-01-...",
+ "name": "spaghetti",
+ "isChecked": true,
+ "checkedBy": "661f-..." // who checked it
+}
+// other members see this on next refresh
+
+
+
+
+
+ POST
+
/v1/shopping-lists/{id}/items
Add custom item. Both roles.
+ auth
+ J5
+
+
+
Request body
{
+ "ingredientId": null, // or existing id
+ "customName": "Paper towels", // if no ingredientId
+ "quantity": 1,
+ "unit": "" // blank for countable
+}
1. Authentication: Spring Security 7 session. HttpOnly + Secure + SameSite=Lax cookie. 24h expiry.
+ 2. Role authorization: @PreAuthorize on systemRole (admin) and householdRole (planner vs member). 403 on mismatch.
+ 3. Household isolation: HouseholdContext resolves householdId from session. Every query includes AND household_id = ?. Wrong household → 404.
Tag model fixed → proper M:N. Added tag reference table. recipe_tag is now a pure junction table with recipe_id FK + tag_id FK. Tags are reusable, renameable, and queryable from both directions.
+
Ingredient category normalized → 1:N. Added ingredient_category reference table. The category string on ingredient is replaced with category_id FK. Rename once, applies to all ingredients. Canonical list of aisle categories for shopping grouping.
+
Admin user management added. New system_role column on user_account (admin vs user). New admin_audit_log table tracks admin actions: account creation, updates, password resets.
This schema covers all six user journeys (J1–J6), the suggestion/variety engine, the lightweight pantry tracker, recipe hero images, and platform-level admin user management. It is normalized by default, with computed fields (variety score) calculated at query time rather than stored. Every mutable table carries audit timestamps. Tags use a proper M:N relationship via a reference table + junction table.
+
+
+
4
Auth & household
+
7
Recipe domain
+
3
Planning domain
+
2
Shopping domain
+
1
Pantry domain
+
1
Admin domain
+
+
+
+
Design decisions
+
Variety score is computed, not stored — it's derived from cooking_log + recipe_ingredient + week_plan_slot.
+ Ingredients are a normalized reference table — enables merging, repetition tracking, and staple filtering.
+ Tags are a proper M:N: a tag reference table + recipe_tag junction. One recipe → many tags, one tag → many recipes. Rename once, applies everywhere.
+ Ingredient categories are a normalized 1:N reference table — one ingredient belongs to one category (e.g. "Produce", "Fish & Meat"). Rename a category once, applies to all ingredients. Powers the aisle-grouped shopping list (J5 variant V2).
+ Hero images store a URL/path reference to object storage (S3/R2).
+ Admin uses a system_role on user_account (not the household role). Admin actions are audit-logged in a dedicated table.
+ Pantry items link to the shared ingredient reference with best-before dates.
+
+
+
+
+
+
+
Entity-relationship diagram
+
Entities grouped by domain. Purple = auth, green = recipe, yellow = planning, blue = shopping, orange = pantry, red = admin. NEW marks v1.1 additions/changes.
+
+
+
+
+
+
+
+
user_account CHANGED
+
+
PK iduuid
+
emailcitext UNIQUE
+
display_namevarchar(100)
+
password_hashvarchar(255)
+
system_roleenum(admin,user) NEW
+
is_activeboolean NEW
+
created_attimestamptz
+
updated_attimestamptz
+
+
+
+
household
+
+
PK iduuid
+
namevarchar(100)
+
FK created_by→ user_account
+
created_attimestamptz
+
+
+
+
household_member
+
+
PK iduuid
+
FK household_id→ household
+
FK user_id→ user_account UNIQUE
+
roleenum(planner,member)
+
joined_attimestamptz
+
+
+
+
household_invite
+
+
PK iduuid
+
FK household_id→ household
+
invite_codevarchar(20) UNIQUE
+
statusenum(pending,used,expired)
+
expires_attimestamptz
+
+
+
+
+
+
+
+
recipe
+
+
PK iduuid
+
FK household_id→ household
+
namevarchar(200)
+
servessmallint
+
cook_time_minsmallint
+
effortenum(easy,medium,hard)
+
is_child_friendlyboolean
+
hero_image_urlvarchar(500) NULL
+
deleted_attimestamptz NULL
+
+
+
+
ingredient CHANGED
+
+
PK iduuid
+
FK household_id→ household
+
namecitext
+
is_stapleboolean
+
FK category_id→ ingredient_category NULL NEW
+
+
+
+
ingredient_category NEW
+
+
PK iduuid
+
FK household_id→ household
+
namecitext
+
sort_ordersmallint
+
+
+
+
recipe_ingredient
+
+
PK iduuid
+
FK recipe_id→ recipe
+
FK ingredient_id→ ingredient
+
quantitynumeric(8,2)
+
unitvarchar(20)
+
sort_ordersmallint
+
+
+
+
recipe_step
+
+
PK iduuid
+
FK recipe_id→ recipe
+
step_numbersmallint
+
instructiontext
+
+
+
+
+
+
+
+
tag NEW
+
+
PK iduuid
+
FK household_id→ household
+
namecitext
+
tag_typevarchar(20)
+
+
+
+
recipe_tag CHANGED
+
+
FK recipe_id→ recipe
+
FK tag_id→ tag NEW
+
PK (recipe_id, tag_id)composite
+
+
+
+
week_plan
+
+
PK iduuid
+
FK household_id→ household
+
week_startdate (Monday)
+
statusenum(draft,confirmed)
+
confirmed_attimestamptz NULL
+
+
+
+
week_plan_slot
+
+
PK iduuid
+
FK week_plan_id→ week_plan
+
FK recipe_id→ recipe
+
slot_datedate
+
+
+
+
cooking_log
+
+
PK iduuid
+
FK recipe_id→ recipe
+
FK household_id→ household
+
cooked_ondate
+
FK cooked_by→ user_account
+
+
+
+
+
+
+
+
shopping_list
+
+
PK iduuid
+
FK household_id→ household
+
FK week_plan_id→ week_plan
+
statusenum(draft,published,done)
+
published_attimestamptz NULL
+
+
+
+
shopping_list_item
+
+
PK iduuid
+
FK shopping_list_id→ shopping_list
+
FK ingredient_id→ ingredient NULL
+
custom_namevarchar(200) NULL
+
quantity / unitnumeric / varchar
+
is_checkedboolean
+
source_recipesuuid[]
+
+
+
+
pantry_item
+
+
PK iduuid
+
FK household_id→ household
+
FK ingredient_id→ ingredient NULL
+
custom_namevarchar(200) NULL
+
quantity / unitnumeric / varchar
+
best_beforedate NULL
+
opened_ondate NULL
+
+
+
+
admin_audit_log NEW
+
+
PK iduuid
+
FK admin_id→ user_account
+
FK target_user_id→ user_account
+
actionvarchar(30)
+
detailjsonb NULL
+
performed_attimestamptz
+
+
+
+
+
+
+
+
+
+
+
+
Tag model — M:N via reference table
+
v1.0 stored tags as raw strings in recipe_tag. v1.1 fixes this to a proper many-to-many relationship. One recipe can have many tags. One tag can appear on many recipes. Tags are owned by a household and typed (protein, dietary, cuisine) to enable structured filtering.
+
+
+
What changed and why
+
Before (v1.0):recipe_tag(recipe_id, tag varchar(50)) — tag name stored as raw string per row. 30 recipes tagged "chicken" = 30 copies of the string "chicken". Renaming requires updating every row. No canonical list of available tags. No typed categorization.
+ After (v1.1):tag(id, household_id, name, tag_type) + recipe_tag(recipe_id, tag_id) — pure M:N junction. Rename a tag in one UPDATE. List available tags with a simple SELECT. Filter by tag_type (protein, dietary, cuisine) for the J2 suggestion engine. The junction PK is composite (recipe_id, tag_id) — no surrogate key needed.
+
+
+
+
+
+
tag NEW in v1.1
+ Recipe
+
+
Reference table for category tags. Scoped per household — each household can have its own tag vocabulary. tag_type classifies tags for the suggestion engine: "protein" tags trigger consecutive-day avoidance, "dietary" tags are informational.
+
+
Column
Type
Constraints
Purpose
+
+
id
uuid
PK, gen_random_uuid()
Surrogate PK
+
household_id
uuid
NOT NULL, FK → household ON DELETE CASCADE
Tags belong to a household
+
name
citext
NOT NULL
"Chicken", "Fish", "Vegetarian", "Pasta"
+
tag_type
varchar(20)
NOT NULL, CHECK(tag_type IN ('protein','dietary','cuisine','other'))
Pure M:N junction table. No surrogate key — the composite PK (recipe_id, tag_id) is the natural key. A recipe can have many tags; a tag can appear on many recipes. Both directions are indexed.
+
+
Column
Type
Constraints
Purpose
+
+
recipe_id
uuid
NOT NULL, FK → recipe ON DELETE CASCADE, part of composite PK
Which recipe
+
tag_id
uuid
NOT NULL, FK → tag ON DELETE CASCADE, part of composite PK
Which tag
+
+
+
+
+
+
+
+
+
J2 — Same-protein consecutive day check (updated for M:N)
+
Uses tag.tag_type = 'protein' to filter only protein tags from the M:N join
+
-- What protein tags are on adjacent planned days?
+SELECT wps.slot_date, t.name AS protein
+FROM week_plan_slot wps
+JOIN recipe_tag rt ON rt.recipe_id = wps.recipe_id
+JOIN tag t ON t.id = rt.tag_id
+WHERE wps.week_plan_id = $1
+ AND t.tag_type = 'protein'
+ORDER BY wps.slot_date;
+
+
+
+
+
+
+
Ingredient category — 1:N reference table
+
v1.0 stored category as a raw string on ingredient. v1.1 normalizes this to a proper 1:N relationship. One ingredient belongs to one category. One category contains many ingredients. Categories are owned per household and ordered for shopping list grouping.
+
+
+
What changed and why
+
Before:ingredient.category varchar(30) — raw string. 15 ingredients labelled "Produce" = 15 copies. Rename requires updating every row. No canonical list. No display ordering for the aisle-grouped shopping list.
+ After:ingredient_category(id, household_id, name, sort_order) + ingredient.category_id FK. Rename once, applies everywhere. sort_order controls the display order on the aisle-grouped shopping list (J5 V2). Category is nullable on ingredient — uncategorized ingredients fall into an "Other" group in the UI.
+
+
+
+
+
ingredient_category NEW in v1.1
+ Recipe
+
+
Reference table for ingredient aisle categories. Scoped per household — each household can customize their store layout. sort_order controls the display sequence in the aisle-grouped shopping list view (J5 screen D1 variant V2).
The system needs a platform-level admin who can create user accounts, update them, and reset passwords. This is separate from the household "planner" role — a planner manages meal plans, an admin manages the platform. The two role systems are orthogonal: system_role (admin vs user) lives on user_account; household_role (planner vs member) lives on household_member.
+
+
+
Two role systems — don't confuse them
+
system_role on user_account: platform-level. "admin" can manage all user accounts. "user" is a normal user. This is about platform administration.
+ household role on household_member: app-level. "planner" has full access to 18 screens. "member" sees C1 read-only + D1 collaborative. This is about what you can do within a household.
+ An admin can also be a planner in their own household. The roles are independent.
+
+
+
+
+
+
user_account CHANGED in v1.1
+ Auth
+
+
User identity for both app users and platform admins. system_role determines platform-level access. is_active allows admins to deactivate accounts without deleting them. Authentication handled here; household authorization in household_member.
+
+
Column
Type
Constraints
Purpose
+
+
id
uuid
PK, gen_random_uuid()
Surrogate PK
+
email
citext
NOT NULL, UNIQUE
Login identifier, case-insensitive
+
display_name
varchar(100)
NOT NULL
Shown in UI (sidebar avatar initials)
+
password_hash
varchar(255)
NOT NULL
bcrypt/argon2 hash — never exposed via API
+
system_role
varchar(10)
NOT NULL, DEFAULT 'user', CHECK(system_role IN ('admin','user'))
NEW — platform role. Admin can manage all accounts.
+
is_active
boolean
NOT NULL, DEFAULT true
NEW — admin can deactivate accounts. Inactive users cannot log in.
+
created_at
timestamptz
NOT NULL, DEFAULT now()
Account creation time
+
updated_at
timestamptz
NOT NULL, DEFAULT now()
Last profile edit
+
+
+
+
+
+
+
+
+
+
admin_audit_log NEW in v1.1
+ Admin
+
+
Immutable audit trail for all admin actions on user accounts. Every account creation, update, or password reset by an admin is logged here. Never updated or deleted. Used for compliance, debugging, and accountability.
+
+
Column
Type
Constraints
Purpose
+
+
id
uuid
PK, gen_random_uuid()
Surrogate PK
+
admin_id
uuid
NOT NULL, FK → user_account ON DELETE RESTRICT
Which admin performed the action
+
target_user_id
uuid
NOT NULL, FK → user_account ON DELETE RESTRICT
Which user was affected
+
action
varchar(30)
NOT NULL, CHECK(action IN ('create_account','update_account','reset_password','deactivate_account','reactivate_account','change_system_role'))
WITH recent_meals AS (
+ SELECT recipe_id, cooked_on
+ FROM cooking_log
+ WHERE household_id = $1
+ AND cooked_on >= CURRENT_DATE - INTERVAL '3 days'
+)
+SELECT DISTINCT i.id, i.name
+FROM recent_meals rm
+JOIN recipe_ingredient ri ON ri.recipe_id = rm.recipe_id
+JOIN ingredient i ON i.id = ri.ingredient_id;
+
+
+
+
J2 — Protein tags on adjacent days (M:N join)
+
Frequency: ~10×/week · Target: <30ms
+
SELECT wps.slot_date, t.name AS protein
+FROM week_plan_slot wps
+JOIN recipe_tag rt ON rt.recipe_id = wps.recipe_id
+JOIN tag t ON t.id = rt.tag_id
+WHERE wps.week_plan_id = $1
+ AND t.tag_type = 'protein'
+ORDER BY wps.slot_date;
+
+
+
+
J5 — Shopping list generation (merged + staples filtered)
+
Frequency: 1×/week · Target: <200ms
+
SELECT i.id, i.name,
+ SUM(ri.quantity) AS total_qty, ri.unit,
+ ARRAY_AGG(DISTINCT r.id) AS source_recipe_ids
+FROM week_plan_slot wps
+JOIN recipe r ON r.id = wps.recipe_id
+JOIN recipe_ingredient ri ON ri.recipe_id = r.id
+JOIN ingredient i ON i.id = ri.ingredient_id
+WHERE wps.week_plan_id = $1
+ AND i.is_staple = false
+GROUP BY i.id, i.name, ri.unit
+ORDER BY i.name;
+
+
+
+
Pantry — Items expiring within 3 days
+
Frequency: daily · Target: <20ms
+
SELECT pi.id, COALESCE(i.name, pi.custom_name) AS name,
+ pi.best_before, pi.quantity, pi.unit
+FROM pantry_item pi
+LEFT JOIN ingredient i ON i.id = pi.ingredient_id
+WHERE pi.household_id = $1
+ AND pi.best_before IS NOT NULL
+ AND pi.best_before <= CURRENT_DATE + INTERVAL '3 days'
+ORDER BY pi.best_before;
+
+
+
+
Admin — All actions on a user (audit trail)
+
Frequency: on-demand · Target: <50ms
+
SELECT aal.action, aal.detail, aal.performed_at,
+ admin.display_name AS admin_name, admin.email AS admin_email
+FROM admin_audit_log aal
+JOIN user_account admin ON admin.id = aal.admin_id
+WHERE aal.target_user_id = $1
+ORDER BY aal.performed_at DESC;
+
+
+
+
All tags for a recipe (M:N forward lookup)
+
Frequency: every recipe detail load · Target: <10ms
+
SELECT t.id, t.name, t.tag_type
+FROM recipe_tag rt
+JOIN tag t ON t.id = rt.tag_id
+WHERE rt.recipe_id = $1
+ORDER BY t.tag_type, t.name;
+
+
+
+
All recipes with a specific tag (M:N reverse lookup)
SELECT r.id, r.name, r.effort, r.cook_time_min
+FROM recipe_tag rt
+JOIN recipe r ON r.id = rt.recipe_id
+WHERE rt.tag_id = $1
+ AND r.deleted_at IS NULL
+ORDER BY r.name;
+
+
+
+
+
+
+
Migration order (v1.1)
+
+
Migration 001 — Extensions & triggers
+
Run once before any table creation
+
CREATE EXTENSION IF NOT EXISTS "pgcrypto"; -- gen_random_uuid()
+CREATE EXTENSION IF NOT EXISTS "citext"; -- case-insensitive text
+
+CREATE OR REPLACE FUNCTION trigger_set_updated_at()
+RETURNS TRIGGER AS $$
+BEGIN
+ NEW.updated_at = NOW();
+ RETURN NEW;
+END;
+$$ LANGUAGE plpgsql;
-- Prevent accidental updates/deletes on audit log
+CREATE RULE no_update_audit AS ON UPDATE TO admin_audit_log
+ DO INSTEAD NOTHING;
+CREATE RULE no_delete_audit AS ON DELETE TO admin_audit_log
+ DO INSTEAD NOTHING;
+
+
+
+
+
+
+
Journey → table coverage matrix (v1.1)
+
+
+
Journey
Reads
Writes
Critical path
+
+
J1 · Add recipe
ingredient, tag (autocomplete)
recipe, recipe_ingredient, recipe_step, recipe_tag, ingredient, tag
Recipe INSERT + child rows + tag associations in one transaction
Every admin action → audit log INSERT in same transaction
+
+
+
+
+
+
+
+
+
Pushback & trade-off log
+
+
+
v1.0 bug: recipe_tag was 1:N, not M:N
+
Fixed in v1.1. v1.0 stored tags as raw strings, making recipe_tag structurally a 1:N (one recipe → many string rows) rather than a true M:N. The tag string had no identity — "chicken" on recipe A and "chicken" on recipe B were unrelated rows. This prevented tag renaming, tag listing, and structured filtering. v1.1 adds a tag reference table, making recipe_tag a proper M:N junction with FK integrity in both directions.
+
+
+
+
v1.0 bug: ingredient.category was a raw string, not a FK
+
Fixed in v1.1. Same anti-pattern as the tag issue. 15 ingredients all storing the string "Produce" independently — no shared identity, no rename capability, no canonical list, no sort order. v1.1 extracts this to ingredient_category as a reference table with a 1:N FK from ingredient. The sort_order column enables the aisle-grouped shopping list (J5 D1 V2) to match supermarket layout. Category is nullable — uncategorized ingredients group into "Other."
+
+
+
+
source_recipes as uuid[] — trade-off accepted
+
Violates 1NF. But it's write-once display metadata, never joined against. A junction table would add ~60 rows/week for zero query benefit. Sunset plan: migrate to junction table if future requirements need "which list items came from recipe X?"
+
+
+
+
Variety score is computed, not materialized
+
At ~50 recipes × 7 slots, the CTE runs in <100ms. Materialized view adds staleness risk. At 100× scale, we add materialized view with refresh-on-mutation triggers.
+
+
+
+
admin_audit_log.detail uses JSONB — justified
+
This is the right use case for schemaless data. Each action type has a different shape (password reset has a "reason", email change has "old"+"new", creation has full profile). The data is write-once, append-only, and queried for display only. Normalizing it into typed columns would require a different schema per action type for no benefit.
+
+
+
+
Rejected: separate admin_user table
+
Having a separate table for admins would split identity across two tables. Login would need to check both. An admin who is also a household planner would need two accounts. Instead, system_role on user_account keeps one identity per person. The role check is a single column read.
Two pages, one journey. E1 is the settings hub at /settings — currently a placeholder. D3 is the StaplesManager component at /household/staples, rendered with context="settings". The component uses StapleChip — ingredient pills in flex-wrap grids per category, not a checklist. Five variations explore how the hub and staples editing relate: from navigating to a sub-page, to showing staples inline on the settings page itself. The recommended variation for v1 is V3 (Accordion) — one page, no navigation, staples always one tap away.
+
+
Five design variations
+
+
+
+
+
+
V1
+
+
Verknüpfte Abschnitte
+
Settings als Hub-Seite mit klickbaren Abschnitt-Zeilen. Jeder Bereich (Profil, Vorräte, Haushalt) ist eine Zeile mit Titel, Beschreibung, Stat und Pfeil. Tippen navigiert zur jeweiligen Unterseite. Klassisches iOS-Settings-Muster.
+ Pasta
+ Reis
+ Couscous
+ Linsen
+ Kichererbsen
+
+
+
+
+
+
+
+
+
+
+
Design-Entscheidungen
+
+
Vorräte-Zeile hat einen grünen linken Rand (border-left: 3px solid --green-dark) — signalisiert "primäre Aktion" ohne ihn visuell zu überfrachten.
+
Die aktive Zutat-Zahl ("14") wird als Display-Schrift-Zahl dargestellt — schafft eine Verbindung zum Wert-Versprechen der App (Varietät-Scores sind ebenfalls Zahlen).
+
D3 Unterseite im settings-Kontext: kein Onboarding-Sidebar, kein "Weiter"-Button — nur die Kategorie-Chip-Liste. "← Einstellungen" Breadcrumb für die Rücknavigation.
+
StapleChip: Ausgewählt = --green-dark Hintergrund + weißer Text. Nicht ausgewählt = transparenter Hintergrund + --color-border Rahmen + --color-text-muted Text. Kein separater Speicher-Button — Auto-Save auf Toggle.
+
+
+
+
+
+
+
+
+
V2
+
+
Einstellungs-Kacheln
+
Jeder Einstellungsbereich als Kachel mit Titel, Beschreibung, Schlüsselstatistik und direktem Aktions-Button. Die Vorräte-Kachel zeigt "14 von 32 aktiv" und einen "Bearbeiten"-Button der direkt in den D3-Kontext führt.
+ Gute Übersicht auf großen Bildschirmen
+
+
+
+
+
+
Desktop · 1200px
+
+
+
+
+
+
Einstellungen
+
+
+
+
+
Vorräte
+
14
von 32 aktiv
+
+
Zutaten, die immer im Haushalt vorhanden sind. Sie werden beim Generieren der Einkaufsliste automatisch herausgefiltert.
+
+
+
+
+
+
Haushalt
+
3
Mitglieder
+
+
Familie Raddatz. Haushaltsname und Mitgliederverwaltung.
+
+
+
+
+
Profil
+
Marcel Raddatz marcel@email.com
+
+
+
+
+
+
+
+
+
+
Mobile · 390px
+
+
+
+
Einstellungen
+
+
+
Vorräte
14
von 32
+
Immer vorhandene Zutaten, automatisch aus Einkaufslisten gefiltert.
+
+
+
+
Haushalt
3 Mitglieder
+
Familie Raddatz
+
+
+
+
Profil
+
Marcel Raddatz · marcel@email.com
+
+
+
+
+
+
+
+
+
+
+
+
Design-Entscheidungen
+
+
Kacheln mit Display-Schrift-Zahlen (14, 3) als Schlüsselmetriken — konsistentes Designmuster mit der Varietätspunktzahl im Planer.
+
Der "Vorräte bearbeiten"-Button auf der Kachel führt direkt zur D3-Unterseite. Keine Zwischennavigation.
+
Nachteil gegenüber V3: erfordert einen Navigationswechsel für die häufigste Aufgabe (Vorräte bearbeiten). V3 macht das inline möglich.
+
+
+
+
+
+
+
+
+
V3
+
+
Akkordeon mit inline Vorräten
+
Die Settings-Seite zeigt alle Bereiche als aufklappbare Abschnitte. Der Vorräte-Bereich ist beim Öffnen der Seite standardmäßig aufgeklappt und zeigt direkt die StapleChip-Kategorien. Kein Seitenwechsel nötig.
+ Empfohlen · v1
+
+
+
+
+
+
Desktop · 1200px — Vorräte aufgeklappt (Standard)
+
+
+
+
+
+
Einstellungen
+
+
+
+
+
+
Tippe eine Zutat an um sie als Vorrat zu markieren oder zu entfernen. Änderungen werden sofort gespeichert.
Vorräte-Abschnitt ist beim Öffnen der Seite standardmäßig aufgeklappt (per URL-Hash oder initial state) — der häufigste Grund für diesen Seitenaufruf ist das Bearbeiten von Vorräten.
+
Kein Seitenwechsel zu /household/staples nötig — die StaplesManager-Komponente rendert direkt im Akkordeon-Bereich. Routing-Vorteil: die /settings URL bleibt beim Bearbeiten erhalten.
+
Akkordeon-Trigger zeigt den aktuellen Wert im eingeklappten Zustand (z. B. "14 aktiv", "Marcel Raddatz") — der Nutzer kann den Status scannen ohne aufzuklappen.
+
Auf Mobile perfekt: kein separater "Zurück"-Button nötig. Ein langer Scroll kann mit einem "Nach oben"-Link oder sticky Akkordeon-Headern optimiert werden.
+
Implementierungshinweis: Der aufgeklappte Bereich enthält direkt die StaplesManager-Komponente (<StaplesManager categories={data.categories} context="settings" />). Keine Seiten-Navigation erforderlich.
+
+
+
+
+
+
+
+
+
V4
+
+
Einstellungs-Sub-Navigation
+
Auf Desktop: eine zweite Navigationsleiste links neben dem Inhalt (Profil · Vorräte · Haushalt). Der Vorräte-Abschnitt ist der Standard-Inhalt. Auf Mobile: flache Liste als Einstieg, dann Drill-down.
Dreifache Navigationsstruktur auf Desktop (App-Sidebar → Settings-Sub-Nav → Inhalt) ist für 3 Einstellungsbereiche Overkill. Skaliert erst ab 6+ Bereichen.
+
Vorrat als Default-Selektion in der Sub-Nav sinnvoll — direktester Einstieg für J8. Verhindert eine "leere Hub"-Seite.
+
Mobile-Drill-down: Sub-Nav-Liste → Unterseite. Entspricht dem Standard-Mobile-Pattern (z. B. iOS Systemeinstellungen). Klare Navigation, aber erfordert eine Zurück-Navigation.
+
Nicht empfohlen für v1: zu viel Struktur für zu wenig Inhalt. V3 (Akkordeon) ist einfacher und erreicht dasselbe Ergebnis ohne Sub-Navigation.
+
+
+
+
+
+
+
+
+
V5
+
+
Schnellzugriff-Dashboard
+
Settings als kleines Dashboard: Haushalt-Zusammenfassung oben (Name + Mitgliederzahl), darunter ein prominenter "Vorräte bearbeiten" Einstieg mit aktuellem Zählstand und zuletzt bearbeiteten Chips als Vorschau. Alles auf einer Seite — kein Drill-down.
+ Informationsdicht · klarer Schwerpunkt
+
+
+
+
+
+
Desktop · 1200px
+
+
+
+
+
+
+
+
+
MR
+
Marcel Raddatz
marcel@email.com · Planner
+
+
+
+
+
+
+
+
+
Vorräte
+
14
+
von 32 aktiv
+
+
Immer vorhandene Zutaten werden automatisch aus Einkaufslisten gefiltert.
+
+
+ Karotten
+ Pasta
+ Zwiebeln
+ Reis
+ +10 weitere
+
+
+
+
+
+
Haushalt
+
3
+
Mitglieder · Familie Raddatz
+
+
+
+
+
+
+
+
+
+
+
Mobile · 390px
+
+
+
+
+
+
MR
+
Marcel Raddatz
Planner · Familie Raddatz
+
+
+
+
+
Vorräte
14
von 32
+
+ Karotten
+ Pasta
+ Zwiebeln
+ +11
+
+
+
+
+
+
Haushalt
Familie Raddatz · 3 Mitglieder
+
+
+
+
+
+
+
+
+
+
+
+
Design-Entscheidungen
+
+
Chip-Vorschau auf der Hub-Seite (4 aktive Vorräte + "+10 weitere") gibt dem Nutzer sofort Kontext über den aktuellen Zustand — kein Klick nötig um zu verstehen, was konfiguriert ist.
+
Profil-Leiste oben als Identitätsanker: Name, E-Mail, Rolle. Schafft eine klare "Wer bin ich in diesem Haushalt"-Aussage ohne eigene Profil-Seite besuchen zu müssen.
+
2:1 Grid-Layout auf Desktop betont Vorräte als primäre Einstellung — genau das richtige Gewicht für J8.
+
Nachteil: Der "Alle Vorräte bearbeiten"-Button navigiert trotzdem zur D3-Unterseite (oder öffnet ein Modal). Keine wirklich inline-Bearbeitung wie bei V3. Funktioniert aber gut als Schnellzugriff-Übersicht.
Authoritative implementation reference for /settings and /household/staples?ctx=settings. Use before building either page.
+
+
/* E1 Settings + D3 Staples — implementation rules
+ * 1. Recommended variation: V3 (Accordion). Vorräte section is open by default. No navigation to sub-page required.
+ * 2. D3 = A3: StaplesManager is the same component. context="settings" removes the onboarding sidebar and "Weiter" button.
+ * 3. StapleChip renders as a pill button, NOT a checkbox. Selected = --green-dark bg + white text. Unselected = transparent bg + --color-border border + --color-text-muted text.
+ * 4. Auto-save on toggle. No explicit save button. The component already implements debounced PATCH to /household/staples.
+ * 5. Category label: font-size 10px · font-weight 500 · letter-spacing 0.08em · text-transform uppercase · color --color-text-muted.
+ * 6. Staple count display ("14 von 32 aktiv"): derive from categories prop — count isStaple=true vs total ingredients.
+ * 7. Sidebar active item: "Einstellungen" (not "Vorräte" — there is no separate Vorräte sidebar item). Active style: --green-tint bg + --green-dark text.
+ * 8. Mobile bottom nav active tab: "Einstellungen". Same for both /settings and /household/staples routes.
+ * 9. Accordion trigger shows current stat in collapsed state: "14 aktiv" for Vorräte. Stat updates reactively as user toggles chips.
+ * 10. Changes to staples (J8) do NOT retroactively update an already-generated shopping list. If the current list should reflect changes, the planner must regenerate it via J5. Consider a note in the UI: "Gilt ab der nächsten Einkaufsliste."
+ * 11. Profile section: show name + email. Edit action navigates to /profile or opens an inline form. Not in scope for J8 — implement minimally.
+ */
The members page is a rarely-visited, high-trust page. The planner opens it when the household changes — a new partner joins, a family member needs access removed. The household is typically 2–4 people. Five variations explore the range from a simple list to a panel-based layout. The recommended variation for v1 is V1 (Roster list) — fewest moving parts, matches the access frequency, household size, and task urgency.
+
+
Five design variations
+
+
+
+
+
+
V1
+
+
Roster-Liste
+
Lineares Listenformat. Alle Mitglieder als Zeilen mit Avatar, Name, Rolle und Beitrittsdatum. Ausstehende Einladungen darunter. Minimale kognitive Last für eine seltene Aufgabe.
+ Empfohlen · v1
+
+
+
+
+
+
+
Desktop · 1200px
+
+
+
+
+
+
+
+
+
+
Mitglieder
+ 3
+
+
+
+
+
+
+
MR
+
+
Marcel Raddatz
+
Beigetreten 14. Januar 2026
+
+ Planner
+
⋯
+
+
+
SR
+
+
Sarah Raddatz
+
Beigetreten 15. Januar 2026
+
+ Mitglied
+
⋯
+
+
+
TM
+
+
Tom Meier
+
Beigetreten 3. März 2026
+
+ Mitglied
+
⋯
+
+
+
+
Ausstehende Einladungen · 1
+
+
inv_x8K2j
+
Läuft ab in 2 Tagen
+
+
+
+
+
+
+
+
+
+
+
Mobile · 390px
+
+
+
+
+
Mitglieder
+
+
+
+
+
MR
+
Marcel Raddatz
Planner · Seit 14.1.26
+
⋯
+
+
+
SR
+
Sarah Raddatz
Mitglied · Seit 15.1.26
+
⋯
+
+
+
TM
+
Tom Meier
Mitglied · Seit 3.3.26
+
⋯
+
+
Einladungen · 1
+
+
inv_x8K2j2 Tage
+
+
+
+
+
+
+
+
+
+
+
+
+
Design-Entscheidungen
+
+
Planner-Avatar in Grün (--green-tint), Mitglieder-Avatar in Blau (--blue-tint) — Rollenfarben konsistent mit den Rollenbadges in der Spec.
+
Kebab-Menü (⋯) öffnet ein Kontextmenü mit "Zugang entziehen". Destructive action erfordert Bestätigung mit Mitgliedsnamen.
+
Ausstehende Einladungen haben einen gelben Ablauf-Badge wenn ≤ 3 Tage verbleiben, grau wenn mehr Zeit bleibt.
+
Auf Mobile: "Einladen"-Button als Kompakt-CTA im Seitenkopf (kein großes Hero-Element) — die Seite ist keine Onboarding-Seite, sondern eine Management-Seite.
+
+
+
+
+
+
+
+
+
V2
+
+
Kachelraster
+
Jedes Mitglied als eigenständige Kachel mit großem Avatar-Kreis, Name, Rolle und Datum. Eine "+" Kachel mit gestricheltem Rand fungiert als Invite-CTA. Visuelle, scannable Übersicht.
+ Geeignet ab 4+ Mitgliedern
+
+
+
+
+
+
Desktop · 1200px
+
+
+
+
+
+
Mitglieder
+
+
+
+
MR
+
Marcel Raddatz
14. Jan 2026
+ Planner
+
+
+
SR
+
Sarah Raddatz
15. Jan 2026
+ Mitglied
+
+
+
TM
+
Tom Meier
3. Mär 2026
+ Mitglied
+
+
+
+
+
+
Einladen
+
+
+
+
+
+
+
+
+
Mobile · 390px
+
+
+
+
Mitglieder
+
+
+
MR
+
Marcel R.
+ Planner
+
+
+
SR
+
Sarah R.
+ Mitglied
+
+
+
TM
+
Tom M.
+ Mitglied
+
+
+
+
+
Einladen
+
+
+
+
+
+
+
+
+
+
+
Design-Entscheidungen
+
+
Kachelgröße funktioniert nur bis ca. 6 Mitgliedern — ab 7+ muss auf Liste zurückgefallen werden. Für die typische Haushaltsgröße (2–4) unnötig visuell.
+
Die "+" Einladen-Kachel mit gestricheltem Rahmen ist ein etabliertes Muster für "leerer Slot zum Hinzufügen" — sofort verständlich ohne Label-Erklärung.
+
Schlechter als V1 für Remove-Aktionen: Die Entfernen-Aktion ist auf der Kachel nicht sichtbar — man muss sie irgendwo verstecken (Hover-State, Kontextmenü). Auf Mobile nicht erreichbar ohne Tap-Geste.
+
+
+
+
+
+
+
+
+
V3
+
+
Split-Panel
+
Geteilte Ansicht: links die Mitgliederliste, rechts das Einladungs-Management-Panel. Auf Desktop zeigt das rechte Panel immer den aktuellen Invite-Status. Auf Mobile: Tab-Navigation zwischen den beiden Bereichen.
+ Für Haushalte mit häufigen Mitgliederwechseln
+
+
+
+
+
+
Desktop · 1200px
+
+
+
+
+
+
+
+
+
+ Mitglieder
+ 3
+
+
+
MR
+
Marcel Raddatz
Planner
+
+
+
SR
+
Sarah Raddatz
Mitglied
+
+
+
+
TM
+
Tom Meier
Mitglied
+
+
+
+
+
+
Mitglied einladen
+
Teile diesen Link per WhatsApp, SMS oder E-Mail. Der Empfänger erstellt ein Konto und tritt automatisch dem Haushalt bei.
+
+ https://mealprep.app/join/inv_x8K2j
+
+
+
+
Ausstehende Einladungen · 1
+
+ inv_x8K2j
+ 2 Tage
+
+
+
+
+
+
+
+
+
+
Mobile · 390px (Tab-Navigation)
+
+
+
+
+
Mitglieder
+
+
+
+
+
+
+
+
MR
+
Marcel Raddatz
Planner
+
+
+
SR
+
Sarah Raddatz
Mitglied
+
+
+
+
TM
+
Tom Meier
Mitglied
+
+
+
+
+
+
+
+
+
+
+
+
Design-Entscheidungen
+
+
Das rechte Panel zeigt immer den Invite-Status — kein Modal, kein Navigationsschritt. Gut für Haushalte, die regelmäßig neue Mitglieder onboarden (z. B. Wohngemeinschaften).
+
"Entfernen" ist im linken Panel direkt sichtbar als Text-Link in Fehlerfarbe — kein verstecktes Kebab-Menü. Spart einen Schritt, erhöht aber das Risiko eines versehentlichen Taps auf Mobile.
+
Mobile Tab-Navigation: Tabs mit Unterstrich-Indikator. Die "Mitglieder"-Seite ist der Default. "Einladen"-Tab zeigt das Invite-Panel mit Link-Generator und ausstehendem Invite.
+
Nachteil: Mehr UI-Fläche für eine seltene Funktion (Invite). Für Haushalte mit 2 Personen wirkt das Panel überdimensioniert.
+
+
+
+
+
+
+
+
+
V4
+
+
Datentabelle
+
Tabellarisches Format mit sortierbaren Spalten: Name, Rolle, Beigetreten, Status, Aktionen. Inline-Aktionen statt Kontextmenü. Kompakt und informationsdicht.
+ Für Power-User · Viele Mitglieder
+
+
+
+
+
+
Desktop · 1200px
+
+
+
+
+
+
+
Mitglieder
+
+
+
+
+
+
Name ↕
+
Rolle
+
Beigetreten ↕
+
Status
+
Aktionen
+
+
+
+
+
MR
Marcel Raddatz
+
Planner
+
14. Jan 2026
+
Aktiv
+
—
+
+
+
SR
Sarah Raddatz
+
Mitglied
+
15. Jan 2026
+
Aktiv
+
+
+
+
TM
Tom Meier
+
Mitglied
+
3. Mär 2026
+
Aktiv
+
+
+
+
+
?
inv_x8K2j
+
—
+
—
+
Ausstehend · 2 Tage
+
+
+
+
+
+
+
+
+
+
+
Mobile · 390px (Karten-Fallback)
+
+
+
+
Mitglieder
+
+
+
MR
+
Marcel Raddatz
Planner · 14. Jan 2026
+
+
+
SR
+
Sarah Raddatz
Mitglied · 15. Jan 2026
+
+
+
+
TM
+
Tom Meier
Mitglied · 3. Mär 2026
+
+
+
+
inv_x8K2jAusstehend · 2 Tage
+
+
+
+
+
+
+
+
+
+
+
+
Design-Entscheidungen
+
+
Ausstehende Einladungen als Tabellenzeilen mit grauem Hintergrund und "?" Avatar — visuell klar von aktiven Mitgliedern getrennt, ohne eigenen Abschnitt zu benötigen.
+
Sortierbare Spalten (↕) nur auf Desktop sinnvoll — bei 2–4 Mitgliedern keine echte Notwendigkeit. Für Wohngemeinschaften mit 6+ Personen relevant.
+
Mobile Fallback: Karten statt Tabelle. Tabellen-Layouts kollabieren auf kleinen Bildschirmen schlecht — Karten sind das korrekte Muster für den selben Inhalt auf Mobile.
+
+
+
+
+
+
+
+
+
V5
+
+
Erweiterbare Zeilen
+
Liste mit progressiver Offenlegung. Jede Mitgliederzeile lässt sich aufklappen, um Detailinfos und Aktionen zu zeigen. Kompakte Standardansicht, Details bei Bedarf — kein Seitennavigation nötig.
+ Gute Balance zwischen V1 und V4
+
+
+
+
+
+
Desktop · 1200px (Sarah-Zeile aufgeklappt)
+
+
+
+
+
+
+
Mitglieder
3
+
+
+
+
+
MR
+
Marcel Raddatz
+ Planner
+
Details ▼
+
+
+
+
+
SR
+
Sarah Raddatz
+ Mitglied
+
Details ▲
+
+
+
Beigetreten 15. Januar 2026 · Zugang zu Planer (Lesen) und Einkauf
+
+
+
+
+
+
TM
+
Tom Meier
+ Mitglied
+
Details ▼
+
+
+
Einladungen · 1
+
inv_x8K2j2 Tage
+
+
+
+
+
+
+
+
Mobile · 390px
+
+
+
+
Mitglieder
+
+
+
MR
+
Marcel Raddatz
Planner
+
▼
+
+
+
+
+
SR
+
Sarah Raddatz
Mitglied
+
▲
+
+
Seit 15. Januar 2026 · Lesen + Einkauf
+
+
+
TM
+
Tom Meier
Mitglied
+
▼
+
+
+
+
+
+
+
+
+
+
+
Design-Entscheidungen
+
+
Der "Zugang entziehen"-Button ist erst nach dem Aufklappen sichtbar — eine natürliche Bestätigungsbarriere ohne expliziten Bestätigungsdialog für das erste Tap.
+
Aufgeklappte Zeile erhält leichten Surface-Hintergrund (--color-surface) zur visuellen Abgrenzung vom Rest der Liste.
+
Besser als V1 wenn die Entfernen-Aktion prominent sein soll, aber nicht permanent sichtbar. Schlechter als V1 wenn maximale Einfachheit das Ziel ist.
+
Auf Mobile: "▼" Chevron als Tap-Target — muss mindestens 44×44px sein. Den gesamten Zeilenbereich tapbar machen ist vorzuziehen.
+
+
+
+
+
+
+
+
+
+
+
+
Machine-readable spec — E2 Mitglieder
+
Authoritative implementation reference for the /members page. Use before building any component for this route.
+
+
/* E2 Members page — implementation rules
+ * 1. Recommended variation: V1 (Roster list). Simplest, lowest overhead, matches household size 2–4.
+ * 2. Avatar colours: Planner = --green-tint bg + --green-dark text. Member = --blue-tint bg + --blue-dark text. Initials only.
+ * 3. Role badges: same colour pairing as avatars. border-radius: --radius-full. font-size: 11px. font-weight: 500.
+ * 4. The planner cannot remove themselves — no remove action on the Planner's row ever.
+ * 5. Pending invites: show expiry in --yellow-tint + --yellow-text when ≤ 3 days remaining, --color-subtle + --color-text-muted otherwise.
+ * 6. Remove action is destructive — requires a confirmation dialog with the member's name before execution.
+ * 7. Invite mechanism: generate a link/code. Copy to clipboard. No email delivery system in v1.
+ * 8. Expired invites: show "Abgelaufen" state. Provide one-tap regeneration — do not require re-opening an invite flow.
+ * 9. Household members can view this page in read-only mode (no invite button, no remove actions, no pending invites section).
+ * 10. Desktop sidebar: "Mitglieder" item is active, under "Haushalt" section. Mobile: "Einstellungen" tab is active.
+ * 11. WCAG 2.2 AA: avatar initials need 4.5:1 contrast. Role badge text needs 4.5:1 contrast. Confirm before implementing.
+ */
+
+
+
+
Element
Value / Rule
Notes
+
+
+
Avatar
+
Size
40px × 40px (desktop) · 36px × 36px (mobile)
border-radius: 50%
+
Planner colour
bg --green-tint · text --green-dark
Contrast OK: #2E6E39 on #E8F5EA ≈ 6.1:1
+
Member colour
bg --blue-tint · text --blue-dark
Contrast OK: #0C447C on #E6F1FB ≈ 7.4:1
+
Content
First letter of first + last name (uppercase)
Max 2 characters
+
Role badge
+
Shape
border-radius: --radius-full · padding: 3px 10px
font-size: 11px · font-weight: 500
+
Planner
bg --green-tint · color --green-dark
Label: "Planner"
+
Member
bg --blue-tint · color --blue-dark
Label: "Mitglied"
+
Invite / pending
+
Expiry badge — urgent (≤3d)
bg --yellow-tint · color --yellow-text
"Läuft ab in N Tagen"
+
Expiry badge — normal
bg --color-subtle · color --color-text-muted
"Läuft ab am DD. MMM"
+
Code font
font-family: --font-mono · font-size: 13px
Invite codes are monospace
+
Interactions
+
Remove action
Confirmation dialog required
Dialog must show member name. Irreversible — member loses access immediately.
+
Copy invite link
navigator.clipboard.writeText()
Show transient "Kopiert!" feedback (checkmark, 2s)
+
Regenerate invite
POST /household/invite — returns new code
Old code is immediately invalidated
+
Responsive
+
Desktop (≥1024px)
224px sidebar + full content area
Active sidebar item: Mitglieder (Haushalt section)
+
Mobile (<768px)
No sidebar · bottom nav · "Einstellungen" tab active
V3 mobile uses tab bar within page, not app bottom nav tabs
+ Der Hauptbereich unterhalb des Kalender-Grids zeigt immer nützlichen Inhalt — je nach Zustand.
+ Kein leerer Raum, kein Tab-Wechsel nötig. Das rechte Panel bleibt für den Rezept-Picker reserviert.
+
+
+
+
Zustand 1 — Kein Tag ausgewählt
+
Zustand 2 — Tag mit Rezept angeklickt
+
Zustand 3 — Leerer Tag angeklickt
+
+
+
+
+
+
+
+
+ Zustand 1
+ Kein Tag ausgewählt
+ Standard beim Laden der Seite
+
Klicke eine Kachel um Details zu sehen oder ein Gericht zu wählen
+
+
+
+
+
+
+ Inhalt ohne Klick: Agenda aller 7 Tage (geplante + leere), darunter Vorschläge für die beiden
+ ungeplanten Tage — anstelle von Score-Delta zeigen die Karten kurze Begründungs-Tags
+ (Neues Protein / Keine Überschneidung / Aufwand-Hinweis). Das rechte Panel zeigt „Heute Abend" als
+ direkte Koch-Modus-Abkürzung. Kein leerer Raum, kein Klick nötig.
+
+
+
+
+
+
+
+
+
+ Zustand 2
+ Tag mit Rezept angeklickt
+ Klick auf Mi, 9. Apr → Gemüse-Stir-fry
+
+ Nach Klick auf Mittwoch: Expansion öffnet sich direkt unter dem Grid mit Pfeil-Indikator.
+ Enthält Rezeptname groß, Zutaten-Tags (normale vs. Grundzutaten gedimmt),
+ Score-Impact-Badge und alle Aktionen. Unselektierte Kacheln werden leicht ausgeblendet (opacity 55%).
+ Darunter: kompakte Liste der restlichen Woche — geplante Tage + leere Tage mit „+ Hinzufügen".
+ Das rechte Panel wechselt auf einen Variety-Kontext: zeigt was dieses Gericht zur Woche beiträgt (positiv/neutral/negativ).
+
+
+
+
+
+
+
+
+
+ Zustand 3
+ Leerer Tag angeklickt
+ Klick auf Sa, 12. Apr → kein Gericht
+
+ Nach Klick auf leeren Samstag: Expansion zeigt 5 Vorschläge (3×3 Grid + „Alle Rezepte" als letztes Feld)
+ mit Begründungs-Tags statt Score-Delta. Die Farbkodierung der Tags macht die Qualität der Empfehlung lesbar ohne Zahlenwert:
+ Grün = klar besser, Gelb = neutral/tradeoff. Das rechte Panel öffnet gleichzeitig den vollständigen Rezept-Picker mit Suche —
+ für Nutzer die keinen der Vorschläge wollen. Klick auf eine Karte (main) oder Picker-Item (rechts) führt dasselbe aus: Rezept eintragen.
+
+ Tofu-Teriyaki erscheint mit „Gleiche Zutaten" (gelb) — das ist die sinnvolle Alternative zu einem Score-Delta von −0.2:
+ nicht versteckt, aber klar als Abwägung markiert.
+
+ Das Bild füllt die gesamte Kachelhöhe. Text und Tags werden über einen Gradienten am unteren Rand eingeblendet.
+ Kein leerer Bereich mehr — jeder Pixel der Kachel ist Bild.
+ Leere Kacheln behalten die Vorschlagsliste von innen.
+
+
+
+
+
+
+
+
+ Nahaufnahme
+ Kachel-Varianten
+
+
+
+
+
+
+
Gefüllt — Standard
+
+
+
+ Mo
+ 7
+
+
+
Hähnchen-Curry
+
35 Min · mittel
+
+ Hähnchen
+ 4 Port.
+
+
+
+
+
+
+
+
Gefüllt — Heute
+
+
+
+ Di
+ 8
+
+
+
Pasta Bolognese
+
45 Min · mittel
+
+ Rind
+ 4 Port.
+
+
+
+
+
+
+
+
Gefüllt — Ausgewählt
+
+
+
+ Mi
+ 9
+
+
+
Gemüse-Stir-fry
+
20 Min · einfach
+
+ Tofu
+ 2 Port.
+
+
▼
+
+
+
+
+
+
+
Gefüllt — Gedimmt
+
+
+
+ Do
+ 10
+
+
+
Lachs mit Kartoffeln
+
30 Min · einfach
+
Fisch
+
+
+
+
+
+
+
Leer — Vorschläge
+
+
+ Sa
+ 12
+
+
+
+
+
Gericht wählen
+
+
+
Vorschläge
+
+ Ramen mit Ei
+ Neu
+
+
+ Shakshuka
+ Kein Overlap
+
+
+ Tacos
+ Leicht
+
+
Alle →
+
+
+
+
+
+
+
Leer — Ausgewählt
+
+
+ Sa
+ 12
+
+
+
+
+
Gericht wählen
+
▼
+
+
+
Vorschläge
+
+ Ramen mit Ei
+ Neu
+
+
+ Shakshuka
+ Kein Overlap
+
+
+ Tacos
+ Leicht
+
+
Alle →
+
+
+
+
+
+
+
+ Gradient-Overlay: Dunkel oben (30% → 0%) für den Tages-Header, dunkel unten (0% → 55%) für den Text.
+ Der mittlere Bereich ist transparent — das Bild ist klar zu sehen.
+ Text-Shadow auf dem Rezeptnamen sichert Lesbarkeit auch bei hellen Bildern.
+ Tags nutzen rgba(255,255,255,.2) als Glasmorphismus-Hintergrund.
+ Zustands-Borders werden per box-shadow umgesetzt (kein Layout-Shift durch border:2px).
+
+
+
+
+
+
+
+
+
+ 01
+ Kein Tag ausgewählt — volle Seite
+ Kacheln füllen die Viewport-Höhe komplett
+
Klicke eine Kachel um Details zu sehen oder ein Gericht zu planen
+
+
+
+
+
+ Kein leerer Bereich. Das Grid nimmt die volle Höhe ein (height:100% auf Kacheln und Grid).
+ Gefüllte Kacheln: Bild von oben bis unten, Text per Overlay am unteren Rand.
+ Leere Kacheln: dieselbe Höhe, oben "+ Gericht wählen", darunter die Vorschlagsliste.
+ Da Mo–Fr alle Bilder haben, entsteht ein visuell abwechslungsreicher Kalender ohne Blank Space.
+
+
+
+
+
+
+
+
+
+ 02
+ Tag mit Rezept angeklickt
+ Mi — Expansion öffnet sich unter dem Grid
+
+ Beim Klick auf eine gefüllte Kachel werden alle anderen auf 42% Deckkraft gedimmt
+ (gefüllte und leere). Die Tiles bleiben in ihrer Höhe, die Expansion wächst darunter.
+ Da das Bild jetzt die volle Kachelhöhe einnimmt, wirkt das Dimmen als echter Fokus-Effekt —
+ wie eine Lupe auf das ausgewählte Gericht.
+
+ Problem: Desktop zeigt ~80 % leeren Platz. Die linke Sidebar hat den Variety-Score nur am unteren Rand.
+ Rechtes Panel beginnt mit „Kein Tag ausgewählt". Die Kacheln sind zu flach für die Datendichte die wir hätten.
+ Alle 5 Konzepte nutzen ausschließlich vorhandene API-Daten.
+
+ Was ändert sich: Variety Score wird an den Anfang der Sidebar verschoben. Darunter folgen Teilwerte (3 Mini-Balken),
+ Aufwandverteilung (Farbbalken), Top-Warnungen, und ein 5/7-Fortschrittsindikator.
+ Kacheln werden auf 160 px min-height erhöht und zeigen Effort-Badge + Protein-Tag.
+
+ Vorteile: Minimaler Aufwand, keine Layout-Änderung, alle Daten bereits vorhanden (varietyScore API liefert sub-scores + overlaps).
+ Die Sidebar ist jetzt von oben bis unten gefüllt. Kacheln vermitteln mehr Kontext auf einen Blick.
+
+ Was ändert sich: Die linke Sidebar entfällt — stattdessen gibt es eine horizontale Stats-Leiste direkt unter der Topbar.
+ Sie zeigt Score, geplante Tage, Ø Kochzeit, Aufwand-Farbbalken und Protein-Tags kompakt nebeneinander.
+ Der Kalender wächst auf die volle verbleibende Breite. Rechtes Panel zeigt beim ausgewählten Tag jetzt auch den aktuellen Score.
+
+ Vorteile: Maximaler Platz für den Kalender. Stats auf einen Blick ohne Scrolling. Variety-Score immer sichtbar.
+ Schwäche: Keine persistente Sidebar für Warnungen.
+
+
+
+
+
+
+
+
+
+ 03
+ Rechtes Panel als Wochenübersicht
+ „Kein Tag ausgewählt" durch echte Daten ersetzen
+
+ Was ändert sich: Nur das rechte Panel im Idle-Zustand. Statt „Kein Tag ausgewählt" zeigt es eine echte Wochenübersicht:
+ Geplant/Offen/Ø Kochzeit, ungeplante Tage als Einladung zum Klicken, und „Heute Abend" als schnellen Koch-Modus-Einstieg.
+
+ Vorteile: Kein leerer Zustand mehr. Nutzer sehen sofort den Stand ihrer Woche. „Heute Abend" löst den häufigsten
+ Use-Case (abends schnell kochen starten) direkt. Minimale Änderungen am restlichen Layout.
+
+
+
+
+
+
+
+
+
+ 04
+ Variety rechts, Kalender breiter
+ Variety-Analyse ins rechte Panel, kein linkes Sidebar mehr
+
+ Was ändert sich: Linke Sidebar komplett entfernt → Kalender gewinnt ~200 px Breite.
+ Das rechte Panel wird zum permanenten Variety-Dashboard: Score-Ring, Teilwerte, Aufwand-Balken, Warnungen.
+ Ganz unten: „Heute Abend" als direkter Koch-Modus-Einstieg. Beim Klick auf einen Tag ersetzt das Day-Detail-Panel diesen Inhalt.
+
+ Vorteile: Variety-Score ist immer im Blick, nicht nur am unteren Sidebar-Rand.
+ Breiterer Kalender = mehr Platz für Rezeptnamen. Klarer Haupt-CTA (Koch-Modus) ohne Tab-Wechsel.
+
+
+
+
+
+
+
+
+
+ 05
+ Mobile — Wochengitter statt Tagesstreifen
+ Alle 7 Tage auf einmal sichtbar, Score im Header
+
+
+
+
+
+
+
+
Aktueller Zustand
+
+
9:41●●●
+
+ Diese Woche
+
+ ‹
+ ›
+
+
+
+
+
+
+ 7.8
+ /10 Abwechslungs-Score
+
+
+
⚠ Hähnchen in 3 Mahlzeiten
+
+
+
+
Mo
+
Di
8
+
Mi
9
+
Do
+
Fr
+
Sa
12
+
So
13
+
+
+
Mittwoch, 9. April
+
+
Gemüse-Stir-fry
+
20 Min · einfach
+
+
+
+
+
+
+
+
+
+
+
Neuer Vorschlag — 2-Spalten-Gitter
+
+
9:41●●●
+
+
+ Diese Woche
+
+
+ 7.8
+ /10
+
+ ‹
+ ›
+
+
+
+
+
+
+
+
Montag · 7.
+
Hähnchen-Curry
+
35 Min · mittel
+
+
+
+
Dienstag · 8. ★
+
Pasta Bolognese
+
45 Min · mittel
+
+
+
+
+
+
Mittwoch · 9. — Ausgewählt
+
Gemüse-Stir-fry
+
20 Min · einfach
+
+
+
+
+
+
+
+
+
+
Donnerstag · 10.
+
Lachs mit Kartoffeln
+
30 Min · einfach
+
+
+
+
Freitag · 11.
+
Pizza Margherita
+
50 Min · aufwändig
+
+
+
+
Samstag · 12.
+
+
+
wählen
+
+
+
+
Sonntag · 13.
+
+
+
wählen
+
+
+
+
+
+
+
+
+
+
+ Was ändert sich (Mobile): Die gelbe Score-Banner wird aus dem Scroll-Bereich herausgelöst und als kompaktes Badge
+ in die Topbar integriert (spart ~80 px). Der horizontale Tagesstreifen + separate „Restliche Woche" Liste werden ersetzt durch ein
+ 2-Spalten-Gitter, das alle 7 Tage auf einmal zeigt. Der ausgewählte Tag expandiert zur vollen Breite mit integrierten Aktionen (kein separater großer Card mehr).
+
+ Vorteile: Auf einem Blick sieht man die ganze Woche. Kein Scrollen nötig um alle Tage zu sehen.
+ Score-Badge bleibt jederzeit sichtbar ohne Platz zu fressen. Expandierter Tag ersetzt das separate Tagesdetail-Pattern.
+
+ Das 7-Spalten-Grid nimmt ~150 px ein. Die Main-Area ist die volle Viewport-Höhe.
+ Fünf Konzepte, was den Raum darunter sinnvoll füllt — je mit dem gleichen Sidebar (Score oben) und rechtem Panel.
+
+
+
+
+
+
+
+
+ A
+ Variety-Dashboard direkt im Planer
+ Kein separater /planner/variety Tab mehr nötig
+
+ Was passiert: Die /planner/variety Seite existiert weiter als Deep-Link, aber ihre Kerninfos (Sub-Scores,
+ Protein-Grid, Aufwands-Balken, Warnungen) sind direkt im Planer sichtbar — kein Tab-Wechsel nötig.
+ Alle Daten kommen aus dem bereits geladenen varietyScore Objekt. Der „Detailansicht →" Link führt zur vollen Analyse-Seite.
+
+ Gelber Ring im Protein-Grid = Protein wiederholt sich an mehreren Tagen (kommt von tagRepeats).
+
+
+
+
+
+
+
+
+
+ B
+ Mehre Wochen gleichzeitig
+ Aktuelle + Folgewochen im selben Grid
+
+ Was passiert: Die Main-Area zeigt 3 aufeinanderfolgende Wochen. Die Spaltenköpfe (Mo–So) sind geteilt.
+ Jede Woche hat ein Label mit KW-Nummer, Datumsbereich und Score. KW 17 ist gedimmt — noch kein Plan, aber klickbar.
+ Die Sidebar zeigt den Score der aktuell fokussierten Woche + eine kompakte Wochenliste.
+
+ Was neu gebaut werden muss: API-Abruf für Folgewochen (gleicher Endpoint, andere weekStart Parameter).
+ Zwei zusätzliche Abrufe beim Laden der Seite. Score für Folgewochen wird mit kleinerem Datensatz berechnet.
+
+
+
+
+
+
+
+
+
+ C
+ Empfehlungen unter dem Grid
+ Ungeplante Tage werden direkt mit Vorschlägen befüllt
+
+ Alle Tage sind geplant. Gute Woche! Score: 7.8/10
+
+
+
+
+
+
+
Mittwoch, 9. Apr
+
Gemüse-Stir-fry
+
20 Min · einfach
+
+
+
+
+
+
+
+
+
+
+ Was passiert: Für jede Lücke in der Woche werden 3 Rezept-Vorschläge inline gezeigt — sortiert nach Score-Delta.
+ Klick auf eine Karte → setzt das Rezept direkt (kein Picker-Sheet nötig). Score-Delta (grün/rot) kommt bereits
+ aus der SuggestionResponse API, die der Planer schon abruft.
+
+ Vorteil: Wenn alle 7 Tage geplant sind, verschwindet diese Sektion und wird durch eine
+ Bestätigungsmeldung ersetzt. Die Hauptfunktion des Planers (leere Tage füllen) passiert ohne Panel-Wechsel.
+
+
+
+
+
+
+
+
+
+ D
+ Einkaufsliste unter dem Grid
+ Was diese Woche eingekauft werden muss
+
+ Was passiert: Alle geplanten Rezepte der Woche werden zusammengeführt und ihre Zutaten in Kategorien gruppiert.
+ Checkboxes ermöglichen das Abhaken beim Einkaufen. Mehrfach benötigte Zutaten (z.B. Tomaten Di+Do) werden gebündelt.
+
+ Was neu gebaut werden muss: Backend-Endpoint zur Zutatenaggregation (oder Frontend-Zusammenführung aus den
+ bereits geladenen Rezeptdaten). Checkboxen-State wäre nur clientseitig (kein Speichern nötig). Grundzutat-Flag
+ ist bereits im Datenmodell vorhanden (RecipeIngredient.staple), damit man diese ein-/ausblenden kann.
+
+
+
+
+
+
+
+
+
+ E
+ Klick-Expansion direkt im Grid
+ Kachel aufklappen statt rechtes Panel öffnen
+
Das rechte Panel könnte für den Rezept-Picker reserviert bleiben
+
+
+
Klicke einen leeren Tag um hier den Picker zu öffnen
+
+
+
+
+
+
+ Was passiert: Klick auf eine Kachel öffnet einen Expansion-Bereich direkt unter dem Grid
+ (volle Breite, mit Pfeil-Indikator zur aktiven Kachel). Gezeigt werden: Rezeptname groß, Metadaten, Zutaten als Tags
+ (normale vs. Grundzutaten farblich unterschieden), Score-Auswirkung und alle Aktionen.
+ Darunter folgt die restliche Woche als kompakte Agenda-Liste — ungeplante Tage als gestrichelte Zeilen mit „+ Hinzufügen".
+
+ Konsequenz für rechtes Panel: Das Day-Detail zieht in die Main-Area um. Das rechte Panel bleibt
+ als reiner Rezept-Picker reserviert — es wäre nur offen wenn man aktiv ein Gericht auswählt.
+ Das eliminiert den Idle-Zustand „Kein Tag ausgewählt" komplett.
+
+ Kein separater Agenda-Bereich. Die Kacheln selbst sind die Informationsschicht:
+ Bild-Placeholder oben, Rezeptname, Metadaten, Tags. Leere Kacheln nutzen die Höhe
+ für Vorschläge direkt inline. Unter dem Grid erscheint nur noch die Expansion beim Klick.
+
+
+
+
+
+
+
+
+ 01
+ Kein Tag ausgewählt
+ Standard beim Laden der Seite
+
Klicke eine Kachel um Details zu sehen oder ein Gericht zu planen
+
+
+
+
+
+
+
+ Kein Agenda-Bereich. Die Kacheln füllen die volle Höhe des Hauptbereichs.
+ Geplante Tage zeigen: farbiges Bild-Placeholder (wird durch heroImageUrl ersetzt),
+ Rezeptname, Kochzeit, Effort-Badge, Protein-Tag, Portionenanzahl.
+ Leere Kacheln (Sa, So) zeigen direkt 3 Vorschläge mit Begründungs-Tags — kein Scrollen nötig.
+ Klick auf einen Vorschlag-Eintrag → Rezept wird direkt eingetragen.
+ Klick auf die Kachel selbst → öffnet Expansion unten (Zustand 3).
+
+
+
+
+
+
+
+
+
+ 02
+ Tag mit Rezept angeklickt
+ Klick auf Mi — Gemüse-Stir-fry
+
+ Nach Klick auf Mittwoch: Nicht-ausgewählte Kacheln werden auf 45% Deckkraft gedimmt.
+ Die Expansion erscheint direkt unter dem Grid (Pfeil zeigt zu Mi).
+ Die Kacheln bleiben auf ihrer Höhe — der Expansion-Bereich wächst zusätzlich darunter.
+ Zutaten zeigen normale Zutaten als Pills; Grundzutaten (Sesamöl, Sojasauce…) gedimmt.
+
+
+
+
+
+
+
+
+
+ 03
+ Leerer Tag angeklickt
+ Klick auf Sa — kein Gericht geplant
+
+ Nach Klick auf leeren Samstag: Die Kachel selbst zeigt schon die 3 Inline-Vorschläge (sichtbar seit Zustand 1).
+ Der Pfeil-Indikator erscheint, die Expansion zeigt alle 4 Vorschläge nebeneinander als klickbare Karten.
+ Das rechte Panel öffnet gleichzeitig den vollständigen Rezept-Picker mit Suche — für alle anderen Optionen.
+ Klick auf eine Karte (main) oder Picker-Eintrag (rechts) trägt das Rezept ein und schließt die Expansion.
+