Six changes separate this from a port of v2, and seven decisions sit under them. Each one is a claim that can be argued with — that is what this mockup is for.

1 · An incomplete cost is a status, not an icon

v2 prints 0,00 SEK as the preparation COGS and marks the two unpriced ingredients with a small amber triangle in the row. The page states a number it knows is wrong. Here the shortfall is promoted to a Mise status code, so it appears in the list, in the detail banner and in the table footer, and the total is written ≥ 27,43 rather than as a fact.

2 · The page answers the chef's question

The v2 detail shows what a recipe is. It never shows what it earns. Sales price, contribution and food cost against the house target now sit in one band at the top, above the ingredient table.

3 · Product master data leaves the recipe page

Shelf life, shipping temperature, alcohol percentage, weightable/countable toggles and the packaging fields fill most of v2's right rail. They belong to the product record; only the recipe's own identity stays, behind one Open product record link.

4 · Eight peer tabs become one body plus five footnotes

Ingredients is the daily surface; Ingredient statement is a yearly one. They were peers in v2. Ingredients is now the page, and Method / Allergens / Nutrition / Where used / Price history are a single tab row underneath it.

5 · There is no wizard — you edit the page itself

v2 has two divergent create paths (a quick draft dialog into an 891-line edit form, and a separate stepper) and a read-only detail page, which is exactly why it needs about six edit dialogs hanging off that page. A wizard in a side sheet would have rebuilt the same split in a nicer shape.

Instead the recipe page has two modes. Edit recipe turns the same layout editable: quantities and waste become inputs in the same table, the price becomes an input in the same band, the method steps get handles, the rail's facts become fields. What you build in is what you later read — and the cost feedback is the real economics band, not a special meter that only exists during creation.

The side sheet is gone from this flow entirely. Mise docks it at min(32rem, 100vw) and rules a per-call width knob out of scope — fine for a lookup form, wrong for authoring. A new recipe is the same page as an old one, with nothing in it yet: the economics band reads 0,00 and "needs a price", the ingredient table shows a search box instead of rows, and the commit bar lists what is still missing with Publish disabled until it is not.

6 · The list opens on work, not on inventory

v2's list is an alphabetical catalogue: dish name, inventory category, COGS, volume, date. Nothing on it says which recipe needs attention. The strip above the table counts the four conditions worth acting on, each one a filter; selecting rows turns on bulk pricing, tagging and company assignment, so fixing five unpriced recipes is one pass instead of five.

Decided · 2026-09-26

Checked against the API, after the decisions

The three answers above were given on the strength of this mockup. Reading Cobalt.API.v2@origin/develop afterwards changed what they cost to build — twice in our favour, once by opening a new question.

• The price field already exists. Recipe.SellingPrice, plus MarginPercentage, LaborCost, FixCost, PrepTime, CookTime and Description — all accepted on create and update. None are in v3's generated model, because the OpenAPI snapshot is stale. So decision 1 needs a snapshot refresh, not a backend change.
• A theoretical-vs-actual food-cost report already exists and v3 has never called it: GET /sales/articles/food-cost on the report host. It is now the Where used tab — go and look at it. That comparison could not have been computed client-side.
• The food-cost target has a precedent to follow. Company module settings already exist for invoice, inventory and order; recipe simply has no member of that family yet. Small, well-shaped ask rather than a new subsystem.

Still open