engine-tdd

# Engine Changes Require a Failing Test First Behavior changes in `src/` require a failing test in `tests/FlatRedBall2.Tests/` **before** the source edit. Write it, run it, watch it fail, then fix. No "the cause is obvious, I'll skip the test" exception — that reasoning is how silent regressions ship. If you're about to edit `src/` without a failing test open, stop. Exceptions: XML docs, style-only edits, pure renames, dead-code removal. ## Shaders, Graphics, Color Values — Manual Test Is Never Skippable Any change touching a shader, blend state, render target, or pixel color math requires either a pixel-verification test or the user manually checking rendered output — never "manual test: not needed." Passing unit tests on surrounding math (offset clamping, parameter selection) does not cover this. ## API Design — Flag Before Implementing Before adding any new `public` or `virtual` member to an engine base class (`Screen`, `Entity`, `FlatRedBallService`, etc.), stop and flag it as an API design decision. Ask before writing code. New public/virtual surface is a footgun risk — it implies intent to users, shows up in IntelliSense, and is hard to remove once shipped.