Sort one boundary's errors into named categories
Errors thrown with no type, replaced by named categories that each say what to do about them.
The ticket
Replace untyped errors at one boundary with a typed taxonomy carrying causes and remedies.
Acceptance criteria
- Each error category is a distinct type with a cause and a remedy
- Callers can branch on category without matching on message strings
- Each category has a test
- Unclassified failures surface as an explicit unknown rather than being swallowed
What lands as proof
A test per category asserting the classification, so error handling stops depending on message text.
Why teams defer it
- Matching on message strings works until somebody rewords a message, and then it fails silently.
- Designing the taxonomy needs agreement on what callers should do about each case, which is a design discussion.
Questions
- What does the agent actually change?
- The ticket is scoped to one outcome: replace untyped errors at one boundary with a typed taxonomy carrying causes and remedies. Work that serves that outcome is in scope, and anything outside it is left for a separate ticket, so the pull request stays reviewable.
- How do I know the work is done?
- The pull request carries the evidence, not only the diff. Here that means each category carries a test and a stated remedy, so a reviewer can confirm the result without reproducing the work locally.
- How much oversight does this need?
- The run stops once the plan is written. Somebody reads the approach and approves it before any code exists, which is the cheapest moment to redirect the work.