一句话

跨函数边界的代码先把调用方用法、类型签名和模块边界画成草图，用 arena 出多个候选设计综合后再填实现；实现证明设计错了就推翻重来。

何时用

• 适合：要写跨越函数边界、动 ownership 或分层的代码；非平凡设计想先看两个以上结构不同的候选。
• 不适合：形状已定的机械改动；纯配置或文档。想要 checkpoint 审设计需显式说 with checkpoint。

怎么用

/architect 先设计导入管线再写代码，我最关心调用方怎么用

1. Ground：对波及的子系统跑 pstack-how；设计动了归属或分层时加跑 pstack-why。
2. Sketch：跑 pstack-arena，至少两个结构不同的候选，逐个过 references/design-red-flags.md 再综合。
3. Agree：默认不 checkpoint，直接进实现；/architect with checkpoint 才停下来给你签字。
4. Implement：草图是合同，偏离是要上报的信号，不默默吸收。
5. Scrap：同类 workaround 反复出现、类型要靠 any 才能编译等模式说明设计错了，重跑 how 后回 Phase B。

产出

• 调用方用法草图加类型签名（小改动一个文件，大改动模块图加类型定义），以及按 rationale-template.md 写的 rationale 与综合决定。

要点与坑

• 「先写调用方用法再推类型」是硬顺序。综合出的设计可以直接作为一个 commit 落地（scaffold first）。
• 设计阶段想要对抗压力，可在综合稿上跑 pstack-interrogate。
• 依赖 Cursor 的 Task 子代理和 pstack-models.mdc 的 architect runners 行；在 Devin CLI 里只能借鉴五阶段流程，用本机子代理模拟 arena。

关联

• 上游：pstack-how、pstack-why · 下游：pstack-arena、pstack-interrogate
• 所属：00-pstack-概览