One input, several useful outcomes
A brain dump can contain an action, a question, and a time commitment in the same sentence. Daydraft separates that input into tasks, knowledge notes, and a daily plan. The interface gives each output a place instead of asking people to sort everything before they begin.
The repository includes a focus task, task lists, calendar views, and notes. The implementation discussed here concentrates on the organizing request and its recovery states.
Treat an AI response as untrusted input
A successful HTTP response does not guarantee a useful plan. The response validator checks the shape and content before the result reaches application state. Blank task titles, malformed lists, and empty output are rejected.
A notes-only result is accepted without manufacturing tasks. That distinction matters when a thought is a question or a useful fact rather than an action. The linked source documents the decision directly.
Make waiting bounded and recovery explicit
The organizing route verifies the session, reads provider settings, and delegates the model request. The deadline helper races the operation against cancellation as well as forwarding an abort signal, so a dependency that ignores cancellation cannot leave the caller waiting indefinitely.
The server route uses a 35-second deadline, while the client has a 45-second outer limit. These are configured time limits, not measured response times. Client messages explain how to retry or change settings and reassure the user that their text remains available.
Check failure paths as carefully as success
The repository includes tests for linked tasks and schedules, notes-only output, invalid JSON, missing credentials, rate limits, provider failures, and deadline handling. These scenarios document the behaviors the implementation intends to protect.
The evidence links point to a pinned source revision, making it possible to follow each decision through the route handler, validation helpers, and recovery tests.
What I would explore next
Proposed future work
Test recovery messages with people using their own provider keys, then use that feedback to improve retry and settings guidance.
Explore clearer previews before accepting generated schedule changes. Establish a baseline for request completion and failure categories while keeping brain-dump text out of measurement data.