Constraints
Defines a three-tier priority system for design decisions, with conflict resolution examples to guide trade-offs.
What this file does
Defines a three-tier priority system for design decisions, with conflict resolution examples to guide trade-offs.
When to use it
- Starting a new project and need to set design priorities
- Resolving disagreements about architecture or feature choices
- Documenting project values for new contributors
- Evaluating whether a proposed change aligns with core goals
Constraints
When two design goals conflict, the higher tier wins.
Tier 0 — Existence
- Conversation quality must improve with accumulated context. Day 3 must be meaningfully better than day 1. If it doesn't improve through use, nothing else matters.
- The UI is load-bearing, not decorative. The phase space and context markers are part of the thinking process — not a dashboard bolted onto a chatbot.
- Real data, not mocks. The system must work on actual conversations, not contrived demos.
Tier 1 — Design Principles
- Don't classify. Annotate. Store traces with minimal metadata. Annotations are computed, re-extractable, and category-free. No predefined types at the schema level — structure emerges from the data.
- Immutable traces, improvable annotations. Raw conversational content is never modified after creation. Everything computed on top (annotations, connections, embeddings) can be recomputed with better models.
- Vertical slices over horizontal layers. Build one thin path through all layers and prove it works end-to-end before widening.
- Tests define done. No component ships without passing tests.
Tier 2 — Technical
- Local-first, zero-cost default. Every component works without paid APIs. Paid services are upgrades, not requirements.
- Single-file database. One SQLite file.
cp voku.db backup.dbis the backup strategy. - Interfaces over implementations. Every service has an abstract interface. Swapping providers is a config change.
Conflict Resolution Examples
"Should I add predefined annotation types for common patterns?" → Tier 1.4: No. Let types emerge from extraction.
"Should I use a graph database for connections?" → Tier 2.9: No. SQLite recursive CTEs handle the query patterns at <10K traces.
"Should the graph be visible during every conversation?" → Tier 0.2: Only on demand. Research shows permanent split-panel hurts conversation quality.
What's inside
3 tiers with 10 numbered constraints, plus 3 conflict resolution examples
Change this for your project
- Replace
voku.dbwith your own database filename - Replace
jmin1219/vokuwith your own repository name
Where it goes
Keep it in your repository where the agent or team that needs it will read it.
Related Documents
Xilinx Constraints
Explains Xilinx XDC constraint ordering, compilation precedence, and key references for FPGA timing closure.
Technical Constraints & Requirements
Defines platform, performance, security, and deployment constraints for a Scottish mountain weather app with native iOS/Android and PWA fallback.
Token Constraints Implementation
Defines a token constraint system that counts tokens, truncates content, and streams responses to stay within an LLM's token limit.
Constraints
Explains how to model constraints as Ceres Solver cost functions in the fuse optimization framework, with a complete code example.