Runbook Repair Lab: Fixing Fictional Runbooks with Next.js and Sanity

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange.

What I Built

Runbook Repair Lab is a Next.js app for exploring the hidden assumptions behind a technical guide. Pick a fictional runbook, change its prerequisites or tool versions, and see which steps stop working and why.

The library contains three deliberately odd projects: build a paper town, light a lantern garden, and stitch a pocket atlas. Their tools and commands are fictional. Commands are display text; the app never executes them.

Sanity stores the guides, tool releases, prerequisite relationships, and persisted repair proposals with approval/rejection decisions. A deterministic TypeScript checker evaluates them in order. OpenAI Codex designed and implemented the app. There are no AI calls at runtime. This article was also AI-written from the source, build log, and verification evidence.

Demo

Open Runbook Repair Lab. No login required.

1. Open Build a paper town. Its starting conditions produce seven findings. Use Reset experiment if you have visited before.
2. Mark Toy workspace and Paper-town blueprint available, then select Grove CLI v2 and Loom Engine v2. The three enabled steps should pass. Try compatible conditions applies a valid combination automatically.
3. Disable Prepare the town scene. The next step loses its town-scene input, and the final step loses the preview that a successful render would have produced.
4. Re-enable the step, switch guides, and refresh. Each guide keeps its own browser-local experiment. Reset restores its original starting conditions.

These screenshots show the verified local export built from real Sanity content. Experiments stay in local storage and never modify Sanity. If storage is blocked, the app still works during the visit and explains the limitation.

The public frontend is a static, build-time Sanity snapshot. Its footer displays the snapshot time in UTC. Content edits require rebuilding and redeploying.

Code

MIT-licensed GitHub repository · Build log · Verification record

The repository includes the Next.js/React/TypeScript frontend, separate Sanity Studio configuration, schemas, fictional seed content, checker tests, and browser tests. Codex is credited in the README.

My Build Process

The build used OpenAI Codex on October 3, 2026. This is a factual account of implementation decisions and corrections, rather than a reconstructed prompt transcript.

Keep the model small enough to explain

The scope was ordered steps, declared inputs and outputs, and inclusive major-version ranges. A missing workspace maps to a prerequisite; an unavailable preview maps to an earlier step; a version conflict maps to a tool reference and supported interval.

Outputs become available only after an enabled step passes every check. A failed or skipped step cannot manufacture an output, and a later step cannot satisfy an earlier requirement. This makes downstream failures visible rather than hiding them behind a single pass/fail badge.

Make suggested repairs obey the same rules

Compatible conditions supplies the guide's declared prerequisites, re-enables steps, and selects published tool releases satisfying every relevant interval. It does not invent releases or rewrite content. Conflicting intervals or capabilities with no producer remain findings that require an author correction.

Fix stale experiments across referenced content changes

Review found that checking only the guide revision missed edits to referenced tool and prerequisite documents. The correction was a fingerprint of the complete resolved content, with regression coverage. After a new deployment includes changed content, outdated saved experiments return to baseline. Invalid or corrupt stored state does too.

Be honest about static freshness

The app became a Next.js static export. Review then exposed a persistent fetch-cache risk: a rebuild must really retrieve current published content. The final build uses a server-only native HTTPS read, with an eight-second timeout and one-megabyte response limit. Invalid or unavailable data fails the build instead of silently substituting sample content.

The tradeoff is displayed in the interface: content updates appear after a rebuild, rather than arriving live in an open browser. No runtime token, AI key, SSR worker, or CORS change is required.

Verify actual content, not just fixtures

Early browser checks used explicitly labeled synthetic fixtures. The final suite ran against an export from the real public dataset and verified actual Sanity document IDs.

The verification record includes:

• 20 passing deterministic unit tests, including version boundaries, failed/skipped producers, conflicting intervals, and stale/corrupt storage
• Passing frontend lint and TypeScript checks, plus Studio typechecking
• Public-backend baseline findings of 7, 7, and 6, reduced to 0, 0, and 0 using compatible conditions
• Six passing real-data browser workflow groups covering repair, reset, reload, guide isolation, blocked/corrupt storage, and responsive layouts at 1400, 768, 390, and 320 pixels
• Zero browser page errors in that suite, plus inspected desktop/mobile screenshots
• Source and browser-export secret-pattern checks before publication

Mobile review also led to larger touch targets, clearer explanation text, and experiment controls appearing before steps on narrow screens. The cloud deployment needed reduced build concurrency; that affected build resource usage, not the checking rules.

The app stays within its tested scope: modeled capabilities and major-version intervals. It does not parse command syntax, infer semantic-version compatibility, or establish whether real-world instructions are safe or correct.

From a local repair to an approved Sanity record

The October 3 upgrade adds a genuine proposal → review → approved/rejected process in a custom Repair review Studio tool. A proposal stores a guide reference, the complete modeled-content fingerprint, prerequisite selections, tool references and versions, and its review state.

The owner signs into Sanity normally. Approval validates the repair, then commits the decision together with source and proposal revision guards in one atomic transaction. A changed dependency or an already-decided proposal cannot silently receive an outdated approval. No server write key or anonymous mutation endpoint was added.

This was tested against the real dataset: Build a paper town has an approved proposal; Light a lantern garden has a rejected one. Both were created and decided through the authenticated Studio UI. Two deliberately stale transactions returned 409 with the relevant document revisions unchanged; an anonymous write returned 403. The existing project permissions protect writes. A trusted administrator or other member already granted write access can still use the API directly; this is not a claim of server-enforced per-document owner-only permissions.

Public builds independently validate approved proposals and exclude pending, rejected, stale or malformed repairs. Open paper town and click Try owner-approved repair: the saved conditions pass all three steps. Reset returns to baseline. The rejected garden proposal does not get that action. Public visitors cannot approve proposals or change Sanity data. Review decisions appear in the public app after rebuilding; it remains an explicitly labeled snapshot.

These screenshots show the verified local build from the actual reviewed Sanity records. Workflow design, live verification and public decisions query · Machine-readable verification evidence. The full test suite, builds, lint, typechecking, six browser groups and secret checks passed after the upgrade.

Sanity Project Details

• Project: Runbook Repair Lab
• Project ID: ipp6nys2
• Dataset: production (public)
• Content: 12 fictional documents: three tools, four prerequisites, three guides, and two reviewed repair proposals

The schema gives each type a specific role:

• repairProposal links a proposed repair to its guide, content fingerprint, chosen conditions and explicit review decision.
• tool lists published fictional major releases.
• prerequisite describes a starting capability, such as a workspace or color palette.
• guide references those documents and contains ordered steps. Steps declare needs, gives, an inert command example, and tool requirements with inclusive min/max versions.

A GROQ projection resolves references into the checker's input and excludes draft guides. Build-time validation checks the response before export.

For example, the paper-town guide starts with Grove CLI v1 and Loom Engine v4, while its steps require releases in the v2–v3 interval. Because the mismatch is structured content, the interface can explain both the selected release and allowed range without interpreting prose.

This version uses schemas, references, GROQ, and a separate Studio configuration. It does not use App SDK, Workflows, Context MCP, or a runtime agent. The custom interactions are a browser-local experiment layer and an authenticated Studio review tool. This is a custom workflow, not the native Sanity Workflows product.

Agent Session

No raw agent session is public. The sanitized build log, verification record, and source document decisions, failures, corrections, and checks without publishing private conversations or credentials.