Safe Code Change

Safe Code Change

After a code change is made, find and fix affected tests before running validation.

Rules

• The code change is already done. Do not modify production code.
• Only update tests to match the new behavior, not the other way around.
• Do not reformat or lint-fix during test updates. Save that for validation.
• If a test change is ambiguous (unclear what the new expected behavior is), ask the user.

Step 1: Identify What Changed

git diff --name-only
git diff --stat

List the modified production files (ignore test files, configs, docs).

Step 2: Find Affected Tests

Search for imports of changed modules across test files:

rg "from lightspeed_agentic\.<changed_module> import" tests/
rg "import lightspeed_agentic\.<changed_module>" tests/

Step 3: Analyze Impact on Tests

For each affected test file, check whether the change breaks existing tests:

1. Signature changes — function renamed, parameters added/removed/reordered.
2. Behavior changes — return value, side effects, exceptions differ.
3. Removed code — tests for deleted functions/classes need removal.
4. New code — consider whether new tests are needed (ask user if unclear).

Step 4: Update Tests

Apply minimal fixes to each affected test:

• Update function names, parameters, expected values.
• Add async/await and @pytest.mark.asyncio if sync changed to async.
• Remove tests for deleted functionality.
• Do not add new tests unless the user asks.

Step 5: Done

Report what was updated. The user can invoke validate-and-fix when ready.