[Workflow] 自定义工作流需要支持结果驱动的条件跳转与自动重入

功能描述

希望 Trellis 为自定义工作流提供一套机器可读的步骤结果与状态转换契约。

当前工作流可以描述阶段、Skill/Agent 路由和 workflow-state 提示，但某些步骤返回的并不是最终成功或失败，而是“当前证据不足，但存在一个仍在任务范围内、无需新增授权、可以继续执行的下一动作”。此时工作流不应默认停止并把任务交还用户。

通用场景

1. 实现阶段已经完成。
2. 验证步骤因为缺少一项运行时证据，暂时无法形成最终结论。
3. 补充验证所需的能力当前可用，仍属于原任务范围，也不需要新的用户授权。
4. 工作流却把非 PASS 结论视为终态并停止，而不是继续执行验证并重新进入验收。

这并不局限于某类项目，UI 验证、集成测试、部署检查、性能测量等需要补充证据的步骤都可能遇到。

期望行为

步骤结果应至少能区分：

• 已满足完成条件，可以结束；
• 需要继续执行某项验证或操作；
• 已确认存在实现缺陷，需要返回修复；
• 确实需要用户输入、新增授权或范围调整；
• 依赖外部负责人或外部状态，只能等待或移交。

示意结果如下，具体字段名可以讨论：

verdict: inconclusive
next_action: resume_execution
capability: runtime_validation
requires_user_input: false
scope_change: false

自定义工作流可以将该结果声明式映射到下一步骤，并在执行后重新进入验证：

transitions:
  - when:
      next_action: resume_execution
      requires_user_input: false
    dispatch: runtime_validation
    reenter: verification

为什么仅靠提示词路由不够

自然语言工作流可以建议下一动作，但它仍是 advisory 的。Agent 可能把非成功结论理解为停止条件。

工作流需要明确分离三个概念：

• verdict：当前验证者能够确认到什么程度；
• transition：下一步应该执行什么；
• authority：是否可以在无需再次询问用户的情况下继续。

这样可以减少不必要的中断，并让自定义工作流在不同平台上的行为更稳定。

建议验收条件

1. 提供稳定、机器可读的步骤结果契约。
2. 自定义工作流支持基于结果的条件跳转。
3. 跳转目标可以是步骤、Skill、Agent 或能力标识。
4. 跳转结果及尝试次数可以跨轮次或会话持久化。
5. 补充执行完成后可以自动重新进入验证。
6. 提供最大尝试次数或循环检测，避免无限重试。
7. 只有在确实需要用户输入、新授权或范围扩张时才要求用户介入。
8. 切换或安装工作流时，能够校验所有目标平台是否具备相应的执行入口。
9. 增加端到端测试，至少覆盖：
   • 缺少证据，但下一动作可直接执行；
   • 已确认实现缺陷，需要返回修复；
   • 缺少用户授权；
   • 依赖外部负责人或外部状态。

与 0.7 自定义 Workflow 的关系

如果 0.7 计划中的自定义 Workflow 已经包含“持久化条件跳转、自动派发、执行后重入”的完整语义，希望能明确相关契约和示例；这种情况下可能只需要补充文档和端到端测试。

如果自定义能力主要解决工作流定义、模板选择或提示词注入，那么仍然需要一个运行时转换契约，才能真正闭环。

考虑过的替代方案

只在 workflow 提示词中约定

实现简单，但无法保证可执行的非终态结果一定会被继续处理。

每个检查或验证 Skill 自定义结果格式

局部可用，但工作流和不同平台无法稳定、统一地消费结果。

所有 inconclusive 都要求用户介入

比较保守，但当下一动作已经获得授权、仍在范围内且能够执行时，会产生不必要的中断。

希望确认的问题

1. 结果驱动的状态转换是否已属于 0.7 自定义 Workflow 的规划范围？
2. 统一结果契约更适合属于工作流引擎、任务状态，还是步骤定义？
3. 对无法强制自动派发的平台，是否应该降级为 advisory，并明确报告该平台的能力边界？