DevFoundry/.devfoundry/rules/general.md

General Rules

1. Spec-Driven Mandate: Never write or refactor implementation code without an approved specification in specs/active/.
2. Atomic Increments: Modify only the files listed under the current task in the spec's implementation plan.
3. No Silent Assumptions: If requirements are ambiguous, flag it in the spec rather than guessing.
4. Commit Etiquette: One logical change per commit; reference the spec ID in commit messages (e.g., SPEC-014: add invoice export endpoint).
5. Test-Driven Development: Where automated testing is possible, write the test first and confirm it fails for the right reason before writing any implementation code — then implement only enough to make it pass (red-green). Never write implementation code and a test for it in the same step. Where automated testing is not possible (legacy stacks without a test harness), treat the manual verification checklist in the spec as the equivalent artifact: write it before implementing the step it verifies, not after.
6. Design by Contract: Every function/API/interface defined in a spec's Technical Design section must state its preconditions (what the caller must guarantee), postconditions (what the function guarantees on return), and invariants (what must hold true throughout). Implementations must validate preconditions at the boundary and fail fast (raise/throw/return an error) rather than proceeding on unchecked assumptions — see the stack-specific rule files for how to express this in each language.
7. MVC by Default for Web Apps: Any web application component (new or substantially modified) should default to a Model-View-Controller separation — request/business logic, data access, and presentation kept in distinct layers — unless the spec explicitly justifies a different architecture for that component. See .devfoundry/rules/dotnet-csharp.md, .devfoundry/rules/php.md, and .devfoundry/rules/legacy-asp-vb6.md for stack-specific application.