-
建立技术影响面矩阵：frontend、backend、domain、API、data、auth/security、config/delivery、jobs、observability、reliability。
-
把每个影响面标成 yes / no / unknown：
no 必须写跳过理由。unknown 如果会改变架构、数据、安全、成本或上线风险，停止并向用户澄清。- 低风险未知可以写入 assumptions，但必须说明后续验证点。
-
生成读取计划：先列本次实际读取的 wiki 入口、代码入口、上游 / 下游和缺口，再列实际读取的子模块、profiles 和官方基准入口。
- 存量项目只沿 wiki 指向的模块、API、数据、测试和运行链路读取代码。
- 若 wiki 入口不足但本次需要确认既有符号、调用关系、API handler、数据写入路径或受影响测试，先运行
node .specforge/core/scripts/graph-freshness.mjs --json；只有 fresh / ready 的图事实才能写入 Graph Facts 或 Architecture Contract，stale / unavailable 只能作为低置信线索并要求 steering / code-intelligence 补证。
- wiki 缺入口、过期或与代码冲突时，停止并路由
sf-steering，不要在本阶段临时全量探索。
-
无技术影响时，写 N/A 结论：例如纯文案、纯 UI 视觉调整、无工程改动的配置说明，并说明验证方式。
-
建立需求追踪表，确保关键需求能落到技术方案或明确不适用。
-
执行技术选型全量访谈协议。该门禁发生在详细 technical design 之前；未确认时只输出分批确认卡并停止，不继续展开架构、API、数据、NFR 或任务拆解：
- 铁律：任何
[NEEDS TECH/DEPENDENCY/TOOLING DECISION] 维度未确认 → 不得写架构设计正文。
- 第一步：影响面扫描（内部，不输出给用户）：先从 requirements / brief / wiki 判断哪些维度适用（前端、后端、数据库、队列/任务、AI/LLM、文件存储、部署、测试栈等），并标记为
reuse、confirmed 或 pending。
- 第二步：生成分批确认卡（只包含 pending 维度，每批等用户确认后再输出下一批）：
- 第一批：架构级决策（部署平台、后端运行时、数据库、认证方案）。
- 第二批：前端工程（前端框架、包管理器、UI组件库、样式方案、状态管理、表单验证）。
- 第三批：测试栈与工程工具（单元/集成测试、E2E测试、API测试、CI/CD）。
- 第三步：新增依赖与工具链确认卡：超出 profile 推荐范围的新增依赖需单独确认。
- 未经确认的关键技术、新增依赖、工具链分别标记为
[NEEDS TECH DECISION]、[NEEDS DEPENDENCY DECISION]、[NEEDS TOOLING DECISION]。
- 用户确认后，在上游/本级 artifact 写入
[TECH DECISION CONFIRMED] / Tech Direction Status: confirmed，新增依赖写入 [DEPENDENCY DECISION CONFIRMED]，工具链写入 [TOOLING DECISION CONFIRMED]（或对应的 delegated_default / existing_stack 状态）。
-
执行当前版本事实检查：
- 新增 / 替换框架、SDK、云服务、数据库、部署平台、AI provider、测试工具或安全相关依赖时，必须查询当前官方文档或项目锁文件中的版本事实。
- 记录
version / source / date / decision impact；无法联网或资料不足时写风险和待确认项。
- 只是沿用现有项目版本时，记录证据路径，例如 lockfile、package manifest、wiki 或代码入口。
-
选择 Tech Profiles，说明采用、部分采用或偏离理由；项目已有技术栈以 wiki 和代码事实优先。
-
对齐规则主基准：按影响面使用对应规则入口内的唯一主基准，并写清采用点、偏离理由和验证证据；无相关影响面时写 N/A。
-
填写 Design Quality Gate，确认设计规模、现有架构复用、新增依赖确认、更简单方案、契约可测试性和 tasks 可拆性。
-
按 architecture-contract.md 选择最小架构视图：Context / Container / Component / Runtime sequence / Data flow / Deployment Ops；只选本次需要的视图，不为完整而堆图。
-
中高风险、跨模块、长期维护、数据、安全、运行或质量属性决策写 ADR 摘要；ADR 必须包含 context、options considered、outcome、consequences、confidence 和 revisit trigger。低风险小改写 N/A 和理由。
-
按影响面展开工程设计，只展开 yes 的章节；no 的章节保留一行 N/A，不写空表：
