CLCTN · TECHNICAL BLUEPRINT · TCA + SQLITE-DATA · SEPTEMBER 2026

Every screen, every reducer.

The whole app deconstructed into features a coding assistant can implement one at a time without holding the rest in its head. Sections 03 and 04 are the tables you asked for; section 00 is the preamble to paste above any single feature; and section 02 is the type manifest — the declarative file behind each of the sixteen types shipping today, which turns out to drive more of the screens than any other decision here.

Written against The Composable Architecture, sqlite-data and swift-dependencies. Where those libraries have an opinion, it is followed rather than wrapped — the fastest way to lose the value of this stack is to build an abstraction layer over it.

00 · THE PREAMBLE TO PASTE WITH EVERY FEATURE

One feature per conversation, this block on top, the feature's row from section 03 below it. Nothing else — a whole-app dump produces plausible code that compiles against imaginary APIs.

{{ p }}

01 · GLOBAL CONVENTIONS

Decided once here so no feature has to decide again. Each of these is load-bearing — breaking one produces code that works alone and fights everything around it.

{{ c.k }}

{{ c.t }}

{{ c.b }}

02 · THE TYPE MANIFEST

Each type is a declarative file with a 3D model beside it. This is the most important structural fact in the document: the app does not hold sixteen implementations of a collection, it holds one implementation and sixteen files — and the seventeenth is a file too. The database is a compiled cache of those files, never their author.

Read this first — any reducer that hardcodes something in the table below is a reducer that must be reopened every time a type ships.

{{ m.k }}

{{ m.t }}

{{ m.b }}

{{ k.key }}

{{ k.by }}

{{ k.what }}

03 · SCREEN OVERVIEW

Twenty-four screens. Where the prototype explored several treatments of one idea, this is the single screen that survives, with the alternatives folded in as states. Purely textual — no mockup is referenced, and none is needed to build from this.

{{ s.name }}

{{ s.route }}

{{ s.purpose }}

{{ s.flow }}

{{ s.actions }}

04 · TCA FEATURE ARCHITECTURE

Twenty-one reducers. Each card carries the six fields you asked for — screen, reducer name, state & inputs, actions split into view / internal / delegate, dependencies, and implementation rules — laid out as a card rather than a table row because state and action lists are code, and code in a 190-pixel column is unreadable.

Each card is self-contained: hand one card plus section 00 to the assistant and it has everything it needs. The rules are the part that matters most — they encode decisions already argued out, and every one of them exists because the obvious implementation is wrong.

{{ f.n }}

{{ f.name }}

{{ f.screen }}

STATE & INPUTS

{{ s }}

ACTIONS

VIEW

{{ a }}

INTERNAL

{{ a }}

DELEGATE

{{ a }}

DEPENDENCIES

{{ d }}

DETAILED IMPLEMENTATION RULES

{{ r }}

05 · DEPENDENCY REGISTRY

Every custom client, its surface, and what its test value does. A dependency without a deliberate testValue is a test suite that either crashes or lies.

{{ d.k }}

{{ d.api }}

{{ d.note }}

06 · WHAT I NEED DECIDED

{{ q.k }}

{{ q.t }}

{{ q.b }}