大多数酒窖应用只回答一个问题：我现在有什么。Cellar想回答的是另一个更难的问题——1999年6月1日，我的酒窖长什么样？2018年那次品鉴改变主意之前，我以为那瓶酒的适饮期是什么时候？哪些酒去年正处在巅峰，而我当时没留意，现在已经过了最佳饮用期？
这些问题直接排除了最直观的数据模型。在酒瓶上放一个状态字段，只能告诉你今天为真的事，对2004年一无所知；在酒款上放一个"适饮至"字段，只能记录某人当下的判断，却抹掉了此前的判断。
不存状态，只存事件和主张
Cellar两样都不存。它存的是事件和主张：
- 购入和消耗是带日期的文档，不是酒瓶上的字段。只要在日期T或之前存在一条消耗事件，这瓶酒在T时点就算已被消耗。
- 评估是带日期、带署名的关于"这瓶酒该什么时候喝"的主张。没有任何东西会覆盖一个适饮窗口。当前窗口由T时点已存在的主张按明确规则解析得出：我自己的品鉴笔记优先于酒庄的，酒庄的优先于酒评人的；同一层级内，最新的主张胜出。
其余的一切都由此推导。把日期控件往回拨，购入记录消失，消耗记录反转，适饮窗口随着主导主张的变化而变化；往前拨，未开瓶的酒会随时间穿过它们的适饮窗口。
底层的设计原则是：当你以后可能需要知道当时为真的事，就不要只存现在为真的事。
三个界面，各司其职
Cellar有三个界面，承担不同的工作：
- Sanity Studio负责编写和治理这本账。六种文档类型、一个自定义审核队列、两个文档操作，以及一个只读的工作流字段。
- 一个基于App SDK构建、运行在Sanity内部的Sanity App负责解读这本账。三个视图，全部由一个纯TypeScript包从事件日志实时计算得出，这个包对Sanity一无所知。
- 一个公开页面，就是同一个App，只是不需要账号。它的只读是结构性的，而非约定俗成的——打包产物里没有令牌，数据集的公开ACL只授予读取权限。
它刻意不做第二套增删改查界面。Studio本身就是一套，所以添加酒瓶和记录消耗都在那里完成。App只负责解读，不负责管理。
至于它是给谁用的，老实说：给我自己。但这个论证可以推广到葡萄酒之外，这也是我把它做出来的原因。
同一本542瓶的账，读三个时点
无需账号即可打开：kenwalger.github.io/Cellar。在Sanity内部（组织成员）则是The Cellar应用。
同一本542瓶的账，在三个时点被读取：1999年，整个酒窖是四瓶1993年的木桐酒庄葡萄酒，其中两瓶已经开过。到2026年，是248瓶。投射到2035年，这248瓶还在，其中182瓶已经过了适饮窗口。
酒窖从不会丢酒，它丢的是机会。
"即将适饮"列出十二个月内关闭窗口的酒，每一行都注明是哪个主张决定了它：哪个层级、谁的、什么时候的。"错过的机会"问的是另一个问题：哪些酒在某段时间里正处巅峰、从未被打开、如今已过窗口。而当什么都没错过时，它会说明原因，而不是显示一个空面板。
App里的三个视图，全部从事件日志实时计算：酒窖健康度，任意日期下按状态划分的瓶数；即将适饮，十二个月内关闭的窗口，每行注明由哪个主张决定；错过的机会，某段时间内正处巅峰、从未被打开、如今已过窗口的酒。而在Studio里，是审核队列——一条被提出的主张在那里等待一个人来处理。
十四份规划文档，没有一行代码
工具方面：终端里的Claude Code，旁边是WebStorm，接上了Sanity的MCP服务器，这样模型可以核对当前文档，而不是凭记忆作答。有一点值得直说：提示词本身是在与Claude的另一次规划对话中起草的，每一个分岔口的决定也是在那里做出后再转达的。把这件事说成"一个开发者加一个智能体"并不准确。
项目进入实现阶段时，带着十四份规划文档：一份内容模型、一份时间解析规范、一份构建计划、一份种子数据计划，以及十一份架构决策记录。没有一行是代码。这一点后来被证明很重要，只是方式和我预想的不同。
浮现出来的模式是：规范，然后智能体冲突检查、不写代码，然后人来决策，然后实现，然后独立的判据、测量或实验，最后是一道只有我能关上的闸门。
每个阶段都以一句大意如下的提示词开始：读规范，对照当前平台检查它们，报告哪里不一致，然后停下。每个阶段都发现了问题。随着项目推进，这个数字是上升的，不是下降的。第一阶段发现了三处规范错误。第四阶段一开场就有十处冲突，其中两处是规范错误。
最有价值的一条指令
"报告冲突，并在写代码之前停下。"这是整个项目里价值最高的一条指令。第一阶段它发现，我指定了带下划线前缀的投影字段，而这是Sanity保留给系统字段的；还发现一条校验规则要求某条评估必须在特定状态下被创建，而Sanity无法表达这一点，因为校验只能看到当前状态。照字面实现那条规则，会让"接受"这个转换永久失效，恰好破坏这条规则本意要保护的工作流。
还有一类闸门，会写明什么不算证据。为App SDK那道闸门，我写下了正在被测试的路径，然后列出它可能被伪造的方式：不要通过单独调用@cellar/core、用别的工具查询数据集、或只依赖现有测试套件来满足这道闸门。目的是证明完整路径：Content Lake → App SDK → CELLAR_QUERY → toCellarSnapshot → bottleState() → 渲染视图。你看不到渲染后的视图，所以不要把闸门报告为已通过。给我命令、URL，以及我具体应该看到什么。