module-design-gate

name	module-design-gate
description	对当前 SDD 工作流指定的正式《{AR编号}-{需求短名}-{模块名}模块详细设计说明书.md》和独立《{AR编号}-{需求短名}-{模块名}模块测试用例设计.md》进行质量门禁检查，围绕证据链、边界链、执行链、验证链和风险链判断成果物是否足以进入后续 AICoding。当前需要确认详设和测试设计是否可进入 AICoding、发现阻断问题、生成整改清单、驱动回到 ASIS、TOBE 或测试设计补齐并多轮复检时使用。门禁阶段不得编辑正式说明书或测试设计正文；配套 `.context.md` 用于证据、过程复核和门禁记录，不得替代正式成果物中的开发和验证指导内容。

SDD 模块设计门禁

阶段规则

本 skill 自身定义门禁阶段必须遵守的规则，可独立检查正式说明书；无论由何种入口调用，均以本 skill 的规则作为 Gate 阶段唯一执行依据。

运行方式

本 skill 应由当前主 Agent 直接执行，不要通过 SubAgent 启动；遇到需要用户或上游确认的问题，应在当前会话及时问询，避免 SubAgent 的运转模式导致问询滞后。

如果当前环境提供 ask_user 工具，影响门禁结论、有限准入范围、核心设计或验收阈值的待确认项必须优先用 ask_user 发起问询，并在门禁结果或 .context.md 中记录问题、回答、影响范围和处理结论；工具不可用时，才退回当前会话问询或标记为 需前置确认。

门禁不检查“章节是否写满”，而检查正式说明书和测试设计是否满足七个准入维度。Gate 的准入结论以维度化门禁结果为准；五链检查、严格探索和采样记录只用于支撑维度判断，不得绕过未达标维度直接给出通过。

七个准入维度是：

• 证据充分性。
• 边界清晰性。
• 决策定稿性。
• 契约完整性。
• 工程可执行性。
• 验证闭环性。
• 风险处置性。

五链是维度检查的证据结构，不是独立于维度的第二套准入体系：

• 证据链：需求/AR -> ASIS 证据 -> TOBE 决策。
• 边界链：模块边界 -> 职责分配 -> 交互约束。
• 执行链：TOBE 决策 -> 工程落点和开发视图 -> 后续 AICoding 可拆分。
• 验证链：TOBE 决策 -> 可测试性输入 -> 覆盖目标 -> 测试用例 -> 断言/观察点。
• 风险链：触发风险 -> 缓解设计 -> 验证/回退。

维度与五链的主要对应关系：

• 证据充分性、决策定稿性主要由证据链支撑。
• 边界清晰性主要由边界链支撑。
• 契约完整性、工程可执行性主要由执行链支撑。
• 验证闭环性主要由验证链支撑。
• 风险处置性主要由风险链支撑。

成果物协作规则

• 正式成果物命名为 {AR编号}-{需求短名}-{模块名}模块详细设计说明书.md，例如 AR07758-支持快速退款接口相关功能-支付审计模块详细设计说明书.md。
• 过程上下文命名为 {AR编号}-{需求短名}-{模块名}模块详细设计说明书.context.md。
• 需要综合之前的其他设计成果物进行审视
• xxx模块详细设计说明书 只是占位名；同一轮 SDD 工作流中必须解析为同一个正式说明书和同名前缀 context 文件。
• 本 skill 不得创建、编辑或覆盖正式说明书中的任何章节。
• 本 skill 不得创建、编辑或覆盖测试设计成果物中的任何章节。
• 本 skill 在 .context.md 中的写入边界是门禁结论、五链摘要、阻断问题、整改清单、阻塞说明、ASIS 采样记录、TOBE 反证探索、测试设计反查、详细五链检查、多轮复检记录和审计材料。
• 本 skill 可以读取 ASIS、TOBE、测试设计和风险章节，但不得直接覆盖其正文。
• 只有工作流、用户或成果物拆分规则明确要求时，门禁结果才写入独立门禁成果物；否则优先写入同名前缀 .context.md 的门禁过程章节，或在当前会话返回。若由 aaw-workflow 编排调用，必须写入工作单 output 指定的独立门禁结果文件，通常为 ./.sdd/{SR}/{AR}/{AR}-{需求短名}-{模块组名}模块设计门禁结果.md。
• 门禁引用的需求/AR 编号、TOBE 决策编号和契约编号必须来自正式说明书；覆盖目标、测试用例和测试缺口编号必须来自独立测试设计；ASIS 证据编号必须能在同名前缀 .context.md 的证据索引中反查。
• 如果某项开发必需内容只存在于 .context.md，正式说明书门禁必须判定为不通过，问题类型为 EXECUTION 或对应链路问题。
• 如果某项验证必需内容只存在于 .context.md 或会话说明，测试设计门禁必须判定为不通过，问题类型为 EXECUTION 或 RISK ，关联维度为 验证闭环性。
• 正式说明书必须是面向用户、评审和开发的标准交付件；若正式说明书包含 ASIS 检索过程、证据编号表、TOBE 推导过程、反证记录、门禁采样、追踪矩阵等过程性内容，或必须阅读 .context.md 才能理解设计结论，门禁必须判定为不通过，问题类型为 EXECUTION。
• 测试设计必须是面向测试实现和验证执行的标准交付件；正式测试设计不要求暴露目标抽取、风险分级、用例合并等推导过程。Gate 不检查“是否写了过程”，而是从最小充分测试集、覆盖矩阵、用例可执行性和缺口回流反推测试设计质量。若测试用例只写“补充单测”“验证异常”“覆盖兼容”等概要，缺少输入、前置条件、断言、观察点或建议位置，门禁必须判定验证闭环性不通过。

强制工作步骤和 todo-list

Gate 阶段有偷懒风险，必须显式使用 todo-list 类工具跟踪检查过程，例如当前环境可用的 update_plan、TODO 工具或等价任务清单。没有可用工具时，必须在当前回复或 context 中维护“门禁待办清单”，并逐项标记状态。

开始门禁前必须创建至少包含以下项目的 todo-list：

1. 定位正式说明书、测试设计和同名前缀 context。
2. 复核上一轮阻断问题、整改项、待确认项和阻塞项。
3. 建立门禁输入索引，并检查 ASIS 探索任务、查证结果、主 Agent 复核吸收、证据充分性、边界清晰性和决策定稿性。
4. 检查契约完整性和工程可执行性。
5. 检查验证闭环性和风险处置性。
6. 执行五链反查和严格探索，寻找会推翻维度结论的反例。
7. 汇总未达标维度、阻断问题、整改清单，输出门禁结论和下一轮重试条件。

执行过程中必须在完成每个合并步骤后更新 todo-list 状态，并在维度化门禁检查表中逐项判定七个适用维度。不得在七个适用维度未逐项判定的情况下直接给出 通过、不通过 或 阻塞 结论。

门禁结论

门禁结论只能是：

• 通过：所有适用维度均达标，阻断问题为 0，可进入 AICoding。
• 不通过：存在必须整改的问题，需回到 ASIS、TOBE、测试设计或上游设计对齐。
• 阻塞：缺少必要输入、代码、上游决策，或连续返工仍因同一外部缺口无法推进。

门禁还必须给出明确的门禁建议，用于指导下一轮重试：

• 可进入 AICoding：所有适用维度达标，且阻断问题为 0。
• 回 ASIS 补证据后重试：证据充分性未达标，或 ASIS 证据不能支撑 TOBE。
• 回 TOBE 补设计后重试：决策定稿性、契约完整性、工程可执行性、风险处置性未达标，或验证闭环性未达标且根因是 TOBE 可测试性输入不足。
• 回测试设计补用例后重试：验证闭环性未达标，且根因是测试设计未形成最小充分验证集、覆盖矩阵或可执行用例。
• 先做上游/用户确认：核心方案、模块边界、接口归属、数据归属、验收阈值或跨模块职责仍需外部确认。
• 拆分范围后有限进入 AICoding：未达标维度不影响某个独立子范围，且正式说明书已明确隔离该子范围的任务、边界和验证方式。
• 阻塞，缺少必要输入：无法完成门禁判断所需的正式说明书、context、代码、架构边界或上游决策。

除 拆分范围后有限进入 AICoding 的受限场景外，只要存在任一适用维度未达标，门禁结论不得为 通过。

维度化门禁建议

门禁必须按以下维度输出 达标 / 未达标 / 不适用 ，并为每个未达标维度给出发现、影响、建议返工阶段和下一轮重试通过条件。维度检查是准入主判定；五链检查、严格探索和采样记录用于支撑、解释或反证维度结论。

维度	关注点	未达标时默认建议
证据充分性	需求、ASIS 结论、证据索引是否足以支撑 TOBE	回 ASIS 补证据后重试
边界清晰性	模块边界、职责、不承担范围、跨模块关系是否清楚	回 ASIS 或上游架构确认
决策定稿性	正式说明书是否仍存在影响实现的建议、可选、如有需要、待定或待确认项	回 TOBE 补设计后重试
契约完整性	新增/修改的函数、接口、DTO、配置、错误码、路径规则等是否有名称、位置、签名/字段、类型、调用方、错误语义和兼容策略	回 TOBE 补设计后重试
工程可执行性	TOBE 是否给出工程落点、契约、流程、异常、配置和风险处理，足以后续 AICoding 拆分任务	回 TOBE 补设计后重试
验证闭环性	测试设计是否覆盖每个关键设计目标、失败路径和触发风险，并给出输入、前置条件、断言、观察点和建议位置	回测试设计补用例；若 TOBE 缺可测试性输入则回 TOBE；若缺现状测试证据则回 ASIS
风险处置性	触发的安全、兼容、回滚、性能、并发、观测风险是否有缓解、验证和回退	回 TOBE 补设计后重试或上游确认

维度未达标的常见判定：

• 影响实现的“建议 / 可选 / 如有需要 / 推荐 / 尽量 / 是否需要 / 待定”没有被明确标为非阻断改进项。
• 只写“抽一个 helper”“增加校验”“优化错误文案”“实现上述方案”，但没有写清契约、调用边界或完成判定。
• 关键目标或风险缓解没有对应测试用例、断言、观察点或人工验证步骤。
• 测试设计机械枚举测试类型或一设计点一用例，导致 P2/低价值用例挤占 P0/P1，且没有说明合并覆盖或最小充分策略。
• .context.md 中存在影响实现的待确认项，但正式说明书或门禁结论没有把它转成阻断问题。
• 关键开发信息只存在于 .context.md，正式说明书自身不能指导编码。

工作流程

1. 定位成果物

• 读取当前 SDD 工作流指定的正式说明书；若正式说明书路径未指定或文件不存在，门禁状态为 阻塞，不得用占位文件名替代正式说明书进行准入判断。
• 读取当前 SDD 工作流指定的测试设计文件；若测试设计路径未指定或文件不存在，门禁状态为 不通过 或 阻塞，建议为 回测试设计补用例后重试 或 阻塞，缺少必要输入。
• 读取同名前缀 .context.md 作为证据和过程复核材料，但不得把 context 中独有的开发信息视为正式说明书已满足。
• 读取之前的其他设计成果物对正式说明书进行综合审视
• 从正式说明书读取需求/AR、TOBE 设计、工程落点、可测试性输入、待确认问题和阻塞项；从测试设计读取覆盖目标、测试用例、断言方式、覆盖矩阵、测试缺口和阻塞项；从同名前缀 .context.md 读取 ASIS 结论、ASIS 探索任务清单、探索任务结果汇总、主 Agent 复核与吸收记录、证据索引、历史门禁结果、上一轮阻断问题、整改清单、复检记录和复核材料。
• 如果正式说明书或 .context.md 中存在上一轮未关闭的阻断问题、整改项、待确认项或阻塞项，必须纳入本轮门禁输入，不得只检查当前正式说明书快照。

2. 按维度检查证据充分性

判断需求/AR 是否能追溯到 ASIS 证据和 TOBE 决策：

• 关键 ASIS 结论是否有证据编号。
• 证据编号是否能在证据索引中反查。
• 关键需求和 TOBE 决策是否能追溯到 ASIS 探索任务。
• ASIS 探索任务是否有查证结果；未完成任务是否写明原因、影响和下一步输入。
• TOBE 引用的 ASIS 事实是否经过主 Agent 复核吸收。
• ASIS 结论状态是否在 .context.md 中保留为事实/推断/待确认/阻塞相关。
• 推断、待确认、低置信度、未完成任务、未经复核吸收或阻塞相关结论是否被 TOBE 错当成事实。
• TOBE 关键决策是否能在 .context.md 中反查 ASIS 证据。
• 正式说明书是否用用户可读的现状约束摘要承接关键 ASIS 约束，而不是输出内部证据编号或检索过程。
• 纯新增场景下，不要求 ASIS 提供不存在的既有实现证据；但必须提供模块边界、新增对象不存在的检索证据、相邻同类实现或不存在相邻实现时可替代的模块惯例证据。

必须进行 ASIS 倾向采样。至少抽查 3 个 ASIS 结论；少于 3 个则全查。高风险、大规模、跨模块、低置信度、边界冲突、规格漂移、未完成探索任务或核心链路影响时，必须风险加抽。

3. 按维度检查边界清晰性

判断模块边界和职责是否约束住设计：

• 模块边界是否来自当前工作区 .sdd/software_architecture.md 的直接声明；不得接受代码结构、README、根目录 software_architecture.md、softWare.md、用户口述或“明确推断”作为模块边界来源。
• 本模块承担和不承担的内容是否清楚。
• TOBE 是否越界承担其他模块职责。
• 跨模块交互是否符合模块影响性分析和模块间交互设计。
• 是否引入循环依赖、跨层调用、外部模型穿透、共享状态扩散、旁路写入或隐式耦合。

存在跨边界改动时，必须检查防腐层、DTO/模型翻译、依赖方向和禁止穿透内容。

4. 按维度检查决策、契约和工程可执行性

判断 TOBE 是否能交给 AICoding 执行：

• 每个关键 TOBE 决策是否落到工程位置。
• 纯新增场景下，TOBE 是否承接 ASIS 中的模块边界、相邻同类实现或模块惯例，而不是脱离现状约束凭空设计。
• 正式说明书是否包含被触发的包图、类图、业务流程图、对外接口、内部接口、数据库变化、配置变化等开发视图。
• 正式说明书是否作为标准交付件自洽可读，不包含 ASIS 检索过程、证据编号表、TOBE 推导过程、反证记录、门禁采样、追踪矩阵等过程性内容。
• 用户输入、上游设计、模块交互、ASIS context 或已有正式说明书中已经明确给出的接口定义、方法/函数签名、入参出参、DTO/字段、JSON/序列化名称、错误码、状态值、Topic、Path、配置项和数据结构，是否在正式说明书中原样或结构化等价保留。
• REST 接口变化是否包含 method、path、权限、请求、响应、错误码和兼容性。
• Kafka/MQ 接口变化是否包含 topic、producer/consumer、消息结构、key、幂等、重试、死信和兼容策略。
• 内部 Java 接口或抽象变化是否包含调用方、实现方、方法签名、入参出参、异常语义和扩展约束。
• 数据库变化是否包含表/字段/索引、约束、默认值、迁移/回填、兼容和回滚。
• TOBE 是否足以支撑后续 AICoding 流程拆分任务；Gate 不检查 TOBE 中的任务表，因为 TOBE 阶段不得生成任务拆分。
• TOBE 是否说明具体工程落点、函数/类型/调用点、契约、异常语义、配置和完成判定所需设计信息。
• 新增或修改的函数、接口、DTO、配置、错误码、路径规则等是否给出名称、所在文件/包、导出性或可见性、签名/字段/类型、调用方、错误语义和兼容策略。
• 正式说明书中是否仍有影响实现的“建议 / 可选 / 如有需要 / 推荐 / 尽量 / 是否需要 / 待定”；若有，是否已明确标为非阻断改进项且不影响当前 AICoding 范围。
• 测试设计中的覆盖矩阵是否能从 TOBE 决策/契约/风险追踪到测试用例和断言/观察点；ASIS 证据追踪保留在 .context.md。
• 每个关键设计目标是否都有测试用例、断言、观察点或人工验证步骤；关键失败路径不能只写成可选测试。
• 是否存在无法被测试设计覆盖的关键设计；若原因是 TOBE 缺设计输入，验证链不通过并要求回 TOBE。
• 字段、DTO、接口、配置项、事件名、状态值、错误码、topic、path、时间单位和 JSON/序列化名称是否在摘要、类图、流程图、接口表、数据设计、工程落点、可测试性输入、测试设计和风险章节中保持一致。

任务过大、改动位置不清、测试不可执行时，执行链不通过。

5. 按维度检查验证闭环性

判断测试设计是否把 TOBE 变成可执行验证：

• 测试设计是否以最小充分验证集为策略，而不是输出测试用例大全。
• 每个需求点是否覆盖主路径、关键失败路径、关键边界/兼容路径；若合并覆盖，覆盖矩阵是否说明清楚。
• 每个 P0/P1 TOBE 决策、契约、失败路径或触发风险是否被至少一个测试用例覆盖，或有明确阻塞原因。
• 每条 P0/P1 测试用例是否包含建议位置、前置条件/Fixture/Mock、输入/触发步骤、预期结果、断言方式和观察点。
• 测试用例是否能反查正式说明书中的 TOBE 决策、契约、流程、异常边界、风险或可测试性输入。
• 测试层级选择是否合理：单元测试覆盖规则和边界；模块内功能集成测试覆盖同一模块/包内业务流程和多类协作；契约、兼容、数据、配置、观测和风险专项只在 TOBE 触发时补充。
• 是否存在机械爆炸：一设计点一用例、重复场景过多、P2 用例过多、低风险验证挤占关键路径。若存在且影响 P0/P1 清晰度，验证链不通过或进入非阻断改进项。
• 测试设计是否显性记录无法覆盖的缺口，并给出回 TOBE、回 ASIS、上游确认或继续测试设计的建议。
• 测试设计是否避免替 TOBE 补设计；若测试设计自行发明 TOBE 未定义的错误码、字段语义、状态流转或阈值，必须判定不通过。

6. 按维度检查风险处置性

只检查被触发的风险专题，不要求所有专项表都填满：

• 架构防腐化。
• 安全增强。
• 性能增强。
• 日志可观测性。
• 兼容、迁移与回滚。
• 并发、事务与幂等。

每个触发风险都必须有缓解设计、验证方式和必要回退策略。未触发专题应有简短不适用说明。

6.1 检查前置问询

• 影响模块边界、核心方案、数据/权限/兼容策略、性能目标、验收阈值或任务拆分的待确认项，是否已在 ASIS 或 TOBE 阶段触发问询。
• 如果没有问询条件，成果物是否标记为 需前置确认 并阻止相关决策定稿。
• 如果待确认项可能推翻当前设计，不得给出真实 AICoding 准入通过结论。

6.2 检查遗留问题闭环

• 读取上一轮门禁阻断问题、整改清单、复检记录、正式说明书待确认问题、正式说明书阻塞项、ASIS 待确认问题、ASIS 阻塞项和 TOBE 部分完成/阻塞说明。
• 遗留问题必须保留原始编号、来源轮次和来源章节；本轮可以增加本轮跟踪编号，但不得用新编号覆盖或掩盖原始问题编号。
• 每个遗留问题必须有明确闭环状态：已关闭、转为非阻断、仍阻断 或 阻塞。
• 标记为 已关闭 的问题必须能反查到正式说明书章节、.context.md 证据/推导记录、ASIS/TOBE 更新记录或外部输入确认；只有口头说明或“已处理”字样不得视为闭环。
• 标记为 转为非阻断 的问题必须说明不影响 AICoding 准入的理由、剩余风险和后续跟踪位置。
• 标记为 仍阻断 或 阻塞 的问题必须继续进入本轮阻断问题或阻塞说明，并明确不可进入 AICoding 或仅允许的有限范围。
• 上一轮遗留问题未逐项复核时，本轮门禁不得给出 通过 结论。

7. TOBE 严格探索和测试设计反查

门禁要主动探索 TOBE 正确性，不只读表格：

• 模拟后续 AICoding 拆分：从正式说明书抽取工程落点和关键契约，判断是否能在不读取 .context.md、不追问用户的情况下拆出编码任务；不能则归类为 EXECUTION 阻断。
• 架构反证：是否可构造出边界腐化或依赖方向错误的反例。
• 替代方案对比：是否存在更小、更贴合现有架构的方案。
• 主流程追踪：入口到副作用是否走通。
• 失败路径追踪：至少覆盖输入异常、外部依赖失败、部分成功或回退场景中的适用项。
• 可测试性追踪：是否能从 TOBE 的可测试性输入追踪到测试设计中的覆盖目标、用例和断言。
• 测试设计反查：抽取每个 P0/P1 测试用例，核对它是否有明确输入、前置条件、预期结果、断言方式、建议位置，并能反查 TOBE 决策或契约。
• 最小充分性反查：抽取覆盖矩阵中的 P0/P1 目标，判断是否被少量高价值用例覆盖；若存在明显可合并却拆散的低价值用例，或关键目标被大量弱用例稀释，应判定验证链不通过或给出整改建议。
• 契约一致性追踪：抽取关键字段、DTO、接口、配置项或事件，沿摘要、设计变量表、图、表、工程落点、可测试性输入和测试设计逐项核对类型、单位、默认值、序列化名称和兼容语义。
• 契约保真追踪：抽取上文已经明确给出的接口定义或方法签名，核对正式说明书是否保留完整签名、每个入参出参、字段名、JSON 名称、错误码和来源；若正式说明书只保留自然语言概要，必须判定执行链不通过。

探索发现的问题必须进入阻断问题或非阻断改进项。

8. 输出门禁结果

加载 <skill-dir>/references/gate-result-template.md，输出门禁结论、门禁建议、维度化门禁检查、五链门禁结果、遗留问题闭环复核、ASIS 采样、TOBE 探索、测试设计反查、阻断问题、整改清单和复检记录。门禁结果写入 .context.md、工作流指定的独立门禁结果文件或作为当前会话结果返回，不写入正式说明书或测试设计正文。

阻断问题只分四类：

• EVIDENCE：证据不足或不确定性被伪装成事实。
• BOUNDARY：边界、职责、交互或防腐化不成立。
• EXECUTION：TOBE 不足以支撑后续 AICoding 拆分、测试设计不可执行、验证不可追踪，或正式说明书丢失上文已经明确给出的接口契约、方法签名、入参出参、DTO/字段等开发必需信息。
• RISK：触发风险没有缓解、验证或回退。

每个阻断问题必须关联至少一个未达标维度，并写明下一轮重试通过条件。

9. 流程结束 / 工作流衔接

本 skill 产出门禁结论（通过 / 不通过 / 阻塞）、门禁建议和整改清单，写入 .context.md 或当前会话。门禁是 SDD 设计阶段的终点：通过 则成果物交付给后续 AICoding；不通过 或 阻塞 则回流到 $module-asis-analysis / $module-tobe-design / $module-test-design 整改后复检。

多轮复检规则

门禁不通过时：

1. 生成整改清单。
2. 判断每个整改项应回到 ASIS、TOBE、测试设计、上游设计对齐还是模块间交互设计。
3. 如果当前 agent 能补齐，回到对应阶段更新对应成果物后重新门禁：ASIS 只更新 .context.md，TOBE 更新正式说明书并补充 .context.md 推导过程，测试设计只更新独立测试用例设计文件。
4. 如果不能补齐，标记阻塞并说明需要的输入。
5. 复检时保留轮次记录，说明完成项、待闭合问题和整改要求。
6. 下一轮门禁必须先复核上一轮遗留问题闭环情况；未闭环的问题不得丢失、重编号后掩盖或从阻断问题中静默移除。

质量标准

结束前确认：

• 门禁结论是 通过、不通过 或 阻塞 之一。
• 已输出门禁建议，且建议与未达标维度一致。
• 已使用 todo-list 类工具或等价清单逐项执行并更新门禁检查状态。
• 已按证据充分性、边界清晰性、决策定稿性、契约完整性、工程可执行性、验证闭环性、风险处置性逐项给出 达标 / 未达标 / 不适用。
• 已检查 ASIS 探索任务清单、探索任务结果汇总和主 Agent 复核与吸收记录；关键 TOBE 决策没有依赖未完成或未经复核吸收的 ASIS 查证结果。
• 五条链均有明确结论。
• 上一轮遗留问题、整改项、待确认项和阻塞项均有闭环状态和证据；未逐项复核时不得通过。
• 阻断问题与非阻断改进项分离。
• 每个阻断问题都有明确返工阶段和整改要求。
• 每个未达标维度都有下一轮重试通过条件。
• 通过时明确说明可进入 AICoding。
• 不通过或阻塞时明确说明不可进入 AICoding，或仅允许哪些有限范围进入 AICoding。

引用文件

• 门禁结果模板：<skill-dir>/references/gate-result-template.md
• 可选检查清单：<skill-dir>/references/gate-checklist.md

完成后回调

若不处于 aaw-workflow 编排中，请忽略此节。

本 skill 由 aaw-workflow 编排调用。交付件生成后：

1. 将门禁结果写入工作单 output 指定的门禁结果文件。

2. 若门禁结论为 通过，构造数据文件并执行工作单中的 commands.done；如果返回 state=awaiting_user_confirm，停止并让 aaw-workflow 询问用户是否放行到 task-split：

   {
     "gate_result": "pass",
     "recommendation": "可进入 AICoding",
     "report": "门禁结果文件路径或摘要"
   }
   

3. 若门禁结论为 不通过，不要推进到 task-split。保持当前 gate step 未完成，按整改清单原地修正 ASIS/TOBE/测试设计成果物后重新执行 gate。必要时可提交 {"gate_result":"fail"} 获取 CLI 拒绝提示。

4. 若门禁结论为 阻塞，不要推进到 task-split。补齐门禁结果中列出的必要输入后重新执行 gate。必要时可提交 {"gate_result":"blocked"} 获取 CLI 拒绝提示。

5. 不要自动执行 aaw rollback。只有用户明确要求重走上游节点，或已经生成了需要废弃的下游 step 时，才使用 rollback。

不记得 SR 号 → 先 aaw status --json