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

The paper town starts with seven findings: missing prerequisites, incompatible tools, and downstream steps waiting for outputs that never appeared. A saved repair marks the prerequisites available and selects compatible releases. All three steps pass, and the original guide stays intact.

Runbook Repair Lab is a Next.js app for exploring those dependencies. Its three fictional projects are Build a paper town, Light a lantern garden, and Stitch a pocket atlas. Change their prerequisites, tool versions, or enabled steps to see what breaks and why. Every command is display text; nothing executes.

Sanity stores the guides and their relationships, plus repair proposals with explicit approval or rejection decisions. A custom Repair review Studio tool records those decisions. The public app can load a validated, approved repair into a visitor's local experiment.

OpenAI Codex designed and implemented the app. The checker is deterministic TypeScript, with no AI calls at runtime. This is a Fully Autonomous entry; the article was also AI-written from the source, build log, and verification evidence.

Demo

Open Runbook Repair Lab. No login required.

Try the persisted repair

1. Open Build a paper town and choose Reset experiment. You should see seven findings.
2. Choose Try owner-approved repair. It loads the saved Sanity proposal's conditions: Toy workspace and Paper-town blueprint available, Grove CLI v2, Loom Engine v2, and all three steps enabled. The result is three passing steps and zero findings.
3. Disable Prepare the town scene. The preview step loses its town-scene input, and the final step loses town-preview. Re-enable the step or reset to explore again.
4. Open Light a lantern garden. Its proposal was rejected, so it has no owner-approved repair action. Try compatible conditions still lets you explore a locally calculated repair.

How a proposal reaches that button

The custom Studio workflow is create a pending proposal → approve or reject → rebuild the public snapshot:

1. Propose. Studio calculates compatible conditions and stores a repairProposal linked to the guide. The document includes selected prerequisites, tool references and versions, enabled-step state, and a fingerprint of the complete modeled content.
2. Decide. Approval checks that the proposal still matches the guide and its referenced content, then verifies that every step passes. Source and proposal revision guards commit with the decision in one atomic transaction. Rejection records the rejected state without changing the guide.
3. Read back. Real Sanity records show paper town moving from pending to approved, and lantern garden moving from pending to rejected. The garden proposal had compatible conditions; its rejection demonstrates that compatibility alone does not put a repair in the approved set. The published evidence does not record a rejection rationale.
4. Build. The public build independently validates approved proposals. Pending, rejected, stale, and malformed proposals are excluded. The included paper-town repair becomes an optional button that only changes the visitor's local experiment.

Who performed the decisions: after I signed into Studio and authorized the work, the assistant created and decided both proposals using Windows UIAutomation confined to the authenticated Studio window. The UI label “owner-approved” refers to that approved record. This demonstration does not establish independent human review of the repair.

Workflow implementation and live verification · Exact proposal IDs and machine-readable evidence

These screenshots show the verified local export built from the actual reviewed Sanity records. The deployed app is also a static, build-time Sanity snapshot, with its snapshot time displayed in UTC. Sanity content edits and review decisions require rebuilding and redeploying before visitors see them.

Experiments are separate browser-local state. Each guide remembers its own conditions across refreshes; reset restores the published baseline. If storage is blocked, the app works for the visit and explains the limitation. Public visitors cannot approve proposals or write to Sanity.

Code

MIT-licensed GitHub repository · Build log · Verification record

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

The workflow is easiest to inspect in the Studio review tool, shared proposal validation and decision guards, and approved-repair build query.

My Build Process

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

Make each finding traceable

The model uses ordered steps, declared inputs and outputs, and inclusive major-version ranges. An output becomes available only after an enabled step passes every check. Failed or skipped steps cannot supply outputs, and a later step cannot satisfy an earlier requirement.

For paper town, Prepare the town scene needs workspace and blueprint, plus Grove CLI v2–v3. It produces town-scene. The next step consumes that capability and produces town-preview; the final step consumes the preview. The seven initial findings follow from two missing starting capabilities, three version conflicts, and two unavailable downstream outputs.

Try compatible conditions supplies declared prerequisites, re-enables steps, and chooses published releases that satisfy every relevant interval. It cannot invent releases, resolve conflicting intervals, or create a capability with no producer. Those problems remain findings requiring an author correction.

Invalidate repairs when their dependencies change

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 rebuild includes changed content, outdated saved experiments return to baseline. Invalid or corrupt stored experiments do too.

The persisted workflow uses that same modeled-content fingerprint. Approval also guards the current revisions of the proposal and its dependencies, so a concurrent edit cannot silently receive an outdated approval. The transaction's dependency writes update guard metadata, leaving guide instructions, defaults, and tool releases unchanged.

Two deliberately stale live transactions returned 409. Direct reads confirmed unchanged source and proposal revisions, including rollback when a later revision check failed. A valid anonymous same-value write attempt returned 403.

Studio uses its normal signed-in client; no server write key or anonymous mutation endpoint was added. Existing project permissions protect writes. Administrators and other members already granted write access can still use the API directly, so these client-side checks are not server-enforced, per-document owner-only permissions.

Make snapshot freshness explicit

The Next.js frontend exports statically. Review exposed a persistent fetch-cache risk, so each build now reads current published Sanity data through server-only native HTTPS, with an eight-second timeout and one-megabyte response limit. Invalid or unavailable data fails the build instead of silently substituting sample content.

This deployment needs no runtime token, AI key, SSR worker, or CORS change. Its deliberate tradeoff is a rebuild after content changes. Reduced cloud-build concurrency addressed resource usage without changing the checking rules.

Verify real data and browser behavior

Early checks used explicitly labeled synthetic fixtures. Final verification used the actual public dataset and its real document IDs. The completed workflow extension records:

• 20 passing deterministic unit tests, including version boundaries, skipped/failed producers, conflicting intervals, stale/corrupt storage, proposal validation, and revision guards
• Passing frontend lint and TypeScript checks, Studio typechecking, and production builds
• Baseline findings of 7, 7, and 6, reduced to 0, 0, and 0 with compatible conditions
• Six passing real-data browser workflow groups in the original verification, covering repair, reset, reload, guide isolation, and blocked/corrupt storage; stricter approval assertions were added later
• Responsive checks at 1400, 768, 390, and 320 pixels, zero browser page errors, and inspected desktop/mobile screenshots
• Source and exported-browser-asset secret-pattern checks before publication

October 4 regression update: review found that the earlier six-group suite allowed a missing approved action and did not assert garden exclusion; a separate screenshot/check script had supplied the latter evidence. The strengthened suite now requires exactly one paper-town approved action that yields three passing steps and zero findings, with reset restoring findings, plus no approved action for the rejected lantern garden or proposal-free pocket atlas. A fresh local build and the existing hosted demo each passed seven groups with zero uncaught JavaScript page exceptions. Three deliberately wrong action-count expectations were correctly rejected on each target. All 20 unit tests, lint, a fresh Next.js build, and Studio typecheck passed. Production code and schemas were unchanged; no redeploy or new Studio decision was needed. Pinned regression evidence.

Mobile inspection led to larger touch targets, clearer explanations, and experiment controls appearing before steps on narrow screens.

The checker covers 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.

Sanity Project Details

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

The relationships carry the checking rules:

• A tool lists published fictional major releases. Guide defaults and step requirements reference the same tool documents.
• A prerequisite describes a starting capability. For example, the Toy workspace document supplies workspace; guides reference it rather than duplicating its definition.
• A guide references prerequisites and tools, and contains ordered steps with needs, gives, inert command examples, and inclusive min/max tool versions.
• A repairProposal references its guide and selected tools, stores prerequisite IDs and conditions, and carries a content fingerprint, status, and timestamps. It preserves the decision separately from the guide's published starting conditions.

A GROQ projection resolves the guide references into the checker's input and excludes draft guides. Build-time validation checks that response before export. Because a repair is tied to the resolved content, changing a referenced release list or prerequisite can invalidate it even when the guide document itself is unchanged.

This version uses Sanity schemas, references, GROQ, and a custom Studio tool. It does not use App SDK, native Sanity Workflows, Context MCP, or a runtime agent. The public frontend has no real-time content subscription.

Agent Session

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

This revision incorporated review feedback from OpenAI Astra, Claude Opus 5.5 High, and Claude Sonnet 5.5 High. Implementation remains credited to OpenAI Codex. The Claude reviews did not provide live browser verification.