Flow Diagrams
Three maps. Each answers one question. The outcome map shows what success looks like. The value stream shows how data flows. The dependency map shows what must exist first.
1 of 3
What does success look like?
OUTCOME MAP — Better Practice
═══════════════════════════════════════════════════════════════════════
A viewer signs in and understands the path in 2 minutes.
The roadmap sells. The time investment makes sense.
The method is visible. The argument stops.
│
├── What exists ├── What blocks
│ ├── Venture JSON data (5 ventures) │ ├── No app exists
│ ├── Planning DB (projects, plans) │ ├── Data scattered across repos
│ ├── this-week.json (plan vs reality) │ ├── No synthesis surface
│ ├── Protocol stack documented │ ├── Technical language barrier
│ ├── Tight Five answers drafted │ ├── Pre-revenue = no financial proof
│ └── Marketing site generator │ └── Trev speaks PM, not tech
│
└── SUCCESS STATES
│
├── [S1] Visitor explains thesis in 1 sentence after 60s
├── [S2] All ventures visible with progress + kill criteria
├── [S3] Dream vs reality grid with weekly score
├── [S4] Plan completion bars match DB state exactly
├── [S5] 5 Tight Five cards render in order
├── [S6] Predictions have conviction + falsification
├── [S7] Auth gate blocks unauthenticated visitors
└── [S8] Viewer cannot access admin routesThe outcome map names what must be true. The value stream shows how data gets there.
2 of 3
How does data flow to the screens?
VALUE STREAM — Data to Screens
═══════════════════════════════════════════════════════════════════════
DREAM REPO (source of truth) ENGINEERING REPO (runtime)
───────────────────────── ────────────────────────────
src/data/ventures/*.json ──copy──→ src/data/family/
src/data/this-week.json ──copy──→ src/data/family/
src/data/family-dashboard.json ────→ src/data/family/
docs/software/protocols/ ──curate──→ vision.protocolStack in JSON
.invisible/profiles/ ──curate──→ tightFive answers in JSON
BETTER PRACTICE APP
───────────────────
/sign-in ─→ Better Auth
│
/roadmap ─→ Screen 1
│ ├── vision section (protocolStack)
│ ├── ventures table (ventures[])
│ ├── financials (3 metric cards)
│ ├── kill criteria (per venture)
│ └── predictions (conviction + horizon)
│
/time ────→ Screen 2
│ ├── this-week grid (dream vs reality)
│ ├── plans in flight (planning DB read)
│ └── weekly score (progress items)
│
/method ──→ Screen 3
├── Tight Five cards (5 Q+A)
└── predictions detail
PLANNING DB (PostgreSQL)
────────────────────────
planning_plan ────────────→ /time: plan cards + completion bars
planning_task ────────────→ /time: tasks done / total
planning_project ─────────→ /time: project contextThe value stream shows what feeds each screen. The dependency map shows what must exist first.
3 of 3
What must exist first?
DEPENDENCY MAP — Build Order
═══════════════════════════════════════════════════════════════════════
BP-005: App Scaffold (generator)
│
├──→ BP-004: Auth + Isolation
│ │
│ └──→ BP-001: Roadmap Screen ──→ [S1, S2, S6]
│ │
│ └──→ BP-003: Method Screen ──→ [S5, S6]
│
└──→ BP-002: Time Screen ──→ [S3, S4]
│
└── REQUIRES: Planning DB read access
(existing PlanningDrizzleRepository)
EXTERNAL DEPENDENCIES
─────────────────────
├── Better Auth .................. EXISTS (drmg-sales stack)
├── Marketing site generator ..... EXISTS (tools/generators/)
├── Planning DB + repository ..... EXISTS (libs/infrastructure/)
├── UI components ................ EXISTS (libs/app-client/)
├── family-dashboard.json ........ EXISTS (created this session)
├── this-week.json ............... EXISTS (src/data/)
├── Venture JSONs ................ EXISTS (src/data/ventures/)
├── Vercel project ............... MISSING (need to create)
└── betterpractice.space DNS ..... MISSING (need to configure)
CRITICAL PATH
─────────────
Generator → Auth → Roadmap → Deploy → Share → Measure
Total new code estimate: ~400 lines (3 pages + layout + nav)
Total composition: ~80% reuse of existing componentsThe maps prove the path. The stories prove the value. The scores rank the priority.