semmelei: Bakery Article Number on Items, shown in the Procurement

Start by reading the Item model and shared validation path, the admin Item request and response schemas, and the Procurement aggregation and page. Check CODING_STANDARDS.md, GLOSSARY.md, and CLAUDE.md for project conventions and the prior HTTP test harness in bnv-manager-v2. Done means the field works through admin editing and Procurement display, shop responses omit it, the migration is committed, and the specified API and frontend checks pass.

Problem Statement

The Nachbarschaftshilfe buys each pickup day's Procurement at the Bakery, and the Bakery takes orders by its own article numbers. semmelei only knows an Item's name, so whoever places the order has to look up or remember the Bakery's number for every line of the Procurement, every time.

Solution

Every Item gets an optional Bakery Article Number ("Artikelnummer (Bäckerei)" in the UI): the number the Bakery uses for it. Admins maintain it in the Item form. The Procurement ("Beschaffung") shows it next to each line, so the order can be read off the list. Customers never see it.

User Stories

1. As an Admin, I want to enter a Bakery Article Number when creating an Item, so that the Procurement shows it from the first order on.
2. As an Admin, I want to add a Bakery Article Number to an existing Item, so that Items created before this feature get one too.
3. As an Admin, I want to change an Item's Bakery Article Number, so that I can follow the Bakery when it renumbers its range.
4. As an Admin, I want to remove an Item's Bakery Article Number, so that an Item that no longer comes from the Bakery has none.
5. As an Admin, I want to leave the Bakery Article Number empty, so that Items not bought at the Bakery (coffee, eggs) need no fake number.
6. As an Admin, I want to enter numbers with leading zeros or letters ("00412", "B-17"), so that I can copy the Bakery's number exactly.
7. As an Admin, I want surrounding whitespace removed and a blank entry treated as no number, so that a pasted number is stored cleanly.
8. As an Admin, I want an overlong number (more than 32 characters) rejected with a clear error, so that typos like pasted paragraphs don't get stored.
9. As an Admin, I want to give two Items the same Bakery Article Number, so that a promotional variant of a product can map to the same Bakery article.
10. As an Admin, I want to see each Item's Bakery Article Number in the admin Item list, so that I can check which Items still lack one.
11. As Verkauf, I want every line of the Procurement to show the Bakery Article Number, so that I can place the order at the Bakery straight from the list.
12. As Verkauf, I want the Procurement to show the Item's current Bakery Article Number, not the one at order time, so that I never order under a number the Bakery has retired.
13. As Verkauf, I want a line without a number to show "–", so that I can see at a glance which lines I have to order by name.
14. As Verkauf, I want a line whose Item was deleted to show "–", so that the Procurement still works for orders of deleted Items.
15. As Verkauf, I want a line that covers several Items with different numbers to show all of them, comma separated, so that no number is silently dropped.
16. As Verkauf, I want the Procurement to keep one line per Item name, sorted by quantity, so that it still works as the packing list.
17. As a customer, I want the shop to show no Bakery Article Numbers, so that I only see what concerns me.

Implementation Decisions

• The Item model gets a new optional field, the Bakery Article Number, as a bounded string of at most 32 characters. A rorm migration adds it, nullable, so existing Items have none. No uniqueness constraint.
• Validation in the shared Item validation path (create and update): trim; empty after trimming becomes "no number"; longer than 32 characters is a bad request. No other format rules.
• The Item admin request and response schemas carry the field as an optional string. The shop's Item schemas do not carry it.
• No snapshot on the order position. Name and price stay snapshots as before; the Bakery Article Number is always read live from the Item through the position's Item link.
• The Procurement keeps grouping by the name snapshot and keeps its sort order (most units first, ties by name). Each Procurement position gains a list of Bakery Article Numbers: the distinct numbers of the live Items linked from that line's positions, sorted. Positions whose Item was deleted or has no number contribute nothing. An empty list renders as "–".
• Frontend: a text input in the admin Item form, a column in the admin Item list, and a column in the Procurement page. New i18n keys follow CODING_STANDARDS.md. The API client is regenerated, not hand-edited.
• Domain terms (Item, Bakery Article Number, Procurement) are in the semmelei GLOSSARY.md.

Testing Decisions

• One seam: the HTTP API, driven in-process against a throwaway Postgres. semmelei has no HTTP test harness yet; copy the one from bnv-manager-v2 (as CLAUDE.md describes) unless one has landed by then.
• Tests assert external behaviour only (requests and JSON responses), not database rows or internal functions.
• Cases:
  • create and update an Item with a number; whitespace is trimmed; blank becomes none; 33 characters are rejected
  • the Procurement shows the current number after the Item's number changed after the order was placed
  • a line without a number, a line of a deleted Item, and a line with two Items of the same name but different numbers
  • no shop response contains the number
  • access on the changed admin routes stays as before (401 anonymous, 403 Verkauf)
• Prior art: bnv-manager-v2's HTTP tests and harness.

Out of Scope

• Merging Procurement lines by Bakery Article Number (one line per number). Lines stay per Item name.
• Sorting the Procurement by number, or a separate "order sheet" view or export.
• Warnings or banners for Items without a number.
• Any number of our own for Items (the uuid already identifies them).
• Sending the order to the Bakery electronically.

Further Notes

The Procurement also serves as the packing list, which is why it stays one line per name and sorted by quantity.

Acceptance criteria

• HTTP tests for the cases above
• Admin can set, change and clear the number in the Item form; the Item list shows it
• Procurement page shows the number column with "–" for missing numbers
• Migration generated and committed
• just ci and the frontend checks are green