shipshitdev When a test or build fails during stabilization, follow this sequence:
READ the full error output — not just the last line. Stack traces, assertion messages, and build logs contain the diagnosis.
REPRODUCE the failure in isolation before changing anything.
- Run the specific failing test or build step alone.
- If it passes in isolation but fails in the suite, the problem is shared state or ordering.
HYPOTHESIZE explicitly before each change.
- State what you believe is wrong and what evidence supports that belief.
- Do not change code "to see if it helps."
LOCALIZE — narrow the failure to the smallest possible scope.
- Is it in the code you wrote, or in existing code you called?
- Is it a type error, a runtime error, or a logic error?
- If it is in existing code, the plan may have an unstated assumption — surface it.
FIX the root cause, not the symptom.
- Suppressing an error message is not a fix.
- Adding a null check at the crash site when the upstream function should not return null is not a fix.
- Changing the test expectation to match broken behavior is not a fix.
GUARD — write or update a test that fails without the fix and passes with it.
- This prevents the same failure from recurring in future stabilization cycles.