ub-workflow

UB 工作流

概述

当工作规模过大、风险过高、涉及范围过广或具有状态依赖性，无法仅靠聊天记录来执行时，请将此技能用作可移植的工作流层。

默认操作根目录为 ./.ub-workflows/，除非宿主有意选择其他根目录。

规范化模型采用产品敏捷混合模式：

Product Vision -> Product Options -> Outcome Waves -> Initiatives -> Discoveries -> Sprints

该模型结合了：

1. 双轨敏捷：交付工作开始前，先通过探索验证各种选项；
2. 目标导向的路线规划：产品愿景保持宽泛，同时由阶段和举措承载当前成果；
3. 类 Scrum 的冲刺执行：一个冲刺目标、检查与调整，以及在启用审核模式时明确的启动批准；
4. 看板式流动控制：明确的策略、WIP 限制、承诺前选项、反馈循环，以及对过时候选项的重新验证；
5. Shape Up 的理念：轻量级的押注框定、工作量预估、熔断机制，以及避免积压工作淤积；
6. 基于工作量预估的预测校准：候选项数量属于预测；若要扩大范围，操作员须在查看范围明确的选项和权衡后作出选择。

标准布局

PROJECT_ROOT/
  AGENTS.md
  SOURCE_ATLAS.md
  .ub-workflows/
    AGENTS.md
    vision.md
    options.md
    status.md
    WORKFLOW_ATLAS.md
    SOURCE_PACK_ATLAS.md
    source-packs/
      .gitkeep
      YYYY-MM-DD-slug/
    waves/
      .gitkeep
      wNN-wave-slug/
        wave.md
        discoveries/
          .gitkeep
          wNN-dNN-slug.md
        source-packs/
          .gitkeep
          YYYY-MM-DD-slug/
        initiatives/
          .gitkeep
          iNN-initiative-slug/
            initiative.md
            options.md
            roadmap.md
            index.md
            discoveries/
              .gitkeep
              wNN-iNN-dNN-slug.md
            sprints/
              .gitkeep
              wNN-iNN-sNN-sprint-slug/
                sprint.md
                decision-log.md
                closeout.md
                evidence/
                  .gitignore
                  index.md

命名规则：

1. 阶段 ID 按项目顺序递增：w01、w02 等；
2. 举措 ID 在每个阶段内重置：i01、i02 等；
3. 阶段级探索使用 wNN-dNN-slug.md，并在每个阶段内重置；
4. 举措级探索使用 wNN-iNN-dNN-slug.md，并在每个举措内重置；
5. 冲刺使用 wNN-iNN-sNN-sprint-slug/，并在每个举措内重置；
6. 来源包使用 YYYY-MM-DD-slug/，日期取创建日期、原始研究日期、已知最早历史日期或迁移日期，并附注说明。

工作泳道

选择一条泳道，使已接受的目标能够完成、通过验证并可恢复，同时不扩展到无关工作：

1. 直接的限定范围工作：可在单次会话中完成的小型变更，无需持久化的规划材料；
2. 阶段／举措工作流：跨多个会话、分阶段、高风险、塑造产品方向或涉及多方面的工作，需要选项看板、探索、路线图、冲刺、收尾和可恢复的证据。

当当前泳道无法提供足够的持久化材料来完成并证明已接受的目标时，升级工作泳道。 在现在负责该工作的材料中记录升级原因。

内嵌契约

1. 将可复用的工作流规则保留在此技能中，而不是放在某个仓库覆盖层里。
2. 仓库覆盖层应保持精简：项目事实、当前指针、本地验证命令、领域边界和仓库专属约束。
3. vision.md 负责维护可调整的产品北极星。
4. 根目录 options.md 负责在承诺前整理产品级、未来波次和责任人未知的选项。它不是待办事项账本、完成历史记录或执行授权入口。
5. status.md 负责维护当前产品态势、波次排序、活动指针、阻塞项、WIP 状态、候选轨道、保留上下文的路由，以及下一步允许采取的行动。
6. SOURCE_ATLAS.md 负责项目根目录的源码路由。初始化时通过一次性扫描生成；之后仅在源码边界发生变化时按事件更新。
7. 根目录 AGENTS.md 负责本地 Agent 覆盖层。初始化只创建或修改一个精简的托管工作流路由部分。
8. 工作流根目录指南、拆分的产品／实时状态启动文件，以及根目录规格轨道，都不是规范的工作流载体。
9. Outcome 波次是可调整的产品切片，可通过经过审查的探索进行拆分、合并、扩展或缩减。
10. Initiative 是波次内按主题划分的押注；可以暂停后恢复。
11. Initiative 本地的 options.md 负责记录该 Initiative 关闭前可能加入的事项。产品级或后续波次选项应移至根目录 options.md。
12. 探索是正常的上游路线调整工作，不是例外流程。
13. 探索和 Sprint 预览应将用户或运营人员证据状态记录为 used、not triggered 或 deferred，确保技术工作仍说明决策是否受真实用户或运营人员反馈影响。
14. Sprint 是从已接受的探索或经过审查的 Sprint 预览中选取的交付切片。
15. 默认 WIP 采用受限的双轨模式：每个活动 Initiative 有一个进行中的交付 Sprint 和一个进行中的探索；仅在激活、过渡或重新路由时进行波次探索。
16. 未来工作在承诺前可放在根目录或 Initiative 本地的选项看板上。选项按各时限轨道中的文档顺序排列，但不是交付承诺、状态账本或执行队列。
17. 选项得到提升、否决、合并或完成，且接收工件已保存持久记录后，应将其移除。不要在选项看板中维护 Done 轨道。
18. 激活新波次或 Initiative 前，应审查根目录选项，以及即将关闭的 Initiative 中未解决的本地选项。
19. 关闭 Initiative 前，应提升、迁移、否决或移除每个本地选项。不要在选项看板本身归档已完成事项。
20. 在波次或 Initiative 过渡、选项提升、Initiative 收尾、终审，以及从选项提取 Sprint 预览时，运行选项验证。
21. 影响工件归属、生命周期关卡、脚手架输出、过渡策略或恢复上下文的可复用工作流系统变更，必须通过精简的工作流改进探索或等效的已接受决策记录。
22. 候选项在使用时重新验证：任何并非基于当前证据准备的候选项，在执行前都必须经过新的探索或预览。有会改变路线的不确定性时使用探索；只有在对已登记候选项重新验证并准备启动时，才使用经过审查的预览。
23. Discovery Triage 是失败即关闭的路由预检，不是预览附录。选择经过审查的预览前，应记录触发类别和以下一种结果：preview_ok、discovery_required、operator_decision_needed 或 not_triggered。触发类别包括自主性、权限、运行时边界、策略、证据、互操作性、Agent 行为变更、Agent 循环、harness、循环续接、目标判断、预算和检查点。如果触发证据可能改变路线、契约、范围、验证方式、运行时边界或实现路径，应记录 discovery_required；只有在路线已确定且触发证据无法改变这些决策时，preview_ok 才有效。仅在有具体理由时使用 not_triggered。
24. 由探索驱动的顺序变更必须在接受前写入所属的 roadmap.md；由收尾驱动的下一步路线变更必须在 Sprint 收尾前写入。
25. 触发时，Sprint 预览应标明仓库负责的运营界面：所有者、生命周期、可见性、安全策略、验证路径，以及对清单／拓扑／注册表／路线图的影响。如果对这些事实的不确定性可能改变范围、架构、风险或验收标准，应在执行前转为探索。
26. 每个波次和 Initiative 都应记录定性的 Outcome Signals，涵盖产品或用户价值、交付流程、质量或稳定性，以及上下文或证据成本。这些是路由信号，不是指标账本。
27. 每个 Initiative 和 Sprint 都应轻量记录押注框架：投入意愿、成功证据、熔断条件、非目标和延期路径。
28. 波次和 Initiative 默认采用 Appetite-Boxed 预测：预测数量不是承诺，扩大顺序不等于自动调整，增加工作需要 Agent 提出选项、权衡和建议路径，交由运营人员明确决策。
29. 波次和 Initiative 章程应记录 Forecast And Appetite；路线图应记录 Forecast Control；当探索和经过审查的预览改变顺序时，应记录 Forecast Impact。
30. Sprint 预览应将 Product Increment Contribution 记录为 direct、enabling 或 audit；enabling Sprint 必须说明它解锁的可见增量，以及为何无法采用直接切片。
31. 连续两个 enabling Sprint 或前置 Sprint 会触发路线审查：提出交付纵向验证、削减／延期范围、重新路由，或明确投入更多 enabling 工作。
32. 主要能力候选项在接受前，应拆解其前置风险和首个可用产品增量。
33. 在经过审查的模式中，收到继续推进的请求时，只开启预览；只有之后再次获得明确批准，才开始执行。
34. 新建的 Sprint 包应包含 decision-log.md、closeout.md 和 evidence/index.md。
35. evidence/index.md 是 T4 级声明到证明的路由器。它记录已验证声明、证据文件、必需的客观关卡、可选或未触发的关卡、脱敏状态、提升目标和读取策略，但不应成为叙述式收尾文档。
36. Sprint 证据目录下生成的运行时状态（包括任何项目专属临时目录）默认是本地临时数据。仅提交经过审查且不含机密的证据文件，或明确获批的导出文件。
37. Sprint 收尾必须包含结果和经验教训审查，并回答四个问题：本次 Sprint 达成了什么？它如何改善项目？哪些方面本可以做得更好？这些经验是否会改变下一步路线、仅保留在本地，或提示需要改进工作流？
38. Sprint 收尾应记录 Forecast Delta：计划与实际情况、发现的隐藏前置条件、剩余预测影响，以及是否更新了路线图、索引或状态。
39. 重要的收尾声明必须有 evidence/index.md 支持。关闭原目标并将其标记为通过时，不得延期必需的客观证明；如果必需证明缺失或未通过，Sprint 必须保持活动或阻塞状态，直到运营人员明确更改范围或证明通过。
40. Sprint 收尾应包含有针对性的迷你回顾：流程阻力、证据成本、上下文成本、决策延迟、必要时的工作流调整，以及涵盖目标信号、可控性和重复阻力的回顾证据检查。
41. 重复出现或结构性的工作流阻力应提升并纳入此技能；一次性的仓库阻力留在本地处理。
42. 除非主机记录了经过审查且保持兼容性的决策，否则项目演进模式默认为 forward-only。
43. 当当前演进模式要求向前迁移时，广泛的边界变更必须包含影响清单，并在收尾前更新、移除或明确延期每个受影响的自有界面。
44. 源码包是保留上下文，不是执行授权、实时状态或待办事项。
45. Trace token 是仅供所有者使用的查询锚点。应先使用触发的 T3 Initiative index.md trace 路由，再进行广泛的工作流搜索；不要将 trace token 添加到探索、Sprint 包、收尾文档、决策日志或证据索引中。

交互模式

1. reviewed 是默认模式：执行前预览，之后明确批准启动，执行后报告，并在收尾后暂停。
2. flow：执行前简短说明，执行后报告，手动推进。
3. auto：内部进行执行前分析，除非遇到阻碍、冲突或需要中断来确定路径的决策，否则自动推进。
4. continuous / yolo：不进行常规暂停，但仍遵循所有关卡、产物和中断规则。

模式会改变可见性和暂停行为，但不会降低就绪度、证据或回写要求。

目标完成规则

选择能完成目标的行动：实现并验证达成已接受的迭代目标和退出标准所需的全部工作。避免无关扩展，但不要仅仅为了控制范围或预算而删减、推迟或拆分必要的证明工作。

当迭代、预览或收尾中出现 smallest、narrow 或 only as needed 等措辞时，应将其理解为能完成目标的最小纵向切片，而不是仅能通过首个专项测试的最小补丁。除非操作人员明确更改目标，否则，迭代范围中列出的每个受影响且由仓库负责的部分、每个必要的证据关卡，以及每项退出标准，都仍在范围之内。

按触发条件加载参考资料

• [phase:lifecycle-detail] 阅读 references/workflow-contract.md，了解详细的操作规则、WIP 政策、reviewed 模式预览和恢复流程。
• [phase:artifact-create|artifact-validate] 创建或验证工作流产物时，阅读 references/artifact-contracts.md。
• [edge:context-management|frontmatter|context-budget] 解读 context_tier、summary_budget_lines、阶段读取预算、atlas 路由、上下文回执、保留上下文读取或证据／回写回执结构时，阅读 references/context-management.md。
• [edge:trace-token|trace-lookup|workflow-search] 搜索工作流历史、解读 trace ID 或标签、添加 trace 元数据，或决定 trace 锚点应放置的位置时，阅读 references/trace-tokens.md。
• [phase:gate-eval|closeout|readiness] 评估就绪度、收尾、归档或完成情况时，阅读 references/validation-and-completion.md。
• [edge:helper-use] 使用或说明确定性辅助工具之前，阅读 references/scaffold-helper.md。
• [edge:strict-placeholder-validation|options-validation] 涉及严格占位符验证时，阅读 references/placeholder-contract.md。涉及选项看板验证、转换检查或收尾检查时，阅读 references/validation-and-completion.md。
• [edge:governance-escalation] 仅在启用显式治理映射时，阅读 references/governance-bridge.md。
• [edge:authoring-conventions] 更改共享路由、命名或选择题编写方式时，阅读 ../ub-authoring/references/authoring-conventions.md。

捆绑资源

使用 assets/operations-root/ 和 assets/initiative-template/ 作为规范模板。使用 scripts/scaffold_workflow.py 执行确定性的引导、波次、计划、探索、来源包、迭代和归档操作。使用 scripts/check_workflow_options.py 验证选项看板转换、收尾、终态审计和过期卡片。

输出要求

对于非简单的工作流任务，报告：

1. 通道和规模决策；
2. 当前产物负责人；
3. WIP 和关卡状态；
4. 选定的路径，以及路径选择相关时被否决的替代方案；
5. 验证和证据预期；
6. 下一项允许的操作。