Dune

Dune, a framework for agent-friendly architecture, introduces five rules to guide coding agents toward globally correct changes. The framework uses reserved files and owned folders to reduce decision fatigue and enforce mechanical failure for forbidden dependencies.

| Agent-friendly architecture | | | Dune assumes many contributors arrive with a narrow prompt, a few nearby files, and no complete model of Sand. the locally obvious change the globally correct change. Unsafe shortcuts fail with an error that names the supporte | | | This page defines the contributor context model and the architecture choices that keep repeated local edits from | | | Contract | | | A coding agent usually optimizes for what fits in its context: | | | - copy the nearest working pattern; | | | - edit the file already open; | | | - choose the shortest path that compiles; | | | - avoid deleting code whose callers are not visible; | | | - follow the requested implementation even when it conflicts with a system invariant. | | | These behaviors are predictable inputs to the framework design. Dune follows five rules: | | | 1. The conventional path requires fewer decisions than a shortcut. | | | 2. Forbidden dependencies fail mechanically. | | | 3. Every durable value has one obvious writer. | | | 4. New product work adds isolated files rather than branches in shared roots. | | | 5. Exceptions are narrow, explicit, and reviewed as architecture changes. | | | The five public nouns carry those rules. | | | A Feature creates an owned folder. | | | Its Entrypoints and Transcript cards are discovered from reserved files rather than registered in shared inventories. | | | The Client gives durable laptop state one writer behind named hooks and commands. | | | Host behavior stays in the box behind one typed contract. | | | The package boundary repeats the same lesson at the top level. Dune lives at sand/dune , the application lives under sand/src , and Dune never imports application code. |