loft

Loft

形状未定，不裁钢板。 造船师按 1:1 放样船体线型，并在裁下第一块钢板前把线型修顺。Loft 把同样的次序用于设计问题：当语言已经用尽——两个都说得通、但都无法靠讨论证伪的答案——就造一个廉价的可运行产物，让船长对它作出反应，再把这份反应折进决策。

角色契约。 船员负责制造产物；船长的唯一职责是作出反应——而那份反应就是决策。产物是用于观察的仪器，绝不是交付物的先行版本。

何时该 loft

• 设计问题在文字中卡住：反复改写措辞，仍然无法定论（"路径页面该长什么样"、"这个状态模型感觉对吗"）
• 导航员地图上带有一张 loft 工单
• 规格讨论走到"得先看到它才行"

不要在以下情况 loft：

• 问题可以从仓库证据中回答，或通过询问船长回答（那是访谈，不是 lofting）
• 目的地本身还不明确（那是迷雾——/oh-my-claudecode:ask-navigator）
• 答案已经存在于某份 ADR 中（不要对已定的决策重新 loft）
• 所谓"设计问题"其实是 bug（那属于调试器的管辖范围）

选择分叉

按问题在问什么来选。选错分叉会浪费掉整个产物。

逻辑分叉——模型对吗？

针对关于状态、业务规则、数据形状或算法的问题（"重考时解锁会回退吗？"、"这个 reducer 在边界情况下站得住吗？"）：

1. 把承载决策的核心——状态机、reducer、schema 或算法——隔离成一个纯模块：没有 DOM、没有 I/O、没有框架。写成一旦形状确认，就能原封不动地移入真实代码库。
2. 把它包进一个可点击的 HTML 外壳：每个场景一个按钮，棘手的边界情况按顺序逐一走一遍，每次点击后完整状态可见。
3. 确认后，该模块即可直接搬运——它通过 launch 作为真实工作重新进入。在 loft 本身进行期间，main 保持不变，外壳留在分支上。

UI 分叉——它该长什么样？

针对形状与排布的问题（"步骤还是卡片？"、"进度放在哪里？"）：

1. 一条路由，三个结构上互不相同的变体——信息架构、导航模型、密度。只在样式上不同的变体什么也回答不了：三份换皮就是壁纸。
2. 页面上的切换器循环切换变体；尽可能嵌入现有产品，让真实的数据密度去考验设计，而不是三行整齐的假数据。
3. 确认后，决策被转移，变体留在分支上，作为它为何长成这样的记录。

纪律

• 一条命令即可运行——用仓库现有的最简启动命令；如果 file:// 模块 CORS 会碍事，就把模块内联进外壳。几秒内加载完成；除仓库已有的之外不引入任何构建步骤。
• 不做持久化、不写测试、不做抽象、除happy path 外不做错误处理。产物应当是那种你不希望发布的东西——这些规则的存在就是为了让它保持那样。
• 预期第一个形状会遭到反驳：在同一会话内于分支上修订。船长确认最终形状才算决策；一个没人反驳的产物，通常回答的是一个没人提过的问题。
• 产物的整个生命周期是几分钟构建、一次会话决策。如果它开始长成生产代码，停下：那是 launch 的工作，不是 loft。沉没成本正是这项技能存在的意义——防止它发生。
• 一次 loft 只回答一个问题。两个问题是两次 loft——或者说一个问题其实是两个。

收拢答案

产物是证据，不是落地页。当负责人作出反应时：

1. 把决定记录在它所属的地方 —— issue 评论、规格的 Implementation Decisions，或待定决定笔记 —— 用负责人自己的话，加上一行说明原因。比散文更精确的片段（reducer、状态机、schema）可以内联在那里，并标记为 lofted。
2. 把产物推送到 loft/<name> 分支。它永远不会合并：它保持为未来读者在决定的“为什么”变得重要时可以打开的主要来源。
3. 产物中的任何内容都不会落到 main —— 对于逻辑分叉，已确认的模块通过 launch 作为真正的工作重新进入；对于 UI 分叉，真正的页面根据决定从零构建。

范围与非目标

• Loft 产出的是答案，而不是交付物：没有运行时，没有状态文件，没有任何常驻运行的东西。
• 它不进行诊断（debugger），不绘制迷雾图（/oh-my-claudecode:ask-navigator），不批准自己的答案（负责人的反应是唯一的验收）。
• 它不替代接缝审批：lofted 的 UI 只展示形态；它的测试接缝仍然在 C2 审批。

完成定义

负责人作出了反应，答案位于决定所属之处，产物位于其分支上 —— 并且产物中没有一行在 main 中。