Inspiration

One delayed train can disrupt an entire household’s afternoon. A child still needs collecting, a grocery order has a collection window, and a parcel shop is about to close. A shared calendar shows those commitments, but someone still has to work out what happens next.

DayPatch was built around that moment: turning a disrupted afternoon into a set of workable choices that a person can review.

What it does

DayPatch checks household availability, travel estimates, deadlines, transport requirements and collection authorisation to propose revised assignments.

In the fictional train-delay example, it finds two different trade-offs: approximately 61 minutes of travel with three reassignments, or 95 minutes with two. Users can compare routes and timelines, inspect individual constraints, and prioritise fewer handoffs or less travel.

Proposing a plan does not apply it. Users review the exact changes before approving. The saved assignment persists across reloads, and one-step undo restores the previous plan. Per-person handoff drafts and calendar exports help communicate the result.

DayPatch also demonstrates when a solution is impossible. If neither authorised adult can reach the child’s pickup before closing, it leaves that errand unresolved rather than assigning an unauthorised person. The server refuses to apply an incomplete plan.

How it was built

The application uses React, TypeScript and Vinext, with a D1-backed workspace and Drizzle database migrations.

A server-side constraint solver searches assignments and route orders. It checks availability, travel between stops, task durations, opening and closing times, authorised collectors, vehicle requirements and return-home limits.

The web interface calls a working MCP Streamable HTTP endpoint supporting protocol version 2025-11-25. Six tools handle reading the household, proposing changes, applying a reviewed option, undoing, loading demonstration scenarios and updating availability.

Saved proposals use revision checks to prevent an older session from overwriting newer changes. The server revalidates a selected option before applying it.

Development was assisted by Codex. The scheduling engine is deterministic; the browser’s conversational controls use a bounded command parser.

Challenges

The main challenge was distinguishing a plausible-looking schedule from a feasible one. A delayed arrival must affect every later stop, and authorisation cannot become a preference that the solver ignores for convenience.

Another challenge was keeping proposed changes separate from approved changes across the interface, database and MCP tools.

What I learned

A useful assistant needs dependable tools and a clear approval boundary. Showing the reasoning behind a schedule—its timing, constraints and trade-offs—helps people judge whether it works for them.

Eight automated solver tests and sixteen live workflow checks passed during development, covering feasibility, confirmation, stale revisions, undo, impossible assignments and calendar content.

What’s next

The next steps are richer task entry, opt-in household calendar connections, verified travel estimates and individual acceptance of proposed handoffs.

The current project is an Alexa+ experience simulation with a working MCP backend. Its household, map and travel estimates are fictional. It does not claim a live Alexa connection, external calendar synchronisation, automatic message delivery or an embedded language model.

Built With

Share this project:

Updates

Submission history