Planning Reference · Version 2 · Current

Household Ledger Platform
10-Step Rebuild Roadmap

The current planning path for the fresh repository. The rebuild now focuses only on the Household Ledger and Grocery applications, uses the legacy repository as reference rather than inherited authority, and keeps visual review available throughout the process.

V2 change: the former legacy-evidence pass and whole-platform upfront design are removed. Future applications are deferred until they are actually ready to enter the platform.
Current product scopeHousehold Ledger + Grocery
Legacy ruleReference, not blueprint
Review ruleEvery useful HTML stays visually accessible
1

Use the Dev Command build method

METHOD

Keep the sequence disciplined and cheap-to-expensive: Draw the Box → HTML Everything → React Fidelity → visual acceptance → interaction/state → data contract → database.

Carry forwardThe method, gates, and visual-first discipline.
Do not carry forwardAnother product's architecture or the legacy Household Ledger bureaucracy.
2

Maintain the Visual Review Library

REVIEW INFRASTRUCTURE

Every reviewable HTML is automatically deployed into one private Vercel library with searchable organization, versioning, and previous/next navigation.

Source remains sourceThe library is a viewer, never a new authority layer.
Automatic discoveryAdd an HTML file; the next deployment adds it to the library.
3

Phase 0 — Draw the Platform box

PLATFORM

Define Household Ledger Platform only as the application-family umbrella: Household Ledger + Grocery today, shared household identity/session, common app-family entry/return, and no requirement to design future apps.

4

Phase 0 — Draw Household Ledger

MAIN APP

Define the Household Ledger job, its Household and Core product groups, its ten major destinations, its route/destination map, and its edges without designing workflows or storage.

HouseholdOverview · Daily Command · Communications · Vision
CoreRecords · Cash Flow · Matters · Assets · Accounts · Binder
5

Phase 0 — Draw Grocery

BOUNDED APP

Document the current working Grocery product cleanly rather than redesigning it. Preserve its five persistent destinations and its separate app experience.

HomeInventoryShopMealsRecipes
6

Finish boundaries and accept Phase 0

OWNER GATE

Resolve only real ownership overlaps and exclusions for the current two-app scope. Approve Product Maps, Route/Destination Maps, and Boundary Decisions before HTML design expands.

7

Phase 1 — HTML Everything for Household Ledger

VISUAL AUTHORITY

Fully design the Household Ledger experience in HTML, destination by destination, including important states and responsive behavior. Detailed product decisions are made in context while the screens are visible.

8

Phase 1 — Normalize Grocery HTML

VISUAL AUTHORITY

Use the recent Grocery work as the current baseline, preserve what already works, fill missing visual authority, and organize it cleanly for migration into its own distinct app experience.

9

Translate accepted HTML with React Fidelity

IMPLEMENTATION

Bootstrap the fresh runtime only after HTML acceptance. Household Ledger and Grocery become distinct application experiences that share the household authentication/session and app-family entry/return model.

RuleReact translates approved HTML; it does not redesign it.
GroceryMigrate useful working implementation selectively rather than dragging the old app structure wholesale.
10

Define behavior, data contracts, then earn the database

BEHAVIOR → DATA

After visual acceptance, define interaction/state contracts and durable data ownership. Only then design the fresh schema, shared household/authentication foundation, and selective migration path from the legacy database.

Future applications

Library, Health, Tax, Estate Planning, Household Jobs, Careers, Gallery, and any later apps enter this same method when they are actually ready to be built. They do not need to be fully defined during the current Household Ledger + Grocery rebuild.