Appearance
Context、Retrieval 和 Tool Catalog 怎样接起来
前置：Shadow Harness 从哪些边界开始：Architecture、Domain Model 与 Model Adapter
核心问题：一次 Model Request 里 Context、Retrieval 和 Tool Catalog 怎样汇合，同时又不让 Retriever/Registry 直接控制 Runtime？
Resume 后 ContextManager 从 durable state 和当前 workspace 重新组装请求，而不是把历史 Session 全量重放给模型。ContextManager 调 retrieve(query, filters) ，得到标准 chunks，再按预算选择。
Harness ContextManager Wiring
最终 Wiring 中，ContextManager 不是一个“大字符串拼接器”，而是把多个事实源整理成一次 ModelRequest 的边界：
text
RunState ─┐
Memory ───┤
Retriever Evidence ─┤→ ContextManager → ModelRequest
ToolRegistry metadata ┤
Workspace/Artifact refs ┘每类输入仍由自己的组件负责 truth：Retriever 决定返回哪些 Evidence，ToolRegistry 决定当前有哪些 capability，StateStore 保存执行事实。ContextManager 只负责本轮 selection、budget、ordering 和 rendering。
这样后面替换 Retriever 或 Tool Provider 时，不需要把 ContextManager 改成一堆 SDK 特判。
Retriever
Retriever 在最终架构里是一个 port。它接收 typed RetrievalQuery，返回标准 Evidence[]；BM25、vector、hybrid 或远端搜索都放在 adapter。
ContextManager 只依赖 Evidence contract，不读取 vector DB SDK object，也不把 retrieval score 当成跨索引可比较的全局置信度。
ToolRegistry Wiring
Module 06 已定义 ToolRegistry 行为。最终 Harness 在 Run 创建时根据 identity、policy、provider capability 和 manifest version 生成 run-scoped exposed catalog，ContextManager 与 ToolExecutor 共享这一个 catalog snapshot。
discovery 更新不会静默改变正在执行的 Run；新 catalog 版本只影响新 Run，或通过显式 revalidation/migration 进入旧 Run。
Failure Modes
Context/Retriever/ToolRegistry 使用不同的身份与版本快照
症状： 三个组件分别读取“当前用户/当前工具/当前索引”，一次 Run 内得到不一致视图。
为什么危险： 同一次决策无法复现，权限或 Tool schema 可能在中途漂移。
处理： 由 RunManifest/Context build 输入统一 identity + version snapshot，组件只消费显式参数。
如何验证
| Case | 断言 |
|---|---|
| Context/Retriever/ToolRegistry 使用不同的身份与版本快照 | 冻结 RunManifest 后模拟 catalog/index 更新，断言当前 Run 仍使用同一 identity/version snapshot。 |
自测
- ContextManager、Retriever、ToolRegistry 三者都向模型提供信息，但为什么应该保持可独立替换和测试？
- 一个 retrieval result 应怎样进入 Context，而 ToolRegistry 又应怎样只暴露当前允许的 Tool？