实际评估waveforge时，我先确认它解决的具体问题：用于多模型 AI 开发的依赖性感知项目分解和经过验证的规划工作空间。把它放到软件开发流程中，最容易暴露的是依赖、接口和异常处理往往比主路径更影响采用，不能只看演示是否顺利。短测时我会在隔离分支完成一个可回滚的小任务，并保留安装步骤、接口契约、测试结果和错误信息的结果，方便团队复盘。我会把它列入需要可检查开发流程而非单次演示的工程师的候选清单，而不是仅凭项目介绍直接纳入生产。

名称： 波弗格 描述：将广泛的项目计划转变为可配置的工作流、依赖波、任务计划以及可编辑的模型路由和所有权记录。在准备跨模型或存储库协调执行的计划时使用；不要用于普通的单任务编码。

waveforge

将用户的源计划转变为便携式计划工作区。保存 来源、其要求以及未解决的选择。生成的工作空间 用于计划和协调；它不会启动代理、批准工作或 发布更改。

制定计划

1. 阅读完整的源计划和任何管理存储库说明。 在创建副本之前检查现有任务或里程碑文档。 对于非文本源，提取 UTF-8 Markdown 工作副本并保留 参考原始文件。 选择现有项目源之外的新输出目录，除非 用户指定了一个位置。不要覆盖现有的规划工作区。
2. 在分解之前阅读用户提供的任何分割规则。如果提供的话， 使用 拆分配置 并尊重其边界和限制。否则，决定工作流程， 计划本身的波浪和任务规模；不强制规定固定数量 计划或任务。按连贯的结果或工作流程划分，而不仅仅是按 源标题。 为每个工作流提供自己的目标、范围、验证、证据和波次。 按依赖关系对wave进行排序；使每项任务成为有限制的、可审查的变更。 包括验收标准、验证步骤、预期证据以及 每个任务的源参考。标记推断工作和未解决的工作 明确的决定。维护安全、许可和发布大门。
3. 根据用户的输入确定模型路由模式。如果用户提供 任务的模型和工作量，保留手动选择。如果用户 仅提供型号目录或委托路由，选择合适的型号 并分别为每个未分配的任务付出努力，优先选择最低的 满足其要求的合理路线。一个项目可能会混合手动和计划 路线。使用目标环境中实际可用的模型并放置 他们的确切 IDs 并支持可编辑模型目录中的工作。检查 针对该目录的每条路线；标记不可用或不受支持的手册 选择而不是默默地取代它。如果不清楚是否有空位，请询问 在完成可执行路径之前获取目录。永远不要发明可调用的 在没有证据的情况下建立模型或声称成本估算。预留更强的航线 用于证明其合理性的任务或明显升级的任务。
4. 创建以下 YAML 分解清单 清单和输出合同。运行 scripts/build_plan_workspace.py 带有源计划、清单、可选 拆分配置和新的输出路径。清单是一个计划 由来源撰写，并非自动推断的替代品 工程判断。
5. 在生成的工作区上运行 scripts/validate_plan_workspace.py。评论 任务排序、可追溯性、验收覆盖率、模型选择和开放 与来源相反的决定。更正清单并重新生成 如果需要进行结构更改，则需要更新目录；保留任何活体 现有工作区的所有权或证据记录。

所有权和执行边界

生成的configuration/文件夹保存着可编辑的分割规则， 清单、模型目录、每任务模型策略、任务寄存器、所有权协议和 未签名的 CSV 签字表。 CSV 是一个电子表格可读的工作表。工人可能 仅记录其实际执行的工作的索赔或完成情况；从不 预填充签名、时间戳、测试结果或提交 IDs。一名有姓名的工人 一次拥有一项任务。协调器检查依赖关系和重叠 文件范围、记录索赔并整合结果。指定的模型在 该策略是计划的路线，而不是改变源的声明或许可。

验证器需要 READY、IN_PROGRESS 和 IN_PROGRESS 的完整依赖关系 DONE，匹配正在进行的任务的主动声明，并有效完成 具有已完成任务证据的事件。账本事件使用非递减的 UTC 次； 交接和阻止释放声明，完成则结束任务。 可识别的本地证据文件必须存在、非空且保留在内部 工作区。注释和外部链接仍然受支持，无需内容或 网络验证。查看 任务状态、所有权和证据 记录或验证执行状态时。

不要默默地扩展源计划或将计划指令变成 实施。保持该技能领域中立：项目特定的限制 属于生成的计划，而不属于该技能。尊重用户现有的 稍后执行工作区时的批准和工具边界。

这些脚本需要 Python 3.10+ 和 PyYAML。他们只阅读提供的 source/manifest 并写入新的输出目录。他们不称呼模特， 网络服务或项目工具。

初始规划的模型偏好

更喜欢 Astra 起草输入计划和 waveforge 的第 当可用且用户拥有时进行分解和架构审查 没有选择其他型号。这是一种质量偏好，而不是要求或 自动模型切换：活动聊天模型不能由此更改 技能。如果 Astra 不可用，请继续使用最合适的可用版本 模型。将实际的源计划和首次分解模型记录在 清单的 project 字段（已知时）；生成的配置使用 unknown 否则。后期任务 实现遵循生成的每任务模型策略；它没有 继承最初的阿斯特拉偏好。