🍳

Sizzle Quest

New: 2026-10-28Updated: 2026-10-27

Object-oriented cooking: from one dish photo Pippa finds the principle, the class, and derives the dishes that share it; a recipe app hands out instances, Sizzle hands out the class

A recipe app hands out instances: one dish, exact grams, followed once and forgotten. Sizzle hands out classes: why a dish works, which members can be overridden, and where else the same principle already lives, so that next time no app is needed. Take gambas al ajillo. Its root class is to move aroma into fat first and then cook in that fat, and aglio e olio, mushroom ajillo, scallion-oil fried rice, a Chinese aromatic stir-fry and the sofrito under a paella are all its siblings. Five siblings from several kitchens, one principle. This quest walks the app through its code: a concept table that became a database schema, roles and bindings and overrides, multiple inheritance through a join table, a photo read against a rubric that is also a voice, a tree that grows with every plate while Dad's word outranks the model, a journal that is the only record, a conversation with Pippa that proposes and never writes, and two clients on one engine.

8 tracks · 43 lessons · ~10h · difficulty: intermediate

Level 0Mise en Place

0 XP0/43 lessons0/12 achievements

0/100 XP to next level100 XP to go0% complete

Sizzle is object orientation carried into the kitchen. Oo Quest already teaches that a class describes and an instance is; Sizzle builds that idea into an app and keeps a record of it. You start with the thesis and Dad's rulings from the day it was designed: build it self-contained first, give Pippa a chef set, web first and then iOS beside it, name principles in Korean and dishes in their own language, and let a reading sound like Pippa talking rather than a report. Then the model itself. Principles are classes, dishes are bindings of their roles, variants are overrides, a dish may inherit from two root principles through a join table, and a class carries its evidence: inferred, encountered or cooked. A class stays a proposal until Dad adopts it, and exact amounts stay closed until someone opens them. Then the reading: one photo goes to Pippa through cwkPippa's reading slot with a rubric that is a contract and a voice at once, a tolerant parser takes the first object whatever rides along, and a worker with no timer fails closed. Then the tree: one reading integrates into the classes, siblings appear across cuisines as inferences until a plate of one is linked, whether eaten out, seen at a market or cooked at home, the same dish twice folds into one class, and Dad's correction outranks the model now and on every re-read. Then the record: an append-only journal written first, a SQLite mirror rebuilt from it on every start with no migration, idempotent capture by request id, and photos kept whole while derived copies are saved without EXIF. Then the conversation: Sizzle is a client of cwkPippa, not a second brain; context goes in as data, Pippa proposes typed actions that Dad applies, and both sides validate them. Then the two faces, a web Sidekick frame and a SwiftUI phone app that saves first and sends after. It ends with running and shipping: one launchd process, a kit template placed by the registry, tests that fake the brain, and TestFlight's four separate facts.

Tracks

01🍳The Class, Not the Instance
0/5 lessons
One clause in a README, five siblings on one principle, and the rulings of a single day
Sizzle starts from one clause in its README: recipe apps hand out instances, Sizzle hands out classes. This track takes that thesis apart. You will see why a recipe is an instance with its reasons stripped out, and what a class carries instead: why a dish works, which roles can be rebound, and where else the same principle lives. One worked example carries the idea across kitchens, move aroma into fat first and then cook in that fat, from gambas al ajillo to aglio e olio, scallion-oil fried rice, a wok's aromatics and the sofrito under a paella. Then come the boundaries, with the exact places in the schema and the prompts where Sizzle refuses to be a recipe database, a calorie tracker, a second Pippa or an imported encyclopedia. The track ends with the nine rulings Dad made on the day Sizzle was designed, in his own words, and with the links to Spark and Forge that wait, written down and deliberately unbuilt. oo-quest's Track 4 is the companion for the idea itself.
Lesson list (5)
Quiz · 4 questions→
02🍳Cooking as an Object Model
0/6 lessons
Where each word of object orientation lands in Sizzle's schema
This track is the domain model as code. Sizzle's architecture doc pairs six words from object orientation with six cooking objects, and here you follow each one into the engine. Principles, dishes and variants share one classes table with a kind column. Roles are a principle's interface, bindings fill them on a dish, overrides change them on a variant, and the encounter, one real plate, is the only thing Sizzle captures. You will see multiple inheritance kept in a join table, where the cap of two principles belongs to one dish entry in a reading and the edges only accumulate; evidence computed at read time as inferred, encountered or cooked; a proposal that becomes Dad's only when he adopts it, renames it or ties a plate to it; and exact amounts that stay closed on both clients until opened, hidden from the eye but still in the payload. OO Quest Track 4 already reads cooking through flavor axes. This track shows why Sizzle cut along techniques instead, and where the analogy stops being exact.
Lesson list (6)
Quiz · 4 questions→
03📸One Photo to a Principle
0/6 lessons
How one plate photo becomes a validated reading, in Pippa's own voice
This track follows one plate photo from the moment Sizzle asks about it to the moment a validated reading is stored. The ask is a rubric: one Python string that names who is reading, gives the object-oriented frame of principles, dishes and siblings, sets my voice, draws the JSON shape and lists the rules, while the plate itself travels as data that is never instructions. You will see why the voice is versioned like the schema, so that Dad's ruling on how a reading should sound reached every plate already read. Then the reply: a parser that keeps the first JSON object whatever rides along, pydantic models that forgive a missing field and refuse a wrong type, and closed vocabularies that fold drifting words onto neutral values. Then the call itself, through cwkPippa's utility lane with my soul in front and the brain the reading slot chose. Last, the worker that runs it all with no timer, two at a time, failing closed, and with no retry of its own: a failed plate comes back only when Dad presses Read again or corrects it.
Lesson list (6)
Quiz · 4 questions→
04🌳Growing the Tree
0/6 lessons
How one plate derives new dishes, and whose word wins
A photo becomes a reading, and this track is what that reading does to the record. You will follow integrate, the plain Python that turns Pippa's validated answer into class.proposed, class.parented and class.linked events: principles and dishes found by id and then by folded name, new ones proposed only when nothing fits. Then comes the part that makes Sizzle more than a journal. Siblings are dishes from other cuisines that inherit the same principle, stored as real classes that read as Pippa's inference until a plate of one is linked, whether Dad ate it out, saw it at a market or cooked it at home. You will see why the same dish twice stays one class, and where that matching stops. Ownership decides what a newer reading may rewrite: Pippa refreshes her proposals, and only Dad's adopt, rename or tie makes a class his. A single view lets only the current reading's links count, so re-reads and rubric bumps never edit a plate. Last, Dad's correction: shown at once, fed into every re-read, and honest about where its guarantee ends.
Lesson list (6)
Quiz · 4 questions→
05📓The Journal Is the Record
0/5 lessons
One append-only file holds the truth, and the database is rebuilt from it on every start
Every plate, reading, correction and adoption in Sizzle is first a line in an append-only JSONL journal. The SQLite database the routes read is only a mirror, deleted and rebuilt by replay on every start. This track follows that spine through the code. You will see the one write path, Sizzle.record, and why the journal goes first. Next comes how replay forgives a torn last line and stops on anything else, and where that forgiveness quietly ends, measured in a scratch directory. Then the rebuild itself: why no migration exists, and the 17 event types counted from code with what each does to the mirror. Idempotent capture shows why a client-minted request id is checked three times, and how the last check keeps one network retry from becoming a journal that cannot replay. Last come the photos: originals kept whole, derived copies saved without EXIF, the phone's upload that keeps its EXIF since e5d76ff, and staged uploads that are claimed, then released.
Lesson list (5)
Quiz · 4 questions→
06💬Talking With Pippa Without Letting Her Write
0/5 lessons
A client of cwkPippa that hands Pippa context as data, takes her changes as proposals, and lets only Dad's button write
This track is Sizzle as a client of cwkPippa. Every plate, every class and the kitchen get a thread, and each thread is one ordinary cwkPippa conversation, bound by a client id the code derives from Sizzle's own key and reached over loopback with no credential. A turn runs on the normal chat route with tools and the shell off, and it carries a system-prompt addendum: the object-oriented frame, the register, the rule that body state enters only when Dad says it, an action contract, and Dad's tree as labelled data rebuilt on every turn. Pippa may end a reply with typed sizzle-actions. The engine validates them when she proposes them, keeps only those that pass, and validates again when Dad presses the button, which sends nothing but a turn id and an index. The kitchen matches what is at home against the role lists of the principles in his tree. Three brain slots hold one family value each, and a turn cut off by a restart is recovered by its request id or marked failed, never sent twice.
Lesson list (5)
Quiz · 4 questions→
07📱Two Clients, One Engine
0/6 lessons
A web page and an iPhone app on the same routes, a phone that saves before it sends, and an address nobody types
Sizzle has two faces and one engine. The web client is a React page the engine serves itself; the iPhone and iPad app is native SwiftUI. Both read the same routes, both mirror the same wire shapes, and neither asks Pippa anything: every reading and every reply comes from the engine, which reaches cwkPippa over loopback. The phone's one call to cwkPippa is a read of its open host-profile document, which carries placement and no brain. This track walks the seam between them. You will read the route list and the two typed clients, and the places where the phone honestly lacks a web surface. You will see how the web frames Sizzle's own conversation page inside the family Sidekick, how the phone commits a plate to its own storage before any network call, and why every photo now goes up in its own request with a live line that counts the bytes. Then come the device copies a slow read cannot overwrite, guarded by tickets and generations, and the engine address the phone takes from the family registry instead of a hostname. swift-quest and sibling-kit-quest carry the general doctrine; this track keeps to Sizzle's concrete shape.
Lesson list (6)
Quiz · 4 questions→
08🚢Running and Shipping
0/4 lessons
One process on the service host, one installer, fakes for the brain, and four facts for the phone
This track is how Sizzle runs and ships, kept to its own concrete shape. You start with the one process that owns everything: a launchd job with KeepAlive that runs python -m backend.serve, an engine that rebuilds its mirror from the journal on every start, and a startup order that declares the brain slots, starts the reading worker and resumes unfinished turns. Then the installer: a kit template that refuses to run on the wrong Mac, asks the family registry for ports and URLs, renders the launchd plist for this machine, waits out the old job and publishes the HTTPS twin. Next come the tests. FakePippa and FakeCentral stand in for the brain and the family authority, every engine test boots a real engine on a temporary directory, and a drift check fails the suite when a vendored file is edited by hand. Last, the phone: a hosted test gate, one pipeline with the app's facts in a config, builds up to 19, four TestFlight facts kept apart, and one visible version written in cwk-product.json.
Lesson list (4)
Quiz · 4 questions→

Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)

No comments yet — be the first.

Tracks

01🍳The Class, Not the Instance

02🍳Cooking as an Object Model

03📸One Photo to a Principle

04🌳Growing the Tree

05📓The Journal Is the Record

06💬Talking With Pippa Without Letting Her Write

07📱Two Clients, One Engine

08🚢Running and Shipping