-
-
Mobile kitchen view with the same persisted plan and explicit step confirmation.
-
Kitchen timeline: confirmed progress, occupied resources, and the next action.
-
Recovery comparison: keep warm bread for 19:07 or accept room-temperature bread for 18:59.
Inspiration
You're halfway through dinner when a call takes you out of the kitchen. Twelve minutes later, the vegetables are still in the oven, the salad is unfinished, and guests will arrive at seven. You need to work out where to resume and what can still change.
SupperShift focuses on that moment. A home cook preparing several dishes has to remember physical progress while sharing limited equipment across the meal. The project brings that information into one place, so the cook can review the situation, weigh a compromise, and continue from the same kitchen state.
What it does
SupperShift is a cooking-interruption recovery companion with a next-action view, resource timeline, and kitchen journal. The cook reports starts and completions, requests a serving time through the companion panel, and accepts a proposed recovery plan. A due timer prompts a check; completing a step requires the cook's confirmation.
The recorded example starts at 18:35 with vegetables roasting. After advancing the demo clock by twelve minutes, the cook asks to serve at 19:00. Keeping warm bread gives an estimated finish of 19:07. Serving the ready-to-eat bread at room temperature changes that estimate to 18:59 by omitting its unstarted warming step. The vegetables keep roasting.
After accepting that choice, the cook confirms the salad, bread, vegetables, and plating in sequence. The sample reaches four completed steps at 18:59. Refreshing midway preserves the accepted plan and confirmed progress. The journal shows the meal's history, and the inspection panel exposes the actual MCP tool records.
These times belong to a fixed, simulated meal. The cook remains responsible for judging physical progress and food readiness.
How we built it
The TypeScript domain layer models step dependencies, duration estimates, and exclusive access to one cook, one oven, and one hob. Recovery proposals carry a state version. Accepting a proposal rechecks that version and the current clock before committing a change. Serialized, atomic writes persist the kitchen state, including retry records.
A Node.js and Express server exposes eight tools through the official MCP TypeScript SDK 1.30.0. The browser gateway uses the SDK client over Streamable HTTP; runtime checks negotiated protocol 2025-11-25. Cooking state persists across transport sessions. The interface and tool responses use the same underlying kitchen model.
The React interface uses shared Radix primitives, Lucide icons, local fonts, and centralized design tokens. It presents an Alexa+ experience simulator with a deterministic local command guide. Text and buttons drive the recorded flow; this build has no connected LLM or real Alexa device.
Challenges we ran into
The hardest state-model decision involved overdue work. A timer can expire while the cook is away, but the application has no basis for marking the food finished. The implementation keeps that step running and asks for confirmation. Recovery also has to preserve work already underway, even when a deadline becomes impossible.
Lost replies created another case to handle. A server can process an action before the browser loses the response. During QA, the browser harness dropped processed action and chat replies, then retried the original requests. Retaining their identifiers kept a twelve-minute clock advance from applying twice.
Mobile inspection also exposed a narrow companion composer. Adjusting its layout and checking the rendered geometry resolved that specific issue.
Accomplishments
The local build passed 44 automated tests, TypeScript checking, and the production build. Six browser regression groups exercised recovery, reload persistence, explicit completion, lost-reply retries, dialog behavior, mute handling, and narrow-screen layout. An independent clean source-copy installation also passed its build and production HTTP/MCP checks.
The 147.760-second demonstration records actual interactions through dinner completion, the journal, and a report_step tool record. It includes English captions. Together with the protocol output and source digests, the recording gives reviewers a concrete path from a serving-time request to accepted changes and confirmed progress.
What we learned
The implementation needs a clear distinction between an estimate, a proposal, and a reported fact. Keeping those separate makes stale-plan rejection and interruption recovery easier to reason about. It also gives the cook a specific choice: which unstarted part of the meal is worth changing.
Protocol integration needs execution evidence. Comparing the SDK's supported-version and default-version constants led to an acceptance check for the negotiated protocol, followed by tool discovery and invocation. That check made the chosen SDK and transport configuration inspectable.
What's next
The next step is a small study with home cooks. No real user study has run yet. Planned tasks will examine whether participants can resume after an interruption, understand the tradeoff, and distinguish an estimate from confirmed completion.
Those observations should guide changes to the recovery wording and menu model. Further work includes evaluating a real compatible assistant connection and assessing the access control and concurrency needed for multiple kitchens. The current prototype supports one local kitchen with fixed sample menus.
Log in or sign up for Devpost to join the conversation.