launch

Launch

Launch 是造船厂的交付流程：从任务简报到交付并验证变更。它位于可验证性边界上——**Agent 持续执行所有可重复且可通过证据验收的工作；对于系统无法判断或出错代价高昂的事项，由人类决策。**目标不是实现最高程度的自动化，而是尽可能多地委派可验证的工作，让人类只把时间花在只有人类才能做出的决策上。

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

Launch 假定造船厂已经存在——如果不存在，就拒绝运行。每次调用的首个操作都是检查船坞大门，先于文档语言解析，也先于读取任何提供的规格：

审计报告包含 contractVersion: 2；缺少必备的首日门面时使用 shipyard.yard.unlaid，使用方不得将已弃用的 shipyard.surface.missing.* ID 解读为可选表面缺失。

• 运行完整的船坞 --check 审计——要求具备首日基础门面 CLAUDE.md 和 GLOSSARY.md（在船坞完成迁移前，可接受可识别的旧版术语表 CONTEXT.md）；除此之外，只审计已采用的可选表面，因此缺少可选表面不构成审计发现。审计还会检查缺失或无效的术语表 documentLanguage、无效路径、代码中未使用的术语，以及从未被引用的标准。这是唯一判定标准：Launch 不会自行另行盘点设施。
• **可执行的／高置信度的审计发现会硬性阻止运行：**逐字列出所有此类发现，指向 /oh-my-claudecode:drydock，说明运行从未开始且未生成任何产物，然后停止。除非获得明确覆盖，否则任何审计发现都视为阻塞项。
• **范围严格的覆盖（仅限明确意图）：**只有在用户针对本次调用明确表达意图后，才能覆盖低置信度发现、在 drydock 报告中明确归类为误报的发现，或用户明确声明为临时／一次性仓库的情况——覆盖必须指出具体发现或临时范围，且绝不能悄然忽略高置信度的可执行发现。没有通用绕过标志。
• 当前审计契约（版本 2）：--check 的机械化子集可执行——node scripts/shipyard-audit.mjs [repoRoot] 会输出带版本的 JSON 报告，并检查必备的船坞基础门面、重复的术语表权威来源、缺失／无效的 documentLanguage 标签、CLAUDE.md 中的无效路径、项目技能触发条件和意图状态。缺少可选表面不构成审计发现；在契约版本 2 中，shipyard.surface.missing.* ID 已弃用。退出码 0 = 无问题，1 = 存在高置信度的可执行发现。入口会根据退出码处理：0 允许运行，1 则逐字列出审计发现并阻止运行。启发式类别（代码中未使用的术语、从未被引用的标准）仍由 drydock 的文字审计处理——它们本质上是低置信度的，覆盖规则不变。
• **审计无问题（或明确覆盖了低置信度／误报／临时范围）后，才允许运行。**首日门面必须齐备；docs/adr/ 和 docs/business/ 在首次使用时出现——决策确定后，预留位置便随时可用；如果该位置尚不存在，Launch 会按 drydock 的延迟表面表触发首次使用，并立即将内容沉淀到其中。Launch 会随着决策确定逐步补齐记录链，绝不推测性地创建预留位置。
• 规则入口是 CLAUDE.md——造船厂地图不承认任何替代项。

边界

人工检查点（关键的 20%）	Agent 持续运行（机械化的 80%）
C1 编写任务简报（目标 + 范围）	自行开展事实调查和代码库探索
C2 批准验收标准 + 测试接缝清单	准备访谈：汇总前沿问题并附上建议答案
C3 批准任务分解（粒度、阻塞关系）	编写规格和任务，进行机械化验证（独立性、可演示性、适合单一上下文）
C4 回答运行中出现的不可逆决策（批量处理、异步进行）	在约定的接缝处进行 TDD 实现、构建、测试和回归验证
C5 验收完成报告；通过 Open Assumptions 和逐行沉积清单行使否决权	代码审查、验证整个变更、安排团队前沿任务、维护完整的文档记录

检查点之间，流水线从不空闲：Agent 会持续处理每个不依赖待处理人工答复的前沿任务。

生命周期定位

启动是对 OMC 现有生命周期进行的无状态组合——它不拥有任何运行时状态机：

• 团队负责任务状态、状态转换、取消和运行时清理；Launch 不会在 Team 合同之外修改这些内容。
• 规范的 plan → execute → review → verify 界面负责各自现有的生命周期行为。Launch 编写的工件仅限于 GLOSSARY.md、docs/adr/ 和 docs/business/——此外，只有在 C5 批准后，才可写入 Phase 5 表中指定的沉积槽位。规格及其任务只存在于跟踪器中——规格是父议题，任务是其原生子议题——Launch 绝不会创建或写入本地规格文件或任务文件；下游读取方从跟踪器获取规格和任务，绝不从本地目录树获取。
• Launch 不会自动恢复。中断后，重新读取工件和当前 Team 状态，但只有在所属 Team 生命周期到达受支持的终止/清理边界后，才能通过新的明确 Launch 调用继续。绝不推断人工审批已通过，也绝不重放 in_progress 任务。
• 模糊不清的工作由导航器负责：当迷雾门将流程导向 /oh-my-claudecode:ask-navigator 时，运行尚未开始——没有工件，也没有部分状态。导航器的地图是跨会话传递信息的唯一载体；Launch 只能根据它交回的任务简报恢复。
• Launch 不会自行添加审批回执、修订计数器、重放日志、取消路径、回滚机制或清理生命周期。

此技能中的任何持久性声明，指的都是明确的跟踪器记录或代码库文件，而不是隐藏的运行时。

阶段 0 — 入口

一次运行只有通过干净的船坞大门才能进入此阶段。在阅读提供的规格说明或进入阶段 1 之前，必须根据drydock 文档语言契约确定文档语言——/oh-my-claudecode:drydock 中的 shipyard-document-language-contract 块是确定顺序的唯一依据（明确的人为选择优先；否则采用 GLOSSARY.md frontmatter 中的 documentLanguage 标签；否则根据 CLAUDE.md 再到 README.md 进行一致且高置信度的推断）、中文脚本资格规则（zh-Hans / zh-Hant），以及仅询问一次的条件（证据缺失、混杂、冲突、置信度低、明确选择无效或脚本不明确时，集中提出一个问题；绝不猜测）。如果旧船坞只有 CONTEXT.md，则在下方的入口检查中从 CONTEXT.md 读取标签，并且只有在简报自检、迷雾关卡和地图检查均允许运行后，且在首次由 Launch 撰写内容之前，才通过 drydock 旧版术语表迁移（重命名为 GLOSSARY.md，保留内容）进行迁移；在这些检查处停止的运行不会改动仓库。绝不要在其旁边创建第二份术语表。Launch 专属要求：在任何由 Launch 撰写的产物之前，将已确定并规范化的标签写回 GLOSSARY.md，以便新的显式调用无需依赖隐藏的对话状态即可读取。人类负责阅读和维护这些产物；Agent 不受语言限制。

仅本地化散文、面向人的标签和可本地化的标量值。路径、斜杠命令、标志、代码围栏、占位符、frontmatter 键和机器语义值、YAML/JSON 键、生命周期标记（plan、execute、review、verify）、状态枚举（pending、in_progress、completed、failed、ready-for-agent）、ID、工单 blockedBy、公开 Team 的 blocked_by 以及所有解析器/控制标记都必须逐字节保持不变。参考语言版本互斥：只输出恰好一个选定版本，绝不重复提供双语标题或标签。

• 首先进行简报自检：简报是否写明了目标、范围边界和非目标？如果缺少其中两项或更多，指出这一点，并要求进行一轮简要完善——对不明确的简报运行流程，只会把模糊不清变成看似笃定的输出。
• 迷雾关卡：完善简报后，应用导航员的迷雾测试——Q1：能否用一句话说明目的地（本次工作要找到方向的规格说明、决策或变更）？Q2：虽然目前还无法回答任何一个问题，但能否现在就准确列出前三个决策？任一答案为否 → 运行不得启动：明确说明这一点，注明未生成任何产物，建议使用 /oh-my-claudecode:ask-navigator（船坞的导航员会将迷雾绘制为决策工单地图，并返回任务简报），然后停止。交接剩余问题以及已经确定的任何术语，避免导航员的 W1 再次询问。
• 地图检查：在阅读提供的规格说明或进入阶段 1 之前，检查是否存在开放的 navigator:map（tracker 标签）。如果存在且本次调用未提供新简报 → 建议使用 /oh-my-claudecode:ask-navigator 处理该地图上的下一个决策，然后停止。如果存在且提供了新简报 → 继续处理开放地图，还是开始新工作？先提出一个问题，再继续。如果不存在 tracker 地图，但有旧版本地地图，则停止并转交 ask-navigator 执行一次性 tracker 迁移，而不是启动重复工作。
• 提供了规格说明路径 → 阅读后跳转至阶段 2。
• 任务简报 → 阶段 1。已接受的意图（docs/intents/<slug>/intent.md，status: accepted，最新轮次——参见 /oh-my-claudecode:intent）是有效的任务简报：其中五个部分包含目标、范围和待解决问题。
• 单点修复 → 移交给 execute，然后退出。

阶段 1 — 收敛（人类决策，Agent 准备）

使用设计树协议开展访谈：梳理决策及其依赖关系，然后按前沿轮次推进——将当前所有可提问的问题汇总为一轮，逐一编号，并为每个问题给出推荐答案。由人类作答；决策树随之调整；重新计算前沿。事实始终由子 Agent 根据代码仓库证据自行查证——只询问人类任何探索都无法确定的问题。

理解重置。 在将已确定的决策提交签字前，先用一段简短、通俗的技术说明复述该决策，使用项目自己的词汇——即 GLOSSARY.md 中定义的术语，不借用其他术语。如果船长无法理解复述内容，就将该决策退回前沿，而不是凭猜测继续推进：签署自己理解的内容，而非别人说过的话，才能避免误读成为后续工作的根基。相同的原则也适用于修正传达途中未能正确理解的信息：如果船长的回复表明其误解了已发送的内容，就用 GLOSSARY.md 中的词汇，更简短、更清楚地重新发送，一次只处理一个误解，然后再继续对话——误读层层叠加，会让两场不同的对话最终挤进同一条线程。

每项内容一经确定，立即记录：

• 领域词汇 → 仓库根目录下的 GLOSSARY.md（每个术语一条）
• 符合 ADR 标准的决策（难以撤销、缺少背景时令人意外、存在真实权衡）→ docs/adr/NNNN-<slug>.md
• 在达成一致过程中发现的业务规则和背景 → docs/business/（每个业务问题一篇文章，首段说明其重要性）

在提出方案前，先检查记录文档（ADR、docs/business/），确认此前是否否决过相同概念：重新提出相似概念时，必须说明发生了什么变化，否则应予以拒绝——给被否决的想法换个名字，并不代表它成了新想法。

访谈期间就要维护术语表，而不是事后补做：如果某个术语与 GLOSSARY.md 中的内容冲突，就当场提出质疑；如果术语含糊不清，就持续追问，直到它有唯一、明确的名称；用具体场景检验业务关系；对照代码核实系统行为的说法，发现矛盾就摆到台面上，而不是放过。如果访谈需要某个术语，但术语表中没有，这本身就是一项发现——要么这是为本项目新造的词（撤回），要么术语表确实有缺漏（立即补上条目）。

无法达成一致是正常工作，不是失败：如果前沿无法清空，就按优先级排列并呈现剩余问题——这是 C2 的输入，不是错误。如果剩余问题本身无法准确表述（迷雾测试 Q2 未通过），说明目标本身尚未确定，这超出了 C2 的权限：停止，记录已确定的内容（GLOSSARY.md 中的词汇、已回答的问题），建议使用 /oh-my-claudecode:ask-navigator，然后退出——流水线绝不自行臆造目标。

Loft 分支。 如果某个剩余问题虽然明确，却无法通过文字确定——必须看见或点击，而非口头描述（例如 UI 应该是什么样，或某种状态模型是否合适）——就用产物来回答，而不是继续提问：调用 Skill 工具并输入 "loft"，让船长作出反馈，再将反馈纳入访谈。Loft 产物是 C2 的输入；船长签署自己看到的内容，而不是别人告诉自己的内容。

Harbor 简报。 /oh-my-claudecode:harbor 移交的任务简报包含已签署的决策及其链接和适用条件：将其视为已确定的内容——不要重新询问未发生变化的业务目标。如果收集证据后代码已有变动（出现新的 head、base 发生变化），就重新核实受影响的技术证据；已签署简报范围之外的新实现范围仍需单独批准。 已达成共识时退出。 如果本次调用来自一个决策树已梳理完毕的对话——所有待决问题均已回答，术语和决策也已确定（通过实时访谈、决策问卷或最新的跟踪器交接评论）——则 Phase 1 收缩为一次共识审计：阅读本轮会话已确定的内容，根据其引用的证据核验每项已确定的决策，完整重述一次（见上文的理解重置），然后直接起草规范。不会重问任何问题；模糊门槛和 C2 仍会把关——跳过访谈不等于跳过签字。共识质量必须经过核验，不能想当然：任何无法通过重述核验的已确定决策都会重新开放，访谈从那里继续。

Phase 2 — 规范综合（Agent 起草 → C2 批准）

将规范综合为一个父级跟踪器议题。当任务是一个已接受的意图时，遵循意图技能中的四步约定：阅读已接受的意图（最新轮次），结合现有代码库，遵循 Rules 支柱（CLAUDE.md + docs/standards/ + docs/business/），并列出所有疑点和规则冲突——按级别归入规范的待确认部分；意图中的未决问题原样带入规范，并保留其待确认状态：

# <Feature> Spec
## Problem
## Solution
## User Stories        (numbered, each with testable acceptance criteria)
## Implementation Decisions
## Testing Decisions   (external behavior only)
## Out of Scope

起草全部内容，然后在 C2 处停下：向人类呈现验收标准和测试接缝清单，供其审批。当任务是一个已接受的意图时，C2 呈现内容还须包含意图专属检查清单：规范是否仍在解决意图的原始问题，带入的未决问题是否均已考虑，以及高风险事项是否在审批前征询技术负责人。接缝依据仓库证据和深模块原则选取（公共接口、现有测试接缝、深度分析；相关术语见 docs/standards/architecture.md）；人类确认或更正该清单——未经人类批准的接缝不得编写测试。每个接缝条目都要声明其边界类别——进程内、本地可替换、自有远程（具有生产适配器和测试适配器的端口），或真正外部（注入替代项）——因为类别决定接缝的测试方式。

斟酌规则。 当接口形态本身存在争议——有两种合理设计，无法通过讨论确定其一——C2 应在备选方案之间签字，而不是只在桌面上唯一的提案上签字：在并行子 Agent 中起草候选形态，每个子 Agent 分别侧重不同方向（最小化接口表面 · 最大限度适应未来需求 · 为最常见的调用方提供最顺畅的默认路径 · 实现最清晰的跨边界适配器），并排呈现这些方案，比较其深度、局部性和接缝位置，然后由负责人选定一个方案或整合出混合方案。

持久性门槛（由 Agent 强制执行，无需审批）：规范和票据应描述约定，而非坐标——不得包含文件路径或行号。比文字更能表达决策的片段（状态机、reducer、架构）属于例外，并须注明其来源（通常是 loft）。

测试决策应淘汰孤儿：当接缝深化或被替换时，绑定旧接口的测试也随之退役——新测试只针对新接口编写。测试规则本身见 docs/standards/process.md。

阶段 3 — 票据拆分（Agent 起草 → C3 审批）

将工作拆分为纵向切片，作为子跟踪 issue（父规范 issue 的原生子 issue），按依赖关系排序，每个都声明 blockedBy: [ids]：

• 每个票据都横跨所有层，可独立演示，并适合在一个全新的上下文中完成
• 阻塞边是承重声明：票据要说明自己在等待什么——哪些决策、制品（规范、ADR、loft 结果）或其他票据，而不只是等待哪些票据编号。该声明是 C3 的输入：这里的粒度若不恰当，就会错误路由每一项依赖；而未声明等待项的票据，无法在前沿上诚实地排期。
• 大范围重构采用扩展-收缩模式：添加新形式，分批迁移，再移除旧形式——每个批次作为一个票据

首先运行 Agent 端的机械验证（独立性、可演示性、上下文适配度）。然后由 C3 审核：向人工审批者展示粒度、阻塞边以及建议的合并/拆分。持续迭代直至获批。将每个票据标记为 ready-for-agent。C3 的标准是：全新的执行者可以着手任何票据，无需反问——必须提问的票据应将问题上报到规范，而不是交给执行者。

集成接线规则：每个纵向切片都包含自身接线和一项冒烟断言——如果切片的输出没有任何东西挂载、提供服务或导入，就不算完成。没有任何单个切片负责的跨切片接缝（路由挂载、静态资源提供、入口点接线）要作为明确的集成票据，放在前沿的最后。

阶段 4 — 推进前沿

前沿包含所有阻塞项均已完成的票据。

侦察阶段。 两个或更多票据共用的探索工作应在派发前执行一次：由 explore 子 Agent 解答共用问题，并将发现报告到会话中——笔记留在对话里，绝不写入磁盘。派发时将这些发现整合进相关跟踪票据；执行者绝不重复探索票据已经解决的问题。只有一个票据需要的问题应留在该票据中。

集成拓扑。 执行者的输出汇聚到一个比执行者存续更久的统一界面：在阶段 4 开始时创建一个集成分支——在 PR 平台上，将其作为草稿 PR 打开，并引用规范及每个票据。执行者分支从集成分支的最新提交开始——基于过时基线的执行者分支会合并出无人负责解决的冲突——只有在该票据通过双轴审查门槛后，才通过团队的合并协调（checkMergeConflicts → mergeWorkerBranch）进行合并；C5 验证针对集成界面运行。首次执行者合并进入集成分支后，才打开草稿 PR——空分支没有可供审查者查看的内容。这仍处于 Team 的约定范围内：分支是拓扑结构，不是新的启动状态机。

修复规则。 双轴审查发现的问题由单个修复执行者修复，并重新通过同一审查门槛。审查者只负责评判，绝不修复；实施者绝不自行批准。

并行（默认，2 个或更多票据）。 将票据交给团队：每个票据都成为一个团队任务，blockedBy 边沿用——团队的认领机制只会选取前沿任务。启动 N 个执行者。每个执行者按照 C2 批准的接缝处 tdd 规范进行实现，并在编写时遵循 /oh-my-claudecode:minimal-code-discipline（该规范保持为可选）；只有在审查者声明差异通过代码审查后，票据才能关闭——实施者绝不自行批准。

串行（单个票据，或使用 --serial）。 每次将一个票据委派给执行器子 Agent；审查门槛相同。

双轴审查门槛。 结项审查沿两条轴线并行进行，并分别报告——绝不合并或交叉排序，因为一项更改可能通过一条轴线，却未通过另一条（符合标准但行为错误；实现忠实但违反惯例）。任一轴线未通过，审查者就会判定票据未通过：

• 标准轴——与匹配的 docs/standards/ 卷的差异，以及仅依赖判断的异味基线（有记录的仓库标准优先于基线；工具已强制执行的内容会跳过）。这是持续运行的使用方，用于确保标准相关界面始终被引用。
• 规范轴——与本工单验收标准的差异（规范是工单拆分所依据的完整账本；仅用于追溯标准的来源，以及判断是否夹带了范围外内容——即没有任何工单要求的行为）：缺失或不完整的要求、无人要求的行为，以及看似已实现但可能有误的要求——每条发现都要引用其来源行。

C4——运行期间出现的决策。 当并行 Team 工作线程遇到符合 ADR 判定标准的决策时，必须在进行依赖该决策的变更前停止，在失败转换的 error 字段和父规范 issue 的评论中记录问题（包括选项、建议和可逆性说明），并通过 Team 支持的 in_progress → failed 转换退出。这是 Launch 的终止结果：不要重新打开任务、创建运行中的后继任务、强制清理，或从本次调用启动另一个 Team。指出阻塞事项，并提供失败任务和决策产物的链接。

在之后明确调用 Launch 时，首先要求所属 Team 的生命周期已终止，并通过其支持的所有者完成清理。然后批量向人工询问所有待处理的 C4 问题，将答案记录到决策日志/ADRs 中，并在开始执行前重建工单队列。所有工单依赖项都要在派发前声明：通过 Team 任务 API 创建任务时，工单的 blockedBy 元数据会映射到公开 Team 的 blocked_by 字段，其中使用数字任务 ID。Team 现有的任务 ID 依赖解析会拒绝过早认领，并且只有在前置任务完成后才会使依赖任务符合执行条件。除非明确注册为 Team 工作线程，否则 Team 负责人绝不认领任务。Launch 绝不动态修改已被认领任务的依赖项，也绝不承诺在出现 C4 后自动重新派发。

串行 C4（--serial）。 执行器在进行依赖该决策的变更前停止，并返回问题，但不宣称已完成。在批次边界记录并解决人工提出的问题，然后使用已记录的答案和剩余验收标准启动一个全新的执行器后继任务。不要重放或恢复被中断的执行器上下文；Team 未激活时，不要创建虚构的 Team 任务。

重复失败停止。 同一验证失败在三次修复尝试后仍未解决时，暂停该执行通道，并向人工提供根因假设。这是唯一会立即中断 C4 批处理的情况。

阶段 5 — 收尾（Agent 汇报 → C5 验收）

• 所有工单均已结束并附有证据 → 对整个变更运行 verify

• 核对文档记录：确保 GLOSSARY.md 准确无误、ADR 完整，并在实现过程中有所发现时更新规范

• 重新检查堆场：重新运行 drydock --check 审计；自开始以来发现的任何新问题均报告为 堆场偏移，并附上指向 /oh-my-claudecode:drydock 的链接

• 沉积复盘——回答：这艘船教会了堆场什么？ 先完成一份结构化复盘——构建了什么（每个切片用一行说明已交付的范围）、出了什么问题（暴露出的每项故障：三次失败后的根因、verify 发现的问题）、学到了什么（C4 答案、评审驳回，以及本次运行所遵循的源映射中的任何映射决议或延后沉积项），以及环境造成了哪些阻碍（寻路摩擦、运行过慢或过晚的检查、导致不得不猜测的标准缺失、未执行任何操作的工具、难以触达的信息）。然后再作答。将每项经验按 lesson → slot → intended change 的格式，对照下方的槽位表提出，或明确说明不采纳及其理由；如果这艘船没有任何新经验，必须原样说明 "no new lessons"。此要求禁止不作答，但绝不要求答案非空——为了有内容而捏造经验，与跳过问题同样违规。经验列表随完成报告一并提交，置于 Open Assumptions 旁边，每一行都可单独否决；获批的经验仅在验收后写入相应槽位，报告须记录每项落地内容的文件位置。将经验写入任何槽位前，先调用 Skill 工具并使用 agent-doc-discipline，遵循其规则；只有通过该技能的验证清单，沉积复盘才算完成。

  经验类别	槽位
  运行过程中确定的术语和边界	GLOSSARY.md 术语表
  可检查的行为规则（须说明原因）	docs/standards/ 中对应的卷（架构／数据／流程）
  最常被违反的约定（精简条目级）	CLAUDE.md 正文 — 仅提议
  难以撤销的决策	docs/adr/（C4 答案已归档于此）
  已排除的方向（概念及驳回原因）	docs/adr/（驳回也是一种决策；原因是关键依据）
  业务规则／背景	docs/business/
  UI 模式／组件契约	design-system/
  可复用的专业技能	.omc/skills/（须通过 skillify 门槛）
  反复需要的自动化／集成	scripts/ 或 .mcp.json
  无合适槽位	明确说明不采纳及其理由

• 精简条目预算： CLAUDE.md 正文最多保留五条高优先级条目。只有当源清单证明本次运行中同一违规至少发生两次，或船长认定其为关键依据时，经验才达到精简条目级。条目按最近提升优先的顺序列出；最旧的条目确定为列表末尾那一条。超出预算的提升提议必须同时降级且仅降级该条目，并将其完整文本移回 docs/standards/——不删除任何内容，只调整层级。膨胀问题逐船重新平衡，刻意不作为 --check 的检查项。

• 在完成报告中说明本次运行的数量：已完成工单数、提出的 C4 决策数、三次失败后停止的次数，以及提议的沉积条目数——仅在报告正文中如实列出，不使用遥测系统或状态文件

• 输出完成报告：已交付范围、验证证据、文档记录位置、堆场偏移问题（如有）、沉积清单（每项均可否决），以及按人工可能否决的意愿强弱排序的 Open Assumptions

• 如果平台通过 PR 进行评审，且阶段 4 创建了草稿 PR，则根据报告中的证据和关联 ADR，按照 /oh-my-claudecode:pr 撰写 PR 正文；仅在 C5 验收后将 PR 标记为可评审

上下文管理

• 阶段 1–3 在同一个连续上下文窗口中完成；仅在阶段边界处压缩（HUD 达到高水位时即为信号）。
• 规范工件是主要信息来源；对话记忆是次要信息来源。 重新阅读跟踪器议题和评论以获取规格、工单和交接信息，并查阅仓库文件以了解记录；绝不能只凭记忆中的状态继续。
• 四种边界选择： 继续（上下文仍有空间且未受污染）→ 从规范工件重新进入（视情况查阅跟踪器议题／评论或仓库文件）→ 交接（只传指针，不传内容）→ 压缩（接近上限且处于阶段边界）。选择第一个适用的选项。
• 长时间无头运行：优先使用 --output-format stream-json（或定期输出进度标记），以便编排器能确认任务仍在运行——纯文本模式会等到本轮结束才输出内容。
• 按设计，阶段 4 会为每张工单使用全新上下文（由团队工作者或子 Agent 执行）。
• 交接时只传指针，不传内容。跟踪器交接评论只包含三项：指针（材料和决策所在位置——绝不复制内容）、下一步关注事项（下一阶段要做什么，以及要调用哪些技能）和警示事项（已排除的红线；凭据须脱敏）。无法避免压缩时，随附一条指令，确保摘要保留下一阶段所需的信息。
• 计划内会话交接：按计划必须在工作进行中结束会话时——例如上下文预算耗尽、到达预定边界或主动暂停——更新父规格议题，并添加一条跟踪器评论，其中包含已确定决策的指针、尚待解决的问题、团队任务状态、下一步关注事项和警示事项（凭据须脱敏）。在对应的子议题中记录每项解决结果；父议题、子议题和最新交接评论共同构成完整的重新进入信息源。不要创建本地交接工件、对话记录或跟踪器内容副本。
• 会话在运行中意外终止：保留跟踪器状态并停止。只有在所属团队生命周期到达受支持的终止／清理边界后，后续明确调用才能继续；继续前必须重新阅读父议题、原生子议题及其状态／依赖关系／证据，以及最新交接评论，然后针对缺失的指针或决策进行询问，不要自行推断。团队状态仍是运行时状态的权威来源。

完成定义

所有工单均已终结并附有证据；已对整个变更进行干净验证；记录链条已核对一致；已生成报告——且 Agent 代表用户作出的每项决策，都能通过一个指针找到记录位置。