gathering-migration

汇聚迁徙 🌲🐻🐕

鼓声在山谷间回荡。指挥者站在山口，协调两种截然不同的力量。猎犬最先抵达，带着全新的视角——不预设任何连接关系，只凭敏锐的嗅觉寻找依赖项。随后熊苏醒过来，接过一张并非自己绘制的地图——不走捷径，也不说“我已经知道东西在哪里”。它们各自拥有独立的上下文，只信任自己亲自验证过的内容，一起安全地移山。

何时召唤

• 执行前需要探索代码库的复杂迁移
• 在系统、库或架构模式之间迁移
• 影响多个关系的架构变更
• 涉及多个文件的组件或 API 迁移
• 存在下游依赖项的图标、资源或内容迁移
• 任何需要在迁移前了解情况的迁移

重要提示：本次汇聚由指挥者负责协调。它绝不会直接侦察或迁移，而是分派子 Agent——每种动物各一个，并为其指定合适的模型。指挥者只管理交接和关卡检查。

---

汇聚流程

SUMMON → DISPATCH → GATE → DISPATCH → GATE → VERIFY
  ↓         ↓        ↓        ↓        ↓        ↓
Spec    Bloodhound  Check    Bear    Check    Final
(self)   (haiku)     ✓     (opus)    ✓     Verify

派遣的动物

顺序	动物	模型	职责	全新视角？
1	🐕 猎犬	haiku	侦察依赖项，绘制领域地图	是——只会看到迁移规范
2	🐻 熊	opus	安全执行迁移	是——只会看到领域地图，不会看到侦察过程

**参考：**加载 references/conductor-dispatch.md，查看子 Agent 提示词和交接格式的详细说明

---

阶段 1：召唤

鼓声响起。山谷静听……

指挥者收到迁移请求并准备派遣计划：

明确迁移内容：

• 需要迁移什么？（数据、组件、图标、配置、约定……）
• 从哪里迁移到哪里？（旧模式 → 新模式）
• 存在哪些下游依赖项？
• 如果出了问题，如何“撤销”？

确定熊所需的领域指南：

迁移类型	领域指南
数据库架构、表、D1/SQLite	domain-database.md
组件属性、API 升级、导入	domain-components.md
图标、资源、文档、文件格式	domain-content.md
配置、约定、依赖项	domain-general.md

与人工确认后继续。

**输出：**迁移规范、确定的领域指南、已确认的派遣计划。

---

阶段 2：侦察（猎犬）

指挥者发出信号。猎犬低头嗅探地面……

Agent(bloodhound, model: haiku)
  Input:  migration specification only
  Reads:  bloodhound-scout/SKILL.md (MANDATORY)
  Output: territory map

派遣一个 haiku 子 Agent 侦察代码库。猎犬只会收到迁移规范——没有预先分析，也没有任何假设。它会读取自己的技能文件，并完整执行 SCENT → TRACK → HUNT → REPORT → RETURN 工作流。

猎犬绘制的地图包括：

• 所有涉及待迁移项目的引用
• 依赖关系（什么依赖于什么）
• 下游使用方
• 边缘情况和不常见的使用模式
• 当前状态计数（项目数、引用数）

**交接给指挥者：**领域地图（受影响的文件、依赖关系图、边缘情况、当前状态计数、风险评估）。

**关卡检查：**领域地图须包含文件列表、依赖关系、项目数量和已识别的边缘情况。如不完整，应向猎犬提出具体问题并恢复其工作。

---

Phase 3：迁移（Bear）

Bear 醒来。它收到了一张并非由自己绘制的地图……

Agent(bear, model: opus)
  Input:  migration spec + territory map (from Bloodhound)
  Reads:  bear-migrate/SKILL.md + references/{domain-guide} (MANDATORY)
  Output: migration results + file list

派遣一个 opus subagent 执行迁移。Bear 会收到规范和 Bloodhound 的领地地图——而不是 Bloodhound 的侦察过程，只接收其结构化输出。

Bear 的工作：

• 保留原始状态（分支、备份或快照）
• 分块执行迁移，确保每块大小适中
• 每完成一块后进行验证
• 确认条目数量一致（源与目标）
• 运行完整性检查（引用均可解析、导入正常、没有孤立项）

**移交给指挥者：**迁移结果（已迁移条目、已跳过条目、验证报告）、文件列表。

关卡检查：

pnpm install
gw dev ci --affected --fail-fast --diagnose

必须通过编译和测试。如果失败，继续调用 Bear 并提供错误信息。

---

Phase 4：验证

旅程结束。指挥者确认已安全抵达……

验证清单：

• Bloodhound：已映射所有依赖项
• Bloodhound：已找到所有引用
• Bloodhound：已记录边缘情况
• Bear：已保留原始状态（分支、备份或快照）
• Bear：条目数量一致（源与目标）
• Bear：完整性检查通过（引用均可解析、导入正常、没有孤立项）
• Bear：测试通过（gw dev ci --affected）
• Bear：已记录回滚方案

完成报告：

🌲 GATHERING MIGRATION COMPLETE

Migration: [Description]

DISPATCH LOG
  🐕 Bloodhound (haiku) — [territory mapped, X files identified, Y dependencies found]
  🐻 Bear (opus)         — [Z items migrated, domain guide: {guide}]

GATE LOG
  After Bloodhound: ✅ territory map complete
  After Bear:       ✅ compiles clean, migration verified
  Final CI:         ✅ gw dev ci --affected passes

MIGRATION RESULTS
  Items migrated: [count]
  Items skipped: [count, reason]
  Item count match: ✅ [source] = [dest]
  Integrity checks: ✅
  Rollback: [branch/backup location]

Everything found its new home.

---

指挥者规则

绝不亲自执行动物的工作

指挥者负责派遣，不负责侦察依赖项或执行迁移。

全新视角是一项优势

Bear 接收的是领地地图，而不是 Bloodhound 的侦察过程。它信任地图，但会在迁移过程中验证自己的发现。

每次交接都要通过关卡

Bear 开始工作前，领地地图必须完整。Bear 完成后，CI 必须通过。

继续执行，不要重来

如果关卡检查失败，就继续调用未通过检查的 Agent。Bear 尤其适合通过继续执行来恢复——它掌握迁移上下文，因此比从头开始能更快地解决问题。

---

反模式

指挥者不会：

• 自行侦察代码库
• 直接执行迁移步骤
• 在领地地图不完整时让 Bear 开始工作
• 跳过数量验证（源与目标必须一致）
• 跳过回滚文档

---

快速决策指南

迁移范围	策略
简单重命名（< 5 个文件）	仅使用 Bear（无需 Bloodhound）
跨多处迁移（5-50 个文件）	标准流程：Bloodhound → Bear
大规模迁移（50+ 个文件）	Bloodhound → Bear，分块执行
范围未知（“迁移 X”）	始终从 Bloodhound 开始

---

当没有任何一种动物足以胜任时，集结便有了答案。 🌲🐾