Initial commit: CookIT recipe collection and week planner

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/adr/0001-local-first-sqlite-with-uuids.md

@@ -0,0 +1,9 @@
+# Local-first storage in SQLite (drift), with UUIDs for later sync
+
+CookIt keeps the whole Recipe collection on the device in a SQLite database accessed through drift, with no server. One cook on one Android phone doesn't need a backend, and the Recipe Bundle export is the backup. Every record gets a UUID rather than an auto-increment integer so a sync service can be added later without rewriting IDs or references.
+
+## Considered Options
+
+- **sqflite**: no code generation, but queries aren't checked at compile time and watch streams have to be wired by hand.
+- **JSON files**: simplest, but weak once Meal Plans reference Recipes.
+- **Cloud backend from day one** (Supabase/Firebase): not worth running for a single user in v1.

docs/adr/0002-recipe-parts-stored-as-json.md

@@ -0,0 +1,7 @@
+# A Recipe's parts are stored as JSON columns on its row
+
+Ingredient Groups and Lines, Step Sections, Photos, Tags, Sources and Review Flag reasons are stored as JSON in the `recipes` table rather than in their own tables. A Recipe is always loaded, edited and saved as a whole, and search runs in memory over a collection of a few hundred Recipes. Separate tables would add joins and position bookkeeping and gain nothing yet.
+
+## Consequences
+
+If a later feature needs to query across ingredients in SQL (e.g. a shopping list that sums the same ingredient over a Meal Plan), extract them into their own table with a drift migration at that point.

docs/adr/0003-units-are-data.md

@@ -0,0 +1,9 @@
+# Units are data: built-in ones plus the cook's own
+
+Units used to be a fixed list in code. The cook wants to add their own (e.g. "Würfel"), choose which ones the picker offers directly and in what order, so units now live in a `units` table (schema version 2). The 27 built-in units are seeded from the `Unit` enum and keep their keys and localized names; the cook's own units get an `own-<uuid>` key and a stored name. Ingredient Lines keep storing just the unit's key, so existing recipes and version 1 Recipe Bundles stay valid.
+
+## Consequences
+
+- Recipe Bundles are version 2: they carry the cook's own units (`units`), and an import creates the ones that are missing. Version 1 bundles (the Excel converter's) still import.
+- Built-in units cannot be renamed or deleted: their keys are shared by every bundle and by the Excel converter.
+- Deleting an own unit rewrites the Ingredient Lines that used it ("2 Würfel Brühe": the name moves into the ingredient), so no recipe points at a unit that no longer exists.

docs/adr/0005-recipe-code-format.md

@@ -0,0 +1,10 @@
+# Recipe Codes: compressed JSON in Base45, one QR code per Recipe
+
+Cooks who meet in person should be able to pass a Recipe from phone to phone without any connection, so a Recipe Code is a QR code that carries the Recipe itself rather than a link. Its text is `COOKIT1:` followed by the Recipe's Recipe Bundle JSON (without id, Photos, Favourite and Review Flag, plus the own units it uses), deflated and written in Base45 (RFC 9285). Base45 uses only the characters of QR's alphanumeric mode, which packs them densely enough that the text costs about as much space as the raw bytes would; this is the scheme the EU's vaccination certificates use. Measured on the original 214 Recipes, every one fits a single code (median QR version 23, largest 38), so there are no multi-part codes. Photos don't fit and travel only in a one-Recipe Recipe Bundle file instead.
+
+## Consequences
+
+- Only CookIt can read a Recipe Code; a plain camera app shows meaningless text. Readable plain text was considered and dropped: about a third of the Recipes wouldn't fit, and the structure would have to be guessed back.
+- The number after `COOKIT` is the format version. A reader refuses higher numbers with "please update CookIt", and must keep reading every older version, because codes may live on as screenshots.
+- The scanner uses ML Kit with its model bundled into the app (`mobile_scanner`'s default), not the Play-services download, so scanning works on a fresh install without internet. This adds about 3 MB to the APK.
+- A received Recipe is always saved as a new Recipe with a new id, even if the same one exists – unlike a full Recipe Bundle import, which skips Recipes it already has.