Hack Night - Can Your Agent-Written Code Survive Production?

Prateek

a reboot.dev MCP App for push notified tracking NASA streaming data with push notifications

Reboot

Its a traditional seat booking system with login, and then we will try 3 failure modes: 1. Two people buying the same seat. 2. The charge goes through but email fails, does it charge twice ? 3. Network crashes mid payment. Are we blaming the user ? I have used the reboot-dev framework to build a robust system that handles these bugs on a web-app.

Reboot

An Angel agent will suggest the most naive and long repair bill, for any commercial retail space, a roof collapse or inventory damage could result in a massive REPAIR cost. The Devil's agent refutes that and says a $45 fix risks $100,000 in liability. However, a full tear-off is overkill right now. Verdict: We believe in the Judge Agent where the Judge decides to the best option of both arguments.

Reboot

Forke

FORKED — AI Decision Multiverse Explore every future. Change the assumptions. Commit the best timeline. FORKED is a Reboot dual-surface app: a standalone browser SPA you can use immediately, plus an optional MCP Chat App surface for Claude / ChatGPT / MCPJam.

Rebootfastapi

Reboot-intelligence is a production-reliability lab for shared AI compute. Instead of hardening a checkout form, we simulate a constellation of phone-class nodes that join a mesh, contribute inference, vote in council rounds, and hand off sharded work—then we deliberately break them the way production breaks real systems. Nodes are heterogeneous: different RAM, speed, thermal state, and shard eligibility. Mid-run, workers vanish, masters fail over, leases race, replies arrive late or lie with a false OK. Naive agent-written orchestration double-assigns work, trusts timeouts as failure, and loses state between “compute finished” and “receipt written.” That is the same disease as double charges and half-completed sagas—on an intelligence mesh. We build on Reboot so rounds, leases, and receipts are durable: idempotent retries, exclusive claims, epoch-fenced leadership, and crash-resume for two-phase handoffs. A space-themed MCP console makes the system legible—vote beams, shard orbits, dropouts, and fault flares—so judges see failure and recovery, not a black box. The proof is a gauntlet: inject the five classic production modes under phone churn, show what the agent missed, then show the mesh survive with effects applied once. Happy-path demos impress for a minute. Reboot-intelligence is built for the minute after everything goes wrong.

RebootPython 3.12 · uv · Reboot 1.4 · Protobuf/RBT · React 18 · Vite 6 · TypeScript · MCP Apps · OpenAI · pydantic-ai · pytest · mypy · Buf

A **transactional, crash-resilient code-refactoring workspace** built on the [Reboot](https://reboot.dev) framework, for the *"Agent Mode Failures"* hackathon. All file modifications during a multi-step refactor are staged in **Reboot durable memory** (staged buffers), never written directly to disk. The staged changes are flushed to disk **only** if validation passes, through a durable, **crash-safe, exactly-once** commit. Kill the process mid-refactor and no progress is lost, no file is half-written, and no write happens twice. The whole surface is exposed as **MCP tools** on the Reboot HTTP transport at `/mcp`, so an AI agent (Claude, ChatGPT, MCPJam, …) drives it directly. --- ## Why the method types are what they are (Reboot's rules) Reboot forbids **any external side effect** (filesystem, subprocess, network) inside a `Reader`, `Writer`, or `Transaction`, because those bodies re-execute under dev-mode *effect validation* and retries — a disk write there would fire twice, which is exactly the "duplicate write" failure this project prevents. That single rule shapes the whole design: | Tool | Reboot method | Why | |------|---------------|-----| | `get_status` | `Reader` | read-only view of staged buffers | | `create` | `Writer` (`factory=True`) | constructs one refactor session (actor) | | `stage_file_edit` | `Writer` | mutates **one** actor's durable buffers | | `abort_transaction` | `Writer` | clears staged buffers | | `validate_and_commit` | `Transaction` | **pure in-memory** syntax validation, then **schedules** the flush workflow — no disk I/O itself | | `flush_to_disk` | `Workflow` | the **only** place disk writes are legal; durable + restartable ⇒ flushes **exactly once**, even across a crash (`at_least_once`, content-idempotent) | | `simulate_crash` | `Writer` | stages then dies **before commit**, proving atomic rollback | Two deliberate reconciliations of the original spec, forced by the framework: 1. **Validation is in-memory `compile()`**, not a `py_compile`/`pytest` subprocess. Parsing the staged source strings in-process is pure and deterministic, so it's legal inside a `Transaction`. The one true side effect — writing files — is isolated in the `flush_to_disk` **Workflow**, which is what makes the commit survive a crash and run exactly once. *(Swapping in a real `pytest` run is a natural extension: run it as an `at_least_once` step inside the flush workflow, before the file writes.)* 2. **The validation-failure path returns `committed=False`** and persists the `INVALID` status, rather than raising. A Reboot abort would *roll back* the very `INVALID` marking we want to keep. One documented pragmatic shortcut: `stage_file_edit` reads a file's original contents from disk (read-only, once per path) inside a `Writer`. A strict-production build would move that capture into a workflow step; it's kept inline here for tool ergonomics and is safe for the demo (the read is deterministic across the immediate effect-validation re-run). --- ## Project layout ``` . ├── .rbtrc # line-based rbt CLI config (NOT yaml) ├── .python-version # 3.12 ├── pyproject.toml # deps (uv); reboot>=1.4.0 ├── .mypy.ini # type-check config ├── api/ │ └── refactor/v1/workspace.py # THE source of truth: state models + API() ├── backend/ │ ├── api/ # generated *_rbt.py (git-ignored) │ └── src/ │ ├── main.py # Application entry point │ ├── domain.py # FileStatus enum + pure validation/disk helpers │ ├── example_prompts.py # MCP wizard example prompts │ └── servicers/ │ └── workspace.py # WorkspaceServicer (all method impls) ├── run_demo.py # end-to-end demo (in-process, no server) └── backend/tests/workspace_test.py # per-user-story tests ``` > `schema.py` / `api.py` / `chaos.py` from the brief are consolidated here: > Reboot requires the state models **and** the `API()` in one file under > `api/` (that's `workspace.py`), the method bodies (incl. the chaos tool) in > the servicer, and the enum + pure helpers in `domain.py`. --- ## Quick start ```bash uv sync # install reboot + dev deps into .venv uv run rbt generate # generate backend/api/refactor/v1/workspace_rbt.py uv run mypy backend/ # type-check (should be clean) uv run rbt dev run # start the app ``` `rbt dev run` prints: ``` Your API is available at: http://127.0.0.1:9991 MCP clients can connect at: http://127.0.0.1:9991/mcp You can inspect your state at: http://127.0.0.1:9991/__/inspect ``` It also serves an interactive **setup wizard at http://localhost:9991** for connecting an MCP client. ### Exposed MCP tools `workspace_create`, `workspace_get_status`, `workspace_stage_file_edit`, `workspace_abort_transaction`, `workspace_validate_and_commit`, `workspace_simulate_crash`. (`flush_to_disk` is intentionally hidden — `mcp=None`.) --- ## Connecting from Claude Code This repo already registered the server (local scope): ```bash claude mcp add --transport http reboot http://localhost:9991/mcp claude mcp list # shows ✔ connected once `rbt dev run` is up ``` Then, in a Claude Code session, drive the tools with prompts like the ones in `backend/src/example_prompts.py`. > **Note:** the endpoint 307-redirects `/mcp` → `/mcp/`. Compliant MCP clients > follow it automatically. --- ## The demo ### Automated (no server needed) ```bash uv run python run_demo.py ``` Runs four scenarios in-process via the Reboot test harness and narrates each: 1. **Stage** edits across 3 dummy Python files → durable buffers, disk untouched. 2. **Crash** while staging a 4th edit (`simulate_crash mode='exception'`) → the in-flight edit is atomically discarded, the 3 prior edits survive. 3. **Failing commit** (invalid Python) → validation blocks it, buffer marked `INVALID`, disk untouched. 4. **Succeeding commit** → staged content flushed to real files via the durable workflow; `is_committed` flips true. ### Live hard-crash + restart (real durability) This proves state survives a **real process death**, using the running server: ```bash # Terminal A uv run rbt dev run ``` Then, from an MCP client (or the tools): 1. `workspace_create` with id `crash-demo` and `workspace_root=/tmp/refactor_demo`. 2. `workspace_stage_file_edit` a couple of files (each commits durably). 3. `workspace_simulate_crash` with **`mode="exit"`** → the backend process is hard-killed (`os._exit(1)`). The in-flight staged edit never commits. 4. Restart `uv run rbt dev run` (state persists via `--application-name=reboot-refactor-workspace`). 5. `workspace_get_status` on `crash-demo` → the committed edits are all there; the in-flight one is cleanly absent. **Zero lost progress, no duplicate writes.** Reset persisted state at any time: ```bash uv run rbt dev expunge --application-name=reboot-refactor-workspace ``` --- ## Tests ```bash cd backend && uv run pytest ``` One test per user story (staging, atomic crash rollback, failing validation, successful commit-to-disk), run through the real authorizers via the harness.

SearchPod

We're going to make an app that enables the user to ask questions about podcasts. They should be able to ask: 1. "What episode mentioned [Topic]?" 2. "Who was the guest when [Podcast Name] discussed [Topic]?" 3. "What did [Person] talk about?" The user should be given as precise as possible output -- if possible, include the timeframe they should listen to.

Rebootbright data API

Khotan Capital is a durable trading-agent backend on Reboot — the reliability layer behind live trading across Kalshi, Polymarket, and Alpaca. The scariest production bug for a trading agent isn't the happy path — it's crashing right after sending an order but before recording it: on restart a naive agent double-fills (double position, real money lost) or loses the position. Khotan Capital wraps every broker fill in Reboot's at_most_once, so a mid-order crash recovers to exactly one fill — no double position, no lost state. Orders persist in Reboot's durable SortedMap, and the whole backend is automatically an MCP server, so any coding agent (Claude Code / Codex) can trade through it with production-grade durability. Agent-written trading code that actually survives production.

RebootPython, MCP, durable-mcp, at_most_once durability

Fantasy football waiver wire where teams have a $100 budget to bid on available players. When claims are processed, only one team can win each player. The highest bid wins, with earlier submission breaking ties.

RebootReboot durable actors, Python backend, React and TypeScript frontend, Vite, MCP Apps, pytest, Vitest, Playwright, Docker

Autopick is a meal-selection and grocery checkout agent demonstrating production-grade retry safety. Its Failure Lab reproduces a lost-response timeout that causes duplicate charges, then proves how stable idempotency keys, a durable SQLite ledger, crash recovery, and post-purchase verification ensure exactly-once checkout.

social in prod

Social in Prod is a local-first “context firewall” for content-generating agents. It creates auditable content prompts while keeping information separated by authority: Permanent editorial policy Current human objective Human-approved style memory Reviewed trends Human-reviewed research summaries Raw research as non-authoritative evidence It supports editable policies, style rules, context weights, research approvals, deterministic conflict resolution, durable prompt history, and persisted audit events. This hackathon MVP uses mock research and creator data. It does not call an AI model, publish content, connect to social networks, or support multiple users.

RebootPython

Bet on markets while in the ChatGPT app. Reboot provides workflows so the shape of the problem is to separate the state, workers, and orchestrator. Reboot already provides the workflows/workers for me.

Reboot

Musical Chairs where every round costs coins — because nothing surfaces distributed-systems bugs like money plus a shared limited resource. Players pay 10 coins to enter, the music stops, N players scramble for N−1 chairs, winner takes the pot. Real multiplayer (each browser tab is a player) on a durable Reboot backend. The point is the built-in CHAOS LAB: one button per failure mode, each runnable against two implementations of the same app. NAIVE mode is deliberately typical REST code — charge and enroll as two separate requests, blind retries, status-code-only error handling, check-then-act chair claims. REBOOT mode is the same pressure hitting distributed transactions, UUID idempotency keys, serialized writers, and durable scheduled tasks. All five failure modes, reproduced and survived: 1. Retry that charges twice — naive: 3 retries = 3 tickets, 30 coins. Reboot: same 3 raw HTTP retries with one x-reboot-idempotency-key header → charged once, duplicates replayed in ~5ms. 2. Timeout that lied — client gives up at 600ms, retries; the "dead" charge lands 2s later → paid twice for one seat. Reboot: re-send with the same key, await the one true outcome. 3. The 200 that hid a failure — payment returns 200 {"charged": false}; naive client enrolls for free. Reboot: failures are typed aborts (NotEnoughCoins, ChairTaken) — there is no lying 200. 4. Two buyers, one chair — two concurrent check-then-sit sequences both pass the availability check → one chair, two occupants. Reboot: claim is one serialized writer; the loser gets a typed rejection. 5. Crash between charge and email — we kill -9 the server mid-join-transaction on camera. After restart: coins intact, no half-enrollment. Charge+enroll commit or roll back together; the payout is a durable scheduled transaction that fires after restart. A live LEDGER audits the books after every action (minted == wallets + pot, no unverified fees, ≤1 body per chair) and turns red with the exact damage when naive code loses, conjures, or fails to verify money.

RebootPython (pydantic API), React 19 + Vite + Tailwind, Reboot generated reactive hooks, pytest + reboot.aio.tests, Envoy, built with Claude Code

SF Appeal Prep helps San Francisco homeowners evaluate and prepare property-tax appeals. Using Reboot, I built a durable paid-report workflow that withstands duplicate webhooks, retries, races, and server crashes. Stripe payment or authenticated admin authorization enters one fulfillment path, and after injected failures the order still converges to exactly one authorization and one completed report—without duplicated work or lost state. Production Version: https://ankushagrawal.com/appeal-prep

RebootPydantic · React · TypeScript · Vite · Stripe test mode · pytest · OpenAI Codex · Python

# CurbLock SF CurbLock SF is a Reboot-powered coordination system for autonomous vehicles competing for one passenger-loading curb at Mission & 16th in San Francisco. A normal application works when everything goes right. CurbLock proves that the same correct result survives production failures. ## Reliability scenarios 1. Normal Reservation — one vehicle reserves the curb and receives one fee and one notification. 2. Lost Response + Retry — the response disappears, but retrying with the same trip ID returns the original reservation without charging twice. 3. Race Two Vehicles — FogCab and Karl request the curb concurrently, but an atomic Reboot transaction guarantees exactly one winner. 4. Crash During Workflow — the server crashes after the fee step and recovers without restarting the workflow or duplicating its effects. ## Reboot implementation - Reactive reader for the live control-room state - Writers for durable mutations - Transaction for atomic curb ownership - Durable asynchronous workflow for fee, notification, and completion - Genuine Reboot Reroute Advisor agent for the losing vehicle - Web application and MCP application - Deterministic trip IDs for idempotency - Effect validation and an actual Reboot down/up recovery test The Reroute Advisor never controls curb ownership. The transaction remains the safety authority, while the agent provides the losing vehicle with a structured alternative pickup recommendation. A deterministic fallback keeps the system safe if the model is unavailable. ## Proof The production build succeeds and all five automated reliability tests pass. Clean execution, retries, concurrency, and crash recovery converge to one reservation, one fee, and one notification. Built with Reboot, Python, Pydantic, React, TypeScript, MCP, CSS/SVG animation, Web Audio, OpenAI Codex, and a Reboot Pydantic AI agent.

RebootPython, Pydantic, React, TypeScript, MCP, OpenAI Codex, Reboot Pydantic AI Agent, CSS/SVG, Web Audio, pytest

Tempo Fitness

Tempo is a durable fitness tracker that lets people log workouts, set weekly movement goals, monitor progress, and receive personalized coaching from either a responsive web dashboard or an MCP-compatible AI client. Users can write naturally, such as “I did squats for 10 minutes,” and Tempo infers the exercise, duration, intensity, and date before recording the session atomically. A built-in catalog recognizes twenty-four activities, including running, walking, cycling, swimming, yoga, strength training, burpees, hiking, basketball, and tennis. It understands seconds, minutes, hours, combined durations, decimals, today, yesterday, ISO dates, and explicit intensity overrides such as easy, steady, or hard. Tempo is designed around failure rather than only the happy path. Its transactional backend prevents partial updates, duplicate workouts, lost progress, forged deletions, stale week resets, and cross-user access. Reactive readers update dashboards without polling. Durable coaching workflows survive application restarts and prevent older responses from overwriting newer advice. The project includes twenty-seven integration tests plus fifteen adversarial subtests covering concurrency, retries, authorization, invalid boundaries, rollback, subscriptions, inference, and crash recovery. A deterministic local coaching model keeps development fast, reproducible, and free from external API keys, while remaining easy to replace with any Pydantic AI model for production use or experimentation.

An AI agent that fulfills orders end-to-end - checks inventory, reserves stock, charges payment, and sends a confirmation - built on Reboot to survive the production failures a plain coding agent misses: retries that double-charge, timeouts that lie about success, background failures that get silently swallowed, race conditions on the last item in stock, and crashes mid-workflow. The agent (reboot.agents.pydantic_ai.Agent, running Claude Haiku 4.5) drives a 4-step tool chain - check inventory, reserve, charge, notify - inside a durable Reboot Workflow. Every step is idempotent (order-scoped reservation guards, set-once charge IDs), inventory writes are serialized per-product to close the two-buyers-one-item race, and the whole chain survives a hard process crash mid-flight and resumes exactly where it left off. Proven with 7 automated tests (idempotent charge/reserve, concurrent-order race safety, a crash-recovery test that kills the app between payment and notification and asserts exactly-once effects, an idempotency-key test for client retries, and a deliberate naive control-group test showing the exact bug the guards prevent) - plus one real, unplanned incident during testing: the live agent hit an actual OpenAI quota failure mid-order, retried indefinitely as designed instead of silently failing, and after a real process restart with a fixed key, resumed and completed with zero duplicate effects.

RebootPython, pydantic, pydantic-ai, Anthropic Claude (Haiku 4.5), React, TypeScript, Vite, MCP (Model Context Protocol), Cloudflare Tunnel

limón

Limón is a Lime-style scooter rental app rebuilt the way it should've been, on Reboot's durable state machines. Last Sunday, I had 3 failed QR scans, got charged every time, and was left stranded with no scooter. We built Limón to fix that: reactive readers power the live scooter map, transactional writers handle unlocks and payments, scheduled workflows run ride billing, and Pydantic AI agents are exposed through an MCP server. All five production failure modes (double charge, lying timeout, silent 200, race on the last scooter, mid-checkout crash) have dedicated test suites, plus a chaos script that kills the server mid-ride to prove recovery. It starts with rbt dev run and npm run dev, runs end to end, and our proof package shows exactly what our agents got wrong and how we fixed it.

RebootPydantic AI Agents, pytest, React + Vite, Python, TypeScript, MCP

Ryan T

Marketplace to purchase clothing

Reboot

TriageDesk

TriageDesk is an ER admission and on-call notification system built on Reboot, targeting three of the five production failure modes from tonight's brief: concurrent resource contention, retry-induced duplication, and crash recovery mid-workflow. Two admissions racing for the same bed: admit() is implemented as a Transaction, not a plain writer, because it has to atomically touch two separate pieces of state, the bed registry and the patient's own record. It calls BedRegistry.reserve_bed() inside the transaction. Reboot serializes every writer call on a given state ID, so two concurrent admit() calls for the same bed are forced through reserve_bed() one at a time. The first claims the bed, the second sees the committed result and returns bed_unavailable. No lock or compare-and-swap was written by us, the serialization is Reboot's default writer guarantee. Verified with a test that fires two concurrent admit() calls for the same bed and asserts exactly one succeeds. Duplicate dose entry on retry: log_dose() is a plain Writer with no deduplication logic in it. The guarantee comes from Reboot's gRPC middleware layer, which deduplicates calls carrying the same idempotency key before the Python method is invoked. Verified manually, since the guarantee lives at the transport layer, not application code. Crash between bed assignment and on-call notification: this is the one failure mode not covered by a default Reboot guarantee. notify_oncall() is a Workflow, spawned from inside the admit() transaction so it's only ever created on a successful admission. The pager call inside it is wrapped in at_least_once_per_workflow, which checkpoints the pager's return value the instant it completes. If the server crashes after that checkpoint but before the patient record is updated, the workflow resumes on restart, finds the checkpoint already recorded, and does not call the pager again. Verified with a test that simulates a mid-workflow crash by killing and restarting the server in that exact window, and asserts the pager was called exactly once. Includes a live web dashboard and a read-only MCP patient summary card that subscribes to patient status reactively through Reboot's generated hooks, no polling.

Reboot

Has a name.

It has a description.

Reboot