prototype

name	prototype
description	构建可丢弃的原型，用来回答一个设计问题。适用于用户希望快速验证状态模型或逻辑是否合理，或探索 UI 应呈现什么样子时。

原型

原型是用来回答问题的可丢弃代码。问题本身决定原型应采用什么形态。

选择分支

先确定当前要回答的问题。可以根据用户的提示、周围代码判断；用户在线时，也可以直接询问：

• “这套逻辑或状态模型是否合理？” → 阅读 LOGIC.md。构建一个小型交互式终端程序，让状态机经历那些仅靠纸面推演很难判断的场景。
• “它应该长什么样？” → 阅读 UI.md。在同一个路由中生成几种差异足够明显的 UI 方案，并通过 URL 查询参数和底部悬浮切换栏在各方案之间切换。

两个分支会产出完全不同的成果。选错分支，整个原型都会失去价值。问题确实含糊、用户又暂时无法联系时，根据周围代码选择更匹配的分支：后端模块通常选择逻辑原型，页面或组件通常选择 UI 原型。必须在原型顶部明确写出这一假设。

两个分支都适用的规则

1. 从第一天起就把它当作可丢弃代码，并清楚标明这一点。 将原型放在未来真正使用该设计的位置附近，例如对应模块或页面旁边，使上下文一目了然；同时通过命名明确告诉普通读者，这是原型，不是生产代码。一次性 UI 路由应遵循项目现有的路由约定，不要另外发明顶层目录结构。
2. 只需一条命令即可运行。 使用项目已有任务运行器支持的形式，例如 pnpm <name>、python <path>、bun <path>。用户启动原型时不应再做额外判断。
3. 默认不做持久化。 状态保存在内存中。持久化可以是原型要验证的对象，但不应成为原型运行的依赖。问题明确涉及数据库时，使用临时数据库，或使用名称中清楚写有 “PROTOTYPE — wipe me” 的本地文件。
4. 省略打磨工作。 不写测试，不添加超过“保证原型能运行”所需的错误处理，也不建立抽象层。目标是快速得到结论，然后删除原型。
5. 展示完整状态。 逻辑原型在每次操作后输出相关状态；UI 原型在每次切换方案时渲染相关状态，使用户能够直接看到变化。
6. 得到结论后删除或吸收。 原型回答问题后，要么删除它，要么把已经验证的决策纳入正式代码。不得任由原型长期留在仓库中腐化。

完成时

原型唯一值得保留的是它给出的答案。将答案和原型原本要回答的问题一起记录在可长期保存的位置，例如提交信息、ADR、Issue，或原型旁边的 NOTES.md。用户在线时，可以通过一次简短对话完成记录；用户不在线时，应留下待填写位置，让用户或下一次处理此任务的你在删除原型前补充最终结论。