prototype

原型

原型是回答问题的废弃代码。问题决定形状。

选择分支

确定正在回答哪个问题——从用户的提示、周围的代码中，或者如果用户在身边则询问：

• "这个逻辑/状态模型感觉对吗？" → LOGIC.md。构建一个小型交互式终端应用程序，将状态机推入难以在纸上推理的案例中。
• "这应该看起来像什么？" → UI.md。在单个路由上生成几个截然不同的 UI 变体，通过 URL 搜索参数和浮动底部栏切换。

两个分支产生非常不同的工件——弄错这一点会浪费整个原型。如果问题确实模棱两可且用户无法联系，默认选择与周围代码更匹配的分支（后端模块 → 逻辑；页面或组件 → UI）并在原型顶部陈述假设。

适用于两者的规则

1. 从第一天起就是废弃的，并明确标记为这样。 将原型代码放置在它将实际使用的位置附近（在它正在原型的模块或页面旁边），以便上下文显而易见——但命名它使偶然读者可以看到它是原型，而不是生产代码。对于废弃的 UI 路由，遵守项目已经使用的任何路由约定；不要发明新的顶级结构。
2. 一个命令运行。 无论项目现有的任务运行器支持什么——pnpm <name>、python <path>、bun <path> 等。用户必须能够无需思考即可启动它。
3. 默认没有持久性。 状态存在于内存中。持久性是原型_检查_的东西，而不是它应该依赖的东西。如果问题明确涉及数据库，点击临时 DB 或具有清晰"原型——擦除我"名称的本地文件。
4. 跳过抛光。 没有测试，没有超出使原型_可运行_所需的错误处理，没有抽象。重点是快速学习一些东西然后删除它。
5. 暴露状态。 每次操作后（逻辑）或每次变体切换时（UI），打印或渲染完整的相关状态，以便用户可以看到发生了什么变化。
6. 完成后删除或吸收。 当原型回答了它的问题后，要么删除它，要么将经过验证的决策折叠到真实代码中——不要让它腐烂在仓库中。

完成后

原型中唯一值得保留的是_答案_。将其捕获到持久的地方（提交消息、ADR、issue 或原型旁边的 NOTES.md）以及它正在回答的问题。如果用户在身边，该捕获是一次快速对话；如果不在，留下占位符，以便他们（或你，在下一次传递时）可以在删除原型之前填写裁决。