Detailed design: fix four P2 findings from Opus 4.8 + DeepSeek reviews

Independent full-scope audits by Opus 4.8 (R6) and DeepSeek V4 Pro (R7)
converged on the same four P2 findings. This commit closes all four:

F1 §10.2: EvidenceStore.list_for_task() → list_for_entity("task", task_id)
  The fictional method list_for_task() was not in contracts §14. Now uses
  the real contract method list_for_entity() with task as entity_type.

F5 §16.1: DoctorService.check_capability() changed from public (+) to
  private (-) with a clarifying comment. Only run() is in contracts §19.

F2 §22.7: Context and Compaction class diagram now shows the internal
  dependency edges ContextAssembler ..> EvidenceStore (L6) and
  ContextAssembler ..> SessionStore (L7/L8), matching §10.2.

F3 §22.4: Tool and Permission class diagram now shows ToolRegistry -->
  ToolDefinition (registers) and ToolRegistry --> ToolExecutor (invokes),
  matching §9.1.

Also adds the two full-scope review reports that identified these findings.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

AirPlan/docs/architecture/DeepSeek系统详细设计审查复查.md

@@ -0,0 +1,387 @@
+# DeepSeek 系统详细设计与 UML 类图全量审查复查
+
+Date: 2026-06-01
+Reviewer: DeepSeek V4 Pro（独立全量复查）
+Scope: 覆盖性 + 内在一致性 + 基线遵守 + 架构合理性 + 内在冲突 + UML 类图完整度
+Target commit: `af99aed`（Opus 4.7 R 系列回归修复后，Opus 4.8 R6 审查前）
+Inputs:
+- 详细设计：`system-detailed-design.md`（2290 行，23 章节，含 §22 8 张 Mermaid 类图）
+- 冻结基线：`interface-contracts-v1.md`、`event-registry-v1.md`、`db-schema-v1.md`、
+  `runtime-semantics-v1.md`、`scheduler-state-machine-v1.md`、`main-agent-state-machine.md`、
+  `prompt-layering-v1.md`、`scope-escalation-v1.md`、`security-model-v1.md`、`tool-registry-v1.md`、
+  `capability-trust-v1.md`、`artifact-naming-v1.md`、`error-taxonomy-v1.md`、`baselineV1.md`
+- 冻结概要设计：`system-overview-design.md`
+- 此前审查：DeepSeek(R1) / MIMO 2.5 Pro(R2) / GPT-5.5 Pro(R3) / Opus 4.8(R4) / Opus 4.7(R5 回归) / Opus 4.8(R6 复查)
+
+---
+
+## 1. 审查方法
+
+本次为 DeepSeek 的**第二轮独立全量复查**（R1 为该模型的初始覆盖性扫描，R7 为本次全量复审）。
+与 Opus 4.8 R6 采用不同策略：
+
+1. **枚举差集法**：从基线提取全部事件名/表名/契约方法签名，用 `comm -23` 与 DD 比对，逐条确认聚合写法是否合理。
+2. **全量方法名回查**：提取 DD 中所有 `ContractClass.method()` 形式的调用，逐一回查 contracts 文件验证方法真实存在（这是 R5 发现 `current_profile()` 的同类扫描，本次扩大到全部 22 个点名方法）。
+3. **FK 不变式逐条比对**：DD §18.3 的 8 条不变式与 runtime-semantics §14 逐列对照。
+4. **禁止边逐个验证**：10 条禁止边各逐条在 DD 中查找对应的执行约束（不要求逐字引用，要求有等效执行条款）。
+5. **状态机迁移完整性**：6 个状态机的迁移弧与事件投影表交叉校验。
+6. **UML 类图与正文一致性**：按类图逐张核对类成员与对应 DD 章节的一致性。
+
+---
+
+## 2. 总览结论
+
+| 维度 | 状态 | 说明 |
+|---|---|---|
+| 契约覆盖 | ✅ 100% | 23 章节全部映射，DD §21.1 矩阵复验通过 |
+| 事件覆盖 | ✅ 100% | 55 durable + 7 ephemeral，差集法确认仅余聚合条目，无遗漏 |
+| DB Schema 覆盖 | ✅ 100% | 16 主表 + 2 项目 DB，schema_meta 归 MigrationRunner |
+| 状态机覆盖 | ✅ 100% | 6/6（main / scheduler / task / agent / workspace / capability） |
+| PromptLayer L0-L9 | ✅ 100% | 11 枚举值（含 system_debug）全部映射 |
+| 禁止边执行 | ✅ 100% | 10/10 各有等效执行条款 |
+| UML 类图 | ✅ 8/8 存在 | 2 张欠边（§22.4 / §22.7，见 §7） |
+| FK 不变式 | ✅ | DD §18.3 ≡ runtime-semantics §14 逐条一致 |
+| Worker exit code | ✅ | DD §8.1 ≡ baselineV1 §8 逐字一致 |
+| R1-01~R2-02 闭合 | ✅ | 5/5 复验通过 |
+| 新增 P0 | **0** | |
+| 新增 P1 | **0** | |
+| 新增 P2 | **4** | F1/F5（契约方法越界）、F2/F3（类图欠边） |
+| 综合判定 | **CONDITIONAL PASS** | |
+
+---
+
+## 3. 覆盖性矩阵
+
+### 3.1 契约覆盖（23 个章节全映射）
+
+DD §21.1 将 contracts §2-§23 映射到 DD 章节。复验全部 23 个章节的对应 DD 内容均存在且可定位。关键抽样：
+
+| 契约 | DD 章节 | 抽样复验 |
+|---|---|---|
+| §7 EventBus/Store/Ingestor | §5 | ✓ `EventBus.drain?()` optional 签名一致 |
+| §9 TaskType / TaskSpec | §7, §8.3 | ✓ 6 个 TaskType 枚举值全对应 |
+| §10 IPC direction | §8.2 | ✓ `parent_to_worker` / `worker_to_parent` 方向约束 |
+| §12 ToolDefinition.streaming | §9.1 | ✓ `register_streaming` 存在 |
+| §13 PermissionAction 6 值 | §9.3 | ✓ 6 个 action 分支与契约逐字一致 |
+| §14 EvidenceRef 字段 | §22.1 | ✓ 5 字段匹配 |
+| §15 ProviderAdapter | §12.2 | ✓ 接口签名一致 |
+| §16 ContextAssembleInput.purpose | §10.1 | ✓ 6 个 purpose 值一致 |
+| §17 ProjectionSnapshot 8 投影 | §13.1 | ✓ 8 个字段名一致 |
+| §19 DoctorService.run() | §16.1 | ⚠ F5 |
+| §20 DebugKnowledgeStore | §11.3 | ✓ `lookup_by_signature` + `lookup_by_task` |
+
+### 3.2 事件覆盖（55 durable + 7 ephemeral）
+
+**方法**：从 event-registry §6 索引提取 55 durable + 7 ephemeral 事件名列表 → 与 DD §5.4 Table A/B 比对 → 差集中 12 个事件名验证为聚合写法。详细：
+
+| 聚合写法（DD §5.4） | 覆盖事件数 | 覆盖的事件 |
+|---|---|---|
+| `agent.completed/failed/lost/cancelled` | 4 | 4 个 agent 终端事件 |
+| `doctor.*` | 6 | run.started / issue.found / fix.started / fix.completed / fix.failed / run.completed |
+| `permission.prompt.requested/resolved` | 2 | 2 个权限提示事件 |
+| `task_attempts.failure_*` | 1 | task_attempts row append pattern |
+
+**差集残余检查**：剩余的 7 个差集事件（`agent.heartbeat`、`task.progress`、`assistant.message.delta`、`tool.progress`、`command.stdout.delta`、`command.stderr.delta`、`hud.frame.rendered`）确认为 ephemeral，不入 §5.4 投影表（正确），在 §5.5 节流列表（L459-461）和 §13.1 ProjectionStore 处理列表（L1094-1095）中全部列出。
+
+**结论**：55 + 7 = 62 事件全覆盖，无遗漏。
+
+### 3.3 DB Schema 覆盖（16 主表 + 1 schema_meta + 2 项目 DB）
+
+DD §4.3 Repository 清单列出 16 个 Repository 类，与 db-schema §3-§18 的 16 张业务表一一对应：
+
+```
+sessions      → SessionRepository
+messages      → MessageRepository
+message_drafts → MessageDraftRepository
+events        → EventRepository
+tasks         → TaskRepository
+task_dependencies → TaskDependencyRepository
+task_attempts → TaskAttemptRepository
+agents        → AgentRepository
+tool_runs     → ToolRunRepository
+command_runs  → CommandRunRepository
+artifacts     → ArtifactRepository
+diagnostics   → DiagnosticRepository
+evidence_refs → EvidenceRepository
+workspaces    → WorkspaceRepository
+summaries     → SummaryRepository
+ui_state      → UiStateRepository
+```
+
+`schema_meta` 归 `MigrationRunner`（DD §4.2 + §21.3 明确），`debug_records` / `learned_memories` 归 `DebugKnowledgeStore` / `LearnedMemoryStore`（§11.3）。**16+1+2 全覆盖。**
+
+### 3.4 状态机覆盖
+
+| 状态机 | 基线来源 | DD 覆盖 | 迁移完备性 |
+|---|---|---|---|
+| Main Agent | main-agent-state-machine.md | §14.1 + §20.1 | ✓ 8 个主要状态 + 6 个 permission_template 映射 |
+| Scheduler | scheduler-state-machine-v1.md §4 | §7 + §20.2 | ✓ 11 状态 + 3 终端 |
+| Task status | db-schema §7 | §20.3 | ✓ 7 状态 + 9 条迁移 |
+| Agent status | db-schema §10 | §20.4 | ✓ 6 状态 + 6 条迁移 |
+| Workspace status | db-schema §16 | §20.5 | ✓ 6 状态 + 6 条迁移 |
+| Capability lifecycle | capability-trust-v1 §7 | §9.5 + §20.6 | ✓ 9 状态 |
+
+### 3.5 PromptLayer L0-L9 覆盖
+
+DD §10.2 两张表覆盖 11 个枚举值 → L# 映射 → Loader。复验 contracts §16 `PromptLayerLevel` 联合类型共 11 个值，DD §10.2 表中全部列出且 L0-L9 + system_debug 层级正确。✓
+
+---
+
+## 4. 基线遵守审查
+
+### 4.1 全量方法名回查
+
+扫描 DD 中所有 `ContractClass.method()` 调用（22 个唯一方法名），逐一回查 contracts 真实性：
+
+| # | 方法引用 | contracts 存在 | 判定 |
+|---|---|---|---|
+| 1 | `ArtifactStore.create(input, context)` | §14: `create(input, context)` | ✓ |
+| 2 | `ContextAssembler.assemble(input)` | §16: `assemble(input)` | ✓ |
+| 3 | `DebugKnowledgeStore.insert(record)` | §20: `insert(record)` | ✓ |
+| 4 | `DebugKnowledgeStore.lookup_by_signature(...)` | §20: `lookup_by_signature(...)` | ✓ |
+| 5 | `EventBus.publish(event)` | §7: `publish(event)` | ✓ |
+| 6 | `EventStore.append(event, options?)` | §7: `append(event, options?)` | ✓ |
+| 7 | `EvidenceStore.list_for_task()` | §14: ❌ 仅有 `list_for_entity()` | **✗ F1** |
+| 8 | `PermissionEngine.evaluate(context)` | §13: `evaluate(context)` | ✓ |
+| 9 | `PermissionEngine.record(decision, context)` | §13: `record(decision, context)` | ✓ |
+| 10 | `ProjectionStore.apply(event)` | §17: `apply(event)` | ✓ |
+| 11 | `PromptLayerLoader.load_role(role)` | §16: `load_role(role)` | ✓ |
+| 12 | `ProviderManager.complete(input)` | §15: `complete(input)` | ✓ |
+| 13 | `Scheduler.create_tasks(session_id, specs)` | §9: `create_tasks(session_id, specs)` | ✓ |
+| 14 | `ToolRegistry.call(name, input, context)` | §12: `call(name, input, context)` | ✓ |
+| 15 | `DoctorService.check_capability(...)` | §19: ❌ 仅有 `run()` | **✗ F5** |
+
+其余 7 个方法（`ContextAssembler.load_layers`、`RetryPlanner.decide`、`WavePlanner.plan`/`assign_workspace`、`WorkerManager.spawn`、`WorkerRuntime.call_tool`、`WorkspaceManager.create_workspace`/`merge_workspace`）属于 DD-internal 类或私有方法，不要求 contracts 对应。✓
+
+**结论**：**2 处契约方法越界**（F1 / F5）。与 R5 发现的 `PermissionEngine.current_profile()` 同型——DD 引用了一个真实契约类上不存在的方法名，违反 §0 "不引入新公开契约" 的自我约束。
+
+### 4.2 Worker exit code
+
+DD §8.1 表（6 行 exit code 0-5）与 baselineV1 §8 逐字一致。解耦说明："task success/failure through WorkerResult.status, not exit codes" 与 baselineV1 语义一致。✓
+
+### 4.3 R 系列回归复验
+
+| 原 ID | 验证项 | 复验结果 |
+|---|---|---|
+| R1-01 | `PermissionEngine.current_profile()` 在 DD 和 contracts 中均为 0 处 | ✓ |
+| R1-02 | `agent.started` 投影为单状态 + §20.4 引用 | ✓ |
+| R1-03 | `memory.promoted`/`debug.record.created` 无 `phase` 字段 | ✓ |
+| R2-01 | `overview §10.5` → `overview §10.3` | ✓（唯一出现位置 L602 已修正） |
+| R2-02 | 16 mandatory files，"only if needed" 已删除 | ✓ |
+
+---
+
+## 5. 架构合理性审查
+
+### 5.1 依赖方向与无循环
+
+DD §2 复述 c4/module.md 单向依赖：`contracts ← llm/toolchain-cpp/tui/runtime ← cli`。workers 零运行时导入（仅 contracts + IPC 接口），contracts 包零运行时逻辑。无逆向边，无环。✓
+
+### 5.2 职责分离
+
+逐项审查：
+
+| 职责边界 | 描述 | 泄漏检测 |
+|---|---|---|
+| Scheduler → WorkspaceManager | 策略归 Scheduler / 机制归 WorkspaceManager | ✓ §7.5 9 行矩阵清晰，WorkspaceManager "never plans, never decides, never re-plans" |
+| EventStore → 领域服务 | EventStore 只做投影，不创建 task/permission/memory | ✓ §5.1 明确 "ingestor never creates scheduler tasks" |
+| ToolRegistry → PermissionEngine | 所有副作用必经 PermissionEngine | ✓ §9.1 call 算法第 4 步为 PermissionEngine.evaluate，无后门 |
+| CapabilityRegistry → Doctor | 依赖安装只走 Doctor | ✓ §9.5 L872-873 显式约束 |
+| ProviderAdapter → canonical format | 全部转换为 Anthropic canonical | ✓ §12.2 禁止 "silent semantic prompt loss" |
+| TUI → runtime | TUI 只读 ProjectionClient / UiCommandChannel | ✓ §13.2 L1115 "never mutates domain tables" |
+
+### 5.3 事件流时序
+
+producer → EventIngestor → (durable: EventStore tx + projection + post-commit publish | ephemeral: EventBus) 在 DD §5.1 / §5.3 / §18.2 三处描述一致。publish 总是在 commit 之后（contracts §7 rule 3）。✓
+
+### 5.4 跨 DB outbox
+
+§18.4（R1-03 修复后）采用 "owning store 先外部写 → 成功后 ingest 单个完成态事件" 模型。与 runtime-semantics §6.3（debug.record.created "intent/completion event"）和 §6.4（memory.promoted "completed promotion"）的 baseline 语义一致。`event-registry §3` payload（无 phase 字段）被完整尊重。✓
+
+### 5.5 FK-off 应用层不变式
+
+DD §18.3 的 8 条不变式与 runtime-semantics §14 逐条比对：
+
+| # | DD §18.3 | runtime-semantics §14 | 一致性 |
+|---|---|---|---|
+| 1 | `tasks.session_id → sessions.id` | `tasks.session_id → sessions.id` | ✓ |
+| 2 | `task_attempts.task_id → tasks.id` | `task_attempts.task_id → tasks.id` | ✓ |
+| 3 | `agents.task_id → tasks.id` (not null) | `agents.task_id → tasks.id` (not null) | ✓ |
+| 4 | `tool_runs.task_id/agent_id` (not null) | `tool_runs.task_id/agent_id` (not null) | ✓ |
+| 5 | `command_runs.task_id/agent_id/tool_run_id` | `command_runs.task_id/agent_id/tool_run_id` (not null) | ✓ |
+| 6 | `workspaces.task_id/agent_id` (not null) | `workspaces.task_id/agent_id` (not null) | ✓ |
+| 7 | `diagnostics.command_run_id/artifact_id` (not null) | `diagnostics.command_run_id/artifact_id` (not null) | ✓ |
+| 8 | `evidence_refs` foreign columns (not null) | `evidence_refs` foreign columns (not null) | ✓ |
+
+8/8 逐条一致。✓
+
+---
+
+## 6. 内在一致性与冲突审查
+
+### 6.1 跨章节一致性
+
+| 检查点 | 来源 A | 来源 B | 一致性 |
+|---|---|---|---|
+| AgentType 枚举 vs runtime roles | §2 "runtime-resident roles not in AgentType" | §10.2 "runtime roles don't use load_role()" | ✓ 自洽 |
+| docs TaskType 复用 ExecutorRole | §8.3 "docs reuses ExecutorRole" | §22.5 无新 Role 类 | ✓ 一致 |
+| 仅 summary.created 插入 summaries 行 | §5.4 Table A | §10.3 / runtime-semantics §7 | ✓ 一致 |
+| compaction 序列 4 事件 | §10.3 正文 | §19.3 序列图 | ✓ 一致 |
+| command status 推导 5 值 | §4.4 | contracts §17 CommandRunProjection.status | ✓ 一致 |
+| Workspace retention 天数 | §7.5 | overview §15 | ✓ 一致（merged 7d / abandoned 3d） |
+
+### 6.2 状态机与投影一致性
+
+| 检查点 | 状态机 | §5.4 投影 | 一致性 |
+|---|---|---|---|
+| agent.started → starting 或 running | §20.4 `starting ──ready──▶ running` | §5.4 Table A "starting OR running" | ✓ R1-02 修复后自洽 |
+| workspace.created → active | §20.5 `active` 状态 | §5.4 Table A `insert workspaces` | ✓ |
+| workspace.merge.completed → merged | §20.5 `merged` | §5.4 Table A `status=merged` | ✓ |
+| task.completed → completed | §20.3 `completed` | §5.4 Table A `update tasks.status` | ✓ |
+
+### 6.3 序列图与类图一致性
+
+| 序列图 | 涉及类 | 类图存在 | 一致性 |
+|---|---|---|---|
+| §19.1 User request | Scheduler/WorkspaceManager/WorkerManager/ContextAssembler | §22.3/§22.2/§22.7 | ✓ |
+| §19.2 Permission prompt | ToolRegistry/PermissionEngine/TUI | §22.4/§13.2 | ✓ |
+| §19.3 Compaction | ContextAssembler/CompactorRole/Scheduler | §22.7 | ✓ |
+| §19.4 Architecture gate | ArchitectureDesigner/ContextAssembler/ProviderManager | §22.8 | ✓ |
+| §19.5 Debug capture | DebuggerRole/DebugKnowledgeStore | §22.5/§11.3 | ✓ |
+
+无序列图引用不存在的类或方法。✓
+
+---
+
+## 7. UML 类图详细审查（§22.1-§22.8 逐张）
+
+| 图 | 类数 | 正文对应章节 | 正文一致性 | 欠边 |
+|---|---|---|---|---|
+| §22.1 契约包 | 9 | §3 | ✓ `EventSource.kind` 枚举与 §2 一致 | 无 |
+| §22.2 核心服务 | 9 | §4-§6 | ✓ EventStore→EventBus "publishes after commit" 准确 | 无 |
+| §22.3 Scheduler | 7 | §7 | ✓ Scheduler→6 个组件关系正确 | 无 |
+| §22.4 Tool/Permission | 5 | §9 | ✓ 注册/调用关系正确 | **F3**: 缺 ToolRegistry→ToolDefinition / ToolExecutor |
+| §22.5 Worker/IPC | 9 | §8 | ✓ 5 个 Role 继承齐全，docs 复用 Executor 无需新类 | 无 |
+| §22.6 Provider | 6 | §12 | ✓ 双 adapter + converter + normalizer 边正确 | 无 |
+| §22.7 Context/Compaction | 4 | §10 | ✓ ContextAssembler→PromptLayerLoader→PromptLayer 正确 | **F2**: 缺 ContextAssembler→EvidenceStore / SessionStore |
+| §22.8 Agents | 2 | §14 | ✓ →Scheduler/ContextAssembler/ProviderManager/EventIngestor 正确 | 无 |
+
+**F2 详细说明**：§10.2 表 2 明确 ContextAssembler 内部装配 L6（Evidence）需读 EvidenceStore，L7（Conversation）需读 SessionStore。但 §22.7 类图仅显示 ContextAssembler→PromptLayerLoader 和 ContextAssembler→CompactionPolicy 两条边。建议补虚线依赖：
+```mermaid
+ContextAssembler --> EvidenceStore : L6
+ContextAssembler --> SessionStore : L7/L8
+```
+
+**F3 详细说明**：§9.1 ToolRegistry.call() 算法第 1 步为 "look up definition+executor"，且 `register`/`register_streaming` 接收 `ToolDefinition` 和 `ToolExecutor` 参数。但 §22.4 类图缺少这两条关系边。建议补：
+```mermaid
+ToolRegistry --> ToolDefinition : registers
+ToolRegistry --> ToolExecutor : invokes
+```
+
+---
+
+## 8. 新发现（P0 / P1 / P2 分类）
+
+### F1 [P2] `EvidenceStore.list_for_task()` 不在契约
+
+- **位置**：DD §10.2 表 2 L6 Evidence 行（L932）
+- **原文**：`` `EvidenceStore.list_for_task()` ``
+- **问题**：contracts §14 `EvidenceStore` 仅声明 `create()` 与 `list_for_entity(entity_type, entity_id)`，无 `list_for_task()` 方法。
+- **根因**：为给 L6 的 evidence loading 指定来源，便捷地发明了一个 `list_for_task` 的命名，但契约只有泛化的 `list_for_entity`。
+- **影响**：实现 ContextAssembler 时无法调用 `EvidenceStore.list_for_task()`，需改为 `list_for_entity("task", task_id)`。
+- **建议**：`s/EvidenceStore.list_for_task()/EvidenceStore.list_for_entity("task", task_id)/`
+- **工作量**：< 2 分钟
+
+### F5 [P2] `DoctorService.check_capability()` 不在契约
+
+- **位置**：DD §16.1（L1201）
+- **原文**：`` +check_capability(capability): Promise<DoctorIssue[]> ``
+- **问题**：标记为 public（`+`），但 contracts §19 `DoctorService` 仅声明 `run(input): Promise<DoctorRunOutput>`。`check_capability` 不在契约中。
+- **根因**：把 DoctorService 的内部分解步骤暴露为公共方法签名。同类的 `self_bootstrap` 已正确标记为 private（`-`），但 `check_capability` 未按同样规范处理。
+- **影响**：类型系统会期望一个 contracts 中不存在的方法。
+- **建议**：改为私有 `-check_capability(capability): Promise<DoctorIssue[]>`，或作为 `run()` 内部步骤描述。
+- **工作量**：< 1 分钟
+
+### F2 [P2] §22.7 类图缺少 ContextAssembler → EvidenceStore / SessionStore 依赖边
+
+- 见 §7 F2 详细说明。
+- **建议**：补两条 `..>` 虚线依赖，标注 `L6` / `L7/L8`。
+- **工作量**：< 3 分钟
+
+### F3 [P2] §22.4 类图缺少 ToolRegistry → ToolDefinition / ToolExecutor 关系边
+
+- 见 §7 F3 详细说明。
+- **建议**：补两条 `-->` 关联，标注 `registers` / `invokes`。
+- **工作量**：< 3 分钟
+
+**无 P0、无 P1。**
+
+---
+
+## 9. 门禁判定
+
+| 条件 | 状态 |
+|---|---|
+| P0 = 0 | **PASS** |
+| 契约覆盖 100%（23 章节） | **PASS** |
+| 事件覆盖 100%（55 durable + 7 ephemeral） | **PASS** |
+| DB Schema 覆盖 100%（16+1+2） | **PASS** |
+| 状态机覆盖 100%（6/6） | **PASS** |
+| L0-L9 覆盖 100% | **PASS** |
+| 禁止边 10/10 有执行约束 | **PASS** |
+| 架构无循环依赖 | **PASS** |
+| 职责分离无泄漏 | **PASS** |
+| FK 不变式 8/8 一致 | **PASS** |
+| R 系列(R1-01~R2-02) 闭合 | **PASS** |
+| 契约方法越界 | **FAIL**（F1 / F5 两处） |
+| UML 类图完整度 | **CONDITIONAL**（F2 / F3 欠边） |
+
+**门禁结果：CONDITIONAL PASS** — 4 项 P2 不阻断实现，合计修复量 < 9 分钟。
+
+---
+
+## 10. 多轮累积视角
+
+| 轮次 | 模型 | 主要贡献 | P0 | P1 | P2 |
+|---|---|---|---|---|---|
+| R1 | DeepSeek | 全量覆盖性扫描 | 0 | 0 | 3 |
+| R2 | MIMO 2.5 Pro | 内在一致性审查 | 0 | 2 | 5 |
+| R3 | GPT-5.5 Pro | 基线冲突检测 | 0 | 2 | 4 |
+| R4 | Opus 4.8 | 验证 + 根因分析 | 0 | 2 | 5 |
+| R5 | Opus 4.7 | 修复回归引入检测 | 0 | 3 | 2 |
+| — | — | R 系列闭合（commit af99aed） | — | — | — |
+| R6 | Opus 4.8 | 全量复查 + 方法名回查 | 0 | 0 | 4 |
+| **R7** | **DeepSeek V4 Pro（本次）** | **全量复查 + 独立验证（差集法 + 全量方法名回查 + FK 逐条比对）** | **0** | **0** | **4** |
+
+**确认声明**：R7（DeepSeek）独立验证了 R6（Opus 4.8）的 4 项 P2 发现，全部确认为真实问题，无新增发现。两轮独立审查结论一致：
+- 覆盖性 / 架构性 / 一致性全部 PASS
+- 4 项 P2 为同一层次问题：F1/F5 为契约方法越界（与 R5 的 `current_profile()` 同型），F2/F3 为类图欠边
+- 修复量合计 < 9 分钟
+
+---
+
+## 11. 最终结论与建议
+
+### 11.1 设计成熟度
+
+详细设计在**覆盖性、架构合理性、状态机一致性、事件流时序、跨 DB outbox、FK-off 不变式**六大维度均达标。从 23 份基线到 2290 行 DD 的映射完整、无环、无泄漏。R 系列修复已在 `af99aed` 闭合，本次全量复验未发现回退。
+
+### 11.2 剩余问题
+
+仅剩 4 项 P2（F1/F5/F2/F3），均为分钟级文字/图形精修。无 P0，无 P1。
+
+### 11.3 建议
+
+4 项 P2 建议在冻结前合并修复（< 9 分钟），可在单次 commit 中完成：
+- L932：`EvidenceStore.list_for_task()` → `EvidenceStore.list_for_entity("task", task_id)`
+- L1201：`+check_capability` → `-check_capability`
+- §22.7 mermaid：加 `ContextAssembler ..> EvidenceStore` / `ContextAssembler ..> SessionStore`
+- §22.4 mermaid：加 `ToolRegistry --> ToolDefinition` / `ToolRegistry --> ToolExecutor`
+
+### 11.4 最终判定
+
+**CONDITIONAL PASS (R7)** — DeepSeek 独立全量复查确认：详细设计满足全量覆盖与结构正确性，4 项 P2 为局部精修，不阻断实现。建议合并 R6/R7 两轮独立审查的共识发现，一并修复后正式冻结。
+
+---
+
+End of DeepSeek independent full-scope re-audit.

AirPlan/docs/architecture/opus4.8系统详细设计审查复查.md

@@ -0,0 +1,303 @@
+# Opus 4.8 系统详细设计与 UML 类图全量审查复查
+
+Date: 2026-06-01
+Reviewer: Claude Opus 4.8 (independent full-scope re-audit)
+Scope: 全量复查 — 覆盖性 + 内在一致性 + 基线遵守 + 架构合理性 + 内在冲突
+Target commit: `af99aed`（R 系列回归修复后）
+Inputs:
+- 详细设计：`system-detailed-design.md`（2290 行，23 章节，含 §22 8 张 Mermaid 类图）
+- 冻结基线：`interface-contracts-v1.md`、`event-registry-v1.md`、`db-schema-v1.md`、
+  `runtime-semantics-v1.md`、`scheduler-state-machine-v1.md`、`main-agent-state-machine.md`、
+  `prompt-layering-v1.md`、`scope-escalation-v1.md`、`security-model-v1.md`、`tool-registry-v1.md`、
+  `capability-trust-v1.md`、`artifact-naming-v1.md`、`error-taxonomy-v1.md`、`baselineV1.md`
+- 冻结概要设计：`system-overview-design.md`
+- 此前审查：DeepSeek / MIMO 2.5 Pro / GPT-5.5 Pro / Opus 4.8(R4) / Opus 4.7(R5 回归)
+
+---
+
+## 1. 审查方法
+
+本次为**独立全量复查**，不预设此前 5 轮审查已经完备。从零重建以下证据链：
+
+1. **逐行通读 DD 全文**（§0-§23，2290 行）
+2. **枚举式覆盖核对**：用脚本从基线提取契约接口名 / 事件名 / DB 表名 / 状态机，再与 DD 逐一比对（`comm -23` / `comm -13` 差集法）
+3. **基线遵守抽样核验**：对 DD 中所有 `Class.method()` 形式的引用，回查契约是否真实存在该方法（这正是 R5 发现 `current_profile()` 越界的同类问题，本次扩大到全部点名方法）
+4. **架构合理性**：依赖方向、职责分离、事件流时序、跨 DB outbox、FK-off 不变式
+5. **UML 逐张审查**：8 张类图的语法、类数、边与正文一致性
+6. **内在冲突**：同一概念跨章节是否自洽
+
+---
+
+## 2. 总览结论
+
+| 维度 | 状态 |
+|---|---|
+| 契约覆盖 | ✅ 100%（23 个契约章节全部映射） |
+| 事件覆盖 | ✅ 100%（55 durable + 7 ephemeral，含聚合写法） |
+| DB Schema 覆盖 | ✅ 100%（16 张主表 + 2 项目级 DB，schema_meta 归 MigrationRunner） |
+| 状态机覆盖 | ✅ 100%（main / scheduler / task / agent / workspace / capability 共 6 个） |
+| PromptLayer L0-L9 覆盖 | ✅ 100% |
+| 10 条禁止边 | ✅ 100% 显式继承 |
+| UML 类图 | ✅ 8/8 存在且语法可解析 |
+| R 系列(R1-01~R2-02) 回归修复 | ✅ 5/5 已闭合（本次复验） |
+| 架构合理性 | ✅ 无循环依赖，职责分离清晰 |
+| **新增 P0** | **0** |
+| **新增 P1** | **0** |
+| **新增 P2** | **4**（F1/F5 契约方法越界，F2/F3 类图欠完整） |
+| 综合判定 | **CONDITIONAL PASS** — 4 项 P2 不阻断实现，建议合并修复 |
+
+---
+
+## 3. 覆盖性矩阵
+
+### 3.1 契约覆盖（interface-contracts-v1 → DD）
+
+`interface-contracts-v1.md` 共 23 个章节（§2-§23），DD §21.1 逐一映射，复验全部命中：
+
+| 契约章节 | DD 章节 | 复验 |
+|---|---|---|
+| §2-§4 原语 / 错误 / 实体引用 | §3、§18.1 | ✓ |
+| §6 事务存储 | §4、§18.2 | ✓ |
+| §7 Event Bus/Store/Ingestor | §5 | ✓ 三接口签名逐字一致 |
+| §8 项目/会话 | §6 | ✓ |
+| §9 Task/Scheduler | §7 | ✓ |
+| §10-§11 Worker/IPC/Result | §8 | ✓ exit code 与 baselineV1 §8 逐行一致 |
+| §12-§13 Tool/Permission | §9 | ✓ |
+| §14 Artifact/Evidence | §11 | ⚠ 见 F1 |
+| §15 Provider | §12 | ✓ |
+| §16 Context | §10 | ✓ PromptLayerLoader 4 方法签名逐字一致 |
+| §17 Projection/UI | §13 | ✓ ProjectionSnapshot 8 个投影字段全覆盖 |
+| §18 Capability | §9.5 | ✓ |
+| §19 Doctor | §16 | ⚠ 见 F5 |
+| §20 Debug/Memory | §11.3 | ✓ lookup_by_signature/by_task 存在 |
+| §21 Diagnostic | §15 | ✓ |
+| §22-§23 版本/边界规则 | §3、§18.5 | ✓ 10 条禁止边全继承 |
+
+### 3.2 事件覆盖（event-registry-v1 → DD）
+
+差集法核对（registry §6 索引 55 durable + 7 ephemeral）：
+
+- DD §5.4 Table A/B 显式列出 46 个事件名；
+- 差集中 12 个"未直接出现"的事件（`agent.completed/failed/lost/cancelled`、6 个 `doctor.*`、`permission.prompt.requested/resolved`）经核查均由 DD 的**聚合写法**覆盖：
+  - `| agent.completed/failed/lost/cancelled | update agents.status |`（§5.4 L384）
+  - `| doctor.* | append (+ optional ...) |`（§5.4 L409）
+  - `| permission.prompt.requested/resolved | append |`（§5.4 L408）
+- 7 个 ephemeral 全部在 §5.5 与 §13.1 列出（含 `command.stdout.delta`/`command.stderr.delta`）。
+
+**结论**：55 + 7 全覆盖，无遗漏。差集中出现的 `agents.status`/`sessions.status`/`events_session.db` 为投影目标列/库名，非事件名，属正常。
+
+### 3.3 DB Schema 覆盖（db-schema-v1 → DD repositories）
+
+db-schema §2-§18 共 17 表。DD §4.3 仓库清单覆盖 §3-§18 的 16 张业务表（一一对应），`schema_meta`（§2）由 `MigrationRunner` 持有（DD §4.2、§21.3 明确）。两张项目级 DB（`debug-records.db`/`learned-memory.db`，§20）由 `DebugKnowledgeStore`/`LearnedMemoryStore` 持有（§11.3）。
+
+**结论**：17/17 表 + 2 项目级 DB 全覆盖。
+
+### 3.4 状态机覆盖
+
+| 状态机 | 基线 | DD |
+|---|---|---|
+| Main Agent | main-agent-state-machine.md | §14.1、§20.1 ✓ |
+| Scheduler | scheduler-state-machine-v1.md §4 | §7、§20.2 ✓（11 状态全列） |
+| Task status | db-schema §7 | §20.3 ✓ |
+| Agent status | db-schema §10 | §20.4 ✓ |
+| Workspace status | db-schema §16 | §20.5 ✓ |
+| Capability lifecycle | capability-trust §7 | §9.5、§20.6 ✓ |
+
+6/6 状态机全覆盖。
+
+### 3.5 需求覆盖（requirements → DD workflows）
+
+- C++ 全流程（configure/build/test/static-analysis/debug/fix/review）：DD §15 + §19.5 ✓
+- GUI/网络取证工具：通过 capability + tool 注册（§9.5、§15）✓
+- 静态分析（`docs/staticanalysis.md`）：`CppcheckRunner` + `DiagnosticParser`（§15）✓
+- TUI/HUD 投影：§13 ✓
+- Linux tier-1 release gate：§16（Doctor/release）+ overview §15 ✓
+
+### 3.6 PromptLayer L0-L9 覆盖
+
+DD §10.2 表 1 将 11 个 `PromptLayerLevel` 枚举值（含 `system_debug`）映射到 L0-L9，与 contracts §16 枚举、prompt-layering-v1 §2 完全对应。表 2 区分 PromptLayerLoader（L0/L1/L3/L5）与 ContextAssembler 内部装配（L2/L4/L6/L7/L8/L9）。✓
+
+### 3.7 UML 类图覆盖（§22.1-§22.8）
+
+| 图 | 类数 | 状态 |
+|---|---|---|
+| §22.1 契约包 | 9 | ✓ |
+| §22.2 运行时核心服务 | 9 | ✓ |
+| §22.3 Scheduler | 7 | ✓ |
+| §22.4 Tool/Permission | 5 | ⚠ F3 |
+| §22.5 Worker/IPC | 9 | ✓ 5 个 Role 继承齐全 |
+| §22.6 Provider | 6 | ✓ |
+| §22.7 Context/Compaction | 4 | ⚠ F2 |
+| §22.8 Agents | 2 | ✓ |
+
+8/8 存在且语法可解析。两处欠完整见 §7。
+
+---
+
+## 4. 基线遵守审查
+
+抽取 DD 中所有 `ClassName.method()` 形式引用，回查契约真实性：
+
+| DD 引用 | 契约真实性 | 判定 |
+|---|---|---|
+| `PromptLayerLoader.load_role()` | contracts §16 存在 | ✓ |
+| `EvidenceStore.list_for_task()` | contracts §14 **只有** `list_for_entity()` | ✗ **F1** |
+| `EventBus.publish()` | contracts §7 存在 | ✓ |
+| `ContextAssembler.load_layers()` | DD 内部私有方法（`-`），非契约 | ✓ |
+| `SessionStore.referential_check()` | SessionStore 是 DD 内部聚合，非契约接口 | ✓ |
+| `ProjectLocator.locate()` / `ProjectInitializer.scaffold()` | DD 标记 `IMPL` 辅助类 | ✓ |
+| `DoctorService.check_capability()` | contracts §19 **只有** `run()` | ✗ **F5** |
+| `current_profile()`（R5 旧问题） | DD 中已 0 处、契约 0 处 | ✓ R1-01 已闭合 |
+
+R 系列复验：`overview §10.3`（R2-01）、`agent.started 单状态 + §20.4`（R1-02）、`无 phase 字段`（R1-03）、`16 mandatory files`（R2-02）均已正确落地。
+
+---
+
+## 5. 架构合理性审查
+
+### 5.1 依赖方向与无循环
+
+DD §2 复述 c4/module.md 的允许导入图：`contracts ← llm/toolchain-cpp/tui/runtime ← cli`，`workers` 仅依赖 contracts + WorkerRuntime IPC。无逆向边、无环。✓
+
+### 5.2 职责分离
+
+- **Scheduler vs WorkspaceManager**（§7.5）：策略归 Scheduler、机制归 WorkspaceManager，9 行职责矩阵清晰，无泄漏。✓
+- **EventStore vs 领域服务**（§5.1、§5.3）：EventStore 只做事务投影，不创建 task/permission/memory；follow-up 由 owning service 发出。✓
+- **ToolRegistry / PermissionEngine / CapabilityRegistry**（§9）：所有副作用经 PermissionEngine；capability 永不绕过。✓
+
+### 5.3 事件流一致性
+
+producer → EventIngestor → (durable: EventStore tx + projection + post-commit publish | ephemeral: EventBus) 在 §5.1、§5.3、§18.2 三处描述一致；"publish AFTER commit"（contracts §7 rule 3）一致。✓
+
+### 5.4 跨 DB outbox 一致性
+
+§18.4 经 R1-03 修复后，采用"owning store 先外部写 → 成功后 ingest 单个完成态事件"模型；与 runtime-semantics §6.3-§6.4、event-registry §3 payload（无 phase 字段）一致；§5.4 Table B 与之呼应。✓ 无残留矛盾。
+
+### 5.5 FK-off 应用层不变式
+
+§18.3 列出 8 条不变式，与 runtime-semantics §14 逐条对应；`SessionStore.referential_check()` 在启动/周期运行。✓
+
+---
+
+## 6. 内在一致性与冲突审查
+
+| 检查点 | 结果 |
+|---|---|
+| §5.3 EventStore 正文 vs §22.2 类图 | ✓ 一致（append/append_many/query + publish-after-commit 边） |
+| §20.4 Agent 状态机 vs §5.4 `agent.started` 投影 | ✓ R1-02 修复后自洽（单状态 + §20.4 过渡） |
+| §10.3 Compaction 时序 vs §19.3 序列图 | ✓ 一致（仅 summary.created 插行） |
+| §4.4 derive_command_status vs contracts §17 CommandRunProjection.status | ✓ 五值一致 |
+| §17 CLI 命令清单 vs overview §14 catalog | ✓ DD 含 6 个 catalog 命令 + 5 个基础命令(run/init/doctor/e2e/release)，后者在 overview §4/§15 有据，属合理超集 |
+| §8.1 exit code vs baselineV1 §8 | ✓ 6 个 code 逐行一致 |
+
+未发现跨章节概念冲突或时序矛盾。
+
+---
+
+## 7. UML 类图详细审查（§22.1-§22.8 逐张）
+
+- **§22.1 契约包**：`EventSource.kind` 枚举与 §2 runtime-role 表协同；`RuntimeEvent → EventSource`、`WorkerResult → Artifact/Evidence`、`AirError → EntityRef` 边正确。✓
+- **§22.2 核心服务**：`EventStore → EventBus : publishes after commit`、`ProjectionStore → EventBus : subscribes` 准确反映事件流。✓
+- **§22.3 Scheduler**：6 个被组合类（TaskGraph/WavePlanner/RetryPlanner/WorkspaceManager/AgentMonitor/WorkerManager）齐全。建议旁注 "Scheduler owns policy; WorkspaceManager owns mechanism"（与 §7.5 呼应），非必须。
+- **§22.4 Tool/Permission** — **F3**：图中 `ToolRegistry` 缺少到 `ToolDefinition` / `ToolExecutor` 的关系边；正文 §9.1 明确 ToolRegistry 注册/调用这两者。建议补 `ToolRegistry --> ToolDefinition : registers` 与 `ToolRegistry --> ToolExecutor : invokes`。
+- **§22.5 Worker/IPC**：5 个 Role 实现 `WorkerRole` 继承齐全；`docs` TaskType 复用 ExecutorRole 无需新增节点，与 §8.3 一致。✓
+- **§22.6 Provider**：双 adapter 继承 + converter + normalizer 边正确。✓
+- **§22.7 Context/Compaction** — **F2**：图中 `ContextAssembler` 仅连 `PromptLayerLoader`/`CompactionPolicy`，但 §10.2 表 2 明确 ContextAssembler 内部装配 L2/L6/L7/L8 需读 `EvidenceStore`、`SessionStore.messages/tool_runs/command_runs`。类图低估了实际耦合。建议补 `ContextAssembler --> EvidenceStore`、`ContextAssembler --> SessionStore`（依赖型虚线即可）。
+- **§22.8 Agents**：`MainAgent`/`ArchitectureDesigner` → Scheduler/ContextAssembler/ProviderManager/EventIngestor 边正确；与 §2 "runtime role 不走 load_role" 决策一致。✓
+
+---
+
+## 8. 新发现（P0 / P1 / P2 分类）
+
+### F1 [P2] `EvidenceStore.list_for_task()` 不在契约
+
+- **位置**：DD §10.2 表 2，L6 Evidence 行（L932）
+- **问题**：引用 `EvidenceStore.list_for_task()`，但 contracts §14 `EvidenceStore` 仅声明 `create()` 与 `list_for_entity(entity_type, entity_id)`。
+- **根因**：与 R5 的 `current_profile()` 同类——为给 L6 找一个明确来源，点名了不存在的方法。
+- **影响**：实现 ContextAssembler 时找不到 `list_for_task()`；轻微，因为 `list_for_entity("task", task_id)` 即可替代。
+- **建议**：改为 `EvidenceStore.list_for_entity("task", task_id)`（契约真实方法）。
+- **工作量**：2 分钟
+
+### F5 [P2] `DoctorService.check_capability()` 不在契约
+
+- **位置**：DD §16.1（L1201）
+- **问题**：`DoctorService` 类列出 `+check_capability(capability): Promise<DoctorIssue[]>`（public `+`），但 contracts §19 `DoctorService` 仅声明 `run(input): Promise<DoctorRunOutput>`。
+- **根因**：把内部分解步骤当成公共契约方法暴露。
+- **影响**：与 §0 "不引入新公共契约" 约束冲突；轻微。
+- **建议**：改为私有 `-check_capability(...)`（与同段 `-self_bootstrap()` 一致风格），或并入 `run()` 内部说明。
+- **工作量**：1 分钟
+
+### F2 [P2] §22.7 类图缺 ContextAssembler 内部装配依赖边
+
+- 见 §7。建议补 `ContextAssembler --> EvidenceStore` / `--> SessionStore` 虚线依赖。
+- **工作量**：3 分钟
+
+### F3 [P2] §22.4 类图缺 ToolRegistry → ToolDefinition/ToolExecutor 边
+
+- 见 §7。建议补两条注册/调用关系边。
+- **工作量**：3 分钟
+
+无 P0、无 P1。F1/F5 是契约边界的两处"点名了不存在的方法"，与本轮独立抽样法直接相关；F2/F3 是类图完整度问题，不影响正文设计正确性。
+
+---
+
+## 9. 门禁判定
+
+| 条件 | 状态 |
+|---|---|
+| P0 = 0 | **PASS** |
+| 契约覆盖 100% | **PASS** |
+| 事件覆盖 100% | **PASS** |
+| DB Schema 覆盖 100% | **PASS** |
+| 状态机覆盖 100% | **PASS** |
+| L0-L9 覆盖 | **PASS** |
+| 禁止路径全继承 | **PASS** |
+| 架构无循环依赖 | **PASS** |
+| 职责分离无泄漏 | **PASS** |
+| R 系列(R1/R2)修复已闭合 | **PASS** |
+| 契约/payload 不变性（无越界方法/字段） | **FAIL**（F1 + F5 两处契约方法越界） |
+| UML 类图完整度 | **CONDITIONAL**（F2 + F3 欠边，不影响正确性） |
+
+**门禁结果：CONDITIONAL PASS** — 覆盖性、架构、状态机全部 PASS；4 项 P2 不阻断实现，但建议在冻结前一并修复以保持契约纯净。
+
+---
+
+## 10. 多轮累积视角
+
+| 轮次 | 模型 | 主要贡献 | P0 | P1 | P2 |
+|---|---|---|---|---|---|
+| R1 | DeepSeek | 全量覆盖性 | 0 | 0 | 3 |
+| R2 | MIMO 2.5 Pro | 内在一致性 | 0 | 2 | 5 |
+| R3 | GPT-5.5 Pro | 基线冲突检测 | 0 | 2 | 4 |
+| R4 | Opus 4.8 | 验证 + 根因 | 0 | 2 | 5 |
+| R5 | Opus 4.7 | 修复回归引入检测 | 0 | 3 | 2 |
+| R5-fix | — | R1-01~R2-02 闭合（commit af99aed） | — | — | — |
+| **R6** | **Opus 4.8（本次全量复查）** | **契约方法越界抽样 + 类图完整度** | **0** | **0** | **4** |
+
+**累积说明**：R1-R5 的 P1×4 + P2×9 + R 系列 5 项均已闭合。R6 在更系统的"点名方法 vs 契约"抽样下浮出 F1/F5（与 R5 的 `current_profile()` 同型，说明此类问题需要一次性全表扫描），以及两处类图欠边 F2/F3。无新增 P0/P1。
+
+---
+
+## 11. 最终结论与建议
+
+### 11.1 设计成熟度
+
+详细设计在**覆盖性、架构合理性、状态机一致性、基线遵守（主体）**四个维度均达标。事件 / 表 / 契约 / 状态机 / 禁止边 / L0-L9 / UML 七类对象 100% 覆盖，依赖无环，职责分离干净，跨 DB outbox 与 FK-off 不变式自洽。
+
+### 11.2 剩余问题
+
+仅剩 4 项 P2，全部为局部精修：
+- **F1 / F5**：两处"点名了不存在的契约方法"（`EvidenceStore.list_for_task`、`DoctorService.check_capability`），合计 3 分钟可改为真实方法 / 改私有。
+- **F2 / F3**：两张类图欠依赖边，合计 6 分钟补全。
+
+### 11.3 建议
+
+**总工作量约 9 分钟**即可收束全部 4 项 P2。这些不阻断进入实现阶段，但建议在正式冻结前一并修复，使契约纯净度与类图完整度达到 100%，避免实现者在 ContextAssembler / DoctorService 处遇到与 R5 同型的"找不到方法"困惑。
+
+### 11.4 最终判定
+
+**CONDITIONAL PASS (R6)** — 详细设计满足全量覆盖与结构正确性，R 系列回归修复全部闭合；本轮新增 4 项 P2（2 契约方法越界 + 2 类图欠边），均为分钟级修复，不阻断实现。
+
+---
+
+End of full-scope re-audit.

AirPlan/docs/architecture/system-detailed-design.md

@@ -929,7 +929,7 @@ configuration or resource loading (L0, L1, L3, L5). The remaining layers are ass
 |---|---|---|
 | L2 Safety | Active permission profile (`~/.air/permissions.yaml` + project permission config; same source the `PermissionEngine` implementation reads internally — no new contract method) | `ContextAssembler` |
 | L4 Architecture | `TaskSpec.context_refs.arc_ref` → load from plan/ADR/C4 docs | `ContextAssembler` |
-| L6 Evidence | `TaskSpec.context_refs.artifacts` + `EvidenceStore.list_for_task()` | `ContextAssembler` |
+| L6 Evidence | `TaskSpec.context_refs.artifacts` + `EvidenceStore.list_for_entity("task", task_id)` | `ContextAssembler` |
 | L7 Conversation | `SessionStore.messages.list_by_session()` (recent N messages) | `ContextAssembler` |
 | L8 Tool output | `SessionStore.tool_runs` + `command_runs` for current task | `ContextAssembler` |
 | L9 Immediate | `TaskSpec.description` + `acceptance_criteria` + immediate user instruction | `ContextAssembler` |
@@ -1198,7 +1198,7 @@ Implements contracts §19.
 ```text
 class DoctorService implements DoctorService
   +run(input: DoctorRunInput): Promise<DoctorRunOutput>
-  +check_capability(capability): Promise<DoctorIssue[]>
+  -check_capability(capability): DoctorIssue[]    // internal helper, not a public contract method
   -self_bootstrap(): DoctorIssue[]    // Bun, SQLite, shell, .air writability
 ```
 
@@ -2124,6 +2124,8 @@ classDiagram
         +register_tools(tool_registry): Promise~void~
     }
     ToolRegistry --> PermissionEngine
+    ToolRegistry --> ToolDefinition : registers
+    ToolRegistry --> ToolExecutor : invokes
     PermissionEngine --> PathClassifier
     PermissionEngine --> CommandRiskAnalyzer
     CapabilityRegistry --> ToolRegistry : registers tools
@@ -2245,6 +2247,8 @@ classDiagram
     }
     ContextAssembler --> PromptLayerLoader
     ContextAssembler --> CompactionPolicy
+    ContextAssembler ..> EvidenceStore : L6 evidence
+    ContextAssembler ..> SessionStore : L7/L8
     PromptLayerLoader --> PromptLayer
 ```