Fliproom: a room changeover is a content problem

Sanity Challenge participant Path Two presents Fliproom, a tool that transforms a room changeover into a structured, visual checklist. Users select the current layout and the desired next layout, and the interface highlights what remains stationary, what shifts position, and what moves to storage. The demo showcases a fictional community hall called The Commons, featuring a 12-by-8-meter space with eight pieces of equipment and three distinct configurations - Workshop, Presentation, and Open floor.

This application, not based on real venues or customers, uses numbered furniture on a floor plan, before/after views, and a move list linked to the same equipment. Dependencies ensure a step remains locked until its destination is cleared. In cases where two items swap places, a temporary parking step can be introduced. Completing the checklist results in checkmarks persisting even after a browser reload; switching layouts initiates a fresh list.

Users can download the instructions as a text file for offline use. Fliproom is a compact planning aid focused on rectangular footprints and room boundaries, ignoring carrying routes, lifting arrangements, or venue safety. It presumes external storage availability when in-room parking becomes impractical, and the time estimates are fixed per equipment operation rather than based on actual measurements.

The demo, accessible at Demo Public application: Try Fliproom, begins with Workshop and progresses to Presentation. Users can compare floor views, examine the numbered moves, and validate prerequisites for blocked steps. They have the option to revert a prerequisite and observe the dependent checkmark disappearing. Alternatively, the user can switch to the Open floor layout to generate a new plan.

No login is required to access the demo, which successfully loaded published Sanity content and displayed a functional plan without any browser errors. Local checks confirmed that the downloaded seven-move checklist did not exceed horizontal space at a 390px viewport. The Fliproom application, built using MIT-licensed Next.js, TypeScript, React, and Sanity, relies on GitHub Pages for hosting the public planner.

It does not make model calls during runtime. All development occurred within the Build Process Codex environment, with AI agents responsible for designing and writing the implementation, reviewing the code, running tests, and drafting this post. My role was limited to account signup/sign-in and approval of the project, fictional content import, source release, and demo publication.

The technical work and checks were performed by the agents. The primary objective was to create a practical application whose functionality relies on structured content. The approach involved deriving moves from layouts instead of creating a separate set of instructions for each layout. Every equipment item possesses its dimensions, and every layout references this information.

The planner compares placements and generates instructions based on this shared model. The project was divided among the interface, planning engine, and Sanity integration, with another agent overseeing the results. Three critical issues were identified during the review process. First, a move from 90° back to 0° initially omitted the target orientation in its text description.

The floor diagram could be accurate, while the printed instructions might be incomplete. Move labels now indicate the absolute target orientation, and a regression test validates this transition. Second, subtitles were optional in Studio but required by the read validator. Omitting a subtitle could potentially break an otherwise valid catalog.

The GROQ projection now converts an omitted subtitle into empty text, and a test evaluates the actual query against the seed documents instead of relying on a separate approximation. Third, authenticated success could mask public-access failures. Studio imported 12 documents and verified 12 exact matches upon rereading, but an anonymous count returned zero.

The generator now produces hyphenated IDs, accompanied by a regression test. After reimport, a separate unauthenticated check confirmed that both the raw documents and the resolved GROQ catalog matched the original seed documents, including both public and private paths. The authenticated receipt and public-read checks served different purposes and were essential.

The local suite passed 21 tests, and typechecking also passed. The tests simulated all nine sample-layout transitions, evaluated collisions and final positions, and tested parking, rotation, invalid inputs, dependent undo, and GROQ reference resolution. Production and static-export builds were successful. Browser tests with live Sanity content confirmed that saved progress persisted after reload, prerequisites unlocked step 6, and undoing a prerequisite cleared and disabled the step.

No console errors or warnings were reported during this check. The entire application content and this writeup remain confined within this build. The project details include the project name "fliproom" (i5bjg9lg), dataset "production," publicly readable. The content model separates rooms, equipment, and layouts, with placements referencing equipment and storing coordinates and orientation, while layouts reference their room.

GROQ resolves these relationships to provide input for the planner. Tests reject unresolved references and equipment not belonging to the correct room. The Sanity Studio runs locally for authenticated editing, and the GitHub Pages demo exposes only the public planner. Invalid published content triggers a catalog error instead of silently substituting demonstration data.

Checklist progress remains in the visitor's browser and does not write completed work to Sanity. The application does not utilize the App SDK or Sanity Workflows.