用途：speculative-pipeline 是一种流水线执行策略，让下游阶段在上游阶段尚未完成时提前启动，用错峰时间替代严格串行，以缩短整体交付时间。
主要能力：领导者阶段立即开始，跟随者阶段在可配置延迟后启动，基于当时已存在的上游产物工作；配合收敛循环，跟随者每轮迭代重新读取最新上游产物并自我修正，逐步消除因输入不完整造成的错误。资料给出的示例中，三阶段流水线由串行约 12 小时缩短到约 7 小时。
使用方式：为每个阶段准备提示文件，并让各阶段读取上游目录、写入自己的目录。示例目录为 context/specs、context/plans、context/impl 与 context/prompts。在多个终端或 tmux 面板中分别运行收敛循环工具，例如： {LOOP_TOOL} context/prompts/001-generate-specs.md -n 5 -t 2h {LOOP_TOOL} context/prompts/002-generate-plans.md -n 5 -t 2h -d 1h {LOOP_TOOL} context/prompts/003-implement.md -n 10 -t 1h -d 2h 其中 -n 为迭代次数，-t 为每轮时间预算，-d 为启动延迟；{LOOP_TOOL} 需替换为实际的收敛循环运行器。延迟建议：不小于一个上游迭代，且小于上游时长的一半；延迟越短，跟随者迭代次数应越多。
适用场景：3 个以上阶段的长流水线、各阶段共享同一 git 仓库、具备收敛循环、上游规格在 1 至 2 轮后基本稳定时效果较好。
限制：存在硬依赖的阶段不适合；单轮迭代阶段无法自我修正；两阶段且每阶段不足 1 小时的短流水线收益有限。需监控跟随者每轮 diff 是否递减，若持续很大说明发生抖动，可通过增大延迟、减少跟随者迭代或增加等待上游收敛的门槛来修正。全部阶段完成后应对合并结果运行完整构建与测试验证。