rundown：将Markdown变为可执行工作流的代理运行时

rundown是一个与工具无关的代理框架，将Markdown文档视为托管工作负载，通过复选框契约实现任务的执行、验证和修复，为AI代理工作流带来确定性和可观测性。

当前大多数AI代理工作流存在一个根本性的断裂：工作描述在Markdown中，代理执行在别处，验证发生在人脑中，历史记录不完整，恢复过程模糊。结果是熟悉的问题——事情看起来完成了，实际上并没有。

这种"交接断裂"导致了一系列痛点：

• 任务状态不透明，难以判断真实进度
• 代理输出缺乏验证机制，质量参差不齐
• 多代理协作时上下文丢失，重复沟通成本高
• 故障恢复依赖人工判断，无法自动化处理

rundown的解决方案是将复选框从"待办事项"提升为"执行契约"。一个任务不是因代理说完成而完成，而是因为工作被执行、验证通过，然后才被标记为完成。

这种设计哲学借鉴了基础设施即代码（Infrastructure as Code）和GitOps的理念：将意图声明（Markdown中的任务描述）与实际执行（运行时管理）分离，同时保持两者的可追溯关联。

rundown将Markdown文件视为一等公民的工作负载定义。每个未勾选的复选框成为一个工作单元，包含：

• 上下文：任务周围的描述性文字和代码块
• 执行指令：通过CLI代理或内联命令运行
• 验证标准：独立的验证步骤确保质量
• 修复机制：验证失败时的自动修复循环
• 规划能力：任务过大时的自动拆分

与许多代理系统的随机或启发式任务选择不同，rundown采用排序和可预测的选择算法。这种确定性确保了多次运行的一致性，便于调试和审计。

rundown的执行流程严格区分"执行"和"验证"两个阶段：

1. 运行时找到下一个就绪的未勾选任务
2. 从周围上下文和仓库模板构建提示
3. 发送给CLI代理执行（支持OpenCode、Claude、Aider等）
4. 独立验证结果
5. 验证失败时进入修复循环
6. 只有通过验证的任务才能被勾选

这种设计防止了"假完成"——代理声称完成但实际未达标的情况。

rundown不绑定特定AI工具，而是通过标准CLI接口与任何代理工具集成。这种设计让团队可以根据场景选择最合适的工具，而不被锁定在单一平台。

每个仓库通过.rundown/目录定义本地工作流模板：

• execute.md：执行提示模板
• verify.md：验证提示模板
• repair.md：修复提示模板
• plan.md：规划提示模板
• trace.md：追踪和审计模板

这种模板化让不同项目可以定义适合自己领域的工作流规范，同时保持一致的执行框架。