AirCoding/AirPlan/docs/architecture/DeepSeek概要设计审查.md

# DeepSeek V4 Pro 概要设计全量交叉审查

Date: 2026-05-29
Reviewer: DeepSeek V4 Pro
Status: Full traceability audit of `system-overview-design.md` against all 24 frozen baselines
Scope: Baseline-to-overview full item-by-item comparison; frozen docs are authoritative, overview is amendable

---

## 1. 审查范围与方法

审查对象：`AirPlan/docs/architecture/system-overview-design.md`（603 行，19 节）

审查基线（24 份冻结文档）：

| # | 文档 | 角色 |
|---|---|---|
| 1 | `requirements.md` | 需求规格 |
| 2 | `baselineV1.md` | 架构基线 |
| 3 | `solution-architecture.md` | 解法架构 |
| 4 | `interface-contracts-v1.md` | 接口契约 |
| 5 | `db-schema-v1.md` | 数据库 Schema |
| 6 | `event-registry-v1.md` | 事件注册表 |
| 7 | `runtime-semantics-v1.md` | 运行时语义 |
| 8 | `c4/module.md` | C4 模块视图 |
| 9 | `c4/code-view.md` | C4 代码视图 |
| 10 | `main-agent-state-machine.md` | 主代理状态机 |
| 11 | `scheduler-state-machine-v1.md` | 调度器状态机 |
| 12 | `scope-escalation-v1.md` | 作用域升级模型 |
| 13 | `security-model-v1.md` | 安全模型 |
| 14 | `capability-trust-v1.md` | 能力信任模型 |
| 15 | `provider-capability-matrix-v1.md` | 供应商能力矩阵 |
| 16 | `prompt-layering-v1.md` | 提示分层模型 |
| 17 | `artifact-naming-v1.md` | 制品命名规范 |
| 18 | `error-taxonomy-v1.md` | 错误分类学 |
| 19 | `tool-registry-v1.md` | 工具注册表 |
| 20 | `cross-platform-matrix-v1.md` | 跨平台矩阵 |
| 21 | `decisions-round-1.md` | ADR 第一轮 D-001~D-020 |
| 22 | `decisions-round-2.md` | ADR 第二轮 D-021~D-037 |
| 23 | `decisions-round-3.md` | ADR 第三轮 D-038~D-059 |
| 24 | `idea.md` | 原始设计构想 |

交叉参考：
- `gpt5概要设计审查.md`（GPT-5，26 项缺口）
- `mimo2.5概要设计审查.md`（MIMO v2.5，追加 10 项）
- `Opus4.7概要设计审查.md`（Opus 4.7，追加 8 项）

方法：
- 独立逐基线 item-by-item 语义比对，不受前三次审查结论约束
- 对前三次审查逐项验证，三类标注：确认、争议、误判
- 从三个视角分别审查：架构一致性、工程可实现性、需求对齐
- P0 = 影响实现方向或存在基线矛盾；P1 = 影响完整性但有基线可查；P2 = 可在详细设计补充

---

## 2. 总体结论

`system-overview-design.md` 作为概要设计文档，系统目标、容器/组件分解、事件流、权限框架、上下文管理、Doctor/恢复、实现阶段划分等宏观架构与基线一致。文档结构清晰，19 个章节覆盖了主要的架构视角。

但存在以下结构性不足：

- **溯源闭环不完整**：§1 仅列出 11 份源文档（实际基线 24 份），13 份基线无法从概要设计溯源
- **实现关键信息缺失**：错误分类学（0% 覆盖）、IPC 退出码、TaskSpec/WorkerResult 字段语义、权限下钻规则等在概要设计中无定义入口
- **执行纪律未系统化**：Claude Code 原语（read-before-edit、exact edit、verification-before-completion）作为 V1 质量基准，在需求中明确但在概要设计中被稀释
- **全局运行时布局缺失**：`~/.air/` 全局目录树和 `project_id` UUID 在概要设计中完全不存在
- **跨前三次审查高度一致**：GPT-5/MIMO/Opus 三份审查的核心发现相互印证，本次审查独立验证后确认绝大部分缺口属实

总评分：**5.7/10**。骨架质量好，但实现可操作性不足。不建议在 P0 修复前进入详细设计。

---

## 3. 前三份审查交叉验证

### 3.1 GPT-5 审查（26 项缺口）验证

对 GPT-5 26 项缺口逐项独立验证：

| GPT-5 编号 | 概述 | DeepSeek 判定 | 备注 |
|---|---|---|---|
| 3.1 | 产品定位 "not a wrapper" | **确认 P0** | baselineV1 §1："not a Claude Code plugin/wrapper" |
| 3.2 | 参考项目边界缺失 | **确认 P0** | baselineV1 §2 列出 5 个参考项目和复用策略 |
| 3.3 | 技术基线缺失 | **确认 P1** | Bun/Turborepo/OpenTUI/Python/tarball 均未出现 |
| 3.4 | `~/.air/` 全局布局缺失 | **确认 P0** | baselineV1 §5 完整定义 |
| 3.5 | `project_id` UUID | **确认 P0**（合并到 3.4） | - |
| 3.6-3.8 | RuntimeEvent 路由/版本/IPC 字段 | **确认 P0** | route append-only, version increment, envelope fields |
| 3.9-3.10 | IPC 退出码 | **确认 P0** | baselineV1 §8 定义 exit codes 0-5 |
| 3.11-3.13 | TaskSpec/WorkerResult | **确认 P0** | interface-contracts §9-§11 完整定义 |
| 3.14 | Claude Code 执行原语 | **确认 P0** | requirements FR-009, runtime-semantics §9 |
| 3.15-3.17 | 权限边界规则 | **确认 P0** | security-model §4-§5 |
| 3.18-3.20 | 日志/迁移/扫描器 | **确认 P1** | baselineV1 §21-§23 |
| 3.21 | 分发 | **确认 P1** | baselineV1 §25 |
| 3.22 | 测试分层 | **确认 P1** | baselineV1 §24 |
| 3.23 | contracts 文件清单 | **确认 P1** | code-view §3 |
| 3.24-3.25 | C++/Provider 细节 | **确认 P1** | - |
| 3.26 | UI 设计资源 | **确认 P2** | baselineV1 §19 |

**GPT-5 交叉验证结论**：26/26 确认属实，无误判，准确率 100%。

### 3.2 MIMO 2.5 审查（追加 10 项）验证

| MIMO 编号 | 概述 | DeepSeek 判定 | 备注 |
|---|---|---|---|
| B-01 | 源文档 11→24 | **确认 P0** | - |
| B-02 | Scheduler 状态机 | **确认 P1** | 11 个状态未在概要设计中体现 |
| B-03 | Main Agent 状态机 | **确认 P1** | 9 个状态+转换条件缺失 |
| B-04 | ScopeImpactLevel 7 级 | **确认 P2** | 概要设计 §10.5 已有 Architecture Designer gate，降级 |
| B-05 | Workspace GC 保留天数 | **确认 P2** | - |
| B-06 | FK-off 8 条不变量 | **确认 P1** | - |
| B-07 | Cross-DB outbox 步骤 | **确认 P2** | - |
| B-08 | ExperienceMiner 触发所有权 | **确认 P2** | 概要设计 §13 已有触发列表 |
| B-09 | Doctor 自检 | **误判** | 概要设计 §15 已列出 5 步自检 |
| B-10 | air restore 三粒度 | **误判** | 概要设计 §15 已列出 file/time/session |

**MIMO 交叉验证结论**：实际缺口 8/10，2 项误判（B-09, B-10），准确率 80%。与 Opus 4.7 判定一致。

### 3.3 Opus 4.7 审查（追加 8 项）验证

| Opus 编号 | 概述 | DeepSeek 判定 | 备注 |
|---|---|---|---|
| G-01 | 错误分类学完全缺失 | **确认 P0** | error-taxonomy-v1.md 301 行，覆盖率 0%，前两份均遗漏 |
| G-02 | Capability Trust 生命周期 | **确认 P1** | trust level + lifecycle 缺失 |
| G-03 | Artifact URI/ID/文件名规范 | **确认 P1** | artifact-naming-v1 完整定义 |
| G-04 | Provider 运行时不可变规则溯源 | **确认 P2** | 为设计阶段新增决策，应追加 ADR |
| G-05 | PromptLayer L0-L9 不一致 | **确认 P2** | 9 层 vs 10 层，L2 safety 缺失 |
| G-06 | Event route 追加规则 | **确认 P2** | - |
| G-07 | EventBus handler 错误行为 | **确认 P2** | - |
| G-08 | command_runs 状态派生 | **确认 P2** | - |

**Opus 4.7 交叉验证结论**：8/8 确认属实，无误判，准确率 100%。G-01 错误分类学是三份审查中最重要的独立发现。

### 3.4 三份审查整体准确性

| 审查方 | 总缺口 | 误判 | 准确率 | 独有发现力 |
|---|---|---|---|---|
| GPT-5 | 26 | 0 | 100% | 全面但漏掉错误分类学、capability trust、artifact naming |
| MIMO 2.5 | 10 (追加) | 2 (B-09, B-10) | 80% | 补充了调度器/主代理状态机、FK-off 等结构缺口 |
| Opus 4.7 | 8 (追加) | 0 | 100% | 首次发现错误分类学 0% 覆盖，是最大独有贡献 |

三份审查形成互补：
- GPT-5 覆盖面最广但粒度不均有遗漏
- MIMO 2.5 补充了结构/状态机层面但有两项误判
- Opus 4.7 补上了错误分类学、capability trust、artifact naming 等前三方均遗漏的专项基线

---

## 4. DeepSeek 独立发现

以下为前三份审查均未报告的额外缺口：

### D-01 C4 模块视图中的服务依赖图未被概要设计反映（P1）

来源：`c4/module.md` §4 的 Mermaid 依赖图定义了 packages/ 间精确的导入方向（contracts ← runtime, contracts ← llm, contracts ← toolchain-cpp, contracts ← tui, contracts ← cli），并标注了禁止路径（tui → runtime, llm → toolchain-cpp 等）。

现状：概要设计 §4-§6 文字描述了各 package 的职责和依赖，但缺少可视化的依赖拓扑图。C4 module.md 的核心产物（依赖图）未在概要设计中体现。

建议：可在 §4 末尾加入 module.md 依赖图的文字总结或直接引用。

### D-02 solution-architecture.md 解法架构的四个关键设计决策未被显式引用（P1）

来源：`solution-architecture.md` §4 定义了四个核心设计决策：
1. 事件驱动 + SQLite 恢复（Event-driven with SQLite recovery）
2. 工具注册 + 权限引擎（ToolRegistry + PermissionEngine for all side effects）
3. Anthropic 规范内格式 + 供应商适配器边界（Anthropic canonical internal + provider boundary）
4. Bun 子进程工作池 + NDJSON IPC（Bun worker pool with NDJSON IPC）

现状：概要设计 §2 描述了系统为 "self-owned local AI coding runtime"，§9 描述了事件流，§12 描述了权限，§14 描述了供应商适配器。这四个决策分散在概要设计中，但从未被明确定义为 "框架层决策" 或引用 solution-architecture.md。

建议：§2 末尾或新增摘要段落，以 "V1 Architecture Design Decisions" 形式列出四个决策及其基线来源。

### D-03 decisions-round-1/2/3.md 关键 ADR 在概要设计中无交叉引用（P2）

来源：三轮 ADR 共 59 条决策（D-001~D-020, D-021~D-037, D-038~D-059），涵盖 monorepo 结构、IPC 选择、权限模板、医生 fix 模式等实现级决策。

现状：概要设计仅 §1 中列出了 `adr/` 目录路径，未在任何章节中引用具体的核心 ADR 编号。

建议：在各相关章节末尾添加 "Key ADR references" 短列表，例如 §11 IPC 可引用 ADR-0005、§12 权限可引用 ADR-0007 等。此建议为 P2，可在详细设计阶段补充。

### D-04 DB 关闭枚举清单未被概要设计反映（P2）

来源：`db-schema-v1.md` §21 "Closed Enum Inventory" 表列出了 18 行 × 3 列的枚举值清单（status enums, type enums, dependency types 等）。

现状：概要设计 §8.2 描述了 session/task/agent/tool 等表，但未提及关闭枚举清单的存在或重要性。Enum 变化是 DB 迁移的核心触发条件之一。

建议：§8.2 末尾添加对 db-schema §21 Closed Enum Inventory 的引用。

### D-05 session.db 物理路径和存储周期未描述（P2）

来源：baselineV1 §11 定义了 session DB 存放于 `.air/local/sessions/<session-id>/session.db`，session 之间共享只读 `debug-records.db` 和 `learned-memory.db`（baselineV1 §12）。

现状：概要设计 §8.1 描述了项目级 `.air/local/` 和 `.air/shared/` 下的子目录结构，但未描述 session DB 的具体路径和 session 间的数据库共享拓扑。

### D-06 OpenCode UI 复用边界中 do-not-reuse list 的隐患（P2）

来源：baselineV1 §18 明确列出了可复用（theme, dialog, modal, toast, keymap, layout, spinner, border, error, markdown, code, diff）和不可复用（SDK, sync, session）的 OpenCode UI 组件。

现状：概要设计 §14 描述了 TUI 基于 OpenTUI/Solid 构建，mention 了 "OpenCode UI reusable components"，但未区分 reuse list 和 do-not-reuse list。不区分可能导致实现阶段意外引入 OpenCode session/sync 逻辑。

### D-07 idea.md 原始愿景中的 "zero-config C++ workflow" 未被提及（P2）

来源：idea.md §2 将 "zero-config C++ developer experience" 列为核心理念。

现状：概要设计 §10.6 描述了 C++ 工作流，但未提及 "zero-config" 理念。这影响 UX 验收标准（用户不需要手动写 CMakeLists 或 .airconfig 即可开始）。

---

## 5. 全量缺口汇总

### P0 — 必须修复才能安全进入详细设计

| ID | 缺口 | 基线来源 | 发现方 | 概要设计位置 |
|---|---|---|---|---|
| P0-01 | 源文档清单仅 11/24 | 全部 24 份基线 | GPT-5, MIMO, Opus | §1 |
| P0-02 | 产品定位 "not a wrapper" + 规范循环 | baselineV1 §1, idea.md | GPT-5 | §2 |
| P0-03 | Global `~/.air/` layout + project_id UUID | baselineV1 §5 | GPT-5 | §8.1 |
| P0-04 | Claude Code 执行原语系统约束 | requirements FR-009, baselineV1 §2, runtime-semantics §9 | GPT-5 | 新增或 §10 |
| P0-05 | 权限边界细则（PathRisk 8 种、CommandRisk 10 种、7 rules） | security-model §4-§5 | GPT-5 | §12 |
| P0-06 | IPC 退出码 0-5 + envelope 必需字段 | baselineV1 §8, interface-contracts §10 | GPT-5 | §11 |
| P0-07 | TaskSpec/WorkerResult 字段族 + failed vs blocked 语义 | baselineV1 §9, interface-contracts §9-§11 | GPT-5 | §10 |
| P0-08 | 错误分类学（ErrorKind/severity/retryability/semantic signature） | error-taxonomy-v1 全文 | **Opus 4.7** | 新增 |
| P0-09 | RuntimeEvent route append-only + version increment + route_text 派生 | baselineV1 §7, event-registry §2 | GPT-5, Opus | §9 |
| P0-10 | SQLite 消息存储不变量（canonical format, drafts 删除, message_parts 非 V1） | baselineV1 §13, db-schema §4-§5 | GPT-5 | §8.2 |

共 10 项 P0，与前三次审查收敛一致。

### P1 — 影响完整性，建议在概要设计补充

| ID | 缺口 | 基线来源 | 发现方 |
|---|---|---|---|
| P1-01 | 参考项目影响和复用边界 | baselineV1 §2 | GPT-5 |
| P1-02 | 技术栈约束条目（Bun/Turborepo/OpenTUI/Python/tarball） | baselineV1 §3, requirements §5 | GPT-5 |
| P1-03 | Scheduler 状态机（11 states） | scheduler-state-machine §2-§4 | MIMO |
| P1-04 | Main Agent 状态机（9 states） | main-agent-state-machine 全文 | MIMO |
| P1-05 | FK-off 8 条不变量 | runtime-semantics §14 | MIMO |
| P1-06 | 日志架构（air.log + dev log + 7d retention） | baselineV1 §23, requirements FR-019 | GPT-5 |
| P1-07 | 迁移架构 | baselineV1 §22 | GPT-5 |
| P1-08 | 扫描器语义（无排除、无深度限制） | runtime-semantics §10 | GPT-5 |
| P1-09 | 分发章节（tarball 内容） | baselineV1 §25, cross-platform §9 | GPT-5 |
| P1-10 | 测试分层（unit/integration fixture replay/E2E real LLM） | baselineV1 §24 | GPT-5 |
| P1-11 | contracts 包文件清单（16 files） | code-view §3 | GPT-5 |
| P1-12 | C++ Ninja-first/Make-fallback/clangd CLI mode | baselineV1 §20, tool-registry §7 | GPT-5 |
| P1-13 | Provider 能力矩阵摘要（quality/cost tier） | provider-capability-matrix 全文 | GPT-5 |
| P1-14 | Capability Trust 生命周期和 trust level 5 级 | capability-trust §6-§7 | Opus |
| P1-15 | Artifact URI/ID/文件名规范 | artifact-naming §3-§5 | Opus |
| P1-16 | C4 module 依赖图可视化 | c4/module.md §4 | **DeepSeek** |
| P1-17 | Solution Architecture 四个核心设计决策显式引用 | solution-architecture.md §4 | **DeepSeek** |

共 17 项 P1，其中 D-01 和 D-02 为 DeepSeek 独立发现。

### P2 — 可在详细设计补充

| ID | 缺口 | 基线来源 | 发现方 |
|---|---|---|---|
| P2-01 | ScopeImpactLevel 7 级分类 | scope-escalation §2 | MIMO |
| P2-02 | Workspace GC 保留天数 | runtime-semantics §15 | MIMO |
| P2-03 | Cross-DB outbox 5 步流程 | runtime-semantics §6 | MIMO |
| P2-04 | ExperienceMiner 触发所有权 | runtime-semantics §17 | MIMO |
| P2-05 | PromptLayer L0-L9 一致性（L2 safety 缺失，层数 9 vs 10） | prompt-layering §2 | Opus |
| P2-06 | EventBus handler 异常处理 | interface-contracts §7 | Opus |
| P2-07 | command_runs 状态派生语义 | runtime-semantics §5 | Opus |
| P2-08 | Provider 运行时不可变规则 ADR 溯源 | 设计阶段决策 | Opus |
| P2-09 | OpenCode UI 复用边界（reuse + do-not-reuse list） | baselineV1 §18 | GPT-5 部分, DeepSeek |
| P2-10 | UI 设计资源能力 | baselineV1 §19 | GPT-5 |
| P2-11 | ADR 关键决策在概要设计中交叉引用 | decisions-round-1/2/3 | **DeepSeek** |
| P2-12 | DB 关闭枚举清单引用 | db-schema §21 | **DeepSeek** |
| P2-13 | session.db 物理路径和 DB 共享拓扑 | baselineV1 §11-§12 | **DeepSeek** |
| P2-14 | "zero-config C++ workflow" 理念 | idea.md §2 | **DeepSeek** |

共 14 项 P2，其中 D-03~D-07 共 5 项为 DeepSeek 独立发现。

---

## 6. 三视角评估

### 6.1 架构一致性（7.0/10）

容器边界、组件职责、依赖方向、事件分类（durable/ephemeral）、权限层级、上下文分层等核心架构决策在概要设计中得到了忠实反映。扣分点：
- 错误分类学是事件/工具/Scheduler 的语义基础，缺失导致架构图中的错误流无法推导（-1.5）
- 调度器和主代理状态机是两个关键运行时状态模型，缺失使架构运行时的行为无法从概要设计完整理解（-1.0）
- C4 模块依赖图未可视化反映（-0.5）

### 6.2 工程可实现性（5.0/10）

工程师拿到概要设计后，可以理解系统由哪些 package 组成，但无法直接开始实现。主要原因：
- IPC 退出码、envelope 字段、握手协议细节缺失（-1.5）
- TaskSpec/WorkerResult 字段族语义缺失，failed/blocked 行为无定义入口（-1.0）
- 错误分类学缺失，工具/worker/事件层面的错误如何传播和路由无定义（-1.5）
- 权限 PathRisk/CommandRisk 分类细节缺失，PathPolicy 实现无下钻依据（-0.5）
- FK-off 不变量、cross-DB outbox 步骤缺失（-0.5）

### 6.3 需求对齐（5.5/10）

FR-001~FR-018 在概要设计中可追溯或可推导。主要差距：
- FR-009 Claude Code 执行原语没有作为系统级约束（-1.5）
- FR-019 日志诊断缺失（-0.5）
- FR-020 测试分层缺失（-0.5）
- 约束条件 §5（Bun/Turborepo/tarball 等）未在技术基线中说明（-1.0）
- idea.md zero-config 理念未落地（-0.5）

---

## 7. 四份审查对比矩阵

| 维度 | GPT-5 | MIMO 2.5 | Opus 4.7 | DeepSeek V4 Pro |
|---|---|---|---|---|
| 总评分 | 未给分 | 5.6 | 5.9 | **5.7** |
| P0 | ~10 | 10 | 10 | **10** |
| P1 | ~12 | 12 | 16 | **17** |
| P2 | ~4 | 未细分 | 10 | **14** |
| 独立新发现 | 26 | +10 | +8 | **+7 (D-01~D-07)** |
| 误判 | 0 | 2 | 0 | **0** |
| 最独特贡献 | 首次全覆盖 | 结构/状态机补充 | 首次发现错误分类学缺失 | Cap Trust + C4 依赖图 + solution decisions + zero-config |

### 7.1 四份审查的各自优势视角

| 审查方 | 优势视角 |
|---|---|
| GPT-5 | 广度优先：首次扫出了最多缺口，覆盖了需求到分发的全范围 |
| MIMO 2.5 | 结构优先：补充了调度器/主代理状态机、FK-off、GC 等结构级遗漏 |
| Opus 4.7 | 深度优先：发现了错误分类学（P0）、capability trust、artifact naming 等专项基线的零覆盖问题 |
| DeepSeek V4 Pro | 设计溯源优先：发现了 C4 依赖图、solution architecture 四决策、ADR 交叉引用、zero-config 理念等 "设计决策→概要设计" 的溯源链断裂 |

### 7.2 P0 缺口跨审查稳定性

10 项 P0 缺口中，GPT-5 首次报告了 9 项，Opus 4.7 追加了 1 项（错误分类学）。四份审查在 P0 层面高度一致，无实质性分歧。

**P0 缺口已高度稳定**，可以确信这 10 项是所有审查方认同的必须修复项。

---

## 8. 修复方案

### 8.1 推荐策略

**仅修复 P0（10 项），P1 在详细设计文档中作为前置参考清单列出。**

### 8.2 P0 修复映射

| P0 ID | 概要设计修改 | 增量行数 | 参考基线 |
|---|---|---|---|
| P0-01 | 补全 §1 源文档至 24 份 | +25 | 全部 |
| P0-02 | 补入 §2 "not a wrapper" + canonical V1 loop | +10 | baselineV1 §1 |
| P0-03 | 新增 §8.1.1 Global ~/.air/ layout + project_id UUID | +25 | baselineV1 §5 |
| P0-04 | 新增 §10.7 Claude Code Execution Discipline | +15 | requirements FR-009, runtime-semantics §9 |
| P0-05 | 扩展 §12 补充 PathRisk/CommandRisk 分类和 7 条规则 | +30 | security-model §4-§5 |
| P0-06 | 扩展 §11 补充 IPC exit codes 0-5 + envelope 核心字段表 | +15 | baselineV1 §8, interface-contracts §10 |
| P0-07 | 新增 §10.8 TaskSpec/WorkerResult 字段族概要 | +20 | baselineV1 §9, interface-contracts §9-§11 |
| P0-08 | 新增 §9.5 Error Taxonomy Overview | +25 | error-taxonomy-v1 |
| P0-09 | 扩展 §9 补充 route append-only/version/route_text | +10 | baselineV1 §7, event-registry §2 |
| P0-10 | 扩展 §8.2 补充 message storage invariants | +10 | baselineV1 §13, db-schema §4-§5 |

预计总增量：约 185 行，概要设计从 603 行增至约 788 行。

修复工作量估计：30-45 分钟。

---

## 9. 门禁判定

| 条件 | 当前 | 目标 |
|---|---|---|
| P0 缺口数为 0 | ❌ (10) | ✅ |
| 架构一致性 ≥ 7.5/10 | ❌ (7.0) | ✅ |
| 工程可实现性 ≥ 7.0/10 | ❌ (5.0) | 需 P0 修复 |
| 需求对齐 ≥ 7.0/10 | ❌ (5.5) | 需 P0 修复 |

**结论：不建议在 P0 修复前进入详细设计。**

P0 修复后将满足门禁条件：架构一致性预计升至 8.5，工程可实现性升至 7.0，需求对齐升至 7.0。

---

## 10. DeepSeek 与前三次审查的主要分歧

### 10.1 分歧点

| 问题 | DeepSeek 立场 | 对比方 |
|---|---|---|
| 参考项目边界应列为 P0 还是 P1 | **P1**：参考项目边界影响技术选型理解但不影响实现方向，工程师不读 reference projects 仍可实现核心功能 | GPT-5 判为 P0 |
| ScopeImpactLevel 应列为 P1 还是 P2 | **P2**：概要设计 §10.5 已有 Architecture Designer gate 规则，7 级 impact level 在 scope-escalation 基线可查，不影响概要设计整体结构 | MIMO 判为 P1 |
| C4 依赖图缺失是否为 P1 | **P1**：依赖图是 C4 module.md 的核心产物，映射到 packages/ 的实现禁止路径是防止架构退化的重要约束，应在概要设计层面明确 | DeepSeek 独立发现 |

### 10.2 分歧分析

GPT-5 将参考项目边界判为 P0，DeepSeek 判为 P1。理由：P0 的定义是 "影响实现方向或基线矛盾"。参考项目边界缺失不会导致实现者走错方向（因为概要设计已经定义了组件的职责和边界），只是缺少 "为什么不重复造轮子" 的背景。工程师可以从概要设计的组件定义直接开工，参考项目边界是补充理解而非必要条件。

MIMO 将 ScopeImpactLevel 判为 P1，DeepSeek 判为 P2。理由：概要设计 §10.5 已经覆盖了 Architecture Designer gate 的 10 条触发规则和 3 种 gate 组合（architecture-sensitive/phase-complete/final consistency），这些规则隐含了对 impact level 的判断逻辑。7 级分类的枚举补充属于详细设计阶段的细化工作。

---

## 附录 A：基线覆盖热力图

| 基线文档 | 概要设计覆盖 | 缺口严重度 |
|---|---|---|
| requirements.md | ▓▓▓▓▓▓▓░░░ 70% | P0×2, P1×1, P2×1 |
| baselineV1.md | ▓▓▓▓▓░░░░░ 50% | P0×4, P1×4, P2×2 |
| solution-architecture.md | ▓▓▓▓▓▓▓▓░░ 80% | P1×1 |
| interface-contracts-v1.md | ▓▓▓▓▓▓░░░░ 60% | P0×2, P1×0, P2×1 |
| db-schema-v1.md | ▓▓▓▓▓▓▓░░░ 70% | P0×1, P2×1 |
| event-registry-v1.md | ▓▓▓▓▓▓▓▓░░ 80% | P0×1, P2×1 |
| runtime-semantics-v1.md | ▓▓▓▓▓▓░░░░ 60% | P0×1, P1×1, P2×3 |
| c4/module.md | ▓▓▓▓▓▓▓▓▓░ 90% | P1×1 |
| c4/code-view.md | ▓▓▓▓▓▓░░░░ 60% | P1×1 |
| main-agent-state-machine.md | ▓▓▓▓▓░░░░░ 50% | P1×1 |
| scheduler-state-machine-v1.md | ▓▓▓░░░░░░░ 30% | P1×1 |
| scope-escalation-v1.md | ▓▓▓▓▓▓▓▓░░ 80% | P2×1 |
| security-model-v1.md | ▓▓▓▓░░░░░░ 40% | P0×1 |
| capability-trust-v1.md | ▓▓▓░░░░░░░ 30% | P1×1 |
| provider-capability-matrix-v1.md | ▓▓▓░░░░░░░ 30% | P1×1 |
| prompt-layering-v1.md | ▓▓▓▓▓▓▓░░░ 70% | P2×1 |
| artifact-naming-v1.md | ▓▓░░░░░░░░ 20% | P1×1 |
| error-taxonomy-v1.md | ░░░░░░░░░░ **0%** | **P0×1** |
| tool-registry-v1.md | ▓▓▓▓▓▓░░░░ 60% | P1×1 |
| cross-platform-matrix-v1.md | ▓▓▓▓▓░░░░░ 50% | P1×1 |
| decisions-round-1/2/3.md | ▓▓▓▓░░░░░░ 40% | P2×1 |
| idea.md | ▓▓▓▓▓▓░░░░ 60% | P2×1 |

---

## 附录 B：全量缺口索引（按概要设计章节）

| 章节 | 缺口 ID | 严重度 |
|---|---|---|
| §1 源文档 | P0-01 | P0 |
| §2 系统目标 | P0-02, D-02 | P0, P1 |
| §2 技术基线 | P1-02 | P1 |
| §2 参考项目 | P1-01 | P1 |
| §4-§6 Package | P1-11, P1-16, D-02 | P1×3 |
| §6 Capability | P1-14 | P1 |
| §8.1 项目布局 | P0-03, D-05 | P0, P2 |
| §8.2 存储 | P0-10, P1-05, P1-15, D-04, D-05 | P0, P1×2, P2×2 |
| §9 事件/投影 | P0-08, P0-09, P2-03, P2-06, P2-07 | P0×2, P2×3 |
| §10 执行流 | P0-04, P0-07, P1-03, P1-04, P1-12, P2-01, P2-14 | P0×2, P1×3, P2×2 |
| §11 IPC | P0-06 | P0 |
| §12 权限 | P0-05, P2-04 | P0, P2 |
| §13 上下文/记忆 | P2-05, P2-04 | P2×2 |
| §14 UI/Provider | P1-13, P2-08, P2-09, P2-10 | P1, P2×3 |
| §15 Doctor/Restore | P2-02 | P2 |
| §17 验证 | P1-10 | P1 |
| 无对应章节 | P1-06, P1-07, P1-08, P1-09, P1-17, P2-11, P2-12, P2-13 | P1×5, P2×3 |