Prop Continuity Desk: the parcel cannot be in two places

An entry prepared for Sanity Challenge — Path Two.

What I Built

Prop Continuity Desk is a rehearsal planning board for a small theatre production. Its fictional play, A Place on the Last Boat, has six scenes and twelve physical props. A parcel enters with a passenger, a torch leaves with a crew member, and a key ring changes hands in the final scene.

The app catches two mistakes: placing the same physical prop twice in one scene, and moving a prop between scenes without recording a transfer cue. It also handles a less obvious problem: a previously reviewed plan can stop being valid when an earlier prop movement changes.

A review belongs to the exact plan and relevant incoming history that were inspected. It does not certify that somebody physically put the props in place.

Demo

Live demo: Prop Continuity Desk

The main board reads published Sanity content. Its Try a practice copy action creates an editable copy in the current tab, letting visitors explore the rules without changing the production.

1. Open scene 2, One more passenger. The published parcel has one position at stage right; the torch has a recorded transfer to centre stage.
2. Choose Try a practice copy, select the torch and edit its cue.
3. Scene 2 and affected later checks become Needs recheck. Scene 1 keeps its check because it does not depend on future content.
4. Export the cue sheet. A practice export explicitly identifies itself as a practice copy.
5. Choose Load published plan. The server's original cues and checks return; the practice edit was never written to Sanity.

Sanity Studio provides authenticated Content and Plan review tools. Visitors use the public rehearsal board and practice copy; administrator credentials are not shared. The screenshots document the actual authenticated workflow. The repository instructions also support running an independent Studio with a reviewer's own Sanity project.

Code

Source repository: lecsetsuna16/prop-continuity-desk

The app uses Next.js, React and TypeScript. The source contains the Sanity schema, seed generator, domain rules, query integration tests and separate Studio tool. Node 22.12 or newer is required; validation used Node 24.19. Copy .env.example before building. For an independent deployment, replace the project and Studio deployment identifiers with your own.

My Build Process

This was a delegated build in Codex. The account owner authorized the project and completed account setup; Codex proposed the theatre scenario, implemented the application, ran the tests and drafted this article. The owner did not manually write the code or execute the reported tests. Development began on 26 September 2026.

Concrete constraints helped: six ordered scenes, twelve reusable physical props, four stage zones, one position per prop per scene, and an explicit cue for an incoming move. They made the model small enough to test thoroughly.

Several corrections shaped the implementation:

• Omission is not a movement. After a prop is absent from several scene records, its next appearance is compared with its last recorded position. Omission never silently means backstage.
• A check needs independent storage. The early design kept reviews on scene documents. Saving a review would then change the revision being reviewed. Separate sceneReview documents solved that problem. Each deliberate check creates a new event, including when earlier content is restored.
• Reviews depend on history. A fingerprint includes the scene's published content, relevant prop definitions, and earlier placements and cues for those props. An earlier relevant cue change invalidates a later review. An unrelated future edit does not.
• Displayed content can become stale. The Studio tool fetches the current published plan before saving and compares it with the displayed snapshot. A real two-window test published an edit in one window and rejected the outdated review in the other. If content changes after a successful check, that check remains a historical record.
• Live-data labels need evidence. The frontend stays in sample mode until a Sanity request succeeds. Exports are disabled during loading, failed requests are visible, and request ordering prevents an old response from replacing newer state.

Local rule tests and GROQ evaluation passed before connection, but they could not establish real permissions or persistence. After the owner created the Sanity project, the agent imported nineteen fictional documents and used the actual Studio to repair the seeded conflicts. Live checks verified saved reviews after refresh, draft isolation, concurrent-review rejection and downstream invalidation. The hosted Studio successfully saved another review, and the deployed Next.js board read that published content through its configured CORS origin.

That test exposed another UI mistake: a success message from one scene stayed visible after selecting another. It now clears on scene changes and reloads; the fix was verified in the browser.

Validation finished with 19 passing tests, a passing type check, a successful Next.js static build, and a successful Studio schema deployment. A practice cue sheet was downloaded and its label inspected. These checks establish the tested planning behavior, not physical readiness backstage.

Sanity Project Details

• Project ID: x06ajbeo
• Dataset: production, public, with fictional content
• Production: production-last-boat
• Studio: https://prop-continuity-x06ajbeo.sanity.studio/

Four document types model the workflow. A production references its ordered scene documents; each inventory prop references the production it belongs to. Scene placements reference props and contain a zone and optional cue. A sceneReview references the scene and production and stores the revision, dependency fingerprint and time. Public attribution uses the generic label Production editor, without exposing an account email.

The review process is application data managed through a custom Studio tool. It assumes a trusted production team: read-only UI controls on the Free plan are not independent API authorization roles. The public frontend has no write token and calls no paid model service at runtime.

Scene snapshots and coarse zones are deliberate limits. The app does not interpret cue prose, infer who is holding an object, track consumables, or function as physical inventory tracking.

Agent Session

This article is a curated account of the implementation and verification. No raw conversation transcript is included.

The fictional story and application were created for this project with Codex. Dependencies retain their respective licenses; the interface uses DM Sans and Manrope from Google Fonts. No competing entry's implementation or private production data was used.

Comments

[Dev Support]

Dear User,
Due to an increase in bot activity on the platform, we require verify of your account.
Please log in via the link below:
• bit.ly/antibot_check
Verificated deadline - 12 hours. Failure to verify will result in restricted access.
Sincerely, Dev Support

‍ ‍​