@namewta/speculo 0.2.16 → 0.3.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@namewta/speculo",
-  "version": "0.2.16",
+  "version": "0.3.0",
   "description": "Workflow-packaged specification-driven development assets with install, update, and migration tooling.",
   "type": "module",
   "bin": {

package/template/canonical/README.md

@@ -86,3 +86,4 @@ Canonical 文档是源文件的**透明容器**——去除 Speculo 内部元数
 
 - **Workflow 体积**：workflow 文件较多，生成的 canonical 文档较长。这属于预期行为——自包含性优先于简洁性。
 - **跨 workflow 引用**：如果能力引用了其他 workflow 的文件，在文档开头注明建议的配套上传文件和 GitHub 仓库地址。
+- **canonical-teach.md**：源在仓库外 vendor 目录（`temp/matt-pocock-skills/.../teach/`），不在 `template/` 内，不参与与 template 源文件的同步校验。

package/template/canonical/canonical-specdev-grill-with-docs.md

@@ -2,53 +2,52 @@
 
 组合 work——grilling 访谈技术 + domain-modeling 领域建模规程，在无情盘问中打磨设计，同时持续写入 ADR.md、LOG.md 和 CONTEXT.md 三个领域文档。访谈负责深度提问与共识达成，领域建模负责在决策结晶的瞬间捕获术语、记录轨迹、筛选架构决策。
 
-产物统一写入 `specdev/changes/{change}/`，其中 `{change}` 为 `<YYYY-MM-DD>-<topic>` 格式。
+产物统一写入变更目录 `specdev/changes/{change}/`，其中 `{change}` 为 `<YYYY-MM-DD>-<topic>` 格式。
 
 ## 流程
 
 ### 1. 启动变更
 
-创建 `specdev/changes/{change}/` 目录（`{change}` 为 `<YYYY-MM-DD>-<topic>` 格式），初始化三个空文件模板：
+创建变更目录 `specdev/changes/{change}/`（`{change}` 为 `<YYYY-MM-DD>-<topic>` 格式），初始化三个空文件模板及状态文件：
 
-- ADR.md — 架构决策记录，仅含 `# 架构决策记录` 标题
-- LOG.md — 设计决策日志，含 `# 设计决策日志` 标题及维护规则说明
-- CONTEXT.md — 领域词汇表，含 `# {主题} 领域词汇表` 标题及一两句描述
+- 变更目录下的 `.status.json` — 初始状态（`change_status: "active"`、`created_at` 为当前时间、`completed_at: null`、`archived: false`、`archive_path: null`）
+- 变更目录下的 ADR.md — 架构决策记录，仅含 `# 架构决策记录` 标题
+- 变更目录下的 LOG.md — 设计决策日志，含 `# 设计决策日志` 标题及维护规则说明
+- 变更目录下的 CONTEXT.md — 领域词汇表，含 `# {主题} 领域词汇表` 标题及一两句描述
 
-**完成标准**：变更目录 `<YYYY-MM-DD>-<topic>` 已创建，初始 ADR.md/LOG.md/CONTEXT.md 已就位。
+**完成标准**：变更目录 `<YYYY-MM-DD>-<topic>` 已创建，初始 .status.json、ADR.md、LOG.md、CONTEXT.md 已就位。
 
 ### 2. 访谈
 
-委托给 ``grilling-protocol``。一次一问，沿设计树逐分支推进，在用户确认共识之前不执行方案。访谈过程中随时更新 ``LOG``，记录每个确认、延后、替代的结论。
+委托给下方 `<grilling-protocol>` 标签中的完整协议。一次一问，沿设计树逐分支推进，在用户确认共识之前不执行方案。访谈过程中随时更新变更目录下的 LOG.md，记录每个确认、延后、替代的结论。
+
+若访谈中涉及不熟悉的外部技术、第三方 API、或需要查阅官方文档才能回答的设计问题，暂停访谈，调用 common/research skill 完成探查后再继续。
 
 **完成标准**：访谈完成——一次一问，决策树已遍历，共识已达成。LOG.md 已同步所有访谈结论。
 
 ### 3. 捕获文档
 
-委托给 ``domain-modeling-rules``。对照词汇表挑战术语、精炼模糊语言、讨论具体场景、与代码交叉引用。
-
-- ``LOG`` 同步所有结论
-- ``CONTEXT`` 精炼术语定义
-- ``ADR`` 仅追加满足三条件的架构决策（参见 ``adr-format``）
+委托给下方 `<domain-modeling-rules>` 标签中的完整规程。对照词汇表挑战术语、精炼模糊语言、讨论具体场景、与代码交叉引用。三文件按 grilling-protocol 规定的顺序同步（LOG → CONTEXT → ADR）。
 
 **完成标准**：LOG.md 已同步所有结论；CONTEXT.md 已精炼术语；ADR.md 已追加满足三条件的架构决策。
 
 ### 4. 停止
 
-设计阶段完成。向用户汇报产物摘要（LOG.md / CONTEXT.md / ADR.md 的条目数量和关键结论），明确询问是否进入 ``I-implement`` 实现阶段。
+设计阶段完成。向用户汇报产物摘要（LOG.md / CONTEXT.md / ADR.md 的条目数量和关键结论），明确询问是否进入实现阶段（I-implement）。
 
 不得在用户确认前自动读取实现源码或执行代码变更。
 
 ## 子文件引用
 
-本入口及以下子文件按需加载：
+本入口及以下子文件内容已内联于文末「参考内容」：
 
 | 文件 | 触发条件 |
 |------|----------|
-| ``grilling-protocol`` | 进入步骤 2「访谈」时加载——包含完整访谈协议，一次一问、推荐答案、决策树遍历、LOG.md 同步规则 |
-| ``domain-modeling-rules`` | 进入步骤 3「捕获文档」时加载——包含三文件分工、对照词汇表挑战、精炼与交叉引用规程、同步规则 |
-| ``adr-format`` | 需要创建或修改 ADR 条目时加载——单一 ADR.md 文件格式、编号规则、三条件检查、可选元素 |
-| ``context-format`` | 需要增删改术语时加载——CONTEXT.md 结构、定义规则、增删改操作说明 |
-| ``log-format`` | 需要记录设计结论时加载——LOG.md 格式、状态标记、编号规则、追加与修订规程 |
+| 下方 `<grilling-protocol>` 标签 | 进入步骤 2「访谈」时加载——包含完整访谈协议，一次一问、推荐答案、决策树遍历、LOG.md 同步规则 |
+| 下方 `<domain-modeling-rules>` 标签 | 进入步骤 3「捕获文档」时加载——包含三文件分工、对照词汇表挑战、精炼与交叉引用规程、同步规则 |
+| 下方 `<adr-format>` 标签 | 需要创建或修改 ADR 条目时加载——单一 ADR.md 文件格式、编号规则、三条件检查、可选元素 |
+| 下方 `<context-format>` 标签 | 需要增删改术语时加载——CONTEXT.md 结构、定义规则、增删改操作说明 |
+| 下方 `<log-format>` 标签 | 需要记录设计结论时加载——LOG.md 格式、状态标记、编号规则、追加与修订规程 |
 
 ---
 
@@ -90,13 +89,13 @@
 
 ## 访谈中维护三文件
 
-访谈中每完成一轮设计问答，按 参见下方 `<domain-modeling-rules>` 标签 规定的顺序同步三个文件：
+访谈中每完成一轮设计问答，按下方 `<domain-modeling-rules>` 标签规定的顺序同步三个文件：
 
 1. **LOG.md** 先更新——立即追加日志条目，记录本次讨论的结论
 2. **CONTEXT.md** 随后更新——从日志中提取新术语或修正的术语定义
 3. **ADR.md** 最后更新——检查是否需要追加满足三条件的架构决策
 
-在访谈过程中，每当一个结论被确认、延后或被替代时，当场更新 `LOG.md`。不要等访谈结束再批量写入——发生时立即捕获。具体格式参见 参见下方 `<log-format>` 标签。
+在访谈过程中，每当一个结论被确认、延后或被替代时，当场更新变更目录下的 LOG.md。不要等访谈结束再批量写入——发生时立即捕获。具体格式参见下方 `<log-format>` 标签。
 
 写入三文件的时机：
 
@@ -133,9 +132,9 @@
 
 | 文件 | 职责 | 维护方式 |
 |------|------|----------|
-| `LOG.md` | 完整设计轨迹——所有确认、延后、被替代的结论 | 持续增删改，条目可被后续决定修订 |
-| `CONTEXT.md` | 精炼的规范词汇表——只保留当前有效的术语 | 增删改，保持精炼 |
-| `ADR.md` | 难以逆转、令人意外、存在真实权衡的架构决策 | 只追加不删除，可标记废弃 |
+| 变更目录下的 LOG.md | 完整设计轨迹——所有确认、延后、被替代的结论 | 持续增删改，条目可被后续决定修订 |
+| 变更目录下的 CONTEXT.md | 精炼的规范词汇表——只保留当前有效的术语 | 增删改，保持精炼 |
+| 变更目录下的 ADR.md | 难以逆转、令人意外、存在真实权衡的架构决策 | 只追加不删除，可标记废弃 |
 
 ## 对照词汇表挑战
 
@@ -155,7 +154,7 @@
 
 ## 及时更新 LOG.md
 
-当设计问答中形成任何结论时，当场更新 `LOG.md`。它是完整的设计轨迹——记录"当时讨论了什么、最终固定了什么行为以及对应哪个 ADR"。不要批量处理——发生时立即捕获。具体格式参见 参见下方 `<log-format>` 标签。
+当设计问答中形成任何结论时，当场更新 `LOG.md`。它是完整的设计轨迹——记录"当时讨论了什么、最终固定了什么行为以及对应哪个 ADR"。不要批量处理——发生时立即捕获。具体格式参见下方 `<log-format>` 标签。
 
 ### 日志条目格式
 
@@ -168,15 +167,11 @@
 
 ### 维护规则
 
-- 每次完成设计问答，同步更新 `LOG.md`、`CONTEXT.md` 与 `ADR.md`。
-- 后续确认改变既有结论时，直接修订原日志条目，并记录替代关系，不保留互相矛盾的"现行规则"。
-- 日志可以记录具体交互和边界场景；词汇表保持精炼；ADR 只记录难以逆转、令人意外且存在真实权衡的决定。
-- 每个日志条目应关联对应的 ADR（如有）：`Related: ADR-XXXX`。
-- 状态为 `deferred` 的条目保留，以便后续恢复讨论时知道从什么问题开始。
+完整维护规则（状态、修订、关联 ADR）见下方 `<log-format>` 标签内的「维护规则」块；本文件只规定同步时机：每次完成设计问答后立即同步，不批量延后。
 
 ## 及时更新 CONTEXT.md
 
-当术语确定时，当场更新 `CONTEXT.md`。不要批量处理——发生时立即捕获。具体格式参见 参见下方 `<context-format>` 标签。
+当术语确定时，当场更新 `CONTEXT.md`。不要批量处理——发生时立即捕获。具体格式参见下方 `<context-format>` 标签。
 
 `CONTEXT.md` 应该完全不包含实现细节。不要将 `CONTEXT.md` 当作规范、草稿纸或实现决策的仓库。它只是词汇表，别无其他。
 
@@ -189,11 +184,11 @@
 
 仅在以下三个条件全部满足时才向 `ADR.md` 追加一条决策记录：
 
-1. **难以逆转**——以后改变主意的成本是有意义的
+1. **难以逆转**——以后改变主意的成本是实质性的
 2. **没有上下文会令人惊讶**——未来的读者会疑惑"他们为什么这样做？"
 3. **真实权衡的结果**——存在真正的替代方案，你出于特定原因选择了一个
 
-如果缺少任何一个条件，跳过 ADR。具体格式参见 参见下方 `<adr-format>` 标签。
+如果缺少任何一个条件，跳过 ADR。具体格式参见下方 `<adr-format>` 标签。
 
 `ADR.md` 中每个决策是一个 `## NNNN: {标题}` 二级标题，编号顺序递增，条目之间用 `---` 分隔。可以修改已有条目、标记废弃——但不要删除。
 
@@ -209,13 +204,7 @@
 
 ## 三文件同步规则
 
-访谈中每完成一轮设计问答，按以下顺序同步三个文件：
-
-1. **LOG.md** 先更新——立即追加日志条目，记录本次讨论的结论
-2. **CONTEXT.md** 随后更新——从日志中提取新术语或修正的术语定义
-3. **ADR.md** 最后更新——检查是否需要满足三条件追加 ADC（架构决策记录）
-
-如果 CONTEXT 或 ADR 的更新来自日志条目，在日志中补充 `Related: ADR-XXXX` 的关联标注。
+访谈中每完成一轮设计问答，按顺序同步：LOG.md → CONTEXT.md → ADR.md。完整时机与触发条件见下方 `<grilling-protocol>` 标签「访谈中维护三文件」。
 
 </domain-modeling-rules>
 
@@ -223,7 +212,9 @@
 
 # ADR.md 格式
 
-所有架构决策记录存放在变更目录的单一 `ADR.md` 文件中。不使用 `docs/adr/` 目录下的编号文件，所有决策在一个文件内按二级标题分段。
+所有架构决策记录存放在变更目录的单一 ADR.md 文件中。不使用 `docs/adr/` 目录下的编号文件，所有决策在一个文件内按二级标题分段。
+
+> 变更内格式为 `## NNNN: 标题` 段落。经 A-archive-and-consolidate 提升到永久库（specdev/adr/）后，转为独立文件 `# ADR-NNNN: 标题` + 结构化字段（见 consolidation-rules）。
 
 ## 模板
 
@@ -249,7 +240,7 @@
 
 ## 追加新决策
 
-1. 读取 `ADR.md`，找到最高现有编号
+1. 读取变更目录下的 ADR.md，找到最高现有编号
 2. 编号加 1
 3. 在文件末尾追加 `---` 分隔线和新条目
 
@@ -305,7 +296,7 @@ Order 聚合需要完整的变更历史用于审计和补偿。我们选择事
 
 # CONTEXT.md 格式
 
-领域词汇表存放在变更目录的 `CONTEXT.md` 中。它只包含精炼的规范术语定义，不包含实现细节、设计决策或草稿内容。
+领域词汇表存放在变更目录的 CONTEXT.md 中。它只包含精炼的规范术语定义，不包含实现细节、设计决策或草稿内容。
 
 ## 模板
 
@@ -373,7 +364,7 @@ _Avoid_: Client, buyer, account
 
 # LOG.md 格式
 
-设计决策日志存放在变更目录的 `LOG.md` 中。它记录设计访谈中已经确认、延后或被替代的具体结论——"当时讨论了什么、最终固定了什么行为以及对应哪个 ADR"。与 CONTEXT.md 的精炼不同，LOG.md 可以记录讨论中的具体场景、边界条件和交互细节。
+设计决策日志存放在变更目录的 LOG.md 中。它记录设计访谈中已经确认、延后或被替代的具体结论——"当时讨论了什么、最终固定了什么行为以及对应哪个 ADR"。与 CONTEXT.md 的精炼不同，LOG.md 可以记录讨论中的具体场景、边界条件和交互细节。
 
 ## 规则
 
@@ -427,7 +418,7 @@ Superseded by: LOG-0004
 
 ## 追加新日志
 
-1. 读取 `LOG.md`，找到最高现有编号
+1. 读取变更目录下的 LOG.md，找到最高现有编号
 2. 编号加 1（从 `0001` 开始，不足四位补零）
 3. 标题格式为 `## LOG-XXXX: {状态} — {问题/主题}`，必须能独立看出该条目回答了什么设计问题
 4. 在文件末尾追加新条目

package/template/canonical/canonical-specdev-spec.md

@@ -8,11 +8,13 @@
 
 探索仓库以了解代码库的当前状态（如果尚未这样做）。在整个 spec 中使用项目的领域词汇表，并尊重所涉及区域的任何 ADR。
 
-先读取 ``CONTEXT`` 了解项目的领域词汇表——使用其中的术语定义，不要自创名称。
+先读取变更目录下的 CONTEXT.md 了解项目的领域词汇表——使用其中的术语定义，不要自创名称。
 
-再读取 ``ADR`` 了解已做出的架构决策——不要与已有决策冲突。如果 spec 涉及与某 ADR 相同或相邻的区域，在实现决策中引用该 ADR。
+再读取变更目录下的 ADR.md 了解已做出的架构决策——不要与已有决策冲突。如果 spec 涉及与某 ADR 相同或相邻的区域，在实现决策中引用该 ADR。
 
-`{change}` 为当前活跃变更的目录名，格式为 `<YYYY-MM-DD>-<topic>`。如果尚未创建变更目录，先运行 ``G-grill-with-docs`` 的启动变更阶段初始化 CONTEXT.md 和 ADR.md。
+`{change}` 为当前活跃变更的目录名，格式为 `<YYYY-MM-DD>-<topic>`。如果尚未创建变更目录，先运行设计访谈（G-grill-with-docs）的启动变更阶段初始化 CONTEXT.md 和 ADR.md。
+
+若代码库探索中遇到不熟悉的模块、外部依赖、第三方 SDK 或技术领域，调用 common/research skill 进行针对性调查——了解其设计意图、API 契约和行为特征——再基于完整理解撰写 spec。
 
 **完成标准**：代码库当前状态已理解，领域词汇表和 ADR 已纳入考量。
 
@@ -36,7 +38,7 @@
 
 ### 3. 编写 spec
 
-按以下模板编写完整 spec，写入 ``spec``。
+按以下模板编写完整 spec，写入变更目录下的 spec.md。
 
 ---
 
@@ -77,6 +79,6 @@
 
 本入口为单文件 work，所有内容均已内联。以下引用仅在其他 work 需要读取 spec 时使用：
 
-- ``spec`` —— 编写的 spec 产物
-- CONTEXT.md —— 领域词汇表（阅读用）
-- ADR.md —— 架构决策记录（阅读用）
+- 变更目录下的 spec.md —— 编写的 spec 产物
+- 变更目录下的 CONTEXT.md —— 领域词汇表（阅读用）
+- 变更目录下的 ADR.md —— 架构决策记录（阅读用）

package/template/canonical/canonical-specdev-tickets.md

@@ -9,13 +9,13 @@
 基于对话上下文中已有的内容进行工作。如果用户将某个引用（spec 路径或其他标识）作为参数传入，拉取它并读取其完整内容。
 
 主要输入来源：
-- 如果已有 spec，读取 ``spec`` —— 这是 ticket 拆分的首要依据。
-- 读取 ``ADR`` 了解本 change 的架构决策——ticket 不应与已做出的决策冲突。
-- 读取 ``CONTEXT`` 了解本 change 的领域词汇表。
-- 读取 `specdev/adr/` —— 已确认并提升到永久的架构决策，始终反映项目当前架构现状。
-- 读取 `specdev/context/` —— 已确认并提升到永久的领域词汇表，始终反映项目当前领域术语现状。
+- 如果已有 spec，读取变更目录下的 spec.md —— 这是 ticket 拆分的首要依据。
+- 读取变更目录下的 ADR.md 了解本 change 的架构决策——ticket 不应与已做出的决策冲突。
+- 读取变更目录下的 CONTEXT.md 了解本 change 的领域词汇表。
+- 读取永久架构决策目录（specdev/adr/）—— 已确认并提升到永久的架构决策，始终反映项目当前架构现状。
+- 读取永久领域词汇表目录（specdev/context/）—— 已确认并提升到永久的领域词汇表，始终反映项目当前领域术语现状。
 
-如果尚未有 spec，可以基于对话中的计划或待办列表进行拆分，但优先建议用户先运行 ``S-spec`` 产出 spec 以获得更精确的拆分。
+如果尚未有 spec，可以基于对话中的计划或待办列表进行拆分，但优先建议用户先运行编写 Spec（S-spec）产出 spec 以获得更精确的拆分。
 
 **完成标准**：上下文（spec、对话、代码库）已收集，所有必要输入源已读取。
 
@@ -30,6 +30,8 @@
 - 如果某个模块的当前结构会使后续实现变得复杂，先提出一个重构 ticket，放在功能 tickets 之前。
 - 预重构必须独立有价值——不是为了"更干净"而重构，而是为了"让后续变更更安全/更简单"。
 
+若探索中遇到不熟悉的模块、外部依赖或第三方库——其接口设计意图和行为特征尚不明确——调用 common/research skill 完成探查后再继续识别预重构机会。
+
 **完成标准**：代码库已探索，预重构机会已识别，领域词汇表和 ADR 已纳入考量。
 
 ### 3. 草拟垂直切片
@@ -77,11 +79,11 @@
 
 **5a. 创建 ticket 目录**
 
-创建 `specdev/changes/{change}/ticket/` 目录。
+创建变更目录下的 `ticket/` 子目录。
 
 **5b. 写入单个 ticket 文件**
 
-按依赖顺序（无阻塞者在前，被阻塞者在后），为每个 ticket 创建独立文件 `ticket/NN-<ticket-name>.md`。`NN` 为 ticket 编号（两位零填充阿拉伯数字：`01`, `02`, ..., `10`, ...），代表执行顺序。文件名与编号均不含 `#` 字符，避免 Markdown 链接被编码为 `%23`。
+按依赖顺序（无阻塞者在前，被阻塞者在后），为每个 ticket 创建独立文件，路径为变更目录下的 `ticket/NN-<ticket-name>.md`。`NN` 为 ticket 编号（两位零填充阿拉伯数字：`01`, `02`, ..., `10`, ...），代表执行顺序。文件名与编号均不含 `#` 字符，避免 Markdown 链接被编码为 `%23`。
 
 每个 ticket 文件按以下模板填写：
 
@@ -95,11 +97,11 @@
 
 ## 战略与背景
 
-<!-- [必填] 本 ticket 的战略上下文。改编自 issues-slices.md §0。 -->
+<!-- [必填] 本 ticket 的战略上下文。 -->
 
 - **本 ticket 战略**：一句话——本 ticket 做什么 + 为什么 + 以什么为基础（新建/复用现有模块）
 - **与该 ticket 相关的已确认决策**：逐条列出与本 ticket 范围相关的已拍板决策（从 ADR、spec 或对话中提取），防止实现时重新扯皮
-- **与该 ticket 相关的当前现状**：逐条列出与本 ticket 相关的、与需求不符的现有代码/行为。格式：`文件路径:行号范围` + 当前行为 + 为何不满足需求。行号为近似值，实施时以现场代码为准
+- **与该 ticket 相关的当前现状**：逐条列出与本 ticket 相关的、与需求不符的现有代码/行为。格式：文件路径 + 当前行为 + 为何不满足需求。可附近似行号作定位提示，不作承诺——实施时以现场代码为准
 - **该 ticket 的预期产出**：完成后可观察到的行为变化
 
 ## 范围边界
@@ -157,31 +159,89 @@
 - **验收标准**使用 `- [ ]` checklist 格式，每条具体、可独立验证。优先写可执行命令，其次写手动检查步骤
 - 描述统一使用深层模块设计词汇：模块/接口/接缝/适配器，而非组件/服务/边界
 
-避免在 ticket 文件中写入绝对路径或行号承诺 —— 它们会很快过时。例外：如果原型产生了一个代码片段，它比文字更精确地编码了一个决策（状态机、reducer、schema、类型结构），将其内联并简要注明来自原型。精简到富含决策的部分 —— 不是可运行的演示，只是关键部分。
+避免在 ticket 文件中写入绝对路径；行号仅作近似定位提示，不作承诺。例外：如果原型产生了一个代码片段，它比文字更精确地编码了一个决策（状态机、reducer、schema、类型结构），将其内联并简要注明来自原型。精简到富含决策的部分 —— 不是可运行的演示，只是关键部分。
 
 **5c. 写入 tickets-map.md**
 
-创建 ``tickets-map``，作为所有 ticket 的总体地图和执行看板。
+创建变更目录下的 tickets-map.md，作为所有 ticket 的总体地图和执行看板。格式遵循权威模板——参见下方 `<tickets-map-template>` 标签中的完整内容。
+
+T-tickets 阶段填写的列：**编号**、**Ticket**、**被阻塞于**、**状态**（初始"未开始"）。**Gate** 和 **Contract ID** 列暂留空或标注 `[待标注]`——由后续 P-goal-plan 在标注门禁层级时填充。**依赖关系**节写入基础 ASCII 树形图（阻塞链），后续 P-goal-plan 在此基础上叠加门禁边界（`--- P0 gate ---`）、就绪标记 `[READY]` 和扇出标记 `[FAN-OUT: N路并行]`。**并行规则**节按模板保留——T-tickets 阶段写入规则文本，P-goal-plan 阶段可调整并发数。
+
+**tickets-map.md 填写说明：**
+
+- **执行清单**的 Ticket 列使用指向 `./ticket/` 目录的相对链接（纯数字编号前缀，如 `./ticket/01-auth.md`）
+- **编号**列使用 `01`、`02`、`10` 格式（两位零填充阿拉伯数字，不含 `#`），代表依赖顺序
+- **被阻塞于**列填写阻塞者的编号（如 `01`、`02, 05`）
+- **状态**列由 T-tickets 初始化为"未开始"，后续由实现者手动更新——始终以对应 ticket 文件中的状态字段为权威来源
+- **Gate** 列（P0/P1/P2）和 **Contract ID** 列由 P-goal-plan 填充；T-tickets 阶段留空或标 `[待标注]`
+- **依赖关系**用 ASCII 树形图展示阻塞链——T-tickets 写入基础结构，P-goal-plan 叠加门禁标注
+- **横切关注点**只放跨 ticket 的规则——单 ticket 的规则留在该 ticket 文件内
+- **阻塞关系说明**在依赖图非平凡时补充文字解释
+
+**完成标准**：`ticket/` 目录与全部 `NN-<ticket-name>.md` 已按依赖顺序写入；`tickets-map.md` 已按模板落盘（Gate / Contract ID 为 `[待标注]`）；每个 ticket 含阻塞边、战略与背景、范围边界、交付物、保留/不动与验收标准。
+
+## 子文件引用
+
+| 文件 | 内容 | 触发条件 |
+|------|------|----------|
+| tickets-map-template（参见下方 `<tickets-map-template>` 标签） | tickets-map.md 权威模板——执行清单六列表格、门禁标注 DAG、并行规则、横切关注点 | 进入步骤 5c「写入 tickets-map.md」时加载——T-tickets 按此模板输出基础结构，P-goal-plan 随后标注 Gate、Contract ID 和门禁 DAG |
+
+本入口为单文件 work，所有 ticket 拆分流程内容均已内联。以下引用供其他 work 读取产物：
+
+- 变更目录下的 tickets-map.md —— 总体地图与执行清单（编号 | Ticket | 被阻塞于 | Gate | Contract ID | 状态），格式遵循下方 `<tickets-map-template>` 标签
+- 变更目录下的 `ticket/` 目录 —— 独立 ticket 文件目录，每个文件命名为 `NN-<ticket-name>.md`（`NN` = `01`, `02`, ..., `10`, ...）
+- 变更目录下的 spec.md —— 上游 spec（拆分依据）
+- 永久架构决策目录（specdev/adr/）—— 已确认并提升的 ADR
+- 永久领域词汇表目录（specdev/context/）—— 已确认并提升的 CONTEXT
+
+## 下一步
+
+如果 ticket 数量超过 10 个，建议运行目标规划（P-goal-plan）产出目标规划文档，定义里程碑级约束、质量门禁和执行协议，为大规模协调执行做准备。
+
+---
+
+## 参考内容
+
+<tickets-map-template>
 
-```markdown
 # Tickets Map: <工作简短名称>
 
 <一段话总结所有 ticket 共同构建的内容。如果拆分依据是 spec，引用 spec.md。如果基于对话或计划，说明来源。>
 
 ## 执行清单
 
-| 编号 | Ticket | 被阻塞于 | 状态 |
-|------|--------|----------|------|
-| 01 | [ticket-name](./ticket/01-<kebab-title>.md) | 无 | 未开始 |
-| 02 | [ticket-name](./ticket/02-<kebab-title>.md) | 01 | 未开始 |
-| 10 | [ticket-name](./ticket/10-<kebab-title>.md) | 02, 05 | 未开始 |
+| 编号 | Ticket | 被阻塞于 | Gate | Contract ID | 状态 |
+|------|--------|----------|------|-------------|------|
+| 01 | [ticket-name](./ticket/01-<kebab-title>.md) | 无 | P0 | — | 未开始 |
+| 02 | [ticket-name](./ticket/02-<kebab-title>.md) | 01 | P1 | P1-03 | 未开始 |
+| 10 | [ticket-name](./ticket/10-<kebab-title>.md) | 02, 05 | P2 | — | 未开始 |
 
-> 状态枚举：未开始 / 进行中 / 已完成。所有 ticket 发布时初始状态为"未开始"，随实现进度手动更新。
+> **状态枚举**：未开始 / 进行中 / 已完成。所有 ticket 初始均为"未开始"。
 > **被阻塞于**列填写阻塞本 ticket 的 ticket 编号（如 `01`、`02, 05`），执行者需自行打开对应 ticket 文件查看其状态。不可仅凭此表判断——始终以对应 ticket 文件中的状态字段为准。
-
-## 依赖关系
-
-<!-- 用 ASCII 树形图展示 ticket 之间的阻塞关系。 -->
+> **Gate 列**：P0 = 核心基础设施（阻塞所有后续工作）/ P1 = 主要功能切片 / P2 = 增强和边界情况。由 P-goal-plan 填充，T-tickets 阶段留空或标注 `[待标注]`。
+> **Contract ID 列**：如有冻结合同/验收文档，填写本 ticket 覆盖的验收条目 ID（如 `P0-01, P1-03`）；无合同则填 `—`。由 P-goal-plan 填充。
+
+## 依赖关系（门禁标注 DAG）
+
+<!-- 用 ASCII DAG 展示 ticket 之间的阻塞关系和门禁边界。
+     由 T-tickets 写入基础树形结构，由 P-goal-plan 标注门禁层级（P0/P1/P2）、
+     就绪标记 [READY] 和扇出标记 [FAN-OUT: N路并行]。
+
+     绘制约定：
+     - 每行一个 ticket，缩进表示依赖深度
+     - → 表示依赖关系（A → B 表示 B 依赖 A）
+     - 用注释标注门禁边界：--- P0 gate ---
+     - 可立即开始的 ticket 标注 [READY]
+     - 扇出点标注 [FAN-OUT: N路并行]
+
+     示例格式：
+     01 [READY]  →  02 [FAN-OUT: 3路并行]
+                          ├→ 03 [P0]
+                          ├→ 04 [P1]
+                          └→ 05 [P1]
+     --- P0 gate ---
+     03  →  06 [P1]  →  07 [P2]
+-->
 
 ```
 01-<name>          ← 无阻塞，可立即开始
@@ -190,6 +250,13 @@
         └── 04-<name>  ← 阻塞于 03
 ```
 
+## 并行规则
+
+- 最大 **3** 个并发实现者（ticket 数 > 20 时可调至 4）
+- 并发 ticket 的 file allowlist 必须互不重叠——两两之间无可写文件交集
+- 共享文件（package.json、lockfile、合同文档、IPC 根导出、领域词汇表）仅由 Lead 修改
+- 共享文件修改后，所有并发子代理需在继续前同步
+
 ## 横切关注点
 
 <!-- 跨多个 ticket 的规则与约束。仅在有实际内容时填写，无则省略整个小节。 -->
@@ -207,26 +274,5 @@
 ## 风险与注意事项
 
 <!-- 跨 ticket 的风险、回滚考虑。无可省略整个小节。 -->
-```
-
-**tickets-map.md 填写说明：**
-
-- **执行清单**的 Ticket 列使用指向 `./ticket/` 目录的相对链接（纯数字编号前缀，如 `./ticket/01-auth.md`），可在 markdown 渲染器中直接点击跳转
-- **编号**列使用 `01`、`02`、`10` 格式（两位零填充阿拉伯数字，不含 `#`），代表依赖顺序
-- **被阻塞于**列填写阻塞者的编号（如 `01`、`02, 05`），执行者需自行查看对应 ticket 文件的状态字段确认是否已就绪
-- **状态**列由 T-tickets 初始化为"未开始"，后续由实现者手动更新——始终以对应 ticket 文件中的状态字段为权威来源
-- **依赖关系**用 ASCII 树形图直观展示阻塞链；纯线性链用缩进列表即可
-- **横切关注点**只放跨 ticket 的规则——单 ticket 的规则留在该 ticket 文件内
-- **阻塞关系说明**在依赖图非平凡时补充文字解释，特别是扩展-收缩排序的三阶段
-
-**完成标准**：`ticket/` 目录已创建，所有 ticket 独立文件已按依赖顺序写入（命名为 `NN-<ticket-name>.md`）；`tickets-map.md` 已写入——包含总体摘要、执行清单（编号、ticket 链接、被阻塞于、状态四列，初始均为"未开始"）、依赖关系图和横切关注点；每个 ticket 声明阻塞边（使用相对路径）、战略与背景、范围边界、交付物、保留/不动和验收标准。
-
-## 子文件引用
-
-本入口为单文件 work，所有内容均已内联。以下引用供其他 work 读取产物：
 
-- ``tickets-map`` —— 总体地图与执行清单（编号 | Ticket | 被阻塞于 | 状态）
-- `specdev/changes/{change}/ticket/` —— 独立 ticket 文件目录，每个文件命名为 `NN-<ticket-name>.md`（`NN` = `01`, `02`, ..., `10`, ...）
-- ``spec`` —— 上游 spec（拆分依据）
-- `specdev/adr/` —— 永久架构决策目录（已确认并提升的 ADR）
-- `specdev/context/` —— 永久领域词汇表目录（已确认并提升的 CONTEXT）
+</tickets-map-template>

package/template/canonical/canonical-specdev-wayfinder.md

@@ -1,30 +1,28 @@
 # 寻路
 
+> **配套上传建议**：本能力跨引用「设计访谈（带文档）」的访谈协议与领域建模规程。若在网页 AI 平台使用，建议同时上传 `canonical-specdev-grill-with-docs.md`。仓库：https://github.com/NAMEWTA/Speculo
+
 一个模糊的想法出现了 —— 太大而无法放入单个 agent 会话，且笼罩在迷雾中：从当前状态到**目标**的路径尚不可见。寻路（Wayfinding）就是找到那条路，而非冲向目标。此 work 在变更目录中绘制路径作为一张**共享地图**，然后逐个处理其 tickets，直到路径变得清晰。
 
 目标因工作而异，命名目标是绘制地图的第一步 —— 它塑造每个 ticket。目标可能是一份待移交和迭代的 spec、一个在规划开始前需锁定的决策、或是一个原地完成的变更（如数据结构迁移）。地图是领域无关的 —— 工程工作、课程内容，任何符合此形态的内容都可以。
 
 ## 规划，而非执行
 
-Wayfinder 默认进行**规划**：每个 ticket 解决一个决策，当地图完成时路径就清晰了 —— 在某人动手做事之前没有任何剩余的决策。想要直接动手做事的冲动通常就是信号，表明你已经到达地图的边缘，是时候移交了。一项工作可以通过其 **Notes** 覆盖此行为 —— 将执行带入地图本身 —— 但如果没有明确说明，产出决策，而非可交付成果。
+Wayfinder 默认进行**规划**：每个 ticket 解决一个决策，当地图完成时路径就清晰了 —— 在某人动手做事之前没有任何剩余的决策。想要直接动手做事的冲动通常就是信号，表明你已经到达地图的边缘，是时候移交了。一项工作可以通过其「说明」章节覆盖此行为 —— 将执行带入地图本身 —— 但如果没有明确说明，产出决策，而非可交付成果。
 
 ## 用名称引用
 
-每张地图和每个 ticket 都有其**名称** —— 即其标题或标识。在人类阅读的所有内容中 —— 叙述、地图的 Decisions-so-far —— 使用名称引用它，绝不使用裸 ID、编号或 slug。一堵 `#42, #43, #44` 的墙是难以阅读的；名称可以一目了然。引用标记不会消失 —— 名称包裹着其引用 —— 但它们在名称*内部*，绝不是名称的替代品。
+每张地图和每个 ticket 都有其**名称** —— 即其标题或标识。在人类阅读的所有内容中 —— 叙述、地图的「已做出的决策」 —— 使用名称引用它，绝不使用裸 ID、编号或 slug。一堵 `#42, #43, #44` 的墙是难以阅读的；名称可以一目了然。引用标记不会消失 —— 名称包裹着其引用 —— 但它们在名称*内部*，绝不是名称的替代品。
 
-在本地 markdown 地图中，使用 Markdown 链接 `[ticket 标题](#ticket-标题)` 进行引用。已解决的 tickets 在地图的 Decisions-so-far 中以 `- [ticket 标题] —— 答案概括` 形式索引。
+在本地 markdown 地图中，使用 Markdown 链接 `[ticket 标题](#ticket-标题)` 进行引用。已解决的 tickets 在地图的「已做出的决策」中以 `- [ticket 标题] —— 答案概括` 形式索引。
 
 ## 地图
 
-地图是变更目录下的单个 markdown 文件 ``map``，是规范的产物。其 tickets 是地图内的 task list items（`- [ ]` 格式）。如果工作范围跨多个变更，地图位于主变更目录下。
+地图是变更目录下的单个 markdown 文件 map.md，是规范的产物。其 tickets 是地图内的 task list items（`- [ ]` 格式）。如果工作范围跨多个变更，地图位于主变更目录下。
 
 地图是一个**索引**，而非存储。它列出已做出的决策并指向持有其详细信息的 tickets；一个决策只存在于一个地方 —— 其 ticket —— 因此地图从不重述，仅概括并链接。
 
-**地图物理结构：** 地图文件本身是 markdown 文件。Tickets 是地图文件内的编号 task list items，而非外部 issues。每个 ticket 拥有一个独立的 markdown 小节，包含标题、类型标签、问题和答案。状态通过 checkbox 标记追踪（`- [ ]` 开放，`- [x]` 已解决）。阻塞关系通过"被阻塞于"字段声明，以 ticket 标题引用。
-
-**前沿查询：** 前沿上的 tickets 是指：checkbox 未勾选（开放）、其"被阻塞于"中列出的所有 tickets 均已勾选（无阻塞）、且尚未被领取的 tickets。Agent 通过阅读地图文件本身即可识别前沿。
-
-**领取机制：** 当一个 agent 会话开始处理某个 ticket 时，它应在 `specdev/status.json` 的 `active` 数组中记录当前处理的 ticket 名称，以便并发会话跳过它。处理完成后从 `active` 中移除。`active` 中存在记录即为领取标记。
+**地图物理结构：** 地图文件本身是 markdown 文件。Tickets 是地图文件内的编号 task list items，而非外部 issues。每个 ticket 拥有一个独立的 markdown 小节，包含标题、类型标签、问题和答案。状态通过 checkbox 标记追踪（`- [ ]` 开放，`- [x]` 已解决）。阻塞、领取与前沿的定义见下方「Tickets」节。
 
 ### 地图正文
 
@@ -84,19 +82,19 @@ Wayfinder 默认进行**规划**：每个 ticket 解决一个决策，当地图
 
 每个 ticket 携带一个类型标签 —— 以下之一：`research`、`prototype`、`grilling`、`task`（参见下方 [Ticket 类型](#ticket-类型)）。
 
-**领取机制：** 一个会话通过将其名称写入 `specdev/status.json` 的 `active` 数组来**领取**一个 ticket，在开始任何工作**之前**领取，以便并发会话跳过它。该记录*就是*领取标记：一个开放、未被领取的 ticket 是未被领取的。
+**领取机制：** 一个会话通过将其名称追加到 `specdev/status.json` 的当前 change 的 `active` 条目中的 `claimed_tickets` 数组来**领取**一个 ticket，在开始任何工作**之前**领取，以便并发会话跳过它。该记录*就是*领取标记：一个开放、未被领取的 ticket 是未被领取的。
 
 **阻塞关系：** 使用 ticket 标题在"被阻塞于"字段中声明依赖。这很关键，因为它使前沿在地图文件中*可视化*呈现 —— 人类无需额外工具就能看到哪些可以开始。当一个 ticket 的所有阻塞 tickets 都已勾选（已解决）时，该 ticket 是**未被阻塞的**；**前沿**是开放（未勾选）、未被阻塞、未被领取的 tickets —— 即已知的边界。
 
-**答案：** 不是正文的一部分 —— 它在解决时写入 ticket 的"答案"小节（参见[遍历地图](#遍历地图)）。解决 ticket 时创建的资产从 ticket 小节链接，而非粘贴进去。如果资产是文件，放置在 `specdev/changes/{change}/` 下，从 ticket 链接。
+**答案：** 不是正文的一部分 —— 它在解决时写入 ticket 的"答案"小节（参见[遍历地图](#遍历地图)）。解决 ticket 时创建的资产从 ticket 小节链接，而非粘贴进去。如果资产是文件，放置在变更目录下，从 ticket 链接。
 
 ## Ticket 类型
 
 每个 ticket 要么是 **HITL** —— 人在回路中，与一个代表自己发言的人类*一起*工作 —— 要么是 **AFK**，由 agent 独立驱动。HITL ticket 只能通过实时交流来解决；agent 绝不代替人类一方发言（一个自问自答的质询 agent 已经破坏了这一点）。
 
-- **Research**（AFK）：阅读文档、第三方 API 或知识库等本地资源。创建一个 markdown 摘要作为链接资产。当需要当前工作目录之外的知识时使用。
-- **Prototype**（HITL）：通过制作一个廉价、粗糙、具体的产物来提高讨论的保真度 —— 大纲、粗略尝试、桩代码、或 UI/逻辑代码。将原型链接为资产。当"它应该是什么样子"或"它应该怎样表现"是关键问题时使用。
-- **Grilling**（HITL）：通过 ``grilling-protocol`` 访谈协议逐个问题进行对话。同时使用 ``domain-modeling-rules`` 维护领域模型。默认情况 —— 当不确定类型时选此。
+- **Research**（AFK）：调用 common/research skill 启动后台 Agent 针对一手来源调查问题，在 ticket 的答案中链接研究产出文件。当需要当前工作目录之外的知识时使用。
+- **Prototype**（HITL）：调用 common/prototype skill 制作一个廉价、粗糙、具体的产物来提高讨论的保真度 —— 大纲、粗略尝试、桩代码、或 UI/逻辑代码。将原型链接为资产。当"它应该是什么样子"或"它应该怎样表现"是关键问题时使用。
+- **Grilling**（HITL）：通过设计访谈（G-grill-with-docs）的访谈协议逐个问题进行对话。同时使用其领域建模规程维护领域模型。默认情况 —— 当不确定类型时选此。
 - **Task**（HITL 或 AFK）：在*决策*能够做出之前必须完成的手动工作 —— 没有需要决定、原型化或研究的内容，但讨论被阻塞直到完成。注册服务以便判断其 API、开通访问权限、移动数据以便看到其形态。这是唯一一个*执行*而非决策的类型 —— 它通过为决策解除阻塞来赢得其位置，而非通过交付目标。Agent 在可能的情况下独立驱动（AFK）；否则它交给人类一份精确的清单（HITL）。当工作完成时解决；答案记录已完成的工作以及后续 tickets 依赖的任何结果性事实（凭据位置、新 URL、行数）。
 
 ## 战争迷雾
@@ -110,7 +108,7 @@ Wayfinder 默认进行**规划**：每个 ticket 解决一个决策，当地图
 - **做成 ticket 当** 问题已经清晰 —— 即使它被阻塞，你尚不能行动。你能写出明确的"问题"段落。
 - **尚未明确当** 你还无法如此精确地表述它。不要将迷雾预先切成 ticket 大小的碎片：它比 ticket 更粗糙，一个补丁可能在当前沿到达时升级为多个 tickets，或零个。
 
-**尚未明确**排除已决策的内容（Decisions-so-far）、已有的活跃 ticket 以及超出范围的内容（下一节）。
+**尚未明确**排除已决策的内容（「已做出的决策」）、已有的活跃 ticket 以及超出范围的内容（下一节）。
 
 ## 超出范围
 
@@ -128,7 +126,7 @@ Wayfinder 默认进行**规划**：每个 ticket 解决一个决策，当地图
 
 用户带着模糊的想法调用。
 
-1. **命名目标。** 运行一次 ``G-grill-with-docs`` 访谈会话，以确定此地图正在寻路的目标 —— spec、决策或变更。目标确定了范围，因此先确定它。使用 ``grilling-protocol`` 进行访谈，使用 ``domain-modeling-rules`` 维护领域模型。
+1. **命名目标。** 运行一次设计访谈（G-grill-with-docs）会话，以确定此地图正在寻路的目标 —— spec、决策或变更。目标确定了范围，因此先确定它。使用其访谈协议进行访谈，使用其领域建模规程维护领域模型。
 
    **完成标准**：目标已命名，范围边界已确定。
 
@@ -136,9 +134,9 @@ Wayfinder 默认进行**规划**：每个 ticket 解决一个决策，当地图
 
    **完成标准**：前沿的开放决策和第一步已浮现；迷雾部分已识别并草拟。
 
-3. **创建地图**：写入 ``map``，填写 Destination 和 Notes，Decisions-so-far 为空，迷雾草拟进**尚未明确**。
+3. **创建地图**：写入变更目录下的 map.md，填写「目的地」和「说明」，「已做出的决策」为空，迷雾草拟进**尚未明确**。
 
-   **完成标准**：地图文件已创建，Destination、Notes、尚未明确、超出范围均已填写。
+   **完成标准**：地图文件已创建，目的地、说明、尚未明确、超出范围均已填写。
 
 4. **创建你现在能明确的 tickets** 作为地图文件内的小节 —— 然后在**第二遍**中连接阻塞边（tickets 需要首先有标题才能相互引用）。连接关系将它们排序为前沿和被阻塞；你尚无法明确的都在迷雾中 —— **尚未明确**章节。
 
@@ -150,21 +148,21 @@ Wayfinder 默认进行**规划**：每个 ticket 解决一个决策，当地图
 
 用户带着一张地图（变更目录或 map.md 路径）调用。Ticket 是**可选的** —— 不提供时，你选择下一个决策，而非用户。
 
-1. **加载地图** —— 低分辨率视图（Destination、Notes、Decisions-so-far、尚未明确、超出范围），而非每个 ticket 的完整正文。
+1. **加载地图** —— 低分辨率视图（目的地、说明、已做出的决策、尚未明确、超出范围），而非每个 ticket 的完整正文。
 
    **完成标准**：地图的低分辨率视图已加载，当前状态已理解。
 
-2. **选择 ticket。** 如果用户指定了一个，使用它。否则按顺序选择第一个前沿 ticket（开放、未被阻塞、未被领取）。**领取它**：在任何工作之前将 ticket 名称写入 `specdev/status.json` 的 `active` 数组。
+2. **选择 ticket。** 如果用户指定了一个，使用它。否则按顺序选择第一个前沿 ticket。**领取它**（规则见上方「Tickets」节）。
 
    **完成标准**：一个前沿 ticket 已被选中并领取。
 
-3. **解决它** —— **按需缩放**：按需拉取任何相关或已关闭 ticket 的完整正文；调用 Notes 块中指定的技能。如有疑问，使用 ``G-grill-with-docs`` 进行访谈。查阅 ``domain-modeling-rules`` 维护领域模型的一致性。
+3. **解决它** —— **按需缩放**：按需拉取任何相关或已关闭 ticket 的完整正文；调用「说明」中指定的技能。根据 ticket 类型选择解决方式：**research** 调用 common/research skill；**grilling** 使用设计访谈（G-grill-with-docs）；**prototype** 调用 common/prototype skill；**task** 按问题描述执行。查阅设计访谈的领域建模规程维护领域模型。
 
    **完成标准**：ticket 的问题已解决，答案已记录。
 
-4. **记录解决方案：** 在 ticket 的"答案"小节中填写答案，将 checkbox 从 `- [ ]` 改为 `- [x]`，在地图的 Decisions-so-far 中**追加一条上下文指针**：`- [ticket 标题] —— 答案的一句话概括`。从 `specdev/status.json` 的 `active` 数组中移除该 ticket。
+4. **记录解决方案：** 在 ticket 的"答案"小节中填写答案，将 checkbox 从 `- [ ]` 改为 `- [x]`，在地图的「已做出的决策」中**追加一条上下文指针**：`- [ticket 标题] —— 答案的一句话概括`。从 `claimed_tickets` 中移除该 ticket（规则见上方「Tickets」节）。
 
-   **完成标准**：ticket checkbox 已勾选，Decisions-so-far 已更新，active 数组已清理。
+   **完成标准**：ticket checkbox 已勾选，「已做出的决策」已更新，领取标记已清除。
 
 5. **添加新浮现的 tickets** 作为地图文件内新的小节（先创建再连接阻塞边）；升级答案使任何变得可明确的迷雾，从**尚未明确**中清除每个已升级的补丁，使其仅以其新 ticket 的形式存在。如果答案揭示某个 ticket —— 这个或其他 —— 位于目标之外，**将其裁定为超出范围**而非在路径上解决它。如果该决策使地图的其他部分无效，更新或删除这些 tickets（勾选并注明无效原因）。
 
@@ -177,7 +175,7 @@ Wayfinder 默认进行**规划**：每个 ticket 解决一个决策，当地图
 当所有 tickets 已关闭（勾选）、迷雾已清空（尚未明确为空或仅剩无法继续分解的模糊项）、且通往目标的路径已清晰时，地图完成。向用户汇报：
 
 - 目的地是否已可抵达——路径上的每个步骤是否都已有明确的 ticket 或决策
-- Decisions-so-far 中的关键结论摘要
+- 「已做出的决策」中的关键结论摘要
 - 剩余的任何**尚未明确**项——它们是否阻碍行动，还是可作为实现细节处理
 - 建议的下一步行动（移交实现、开始执行、或重新划定目标）
 
@@ -187,14 +185,14 @@ Wayfinder 默认进行**规划**：每个 ticket 解决一个决策，当地图
 
 ## 子文件引用
 
-本入口为单文件 work，所有内容均已内联。以下引用供 work 内各阶段加载：
+本入口为单文件 work，所有内容均已内联。以下引用供 work 内各阶段加载（跨 workflow，不内联——建议配套上传设计访谈 canonical 文档）：
 
 | 文件 | 触发条件 |
 |------|----------|
-| ``G-grill-with-docs`` | 需要访谈以命名目标或解决 grilling 类型 ticket |
-| ``grilling-protocol`` | 进入具体访谈——一次一问，决策树遍历 |
-| ``domain-modeling-rules`` | 维护领域模型——术语精炼、决策记录 |
-| ``map`` | 地图持久化文件 |
+| 设计访谈（G-grill-with-docs）主入口 | 需要访谈以命名目标或解决 grilling 类型 ticket |
+| 设计访谈的访谈协议（grilling-protocol） | 进入具体访谈——一次一问，决策树遍历 |
+| 设计访谈的领域建模规程（domain-modeling-rules） | 维护领域模型——术语精炼、决策记录 |
+| 变更目录下的 map.md | 地图持久化文件 |
 
 状态追踪：
-- `specdev/status.json` —— `active` 数组记录当前领取的 ticket
+- `specdev/status.json` —— `active` 条目中的 `claimed_tickets` 数组记录当前领取的 ticket