This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange. 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, 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.
Open Runbook Repair Lab. No login required. 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.
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.
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.
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.
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.
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.
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.
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:
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.
ipp6nys2
production (public)
The schema gives each type a specific role:
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 interaction is a browser-local experiment layer over published content.
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.