一句话

方向还没定的数周工程：先在 issue tracker 上画一张决策地图，每个会话只解一张票拿决定，地图清空后移交 to-spec 进入 W3。

适用

• 适合：目标模糊、依赖未知、要靠调研加原型加访谈才能定方向的大项目。
• 不适合：需求已清楚只是工作量大（直接 W3-多会话功能）；一次性能做完的探索。

步骤

1. 画地图：matt-wayfinder 在 issue tracker 建 map issue 和一组 decision tickets，产出是决定，不是交付物。
2. 按票的类型选工具：
   • research 票：matt-research 派后台子代理对一手来源查证，可并行，主线只收回带引用的 Markdown 笔记。
   • prototype 票：matt-prototype 用一次性代码回答一个设计问题。
   • grilling 票：matt-grilling 把议题当设计树按轮问完 frontier，配 matt-domain-modeling 把敲定的词写进 GLOSSARY.md。
3. 每个会话只解一张票，新票新窗口 /clear；票之间的依赖由 map issue 承载，不靠在脑子里记。
4. 同期立规矩：addy-constraint-driven-development 写 CONSTRAINTS.md 定质量底线；接口边界用 addy-api-and-interface-design 加 matt-codebase-design 的词汇讨论；够格的决策用 addy-documentation-and-adrs 记 ADR。
5. 地图清空、通往 destination 的路清晰后，matt-to-spec 把决定综合成 spec，转入 W3-多会话功能。

token 与旋钮

• 省：目标收窄到一个 epic，地图只画当前 epic 的票。
• 标准：决策票串行解，research 票并行。
• 加强：多做原型、少写计划；每个对外部依赖的假设都配一张 research 票。

进入与退出

• 进入：一句话说不清验收，或依赖、架构、术语都有开放问题。
• 完成判据：map issue 上的 decision tickets 全部关闭，spec 写得出来。
• 之后：转 W3-多会话功能 拆票实现；命中高风险触发条件就叠 W6-高风险加固层。

常见坑

• 地图阶段就写实现代码，决定没定代码先烂。
• 一个会话连解多张票，上下文混了之后决定质量变差。
• 主线自己读调研原文；阅读交给子代理，主线只收摘要。

关联

• 入口：00-怎么选工作流 · 下游：W3-多会话功能 · 加固：W6-高风险加固层 · 调研也可走：W5-接手老项目与技术调研