Project creatortrack collections over dedicated tables
name: CreatorTrack: apps are collections + custom view-blocks, not dedicated tables description: Architectural canon: every app = collection + custom view-block renderer; dedicated-table approach (app.habits, app.meal_entries, app.time_entries) is deprecated for CreatorTrack type: project
Decided 2026-06-19: in CreatorTrack, daily-driver apps (habits, food, time tracking, tasks) must be built as collections + custom view-block renderers, NOT as dedicated typed tables.
The framework: every app = Data (collection in the engine) + View (custom view-block registered in the renderer registry) + optional Feed (integration pulling data in) + optional Compute (rollups, AI, real-time).
The old Flask prototype's app.habits, app.meal_entries, app.time_entries tables are the deprecated pattern. They are islands: no relations, no rollups, AI needs special-case queries, can't link to projects or docs. The collection engine (app.nodes, collection_props, collection_values, collection_relations) is the right substrate because everything stays interconnected and AI reads all of it with one query path.
The new primitive to build: a custom view-block registry that extends collection_views.type beyond the 6 built-ins (table/board/calendar/gallery/list/timeline). A streak view-block over a Habits collection is the first proof.
Written as canon at memory/plans/creatortrack-app-model-collections-and-view-blocks-2026-06-19.md.
Why: Dedicated tables created a parallel universe that bypassed relations/rollups/AI uniformity. Justin explicitly wanted interconnected-database-first with custom UI on top, not standalone apps.
How to apply: Before building any new app domain in CreatorTrack, model it as a collection + view-block. Never create a new app.<domain> typed table for a daily-driver use case. The dedicated table pattern is allowed only for genuine scale/special data (clips, finance).
[auto-memory session ffde9d7e-154d-4218-b8fd-db176808a92b, confidence 0.88, mode direct]