Entity Overview
All portal entities, their relationships, and the design philosophy behind them.
🗺️ Entity Mindmap
📊 Entity Matrix
| Entity | D1 Table | Mutable? | Lifecycle | API |
|---|---|---|---|---|
| 📋 Task | tasks |
Yes | draft → backlog → active → done → archived | Full CRUD |
| 📥 Feedback | feedback |
Yes | open → processed | parked → archived | Full CRUD |
| 💬 Comment | comments |
No | Append-only | GET/POST |
| 📊 Report | reports |
Yes | Active → archived | Full CRUD |
| 💭 Message | messages |
Yes | Sent/read tracking | Full CRUD |
| 🚀 Remote Job | remote_jobs |
Yes | pending → running → done/failed | Full CRUD + SSE |
| ⏱️ Velocity | velocity_logs |
Write-only | — | GET/POST/DEL |
| 📝 Session Log | session_logs |
Write-only | — | GET/POST/DEL |
| 📁 Project | projects |
Yes | active → completed → archived | Full CRUD |
| 🔴 Problem | problems |
Yes | 🔴 Solve → 🟡 Bear → 🟢 Accept | Full CRUD |
| 🌳 Nexus | nexus |
Yes | Vision tree nodes | GET/POST/PATCH |
| 🧪 Distill | distill |
Yes | Pipeline items | GET/POST/PATCH |
| 📚 Learning | learnings |
Write-mostly | — | GET/POST |
| 📊 Workflow Usage | workflow_usage |
Write-only | — | GET/POST |
| ⚙️ Preferences | preferences |
Yes | — | GET/PATCH |
🧬 Design Philosophy
Two opposing intents: The portal captures both permanent history (Comments, Logs)
and actionable work-in-progress (Feedback, Tasks). These are deliberately separated into different
entities to prevent conflation.
Two Loops reflected in entities: Entities have D1 tables and API endpoints. Concepts (like "Project" and
"Session") are implicit — tracked via fields or conventions, not their own tables.
Soft-delete everywhere: No record is ever physically deleted. Status PATCHed to
archived. Comments are the extreme case — they are literally append-only with no UPDATE
or DELETE.