用途：这是一份操作流程，指导把 Herdr 的单个提供商集成移植进 Sidecar。Sidecar 会向其他 agent 的配置安装 hook、插件和扩展资产，使这些 agent 回报生命周期状态与会话身份；这些资产的知识来自 Herdr（共十七个）。移植即保留提供商知识原文，用 Sidecar 的传输替换 Herdr 的传输，并让结果通过既有适配器相同的守卫。
主要能力与结构：上游 vendored 树 internal/agentintegration/upstream/<dir>/ 保存 Herdr 资产的逐字节副本；upstream.lock.json 用 SHA-256 固定每个文件并记录 HERDR_INTEGRATION_VERSION；portedfrom.go 为每个已发布资产记录一行 PortedFrom；internal/tools/herdrsync 负责重新 vendoring、重写锁并渲染 report.md，由 herdr-sync.yml 每周一运行。
使用方式：按顺序一次处理一个提供商。先读 internal/agentactivity/manifests/report.md 的 ## Integration assets 判断哪个提供商有变动，注意提交的报告只是快照。再选择移植形态：形态 A 是把 Herdr Rust 中的 (event, matcher, action) 表渲染进提供商自己的配置文件，参考 kimi_install.go 与 mastracode_install.go；形态 B 是投放提供商加载的文件，提供商部分逐字保留、传输部分替换，参考 OpenCode、Pi、Kilo、OMP、Hermes；形态 C 是会话身份条目，复用 sessionhook.go 的通用描述符，已有八个提供商实例。
限制：不要手改 upstream/ 下文件；不要为“看效果”运行 go run ./internal/tools/herdrsync，也不要 glob ./internal/tools/...；报告表格以下内容受 600 行预算限制；非 JS 资产（如 Hermes 的 Python 包）需相应解释器，缺失时默认跳过，除非设置 SIDECAR_REQUIRE_NODE=1 或 SIDECAR_REQUIRE_PYTHON=1。是否遵循提供商的配置目录覆盖变量由证据决定，而非变量名。