@namewta/speculo 0.2.10 → 0.2.11

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (7) hide show
  1. package/package.json +1 -1
  2. package/template/canonical/canonical-specdev-tickets.md +19 -19
  3. package/template/workflows/specdev/P-goal-plan/execution-sections.md +35 -12
  4. package/template/workflows/specdev/P-goal-plan/governance-sections.md +3 -3
  5. package/template/workflows/specdev/P-goal-plan/lead-orchestration-protocol.md +5 -3
  6. package/template/workflows/specdev/T-tickets/T-tickets.md +10 -10
  7. package/template/workflows/specdev/T-tickets/tickets-map-template.md +14 -14
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@namewta/speculo",
3
- "version": "0.2.10",
3
+ "version": "0.2.11",
4
4
  "description": "Workflow-packaged specification-driven development assets with install, update, and migration tooling.",
5
5
  "type": "module",
6
6
  "bin": {
package/template/canonical/canonical-specdev-tickets.md CHANGED
@@ -69,7 +69,7 @@
69
69
 
70
70
  迭代直到用户批准拆分方案。每次修改后重新展示完整列表。
71
71
 
72
- **完成标准**：用户已确认粒度、阻塞边与合并/拆分方案。批准后，tickets 将写入 `ticket/` 目录（一个 ticket 一个独立文件，命名为 `#NN-<name>.md`），并生成 `tickets-map.md` 作为总体地图和执行清单。
72
+ **完成标准**：用户已确认粒度、阻塞边与合并/拆分方案。批准后，tickets 将写入 `ticket/` 目录（一个 ticket 一个独立文件，命名为 `NN-<name>.md`），并生成 `tickets-map.md` 作为总体地图和执行清单。
73
73
 
74
74
  ### 5. 发布
75
75
 
@@ -81,14 +81,14 @@
81
81
 
82
82
  **5b. 写入单个 ticket 文件**
83
83
 
84
- 按依赖顺序（无阻塞者在前，被阻塞者在后），为每个 ticket 创建独立文件 `ticket/#NN-<ticket-name>.md`。`#NN` 为 ticket 编号（`#01`, `#02`, ..., `#10`, ...），代表执行顺序。
84
+ 按依赖顺序（无阻塞者在前，被阻塞者在后），为每个 ticket 创建独立文件 `ticket/NN-<ticket-name>.md`。`NN` 为 ticket 编号（两位零填充阿拉伯数字：`01`, `02`, ..., `10`, ...），代表执行顺序。文件名与编号均不含 `#` 字符，避免 Markdown 链接被编码为 `%23`。
85
85
 
86
86
  每个 ticket 文件按以下模板填写：
87
87
 
88
88
  ```markdown
89
- # Ticket #NN: <标题>
89
+ # Ticket NN: <标题>
90
90
 
91
- - **被阻塞于：** `./ticket/#NN-<name>.md`, `./ticket/#NN-<name>.md`（相对路径，或多个用逗号分隔。无阻塞则写"无 —— 可立即开始"。查看被引用 ticket 文件中的状态字段自行判断是否已就绪）
91
+ - **被阻塞于：** `./ticket/NN-<name>.md`, `./ticket/NN-<name>.md`（相对路径，或多个用逗号分隔。无阻塞则写"无 —— 可立即开始"。查看被引用 ticket 文件中的状态字段自行判断是否已就绪）
92
92
  - **状态：** 未开始
93
93
 
94
94
  <!-- 如需了解整体上下文、所有 ticket 的依赖关系全景或横切关注点，请查看 `../tickets-map.md`。 -->
@@ -146,7 +146,7 @@
146
146
 
147
147
  **模板填写说明：**
148
148
 
149
- - **被阻塞于**使用指向 `./ticket/` 目录的相对路径（如 `./ticket/#01-auth.md`），多个用逗号分隔。执行者应自行打开被引用的 ticket 文件查看其状态字段，判断阻塞是否已解除
149
+ - **被阻塞于**使用指向 `./ticket/` 目录的相对路径（如 `./ticket/01-auth.md`），多个用逗号分隔。执行者应自行打开被引用的 ticket 文件查看其状态字段，判断阻塞是否已解除
150
150
  - **状态**初始固定为"未开始"；实现者开始工作时改为"进行中"，完成后改为"已完成"
151
151
  - **战略与背景**是必填段——为执行者提供该 ticket 的决策锚点和当前现状。从 spec、ADR、对话中提取，不确定的标记 `[待确认]`
152
152
  - **范围边界**是必填段——明确本 ticket 的 IN/REUSE/OUT 三列，防止范围蔓延。OUT 列吸收"明确不做"的内容
@@ -172,22 +172,22 @@
172
172
 
173
173
  | 编号 | Ticket | 被阻塞于 | 状态 |
174
174
  |------|--------|----------|------|
175
- | #01 | [ticket-name](./ticket/#01-ticket-name.md) | 无 | 未开始 |
176
- | #02 | [ticket-name](./ticket/#02-ticket-name.md) | #01 | 未开始 |
177
- | #10 | [ticket-name](./ticket/#10-ticket-name.md) | #02, #05 | 未开始 |
175
+ | 01 | [ticket-name](./ticket/01-<kebab-title>.md) | 无 | 未开始 |
176
+ | 02 | [ticket-name](./ticket/02-<kebab-title>.md) | 01 | 未开始 |
177
+ | 10 | [ticket-name](./ticket/10-<kebab-title>.md) | 02, 05 | 未开始 |
178
178
 
179
179
  > 状态枚举：未开始 / 进行中 / 已完成。所有 ticket 发布时初始状态为"未开始"，随实现进度手动更新。
180
- > **被阻塞于**列填写阻塞本 ticket 的 ticket 编号（如 `#01`、`#02, #05`），执行者需自行打开对应 ticket 文件查看其状态。不可仅凭此表判断——始终以对应 ticket 文件中的状态字段为准。
180
+ > **被阻塞于**列填写阻塞本 ticket 的 ticket 编号（如 `01`、`02, 05`），执行者需自行打开对应 ticket 文件查看其状态。不可仅凭此表判断——始终以对应 ticket 文件中的状态字段为准。
181
181
 
182
182
  ## 依赖关系
183
183
 
184
184
  <!-- 用 ASCII 树形图展示 ticket 之间的阻塞关系。 -->
185
185
 
186
186
  ```
187
- #01-<name> ← 无阻塞，可立即开始
188
- ├── #02-<name> ← 阻塞于 #01
189
- └── #03-<name> ← 阻塞于 #01
190
- └── #04-<name> ← 阻塞于 #03
187
+ 01-<name> ← 无阻塞，可立即开始
188
+ ├── 02-<name> ← 阻塞于 01
189
+ └── 03-<name> ← 阻塞于 01
190
+ └── 04-<name> ← 阻塞于 03
191
191
  ```
192
192
 
193
193
  ## 横切关注点
@@ -202,7 +202,7 @@
202
202
 
203
203
  <!-- 依赖图的文字说明。简单线性链可省略整个小节。对于扩展-收缩模式，解释三阶段。 -->
204
204
 
205
- <描述为何 ticket #B 被 ticket #A 阻塞。扩展-收缩模式：扩展阶段创建新形式 → 迁移批次逐步切换调用点 → 收缩阶段删除旧形式。>
205
+ <描述为何 ticket B 被 ticket A 阻塞。扩展-收缩模式：扩展阶段创建新形式 → 迁移批次逐步切换调用点 → 收缩阶段删除旧形式。>
206
206
 
207
207
  ## 风险与注意事项
208
208
 
@@ -211,22 +211,22 @@
211
211
 
212
212
  **tickets-map.md 填写说明：**
213
213
 
214
- - **执行清单**的 Ticket 列使用指向 `./ticket/` 目录的相对链接（含 `#` 编号前缀），可在 markdown 渲染器中直接点击跳转
215
- - **编号**列使用 `#01`、`#02`、`#10` 格式（`#` + 零填充序号），代表依赖顺序
216
- - **被阻塞于**列填写阻塞者的编号（如 `#01`、`#02, #05`），执行者需自行查看对应 ticket 文件的状态字段确认是否已就绪
214
+ - **执行清单**的 Ticket 列使用指向 `./ticket/` 目录的相对链接（纯数字编号前缀，如 `./ticket/01-auth.md`），可在 markdown 渲染器中直接点击跳转
215
+ - **编号**列使用 `01`、`02`、`10` 格式（两位零填充阿拉伯数字，不含 `#`），代表依赖顺序
216
+ - **被阻塞于**列填写阻塞者的编号（如 `01`、`02, 05`），执行者需自行查看对应 ticket 文件的状态字段确认是否已就绪
217
217
  - **状态**列由 T-tickets 初始化为"未开始"，后续由实现者手动更新——始终以对应 ticket 文件中的状态字段为权威来源
218
218
  - **依赖关系**用 ASCII 树形图直观展示阻塞链；纯线性链用缩进列表即可
219
219
  - **横切关注点**只放跨 ticket 的规则——单 ticket 的规则留在该 ticket 文件内
220
220
  - **阻塞关系说明**在依赖图非平凡时补充文字解释，特别是扩展-收缩排序的三阶段
221
221
 
222
- **完成标准**：`ticket/` 目录已创建，所有 ticket 独立文件已按依赖顺序写入（命名为 `#NN-<ticket-name>.md`）；`tickets-map.md` 已写入——包含总体摘要、执行清单（编号、ticket 链接、被阻塞于、状态四列，初始均为"未开始"）、依赖关系图和横切关注点；每个 ticket 声明阻塞边（使用相对路径）、战略与背景、范围边界、交付物、保留/不动和验收标准。
222
+ **完成标准**：`ticket/` 目录已创建，所有 ticket 独立文件已按依赖顺序写入（命名为 `NN-<ticket-name>.md`）；`tickets-map.md` 已写入——包含总体摘要、执行清单（编号、ticket 链接、被阻塞于、状态四列，初始均为"未开始"）、依赖关系图和横切关注点；每个 ticket 声明阻塞边（使用相对路径）、战略与背景、范围边界、交付物、保留/不动和验收标准。
223
223
 
224
224
  ## 子文件引用
225
225
 
226
226
  本入口为单文件 work，所有内容均已内联。以下引用供其他 work 读取产物：
227
227
 
228
228
  - ``tickets-map`` —— 总体地图与执行清单（编号 | Ticket | 被阻塞于 | 状态）
229
- - `specdev/changes/{change}/ticket/` —— 独立 ticket 文件目录，每个文件命名为 `#NN-<ticket-name>.md`（`#NN` = `#01`, `#02`, ..., `#10`, ...）
229
+ - `specdev/changes/{change}/ticket/` —— 独立 ticket 文件目录，每个文件命名为 `NN-<ticket-name>.md`（`NN` = `01`, `02`, ..., `10`, ...）
230
230
  - ``spec`` —— 上游 spec（拆分依据）
231
231
  - `specdev/adr/` —— 永久架构决策目录（已确认并提升的 ADR）
232
232
  - `specdev/context/` —— 永久领域词汇表目录（已确认并提升的 CONTEXT）
package/template/workflows/specdev/P-goal-plan/execution-sections.md CHANGED
@@ -32,15 +32,16 @@ P0 门禁先开，阻塞所有 P1/P2 关闭。ticket 可以在其依赖就绪后
32
32
  - 用注释标注门禁边界：`--- P0 gate ---`
33
33
  - 可立即开始的 ticket 标注 `[READY]`
34
34
  - 扇出点标注 `[FAN-OUT: N路并行]`
35
+ - ticket 编号使用两位零填充纯数字（`01`, `02`, …），**不含** `#`
35
36
 
36
37
  示例格式：
37
38
  ```
38
- #4 [READY] → #5 [FAN-OUT: 3路并行]
39
- ├→ #6 [P0]
40
- ├→ #7 [P1]
41
- └→ #8 [P1]
39
+ 04 [READY] → 05 [FAN-OUT: 3路并行]
40
+ ├→ 06 [P0]
41
+ ├→ 07 [P1]
42
+ └→ 08 [P1]
42
43
  --- P0 gate ---
43
- #6 → #9 [P1] → #10 [P2]
44
+ 06 → 09 [P1] → 10 [P2]
44
45
  ```
45
46
 
46
47
  将丰富后的 DAG 回写到 tickets-map.md 的「依赖关系」节，替换 T-tickets 写入的基础版本。
@@ -55,15 +56,27 @@ tickets-map.md 的「并行规则」节已由模板预设默认值（最大 3
55
56
 
56
57
  ## §5 — Per-Ticket Execution Protocol
57
58
 
59
+ 本协议是对 I-implement 的实例化执行；实现者必须同时遵循 I-implement 四步协议（设计检查→TDD→双轴审查→提交）。权威入口：`<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>`。
60
+
58
61
  ### 协议定制
59
62
 
60
63
  根据 input-validation.md 检测到的执行模型选择协议骨架：
61
64
 
62
65
  #### Lead+Subagent 模型（完整八步）
63
66
 
64
- 1. **读取** —— Lead 读取 issue 全文、合同/参考权威对应行、ticket 的验收标准。如果激活参考权威模式，对照参考快照中的对应交互路径。
65
- 2. **派单** —— Lead 输出结构化派单行 `IMPLEMENTER_DISPATCH #<n> issue=<url> gate=<P0|P1|P2> allowlist=<files> contract_ids=<...>`，然后生成实现子代理（model: fable, 唯一 name）。Lead+Subagent 模型下，加载 `<Path>{roots.workflows}/specdev/P-goal-plan/lead-orchestration-protocol.md</Path>` 获取完整的编排协议——包括子代理上下文载荷结构、handoff 交接、合并冲突解决、Worktree 隔离和收尾审查的详细步骤。
66
- 3. **实现** —— 子代理在 file allowlist 内实现变更，按 ticket 指定的测试矩阵运行测试。
67
+ 1. **读取** —— 实现者（Lead 与子代理）在开始前**必须按顺序读取以下文件**建立完整上下文：
68
+
69
+ | # | 文件 | 用途 |
70
+ |---|------|------|
71
+ | 1 | `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>` | specdev 实现流程入口——设计检查、TDD 循环、双轴审查、提交 |
72
+ | 2 | 本 ticket 全文 | 验收标准、范围边界、交付物、保留/不动 |
73
+ | 3 | 合同/参考权威对应行（如激活） | 编号验收条目或对照路径 |
74
+ | 4 | 项目 skills（如有） | 前后端编排、构建规范、路由/菜单、数据库标准等项目级约定——按实际检出的 skill 路径追加，可变 |
75
+
76
+ Lead 读取 issue 全文、合同/参考权威对应行、ticket 的验收标准。如果激活参考权威模式，对照参考快照中的对应交互路径。
77
+
78
+ 2. **派单** —— Lead 输出结构化派单行 `IMPLEMENTER_DISPATCH <n> issue=<url> gate=<P0|P1|P2> allowlist=<files> contract_ids=<...>`（`<n>` 为两位零填充纯数字编号，如 `01`，不含 `#`），然后生成实现子代理（model: fable, 唯一 name）。Lead+Subagent 模型下，加载 `<Path>{roots.workflows}/specdev/P-goal-plan/lead-orchestration-protocol.md</Path>` 获取完整的编排协议——包括子代理上下文载荷结构、handoff 交接、合并冲突解决、Worktree 隔离和收尾审查的详细步骤。
79
+ 3. **实现** —— 子代理在 file allowlist 内实现变更，按 ticket 指定的测试矩阵运行测试；实现过程遵循 I-implement 的设计检查与 TDD 红绿循环。
67
80
  4. **双轴审查** —— 实现完成后，立即启动两个审查子代理并行运行：
68
81
  - `reviewer-standards-<n>`：代码质量、架构、测试覆盖
69
82
  - `reviewer-spec-<n>`：spec 合规、验收标准
@@ -75,9 +88,17 @@ tickets-map.md 的「并行规则」节已由模板预设默认值（最大 3
75
88
 
76
89
  #### 简化模型（精简协议）
77
90
 
78
- 1. **读取** — 读 ticket、spec 对应 User Story、验收标准。
79
- 2. **实现** — 在 ticket 声明的范围内实现变更。
80
- 3. **审查** — 单审查者检查代码质量和 spec 合规。
91
+ 1. **读取** —— 实现者在开始前**必须按顺序读取以下文件**建立完整上下文：
92
+
93
+ | # | 文件 | 用途 |
94
+ |---|------|------|
95
+ | 1 | `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>` | specdev 实现流程入口——设计检查、TDD 循环、双轴审查、提交 |
96
+ | 2 | 本 ticket 文件 | 验收标准、范围边界、交付物 |
97
+ | 3 | spec 对应 User Story / 验收标准 | 行为与验收锚点 |
98
+ | 4 | 项目 skills（如有） | 项目级约定——按实际检出路径追加，可变 |
99
+
100
+ 2. **实现** — 在 ticket 声明的范围内实现变更；遵循 I-implement 的设计检查与 TDD 红绿循环。
101
+ 3. **审查** — 单审查者检查代码质量和 spec 合规（对齐 I-implement 双轴审查意图）。
81
102
  4. **门禁** — 类型检查、测试通过。
82
103
  5. **关闭** — 提交并关闭 issue。
83
104
 
@@ -87,12 +108,14 @@ tickets-map.md 的「并行规则」节已由模板预设默认值（最大 3
87
108
  - 测试矩阵从 tickets 或 spec 的 Test Decisions 提取
88
109
  - 双轴审查的派单模板写为可复制的文本块
89
110
  - Lead 纪律写为不可协商的约束
111
+ - **§5 步骤 1 表格必须以 I-implement 为第一行**；项目 skills 仅作为后续可变项追加，不得因 skills 列表变化而挤掉或省略 I-implement
112
+ - ticket 编号、派单行、进度行一律使用纯数字（`01`），不使用 `#01`
90
113
 
91
114
  ### 草拟与确认
92
115
 
93
116
  输出 §5 完整协议文本。等待用户确认后进入治理章节。
94
117
 
95
- **完成标准**：§4 DAG 图无循环、门禁标注正确、对照表完整且经用户确认；§5 执行协议八步/精简流程已定制填入具体路径、测试矩阵和双轴审查模板，经用户确认。
118
+ **完成标准**：§4 DAG 图无循环、门禁标注正确、对照表完整且经用户确认；§5 执行协议八步/精简流程已定制填入具体路径、测试矩阵和双轴审查模板，步骤 1 清单以 I-implement 为首项，经用户确认。
96
119
 
97
120
  ## 子文件引用
98
121
 
package/template/workflows/specdev/P-goal-plan/governance-sections.md CHANGED
@@ -70,11 +70,11 @@
70
70
  #### TICKET_DONE 格式（Lead+Subagent 模型）
71
71
 
72
72
  ```
73
- TICKET_DONE #<n> (<k>/<N>) gate=<P0|P1|P2> contract_ids=<P0-01,P1-03> verify=<cmd:result> commit=<sha>
73
+ TICKET_DONE <n> (<k>/<N>) gate=<P0|P1|P2> contract_ids=<P0-01,P1-03> verify=<cmd:result> commit=<sha>
74
74
  ```
75
75
 
76
76
  字段说明：
77
- - `#<n>` —— ticket 编号
77
+ - `<n>` —— ticket 编号（两位零填充纯数字，如 `01`，不含 `#`）
78
78
  - `(<k>/<N>)` —— 进度计数（当前第几个 / 总数）
79
79
  - `gate` —— 门禁层级
80
80
  - `contract_ids` —— 如激活合同模式，列出本 ticket 覆盖的合同条目 ID，逗号分隔；如无合同则使用 `adr_ref=<ADR-NNNN>`
@@ -94,7 +94,7 @@ MILESTONE_DONE issues_closed=<N>/<N> contract_todo=0 verify=GREEN
94
94
  #### 格式变体
95
95
 
96
96
  - **切面跟踪**（ticket 数 > 15 时推荐）：在 TICKET_DONE 中增加 `slice=<ADR|DATA|SHELL|WORK|...>` 字段，按切面分组追踪进度
97
- - **简化模型**：使用简化格式 `TICKET_DONE #<n> verify=<cmd:result>`
97
+ - **简化模型**：使用简化格式 `TICKET_DONE <n> verify=<cmd:result>`
98
98
 
99
99
  ### 草拟与确认
100
100
 
package/template/workflows/specdev/P-goal-plan/lead-orchestration-protocol.md CHANGED
@@ -17,14 +17,14 @@
17
17
  | 目标规划文档 | `<Path>{roots.state}/specdev/changes/{change}/goal-plan.md</Path>` | 里程碑级约束、门禁次序、Definition of Done——子代理理解全局上下文和自身 ticket 在整体中的位置 |
18
18
  | ticket 文件 | `<Path>{roots.state}/specdev/changes/{change}/</Path>` 下对应 ticket | 验收标准、file allowlist、合同引用、阻塞关系——子代理的直接任务定义，包含「要构建什么」「范围边界」「保留/不动」 |
19
19
  | 合同验收条目 | 合同文档中本 ticket 覆盖的条目（如激活合同模式） | 编号验收条目及当前状态——子代理必须逐个满足的可检查条件 |
20
- | 实现方法参考 | `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>` | 深层模块设计原则、TDD 红绿循环、双轴审查流程——子代理的实现方法论，确保所有子代理采用一致的工程质量标准 |
20
+ | 实现方法参考 | `<Path>{roots.workflows}/specdev/I-implement/I-implement.md</Path>` | 深层模块设计原则、TDD 红绿循环、双轴审查流程——子代理的实现方法论；子代理开始实现前**必须先读**，与 goal-plan §5 步骤 1 第一项一致 |
21
21
 
22
22
  ### 1.2 派单模板
23
23
 
24
24
  Lead 向子代理发送的内容应包含以下结构化信息块，而非仅一行元数据：
25
25
 
26
26
  ```
27
- IMPLEMENTER_DISPATCH #<n>
27
+ IMPLEMENTER_DISPATCH <n>
28
28
  issue: <url>
29
29
  gate: <P0|P1|P2>
30
30
  allowlist: <files>
@@ -36,10 +36,12 @@ IMPLEMENTER_DISPATCH #<n>
36
36
  context: <{roots.state}/specdev/changes/{change}/CONTEXT.md>
37
37
  permanent_context: <{roots.state}/specdev/context/>
38
38
  goal_plan: <{roots.state}/specdev/changes/{change}/goal-plan.md>
39
- ticket_file: <{roots.state}/specdev/changes/{change}/<ticket-file>>
39
+ ticket_file: <{roots.state}/specdev/changes/{change}/ticket/<nn>-<slug>.md>
40
40
  implement_ref: <{roots.workflows}/specdev/I-implement/I-implement.md>
41
41
  ```
42
42
 
43
+ 其中 `<n>` / `<nn>` 为两位零填充纯数字 ticket 编号（如 `01`），不含 `#`。
44
+
43
45
  Lead 在生成子代理时将以上文件作为上下文传入，确保子代理在开始实现前已读取全部载荷。永久 ADR 和永久 CONTEXT 目录可能为空——静默继续。
44
46
 
45
47
  **完成标准**：每个子代理在启动时收到完整的上下文载荷（ADR、CONTEXT、goal-plan、ticket 文件、合同条目、I-implement 参考），所有路径指向真实存在的文件；IMPLEMENTER_DISPATCH 行和附加上下文已一并传递给子代理。
package/template/workflows/specdev/T-tickets/T-tickets.md CHANGED
@@ -80,7 +80,7 @@ keywords: [tickets, 拆分, 任务, 垂直切片, 阻塞, 曳光弹]
80
80
 
81
81
  迭代直到用户批准拆分方案。每次修改后重新展示完整列表。
82
82
 
83
- **完成标准**：用户已确认粒度、阻塞边与合并/拆分方案。批准后，tickets 将写入 `ticket/` 目录（一个 ticket 一个独立文件，命名为 `#NN-<name>.md`），并生成 `tickets-map.md` 作为总体地图和执行清单。
83
+ **完成标准**：用户已确认粒度、阻塞边与合并/拆分方案。批准后，tickets 将写入 `ticket/` 目录（一个 ticket 一个独立文件，命名为 `NN-<name>.md`），并生成 `tickets-map.md` 作为总体地图和执行清单。
84
84
 
85
85
  ### 5. 发布
86
86
 
@@ -92,14 +92,14 @@ keywords: [tickets, 拆分, 任务, 垂直切片, 阻塞, 曳光弹]
92
92
 
93
93
  **5b. 写入单个 ticket 文件**
94
94
 
95
- 按依赖顺序（无阻塞者在前，被阻塞者在后），为每个 ticket 创建独立文件 `<Path>{roots.state}/specdev/changes/{change}/ticket/#NN-<ticket-name>.md</Path>`。`#NN` 为 ticket 编号（`#01`, `#02`, ..., `#10`, ...），代表执行顺序。
95
+ 按依赖顺序（无阻塞者在前，被阻塞者在后），为每个 ticket 创建独立文件 `<Path>{roots.state}/specdev/changes/{change}/ticket/NN-<ticket-name>.md</Path>`。`NN` 为 ticket 编号（两位零填充阿拉伯数字：`01`, `02`, ..., `10`, ...），代表执行顺序。文件名与编号均不含 `#` 字符，避免 Markdown 链接被编码为 `%23`。
96
96
 
97
97
  每个 ticket 文件按以下模板填写：
98
98
 
99
99
  ```markdown
100
- # Ticket #NN: <标题>
100
+ # Ticket NN: <标题>
101
101
 
102
- - **被阻塞于：** `./ticket/#NN-<name>.md`, `./ticket/#NN-<name>.md`（相对路径，或多个用逗号分隔。无阻塞则写"无 —— 可立即开始"。查看被引用 ticket 文件中的状态字段自行判断是否已就绪）
102
+ - **被阻塞于：** `./ticket/NN-<name>.md`, `./ticket/NN-<name>.md`（相对路径，或多个用逗号分隔。无阻塞则写"无 —— 可立即开始"。查看被引用 ticket 文件中的状态字段自行判断是否已就绪）
103
103
  - **状态：** 未开始
104
104
 
105
105
  <!-- 如需了解整体上下文、所有 ticket 的依赖关系全景或横切关注点，请查看 `../tickets-map.md`。 -->
@@ -157,7 +157,7 @@ keywords: [tickets, 拆分, 任务, 垂直切片, 阻塞, 曳光弹]
157
157
 
158
158
  **模板填写说明：**
159
159
 
160
- - **被阻塞于**使用指向 `./ticket/` 目录的相对路径（如 `./ticket/#01-auth.md`），多个用逗号分隔。执行者应自行打开被引用的 ticket 文件查看其状态字段，判断阻塞是否已解除
160
+ - **被阻塞于**使用指向 `./ticket/` 目录的相对路径（如 `./ticket/01-auth.md`），多个用逗号分隔。执行者应自行打开被引用的 ticket 文件查看其状态字段，判断阻塞是否已解除
161
161
  - **状态**初始固定为"未开始"；实现者开始工作时改为"进行中"，完成后改为"已完成"
162
162
  - **战略与背景**是必填段——为执行者提供该 ticket 的决策锚点和当前现状。从 spec、ADR、对话中提取，不确定的标记 `[待确认]`
163
163
  - **范围边界**是必填段——明确本 ticket 的 IN/REUSE/OUT 三列，防止范围蔓延。OUT 列吸收"明确不做"的内容
@@ -178,16 +178,16 @@ T-tickets 阶段填写的列：**编号**、**Ticket**、**被阻塞于**、**
178
178
 
179
179
  **tickets-map.md 填写说明：**
180
180
 
181
- - **执行清单**的 Ticket 列使用指向 `./ticket/` 目录的相对链接（含 `#` 编号前缀）
182
- - **编号**列使用 `#01`、`#02`、`#10` 格式（`#` + 零填充序号），代表依赖顺序
183
- - **被阻塞于**列填写阻塞者的编号（如 `#01`、`#02, #05`）
181
+ - **执行清单**的 Ticket 列使用指向 `./ticket/` 目录的相对链接（纯数字编号前缀，如 `./ticket/01-auth.md`）
182
+ - **编号**列使用 `01`、`02`、`10` 格式（两位零填充阿拉伯数字，不含 `#`），代表依赖顺序
183
+ - **被阻塞于**列填写阻塞者的编号（如 `01`、`02, 05`）
184
184
  - **状态**列由 T-tickets 初始化为"未开始"，后续由实现者手动更新——始终以对应 ticket 文件中的状态字段为权威来源
185
185
  - **Gate** 列（P0/P1/P2）和 **Contract ID** 列由 P-goal-plan 填充；T-tickets 阶段留空或标 `[待标注]`
186
186
  - **依赖关系**用 ASCII 树形图展示阻塞链——T-tickets 写入基础结构，P-goal-plan 叠加门禁标注
187
187
  - **横切关注点**只放跨 ticket 的规则——单 ticket 的规则留在该 ticket 文件内
188
188
  - **阻塞关系说明**在依赖图非平凡时补充文字解释
189
189
 
190
- **完成标准**：`ticket/` 目录已创建，所有 ticket 独立文件已按依赖顺序写入（命名为 `#NN-<ticket-name>.md`）；`tickets-map.md` 已按 `<Path>{roots.workflows}/specdev/T-tickets/tickets-map-template.md</Path>` 格式写入——包含总体摘要、六列执行清单（Gate 和 Contract ID 列为 `[待标注]`）、基础依赖关系 ASCII 树形图、并行规则和横切关注点；每个 ticket 声明阻塞边、战略与背景、范围边界、交付物、保留/不动和验收标准。
190
+ **完成标准**：`ticket/` 目录已创建，所有 ticket 独立文件已按依赖顺序写入（命名为 `NN-<ticket-name>.md`）；`tickets-map.md` 已按 `<Path>{roots.workflows}/specdev/T-tickets/tickets-map-template.md</Path>` 格式写入——包含总体摘要、六列执行清单（Gate 和 Contract ID 列为 `[待标注]`）、基础依赖关系 ASCII 树形图、并行规则和横切关注点；每个 ticket 声明阻塞边、战略与背景、范围边界、交付物、保留/不动和验收标准。
191
191
 
192
192
  ## 子文件引用
193
193
 
@@ -198,7 +198,7 @@ T-tickets 阶段填写的列：**编号**、**Ticket**、**被阻塞于**、**
198
198
  本入口为单文件 work，所有 ticket 拆分流程内容均已内联。以下引用供其他 work 读取产物：
199
199
 
200
200
  - `<Path>{roots.state}/specdev/changes/{change}/tickets-map.md</Path>` —— 总体地图与执行清单（编号 | Ticket | 被阻塞于 | Gate | Contract ID | 状态），格式遵循 `<Path>{roots.workflows}/specdev/T-tickets/tickets-map-template.md</Path>`
201
- - `<Path>{roots.state}/specdev/changes/{change}/ticket/</Path>` —— 独立 ticket 文件目录，每个文件命名为 `#NN-<ticket-name>.md`（`#NN` = `#01`, `#02`, ..., `#10`, ...）
201
+ - `<Path>{roots.state}/specdev/changes/{change}/ticket/</Path>` —— 独立 ticket 文件目录，每个文件命名为 `NN-<ticket-name>.md`（`NN` = `01`, `02`, ..., `10`, ...）
202
202
  - `<Path>{roots.state}/specdev/changes/{change}/spec.md</Path>` —— 上游 spec（拆分依据）
203
203
  - `<Path>{roots.state}/specdev/adr/</Path>` —— 永久架构决策目录（已确认并提升的 ADR）
204
204
  - `<Path>{roots.state}/specdev/context/</Path>` —— 永久领域词汇表目录（已确认并提升的 CONTEXT）
package/template/workflows/specdev/T-tickets/tickets-map-template.md CHANGED
@@ -6,12 +6,12 @@
6
6
 
7
7
  | 编号 | Ticket | 被阻塞于 | Gate | Contract ID | 状态 |
8
8
  |------|--------|----------|------|-------------|------|
9
- | #01 | [ticket-name](./ticket/#01-ticket-name.md) | 无 | P0 | — | 未开始 |
10
- | #02 | [ticket-name](./ticket/#02-ticket-name.md) | #01 | P1 | P1-03 | 未开始 |
11
- | #10 | [ticket-name](./ticket/#10-ticket-name.md) | #02, #05 | P2 | — | 未开始 |
9
+ | 01 | [ticket-name](./ticket/01-<kebab-title>.md) | 无 | P0 | — | 未开始 |
10
+ | 02 | [ticket-name](./ticket/02-<kebab-title>.md) | 01 | P1 | P1-03 | 未开始 |
11
+ | 10 | [ticket-name](./ticket/10-<kebab-title>.md) | 02, 05 | P2 | — | 未开始 |
12
12
 
13
13
  > **状态枚举**：未开始 / 进行中 / 已完成。所有 ticket 初始均为"未开始"。
14
- > **被阻塞于**列填写阻塞本 ticket 的 ticket 编号（如 `#01`、`#02, #05`），执行者需自行打开对应 ticket 文件查看其状态。不可仅凭此表判断——始终以对应 ticket 文件中的状态字段为准。
14
+ > **被阻塞于**列填写阻塞本 ticket 的 ticket 编号（如 `01`、`02, 05`），执行者需自行打开对应 ticket 文件查看其状态。不可仅凭此表判断——始终以对应 ticket 文件中的状态字段为准。
15
15
  > **Gate 列**：P0 = 核心基础设施（阻塞所有后续工作）/ P1 = 主要功能切片 / P2 = 增强和边界情况。由 P-goal-plan 填充，T-tickets 阶段留空或标注 `[待标注]`。
16
16
  > **Contract ID 列**：如有冻结合同/验收文档，填写本 ticket 覆盖的验收条目 ID（如 `P0-01, P1-03`）；无合同则填 `—`。由 P-goal-plan 填充。
17
17
 
@@ -29,19 +29,19 @@
29
29
  - 扇出点标注 [FAN-OUT: N路并行]
30
30
 
31
31
  示例格式：
32
- #01 [READY] → #02 [FAN-OUT: 3路并行]
33
- ├→ #03 [P0]
34
- ├→ #04 [P1]
35
- └→ #05 [P1]
32
+ 01 [READY] → 02 [FAN-OUT: 3路并行]
33
+ ├→ 03 [P0]
34
+ ├→ 04 [P1]
35
+ └→ 05 [P1]
36
36
  --- P0 gate ---
37
- #03 → #06 [P1] → #07 [P2]
37
+ 03 → 06 [P1] → 07 [P2]
38
38
  -->
39
39
 
40
40
  ```
41
- #01-<name> ← 无阻塞，可立即开始
42
- ├── #02-<name> ← 阻塞于 #01
43
- └── #03-<name> ← 阻塞于 #01
44
- └── #04-<name> ← 阻塞于 #03
41
+ 01-<name> ← 无阻塞，可立即开始
42
+ ├── 02-<name> ← 阻塞于 01
43
+ └── 03-<name> ← 阻塞于 01
44
+ └── 04-<name> ← 阻塞于 03
45
45
  ```
46
46
 
47
47
  ## 并行规则
@@ -63,7 +63,7 @@
63
63
 
64
64
  <!-- 依赖图的文字说明。简单线性链可省略整个小节。对于扩展-收缩模式，解释三阶段。 -->
65
65
 
66
- <描述为何 ticket #B 被 ticket #A 阻塞。扩展-收缩模式：扩展阶段创建新形式 → 迁移批次逐步切换调用点 → 收缩阶段删除旧形式。>
66
+ <描述为何 ticket B 被 ticket A 阻塞。扩展-收缩模式：扩展阶段创建新形式 → 迁移批次逐步切换调用点 → 收缩阶段删除旧形式。>
67
67
 
68
68
  ## 风险与注意事项
69
69