adjust: clarify runtime vs compile-time red validation

This commit is contained in:
Toni Doni
2026-03-25 02:10:01 +03:00
parent 46f6e3644b
commit 3c59d8dc60

View File

@@ -99,12 +99,15 @@ npm test
This step is mandatory and is the RED gate for all production changes. This step is mandatory and is the RED gate for all production changes.
Before modifying business logic or other production code, you must verify all of the following: Before modifying business logic or other production code, you must verify a valid RED state via one of these paths:
- The relevant test target compiles successfully, or the compile failure is itself the RED signal (i.e., the new test instantiates the buggy code path and a compile-time RED is the intended failure) - Runtime RED:
- The new or changed test is actually executed - The relevant test target compiles successfully
- The result is RED - The new or changed test is actually executed
- The failure is caused by the intended business-logic bug, undefined behavior, or missing implementation - The result is RED
- A compile-time RED is valid if the new test newly instantiates, references, or exercises the buggy code path and exposes the intended defect - Compile-time RED:
- The new test newly instantiates, references, or exercises the buggy code path
- The compile failure is itself the intended RED signal
- In either case, the failure is caused by the intended business-logic bug, undefined behavior, or missing implementation
- The failure is not caused only by unrelated syntax errors, broken test setup, missing dependencies, or unrelated regressions - The failure is not caused only by unrelated syntax errors, broken test setup, missing dependencies, or unrelated regressions
A test that was only written but not compiled and executed does not count as RED. A test that was only written but not compiled and executed does not count as RED.