Dispatch rules

Skill: 任务派发规则与调度策略

适用 Agent：尚书省 加载时机：尚书省 dispatch 模式（收到准奏方案准备派发时）

派发原则

任务类型	派发至	示例
功能开发、代码实现、Bug 修复	🔧 工部	实现登录接口、修复分页 Bug
数据库设计、数据处理、报表	💰 户部	设计用户表、生成月报
文档编写、规范制定	📝 礼部	编写 API 文档、制定 Git 规范
部署、CI/CD、服务器运维	⚔️ 兵部	配置 GitHub Actions、部署到 K8s
测试、审计、安全扫描	⚖️ 刑部	编写单元测试、OWASP 扫描
Agent 管理、权限配置	📋 吏部	添加新 Agent、调整权限

跨部门协作

当一个子任务涉及多个部门时：

1. 拆分：将复合任务拆为独立子任务，明确每部分负责部门
2. 定义依赖：标注执行顺序（如工部先开发 → 礼部写文档 → 刑部写测试）
3. 接口约定：定义各部门之间的数据传递格式
4. 同步机制：前序任务完成后，通知后续部门启动

调度策略

1. 依赖优先：先派发无依赖的任务，再按依赖链派发后续任务
2. 并行最大化：无依赖关系的任务同时派发，缩短总执行时间
3. 关键路径：识别最长执行链，优先保障关键路径上的任务
4. 负载均衡：避免单一部门堆积过多任务
5. 快速反馈：短任务优先完成，让皇上尽早看到进展

📎 容错与降级策略详见 fault-tolerance-tables.md

部门内并行提示（parallel_hint）

尚书省派发时，若同一部门收到多个属于同一 parallel_group 的任务，须进一步判断并在工单中附加 parallel_hint：

{
  "task": {
    "id": "TASK-001",
    "assigned_to": "gongbu",
    "parallel_hint": {
      "can_parallel_with": ["TASK-005"],
      "reason": "T-001 修改 src/auth/，T-005 修改 src/api/，模块不重叠",
      "confidence": "high"
    }
  }
}

• can_parallel_with：可与哪些同部门任务并行
• reason：并行判断的理由
• confidence：high（确定无冲突）/ medium（大概率无冲突，堂官需验证）/ low（不确定，堂官自行判断）
• 分析粒度：模块级——同部门任务影响的模块是否重叠

注意：parallel_hint 是建议而非命令，堂官有权基于文件级冲突检测推翻。

📎 堂官收到 parallel_hint 后的冲突检测规则详见 parallel-conflict-rules.md

并行与串行示例

并行：工部(前端) + 户部(数据库) + 礼部(文档) ──→ 尚书汇总 → 刑部集成测试
串行：工部(核心逻辑) → 刑部(测试) → 兵部(部署)