AllAtOnce — the dinner conductor

Alexa+ doesn't just time dinner — it lands it.

Tell Alexa+ who's eating, what's cooking, and when you want to sit down. AllAtOnce builds the plan backwards from serve time, gives every cook their next job, tracks progress by voice — and when the chicken runs late, it re-plans the whole landing instead of letting three dishes die waiting.

Alexa already does timers. Timers don't re-plan dinner when the chicken's late.

Built for the Alexa+ track of Build, Ship, Shape: Amazon Developer Hackathon (Devpost). Self-hosted MCP server, MCP spec 2025-11-25, Streamable HTTP, official Python MCP SDK.

The demo scenario (one dinner, ~3 minutes)

"Alexa, we're four for dinner at seven — roast chicken, garlic mash, green beans, and Maya's doing her gravy. Land it all at seven."

1. plan_dinner backward-schedules all four dishes to 7:00, reading household memory (Maya always does the gravy; chicken rests 10 minutes in this house). The Echo Show board appears: dish bars converging on one SERVE line.

2. Cooks check in by voice (get_cook_brief, complete_step). Maya finishes the mash and gets her next job.

3. The payoff: "Alexa, the chicken's running fifteen behind." report_delay → replan_dinner re-solves the landing: the chicken finishes at high heat and rests 7 instead of 10, tonight's guest Alex gets a job helping carve, the gravy moves from Maya to Dad and is served straight from the pan, the mash goes on hold and is rewhipped at the last call, and the beans switch to a single pan so Sam can set the table. Alexa+ reads the trade-off out loud and asks for a yes. Dinner lands at 7:01 — one honest minute past seven, instead of 7:15 with no re-plan.

Full script: DEMO-SCRIPT.md. Full test run: test-output.txt.

Related MCP server: Aura+

How the re-plan actually works

This is a real recomputation, not a timer offset:

• Backward planning. Each dish is a step graph (durations, dependencies, cook assignments, active/passive steps, minimum compressible durations, freshness windows). Dishes are scheduled backwards from serve time; cross-dish dependencies are honoured — gravy cannot start before the chicken roast releases its drippings, and if a dependency pushes a dish late, the slip is reported, never hidden.

• Forward repair. A delay is reported mid-cook, so the delayed dish is re-scheduled forward from its real start (a backward-only planner would cheat by quietly moving the start earlier). Recovery actions apply in order: a high-heat finish recovers a modelled fraction of the slip, the rest trims to its minimum, carving is parallelised with a helper. Whatever cannot be absorbed becomes an honest slip — tell it the chicken is 30 minutes behind and AllAtOnce will tell you dinner lands at 7:16, not pretend otherwise (this is unit-tested).

• Cascade. Dependent dishes follow their inputs (gravy follows the drippings, compresses, and is served from the pan), flexible dishes extend their holds (the mash), and constrained dishes change method (the beans go single-pan). Cook conflicts are re-validated after every re-plan.

• Household memory. household.json holds remembered facts — who does the gravy, how long the chicken rests, who usually sets the table. plan_dinner genuinely reads them (change the rest to 12 in memory and the chicken starts 2 minutes earlier — also unit-tested), and every landing is written back as plan-vs-actual.

Tools (MCP)

Plus plain HTTP on the same app: GET /board (the Echo Show board), GET /status (the board's JSON), GET /health.

Run it locally

python3 -m venv .venv
.venv/bin/pip install -r requirements.txt
.venv/bin/python server.py            # MCP at http://127.0.0.1:8000/mcp
                                      # board at http://127.0.0.1:8000/board
PORT=9000 .venv/bin/python server.py  # hosting platforms set $PORT

Test it:

.venv/bin/python test_schedule.py     # pure-logic engine tests (no server)
.venv/bin/python test_client.py       # full demo arc over Streamable HTTP
                                      # (start the server first, in another
                                      #  terminal; set MCP_URL to test a
                                      #  deployed instance instead)

Latest recorded run: 91 checks, ALL PASS (56 engine/robustness + 35 end-to-end) — see test-output.txt. The robustness tests cover judge-style poking: no-plan calls, unknown dishes/cooks/ steps, malformed times, out-of-range delays, and re-planning the same delay twice all return spoken-style errors, never a crash.

Layout

server.py        MCP wiring (6 tools) + /board, /status, /health routes
schedule.py      scheduling + re-planning engine (pure logic, tested)
household.json   household memory seed (facts the planner reads)
board.html       the Echo Show board (polls /status)
test_client.py   end-to-end MCP client driving the full demo arc
test_schedule.py unit tests for the engine, incl. honest-slip cases
project-image.png screenshot of the real board after the demo re-plan
AUDIT.md         end-to-end submission audit (2026-10-19)
state.json       runtime state (generated; gitignored)

Honest limitations

• The recipe set is a small curated set of step graphs — by design. AllAtOnce is bring-your-own dishes: the step graph is the data model, not a recipe catalogue. Adding a dish means adding its steps, not scraping a cookbook site.

• There is no entrant-facing live Alexa+ test harness we could verify, so the demo path is a real MCP client (the test client) standing in for the Alexa+ host, plus the board a Show would render. The MCP server itself is the real thing, speaking spec 2025-11-25.

• The high-heat recovery is a modelled heuristic (recovers 60% of a slip, capped at 9 minutes) — stated in the recipe data, not hidden. Recovery strategies are authored per dish (the roast-chicken path is the fully modelled one); a delay on another dish still re-solves the timeline and reports an honest projected serve, and says when a slip can't be absorbed.

• One active dinner per server process — a second plan_dinner replaces the active dinner. Household state persists to state.json on disk.

License

MIT — see LICENSE.