collaborative-delivery

协作交付

选择模型前先选择分支。在当前协调器中选择任务和面板角色。开始面板角色前，使用 shared/references/model-preview.md 绑定一个经批准的路由快照。

模型 ID、工作量支持和任务默认值仅来自 shared/model-routing.json。在调度、重试和恢复期间保留经批准的快照。

仅在已有经批准的任务计划且需要面板审计轨迹时使用此流程。它的成本有意高于常规实现路径。选择此技能后，面板为必需项。

开始前请阅读 shared/collaborative-panel-runner.md 和 shared/references/host-model-execution.md。这些文件定义了面板运行器、实际参与规则、状态分类、完成检查、原生委派和会话规则。assets/routing.toml 是面向一个宿主的可编辑默认配置。使用 shared/references/task-shaped-model-routing.md 在经批准的快照中绑定所选角色。向用户展示准确的模型、执行路径、工作量和验证策略。配置的模型标签不等于实际服务模型凭据。

结果

交付一项任务，并记录红、绿、重构、审查、验证和交接轨迹。只有在所需角色都给出实际记录的响应后，阶段才算完成。生成的提示词不算参与。

工作流

1. 选择一项任务，并重述其验收约定、预期文件和最精简的验证命令。在任何角色开始前，根据快照上限记录计划中的阶段调用和并发情况。
2. 按顺序运行各阶段：task_intake、red、green、refactor、review、verification 和 handoff。在这些阶段中，为每项任务和角色保留独立上下文。实现者、审查者、综合者和对抗角色不得共用上下文。
3. 每个阶段都包含综合和对抗锚点。已配置的专家角色各自提供独立响应。仅当当前切片涉及相应界面时，才将 backend 或 interface 添加为阶段角色。
4. 在 red 阶段添加或更新失败测试，并记录预期失败。在 green 阶段进行能使测试通过的最小更改。在 refactor 阶段，仅在测试持续通过的前提下进行简化。
5. 在 review 阶段检查正确性、数据和安全风险、可维护性以及与任务的契合度。在 verification 阶段记录命令、结果、跳过的检查及其原因。
6. 在 handoff 阶段记录更改的文件、行为、证据、决策、局限和下一项任务。

对于宿主当前支持的准确模型，请使用持久化的原生子 Agent 或受支持的任务上下文。仅当模型来自其他平台，或宿主无法提供准确路由时，才使用运行器。代码更改由宿主负责。除非路由明确委派实现角色，否则面板角色负责质疑、审查并参与决策。将异议保留在决策日志中。缺少角色会阻止面板完整；只有用户明确接受时，才将该缺失作为已接受的例外报告。

产物

除非用户选择其他位置，否则将以下文件写入 .ai-workflow/panel/delivery：

1. execution_log.md
2. test_evidence.md
3. review_notes.md
4. changed_files.md
5. decision_log.md
6. panel_summary.json

在解读面板状态或完成最终整理前，请阅读 references/output_contract.md。在更改路由或可移植性边界前，请阅读 references/workflow_contract.md。