Two copies, on purpose
This track's title is the studio sidebar's motto: "Ember creates. Avatars remembers." It reads like a slogan, and it is a storage rule. The architecture spells it out in the first code block: Ember is first-level generated storage, and Avatars keeps a second durable copy so that Ember's history cleanup cannot destroy a chosen avatar.
Ember keeps the first copy of everything it makes, with the provider, the actual model, the references and a Pro history row. Ember is also allowed to clean up. Its exploration space, where apps send work they may or may not keep, can carry a retention policy per app: once that app's expiry is enabled, a cleanup pass deletes the bytes of its old, unprotected exploration images, while each record keeps its provenance. That is a sound policy for a generation engine that serves many apps. It is the wrong policy for my face.
So the two copies have two purposes. Ember's copy is generation history, cleaned by Ember's rules. Avatars' copy is the chosen avatar, kept by Avatars' rules: never resized, never re-encoded, and never archived while a publication, a set, a profile, a look or an unfinished generation still uses it.
The handshake between them
Every Avatars image job goes to Ember tagged as exploration work from cwkAvatars, with the batch, task and attempt in its metadata. Ember protects a new exploration result until its consumer says it holds a durable copy. A promise in the original request does not count; only an acknowledgement after the fact does. Avatars sends that acknowledgement only after the native bytes and their metadata are durable on its side. The second code block is the kit module's own statement of those rules, and one of them promises more than the code can keep. A failed acknowledgement usually leaves the image protected, but a PATCH that Ember applied before the connection dropped also reads as failed, with the protection already gone. That costs nothing here, because by then Avatars already holds its durable copy. Track 4 walks the handshake line by line.
One more state shows which copy matters. If Avatars holds the original but Ember's history insertion failed, the task ends as history_missing, with the phase "Original saved; history needs repair". The architecture calls that "recoverable metadata work, not permission to bill another generation." A missing receipt never becomes a reason to pay twice.
Born in one night
Firelink Birth created the repository on the evening of 2026-09-29, and the first night's work came as a fast run of commits:
| When | What landed |
|---|---|
| Birth | The scaffold from the family's birth template |
| 14 minutes later | The architecture and the durable asset foundation |
| Same evening | Durable batches, reference profiles and candidate review |
| Same evening | Canonical originals retained, legacy sets adopted, the native mobile studio; product 0.1.0 and TestFlight build 1 |
| After midnight | Reference drafts kept apart from studio composition; registered people adopted without reopening the legacy import (0.1.2); library navigation (0.1.3) |
| Early on 2026-09-30 | Image delivery bursts repaired and gallery lightboxes added (0.1.4) |
That is under three and a half hours from scaffold to 0.1.4. The commits of that night that carry a brain trailer name Codex, on GPT-6.
The review day, and several brains
The next day Claude took over. On 2026-09-30 Claude Fable 5.1 added named looks, appearance rules, the workflow templates of the previous lesson, delivery exports and the automatic route. About an hour later it replaced the studio's own Automatic entry with Ember's catalog row, and that evening it held each generator to the aspect ratios its catalog row lists and added the paid clip workflow. Claude Opus 5.5 made those clips play inline in the iOS app. On 2026-10-06 GPT-6 came back to remove the fallback ten-reference ceiling, and most later commits that carry a trailer name Claude Opus 5.5.
Several brains, one contract. Nobody renegotiated the design between sessions. The architecture written in the second commit is the contract, and the house sign asks every session to read it before changing an ownership boundary. The trailers make the provenance visible: you can see which brain made which move, and every move answers to the same document.
A born repository is not a running app
The architecture's purpose section sets the honesty rule for everything after it: "This document defines intended behavior; implementation and delivery evidence remain separate. A born repository is not a running or installed app." The README keeps delivery evidence in its own section, and each entry separates its facts: the tests that passed, the web build being served, a TestFlight build uploaded, processed and assigned to internal testing, and installation on a device "not yet counted". The house sign makes it an invariant: TestFlight upload, processing, assignment and device installation are separate facts.
The habit matters most when work moves fast. By 2026-10-23 the TestFlight pipeline had committed 21 builds. The pipeline commits a build number only after its export or upload step has passed, and the commit body names which one ran: an export-only run leaves the same subject line with Destination: export. All 21 bodies say Destination: upload, so each commit is evidence of the first fact of four, an upload, and nothing past it. The README records processing and assignment for only a few of them. Firelink Quest tells how a family repository is born. This quest keeps asking what each claim is evidence of.