| name | spot-blindness |
| description | Fix algebraic blindness flagged by the unblind detector hook — replace over-generic bool/string/Maybe/tuple types with named sum types and newtypes. Use when a hook flags algebraic blindness, or when the user asks how to spot or fix it. Includes guardrails against over-narrowing (don't trade blindness for ceremony). |
Algebraic blindness is using a type too generic to carry the meaning of its
own values — bool, bare string/int, blind Maybe/Option/null,
untagged tuples. The fix is almost always the same move: name the cases, put
them in a type, let the compiler hold the line.
When the detector flags a site:
- Read
checklist.md (same directory) — it has the symptom tells, the 7-question
checklist, the fix toolbox, and the "when to stop" guardrails.
- Identify which fix applies (boolean param → enum; multiple flags → one state
type; blind nullable → named result; primitive obsession → newtype; ambiguous
predicate → meaningful return type).
- Run the litmus test first. A type earns its place only if it encodes a
distinction that (a) actually exists in the domain, (b) is currently lost or
violable, and (c) costs less to maintain than the bugs it prevents. If you
can't name the bug the precision prevents, leave the simple type — don't gild.
- Apply the smallest fix that removes the blindness. It usually deletes
validation code rather than adding it.
The detector only flags symptom shapes then asks an LLM to judge; it is not
authoritative. If a flag is a false positive (self-evident boolean, speculative
variant, harmless newtype), say so and move on.
