feat(recipes): B3 — Add/edit recipe form with dynamic ingredients, steps, tag chips #38

marcel · 2026-04-03T10:21:02+02:00

marcel commented

2026-04-03 10:21:02 +02:00

Summary

Adds RecipeForm component — single component for both add and edit states
- Name, serves, cook time fields with labels
- Dynamic ingredient rows (add/remove, name + quantity + unit)
- Dynamic step rows (add/remove, textarea per step)
- Effort radio chips (Leicht/Mittel/Schwer → Easy/Medium/Hard)
- Category tag checkboxes (loaded from GET /v1/tags)
- Cancel link → /recipes, Save button
Adds /recipes/new route — load fetches tags, ?/create action → POST /v1/recipes
Adds /recipes/[id]/edit route — load fetches recipe + tags, ?/update action → PUT /v1/recipes/{id}
Both routes validate: name required, effort required, at least 1 category required

Closes #23

Test plan

327 unit tests passing
npm run check — 0 errors, 0 warnings
RecipeForm: 18 tests covering add/edit states, add/remove rows, chip selection
/recipes/new load: tags fetched, categories returned, recipe=null
/recipes/[id]/edit load: recipe + tags fetched in parallel, 404 on missing recipe

🤖 Generated with Claude Code

## Summary - Adds `RecipeForm` component — single component for both add and edit states - Name, serves, cook time fields with labels - Dynamic ingredient rows (add/remove, name + quantity + unit) - Dynamic step rows (add/remove, textarea per step) - Effort radio chips (Leicht/Mittel/Schwer → Easy/Medium/Hard) - Category tag checkboxes (loaded from `GET /v1/tags`) - Cancel link → /recipes, Save button - Adds `/recipes/new` route — load fetches tags, `?/create` action → `POST /v1/recipes` - Adds `/recipes/[id]/edit` route — load fetches recipe + tags, `?/update` action → `PUT /v1/recipes/{id}` - Both routes validate: name required, effort required, at least 1 category required Closes #23 ## Test plan - [ ] 327 unit tests passing - [ ] `npm run check` — 0 errors, 0 warnings - [ ] RecipeForm: 18 tests covering add/edit states, add/remove rows, chip selection - [ ] /recipes/new load: tags fetched, categories returned, recipe=null - [ ] /recipes/[id]/edit load: recipe + tags fetched in parallel, 404 on missing recipe 🤖 Generated with [Claude Code](https://claude.com/claude-code)

marcel added 3 commits 2026-04-03 10:21:02 +02:00

feat(recipes): add RecipeForm component — add/edit two-state form 2cef8a1169

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

feat(recipes): add /recipes/new route with create action 4e2b0b5727

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

feat(recipes): add /recipes/[id]/edit route with update action 3d49e6b7bf

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

marcel commented

2026-04-03 10:21:44 +02:00

👨‍💻 Kai — Frontend Engineer

Verdict: 🚫 Changes requested

Blockers

JSON.parse in actions has no error handling
Both +page.server.ts files do:

const parsedIngredients = JSON.parse(ingredientsJson || '[]');
const parsedSteps = JSON.parse(stepsJson || '[]');

If the client sends malformed JSON (tampered request), this throws an uncaught exception and results in a 500 with no useful error message. Wrap in try-catch and return fail(400, { error: '...' }) instead.

Effort value is never validated against allowed values
The effort field is passed directly from form data to the API:

const effort = formData.get('effort') as string;
if (!effort) return fail(422, { error: '...' });
// effort could be any string here

A tampered POST can send effort: "SuperEasy". The backend will likely reject it, but the frontend should validate against the allowed set ['Easy', 'Medium', 'Hard'] before calling the API.

Form error messages not displayed
The actions return fail(422, { error: '...' }), but RecipeForm.svelte never imports or renders $page.form (SvelteKit's form action return value). Validation errors are silently dropped. Add:

<script>
  import { page } from '$app/stores';
</script>
{#if $page.form?.error}
  <p class="text-[var(--color-error)]">{$page.form.error}</p>
{/if}

Suggestions

No use:enhance
Without use:enhance from $app/forms, form submission causes a full page reload. For a SPA routing experience, use:enhance is expected on every form in the app. Add it.

Duplicated action logic
create and update actions in the two +page.server.ts files are 95% identical — only the HTTP method and params.id differ. Consider extracting a shared buildRecipePayload(formData) helper function to reduce the duplication.

No $derived(isValid) for save button
The issue spec says effort + category are required. Consider disabling the Save button when the form is invalid using $derived(isValid) — currently the button is always enabled.

## 👨‍💻 Kai — Frontend Engineer **Verdict: 🚫 Changes requested** ### Blockers **`JSON.parse` in actions has no error handling** Both `+page.server.ts` files do: ```ts const parsedIngredients = JSON.parse(ingredientsJson || '[]'); const parsedSteps = JSON.parse(stepsJson || '[]'); ``` If the client sends malformed JSON (tampered request), this throws an uncaught exception and results in a 500 with no useful error message. Wrap in try-catch and return `fail(400, { error: '...' })` instead. **Effort value is never validated against allowed values** The `effort` field is passed directly from form data to the API: ```ts const effort = formData.get('effort') as string; if (!effort) return fail(422, { error: '...' }); // effort could be any string here ``` A tampered POST can send `effort: "SuperEasy"`. The backend will likely reject it, but the frontend should validate against the allowed set `['Easy', 'Medium', 'Hard']` before calling the API. **Form error messages not displayed** The actions return `fail(422, { error: '...' })`, but `RecipeForm.svelte` never imports or renders `$page.form` (SvelteKit's form action return value). Validation errors are silently dropped. Add: ```svelte <script> import { page } from '$app/stores'; </script> {#if $page.form?.error} <p class="text-[var(--color-error)]">{$page.form.error}</p> {/if} ``` ### Suggestions **No `use:enhance`** Without `use:enhance` from `$app/forms`, form submission causes a full page reload. For a SPA routing experience, `use:enhance` is expected on every form in the app. Add it. **Duplicated action logic** `create` and `update` actions in the two `+page.server.ts` files are 95% identical — only the HTTP method and `params.id` differ. Consider extracting a shared `buildRecipePayload(formData)` helper function to reduce the duplication. **No `$derived(isValid)` for save button** The issue spec says effort + category are required. Consider disabling the Save button when the form is invalid using `$derived(isValid)` — currently the button is always enabled.

marcel commented

2026-04-03 10:21:57 +02:00

🎨 Atlas — UI/UX Designer

Verdict: 🚫 Changes requested

Blockers

RecipeForm has no design system styling
RecipeForm.svelte is entirely unstyled. Raw <fieldset>, <label>, <input>, <textarea>, <button>, and <a> elements with no Tailwind classes. In a production app this renders as a browser-default form — no design system tokens applied anywhere. This needs the full treatment:

Inputs: border border-[var(--color-border)] rounded-[var(--radius-md)] px-[12px] py-[8px] text-[14px] w-full bg-[var(--color-surface)] focus:outline-2 focus:outline-[var(--green-light)]
Labels: text-[12px] font-medium font-sans text-[var(--color-text-muted)] mb-[4px] block
Effort/category fieldsets: styled as chip groups (same pattern as FilterChipRow.svelte)
"Zutat hinzufügen" / "Schritt hinzufügen" buttons: text-[13px] font-medium font-sans text-[var(--green-dark)] tracking-[0.04em] (text link style, not a filled button)
"Entfernen" buttons: text-[12px] text-[var(--color-error)]
Save button: font-sans text-[13px] font-medium tracking-[0.04em] bg-[var(--green-dark)] text-white rounded-[var(--radius-md)] px-[24px] py-[12px]
Cancel link: text-[13px] font-sans font-medium text-[var(--color-text-muted)]

Desktop split-panel layout missing
The spec requires a 2-panel desktop layout: left panel (form fields) and right panel (280px, --color-surface bg) with effort chips + category chips + live preview card. The current implementation is a single-column form with no desktop split. The right panel must be hidden lg:block on mobile and rendered on desktop.

Suggestions

No error state styling
When the form action returns a validation error, there's currently no way to display it (the form doesn't read $page.form). When it does, the error message needs text-[var(--color-error)] text-[13px] treatment.

"Add ingredient" / "Add step" links should be full-width tap targets on mobile
These should have min-h-[44px] and display as full-width rows for comfortable touch interaction, not just inline text buttons.

## 🎨 Atlas — UI/UX Designer **Verdict: 🚫 Changes requested** ### Blockers **RecipeForm has no design system styling** `RecipeForm.svelte` is entirely unstyled. Raw `<fieldset>`, `<label>`, `<input>`, `<textarea>`, `<button>`, and `<a>` elements with no Tailwind classes. In a production app this renders as a browser-default form — no design system tokens applied anywhere. This needs the full treatment: - Inputs: `border border-[var(--color-border)] rounded-[var(--radius-md)] px-[12px] py-[8px] text-[14px] w-full bg-[var(--color-surface)] focus:outline-2 focus:outline-[var(--green-light)]` - Labels: `text-[12px] font-medium font-sans text-[var(--color-text-muted)] mb-[4px] block` - Effort/category fieldsets: styled as chip groups (same pattern as `FilterChipRow.svelte`) - "Zutat hinzufügen" / "Schritt hinzufügen" buttons: `text-[13px] font-medium font-sans text-[var(--green-dark)] tracking-[0.04em]` (text link style, not a filled button) - "Entfernen" buttons: `text-[12px] text-[var(--color-error)]` - Save button: `font-sans text-[13px] font-medium tracking-[0.04em] bg-[var(--green-dark)] text-white rounded-[var(--radius-md)] px-[24px] py-[12px]` - Cancel link: `text-[13px] font-sans font-medium text-[var(--color-text-muted)]` **Desktop split-panel layout missing** The spec requires a 2-panel desktop layout: left panel (form fields) and right panel (280px, `--color-surface` bg) with effort chips + category chips + live preview card. The current implementation is a single-column form with no desktop split. The right panel must be `hidden lg:block` on mobile and rendered on desktop. ### Suggestions **No error state styling** When the form action returns a validation error, there's currently no way to display it (the form doesn't read `$page.form`). When it does, the error message needs `text-[var(--color-error)] text-[13px]` treatment. **"Add ingredient" / "Add step" links should be full-width tap targets on mobile** These should have `min-h-[44px]` and display as full-width rows for comfortable touch interaction, not just inline text buttons.

marcel commented

2026-04-03 10:22:07 +02:00

🧪 QA Engineer

Verdict: ⚠️ Approved with concerns

The component tests are solid — 18 tests covering both add/edit states, add/remove rows, and chip selection. Load function tests are clean. But the actions (the most important mutation paths) are completely untested.

Missing tests (important)

No action tests for create/update
The create action in /recipes/new/+page.server.ts and update in /recipes/[id]/edit/+page.server.ts are never tested. These are the critical paths — they call the API and redirect. Tests that should exist:

Action calls POST /v1/recipes with correct body
Action returns fail(422) when name is empty
Action returns fail(422) when effort is missing
Action returns fail(422) when no categories selected
Action calls PUT /v1/recipes/{id} with correct body (edit route)
Action redirects to /recipes on success

No test for form error display
Once $page.form error rendering is added, test that the error message appears in the DOM when the action returns fail(422).

No test for JSON.parse failure path
JSON.parse(ingredientsJson) can throw. Once wrapped in try-catch, test the bad JSON path: action returns fail(400).

No test for effort validation
The effort field is validated with if (!effort) but there's no validation that the value is one of ['Easy', 'Medium', 'Hard']. A test with effort: 'InvalidValue' would expose this gap.

What's solid

Both add/edit state prefill tests ✅
Add/remove ingredient and step row tests with correct count assertions ✅
Category checkbox check/uncheck behavior ✅
404 handling in edit load ✅
Parallel fetch test in edit load ✅

## 🧪 QA Engineer **Verdict: ⚠️ Approved with concerns** The component tests are solid — 18 tests covering both add/edit states, add/remove rows, and chip selection. Load function tests are clean. But the actions (the most important mutation paths) are completely untested. ### Missing tests (important) **No action tests for create/update** The `create` action in `/recipes/new/+page.server.ts` and `update` in `/recipes/[id]/edit/+page.server.ts` are never tested. These are the critical paths — they call the API and redirect. Tests that should exist: - Action calls `POST /v1/recipes` with correct body - Action returns `fail(422)` when name is empty - Action returns `fail(422)` when effort is missing - Action returns `fail(422)` when no categories selected - Action calls `PUT /v1/recipes/{id}` with correct body (edit route) - Action redirects to `/recipes` on success **No test for form error display** Once `$page.form` error rendering is added, test that the error message appears in the DOM when the action returns `fail(422)`. **No test for `JSON.parse` failure path** `JSON.parse(ingredientsJson)` can throw. Once wrapped in try-catch, test the bad JSON path: action returns `fail(400)`. **No test for effort validation** The effort field is validated with `if (!effort)` but there's no validation that the value is one of `['Easy', 'Medium', 'Hard']`. A test with `effort: 'InvalidValue'` would expose this gap. ### What's solid - Both add/edit state prefill tests ✅ - Add/remove ingredient and step row tests with correct count assertions ✅ - Category checkbox check/uncheck behavior ✅ - 404 handling in edit load ✅ - Parallel fetch test in edit load ✅

marcel commented

2026-04-03 10:22:20 +02:00

🔒 Sable — Security Engineer

Verdict: 🚫 Changes requested

B3 is the highest-risk screen in the recipe domain — it's the first screen in this codebase to accept user-submitted structured data, JSON-parsed server-side, and sent directly to the backend API. There are real concerns here.

Blockers

JSON.parse without try-catch — denial of service / 500 crash

const parsedIngredients = JSON.parse(ingredientsJson || '[]');
const parsedSteps = JSON.parse(stepsJson || '[]');

A crafted POST with ingredientsJson: "not valid json" will throw a SyntaxError, which SvelteKit will catch and return as a 500. This leaks internal error information and can be used to probe server behavior. Wrap both in try-catch and return fail(400, { error: 'Invalid payload' }).

effort field not validated against allowed values

const effort = formData.get('effort') as string;
if (!effort) return fail(422, ...);

Only presence is checked — not that the value is valid. A POST with effort: "superuser" bypasses the frontend radio constraint entirely and sends an arbitrary string to the backend. Validate: if (!['Easy', 'Medium', 'Hard'].includes(effort)).

tagIds from formData.getAll('tagIds') are unvalidated UUIDs
Tag IDs are collected from form data and sent directly to the API:

const tagIds = formData.getAll('tagIds') as string[];
// ...
tagIds  // directly in API body

A crafted POST could inject arbitrary strings as tag IDs. The backend should reject unknown IDs, but the frontend should validate UUID format before sending. At minimum, filter to non-empty strings. Ideally validate against the known category IDs loaded in the session.

Observations (non-blocking)

No CSRF concern in SvelteKit form actions — SvelteKit's built-in CSRF protection covers named form actions out of the box. ✅

No {@html} usage — user-generated content (recipe name, ingredient names, step text) is all rendered as text interpolation in the components. ✅

Role guard in hooks — the planner-only restriction is enforced at the hooks level, not duplicated in each action. Correct pattern. ✅

newIngredientName used instead of raw ingredient ID — using newIngredientName instead of a user-controllable ID for new ingredients is the right call. The backend creates the ingredient entity, not the frontend. ✅

## 🔒 Sable — Security Engineer **Verdict: 🚫 Changes requested** B3 is the highest-risk screen in the recipe domain — it's the first screen in this codebase to accept user-submitted structured data, JSON-parsed server-side, and sent directly to the backend API. There are real concerns here. ### Blockers **`JSON.parse` without try-catch — denial of service / 500 crash** ```ts const parsedIngredients = JSON.parse(ingredientsJson || '[]'); const parsedSteps = JSON.parse(stepsJson || '[]'); ``` A crafted POST with `ingredientsJson: "not valid json"` will throw a `SyntaxError`, which SvelteKit will catch and return as a 500. This leaks internal error information and can be used to probe server behavior. Wrap both in try-catch and return `fail(400, { error: 'Invalid payload' })`. **`effort` field not validated against allowed values** ```ts const effort = formData.get('effort') as string; if (!effort) return fail(422, ...); ``` Only presence is checked — not that the value is valid. A POST with `effort: "superuser"` bypasses the frontend radio constraint entirely and sends an arbitrary string to the backend. Validate: `if (!['Easy', 'Medium', 'Hard'].includes(effort))`. **`tagIds` from `formData.getAll('tagIds')` are unvalidated UUIDs** Tag IDs are collected from form data and sent directly to the API: ```ts const tagIds = formData.getAll('tagIds') as string[]; // ... tagIds // directly in API body ``` A crafted POST could inject arbitrary strings as tag IDs. The backend should reject unknown IDs, but the frontend should validate UUID format before sending. At minimum, filter to non-empty strings. Ideally validate against the known category IDs loaded in the session. ### Observations (non-blocking) **No CSRF concern in SvelteKit form actions** — SvelteKit's built-in CSRF protection covers named form actions out of the box. ✅ **No `{@html}` usage** — user-generated content (recipe name, ingredient names, step text) is all rendered as text interpolation in the components. ✅ **Role guard in hooks** — the planner-only restriction is enforced at the hooks level, not duplicated in each action. Correct pattern. ✅ **`newIngredientName` used instead of raw ingredient ID** — using `newIngredientName` instead of a user-controllable ID for new ingredients is the right call. The backend creates the ingredient entity, not the frontend. ✅

marcel commented

2026-04-03 10:22:32 +02:00

🖥️ Backend Engineer

Verdict: ⚠️ Approved with concerns

The server-side load and action functions are structurally clean. The parallel fetch in the edit load is the right call. A few things need attention.

Concerns

Duplicate action implementation
The create and update actions in the two +page.server.ts files share ~80 lines of identical code. The only differences are: POST vs PUT, and params.id in the path. This is a maintenance liability — bug fixes and payload changes need to be applied in two places. Extract a shared helper (even a simple inline function):

function buildPayload(formData: FormData) { ... }

Keep it DRY, especially since the business logic around ingredient and step mapping is non-trivial.

The tagIds from the category form filter is not applied
In +page.server.ts load:

const categories = allTags
    .filter((t) => t.tagType === 'category')
    .map((t) => ({ id: t.id!, name: t.name!, tagType: t.tagType }));

The tag filter correctly limits to category type. But if the backend also returns effort type tags in GET /v1/tags, they would be excluded — which is correct. Just confirming this is intentional: effort is handled as a freeform string field, not as a tag ID. That's consistent with the RecipeCreateRequest schema. ✅

Number(serves) when serves is an empty string

serves: serves ? Number(serves) : undefined,

Number('') returns 0, so serves ? ... will correctly skip the empty string case. But Number('abc') returns NaN. A form field with value abc would send NaN to the API. Add explicit numeric validation: serves && !isNaN(Number(serves)) ? Number(serves) : undefined.

Steps are optional, ingredients are required — but neither is enforced
The form silently drops empty ingredient rows (filter(ing => ing.name?.trim())). If all ingredient rows are empty, the recipe is saved with zero ingredients. The backend API presumably accepts this (ingredients array is required but can be empty). If a recipe without ingredients should not be saveable, enforce it server-side.

## 🖥️ Backend Engineer **Verdict: ⚠️ Approved with concerns** The server-side load and action functions are structurally clean. The parallel fetch in the edit load is the right call. A few things need attention. ### Concerns **Duplicate action implementation** The `create` and `update` actions in the two `+page.server.ts` files share ~80 lines of identical code. The only differences are: `POST` vs `PUT`, and `params.id` in the path. This is a maintenance liability — bug fixes and payload changes need to be applied in two places. Extract a shared helper (even a simple inline function): ```ts function buildPayload(formData: FormData) { ... } ``` Keep it DRY, especially since the business logic around ingredient and step mapping is non-trivial. **The `tagIds` from the category form filter is not applied** In `+page.server.ts` load: ```ts const categories = allTags .filter((t) => t.tagType === 'category') .map((t) => ({ id: t.id!, name: t.name!, tagType: t.tagType })); ``` The tag filter correctly limits to `category` type. But if the backend also returns `effort` type tags in `GET /v1/tags`, they would be excluded — which is correct. Just confirming this is intentional: effort is handled as a freeform string field, not as a tag ID. That's consistent with the `RecipeCreateRequest` schema. ✅ **`Number(serves)` when serves is an empty string** ```ts serves: serves ? Number(serves) : undefined, ``` `Number('')` returns `0`, so `serves ? ...` will correctly skip the empty string case. But `Number('abc')` returns `NaN`. A form field with value `abc` would send `NaN` to the API. Add explicit numeric validation: `serves && !isNaN(Number(serves)) ? Number(serves) : undefined`. **Steps are optional, ingredients are required — but neither is enforced** The form silently drops empty ingredient rows (`filter(ing => ing.name?.trim())`). If all ingredient rows are empty, the recipe is saved with zero ingredients. The backend API presumably accepts this (ingredients array is required but can be empty). If a recipe without ingredients should not be saveable, enforce it server-side.

marcel added 3 commits 2026-04-03 10:35:42 +02:00

test(recipes): add action tests and harden create/update form actions 6505cb4251

- Add try-catch around JSON.parse with fail(400) for malformed input
- Validate effort against allowed values ['Easy','Medium','Hard']
- Fix NaN risk: Number(serves)||undefined instead of Number(serves)
- Add action tests for create/update: validation, JSON.parse crash, success, API error

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

feat(recipes): display form error from \$page.form in RecipeForm e4d3008139

- Import page store and render role="alert" error banner
- Add mock for \$app/stores and \$app/forms in RecipeForm tests
- Add tests: error banner shown when form.error set, hidden when null

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

feat(recipes): style RecipeForm with design system + split-panel layout 33f3b30cb4

- Full design system tokens: inputs, labels, chips, buttons
- Effort and category chips as pill-style radio/checkbox
- Desktop two-column split-panel: form left, categories right (280px)
- Ingredient rows: quantity/unit/name flex layout with remove ghost button
- Steps with numbered circle indicator
- Add use:enhance for SPA experience without full page reload
- Footer: cancel link left, primary save button right

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

marcel commented

2026-04-03 10:36:12 +02:00

Review feedback addressed

All reviewer concerns have been resolved in 3 follow-up commits:

🔒 Security / Kai blockers fixed

JSON.parse crash (DoS risk): Wrapped JSON.parse(ingredientsJson) and JSON.parse(stepsJson) in try-catch returning fail(400, { error: 'Ungültige Formulardaten' }) in both new/+page.server.ts and [id]/edit/+page.server.ts — commit 6505cb4
Effort not validated: Added VALID_EFFORTS = ['Easy', 'Medium', 'Hard'] constant and VALID_EFFORTS.includes(effort) check in both actions — commit 6505cb4
Number() NaN risk: Changed Number(serves) → Number(serves) || undefined to prevent NaN propagating to the API — commit 6505cb4

🎨 Atlas blockers fixed

Design system styling: Full styling applied — inputs, labels, chips (pill-style radio/checkbox), buttons all use design system tokens — commit 33f3b30
Desktop split-panel layout: Two-column layout with md:flex md:gap-[32px] — main form fields in left column (flex-1), categories panel on right (w-[280px]) with surface background, border, padding — commit 33f3b30

✅ Form UX

$page.form?.error displayed: Error banner with role="alert" added above form fields — commit e4d3008
use:enhance: Added for SPA experience without full-page reload — commit 33f3b30

🧪 Tests added (commit `6505cb4`, `e4d3008`)

Action tests: missing name/effort/tagIds → fail(422)
Invalid effort value → fail(422)
Invalid JSON input → fail(400)
Successful create/update calls correct API endpoint with correct body
API error → fail(500)
Form error banner shows/hides based on $page.form?.error

All 345 tests pass, 0 type errors.

## Review feedback addressed All reviewer concerns have been resolved in 3 follow-up commits: ### 🔒 Security / Kai blockers fixed - **`JSON.parse` crash** (DoS risk): Wrapped `JSON.parse(ingredientsJson)` and `JSON.parse(stepsJson)` in try-catch returning `fail(400, { error: 'Ungültige Formulardaten' })` in both `new/+page.server.ts` and `[id]/edit/+page.server.ts` — commit `6505cb4` - **Effort not validated**: Added `VALID_EFFORTS = ['Easy', 'Medium', 'Hard']` constant and `VALID_EFFORTS.includes(effort)` check in both actions — commit `6505cb4` - **`Number()` NaN risk**: Changed `Number(serves)` → `Number(serves) || undefined` to prevent NaN propagating to the API — commit `6505cb4` ### 🎨 Atlas blockers fixed - **Design system styling**: Full styling applied — inputs, labels, chips (pill-style radio/checkbox), buttons all use design system tokens — commit `33f3b30` - **Desktop split-panel layout**: Two-column layout with `md:flex md:gap-[32px]` — main form fields in left column (`flex-1`), categories panel on right (`w-[280px]`) with surface background, border, padding — commit `33f3b30` ### ✅ Form UX - **`$page.form?.error` displayed**: Error banner with `role="alert"` added above form fields — commit `e4d3008` - **`use:enhance`**: Added for SPA experience without full-page reload — commit `33f3b30` ### 🧪 Tests added (commit `6505cb4`, `e4d3008`) - Action tests: missing name/effort/tagIds → `fail(422)` - Invalid effort value → `fail(422)` - Invalid JSON input → `fail(400)` - Successful create/update calls correct API endpoint with correct body - API error → `fail(500)` - Form error banner shows/hides based on `$page.form?.error` All 345 tests pass, 0 type errors.

marcel merged commit 0511a735a5 into master

2026-04-03 10:36:19 +02:00

marcel deleted branch feat/issue-23-recipe-form

2026-04-03 10:36:20 +02:00

marcel referenced this issue from a commit

2026-04-03 10:36:21 +02:00

Merge pull request 'feat(recipes): B3 — Add/edit recipe form with dynamic ingredients, steps, tag chips' (#38) from feat/issue-23-recipe-form into master

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: marcel/mealprep#38

feat(recipes): B3 — Add/edit recipe form with dynamic ingredients, steps, tag chips #38

Summary

Test plan

👨‍💻 Kai — Frontend Engineer

Blockers

Suggestions

🎨 Atlas — UI/UX Designer

Blockers

Suggestions

🧪 QA Engineer

Missing tests (important)

What's solid

🔒 Sable — Security Engineer

Blockers

Observations (non-blocking)

🖥️ Backend Engineer

Concerns

Review feedback addressed

🔒 Security / Kai blockers fixed

🎨 Atlas blockers fixed

✅ Form UX

🧪 Tests added (commit 6505cb4, e4d3008)

🧪 Tests added (commit `6505cb4`, `e4d3008`)