Freeze One Function's I/O Table, Then Change One Branch

Description and use

A technique for freezing a function's I/O table before refactoring. Create a JSONL oracle of observable I/O values, then safely refactor with regression protection.

Problem

Refactoring messy modules with hidden branches can silently break callers. Coding models rewrite entire files and drop rare conditions without a frozen oracle, leading to new outage modes.

Outcome

A reproducible test oracle that captures all observable I/O behaviors of a function, enabling safe refactoring without silent regressions.

Workflow

• Isolate the target function into a thin module without renaming branches or magic numbers
• Identify all observable I/O: return payloads, raised exception types, numeric delays, message text prefixes
• Build a fixture matrix covering all branches including max attempts, missing retry_after headers, auth failures, and unknown HTTP status codes
• Generate JSONL rows for each test case capturing args, result, and error
• Use the JSONL oracle as a regression baseline before refactoring
• Verify refactored code produces identical I/O by replaying the JSONL

Evidence

I/O means every value a caller can observe. Return payloads count as observable I/O. Raised exception types also count as I/O.

Source

Coding models will rewrite the entire file on request. They drop rare conditions without a frozen oracle.

Source