prototype

name	prototype
description	构建一个可丢弃的原型来回答设计问题。当用户想要验证状态模型或逻辑是否合理，或探索 UI 应该长什么样时使用。

原型

原型是用于回答某个问题的可丢弃代码。问题决定了它的形态。

选择分支

确定正在回答的是哪个问题——从用户的 prompt、周围的代码，或通过询问用户（如果用户在附近）：

• "这个逻辑/状态模型感觉对吗？" → LOGIC.md。构建一个小的交互式终端应用，推动状态机遍历那些在纸上难以推理的场景。
• "这应该长什么样？" → UI.md。在单个路由上生成多个截然不同的 UI 变体，通过 URL search param 和浮动底部栏切换。

两个分支产生截然不同的产物——选错分支会浪费整个原型。如果问题确实模糊且用户无法联系，默认选择与周围代码更匹配的分支（后端 module → logic；页面或 component → UI），并在原型顶部说明你的假设。

两个分支都适用的规则

1. 从第一天起就是可丢弃的，并明确标记为可丢弃。 将原型代码放在它将实际使用的位置附近（在其原型设计的 module 或页面旁边），以便上下文显而易见——但命名方式要让随便的读者一看便知这是原型，而非生产代码。对于可丢弃的 UI 路由，遵循项目已有的路由约定；不要发明新的顶层结构。
2. 一条命令即可运行。 无论项目现有的 task runner 支持什么——pnpm <name>、python <path>、bun <path> 等。用户必须能够毫不费力地启动它。
3. 默认不持久化。 状态保存在内存中。持久化是原型要验证的东西，而不是它应该依赖的东西。如果问题明确涉及数据库，使用临时数据库或本地文件，文件名要清晰标记"PROTOTYPE — 用完即删"。
4. 跳过打磨。 没有测试，没有超出使原型可运行所需的错误处理，没有抽象。重点是快速学到东西。
5. 暴露状态。 每次操作后（logic）或每次变体切换时（UI），打印或渲染完整的相关状态，以便用户看到变化。
6. 完成后保留为第一手来源。 当原型回答了问题后，将验证过的决策纳入正式代码——然后将原型本身保留为第一手来源：提交到一个可丢弃的分支上（不在 main 上），并在实现 issue 上留下一个指向该分支的上下文指针。同时记录答案——结论和它解决的问题——记录在 issue 或提交信息中。Main 分支只保留已验证的决策。