| name | edge-case-sweep |
| description | Enumerate edge cases against a concrete checklist before declaring code complete. Use when implementing or reviewing any function, handler, parser, or data transformation — after the happy path works, before reporting done. |
edge-case-sweep
The happy path is the easy 80%. Sweep this list against every new or changed code path and either handle, explicitly reject, or consciously note each relevant case:
Inputs
- empty:
"", [], {}, zero rows, zero-byte file
- absent: null / undefined / missing key / missing flag — distinct from empty
- boundaries: 0, -1, exactly-at-limit, limit+1, first and last element
- huge: 10^6 items, multi-GB file, pathologically long string
- weird text: unicode, emoji, RTL, newlines-in-fields, quotes, leading/trailing whitespace, case variants
- duplicates and unsorted order where uniqueness/order is assumed
State & time
- called twice (idempotency), called concurrently, retried after partial success
- stale state: file changed since read, record deleted between fetch and update
- timezone, DST, end-of-month/year, clock skew
Environment
- dependency down / slow / returning errors: what does the caller see?
- permissions denied, disk full, network cut mid-operation
For each case that applies: decide handle vs reject-loudly. The unacceptable outcome is silent wrong behavior. If a case is deliberately unhandled, say so in the completion report — a stated limitation is fine, a hidden one is a bug report waiting.
