prototype

原型

原型是一次性代码，其唯一任务是回答一个设计问题。问题决定原型的形式。

选择分支

先明确问题——从请求、周边代码中识别，或直接询问：

• “这套逻辑／状态模型是否经得起考验？” → LOGIC.md：一个基于纯逻辑模块的交互式终端应用，用户可以手动操作。
• “它应该是什么样子？” → UI.md：同一屏幕的多个结构迥异的变体，可在浏览器中切换。

选错分支会让整个原型白费。如果确实难以判断且无法联系用户，就根据代码位置选择（后端模块 → logic；页面或组件 → UI），并在原型顶部记录这一假设。

两个分支都适用的规则

1. 从第一天起就是一次性代码，并明确标记。 将它放在所探索代码的附近，让上下文一目了然，但命名时要确保没人会把它误认为生产代码（路径或文件名中包含 prototype）。遵循项目现有约定——绝不要为它另建顶层结构。
2. 一条命令即可运行。 使用项目现有的任务运行器注册它（如果存在 docs/agents/project.md，请从中读取命令）。用户无需思考就能启动它。
3. 不做持久化。 状态保存在内存中。持久化是原型要验证的想法，而不是原型所依赖的东西。如果问题明确涉及存储，请使用名称醒目地标注“prototype — safe to wipe”的临时存储。
4. 跳过打磨。 将逻辑以内联、硬编码的方式编写，用最少的行数回答问题——不写测试，只添加足以让它运行的错误处理。快速获取认知才是全部目的。
5. 展示内部状态。 每次操作或切换变体后，都显示完整的相关状态。隐藏状态会掩盖答案。
6. 完成后删除或吸收。 问题得到解答后，删除原型，或将已验证的部分并入正式代码——必需的子技能：将其重新实现为生产代码时，使用 tdd；原型逻辑只是参考，不是经过测试的代码。

答案是唯一的交付物

原型代码本身之后毫无意义——只有它教会你的内容才重要。将问题及其答案记录在某个持久位置：ADR（若通过 domain-modeling 中的 ADR 门槛）、功能的 requirements.md 中的需求，或删除／吸收原型时的提交说明中。如果用户不在场，无法给出结论，就在原型旁留下一个明确标记的占位符，确保删除前将其补全。