System detailed design: four-model cross-review complete
Add system-detailed-design.md (2033 lines, 23 sections) derived from frozen baselines and overview. Complete four-model cross-review: - DeepSeek: baseline coverage audit (PASS, 9.6/10) - MIMO 2.5 Pro: internal consistency (PASS, 9.4/10) - GPT-5.5 Pro: baseline conflict detection (Requires repair) - Opus 4.8: validation + root cause analysis (CONDITIONAL PASS, 9.1/10) Key findings requiring resolution before freeze: - P1-01: Worker exit code semantic conflict (baselineV1 vs overview) - P1-02: PromptLayerLevel enum vs L0-L9 layer name mismatch - P1-03: EventStore.project() error handling undefined - P1-04: PromptLayerLoader interface incomplete for 10 layers Coverage verified: 100% contracts, events, DB schema, state machines. Architecture validated: no circular dependencies, proper separation. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
AirCoding
367
AirPlan/docs/architecture/DeepSeek系统详细设计审查.md
Normal file
367
AirPlan/docs/architecture/DeepSeek系统详细设计审查.md
Normal file
@@ -0,0 +1,367 @@
|
||||
# DeepSeek 系统详细设计全量交叉审查
|
||||
|
||||
Date: 2026-05-29
|
||||
Reviewer: DeepSeek (single-model, first-pass)
|
||||
Status: Full cross-verification audit of `system-detailed-design.md` against all frozen baselines + frozen overview
|
||||
Scope: Baseline-to-detailed-design full item-by-item comparison; frozen docs are authoritative
|
||||
|
||||
---
|
||||
|
||||
## 1. 审查范围与方法
|
||||
|
||||
审查对象：`AirPlan/docs/architecture/system-detailed-design.md`（2033 行，23 节）
|
||||
|
||||
审查基线（22 份冻结文档 + 1 份已冻结概要设计）：
|
||||
|
||||
| # | 文档 | 角色 |
|
||||
|---|---|---|
|
||||
| 1 | `requirements.md` | 需求规格 |
|
||||
| 2 | `baselineV1.md` | 架构基线 |
|
||||
| 3 | `solution-architecture.md` | 解法架构 |
|
||||
| 4 | `interface-contracts-v1.md` | 接口契约（§2-§23） |
|
||||
| 5 | `db-schema-v1.md` | 数据库 Schema（19 张表） |
|
||||
| 6 | `event-registry-v1.md` | 事件注册表（55 durable + 7 ephemeral） |
|
||||
| 7 | `runtime-semantics-v1.md` | 运行时语义 |
|
||||
| 8 | `scheduler-state-machine-v1.md` | 调度器状态机（11 状态） |
|
||||
| 9 | `main-agent-state-machine.md` | 主代理状态机（9 状态） |
|
||||
| 10 | `scope-escalation-v1.md` | 作用域升级模型 |
|
||||
| 11 | `security-model-v1.md` | 安全模型 |
|
||||
| 12 | `capability-trust-v1.md` | 能力信任模型 |
|
||||
| 13 | `prompt-layering-v1.md` | 提示分层模型（L0-L9） |
|
||||
| 14 | `provider-capability-matrix-v1.md` | 供应商能力矩阵 |
|
||||
| 15 | `artifact-naming-v1.md` | 制品命名规范 |
|
||||
| 16 | `error-taxonomy-v1.md` | 错误分类学 |
|
||||
| 17 | `tool-registry-v1.md` | 工具注册表 |
|
||||
| 18 | `cross-platform-matrix-v1.md` | 跨平台矩阵 |
|
||||
| 19 | `c4/module.md` | C4 模块视图 |
|
||||
| 20 | `c4/code-view.md` | C4 代码视图 |
|
||||
| 21 | `decisions-round-1/2/3.md` | ADR 三轮决策 |
|
||||
| 22 | `idea.md` | 原始设计构想 |
|
||||
| F | `system-overview-design.md` | **FROZEN** 概要设计 |
|
||||
|
||||
方法：
|
||||
- 逐基线 item-by-item 语义比对，非标题/关键词匹配
|
||||
- 每个契约接口 → 详细设计类 → 方法签名是否吻合
|
||||
- 每个持久化事件 → 投影映射表是否覆盖
|
||||
- 每个 DB 表 → 仓储是否覆盖
|
||||
- 每个状态机状态 → 详细设计是否完整
|
||||
- 每个禁止路径 → 详细设计是否强制执行
|
||||
- UML 图 → 类签名与契约是否一致
|
||||
|
||||
P 级定义：
|
||||
- **P0** = 详细设计与基线矛盾，或基线强制要求的 item 在详细设计中完全缺失
|
||||
- **P1** = 完整性缺口：baseline 有对应 item，但详细设计省略了重要细节
|
||||
- **P2** = 措辞/渲染/组织方式差异，不影响实现正确性
|
||||
|
||||
---
|
||||
|
||||
## 2. 总体评估
|
||||
|
||||
### 2.1 优势
|
||||
|
||||
1. **逐契约派生**：每个 `interface-contracts-v1.md` 的接口都在详细设计中找到了对应的类/方法签名，字段完整，无遗漏。
|
||||
2. **55 个持久化事件全投影**：`EventStore.project()` 的投影映射表（§5.4）逐行覆盖了 `event-registry-v1.md` §3 的全部 55 个事件类型，域更新描述准确。
|
||||
3. **19 张 DB 表全仓储**：每张 `db-schema-v1.md` 表都有对应的仓储，项目级 DB（`debug-records.db`、`learned-memory.db`）有独立 Store 类，`schema_meta` 由 `MigrationRunner` 管理。
|
||||
4. **6 个状态机完整**：Main Agent、Scheduler、Task、Agent、Workspace、Capability 六个状态机全部覆盖，与基线转换条件一致。
|
||||
5. **10 条禁止路径全执行**：`interface-contracts-v1.md` §23 的 10 条禁止路径在详细设计中有明确的禁止点（§2 依赖方向 + §18.5 安全不变量）。
|
||||
6. **8 个 Mermaid UML 类图**：覆盖 Contracts、Runtime Core、Scheduler、Tool/Permission、Worker/IPC、Provider、Context、Agents 八个子系统。
|
||||
7. **5 向可追溯性矩阵**：Contracts→设计、状态机→设计、DB Schema→设计、Code View→设计、Overview→设计全部有映射表（§21）。
|
||||
8. **`IMPL` 标注纪律**：非基线固定的实现自由度均显式标记 `IMPL`，不伪装为基线原文。
|
||||
|
||||
### 2.2 系统性评估
|
||||
|
||||
| 维度 | 得分 (1-10) | 说明 |
|
||||
|---|---|---|
|
||||
| 契约覆盖率 | **10** | 80+ 个契约接口全部有对应类/方法 |
|
||||
| 事件覆盖率 | **10** | 55 durable + 7 ephemeral 全部覆盖 |
|
||||
| DB Schema 覆盖率 | **10** | 19 表全仓储覆盖 |
|
||||
| 状态机完整性 | **10** | 6 个状态机全部覆盖 |
|
||||
| 禁止路径执行 | **10** | 10/10 路径强制执行 |
|
||||
| UML 图覆盖率 | **9.0** | 8 图覆盖核心子系统；仓储/CLI 为文本覆盖（合理） |
|
||||
| 序列图覆盖率 | **8.5** | 4 个关键流程覆盖；可补充的次要流程见 P2 |
|
||||
| 可追溯性 | **10** | 5 向矩阵完整 |
|
||||
| 基线吻合度 | **9.5** | 2 项 P2 级别措辞/组织差异 |
|
||||
|
||||
**综合评分：9.6/10** — 详细设计可直接指导实现。
|
||||
|
||||
### 2.3 结论
|
||||
|
||||
详细设计完全覆盖并遵守了所有冻结基线、需求和已冻结概要设计。未发现 P0 或 P1 缺口。两项标注为 P2 的是措辞/组织差异，不需要阻塞实现。
|
||||
|
||||
---
|
||||
|
||||
## 3. 契约覆盖逐项检查
|
||||
|
||||
### 3.1 interface-contracts-v1.md §2-§23 逐章检查
|
||||
|
||||
| 契约章节 | 详细设计覆盖位置 | 状态 |
|
||||
|---|---|---|
|
||||
| §2 Core Primitive Types + Clock/IdGenerator | §3（contracts 包 → ids.ts） | OK |
|
||||
| §3 Error（AirError, 22 ErrorKind, 4 severity, 4 retryability）| §3（error.ts）+ §18.1（make_air_error） | OK |
|
||||
| §4 EntityRef（12 EntityTypes）| §3（event.ts） | OK |
|
||||
| §5 RuntimeEvent, EventSource, EventFilter | §3（event.ts）+ §5 事件子系统 | OK |
|
||||
| §6 Transaction, Repository, 16 种 DB Record 类型 | §4.1-§4.3 + §18.2 事务纪律 | OK |
|
||||
| §7 EventBus, EventStore, EventIngestor, EventSchemaRegistry, Subscription | §5.1-§5.5（5 个类实现） | OK |
|
||||
| §8 ProjectStore, SessionManager, ProjectContext, SessionContext | §6（ProjectStore + SessionManager） | OK |
|
||||
| §9 TaskSpec（8 字段族）, Scheduler, TaskNode, TaskGraph, WavePlan | §7（Scheduler 6 个类） | OK |
|
||||
| §10 IPC, IpcEnvelope, ControlMessage（6 variants）, WorkerRole, WorkerRuntime | §8.1-§8.3（WorkerManager, WorkerProcess, WorkerProtocol, WorkerRuntime, 5 Roles） | OK |
|
||||
| §11 WorkerResult（6 子类型）, BlockerReport, VerificationResult | §8.3（Role 清单 + 约束表） | OK |
|
||||
| §12 ToolDefinition, ToolRegistry, 16 ToolCategory, streaming 规则 | §9.1（ToolRegistry + call 算法） | OK |
|
||||
| §13 PermissionEngine, PermissionDecision, PathPolicy, 6 actions, 5 scopes | §9.2-§9.3（PermissionEngine + PathClassifier + CommandRiskAnalyzer + 分支表） | OK |
|
||||
| §14 ArtifactStore, EvidenceStore, ArtifactRef, EvidenceRef | §11.1-§11.2（ArtifactStore + EvidenceStore） | OK |
|
||||
| §15 ProviderAdapter, ProviderManager, ProviderCapabilityMatrix, ModelRequirement | §12（ProviderManager + 2 adapters + Converter + StreamNormalizer） | OK |
|
||||
| §16 ContextAssembler, PromptLayer, PromptLayerLevel, CompactionPolicy, BudgetFitResult | §10（ContextAssembler + PromptLayerLoader + CompactionPolicy + L0-L9 映射） | OK |
|
||||
| §17 ProjectionStore, ProjectionClient, 7 Projection 类型 | §13（ProjectionStore + TuiApp + ProjectionClient） | OK |
|
||||
| §18 CapabilityManifestV1, CapabilityRegistry, 5 trust levels | §9.5（CapabilityRegistry + CapabilityManifestValidator） | OK |
|
||||
| §19 DoctorService, DoctorRunInput/Output, Logger | §16（DoctorService + Logger + DeveloperLogEncryptor） | OK |
|
||||
| §20 DebugKnowledgeStore, LearnedMemoryStore, DebugRecord, LearnedMemory | §11.3（两个 Store 类） | OK |
|
||||
| §21 Diagnostic, DiagnosticSeverity（4 值）| §15（DiagnosticParser）| OK |
|
||||
| §22 兼容性和版本规则（6 条）| §3（contracts 包规则 1-4）| OK |
|
||||
| §23 不可妥协的边界规则（10 条禁止路径）| §2 依赖方向 + §18.5 安全不变量 | OK |
|
||||
|
||||
结果：**23/23 契约章节全部覆盖**。
|
||||
|
||||
### 3.2 契约字段完整性抽样
|
||||
|
||||
随机抽样 5 个高阶接口，逐字段检查其详细设计对应内容：
|
||||
|
||||
| 接口（contracts） | 详细设计 | 字段数 | 缺失 |
|
||||
|---|---|---|---|
|
||||
| TaskSpec（§9）| DD §10.10 TaskSpec field families（8 族）| 9 字段 | 0 |
|
||||
| WorkerResult<T>（§11）| DD §8.3 WorkerResult field families | 11 字段 | 0 |
|
||||
| IpcEnvelope<T>（§10）| DD §11 IPC envelope fields | 9 字段 | 0 |
|
||||
| ProviderCapabilityMatrix（§15）| DD §14 provider capability matrix concepts | 10 字段 | 0 |
|
||||
| AirError（§3）| DD §18.1 make_air_error + §22.1 UML | 11 字段 | 0 |
|
||||
|
||||
结果：**抽样 5/5 全部字段完整**。
|
||||
|
||||
---
|
||||
|
||||
## 4. 事件覆盖
|
||||
|
||||
### 4.1 持久化事件
|
||||
|
||||
`event-registry-v1.md` §6 列出了 55 个持久化事件名。详细设计 §5.4 投影映射表以 45 行覆盖了全部 55 个事件（部分行合并了域更新相同的事件，如 `agent.completed/failed/lost/cancelled` 和 `doctor.*`）。
|
||||
|
||||
逐一核对：所有 55 个事件类型均在投影映射表中找到了对应的域更新描述，且域更新内容与 event-registry §3 原文一致。
|
||||
|
||||
结果：**55/55 持久化事件覆盖**。
|
||||
|
||||
### 4.2 暂态事件
|
||||
|
||||
详细设计 §5.5 列出了全部 7 个暂态事件（`agent.heartbeat`, `task.progress`, `assistant.message.delta`, `tool.progress`, `command.stdout.delta`, `command.stderr.delta`, `hud.frame.rendered`），并明确了合并/节流规则。
|
||||
|
||||
结果：**7/7 暂态事件覆盖**。
|
||||
|
||||
---
|
||||
|
||||
## 5. DB Schema 覆盖
|
||||
|
||||
### 5.1 表 → 仓储映射
|
||||
|
||||
| DB Schema 表（19 张）| 详细设计覆盖 | 角色 |
|
||||
|---|---|---|
|
||||
| schema_meta（§2）| MigrationRunner（§4.2）| 版本管理 |
|
||||
| sessions（§3）| SessionRepository（§4.3）| CRUD |
|
||||
| messages（§4）| MessageRepository | CRUD + list_by_session |
|
||||
| message_drafts（§5）| MessageDraftRepository | upsert + delete_for_message |
|
||||
| events（§6）| EventRepository | insert + query |
|
||||
| tasks（§7）| TaskRepository | list_by_status + list_runnable_candidates |
|
||||
| task_dependencies（§8）| TaskDependencyRepository | list_for_task + list_dependents |
|
||||
| task_attempts（§9）| TaskAttemptRepository | next_attempt_index + list_by_task |
|
||||
| agents（§10）| AgentRepository | list_active + update_heartbeat |
|
||||
| tool_runs（§11）| ToolRunRepository | list_by_task + list_by_origin_message |
|
||||
| command_runs（§12）| CommandRunRepository | list_by_task + derived status |
|
||||
| artifacts（§13）| ArtifactRepository | list_by_entity + get_by_uri |
|
||||
| diagnostics（§14）| DiagnosticRepository | list_by_signature + list_by_command_run |
|
||||
| evidence_refs（§15）| EvidenceRepository | list_for_entity |
|
||||
| workspaces（§16）| WorkspaceRepository | list_by_status + list_gc_candidates |
|
||||
| summaries（§17）| SummaryRepository | get + insert |
|
||||
| ui_state（§18）| UiStateRepository | upsert + read（scope,key）|
|
||||
| debug_records（§20.1）| DebugKnowledgeStore（§11.3）| insert + lookup + update |
|
||||
| learned_memories（§20.2）| LearnedMemoryStore（§11.3）| insert + lookup + update_status + scan_stale |
|
||||
|
||||
结果：**19/19 表全仓储覆盖**。
|
||||
|
||||
### 5.2 其他 DB 基线合规
|
||||
|
||||
| 基线规则 | 详细设计 | 状态 |
|
||||
|---|---|---|
|
||||
| WAL + NORMAL + foreign_keys=OFF（db-schema §1）| §4.1 DatabaseManager.applyPragmas | OK |
|
||||
| 事务纪律（event + domain update 同事务）| §18.2 Transaction discipline | OK |
|
||||
| command_runs 无物理 status 列（runtime-semantics §5）| §4.4 derive_command_status | OK |
|
||||
| 关闭枚举验证（db-schema §21, 18 行）| §4.5 enum validation | OK |
|
||||
| FK-off 8 条不变量（runtime-semantics §14）| §18.3 全列 + SessionStore.referential_check | OK |
|
||||
| 跨存储 outbox 模型（runtime-semantics §6.3-§6.4）| §18.4 5 步流程 | OK |
|
||||
|
||||
---
|
||||
|
||||
## 6. 状态机覆盖
|
||||
|
||||
| 状态机 | 基线状态数 | 详细设计 | 转换条件 | 结果 |
|
||||
|---|---|---|---|---|
|
||||
| Main Agent（main-agent-state-machine.md）| 9 + DIRECT_MODE | §14.1 + §20.1 | 全部覆盖 | OK |
|
||||
| Scheduler（scheduler-state-machine-v1.md §4）| 11 + 3 terminal | §7 + §20.2 | 全部覆盖 | OK |
|
||||
| Task status（db-schema §7 + scheduler SM §2）| 7 | §20.3 | pending→running→7终态 | OK |
|
||||
| Agent status（db-schema §10）| 6 | §20.4 | 全部覆盖 | OK |
|
||||
| Workspace status（db-schema §16）| 5 | §20.5 | active→merged/conflicted/abandoned→cleaned | OK |
|
||||
| Capability lifecycle（capability-trust §7）| 8 phases | §9.5 + §20.6 | discovered→active→disabled/failed/updated | OK |
|
||||
|
||||
结果：**6/6 状态机完整覆盖**。
|
||||
|
||||
---
|
||||
|
||||
## 7. 禁止路径强制执行
|
||||
|
||||
`interface-contracts-v1.md` §23 的 10 条不可妥协边界规则：
|
||||
|
||||
| 禁止路径 | 详细设计强制执行点 |
|
||||
|---|---|
|
||||
| TUI → SQLite direct query | §2 依赖方向 + §13.2 |
|
||||
| TUI → runtime private service import | §2 + §13.2 |
|
||||
| worker → SQLite direct write | §2 + §8.1 + §8.3 |
|
||||
| worker → filesystem/shell/network side effect outside tool IPC | §2 + §8.3 |
|
||||
| tool → side effect without PermissionEngine | §2 + §9.1 |
|
||||
| capability → dependency install outside Doctor | §2 + §9.5 |
|
||||
| provider adapter → silent semantic prompt loss | §2 + §12.2 |
|
||||
| repository → scheduling policy | §2 + §4.3 |
|
||||
| EventBus → recovery source of truth | §2 + §5.5 |
|
||||
| LLM output → direct file/shell side effect | §2 + §12.2 + §18.5 |
|
||||
|
||||
详细设计额外新增 1 条：`runtime → TUI import`（C4 依赖方向强化，不弱化基线）。
|
||||
|
||||
结果：**10/10 禁止路径强制执行**。
|
||||
|
||||
---
|
||||
|
||||
## 8. UML 图评估
|
||||
|
||||
8 个 Mermaid classDiagram 覆盖了 8 个子系统。UML 中的类签名与对应契约的逐字段抽样全部吻合。
|
||||
|
||||
未包含 UML 图的子系统：
|
||||
- **仓储层**（§4.3）：以 16 行表格展示，文本形式更适合 16 个同构仓储的呈现
|
||||
- **CLI**（§17）：以文本描述展示，命令路由不需要类图
|
||||
- **契约所有权表**（code-view §3）：已内嵌在详细设计 §3 的文件映射中
|
||||
|
||||
这些省略是有意且合理的。
|
||||
|
||||
---
|
||||
|
||||
## 9. 序列图覆盖
|
||||
|
||||
4 个序列图覆盖关键运行时流程：
|
||||
|
||||
| 序列 | 覆盖 |
|
||||
|---|---|
|
||||
| 用户请求 → 任务执行 → 完成（§19.1）| Main Agent → Scheduler → Executor → Reviewer → 返回 |
|
||||
| 权限提示的工具调用（§19.2）| ToolRegistry → PermissionEngine → TUI → 用户决策 → 恢复 |
|
||||
| 压缩流程（§19.3）| ContextAssembler → Scheduler → CompactorRole → summary.created |
|
||||
| 调试知识捕获（§19.4）| Executor 失败 → Scheduler → DebuggerRole → Knowledge Store |
|
||||
|
||||
**轻微差距**：架构设计器大门触发流程（overview §10.7）的序列未单列出来——其逻辑隐含在 §19.1 的 "architecture impact?" 分支中，但没有详细的 "敏感任务 → Reviewer → Architecture Designer gate → combined decision" 序列。评估：P2（可从文本/状态机推导，不影响实现）。
|
||||
|
||||
---
|
||||
|
||||
## 10. 概要设计覆盖检查
|
||||
|
||||
已冻结的概要设计所有章节 → 详细设计可追溯性：
|
||||
|
||||
| 概要设计章节 | 详细设计覆盖 | 状态 |
|
||||
|---|---|---|
|
||||
| §2 System Goal | §0 权威声明 + §2 系统分解 | OK |
|
||||
| §3 System Context | §6（Project/Session）+ §12（Provider）| OK |
|
||||
| §4 Container Overview | §2-§3（分解 + contracts 包）| OK |
|
||||
| §5 Dependency Rules | §2（允许导入 + 禁止边）| OK |
|
||||
| §6 Runtime Component Overview | §4-§11（所有 22 个组件有类设计）| OK |
|
||||
| §7 Runtime Agent Overview | §14（Main Agent + Architecture Designer）| OK |
|
||||
| §8 State and Data Overview | §4（storage）+ §6（project/session）+ §11（artifact/evidence）| OK |
|
||||
| §9 Event, Error, Projection | §5（events）+ §18.1（error）+ §13（projection）| OK |
|
||||
| §10 Execution Flow Overview | §7-§9 + §19（sequences）| OK |
|
||||
| §11 IPC and Worker Overview | §8 | OK |
|
||||
| §12 Permission and Security | §9.2-§9.3 + §18.5 | OK |
|
||||
| §13 Context, Memory, Compaction | §10 + §11.3 + §19.3 | OK |
|
||||
| §14 UI/HUD and Provider | §12 + §13 | OK |
|
||||
| §15 Doctor, Restore, Recovery | §16 | OK |
|
||||
| §16 Implementation Phase Mapping | 不适用（实现阶段协调，非类设计）| — |
|
||||
| §17 Validation Overview | 不适用（测试阶段，非类设计）| — |
|
||||
| §18 Open Items（12 项）| 9 项在 DD 中处理，3 项（fixture/mockup/manifest）为测试/资产 | OK |
|
||||
|
||||
结果：**概要设计完全被详细设计覆盖**。
|
||||
|
||||
---
|
||||
|
||||
## 11. 发现项汇总
|
||||
|
||||
### P0（0 项）
|
||||
|
||||
未发现 P0 项。
|
||||
|
||||
### P1（0 项）
|
||||
|
||||
未发现 P1 项。
|
||||
|
||||
### P2（3 项）
|
||||
|
||||
| ID | 发现 | 严重度 | 说明 |
|
||||
|---|---|---|---|
|
||||
| P2-01 | PromptLayerLevel 枚举与 L0-L9 层映射不完全 1:1 | P2 | 契约枚举有 10 个值，prompt-layering 定义 10 层（L0-L9），但 L2 "Safety and permission policy" 没有独立的枚举值——它由不可变的 L0/L1 层承载。DD §10.2 正确记录了此映射，IMP 注释解释了对齐策略。实现时需要约定安全层在不可变层中的具体嵌入方式。 |
|
||||
| P2-02 | Architecture Designer gate 触发序列无独立序列图 | P2 | 概览 §10.7 定义了 10 个 gate 触发条件和门控结果规则。DD §19.1 在主请求序列中有一个 "architecture impact?" 分支，但没有详细的 "敏感任务 → Reviewer → Architecture Designer → combined decision" 专用序列图。逻辑存在于 DD §10.7 + §14.2 文本中，不影响实现。 |
|
||||
| P2-03 | CLI 命令路由未指定 catalog 命令的类归属 | P2 | DD §17 列出了 `resume, compact, history, session list, restore` 等 catalog 命令，但没有像 `RunCommand, InitCommand` 那样为每个指定实现类。这些可能共享一个 `CatalogCommand` 类或由 Main Agent/SessionManager 直接处理。标签为 IMP 范围，不影响实现。 |
|
||||
|
||||
---
|
||||
|
||||
## 12. 需求覆盖摘要
|
||||
|
||||
| 需求 | 基线来源 | 详细设计覆盖 |
|
||||
|---|---|---|
|
||||
| FR-001 项目本地状态 | requirements.md | §6.1 ProjectStore.initialize |
|
||||
| FR-009 Claude Code 执行纪律 | requirements.md | §8.4 + §9.4 |
|
||||
| FR-019 日志和诊断 | requirements.md | §16.2（Logger, DeveloperLogEncryptor, SecretRedactor）|
|
||||
| FR-020 发布门禁验证 | requirements.md | §17（CLI release/e2e 命令）|
|
||||
| NFR-001 本地优先 | requirements.md | §6（项目本地 .air，无云依赖）|
|
||||
| NFR-002 可恢复性 | requirements.md | §16.3（恢复步骤）+ §18.2（事务纪律）|
|
||||
| NFR-008 安全边界保护 | requirements.md | §18.5（安全不变量）|
|
||||
|
||||
---
|
||||
|
||||
## 13. 基线覆盖热力图
|
||||
|
||||
| 基线文档 | 详细设计覆盖程度 | 缺口量 |
|
||||
|---|---|---|
|
||||
| interface-contracts-v1.md | ██████████ 100% | 0 |
|
||||
| event-registry-v1.md | ██████████ 100% | 0 |
|
||||
| db-schema-v1.md | ██████████ 100% | 0 |
|
||||
| scheduler-state-machine-v1.md | ██████████ 100% | 0 |
|
||||
| main-agent-state-machine.md | ██████████ 100% | 0 |
|
||||
| scope-escalation-v1.md | █████████░ 95% | 0 P0/P1 |
|
||||
| security-model-v1.md | ██████████ 100% | 0 |
|
||||
| capability-trust-v1.md | ██████████ 100% | 0 |
|
||||
| prompt-layering-v1.md | ██████████ 100% | 0 |
|
||||
| provider-capability-matrix-v1.md | █████████░ 95% | 0 P0/P1 |
|
||||
| artifact-naming-v1.md | ██████████ 100% | 0 |
|
||||
| error-taxonomy-v1.md | ██████████ 100% | 0 |
|
||||
| tool-registry-v1.md | ██████████ 100% | 0 |
|
||||
| cross-platform-matrix-v1.md | ████████░░ 85% | 0 P0/P1 |
|
||||
| c4/module.md | ██████████ 100% | 0 |
|
||||
| c4/code-view.md | ██████████ 100% | 0 |
|
||||
| runtime-semantics-v1.md | ██████████ 100% | 0 |
|
||||
| requirements.md | █████████░ 95% | 0 P0/P1 |
|
||||
| solution-architecture.md | █████████░ 95% | 0 P0/P1 |
|
||||
| system-overview-design.md（FROZEN）| ██████████ 100% | 0 |
|
||||
|
||||
---
|
||||
|
||||
## 14. 门禁判定
|
||||
|
||||
| 条件 | 状态 |
|
||||
|---|---|
|
||||
| P0 缺口 = 0 | **PASS**（0 项）|
|
||||
| P1 缺口 = 0 | **PASS**（0 项）|
|
||||
| 契约覆盖率 100% | **PASS**（23/23 章节）|
|
||||
| 事件覆盖率 100% | **PASS**（55 durable + 7 ephemeral）|
|
||||
| DB Schema 覆盖率 100% | **PASS**（19/19 表）|
|
||||
| 状态机完整 100% | **PASS**（6/6 状态机）|
|
||||
| 禁止路径全执行 | **PASS**（10/10）|
|
||||
| UML 图覆盖核心子系统 | **PASS**（8 图）|
|
||||
|
||||
**门禁结果：PASS — 详细设计可以进入实现阶段。**
|
||||
353
AirPlan/docs/architecture/Mimo2.5pro系统详细设计审查.md
Normal file
353
AirPlan/docs/architecture/Mimo2.5pro系统详细设计审查.md
Normal file
@@ -0,0 +1,353 @@
|
||||
# MIMO 2.5 Pro 系统详细设计全量交叉审查
|
||||
|
||||
Date: 2026-05-29
|
||||
Reviewer: MIMO 2.5 Pro (single-model, independent pass)
|
||||
Status: Full cross-verification of `system-detailed-design.md` against all frozen baselines, frozen overview, and internal architectural consistency
|
||||
Scope: Coverage + consistency + architecture soundness audit
|
||||
|
||||
---
|
||||
|
||||
## 1. 审查方法
|
||||
|
||||
审查对象：`AirPlan/docs/architecture/system-detailed-design.md`（2033 行，23 节）
|
||||
|
||||
审查三维度：
|
||||
|
||||
1. **覆盖性**：基线/概要设计的每个 item 是否在详细设计中有对应项
|
||||
2. **一致性**：详细设计内部是否存在矛盾、基线引用是否准确
|
||||
3. **架构合理性**：类职责划分、依赖方向、边界执行是否合理，是否存在内在冲突
|
||||
|
||||
审查输入：
|
||||
|
||||
| 文档 | 角色 |
|
||||
|---|---|
|
||||
| `interface-contracts-v1.md` (23 节) | 接口契约 |
|
||||
| `event-registry-v1.md` (55 durable + 7 ephemeral) | 事件注册表 |
|
||||
| `db-schema-v1.md` (19 表, 18 个关闭枚举) | 数据库 Schema |
|
||||
| `runtime-semantics-v1.md` (19 节) | 运行时语义 |
|
||||
| `scheduler-state-machine-v1.md` (11 节) | 调度器状态机 |
|
||||
| `main-agent-state-machine.md` | 主代理状态机 |
|
||||
| `prompt-layering-v1.md` (L0-L9) | 提示分层 |
|
||||
| `scope-escalation-v1.md` (13 节) | 作用域升级 |
|
||||
| `security-model-v1.md` (8 PathRisk + 10 CommandRisk) | 安全模型 |
|
||||
| `capability-trust-v1.md` | 能力信任 |
|
||||
| `system-overview-design.md` (FROZEN, 1222 行) | 概要设计 |
|
||||
| `DeepSeek系统详细设计审查.md` | 前一轮审查报告 |
|
||||
|
||||
方法：
|
||||
- 逐契约接口字段比对
|
||||
- 逐事件投影映射核对
|
||||
- 逐表仓储核对
|
||||
- 逐状态机转换核对
|
||||
- PromptLayer 三方比对（contracts / prompt-layering / overview）
|
||||
- 依赖方向一致性验证
|
||||
- 内在冲突检测
|
||||
|
||||
---
|
||||
|
||||
## 2. 总体评估
|
||||
|
||||
### 2.1 评分
|
||||
|
||||
| 维度 | 得分 | 说明 |
|
||||
|---|---|---|
|
||||
| 契约覆盖 | 9.5/10 | 接口字段全覆盖，1 处 PromptLayerLevel 枚举与层名不完全对齐 |
|
||||
| 事件覆盖 | 10/10 | 55 durable + 7 ephemeral 全覆盖 |
|
||||
| DB Schema 覆盖 | 10/10 | 19 表全仓储 |
|
||||
| 状态机覆盖 | 10/10 | 6 个状态机全覆盖 |
|
||||
| 内在一致性 | 8.5/10 | 1 处真实内部矛盾（PromptLayer），1 处架构弱点（EventStore 错误隔离） |
|
||||
| 架构合理性 | 9.5/10 | 边界清晰、职责分离良好、依赖方向正确 |
|
||||
| 序列图覆盖 | 8.0/10 | 4 个关键序列覆盖，2 个可补充 |
|
||||
| 可实现性 | 9.5/10 | 方法签名可直接编码，无歧义 |
|
||||
|
||||
**综合评分：9.4/10**
|
||||
|
||||
### 2.2 结论
|
||||
|
||||
详细设计是一个高质量的实现导向文档。架构边界清晰，依赖方向正确，类职责分离良好。发现了 **1 处真实内部矛盾** 和 **1 处架构弱点** 需要解决，但均不阻塞实现阶段——可以通过明确的设计决策澄清来修复。
|
||||
|
||||
---
|
||||
|
||||
## 3. P0 发现（0 项）
|
||||
|
||||
未发现 P0 项。
|
||||
|
||||
---
|
||||
|
||||
## 4. P1 发现（2 项）
|
||||
|
||||
### P1-01: PromptLayerLevel 枚举与 L0-L9 层名结构性不对齐
|
||||
|
||||
**严重度**：P1（真实内部矛盾，影响实现一致性）
|
||||
|
||||
**问题**：`interface-contracts-v1.md` §16 定义了 10 个 `PromptLayerLevel` 枚举值，`prompt-layering-v1.md` §2 定义了 L0-L9 共 10 个层名。概要设计 §13 已将 L0-L9 逐层与基线对齐。但三方存在结构性不匹配：
|
||||
|
||||
| L# | prompt-layering-v1 §2 | contracts §16 枚举值 | 对齐状态 |
|
||||
|---|---|---|---|
|
||||
| L0 | Runtime invariant | `runtime_invariant` | ✓ |
|
||||
| L1 | Role / agent mode | `role` | ✓ |
|
||||
| L2 | Safety and permission policy | **（无对应枚举值）** | ✗ |
|
||||
| L3 | Project rules and user preferences | `project_rules` | ✓ |
|
||||
| L4 | Architecture baseline and current plan | `architecture` | ✓ |
|
||||
| L5 | Task specification and acceptance criteria | `task_spec` | ✓ |
|
||||
| L6 | Relevant code / artifacts / evidence | `evidence` | ✓ |
|
||||
| L7 | Recent conversation and decision context | `conversation` | ✓ |
|
||||
| L8 | Tool result history / diagnostics | `tool_output` | ✓ |
|
||||
| L9 | Immediate instruction | `user_override`（名字不同） | △ |
|
||||
| — | （无对应层） | `system_debug` | ✗ |
|
||||
|
||||
**矛盾点**：
|
||||
1. L2 "Safety and permission policy" 没有对应的 `PromptLayerLevel` 枚举值——但它是 prompt-layering-v1 定义的独立层
|
||||
2. `user_override` 映射到 L9，但概要设计 §13 说 L9 = "Immediate instruction"，名字不一致
|
||||
3. `system_debug` 枚举值没有对应的 L 层——DD §10.2 说"applied within L9 when present"，但这是一个缩写而非结构映射
|
||||
|
||||
**影响**：实现时 `ContextAssembler.load_layers()` 需要 10 个加载点，但 `PromptLayerLoader` 接口只有 4 个方法（`load_runtime_invariant`, `load_role`, `load_project_rules`, `load_task_context`）。L2 safety、L4 architecture、L6 evidence、L7 conversation、L8 tool_output、L9 immediate instruction 都没有明确的 loader 方法。
|
||||
|
||||
**修复建议**（需要设计决策）：
|
||||
- 选项 A：在 contracts §16 添加 `safety_permission` 枚举值，将 `user_override` 改名为 `immediate_instruction`，删除 `system_debug` 或并入 L9
|
||||
- 选项 B：保持枚举不变，在实现层将 L2 映射到 `runtime_invariant`（immutable=true），L9 由 `user_override` + `system_debug` 合并
|
||||
- 选项 C：扩展 `PromptLayerLoader` 接口添加 L2/L4-L9 的显式加载方法
|
||||
|
||||
无论选哪个，需要一个明确的设计决策记录。
|
||||
|
||||
---
|
||||
|
||||
### P1-02: EventStore.project() 错误处理未定义
|
||||
|
||||
**严重度**：P1（架构弱点，影响运行时鲁棒性）
|
||||
|
||||
**问题**：DD §5.3 `EventStore.append()` 在事务内执行 `EventRepository.insert()` 和 `project(event, tx)`。但 `project()` 执行的是多行 domain update（如 `task.started` 需要更新 `tasks` 表 + 插入 `task_attempts` 行）。如果 `project()` 中间步骤失败，事务会回滚——但此时 `EventBus.publish()` 不会执行（正确行为），然而 **没有描述 `project()` 内部的错误语义**：
|
||||
|
||||
- 如果 `project()` 抛出异常，是整个 `append()` 回滚？（应该）
|
||||
- 如果 domain update 因 FK-off 不一致失败（如引用了不存在的 `tasks.id`），错误如何传播？
|
||||
- `project()` 是否有部分失败的恢复逻辑？
|
||||
|
||||
**影响**：在高并发或重启恢复场景下，如果 `project()` 的某一步 domain update 失败（如引用的 task 已被删除），整个事件追加会回滚——这是正确的原子行为，但 DD 没有显式描述这个错误路径。
|
||||
|
||||
**修复建议**：在 DD §5.3 或 §18.2 添加：`project()` 异常 → 事务回滚 → `EventBus.publish()` 不执行 → 返回 `AirError{kind: "system_error"}`。如果是因为 FK-off 不一致导致，记录到 developer log 并触发 `referential_check()`。
|
||||
|
||||
---
|
||||
|
||||
## 5. P2 发现（5 项）
|
||||
|
||||
### P2-01: DeepSeek 审查报告中的 3 项 P2 已验证
|
||||
|
||||
DeepSeek 审查报告的 3 项 P2 均确认属实：
|
||||
|
||||
| ID | DeepSeek 发现 | MIMO 验证 |
|
||||
|---|---|---|
|
||||
| DeepSeek P2-01 | PromptLayerLevel 枚举与 L0-L9 不完全 1:1 | 确认（已升级为 MIMO P1-01） |
|
||||
| DeepSeek P2-02 | Architecture Designer gate 无独立序列图 | 确认，P2 |
|
||||
| DeepSeek P2-03 | CLI catalog 命令类归属未指定 | 确认，P2 |
|
||||
|
||||
### P2-04: `agent.started` 投影映射措辞
|
||||
|
||||
DD §5.4 投影映射表中 `agent.started` 的域更新描述为 "insert `agents` (starting/running)"。这暗示 `project()` 可能选择 `starting` 或 `running`，但 event-registry §3.3 固定为 "insert `agents` row with `status = running` or `starting`"——具体选择哪个取决于调度器上下文（spawn 前 vs 握手后）。
|
||||
|
||||
建议：DD 应明确 `starting` 是初始状态，`running` 是握手完成后的状态（与 db-schema §10 agent status 一致）。当前描述可接受但含糊。
|
||||
|
||||
### P2-05: `WorkspaceManager` 与 `Scheduler` 状态机 MERGING 阶段的职责边界
|
||||
|
||||
DD §7.5 `WorkspaceManager.merge_workspace()` 和 DD §20.2 Scheduler 的 MERGING 状态都描述了合并逻辑。但 Scheduler 状态机的 MERGING 包含了冲突处理路由（trivial → repair/debugger, semantic → Reviewer/Architecture Designer, architecture → block, user → Main Agent）——这些是 Scheduler 级别的决策，而 `WorkspaceManager` 只负责 git 操作。
|
||||
|
||||
建议：明确 `WorkspaceManager` 返回 `MergeResult{status: success|conflict, conflict_files?, conflict_type?}`，Scheduler 根据 `conflict_type` 做路由决策。当前描述隐含了这个分工但没有显式标注。
|
||||
|
||||
---
|
||||
|
||||
## 6. 架构合理性分析
|
||||
|
||||
### 6.1 依赖方向
|
||||
|
||||
```text
|
||||
contracts → (none)
|
||||
llm → contracts
|
||||
toolchain-cpp → contracts
|
||||
tui → contracts
|
||||
runtime → contracts, llm (facade only)
|
||||
cli → contracts, runtime, tui, llm, toolchain-cpp
|
||||
workers → contracts + WorkerRuntime IPC (no direct runtime import)
|
||||
```
|
||||
|
||||
**评估**：完全正确。`contracts` 是叶节点，`cli` 是根节点，`runtime` 依赖 `llm` 但仅通过 facade（`ProviderManager` 接口），`workers` 通过 IPC 间接依赖 `runtime`（不直接 import）。这个依赖方向避免了循环依赖，允许各包独立编译。
|
||||
|
||||
### 6.2 职责分离
|
||||
|
||||
| 组件 | 职责 | 边界 | 评估 |
|
||||
|---|---|---|---|
|
||||
| EventIngestor | 事件入口 | 不创建 scheduler/permission/memory 决策 | ✓ 正确隔离 |
|
||||
| EventStore | 持久化事件 + 投影 | 不直接暴露 EventBus | ✓ 正确（投影在事务内，发布在事务后） |
|
||||
| EventBus | 实时发布/订阅 | 不是恢复源 | ✓ 正确 |
|
||||
| SessionStore | 聚合所有仓储 | 不含调度/权限/投影策略 | ✓ 正确（code-view §9） |
|
||||
| Scheduler | 编排服务 | 不是编码代理 | ✓ 正确（scheduler-state-machine §intro） |
|
||||
| ToolRegistry | 工具调用 | 所有 side effect 必须经过 PermissionEngine | ✓ 正确（contracts §23） |
|
||||
| PermissionEngine | 权限决策 | 不绕过 credential/system-sensitive override | ✓ 正确 |
|
||||
| TUI | UI 渲染 | 只依赖 ProjectionClient/contracts | ✓ 正确（contracts §23） |
|
||||
| ContextAssembler | 上下文组装 | 不自行压缩 | ✓ 正确（概要设计 §13） |
|
||||
|
||||
**评估**：所有组件的职责边界与基线一致。没有发现职责泄漏或边界违反。
|
||||
|
||||
### 6.3 状态机一致性
|
||||
|
||||
6 个状态机之间的交互路径：
|
||||
|
||||
| 源状态机 | 目标状态机 | 事件/数据流 | 一致性 |
|
||||
|---|---|---|---|
|
||||
| Main Agent → Scheduler | DELEGATING → SCHEDULING | `task.created` | ✓ |
|
||||
| Scheduler → Worker | DISPATCHING → worker spawn | `agent.start` IPC | ✓ |
|
||||
| Worker → Scheduler | worker.return → COLLECTING_RESULTS | `worker.result` IPC | ✓ |
|
||||
| Scheduler → Architecture Designer | architecture-sensitive review | `architecture.impact.completed` | ✓ |
|
||||
| Architecture Designer → Scheduler | impact assessment done | Scheduler consumes impact | ✓ |
|
||||
| Main Agent ← Scheduler | progress/blocked/complete | `task.progress/blocked/completed` events | ✓ |
|
||||
| EventBus → ProjectionStore | all events | subscribe/apply | ✓ |
|
||||
| ContextAssembler → Scheduler | `compaction_requested` | Scheduler creates compact task | ✓ |
|
||||
|
||||
**评估**：所有状态机交互路径的事件名称、方向和触发条件一致。没有发现状态机之间的死锁或悬空事件路径。
|
||||
|
||||
### 6.4 事务语义一致性
|
||||
|
||||
关键事务边界：
|
||||
|
||||
| 操作 | 事务范围 | 后置操作 | 一致性 |
|
||||
|---|---|---|---|
|
||||
| EventStore.append | event insert + domain projection | EventBus.publish (after commit) | ✓ |
|
||||
| ArtifactStore.create | temp→rename→DB record | event ingest | ✓ |
|
||||
| Task.start | task.started event + tasks update + task_attempts insert | agent.started event | ✓ |
|
||||
| Compaction | summary.created event + summaries insert | context.compaction.completed | ✓ |
|
||||
| Cross-DB write (outbox) | session event → external DB → completion event | recovery on restart | ✓ |
|
||||
|
||||
**评估**：所有事务边界遵循 runtime-semantics §3 规则（durable event + domain update 同事务，EventBus 发布在事务后）。
|
||||
|
||||
---
|
||||
|
||||
## 7. 与 DeepSeek 审查的交叉验证
|
||||
|
||||
| 发现 | DeepSeek 判定 | MIMO 判定 | 差异 |
|
||||
|---|---|---|---|
|
||||
| PromptLayerLevel 结构性不对齐 | P2 | **P1** | MIMO 升级：这不是"措辞差异"而是真实内部矛盾，影响实现一致性 |
|
||||
| Architecture gate 无独立序列图 | P2 | P2 | 一致 |
|
||||
| CLI catalog 类归属 | P2 | P2 | 一致 |
|
||||
| EventStore.project() 错误处理 | **未报告** | **P1** | MIMO 独立发现 |
|
||||
| agent.started 投影措辞 | **未报告** | P2 | MIMO 独立发现 |
|
||||
| WorkspaceManager/Scheduler 职责边界 | **未报告** | P2 | MIMO 独立发现 |
|
||||
|
||||
**差异分析**：DeepSeek 将 PromptLayer 问题标记为 P2，理由是"DD §10.2 正确记录了此映射"。MIMO 认为这是 P1，因为虽然 DD 记录了差异，但没有给出明确的解决决策——实现时仍然面临"枚举值和层名不完全对应"的问题，而这个差异发生在两个已冻结的基线之间（contracts 和 prompt-layering），属于需要明确澄清的架构级问题。
|
||||
|
||||
---
|
||||
|
||||
## 8. 覆盖性检查
|
||||
|
||||
### 8.1 契约接口字段抽样
|
||||
|
||||
| 接口 | 基线字段数 | DD 覆盖数 | 缺失 |
|
||||
|---|---|---|---|
|
||||
| TaskSpec | 9 fields | 9 | 0 |
|
||||
| WorkerResult<T> | 12 fields | 12 | 0 |
|
||||
| IpcEnvelope<T> | 9 fields | 9 | 0 |
|
||||
| PermissionDecision | 7 fields | 7 | 0 |
|
||||
| AirError | 11 fields | 11 | 0 |
|
||||
| ProviderCapabilityMatrix | 10 fields | 10 | 0 |
|
||||
| CapabilityManifestV1 | 13 fields | 13 | 0 |
|
||||
| DebugRecord | 10 fields | 10 | 0 |
|
||||
| LearnedMemory | 9 fields | 9 | 0 |
|
||||
| Diagnostic | 14 fields | 14 | 0 |
|
||||
|
||||
**10/10 接口字段完整性抽样全部通过。**
|
||||
|
||||
### 8.2 事件投影映射核对
|
||||
|
||||
55 个持久化事件逐一对比 event-registry §3 的 Domain update 描述。全部 55/55 覆盖且域更新描述准确。
|
||||
|
||||
### 8.3 DB Schema 表核对
|
||||
|
||||
19 张表（db-schema §2-§18 + §20.1-§20.2）逐一对比 DD §4.3 仓储清单 + §11.3 项目级 DB Store。19/19 全覆盖。
|
||||
|
||||
### 8.4 禁止路径核对
|
||||
|
||||
10 条 contracts §23 禁止路径逐一对比 DD §2 + §18.5。10/10 全覆盖。DD 额外添加 1 条 C4 规则（runtime → TUI import）。
|
||||
|
||||
---
|
||||
|
||||
## 9. 与前轮审查的一致性
|
||||
|
||||
| 维度 | DeepSeek | MIMO 2.5 Pro |
|
||||
|---|---|---|
|
||||
| P0 | 0 | 0 |
|
||||
| P1 | 0 | 2 |
|
||||
| P2 | 3 | 5 |
|
||||
| 综合评分 | 9.6/10 | 9.4/10 |
|
||||
| 新发现 | — | P1-02, P2-04, P2-05 |
|
||||
|
||||
**一致性结论**：两轮审查在 P0 层面一致（0 项）。MIMO 发现了 DeepSeek 未报告的 P1 级 EventStore 错误处理问题，并将 PromptLayer 结构性矛盾从 P2 升级为 P1。
|
||||
|
||||
---
|
||||
|
||||
## 10. 门禁判定
|
||||
|
||||
| 条件 | 状态 |
|
||||
|---|---|
|
||||
| P0 = 0 | PASS |
|
||||
| P1 ≤ 2（均有明确修复路径）| PASS |
|
||||
| 契约覆盖 100% | PASS |
|
||||
| 事件覆盖 100% | PASS |
|
||||
| DB Schema 覆盖 100% | PASS |
|
||||
| 状态机覆盖 100% | PASS |
|
||||
| 禁止路径全执行 | PASS |
|
||||
| 架构无循环依赖 | PASS |
|
||||
| 职责分离无泄漏 | PASS |
|
||||
| 状态机交互无死锁 | PASS |
|
||||
| 事务语义一致 | PASS |
|
||||
|
||||
**门禁结果：PASS（附 2 项 P1 修复建议）**
|
||||
|
||||
详细设计可以进入实现阶段，但建议在实现开始前明确 P1-01（PromptLayer 设计决策）和 P1-02（EventStore 错误路径文档化）。
|
||||
|
||||
---
|
||||
|
||||
## 11. P1 修复建议
|
||||
|
||||
### P1-01 修复路径
|
||||
|
||||
需要一个设计决策（ADR 或详细设计补充）：
|
||||
|
||||
**推荐方案 B**：保持枚举不变，在实现层建立映射：
|
||||
|
||||
```text
|
||||
L0 → runtime_invariant (immutable=true)
|
||||
L1 → role (immutable=true)
|
||||
L2 → (safety layer loaded by ContextAssembler as a runtime_invariant variant with immutable=true,
|
||||
source from ~/.air/permissions.yaml + project permissions)
|
||||
L3 → project_rules
|
||||
L4 → architecture (loaded from plan/todo/ADR context)
|
||||
L5 → task_spec
|
||||
L6 → evidence (loaded from artifacts/diagnostics/evidence_refs)
|
||||
L7 → conversation (loaded from messages/summaries)
|
||||
L8 → tool_output (loaded from recent tool_runs/command_runs/diagnostics)
|
||||
L9 → user_override + system_debug (merged, highest priority non-immutable layer)
|
||||
```
|
||||
|
||||
PromptLayerLoader 接口扩展为：
|
||||
|
||||
```text
|
||||
load_safety_policy(): PromptLayer // L2
|
||||
load_architecture_context(refs): PromptLayer[] // L4
|
||||
load_evidence_context(refs): PromptLayer[] // L6
|
||||
load_conversation(session_id): PromptLayer[] // L7
|
||||
load_tool_output(recent_runs): PromptLayer[] // L8
|
||||
load_immediate_instruction(): PromptLayer // L9
|
||||
```
|
||||
|
||||
### P1-02 修复路径
|
||||
|
||||
在 DD §5.3 或 §18.2 补充：
|
||||
|
||||
```text
|
||||
EventStore.append error semantics:
|
||||
- project() 内部异常 → 整个事务回滚
|
||||
- EventBus.publish() 不执行（正确：post-commit only）
|
||||
- 返回 AirError{kind: "system_error", message: "event projection failed"}
|
||||
- 如果是因为 FK-off 不一致（如引用不存在的 task_id）：
|
||||
- 记录到 developer log
|
||||
- 触发 SessionStore.referential_check()
|
||||
- Scheduler 将受影响的 task 标记为 interrupted/blocked
|
||||
- 不会部分投影：SQLite 事务保证原子性
|
||||
```
|
||||
418
AirPlan/docs/architecture/detailed-design-audit.md
Normal file
418
AirPlan/docs/architecture/detailed-design-audit.md
Normal file
@@ -0,0 +1,418 @@
|
||||
# 系统详细设计全量覆盖审计
|
||||
|
||||
Date: 2026-05-29
|
||||
Status: Full coverage audit of `system-detailed-design.md` against frozen baselines, requirements, and frozen overview
|
||||
Auditor: Claude Opus 4.8
|
||||
|
||||
This is a design-correctness audit, not a design-criticism report. It verifies that the detailed
|
||||
design fully covers and derives correctly from every frozen authority. It also freezes the overview
|
||||
design before the audit begins.
|
||||
|
||||
---
|
||||
|
||||
## 0. Pre-Audit Action: Freeze Overview Design
|
||||
|
||||
`system-overview-design.md` status was updated to **FROZEN — no further edits permitted**. All
|
||||
subsequent design work must treat it as authoritative and immutable.
|
||||
|
||||
---
|
||||
|
||||
## 1. Audit Scope and Method
|
||||
|
||||
Audited document: `AirPlan/docs/architecture/system-detailed-design.md` (2033 lines, 23 sections)
|
||||
|
||||
Authoritative sources checked (item-by-item):
|
||||
|
||||
1. `requirements.md` — functional/non-functional requirements
|
||||
2. `baselineV1.md` — architecture baseline
|
||||
3. `interface-contracts-v1.md` — frozen public TypeScript contracts (§2-§23)
|
||||
4. `event-registry-v1.md` — 55 durable + 7 ephemeral event types
|
||||
5. `db-schema-v1.md` — 19 tables, 18 closed-enum rows, FK-off rules
|
||||
6. `runtime-semantics-v1.md` — ingestion, outbox, FK-off, execution primitives
|
||||
7. `scheduler-state-machine-v1.md` — 11 Scheduler states + retry/timeout/merge policies
|
||||
8. `main-agent-state-machine.md` — 9 Main Agent states + direct mode + confirmation gating
|
||||
9. `scope-escalation-v1.md` — 7 ScopeImpactLevels, escalation routes
|
||||
10. `security-model-v1.md` — 8 PathRisk + 10 CommandRisk categories, 10 boundary rules
|
||||
11. `capability-trust-v1.md` — capability lifecycle and 5 trust levels
|
||||
12. `prompt-layering-v1.md` — L0-L9 layer definitions
|
||||
13. `provider-capability-matrix-v1.md` — provider adapter behavior
|
||||
14. `artifact-naming-v1.md` — URI/ID/filename conventions
|
||||
15. `error-taxonomy-v1.md` — ErrorKind, severity, retryability, semantic_signature
|
||||
16. `tool-registry-v1.md` — ToolCategory, ToolRegistry, streaming rules
|
||||
17. `cross-platform-matrix-v1.md` — platform tiers (referenced by Doctor)
|
||||
18. `c4/module.md` — container dependency direction
|
||||
19. `c4/code-view.md` — package/file layout and class inventory
|
||||
20. `decisions-round-1/2/3.md` — ADR decisions (cross-referenced where applicable)
|
||||
21. `idea.md` — original design intent (zero-config C++ etc.)
|
||||
22. `system-overview-design.md` (FROZEN) — container/component/flow overview
|
||||
|
||||
Method: each baseline section → check detailed design has covering section → verify the design
|
||||
derives correctly from the baseline without contradiction → note gaps (items the baseline requires
|
||||
that the detailed design omits) and drift (items where the detailed design contradicts a baseline).
|
||||
|
||||
---
|
||||
|
||||
## 2. Overall Result
|
||||
|
||||
**PASS — no blocking gaps found.**
|
||||
|
||||
The detailed design systemically covers all 22 authoritative sources. Every frozen contract has a
|
||||
class or interface that implements it. Every durable event has a projection handler. Every DB table
|
||||
has a repository. Every state machine transition is documented. Every forbidden path is enforced.
|
||||
|
||||
Summary statistics:
|
||||
|
||||
| Coverage dimension | Baseline count | DD coverage |
|
||||
|---|---|---|
|
||||
| Contracts §2-§21 interfaces | 80+ | 100% — all mapped to files and classes |
|
||||
| Contracts §23 forbidden paths | 10 | 100% — all enforced |
|
||||
| Durable event types | 55 | 100% — all in projection map |
|
||||
| Ephemeral event types | 7 | 100% — all listed with coalescing |
|
||||
| DB session tables | 17 | 100% — all have repositories |
|
||||
| DB project-level tables | 2 | 100% — both have stores |
|
||||
| DB closed-enum rows | 18 | 100% — validated on insert/update |
|
||||
| FK-off invariants | 8 | 100% — all listed with check method |
|
||||
| Scheduler states | 11 | 100% — all in state machine |
|
||||
| Main Agent states | 9 | 100% — all in state machine |
|
||||
| Code-view classes | 50+ | 100% — all have design entries |
|
||||
| Mermaid UML diagrams | 8 | Covers contracts, runtime-core, scheduler, tool/permission, worker/IPC, provider, context, agents |
|
||||
|
||||
**Drift findings: 2 minor (non-blocking), 0 blocking.**
|
||||
|
||||
---
|
||||
|
||||
## 3. Contracts Coverage
|
||||
|
||||
### 3.1 interface-contracts-v1.md §2-§21 → DD §3 map
|
||||
|
||||
Every contracts section is mapped. The contract-to-file table in DD §3 covers all 16 files from
|
||||
code-view §3 plus the `platform.ts` extension. The `IMPL` note correctly handles the superset
|
||||
from overview §4 vs code-view §3.
|
||||
|
||||
| Contracts § | Subject | DD covering section |
|
||||
|---|---|---|
|
||||
| §2 | Core primitive types + Clock/IdGenerator | §3 (ids.ts) |
|
||||
| §3 | Error (AirError, ErrorKind, 22 kinds, 4 severities, 4 retryabilities) | §3 (error.ts), §18.1 (AirError helper) |
|
||||
| §4 | EntityRef (12 EntityTypes) | §3 (event.ts) |
|
||||
| §5 | RuntimeEvent, EventSource, EventFilter | §3 (event.ts), §5 |
|
||||
| §6 | Transaction, Repository, DB records (16 types) | §4.1-§4.3, §18.2 |
|
||||
| §7 | EventBus, EventStore, EventIngestor, EventSchemaRegistry, Subscription | §5.1-§5.5 |
|
||||
| §8 | ProjectStore, SessionManager, ProjectContext, SessionContext | §6 |
|
||||
| §9 | TaskSpec (8 field families), Scheduler, TaskNode, TaskGraph | §7 |
|
||||
| §10 | IPC, IpcEnvelope, ControlMessage, WorkerRole, WorkerRuntime | §8.1-§8.3 |
|
||||
| §11 | WorkerResult (6 result subtypes), BlockerReport, VerificationResult | §8.3 |
|
||||
| §12 | ToolDefinition, ToolRegistry, ToolCategory (16 categories), streaming | §9.1 |
|
||||
| §13 | PermissionEngine, PermissionDecision, PathPolicy, 6 actions, 5 scopes | §9.2-§9.3 |
|
||||
| §14 | ArtifactStore, EvidenceStore, ArtifactRef, EvidenceRef | §11.1-§11.2 |
|
||||
| §15 | ProviderAdapter, ProviderManager, ProviderCapabilityMatrix, ModelRequirement | §12 |
|
||||
| §16 | ContextAssembler, PromptLayer, CompactionPolicy, 10 PromptLayerLevels | §10 |
|
||||
| §17 | ProjectionStore, ProjectionClient, 7 projection types | §13 |
|
||||
| §18 | CapabilityManifestV1, CapabilityRegistry, 5 trust levels | §9.5 |
|
||||
| §19 | DoctorService, DoctorRunInput/Output, Logger | §16 |
|
||||
| §20 | DebugKnowledgeStore, LearnedMemoryStore, DebugRecord, LearnedMemory | §11.3 |
|
||||
| §21 | Diagnostic, DiagnosticSeverity (4 values) | §15 (DiagnosticParser) |
|
||||
| §22 | Versioning rules (6 rules) | §3 (contracts package design rules) |
|
||||
| §23 | Boundary rules (10 forbidden paths) | §2 (dependency direction), §18.5 (security invariants) |
|
||||
|
||||
Result: **100% covered**.
|
||||
|
||||
### 3.2 Contract fidelity check
|
||||
|
||||
Every class method signature in DD §4-§17 is derived from its contracts interface. No new public
|
||||
fields are added. The `IMPL` markers denote implementation freedom within the contract boundary,
|
||||
never a contract break.
|
||||
|
||||
Example verification: DD §5.3 `EventStore.append` signature matches contracts §7 `EventStore.append`.
|
||||
DD §9.2 `PermissionEngine.evaluate` signature matches contracts §13 `PermissionEngine.evaluate`.
|
||||
|
||||
Result: **no contract drift**.
|
||||
|
||||
---
|
||||
|
||||
## 4. Event Coverage
|
||||
|
||||
### 4.1 Durable events
|
||||
|
||||
Event registry §6 lists 55 durable event names. DD §5.4 projection map covers all of them.
|
||||
|
||||
The map uses reasonable grouping where the domain update is identical:
|
||||
- `agent.completed/failed/lost/cancelled` → update agents.status (1 row, 4 event types)
|
||||
- `doctor.*` → 6 event types with append + optional artifacts/commands
|
||||
- `permission.prompt.requested/resolved` → 1 row, 2 event types
|
||||
|
||||
Every event type's domain update matches exactly what event-registry §3 specifies.
|
||||
|
||||
Result: **55/55 durable events covered**.
|
||||
|
||||
### 4.2 Ephemeral events
|
||||
|
||||
DD §5.5 lists all 7 ephemeral event types with their coalescing rule (event-registry §4):
|
||||
`agent.heartbeat`, `task.progress`, `assistant.message.delta`, `tool.progress`,
|
||||
`command.stdout.delta`, `command.stderr.delta`, `hud.frame.rendered`.
|
||||
|
||||
Result: **7/7 ephemeral events covered**.
|
||||
|
||||
### 4.3 EventStore rules
|
||||
|
||||
The six rules from event-registry §2 + runtime-semantics §3 are all present in DD §5:
|
||||
1. Durable event + domain update in same SQLite transaction → §5.3, §18.2
|
||||
2. Ephemeral events throttled/coalesced → §5.5
|
||||
3. Ephemeral → durable promotion by artifact/summary only → §5.1 (ingestor never creates tasks/promotions)
|
||||
4. Streaming deltas ephemeral; completed records durable → §5.1, §5.5
|
||||
5. route append-only → §5.3
|
||||
6. route_text = route.join("/") → §5.3
|
||||
7. Payload schema change → version increment → §5.2
|
||||
|
||||
Result: **all EventStore rules covered**.
|
||||
|
||||
---
|
||||
|
||||
## 5. DB Schema Coverage
|
||||
|
||||
### 5.1 Table → Repository mapping
|
||||
|
||||
DB schema (19 tables). DD §4.3 lists 16 repositories for session tables, §11.3 covers 2 project-level DB stores, and §4.2 covers `schema_meta` through `MigrationRunner`.
|
||||
|
||||
| DB Schema table | DD Repository | Role |
|
||||
|---|---|---|
|
||||
| schema_meta (§2) | MigrationRunner (§4.2) | Version management |
|
||||
| sessions (§3) | SessionRepository | CRUD |
|
||||
| messages (§4) | MessageRepository | CRUD + list_by_session |
|
||||
| message_drafts (§5) | MessageDraftRepository | upsert + delete_for_message |
|
||||
| events (§6) | EventRepository | insert + query |
|
||||
| tasks (§7) | TaskRepository | list_by_status + list_runnable_candidates |
|
||||
| task_dependencies (§8) | TaskDependencyRepository | list_for_task + list_dependents |
|
||||
| task_attempts (§9) | TaskAttemptRepository | next_attempt_index + list_by_task |
|
||||
| agents (§10) | AgentRepository | list_active + update_heartbeat |
|
||||
| tool_runs (§11) | ToolRunRepository | list_by_task + list_by_origin_message |
|
||||
| command_runs (§12) | CommandRunRepository | list_by_task + derived status |
|
||||
| artifacts (§13) | ArtifactRepository | list_by_entity + get_by_uri |
|
||||
| diagnostics (§14) | DiagnosticRepository | list_by_signature + list_by_command_run |
|
||||
| evidence_refs (§15) | EvidenceRepository | list_for_entity |
|
||||
| workspaces (§16) | WorkspaceRepository | list_by_status + list_gc_candidates |
|
||||
| summaries (§17) | SummaryRepository | get + insert |
|
||||
| ui_state (§18) | UiStateRepository | upsert + read (scope,key) |
|
||||
| debug_records (§20.1) | DebugKnowledgeStore (§11.3) | insert + lookup + update |
|
||||
| learned_memories (§20.2) | LearnedMemoryStore (§11.3) | insert + lookup + update_status + scan_stale |
|
||||
|
||||
Result: **19/19 tables have repository/store coverage**.
|
||||
|
||||
### 5.2 Derived command status
|
||||
|
||||
DD §4.4 correctly derives `command_runs` status from `completed_at`/`exit_code`/cancellation
|
||||
metadata (runtime-semantics §5). The five derived values match `CommandRunProjection.status`
|
||||
(contracts §17).
|
||||
|
||||
### 5.3 Closed enums
|
||||
|
||||
DD §4.5: "Every closed-enum TEXT column (db-schema §21, 18 rows) is validated on insert/update."
|
||||
The 18-row count matches db-schema §21.
|
||||
|
||||
### 5.4 FK-off invariants
|
||||
|
||||
DD §18.3 lists all 8 invariants from runtime-semantics §14. `SessionStore.referential_check()` is
|
||||
the enforcement point; it runs at startup and periodically.
|
||||
|
||||
### 5.5 WAL/NORMAL/foreign_keys OFF pragmas
|
||||
|
||||
DD §4.1 `DatabaseManager.applyPragmas` sets all three pragmas matching db-schema §1.
|
||||
|
||||
---
|
||||
|
||||
## 6. State Machine Coverage
|
||||
|
||||
### 6.1 Main Agent
|
||||
|
||||
DD §20.1 includes all 9 states from main-agent-state-machine.md:
|
||||
IDLE, CLASSIFYING, ANSWERING, DELEGATING, SCHEDULING, ARCHITECTURE_DESIGNING, CONFIRMING,
|
||||
EXECUTING, INTERRUPTING, ARCHITECTURE_REVISING, SUMMARIZING, DIRECT_MODE.
|
||||
|
||||
The state-to-permission_template table matches main-agent-state-machine §State-to-AgentRuntimeContext.
|
||||
Idle principle, direct mode rules, confirmation gating, and event emissions are all present.
|
||||
|
||||
### 6.2 Scheduler
|
||||
|
||||
DD §20.2 includes all 11 states from scheduler-state-machine-v1.md §4:
|
||||
IDLE, LOADING_GRAPH, PLANNING_WAVE, DISPATCHING, MONITORING, COLLECTING_RESULTS, MERGING,
|
||||
REVIEWING_WAVE, REPAIRING_OR_CONTINUING, COMPLETED, BLOCKED, CANCELLED.
|
||||
|
||||
All transition conditions, retry policies, timeout policies, merge conflict handling, and
|
||||
recovery semantics are present in §7.2-§7.6 + §20.2.
|
||||
|
||||
### 6.3 Task/Agent/Workspace/Capability
|
||||
|
||||
DD §20.3-§20.6 cover task status, agent status, workspace status, and capability lifecycle
|
||||
transitions, each matching the db-schema and scheduler-state-machine definitions.
|
||||
|
||||
---
|
||||
|
||||
## 7. Forbidden Path Enforcement
|
||||
|
||||
Contracts §23 defines 10 forbidden paths. DD §2 (dependency direction + forbidden edges) and
|
||||
§18.5 (security invariants) enforce all of them:
|
||||
|
||||
| Forbidden path (contracts §23) | DD enforcement point |
|
||||
|---|---|
|
||||
| TUI → SQLite direct query | §2, §13.2 |
|
||||
| TUI → runtime private service import | §2, §13.2 |
|
||||
| worker → SQLite direct write | §2, §8.1, §8.3 |
|
||||
| worker → filesystem/shell/network outside tool IPC | §2, §8.3 |
|
||||
| tool → side effect without PermissionEngine | §2, §9.1 |
|
||||
| capability → dependency install outside Doctor | §2, §9.5 |
|
||||
| provider adapter → silent semantic prompt loss | §2, §12.2 |
|
||||
| repository → scheduling policy | §2, §4.3 |
|
||||
| EventBus → recovery source of truth | §2, §5.5 |
|
||||
| LLM output → direct file/shell side effect | §2, §12.2, §18.5 |
|
||||
|
||||
Additionally, DD §2 adds `runtime → TUI import` (which is a C4 dependency rule, not a contracts
|
||||
requirement — it strengthens rather than weakens the baseline). This was previously noted in the
|
||||
overview.
|
||||
|
||||
Result: **10/10 forbidden paths enforced; 1 additional C4 rule added**.
|
||||
|
||||
---
|
||||
|
||||
## 8. UML Diagram Completeness
|
||||
|
||||
Eight Mermaid `classDiagram` blocks covering:
|
||||
|
||||
| Diagram | Contracts/entities shown | Baseline alignment |
|
||||
|---|---|---|
|
||||
| 22.1 Contracts Package | RuntimeEvent, TaskSpec, WorkerResult, AirError, ToolDefinition, PermissionDecision, ArtifactRef, EvidenceRef | Matches code-view §3 UML |
|
||||
| 22.2 Runtime Core Services | RuntimeApp, ServiceRegistry, ProjectStore, SessionManager, DatabaseManager, EventIngestor, EventStore, EventBus, ProjectionStore | Matches code-view §4 UML + additions from overview |
|
||||
| 22.3 Scheduler Subsystem | Scheduler, TaskGraph, WavePlanner, RetryPlanner, WorkspaceManager, AgentMonitor, WorkerManager | Matches code-view §4 Scheduler UML |
|
||||
| 22.4 Tool and Permission | ToolRegistry, PermissionEngine, PathClassifier, CommandRiskAnalyzer, CapabilityRegistry | Matches code-view §4 Tool/Permission UML |
|
||||
| 22.5 Worker and IPC | WorkerProcess, WorkerProtocol, WorkerRuntime, WorkerRole, 5 role classes | Matches code-view §10 Worker UML |
|
||||
| 22.6 Provider (LLM) | ProviderManager, ProviderAdapter, AnthropicAdapter, OpenAICompatibleAdapter, AnthropicCanonicalConverter, StreamNormalizer | Matches code-view §5 UML |
|
||||
| 22.7 Context and Compaction | ContextAssembler, PromptLayerLoader, CompactionPolicy, PromptLayer | Matches code-view §4 Context UML |
|
||||
| 22.8 Agents | MainAgent, ArchitectureDesigner | Matches code-view §4 Agent UML |
|
||||
|
||||
The UML diagrams use Mermaid syntax (not PlantUML as in code-view) — this is a rendering choice
|
||||
that does not affect semantic correctness.
|
||||
|
||||
Diagrams not included (these are covered textually):
|
||||
- Code-view §9 Repository UML → covered in DD §4.3 table
|
||||
- Code-view §8 CLI UML → covered in DD §17 text
|
||||
- Code-view §3 Contract Ownership table → covered in DD §3 contract-to-file map
|
||||
|
||||
Result: **all major subsystems have UML diagrams**.
|
||||
|
||||
---
|
||||
|
||||
## 9. Sequence Diagram Coverage
|
||||
|
||||
Four sequence diagrams covering the critical runtime flows:
|
||||
|
||||
| Sequence | DD section | Covers |
|
||||
|---|---|---|
|
||||
| User request → task execution → completion | §19.1 | Full flow: Main Agent → Scheduler → Executor → Reviewer → Scheduler → Main Agent |
|
||||
| Tool call with permission prompt | §19.2 | ToolRegistry → PermissionEngine → TUI → user decision → resume |
|
||||
| Compaction flow | §19.3 | ContextAssembler → Scheduler → CompactorRole → summary.created |
|
||||
| Debug knowledge capture | §19.4 | Executor failure → Scheduler → DebuggerRole → DebugKnowledgeStore |
|
||||
|
||||
Result: **key flows covered; all aligned with state machines and event sequences from baselines**.
|
||||
|
||||
---
|
||||
|
||||
## 10. Overview → Detailed Design Coverage
|
||||
|
||||
DD §21.5 traceability matrix maps every overview section to detailed design sections. Manual
|
||||
cross-check confirms:
|
||||
|
||||
| Overview § | Coverage |
|
||||
|---|---|
|
||||
| §2 System Goal | §0 authority declaration + §2 decomposition |
|
||||
| §3 System Context | §6 (Project/Session), §12 (Provider) |
|
||||
| §4 Container Overview | §2-§3 (decomposition + contracts) |
|
||||
| §5 Dependency Rules | §2 (allowed imports + forbidden edges) |
|
||||
| §6 Runtime Component Overview | §4-§11 (all components have class designs) |
|
||||
| §7 Runtime Agent Overview | §14 (Main Agent, Architecture Designer) |
|
||||
| §8 State and Data Overview | §4 (storage), §6 (project/session), §11 (artifact/evidence) |
|
||||
| §9 Event, Error, Projection | §5 (events), §9.2 (error), §13 (projection) |
|
||||
| §10 Execution Flow Overview | §7-§9, §19 (sequences) |
|
||||
| §11 IPC and Worker Overview | §8 |
|
||||
| §12 Permission and Security | §9.2-§9.3, §18.5 |
|
||||
| §13 Context, Memory, Compaction | §10, §11.3, §19.3 |
|
||||
| §14 UI/HUD and Provider | §12-§13 |
|
||||
| §15 Doctor, Restore, Recovery | §16 |
|
||||
| §16 Implementation Phase Mapping | (not design — implementation phase) |
|
||||
| §17 Validation Overview | (not design — test phase) |
|
||||
| §18 Open Items for Detailed Design | 9/12 items resolved in DD; 3 are test/mockup items |
|
||||
| §19 Readiness Decision | DD §23 freeze checklist |
|
||||
|
||||
Result: **overview fully covered by detailed design**.
|
||||
|
||||
---
|
||||
|
||||
## 11. Requirements Coverage Check
|
||||
|
||||
Key functional requirements and their detailed design handling:
|
||||
|
||||
| Requirement | Source | DD coverage |
|
||||
|---|---|---|
|
||||
| FR-001 Project-local state | requirements.md | §6.1 ProjectStore.initialize |
|
||||
| FR-009 Claude Code execution discipline | requirements.md | §8.4, §9.4 |
|
||||
| FR-019 Logging and diagnostics | requirements.md | §16.2 (Logger, DeveloperLogEncryptor, SecretRedactor) |
|
||||
| FR-020 Release gates | requirements.md | §17 (CLI release/check commands); test phase detail |
|
||||
| NFR-001 Local-first | requirements.md | §6 (project-local .air, no cloud dependency) |
|
||||
| NFR-002 Recoverability | requirements.md | §16.3 (recovery steps), §18.2 (transaction discipline) |
|
||||
| NFR-008 Security boundary preservation | requirements.md | §18.5 (security invariants) |
|
||||
|
||||
Result: **all checkable requirements covered at design level**.
|
||||
|
||||
---
|
||||
|
||||
## 12. Drift Findings
|
||||
|
||||
### Drift #1 (P2/non-blocking): `PromptLayerLevel` enum vs L# mapping in §10.2
|
||||
|
||||
DD §10.2 maps `PromptLayerLevel` enum values (from contracts §16) to L0-L9 layer names (from
|
||||
prompt-layering-v1 §2). The contracts enum has 10 values (`runtime_invariant`, `role`,
|
||||
`project_rules`, `task_spec`, `architecture`, `evidence`, `tool_output`, `conversation`,
|
||||
`user_override`, `system_debug`), but prompt-layering has a separate L2 "Safety and permission
|
||||
policy" layer that is not its own enum value — it is carried by the immutable L0/L1 layers.
|
||||
|
||||
The DD §10.2 table acknowledges this with `(safety/permission policy)` in parentheses on its
|
||||
own row without an enum value, and the IMPL note explains the mapping. This is a correct mapping
|
||||
of the enum to the layering model, not an error.
|
||||
|
||||
Assessment: **non-issue** — correctly documented tradeoff between contracts enum and layering model.
|
||||
|
||||
### Drift #2 (P2/non-blocking): `SecretRedactor` defined in two places
|
||||
|
||||
DD §9.2 (PermissionEngine) and §16.2 (Logging) both list `SecretRedactor. Note at §16.2 says
|
||||
"shared with PermissionEngine §9.2." This is a shared utility, not a duplication error.
|
||||
|
||||
Assessment: **non-issue** — correctly noted as a shared dependency.
|
||||
|
||||
---
|
||||
|
||||
## 13. Items Not Covered (Intentional)
|
||||
|
||||
The following overview §18 open items are intentionally not detailed in this design document:
|
||||
|
||||
| Item | Reason |
|
||||
|---|---|
|
||||
| fixture definitions and test harness layout | Test infrastructure, not class design |
|
||||
| release package resource manifest | Packaging phase, not design phase |
|
||||
| exact UI mockups | UI design assets, not class design |
|
||||
|
||||
These are correctly listed in DD §18 Open Items as deferred to implementation/detailed-planning
|
||||
phase.
|
||||
|
||||
---
|
||||
|
||||
## 14. Overall Verdict
|
||||
|
||||
**The system detailed design fully covers all frozen requirements, baselines, and the frozen
|
||||
overview design.**
|
||||
|
||||
- Contracts coverage: 100%
|
||||
- Event coverage: 100% (55 durable + 7 ephemeral)
|
||||
- DB schema coverage: 100% (19 tables with repositories/stores)
|
||||
- State machine coverage: 100% (6 state machines)
|
||||
- Forbidden path enforcement: 100% (10 paths)
|
||||
- UML diagram coverage: 8 diagrams across all subsystems
|
||||
- Traceability matrix: complete 5-way mapping
|
||||
|
||||
No blocking gaps were found. The design can proceed to implementation (packages/contracts → T-001+).
|
||||
320
AirPlan/docs/architecture/gpt5.5pro系统详细设计审查.md
Normal file
320
AirPlan/docs/architecture/gpt5.5pro系统详细设计审查.md
Normal file
@@ -0,0 +1,320 @@
|
||||
# GPT-5.5 Pro 系统详细设计审查
|
||||
|
||||
Date: 2026-05-29
|
||||
Status: Requires repair before freeze
|
||||
Auditor: GPT-5.5 Pro
|
||||
Scope: `system-detailed-design.md` against frozen baselines, contracts, registry, runtime semantics, code view, and frozen overview.
|
||||
|
||||
本报告只记录本轮审查发现的合同级、语义级不一致，供后续统一处理。未对原有审计报告做修改。
|
||||
|
||||
---
|
||||
|
||||
## 1. Overall Verdict
|
||||
|
||||
`system-detailed-design.md` 当前还不能作为一致、可实施的详细设计冻结版。
|
||||
|
||||
主要问题不是章节缺失，而是几处上游冻结文档之间的语义冲突没有被详细设计收束，且其中两处在详细设计中被继续放大：
|
||||
|
||||
1. Worker 退出码语义冲突。
|
||||
2. EventStore 投影职责越界。
|
||||
3. `memory.promoted` / outbox 阶段语义自相矛盾。
|
||||
4. `docs` task 类型未闭合。
|
||||
5. Prompt role/profile 类型覆盖不完整。
|
||||
6. contracts 包文件集仍有两套命名。
|
||||
|
||||
建议先修复这些合同级裂缝，再继续冻结详细设计。
|
||||
|
||||
---
|
||||
|
||||
## 2. Findings
|
||||
|
||||
### Finding 1 — High — Worker exit code 语义冲突
|
||||
|
||||
**问题**
|
||||
|
||||
Worker 退出码在不同权威文档中定义不一致。
|
||||
|
||||
`baselineV1.md` 定义：
|
||||
|
||||
- `0` = protocol-level completion, including task failed/blocked
|
||||
- `1` = uncaught exception
|
||||
- `2` = startup/protocol error
|
||||
- `3` = permission error
|
||||
- `5` = hard timeout killed
|
||||
|
||||
但 `system-overview-design.md` 和 `system-detailed-design.md` 采用另一套语义：
|
||||
|
||||
- `1` = task failed
|
||||
- `2` = crashed
|
||||
- `3` = protocol error
|
||||
- `5` = permission/policy blocked
|
||||
|
||||
**证据**
|
||||
|
||||
- `baselineV1.md:351`
|
||||
- `system-overview-design.md:856`
|
||||
- `system-detailed-design.md:566`
|
||||
|
||||
**影响**
|
||||
|
||||
实现 `WorkerManager` 时，父进程会无法稳定区分：
|
||||
|
||||
- 任务失败但协议正常
|
||||
- worker 崩溃
|
||||
- 启动/协议错误
|
||||
- 权限阻断
|
||||
- 硬超时 kill
|
||||
|
||||
这会直接影响 Scheduler 的 retry、blocked、failed、lost 判定。
|
||||
|
||||
**建议处理**
|
||||
|
||||
统一以一份权威退出码表为准，并在详细设计中明确：
|
||||
|
||||
- task failed / blocked 是否仍通过 exit code `0` 返回 WorkerResult。
|
||||
- 非零 exit code 只表示 worker/process/protocol 层异常，还是也表示业务任务失败。
|
||||
- permission blocked 应归入 WorkerResult 还是进程退出码。
|
||||
|
||||
---
|
||||
|
||||
### Finding 2 — High — EventStore.project 职责越界
|
||||
|
||||
**问题**
|
||||
|
||||
`runtime-semantics-v1.md` 明确要求 EventStore 不应创建 scheduler tasks、permission decisions、memory promotions、doctor fixes 等策略动作。
|
||||
|
||||
但 `system-detailed-design.md` 的 durable projection map 中，仍把部分跨服务/跨存储行为写进 `EventStore.project`：
|
||||
|
||||
- `context.compaction.requested` -> insert compaction task if accepted
|
||||
- `memory.promoted` -> append + write rules/skill/learned-memory.db
|
||||
- `debug.record.created` -> insert/update debug-records.db
|
||||
|
||||
**证据**
|
||||
|
||||
- `runtime-semantics-v1.md:38`
|
||||
- `runtime-semantics-v1.md:43`
|
||||
- `system-detailed-design.md:350`
|
||||
- `system-detailed-design.md:367`
|
||||
|
||||
**影响**
|
||||
|
||||
这会把 Scheduler、ExperienceMiner/Curator、DebugKnowledgeStore 等 owning service 的职责错误塞进 EventStore，并破坏 runtime-semantics 对事务边界的要求。
|
||||
|
||||
特别是：
|
||||
|
||||
- session DB event/domain projection 应在同一 SQLite transaction 内完成。
|
||||
- 外部 DB/file side effect 应走 cross-store semantics/outbox/recovery 规则。
|
||||
- EventStore 不应隐藏调度策略或 promotion 策略。
|
||||
|
||||
**建议处理**
|
||||
|
||||
将 `EventStore.project(event, tx)` 严格限制为 session DB domain table projection。
|
||||
|
||||
需要移出 EventStore 的行为：
|
||||
|
||||
- compaction task 创建：由 Scheduler 或 Context/Scheduler 协调服务处理。
|
||||
- memory/rule/skill 写入：由 ExperienceMiner/Curator owning service 处理。
|
||||
- debug-records.db 写入：由 DebugKnowledgeStore/Debugger flow 处理。
|
||||
|
||||
详细设计的 projection map 应只描述 event -> session DB domain row update，不描述跨 DB/文件副作用。
|
||||
|
||||
---
|
||||
|
||||
### Finding 3 — Medium — `memory.promoted` outbox 阶段语义自相矛盾
|
||||
|
||||
**问题**
|
||||
|
||||
`runtime-semantics-v1.md` 说明 `memory.promoted` 表示 promotion 已完成，并记录 target ref：
|
||||
|
||||
```text
|
||||
candidate was approved/promoted by owning service
|
||||
rule/skill/learned-memory write is performed by ExperienceMiner/Curator service
|
||||
session event records completed promotion and target ref
|
||||
```
|
||||
|
||||
如果文件/DB 写失败，应发 failure event，并让 candidate 保持未 promoted 或 pending repair。
|
||||
|
||||
但 `system-detailed-design.md` §18.4 又把 `memory.promoted` 同时当作：
|
||||
|
||||
1. step 1 intent/event
|
||||
2. step 4 completion evidence
|
||||
|
||||
**证据**
|
||||
|
||||
- `runtime-semantics-v1.md:145`
|
||||
- `runtime-semantics-v1.md:153`
|
||||
- `system-detailed-design.md:1161`
|
||||
|
||||
**影响**
|
||||
|
||||
同一个 event 同时表示“准备 promotion”和“已经 promotion 成功”，会导致 recovery、dedupe、UI 状态、candidate 状态无法可靠判断。
|
||||
|
||||
**建议处理**
|
||||
|
||||
拆清事件阶段：
|
||||
|
||||
- 如果需要 intent：新增或使用明确的 request/intent event。
|
||||
- `memory.promoted` 只表示 completed promotion + target ref。
|
||||
- 写入失败时发 `memory.promotion.failed` 或对应 failure event，并保持 candidate 未完成或 pending repair。
|
||||
|
||||
---
|
||||
|
||||
### Finding 4 — Medium — `docs` task 类型进入 contracts/DB，但事件与 worker output 未闭合
|
||||
|
||||
**问题**
|
||||
|
||||
`TaskType` 和 DB enum 都包含 `docs`，但事件 registry 和 worker output contract 没有闭合这一路径。
|
||||
|
||||
已包含 `docs` 的位置：
|
||||
|
||||
- `TaskType`
|
||||
- DB closed enum / task type
|
||||
|
||||
未包含 `docs` 的位置：
|
||||
|
||||
- `TaskCreatedPayload.type` 只允许五类 worker task，不含 `docs`。
|
||||
- `WorkerOutputContract` 没有 docs result 类型。
|
||||
- `system-detailed-design.md` 没有说明 `ArchitectureDesigner.update_architecture_docs` 是非 task service，还是 `docs` task 的正式执行路径。
|
||||
|
||||
**证据**
|
||||
|
||||
- `interface-contracts-v1.md:222`
|
||||
- `db-schema-v1.md:666`
|
||||
- `event-registry-v1.md:296`
|
||||
- `interface-contracts-v1.md:435`
|
||||
- `system-detailed-design.md:992`
|
||||
|
||||
**影响**
|
||||
|
||||
如果实现时按 DB/contracts 创建 `docs` task，则 event validation 和 worker result contract 会断裂；如果 `docs` 不是 task，则 DB/contracts 中的 task type 会误导实现。
|
||||
|
||||
**建议处理**
|
||||
|
||||
二选一收束：
|
||||
|
||||
1. `docs` 是正式 task type：补齐 event registry、worker output/result、Scheduler dispatch 规则。
|
||||
2. `docs` 不是 task type：从 TaskType/DB enum 中移除或标注为非 worker internal type，并明确 ArchitectureDesigner 直接服务路径。
|
||||
|
||||
---
|
||||
|
||||
### Finding 5 — Medium — Prompt role/profile 类型覆盖不完整
|
||||
|
||||
**问题**
|
||||
|
||||
`prompt-layering-v1.md` 要求内置 role 覆盖：
|
||||
|
||||
- `main`
|
||||
- `architecture`
|
||||
- `scheduler`
|
||||
- `executor`
|
||||
- `reviewer`
|
||||
- `debugger`
|
||||
- `compactor`
|
||||
- `experience_miner`
|
||||
|
||||
但 `interface-contracts-v1.md` 的 `AgentType` 只覆盖 worker role。`PromptLayerLoader.load_role(role: AgentType)` 因而无法类型化加载 main/architecture/scheduler role。
|
||||
|
||||
`system-detailed-design.md` 沿用了该接口，但没有补一个 `PromptRole` / `RuntimeRole` union 来承接非 worker role。
|
||||
|
||||
**证据**
|
||||
|
||||
- `prompt-layering-v1.md:71`
|
||||
- `interface-contracts-v1.md:142`
|
||||
- `interface-contracts-v1.md:1049`
|
||||
- `system-detailed-design.md:769`
|
||||
|
||||
**影响**
|
||||
|
||||
Main Agent、Architecture Designer、Scheduler 的 prompt role/profile 在设计上没有类型入口，实现时可能被迫用 string escape hatch，削弱 prompt layering 的冻结语义。
|
||||
|
||||
**建议处理**
|
||||
|
||||
补一个覆盖所有 prompt profile 的类型，例如：
|
||||
|
||||
```ts
|
||||
export type PromptRole =
|
||||
| "main"
|
||||
| "architecture"
|
||||
| "scheduler"
|
||||
| WorkerRole
|
||||
```
|
||||
|
||||
并将 `PromptLayerLoader.load_role` 参数从 `AgentType` 调整为完整 prompt role 类型，或明确 `AgentType` 扩展为包含 runtime roles。
|
||||
|
||||
---
|
||||
|
||||
### Finding 6 — Low — contracts 包文件集仍有两套命名
|
||||
|
||||
**问题**
|
||||
|
||||
`c4/code-view.md` 期望 contracts 包文件集为：
|
||||
|
||||
```text
|
||||
ids.ts
|
||||
runtime.ts
|
||||
event.ts
|
||||
ipc.ts
|
||||
task.ts
|
||||
worker-result.ts
|
||||
tool.ts
|
||||
artifact.ts
|
||||
evidence.ts
|
||||
project.ts
|
||||
provider.ts
|
||||
permission.ts
|
||||
ui.ts
|
||||
error.ts
|
||||
```
|
||||
|
||||
但 `system-overview-design.md` 期望另一套文件集：
|
||||
|
||||
```text
|
||||
types.ts
|
||||
errors.ts
|
||||
events.ts
|
||||
storage.ts
|
||||
project.ts
|
||||
scheduler.ts
|
||||
workers.ts
|
||||
tools.ts
|
||||
permissions.ts
|
||||
artifacts.ts
|
||||
providers.ts
|
||||
context.ts
|
||||
projection.ts
|
||||
capabilities.ts
|
||||
doctor.ts
|
||||
knowledge.ts
|
||||
```
|
||||
|
||||
`system-detailed-design.md` 引用 code-view，但没有明确最终文件树如何处理这两套命名。
|
||||
|
||||
**证据**
|
||||
|
||||
- `c4/code-view.md:67`
|
||||
- `system-overview-design.md:196`
|
||||
|
||||
**影响**
|
||||
|
||||
后续脚手架可能出现重复文件、错位 re-export、或者实现者不知道哪份文件树是冻结目标。
|
||||
|
||||
**建议处理**
|
||||
|
||||
在详细设计中冻结唯一 contracts package file tree，并明确另一套命名是：
|
||||
|
||||
- 已废弃；或
|
||||
- overview-level logical grouping；或
|
||||
- code-view 需要更新的旧版本。
|
||||
|
||||
---
|
||||
|
||||
## 3. Recommended Repair Order
|
||||
|
||||
1. 统一 Worker exit code 语义。
|
||||
2. 重写 EventStore durable projection map，移除所有跨服务/跨存储副作用。
|
||||
3. 拆清 `memory.promoted` 的 intent/completion 事件阶段。
|
||||
4. 决定 `docs` 是否为正式 task type，并补齐或移除相关 contracts。
|
||||
5. 补齐 prompt role/profile 类型模型。
|
||||
6. 冻结 contracts 包唯一文件树。
|
||||
|
||||
前三项会直接影响 runtime 核心实现，应优先处理。
|
||||
520
AirPlan/docs/architecture/opus4.8系统详细设计审查.md
Normal file
520
AirPlan/docs/architecture/opus4.8系统详细设计审查.md
Normal file
@@ -0,0 +1,520 @@
|
||||
# Opus 4.8 系统详细设计全量交叉审查
|
||||
|
||||
Date: 2026-05-29
|
||||
Reviewer: Claude Opus 4.8 (independent multi-model cross-review)
|
||||
Status: Full cross-verification with independent findings and prior-review validation
|
||||
Scope: `system-detailed-design.md` against all frozen baselines, frozen overview, internal consistency, and architecture soundness
|
||||
|
||||
---
|
||||
|
||||
## 1. 审查方法
|
||||
|
||||
### 1.1 审查对象
|
||||
|
||||
`AirPlan/docs/architecture/system-detailed-design.md`（2033 行，23 节）
|
||||
|
||||
### 1.2 审查输入
|
||||
|
||||
| 文档 | 角色 |
|
||||
|---|---|
|
||||
| `interface-contracts-v1.md` (23 节) | 接口契约 |
|
||||
| `event-registry-v1.md` (55 durable + 7 ephemeral) | 事件注册表 |
|
||||
| `db-schema-v1.md` (19 表, 18 个关闭枚举) | 数据库 Schema |
|
||||
| `runtime-semantics-v1.md` (19 节) | 运行时语义 |
|
||||
| `scheduler-state-machine-v1.md` (11 节) | 调度器状态机 |
|
||||
| `main-agent-state-machine.md` | 主代理状态机 |
|
||||
| `prompt-layering-v1.md` (L0-L9) | 提示分层 |
|
||||
| `scope-escalation-v1.md` (13 节) | 作用域升级 |
|
||||
| `security-model-v1.md` (8 PathRisk + 10 CommandRisk) | 安全模型 |
|
||||
| `capability-trust-v1.md` | 能力信任 |
|
||||
| `baselineV1.md` | 架构基线 |
|
||||
| `c4/code-view.md` | C4 代码视图 |
|
||||
| `system-overview-design.md` (FROZEN) | 概要设计 |
|
||||
|
||||
### 1.3 前轮审查报告
|
||||
|
||||
| 审查者 | 结论 | P0 | P1 | P2 |
|
||||
|---|---|---|---|---|
|
||||
| DeepSeek | PASS | 0 | 0 | 3 |
|
||||
| MIMO 2.5 Pro | PASS (附修复建议) | 0 | 2 | 5 |
|
||||
| GPT-5.5 Pro | Requires repair | 0 | 2 (High) | 4 (Medium/Low) |
|
||||
|
||||
### 1.4 审查方法
|
||||
|
||||
1. 独立全量覆盖核对（不依赖前轮结论）
|
||||
2. 前轮发现的独立验证
|
||||
3. 寻找前轮可能遗漏的新问题
|
||||
4. 基线间冲突的根因分析
|
||||
5. 架构合理性和内在一致性评估
|
||||
|
||||
---
|
||||
|
||||
## 2. 总体评估
|
||||
|
||||
### 2.1 评分
|
||||
|
||||
| 维度 | 得分 | 说明 |
|
||||
|---|---|---|
|
||||
| 契约覆盖 | 9.5/10 | 接口字段全覆盖，PromptLayerLevel/AgentType 类型边界有缺口 |
|
||||
| 事件覆盖 | 10/10 | 55 durable + 7 ephemeral 全覆盖 |
|
||||
| DB Schema 覆盖 | 10/10 | 19 表全仓储 |
|
||||
| 状态机覆盖 | 10/10 | 6 个状态机全覆盖 |
|
||||
| 基线一致性 | 7.5/10 | 2 处基线间冲突未收束，1 处详细设计放大了冲突 |
|
||||
| 架构合理性 | 9.0/10 | 依赖方向正确，职责分离良好，但 EventStore 职责边界模糊 |
|
||||
| 可实现性 | 8.5/10 | 方法签名可编码，但 3 处需要设计决策才能实现 |
|
||||
|
||||
**综合评分：9.1/10**
|
||||
|
||||
### 2.2 结论
|
||||
|
||||
详细设计在覆盖性上是完整的，但存在 **3 处需要在实现前解决的基线级冲突**。这些冲突不是详细设计本身的错误，而是上游冻结文档之间的语义不一致，详细设计未能收束它们。
|
||||
|
||||
**建议**：在冻结详细设计前，先修复基线间冲突，或在详细设计中明确记录设计决策来收束这些冲突。
|
||||
|
||||
---
|
||||
|
||||
## 3. 前轮发现验证
|
||||
|
||||
### 3.1 GPT-5.5 Pro 发现验证
|
||||
|
||||
| Finding | GPT-5.5 判定 | Opus 4.8 验证 | 结论 |
|
||||
|---|---|---|---|
|
||||
| Worker exit code 语义冲突 | High | **确认** | 真实基线冲突，需要修复 |
|
||||
| EventStore.project 职责越界 | High | **部分确认** | 措辞问题，非职责越界（见 §4.1） |
|
||||
| `memory.promoted` outbox 语义 | Medium | **确认** | 事件阶段语义不清 |
|
||||
| `docs` task 类型未闭合 | Medium | **确认** | 需要设计决策 |
|
||||
| Prompt role/profile 类型不完整 | Medium | **确认** | AgentType 不覆盖 main/architecture/scheduler |
|
||||
| contracts 包文件集两套命名 | Low | **确认** | 需要统一 |
|
||||
|
||||
### 3.2 MIMO 2.5 Pro 发现验证
|
||||
|
||||
| Finding | MIMO 判定 | Opus 4.8 验证 | 结论 |
|
||||
|---|---|---|---|
|
||||
| PromptLayerLevel 枚举与 L0-L9 不对齐 | P1 | **确认** | 真实结构性不匹配 |
|
||||
| EventStore.project() 错误处理未定义 | P1 | **确认** | 需要补充错误语义 |
|
||||
| agent.started 投影措辞 | P2 | **确认** | 含糊但可接受 |
|
||||
| WorkspaceManager/Scheduler 职责边界 | P2 | **确认** | 隐含分工但未显式标注 |
|
||||
|
||||
### 3.3 DeepSeek 发现验证
|
||||
|
||||
| Finding | DeepSeek 判定 | Opus 4.8 验证 | 结论 |
|
||||
|---|---|---|---|
|
||||
| PromptLayerLevel 枚举映射 | P2 | **升级为 P1** | 同意 MIMO 的升级判定 |
|
||||
| Architecture gate 无独立序列图 | P2 | **确认** | 可从文本推导，非阻塞 |
|
||||
| CLI catalog 类归属 | P2 | **确认** | IMPL 范围，非阻塞 |
|
||||
|
||||
---
|
||||
|
||||
## 4. Opus 4.8 独立发现
|
||||
|
||||
### 4.1 Finding O1 — High — Worker exit code 基线冲突（验证 + 根因分析）
|
||||
|
||||
**问题**
|
||||
|
||||
`baselineV1.md` §8 定义的 worker exit code 语义与 `system-overview-design.md` §11 和 `system-detailed-design.md` §8.1 不一致。
|
||||
|
||||
**baselineV1.md:351-360**（冻结基线）：
|
||||
|
||||
```text
|
||||
0 protocol-level completion, including task failed/blocked
|
||||
1 uncaught exception
|
||||
2 startup/protocol error
|
||||
3 permission error
|
||||
4 parent cancelled
|
||||
5 hard timeout killed
|
||||
```
|
||||
|
||||
**system-overview-design.md:856-866** 和 **system-detailed-design.md:566-569**：
|
||||
|
||||
```text
|
||||
0 success
|
||||
1 task failed
|
||||
2 crashed
|
||||
3 protocol error
|
||||
4 cancelled
|
||||
5 permission/policy blocked
|
||||
```
|
||||
|
||||
**根因分析**
|
||||
|
||||
这不是详细设计的错误，而是 **概要设计在冻结时已经与基线冲突**。概要设计声称"frozen source documents are authoritative"，但它自己定义了一套不同的 exit code 语义。详细设计沿用了概要设计的定义，从而继承了这个冲突。
|
||||
|
||||
**关键语义差异**：
|
||||
|
||||
| Exit code | baselineV1 | overview/DD | 冲突点 |
|
||||
|---|---|---|---|
|
||||
| 0 | protocol-level completion (包括 task failed/blocked) | success | **task failed 是 0 还是 1？** |
|
||||
| 1 | uncaught exception | task failed | **task failed 是业务失败还是进程异常？** |
|
||||
| 2 | startup/protocol error | crashed | **crashed 是否包含 startup error？** |
|
||||
| 3 | permission error | protocol error | **permission 和 protocol 互换了** |
|
||||
| 5 | hard timeout killed | permission/policy blocked | **timeout 和 permission 互换了** |
|
||||
|
||||
**影响**
|
||||
|
||||
`WorkerManager` 实现时无法确定：
|
||||
- task failed/blocked 应该返回 exit code 0（baselineV1）还是 1（overview/DD）
|
||||
- permission blocked 应该返回 exit code 3（baselineV1）还是 5（overview/DD）
|
||||
- Scheduler 的 retry/blocked/failed/lost 判定逻辑会因此不确定
|
||||
|
||||
**建议处理**
|
||||
|
||||
1. 确定哪份文档是权威：baselineV1 还是 overview
|
||||
2. 如果 baselineV1 是权威，修复 overview 和 DD
|
||||
3. 如果 overview 是权威，记录 ADR 说明 baselineV1 §8 被 overview §11 取代
|
||||
4. 无论哪种，DD 应明确：task failed/blocked 通过 WorkerResult 返回，exit code 0 表示协议正常完成
|
||||
|
||||
---
|
||||
|
||||
### 4.2 Finding O2 — High — EventStore.project 职责边界澄清
|
||||
|
||||
**问题**
|
||||
|
||||
GPT-5.5 Pro 报告 EventStore.project 职责越界，但 Opus 4.8 认为这是 **措辞问题而非真正的职责越界**。
|
||||
|
||||
**DD §5.4 投影映射表**：
|
||||
|
||||
```text
|
||||
context.compaction.requested | insert compaction task if accepted
|
||||
memory.promoted | append + write rules/skill/learned-memory.db via owner (outbox §18.4)
|
||||
debug.record.created | insert/update debug-records.db (outbox §18.4) + append session event
|
||||
```
|
||||
|
||||
**runtime-semantics-v1.md:43**：
|
||||
|
||||
```text
|
||||
EventStore must not create scheduler tasks, permission decisions, memory promotions, or doctor fixes by policy.
|
||||
```
|
||||
|
||||
**Opus 4.8 分析**
|
||||
|
||||
DD §5.4 的措辞确实容易误解，但仔细阅读后：
|
||||
|
||||
1. `context.compaction.requested | insert compaction task if accepted` — 这里的 "if accepted" 暗示 Scheduler 做决策，EventStore 只是记录事件。但措辞不清。
|
||||
|
||||
2. `memory.promoted | append + write ... via owner (outbox §18.4)` — "via owner" 明确说明写入由 owning service 执行，EventStore 只 append 事件。
|
||||
|
||||
3. `debug.record.created | insert/update debug-records.db (outbox §18.4)` — 同样引用 outbox 模型，说明外部写入不在 EventStore 事务内。
|
||||
|
||||
**真正的问题**
|
||||
|
||||
DD §5.4 的投影映射表混合了两种不同的内容：
|
||||
- session DB domain projection（应该在 EventStore.project 内）
|
||||
- cross-DB/file side effects（应该由 owning service 处理，EventStore 只 append 事件）
|
||||
|
||||
这种混合导致读者误解 EventStore 的职责边界。
|
||||
|
||||
**建议处理**
|
||||
|
||||
将 DD §5.4 拆分为两个表：
|
||||
1. **Session DB projection map**：只包含 session DB domain table updates
|
||||
2. **Cross-store side effect triggers**：说明哪些事件触发 owning service 的外部操作
|
||||
|
||||
---
|
||||
|
||||
### 4.3 Finding O3 — Medium — PromptLayerLoader 接口与 prompt-layering 层定义不匹配
|
||||
|
||||
**问题**
|
||||
|
||||
`prompt-layering-v1.md` §2 定义了 L0-L9 共 10 层，但 `interface-contracts-v1.md` §16 的 `PromptLayerLoader` 接口只有 4 个方法：
|
||||
|
||||
```ts
|
||||
export interface PromptLayerLoader {
|
||||
load_runtime_invariant(): PromptLayer // L0
|
||||
load_role(role: AgentType): PromptLayer // L1
|
||||
load_project_rules(project: ProjectContext): PromptLayer[] // L3
|
||||
load_task_context(spec: TaskSpec, refs: TaskContextRefs): PromptLayer[] // L5
|
||||
}
|
||||
```
|
||||
|
||||
**缺失的层**：
|
||||
|
||||
| Layer | Name | Loader method |
|
||||
|---|---|---|
|
||||
| L2 | Safety and permission policy | **缺失** |
|
||||
| L4 | Architecture baseline and current plan | **缺失** |
|
||||
| L6 | Relevant code/artifacts/evidence | **缺失** |
|
||||
| L7 | Recent conversation and decision context | **缺失** |
|
||||
| L8 | Tool result history / diagnostics | **缺失** |
|
||||
| L9 | Immediate instruction | **缺失** |
|
||||
|
||||
**DD §10.2 的处理**
|
||||
|
||||
DD §10.2 承认了这个差异，并用 IMPL 注释说明：
|
||||
|
||||
```text
|
||||
IMPL note: contracts §16 enumerates 10 PromptLayerLevel symbols; prompt-layering L2 (safety) is
|
||||
carried by the runtime_invariant/role immutable layers and a dedicated safety layer is loaded with
|
||||
immutable=true.
|
||||
```
|
||||
|
||||
但这只解释了 L2，没有解释 L4-L9 如何加载。
|
||||
|
||||
**影响**
|
||||
|
||||
实现 `ContextAssembler` 时，需要加载 10 层，但 `PromptLayerLoader` 接口只提供 4 个方法。实现者必须：
|
||||
- 扩展接口（违反冻结契约）
|
||||
- 在 `load_task_context` 中塞入所有剩余层（违反单一职责）
|
||||
- 在 `ContextAssembler` 中硬编码剩余层的加载逻辑（绕过 Loader 抽象）
|
||||
|
||||
**建议处理**
|
||||
|
||||
在 DD 中明确记录设计决策：
|
||||
|
||||
```text
|
||||
PromptLayerLoader 接口只覆盖需要外部配置/数据的层（L0, L1, L3, L5）。
|
||||
其他层由 ContextAssembler 内部组装：
|
||||
- L2 Safety: 从 PermissionEngine 获取当前 permission profile
|
||||
- L4 Architecture: 从 TaskSpec.context_refs.arc_ref 加载
|
||||
- L6 Evidence: 从 TaskSpec.context_refs.artifacts 加载
|
||||
- L7 Conversation: 从 SessionStore.messages 加载
|
||||
- L8 Tool output: 从 SessionStore.tool_runs/command_runs 加载
|
||||
- L9 Immediate: 从 TaskSpec.description/acceptance_criteria 构建
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 4.4 Finding O4 — Medium — AgentType 不覆盖 runtime roles
|
||||
|
||||
**问题**
|
||||
|
||||
`interface-contracts-v1.md` §5 定义：
|
||||
|
||||
```ts
|
||||
export type AgentType = "executor" | "reviewer" | "debugger" | "compactor" | "experience_miner"
|
||||
```
|
||||
|
||||
但 `prompt-layering-v1.md` §3.1 要求 L1 role 覆盖：
|
||||
|
||||
```text
|
||||
built-in role prompt for main/architecture/scheduler/executor/reviewer/debugger/compactor/experience_miner
|
||||
```
|
||||
|
||||
`main`, `architecture`, `scheduler` 不在 `AgentType` 中。
|
||||
|
||||
**影响**
|
||||
|
||||
`PromptLayerLoader.load_role(role: AgentType)` 无法类型安全地加载 Main Agent、Architecture Designer、Scheduler 的 role prompt。
|
||||
|
||||
**DD §10.2 的处理**
|
||||
|
||||
DD 沿用了 contracts 的 `AgentType`，没有补充 runtime role 类型。
|
||||
|
||||
**建议处理**
|
||||
|
||||
在 DD 中明确：
|
||||
|
||||
```text
|
||||
AgentType 只覆盖 worker roles（child process agents）。
|
||||
Runtime roles（main, architecture, scheduler）不通过 PromptLayerLoader.load_role 加载，
|
||||
而是由 MainAgent/ArchitectureDesigner/Scheduler 内部硬编码其 role prompt。
|
||||
```
|
||||
|
||||
或者建议在 contracts 中添加：
|
||||
|
||||
```ts
|
||||
export type RuntimeRole = "main" | "architecture" | "scheduler"
|
||||
export type PromptRole = RuntimeRole | AgentType
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 4.5 Finding O5 — Low — DD §18.4 outbox 示例与 runtime-semantics 不一致
|
||||
|
||||
**问题**
|
||||
|
||||
DD §18.4 的 outbox 示例：
|
||||
|
||||
```text
|
||||
Example: memory.promoted → session event (step 1) → LearnedMemoryStore.insert (step 3) →
|
||||
memory.promoted completion evidence (step 4).
|
||||
```
|
||||
|
||||
这暗示 `memory.promoted` 同时是 step 1 的 intent event 和 step 4 的 completion event。
|
||||
|
||||
但 `runtime-semantics-v1.md` §6.4 说：
|
||||
|
||||
```text
|
||||
memory.promoted means:
|
||||
candidate was approved/promoted by owning service
|
||||
rule/skill/learned-memory write is performed by ExperienceMiner/Curator service
|
||||
session event records completed promotion and target ref
|
||||
```
|
||||
|
||||
这里 `memory.promoted` 只表示 completed promotion，不是 intent。
|
||||
|
||||
**影响**
|
||||
|
||||
如果 `memory.promoted` 是 completion event，那 step 1 的 intent event 是什么？DD 没有说明。
|
||||
|
||||
**建议处理**
|
||||
|
||||
明确 outbox 流程：
|
||||
|
||||
```text
|
||||
1. memory.candidate.created (intent/request)
|
||||
2. ExperienceMiner/Curator 审批
|
||||
3. LearnedMemoryStore.insert
|
||||
4. memory.promoted (completion)
|
||||
```
|
||||
|
||||
或者如果 `memory.promoted` 确实是 intent+completion 合一，需要在 DD 中明确说明这是一个简化设计，并解释 recovery 如何区分 pending 和 completed。
|
||||
|
||||
---
|
||||
|
||||
## 5. 覆盖性检查
|
||||
|
||||
### 5.1 契约覆盖
|
||||
|
||||
| 契约章节 | DD 覆盖 | 状态 |
|
||||
|---|---|---|
|
||||
| §2 Core primitives | §3 ids.ts | ✓ |
|
||||
| §3 Error | §3 error.ts, §18.1 | ✓ |
|
||||
| §4 EntityRef | §3 event.ts | ✓ |
|
||||
| §5 RuntimeEvent | §3 event.ts, §5 | ✓ |
|
||||
| §6 Transaction/Repository | §4.1-§4.3, §18.2 | ✓ |
|
||||
| §7 EventBus/Store/Ingestor | §5.1-§5.5 | ✓ |
|
||||
| §8 Project/Session | §6 | ✓ |
|
||||
| §9 Task/Scheduler | §7 | ✓ |
|
||||
| §10 IPC | §8.1-§8.3 | ✓ |
|
||||
| §11 WorkerResult | §8.3 | ✓ |
|
||||
| §12 Tool | §9.1 | ✓ |
|
||||
| §13 Permission | §9.2-§9.3 | ✓ |
|
||||
| §14 Artifact/Evidence | §11.1-§11.2 | ✓ |
|
||||
| §15 Provider | §12 | ✓ |
|
||||
| §16 Context/Prompt | §10 | ✓ |
|
||||
| §17 Projection | §13 | ✓ |
|
||||
| §18 Capability | §9.5 | ✓ |
|
||||
| §19 Doctor | §16 | ✓ |
|
||||
| §20 Knowledge | §11.3 | ✓ |
|
||||
| §21 Diagnostic | §15 | ✓ |
|
||||
| §22 Versioning | §3 | ✓ |
|
||||
| §23 Forbidden paths | §2, §18.5 | ✓ |
|
||||
|
||||
**结果：23/23 契约章节全覆盖**
|
||||
|
||||
### 5.2 事件覆盖
|
||||
|
||||
55 个 durable 事件全部在 DD §5.4 投影映射表中覆盖。
|
||||
7 个 ephemeral 事件全部在 DD §5.5 中列出。
|
||||
|
||||
**结果：62/62 事件全覆盖**
|
||||
|
||||
### 5.3 DB Schema 覆盖
|
||||
|
||||
19 张表全部有对应的 Repository 或 Store。
|
||||
|
||||
**结果：19/19 表全覆盖**
|
||||
|
||||
### 5.4 状态机覆盖
|
||||
|
||||
| 状态机 | DD 覆盖 | 状态 |
|
||||
|---|---|---|
|
||||
| Main Agent (9 states) | §14.1, §20.1 | ✓ |
|
||||
| Scheduler (11 states) | §7, §20.2 | ✓ |
|
||||
| Task status (7 values) | §20.3 | ✓ |
|
||||
| Agent status (6 values) | §20.4 | ✓ |
|
||||
| Workspace status (5 values) | §20.5 | ✓ |
|
||||
| Capability lifecycle (8 phases) | §9.5, §20.6 | ✓ |
|
||||
|
||||
**结果：6/6 状态机全覆盖**
|
||||
|
||||
### 5.5 禁止路径覆盖
|
||||
|
||||
10 条 contracts §23 禁止路径全部在 DD §2 和 §18.5 中强制执行。
|
||||
|
||||
**结果：10/10 禁止路径全覆盖**
|
||||
|
||||
---
|
||||
|
||||
## 6. 架构合理性分析
|
||||
|
||||
### 6.1 依赖方向
|
||||
|
||||
```text
|
||||
contracts → (none)
|
||||
llm → contracts
|
||||
toolchain-cpp → contracts
|
||||
tui → contracts
|
||||
runtime → contracts, llm (facade only)
|
||||
cli → contracts, runtime, tui, llm, toolchain-cpp
|
||||
workers → contracts + WorkerRuntime IPC (no direct runtime import)
|
||||
```
|
||||
|
||||
**评估**：完全正确。无循环依赖。
|
||||
|
||||
### 6.2 职责分离
|
||||
|
||||
| 组件 | 职责边界 | 评估 |
|
||||
|---|---|---|
|
||||
| EventIngestor | 不创建 scheduler/permission/memory 决策 | ✓ |
|
||||
| EventStore | 持久化 + session DB projection | ✓ (但措辞需澄清) |
|
||||
| EventBus | 不是恢复源 | ✓ |
|
||||
| SessionStore | 不含调度/权限/投影策略 | ✓ |
|
||||
| Scheduler | 不是编码代理 | ✓ |
|
||||
| ToolRegistry | 所有 side effect 经过 PermissionEngine | ✓ |
|
||||
| PermissionEngine | 不绕过 credential/system-sensitive override | ✓ |
|
||||
| TUI | 只依赖 ProjectionClient/contracts | ✓ |
|
||||
| ContextAssembler | 不自行压缩 | ✓ |
|
||||
|
||||
**评估**：职责分离良好，无泄漏。
|
||||
|
||||
### 6.3 事务语义
|
||||
|
||||
所有 durable event + domain update 在同一 SQLite transaction 内。
|
||||
EventBus publish 在 commit 后。
|
||||
Cross-DB writes 使用 outbox 模型。
|
||||
|
||||
**评估**：事务语义正确。
|
||||
|
||||
---
|
||||
|
||||
## 7. 门禁判定
|
||||
|
||||
| 条件 | 状态 |
|
||||
|---|---|
|
||||
| P0 = 0 | **PASS** |
|
||||
| 契约覆盖 100% | **PASS** |
|
||||
| 事件覆盖 100% | **PASS** |
|
||||
| DB Schema 覆盖 100% | **PASS** |
|
||||
| 状态机覆盖 100% | **PASS** |
|
||||
| 禁止路径全执行 | **PASS** |
|
||||
| 架构无循环依赖 | **PASS** |
|
||||
| 职责分离无泄漏 | **PASS** |
|
||||
| 基线间冲突已收束 | **FAIL** (3 处未收束) |
|
||||
|
||||
**门禁结果：CONDITIONAL PASS**
|
||||
|
||||
详细设计在覆盖性和架构合理性上通过，但存在 3 处基线间冲突需要在冻结前解决：
|
||||
|
||||
1. Worker exit code 语义冲突（baselineV1 vs overview/DD）
|
||||
2. PromptLayerLoader 接口与 prompt-layering 层定义不匹配
|
||||
3. `memory.promoted` outbox 阶段语义不清
|
||||
|
||||
---
|
||||
|
||||
## 8. 修复建议优先级
|
||||
|
||||
| 优先级 | Finding | 建议处理 |
|
||||
|---|---|---|
|
||||
| **P0** | Worker exit code 冲突 | 发布 ADR 明确 baselineV1 §8 被 overview §11 取代，或修复 overview/DD |
|
||||
| **P1** | EventStore.project 措辞 | 拆分 DD §5.4 为 session DB projection 和 cross-store triggers 两个表 |
|
||||
| **P1** | PromptLayerLoader 接口 | 在 DD §10.2 明确记录 L2/L4-L9 的加载方式 |
|
||||
| **P2** | AgentType 不覆盖 runtime roles | 在 DD 中明确 runtime roles 的 prompt 加载方式 |
|
||||
| **P2** | `memory.promoted` outbox 语义 | 明确 intent event 和 completion event 的区分 |
|
||||
| **P3** | contracts 包文件集命名 | 在 DD 中冻结唯一文件树 |
|
||||
| **P3** | `docs` task 类型 | 决定是正式 task type 还是移除 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 与前轮审查的一致性总结
|
||||
|
||||
| 审查者 | P0 | P1 | P2 | 综合评分 | Opus 4.8 验证 |
|
||||
|---|---|---|---|---|---|
|
||||
| DeepSeek | 0 | 0 | 3 | 9.6/10 | 过于乐观，遗漏了基线冲突 |
|
||||
| MIMO 2.5 Pro | 0 | 2 | 5 | 9.4/10 | 准确，但未深入基线冲突根因 |
|
||||
| GPT-5.5 Pro | 0 | 2 | 4 | — | 准确，发现了基线冲突 |
|
||||
| **Opus 4.8** | 0 | 2 | 5 | 9.1/10 | 验证前轮 + 根因分析 + 修复建议 |
|
||||
|
||||
**多模型审查结论**：
|
||||
|
||||
四轮审查在覆盖性上一致（100%），在基线冲突上逐步深入。Opus 4.8 确认 GPT-5.5 Pro 发现的 Worker exit code 冲突是真实的基线级问题，需要在冻结前解决。
|
||||
2033
AirPlan/docs/architecture/system-detailed-design.md
Normal file
2033
AirPlan/docs/architecture/system-detailed-design.md
Normal file
File diff suppressed because it is too large
Load Diff
@@ -1,7 +1,7 @@
|
||||
# AirCoding V1.0.0 Alpha System Overview Design
|
||||
|
||||
Date: 2026-05-29
|
||||
Status: System overview design for V1.0.0 Alpha after multi-model audit repair
|
||||
Status: FROZEN — no further edits permitted. This document is the authoritative overview for detailed design and implementation.
|
||||
Scope: Architecture-level design. No implementation code.
|
||||
|
||||
## 1. Purpose
|
||||
|
||||
302
AirPlan/docs/architecture/多模型系统详细设计交叉审查汇总.md
Normal file
302
AirPlan/docs/architecture/多模型系统详细设计交叉审查汇总.md
Normal file
@@ -0,0 +1,302 @@
|
||||
# 多模型系统详细设计交叉审查汇总
|
||||
|
||||
Date: 2026-05-29
|
||||
Status: Multi-model cross-review synthesis
|
||||
Scope: `system-detailed-design.md` against all frozen baselines, frozen overview, and internal consistency
|
||||
|
||||
---
|
||||
|
||||
## 1. 审查概览
|
||||
|
||||
### 1.1 参与模型
|
||||
|
||||
| 模型 | 审查轮次 | 审查重点 |
|
||||
|---|---|---|
|
||||
| DeepSeek | 第 1 轮 | 基线覆盖性全量核对 |
|
||||
| MIMO 2.5 Pro | 第 2 轮 | 内在一致性 + 架构合理性 |
|
||||
| GPT-5.5 Pro | 第 3 轮 | 基线间冲突检测 |
|
||||
| Claude Opus 4.8 | 第 4 轮 | 前轮验证 + 根因分析 + 修复建议 |
|
||||
|
||||
### 1.2 审查输入
|
||||
|
||||
- 22 份冻结基线文档
|
||||
- 1 份已冻结概要设计 (`system-overview-design.md`)
|
||||
- 详细设计文档 (`system-detailed-design.md`, 2033 行, 23 节)
|
||||
|
||||
---
|
||||
|
||||
## 2. 各模型审查结论
|
||||
|
||||
| 模型 | 结论 | P0 | P1 | P2 | 综合评分 |
|
||||
|---|---|---|---|---|---|
|
||||
| DeepSeek | **PASS** | 0 | 0 | 3 | 9.6/10 |
|
||||
| MIMO 2.5 Pro | **PASS (附修复建议)** | 0 | 2 | 5 | 9.4/10 |
|
||||
| GPT-5.5 Pro | **Requires repair** | 0 | 2 | 4 | — |
|
||||
| Opus 4.8 | **CONDITIONAL PASS** | 0 | 2 | 5 | 9.1/10 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 覆盖性共识
|
||||
|
||||
四轮审查在覆盖性上达成完全共识：
|
||||
|
||||
| 维度 | 基线要求 | DD 覆盖 | 共识 |
|
||||
|---|---|---|---|
|
||||
| 契约接口 | 23 章节, 80+ 接口 | 100% | ✓ 全覆盖 |
|
||||
| 持久化事件 | 55 个 | 100% | ✓ 全覆盖 |
|
||||
| 暂态事件 | 7 个 | 100% | ✓ 全覆盖 |
|
||||
| DB Schema 表 | 19 张 | 100% | ✓ 全覆盖 |
|
||||
| 状态机 | 6 个 | 100% | ✓ 全覆盖 |
|
||||
| 禁止路径 | 10 条 | 100% | ✓ 全覆盖 |
|
||||
| UML 类图 | 8 个子系统 | 100% | ✓ 全覆盖 |
|
||||
| 序列图 | 4 个关键流程 | 100% | ✓ 全覆盖 |
|
||||
|
||||
**结论：详细设计在覆盖性上完全通过。**
|
||||
|
||||
---
|
||||
|
||||
## 4. 发现汇总
|
||||
|
||||
### 4.1 P0 发现
|
||||
|
||||
**无 P0 发现。** 四轮审查均未发现详细设计与基线的直接矛盾或强制要求的完全缺失。
|
||||
|
||||
### 4.2 P1 发现（需要在冻结前解决）
|
||||
|
||||
| ID | 发现 | 发现者 | 验证者 | 根因 |
|
||||
|---|---|---|---|---|
|
||||
| **P1-01** | Worker exit code 语义冲突 | GPT-5.5 Pro | Opus 4.8 | baselineV1 §8 与 overview §11 定义了两套不同的 exit code 语义 |
|
||||
| **P1-02** | PromptLayerLevel 枚举与 L0-L9 层名结构性不对齐 | DeepSeek (P2) → MIMO (P1) | Opus 4.8 | contracts §16 的 10 个枚举值与 prompt-layering §2 的 10 层不完全对应 |
|
||||
| **P1-03** | EventStore.project() 错误处理未定义 | MIMO 2.5 Pro | Opus 4.8 | DD 未描述 project() 内部异常的错误语义和事务回滚行为 |
|
||||
| **P1-04** | PromptLayerLoader 接口与 prompt-layering 层定义不匹配 | Opus 4.8 | — | 接口只有 4 个方法，但需要加载 10 层 |
|
||||
|
||||
### 4.3 P2 发现（不阻塞实现，建议修复）
|
||||
|
||||
| ID | 发现 | 发现者 |
|
||||
|---|---|---|
|
||||
| P2-01 | Architecture Designer gate 无独立序列图 | DeepSeek |
|
||||
| P2-02 | CLI catalog 命令类归属未指定 | DeepSeek |
|
||||
| P2-03 | `agent.started` 投影映射措辞含糊 | MIMO 2.5 Pro |
|
||||
| P2-04 | WorkspaceManager/Scheduler 职责边界隐含但未显式标注 | MIMO 2.5 Pro |
|
||||
| P2-05 | EventStore.project 职责边界措辞问题 | GPT-5.5 Pro → Opus 4.8 (澄清) |
|
||||
| P2-06 | `memory.promoted` outbox 阶段语义不清 | GPT-5.5 Pro |
|
||||
| P2-07 | `docs` task 类型进入 contracts/DB 但事件与 worker output 未闭合 | GPT-5.5 Pro |
|
||||
| P2-08 | AgentType 不覆盖 runtime roles (main/architecture/scheduler) | GPT-5.5 Pro, Opus 4.8 |
|
||||
| P2-09 | contracts 包文件集仍有两套命名 (code-view vs overview) | GPT-5.5 Pro |
|
||||
|
||||
---
|
||||
|
||||
## 5. P1 发现详细分析
|
||||
|
||||
### 5.1 P1-01: Worker exit code 语义冲突
|
||||
|
||||
**问题**
|
||||
|
||||
`baselineV1.md` §8 定义：
|
||||
|
||||
```text
|
||||
0 protocol-level completion, including task failed/blocked
|
||||
1 uncaught exception
|
||||
2 startup/protocol error
|
||||
3 permission error
|
||||
4 parent cancelled
|
||||
5 hard timeout killed
|
||||
```
|
||||
|
||||
`system-overview-design.md` §11 和 `system-detailed-design.md` §8.1 定义：
|
||||
|
||||
```text
|
||||
0 success
|
||||
1 task failed
|
||||
2 crashed
|
||||
3 protocol error
|
||||
4 cancelled
|
||||
5 permission/policy blocked
|
||||
```
|
||||
|
||||
**关键冲突点**
|
||||
|
||||
| Exit code | baselineV1 | overview/DD | 冲突 |
|
||||
|---|---|---|---|
|
||||
| 0 | 包括 task failed/blocked | 仅 success | task failed 是 0 还是 1？ |
|
||||
| 1 | uncaught exception | task failed | 业务失败 vs 进程异常 |
|
||||
| 3 | permission error | protocol error | 互换 |
|
||||
| 5 | hard timeout killed | permission/policy blocked | 互换 |
|
||||
|
||||
**影响**
|
||||
|
||||
WorkerManager 实现时无法确定 Scheduler 的 retry/blocked/failed/lost 判定逻辑。
|
||||
|
||||
**建议处理**
|
||||
|
||||
发布 ADR 明确：
|
||||
1. baselineV1 §8 被 overview §11 取代，或
|
||||
2. 修复 overview/DD 以符合 baselineV1
|
||||
|
||||
---
|
||||
|
||||
### 5.2 P1-02: PromptLayerLevel 枚举与 L0-L9 不对齐
|
||||
|
||||
**问题**
|
||||
|
||||
| L# | prompt-layering-v1 §2 | contracts §16 枚举值 | 对齐 |
|
||||
|---|---|---|---|
|
||||
| L0 | Runtime invariant | `runtime_invariant` | ✓ |
|
||||
| L1 | Role / agent mode | `role` | ✓ |
|
||||
| L2 | Safety and permission policy | **（无对应枚举值）** | ✗ |
|
||||
| L3 | Project rules | `project_rules` | ✓ |
|
||||
| L4 | Architecture baseline | `architecture` | ✓ |
|
||||
| L5 | Task specification | `task_spec` | ✓ |
|
||||
| L6 | Relevant code/artifacts | `evidence` | ✓ |
|
||||
| L7 | Conversation context | `conversation` | ✓ |
|
||||
| L8 | Tool result history | `tool_output` | ✓ |
|
||||
| L9 | Immediate instruction | `user_override` (名字不同) | △ |
|
||||
| — | （无对应层） | `system_debug` | ✗ |
|
||||
|
||||
**影响**
|
||||
|
||||
ContextAssembler 实现时需要 10 个加载点，但 PromptLayerLoader 接口只有 4 个方法。
|
||||
|
||||
**建议处理**
|
||||
|
||||
在 DD 中明确记录设计决策：
|
||||
- L2 Safety 由 PermissionEngine 提供
|
||||
- L4-L9 由 ContextAssembler 内部组装
|
||||
- 或扩展 PromptLayerLoader 接口
|
||||
|
||||
---
|
||||
|
||||
### 5.3 P1-03: EventStore.project() 错误处理未定义
|
||||
|
||||
**问题**
|
||||
|
||||
DD §5.3 描述了 `EventStore.append()` 在事务内执行 `project(event, tx)`，但未描述：
|
||||
- `project()` 抛出异常时的行为
|
||||
- FK-off 不一致导致的失败如何传播
|
||||
- 是否有部分失败的恢复逻辑
|
||||
|
||||
**建议处理**
|
||||
|
||||
在 DD §5.3 或 §18.2 补充：
|
||||
|
||||
```text
|
||||
project() 异常 → 事务回滚 → EventBus.publish() 不执行 → 返回 AirError{kind: "system_error"}
|
||||
如果是 FK-off 不一致导致，记录到 developer log 并触发 referential_check()
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 5.4 P1-04: PromptLayerLoader 接口不完整
|
||||
|
||||
**问题**
|
||||
|
||||
`PromptLayerLoader` 接口只有 4 个方法：
|
||||
|
||||
```ts
|
||||
load_runtime_invariant(): PromptLayer // L0
|
||||
load_role(role: AgentType): PromptLayer // L1
|
||||
load_project_rules(project): PromptLayer[] // L3
|
||||
load_task_context(spec, refs): PromptLayer[] // L5
|
||||
```
|
||||
|
||||
缺失 L2, L4, L6, L7, L8, L9 的加载方法。
|
||||
|
||||
**建议处理**
|
||||
|
||||
在 DD §10.2 明确记录：
|
||||
|
||||
```text
|
||||
PromptLayerLoader 只覆盖需要外部配置/数据的层（L0, L1, L3, L5）。
|
||||
其他层由 ContextAssembler 内部组装：
|
||||
- L2 Safety: 从 PermissionEngine 获取
|
||||
- L4 Architecture: 从 TaskSpec.context_refs.arc_ref 加载
|
||||
- L6 Evidence: 从 TaskSpec.context_refs.artifacts 加载
|
||||
- L7 Conversation: 从 SessionStore.messages 加载
|
||||
- L8 Tool output: 从 SessionStore.tool_runs/command_runs 加载
|
||||
- L9 Immediate: 从 TaskSpec.description/acceptance_criteria 构建
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. 架构合理性共识
|
||||
|
||||
四轮审查在架构合理性上达成共识：
|
||||
|
||||
| 维度 | 评估 | 共识 |
|
||||
|---|---|---|
|
||||
| 依赖方向 | contracts → (none), cli → runtime/tui/llm/toolchain-cpp | ✓ 正确，无循环依赖 |
|
||||
| 职责分离 | EventIngestor/EventStore/EventBus/Scheduler/ToolRegistry/PermissionEngine | ✓ 边界清晰 |
|
||||
| 事务语义 | durable event + domain update 同事务，EventBus publish 在 commit 后 | ✓ 正确 |
|
||||
| 状态机交互 | Main Agent ↔ Scheduler ↔ Worker ↔ Architecture Designer | ✓ 无死锁 |
|
||||
|
||||
**结论：架构设计合理，无内在冲突。**
|
||||
|
||||
---
|
||||
|
||||
## 7. 门禁判定
|
||||
|
||||
| 条件 | 状态 |
|
||||
|---|---|
|
||||
| P0 = 0 | **PASS** |
|
||||
| 契约覆盖 100% | **PASS** |
|
||||
| 事件覆盖 100% | **PASS** |
|
||||
| DB Schema 覆盖 100% | **PASS** |
|
||||
| 状态机覆盖 100% | **PASS** |
|
||||
| 禁止路径全执行 | **PASS** |
|
||||
| 架构无循环依赖 | **PASS** |
|
||||
| 职责分离无泄漏 | **PASS** |
|
||||
| 基线间冲突已收束 | **FAIL** (4 处 P1 未收束) |
|
||||
|
||||
**门禁结果：CONDITIONAL PASS**
|
||||
|
||||
详细设计在覆盖性和架构合理性上通过，但存在 4 处 P1 级问题需要在冻结前解决。
|
||||
|
||||
---
|
||||
|
||||
## 8. 修复建议优先级
|
||||
|
||||
| 优先级 | Finding | 建议处理 | 预计工作量 |
|
||||
|---|---|---|---|
|
||||
| **P0** | P1-01 Worker exit code 冲突 | 发布 ADR 明确权威定义 | 0.5h |
|
||||
| **P1** | P1-02 PromptLayerLevel 不对齐 | 在 DD §10.2 记录设计决策 | 0.5h |
|
||||
| **P1** | P1-03 EventStore.project 错误处理 | 在 DD §5.3 补充错误语义 | 0.5h |
|
||||
| **P1** | P1-04 PromptLayerLoader 接口 | 在 DD §10.2 明确加载方式 | 0.5h |
|
||||
| **P2** | P2-05 EventStore.project 措辞 | 拆分 DD §5.4 为两个表 | 1h |
|
||||
| **P2** | P2-06 memory.promoted outbox | 明确 intent/completion 区分 | 0.5h |
|
||||
| **P2** | P2-07 docs task 类型 | 决定是正式 task type 还是移除 | 0.5h |
|
||||
| **P2** | P2-08 AgentType 不覆盖 runtime roles | 在 DD 中明确 runtime roles 处理 | 0.5h |
|
||||
| **P2** | P2-09 contracts 包文件集命名 | 冻结唯一文件树 | 0.5h |
|
||||
|
||||
**总预计工作量：5-6 小时**
|
||||
|
||||
---
|
||||
|
||||
## 9. 最终结论
|
||||
|
||||
### 9.1 多模型审查一致性
|
||||
|
||||
四轮审查在以下方面达成一致：
|
||||
- 覆盖性：100% 通过
|
||||
- 架构合理性：通过
|
||||
- 存在基线间冲突：需要修复
|
||||
|
||||
### 9.2 审查深度递进
|
||||
|
||||
| 轮次 | 模型 | 贡献 |
|
||||
|---|---|---|
|
||||
| 1 | DeepSeek | 建立覆盖性基线，确认无 P0 |
|
||||
| 2 | MIMO 2.5 Pro | 发现内在一致性问题，升级 PromptLayer 为 P1 |
|
||||
| 3 | GPT-5.5 Pro | 发现基线间冲突（Worker exit code） |
|
||||
| 4 | Opus 4.8 | 验证前轮发现，根因分析，提供修复建议 |
|
||||
|
||||
### 9.3 建议
|
||||
|
||||
1. **立即处理**：P1-01 Worker exit code 冲突（发布 ADR）
|
||||
2. **冻结前处理**：P1-02, P1-03, P1-04（在 DD 中补充设计决策）
|
||||
3. **实现阶段处理**：P2 级问题（不阻塞冻结）
|
||||
|
||||
### 9.4 最终判定
|
||||
|
||||
**CONDITIONAL PASS — 详细设计可以进入实现阶段，但需要先解决 4 处 P1 级问题。**
|
||||
|
||||
预计修复工作量：2-3 小时（P1 级）+ 3-4 小时（P2 级）= 5-7 小时。
|
||||
Reference in New Issue
Block a user