Prop Continuity Desk: the parcel cannot be in two places
Prop Continuity Desk: the parcel cannot be in two places
道具连续性工作台：包裹不能同时出现在两个地方
Sanity Challenge Path Two Submission. An entry prepared for Sanity Challenge — Path Two. Sanity 挑战赛路径二提交。这是为 Sanity 挑战赛路径二准备的参赛作品。
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. 我构建了什么。Prop Continuity Desk 是一个为小型戏剧制作设计的排练规划板。其虚构剧目《最后一艘船上的位置》（A Place on the Last Boat）包含六个场景和十二个实体道具。一个包裹随乘客进入，一个火炬随工作人员离开，钥匙扣在最后一幕中易手。
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. 演示。在线演示：Prop Continuity Desk。主面板读取已发布的 Sanity 内容。“尝试练习副本”（Try a practice copy）操作会在当前标签页创建一个可编辑副本，让访问者在不更改正式制作内容的情况下探索规则。
Open scene 2, “One more passenger.” The published parcel has one position at stage right; the torch has a recorded transfer to centre stage. Choose “Try a practice copy,” select the torch and edit its cue. Scene 2 and affected later checks become “Needs recheck.” Scene 1 keeps its check because it does not depend on future content. Export the cue sheet. A practice export explicitly identifies itself as a practice copy. Choose “Load published plan.” The server’s original cues and checks return; the practice edit was never written to Sanity. 打开场景 2，“又多了一名乘客”。已发布的包裹在舞台右侧有一个位置；火炬有一个记录在案的转移到舞台中央的动作。选择“尝试练习副本”，选中火炬并编辑其提示。场景 2 及受影响的后续检查变为“需要重新检查”（Needs recheck）。场景 1 保留其检查状态，因为它不依赖于未来的内容。导出提示单。练习导出文件会明确标识为练习副本。选择“加载已发布计划”。服务器原始的提示和检查状态恢复；练习编辑内容从未写入 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. Sanity Studio 提供了经过身份验证的内容和计划审核工具。访问者使用公共排练板和练习副本；管理员凭据不会被共享。截图记录了实际的身份验证工作流程。仓库说明还支持使用审核员自己的 Sanity 项目运行独立的 Studio。
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. 代码。源代码仓库：lecsetsuna16/prop-continuity-desk。该应用使用 Next.js、React 和 TypeScript。源代码包含 Sanity 模式、种子生成器、领域规则、查询集成测试和独立的 Studio 工具。需要 Node 22.12 或更高版本；验证使用 Node 24.19。构建前请复制 .env.example。如需独立部署，请将项目和 Studio 部署标识符替换为您自己的。
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. 我的构建过程。这是一个在 Codex 中委托构建的项目。账户所有者授权了该项目并完成了账户设置；Codex 提出了戏剧场景、实现了应用程序、运行了测试并起草了本文。所有者没有手动编写代码或执行报告中的测试。开发始于 2026 年 9 月 26 日。
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. 检查需要独立存储。 早期设计将审核结果保存在场景文档中。保存审核结果会改变正在审核的版本。独立的 sceneReview 文档解决了这个问题。每次审慎的检查都会创建一个新事件，包括恢复早期内容时。
- 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. 审核依赖于历史。 指纹（fingerprint）包含场景的已发布内容、相关道具定义以及这些道具的早期放置和提示。早期相关的提示更改会使后续审核失效。不相关的未来编辑则不会。
- 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. 显示的内容可能会过时。 Studio 工具在保存前会获取当前已发布的计划，并将其与显示的快照进行比较。一个真实的两窗口测试在其中一个窗口发布了编辑，并在另一个窗口拒绝了过时的审核。如果内容在成功检查后发生变化，该检查仍作为历史记录保留。
- 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. 实时数据标签需要证据。 在 Sanity 请求成功之前，前端保持在示例模式。加载期间禁用导出，失败的请求可见，且请求排序机制防止旧响应替换较新的状态。
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. 在连接之前，本地规则测试和 GROQ 评估已通过，但它们无法建立真实的权限或持久性。在所有者创建 Sanity 项目后，代理导入了 19 个虚构文档，并使用实际的 Studio 修复了种子冲突。实时检查验证了刷新后保存的审核、草稿隔离、并发审核拒绝和下游失效。托管的 Studio 成功保存了另一个审核，部署的 Next.js 面板通过其配置的 CORS 源读取了该已发布内容。该测试暴露了另一个 UI 错误：从一个场景获得的成功消息在选择另一个场景后仍然可见。现在它会在场景更改和重新加载时清除；该修复已在浏览器中验证。
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. 验证工作以 19 个通过的测试、通过的类型检查、成功的 Next.js 静态构建和成功的 Studio 模式部署而结束。下载了练习提示单并检查了其标签。这些检查确立了经过测试的规划行为，而非后台的物理准备情况。
Sanity Project Details. Project ID: x06ajbeo. Dataset: production, public, with fictional content. Production: production-last-boat. Studio: https://prop-continuity-x06ajbeo.sanity.studio/. Sanity 项目详情。项目 ID：x06ajbeo。数据集：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… 四种文档类型对工作流程进行建模。Production 引用其有序的场景文档；每个库存道具引用其所属的 Production。Scene placements 引用道具并包含区域和可选提示。SceneReview 引用场景和 Production，并存储修订版本、依赖指纹和时间。公共归属使用通用标签“Production editor”，而不暴露账户电子邮件。审核过程是通过自定义 Studio 工具管理的应用程序数据。它假设一个受信任的制作……