# Architecture Design

> 由 pre-development 在领域调研后调用的 CTO 架构综合与红白队对抗流程，定稿模块、接口、数据、安全、失败模式、迁移、可观测性和测试性。用户明确要求架构设计时也可直接使用。不创建 Linear Milestone / Issue。

- Skill: `jsonlee12138/architecture-design` (Agent Skill)
- Install (CLI): `npx skillmds@latest add jsonlee12138/architecture-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jsonlee12138/architecture-design/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: jsonlee12138 (https://skillmd.com/u/jsonlee12138)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jsonlee12138/architecture-design

---


# Architecture Design（CTO 架构综合）

把需求基线、PRD、领域调研和现有代码综合成可实现、可测试、可运行的架构方案。日常技术分歧由 CTO 裁决，不逐项询问老板。

## 契约

- 读取 `intake.md`、关联 PRD、全部领域报告、已有 ADR 与项目约束。
- 缺少关键领域证据时，先调用 `tech-research` 补齐，不凭空设计。
- 产出 `architecture.md` 和必要 ADR；不创建 Linear 内容，不定正式交付计划。
- 架构约束交付顺序，但 Milestone 按可验收用户价值切分，不按模块一一对应。

## 流程

1. **白队方案**：各领域负责人基于调研提出推荐方案、契约、风险和备选。
2. **CTO 初步综合**：消解重复责任和跨领域冲突，形成一套端到端推荐设计。
3. **独立红队攻击**：通过 `subagent-routing` 实际调用 `architecture_red_team`。L2 仅在公共契约、不可逆、安全、数据或交付升级信号存在时选择一个最高信息增益 focus；L3 必须分别执行 `architecture` 与 `delivery`，再按风险追加 `failure_modes` 与 `security`。每个实例只攻击一个 focus、只找问题，不验证或修复方案。
4. **白队回应**：把 Finding 定向返回原 `frontend_architect`、`backend_architect`、`data_architect`、`security_auditor`、`reliability_engineer`、`qa` 或 `uiux_design` 领域负责人；逐条接受、部分接受或反驳，并给出证据和修改建议。白队不创建独立 Agent。
5. **CTO 裁决**：标记 `resolved`、`accepted_risk`、`owner_decision` 或 `rework`；必须记录理由。
6. **定稿**：更新架构与 ADR，向下游提供稳定的设计输入。

每个红队 focus 和白队回应都必须有 `dispatch_receipt`。红队与对应白队、实现者的 invocation identity 必须不同；artifact fingerprint 漂移后旧 receipt 失效。required 派发失败时 Gate 为 `BLOCKED`，主 Agent 不得自行补写一段“红队意见”后继续。

## architecture.md 必含内容

| 章节 | 最低要求 |
|---|---|
| 目标与约束 | 需求目标、架构原则、非目标、已知限制 |
| 现状与变更边界 | 复用、替换、新增及明确不动的部分 |
| 模块与职责 | 每个模块的职责、非职责、依赖、唯一属主 |
| 接口契约 | 输入输出、版本、权限、错误语义、幂等/重试 |
| 数据模型与数据流 | 来源、转换、存储、生命周期、一致性、隐私 |
| 安全与权限 | 身份、授权、审计、威胁与控制 |
| 失败模式 | 超时、部分失败、并发、降级、恢复、灾难场景 |
| 非功能性 | 性能、容量、可靠性、兼容性、可访问性 |
| 迁移与回滚 | schema/数据/配置迁移、验证、回退边界 |
| 发布与可观测性 | 灰度、指标、日志、追踪、告警、运行责任 |
| 测试性 | 测试边界、替身/夹具、契约点、E2E 入口 |
| 决策记录 | 选项、推荐、偏离调研理由、ADR 引用 |
| 红白队记录 | 发现、回应、CTO 裁决、残余风险 |

图可按项目习惯使用，但必须同时有可检索的文字和表格契约，不能让图成为唯一信息载体。

## 打断条件

只有互斥业务方向、预算/合同授权、不可逆数据决策、安全合规风险接受或范围—期限—质量取舍需要老板决定。其他开放问题由 CTO选择推荐默认值并写明影响。

## 红线

- 没有领域证据就直接选型。
- 红队与白队使用相同立场或结论，形成伪对抗。
- 一个 `architecture_red_team` 实例同时承担多个 focus，或让红队自己修复、裁决 Finding。
- 没有真实 dispatch receipt 却在文档中声称完成独立红队/白队。
- 发现被静默丢弃，或把普通技术偏好上交老板。
- 缺少迁移、回滚、可观测性、失败模式或测试性且不说明不适用理由。
- 用模块边界直接决定 Milestone 边界。

## 完成检查

- [ ] 端到端边界、契约、数据、权限和失败恢复闭合。
- [ ] 调研分歧和偏离理由已裁决。
- [ ] 风险要求的每个红队 focus 均有独立 receipt、白队回应与 CTO 状态。
- [ ] 迁移、发布、回滚、监控和测试性可执行。
- [ ] 残余风险进入风险登记，权限问题进入 CTO 汇报。
- [ ] 未创建 Linear Milestone / Issue。