openspec-playwright 0.3.29 → 0.3.30
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/employee-standards.md +16 -61
- package/package.json +1 -1
package/employee-standards.md
CHANGED
|
@@ -10,27 +10,17 @@
|
|
|
10
10
|
|
|
11
11
|
**项目规范**：动手前读 `openspec/config.yaml`（技术栈、结构、约定、约束等），无内容则忽略。
|
|
12
12
|
|
|
13
|
-
**E2E
|
|
14
|
-
- gstack：提供 `/browse` 探索 + `/qa` 浏览器验证（安装见 README）
|
|
15
|
-
- OpenSpec CLI：提供变更管理能力（安装见 README）
|
|
16
|
-
- openspec-playwright：提供 `/opsx:e2e` 命令（安装见 README）
|
|
17
|
-
- 项目包含 `specs/`、`changes/`、`tests/playwright/` 目录
|
|
13
|
+
**E2E 工作流前提**：工具链（gstack / OpenSpec CLI / openspec-playwright）由用户安装并维护，AI 不做安装操作。
|
|
18
14
|
|
|
19
|
-
## 1.
|
|
20
|
-
|
|
21
|
-
所有浏览器操作用 gstack 的 `/browse` 探索 + `/qa` 验证。
|
|
22
|
-
|
|
23
|
-
**冲突解决**：gstack 任何想直接修改代码的行为，都必须先确认当前 OpenSpec proposal 是否已存在并通过（检查 `changes/<name>/proposal.md` 是否处于 `approved` 状态）。
|
|
24
|
-
|
|
25
|
-
## 2. 代码质量（强制执行）
|
|
15
|
+
## 1. 代码质量（强制执行）
|
|
26
16
|
|
|
27
17
|
**动手前先思考**：列出假设，逐条验证。复杂任务如有多种解释则都列出来，如有更简单的方案则提出来，必要时坚持己见。有不清楚的地方则停下来，说出困惑，再提问。
|
|
28
18
|
|
|
29
|
-
**每步有可验证的退出条件**：多步骤任务先列计划（`1. [Step] → verify: [check]`），动手后循环验证直到成功。lint + typecheck
|
|
19
|
+
**每步有可验证的退出条件**：多步骤任务先列计划（`1. [Step] → verify: [check]`），动手后循环验证直到成功。lint + typecheck 自动执行，任一失败则停止。lint 失败时优先运行 `npm run lint:fix`。
|
|
30
20
|
|
|
31
21
|
**只写被要求的东西**：不要加"灵活"、"可配置"、单次使用的抽象、没被要求的功能。200行能50行完成则重写。
|
|
32
22
|
|
|
33
|
-
|
|
23
|
+
**精准改动**：只改必要的，改完清理自己造成的垃圾。匹配现有风格，不改进无关代码。
|
|
34
24
|
|
|
35
25
|
**lint + typecheck 通过（项目标准工具链）才算成功**。动手前扫描项目根目录源码文件扩展名检测主语言——`.py`→Python（ruff + mypy）、`.ts`/`.tsx`→TypeScript（ESLint + tsc）、`.go`→Go（gofmt + vet），工具不存在时告知用户。
|
|
36
26
|
|
|
@@ -45,12 +35,7 @@
|
|
|
45
35
|
- 禁止精度/范围假设 → 计算前确认数值在安全范围内
|
|
46
36
|
- 禁止资源泄漏假设 → 文件/连接/cursor 等使用后必须释放
|
|
47
37
|
|
|
48
|
-
|
|
49
|
-
- lint 失败：运行 `npm run lint:fix` 自动修复，手动修复剩余问题
|
|
50
|
-
- typecheck 失败：检查类型定义，修复类型错误
|
|
51
|
-
- 测试失败：检查测试用例，修复实现或测试
|
|
52
|
-
|
|
53
|
-
## 3. 上下文管理
|
|
38
|
+
## 2. 上下文管理
|
|
54
39
|
|
|
55
40
|
**文件读取完整**：超过 500 行的文件，不要假设单次读取覆盖完整内容——根据需要分次读取或编辑前重新读取完整文件。超过 10 条消息后，编辑任何文件前强制重新读取。
|
|
56
41
|
|
|
@@ -61,15 +46,17 @@
|
|
|
61
46
|
4. 运行对应语言的 lint + typecheck 验证
|
|
62
47
|
5. 然后继续实施
|
|
63
48
|
|
|
64
|
-
**OpenSpec
|
|
49
|
+
**OpenSpec 阶段隔离**：每个阶段由用户手动触发，禁止跨阶段跳步（explore 阶段不能调 apply，verify 阶段不能调 e2e）。
|
|
50
|
+
|
|
51
|
+
**禁止跨 change 改动**：执行 `/opsx:apply <X>` 期间，不得修改 `changes/<Y>/`（X≠Y）下任何文件。看到其它 open change 的"顺手清理"诱惑一律拒绝。
|
|
65
52
|
|
|
66
53
|
**重构前清死代码**：未使用的 import/export/prop/console.log 先删掉，单独提交，再做重构。
|
|
67
54
|
|
|
68
|
-
##
|
|
55
|
+
## 3. 大规模任务处理
|
|
69
56
|
|
|
70
57
|
**200 行以上修改或显著架构变更必须走 OpenSpec**：代码改动超过 200 行、或涉及新增服务/API 契约/数据模型重构时，禁止直接修改，必须通过 OpenSpec 工作流（/opsx:propose）。
|
|
71
58
|
|
|
72
|
-
##
|
|
59
|
+
## 4. 工具限制与编辑安全
|
|
73
60
|
|
|
74
61
|
**搜索要全**：用 Grep 搜内容，用 Glob 搜文件名。两者缺一不可。搜项目/工作区时默认包含所有源码类型，跳过 node_modules/、vendor/、__pycache__ 等依赖目录（调试依赖时除外）；搜子目录时按需缩小。重命名时覆盖调用、类型、字符串、`import`、barrel file、测试 mock，不得假设一次覆盖所有情况。
|
|
75
62
|
|
|
@@ -81,46 +68,14 @@
|
|
|
81
68
|
|
|
82
69
|
**中文回复**：用中文回复用户。
|
|
83
70
|
|
|
84
|
-
|
|
85
|
-
- 敏感信息：不提交 API 密钥、密码、token 等敏感信息
|
|
86
|
-
- 依赖安全：定期运行 `npm audit` 或 `yarn audit` 检查依赖漏洞
|
|
87
|
-
- 环境变量：使用 `.env` 文件存储配置，不提交到版本控制
|
|
88
|
-
|
|
89
|
-
---
|
|
90
|
-
|
|
91
|
-
## 6. 完整生产工作流
|
|
92
|
-
|
|
93
|
-
```
|
|
94
|
-
1. 探索与提案
|
|
95
|
-
2. 产品与架构评审（按需触发）
|
|
96
|
-
3. 设计审查 → /plan-design-review
|
|
97
|
-
4. 实现 → /opsx:apply
|
|
98
|
-
5. 自审 → /opsx:verify
|
|
99
|
-
6. E2E 测试 → /opsx:e2e <change-name> → /browse 探索 + /qa 验证
|
|
100
|
-
7. 发布 → 用户手动 /ship 或 /land-and-deploy
|
|
101
|
-
8. 迭代回顾 → /retro
|
|
102
|
-
```
|
|
103
|
-
|
|
104
|
-
### 步骤详解
|
|
105
|
-
|
|
106
|
-
**1. 探索与提案**：现有项目先探索（`/opsx:explore`）再写 proposal（`/opsx:propose`）；新项目（greenfield）直接生成 proposal + scenarios（记录到 `specs/` 和 `changes/`）。方向不明确时可用 `/office-hours` 做创意验证。
|
|
107
|
-
|
|
108
|
-
**2. 产品与架构评审**（按需触发）：
|
|
109
|
-
- `/plan-ceo-review`：产品战略影响、竞争格局变化时
|
|
110
|
-
- `/plan-eng-review`：架构影响（新增服务、API 契约变更、数据模型重构）时
|
|
111
|
-
|
|
112
|
-
**3. 设计审查**：在实现前进行设计评审，确保方案合理。评审通过后开始实现。
|
|
113
|
-
- `/plan-design-review`：UI/UX 方案审查，评分各设计维度，确保用户体验达标
|
|
71
|
+
**安全规范**：密钥与 `.env` 文件不入版本控制。示例代码用占位符（如 `YOUR_API_KEY`）不用真实凭据。调试日志不打印凭据/密钥/token。
|
|
114
72
|
|
|
115
|
-
|
|
116
|
-
- **变更边界检查**：实施前对照 proposal.md 确认范围，实施中禁止修改其他 changes 目录，完成后逐条对照确认
|
|
117
|
-
- **任务类型区分**：构建任务（lint+typecheck 后标记）、验证任务（实际运行后标记）、依赖任务（等前置完成）
|
|
118
|
-
- **自动化 Gate**：lint + typecheck 自动执行，任一失败则停止
|
|
73
|
+
## 5. 完整生产工作流
|
|
119
74
|
|
|
120
|
-
|
|
75
|
+
按需叠加的评审：`/plan-ceo-review`（产品战略）/ `/plan-eng-review`（架构）/ `/plan-design-review`（UX）。
|
|
121
76
|
|
|
122
|
-
|
|
77
|
+
阶段命令即触发器：`/opsx:propose` → `/opsx:apply` → `/opsx:verify` → `/opsx:e2e` → `/opsx:archive`。**所有阶段由用户手动触发，AI 不自动进入下一阶段**（详见 §2 阶段隔离）。
|
|
123
78
|
|
|
124
|
-
|
|
79
|
+
可用 `npx openspec --help` 查看更多 OpenSpec 命令。
|
|
125
80
|
|
|
126
|
-
|
|
81
|
+
方向不明时可用 `/office-hours` 做创意验证。**Healer 需要 Playwright 环境**；非 Node.js 项目请参考各自语言的 OpenSpec 测试集成。
|