Codex 為既有程式補測試：鎖住現有行為、專攻邊界、零行為改動

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.

把方括號 [ ] 內的變數換成你的內容，丟進 Claude Code / Codex。

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.