One entry per experiment.

The biggest app in the lab. It started as a provider switcher and became a question: if a model returns arbitrary text, what does it take to turn that into a component you can render? Answer: a structure, a for…

Building AI apps burns tokens on every hot reload and breaks when the network does. Phantom returns responses shaped exactly like the real provider, deterministically. It is the only tool here that exists purel…

The premise: most prompt work is guesswork because nothing measures it. Forge closes the loop — pick a reference output from the expensive model, then iterate the prompt against the cheap one until parity cross…

Prompts are code and should be treated like it: versioned, diffed, reviewed, reused. This is the version of that idea where a prompt is one shape of a general asset, so agents, workflows and tools share the sam…

Every shell feature has to be proven somewhere. This is that somewhere: prompts, agents, workflows, library and docs in a single console. When the shell changes, this is what breaks first, on purpose.

The point was not to have a Flask app. It was to find out whether phantom-core was genuinely framework-agnostic or merely untested outside one runtime. Building the same API on Flask, and then again on Django, …

Written deliberately in Django's grain rather than as a transliteration of the Flask version: StreamingHttpResponse for SSE, a trimmed INSTALLED_APPS because the app has no models, and /v1 exempted from CSRF wi…

If agents are going to execute procedures, something has to hold the procedures. This is that, built on the same edit substrate.

Least resolved of the fifteen. The object model is there; what it should actually show is not settled.

Pairs with Phantom: Phantom fakes the model, this fakes everything else.

The input is a pile, the output is an object. First instance where the substrate had to build the object rather than receive it.

Graduated from app to shared module. It runs standalone and drops into any other app as a 'what's new' widget, which is the pattern the whole lab is aiming for.

The object model here is a tree rather than a flat block list, which is where the substrate first had to stretch.

The second module to graduate. Schema factory, pure pipeline logic, props-driven UI — no app owns it any more.

Second instance, and the one that proved the substrate generalised. Nothing changed except the object model and the exporters.

A deck is a document with a harder layout constraint. Same edit-operation loop, different exporter.

The object stops being linear here. Nodes and edges instead of blocks, same operation loop.

The original of the fifteen. The insight that made the rest possible: don't ask the model to rewrite the document, ask it to emit edit operations against a block model. The chat stays a conversation; the docume…

Regenerating an email loses the bits you liked. Editing it as an object doesn't.

The one with the cleanest export story — the object model is already close to JSON Schema, so the exporter is almost a cast.

Scaling a recipe is an edit operation over quantities, which makes it a neat test of typed fields in the block model.

Tables punish regeneration hardest — one hallucinated row and the whole thing is suspect. Edit operations keep the rest untouched.

The first of the studio line in Python, and the proof that porting the substrate rather than an app was the right call: ai-object plans the edits, phantom-core writes the prose, and neither knows the other exis…

The test of whether flask-studio was a real abstraction or just a folder. Copying Doc Studio would have proved nothing, so the generic half was extracted first and this was written as pure vocabulary: a slide i…

Its vocabulary file is identical to the Flask app's, and that is the whole point: the same studio, a different framework, and nothing about what a document is changes. Building it forced the honest split — thre…

Mirrors the React CV Studio's vocabulary exactly — sections and bullets, with the words a user actually says for each. Its test file is short on purpose: the machinery is tested once in studio-core, and once mo…

The vocabulary that stretched the abstraction least and proved it most: a runbook is a document whose containers are phases and whose items are steps you can tick off. Nothing in the shared core needed to know …

Pairs with Phantom: this drafts the shape of an API, Phantom serves fake responses in it. Both are vocabulary over shared machinery rather than applications in their own right.

The first studio whose items are references rather than prose, which was worth checking: the planner does not care what an item *is*, only what a user calls it.

Articles and clauses are containers and items with different names, which is the whole thesis of the studio line. The prompts ask for plain language on purpose — a fake contract that reads like real legalese wo…

A form is a document whose items happen to be questions. Same substrate, different noun.

The shortest object in the line, and the one where the container/item split is least obvious: an email's 'sections' are really beats. It still fits, which is the point.

The only consumer-facing vocabulary in the line, and the one that reads most naturally in another language — 'add a step about the sauce', drafted in German, comes back as a step rather than a section.

This one found a real assumption in my own test suite: every other studio has a container type distinct from its item type, and a generic test quietly relied on that. A diagram does not — it is nodes all the wa…

Rounds out the twelve. At this point a new studio costs a vocabulary and nothing else, which is the only useful measure of whether the abstraction worked.

Once there were more than ten apps, I needed something that could see all of them at once. It reads the same registry this website does.

The most backend-heavy thing in the lab — forty-seven server modules against nine screens. The hard parts are invisible: leases so two agents don't take the same task, and routing by capability rather than by n…

A window into the compiler system rather than a product. Useful mostly when something is wrong.

Every other app is this plus something. Keeping an untouched instance makes it obvious what each app actually contributes.

The most ambitious pipeline here — six stages from premise to rendered scene, each one a place the whole thing can go wrong. Getting characters to stay themselves between scenes is the unsolved part.

Cartoon Studio without the time axis, which makes it dramatically more tractable. Consistency is still the hard problem, just bounded.

Built because the media apps kept needing the same library screen. Should probably graduate into a module.

Narrow on purpose. One job, done end to end, with a real provider behind it rather than a mock.

Auth-free on purpose — it is the fastest way to see what the shell can look like. Flip a design and a lawyer's site becomes a pizzeria's.

The higher-level sibling of Website Builder: start from a design system rather than from blocks. The closest thing in the lab to a full site-building product.

No framework in the output — plain HTML and CSS, because the thing being built should outlive the thing that built it. Swapping chrome without touching content is the trick worth keeping.

Built for myself, which makes it the most honestly tested app in the lab. Vision models are good enough at food, and wrong in interesting ways.

A scheduling problem disguised as a CRUD app. The insights view is where it stops being either.