docs: Add CSS/layout changes as behavioral in TDD skip-red guidance

CSS class/property changes (overflow, flex, position, layout) alter
rendered output and are not refactoring. Document that these require
full Red-Green TDD with component tests asserting expected classes.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Author: cadamsdotcom

CLAUDE.md

@@ -232,6 +232,8 @@ uv run python -m scripts.tdd_log --log tdd-abc.log green --skip-red --reason=add
 
 The `--reason=refactoring` flag means "tests continue to pass without modification." If existing tests would FAIL after your change, you need the full Red-Green cycle -- not `--skip-red`. This applies even when the change feels minor (updating constants, changing timeouts, adjusting limits). If a test documents the current behavior and your change alters that behavior, update the test first, watch it fail, then implement the change.
 
+**CSS/layout changes are behavioral changes.** Changing CSS classes or properties (overflow, flex, position, min-height, z-index, etc.) alters how the page renders and is NOT refactoring. Write component tests asserting the expected CSS classes or inline styles are present, watch them fail, then implement the change. Even though jsdom cannot validate visual behavior (sticky, scroll, overflow), asserting the correct classes/properties are rendered catches regressions and enforces the Red-Green cycle.
+
 **Discovering the TDD Log File Name:**
 
 The TDD log file name and full usage examples are provided automatically at session start via the `SessionStart` hook. Look for the message at the top of your session that says `Your TDD log file is: tdd-<id>.log` followed by copy-pasteable Red, Green, and skip-red commands with the correct `--log` value already filled in. Use those examples as templates for all `tdd_log` commands.

scripts/plan_exit_hook.py

@@ -55,8 +55,10 @@ def get_nested_claude_review(plan_content: str) -> str:
 - Does the plan say "no test needed" or rationalize skipping tests for any changed file?
   If so, flag it - if it's worth implementing, it's worth testing.
 - If the plan modifies UI rendering (new elements, conditional display, disabled states,
-  event handlers), does it require component-level tests? Hook tests and backend tests
+  event handlers, CSS class/property changes like overflow, flex, position, layout),
+  does it require component-level tests? Hook tests and backend tests
   do NOT substitute for component tests that verify rendering and interaction.
+  CSS/layout changes are behavioral - assert expected classes/properties in component tests.
 
 Provide brief, actionable feedback. Be critical. Keep response under 200 words.
 
@@ -134,8 +136,10 @@ def main() -> None:
    - Are role-based access checks present?
    - If the plan adds or updates queries or handles user data, are the updatable fields restricted to only those needed?
 11. If the plan modifies UI rendering (new elements, conditional display, disabled states,
-    event handlers), component tests are required - not optional. Hook tests verify data flow,
+    event handlers, CSS class/property changes like overflow, flex, position, layout),
+    component tests are required - not optional. Hook tests verify data flow,
     backend tests verify the API, but neither verifies that elements render or wire events correctly.
+    CSS/layout changes are behavioral - assert expected classes/properties in component tests.
 12. Reject any plan section that says "no test needed" - if it's worth implementing, it's worth testing.
 13. Add a CLEANUP step at the end of your plan that addresses:
    - Remove "absence tests" used during TDD to verify removal of features/routes/UI