prototype

name	prototype
description	构建一次性原型来回答设计问题。当用户想要快速验证状态模型或逻辑是否感觉正确，或探索 UI 应该长什么样时使用。

原型

原型是回答问题的一次性代码。问题决定形态。

选择分支

识别正在回答哪个问题 — 从用户提示、周围代码或用户在线时通过询问来判断：

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

两个分支产生截然不同的产物 — 选错会浪费整个原型。如果问题确实模棱两可且用户不在线，默认选择更能匹配周围代码的分支（后端模块 → 逻辑；页面或组件 → UI），并在原型顶部陈述假设。

适用于两者的规则

1. 从一开始就是一次性的，并清楚标记。 将原型代码放在它实际将被使用的位置附近（靠近它正在原型化的模块或页面旁边），这样上下文是明确的 — 但命名时让随意读者能看出它是原型，而非生产代码。对于一次性 UI 路由，遵循项目已有的任何路由约定；不要发明新的顶层结构。
2. 一条命令运行。 无论项目现有任务运行器支持什么 — pnpm <名称>、python <路径>、bun <路径> 等。用户必须能毫不费力地启动它。
3. 默认不持久化。 状态驻留在内存中。持久化是原型正在_检验_的东西，而非它应该依赖的东西。如果问题明确涉及数据库，用一个标记着"PROTOTYPE — 请清除我"的临时数据库或本地文件。
4. 跳过润色。 没有测试，没有超出使原型_可运行_的错误处理，没有抽象。重点是快速学到东西然后删除它。
5. 呈现状态。 每次操作后（逻辑）或每次变体切换时（UI），打印或渲染完整的相关状态，让用户看到什么发生了变化。
6. 完成后删除或吸收。 当原型回答了它的问题时，要么删除它，要么将已验证的决策整合到真实代码中 — 不要让它烂在仓库里。

完成后

_答案_是原型中唯一值得保留的东西。将其捕获到某个持久的地方（commit 消息、ADR、issue，或原型旁边的 NOTES.md），连同它所回答的问题。如果用户在线，这只是一个快速对话；如果不，留下占位符以便他们（或你，在下一轮）能在删除原型之前填上结论。