fix-red-case

name	fix-red-case
description	Fix production code for one red Kotlin JUnit case created or aligned by `$code-test-case`; use after that skill when the test is failing and test edits are forbidden.

Fix Red Case

Read ../../conventions/tests.md. Read ../../conventions/ergonomic-approach-rules.md. Read ../../conventions/process/production-code-development.md. Read ../../conventions/code-implementation.md.

Use this skill only after $code-test-case has created or aligned one Kotlin JUnit case and that case is red. Fix production code only. Do not edit tests, test fixtures, test data, assertions, display names, test annotations, or test build configuration.

Workflow

1. Reproduce or inspect the selected failing test and identify the current failure cause.
2. Make only the smallest production-code change that addresses the currently observed failure cause and is consistent with the selected case, and task design when they exist. Before editing production code, apply the loaded ergonomic, boundary, and code implementation conventions. Keep this skill's test-edit ban and selected-case scope as stricter constraints. Derive the selected behavior boundary from the failing test's entry point, endpoint, operation, scenario, and task design when present. Treat task design as the source for behavior intent and production value sources; use the selected case only to choose the current slice and checks. Keep investigation and edits inside that boundary, except for compile-only call-site propagation forced by the chosen change. Smallest production change means the smallest coherent production fix, not the smallest shortcut that greens the selected test. Do not introduce temporary, test-shaped, or bypass behavior into existing production code or existing call paths to reduce the current green slice. Placeholder behavior is allowed only where production-code-development.md allows it for newly introduced production code during selected red-case greening. If the selected test uses stale database setup after a production migration, fix the normal migration path used by the test; do not add production schema-existence branches. If the next necessary step would inspect or change a sibling endpoint, operation, mode, or scenario to justify the fix, stop and report the boundary instead of widening the implementation. Do not implement predicted later design changes before rerunning the selected test. If the test contradicts the task design, requires test edits, or cannot be fixed within production code, stop and report the blocker.
3. Rerun only the same selected test after each production-code change. If the failure changes, stop immediately and report the new failure. If the same failure remains after a production-code change, re-identify the current cause and continue only inside the same selected Feature boundary. Stop if the next fix requires changing a sibling endpoint, operation, mode, scenario, or a broader shared path not already inside that boundary.

Constraints

• Preserve the red case as the contract; do not weaken, skip, rewrite, or delete it.
• Keep scope to the selected failing case and the nearest production change points.
• Do not degrade, bypass, or special-case working production code to reduce the current slice.
• Do not refactor, redesign, or broaden behavior beyond what the case and task design require.

Output

Report the failure cause, design context used or absent, production files changed, verification command, and whether the test passed or the failure changed.