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

Opus 4.7 概要设计全量交叉审查

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

---

1. 审查范围与方法

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

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

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

额外参考：

• gpt5概要设计审查.md（GPT-5 审查，同日）
• mimo2.5概要设计审查.md（MIMO v2.5 审查，同日）

方法：

• 逐基线 item-by-item 语义比对，非标题/关键词匹配
• 对 GPT-5 和 MIMO 2.5 审查逐项交叉验证，标注确认、误判或遗漏
• 从三个独立视角审查：架构一致性、工程可实现性、需求/基线对齐
• 冻结基线不修改，概要设计标注差异并解决
• P0 = 影响实现方向或基线矛盾，P1 = 影响完整性但有基线可查，P2 = 可在详细设计补充

---

2. 总体评估

2.1 概要设计优势

1. 容器/组件视图完整：§4-§6 覆盖了全部 6 个 package 的职责、依赖和产出，与 c4/module.md 一致。
2. 事件/投影流清晰：§9 的 durable/ephemeral 分类和 ProjectionStore 规则与 event-registry-v1.md 一致。
3. 执行流覆盖面广：§10.1-§10.6 涵盖 startup、normal request、direct mode、tool call、review gate、C++ workflow 六条路径。
4. Architecture Designer gate 设计完善：§10.5 的 10 条触发规则和 gate 组合规则与 scope-escalation-v1.md 一致。
5. 权限层级正确：§12 的 6 层评估顺序与 security-model-v1.md 和 runtime-semantics-v1.md §8 一致。
6. 上下文/压缩/经验挖掘：§13 覆盖了 PromptLayer 顺序、Compaction 语义和 ExperienceMiner 触发，与 prompt-layering-v1.md 和 runtime-semantics-v1.md §7/§11/§17 一致。
7. Doctor/Restore/Recovery：§15 覆盖了 Doctor 自检引导、三粒度 restore、DB/workspace 恢复。
8. 实现阶段映射：§16 的 Phase 0-8 和关键串行约束与 todo.md T-001~T-037 对应。

2.2 系统性缺口

缺口类别	涉及基线	影响
源文档清单不完整（11/24）	全部	下游设计无法溯源
全局 ~/.air/ 布局缺失	baselineV1 §5	project_id UUID 和全局配置无定义
Claude Code 执行原语未系统化	requirements FR-009, baselineV1 §2	下游工具实现无质量基准
权限边界细则缺失	security-model-v1 §4-§5	realpath/.git//build/sudo/project-outside-backup 规则缺失
TaskSpec/WorkerResult 字段语义缺失	baselineV1 §9, interface-contracts §9-§11	failed vs blocked 语义、summary 用途无定义
IPC 退出码和 envelope 字段缺失	baselineV1 §8, interface-contracts §10	工程实现无依据
错误分类学完全缺失	error-taxonomy-v1 全文	ErrorKind/severity/retryability/semantic signature 无定义
日志/迁移/扫描器/分发章节缺失	baselineV1 §21-§25, requirements FR-019	4 个子系统无概要设计入口
参考项目影响和技术栈约束缺失	baselineV1 §2-§3	执行纪律和复用边界不清
调度器状态机语义缺失	scheduler-state-machine-v1 全文	11 个状态和转换条件无概要

2.3 综合评分

维度	得分 (1-10)	说明
架构一致性	7.5	容器/组件/事件/权限/上下文大方向一致，但错误分类学、调度器状态机、执行原语系统化缺失
需求覆盖	6.0	FR-001~FR-018 覆盖良好，FR-009 执行原语、FR-019 日志、FR-020 测试分层、约束条件 §5 缺失
工程可实现性	5.5	缺少 IPC 退出码、TaskSpec 字段族、错误分类学、权限细则等实现必需信息
基线溯源	4.5	源文档仅列 11/24，无法回溯 13 份冻结基线
总分	5.9/10	骨架良好但实现可操作性不足

---

3. GPT-5 审查交叉验证

对 GPT-5 审查报告的 26 项缺口逐一交叉验证：

GPT-5 编号	GPT-5 缺口摘要	Opus 4.7 判定	理由
3.1	产品定位 "not wrapper" 和完整循环缺失	确认 P0	baselineV1 §1 明确定义，概要设计 §2 虽说"self-owned"但未明确"不是 wrapper"，循环缺失
3.2	参考项目边界缺失	确认 P1	baselineV1 §2 定义了 5 个参考项目和复用边界，概要设计完全未提及
3.3	技术基线缺失	确认 P1	Bun/Turborepo/OpenTUI 包名/Python/tarball 均未出现
3.4	~/.air/ 全局布局缺失	确认 P0	baselineV1 §5 定义了 config.yaml/models.yaml/project-index.db/cache/skills/logs 等，概要设计仅有项目级
3.5	project_id UUID 缺失	确认 P0（合并到 3.4）	baselineV1 §5 明确 "stable UUID generated at initialization"
3.6-3.10	RuntimeEvent 路由/版本/IPC 字段/退出码	确认 P0	IPC 退出码 0-5 在 baselineV1 §8 明确定义，概要设计 §11 完全缺失
3.11-3.13	TaskSpec/WorkerResult 字段族	确认 P0	failed vs blocked 语义、summary 用途、output_contract 在 baselineV1 §9 明确，概要设计无展开
3.14	Claude Code 执行原语缺失	确认 P0	requirements FR-009 和 baselineV1 §2 将此列为核心质量基准
3.15-3.17	权限边界 7 条规则缺失	确认 P0	security-model §4 的 8 个 PathRiskCategory 和 §5 的 10 个 CommandRisk 均未反映
3.18-3.20	日志/迁移/扫描器缺失	确认 P1	baselineV1 §21-§23 和 runtime-semantics §10 有完整定义
3.21	分发章节缺失	确认 P1	baselineV1 §25 和 cross-platform-matrix §9 定义了 tarball 内容
3.22	测试分层缺失	确认 P1	baselineV1 §24 区分了 unit/integration/E2E 三层
3.23	contracts 包文件清单缺失	确认 P1	code-view §3 列出了 16 个预期文件
3.24-3.25	C++ 细节/Provider 矩阵摘要	确认 P1	Ninja/Make 优先级、compile_commands 策略、quality/cost tier 概念缺失
3.26	UI 设计资源能力缺失	确认 P2	baselineV1 §19 定义了 ui-design-assets capability

GPT-5 审查准确率：26/26 = 100%。无误判。所有缺口经 Opus 4.7 逐基线验证确认存在。

---

4. MIMO 2.5 审查交叉验证

MIMO 2.5 在 GPT-5 基础上增加了 10 项缺口（标记为 baseline gap list B-01~B-10）：

MIMO 编号	MIMO 缺口摘要	Opus 4.7 判定	理由
B-01	源文档 11/24 → 应补全至 24	确认 P0	概要设计 §1 仅列 11 份，无法溯源 scope-escalation、security-model、error-taxonomy 等 13 份
B-02	Scheduler 状态机语义缺失	确认 P1	scheduler-state-machine §4 定义了 11 个状态和转换条件，概要设计仅有 "Scheduler computes runnable wave" 一句
B-03	Main Agent 状态机缺失	确认 P1	main-agent-state-machine.md 定义了 IDLE→CLASSIFYING→ANSWERING/DELEGATING/DIRECT_MODE 等 9 个状态，概要设计仅描述了 3 个流程
B-04	ScopeImpactLevel 全分类未引用	确认 P1	scope-escalation §2 定义了 7 级 impact level，概要设计 §10.5 只覆盖了 Architecture Designer gate 触发规则
B-05	Workspace GC 保留规则缺失	确认 P2	runtime-semantics §15 定义了具体保留天数（merged 7d, abandoned 3d），概要设计 §15 仅提"retention policy"
B-06	FK-off 8 条不变量缺失	确认 P1	runtime-semantics §14 列出 8 条应用层强制规则，概要设计 §8.2 仅提"repository-level invariant checks"
B-07	Cross-DB outbox 具体步骤缺失	确认 P2	runtime-semantics §6 定义了 session-DB-first 5 步流程，概要设计 §8.3 仅提"session-DB-first intent + external write + completion/failure event"
B-08	ExperienceMiner 触发所有权缺失	降级 P2	概要设计 §13 已列出 4 条触发，但未明确"Scheduler owns trigger creation; ExperienceMiner never self-triggers"（runtime-semantics §17），影响有限
B-09	Doctor 自检引导步骤	已覆盖	概要设计 §15 列出了 5 步 Doctor 自检，与 runtime-semantics §18 一致
B-10	air restore 三粒度	已覆盖	概要设计 §15 列出了 file/time/session 三粒度，与 runtime-semantics §19 一致

MIMO 2.5 审查准确率：8/10 = 80%。B-09 和 B-10 为误判（概要设计已覆盖）。

---

5. Opus 4.7 独立发现

以下为 GPT-5 和 MIMO 2.5 均未报告的额外缺口：

G-01 错误分类学完全缺失（P0）

来源：error-taxonomy-v1.md 全文（301 行）

现状：概要设计从 §1 到 §19 完全没有提及 ErrorKind、ErrorSeverity、Retryability、AirError、semantic_signature。错误分类学定义了 21 种 ErrorKind、4 种 severity、4 种 retryability、failure signature 格式和 Scheduler 路由规则。这是工具/事件/Worker/Scheduler 实现的核心依赖。

建议：新增 §12.5 或 §9.5 Error Taxonomy Overview，至少覆盖：

• AirError 作为统一错误契约
• ErrorKind 主要分类和路由规则
• semantic_signature 格式和用途
• Retryability 与 Scheduler 路由映射

G-02 Capability Trust 生命周期缺失（P1）

来源：capability-trust-v1.md §7 定义了 discovered→validated→doctor_checked→enabled→registered→active→disabled|failed|updated 完整生命周期

现状：概要设计 §6 提到 CapabilityRegistry 但仅描述 "manifest discovery/validation/enable"。未描述 trust level（built_in/project_local/user_installed/verified_publisher/untrusted）和生命周期阶段。

G-03 Artifact 命名和 URI 规范缺失（P1）

来源：artifact-naming-v1.md 定义了 URI 格式 artifact://project/<project-id>/session/<session-id>/<artifact-id>、ID 格式 art_<ulid>、文件名格式 <timestamp>-<artifact-id>-<slug><extension>、类型到目录映射表。

现状：概要设计 §8.2 提到"artifact files use temp-write → hash → rename → DB record"但未引用 URI/ID/filename 规范。

G-04 Provider 运行时不可变规则的语义不足（P1）

来源：概要设计 §14 说"runtime provider/model selection is fixed for a running session and must not be changed"

现状：此规则在概要设计中表述正确，但缺少基线支撑 — baselineV1 §17 仅描述了 provider layer 一般架构，并未明确定义运行时不可变约束。此规则是在多模型审查阶段新增的设计决策，应追加 ADR 记录或在概要设计中标注来源为"设计阶段决策，非基线原文"。

G-05 PromptLayer 分层命名不一致（P2）

来源：prompt-layering-v1.md §2 定义了 L0-L9 共 10 层，每层有明确名称（L0 Runtime invariant, L1 Role/agent mode, L2 Safety and permission policy, ...L9 Immediate instruction）

现状：概要设计 §13 列出了层名但缩写了（"runtime invariant; role; project rules; task spec; architecture context; evidence/tool output; conversation; user override; debug context"）。L2 "safety and permission policy" 被省略为未出现，L9 "immediate instruction" 未列出。层数仅 9 项而基线为 10 层。

G-06 Event 路由追加规则缺失（P2）

来源：baselineV1 §7 "route is an append-only structured route chain"；event-registry §2 rule 5 "route is append-only. Forwarders append their route segment; they never rewrite earlier route entries"

现状：概要设计 §9 未提及 route 的 append-only 语义和 route_text = route.join("/") 派生规则。

G-07 EventBus handler 错误行为缺失（P2）

来源：interface-contracts-v1.md §7 rule 5 "If a subscribe handler throws, the error is caught, logged to developer log, and does not propagate to the publisher. The subscription remains active."

现状：概要设计 §9 的 EventBus 描述未提及 handler 异常处理规则。

G-08 command_runs 状态派生规则缺失（P2）

来源：runtime-semantics-v1.md §5 定义了 command_runs 无物理 status 列，运行时从 completed_at/exit_code/cancellation metadata 派生 running/ok/error/cancelled/unknown 状态。

现状：概要设计未提及 command_runs 状态派生语义。

---

6. 全量缺口汇总与 P 级分类

P0 — 影响实现方向或存在基线矛盾（必须修复才能进入详细设计）

ID	缺口	涉及基线	概要设计位置
P0-01	源文档清单 11→24	全部 24 份	§1
P0-02	产品定位 "not wrapper" + 规范循环	baselineV1 §1	§2
P0-03	全局 ~/.air/ 布局 + project_id UUID	baselineV1 §5	§8.1
P0-04	Claude Code 执行原语系统约束	requirements FR-009, baselineV1 §2, runtime-semantics §9	新增或 §10
P0-05	权限边界细则（7 rules）	security-model §4-§5	§12
P0-06	IPC 退出码（0-5）和 envelope 字段	baselineV1 §8, interface-contracts §10	§11
P0-07	TaskSpec/WorkerResult 字段族 + failed/blocked 语义	baselineV1 §9, interface-contracts §9-§11	§10 或新增
P0-08	错误分类学（ErrorKind/severity/retryability/signature）	error-taxonomy-v1 全文	新增
P0-09	RuntimeEvent 路由 append-only 和版本语义	baselineV1 §7, event-registry §2	§9
P0-10	SQLite 消息存储不变量（canonical format, drafts, message_parts）	baselineV1 §13, db-schema §4-§5	§8.2

P1 — 影响完整性但有基线可查（建议在概要设计补充，否则须在详细设计开头注明）

ID	缺口	涉及基线	概要设计位置
P1-01	参考项目影响和复用边界	baselineV1 §2	新增
P1-02	技术栈约束条目	baselineV1 §3, requirements §5	§2 或新增
P1-03	Scheduler 状态机摘要（11 states）	scheduler-state-machine §2-§4	§10.2
P1-04	Main Agent 状态机摘要（9 states）	main-agent-state-machine 全文	§10.2
P1-05	ScopeImpactLevel 7 级分类	scope-escalation §2	§10.5
P1-06	FK-off 应用层 8 条不变量	runtime-semantics §14	§8.2
P1-07	日志架构（air.log + encrypted dev log + 7d retention）	baselineV1 §23, requirements FR-019	新增
P1-08	迁移架构（schema 检测、计划、确认、备份、回滚）	baselineV1 §22	新增
P1-09	扫描器语义（无排除、无深度限制、symlink/error 处理）	runtime-semantics §10	新增
P1-10	分发章节（tarball 内容 bin/air + resources + LICENSE）	baselineV1 §25, cross-platform §9	新增
P1-11	测试分层定义（unit/integration fixture replay/E2E real LLM）	baselineV1 §24	§17
P1-12	contracts 包文件清单（16 files）	code-view §3	§4
P1-13	C++ 细节：Ninja-first/Make-fallback、compile_commands 按需、clangd CLI mode	baselineV1 §20, tool-registry §7	§10.6
P1-14	Provider 能力矩阵摘要（quality/cost tier, conversion report）	provider-capability-matrix 全文	§14
P1-15	Capability Trust 生命周期和 trust level	capability-trust §6-§7	§6
P1-16	Artifact URI/ID/filename 规范引用	artifact-naming §3-§5	§8.2

P2 — 可在详细设计阶段补充

ID	缺口	涉及基线
P2-01	OpenCode UI 复用边界（reuse list + do-not-reuse list）	baselineV1 §18
P2-02	UI 设计资源能力（ASCII/wireframe/SVG/screenshot analysis）	baselineV1 §19
P2-03	Workspace GC 具体保留天数	runtime-semantics §15
P2-04	Cross-DB outbox 具体 5 步流程	runtime-semantics §6
P2-05	ExperienceMiner 触发所有权（Scheduler owns, never self-triggers）	runtime-semantics §17
P2-06	PromptLayer L0-L9 全名一致性（L2 safety 缺失，层数 9→10）	prompt-layering §2
P2-07	event route append-only 和 route_text 派生	event-registry §2
P2-08	EventBus handler 异常处理	interface-contracts §7
P2-09	command_runs 状态派生语义	runtime-semantics §5
P2-10	Provider 运行时不可变规则 ADR 溯源	设计阶段决策

---

7. 三视角联合评估

7.1 架构师视角

概要设计的容器边界、组件职责划分、依赖方向和禁止路径均与 C4 module/code-view 一致，这是最大的优势。Architecture Designer gate 规则完备。但缺少错误分类学意味着 Scheduler 路由决策和 Worker 失败语义在概要设计层面没有定义入口，详细设计无法直接从概要设计推导错误处理流程。

7.2 工程师视角

IPC 退出码、TaskSpec 字段族、PermissionEngine 具体分类规则、错误签名格式等是工程实现的直接依据。概要设计省略这些意味着实现者必须同时查阅 5+ 份基线文档才能开工。P0 级别的缺口直接影响 Phase 0-1 的 contracts 包和 storage 实现。

7.3 需求验证视角

FR-001FR-018 在概要设计中有对应描述或可推导。FR-009（执行原语）、FR-019（日志）、FR-020（测试分层）和约束条件 §5 缺失。NFR-001NFR-008 中 NFR-001 local-first、NFR-002 recoverability、NFR-005 UI responsiveness 覆盖良好，但 NFR-008 security boundary preservation 的细节在概要设计中不足（缺少 PathRiskCategory 和 CommandRisk 分类定义）。

---

8. 与先前审查的一致性对比

维度	GPT-5	MIMO 2.5	Opus 4.7
总分	未给分	5.6/10	5.9/10
P0 缺口数	~10	10	10
P1 缺口数	~12	12	16
P2 缺口数	~4	未细分	10
独立发现	26 items	+10 items	+8 items (G-01~G-08)
误判率	0%	20% (B-09, B-10)	N/A
最关键遗漏	错误分类学未报告	错误分类学未报告	错误分类学 P0 报告

三份审查的核心结论一致：概要设计骨架良好，但实现可操作性不足，P0 缺口必须修复才能安全进入详细设计。

GPT-5 和 MIMO 2.5 共同遗漏的最大缺口是错误分类学（error-taxonomy-v1.md），该文件 301 行定义了整个运行时的错误传播和路由基础，概要设计完全未引用。

---

9. 修复建议

9.1 推荐修复策略

仅应用 P0 补丁（10 项），P1/P2 在详细设计阶段作为设计输入补充。此方案下可进入详细设计，但需在详细设计文档开头注明概要设计的已知缺口。

9.2 P0 补丁清单

P0 ID	修改位置	修改内容	预计行数
P0-01	§1 Source documents	补全 24 份源文档	+30
P0-02	§2 System Goal	补入 "not a wrapper"、canonical V1 loop	+8
P0-03	§8.1 Project layout	新增 Global ~/.air/ layout + project_id UUID	+25
P0-04	§10 (新增 §10.7)	Claude Code execution discipline 系统约束	+15
P0-05	§12	补充 PathRiskCategory 8 种、CommandRisk 10 种、7 条规则	+30
P0-06	§11	补充 IPC exit codes 0-5、envelope 必需字段	+15
P0-07	§10 (新增 §10.8)	TaskSpec/WorkerResult 字段族概要 + failed/blocked 语义	+20
P0-08	新增 §12.5 或 §9.5	Error Taxonomy Overview	+25
P0-09	§9	补充 route append-only、version increment、route_text 派生	+8
P0-10	§8.2	补充 canonical format = anthropic JSON、drafts 删除规则、message_parts 非 V1 表	+8

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

9.3 P1 处理建议

在详细设计文档（或 class diagram freeze 文档）开头附录中列出 16 条 P1 缺口及其基线引用，确保实现者知道需要查阅哪些基线。

---

10. 进入详细设计的门禁判定

条件	状态
P0 缺口全部修复	未满足（10 项待修复）
P1 缺口有溯源路径	满足（基线可查）
架构一致性 > 7/10	满足（7.5）
需求覆盖 > 7/10	未满足（6.0）

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

P0 修复预计工作量约 30-45 分钟（184 行概要设计补丁），修复后可立即进入详细设计 / class diagram freeze。

---

附录 A：三份审查缺口交叉索引

概要设计位置	GPT-5	MIMO 2.5	Opus 4.7	P 级
§1 源文档	3.1 提及	B-01	P0-01	P0
§2 产品定位	3.1	R-01	P0-02	P0
§2 参考项目	3.2	-	P1-01	P1
§2 技术栈	3.3	R-04	P1-02	P1
§8.1 ~/.air/	3.4+3.5	B-01 partial	P0-03	P0
§8.2 SQL 消息	-	-	P0-10	P0
§8.2 FK-off	-	B-06	P1-06	P1
§9 事件路由	3.6-3.8	-	P0-09	P0
§9.5 错误分类	未报告	未报告	G-01/P0-08	P0
§10 执行原语	3.14	R-01	P0-04	P0
§10.2 TaskSpec/WR	3.11-3.13	-	P0-07	P0
§10.2 Scheduler SM	-	B-02	P1-03	P1
§10.2 Main Agent SM	-	B-03	P1-04	P1
§10.5 ScopeImpact	-	B-04	P1-05	P1
§11 IPC 退出码	3.9-3.10	-	P0-06	P0
§12 权限细则	3.15-3.17	-	P0-05	P0
§13 PromptLayer	-	-	P2-06	P2
§13 ExperienceMiner	-	B-08	P2-05	P2
§14 Provider	3.25	-	P1-14	P1
§14 UI 复用	-	-	P2-01	P2
§15 Workspace GC	-	B-05	P2-03	P2
日志	3.18	R-02	P1-07	P1
迁移	3.19	-	P1-08	P1
扫描器	3.20	-	P1-09	P1
分发	3.21	-	P1-10	P1
测试分层	3.22	R-03	P1-11	P1
contracts 清单	3.23	-	P1-12	P1
C++ 细节	3.24	-	P1-13	P1
Capability 生命周期	-	-	G-02/P1-15	P1
Artifact 命名	-	-	G-03/P1-16	P1
UI 设计资源	3.26	-	P2-02	P2

---

附录 B：基线覆盖热力图

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

覆盖最差基线：error-taxonomy-v1.md（0%）、artifact-naming-v1.md（20%）、capability-trust-v1.md（30%）、scheduler-state-machine-v1.md（30%）、provider-capability-matrix-v1.md（30%）。