run-spike

运行尖峰

运行尖峰是一次性代码，唯一作用是回答一个设计问题。问题决定了它的形式。

选择分支

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

• “这套逻辑 / 状态模型是否站得住脚？” → LOGIC.md：一个交互式终端应用，基于纯逻辑模块构建，用户可以手动操作。
• “它应该是什么样子？” → 必需的子技能：使用 draft-ui——UI 分支现在就是这项技能：通过切换器展示多个各不相同的真实 HTML 变体、进行评审迭代，并锁定 ui-brief。UI.md 是指引文件。

选错分支会浪费整个运行尖峰。如果确实无法判断，且联系不上用户，就按邻近关系选择（后端模块 → 逻辑；页面或组件 → UI），并在运行尖峰开头记录这一假设。

逻辑分支规则

1. 从第一天起就作为一次性代码，并明确标记。 把它放在正在探索的代码附近，便于理解上下文，但要通过命名避免被误认为是生产代码（在路径或文件名中使用 run-spike）。遵循项目现有约定——切勿为它另建顶层结构。
2. 只需一条命令即可运行。 使用项目现有的任务运行器注册它（如果有 docs/agents/project.md，请从中读取命令）。用户无需多想就能启动它。
3. 不做持久化。 状态保存在内存中。持久化是运行尖峰要验证的想法，而不是它依赖的东西。如果问题明确涉及存储，就使用临时存储，并以一眼就能认出是“run-spike — 可安全清除”的名称标记。
4. 略过打磨。 将逻辑以内联、硬编码的方式写出，用尽可能少的代码回答问题——不写测试，只添加足以保证它能运行的错误处理。快速获得认知才是全部目的。
5. 展示内部状态。 每次操作后都显示所有相关状态。隐藏状态就会隐藏答案。
6. 得到答案后立即停止。 一旦问题得到解答，就删除运行尖峰。运行尖峰不写任何生产代码，即使操作人员邀请你提前动手也不例外：下一步是 plan-tasks，等评审解决答案中尚未明确的问题后再进行，且答案中要写明这一点。接受过这种邀请的 4 次运行中，有 4 次都写了 src/latefee.ts。其中一次还改接了 src/invoice.ts（归 Minh 所有）和公共 API，以适应“周四评审前的当日 marina-local”，而它自己的答案明明把这个问题留待周四评审处理。另一次未经询问就修改了 Approved 设计的决定 2。提前准备应该是一份已准备好供批准的计划，而不是一段之后还得撤销的代码。

答案是唯一交付物

运行尖峰的代码之后毫无意义——只有它带来的认知有价值。将问题和答案记录在某个持久位置：ADR（如果满足 define-domain 中的 ADR 门槛）、功能的 requirements.md 中的一项需求，或删除运行尖峰的提交说明中。如果用户不在场无法给出结论，就在运行尖峰旁留下一个明确标记的占位符，确保删除前将其补全。