design-gate

设计关卡

将“此处适用哪种设计视角？”转化为一个小型、基于证据的路由决策，然后仅应用选定的视角，并将其发现合并为一个结论。本技能是路由的权威依据。它不会另创一套评审方法，也不会召集评审团。

有关工作流阶段边界以及通过此关卡后使用的实用技能，请阅读 shared/references/workflow-stage-routing.md。

工作流

1. 根据计划、Slice Contract 或变更范围识别阶段和涉及的表面。在任务规划期间，对共享的功能决策评估一次，并为每项任务分类其适用性和剩余风险。当多个任务共用已确定的结论时，使用 shared/references/planning-reuse.md。实施前，沿用继承的约束；仅当证据改变设计表面时才重新路由。
2. 仅针对尚未解决的决策或发生变化的风险选择视角。如果范围、权威依据、假设和来源修订版本一致，则按 ID 复用已确定的决策。匹配的任务表面无需重复调用视角；应分别分类其剩余风险和安全风险。先为核心风险选择最多三个范围明确的视角。当另一个重大风险需要覆盖时，记录其范围理由，并在当前角色中应用该范围明确的视角。仅当风险需要当前角色无法提供的专业知识或独立性时，才在获批的路由下委派专家；否则明确保留阻塞项。视角数量本身既不要求委派，也不意味着可以减少覆盖范围。对于本地变更，没有匹配的行即表示无需经过关卡。
3. 在当前协调者或实施者中，以只读流程应用每个选定的视角。独立专家需要处理重大风险或尚未解决的问题。委派前，使用 shared/references/model-preview.md 复用或获取一份具体且获批的路由快照。向其提供计划或设计问题、涉及的文件和边界，以及下文定义的规范关卡结果。此响应将取代该视角独立的简报、编辑或实施路由。独立的最终代码评审仍是单独的工作流要求。
4. 合并结果。任何带有具体、关键性发现的 revise 都会使关卡结论变为 revise。外观问题或推测性发现仅供参考。
5. 出现 revise 时，将所需的计划变更列为简短的编号清单。当各视角揭示出真实且尚未解决的权衡时，设置 verdict: revise，设置 decision_required，然后停止。绝不要在本技能中调用 models-consensus。如果需要更多意见，用户可以单独调用它。

路由表

变更涉及	视角技能
尚未确定的整体系统风格	macro-architecture
业务词汇、有界上下文或领域上下文之间的关系	domain-driven-design
服务拆分或服务／数据所有权	macro-architecture
本地模块的布局、内聚性或依赖方向	architecture-lens
单个上下文内的业务逻辑结构（聚合、不变量、事件）	domain-driven-design
代码结构选择、可扩展性、不断膨胀的条件分支	design-patterns
范围压力，或存在实际权衡的相互竞争的局部结构	architecture-lens
模块／类／API 接口设计——深度、信息隐藏、接口复杂度	software-design-philosophy
持久化状态、数据库、队列、缓存、迁移、重试、并发、外部 API	data-systems-coding-lens
分布式应用的容器／进程拓扑——边车、ambassador、适配器、负载均衡副本、分片、scatter/gather、FaaS 适用性、所有权选举、工作队列、批处理工作流	distributed-systems-patterns
以事件流作为事实来源——采用或迁移到事件驱动微服务、Kafka/Pulsar/Kinesis 主题、事件架构、编排与协同、CDC/outbox 数据解放	distributed-systems-patterns（事件驱动路线）、data-systems-coding-lens
所构建的事物本身就是一个 Agent——LLM 工具调用循环、多 Agent 流水线，或需要持久化状态、中途审批或重放的长时间运行自主任务	agent-architecture-lens
React 状态放置、渲染、副作用或异步行为	advanced-react
新建或重新设计面向用户的流程、信息层级或设计系统	ui-ux-pro-max
两种或更多存在实际权衡的竞争方案	architecture-lens

**兜底行（仅在上述各行均不适用时）：**没有适用的特定视角，但变更在架构上影响重大 → 将 architecture-lens 用作 Lens 1 权衡评审（指出相互制约的 2–4 项特征、实际选项及各选项的代价），并采用 全做或全不做 ADR，然后使用 architecture-lens/references/adr-template.md 中的标准 ADR 模板记录。不要将此项与上述各行搭配使用——当变更影响重大却无法归类时，才使用此兜底项，而不是将其作为并列视角。

没有适用的行，且变更在架构上影响不重大 → 该变更属于局部变更；返回 proceed，并附注“无需设计门禁”，不要凭空添加评审。

输出约定

阅读 shared/references/gate-result.md，并返回其中规定的标准门禁结果。合并或重新检查时，保留阻断性和建议性问题的 ID、状态、解决证据及评审重点。在任务获批前解决阻断性问题、必需变更和重大决策；使用 shared/scripts/gate_contract.py 验证带版本的记录。安全分类应与 security-gate 分开处理。实现引擎接收这些约束；它不会重新执行每项视角评审。

注意事项

1. 针对每项重大决策或风险选择相应视角，并限定其审查范围。
2. 不要让视角技能修改任何内容；门禁只读。
3. 不要因风格观点而阻断；只有会改变边界、数据所有权、契约或正确性的发现才构成阻断。
4. revise 修复后，不要重新执行完整门禁。只重新应用提出阻断性问题的视角。
5. 不要使用共识小组来打破平局。门禁可以指出需要作出决策，但不能代替用户决定偏好。

当重大风险或未解决的问题需要独立专家评估时，应在全新的上下文中向其提供范围明确、反映当前决策的材料包及源代码定位信息。仅针对该专家提出的阻断性问题复查时，才复用其角色上下文。不要将完整的产品讨论分叉到范围狭窄的门禁审查中。确保覆盖每项重大风险，并保留路线审批边界。