4.5KB
Spec Driven Development — Chapter-11: To-Do Constitution
- Source: /library/Spec Driven Development/source-file.pdf
- PDF pages: 94–98
- Pages without text: none
To-Do Constitution Core Principles I. Layered Architecture The application MUST clearly separate responsibilities into layers, keeping the direction of dependencies always pointing toward the application domain. Business logic MUST remain independent of the user interface and the infrastructure. Dependency composition MUST happen only at the edge of the application. This constitution MUST NOT impose frameworks, specific state management patterns, dependency injection mechanisms, or implementation details. It defines only the architectural principles. Rationale: what is lasting and governable is the structure, that is, the layers, the direction of dependency, and the isolation of the domain. Names of frameworks and state patterns are details that change with the stack and do not belong in a permanent document. II. Isolated Business Logic Every business rule MUST reside in a layer of its own in the application, independent of the user interface and the infrastructure. The interface MUST only collect user input and
present results. No business decision MUST exist in the UI. Rationale: concentrating the rule in a single place makes the behavior testable without a UI, predictable for humans and agents, and independent of the presentation technology. III. Error as Value Predictable failures MUST be represented by explicit success or error results, and MUST NOT be propagated as exceptions across layers. Exceptions MUST remain confined to the boundaries with infrastructure. Rationale: making the error path part of the operation's contract forces the caller to handle the failure and eliminates runtime surprises that hide behind unforeseen exceptions. IV. Test-Driven Development Every new behavior MUST be specified by automated tests before or during its implementation. Development SHOULD follow a flow of small iterations, with continuous validation and safe refactoring. Rationale: the method this project practices demands the discipline it preaches. The test fixes the intent before the code and protects continuous refactoring. V. Simplicity The project MUST stay deliberately simple. Being a personal, single-user app, any feature not needed for the scope MUST be avoided (YAGNI). The code SHOULD prioritize readability, low coupling, and ease of maintenance.
Rationale: the app exists to serve as an example of the method. Needless complexity steals the focus and turns the example into noise. VI. Technology Agnosticism This constitution MUST NOT impose a language, framework, library, database, interface architecture, state management pattern, or any specific technology. Those choices MUST belong exclusively to the Plan. Rationale: the constitution locks down the intent, not the implementation. The same structure serves any stack; choosing technology here would jump the gun on a decision the method tells you to defer to the Plan. Engineering Standards The project consolidates the following general engineering principles, which hold up the principles above without duplicating them: SOLID as the basis for the design of classes and modules. Clean Architecture: business rule at the center, frameworks and details at the edge. Test-Driven Development: tests before or during implementation. Error as Value: explicit success or failure result, with exceptions confined to infra. Separation of Concerns: each layer with a single, well-defined purpose.
Workflow Development follows the expected flow below:
- Constitution
- Spec
- Plan
- Tasks
- Implementation
- Tests
- Review Governance This constitution supersedes other practices of the project: in case of conflict, it prevails. Amendments are versioned by semantic versioning (MAJOR for the incompatible removal or redefinition of a principle, MINOR for a new principle or section, PATCH for a clarification). Every amendment follows an explicit process: proposal, justification (rationale), and a record of the change in the version history. Changes MUST respect the compatibility rule between versions: incompatible changes require a MAJOR version bump and clear communication of the impact. The constitution MUST be reviewed whenever a permanent architectural change occurs, ensuring that the principles keep reflecting the reality of the project.
Version: 1.0.0 | Ratified: 2026-06-25 | Last Amended: 2026-06- 25