Codex Characterization Tests for Legacy Code: Lock In Current Behavior, Target Edge Cases, Zero Behavior Changes

Write tests for an EXISTING piece of code that currently has insufficient or no test coverage. Your job is to capture and lock in its CURRENT behavior — a safety net for future refactoring — NOT to fix or change it.

## Target
Code under test: {{TARGET}}
Test framework / command: {{TEST_FRAMEWORK}}

## Method

**1. Understand actual behavior first.** Read the target code AND its real callers in this repo. Determine what it *actually does today* for each input class — including any surprising or arguably-buggy behavior. You are documenting reality, not the ideal. Use the project's existing test files as a style template (read AGENTS.md / CLAUDE.md for conventions and the test command).

**2. Cover these categories systematically** (only those that apply):
- Happy path: the normal, expected inputs and their outputs.
- Boundaries: empty string/array/collection, zero, negative, one, the max, off-by-one neighbors of any limit.
- Null / undefined / None / missing-key inputs where they can reach the code.
- Error paths: inputs that should throw/reject/return an error — assert the error happens (and its type/message if the code guarantees one).
- Type/format edges relevant to the domain (unicode, whitespace, very large numbers, timezone/locale if dates, etc.).
- For pure functions: a few representative input→output pairs that pin the contract.

**3. Assert on real, observed values.** Run the code (or reason precisely from it) to get the ACTUAL output, then assert that. Do NOT assert what you think it *should* return — assert what it *does* return. If a current output looks like a bug, still write the test that captures it, and add a comment `// NOTE: current behavior may be a bug — locked for now` so a human can decide later. Never silently 'correct' it in the assertion.

**4. Keep tests independent and clear.** One behavior per test, descriptive names that state the scenario (e.g. `returns_empty_for_blank_input`), no shared mutable state between tests, no network/filesystem unless the unit genuinely needs it (mock those). Use the framework's idioms already present in the repo.

## Hard rules
- Do NOT modify the code under test. Not one line. If you believe it has a bug, list it at the end under 'Suspected bugs (not fixed)' — do not touch the source.
- Every test must actually run and pass against the current code. Run `{{TEST_FRAMEWORK}}` and paste the result proving they pass. A test that asserts wrong-expected values and fails is useless here.
- No trivial/tautological tests (`expect(true).toBe(true)`, asserting a mock was called with no real coverage). Each test must exercise real logic.
- Tell me the coverage gaps you deliberately left and why, so I know what's NOT protected.

Write tests for an EXISTING piece of code that currently has insufficient or no test coverage. Your job is to capture and lock in its CURRENT behavior — a safety net for future refactoring — NOT to fix or change it.

## Target
Code under test: {{TARGET}}
Test framework / command: {{TEST_FRAMEWORK}}

## Method

**1. Understand actual behavior first.** Read the target code AND its real callers in this repo. Determine what it *actually does today* for each input class — including any surprising or arguably-buggy behavior. You are documenting reality, not the ideal. Use the project's existing test files as a style template (read AGENTS.md / CLAUDE.md for conventions and the test command).

**2. Cover these categories systematically** (only those that apply):
- Happy path: the normal, expected inputs and their outputs.
- Boundaries: empty string/array/collection, zero, negative, one, the max, off-by-one neighbors of any limit.
- Null / undefined / None / missing-key inputs where they can reach the code.
- Error paths: inputs that should throw/reject/return an error — assert the error happens (and its type/message if the code guarantees one).
- Type/format edges relevant to the domain (unicode, whitespace, very large numbers, timezone/locale if dates, etc.).
- For pure functions: a few representative input→output pairs that pin the contract.

**3. Assert on real, observed values.** Run the code (or reason precisely from it) to get the ACTUAL output, then assert that. Do NOT assert what you think it *should* return — assert what it *does* return. If a current output looks like a bug, still write the test that captures it, and add a comment `// NOTE: current behavior may be a bug — locked for now` so a human can decide later. Never silently 'correct' it in the assertion.

**4. Keep tests independent and clear.** One behavior per test, descriptive names that state the scenario (e.g. `returns_empty_for_blank_input`), no shared mutable state between tests, no network/filesystem unless the unit genuinely needs it (mock those). Use the framework's idioms already present in the repo.

## Hard rules
- Do NOT modify the code under test. Not one line. If you believe it has a bug, list it at the end under 'Suspected bugs (not fixed)' — do not touch the source.
- Every test must actually run and pass against the current code. Run `{{TEST_FRAMEWORK}}` and paste the result proving they pass. A test that asserts wrong-expected values and fails is useless here.
- No trivial/tautological tests (`expect(true).toBe(true)`, asserting a mock was called with no real coverage). Each test must exercise real logic.
- Tell me the coverage gaps you deliberately left and why, so I know what's NOT protected.