ask-navigator

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Ask Navigator

Ask-navigator is the shipyard's navigator: it takes an effort wrapped in fog — the way from here to the destination isn't visible yet — and charts it as a map of decision tickets on the repo's issue tracker, then works the frontier one ticket per session until the route is clear. It produces decisions, never deliverables: when the way is clear it hands off, it doesn't build. Delivery belongs to

/oh-my-claudecode:launch

The role contract. The captain (the human) signs the destination (W1) and the chart (W2); the navigator drafts everything else and never answers a question that belongs to the captain — a grilling session in which the agent answers its own questions has broken the role, not just the process. Facts are the navigator's job; decisions are the captain's.

Fog test. An effort has fog when either answer is no:

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 of them can be answered yet?

Both yes → no map is needed; run

/oh-my-claudecode:launch

(its fog gate sends efforts here only when an answer is no). Either no → chart first.

ask-navigator

is also reachable directly: invoke it with a loose idea, with residual questions handed over by launch's fog gate, or with no argument to continue the open map.

Ask-navigator是Shipyard的导航员：它将一项笼罩在迷雾中的工作——从当前位置到目标的路径尚不可见——规划为仓库issue追踪器上的决策工单地图，随后每次会话处理前沿的一个工单，直到路径清晰。它产出决策，而非可交付成果：路径清晰后它就会移交，不会进行构建。交付工作属于

/oh-my-claudecode:launch

。

角色契约。船长（人类）负责签署目标（W1）和规划图（W2）；导航员负责起草其他所有内容，并且绝不回答属于船长的问题——如果出现Agent自行回答问题的grilling会话，那已经破坏了角色契约，而不仅仅是流程。事实是导航员的工作；决策是船长的职责。

迷雾测试。只要有一个问题的答案为“否”，这项工作就存在迷雾：

Q1——能否用一句话描述目标：这项工作要达成的规范、决策或变更是什么？
Q2——能否在当前就精确地列出前三个决策，即使它们目前都无法得到答案？

两个答案都为“是”→ 不需要地图；直接运行

/oh-my-claudecode:launch

（它的迷雾闸门只会在有一个答案为否时才将工作转到这里）。任意一个答案为“否”→ 先做规划。

ask-navigator

也可以直接调用：用一个模糊的想法调用它，或者传入launch的迷雾闸门移交的遗留问题，或者不带参数以继续进行中的地图。

Map home

地图载体

The map is a single issue labelled

navigator:map

on the repo's issue tracker; its decision tickets are child issues of the map. The tracker should have been recorded by

/oh-my-claudecode:drydock

; if none was recorded, ask once (GitHub / GitLab / local markdown) and remember the answer inside the map's Notes.

Tracker-backed (GitHub, GitLab, or recorded tracker): one map issue, child issues per ticket, native blocking/sub-issue relationships. Concurrent sessions and the tracker's own UI render the frontier — the map lives where humans already look. Create the
```
navigator:map
```
label if the tracker doesn't have it yet; ticket types live in the ticket body, not in labels.
Local markdown fallback:
```
.omc/wayfinder/<map-slug>/map.md
```
plus
```
decisions/NN-<slug>.md
```
, one file per ticket, numbered in dependency order. Local mode has no concurrent-claim guarantee: it is single-driver by convention, stated once in the map's Notes.

The map is an index, not a store: a decision lives in exactly one place — its ticket. The map gists each resolution in one line and links; it never restates the detail.

地图是仓库issue追踪器中一个标记为

navigator:map

的单独issue；它的决策工单是该地图issue的子issue。追踪器应该已经由

/oh-my-claudecode:drydock

记录过；如果没有记录，询问一次（GitHub / GitLab / 本地markdown）并将答案记录在地图的Notes中。

基于追踪器（GitHub、GitLab或已记录的追踪器）：一个地图issue，每个工单对应一个子issue，使用原生的阻塞/子issue关系。并发会话和追踪器自身的UI会展示前沿——地图就存在于人们已经在看的地方。如果追踪器还没有
```
navigator:map
```
标签，就创建它；工单类型写在工单正文中，而非标签中。
本地markdown备用方案：
```
.omc/wayfinder/<map-slug>/map.md
```
加上
```
decisions/NN-<slug>.md
```
，每个工单对应一个文件，按依赖顺序编号。本地模式没有并发认领保证：按照约定为单操作者模式，会在地图的Notes中说明一次。

地图是索引，而非存储：决策只存在于唯一的位置——它的工单。地图用一行摘要记录每个决议并附上链接；绝不会重述细节。

Document language

文档语言

Map and ticket prose follow the same document-language contract as

/oh-my-claudecode:drydock

: read

documentLanguage

from

CONTEXT.md

frontmatter when present; if the yard is not laid, ask the language question once during charting (W2) and record the resolved tag in the map's Notes so the later launch run inherits it. Paths, labels, slash commands, the

navigator:map

label, ticket-type names (

research

loft

grilling

task

HITL

AFK

, and

blockedBy

are stable tokens and stay byte-for-byte stable in every language.

地图和工单的文案遵循与

/oh-my-claudecode:drydock

相同的文档语言契约：如果存在

CONTEXT.md

，从其frontmatter中读取

documentLanguage

；如果造船厂尚未搭建，在规划阶段（W2）询问一次语言问题，并将确定的标签记录在地图的Notes中，以便后续的launch运行继承该设置。路径、标签、斜杠命令、

navigator:map

标签、工单类型名称（

research

、

loft

、

grilling

、

task

）、

HITL

AFK

以及

blockedBy

都是稳定令牌，在任何语言中都保持字节级稳定。

Chart the map

规划地图

Invoked with a loose idea (or launch's residual questions). Charting is one session's work; it hand-resolves nothing.

Run the audit, defer the findings. Run the
```
/oh-my-claudecode:drydock
```
```
--check
```
audit in report-only mode — the mechanical subset via
```
node scripts/shipyard-audit.mjs
```
, the heuristic classes via the drydock prose audit: findings never block charting (a map produces decisions, not slot landings), but they are recorded verbatim in the map's Notes — launch's yard gate will collect that debt when the effort finally enters delivery. If the yard is not laid at all (no
```
CONTEXT.md
```
, no
```
docs/adr/
```
), offer
```
/oh-my-claudecode:drydock
```
once; if the captain declines, proceed in tracker-only mode and defer all sediment (see Sediment).
W1 — name the destination. Call the Skill tool with "deep-interview" and pin down what this map is finding its way to: the spec, decision, or change. The destination fixes the scope, so it is settled first. W1 is a captain signature: present the destination statement and get explicit confirmation. If the captain cannot state a destination even with the interview's help, that is not an error — present the best candidates ranked and let the captain pick one to chart toward or park the effort.
Map the frontier. Grill again with "deep-interview", breadth-first with frontier rounds (
```
--frontier
```
): fan out across the whole space rather than deep on any one thread — each round asks the whole frontier of decisions whose prerequisites are settled, then recomputes from the answers — surfacing the open decisions and the first steps takeable now. When charting against an existing map (residual questions or a redraw), read its Out of scope section before ticketing — ruled-out work never re-enters as a fresh ticket. If this surfaces no fog — the way to the destination is already clear and the journey fits one session — no map is needed: stop and recommend
```
/oh-my-claudecode:launch
```
.
W2 — sign the chart. Present the proposed map: destination, initial tickets with types and blocking edges, and the fog sketch. W2 is a captain signature: granularity wrong here wastes every later session. Iterate until signed.
Create the map and tickets. Label the map
```
navigator:map
```
; create child tickets; wire blocking edges in a second pass (issues need ids before they can reference each other). Everything not yet sharp enough to ticket stays in Not yet specified.
Fire the research subagents. For each
```
research
```
ticket just created, spawn a background subagent to resolve it in parallel (see Ticket types), capturing findings where the ticket can link them.
Stop with the session-close pointer: the map link, how many tickets are on the frontier, and "next session, run
```
/oh-my-claudecode:ask-navigator
```
to work the next decision."

使用模糊的想法（或launch的遗留问题）调用。规划是单次会话的工作；它不会手动解决任何问题。

运行审计，记录发现项。 以仅报告模式运行
```
/oh-my-claudecode:drydock
```
的
```
--check
```
审计——机械类检查通过
```
node scripts/shipyard-audit.mjs
```
执行，启发式类检查通过drydock文档审计执行：发现项永远不会阻塞规划（地图产出的是决策，而非槽位落地），但它们会被原样记录在地图的Notes中——launch的造船厂闸门会在工作最终进入交付阶段时处理这些债务。如果造船厂完全没有搭建（没有
```
CONTEXT.md
```
，没有
```
docs/adr/
```
），一次性推荐使用
```
/oh-my-claudecode:drydock
```
；如果船长拒绝，就以仅追踪器模式继续，并推迟所有沉淀（见沉淀）。
W1——确定目标。 调用Skill工具的"deep-interview"功能，明确这份地图要达成的目标：对应的规范、决策或变更。目标决定了范围，因此需要首先确定。W1是船长签字项：展示目标陈述并获得明确确认。 如果即使经过深度访谈，船长仍然无法描述目标，这不是错误——展示排名靠前的最佳候选方案，让船长选择一个作为规划方向，或者暂时搁置这项工作。
绘制前沿。 再次使用"deep-interview"进行追问，采用带前沿轮次的广度优先（
```
--frontier
```
）模式：在整个范围内展开，而非深入任何单条线程——每一轮都会询问所有前置条件已确定的前沿决策，然后根据答案重新计算——从而梳理出待解决的决策以及当前可执行的第一步。如果是基于现有地图进行规划（遗留问题或重绘），在创建工单前先阅读其Out of scope部分——已排除的工作绝不会作为新工单重新出现。如果此时发现没有迷雾——到达目标的路径已经清晰，且整个工作可以在一次会话内完成——则不需要地图：停止并推荐使用
```
/oh-my-claudecode:launch
```
。
W2——签署规划图。 展示拟定的地图：目标、带类型和阻塞关系的初始工单，以及迷雾概览。W2是船长签字项：这里的粒度错误会浪费后续每一次会话的时间。反复迭代直到签署确认。
创建地图和工单。 给地图打上
```
navigator:map
```
标签；创建子工单；在第二步中连接阻塞边（issue需要先有ID才能互相引用）。所有还不够明确、无法创建工单的内容都留在Not yet specified中。
启动调研子Agent。 为刚创建的每个
```
research
```
工单，生成一个后台子Agent并行解决（见工单类型），并将发现结果记录在工单可以链接到的位置。
停止并给出会话结束提示：地图链接、前沿工单数量，以及“下次会话运行
```
/oh-my-claudecode:ask-navigator
```
来处理下一个决策。”

Work through the map

推进地图工作

Invoked with a map (link or number) or with no argument (pick up the open map). A ticket is optional: without one, take the next frontier ticket, not one the captain must choose.

Load the map: the low-res view, never every ticket body. Zoom into a ticket's full body on demand.
Claim before work: assign the ticket to the captain (tracker) or set
```
Claimed-by
```
(local) first, so concurrent sessions skip it. An open, unclaimed ticket is unclaimed. If assignment isn't possible (permissions, no handle), record the claim in a ticket comment instead.
Resolve it according to its type (see Ticket types). Zoom as needed; call the Skill tool with "deep-interview" whenever the resolution needs the captain's input.
Record the resolution: post the answer as a resolution comment/section, close the ticket (as completed; a ticket ruled beyond the destination closes as not planned), and append one line to the map's Decisions so far —
```
[<ticket title>](link): <one-line gist>
```
.
Advance the frontier: graduate any fog the answer has made specifiable (remove it from Not yet specified, create the new tickets, wire edges); if the answer reveals a ticket sits beyond the destination, close it and leave one line in Out of scope carrying the concept and the reason (so a later session or a later map can match it); update or delete tickets the decision invalidated.
Sediment (see Sediment).
Stop after one ticket. One resolution per session is the cadence — it is the context-window budget, not a policy. The session-close pointer names what just resolved and what is now on the frontier. The map issue is the primary source, session memory secondary — every session re-orients from the map, never from the previous session's memory.

使用地图（链接或编号）调用，或不带参数调用（接手进行中的地图）。工单参数是可选的：如果没有指定，就取下一个前沿工单，而不是让船长选择。

加载地图：先看概览视图，绝不直接加载所有工单内容。按需深入查看工单的完整正文。
工作前先认领：首先将工单分配给船长（追踪器模式）或设置
```
Claimed-by
```
（本地模式）首先，这样并发会话就会跳过它。一个开放的、未被认领的工单就是未认领状态。如果无法分配（权限问题、没有账号），就将认领信息记录在工单评论中。
解决工单 根据其类型（见工单类型）。按需深入查看；当决议需要船长输入时，调用Skill工具的"deep-interview"功能。
记录决议：将答案作为决议评论/章节发布，关闭工单（已完成；如果被判定超出目标范围，则以not planned状态关闭），并在地图的Decisions so far中追加一行——
```
[<工单标题>](链接): <一行摘要>
```
。
推进前沿：将答案带来的、已经可以明确的迷雾内容升级（从Not yet specified中移除，创建新工单，连接依赖边）；如果答案显示某个工单超出了目标范围，关闭它并在Out of scope中留下一行说明，记录该概念和原因（以便后续会话或后续地图可以匹配到）；更新或删除被该决策作废的工单。
沉淀（见沉淀）。
处理一个工单后停止。 每次会话解决一个问题是固定节奏——这是上下文窗口的预算限制，而非硬性政策。会话结束提示会说明刚解决的内容以及当前前沿的工单。地图issue是主要信息来源，会话记忆是次要的——每次会话都从地图重新定位，而不是依赖上一次会话的记忆。

Large efforts — the map outlives the session

大型工作——地图的生命周期超过单次会话

When charting reveals an effort whose frontier no number of sessions is likely to clear quickly — decisions fanning out across several independent threads, a destination that keeps opening new fog — the map itself becomes long-lived rather than a short stop on the way to launch:

Decisions group into vessels: independent threads of the frontier are named as vessels in the map's Notes, each carrying its child tickets, so any session can orient to one thread without re-reading the whole space.
The map issue carries a census line: one line stating the open-ticket count per vessel and what the current frontier is, refreshed every session — a session that reads only the map knows where the effort stands.
The one-ticket-per-session budget is spent on the map's frontier in priority order across any number of sessions — the cadence never changes; only the horizon does.

Long-lived is a property of the map, not a mode switch: the same map issue, the same child tickets, the same rules. When the fog finally clears, the exit is unchanged — collapse the decisions into the mission brief and hand off.

当规划显示某项工作的前沿不太可能在有限次数的会话内快速澄清时——决策在多个独立线程中发散，目标不断产生新的迷雾——地图本身就会变成长期存在的，而非通往launch路上的短暂停留：

决策分组为船只：前沿的独立线程会在地图的Notes中被命名为船只，每个船只包含其下的子工单，这样任何会话都可以聚焦于一条线程，而无需重新阅读整个范围。
地图issue包含一行统计信息：这行信息说明每个船只的未完工单数量以及当前前沿是什么，每次会话都会更新——只看地图的会话也能了解工作进展。
每次会话的一个工单预算会按优先级顺序用于处理地图的前沿——可以跨越任意多次会话——节奏永远不变；改变的只是视野范围。

长期性是地图的属性，而非模式切换：同一个地图issue，同样的子工单，同样的规则。当迷雾最终消散时，退出方式不变——将决策汇总为任务简报并移交。

Ticket types

工单类型

Every ticket is HITL (worked with the captain, who speaks for themselves) or AFK (driven by the navigator alone). A HITL ticket only resolves through live exchange; the agent never stands in for the captain's side.

Type	Mode	Resolved by	Use when
`research`	AFK	Background subagent: investigate against primary sources (official docs, source code, specs), leave a cited Markdown file at `docs/research/<ticket-slug>.md` (or the repo's existing notes convention when one exists), link it from the ticket	A decision waits on knowledge outside the current working directory
`loft`	HITL	Call the Skill tool with "loft": a throwaway artifact answers the ticket's question — a pure logic module in a clickable shell, or structurally different UI variants behind one route; the captain reacts, the answer folds into the resolution, the artifact stays on a `loft/<name>` branch	The question is precise but prose cannot settle it — it needs to be seen or clicked, not described
`grilling`	HITL	Call the Skill tool with "deep-interview"; the captain decides each round	Conversation is the resolution — the default case
`task`	HITL or AFK	The navigator drives it alone where it can; otherwise hands the captain a precise checklist	Manual work that unblocks a decision (sign up for a service, provision access, move data so its shape can be seen) — it earns its place by unblocking a decision, not by delivering the destination

The answer is never part of the ticket body; it is recorded on resolution. Assets created while resolving are linked from the ticket, not pasted in.

research

ticket whose knowledge lives in a person rather than a document resolves by asking that person directly: one tracker comment naming them (per the granted communication scope), carrying everything they need to answer in one read, and their reply is cited as the primary source — the same standard a document source would meet. No third party is cold-contacted; a person the evidence does not name gets no question. The resolution records who answered and where, so the map's index points at the reply, not at a paraphrase.

research

file speaks the yard's one evidence format: it opens by restating the question it answers, every claim links its source, and it closes with an Unverified section — what could not be confirmed, and why it matters.

每个工单都是HITL（与船长协作处理，船长代表自己发言）或AFK（由导航员独立驱动）。HITL工单只能通过实时交流解决；Agent绝不代替船长发言。

类型	模式	解决方式	使用场景
`research`	AFK	后台子Agent：基于一手资料（官方文档、源代码、规范）进行调研，在 `docs/research/<ticket-slug>.md` （或仓库已有的笔记规范）中生成带引用的Markdown文件，并在工单中添加链接	某项决策依赖当前工作目录之外的知识时
`loft`	HITL	调用Skill工具的"loft"功能：用临时产物回答工单的问题——可以是可点击外壳中的纯逻辑模块，或是同一路由下结构不同的UI变体；由船长给出反馈，答案会被纳入决议，该产物保留在 `loft/<name>` 分支上	问题足够明确，但无法通过文字解决——需要亲眼看到或点击操作，而非描述
`grilling`	HITL	调用Skill工具的"deep-interview"功能；由船长决定每一轮的结果	对话本身就是解决方案——默认场景
`task`	HITL 或 AFK	导航员能独立完成的就自行处理；否则向船长提供一份精确的检查清单	为决策扫清障碍的手动工作（注册服务、配置权限、移动数据以查看其结构）——它的存在意义是为决策解锁，而非交付最终目标

答案永远不会是工单正文的一部分；它会在解决时记录。解决过程中创建的资产会从工单链接出去，而非粘贴在工单中。

如果一个

research

工单所需的知识存在于某个人而非文档中，解决方式是直接询问那个人：在追踪器中发一条评论提及对方（根据已授予的沟通范围），包含对方一次阅读就能回答的所有信息，对方的回复会被作为一手资料引用——与文档来源的标准相同。绝不会主动联系第三方；如果证据没有提到某个人，就不会向其提问。决议会记录回答者和回答位置，这样地图的索引会指向回复本身，而非转述内容。

research

文件遵循造船厂的统一证据格式：开头重述它要回答的问题，每个声明都链接到来源，结尾有一个Unverified部分——列出哪些内容无法确认，以及为什么重要。

Map body

地图正文

markdown

undefined

markdown

undefined

Destination

Notes

<domain; skills every session should consult; standing preferences; deferred drydock --check findings (verbatim); resolved documentLanguage tag; tracker-mode caveats for local mode>

Decisions so far

<closed ticket title>: <one-line gist of the answer>

<closed ticket title>: <one-line gist of the answer>

Not yet specified

Out of scope


**Fog or ticket?** The test is whether you can state the question precisely now, not whether you can answer it now. Ticket when the question is already sharp, even if it is blocked. Not-yet-specified when you cannot phrase it that sharply — do not pre-slice the fog into ticket-sized pieces; one patch may graduate into several tickets, or none. **Out of scope** is a scoping act, not a step on the route: scope, not sharpness, lands work there, and it returns only if the destination is redrawn.


**迷雾还是工单？** 判断标准是你现在能否精确地表述问题，而非你现在能否回答它。当问题已经足够明确时就创建工单，即使它被阻塞了。当你还无法如此清晰地表述时，就放在待明确中——不要提前把迷雾切成工单大小的碎片；一块迷雾可能会升级为多个工单，也可能一个都不会。**Out of scope**是范围界定行为，而非路线上的一步：是范围而非明确度决定了工作是否放在这里，并且只有当目标重绘时才会重新纳入。

Sediment

沉淀

Resolutions land in the shipyard's paper trail the moment they settle — the same slots launch's Phase 1 uses:

a term the resolutions settled or sharpened →
```
CONTEXT.md
```
glossary (one entry: definition, boundary, resolved ambiguity)
a decision passing the ADR test (hard to reverse, surprising without context, a real tradeoff) →
```
docs/adr/NNNN-<slug>.md
```
a business rule or background fact →
```
docs/business/
```
(one article per business question)

When the yard is not laid (the captain declined drydock at charting time), defer, don't skip: record each pending landing as one line in the map's Notes under a

Deferred sediment

heading. The later

/oh-my-claudecode:launch

run's yard gate treats the un-laid surfaces as findings, and the deferred lines tell it exactly what to land first.

决议一旦确定就会立即存入造船厂的文档记录中——与launch第一阶段使用的槽位相同：

决议确定或明确的术语 →
```
CONTEXT.md
```
术语表（一个条目：定义、边界、已解决的歧义）
通过ADR测试的决策（难以逆转、没有上下文会令人意外、是真实的权衡） →
```
docs/adr/NNNN-<slug>.md
```
业务规则或背景事实 →
```
docs/business/
```
（每个业务问题对应一篇文章）

如果造船厂尚未搭建（船长在规划阶段拒绝了drydock），推迟而非跳过：在地图的Notes中

Deferred sediment

标题下，将每个待落地内容记录为一行。后续

/oh-my-claudecode:launch

运行的造船厂闸门会将未搭建的部分视为发现项，而这些推迟的行会明确告诉它首先要落地什么。

Exit — hand off, don't build

退出——移交，而非构建

The map is done when no open tickets remain and Not yet specified is empty. Then:

Collapse Decisions so far into a mission brief: objective, scope boundary, non-goals — writable now because the way is clear. Write it to
```
.omc/wayfinder/<map-slug>/brief.md
```
so the handoff passes a pointer, not content.
Recommend: "The way is clear. Run
```
/oh-my-claudecode:launch
```
with the brief at
```
.omc/wayfinder/<map-slug>/brief.md
```
." The map stays as the effort's logbook; launch's yard gate owns every check from there.
Default entry is launch Phase 1 (the paper trail is already half-full; its frontier clears fast). Only when the decisions already read like a spec may a spec be drafted and launch entered at Phase 2 with the spec path.

当没有未完成的工单且Not yet specified为空时，地图就完成了。此时：

将Decisions so far汇总为一份任务简报：目标、范围边界、非目标——现在可以编写了，因为路径已经清晰。将其写入
```
.omc/wayfinder/<map-slug>/brief.md
```
，这样移交的是一个指针，而非内容。
推荐：“路径已清晰。使用
```
.omc/wayfinder/<map-slug>/brief.md
```
中的简报运行
```
/oh-my-claudecode:launch
```
。” 地图会作为工作的日志保留；从那里开始，所有检查都由launch的造船厂闸门负责。
默认进入launch第一阶段（文档记录已经完成了一半；它的前沿会很快澄清）。只有当决策读起来已经像规范时，才可以起草规范，并以规范路径进入launch第二阶段。

Scope and non-goals

范围与非目标

No daemon, no mode, no always-on behavior, no runtime state machine: the map is ordinary tracker issues or repo files.
Incoming requests that arrive as fog are the harbor's to route: a fuzzy issue handed over by
```
/oh-my-claudecode:harbor
```
charts like any loose idea, with the original thread and any signed decision links as material.
Never mutates Team lifecycle, task statuses, or runtime state; never publishes delivery tickets — vertical-slice build tickets belong to launch's C3, and the navigator must not pre-slice fog into them.
Never executes a decision beyond recording it. The one exception is a
```
task
```
ticket, which does only what unblocks a decision.
The map's Decisions-so-far is an index; a decision lives in exactly one place, its ticket.

没有守护进程、没有模式、没有始终运行的行为、没有运行时状态机：地图就是普通的追踪器issue或仓库文件。
以迷雾形式到达的传入请求由harbor负责路由：由
```
/oh-my-claudecode:harbor
```
移交的模糊issue会像任何模糊想法一样进行规划，原始线程和任何已签署的决策链接都会作为参考材料。
绝不会修改团队生命周期、任务状态或运行时状态；绝不会发布交付工单——垂直切片构建工单属于launch的C3，导航员绝不能提前把迷雾切成这些工单。
除了记录决策之外，绝不执行决策。唯一的例外是
```
task
```
工单，它只做能为决策解锁的工作。
地图的Decisions so far是索引；决策只存在于唯一的位置——它的工单。

Completion definition

完成定义

A charting session ends with a captain-signed map and fired research tickets. A working session ends with exactly one resolution recorded, the frontier advanced, and the session-close pointer emitted. The effort ends when the way is clear and the mission brief is in the captain's hands with

/oh-my-claudecode:launch

recommended — every decision the navigator made on the captain's behalf answerable with one pointer to where it was recorded.

规划会话的结束标志是有一份船长签字的地图，并且调研工单已启动。工作会话的结束标志是恰好记录了一个决议、前沿已推进，并且发出了会话结束提示。工作的结束标志是路径已清晰，任务简报已交到船长手中，并且推荐了

/oh-my-claudecode:launch

——导航员代表船长做出的每一个决策都可以通过一个指针追溯到记录位置。