Architecture Design(CTO 架构综合)
把需求基线、PRD、领域调研和现有代码综合成可实现、可测试、可运行的架构方案。日常技术分歧由 CTO 裁决,不逐项询问老板。
契约
- 读取
intake.md、关联 PRD、全部领域报告、已有 ADR 与项目约束。 - 缺少关键领域证据时,先调用
tech-research补齐,不凭空设计。 - 产出
architecture.md和必要 ADR;不创建 Linear 内容,不定正式交付计划。 - 架构约束交付顺序,但 Milestone 按可验收用户价值切分,不按模块一一对应。
流程
- 白队方案:各领域负责人基于调研提出推荐方案、契约、风险和备选。
- CTO 初步综合:消解重复责任和跨领域冲突,形成一套端到端推荐设计。
- 独立红队攻击:通过
subagent-routing实际调用architecture_red_team。L2 仅在公共契约、不可逆、安全、数据或交付升级信号存在时选择一个最高信息增益 focus;L3 必须分别执行architecture与delivery,再按风险追加failure_modes与security。每个实例只攻击一个 focus、只找问题,不验证或修复方案。 - 白队回应:把 Finding 定向返回原
frontend_architect、backend_architect、data_architect、security_auditor、reliability_engineer、qa或uiux_design领域负责人;逐条接受、部分接受或反驳,并给出证据和修改建议。白队不创建独立 Agent。 - CTO 裁决:标记
resolved、accepted_risk、owner_decision或rework;必须记录理由。 - 定稿:更新架构与 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。