Resolving Edge Cases

Use this to actively inspect relevant code, find plausible edge-case bugs, and fix or harden them. Do not wait for the user to enumerate edge cases.

Default Scope

When the user does not provide files, a commit, or a diff, inspect git status --short and start with relevant staged, unstaged, and untracked paths. For a branch or pull request, determine its target from repository or PR context and include paths from the merge-base diff, such as git diff --name-only <target>...HEAD; do not assume the target is main or master. If no changed path applies, inspect the files implied by the request; if no scope can be inferred, ask for one target.

Loop

1. Infer intended behavior from the user request, code, tests, docs, and sibling flows; state assumptions, but only ask when the rule is ambiguous.
2. Trace the real flow end to end, including callers, sibling routes, cleanup paths, and stored state.
3. Proactively inspect plausible edge cases for that flow; skip generic checklists that cannot occur.
4. Establish that each candidate violates intended behavior, then add the smallest regression test or executable check that fails before the fix when practical. If the failure cannot be verified, report the risk as unverified instead of changing behavior.
5. Fix or harden each confirmed bug at the shared root path, not only the reported symptom.
6. Run the narrow check, then scan sibling callers/routes for the same pattern.
7. Repeat while each fix exposes a concrete adjacent edge case.
8. Run the repo's normal verification gate before final response.