thrifty-dispatch

thrifty-dispatch 是一个精简的分层构建编排器，基于 JSONL 派发架构，适用于成本敏感的多冲刺构建任务。

用途

thrifty-dispatch 用于执行规格说明（spec），而非发明需求。它适合「thrifty fast / lean / dispatch」场景，或成本敏感的多冲刺构建。其存在的原因是：子代理（subagent）版本被编排器成本主导——每个子代理携带 40k 的 harness 上下文，其报告返回编排器上下文后每轮都会被重新读取（实测：3 冲刺任务产生 1.2M 缓存读取，成本 $1.86）。本架构通过两项修复避免这两个问题。

主要能力

裸调用（Bare calls）：每个冲刺运行 claude -p "<prompt>" --model {haiku|sonnet} --bare。--bare 剥离 hooks、插件和系统提示，因此 Haiku 冲刺调用约为 $0.002–0.05，而非约 $0.05 加 40k harness。使用订阅 OAuth，无需 API key。

不摄入输出：脚本将文件写入磁盘并返回 manifest.json。你读取 manifest（很小），而非生成的代码。没有上下文复合，没有重复读取税。

使用方式

你是架构师，需保持自己的轮次和上下文精简。流程如下：

框定（Frame）：先确认规格存在。thrifty 执行规格（需求加「完成」的定义）；它做规划，但不发明需求。如果用户没有给出规格或指针，不要捏造并构建——告知用户 thrifty 执行他们带来的规格（thrifty 与规划方式无关），可提供帮助起草或头脑风暴，待规格存在后再进入。否则：读取规格或探索上下文。选择一个 <slug>，在干净目录中工作。
编写 contract.md：仅跨冲刺表面（共享接口/接缝、约定、所有权、依赖图）。保持精简——固定跨边界的内容，内部实现信任执行器（Haiku 很强；这不是为本地模型做逐字节固定）。
编写 sprints.jsonl：每行一个 JSON 对象：

{"id":"SPRINT-001","tier":"haiku","kind":"generate","deps":[],"brief":"...terse brief + acceptance criteria..."}

tier：generate 冲刺始终在 Haiku 上运行（脚本强制）——代码生成从不升级。如果某单元对 Haiku 来说太难，将其拆分为更小的冲刺；不要寻求更强的执行器。Sonnet 仅用于规划和修复循环。
kind：generate（模型输出 <FILE path="...">...</FILE> 块，脚本写入它们）或 brief（模型输出 markdown，保存到 briefs/<id>.md）。
deps：必须先完成的冲刺 id（脚本按依赖波次运行，波次内并行）。

对于拆分规划阶段，先输出 kind:"brief" 冲刺（tier sonnet）编写简报，然后输出消费它们的 kind:"generate" 冲刺（tier haiku）。对于小任务，直接在此内联编写简报并跳过简报阶段。

派发（Dispatch）：通过 Bash 运行脚本。优先使用 --run "<gate>"（完整流水线：规划 → 执行 → 门禁 → 有界修复），或裸运行仅执行：

python3 <this-skill-dir>/dispatch.py --run "node --test"

它循环冲刺，进行裸调用（依赖波次内并行），将文件写入磁盘，并输出 manifest.json 加 run_manifest.json。不要将生成的文件读入上下文——读取 manifest。

在后台运行并向用户叙述进度——多分钟的静默 Bash 调用是糟糕的 UX。脚本会流式输出已刷新的里程碑，你应在它们出现时转达，例如 [plan] done: … N sprints → [execute] ok SPRINT-003 → … (3/N) → [gate] PASS → [done] … = $X。manifest 是持久检查点（规划后 plan_manifest.json，执行后 manifest.json，结束时 run_manifest.json），因此轮询/跟踪并报告：「✅ Planned N sprints → ⏳ executing 3/N → ✅ gate passed, $X」。保持这些摘要精简——转达里程碑，而非文件内容。

验证（Gate）：自行用 Bash 运行任务的门禁（node --test、pytest、CLI 冒烟）。这是独立检查；廉价，无模型。基于项目实际发布的命令进行门禁（npm run build、tsc -b && vite build、go build ./...），而非可能在实际构建失败时仍通过的较弱代理（例如在 tsc -b 项目引用设置下，裸 tsc --noEmit 通常是无操作）。如果不确定，读取 package.json scripts 或构建配置并据此门禁。
外科手术式修复循环：对每个失败，仅读取失败的测试加相关代码，诊断（代码 bug 还是执行器自己的坏测试），就地修复——或重新派发该冲刺并在其简报后附加纠正说明。重新运行门禁。限制它：几次修复后，上报给人类。
报告：构建了什么、门禁结果和总成本（你的编排器会话 /status 加 manifest.json 的 dispatch_cost_usd）。

适用场景

成本敏感的多冲刺构建任务。
需要精简编排、避免上下文膨胀的代码生成工作流。
已有明确规格说明、需要确定性执行的构建。

限制与注意事项

执行器输出文本，而非工具使用：--bare 剥离工具；模型输出 <FILE> 块，脚本写入它们。不要期望冲刺调用运行测试或读取文件——那是编排器在门禁处的职责。
在新环境中确认一次模型路由：claude -p "hi" --model haiku --bare --output-format json 应花费约 $0.002（Haiku 费率），而非约 $0.05+（回退到更大模型）。
保持 contract 精简、自己的轮次少：编排器的上下文 × 轮次是本架构旨在最小化的成本。编写两个文件、调用脚本、读取 manifest、门禁、修复。不要重新读取产物。
规格必须由用户提供：thrifty 不发明需求。

已验证案例

任务 01（wordfreq，3 冲刺）：派发层成本 $0.078（3 次 Haiku 裸调用），一次性 18/19 测试通过，一次外科手术式修复后 19/19——对比子代理 thrifty 同一任务的 $1.86。唯一失败是执行器编写的测试与 contract 的分词器矛盾（在「按非字母分割」下 word0 折叠为 word）——被门禁捕获，一次编辑修复。