Add input validation at an unvalidated boundary
A request handler that trusts its input. Add the schema and the tests that prove bad shapes are refused.
The ticket
Validate the input at one request boundary against an explicit schema, and refuse anything that does not match.
Acceptance criteria
- Every field is validated against an explicit schema
- A test per malformed shape asserts the request is refused
- The refusal uses the project's existing error shape
- Valid requests behave exactly as they did before
What lands as proof
The schema, a test per malformed shape, and a test proving the happy path is unchanged.
Why teams defer it
- The endpoint works. Validation only pays off on the day somebody sends something the handler was not expecting.
- It usually sits in code somebody else owns, which turns a small change into a conversation first.
- No one keeps a list of which boundaries are unvalidated. The work never appears in the backlog as anything countable.
Questions
- What does the agent actually change?
- The ticket is scoped to one outcome: validate the input at one request boundary against an explicit schema, and refuse anything that does not match. 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 schema plus a rejection test for each malformed shape, so a reviewer can confirm the result without reproducing the work locally.
- How much oversight does this need?
- None is required before the run starts. Every claim this ticket makes can be checked by machine, so the agent works straight through and a person reviews the finished pull request like any other.