Shadow Harness Integration

把前述 canonical contracts 接成 API→State→Scheduler→Worker→Runtime→Tool/Sandbox→Trace 的完整系统。

推荐阅读顺序

1. Shadow Harness 从哪些边界开始：Architecture、Domain Model 与 Model Adapter

回答：Shadow Harness 的顶层组件和 domain objects 应怎样分层，Model Adapter 为什么必须隔离 Provider SDK？

2. Context、Retrieval 和 Tool Catalog 怎样接起来

回答：ContextManager 如何组合 Retriever 和 ToolRegistry 的输出，同时保持 identity、version 和 permission 一致？

3. 模型计划如何变成真实执行：ToolExecutor、Planner 与 GraphCompiler

回答：Planner 输出怎样先编译成受约束 Graph，再由 ToolExecutor 执行，而不是让模型直接调用实现？

4. Graph 怎样被调度并持久化：Scheduler、State Machine 与 StateStore

回答：Scheduler、Run State Machine 与 StateStore 怎样共享同一份 execution truth，避免双重状态源？

5. 恢复、重试和人工审批怎样共享同一执行事实

回答：Checkpoint、Retry 和 Approval 怎样围绕同一个 logical operation identity 协作，确保 resume 不重复副作用？

6. Trace、Eval 和 OpenTelemetry 怎样共用同一条 Run Identity

回答：TracePipeline、Evaluation Harness 和 OTel exporter 怎样复用同一 Run / Span identity，而不各造一套事件模型？

7. 外部能力适配：MCP 与 Workspace / Sandbox

回答：MCP 和 Workspace / Sandbox 适配器怎样暴露统一内部接口，不让远端协议或本地 SDK 类型渗入 Runtime？

8. 运行入口与调试面：API、RunManifest 与 Developer Console

回答：API / Event Stream、RunManifest 和 Developer Console 怎样共享 Runtime 事实，而不让调试面变成第二个状态源？

9. Run 真正怎样从 API 跑到 Worker：Dispatch、Lease 与 Lifecycle Hooks

回答：最终 Shadow Harness 中，API 创建的 Run 怎样可靠进入 Worker 执行；Hooks 又怎样扩展行为而不篡改 Runtime authority？

最终闭环矩阵

Module 21 不重新教学前 20 个模块，而是验证它们是否真正落到组件、durable fact 和测试证据。完整映射见 Module 01–21 → Shadow Harness 闭环矩阵。

本模块学习边界

• 暂不展开：不要为了“架构完整”提前一次实现全部组件；按 v0.1→v1.0 版本逐步吸收