I-03 · 多模型任务调度器

字段	值
项目	基础设施 · `vscode/PLANNING`（工具本体）+ `Desktop/dsh`（可选深度集成）
优先级	P0 · M1
建议模型	gpt-5.6-luna（设计） → deepseek-v4.1-flash（实现）
依赖	无（消费 `task-manifest.json`）
预估	2.5 天

一、背景（为什么做）

你现在的核心痛点：多模型派发全靠手工——复制任务卡、记住哪张给了谁、回收 PROGRESS 靠人肉记忆。这套体系要跑 28 张卡 × N 轮迭代，必须有调度器兜底。它是整个 PLANNING 体系的"执行引擎"。

重要：参考实现已预植入 —— PLANNING/tasks.py（标准库，零依赖）已由规划者写完并全命令实测通过：list / show / dispatch / bundle / collect / status / start / accept / block / reset。 你的工作降级为：① 复核全部命令（跑一遍验收命令）② 补 state.json 初始化样例与文档 ③ 针对发现的问题修复或提改进（如 review 状态的流转）④ 若 DSH 有可调用接口，评估深度集成的可行性（保持可选）。不要重写。

二、目标（交付物）

一个 CLI 工具（建议 PLANNING/tasks.py，Python + 标准库，零重依赖）：

tasks.py list                       # 列出全部任务 + 状态（读 manifest + 扫描 PROGRESS）
tasks.py show C-01                  # 打印任务卡全文 + 项目上下文指引
tasks.py dispatch C-01              # 产出「可直接粘贴的派单提示词」（卡全文+协议+发令）
tasks.py dispatch C-01 --model deepseek-v4.1-flash   # 指定模型版本
tasks.py collect                    # 扫描各项目根 PROGRESS_*.md，汇总状态与验收线索
tasks.py status                     # 看板：表格式状态 + 里程碑进度
tasks.py accept C-01                # 人工验收标记（写回 manifest 状态：todo/doing/review/done/blocked）

关键设计

状态存储：manifest 为源 + PLANNING/state.json 覆盖层（避免互相写冲突；accept 写 state）。
dispatch 输出格式（自包含，直接能喂任何模型）：
- 任务卡全文
- 03-执行协议.md 内容或引用
- 项目根路径 + "先读 README 与最近 PROGRESS" 指引
- 发令语："按卡作业，完成后写 PROGRESS_.md"
collect 自动扫描：四个项目根 + PLANNING/ 下的 PROGRESS_*.md，解析状态字段，更新看板。
可选深度集成（Phase 2）：对接 DSH subagent 派发（若 DSH 有可调用接口则自动投递；没有则保持"产出提示词由人粘贴"模式）。
用一张真实任务卡做端到端演示（推荐 C-01：list → dispatch → collect 演练）。

三、验收标准

list 正确输出 28 任务与状态（读取真实 manifest）
dispatch C-01 输出自包含提示词（不依赖外部粘贴即完整可执行）
collect 扫描到模拟的 PROGRESS_C-01.md 并正确解析状态（用 fixture 验证）
status 看板含里程碑分组与进度计数
accept 写回状态且重复执行幂等
零第三方重依赖（可用 rich 之外不强求；Windows/Git Bash 均可跑）
全流程演练记录进 PROGRESS

四、验收命令（参考）

cd vscode/PLANNING && python tasks.py list
python tasks.py dispatch C-01
python tasks.py collect
python tasks.py status

五、边界（不许做）

不自动 git 操作（调度器不碰仓库）
不做 Web UI（CLI 优先；看板后续再说）
不改任务卡内容（只读取与状态回写）

六、交接

写 PROGRESS_I-03.md（含全流程演练输出）。

3.7 KiB Raw Blame History Unescape Escape