RedGranite before-build：动手前的判断关卡
何时用
设计已定、代码还没写：新项目脚手架、demo、新子系统、大功能首次实现。实现中途遇到具体问题时直接用对应维度 skill。
硬规则
- MUST 写第一行实现代码前完成判断记录并交用户确认。
- MUST 八个维度逐一判断，只写
适用（证据 + 具体后果）与待定（谁回答什么）；不适用的省略，仅当其前提可能变化时写一句（见 context-legibility）。 - NEVER 写"已考虑""无明显问题"这类无证据结论。
- MUST 判断记录含 MVP 边界与验证计划（见 minimal-viable）。
- MUST 判断记录只写在回复里，不另建文件；本次实现以它为约束。
- NEVER 因维度 skill 未安装而跳过该维度；按下表核心问题作答。
审问清单
| 维度 | 核心问题 | 细则 skill |
|---|---|---|
| 自研边界 | 哪部分是 commodity、哪部分是 core differentiation？官方 SDK / 库 / 成品查过没？ | build-vs-buy |
| 复用 | 已有哪些定义可复用？新定义是否重复？做接口还是一次性方法？ | ssot-reuse |
| 并发 | 会并发跑吗？同一状态会被多 request / webhook / worker 同时改吗？竞态怎么建模？ | concurrency-modeling |
| 工程评审 | 异常路径？组件间状态一致？可观测？tech debt 在哪、谁维护？ | engineering-review |
| spec | 接口、状态、critical path、非目标写清了吗？ | spec-first |
| 守卫 | 哪些规则应确定化：lint、CI、e2e、状态机约束？ | guardrails |
| MVP | 边界在哪？edge case 与复杂度如何取舍？验证做哪几项？ | minimal-viable |
| 平台 | 当前平台有哪些已知兼容问题？已出现编码异常时再排查。 | powershell-utf8 |
反模式
- 错误：brainstorm 完直接起项目，并发问题上线后暴露。→ 正确：先答"同一订单状态会被支付回调和用户操作同时改吗"，答"会"就先定状态机。
- 错误：判断记录写"并发：已考虑，暂不处理"。→ 正确："并发：不适用——单进程 CLI，无共享状态"或"待定——需产品确认是否多设备同时登录"。
- 错误：八个维度全写"适用"，堆一页分析。→ 正确：不适用的不写，适用的给证据与决策。
输出要求
判断记录直接作为回复，格式固定：
## 建设前判断记录（YYYY-MM-DD）
| 维度 | 结论 | 证据 / 理由 |
|---|---|---|
| 并发 | 适用 | 支付回调与用户取消会同时改订单状态；不处理会重复退款。用状态机 + 幂等键 |
| 自研边界 | 适用 | 支付用 Stripe SDK；核心是分账规则引擎，自研 |
| 守卫 | 待定 | 需你确认：有 CI 吗？没有则 e2e 只做本地脚本 |
### 决策
1. 订单状态用状态机，转移表见 spec §x
### MVP 边界
做：…；不做：…
### 验证计划
1. e2e：下单 → 支付回调 → 状态 paid，跑一次
末尾一句：请确认以上判断，确认后进入实现。