Design Principles
MindMux is designed around a narrow thesis: durable project context is more valuable than disposable chat history.
Product principles
Durable outputs over transient interaction
A successful session should leave the project in a better state than it found it. Good answers matter, but durable knowledge matters more.
Local-first by default
Project knowledge should remain easy to inspect, version, move, and back up. File-based storage is a feature, not an implementation detail.
Strong opinions on scope
MindMux deliberately avoids becoming a generic chat client, a general wiki, or a full task board. The product is more useful when its boundaries stay sharp.
Runtime-portable knowledge
The knowledge layer should not depend on a single model vendor or runtime. Teams should be able to change execution surfaces without reauthoring core context.
Human-readable artifacts
Important outputs should be legible to humans and reusable by machines. Markdown is the default because it works well in both directions.
Discussion should lead to structure
MindMux does not treat conversation as the end state. The product should help users move from conversation to root docs, pages, or tasks with minimal friction.
Clear input and output boundaries
Tasks are for outbound execution from settled discussion. The app is easier to understand when its boundaries stay sharp.
UX implications
These principles shape the interface in concrete ways:
- chat is the front door, but not the final destination
- documentation is treated as a first-class output
- task handoff is lightweight and contextual
- workspace boundaries are explicit
- the app favors clarity over configurability in early flows
Architectural implications
These principles also explain several implementation choices:
- durable knowledge is stored in
brain/ - operational state is separated into project-local storage
- runtimes are abstracted away from the brain model
- MCP tools expose structured project context instead of relying only on prompt stuffing
- sessions and tasks are treated as real product objects, not incidental UI tabs
Non-goals
MindMux does not aim to be:
- a full knowledge graph platform
- a generic enterprise collaboration suite
- a catch-all AI shell for every workflow
- a replacement for engineering systems of record
That restraint is part of the design. The product should integrate with those systems when useful, not absorb all of their responsibilities.