Process & Registry

Family build order

Which repo to tackle next, decided once (3 Sept 2026) rather than re-argued each session. The basis is dependency order, not effort or revenue — see "Why this basis" below.

Correction, same day: this list was written describing Amoleo-Accounts as the not-yet-built primary #1 — already stale the moment it was written, since Accounts had a working container, CI-published image, and shipped sign-in/profile/GDPR-erasure/RP-initiated-logout flows well before 3 Sept 2026 (see docs/stack.md §0 and Amoleo-Accounts's own commit history). Caught the same session a user flagged this repo's docs going stale generally. Accounts is done as a foundation — what's left against it is the migration work tracked under "Not 'build' work" below, not a build item — so it's dropped from the primary list and Images moves up to #1.

Primary — foundational or urgent

Build in this order. Each one either unblocks several later repos or is something the user needs soon regardless of what depends on it.

1. Amoleo-Images — the family's central image service. A shared dependency for whatever the newer products need for images, and the eventual replacement for Pets' and Connections' own Docker-volume storage.
2. Amoleo-Communications — comments, email, push. Amoleo-Reviews is explicitly designed to power its comment threads through this rather than building its own.
3. Amoleo-Registry — the shared canonical-identity store. Collections, Upnext and Editions are all designed to resolve item identity through Registry rather than storing their own — building any of those first would mean retrofitting Registry calls in later.
4. Amoleo-Todo — a self-contained personal task tool. Already depends on nothing left to build (Accounts is done); nothing else depends on it. Urgent on its own merits (user priority), not on the dependency graph.
5. Amoleo-Editions — the editions catalogue.

Everything else

No urgency attached — tackle in roughly this order since it still avoids rework, but exact sequencing among these matters far less than finishing the primary five above first:

• Amoleo-Collections and Amoleo-Upnext — both consume Registry, can be built in either order relative to each other.
• Amoleo-Reviews — needs Communications live, and ideally Editions live to pull approved reviews into.
• Amoleo-Worldbook — needs Registry for its appearsIn edges; more useful once Editions/Upnext/Collections exist to link entries into.
• Amoleo-Recommendations — reads live Collections/Upnext usage data, so it's only meaningful once those have real data. Last by construction.

Not "build" work — ongoing migration

Accounts already exists; Images is primary #1 above. Once Images ships too, the already-live sites pick up follow-up work triggered by that, not new builds:

• Pets, Connections — flip oidc: false → true in tools/stack.json now that Accounts has shipped (this is the migration work itself, not blocked on anything further); migrate off their own Docker-volume image storage once Images ships.
• Rissbrook, Website — no login system, so no Accounts migration; Website has no code dependencies on anything above and can be fleshed out any time, it's just low-urgency since nothing references it yet beyond the family lockup.

Why this basis

Ordering could have been driven by effort, revenue potential, or personal usefulness instead. Dependency order was chosen (3 Sept 2026 conversation) because building a downstream product before its foundation ships means retrofitting — logins bolted on after the fact (the risk this list itself briefly fell into, describing Accounts as unbuilt after it had already shipped), Registry lookups grafted onto data that was already free-form, image upload code thrown away once Images exists. The one deliberate departure from pure dependency order: Todo and Editions are pulled into the primary tier ahead of Collections/Upnext/Reviews/Worldbook/Recommendations despite not blocking anything, because the user wants them sooner regardless of the graph.

This list is a snapshot, not a standing rule — no checker enforces it, and there's no obligation to follow it strictly session to session. Update it here when the priority genuinely changes, the same idiom as everything else in this repo that would otherwise go stale silently.

Generated from docs/family-roadmap.md. Edit there and re-run npm run build in docs-site-src/ — never hand-edit a page.