launch

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Launch

Launch is the shipyard's delivery run: from mission brief to shipped, verified change. It stands on the verifiability boundary — agents continuously run everything repeatable and acceptable-by-evidence; humans decide what cannot be judged by the system or what fails expensively. The goal is not maximum automation — it is maximum delegation of verifiable work, so the human's time is spent only on the decisions only a human can make.

The verifiability test, applied to every step: if this is done wrong, can the system detect it? Can it redo or roll back automatically? Both yes → agent. No unique answer, system cannot judge, or expensive to get wrong → human.

Launch assumes the shipyard exists — and refuses to run if it does not. The yard gate is the first action of every invocation, before document-language resolution and before reading any supplied spec:

Run the full drydock
--check
audit — missing surfaces, a missing or invalid
```
CONTEXT.md
```
frontmatter
```
documentLanguage
```
, dead paths, glossary terms unused in code, standards never referenced. This is the single criterion: Launch performs no separate facility inventory of its own.
Actionable / high-confidence findings hard-block the run: list every such finding verbatim, point at
```
/oh-my-claudecode:drydock
```
, state that the run never started and no artifacts were produced, and stop. Without an explicit override, treat any finding as blocking.
Narrow override (explicit intent only): low-confidence findings, findings explicitly classified as false positives in the drydock report, or a scratch/throwaway repository explicitly declared by the user may be overridden only with deliberate, per-invocation user intent — the override must name the finding(s) or the throwaway scope and must never silently swallow a high-confidence actionable finding. No general bypass flag.
Current audit contract: the mechanical subset of
```
--check
```
is executable —
```
node scripts/shipyard-audit.mjs [repoRoot]
```
checks the high-confidence classes (missing surfaces, a missing/invalid
```
documentLanguage
```
tag, dead paths in
```
CLAUDE.md
```
, project-skill triggers present, and intent statuses within the documented vocabulary) and emits JSON findings in the shared severity/confidence/actionable vocabulary; exit 0 = clean, 1 = high-confidence actionable findings present. The gate consumes that exit: 0 admits the run, 1 lists the findings verbatim and blocks. The heuristic classes (glossary terms unused in code, standards never referenced) stay in the drydock prose audit — low-confidence by construction, override rules unchanged.
A clean audit (or an explicitly overridden low-confidence/false-positive/scratch scope) admits the run. Every paper-trail slot (
```
CONTEXT.md
```
,
```
docs/adr/
```
,
```
docs/business/
```
) and facility surface already exists at that point; Launch fills the paper trail as decisions settle but never creates the slots.
The rules entry is
```
CLAUDE.md
```
— the shipyard map recognizes no substitute.

Launch 是 Shipyard 的交付运行流程：从任务简报到已上线、已验证的变更。它建立在可验证性边界之上——agents 持续运行所有可重复、且可通过证据验证的工作；人类负责系统无法判断、或出错代价高昂的事项。 其目标不是最大化自动化，而是最大化委派可验证的工作，让人类的时间只花在只有人类才能做出的决策上。

每一步都要经过可验证性测试：如果这一步做错了，系统能检测到吗？能自动重做或回滚吗？ 两个答案都是肯定的 → 交给 agent。没有唯一答案、系统无法判断、或出错代价高昂 → 交给人类。

Launch 以 Shipyard 存在为前提——如果不存在则拒绝运行。船坞门（yard gate）是每次调用的第一个动作，先于文档语言解析，也先于读取任何提供的规格：

运行完整的 drydock
--check
审计——检查缺失的表层文件、
```
CONTEXT.md
```
前置元数据中缺失或无效的
```
documentLanguage
```
、无效路径、代码中未使用的术语表术语、从未被引用的标准。这是唯一的判定标准：Launch 本身不做单独的设施清点。
可操作/高置信度的发现会直接阻塞运行： 逐字列出所有此类发现，指向
```
/oh-my-claudecode:drydock
```
，说明运行从未启动、未生成任何产物，然后停止。没有显式覆盖的情况下，所有发现都视为阻塞项。
有限覆盖（仅支持显式意图）： 低置信度发现、drydock 报告中明确归类为误报的发现、或用户显式声明的临时/一次性仓库，仅可在用户每次调用时明确表达意图的情况下进行覆盖——覆盖必须指定具体的发现项或一次性范围，绝不能静默忽略高置信度的可操作发现。不提供通用绕过标志。
当前审计契约：
```
--check
```
的机械性子集是可执行的——
```
node scripts/shipyard-audit.mjs [repoRoot]
```
会检查高置信度类别（缺失的表层文件、缺失/无效的
```
documentLanguage
```
标签、
```
CLAUDE.md
```
中的无效路径、是否存在项目 skill 触发器、以及文档词汇表范围内的意图状态），并以通用的严重度/置信度/可操作性词汇输出 JSON 格式的发现；退出码 0 = 无问题，1 = 存在高置信度可操作发现。入口门会读取该退出码：0 则放行运行，1 则逐字列出发现并阻塞。启发式类别（代码中未使用的术语表术语、从未被引用的标准）仍保留在 drydock 的文本审计中——本质上属于低置信度，覆盖规则不变。
审计通过（或显式覆盖了低置信度/误报/临时范围）后放行运行。 此时所有审计轨迹槽位（
```
CONTEXT.md
```
、
```
docs/adr/
```
、
```
docs/business/
```
）和设施表层都已存在；Launch 会在决策落地时填充审计轨迹，但绝不会创建这些槽位。
规则入口是
```
CLAUDE.md
```
——Shipyard 地图不认可任何替代文件。

The boundary

边界

Human checkpoints (the critical 20%)	Agent continuous run (the mechanical 80%)
C1 author the mission brief (objective + scope)	fact-finding and repo exploration, self-served
C2 approve acceptance criteria + test seam list	interview preparation: frontier questions batched with recommended answers
C3 approve ticket decomposition (granularity, blocking edges)	spec and ticket drafting, mechanical validation (independence, demonstrability, fits-one-context)
C4 answer irreversible decisions that emerge mid-run (batched, async)	tdd implementation at agreed seams, builds, tests, regressions
C5 accept the completion report; veto via Open Assumptions and the per-line sediment list	code-review, verify across the change, team frontier scheduling, the whole paper trail

Between checkpoints the pipeline never idles: agents keep working every frontier ticket that does not depend on a pending human answer.

人类检查点（关键的20%）	Agent 持续运行（机械性的80%）
C1 编写任务简报（目标 + 范围）	事实调查与代码库探索，自助完成
C2 审批验收标准 + 测试接缝列表	访谈准备：将前沿问题与推荐答案批量整理
C3 审批工单分解（粒度、阻塞依赖）	规格与工单起草、机械性验证（独立性、可演示性、单上下文适配）
C4 答复运行过程中出现的不可逆决策（批量、异步）	在约定的接缝处采用 TDD 实现、构建、测试、回归
C5 验收完成报告；通过开放假设和逐行沉淀列表行使否决权	代码评审、跨变更验证、团队前沿任务调度、完整审计轨迹

在检查点之间，流水线绝不会空闲：agents 会持续处理所有不依赖待答复人类决策的前沿工单。

Lifecycle posture

生命周期定位

Launch is a stateless composition over OMC's existing lifecycle — it owns no runtime state machine:

Team owns task statuses, transitions, cancellation, and runtime cleanup; Launch never mutates them outside Team's contract.
The canonical
```
plan
```
→
```
execute
```
→
```
review
```
→
```
verify
```
surfaces own their existing lifecycle behavior. Launch-authored artifacts are limited to
```
.omc/specs/<feature-slug>/
```
,
```
CONTEXT.md
```
,
```
docs/adr/
```
, and
```
docs/business/
```
— plus, only after C5 approval, the sediment slots named in the Phase 5 table.
Launch has no automatic resume. After interruption, re-read the artifacts and current Team status, but continue only through a new explicit Launch invocation after the owning Team lifecycle has reached a supported terminal/cleanup boundary. Never infer a human approval or replay an
```
in_progress
```
task.
Foggy efforts are the navigator's jurisdiction: when the fog gate routes to
```
/oh-my-claudecode:ask-navigator
```
, the run never started — no artifacts, no partial state. The navigator's map is the only carrier across sessions; launch resumes only from the mission brief it hands back.
Launch adds no approval receipt, revision counter, replay log, cancellation path, rollback mechanism, or cleanup lifecycle of its own.

Any durability claim in this skill is a claim about the files on disk, not about a hidden runtime.

Launch 是构建在 OMC 现有生命周期之上的无状态组合——它本身不拥有运行时状态机：

Team 负责任务状态、流转、取消和运行时清理；Launch 绝不会在 Team 的契约之外修改它们。
标准的
```
plan
```
→
```
execute
```
→
```
review
```
→
```
verify
```
表层保留其现有生命周期行为。Launch 生成的产物仅限于
```
.omc/specs/<feature-slug>/
```
、
```
CONTEXT.md
```
、
```
docs/adr/
```
和
```
docs/business/
```
——此外，仅在 C5 审批通过后，才会写入第5阶段表格中列出的沉淀槽位。
Launch 没有自动恢复功能。中断后，会重新读取产物和当前 Team 状态，但仅在所属 Team 的生命周期到达支持的终止/清理边界后，通过新的显式 Launch 调用才能继续。绝不能推断人类审批，也不能重放
```
in_progress
```
状态的任务。
模糊工作项属于导航员（navigator）的管辖范围：当雾门将请求路由到
```
/oh-my-claudecode:ask-navigator
```
时，运行并未启动——没有产物，也没有部分状态。导航员地图是跨会话的唯一载体；Launch 仅能从其返回的任务简报处恢复。
Launch 自身不添加审批回执、修订计数器、重放日志、取消路径、回滚机制或清理生命周期。

本 skill 中任何关于持久性的声明，都是针对磁盘上的文件而言，而非针对隐藏的运行时。

Phase 0 — Entry

阶段 0 — 入口

A run reaches this phase only through a clean yard gate. Before reading a supplied spec or entering Phase 1, resolve the document language per the drydock document-language contract — the

shipyard-document-language-contract

block in

/oh-my-claudecode:drydock

is the single authority for the resolution order (explicit human choice wins; otherwise the

CONTEXT.md

frontmatter

documentLanguage

tag; otherwise unanimous high-confidence inference from

CLAUDE.md

then

README.md

), the Chinese script-qualification rule (

zh-Hans

zh-Hant

), and the ask-once conditions (missing, mixed, conflicting, low-confidence, invalid-explicit, or script-ambiguous evidence asks one batched question; never guess). Launch-specific requirements: persist the resolved normalized tag back to

CONTEXT.md

before any Launch-authored artifact so a fresh explicit invocation can read it without hidden conversation state. The human reads and maintains these artifacts; agents are language-agnostic.

Localize prose and human-facing labels/localizable scalar values only. Paths, slash commands, flags, code fences, placeholders, frontmatter keys and machine-semantic values, YAML/JSON keys, lifecycle tokens (

plan

execute

review

verify

), status enums (

pending

in_progress

completed

failed

ready-for-agent

), IDs, ticket

blockedBy

, public Team

blocked_by

, and all parser/control tokens remain byte-for-byte stable. Reference language companions are mutually exclusive: emit exactly one selected rendering, never bilingual duplicate headings or labels.

Brief self-check before anything else: does the brief name an objective, a scope boundary, and non-goals? If two or more are missing, say so and ask for one sharpening pass — running the pipeline on a soft brief converts ambiguity into confident-looking output.
Fog gate: after the sharpening pass, apply the navigator's fog test — Q1: can the destination be stated in one sentence (the spec, decision, or change this effort is finding its way to)? Q2: can the first three decisions be stated precisely right now, even though none can be answered yet? Either answer no → the run never starts: state that plainly, note that no artifacts were produced, recommend
```
/oh-my-claudecode:ask-navigator
```
(the shipyard's navigator charts fog as a map of decision tickets and hands back a mission brief), and stop. Hand over the residual questions and any vocabulary already settled, so the navigator's W1 does not re-ask them.
Map check: before reading a supplied spec or entering Phase 1, look for an open
```
navigator:map
```
(tracker label, or under
```
.omc/wayfinder/
```
). One exists and this invocation supplies no new brief → recommend
```
/oh-my-claudecode:ask-navigator
```
to work the next decision on that map, and stop. One exists and a new brief is supplied → ask one question — continue the open map, or start a new effort — before proceeding.
Spec path supplied → read it, jump to Phase 2.
Mission brief → Phase 1. An accepted intent (
```
docs/intents/<slug>/intent.md
```
,
```
status: accepted
```
, latest round — see
```
/oh-my-claudecode:intent
```
) is a valid mission brief: its five sections carry the objective, scope, and open questions.
Single-point fix → hand off to execute, exit.

运行仅在通过船坞门后才能进入此阶段。在读取提供的规格或进入阶段1之前，需按照drydock 文档语言契约解析文档语言——

/oh-my-claudecode:drydock

中的

shipyard-document-language-contract

块是解析规则的唯一权威来源，包括解析顺序（显式人工选择优先；否则取

CONTEXT.md

前置元数据的

documentLanguage

标签；再否则依次从

CLAUDE.md

和

README.md

中进行一致的高置信度推断）、中文书写体判定规则（

zh-Hans

zh-Hant

）以及单次询问条件（缺失、混合、冲突、低置信度、显式无效或书写体不明确的证据，会发起一次批量询问；绝不猜测）。Launch 的特定要求：在生成任何 Launch 产物之前，将解析后的标准化标签写回

CONTEXT.md

，这样新的显式调用无需依赖隐藏的会话状态就能读取该值。人类负责阅读和维护这些产物；agents 与语言无关。

仅对正文文本和面向人类的标签/可本地化标量值进行本地化。路径、斜杠命令、标志、代码块、占位符、前置元数据键和机器语义值、YAML/JSON 键、生命周期令牌（

plan

、

execute

、

review

、

verify

）、状态枚举（

pending

、

in_progress

、

completed

、

failed

、

ready-for-agent

）、ID、工单的

blockedBy

、公开的 Team

blocked_by

，以及所有解析器/控制令牌都保持字节级稳定。参考语言版本是互斥的：仅输出选定的单一渲染版本，绝不能使用双语重复的标题或标签。

首要进行简报自检：简报是否明确了目标、范围边界和非目标？如果缺少两项及以上，需说明情况并请求进行一次细化——基于模糊的简报运行流水线，会把歧义包装成看起来很确定的输出。
雾门：细化之后，执行导航员的模糊测试——问题1：能否用一句话描述目标（本次工作要达成的规格、决策或变更）？问题2：能否在尚无法给出答案的情况下，精准描述前三个待决策事项？任一问题答案为否 → 运行不启动：明确说明情况，注明未生成任何产物，推荐使用
```
/oh-my-claudecode:ask-navigator
```
（Shipyard 的导航员会将模糊区域绘制成决策工单地图，并返回一份任务简报），然后停止。将剩余问题和所有已确定的术语移交过去，这样导航员的 W1 阶段就不会重复提问。
地图检查：在读取提供的规格或进入阶段1之前，查找是否存在未完成的
```
navigator:map
```
（追踪器标签，或位于
```
.omc/wayfinder/
```
目录下）。如果存在且本次调用未提供新的简报 → 推荐使用
```
/oh-my-claudecode:ask-navigator
```
来处理该地图上的下一个决策，然后停止。如果存在且提供了新的简报 → 先询问一个问题：是继续现有地图，还是启动新的工作项——之后再继续。
提供了规格路径 → 读取该路径，跳至阶段2。
任务简报 → 阶段1。已接受的意图（
```
docs/intents/<slug>/intent.md
```
，
```
status: accepted
```
，最新轮次——参见
```
/oh-my-claudecode:intent
```
）是有效的任务简报：其五个部分包含了目标、范围和待解决问题。
单点修复 → 移交执行，退出。

Phase 1 — Converge (human decides, agent prepares)

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

Run the interview with the design-tree protocol: map decisions and their dependencies, then work in frontier rounds — batch every currently-askable question into one round, numbered, each with a recommended answer. The human answers; the tree reshapes; recompute the frontier. Facts are always self-served by sub-agents from repo evidence — the human is asked only what no amount of exploration can settle.

Comprehension reset. Before a settled decision is presented for signature, restate it back in one short paragraph of plain technical prose, using the yard's own vocabulary — the terms as

CONTEXT.md

defines them, no borrowed jargon. A restatement the captain cannot follow sends the decision back to the frontier, not forward on a guess: signing what was understood, not what was said, is how misreads become load-bearing. The same discipline repairs a message that did not land mid-flight: when the captain's reply shows a misunderstanding of what was sent, re-send it shorter and plainer in the CONTEXT.md vocabulary, one misunderstanding at a time, before the conversation continues — compounding a misread is how two different conversations end up sharing one thread.

Paper trail, written the moment each item settles:

domain vocabulary →
```
CONTEXT.md
```
at repo root (one entry per term)
decisions passing the ADR test (hard to reverse, surprising without context, real tradeoff) →
```
docs/adr/NNNN-<slug>.md
```
business rules and background discovered during convergence →
```
docs/business/
```
(one article per business question, opening paragraph states why it matters)

Before surfacing a proposal, check the paper trail (ADRs,

docs/business/

) for a prior rejection of the same concept: a concept-similar re-proposal must state what changed, or it is declined — a new name for a rejected idea is not a new idea.

The glossary is policed during the interview, not after it: a term that collides with

CONTEXT.md

is challenged on the spot; a fuzzy term is pressed until it holds one exclusive name; business relationships are stress-tested against a concrete scenario; claims about system behavior are checked against the code, and a contradiction goes on the table instead of passing. A term the interview needs but the glossary lacks is itself a finding — either the word is being invented for this ship (withdraw it) or the glossary has a real gap (write the entry now).

Non-convergence here is normal work, not a failure: if the frontier will not empty, present the residual questions ranked — this is C2's input, not an error. If the residual questions themselves cannot be stated precisely (fog test Q2 fails), the destination itself is unsettled and that is beyond C2's authority: stop, note what already settled (vocabulary in

CONTEXT.md

, answered questions), recommend

/oh-my-claudecode:ask-navigator

, and exit — the pipeline never invents a destination.

Loft detour. A residual question that is precise but cannot settle in prose — it needs to be seen or clicked, not described (how the UI should look, whether a state model feels right) — is answered with an artifact, not more questions: call the Skill tool with "loft", let the captain react, and fold that reaction back into the interview. The lofted artifact is C2's input; the captain signs what they saw, not what they were told.

Harbor briefs. A mission brief handed over by

/oh-my-claudecode:harbor

carries signed decisions with links and applicable conditions: consume them as already-made — do not re-ask unchanged business goals. If the code has moved since the evidence was gathered (new head, changed base), re-verify the affected technical evidence; new implementation scope beyond the signed brief still gets its own approval.

Settled-consensus exit. When this invocation arrives from a conversation whose decision tree is already worked — every frontier question answered, vocabulary and decisions already settled (by a live interview, a decision questionnaire, or a handoff artifact) — Phase 1 collapses to a consensus audit: read what the session settled, verify each settled decision against the evidence it names, restate the whole set once (the comprehension reset above), and draft the spec directly. No questions are re-asked; the fog gate and C2 still gate the run — skipping the interview never skips a signature. Consensus quality is verified, never assumed: any settled decision that fails its restatement re-opens, and the interview resumes from there.

按照设计树协议执行访谈：梳理决策及其依赖关系，然后以前沿轮次的方式推进——将所有当前可提问的问题批量整理为一轮，编号，每个问题都附带推荐答案。人类答复后，设计树会重塑，再重新计算前沿问题。事实性信息始终由子 agents 从代码库证据中自助获取——只有无论怎么探索都无法确定的问题，才会询问人类。

理解重置。 在将已确定的决策提交签字之前，要用简短的平实技术段落重述，使用船坞自身的词汇表——即

CONTEXT.md

中定义的术语，不使用外来行话。如果船长（captain）无法理解重述内容，决策会被退回前沿问题列表，而不是猜测着推进：对理解的内容签字，而非对听到的内容签字，这是避免误读成为核心依赖的关键。同样的原则也用于修复中途未传达清楚的信息：当船长的回复显示其对发送的内容存在误解时，要用

CONTEXT.md

中的词汇更简短、更清晰地重新发送，每次只纠正一个误解，然后再继续对话——叠加误读会导致两个完全不同的对话共用同一个线程。

审计轨迹会在每项内容确定后立即写入：

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

在提出提案之前，先检查审计轨迹（ADR、

docs/business/

）中是否有过对同一概念的否决：概念相似的重新提案必须说明发生了什么变化，否则会被拒绝——给被否决的想法换个名字，不代表是新想法。

术语表的校验在访谈过程中进行，而非事后：与

CONTEXT.md

冲突的术语会当场被质疑；模糊的术语会被追问到只有唯一的明确名称；业务关系会通过具体场景进行压力测试；关于系统行为的主张会对照代码检查，存在矛盾的会摆到桌面上，而不是直接通过。访谈需要但术语表中没有的术语本身就是一项发现——要么这个词是为本项目临时发明的（撤回它），要么术语表确实有缺口（现在就补写条目）。

此处无法收敛是正常工作，而非失败：如果前沿问题无法清空，就按优先级列出剩余问题——这是 C2 的输入，而非错误。如果剩余问题本身无法精准描述（模糊测试问题2未通过），说明目标本身尚未明确，这超出了 C2 的权限：停止，注明已确定的内容（

CONTEXT.md

中的术语、已答复的问题），推荐使用

/oh-my-claudecode:ask-navigator

，然后退出——流水线绝不会凭空发明目标。

Loft 绕行。 如果剩余问题表述精准但无法通过文字确定——需要亲眼看到或点击体验，而非描述（比如UI应该是什么样、状态模型是否合理）——则用产物来答复，而非继续提问：调用 Skill 工具的「loft」功能，让船长给出反馈，再将反馈整合到访谈中。生成的 loft 产物是 C2 的输入；船长对自己看到的内容签字，而非对被告知的内容签字。

Harbor 简报。 由

/oh-my-claudecode:harbor

移交的任务简报带有已签字的决策，包含链接和适用条件：直接采纳这些已完成的决策——不要对未变更的业务目标重复提问。如果自证据收集以来代码发生了变化（新的HEAD、基准变更），需要重新验证受影响的技术证据；超出已签字简报范围的新实现 scope 仍需单独审批。

已达成共识的退出路径。 如果本次调用来自一个决策树已经梳理完成的对话——所有前沿问题都已答复，术语和决策都已确定（通过实时访谈、决策问卷或移交产物）——阶段1会简化为共识审计：读取本次会话确定的内容，对照每项决策所引用的证据进行验证，将全部内容重述一遍（即上述的理解重置），然后直接起草规格。不会重复提问；但雾门和 C2 仍然是运行的必经关卡——跳过访谈绝不等于跳过签字。共识质量需要验证，绝不能假设：任何已确定的决策如果重述不通过，就会重新开放，访谈从该点恢复。

Phase 2 — Spec synthesis (agent drafts → C2 approves)

阶段 2 — 规格合成（Agent 起草 → C2 审批）

Synthesize

.omc/specs/<feature-slug>/spec.md

. When the mission is an accepted intent, follow the four-step contract from the intent skill: read the accepted intent (latest round), combine with the existing codebase, follow the Rules pillar (

CLAUDE.md

docs/standards/

docs/business/

), and list every doubt and rule conflict — graded into the spec's pending-confirmation section; intent open questions carry into the spec verbatim, keeping their pending status:

undefined

合成

.omc/specs/<feature-slug>/spec.md

。如果任务是已接受的意图，需遵循 intent skill 的四步契约：读取已接受的意图（最新轮次），结合现有代码库，遵循规则支柱（

CLAUDE.md

docs/standards/

docs/business/

），并列出所有疑问和规则冲突——分级归入规格的待确认部分；意图的待解决问题会原样带入规格，保持其待处理状态：

undefined

<Feature> Spec

Problem

Solution

User Stories (numbered, each with testable acceptance criteria)

Implementation Decisions

Testing Decisions (external behavior only)

Out of Scope


Draft all of it, then stop at **C2**: present the acceptance criteria and the test seam list for human approval. When the mission is an accepted intent, the C2 presentation also carries the intent-flavor checklist: does the spec still solve the intent's original problem, are the carried open questions accounted for, and do high-risk items get a tech-lead consult before approval. Seams are selected by repo evidence and the deep-module discipline (public interfaces, existing test seams, depth analysis; the vocabulary is seeded in `docs/standards/architecture.md`); the human confirms or corrects the list — a seam the human has not approved gets no tests. Each seam entry declares its **boundary class** — in-process, locally substitutable, owned-remote (a port with a production and a test adapter), or true-external (an injected substitute) — because the class decides how the seam is tested.

**Tender rule.** When the interface's shape is itself contested — two plausible designs, neither settleable by talk — C2 signs *between* alternatives, never on the only proposal on the table: draft the candidate shapes in parallel sub-agents, each under a different emphasis (smallest interface surface · widest future fit · smoothest default path for the most common caller · cleanest cross-boundary adapter), present them side by side compared on depth, locality, and seam placement, and let the captain pick one or fold a hybrid.

Durability gate (agent-enforced, no approval needed): spec and tickets carry contracts, never coordinates — no file paths, no line numbers. Fragments encoding a decision better than prose (state machines, reducers, schemas) are the exception and state their origin (usually a loft).

Testing decisions retire orphans: when a seam is deepened or replaced, the tests pinned to the old interface retire with it — new tests write to the new interface only. The testing rules themselves are seeded in `docs/standards/process.md`.


完成全部起草后，在**C2**处停止：提交验收标准和测试接缝列表供人类审批。如果任务是已接受的意图，C2 的提交内容还会附带意图类型检查清单：规格是否仍能解决意图的原始问题、带入的待解决问题是否都已考虑、高风险项在审批前是否已咨询技术负责人。测试接缝根据代码库证据和深模块原则（公共接口、现有测试接缝、深度分析；相关术语定义在 `docs/standards/architecture.md` 中）选择；人类确认或修正该列表——未经人类批准的接缝不会编写测试。每个接缝条目都会声明其**边界类别**——进程内、本地可替换、自有远程（带有生产和测试适配器的端口）、或纯外部（注入的替代项）——因为类别决定了接缝的测试方式。

**竞标规则。** 如果接口的形态本身存在争议——有两种合理的设计，都无法通过讨论确定——C2 会在备选方案之间*选择*签字，绝不会只对桌上的唯一提案签字：让并行的子 agents 起草候选形态，每个候选方案侧重不同的方向（最小接口表面积 · 最广的未来适配性 · 最常见调用方的最平滑默认路径 · 最整洁的跨边界适配器），将它们并排展示，从深度、局部性和接缝位置三个维度进行对比，让船长选择一个或组合出混合方案。

持久性门禁（由 Agent 强制执行，无需审批）：规格和工单承载的是契约，而非坐标——不包含文件路径，不包含行号。比文字更能清晰表达决策的片段（状态机、reducer、schema）是例外，但需要注明来源（通常来自 loft）。

测试决策会清理孤立测试：当接缝被深化或替换时，绑定到旧接口的测试会随之退役——新测试仅针对新接口编写。测试规则本身定义在 `docs/standards/process.md` 中。

Phase 3 — Ticket decomposition (agent drafts → C3 approves)

阶段 3 — 工单分解（Agent 起草 → C3 审批）

Split into vertical slices under

.omc/specs/<feature-slug>/tickets/

```
NN-slug.md
```
, one file per ticket, dependency-ordered, each declaring
```
blockedBy: [ids]
```
each ticket crosses every layer, is independently demonstrable, and fits one fresh context
blocking edges are load-bearing declarations: a ticket states what it waits on — which decisions, artifacts (specs, ADRs, loft results), or other tickets — not just which ticket numbers. The declaration is C3's input: granularity wrong here misroutes every dependency, and a ticket whose waits are undeclared cannot be scheduled honestly on the frontier.
wide refactors go expand-contract: add the new form, migrate in batches, remove the old — each batch a ticket

Agent-side mechanical validation runs first (independence, demonstrability, context fit). Then C3: present granularity, blocking edges, and proposed merges/splits for human approval. Iterate until approved. Mark every ticket

ready-for-agent

. The C3 bar: a fresh worker can start any ticket without a question back — a ticket that must ask sends the flaw up to the spec, not to the worker.

Integration-wiring rule: every vertical slice includes its own wiring and a smoke assertion — a slice whose output nothing mounts, serves, or imports is not done. Cross-slice seams that no single slice owns (route mounting, static serving, entry-point wiring) get an explicit integration ticket as the last frontier item.

在

.omc/specs/<feature-slug>/tickets/

目录下拆分为垂直切片：

```
NN-slug.md
```
，每个工单一个文件，按依赖顺序排列，每个都声明
```
blockedBy: [ids]
```
每个工单都跨越所有层级，可独立演示，且适配单个全新上下文
阻塞依赖是核心声明：工单需要说明它在等待什么——哪些决策、产物（规格、ADR、loft 结果）或其他工单——而不仅仅是工单编号。该声明是 C3 的输入：这里的粒度错误会导致所有依赖路由错误，而未声明等待项的工单无法在前沿任务中被合理调度。
大规模重构采用扩展-收缩模式：先添加新形式，批量迁移，再移除旧形式——每一批次对应一个工单

Agent 端会先运行机械性验证（独立性、可演示性、上下文适配性）。然后到C3：提交粒度、阻塞依赖以及提议的合并/拆分方案供人类审批。迭代直到通过审批。将每个工单标记为

ready-for-agent

。C3 的标准是：一个全新的工作者可以直接开始处理任何工单，无需回头提问——如果工单需要提问，说明缺陷出在规格层面，而非工作者的问题。

集成接线规则：每个垂直切片都包含自身的接线和冒烟断言——如果一个切片的输出没有任何东西挂载、提供或导入，那它就没有完成。不属于任何单个切片的跨切片接缝（路由挂载、静态服务、入口点接线）需要有一个明确的集成工单，作为最后一个前沿任务项。

Phase 4 — Run the frontier

阶段 4 — 推进前沿任务

The frontier is every ticket whose blockers are all complete.

Parallel (default, 2+ tickets). Hand tickets to team: each ticket becomes a team task,

blockedBy

edges carry over — team's claim mechanics pick only frontier tasks. Spawn N workers. Each worker implements with the tdd discipline at the seams approved in C2, applying

/oh-my-claudecode:minimal-code-discipline

as the writing-time discipline (it stays opt-in); a ticket closes only after code-review passes on the diff, declared by the reviewer — the implementer never self-approves.

Serial (single ticket, or
--serial
). Delegate one ticket at a time to an executor subagent; same review gate.

Two-axis review gate. The closing review runs along two axes, in parallel, reported separately — never merged or cross-ranked, because a change can pass one axis and fail the other (standards-conforming but wrong behavior; faithful but convention-breaking). The reviewer fails the ticket when either axis fails:

Standards axis — the diff against the matching
```
docs/standards/
```
volume, plus a judgement-call-only smell baseline (a documented repo standard overrides the baseline; anything tooling already enforces is skipped). This is the standing consumer that keeps the standards surfaces referenced.
Spec axis — the diff against this ticket's acceptance criteria (the spec is the total ledger the tickets were decomposed from; it is consulted only to trace where a criterion came from and to rule on smuggled scope — behavior no ticket asked for): requirements missing or partial, behavior nobody asked for, and requirements that look implemented but look wrong — each finding quoting its source line.

C4 — decisions that emerge mid-run. When a parallel Team worker hits a decision passing the ADR test, it stops before decision-dependent mutation, records the question (options, recommendation, reversibility note) in the failed transition's

error

field and

.omc/specs/<feature-slug>/decisions-pending.md

, and exits through Team's supported

in_progress

→

failed

transition. This is a terminal Launch outcome: do not reopen the task, create an in-run successor, force cleanup, or start another Team from this invocation. Surface the blocker with pointers to the failed task and decision artifact.

On a later explicit Launch invocation, first require the owning Team lifecycle to be terminal and cleaned up through its supported owner. Then batch every pending C4 question for the human, record the answers in the decision log/ADRs, and rebuild the ticket frontier before starting execution. All ticket dependencies are declared before dispatch: ticket

blockedBy

metadata maps to the public Team

blocked_by

field with numeric task IDs when tasks are created through the Team task API. Team's existing task-ID dependency resolution rejects early claims and makes dependents eligible only after their predecessors complete. The team lead never claims a task unless it is explicitly registered as a Team worker. Launch never dynamically mutates a claimed task's dependencies and never promises automatic re-dispatch after C4.

Serial C4 (
--serial
). The executor stops before decision-dependent mutation and returns the question without claiming completion. Record and resolve the human question at the batch boundary, then start a fresh executor successor with the recorded answer and remaining acceptance criteria. Do not replay or resume the interrupted executor context, and do not manufacture Team tasks when Team is not active.

Repeated failure stop. The same verification failure surviving three repair attempts halts that lane with a root-cause hypothesis for the human. This is the one condition that interrupts C4's batching immediately.

前沿任务是指所有阻塞项都已完成的工单。

并行（默认，2个及以上工单）。 将工单移交给 Team：每个工单变成一个 Team 任务，

blockedBy

依赖会同步过去——Team 的认领机制只会选取前沿任务。生成 N 个工作者。每个工作者在 C2 批准的接缝处遵循 TDD 原则进行实现，编写代码时应用

/oh-my-claudecode:minimal-code-discipline

（该规则为可选启用）；工单只有在评审人确认代码评审通过后才能关闭——实现者绝不能自行批准。

串行（单个工单，或使用
--serial
标志）。一次将一个工单委派给执行子 agent；评审门禁相同。

双轴评审门禁。 关闭评审会沿两个轴并行进行，分别报告——绝不合并或交叉排名，因为一项变更可能通过一个轴但未通过另一个（符合标准但行为错误；符合规格但违反约定）。只要任一轴未通过，评审人就会驳回工单：

标准轴 — 对照匹配的
```
docs/standards/
```
卷检查 diff，加上仅需主观判断的坏味道基线（已记录的仓库标准优先于基线；工具已经强制检查的内容会被跳过）。这是保持标准表层被持续引用的固定消费者。
规格轴 — 对照本工单的验收标准检查 diff（规格是工单分解的总台账；仅在追溯标准来源和裁定私自增加的范围——即任何工单都未要求的行为——时才会查阅规格）：缺失或不完整的需求、无人要求的行为、看似实现但实际错误的需求——每项发现都引用其来源行。

C4 — 运行过程中出现的决策。 当并行的 Team 工作者遇到一个通过 ADR 测试的决策时，会在进行依赖该决策的变更之前停止，将问题（选项、推荐方案、可逆性说明）记录在失败流转的

error

字段和

.omc/specs/<feature-slug>/decisions-pending.md

中，并通过 Team 支持的

in_progress

→

failed

流转退出。这是 Launch 的终止性结果：不要重新打开任务、创建运行中后续任务、强制清理，或从本次调用启动另一个 Team。展示阻塞项，并指向失败的任务和决策产物。

在后续的显式 Launch 调用中，首先要求所属 Team 的生命周期已终止，并通过其支持的所有者完成清理。然后将所有待处理的 C4 问题批量提交给人类，将答案记录在决策日志/ADR 中，在开始执行前重建工单前沿任务列表。所有工单依赖都在分发前声明：通过 Team 任务 API 创建任务时，工单的

blockedBy

元数据会映射为公开的 Team

blocked_by

字段，并附带数字任务 ID。Team 现有的任务 ID 依赖解析机制会拒绝提前认领，仅在前置任务完成后，依赖任务才会变为可认领状态。团队负责人绝不会认领任务，除非被显式注册为 Team 工作者。Launch 绝不会动态修改已认领任务的依赖，也绝不承诺 C4 之后会自动重新分发。

串行 C4（
--serial
模式）。执行器会在进行依赖决策的变更之前停止，返回问题，不声称完成。在批量边界处记录并解决人类的问题，然后使用记录的答案和剩余的验收标准启动一个全新的后续执行器。不要重放或恢复被中断的执行器上下文，在 Team 未激活时也不要制造 Team 任务。

重复失败停止。 同一验证失败经过三次修复尝试仍存在的，会暂停该流水线，并向人类提交根本原因假设。这是唯一会立即中断 C4 批量处理的情况。

Phase 5 — Closeout (agent reports → C5 accepts)

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

all tickets terminal with evidence → run verify across the whole change
reconcile the paper trail: CONTEXT.md accurate, ADRs complete, spec updated where implementation taught it something
yard re-check: re-run the drydock
```
--check
```
audit; any new findings since entry are reported as yard drift, with a pointer to
```
/oh-my-claudecode:drydock
```

sediment pass — answer: what did this ship teach the yard? Consume a structured retro first — what was built (the shipped scope in one line per slice), what broke (every failure that surfaced: three-strike root causes, verify findings), what taught (C4 answers, review rejections, and any map resolutions or deferred-sediment lines from a source map this run followed), and where the environment dragged (wayfinding friction, checks that ran too slow or too late, standards gaps that forced guesswork, tools that no-op'd, information that was harder to reach than it should have been) — then answer. Propose every lesson as

lesson → slot → intended change

against the slot table below, or decline it explicitly with a reason; a ship with nothing to teach must say so verbatim as "no new lessons". This requirement blocks non-answers, never empty answers — inventing lessons to have one is the same violation as skipping the question. The lesson list rides in the completion report next to the Open Assumptions, each line individually vetoable; approved lessons are written to their slots only after acceptance, and the report records each landing's file location. Before writing any lesson into a slot, call the Skill tool with

agent-doc-discipline

and apply its rules; the sediment pass is complete only after the skill's verification checklist passes.

Lesson kind	Slot
terms and boundaries settled mid-run	`CONTEXT.md` glossary
checkable behavior rules (carry a why)	`docs/standards/` matching volume (architecture / data / process)
most-violated conventions (thin-entry grade)	`CLAUDE.md` body — propose only
hard-to-reverse decisions	`docs/adr/` (C4 answers already land here)
ruled-out directions (concept + why rejected)	`docs/adr/` (a rejection is a decision too; the why is the load-bearing part)
business rules / background	`docs/business/`
UI patterns / component contracts	`design-system/`
reusable craft	`.omc/skills/` (through the skillify gate)
repeatedly needed automation / integrations	`scripts/` or `.mcp.json`
no slot fits	decline explicitly with the reason

thin-entry budget: the
```
CLAUDE.md
```
body carries at most five hot entries. A lesson is thin-entry grade only when the source checklist evidences the same violation at least twice in this run, or the captain marks it load-bearing. Entries are listed most-recently-promoted first; the coldest entry is deterministically the last one listed, and a promotion over budget must demote exactly that entry in the same proposal, moving its full text back to
```
docs/standards/
```
— nothing is deleted, only re-tiered. Bloat is rebalanced ship by ship and is deliberately not a
```
--check
```
finding.
state the run numbers in the completion report: tickets completed, C4 decisions surfaced, three-strike halts, and sediment lines proposed — plain facts in the report text, no telemetry system, no state files
emit the completion report: shipped scope, verification evidence, paper-trail locations, yard-drift findings (if any), the sediment list (each line vetoable), and Open Assumptions ranked by how much a human would likely want to veto them

所有工单都已终止且有证据支撑 → 对整个变更运行 verify
核对审计轨迹：
```
CONTEXT.md
```
准确无误，ADR 完整，规格在实现过程中获得的新认知已更新
船坞复检：重新运行 drydock
```
--check
```
审计；自入口以来的所有新发现都会作为船坞漂移上报，并指向
```
/oh-my-claudecode:drydock
```

沉淀环节——回答：这艘船教会了船坞什么？ 首先进行结构化复盘——构建了什么（已交付范围，每个切片一行）、出了什么问题（所有出现的失败：三次重试的根本原因、verify 发现）、学到了什么（C4 答复、评审驳回、以及本次运行遵循的源地图中的任何地图决议或 deferred-sediment 条目）、以及环境拖后腿的地方（导航摩擦、检查运行太慢或太晚、迫使猜测的标准缺口、无效的工具、比预期更难获取的信息）——然后给出答案。按照下表的槽位，将每条经验以「经验 → 槽位 → 预期变更」的形式提出，或者明确拒绝并说明理由；没有可传授经验的项目必须逐字说明「无新经验」。该要求禁止不回答，但不禁止空答案——编造经验和跳过问题是同样的违规行为。经验列表会和开放假设一起放在完成报告中，每行都可单独否决；已批准的经验仅在验收后才会写入对应的槽位，报告中会记录每条经验的落地文件位置。在将任何经验写入槽位之前，调用 Skill 工具的

agent-doc-discipline

并应用其规则；沉淀环节仅在该 skill 的验证检查清单通过后才算完成。

经验类型	槽位
运行过程中确定的术语和边界	`CONTEXT.md` 术语表
可检查的行为规则（附带原因）	`docs/standards/` 对应卷（架构 / 数据 / 流程）
最常违反的约定（薄条目级别）	`CLAUDE.md` 正文 — 仅提议
难以逆转的决策	`docs/adr/` （C4 答复已经落地在此）
被排除的方向（概念 + 拒绝原因）	`docs/adr/` （拒绝也是一种决策；原因是核心）
业务规则 / 背景信息	`docs/business/`
UI 模式 / 组件契约	`design-system/`
可复用的工艺	`.omc/skills/` （通过 skillify 门禁）
反复需要的自动化 / 集成	`scripts/` 或 `.mcp.json`
无合适槽位	明确拒绝并说明理由

薄条目预算：
```
CLAUDE.md
```
正文最多承载 5 条热门条目。一条经验只有在源检查清单证明本次运行中同一违规至少出现两次，或船长标记其为核心项时，才达到薄条目级别。条目按最近提升顺序排列；最冷的条目固定是列表的最后一个，超出预算的提升必须在同一份提案中将该条目降级，将其完整文本移回
```
docs/standards/
```
——不会删除任何内容，只是重新分级。臃肿问题会逐项目重新平衡，且刻意不将其作为
```
--check
```
的发现项。
在完成报告中说明运行数据：已完工单数量、出现的 C4 决策数量、三次重试暂停次数、提出的沉淀条目数量——都是报告文本中的简单事实，没有遥测系统，没有状态文件
输出完成报告：已交付范围、验证证据、审计轨迹位置、船坞漂移发现（如有）、沉淀列表（每行都可否决）、以及按人类可能想否决的程度排序的开放假设

Context hygiene

上下文卫生

Phases 1–3 in one unbroken context window; compact at phase boundaries only (HUD high water is the signal).
Disk is the primary source; conversation memory is secondary. Every boundary action except continuing converts the primary source into a secondary one — so after any boundary, re-read the artifacts from disk and never continue from remembered state.
The four-way boundary choice: continue (context still fits and is unpolluted) → re-enter from disk (a phase just completed) → hand off (pointer, never content) → compact (approaching the limit, at the phase edge). Take the first that fits.
Long headless runs: prefer
```
--output-format stream-json
```
(or periodic progress markers) so the orchestrator sees liveness — plain text mode emits nothing until the turn ends.
Phase 4 runs in fresh contexts per ticket by construction (team workers or subagents).
Handoffs pass pointers, never content. A handoff paper carries three things only: pointers (where the material and the decisions live — never copies), the next watch (what the next phase does, and which skills to call), and the warning lines (red lines already ruled out; credentials redacted). When a compact is unavoidable, pass an instruction with it, so the summary keeps what the next phase needs.
Planned session handoff: when a session must end mid-effort by design — context budget, scheduled boundary, a deliberate pause — it compresses itself into a handoff artifact beside the run's other artifacts: what settled (decisions with their pointers), what is open (frontier questions), what state the run is in, and nothing else. No raw transcript, no chat history. The next session re-orients from the artifact, never from memory — the same re-orientation rule the navigator's map follows. Handoff is the proactive twin of crash recovery below: one governs planned transfer, the other governs a session that died.
Session died mid-run: preserve the artifacts and stop. A later explicit invocation may continue only after the owning Team lifecycle reaches its supported terminal/cleanup boundary; Team remains authoritative for runtime state.

阶段 1–3 在一个不间断的上下文窗口中运行；仅在阶段边界处进行压缩（以 HUD 高水位为信号）。
磁盘是主要来源；会话记忆是次要的。 除了继续之外的所有边界操作都会将主要来源转换为次要来源——因此在任何边界之后，都要从磁盘重新读取产物，绝不能从记忆中的状态继续。
四选一边界决策： 继续（上下文仍足够且未被污染）→ 从磁盘重新进入（某个阶段刚完成）→ 移交（仅指针，不传递内容）→ 压缩（接近限制，在阶段边缘）。选择第一个符合条件的选项。
长时间无头运行：优先使用
```
--output-format stream-json
```
（或周期性进度标记），以便编排器能看到存活状态——纯文本模式在回合结束前不会输出任何内容。
阶段 4 按设计在每个工单的全新上下文中运行（Team 工作者或子 agent）。
移交仅传递指针，不传递内容。移交单只包含三样东西：指针（材料和决策的存放位置——绝不复制）、下一班职责（下一阶段做什么，需要调用哪些 skill）、以及警示线（已经排除的红线；已脱敏的凭证）。当不可避免要进行压缩时，要附带一条说明，确保摘要保留下一阶段需要的内容。
计划内会话移交： 当会话按设计必须在工作中途结束时——上下文预算、预定边界、刻意暂停——它会将自身压缩为一个移交产物，放在运行的其他产物旁边：已确定的内容（决策及其指针）、待解决的内容（前沿问题）、运行所处的状态，仅此而已。没有原始转录，没有聊天历史。下一个会话会从该产物重新定位，绝不是从记忆中——这和导航员地图遵循的重新定位规则相同。移交是下面崩溃恢复的主动版本：一个管理计划内的转移，一个管理意外终止的会话。
会话在运行中途终止：保留产物并停止。后续的显式调用仅在所属 Team 的生命周期到达其支持的终止/清理边界后才能继续；Team 仍是运行时状态的权威来源。

Completion definition

完成定义

All tickets terminal with evidence, verify clean on the whole change, paper trail reconciled, report emitted — and every decision the agents made on the human's behalf is answerable with one pointer to where it was recorded.

所有工单都已终止且有证据支撑，整个变更的 verify 结果干净，审计轨迹已核对，报告已输出——并且 agents 代表人类做出的每一项决策，都能通过一个指向其记录位置的指针来追溯。