This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange.
What I Built
INKSHIFT lets an organiser change a meetup plan after people have signed up. A guest books Ticket to Ride at Table B. The organiser reviews a move to Table C and approves it; the original session and registration IDs stay the same, and the guest sees the new table under Your places without booking again. The paper time machine shows that booking through the saved plan versions.
Open INKSHIFT · Watch the booking move · Watch the product walkthrough · Source code
A photo or typed plan starts the process. The organiser reviews the reading, corrects uncertainty and approves the change before it reaches the live schedule. In the guided sample, keep the guest page open and inspect the existing booking after the move. After you open the saved move review, the guide shows the preserved booking and session IDs. The sample uses a fixed reading; signup, approval and Content Lake writes are real.
The paper time machine halfway between version 1 and 2: Ticket to Ride slides from Table B to Table C and its booking goes with it.
INKSHIFT 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 book a place without an account.
When the paper changes, you review the proposed edit against the people who have already joined, correct the reading if needed and approve. 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.
Demo
The 43-second walkthrough follows a prepared games-night plan through a table change:
Choose Try the guided sample. Its organiser checklist, Move the table. Keep the booking., follows the same flow:
- Open the signup page from the organiser workspace.
- 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.
Here is the organiser's review with a booking already in place:
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:
They do not need to sign up again.
The videos and screenshots use labelled prepared samples with fixed readings. Try the guided sample and Use the crossed-out example exercise real signup, review and Content Lake writes, but skip image inference. The screenshots show a saved demo registration and an applied review. Separate photo-reader checks used rendered typed sheets and one genuine handwritten schedule, described below. Physical phone-camera capture remains untested.
Scrub back through the paper
Every approved edit becomes a version. Below the live plan there is a Paper time machine: a slider over every version of the paper, with the sheet on the left and the tables on the right. Move from version 1 to version 2 and the Ticket to Ride card slides from Table B to Table C, carrying Ada's token with it. Move back and it slides home.
Each version shows when it was applied, what changed ("Ticket to Ride: Table B → Table C"), how many bookings were kept and the state of its Workflows run. Readings I discarded appear as a faded note, never as a version.
Version 1 in the sample needs no upload: choose Try the guided sample, join as a guest, apply the crossed-out example and the time machine has two versions. The rename example adds a third.
The time machine reads saved records. Plans only change when a proposal is applied, so each applied proposal's stored preview is exactly the plan it produced. The one gap was the plan before the first edit: nothing stored it. INKSHIFT now records a planBefore snapshot on the proposal at apply time. Older sample gatherings that predate the snapshot rebuild version 1 from the prepared sample definition, and the time machine labels that version Reconstructed. Bookings are placed per version from their createdAt and cancelledAt times; they always point at the same session ID, so nothing has to be guessed about where a person went.
The timeline, photos and booking initials come from an organiser-only server route. A request without the organiser cookie gets a 403, and the App SDK public schedule still carries only sessions and counts.
How Sanity keeps the booking attached
In Content Lake, spaces, sessions and registrations have separate identities. A registration points to a session; the session points to its space.
Registration → Ticket to Ride → Table B
↓ move approved
Registration → Ticket to Ride → Table C
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. Trimmed, with // ... marking skipped lines:
// inkshiftRegistration: a booking points at a session
ref("session", "inkshiftSession"),
// inkshiftSession: the session points at its current table
ref("space", "inkshiftSpace"),
// inkshiftProposal: the plan it replaced, recorded at apply time
defineField({
name: "planBefore",
type: "object",
// inkshiftEvent: private aggregate, one revision guards every write
arr("spaces", table()),
arr("sessions", session()),
arr("bookings", booking()),
// inkshiftPublicEvent: what App SDK reads anonymously
arr("spaces", [str("id"), str("label"), capacity()]),
num("booked"),
The event aggregate repeats spaces, sessions and bookings as arrays on purpose: its document revision is the single lock. Every booking and approval patches it with ifRevisionId and saves the changed linked records and public projection in the same transaction. A write against a stale revision is rejected whole with a 409: a booking retries against the new state, and a stale approval has to be rechecked.
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. Public projection IDs are hashed and contain no raw event invite IDs. The September 29 release migrated all 41 legacy public copies; anonymous checks found no old public projections or private event aggregates. The Sanity write token stays on the server.
A change has a review and a decision
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. Reader and organiser labels describe the caller context under the server credential. They do not grant permission to approve a change.
On September 30 Codex reopened the saved manual room move from the handwritten-schedule test. The hosted organiser view showed this review record:
Source: Manual plan
Progress: Reading (Organizer) → Review (Organizer) → Applied (Organizer)
Applied: 30 September, 21:03, Asia/Calcutta
Changes: add Room D; move Hybrid meeting Tips from Room B to Room D
Unresolved checks: 0
Registrations affected: 1
Applied result: 1 registration preserved
This is a transcription of the saved hosted review and timeline, captured after approval. Organizer is caller context recorded by the server, not a separate login. The change was entered manually after correcting the photograph; it is not a second photo interpretation. To inspect a run yourself, open a saved review and expand Review record · Sanity Workflows. The record is available to that gathering's organiser.
Code
Source code and setup instructions
INKSHIFT uses Next.js and React, Sanity Content Lake, App SDK and Workflows. Photo reading uses Qwen3-VL through Hugging Face Inference Providers. The verification record covers booking preservation, concurrent changes, access recovery and private-data checks.
My Build Process
Codex and Claude Code were my AI-native coding environment: Codex for the first build and the finish, Claude Code for an upgrade pass in between and the time machine. I checked the deployed paths against the real Sanity project and used local tests for the domain rules. The prepared demonstration and photo-reader checks are separate, because a fixed reading cannot establish whether the model understood a photograph.
The pitch, then very short prompts
The idea started as a note I pasted in: "A handwritten plan becomes a working, multiplayer app. Then you change the paper, and the app understands what changed without losing what people already did."
My prompts after that were short. "go on it's for dev.to challenge", then "anything works also if that does not fit the hackathon let me know and switch over to another project". Codex read the Path Two rules before writing code and answered that it fit, because Sanity would hold the model the whole product depends on.
The first correction: a table is not a session
The first model tied each game to its table. Moving Ticket to Ride from Table B to Table C would have replaced the session and dropped its bookings, which is the exact failure the product exists to prevent. Spaces, sessions and registrations became separate records with stable IDs, and a registration points to its session. Most of the later work follows from that decision.
The same day we set a second rule: a region missing from a photo leaves its contents uncertain and sends the reading to review.
Where the models got stuck
- The vision provider rejected the schema. Qwen3-VL through the Hugging Face router refused the bounding-box format. Codex fixed it by expressing each box as a fixed-length array of numbers.
- The reader removed a booked game. On the second photo of an edited plan, the reader decided Ticket to Ride was gone. Review blocked approval until I matched it back to the original session. After approval, the booking appeared at Table C. That run is why review is mandatory.
- The schema deploy was refused. The token Sanity provisioned for the project could write documents but could not deploy a schema. The app doesn't need it at runtime, so it waited until I deployed it with my own Sanity login four days later.
- App SDK warned during server rendering in production. Moving the subscription provider behind a browser-only import fixed it.
- Vercel picked the wrong framework preset. Committing an explicit Next.js configuration fixed the first deploy.
What I threw away
I asked for a Three.js scroll world on the landing page. It worked: the paper became tables, pawns took their seats and the game moved from B to C. It also looked like a toy, with small pieces and handwriting you couldn't read. I told Claude the 3D looked bad and chose a replacement built from the real interface. The homepage now uses an illustrated interface walkthrough. The separate browser recordings above show the real app controls and saved data.
Reaching into Workflows
When I added Workflows, the agent worked from the docs. Claude wrote the inkshift-plan-change definition (Reading, then Review, then Applied or Discarded) and its adapter, then hit its session limit before wiring the routes and interface. Codex picked up that working copy, connected proposal creation, readings, corrections, approval and discard to the engine, and deployed definition v1.
One detail from the docs shaped the design: the engine's checks are advisory, and only the Content Lake enforces anything. So the server still rechecks revisions, seats and the time slot before it writes, and a registration that arrives during review invalidates the stale proposal. Codex also added recovery for a plan decision whose workflow follow-up fails.
The time machine
After the first submission I wanted the strange part to be visible: ink on paper edits a live database, and the same people travel with their bookings as the paper changes. I asked Claude Code for a "paper time machine" and gave it one rule: do not fake history.
Before any UI, it checked the rule against the real dataset with a GROQ read. When I reran it on September 28, 22 events had applied proposals, and in all 22 the latest applied preview matched the live plan exactly (queries and counts). Two problems came out of that read. 8 of 30 applied proposals were saved before appliedVersion existed, so ordering falls back to the applied time. And nothing stored the plan before the first edit, so version 1 of a sample could only be rebuilt from code. That is why planBefore now exists and why old gatherings say Reconstructed on version 1.
What went wrong: the first test run was flaky. A booking and an approval landed in the same millisecond, and the version-1 frame dropped the guest. The tests now run on a fixed clock, and a booking made at the exact moment of an apply counts as before it. The agent also hit its session limit while writing the component and picked the work up from the last commit.
Writing this post
I pushed back on two drafts: "you've to establish it as completed product not incomplete" and "why'd you talk about how we made it instead of what product and how it uses sanity". That's why the post opens with the product. The build story lives here.
Testing a handwritten schedule
On September 30, Codex uploaded a photographed handwritten unconference schedule by James Arthur Cattell through the hosted app at a 390-pixel browser viewport. It contains 12 sessions in Rooms A, B and C, with four 45-minute slots. It has no seat limits.
Photograph © 2024 James Arthur Cattell, CC BY 4.0, reproduced unchanged from the linked article.
The first reading found the sessions and times, misread one title and guessed four-seat limits. It reported no uncertainty. Codex discarded it without changing the live plan. That failure led to a new gate: every photo reading now requires the organiser to check seat limits explicitly before approval. The model can still guess a number; the acknowledgement does not prove it is right.
Claude reviewed the fix independently. In the hosted rerun, approval stayed disabled through edits until the reading was explicitly checked and rechecked. Codex supplied eight places per room and session for this test, corrected the title, then approved the 12-session plan. A guest booked Hybrid Meeting Tips. A later manual edit added Room D and moved that session there; the guest's existing place appeared at Room D without another signup. The room move was an organiser edit, not a second photograph interpreted by the reader.
What is still unverified
Camera access on physical phones and broad handwriting accuracy remain unverified. The single-photo check above tests one legible handwritten schedule. The domain tests cover relocation, full destinations, identity ambiguity, cropped photos, time conflicts and capacity cuts. The September 28 suite had 37 tests, including six for the time machine: ordering, discarded readings left out, bookings followed by session ID, missing photos and reconstructed originals. The September 29 release expanded the suite to 62 passing tests and passed the hosted product, workflow and typed-photo checks. The September 30 capacity-review fix brought the suite to 65 passing tests and passed type checking, lint and the production build. An earlier live race for the last place produced exactly one winner, and five booking IDs survived a relocation.
In the September 29 photo check, the first typed sheet needed no correction. The crossed-out sheet produced two ambiguity questions. The test operator corrected that reading before approval, and the same booking then appeared at Table C. That run demonstrates the reader-to-review-to-approval path, including its need for a human decision.
The release audit also found that a proposal could change after the organiser had reviewed it. Approve, revise and discard now require the exact proposal revision shown in the review. Timeline loading includes the complete saved history, and ordinary joins and cancellations write only the records that changed. Claude independently reviewed the repairs before deployment.
The read-only Studio schema was deployed with my Sanity login on September 24 and updated on September 25. The September 29 schema changes are committed, but the optional admin metadata sync was refused by the current credentials. The running app and completed public-record migration do not depend on that sync.
INKSHIFT is bounded to small gatherings and keeps up to 1,200 lifetime registration records, including cancellations. Its recent-join guard is per browser, so an invite holder using fresh cookies could exhaust that limit. Existing places remain viewable and cancellable; recovery currently means creating a new gathering. Removing invite IDs from public projections cannot revoke links someone already knew.
Sanity Project Details
Project ID: a5xdqsb7
Dataset: production
Workflow: inkshift-plan-change, version 1
To use INKSHIFT for your own gathering, create an event, add its plan and share the participant invite. You can return through Your gatherings, or restore organiser access on another device with your private backup code.
Agent Session
I’ll read the pasted request and pick up the relevant context before proceeding.
The core of INKSHIFT is the second photograph: changing a live plan while preserving registrations. I’m using the hackathon-brainstorm skill to check the event fit and hardest technical assumptions, then I’ll bring back a concrete build recommendation before starting implementation.
I found the matching Sanity challenge. App SDK and Workflows are encouraged but optional, and the submission is a DEV article with a testable app. I’d make the paper-edit demo reproducible by a judge working alone.
There’s also a modeling issue to fix: removing a table must preserve the game session, and a relocation needs a free table at that time—not merely spare player seats.
I recommend pursuing INKSHIFT, with the second photograph as the core feature. The first build should prove that paper edits preserve a working event’s sessions and registrations.
I verified the matching event: Sanity Challenge, Path Two. It judges functionality, schema design, originality, and the build-process writeup. The deadline is October 5, 2026 at 12:29 PM IST. A DEV submission and Sanity project ID or public dataset URL are required. Official rules
I’d sharpen the proposal in four ways:
Separate tables, sessions, and registrations. People register for a particular game session. Moving that session changes its location while preserving its identity. Table C must be available during the entire session and support its capacity; spare seats in another game aren’t sufficient.
Treat unclear changes as questions. A table missing from a cropped photograph must not become a deletion. A crossed-out label could mean a rename, cancellation, or unavailable table. Show the interpretation before applying it.
Check again when approval happens. Someone may register while the organizer reviews a change. The server must revalidate capacity and affected records at commit time. Sanity supports atomic transactions and revision checks, but its query results can lag behind writes. Transaction documentation
Make the demo work without a presenter. Give each judge an isolated event, example photographs, and a participant link they can open on their phone. They should also be able to upload their own edited photograph. The submission format makes this more useful than depending on two judges participating together. Challenge instructions
The proposed architecture fits: an App SDK organizer canvas, a public participant page, and linked Sanity records for photographs, extracted evidence, tables, sessions, registrations, and proposed changes. Workflows can manage review and approval, but its current early-access guards are advisory; server validation and access controls must enforce the actual rules. Workflows limitations
The first experiment should test these cases before visual polish:
| Paper change | Required result |
|---|---|
| Same sheet, different camera angle | No meaningful changes |
| Rename or reposition a session | Preserve its identity and registrations |
| Cross out a table | Propose relocation or explain the conflict |
| Reduce capacity below registrations | Flag the conflict; preserve participants |
| Crop out part of the sheet | Request clarification |
Sketch-to-interface tools already exist, including Uizard and tldraw Make Real. My assessment is that INKSHIFT’s stronger differentiator is correctly reconciling a physical edit after people have started participating. That remains an untested hypothesis.
The tradeoff is deliberate: one event domain, explicit review, and bounded handwriting support in exchange for a credible, repeatable demo.
Shall I lock in this scope and begin with the photograph-matching experiment?
Your AGENTS.md requires choosing the direction before a new hackathon build. The hackathon-brainstorm skill explicitly says, “Wait for the choice.”
I’ll build INKSHIFT for the DEV Sanity challenge, starting with photo interpretation, change review, and registrations that survive approved edits. I’ll use Impeccable for the interface and keep a build log for the submission writeup.
I’m proceeding with a focused organizer workspace and a separate phone-friendly joining page. The first checks will cover renames, removed tables, capacity conflicts, and bookings made while a change is under review.
Sanity’s Workflows docs confirm that approval screens alone won’t enforce those rules. I’ll put the checks on the server and keep uncertain photo matches pending for review.
INKSHIFT fits Path Two: it gives Sanity a central role in the data model and produces a working app with a clear demo. I’ll keep this direction. If photo interpretation proves too unreliable, I’ll flag that with evidence before spending time on the final presentation.
The core model is in place. It preserves unmatched sessions for review, blocks capacity reductions below existing registrations, and proposes a relocation only when a table is free for the whole session.
I’m now wiring those rules to storage and the interface, then I’ll test the last-seat race and stale approvals.
The dedicated Sanity project is ready. Please claim INKSHIFT before September 23 at 7:15 PM IST so Sanity keeps the project and its data. Claiming is free and won’t interrupt the build.
I’m connecting the app to that project now.
Sanity is responding to a real write-and-read check. I’ve also found an available vision model through the configured Hugging Face connection.
The interface now pairs the paper with the live schedule. I’m keeping the prepared examples clearly labeled so judges can distinguish a working registration flow from a fresh photo interpretation.
The core flow is built: an organizer can review a changed plan, move a session, and keep its registrations attached. I’m now checking that against live Sanity data and testing the photo-reading and browser flows before preparing the challenge package.
The live check caught a useful integration bug: sample sessions referenced a paper document that hadn’t been saved. That’s fixed. The app builds successfully; I’m checking concurrent signups and changed-photo behavior next.
The live Sanity test passed: two people competed for the last seat, only one got it, stale approval was rejected, and moving the session preserved all five registration IDs. I’m also applying the no-ai-slop skill to the DEV draft.
Automatic approval review blocked deployment to Vercel because it requires explicit approval to upload this project there. I’ll finish the local app and review package before asking for that approval.
The organizer and invitation pages now work against the same event. The remaining issue is the vision provider returning malformed JSON on some examples. Those readings are rejected without changing the event; I’m tightening that response format before calling the photo flow ready.
I found and fixed an identity edge case that could assign a new game an old game’s ID before the first edit. The tests now cover that explicitly. Disk space also ran low during Studio setup; I’m removing this task’s rebuildable files and reusing the installed Sanity CLI so work can continue.
The photo reader now returns valid plans. It recognized the original sheet and proposed removing Table B while moving Ticket to Ride; the rename example still required a review. These checks use rendered sample sheets, so I’m keeping real handwriting accuracy as an explicit test still to do.
The Sanity project is now claimed, and all 19 domain tests pass. I’m running the complete photo flow through the app’s HTTP routes and checking the remaining mobile screens. The current token can save app data, but Sanity rejected schema deployment for lack of permission; the schema source is included locally.
I’ll use the Three.js scroll-world skill for the landing page: start with a sheet of paper, build the tables and games around it as you scroll, then show a table disappearing while its players move with the session. The organizer workspace will keep its current layout.
The live photo flow now preserves a registration when its game moves to another table. One AI reading needed a correction, which the review screen caught before it could change the event. I’m building that same moment into the landing page’s scroll story.
The landing will stay in one miniature world: paper, tables, players, then the move. Scrolling back will restore the scene, and people who prefer reduced motion will get still chapter views with the same controls.
The scene is implemented. I’m checking the phone layout and reverse-scroll behavior now, including whether the illustrated players arrive with the game board and return to the same seats when you rewind.
I’ll finish the landing-page checks, then verify that its main button opens the working event app.
The tables now rise from the paper in the live preview. I’m tightening the chapter navigation and checking the complete phone composition before saving the demo screenshots.
The first pass found a navigation overlap and a phone scene that was too small. Both are corrected. The heaviest scene is about 7,700 triangles and 58 draw calls; the next pass checks the revised layouts and real signup flow.
All four chapters now work at desktop, tablet, and phone sizes, including rewind and reduced motion. I’m checking the final handoff: create an event, join a game, approve the paper edit, and confirm that the participant’s booking stays intact.
The end-to-end check passed: Alex joined Ticket to Ride at Table B, the organizer approved the move, and Alex’s page updated to Table C. The Sanity App SDK inspector also shows the same session ID and registration count. I’m packaging the source and evidence next.
The final review found a few concrete fixes: resize handling, the static fallback’s highlight button, and easier access to the photograph action. I’m correcting those and finishing the source package and demo notes.
The photograph button now stays visible on both laptop and phone layouts. The landing’s fallback highlights the actual game row, and I’m rechecking all four scenes after the resize fix.
All four scene endpoints now remain correct after a height-only resize. The real signup and table-move flow also passed. I’m keeping the submission notes precise: the photo reader was tested with typed sample sheets; a physical handwritten-paper demo still needs a rehearsal.
The final review cleared the five fixes, and the production build, lint, type check, and all 19 tests pass. I’ve also prepared the DEV draft and demo script, with the remaining deployment and handwriting checks called out.
The optimized app also passed a local smoke test: saved bookings survived the restart, and the landing created a fresh event successfully. I’m finishing the downloadable source package now; public deployment is the remaining approval step.
The local review package is complete.
Automatic approval review rejected the Vercel upload because sending this project to Vercel requires explicit approval for that destination and data.
Built the four-scene Three.js landing and connected it to the working Sanity app.
Local demo · Source ZIP · DEV draft
All 19 tests, lint, type checks and production build pass. The booking survived the Table B → C move. A fresh reviewer cleared the final fixes using Impeccable’s contract. Physical handwriting still needs testing.
Approve uploading INKSHIFT to Vercel, including its Sanity/Hugging Face tokens as private environment variables, to deploy the public demo?
Automatic approval review blocked that upload because this destination and data transfer require explicit approval.
I’ll deploy INKSHIFT to Vercel, configure the private server credentials, then verify the public landing and signup flow.
I’m using the Vercel deployment and environment-variable guidance to keep the keys server-side and check the hosted app after release.
The Vercel connector’s deployment tool is unavailable, so I’m using the CLI. I’m setting up its login session before uploading the app.
The Vercel account is signed in. I’ve limited the upload to the app’s runtime files and pinned Node 24 to match the tested build. The credentials will be stored separately as private environment variables.
Vercel’s authorization button is still disabled with the current CLI. I’ve sent the login link for completion in your usual browser. The deployment configuration is ready, and I’m checking the hosted-test setup while that step is pending.
Deployment is waiting on Vercel login. Its authorization button stays disabled in the in-app browser.
Please approve the CLI login in your usual browser, then reply done. The deployment configuration is ready; nothing has been uploaded yet.
<oai-mem-citation>
<citation_entries>
MEMORY.md:57-66|note=[Vercel CLI deployment and private environment handling]
</citation_entries>
<rollout_ids>
019f56c6-dc99-7e23-a219-8610772201dc
</rollout_ids>
</oai-mem-citation>
I’ll verify the login, deploy INKSHIFT, then test the public signup and table-move flow.
The login is confirmed. I’m connecting INKSHIFT to your Vercel account and deploying the production build with its private server credentials.
The production project is linked correctly. The next checks will exercise real photo interpretation and confirm that a participant keeps the same booking when the table changes.
Vercel is building the app now. I’m also adding the final site address to Sanity’s allowed origins so the live content inspector works from the public demo.
The first build exposed a Vercel setup issue: the new project used the “Other” framework preset, so its routes returned 404. I’ve identified the cause and am pinning the deployment to Next.js before rebuilding.
INKSHIFT is live, and the public runtime is connected to Sanity. I’m checking the hosted signup, photo-review, and table-move flow now, including the browser experience.
The hosted photo reader returned an uncertain reading, and the app correctly blocked approval. I’m verifying the correction-and-approval path as well, since that’s part of the intended demo.
The hosted photo test passed: the booking kept its ID after moving to Table C, and unauthorized organizer/photo requests were blocked. The browser test is now checking the same move through the actual signup and review screens.
The browser flow also passed: Alex’s signup moved from Table B to C, and the Sanity inspector shows the same session ID at revision 2. I’m checking one console warning and finishing the release evidence.
The warning came from Sanity’s live subscription trying to render on the server. I’ve moved that connection into the browser and am deploying the fix; the page’s initial content still renders normally.
The final deployment is verified, including live Sanity updates after the fix and the existing booking surviving a reload. I’m packaging the updated source and evidence, then leaving the public demo open for you.
INKSHIFT is live and open in the browser.
Verified signup, photo review, registration-preserving table moves, live Sanity updates, and mobile layouts. All 19 tests and the production build pass.
Remaining: public repository, handwritten demo video, and DEV submission. Photo tests used typed sample sheets.
<oai-mem-citation>
<citation_entries>
MEMORY.md:57-66|note=[Vercel CLI deployment and private environment handling]
</citation_entries>
<rollout_ids>
019f56c6-dc99-7e23-a219-8610772201dc
</rollout_ids>
</oai-mem-citation>
I’ll find Claude’s latest work on INKSHIFT, check what changed, and continue from its approach and next steps.
I found Claude’s handoff. It moved the active build to ~/n/inkshift and was adding Sanity Workflows, replacing the 3D landing with an animated product walkthrough, and preparing the DEV article. Its session limit interrupted the work. I’ll continue from that copy and verify the unfinished changes before publishing or redeploying.
I’ll use Impeccable to finish the landing in Claude’s chosen direction, and no-ai-slop to edit the DEV draft. I’m also checking whether the workflow changes perform real transitions, since the handoff marked them unfinished.
The main gap is clear: Claude wrote the workflow definition, but the app still uses the old approval path. I’m connecting reading, review, approval, and discard to the real workflow, including a way to reopen saved reviews after a refresh.
The review path now preserves a saved decision even if the workflow service briefly fails afterward; reopening the review retries the missing record. I’m testing that recovery and stale-registration checks before adding the visible progress trail.
The new landing now demonstrates the actual sequence: paper, signups, review, and relocation with the same people. The workflow tests pass, including blocked approval, discard, stale reviews, and recovery after a failed workflow write. Next I’m checking the live Sanity definition and the browser experience.
The workflow definition is now deployed to Sanity, and the production build passes. INKSHIFT still fits Path Two; the current rules explicitly welcome App SDK and Workflows. They allow one submission per path, so the DEV draft will need to be treated as your Path Two entry when it’s published.
The live tests passed: a new signup makes an old review stale, rechecking updates the affected count, and approval moves the game without replacing the booking. The photo test also entered the real workflow; its second reading needed an identity correction, which approval correctly blocked until resolved.
The browser test now shows the saved Reading → Review → Applied trail, and the participant keeps their place at the new table. I’m finishing the mobile checks, updating the article to reflect what actually works, and preparing the verified source and redeployment Claude had approval to publish.
The landing and workflow screens are ready for a fresh visual review. The automated checks are clean, and the DEV draft now documents the failed image reading, the recovery logic, and the remaining handwriting test instead of overstating the demo.
The independent review found no material layout issues in the captured screens. It flagged the old design documentation, which still described the removed 3D landing; that is being updated now. The source scan found no credentials in the files prepared for publication.
The local end-to-end flow is working: after approval, the participant still has the same booking at Table C, and the saved review reopens after reload. I’m finishing the documentation review, then publishing the source and updating the live deployment as previously approved.
The new build has compiled successfully on Vercel. It includes the product walkthrough you chose with Claude, plus real Sanity workflow stages, saved reviews, and discard handling. I’m checking the hosted booking and photo flows before calling the release finished.
The hosted workflow check passed: stale reviews are blocked, rechecking updates the participant count, bookings survive the move, and discarded changes leave the plan intact. The independent reviewer also passed the corrected design documentation. The final photo-reader check is still running.
The live photo flow also passed. The edited sheet needed a manual identity correction, and the app preserved the booking afterward; the write-up records that limitation. The source scan found no credentials in the 114 staged files, so I’m publishing the repository and preparing the final handoff.
The update is live, and the public GitHub repository and article screenshot links are verified. I’m saving the release record and refreshed source ZIP. Physical handwriting testing, the Studio/schema deployment, and DEV publication remain unfinished, as recorded in the handoff.
I recovered Claude’s active INKSHIFT checkout. It had started Sanity Workflows but left the API and UI integration unfinished. I completed that work and the product-led landing you selected.
All 25 tests, build checks, hosted workflows, photo processing, and browser checks passed. Bookings survived the table move. Independent design review passed using substitute agents because the specialized roles were unavailable.
Still pending: physical handwriting testing/demo video, Studio/schema deployment, and DEV submission. The article remains unpublished.
<oai-mem-citation>
<citation_entries>
MEMORY.md:1729-1729|note=[CLI recovery of Claude project context]
MEMORY.md:148-148|note=[Prior INKSHIFT deployment checks refreshed live]
</citation_entries>
<rollout_ids>
01a08010-6959-7fd1-8c86-4559ea1497aa
</rollout_ids>
</oai-mem-citation>
I’ll make INKSHIFT feel ready for an organizer to use: review the live experience, tighten the onboarding and language, and address gaps in the core flow. I’ll also check what remains for the challenge handoff.
The main gap is the first-use flow: the site leads with a sample, while starting and returning to a real gathering takes too much effort. I’ll add a clear setup flow, a “Your gatherings” page, and a way to save organizer access. I’ll keep challenge details in the about page so the main interface focuses on planning and inviting people.
The new setup and returning-user flows are in place. Organizers can name a gathering, choose its date and time zone, and return to it from “Your gatherings.” I’ve also added a private access-code flow and tests that verify it only opens the intended organizer workspace.
The interface now separates real gatherings from practice examples, and puts help and privacy information where organizers can find it. All 31 tests pass, including the new access-recovery checks. I’m checking desktop and phone layouts next, then I’ll capture a walkthrough of the finished product.
I found a first-use issue: manual entry was showing an unrelated example sheet. I’m fixing that and checking the full path from typing a plan to sharing an invite.
Automatic approval review blocked the Sanity schema deployment because the earlier instruction left schema/Studio as a handoff. I’ll prepare the local schema package and request approval for that exact step while continuing the product work.
The API checks passed for custom event details, private gathering lists, and restoring organizer access in a separate browser session. The schema also validates with zero errors or warnings, and the Studio build is ready. I’m finishing browser verification and the product walkthrough while the deployment approval is pending.
The browser checks caught and fixed a date-field issue: the date shown in the form now carries through to the saved gathering. I’ve also verified returning to a saved gathering, invalid-code feedback, and manual entry without a misleading sample image. I’m using the browser-video-recording workflow for an edited walkthrough of the actual app states.
The product now supports creating your own gathering, returning to it, and restoring organizer access. I’m finishing the release review and checking the hosted flow before publishing the update and demo.
I’m sending the finished screens through the Impeccable review. Its specialized reviewer role is unavailable here, so a fresh reviewer will use the same review contract.
The review has confirmed that all eleven desktop and phone captures are valid. The local checks also pass: 31 tests, a production build, and HTTP checks for access recovery and typed plans without a sample image.
The independent finish review returned ship. I’m deploying the update now, then I’ll verify recovery and booking preservation on the public site and capture the walkthrough there.
Yes. People can create a gathering, upload or type a plan, approve it, share an invite, and let guests join from their phones. They can also return later or restore access with their private code.
The Sanity Studio is an internal inspection tool; it isn’t required for people to use INKSHIFT. I’m finishing the public-site checks now.
The public-site checks passed: organizer access restores correctly, private data stays restricted, and the same booking survives a move from Table B to C. I’m capturing the demo from the released app; it will label the prepared example clearly.
The browser walkthrough confirms that a custom name and date save correctly and a guest can book a place. I’m now recording the edit approval and the guest’s updated table, then packaging the verified source and demo.
The recorded flow now shows the guest’s place at Table C after approval. The update is live, and I’m exporting the walkthrough and syncing the source and verification notes to GitHub.
The product update is live and the source checks are clean. The walkthrough export is still running. Public write-up notes now distinguish the verified browser flow from the handwriting test and DEV submission that remain unfinished.
The walkthrough export is complete and its video checks pass. GitHub’s remote check is taking longer than expected; the live app is already available.
The 43-second walkthrough is ready, including a smaller copy for sharing. I’m publishing the final source commit now; no credentials were found in the staged changes.
INKSHIFT is live and usable. People can create gatherings, upload or type plans, invite guests, and return or restore organizer access.
Verified 31 tests, production checks, mobile layouts, and booking preservation after a table move.
43-second walkthrough · Source
DEV publication and photographed-handwriting testing remain open.
Automatic approval review blocked optional Studio deployment because earlier instructions left it as a handoff. Public use does not require Studio.
<oai-mem-citation>
<citation_entries>
MEMORY.md:148-148|note=[Used prior deployment guidance and verified current production]
</citation_entries>
<rollout_ids>
</rollout_ids>
</oai-mem-citation>
I put it on GitHub alongside the source so there was a public link immediately. I didn’t verify a YouTube channel or upload it there. YouTube would be easier to watch and embed in the DEV post; I’ll check the available upload options.
I used GitHub as a quick hosting shortcut and left the YouTube upload unfinished. That was my miss.
Your YouTube channel is signed in. I’ve asked to upload the walkthrough as Unlisted and replace the links; the browser’s upload rule requires explicit approval first.
<oai-mem-citation>
<citation_entries>
MEMORY.md:975-975|note=[YouTube upload verification guidance]
</citation_entries>
<rollout_ids>
</rollout_ids>
</oai-mem-citation>
I’ll upload it as unlisted, verify playback, and replace the GitHub video links with the YouTube link.
YouTube has processed the upload and found no copyright issues. I’m saving it as unlisted with a description that identifies the prepared sample, then I’ll check the watch page.
The video is published as unlisted and played through successfully. I’m updating the README and DEV draft to use the YouTube link.
The YouTube links and DEV embed are pushed to GitHub. I’m refreshing the source archive and checking the published files.
Uploaded as unlisted: Watch INKSHIFT on YouTube.
Playback verified. The README and unpublished DEV draft now use YouTube, including an embed.
<oai-mem-citation>
<citation_entries>
MEMORY.md:975-975|note=[YouTube publication and playback verification]
</citation_entries>
<rollout_ids>
</rollout_ids>
</oai-mem-citation>
I’m using the no-ai-slop skill to finish the DEV challenge post, keeping your voice, the YouTube demo, and the limits of what we’ve tested clear.
The draft fits the challenge’s Path Two template. I’m tightening the build story around the booking-preservation problem and the model’s identity mistake, and removing internal handoff details that don’t help readers.
The post is finished and checked against the skill’s evaluation guide. It keeps the concrete failures and fixes, includes the YouTube embed, and clearly says the handwriting demo is still untested. I’m saving the publication-ready copy separately from the editorial notes.
Saved the finished DEV post, including tags and the YouTube embed. It remains unpublished.
INKSHIFT: move the game, keep the bookings
This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange.
What I Built
Four people sign up for Ticket to Ride at Table B. Then Table B becomes unavailable.
I wanted the organizer to cross out the table on their paper plan, photograph the edit, and move the game without asking everyone to sign up again. I built INKSHIFT around that problem, with games nights, clubs and workshops in mind.
An organizer creates a gathering with a name, date and time zone, then uploads a photo or types the plan. They check the games, tables, times and player limits before sharing a signup link. A later photograph creates a proposed change that they can correct, approve or discard. People who already joined keep their registrations when the same session moves.
The model proposes structured data. The app checks capacity, time conflicts and session identity before applying a change. Returning organizers can reopen their gatherings and save a private access code to restore access on another device.
Demo
Watch the 43-second product walkthrough on YouTube. It is edited from real browser states and uses the prepared sample described below.
{% embed https://www.youtube.com/watch?v=xM5eC-q7t_0 %}
Open INKSHIFT and choose Try a sample. No account is needed. Open its participant invite, join Ticket to Ride, then return to the organizer and choose Use the crossed-out example. The review proposes moving the game from B to C. After approval, the participant page shows the same booking at Table C.
The landing walkthrough is an illustration, and the sample uses a fixed reading. Both are labeled. Choose Plan a gathering to start your own event; uploading a photo from its workspace calls the image reader.
The photo-reader tests used rendered typed sheets. I have not yet validated photographed handwriting or recorded the physical-paper demonstration.
Code
The app uses Next.js, React, Sanity Content Lake, Sanity App SDK, Sanity Workflows, Zod and Qwen3-VL through Hugging Face Inference Providers. The Sanity write token stays on the server.
Start with reconcile.ts for identity and scheduling, service.ts for revision-checked writes, and plan-change.ts for the workflow definition.
My Build Process
The original brief asked for “a handwritten plan” that becomes “a working, multiplayer app,” then survives changes after people have started using it. I started in Codex, continued in Claude Code, and returned to Codex to finish the integration and test it.
I started with the data model. A table and a game needed different IDs. A booking points to a session, so the session can change tables without replacing the booking. Moving a game requires enough seats and an available table for its entire time slot. When no destination fits, approval stays blocked.
The photo reader was harder than the first screenshot suggested. The provider initially rejected the JSON schema for source boxes. Representing each box as a fixed-length array of numbers fixed that request.
The next failure affected an existing booking. In a test using two typed sheets, the edited sheet produced a reading that would have removed the booked game. Approval stayed blocked until I corrected the session match. The same booking then moved to Table C. I kept that correction step in the interface because an uncertain reading needs a person to check it.
I first asked for a Three.js scroll world on the landing page. Later I dropped it so the demonstration could show the paper, signup interface and approval directly. The replacement walks through four selectable steps. The live sample opens a separate practice gathering.
Claude began the Sanity Workflows integration before its session stopped. It had written the definition and engine adapter, but the API and UI still used the old approval path. I used Codex to connect those paths and add saved reviews. Prepared examples also got their own caller label so the history distinguishes them from photo readings.
The process now runs through Reading, Review and either Applied or Discarded. The reader submits the proposed changes and unresolved checks. The organizer corrects and approves through the same saved workflow instance. Completed reviews can be reopened from their history.
I also had to handle a partial failure. The event transaction can succeed while the workflow record fails to update. Repeating the entire operation could apply a decision twice. INKSHIFT saves the decision alongside the event update and uses it to resume the missing workflow action. The interface tells the organizer when the plan is saved but the workflow record needs a retry.
I tested that recovery with a simulated connection failure and the workflow engine's in-memory test bench. All 31 tests passed: 19 domain tests, six workflow tests and six tests for organizer access and returning to saved gatherings.
Against the deployed app, I checked that a new registration makes an open review stale. Rechecking it updated the affected count, and approval preserved the booking through the move. Discarding a conflicting proposal left the plan unchanged. The dated verification records include those checks and the rejected requests for private review data.
My later instruction was “make sure it's like a product not a project.” I moved the sample behind a secondary action and added gathering setup, a returning-organizer list and access recovery. The private backup code lets someone manage the gathering on another device, so the interface tells organizers to keep it separate from the participant invite.
Testing that path exposed two defects. The date shown in the form could differ from the date submitted, so setup now reads the form's current values. Manual entry also inherited an unrelated sample photograph. I removed that fallback and checked that approving a typed plan creates no example-photo link.
Sanity Project Details
Project ID: a5xdqsb7
Dataset: production
Sanity Content Lake stores the event and linked spaces, sessions, registrations, photo revisions and proposals. Plan and registration updates write the public schedule projection in the same revision-checked transaction. Approval checks both the event and proposal revisions, so a new registration or another review edit can invalidate an old approval.
The organizer and content inspector use App SDK subscriptions for the public schedule and counts. Authorized server routes return private organizer data and each participant's own booking. The browser never receives the write token.
The deployed Workflows definition is inkshift-plan-change, version 1. Its instances sit alongside the proposals in Content Lake. The server records whether a step came from the photo reader, a prepared example or the organizer. Those labels describe application callers under one server credential. Server authorization and revision checks enforce access and protect writes.
The repository includes the Studio schema and a read-only inspector. The schema validates and the inspector builds locally; I have not deployed that inspector. The public app's Content Lake writes, App SDK subscriptions and workflow transitions have been tested.
Next, I need to run the full flow with physical handwriting and a participant on a second phone, then record it.
What changed: Tightened repetition, removed internal handoff details, preserved your build story and concrete failures, and changed the title to avoid implying a completed handwriting test. Checked against the skill’s eval.md.
<oai-mem-citation>
<citation_entries>
MEMORY.md:148-148|note=[Prior hosted flow context checked against current project evidence]
</citation_entries>
<rollout_ids>
</rollout_ids>
</oai-mem-citation>
You’re right. The post ends like a progress report. I’ll close with what people can use today, remove the internal deployment details, and keep the demo disclosure brief and factual.
Updated the post to present the live product. Removed the future-work ending and internal deployment details.
It now closes with:
INKSHIFT is live at inkshift.vercel.app. Choose Plan a gathering, add your plan and share the signup link with your guests.
I gave the build diary too much space. I’ll rewrite it around what INKSHIFT does, how organizers use it, and what Sanity handles. I’ll keep the challenge’s required build-process section brief.
Sanity now has a clear role in the story: Content Lake stores sessions and bookings, App SDK keeps the organizer view updated, and Workflows records review and approval. I’m removing the tool handoffs, design changes, and debugging chronology.
The rewrite is now about 725 words, with just one short build-process paragraph. Most of it covers the product flow and explains how Sanity preserves bookings, updates the interface, and records approvals.
Her Hermes post is the closest reference for INKSHIFT: it introduces the product, names three concrete jobs Hermes performs, then supports them with a demo and implementation details. She includes development decisions when they explain product behavior. The useful change for our post is to bring Sanity’s role forward and tie each feature to an organizer’s action.
I also checked her newer PadForward post. It walks readers through concrete actions and labels the demo data clearly. I’m applying that structure to INKSHIFT: introduce Sanity’s three jobs near the top, give readers a test they can follow, and explain the implementation through the product behavior it supports.
The rewrite now follows one situation from signup to a table move. Sanity appears as each part becomes relevant: Content Lake keeps the bookings attached, Workflows holds the review, and App SDK updates the organizer view. I’ve kept the build history to one paragraph.
I changed the outline before; this time I rewrote the prose around one situation. The updated Markdown file includes the video embed.
INKSHIFT: keep the bookings when the plan changes
This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange.
What I Built
You're organising a games night. People have picked their games and booked their places.
Then Table B becomes unavailable. There is room for Ticket to Ride at Table C, but the people joining it already have a booking that says Table B.
I built INKSHIFT so the organiser can approve that move and keep those bookings.
INKSHIFT turns a small-event plan into a shared signup page. You can use it for a games night, a club meetup or a workshop, then keep managing the same gathering as the plan changes.
Start with the plan you already have
Create a gathering, give it a name and choose its date and time zone. Upload a photo of the plan, or type it in. Check the sessions, spaces, times and player limits before opening registrations.
Once you're happy with the plan, share the invite link. Your guests pick a session and join without creating an account. Their places appear in the organiser's workspace.
You can come back through Your gatherings to manage the event. A private backup code lets you restore organiser access on another device, so keep that code separate from the invitation you send to guests.
Move the game with its bookings
Ticket to Ride is still the same game, at the same time, with the same people. It needs another table.
In Sanity Content Lake, the table, session and registration are separate linked records. Each booking belongs to the session's stable ID. Moving the session to Table C changes its table reference, and the bookings stay attached to it.
The app checks that C has enough seats and is free for the whole session. You see the proposed move and the affected registrations before approving it. If the move cannot fit, approval stays blocked while you correct the plan.
The landing-page illustration shows how a table move affects existing registrations.
You decide when the change goes live
Uploading an edited plan opens a review. The reading can be corrected before it changes anyone's booking.
Sanity Workflows keeps that review as a saved process alongside the proposal in Content Lake. It moves through Reading, Review and either Applied or Discarded. You can approve the change, discard it or reopen a completed review later to see the decision.
Someone might join the game while you're still deciding where to move it. INKSHIFT checks the event and proposal revisions before saving. If the registrations have changed, it asks you to recheck the move against the current bookings.
The approved plan, linked records and public schedule are saved together in one Content Lake transaction. App SDK subscribes to the schedule and booking counts, keeping the organiser workspace connected to those changes. The content inspector lets you see the session's ID alongside its current table and booked places.
That public view contains the schedule and counts. Participant names, uploaded photos and organiser access data remain behind authorised server routes. The Sanity write token stays on the server.
Demo
Try INKSHIFT or watch the 43-second walkthrough.
To try the move yourself, choose Try a sample and join Ticket to Ride through its participant invite. Return to the organiser, select Use the crossed-out example, review the move and approve it. Reopen the participant page to see your booking at Table C.
The video uses a labeled prepared sample with a fixed reading. Separate photo-reader checks used rendered typed sheets.
Code
INKSHIFT uses Next.js and React, with Qwen3-VL through Hugging Face Inference Providers for photo reading. The verification record covers booking preservation, concurrent changes, access recovery and private-data checks.
My Build Process
I used Codex and Claude Code to build the app around sessions that keep their identity when the plan changes. In a typed-image test, the reader treated a booked game as removed. I added an explicit correction step before approval and verified that the original booking survived the move. That is why the review is part of the product's normal flow.
Sanity Project Details
Project ID: a5xdqsb7, dataset: production. The deployed workflow is inkshift-plan-change, version 1.
Create your own gathering, add the plan and share the signup link with your guests.
What changed: Replaced the feature catalogue with a connected organizer-and-guest story. Sanity now appears where it explains the product’s behavior, with the build diary kept brief.
<oai-mem-citation>
<citation_entries>
MEMORY.md:148-148|note=[INKSHIFT continuity checked against the current article and verified project context]
</citation_entries>
<rollout_ids>
</rollout_ids>
</oai-mem-citation>
I’ll review the current design and post together, study relevant 21st.dev examples and past winners, and use the strongest findings to improve INKSHIFT’s presentation and make its Sanity integration easier to judge. I’ll use Impeccable for design direction and keep applying no-ai-slop to the writing.
The current Sanity brief explicitly judges schema design and an honest build-process writeup. I’ll keep that section short, but give it substance: why bookings reference sessions, what the image-reader test got wrong, and how review protects existing registrations.
The landing changes are built: larger walkthrough text, 44px mobile step controls, shared colour tokens, and a compact FAQ covering accounts, photo corrections and bookings.
The finish review confirmed the sponsor descriptions match the implementation and caught a low-contrast FAQ hover colour, which I’m correcting. At 390px, the walkthrough has no horizontal overflow and all four step controls measure 44px high. The research notes now link the winner examples and explain which choices informed INKSHIFT.
The changes are committed and pushed. Vercel rejected the saved CLI token, so I’m checking the existing deployment access before publishing. The production build and responsive checks have passed; the live site still has the previous version.
The design and writing changes are complete. Deployment is blocked by Vercel’s sign-in page: its “Allow Access” button remains disabled after a reload. I’m keeping the release record accurate—the updated source is on GitHub, while the live site remains on the previous deployment.
The organiser screen is already clear. The review screen needs to make the important change more obvious: which table the game is leaving, where it will go, and how many bookings it keeps. I’ll add that comparison using the saved proposal data.
I’ll also open the landing walkthrough on the review step and replace the article’s illustration with screenshots of an actual sample booking, review and content inspector.
The sample run caught a useful case: the booking arrived while the review was being prepared, so INKSHIFT blocked approval and required a recheck. The refreshed review now shows one booking staying with Ticket to Ride as it moves from Table B to Table C. I’ve captured that real review screen for the article.
The article now has three screenshots: the proposed move, the participant’s retained booking at Table C, and the live Sanity inspector showing session-1-1 with 1/4 places booked. Each image supports the product story with something a reader can inspect.
The build and lint checks passed, and the finish reviewer found no issues in the new changes. Vercel is still signed out, so I’m showing the updated UI locally.
The review now shows Table B → Table C clearly, alongside the booking it preserves.
I also improved the landing’s opening state and added three real product screenshots to the article, including the live Sanity inspector.
Explore the updated UI locally. Build, lint and finish review passed; the sample booking survived the move.
Source and screenshots are pushed. The latest UI deployment remains blocked by Vercel sign-in.
<oai-mem-citation>
<citation_entries>
MEMORY.md:197-198|note=[Used prior booking preservation context and verified a fresh sample flow]
</citation_entries>
<rollout_ids>
01a0beff-7061-7153-a959-883a492c5cc7
</rollout_ids>
</oai-mem-citation>
I’ll revisit the winning posts and rewrite the article around INKSHIFT’s strongest story: a plan changes, a booking survives, and Sanity makes that continuity possible. I’ll use their approach to explanation and evidence while keeping your own voice, then check the draft with no-ai-slop.
