Launch（交付发射）

Launch（交付发射） 是做什么的？

Launch 是 Shipyard 的交付发射流程：从任务简报出发，到交付并验证的变更。它建立在可验证性边界之上——代理持续运行所有可重复且可通过证据接受的任务；人类决定哪些无法由系统判断或失败代价高昂的事务。 目标不是最大化自动化——而是将可验证的工作最大程度地委派出去，从而将人类的时间仅花在只有人类才能做出的决策上。

适用于每一步的可验证性测试：如果这一步做错了，系统能检测到吗？能自动重做或回滚吗？ 两个都“是”→ 代理。没有唯一答案、系统无法判断、或者做错代价高昂 → 人类。

Launch 假定 Shipyard 存在——并且在它不存在时拒绝运行。船厂大门是每次调用的第一个动作，在文档语言解析之前，在读取任何提供的规格之前：

• 运行完整的 drydock --check 审计——缺失的表面、缺失或无效的 CONTEXT.md 前言字段 documentLanguage、死路径、代码中未使用的术语、从未被引用的标准。这是单一标准：Launch 不执行自己的单独设施清单。
• 可操作/高置信度的发现硬性阻止运行： 逐字列出每个这样的发现，指向 /oh-my-claudecode:drydock，说明运行从未开始且未产生任何工件，然后停止。没有明确覆盖的情况下，将任何发现视为阻塞。
• 狭窄覆盖（仅限明确意图）： 低置信度的发现、被 drydock 报告明确分类为误报的发现、或者用户明确声明的临时/废弃仓库，只有在每个调用中提供明确且故意的用户意图时才能被覆盖——覆盖必须命名具体的发现或废弃范围，且绝不能静默吞掉高置信度的可操作发现。没有通用绕过标志。
• 当前审计限制： 目前 --check 是一个技能指令清单，没有机器可读的发现/严重性契约或可执行文件——严重性分类依赖于 drydock 报告的措辞，直到结构化契约存在。机器可读的发现/严重性退出契约是预期的后续工作；大门措辞诚实地说明了它目前可以机械依赖和不能依赖的内容。
• 干净的审计（或明确覆盖的低置信度/误报/废弃范围）允许运行。 此时，每个纸迹槽（CONTEXT.md、docs/adr/、docs/business/）和设施表面都已存在；Launch 在决策确定时填充纸迹，但从不创建这些槽。
• 规则入口是 CLAUDE.md——Shipyard 地图不认可任何替代。

边界

人类检查点（关键的 20%）	代理持续运行（机械性的 80%）
C1 撰写任务简报（目标 + 范围）	事实发现和仓库探索，自助服务
C2 批准验收标准 + 测试接缝列表	面试准备：前沿问题批量整理并附带推荐答案
C3 批准任务分解（粒度、阻塞边缘）	规格和任务草稿，机械验证（独立性、可演示性、适合单一上下文）
C4 回答运行中出现的不可逆决策（批量、异步）	在约定的接缝处进行 TDD 实现、构建、测试、回归
C5 接受完成报告；通过开放假设和逐行沉淀列表行使否决权	代码审查、跨变更验证、团队前沿调度、整个纸迹

在检查点之间，管道从不空闲：代理继续处理每个不依赖于待定人类答案的前沿任务。

生命周期姿态

Launch 是一个对 OMC 现有生命周期的无状态编排——它不拥有运行时状态机：

• 团队拥有任务状态、转换、取消和运行时清理；Launch 从不在此之外变更它们。
• 规范的 plan → execute → review → verify 表面拥有其现有的生命周期行为。Launch 创作的工件仅限于 .omc/specs/<feature-slug>/、CONTEXT.md、docs/adr/ 和 docs/business/——此外，仅在 C5 批准后，还包括 Phase 5 表中命名的沉淀槽。
• Launch 没有自动恢复。中断后，重新读取工件和当前团队状态，但只能通过在新的显式 Launch 调用后继续，前提是所属团队生命周期已达到支持的中断/清理边界。切勿推断人类批准或重放 in_progress 任务。
• 模糊的任务属于导航员的管辖范围：当雾门路由到 /oh-my-claudecode:ask-navigator 时，运行从未开始——没有工件，没有部分状态。导航员的地图是跨会话的唯一载体；Launch 仅从它交回的任务简报中恢复。
• Launch 不添加自己的批准回执、修订计数器、重放日志、取消路径、回滚机制或清理生命周期。

此技能中的任何耐久性声明都是关于磁盘上文件的声明，而不是关于隐藏运行时的声明。

Phase 0 — 入口

运行只有在通过干净的船厂大门后才能到达此阶段。在读取提供的规格或进入 Phase 1 之前，解析文档语言。当前调用中的显式人类选择优先；否则从 CONTEXT.md 前言中读取一个有效的 BCP-47 风格标签，位于精确的稳定键 documentLanguage；否则要求从 CLAUDE.md 然后 README.md 中获得一致的高置信度推断。持久化的裸地区或仅地区中文标签是脚本歧义的，必须在该权威层级询问一次，绝不能通过推断绕过。缺失、混合、冲突、低置信度、无效显式或脚本歧义的中文证据要求提出一个批量语言问题；不要猜测。中文必须解析为显式的 zh-Hans 或 zh-Hant 脚本标签。zh-Hans-* 选择简体中文配套文件，zh-Hant-* 选择繁体中文配套文件，同时持久化完整的规范化标签。在创建任何 Launch 创作的工件之前，将解析后的规范化标签持久化回 CONTEXT.md，以便新的显式调用可以在没有隐藏对话状态的情况下读取它。人类读取和维护这些工件；代理是语言中立的。

仅本地化散文和面向人类的标签/可本地化的标量值。路径、斜杠命令、标志、代码围栏、占位符、前言键和机器语义值、YAML/JSON 键、生命周期令牌（plan、execute、review、verify）、状态枚举（pending、in_progress、completed、failed、ready-for-agent）、ID、任务 blockedBy、公共团队 blocked_by 以及所有解析器/控制令牌保持字节对字节稳定。参考语言配套文件是互斥的：只发出一个选定的渲染，绝不生成双语重复的标题或标签。

• 在进行任何其他操作之前快速自检：简报是否命名了目标、范围边界和非目标？如果缺少两个或更多，则说明这一点并要求进行一次精化——在软简报上运行管道会将歧义转化为看起来自信的输出。
• 雾门：在精化之后，应用导航员的雾测试——Q1：能否用一句话陈述目的地（此任务正在寻找的规格、决策或变更）？Q2：能否现在就精确陈述前三个决策，尽管它们目前都无法回答？任一答案为否 → 运行绝不开始：明确说明这一点，指出未产生任何工件，推荐 /oh-my-claudecode:ask-navigator（Shipyard 的导航员将雾视为决策任务地图并交回任务简报），然后停止。移交剩余问题和已确定的词汇，以便导航员的 W1 不重新询问它们。
• 地图检查：在读取提供的规格或进入 Phase 1 之前，查找一个开放的 navigator:map（跟踪器标签，或在 .omc/wayfinder/ 下）。如果存在且此调用未提供新的简报 → 推荐 /oh-my-claudecode:ask-navigator 来处理该地图上的下一个决策，然后停止。如果存在且提供了新的简报 → 提出一个问题——是继续开放的地图，还是开始新的任务——然后再继续。
• 如果提供了规格路径 → 读取它，跳转到 Phase 2。
• 如果提供了任务简报 → 进入 Phase 1。
• 如果是单点修复 → 移交给执行，退出。

Phase 1 — 收敛（人类决定，代理准备）

使用决策树协议运行面试：绘制决策及其依赖关系，然后以前沿轮次工作——将当前每个可问的问题分批到一个轮次，编号，每个附带一个推荐答案。人类回答；树形结构调整；重新计算前沿。事实始终由子代理从仓库证据中自助获取——人类只被询问任何探索都无法解决的事项。

纸迹，在每项确定时写入：

• 领域词汇 → 仓库根目录下的 CONTEXT.md（每个术语一个条目）
• 通过 ADR 测试的决策（难以逆转、没有上下文令人惊讶、存在真实权衡） → docs/adr/NNNN-<slug>.md
• 收敛过程中发现的业务规则和背景 → docs/business/（每个业务问题一篇文章，开头段落说明其重要性）

此处不收敛是正常的工作，不是失败：如果前沿不能清空，则对剩余问题排名——这是 C2 的输入，而不是错误。如果剩余问题本身无法精确陈述（雾测试 Q2 失败），则目的地本身不确定，这超出了 C2 的权限：停止，记录已确定的内容（CONTEXT.md 中的词汇、已回答的问题），推荐 /oh-my-claudecode:ask-navigator，然后退出——管道从不发明目的地。

Loft 绕行。 一个精确但无法在散文中解决——它需要被看到或点击，而不是被描述（UI 应该是什么样子，状态模型感觉是否正确）——的剩余问题，用工件而不是更多的问题来回答：调用带有“loft”的 Skill 工具，让负责人做出反应，并将该反应反馈到面试中。设计的工件是 C2 的输入；负责人签署他们看到的，而不是被告知的。

Harbor 简报。 由 /oh-my-claudecode:harbor 移交的任务简报携带已签署的决策及其链接和适用条件：将它们视为已做出的——不要重新询问未更改的业务目标。如果自证据收集以来代码已移动（新头、更改的基准），则重新验证受影响的技术证据；超出已签署简报的新实现范围仍需要其自己的批准。

Phase 2 — 规格合成（代理起草 → C2 批准）

合成 .omc/specs/<feature-slug>/spec.md：

# <Feature> 规格
## 问题
## 解决方案
## 用户故事        （编号，每个带有可测试的验收标准）
## 实现决策
## 测试决策   （仅外部行为）
## 超出范围

起草所有内容，然后在 C2 停止：展示验收标准和测试接缝列表以供人类审批。接缝根据仓库证据和深层模块纪律（公共接口、现有测试接缝、深度分析）选择；人类确认或更正列表——人类未批准的接缝不进行测试。

耐久性门（代理强制执行，无需审批）：规格和任务携带契约，绝不携带坐标——没有文件路径，没有行号。比散文更好地编码决策的片段（状态机、reducers、schemas）是例外，并说明其来源（通常是 loft）。

Phase 3 — 任务分解（代理起草 → C3 批准）

在 .omc/specs/<feature-slug>/tickets/ 下拆分为垂直切片：

• NN-slug.md，每个任务一个文件，按依赖顺序排列，每个声明 blockedBy: [ids]
• 每个任务跨越每个层，可独立演示，并且适合单个新上下文
• 宽泛的重构采用展开-收缩模式：添加新形式，分批迁移，移除旧形式——每批一个任务

代理端的机械验证首先进行（独立性、可演示性、上下文适配）。然后 C3：展示粒度、阻塞边缘以及建议的合并/拆分以供人类审批。迭代直至批准。将每个任务标记为 ready-for-agent。

集成连线规则：每个垂直切片包括其自己的连线和冒烟断言——输出没有被挂载、服务或导入的切片不算完成。没有单个切片拥有的跨切片接缝（路由挂载、静态服务、入口点连线）会得到一个显式的集成任务作为最后一个前沿项。

Phase 4 — 运行前沿

前沿是所有其阻塞项均已完成的任务。

并行（默认，2+ 个任务）。 将任务交给团队：每个任务变成一个团队任务，blockedBy 边继承——团队的声明机制只选择前沿任务。生成 N 个工作节点。每个工作节点使用在 C2 中批准的接缝处的 TDD 纪律进行实现，应用 /oh-my-claudecode:minimal-code-discipline 作为编写时纪律（它是可选的）；一个任务仅在代码审查通过差异、由审查者声明后关闭——实现者从不自我批准。

串行（单个任务，或 --serial）。 一次将一个任务委派给执行子代理；相同的审查门。

双轴审查门。 关闭审查沿着两个轴并行运行，分别报告——绝不能合并或交叉排名，因为一个变更可以通过一个轴但失败另一个轴（符合标准但行为错误；忠实但违反惯例）。审查者当任一轴失败时使任务失败：

• 标准轴 — 差异与匹配的 docs/standards/ 卷进行比较，再加上仅判断调用的气味基线（已记录的仓库标准覆盖基线；工具已强制执行的任何内容被跳过）。这是保持标准表面被引用的常驻消费者。
• 规格轴 — 差异与此任务的验收标准进行比较（规格是任务从中分解的总账；仅为了追踪标准的来源并裁决走私的范围——未在任何任务中的行为是走私的并且被拒绝）。

集成任务。 一个包含集成烟雾的最终任务，由审查者验证。

Phase 5 — 发布（C5 闸门）

发布人是 C5。他们收到完成报告并行使对开放假设和纸迹驳回的权利。这标志着管道的结束。

Launch 将以下工件写入磁盘：

• 任务状态（通过团队）
• 纸迹
• 仅当批准时，沉淀槽：每个任务一个文件在 .omc/sediment/ 下，包含关于未来的陈述，例如“如果 X 改变，检查 Y”。