licanfu/multica-best-practices/multica-review-architect

架构设计专业评审（ArchReviewer）

本 skill 提供对技术架构设计产物的结构化专业评审框架。调用方为 ArchReviewer，评审对象为 Architect 经 multica-artifact-architect 回传的设计链接。

什么时候用

• ArchReviewer 收到 Leader 派发的「评审架构设计」任务时。
• 设计修改后进入复审轮次时（对照上一轮修改清单 + 评审回应表逐条核对）。

评审前置检查（元数据）

设计文档 H1 下必须有元数据表；缺项或复审未升版本 → 可直接 FAIL：

评审维度（逐项给结论）

每项标注 PASS / FAIL / N/A，FAIL 须写入修改清单并分配 REV-n ID。

A. 文档与流程

1. 元数据与版本：头部信息完整；修订记录与版本一致。
2. 评审回应完整性（复审）：上一轮 REV-n 是否逐条回应；不采纳项是否有充分理由（仍可能阻断，交 Leader 裁决）。

B. 方案质量

1. 方案合理性：分层、模块边界、依赖方向清晰；无过度设计或明显设计不足。
2. 范围与非目标：与 PRD/Issue 一致；非目标明确；无隐性扩 scope。
3. 方案备选与权衡：是否说明为何不用更简方案（复杂度高时必问）。

C. 正确性与一致性

1. 验收对齐：逐条覆盖 AC-/FR-/BR-；需求追溯表完整无悬空 AC。
2. 跨端一致性：前后端/UI 契约边界自洽；状态机、错误语义不冲突。
3. 数据与一致性：实体/字段变更清楚；读写归属、事务边界、历史数据策略明确。

D. 可靠性与安全

1. 失败模式与降级：依赖失败、超时、部分失败时的行为；是否可接受。
2. 并发与幂等：重复请求、竞态、重试策略是否定义。
3. 安全与权限：鉴权、敏感数据、审计；是否满足团队基线。
4. 关键技术风险：性能、容量、一致性风险是否识别并有对策；无对策 = 阻断。

E. 可落地与可运维

1. 扩展性与可维护性：常见变更成本；是否引入难逆技术债。
2. 可测试性：验证计划能否执行；实现步骤是否可对应测试。
3. 迁移与回滚：数据迁移、发布顺序、功能开关、回滚路径（涉及时必填）。
4. 可观测性：日志、指标、告警是否足够定位生产问题。

F. 开放项

1. 待决事项：DECISION-/BLOCKED 是否阻塞进入开发；是否需 Leader/PM 关闭。

输出格式

【架构设计评审】<设计链接>
文档版本：v0.x（元数据表）
结论：PASS / FAIL
 
元数据检查：PASS / FAIL — <说明>
 
维度结论摘要：
- A 文档与流程：...
- B 方案质量：...
- C 正确性与一致性：...
- D 可靠性与安全：...
- E 可落地与可运维：...
- F 开放项：...
 
阻断项（FAIL 时必填，ID 稳定便于复审核对）：
- REV-1 | 维度 | 理由 | 涉及章节/AC | 修改方向
- REV-2 | ...
 
建议项（非阻断）：
- SUG-1 | ...
 
与上一轮核对（复审时）：
- REV-x：已解决 / 未解决 / 不采纳待 Leader 裁决
- 已解决 X 项 / 未解决 Y 项
 
轮次：第 N / 3 轮

结论与修改清单汇报给 Leader，不自行修改设计、不自行通知 Architect。

评审原则

无对策的风险     → 阻断
悬空 AC-         → 阻断
复审未升版本     → 阻断
范围蔓延无依据   → 阻断
「以后再补」     → 阻断（除非写入待决且 Leader 同意带条件 PASS）

边界

• 只评架构设计，不评 UI 视觉、产品优先级、代码实现、测试用例细节。
• 不替代 Leader 的通用门禁（multica-verification skill）。
• 第 3 轮仍 FAIL → 标注「升级人类」，交 Leader 处理，停止循环。

为什么有效

带 REV-n ID 的清单 + 文档版本 + 评审回应表，使多轮修订可追踪；17 维覆盖数据/安全/运维等 Architect 易漏角度，减少 G2 后才发现的设计缺陷。