{"slug": "runbook-repair-lab-fixing-fictional-runbooks-with-next-js-and-sanity", "title": "Runbook Repair Lab: Fixing Fictional Runbooks with Next.js and Sanity", "summary": "A developer built Runbook Repair Lab, a Next.js and Sanity application that lets users modify the prerequisites and tool versions of fictional technical runbooks to see which steps break and why. The app uses a deterministic TypeScript checker to evaluate ordered steps, declared inputs and outputs, and version ranges, with OpenAI Codex credited for designing and implementing it and no AI calls at runtime. The public frontend is a static build-time Sanity snapshot, and the MIT-licensed code, build log, and verification record are available on GitHub.", "body_md": "*This is a submission for the [Sanity Challenge, Path Two: Vibe-Code Something Strange](https://dev.to/challenges/sanity-2026-09-16).*\n\nRunbook 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.\n\nThe 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.\n\nSanity stores the guides, tool releases, and prerequisite relationships. 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.\n\n[Open Runbook Repair Lab](https://runbook-repair-lab.simonlevy00.chatgpt.site). No login required.\n\nThese 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.\n\nThe public frontend is a **static, build-time Sanity snapshot**. Its footer displays the snapshot time in UTC. Content edits require rebuilding and redeploying.\n\n[MIT-licensed GitHub repository](https://github.com/simon-levy01/runbook-repair-lab) · [Build log](https://github.com/simon-levy01/runbook-repair-lab/blob/main/BUILD_LOG.md) · [Verification record](https://github.com/simon-levy01/runbook-repair-lab/blob/main/VERIFICATION.md)\n\nThe 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.\n\nThe build used **OpenAI Codex** on October 3, 2026. This is a factual account of implementation decisions and corrections, rather than a reconstructed prompt transcript.\n\nThe 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.\n\nOutputs 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.\n\nCompatible 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.\n\nReview 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.\n\nThe 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.\n\nThe 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.\n\nEarly 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.\n\nThe verification record includes:\n\nMobile 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.\n\nThe 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.\n\n`ipp6nys2`\n`production` (public)\nThe schema gives each type a specific role:\n\n`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.\nA GROQ projection resolves references into the checker's input and excludes draft guides. Build-time validation checks the response before export.\n\nFor 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.\n\nThis 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 interaction is a browser-local experiment layer over published content.\n\nNo raw agent session is public. The [sanitized build log](https://github.com/simon-levy01/runbook-repair-lab/blob/main/BUILD_LOG.md), [verification record](https://github.com/simon-levy01/runbook-repair-lab/blob/main/VERIFICATION.md), and source document decisions, failures, corrections, and checks without publishing private conversations or credentials.", "url": "https://wpnews.pro/news/runbook-repair-lab-fixing-fictional-runbooks-with-next-js-and-sanity", "canonical_source": "https://dev.to/simon_levy_e0b34a39073843/runbook-repair-lab-fixing-fictional-runbooks-with-nextjs-and-sanity-4214", "published_at": "2026-10-03 14:33:29+00:00", "updated_at": "2026-10-03 14:37:51.298473+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "ai-products"], "entities": ["Runbook Repair Lab", "Sanity", "Next.js", "OpenAI Codex", "TypeScript", "GitHub", "React"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/runbook-repair-lab-fixing-fictional-runbooks-with-next-js-and-sanity", "markdown": "https://wpnews.pro/news/runbook-repair-lab-fixing-fictional-runbooks-with-next-js-and-sanity.md", "text": "https://wpnews.pro/news/runbook-repair-lab-fixing-fictional-runbooks-with-next-js-and-sanity.txt", "jsonld": "https://wpnews.pro/news/runbook-repair-lab-fixing-fictional-runbooks-with-next-js-and-sanity.jsonld"}}