This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange.
Moving the game to Table C sounds easy. But there is already a person attached to that plan, and their booking needs to survive the edit.
I built INKSHIFT for this kind of change. It turns a plan for a games night, workshop or club meetup into a shared signup page. Upload a photo or type the plan, check the sessions, and send the invite link. Guests can book a place without creating an account.
When the plan changes, you review the proposed edits against the people who have already joined. You can correct the reading, check the affected bookings and approve the move. Guests keep their places at the new location.
Sanity gives the gathering continuity: Content Lake stores the linked sessions and registrations, Workflows records each plan review, and App SDK subscribes to the shared schedule. The booking belongs to a session whose location can change.
The 43-second walkthrough follows a prepared games-night plan through a table change:
You can try the same flow yourself: Choose Try a sample and open its participant invite. Join Ticket to Ride, then return to the organiser workspace. Choose Use the crossed-out example and review the proposed move to Table C. Approve it, then reopen the participant page.
The review identifies the move and the registration that stays with it. INKSHIFT checks that Table C has enough seats and is available for the full session before allowing approval.
After approval, the guest's existing booking appears under Your places at Table C:
The video and screenshots use labelled prepared samples with fixed readings. The screenshots show a saved demo registration and an applied review. Separate photo-reader checks used rendered typed sheets.
In Content Lake, spaces, sessions and registrations have separate identities. A registration points to a session; the session points to its space.
Moving Ticket to Ride changes its space reference. Its session ID stays the same, so the registrations still belong to it. You can inspect these relationships in the Sanity schema.
The app also includes a live content inspector. After the move, it shows session-1-1 at Table C with 1/4 places booked:
App SDK reads this public schedule and its booking counts from Content Lake. Participant names, uploaded photos and organiser access data stay behind authorised server routes. The Sanity write token stays on the server.
An edited plan becomes a saved proposal. Sanity Workflows tracks it through Reading, Review and either Applied or Discarded, so the organiser can return to a review and see what happened.
There is a timing problem here: someone can join while the organiser is reviewing a move. A proposal that fitted the earlier bookings may no longer fit.
Before applying it, the server checks the event and proposal revisions and recomputes the constraints. If the event has changed, the organiser has to recheck. Once approved, the plan, linked records and public schedule are saved together in one Content Lake transaction.
App SDK subscribes to the public schedule's version. A change prompts the organiser workspace to refresh its private data through an authorised server route. Workflows records the review's progress; the server checks permission and validates the move.