@pennixrv/trellis 0.7.0-beta.45 → 0.7.0-beta.47
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.
- package/dist/commands/workflow.js +1 -1
- package/dist/commands/workflow.js.map +1 -1
- package/dist/migrations/manifests/0.7.0-beta.46.json +9 -0
- package/dist/migrations/manifests/0.7.0-beta.47.json +9 -0
- package/dist/templates/codex/hooks/session-start.py +6 -6
- package/dist/templates/common/skills/brainstorm.md +12 -0
- package/dist/templates/common/skills/break-loop.md +4 -0
- package/dist/templates/common/skills/check.md +12 -0
- package/dist/templates/copilot/hooks/session-start.py +6 -6
- package/dist/templates/markdown/spec/backend/database-guidelines.md.txt +22 -22
- package/dist/templates/markdown/spec/backend/directory-structure.md.txt +20 -20
- package/dist/templates/markdown/spec/backend/error-handling.md.txt +22 -22
- package/dist/templates/markdown/spec/backend/index.md.txt +19 -19
- package/dist/templates/markdown/spec/backend/logging-guidelines.md.txt +22 -22
- package/dist/templates/markdown/spec/backend/quality-guidelines.md.txt +22 -22
- package/dist/templates/markdown/spec/frontend/component-guidelines.md.txt +25 -25
- package/dist/templates/markdown/spec/frontend/directory-structure.md.txt +20 -20
- package/dist/templates/markdown/spec/frontend/hook-guidelines.md.txt +22 -22
- package/dist/templates/markdown/spec/frontend/index.md.txt +20 -20
- package/dist/templates/markdown/spec/frontend/quality-guidelines.md.txt +22 -22
- package/dist/templates/markdown/spec/frontend/state-management.md.txt +22 -22
- package/dist/templates/markdown/spec/frontend/type-safety.md.txt +22 -22
- package/dist/templates/markdown/spec/guides/code-reuse-thinking-guide.md.txt +80 -85
- package/dist/templates/markdown/spec/guides/cross-layer-thinking-guide.md.txt +164 -209
- package/dist/templates/markdown/spec/guides/cross-platform-thinking-guide.md.txt +161 -185
- package/dist/templates/markdown/spec/guides/index.md.txt +51 -51
- package/dist/templates/markdown/workspace-index.md +44 -44
- package/dist/templates/opencode/lib/session-utils.js +2 -2
- package/dist/templates/shared-hooks/session-start.py +7 -7
- package/dist/templates/trellis/scripts/add_session.py +35 -32
- package/dist/templates/trellis/scripts/common/developer.py +18 -18
- package/dist/templates/trellis/scripts/common/task_store.py +11 -11
- package/dist/templates/trellis/scripts/common/workflow_phase.py +4 -3
- package/dist/templates/trellis/workflow.md +403 -458
- package/package.json +2 -2
|
@@ -1,327 +1,282 @@
|
|
|
1
|
-
# Cross-Layer Thinking Guide
|
|
1
|
+
# 跨层思考指南(Cross-Layer Thinking Guide)
|
|
2
2
|
|
|
3
|
-
>
|
|
3
|
+
> **目的(Purpose)**:实现前先梳理跨层数据流。
|
|
4
4
|
|
|
5
5
|
---
|
|
6
6
|
|
|
7
|
-
## The Problem
|
|
7
|
+
## 问题(The Problem)
|
|
8
8
|
|
|
9
|
-
|
|
9
|
+
**大多数错误发生在层之间的边界,而不是层内部。**
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
常见的跨层错误:
|
|
12
12
|
|
|
13
|
-
- API
|
|
14
|
-
-
|
|
15
|
-
-
|
|
13
|
+
- API 返回格式 A,而前端期望格式 B
|
|
14
|
+
- 数据库存储 X,服务转换为 Y 时丢失数据
|
|
15
|
+
- 多个层以不同方式实现同一逻辑
|
|
16
16
|
|
|
17
17
|
---
|
|
18
18
|
|
|
19
|
-
## Before Implementing Cross-Layer Features
|
|
19
|
+
## 实现跨层功能前(Before Implementing Cross-Layer Features)
|
|
20
20
|
|
|
21
|
-
### Step 1: Map the Data Flow
|
|
21
|
+
### 第一步:绘制数据流(Step 1: Map the Data Flow)
|
|
22
22
|
|
|
23
|
-
|
|
23
|
+
画出数据如何流动:
|
|
24
24
|
|
|
25
25
|
```
|
|
26
26
|
Source → Transform → Store → Retrieve → Transform → Display
|
|
27
27
|
```
|
|
28
28
|
|
|
29
|
-
|
|
29
|
+
对每条箭头回答:
|
|
30
30
|
|
|
31
|
-
-
|
|
32
|
-
-
|
|
33
|
-
-
|
|
31
|
+
- 数据处于什么格式?
|
|
32
|
+
- 可能出现什么问题?
|
|
33
|
+
- 谁负责校验?
|
|
34
34
|
|
|
35
|
-
### Step 2: Identify Boundaries
|
|
35
|
+
### 第二步:识别边界(Step 2: Identify Boundaries)
|
|
36
36
|
|
|
37
|
-
| Boundary
|
|
37
|
+
| 边界(Boundary) | 常见问题(Common Issues) |
|
|
38
38
|
| --------------------- | --------------------------------- |
|
|
39
|
-
| API ↔ Service |
|
|
40
|
-
| Service ↔ Database |
|
|
41
|
-
| Backend ↔ Frontend |
|
|
42
|
-
| Component ↔ Component | Props
|
|
39
|
+
| API ↔ Service | 类型不匹配、字段缺失 |
|
|
40
|
+
| Service ↔ Database | 格式转换、空值处理 |
|
|
41
|
+
| Backend ↔ Frontend | 序列化、日期格式 |
|
|
42
|
+
| Component ↔ Component | Props 形状变化 |
|
|
43
43
|
|
|
44
|
-
### Step 3: Define Contracts
|
|
44
|
+
### 第三步:定义合同(Step 3: Define Contracts)
|
|
45
45
|
|
|
46
|
-
|
|
46
|
+
对每个边界:
|
|
47
47
|
|
|
48
|
-
-
|
|
49
|
-
-
|
|
50
|
-
-
|
|
48
|
+
- 精确的输入格式是什么?
|
|
49
|
+
- 精确的输出格式是什么?
|
|
50
|
+
- 可能出现哪些错误?
|
|
51
51
|
|
|
52
52
|
---
|
|
53
53
|
|
|
54
|
-
## Common Cross-Layer Mistakes
|
|
54
|
+
## 常见跨层错误(Common Cross-Layer Mistakes)
|
|
55
55
|
|
|
56
|
-
### Mistake 1: Implicit Format Assumptions
|
|
56
|
+
### 错误一:隐含的格式假设(Mistake 1: Implicit Format Assumptions)
|
|
57
57
|
|
|
58
|
-
|
|
58
|
+
**不佳**:未经核对就假定日期格式。
|
|
59
59
|
|
|
60
|
-
|
|
60
|
+
**较好**:在边界处显式进行格式转换。
|
|
61
61
|
|
|
62
|
-
### Mistake 2: Scattered Validation
|
|
62
|
+
### 错误二:分散校验(Mistake 2: Scattered Validation)
|
|
63
63
|
|
|
64
|
-
|
|
64
|
+
**不佳**:在多个层中校验同一内容。
|
|
65
65
|
|
|
66
|
-
|
|
66
|
+
**较好**:在入口处校验一次。
|
|
67
67
|
|
|
68
|
-
### Mistake 3: Leaky Abstractions
|
|
68
|
+
### 错误三:抽象泄漏(Mistake 3: Leaky Abstractions)
|
|
69
69
|
|
|
70
|
-
|
|
70
|
+
**不佳**:组件了解数据库 schema。
|
|
71
71
|
|
|
72
|
-
|
|
72
|
+
**较好**:每个层只了解相邻层。
|
|
73
73
|
|
|
74
|
-
### Mistake 4: Every Consumer Parses The Same Payload
|
|
74
|
+
### 错误四:每个消费者都解析同一载荷(Mistake 4: Every Consumer Parses The Same Payload)
|
|
75
75
|
|
|
76
|
-
|
|
76
|
+
**错误示例(Bad)**:命令读取 JSONL 事件时就地转换字段:
|
|
77
77
|
|
|
78
78
|
```typescript
|
|
79
79
|
const thread = (ev as { thread?: string }).thread;
|
|
80
80
|
const labels = (ev as { labels?: string[] }).labels;
|
|
81
81
|
```
|
|
82
82
|
|
|
83
|
-
|
|
84
|
-
event contract. The next field change will update one command and miss another.
|
|
83
|
+
这看似是局部处理,但意味着每个消费者都拥有一份私有事件合同。下次字段变化时,一个命令可能更新了,另一个命令却遗漏了。
|
|
85
84
|
|
|
86
|
-
|
|
85
|
+
**较好**:在事件边界解码一次,然后导出带类型的投影:
|
|
87
86
|
|
|
88
87
|
```typescript
|
|
89
88
|
if (!isThreadEvent(ev)) return false;
|
|
90
89
|
return ev.thread === filter.thread;
|
|
91
90
|
```
|
|
92
91
|
|
|
93
|
-
|
|
94
|
-
create one owner for:
|
|
92
|
+
**规则**:对于只追加日志、JSON 流、RPC 载荷或配置文件,应由一个 owner 负责:
|
|
95
93
|
|
|
96
|
-
-
|
|
97
|
-
-
|
|
98
|
-
-
|
|
99
|
-
-
|
|
94
|
+
- 事件/载荷类型定义
|
|
95
|
+
- 从 `unknown` 开始的类型守卫和规范化
|
|
96
|
+
- UI 命令使用的元数据投影
|
|
97
|
+
- 根据事实来源重放状态的 reducer
|
|
100
98
|
|
|
101
|
-
|
|
99
|
+
渲染代码可以格式化字段,但不得重新定义载荷合同。
|
|
102
100
|
|
|
103
101
|
---
|
|
104
102
|
|
|
105
|
-
## Checklist for Cross-Layer Features
|
|
103
|
+
## 跨层功能清单(Checklist for Cross-Layer Features)
|
|
106
104
|
|
|
107
|
-
|
|
105
|
+
实现前:
|
|
108
106
|
|
|
109
|
-
- [ ]
|
|
110
|
-
- [ ]
|
|
111
|
-
- [ ]
|
|
112
|
-
- [ ]
|
|
107
|
+
- [ ] 已绘制完整数据流
|
|
108
|
+
- [ ] 已识别所有层边界
|
|
109
|
+
- [ ] 已定义每个边界的格式
|
|
110
|
+
- [ ] 已决定校验发生的位置
|
|
113
111
|
|
|
114
|
-
|
|
112
|
+
实现后:
|
|
115
113
|
|
|
116
|
-
- [ ]
|
|
117
|
-
- [ ]
|
|
118
|
-
- [ ]
|
|
119
|
-
- [ ]
|
|
120
|
-
|
|
121
|
-
- [ ] Checked that derived state points back to the source event identifier
|
|
122
|
-
(`seq`, `id`, `version`) instead of inventing a second cursor
|
|
114
|
+
- [ ] 已使用边界情况测试(null、空值、无效值)
|
|
115
|
+
- [ ] 已验证每个边界的错误处理
|
|
116
|
+
- [ ] 已确认数据能够完整往返
|
|
117
|
+
- [ ] 已确认消费者导入共享解码器/投影,而不是在本地转换载荷字段
|
|
118
|
+
- [ ] 已确认派生状态指向源事件标识符(`seq`、`id`、`version`),而不是另造第二个游标
|
|
123
119
|
|
|
124
120
|
---
|
|
125
121
|
|
|
126
|
-
## Cross-Platform Template Consistency
|
|
122
|
+
## 跨平台模板一致性(Cross-Platform Template Consistency)
|
|
127
123
|
|
|
128
|
-
|
|
124
|
+
在 Trellis 中,命令模板(例如 `record-session.md`)存在于**多个平台**,内容相同或近似。这就是一个跨层边界。
|
|
129
125
|
|
|
130
|
-
### Checklist: After Modifying Any Command Template
|
|
126
|
+
### 清单:修改任意命令模板后(Checklist: After Modifying Any Command Template)
|
|
131
127
|
|
|
132
|
-
- [ ]
|
|
133
|
-
- [ ]
|
|
134
|
-
- [ ]
|
|
135
|
-
- [ ]
|
|
128
|
+
- [ ] 找到包含同一命令的所有平台:`find src/templates/*/commands/trellis/ -name "<command>.*"`
|
|
129
|
+
- [ ] 更新所有平台副本(Markdown `.md` 和 TOML `.toml`)
|
|
130
|
+
- [ ] 对 Gemini TOML 适配续行符(`\\` 与 `\`)和三引号字符串
|
|
131
|
+
- [ ] 运行 `/trellis:check-cross-layer`,确认没有遗漏
|
|
136
132
|
|
|
137
|
-
|
|
133
|
+
**真实示例**:在 Claude 中将 `record-session.md` 更新为使用 `--mode record`,却遗漏了 iFlow、Kilo、OpenCode 和 Gemini,最终由跨层检查发现。
|
|
138
134
|
|
|
139
135
|
---
|
|
140
136
|
|
|
141
|
-
## Generated Runtime Template Upgrade Consistency
|
|
137
|
+
## 生成运行时模板的升级一致性(Generated Runtime Template Upgrade Consistency)
|
|
142
138
|
|
|
143
|
-
|
|
144
|
-
`.trellis/workflow.md` is parsed by `get_context.py`, `workflow_phase.py`,
|
|
145
|
-
SessionStart filters, and per-turn hooks. Template changes must be validated
|
|
146
|
-
against both fresh init and upgrade paths.
|
|
139
|
+
一些生成文件同时是文档和运行时输入。在 Trellis 中,`.trellis/workflow.md` 会被 `get_context.py`、`workflow_phase.py`、SessionStart 过滤器和逐轮 Hook 解析。模板变更必须同时通过全新 init 和升级路径验证。
|
|
147
140
|
|
|
148
|
-
### Checklist: After Modifying A Runtime-Parsed Template
|
|
141
|
+
### 清单:修改运行时解析的模板后(Checklist: After Modifying A Runtime-Parsed Template)
|
|
149
142
|
|
|
150
|
-
- [ ]
|
|
151
|
-
|
|
152
|
-
- [ ]
|
|
153
|
-
|
|
154
|
-
- [ ]
|
|
155
|
-
the older `.trellis/.version`
|
|
156
|
-
- [ ] Add an upgrade regression using an older pristine template fixture, then
|
|
157
|
-
assert the installed file reaches the current packaged shape
|
|
158
|
-
- [ ] Update the backend spec that owns the runtime contract
|
|
143
|
+
- [ ] 找到读取模板的所有运行时解析器,而不只是安装模板的文件写入器
|
|
144
|
+
- [ ] 检查相关语法是否位于明显托管区域(例如标记块)之外
|
|
145
|
+
- [ ] 验证全新 `init` 输出,以及写入旧 `.trellis/.version` 的版本化 `update` 场景
|
|
146
|
+
- [ ] 使用旧的干净模板 fixture 增加升级回归,并断言安装文件达到当前打包形态
|
|
147
|
+
- [ ] 更新负责运行时合同的后端 spec
|
|
159
148
|
|
|
160
149
|
---
|
|
161
150
|
|
|
162
|
-
## Versioned Documentation Boundary
|
|
163
|
-
|
|
164
|
-
|
|
165
|
-
|
|
166
|
-
|
|
167
|
-
|
|
168
|
-
|
|
169
|
-
|
|
170
|
-
-
|
|
171
|
-
-
|
|
172
|
-
-
|
|
173
|
-
|
|
174
|
-
|
|
175
|
-
- [ ]
|
|
176
|
-
|
|
177
|
-
|
|
178
|
-
|
|
179
|
-
|
|
180
|
-
**Real-world example**: A beta-only task workflow change documented
|
|
181
|
-
`prd.md` + `design.md` + `implement.md`, task-creation consent, and Codex
|
|
182
|
-
mode banners under root `start/` and `advanced/` paths. The docs site then
|
|
183
|
-
served 0.6 beta behavior under the Release selector. The fix was to restore root
|
|
184
|
-
release docs, move the 0.6 content to `beta/` and `zh/beta/`, and add a grep
|
|
185
|
-
audit for beta markers against the root release tree.
|
|
186
|
-
|
|
187
|
-
**Real-world example**: Codex inline mode changed workflow platform markers from
|
|
188
|
-
`[Codex]` / `[Kilo, Antigravity, Windsurf]` to `[codex-sub-agent]` /
|
|
189
|
-
`[codex-inline, Kilo, Antigravity, Windsurf]`. Fresh init was correct, but
|
|
190
|
-
`trellis update` only merged `[workflow-state:*]` blocks and preserved stale
|
|
191
|
-
markers outside those blocks. Result: upgraded projects got new hook scripts
|
|
192
|
-
but old workflow routing, so `get_context.py --mode phase --platform codex`
|
|
193
|
-
could return empty Phase 2.1 detail.
|
|
151
|
+
## 版本化文档边界(Versioned Documentation Boundary)
|
|
152
|
+
|
|
153
|
+
版本化文档是一个跨层边界:源路径、`docs.json` 版本路由和渲染后的版本选择器必须描述同一条发布线。
|
|
154
|
+
|
|
155
|
+
### 清单:编辑版本化文档前(Checklist: Before Editing Versioned Docs)
|
|
156
|
+
|
|
157
|
+
- [ ] 确认目标发布线:stable、beta 或 RC
|
|
158
|
+
- [ ] 确认编辑的 MDX 路径与发布线匹配:
|
|
159
|
+
- stable:`docs-site/{start,advanced,...}` 和 `docs-site/zh/{start,advanced,...}`
|
|
160
|
+
- beta:`docs-site/beta/**` 和 `docs-site/zh/beta/**`
|
|
161
|
+
- RC:`docs-site/rc/**` 和 `docs-site/zh/rc/**`
|
|
162
|
+
- [ ] 确认 `docs.json` 导航将版本标签指向相同路径
|
|
163
|
+
- [ ] 提交前在另一棵目录树中 grep 发布线专属术语
|
|
164
|
+
- [ ] 将根发布路径下出现 beta 内容视为源路径错误,而不是渲染错误
|
|
165
|
+
|
|
166
|
+
**真实示例**:一个仅属于 beta 的任务工作流变更,将 `prd.md`、`design.md`、`implement.md`、任务创建确认和 Codex 模式提示写到了根 `start/` 与 `advanced/` 路径。文档站点随后在 Release 选择器下提供了 0.6 beta 行为。修复方式是恢复根发布文档,将 0.6 内容移动到 `beta/` 和 `zh/beta/`,并对根发布目录中的 beta 标记增加 grep 审查。
|
|
167
|
+
|
|
168
|
+
**真实示例**:Codex inline 模式将工作流平台标记从 `[Codex]` / `[Kilo, Antigravity, Windsurf]` 改为 `[codex-sub-agent]` / `[codex-inline, Kilo, Antigravity, Windsurf]`。全新 init 正确,但 `trellis update` 只合并了 `[workflow-state:*]` 块,保留了这些块之外的旧标记。结果是升级项目获得了新 Hook 脚本,却仍使用旧工作流路由,`get_context.py --mode phase --platform codex` 可能返回空的 Phase 2.1 详情。
|
|
194
169
|
|
|
195
170
|
---
|
|
196
171
|
|
|
197
|
-
## Mode-Detection Probe Checklist
|
|
172
|
+
## 模式检测探针清单(Mode-Detection Probe Checklist)
|
|
198
173
|
|
|
199
|
-
|
|
174
|
+
当 CLI 通过探测远程资源自动检测模式时(例如检查是否存在 `index.json`,以决定使用 marketplace 还是直接下载):
|
|
200
175
|
|
|
201
|
-
### Before implementing
|
|
176
|
+
### 实现前(Before implementing)
|
|
202
177
|
|
|
203
|
-
- [ ]
|
|
204
|
-
- [ ] 404
|
|
205
|
-
- [ ]
|
|
206
|
-
- [ ]
|
|
207
|
-
- [ ]
|
|
178
|
+
- [ ] 探针在使用该结果的**所有**代码路径中运行(交互式、`-y`、`--flag` 组合)
|
|
179
|
+
- [ ] 区分 404 与临时错误,不要都当作“未找到”
|
|
180
|
+
- [ ] 临时错误必须**中止或重试**,不能静默切换模式
|
|
181
|
+
- [ ] 上下文变化时重置共享状态(缓存、预取数据)(例如用户切换来源)
|
|
182
|
+
- [ ] **快捷路径**(例如 `--template` 跳过选择器)必须与探测路径具有相同的错误处理质量,检查下游函数是否调用了兜底包装器
|
|
208
183
|
|
|
209
|
-
### After implementing
|
|
184
|
+
### 实现后(After implementing)
|
|
210
185
|
|
|
211
|
-
- [ ]
|
|
212
|
-
- [ ]
|
|
213
|
-
- [ ]
|
|
214
|
-
- [ ]
|
|
215
|
-
- [ ]
|
|
186
|
+
- [ ] 跟踪从探针结果到模式决策分支的每条路径,不允许无意落入其他路径
|
|
187
|
+
- [ ] 外部格式合同(giget URI、原始 URL)已经测试,或至少以注释记录
|
|
188
|
+
- [ ] 元数据读取完整响应,或使用流式解析器,不能把固定大小的前缀当作完整 JSON 解析
|
|
189
|
+
- [ ] 从解析部分重建复合标识符时,确认包含**所有**字段且位置**正确**(例如 `provider:repo/path#ref`,而不是 `provider:repo#ref/path`)
|
|
190
|
+
- [ ] 确认快捷路径之后调用的**动作函数**没有内部使用旧的兜底获取逻辑;需要区分错误时必须使用具备探测质量的变体
|
|
216
191
|
|
|
217
|
-
|
|
192
|
+
**真实示例**:自定义 registry 流程在三轮审查中发现了 8 个错误:(1) 探针只在交互模式运行;(2) 临时错误落入错误模式;(3) giget URI 中 `#ref` 位置错误;(4) 预取模板泄漏到来源切换之后;(5) `--template` 快捷路径绕过探针,但 `downloadTemplateById` 内部使用兜底的 `fetchTemplateIndex`,将超时变成“模板未找到”。
|
|
218
193
|
|
|
219
|
-
|
|
194
|
+
**真实示例**:Agent session 更新提示使用 `response.read(4096)` 获取 npm `latest` 元数据,然后把它作为完整 JSON 解析。`@pennixrv/trellis` 的包元数据超过 4 KB,JSON 被截断,解析静默失败,第一次会话注入没有显示更新提示。修复方式是解析前读取完整响应,并增加 `version` 后跟随 8 KB 元数据尾部的回归测试。
|
|
220
195
|
|
|
221
196
|
---
|
|
222
197
|
|
|
223
|
-
## Cross-Platform Template Consistency
|
|
198
|
+
## 跨平台模板一致性(Cross-Platform Template Consistency)
|
|
224
199
|
|
|
225
|
-
|
|
200
|
+
在 Trellis 中,命令模板(例如 `record-session.md`)存在于**多个平台**,内容相同或近似。这就是一个跨层边界。
|
|
226
201
|
|
|
227
|
-
### Checklist: After Modifying Any Command Template
|
|
202
|
+
### 清单:修改任意命令模板后(Checklist: After Modifying Any Command Template)
|
|
228
203
|
|
|
229
|
-
- [ ]
|
|
230
|
-
- [ ]
|
|
231
|
-
- [ ]
|
|
232
|
-
- [ ]
|
|
204
|
+
- [ ] 找到包含同一命令的所有平台:`find src/templates/*/commands/trellis/ -name "<command>.*"`
|
|
205
|
+
- [ ] 更新所有平台副本(Markdown `.md` 和 TOML `.toml`)
|
|
206
|
+
- [ ] 对 Gemini TOML 适配续行符(`\\` 与 `\`)和三引号字符串
|
|
207
|
+
- [ ] 运行 `/trellis:check-cross-layer`,确认没有遗漏
|
|
233
208
|
|
|
234
|
-
|
|
209
|
+
**真实示例**:在 Claude 中将 `record-session.md` 更新为使用 `--mode record`,却遗漏了 iFlow、Kilo、OpenCode 和 Gemini,最终由跨层检查发现。
|
|
235
210
|
|
|
236
211
|
---
|
|
237
212
|
|
|
238
|
-
## Generated Runtime Template Upgrade Consistency
|
|
239
|
-
|
|
240
|
-
|
|
241
|
-
|
|
242
|
-
|
|
243
|
-
|
|
244
|
-
|
|
245
|
-
|
|
246
|
-
|
|
247
|
-
- [ ]
|
|
248
|
-
|
|
249
|
-
|
|
250
|
-
|
|
251
|
-
- [ ] Verify fresh `init` output and a versioned `update` scenario that writes
|
|
252
|
-
the older `.trellis/.version`
|
|
253
|
-
- [ ] Add an upgrade regression using an older pristine template fixture, then
|
|
254
|
-
assert the installed file reaches the current packaged shape
|
|
255
|
-
- [ ] Update the backend spec that owns the runtime contract
|
|
256
|
-
|
|
257
|
-
**Real-world example**: Codex inline mode changed workflow platform markers from
|
|
258
|
-
`[Codex]` / `[Kilo, Antigravity, Windsurf]` to `[codex-sub-agent]` /
|
|
259
|
-
`[codex-inline, Kilo, Antigravity, Windsurf]`. Fresh init was correct, but
|
|
260
|
-
`trellis update` only merged `[workflow-state:*]` blocks and preserved stale
|
|
261
|
-
markers outside those blocks. Result: upgraded projects got new hook scripts
|
|
262
|
-
but old workflow routing, so `get_context.py --mode phase --platform codex`
|
|
263
|
-
could return empty Phase 2.1 detail.
|
|
213
|
+
## 生成运行时模板的升级一致性(Generated Runtime Template Upgrade Consistency)
|
|
214
|
+
|
|
215
|
+
一些生成文件同时是文档和运行时输入。在 Trellis 中,`.trellis/workflow.md` 会被 `get_context.py`、`workflow_phase.py`、SessionStart 过滤器和逐轮 Hook 解析。模板变更必须同时通过全新 init 和升级路径验证。
|
|
216
|
+
|
|
217
|
+
### 清单:修改运行时解析的模板后(Checklist: After Modifying A Runtime-Parsed Template)
|
|
218
|
+
|
|
219
|
+
- [ ] 找到读取模板的所有运行时解析器,而不只是安装模板的文件写入器
|
|
220
|
+
- [ ] 检查相关语法是否位于明显托管区域(例如标记块)之外
|
|
221
|
+
- [ ] 验证全新 `init` 输出,以及写入旧 `.trellis/.version` 的版本化 `update` 场景
|
|
222
|
+
- [ ] 使用旧的干净模板 fixture 增加升级回归,并断言安装文件达到当前打包形态
|
|
223
|
+
- [ ] 更新负责运行时合同的后端 spec
|
|
224
|
+
|
|
225
|
+
**真实示例**:Codex inline 模式将工作流平台标记从 `[Codex]` / `[Kilo, Antigravity, Windsurf]` 改为 `[codex-sub-agent]` / `[codex-inline, Kilo, Antigravity, Windsurf]`。全新 init 正确,但 `trellis update` 只合并了 `[workflow-state:*]` 块,保留了这些块之外的旧标记。结果是升级项目获得了新 Hook 脚本,却仍使用旧工作流路由,`get_context.py --mode phase --platform codex` 可能返回空的 Phase 2.1 详情。
|
|
264
226
|
|
|
265
227
|
---
|
|
266
228
|
|
|
267
|
-
## Mode-Detection Probe Checklist
|
|
229
|
+
## 模式检测探针清单(Mode-Detection Probe Checklist)
|
|
268
230
|
|
|
269
|
-
|
|
231
|
+
当 CLI 通过探测远程资源自动检测模式时(例如检查是否存在 `index.json`,以决定使用 marketplace 还是直接下载):
|
|
270
232
|
|
|
271
|
-
### Before implementing
|
|
272
|
-
- [ ]
|
|
273
|
-
- [ ] 404
|
|
274
|
-
- [ ]
|
|
275
|
-
- [ ]
|
|
276
|
-
- [ ]
|
|
233
|
+
### 实现前(Before implementing)
|
|
234
|
+
- [ ] 探测覆盖使用其结果的**所有**代码路径(交互式、`-y`、`--flag` 组合)
|
|
235
|
+
- [ ] 区分 404 与临时错误,不把两者都当成“未找到”
|
|
236
|
+
- [ ] 临时错误会**中止或重试**,不会静默切换模式
|
|
237
|
+
- [ ] 上下文变化时(如用户切换来源),共享状态(缓存、预取数据)会**重置**
|
|
238
|
+
- [ ] **快捷路径**(如 `--template` 跳过选择器)具有与探测路径相同的错误处理质量;检查下游函数没有调用笼统捕获错误的包装器
|
|
277
239
|
|
|
278
|
-
### After implementing
|
|
279
|
-
- [ ]
|
|
280
|
-
- [ ]
|
|
281
|
-
- [ ]
|
|
282
|
-
- [ ]
|
|
283
|
-
- [ ]
|
|
240
|
+
### 实现后(After implementing)
|
|
241
|
+
- [ ] 跟踪从探测结果到模式决策分支的每条路径,不发生意外贯穿
|
|
242
|
+
- [ ] 外部格式合同(giget URI、原始 URL)经过测试,或至少有注释说明
|
|
243
|
+
- [ ] 元数据读取完整响应或使用流式解析器,不把固定长度前缀当成完整 JSON
|
|
244
|
+
- [ ] 从解析结果重建复合标识时,核对**全部**字段均包含且处于**正确位置**(如 `provider:repo/path#ref`,而非 `provider:repo#ref/path`)
|
|
245
|
+
- [ ] 核对快捷路径后的**动作函数**没有在内部使用旧的笼统捕获错误的获取逻辑;需要区分错误时,必须使用与探测同等质量的版本
|
|
284
246
|
|
|
285
|
-
|
|
247
|
+
**真实示例**:自定义 registry 流程在三轮审查中发现了 8 个错误:(1) 探针只在交互模式运行;(2) 临时错误落入错误模式;(3) giget URI 中 `#ref` 位置错误;(4) 预取模板泄漏到来源切换之后;(5) `--template` 快捷路径绕过探针,但 `downloadTemplateById` 内部使用兜底的 `fetchTemplateIndex`,将超时变成“模板未找到”。
|
|
286
248
|
|
|
287
|
-
|
|
249
|
+
**真实示例**:Agent session 更新提示使用 `response.read(4096)` 获取 npm `latest` 元数据,然后把它作为完整 JSON 解析。`@pennixrv/trellis` 的包元数据超过 4 KB,JSON 被截断,解析静默失败,第一次会话注入没有显示更新提示。修复方式是解析前读取完整响应,并增加 `version` 后跟随 8 KB 元数据尾部的回归测试。
|
|
288
250
|
|
|
289
251
|
---
|
|
290
252
|
|
|
291
|
-
## When to Create Flow Documentation
|
|
253
|
+
## 何时创建流程文档(When to Create Flow Documentation)
|
|
292
254
|
|
|
293
|
-
|
|
255
|
+
在以下情况创建详细流程文档:
|
|
294
256
|
|
|
295
|
-
-
|
|
296
|
-
-
|
|
297
|
-
-
|
|
298
|
-
-
|
|
257
|
+
- 功能跨越三个或更多层
|
|
258
|
+
- 涉及多个团队
|
|
259
|
+
- 数据格式复杂
|
|
260
|
+
- 该功能过去曾经引发错误
|
|
299
261
|
|
|
300
262
|
---
|
|
301
263
|
|
|
302
|
-
## Event Log / Projection Boundary
|
|
264
|
+
## 事件日志/投影边界(Event Log / Projection Boundary)
|
|
303
265
|
|
|
304
|
-
|
|
266
|
+
只追加日志是跨层合同。单个事件会经过:
|
|
305
267
|
|
|
306
268
|
```
|
|
307
269
|
CLI input → event writer → events.jsonl → reader → filter → reducer → display
|
|
308
270
|
```
|
|
309
271
|
|
|
310
|
-
### Checklist: After Adding A New Event Kind Or Field
|
|
311
|
-
|
|
312
|
-
- [ ]
|
|
313
|
-
- [ ]
|
|
314
|
-
- [ ]
|
|
315
|
-
|
|
316
|
-
- [ ]
|
|
317
|
-
- [ ]
|
|
318
|
-
- [ ]
|
|
319
|
-
|
|
320
|
-
|
|
321
|
-
|
|
322
|
-
**Real-world example**: Thread channels added `kind: "thread"`, `description`,
|
|
323
|
-
`context`, labels, and `lastSeq`. The first implementation replayed thread
|
|
324
|
-
state correctly, but several commands still re-parsed event payload fields with
|
|
325
|
-
local casts. The fix was to make the core event layer own `ThreadChannelEvent`
|
|
326
|
-
and `isThreadEvent`, make `reduceChannelMetadata` the only channel metadata
|
|
327
|
-
projection, and make `reduceThreads` the only thread replay reducer.
|
|
272
|
+
### 清单:增加新的事件类型或字段后(Checklist: After Adding A New Event Kind Or Field)
|
|
273
|
+
|
|
274
|
+
- [ ] 将事件类型加入中央事件分类
|
|
275
|
+
- [ ] 在事件层增加带类型的事件变体或类型守卫
|
|
276
|
+
- [ ] 为来自用户输入或 JSON 的数组/对象字段增加规范化辅助函数
|
|
277
|
+
- [ ] 只在事件写入器中分配 `seq` / `id`
|
|
278
|
+
- [ ] 让过滤器和 reducer 使用带类型的事件守卫,而不是本地断言
|
|
279
|
+
- [ ] 让展示代码使用 reducer 输出或带类型事件,而不是原始 JSON
|
|
280
|
+
- [ ] 至少增加一项回归测试,证明历史重放和实时过滤使用相同的过滤模型
|
|
281
|
+
|
|
282
|
+
**真实示例**:Thread channel 增加了 `kind: "thread"`、`description`、`context`、labels 和 `lastSeq`。首版实现能够正确重放 thread 状态,但多个命令仍使用本地断言重新解析事件载荷字段。修复方式是让核心事件层负责 `ThreadChannelEvent` 和 `isThreadEvent`,让 `reduceChannelMetadata` 成为唯一的 channel 元数据投影,让 `reduceThreads` 成为唯一的 thread 重放 reducer。
|