A task-plan interface needs predictable fields before it can display generated content. In Break-it-Down, a Zod schema defines that contract for the generation route.
Describe the object the interface needs#
The top-level plan contains a goal title, an emoji, and tasks. Each task contains an ID, title, description, and one of three difficulty labels: Easy, Medium, or Hard.
These fields make rendering decisions explicit. A title is a title, a description supplies supporting detail, and difficulty comes from a bounded set rather than an arbitrary sentence.
The route calls streamed object generation with this schema and Gemini, then returns a stream response. That connects the expected interface shape to the model-generation path.
Distinguish complete objects from partial progress#
A stream arrives over time. Consumers need to distinguish fields that are ready to render from fields that are still incomplete. The existence of a final schema does not make every partial chunk a complete plan.
That is a design constraint for streamed interfaces, rather than a claim that this source review tested every intermediate rendering state. A useful review exercises empty output, partial task descriptions, and generation failure.
Check invariants beyond field types#
The task ID schema accepts a string. Asking for a unique ID in its description helps communicate intent, but does not itself validate uniqueness across the task list.
If uniqueness is required for stable rendering or task references, it needs an additional check. The same distinction applies to meaningful task ordering: structurally valid fields can still describe a poor sequence.
Make the user's judgment part of the workflow#
The contract improves the predictability of generated output. A person still needs to review the proposed tasks, dependencies, and difficulty labels. Structural validation is one engineering boundary; useful planning is a separate product outcome that requires evaluation.