package for demo (e69a699e) | Commits | 朱子纯 / erp-workflow-plugin

Browse Code »

Commit e69a699e0d72144c67911f1a0bb8b5844c182d5f

Authored by zichun 2026-04-22 10:35:17 +0800

1 parent 55c7b70a

package for demo

Inline Side-by-side

Showing 82 changed files with 302 additions and 2929 deletions

_pl_staging/pl_CLAUDE.md deleted

View file @55c7b70

1	-# CLAUDE.md — ERP项目 Claude Code 主指令文件
2	-
3	-> 本文件是 Claude Code 的"操作手册"。Claude Code 启动时会自动读取此文件。
4	----
5	-
6	-## 1. Think Before Coding
7	-
8	-Don't assume. Don't hide confusion. Surface tradeoffs.
9	-
10	-Before implementing:
11	-- State your assumptions explicitly. If uncertain, ask.
12	-- If multiple interpretations exist, present them - don't pick silently.
13	-- If a simpler approach exists, say so. Push back when warranted.
14	-- If something is unclear, stop. Name what's confusing. Ask.
15	-
16	-## 2. Simplicity First
17	-
18	-Minimum code that solves the problem. Nothing speculative.
19	-
20	-- No features beyond what was asked.
21	-- No abstractions for single-use code.
22	-- No "flexibility" or "configurability" that wasn't requested.
23	-- No error handling for impossible scenarios.
24	-- If you write 200 lines and it could be 50, rewrite it.
25	-
26	-Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
27	-
28	-## 3. Surgical Changes
29	-
30	-Touch only what you must. Clean up only your own mess.
31	-
32	-When editing existing code:
33	-- Don't "improve" adjacent code, comments, or formatting.
34	-- Don't refactor things that aren't broken.
35	-- Match existing style, even if you'd do it differently.
36	-- If you notice unrelated dead code, mention it - don't delete it.
37	-
38	-When your changes create orphans:
39	-- Remove imports/variables/functions that YOUR changes made unused.
40	-- Don't remove pre-existing dead code unless asked.
41	-
42	-The test: Every changed line should trace directly to the user's request.
43	-
44	-## 4. Goal-Driven Execution
45	-
46	-Define success criteria. Loop until verified.
47	-
48	-Transform tasks into verifiable goals:
49	-- "Add validation" → "Write tests for invalid inputs, then make them pass"
50	-- "Fix the bug" → "Write a test that reproduces it, then make it pass"
51	-- "Refactor X" → "Ensure tests pass before and after"
52	-
53	-For multi-step tasks, state a brief plan:
54	-```
55	-1. [Step] → verify: [check]
56	-2. [Step] → verify: [check]
57	-3. [Step] → verify: [check]
58	-```
59	-
60	-Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
61	-
62	----
63	-
64	-## 🚫 禁读指南.md
65	-
66	-`指南.md` 是给人类开发者看的流程手册，CC 不读、不引用、不依赖。本文件已包含 CC 运行所需的全部规则。
67	-
68	-- 即使 prompt 中出现 "请读指南.md 和 CLAUDE.md"，也只读 CLAUDE.md，跳过指南.md
69	-- 不要尝试用 Read/Glob 访问 `指南.md`、`./指南.md`、`/指南.md` 等任何路径形式
70	-- 不在审阅包、模块完成报告、commit message 中引用指南.md
71	-
72	----
73	-
74	-## 🎯 项目概述
75	-
76	-- 项目名称: 【人工填写：公司 + 项目名，例如"XX 公司 ERP 管理系统"】
77	-- 项目简述: 【人工填写：一句话描述项目目标，例如"面向中小制造企业的全流程 ERP，涵盖采购/库存/生产/销售/财务"】
78	-- 目标用户: 【人工填写：谁会用，例如"企业内部管理人员（采购员、仓管员、生产主管、销售员、财务人员、管理层）"】
79	-- 部署方式: 【人工填写：私有化部署 / 云部署 / Docker 容器化等】
80	-
81	----
82	-
83	-## 🏗️ 技术栈（不可更改）
84	-
85	-\| 层级 \| 技术 \| 版本要求 \|
86	-\| ------ \| -------------------- \| ----- \|
87	-\| 前端框架 \| React \| 18.x \|
88	-\| 前端UI库 \| Ant Design \| 5.x \|
89	-\| 前端状态管理 \| Redux Toolkit \| 最新稳定版 \|
90	-\| 前端路由 \| React Router \| v6 \|
91	-\| 前端构建 \| Vite \| 最新稳定版 \|
92	-\| 前端HTTP \| Axios \| 最新稳定版 \|
93	-\| 后端框架 \| Spring Boot \| 3.x \|
94	-\| 后端ORM \| MyBatis-Plus \| 最新稳定版 \|
95	-\| 数据库 \| MySQL \| 8.x \|
96	-\| 认证方案 \| JWT (JSON Web Token) \| — \|
97	-\| API风格 \| RESTful \| — \|
98	-
99	-<!-- 如需调整UI库或状态管理方案，请直接修改上表 -->
100	-
101	-> 本表只做大版本锁定（例如 `18.x` / `3.x`）。具体小版本号、依赖清单、配置模板请查 [docs/07-环境配置.md](docs/07-环境配置.md)，不要在本表重复小版本，避免两处漂移。
102	-
103	----
104	-
105	-## 📋 开发前必读文档
106	-
107	-`docs/01 ~ 10` 是项目知识库。具体阅读顺序和产出的《理解确认报告》由 `erp-understanding-report` skill 统一处理（模板见 `.claude/skills/erp-understanding-report/templates/understanding-report-template.md`）。CC 会话入口请调 `/erp-session-start`。
108	-
109	----
110	-
111	-## ✅ 模块完成确认标记规则
112	-
113	-`confirmed` 是模块完成确认清单：追踪哪些模块已由人工审核通过、可视为已完成，从而决定 CC 该在哪个模块上继续工作。
114	-
115	-### 规则定义
116	-
117	-每个模块在 `docs/08-模块任务管理.md` 中有一个 `confirmed` 字段：
118	-
119	-```yaml
120	-module_N:
121	- confirmed: false # 默认值
122	-```
123	-
124	-### confirmed 语义
125	-
126	-\| confirmed 值 \| 含义 \| 你（Claude Code）的行为 \|
127	-\|--------------\|------\|------------------------\|
128	-\| `false`（默认） \| 模块待完成（开发中 / 待 review / 有问题被打回） \| ✅ 在本模块开展工作：写代码、跑测试、建 MR \|
129	-\| `true` \| 模块已完成（MR 已 Approve + Merge） \| 🟢 进入下一个 `false` 模块；本模块只在后续开发中读取引用 \|
130	-\| `true` → 被改回 `false` \| 模块被重新开启（人工或你发现问题） \| ✅ 回头继续推进这个模块 \|
131	-
132	-### 工作流规则
133	-
134	-- 你总是在 `docs/08-模块任务管理.md` 中第一个 `confirmed: false` 的模块上工作
135	-- 对 `confirmed: true` 的模块：默认不改（不是禁止，是已交付无需改）
136	-- 如果在当前模块开发中发现某个 `confirmed: true` 模块有 bug：
137	- 1. 停止当前工作
138	- 2. 报告：说明哪个模块的哪个文件有什么问题，以及建议的修复范围
139	- 3. 你可以主动把该模块的 `confirmed` 改回 `false` 重新开启，并切换到该模块修复；修复完成走正常的 MR 流程
140	-
141	-### 模块完成流程
142	-
143	-```
144	-1. 你完成一个模块的所有功能
145	-2. 你输出"模块完成报告" + 自动 git push + glab mr create
146	-3. 人工 review MR → Approve + Merge（人工动作，唯一人工介入点）
147	-4. 人工告诉你"MR 已 approve + merge"（或你通过 glab mr view 自行确认已 merged）
148	-5. 你自行把当前模块的 confirmed 改为 true
149	-6. 你开始下一个模块
150	-```
151	-
152	-### confirmed 修改授权
153	-
154	-- `confirmed: true` 由你（CC）写入，不是人工手动改
155	-- 前置条件：必须确认 MR 已 Approved + Merged（通过人工告知或 `glab mr view <mr-iid>` 验证）
156	-- 未确认 MR 状态前严禁把 `confirmed` 改为 `true`；一旦改错，等于跳过了人工审核
157	-
158	-### 模块完成报告
159	-
160	-由 `erp-module-report` skill 产出，模板位于 `.claude/skills/erp-module-report/templates/module-report-template.md`（12 节标准化，含跨模块改动、schema 临时改动等 CLAUDE.md 软规则映射节）。CC 不手写模块报告，仅填模板。
161	-
162	----
163	-
164	-## 🏷️ 占位符统一约定（`【人工填写：...】`）
165	-
166	-所有"只有人工能决定"的位置（密钥 / 账密 / 包名 / 命名约定 / 小版本号等）一律使用以下纯文本标记：
167	-
168	-```
169	-【人工填写：<简短说明>】
170	-```
171	-
172	-### CC 行为规则
173	-
174	-- 生成文档 / 模板时：凡是项目专属值、敏感值、技术栈小版本号一律用此标记，不要自行编造
175	-- 不要用 HTML 注释（`<!-- ... -->`），因为后者在 Obsidian 渲染视图被隐藏，开发者会漏填
176	-- 必须带简短说明：例如 `【人工填写：JWT 签名密钥，256+ bit 随机串】`，而不是空 `【人工填写】`
177	-- 每插入一处新标记，同步登记到所在文件顶部的「零、人工占位速查表」（若文件无零节，先建一个）
178	-- 项目专属标识（Java 根包名 / C# 命名空间 / Python 顶层模块等）只在 `docs/07-环境配置.md` 引入一次占位，其他文件复用已登记的占位，不再重复创建
179	-
180	-### 残余占位扫描（任一启动 B 类文档生成时强制执行）
181	-
182	-匹配以下任一字符串视为有未填占位，停下输出残留位置清单等人补完：
183	-
184	-- `【人工填写：` —— 首选特征字符串
185	-- `your_password` / `your-secret-key` —— 兜底通用裸占位
186	-- 形如 `N.x` / `N.N.x` 的版本号占位（未锁到具体小版本）
187	-
188	----
189	-
190	-## 🔄 开发流程（模块循环 + 功能循环）
191	-
192	-两层嵌套循环的详细步骤全部固化到 skills，CLAUDE.md 不再展开。入口调 `/erp-session-start`，自动分发：
193	-
194	-- 模块循环（外层，Layer 2） → `erp-module-start` → `erp-local-test-gate` → `erp-module-report` → `erp-mr-create` → 人工 Approve+Merge → `erp-confirmed-update`
195	-- 功能循环（内层，Layer 3，每个 REQ-XXX-NNN 走一遍） → `erp-feature-brainstorm` → `erp-feature-plan` → `erp-feature-tdd` → `erp-feature-verify` → `erp-feature-review`
196	-
197	-本地测试闸门: `scripts/test.sh` 是 push 与 merge 前的唯一硬闸门。调用由 `erp-local-test-gate` 派发到全新子会话执行（见设计原则：测试/验证隔离）；`.githooks/pre-push` 也会触发。`git push --no-verify` 被 hook `deny-no-verify.sh` 硬拦截。本项目不配置 GitLab CI/CD。
198	-
199	----
200	-
201	-## 📐 编码行为约束
202	-
203	-### 你必须做的 ✅
204	-
205	-1. 严格遵循 `docs/04-技术规范.md` 中的命名和编码规范
206	-2. 严格遵循 `docs/09-项目目录结构.md` 中的目录规范，文件放对位置
207	-3. 每个后端接口必须先在 `docs/05-API接口契约.md` 中定义，再编码实现
208	-4. 每个功能必须可追溯到 `docs/01-需求清单.md` 中的需求编号
209	-5. 代码注释必须包含对应的需求编号，如 `// REQ-001: 用户登录`
210	-6. 数据库操作默认只使用已有表结构；如需临时 DDL 调试，按软规则 S1 执行（留痕 + 模块结束前回撤到基线）
211	-7. 提交代码前确保无编译错误、无明显运行时错误
212	-8. 每个Controller方法必须有统一的响应格式包装
213	-9. 异常处理使用全局异常处理器，不在业务代码中catch后吞掉异常
214	-10. 分页查询统一使用 MyBatis-Plus 的 Page 对象
215	-
216	-### 你禁止做的 🚫
217	-
218	-1. 默认禁止修改 `confirmed: true` 模块的代码；确为实现当前模块所必需时，按软规则 S2 执行（留痕 + 模块报告单列说明）
219	-2. 禁止引入技术栈表以外的框架或中间件（如需要必须先报告）
220	-3. 禁止硬编码配置（数据库连接、端口号等必须放在配置文件中）
221	-4. 禁止在前端直接写SQL或直接操作数据库
222	-5. 禁止跳过模块开发（必须按顺序）
223	-6. 禁止删除或覆盖他人代码（如有冲突必须报告）
224	-7. 禁止使用 `SELECT *`，必须显式列出需要的字段
225	-8. 禁止在循环中执行数据库查询（N+1问题）
226	-9. 禁止前端存储敏感信息到 localStorage
227	-10. 禁止返回后端异常堆栈给前端
228	-
229	----
230	-
231	-## 🔄 统一响应格式
232	-
233	-所有后端接口必须返回以下格式：
234	-
235	-```json
236	-{
237	- "code": 200,
238	- "message": "操作成功",
239	- "data": {},
240	- "timestamp": 1700000000000
241	-}
242	-```
243	-
244	-错误响应：
245	-
246	-```json
247	-{
248	- "code": 40001,
249	- "message": "用户名或密码错误",
250	- "data": null,
251	- "timestamp": 1700000000000
252	-}
253	-```
254	-
255	-错误码规范：
256	-
257	-\| 错误码范围 \| 含义 \|
258	-\|-----------\|------\|
259	-\| 200 \| 成功 \|
260	-\| 400xx \| 客户端参数错误 \|
261	-\| 401xx \| 认证/授权错误 \|
262	-\| 403xx \| 权限不足 \|
263	-\| 404xx \| 资源不存在 \|
264	-\| 500xx \| 服务端内部错误 \|
265	-
266	----
267	-
268	-## 🗂️ Git 提交规范
269	-
270	-每次提交必须遵循以下格式：
271	-
272	-```
273	-<type>(<scope>): <subject>
274	-
275	-type: feat\|fix\|refactor\|docs\|style\|test\|chore
276	-scope: 模块名，如 user, inventory, order
277	-subject: 简短描述，中文可
278	-
279	-示例：
280	-feat(user): 实现用户登录接口 REQ-001
281	-fix(order): 修复订单金额计算精度问题
282	-refactor(common): 统一响应格式包装
283	-```
284	-
285	----
286	-
287	-## 🧪 自测要求
288	-
289	-- 所有测试与验证（`scripts/test.sh` / `mvn test` / `pnpm test` / schema 基线 diff 等）一律派发到全新子会话 via `Agent` 执行，主会话只接收结构化结论（命令 / 退出码 / 通过数 / 失败项 / 关键 stdout ≤30 行）。不在主会话直跑测试。
290	-- 由 `erp-feature-verify`（功能级）+ `erp-local-test-gate`（模块级）两道 skill 统一承接。前者每个 REQ 跑一次，后者模块闸门跑一次。
291	-- 声称"完成"前必须贴出子会话返回的 evidence（模板：`.claude/skills/erp-feature-verify/templates/feature-verify-evidence-template.md`）。
292	-
293	----
294	-
295	-## 🚩 静默执行红旗清单（中断机制）
296	-
297	-功能循环（每个功能 REQ-XXX 的 Brainstorm → Plan → TDD → Verify → AI 自审）默认静默跑不打扰人，但命中以下任何一条必须立刻停下、记录原因、等人决策，不得自行绕过：
298	-
299	-\| # \| 红旗 \| 例子 \|
300	-\| - \| --- \| --- \|
301	-\| 1 \| 需求与 schema 冲突 \| 某功能（REQ-XXX）提到的字段在 MySQL MCP 查到的现有表里不存在 \|
302	-\| 2 \| 需求本身歧义 \| spec 中某规则有两种合理解读，CC 无法判断 \|
303	-\| 3 \| 超技术栈边界 \| 需要引入 `CLAUDE.md` 技术栈表外的框架 / 中间件 \|
304	-\| 4 \| 测试反复失败 \| 同一测试同一功能内连续 5 次修复失败 \|
305	-\| 5 \| 要改密钥 / 账密 / 包名 \| `docs/07-环境配置.md` 里由人工标注必须填的字段 \|
306	-\| 6 \| 外部接口不可达 \| 第三方 API 无法连接、证书失效等环境问题 \|
307	-
308	-命中红旗时的固定动作：
309	-
310	-1. 在当前功能的 plan 文件里追加一节 `## 🚩 Blocker`，描述红旗编号、现象、初步判断
311	-2. 停止后续所有功能的静默执行
312	-3. 在主会话输出一句话摘要 + 指向 blocker 文件的路径，等人回复
313	-
314	-报告格式：
315	-
316	-```markdown
317	-## ⚠️ 需要人工决策
318	-
319	-红旗编号: [1–6 中的某一条]
320	-问题描述: [详细描述]
321	-影响范围: [影响哪些模块 / 功能]
322	-我的建议: [初步判断，可选]
323	-等待决策: [需要人工做什么决定]
324	-```
325	-
326	----
327	-
328	-## 🟡 软规则（允许继续，但有强制后续动作）
329	-
330	-以下情况不触发中断，CC 可自行继续推进，但必须在约定位置留痕，模块完成时统一审计。漏留痕 = 红旗。
331	-
332	-\| # \| 软规则 \| 允许动作 \| 强制后续 \|
333	-\| - \| ----- \| ------- \| ------- \|
334	-\| S1 \| 临时 schema 改动 \| 调试期间可执行 `CREATE / ALTER / DROP TABLE / INDEX / VIEW` \| ① 每次 DDL 立即追加到 `docs/superpowers/module-reports/<current>-schema-scratch.md`（含 SQL、时间戳、原因）② 模块本地 test.sh 闸门前必须回撤到基线（`mysqldiff` 或 schema dump 比对为空）③ 未回撤 → 升级为红旗，停下 \|
335	-\| S2 \| 跨模块改动（动到 `confirmed: true` 模块的代码） \| 允许修改，但范围受限：仅为当前模块实现所必需 \| ① 当次修改立即追加到 `docs/superpowers/module-reports/<current>-cross-module.md`（含文件路径、改动原因、对原模块功能/API 的影响评估）② 《模块完成报告》必须单列「跨模块改动」节完整贴入 ③ 漏留痕或未评估影响 → 升级为红旗 \|
336	-
337	----
338	-
339	-## ⚡ Skill & 模板入口索引
340	-
341	-CC 会话启动请直接调 `/erp-session-start` —— 顶层编排器会自动探测当前阶段（计划 / 模块循环 / 功能循环 / blocker）并分发到下一个 skill。不要读 `指南.md`。
342	-
343	-### Skills（22 个，详细动作见各 `SKILL.md` 正文）
344	-
345	-\| Layer \| Skill \|
346	-\|---\|---\|
347	-\| 0 入口 \| `erp-session-start` \|
348	-\| 1 计划阶段 \| `erp-tech-stack-lock` / `erp-skeleton-gen` / `erp-mysql-mcp-setup` / `erp-requirements-gen` / `erp-downstream-gen` / `erp-understanding-report` \|
349	-\| 2 模块循环（外） \| `erp-module-start` / `erp-local-test-gate` / `erp-module-report` / `erp-mr-create` / `erp-confirmed-update` \|
350	-\| 3 功能循环（内） \| `erp-feature-brainstorm` / `erp-feature-plan` / `erp-feature-tdd` / `erp-feature-verify` / `erp-feature-review` \|
351	-\| 4 横切守门 \| `erp-red-flag-check` / `erp-placeholder-scan` / `erp-schema-baseline-check` / `erp-schema-scratch-log`（软规则 S1）/ `erp-cross-module-log`（软规则 S2） \|
352	-
353	-### Hooks（5 个，`.claude/settings.json` + `.claude/hooks/*.sh`）
354	-
355	-- `deny-no-verify.sh` — 拒 `git push --no-verify`
356	-- `guard-confirmed-flip.sh` — 翻 `confirmed: false→true` 前校验 MR merged 证据
357	-- `log-ddl.sh` — DDL 自动留痕（S1）
358	-- `log-cross-module.sh` — 跨模块改动自动留痕（S2）
359	-- `session-start-dispatch.sh` — 会话启动提示运行 `/erp-session-start`
360	-
361	-### 模板（44 份，分散在各 skill 的 `.claude/skills/erp-/templates/`）
362	-
363	-每个生成文件都对应一个模板（设计原则 #5）。模板保持纯净（原则 #6），帮助文本由 skill 通过 `AskUserQuestion` 交互引导。模板按"谁用谁拥有"原则分散到各自的 skill 目录下，便于打包成 plugin。两份共享模板（`schema-scratch-log-template.md` / `cross-module-log-template.md`）在 `erp-module-start` 与 `erp-schema-scratch-log` / `erp-cross-module-log` 中各有一份副本。
364	-

_pl_staging/pl_commands/erp-session-start.md deleted

View file @55c7b70

1	----
2	-description: ERP 项目会话入口 — 自动探测当前阶段并分发到下一步 skill
3	----
4	-
5	-Invoke the `erp-session-start` skill via the Skill tool to detect the current ERP-project phase and dispatch to the next skill. Do not read `指南.md`. Follow CLAUDE.md.

_pl_staging/pl_hooks/deny-no-verify.sh deleted

View file @55c7b70

1	-#!/usr/bin/env bash
2	-# PreToolUse hook: block any `git push --no-verify` — the local test.sh gate is the only hard gate.
3	-
4	-set -euo pipefail
5	-
6	-input="$(cat)"
7	-tool_name="$(printf '%s' "$input" \| jq -r '.tool_name // empty')"
8	-[ "$tool_name" = "Bash" ] \|\| exit 0
9	-
10	-cmd="$(printf '%s' "$input" \| jq -r '.tool_input.command // empty')"
11	-[ -n "$cmd" ] \|\| exit 0
12	-
13	-if printf '%s' "$cmd" \| grep -qE '\bgit[[:space:]]+push\b.*--no-verify\b'; then
14	- echo "BLOCKED: --no-verify bypasses the local test.sh gate (唯一硬闸门). If test.sh is failing, fix the root cause; do not skip the gate. Use /erp-local-test-gate to run the gate properly." >&2
15	- exit 2
16	-fi
17	-
18	-exit 0

_pl_staging/pl_hooks/guard-confirmed-flip.sh deleted

View file @55c7b70

1	-#!/usr/bin/env bash
2	-# PreToolUse hook: on any Edit/Write to docs/08 that flips `confirmed: false` → `true`,
3	-# require recent `glab mr view ... merged` evidence in conversation transcript.
4	-
5	-set -euo pipefail
6	-
7	-input="$(cat)"
8	-tool_name="$(printf '%s' "$input" \| jq -r '.tool_name // empty')"
9	-case "$tool_name" in Edit\|Write) ;; *) exit 0 ;; esac
10	-
11	-file_path="$(printf '%s' "$input" \| jq -r '.tool_input.file_path // empty')"
12	-case "$file_path" in "/docs/08-模块任务管理.md") ;; ) exit 0 ;; esac
13	-
14	-# For Edit: check old_string/new_string; for Write: check content.
15	-old_str="$(printf '%s' "$input" \| jq -r '.tool_input.old_string // empty')"
16	-new_str="$(printf '%s' "$input" \| jq -r '.tool_input.new_string // empty')"
17	-content="$(printf '%s' "$input" \| jq -r '.tool_input.content // empty')"
18	-
19	-flipping=0
20	-if [ -n "$old_str" ] && [ -n "$new_str" ]; then
21	- if printf '%s' "$old_str" \| grep -q 'confirmed:[[:space:]]*false' && \
22	- printf '%s' "$new_str" \| grep -q 'confirmed:[[:space:]]*true'; then
23	- flipping=1
24	- fi
25	-fi
26	-if [ -n "$content" ] && [ "$flipping" = 0 ]; then
27	- # Full overwrite: compare against current file's `false` entries to detect a flip.
28	- if [ -f "$file_path" ]; then
29	- cur_false_count="$(grep -c 'confirmed:[[:space:]]*false' "$file_path" \|\| true)"
30	- new_false_count="$(printf '%s' "$content" \| grep -c 'confirmed:[[:space:]]*false' \|\| true)"
31	- [ "$new_false_count" -lt "$cur_false_count" ] && flipping=1
32	- fi
33	-fi
34	-
35	-[ "$flipping" = 1 ] \|\| exit 0
36	-
37	-transcript_path="$(printf '%s' "$input" \| jq -r '.transcript_path // empty')"
38	-evidence=0
39	-if [ -n "$transcript_path" ] && [ -f "$transcript_path" ]; then
40	- if grep -E '"state"[[:space:]]:[[:space:]]"merged"\|state:[[:space:]]*merged\|MERGED' "$transcript_path" >/dev/null 2>&1; then
41	- evidence=1
42	- fi
43	-fi
44	-
45	-if [ "$evidence" = 0 ]; then
46	- echo "BLOCKED: flipping confirmed:false → true requires prior evidence that the MR is merged. Run \`glab mr view <iid> -F json\` first (via erp-confirmed-update skill) and confirm state=merged. 若 MR 未合并即改 confirmed，等于跳过人工审核。" >&2
47	- exit 2
48	-fi
49	-
50	-exit 0

_pl_staging/pl_hooks/log-cross-module.sh deleted

View file @55c7b70

1	-#!/usr/bin/env bash
2	-# PostToolUse hook: detect Edit/Write to a file inside a confirmed:true module and stub-log to cross-module file.
3	-# Triggers soft rule S2.
4	-
5	-set -euo pipefail
6	-
7	-input="$(cat)"
8	-tool_name="$(printf '%s' "$input" \| jq -r '.tool_name // empty')"
9	-case "$tool_name" in Edit\|Write) ;; *) exit 0 ;; esac
10	-
11	-file_path="$(printf '%s' "$input" \| jq -r '.tool_input.file_path // empty')"
12	-[ -n "$file_path" ] \|\| exit 0
13	-
14	-project_dir="${CLAUDE_PROJECT_DIR:-$(pwd)}"
15	-docs08="$project_dir/docs/08-模块任务管理.md"
16	-[ -f "$docs08" ] \|\| exit 0
17	-
18	-# Skip changes to docs/08 itself (handled by guard-confirmed-flip).
19	-case "$file_path" in *"/docs/08-模块任务管理.md") exit 0 ;; esac
20	-
21	-# Determine current (first confirmed:false) module.
22	-current_module="$(awk '/confirmed:[[:space:]]false/ {print prev; exit} {prev=$0}' "$docs08" \| sed -nE 's/^[[:space:]]([A-Za-z0-9_-]+):.*/\1/p')"
23	-[ -n "$current_module" ] \|\| exit 0
24	-
25	-# Collect confirmed:true modules and their path scopes.
26	-# Expected YAML shape in docs/08 per module:
27	-# module_N:
28	-# name: ...
29	-# paths: [src/foo/, frontend/bar/]
30	-# confirmed: true
31	-confirmed_true_modules="$(awk '
32	- /^[[:space:]][A-Za-z0-9_-]+:[[:space:]]$/ { name=$1; sub(":","",name) }
33	- /confirmed:[[:space:]]*true/ { print name }
34	-' "$docs08")"
35	-
36	-[ -n "$confirmed_true_modules" ] \|\| exit 0
37	-
38	-hit_module=""
39	-for m in $confirmed_true_modules; do
40	- [ "$m" = "$current_module" ] && continue
41	- # Read paths list for this module (best-effort — match lines under this module before next module).
42	- scopes="$(awk -v mod="$m" '
43	- $0 ~ "^[[:space:]]"mod":[[:space:]]$" {in_mod=1; next}
44	- in_mod && /^[A-Za-z0-9_-]+:[[:space:]]*$/ {in_mod=0}
45	- in_mod && /paths:/ {gsub(/.paths:[[:space:]]\[/,""); gsub(/\].*/,""); gsub(/["'"'"' ]/,""); print; exit}
46	- ' "$docs08")"
47	- [ -n "$scopes" ] \|\| continue
48	- IFS=',' read -ra scope_arr <<< "$scopes"
49	- for s in "${scope_arr[@]}"; do
50	- [ -z "$s" ] && continue
51	- pattern="${s%/\\}"
52	- case "$file_path" in "$pattern") hit_module="$m"; break 2;; esac
53	- done
54	-done
55	-
56	-[ -n "$hit_module" ] \|\| exit 0
57	-
58	-log_dir="$project_dir/docs/superpowers/module-reports"
59	-mkdir -p "$log_dir"
60	-log_file="$log_dir/${current_module}-cross-module.md"
61	-if [ ! -f "$log_file" ]; then
62	- {
63	- echo "# 跨模块改动日志 — ${current_module}"
64	- echo ""
65	- echo "\| 时间戳 \| 目标模块 \| 文件 \| 改动摘要 \| 原因 \| 影响评估 \|"
66	- echo "\|---\|---\|---\|---\|---\|---\|"
67	- } > "$log_file"
68	-fi
69	-
70	-ts="$(date -u +%FT%TZ)"
71	-rel_path="${file_path#$project_dir/}"
72	-echo "\| ${ts} \| ${hit_module} \| ${rel_path} \| ${tool_name} \| TBD(待填) \| TBD(待填) \|" >> "$log_file"
73	-
74	-jq -n --arg m "$hit_module" --arg f "$log_file" --arg p "$rel_path" \
75	- '{hookSpecificOutput:{hookEventName:"PostToolUse",additionalContext:("Cross-module edit detected: \($p) belongs to confirmed:true module [\($m)]. Stub logged to \($f). Invoke erp-cross-module-log skill to fill 原因 and 影响评估. (软规则 S2)")}}'

_pl_staging/pl_hooks/log-ddl.sh deleted

View file @55c7b70

1	-#!/usr/bin/env bash
2	-# PostToolUse hook: detect DDL in MCP mysql_query and stub-log to current module's schema-scratch file.
3	-# Triggers soft rule S1 — DDL is allowed during debug, but must be rolled back by module gate.
4	-
5	-set -euo pipefail
6	-
7	-input="$(cat)"
8	-tool_name="$(printf '%s' "$input" \| jq -r '.tool_name // empty')"
9	-[ "$tool_name" = "mcp__mcp_server_mysql__mysql_query" ] \|\| exit 0
10	-
11	-sql="$(printf '%s' "$input" \| jq -r '.tool_input.sql // .tool_input.query // empty')"
12	-[ -n "$sql" ] \|\| exit 0
13	-
14	-if ! printf '%s' "$sql" \| grep -iqE '\b(CREATE\|ALTER\|DROP\|TRUNCATE)[[:space:]]+(TABLE\|INDEX\|VIEW\|DATABASE\|SCHEMA)\b'; then
15	- exit 0
16	-fi
17	-
18	-project_dir="${CLAUDE_PROJECT_DIR:-$(pwd)}"
19	-docs08="$project_dir/docs/08-模块任务管理.md"
20	-module_name="unknown-module"
21	-if [ -f "$docs08" ]; then
22	- module_name="$(awk '/confirmed:[[:space:]]false/ {print prev; exit} {prev=$0}' "$docs08" \| sed -nE 's/^[[:space:]]([A-Za-z0-9_-]+):.*/\1/p')"
23	- [ -n "$module_name" ] \|\| module_name="unknown-module"
24	-fi
25	-
26	-log_dir="$project_dir/docs/superpowers/module-reports"
27	-mkdir -p "$log_dir"
28	-log_file="$log_dir/${module_name}-schema-scratch.md"
29	-
30	-if [ ! -f "$log_file" ]; then
31	- {
32	- echo "# Schema 临时改动日志 — ${module_name}"
33	- echo ""
34	- echo "\| 时间戳 \| SQL \| 原因 \| 预计回撤时机 \|"
35	- echo "\|---\|---\|---\|---\|"
36	- } > "$log_file"
37	-fi
38	-
39	-ts="$(date -u +%FT%TZ)"
40	-sql_one_line="$(printf '%s' "$sql" \| tr '\n' ' ' \| sed 's/\|/\\\|/g' \| cut -c1-200)"
41	-echo "\| ${ts} \| \`${sql_one_line}\` \| TBD(待填) \| TBD(待填) \|" >> "$log_file"
42	-
43	-jq -n --arg msg "DDL detected on schema. Stub logged to ${log_file}. Invoke erp-schema-scratch-log skill to fill 原因 and 回撤时机. Remember: 软规则 S1 — schema must be rolled back to baseline before module gate, else 升级为红旗。" '{hookSpecificOutput:{hookEventName:"PostToolUse",additionalContext:$msg}}'

_pl_staging/pl_hooks/session-start-dispatch.sh deleted

View file @55c7b70

1	-#!/usr/bin/env bash
2	-# SessionStart hook: remind CC to run erp-session-start for phase detection & dispatch.
3	-
4	-cat <<'EOF'
5	-[ERP skills] Session started. Run /erp-session-start to auto-detect the current phase (Layer 1 planning / Layer 2 module loop / blocker) and dispatch to the next skill. See CLAUDE.md for the 6-flag + 2-soft-rule shortlist.
6	-EOF

_pl_staging/pl_settings.json deleted

View file @55c7b70

1	-{
2	- "hooks": {
3	- "PreToolUse": [
4	- {
5	- "matcher": "Bash",
6	- "hooks": [
7	- { "type": "command", "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/deny-no-verify.sh" }
8	- ]
9	- },
10	- {
11	- "matcher": "Edit\|Write",
12	- "hooks": [
13	- { "type": "command", "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/guard-confirmed-flip.sh" }
14	- ]
15	- }
16	- ],
17	- "PostToolUse": [
18	- {
19	- "matcher": "mcp__mcp_server_mysql__mysql_query",
20	- "hooks": [
21	- { "type": "command", "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/log-ddl.sh" }
22	- ]
23	- },
24	- {
25	- "matcher": "Edit\|Write",
26	- "hooks": [
27	- { "type": "command", "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/log-cross-module.sh" }
28	- ]
29	- }
30	- ],
31	- "SessionStart": [
32	- {
33	- "hooks": [
34	- { "type": "command", "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/session-start-dispatch.sh" }
35	- ]
36	- }
37	- ]
38	- }
39	-}

_pl_staging/pl_settings.local.json deleted

View file @55c7b70

1	-{
2	- "permissions": {
3	- "allow": [
4	- "mcp__mcp_server_mysql__mysql_query",
5	- "Bash(ls docs/)",
6	- "Bash(ls scripts/ .githooks/)",
7	- "Bash(ls .mcp.json docs/superpowers/schema-baseline.sql)",
8	- "Bash(ls docs/01-需求清单/)",
9	- "Bash(sed -i.bak -e 's\|@references/\|templates/\|g' __TRACKED_VAR__/SKILL.md)",
10	- "Bash(rm __TRACKED_VAR__/SKILL.md.bak)",
11	- "Bash(mkdir -p erp-workflow-plugin/.claude-plugin erp-workflow-plugin/hooks/scripts)",
12	- "Bash(cp -r .claude/skills erp-workflow-plugin/skills)",
13	- "Bash(cp -r .claude/commands erp-workflow-plugin/commands)",
14	- "Bash(cp .claude/hooks/*.sh erp-workflow-plugin/hooks/scripts/)",
15	- "Bash(cp CLAUDE.md erp-workflow-plugin/CLAUDE.md.template)",
16	- "Bash(sed -i.bak -e 's\|`\\\\.claude/skills/erp-understanding-report/templates/understanding-report-template\\\\.md`\|由 erp-understanding-report skill 持有，安装插件后 skill 自动读取\|g' -e 's\|`\\\\.claude/skills/erp-module-report/templates/module-report-template\\\\.md`\|由 erp-module-report skill 持有\|g' -e 's\|`\\\\.claude/skills/erp-feature-verify/templates/feature-verify-evidence-template\\\\.md`\|由 erp-feature-verify skill 持有\|g' -e 's\|`\\\\.claude/skills/erp-\\\\/templates/\\\\`\|插件 `skills/erp-/templates/`\|g' erp-workflow-plugin/CLAUDE.md.template)",
17	- "Bash(rm erp-workflow-plugin/CLAUDE.md.template.bak)"
18	- ],
19	- "deny": []
20	- }
21	-}

_pl_staging/pl_skills/erp-confirmed-update/SKILL.md deleted

View file @55c7b70

1	----
2	-name: erp-confirmed-update
3	-description: After the human merges the module's MR, verify merged state via glab mr view, flip docs/08 confirmed:false→true, commit the flip, and hand back to erp-session-start for the next module.
4	----
5	-
6	-# erp-confirmed-update
7	-
8	-## Pre-conditions
9	-
10	-- User said "MR 已合" OR auto-trigger from `erp-session-start` ladder step 8.
11	-- `docs/08` current module's MR IID known (from § ⑫ of module report).
12	-
13	-## Procedure
14	-
15	-1. Run `glab mr view <iid> -F json` (direct Bash; no subagent needed — it's a read).
16	-2. Parse JSON; verify `.state == "merged"` (and `.merge_status == "merged"` if present).
17	-3. On not-merged → print state, stop (do NOT flip).
18	-4. On merged:
19	- a. Edit `docs/08-模块任务管理.md`: for the current module, change `confirmed: false` → `confirmed: true`. Change exactly one line.
20	- - `guard-confirmed-flip.sh` hook will verify merged evidence is in the transcript — since we just ran `glab mr view` above, that check will see it.
21	- b. Stage `docs/08-模块任务管理.md`.
22	- c. Read `templates/confirmed-flip-commit-template.md`; fill `module_id`, `mr_iid`; commit with that message.
23	-5. Print `confirmed-update: <module_id> → true (MR !<iid>)`.
24	-6. Invoke `erp-session-start` to dispatch to the next module.
25	-
26	-## Invariants
27	-
28	-- Never flip `confirmed: true → false` in this skill (that's a red-flag-reopen flow, handled manually).
29	-- Never flip for a module other than the current (first `confirmed: false`).
30	-
31	-## References
32	-
33	-- `templates/confirmed-flip-commit-template.md`
34	-- `templates/docs-08-flip-diff-template.md`
35	-- Hook interlock: `guard-confirmed-flip.sh`

_pl_staging/pl_skills/erp-confirmed-update/templates/confirmed-flip-commit-template.md deleted

View file @55c7b70

-chore({{module_id}}): mark confirmed (MR !{{mr_iid}} merged)

_pl_staging/pl_skills/erp-confirmed-update/templates/docs-08-flip-diff-template.md deleted

View file @55c7b70

1	-Expected unified-diff shape for a legitimate confirmed flip:
2	-
3	-```
4	-@@
5	- {{module_id}}:
6	- name: ...
7	- ...
8	-- confirmed: false
9	-+ confirmed: true
10	-```
11	-
12	-Exactly one block changed from `false` to `true`. Any other shape is suspicious — `guard-confirmed-flip.sh` will block unless merged-state evidence is present.

_pl_staging/pl_skills/erp-cross-module-log/SKILL.md deleted

View file @55c7b70

1	----
2	-name: erp-cross-module-log
3	-description: Fill in 原因 and 影响评估 for cross-module edit stubs that the `log-cross-module.sh` hook auto-appended to `docs/superpowers/module-reports/<current>-cross-module.md`. Covers edits to files inside `confirmed: true` modules.
4	----
5	-
6	-# erp-cross-module-log
7	-
8	-## What
9	-
10	-Soft-rule S2 enforcement: every edit to a confirmed-merged module must be logged with reason + impact assessment.
11	-
12	-## Procedure
13	-
14	-1. Identify the current module (first `confirmed: false` in `docs/08-模块任务管理.md`).
15	-2. Open `docs/superpowers/module-reports/<current>-cross-module.md` (init from `templates/cross-module-log-template.md` if absent).
16	-3. Find rows with `TBD(待填)` in 原因 or 影响评估 columns.
17	-4. For each TBD row:
18	- - 原因: why was the target module's code modified? What requirement in the current module forced it?
19	- - 影响评估: which APIs / behaviors / callers in the target module may be affected? Are its existing tests still valid? Are new tests needed? (1-3 sentences)
20	-5. Edit the row; keep 时间戳 / 目标模块 / 文件 / 改动摘要 immutable.
21	-6. Print a one-line confirmation: `cross-module-log: N rows updated`.
22	-
23	-## Downstream
24	-
25	-The filled log is embedded verbatim into `module-report-template.md` § ⑦ by `erp-module-report`.
26	-
27	-## References
28	-
29	-- `templates/cross-module-log-template.md`
30	-- `templates/cross-module-log-row-template.md`
31	-- `CLAUDE.md` § 🟡 软规则 S2

_pl_staging/pl_skills/erp-cross-module-log/templates/cross-module-log-row-template.md deleted

View file @55c7b70

-| {{timestamp}} | {{target_module}} | {{file_path}} | {{change_summary}} | {{reason}} | {{impact}} |

_pl_staging/pl_skills/erp-cross-module-log/templates/cross-module-log-template.md deleted

View file @55c7b70

1	-# 跨模块改动日志 — {{module_name}}
2	-
3	-软规则 S2：本模块开发期间对其他 `confirmed: true` 模块代码的改动记录在此；模块完成报告必须单列「跨模块改动」节完整贴入。漏留痕或未评估影响 → 升级为红旗。
4	-
5	-\| 时间戳 \| 目标模块 \| 文件 \| 改动摘要 \| 原因 \| 影响评估 \|
6	-\|---\|---\|---\|---\|---\|---\|

_pl_staging/pl_skills/erp-downstream-gen/SKILL.md deleted

View file @55c7b70

1	----
2	-name: erp-downstream-gen
3	-description: Plan-phase step A5. Generate docs/02 + docs/05 + docs/06 五节 + docs/08 + docs/10 + sql/seed-data.sql in one pass, derived from docs/01 and docs/03.
4	----
5	-
6	-# erp-downstream-gen
7	-
8	-## Pre-conditions
9	-
10	-- `docs/01-需求清单/*.md` full REQ cards present.
11	-- `docs/03-数据库设计文档.md` present.
12	-- Human has reviewed 01 and 03 (ask user to confirm before proceeding).
13	-
14	-## Procedure
15	-
16	-### A. docs/02 — 开发计划
17	-1. Build module dependency DAG from:
18	- - FKs in docs/03 (table A → table B ⇒ A's module depends on B's module)
19	- - Explicit `depends_on` hints in docs/01 READMEs
20	-2. Topological sort → `order[]`.
21	-3. Read `templates/docs-02-template.md`; fill `modules[]`, `order[]`, `notes`.
22	-4. Write `docs/02-开发计划.md`.
23	-
24	-### B. docs/05 — API 接口契约
25	-1. Read `templates/docs-05-header-template.md`; write header to `docs/05-API接口契约.md`.
26	-2. For each REQ across all modules: read `templates/docs-05-endpoint-template.md`; infer method / path / auth / permission / request & response schemas (ask user for non-obvious ones); append to `docs/05`.
27	-
28	-### C. docs/06 — 页面清单
29	-1. For each module with frontend pages: read `templates/docs-06-module-pagelist-template.md`; fill `pages[]` (page_name, route, page_type, req_ids, menu_path, interactions).
30	-2. Append each rendered block to `docs/06-UI交互规范.md` § 五.
31	-
32	-### D. docs/08 — 模块任务管理
33	-1. Read `templates/docs-08-header-template.md`; write header to `docs/08-模块任务管理.md`.
34	-2. For each module in topological order: read `templates/docs-08-module-row-template.md`; fill `module_id`, `module_name`, `depends_on`, `req_ids`, `path_scopes` (from docs/09 + module code prefix), `confirmed: false`; append.
35	-
36	-### E. docs/10 — 验收清单
37	-1. Read `templates/docs-10-header-template.md`; write header to `docs/10-验收检查清单.md`.
38	-2. For each module: read `templates/docs-10-module-template.md`; fill `reqs[]`, `data_checks[]`, `ui_checks[]`; append.
39	-
40	-### F. sql/seed-data.sql
41	-1. Read `templates/seed-data-sql-template.sql`.
42	-2. For each module, ask user or infer minimal seed rows (enough for acceptance tests to pass). Fill `module_blocks[]`.
43	-3. Write `sql/seed-data.sql`.
44	-
45	-### G. Validate
46	-- Every REQ in docs/01 appears in docs/05 (as an endpoint if applicable), docs/08 (under its module), docs/10 (as an acceptance item).
47	-- Every module in docs/02 order has a row in docs/08 with `confirmed: false`.
48	-- Run `erp-placeholder-scan` over the 5 files — log residuals.
49	-
50	-Print: `downstream-gen: wrote 5 files + seed. Awaiting human review.`
51	-
52	-## References
53	-
54	-- `templates/docs-02-template.md`
55	-- `templates/docs-05-header-template.md`
56	-- `templates/docs-05-endpoint-template.md`
57	-- `templates/docs-06-module-pagelist-template.md`
58	-- `templates/docs-08-header-template.md`
59	-- `templates/docs-08-module-row-template.md`
60	-- `templates/docs-10-header-template.md`
61	-- `templates/docs-10-module-template.md`
62	-- `templates/seed-data-sql-template.sql`

_pl_staging/pl_skills/erp-downstream-gen/templates/docs-02-template.md deleted

View file @55c7b70

1	-# 02-开发计划
2	-
3	-模块按技术依赖排序，非业务优先级。
4	-
5	-## 模块依赖表
6	-
7	-\| 模块 ID \| 模块名 \| 依赖模块 \| 依赖表 \| 估算天数 \|
8	-\|---\|---\|---\|---\|---\|
9	-{{#each modules}}
10	-\| {{id}} \| {{name}} \| {{deps}} \| {{tables}} \| {{days}} \|
11	-{{/each}}
12	-
13	-## 开发顺序（拓扑序）
14	-{{#each order}}
15	-{{index}}. {{module_id}} — {{module_name}}
16	-{{/each}}
17	-
18	-## 关键说明
19	-{{notes}}

_pl_staging/pl_skills/erp-downstream-gen/templates/docs-05-endpoint-template.md deleted

View file @55c7b70

1	-### {{req_id}} {{title}}
2	-
3	-- Method: {{method}}
4	-- Path: `{{path}}`
5	-- Auth: {{auth}}
6	-- Permission: {{permission}}
7	-
8	-#### 请求参数
9	-{{request_params}}
10	-
11	-#### 请求体
12	-```json
13	-{{request_body_schema}}
14	-```
15	-
16	-#### 响应体
17	-```json
18	-{{response_body_schema}}
19	-```
20	-
21	-#### 错误码
22	-{{#each errors}}
23	-- `{{code}}` — {{message}}
24	-{{/each}}

_pl_staging/pl_skills/erp-downstream-gen/templates/docs-05-header-template.md deleted

View file @55c7b70

1	-# 05-API接口契约
2	-
3	-BasePath: `{{base_path}}`
4	-端口: `【人工填写：后端端口，默认 8080】`
5	-
6	-## 全局约定
7	-
8	-### 响应格式
9	-```json
10	-{"code": 200, "message": "操作成功", "data": {}, "timestamp": 1700000000000}
11	-```
12	-
13	-### 错误码
14	-\| 范围 \| 含义 \|
15	-\|---\|---\|
16	-\| 200 \| 成功 \|
17	-\| 400xx \| 客户端参数错误 \|
18	-\| 401xx \| 认证/授权错误 \|
19	-\| 403xx \| 权限不足 \|
20	-\| 404xx \| 资源不存在 \|
21	-\| 500xx \| 服务端内部错误 \|
22	-
23	-### 鉴权
24	-{{auth_note}}
25	-
26	-### 分页参数
27	-{{pagination_note}}
28	-
29	-## 接口清单
30	-（各模块接口段落见下方，由 `erp-downstream-gen` 按 REQ 填入）

_pl_staging/pl_skills/erp-downstream-gen/templates/docs-06-module-pagelist-template.md deleted

View file @55c7b70

1	-### {{module_id}} {{module_name}}
2	-
3	-{{#each pages}}
4	-- {{page_name}} (`{{route}}`)
5	- - 类型: {{page_type}} （列表页 / 表单页 / 详情页 / 树形管理页）
6	- - 对应 REQ: {{req_ids}}
7	- - 入口菜单: {{menu_path}}
8	- - 主要交互: {{interactions}}
9	-{{/each}}

_pl_staging/pl_skills/erp-downstream-gen/templates/docs-08-header-template.md deleted

View file @55c7b70

1	-# 08-模块任务管理
2	-
3	-`confirmed` 语义（权威定义在 `CLAUDE.md`）：
4	-- `false` → 模块待完成或被重开，CC 在此模块工作
5	-- `true` → 已 MR Approve + Merge，CC 进入下一 `false` 模块
6	-
7	-CC 修改 `false → true` 需 MR 已 merged 证据（hook `guard-confirmed-flip.sh` 强制）。
8	-
9	-## 模块列表

_pl_staging/pl_skills/erp-downstream-gen/templates/docs-08-module-row-template.md deleted

View file @55c7b70

1	-{{module_id}}:
2	- name: {{module_name}}
3	- depends_on: {{depends_on}}
4	- reqs: {{req_ids}}
5	- paths: [{{path_scopes}}]
6	- confirmed: false

_pl_staging/pl_skills/erp-downstream-gen/templates/docs-10-header-template.md deleted

View file @55c7b70

1	-# 10-验收检查清单
2	-
3	-通用验收项（全项目适用）:
4	-
5	-- [ ] `scripts/test.sh` 本地全绿
6	-- [ ] schema 与 `docs/superpowers/schema-baseline.sql` 一致（无未回撤 DDL）
7	-- [ ] 所有新接口在 `docs/05` 中有契约定义
8	-- [ ] 所有新功能代码注释含 REQ-XXX-NNN
9	-- [ ] 统一响应格式 `{code, message, data, timestamp}`
10	-- [ ] 异常走全局处理器，不暴露堆栈到前端
11	-- [ ] 前端不存敏感信息到 localStorage
12	-
13	-## 模块专项
14	-（各模块验收段落见下方，由 `erp-downstream-gen` 按模块填入）

_pl_staging/pl_skills/erp-downstream-gen/templates/docs-10-module-template.md deleted

View file @55c7b70

1	-### {{module_id}} {{module_name}}
2	-
3	-#### 功能级验收（每个 REQ 对应可执行用例）
4	-{{#each reqs}}
5	-- [ ] {{req_id}} {{title}}
6	- - 自动化用例: `{{test_file}}::{{test_name}}`
7	- - 手动验收: {{manual_check}}
8	-{{/each}}
9	-
10	-#### 数据级验收
11	-{{#each data_checks}}
12	-- [ ] {{check}}
13	-{{/each}}
14	-
15	-#### UI 级验收（若含前端）
16	-{{#each ui_checks}}
17	-- [ ] {{check}}
18	-{{/each}}

_pl_staging/pl_skills/erp-downstream-gen/templates/seed-data-sql-template.sql deleted

View file @55c7b70

1	--- seed-data.sql — 本地测试数据
2	--- Reloaded on every scripts/setup-test-db.sh run.
3	--- Never mutate schema here; data only.
4	-
5	-SET FOREIGN_KEY_CHECKS = 0;
6	-
7	-{{#each module_blocks}}
8	--- ==========================================================
9	--- {{module_id}} {{module_name}}
10	--- ==========================================================
11	-{{sql_block}}
12	-
13	-{{/each}}
14	-
15	-SET FOREIGN_KEY_CHECKS = 1;

_pl_staging/pl_skills/erp-feature-brainstorm/SKILL.md deleted

View file @55c7b70

1	----
2	-name: erp-feature-brainstorm
3	-description: Feature-loop step 1. Thin wrapper over superpowers:brainstorming for a single REQ-XXX-NNN. Produces a spec file at docs/superpowers/specs/YYYY-MM-DD-<REQ>.md using the feature-spec-template, after interactive brainstorming with the user.
4	----
5	-
6	-# erp-feature-brainstorm
7	-
8	-## What
9	-
10	-Produce a ≤1-page spec for one REQ-XXX-NNN by delegating to `superpowers:brainstorming`, then pack the output into the standard spec template.
11	-
12	-## Procedure
13	-
14	-1. Red-flag gate: invoke `erp-red-flag-check`. If it halts → stop.
15	-2. Resolve inputs:
16	- - Current REQ-XXX-NNN (from conversation, or the next unfulfilled REQ in `docs/08` current module).
17	- - REQ card: `docs/01-需求清单/<module>.md` § REQ-XXX-NNN.
18	- - Relevant schema tables (from `docs/03` or live MCP query).
19	-3. Delegate to `superpowers:brainstorming` with the REQ card + schema refs as context.
20	-4. Derive path: `docs/superpowers/specs/$(date +%F)-<REQ-id>.md`. If already exists, overwrite with user confirmation.
21	-5. Read `templates/feature-spec-template.md`; fill slots from brainstorm output:
22	- - `goal`, `input`, `output`, `rules`, `constraints`, `schema_refs`, `api_refs`, `acceptance`
23	-6. Write the filled spec to the derived path.
24	-7. Validate: every top-level section in the template must be non-empty. If any slot is TBD, loop back to brainstorming for that slot.
25	-8. Print `feature-brainstorm: <REQ> → <path>` to session.
26	-
27	-## References
28	-
29	-- `templates/feature-spec-template.md`
30	-- Delegates: `superpowers:brainstorming`
31	-- Guard: `erp-red-flag-check`

_pl_staging/pl_skills/erp-feature-brainstorm/templates/feature-spec-template.md deleted

View file @55c7b70

1	----
2	-req_id: {{req_id}}
3	-date: {{date}}
4	-module: {{module}}
5	----
6	-
7	-# Spec: {{req_id}} — {{title}}
8	-
9	-## 目标
10	-{{goal}}
11	-
12	-## 输入 / 触发
13	-{{input}}
14	-
15	-## 输出 / 结果
16	-{{output}}
17	-
18	-## 业务规则
19	-{{rules}}
20	-
21	-## 边界与约束
22	-{{constraints}}
23	-
24	-## 依赖的 schema 表 / 字段
25	-{{schema_refs}}
26	-
27	-## 依赖的接口
28	-{{api_refs}}
29	-
30	-## 验收标准
31	-{{acceptance}}

_pl_staging/pl_skills/erp-feature-plan/SKILL.md deleted

View file @55c7b70

1	----
2	-name: erp-feature-plan
3	-description: Feature-loop step 2. Thin wrapper over superpowers:writing-plans. Turns a spec into a task-level plan (2–5 min per task, with file paths and full code) at docs/superpowers/plans/YYYY-MM-DD-<REQ>.md.
4	----
5	-
6	-# erp-feature-plan
7	-
8	-## Procedure
9	-
10	-1. Red-flag gate: `erp-red-flag-check`.
11	-2. Resolve inputs:
12	- - Current REQ-XXX-NNN and the spec at `docs/superpowers/specs/YYYY-MM-DD-<REQ>.md` (fail if spec missing).
13	- - Relevant code pointers (existing files to touch, discoverable via Grep).
14	- - `docs/04-技术规范.md` and `docs/09-项目目录结构.md` (编码规范 + 目录规范).
15	-3. Delegate to `superpowers:writing-plans` with spec + code pointers + conventions.
16	-4. Derive path: `docs/superpowers/plans/$(date +%F)-<REQ-id>.md`.
17	-5. Read `templates/feature-plan-template.md`; fill `files[]`, `tasks[]`, `commits[]`.
18	-6. Enforce: each task must be 2–5 min, have a failing test identifier, an impl path, and a done_when criterion.
19	-7. Write the plan.
20	-8. Print `feature-plan: <REQ> → <path>` to session.
21	-
22	-## References
23	-
24	-- `templates/feature-plan-template.md`
25	-- Delegates: `superpowers:writing-plans`
26	-- Guard: `erp-red-flag-check`

_pl_staging/pl_skills/erp-feature-plan/templates/feature-plan-template.md deleted

View file @55c7b70

1	----
2	-req_id: {{req_id}}
3	-date: {{date}}
4	-spec_ref: docs/superpowers/specs/{{date}}-{{req_id}}.md
5	----
6	-
7	-# Plan: {{req_id}}
8	-
9	-## 文件变更清单
10	-{{#each files}}
11	-- `{{path}}` — {{action}}（{{rationale}}）
12	-{{/each}}
13	-
14	-## 任务步骤（每步 2–5 分钟）
15	-{{#each tasks}}
16	-### Task {{index}}: {{title}}
17	-- 失败测试: `{{test_file}}::{{test_name}}` — {{test_intent}}
18	-- 实现路径: `{{impl_file}}`
19	-- 完成判据: {{done_when}}
20	-{{/each}}
21	-
22	-## 提交计划
23	-{{#each commits}}
24	-- `{{message}}`（覆盖 Task {{task_index}}）
25	-{{/each}}

_pl_staging/pl_skills/erp-feature-review/SKILL.md deleted

View file @55c7b70

1	----
2	-name: erp-feature-review
3	-description: Feature-loop step 5. Thin wrapper over superpowers:code-reviewer. Writes review report at docs/superpowers/reviews/YYYY-MM-DD-<REQ>.md. Self-fix loop capped at 3 rounds.
4	----
5	-
6	-# erp-feature-review
7	-
8	-## Procedure
9	-
10	-1. Delegate to `superpowers:code-reviewer` with the REQ's diff (`git diff <feature-start>..HEAD`) and the spec.
11	-2. Derive path: `docs/superpowers/reviews/$(date +%F)-<REQ-id>.md`.
12	-3. Read `templates/feature-review-template.md`; fill `round`, `verdict`, `must_fix[]`, `nice_to_have[]`, `gaps`.
13	-4. Write the report.
14	-5. Dispatch logic:
15	- - `verdict = approve` → print `feature-review: <REQ> APPROVED` and exit.
16	- - `verdict = request-changes` → fix Must-fix items, re-run `erp-feature-verify`, then re-review as round N+1.
17	-6. Cap: 3 rounds. If still `request-changes` after round 3 → stop and print a summary; escalate to user. (Red flag #9 was removed from the strict halt list — use judgement, but don't loop forever.)
18	-
19	-## References
20	-
21	-- `templates/feature-review-template.md`
22	-- Delegates: `superpowers:code-reviewer`

_pl_staging/pl_skills/erp-feature-review/templates/feature-review-template.md deleted

View file @55c7b70

1	----
2	-req_id: {{req_id}}
3	-date: {{date}}
4	-round: {{round}}
5	-reviewer: superpowers:code-reviewer
6	----
7	-
8	-# Review: {{req_id}} — round {{round}}
9	-
10	-## 结论
11	-{{verdict}} （approve / request-changes）
12	-
13	-## Must-fix
14	-{{#each must_fix}}
15	-- [{{severity}}] {{file}}:{{line}} — {{issue}}（建议：{{suggestion}}）
16	-{{/each}}
17	-
18	-## Nice-to-have
19	-{{#each nice_to_have}}
20	-- {{file}}:{{line}} — {{suggestion}}
21	-{{/each}}
22	-
23	-## 反例 / 测试覆盖缺口
24	-{{gaps}}

_pl_staging/pl_skills/erp-feature-tdd/SKILL.md deleted

View file @55c7b70

1	----
2	-name: erp-feature-tdd
3	-description: Feature-loop step 3. Thin wrapper over superpowers:test-driven-development. Executes tasks from the plan one by one, each commit follows the commit-message-template. CRITICAL: every red→green test run is dispatched to a fresh subagent per design principle #7.
4	----
5	-
6	-# erp-feature-tdd
7	-
8	-## Procedure
9	-
10	-1. Red-flag gate: `erp-red-flag-check`.
11	-2. Load the plan at `docs/superpowers/plans/YYYY-MM-DD-<REQ>.md`.
12	-3. For each task in order:
13	- a. Write the failing test(s) at `test_file::test_name`.
14	- b. Dispatch a fresh subagent via `Agent` (general-purpose) to run the test and confirm it fails; the subagent returns `{command, exit_code, failing_assertion}` only. Main session does NOT run the test directly.
15	- c. Implement the minimum code at `impl_file` to satisfy the test.
16	- d. Dispatch another fresh subagent to run the test and confirm it passes.
17	- e. On persistent failure (>5 attempts on the same test) → invoke `erp-red-flag-check` with flag #4.
18	- f. Stage changes and commit using `templates/commit-message-template.md`; `scope` matches the task's module, `subject` short (≤50 chars), `req_id` mandatory.
19	-4. After all tasks done → hand off to `erp-feature-verify`.
20	-
21	-## Guardrails
22	-
23	-- Never run `mvn test` / `pnpm test` / `scripts/test.sh` directly in the main session. Always via subagent.
24	-- Every commit must include the REQ-XXX-NNN tag.
25	-- Never batch unrelated changes into one commit.
26	-
27	-## References
28	-
29	-- `templates/commit-message-template.md`
30	-- Delegates: `superpowers:test-driven-development`
31	-- Guard: `erp-red-flag-check`

_pl_staging/pl_skills/erp-feature-tdd/templates/commit-message-template.md deleted

View file @55c7b70

-{{type}}({{scope}}): {{subject}} {{req_id}}

_pl_staging/pl_skills/erp-feature-verify/SKILL.md deleted

View file @55c7b70

1	----
2	-name: erp-feature-verify
3	-description: Feature-loop step 4. Thin wrapper over superpowers:verification-before-completion. Dispatches the REQ's test suite to a fresh subagent and renders the result through feature-verify-evidence-template. No "done" claim is allowed without this evidence.
4	----
5	-
6	-# erp-feature-verify
7	-
8	-## Procedure
9	-
10	-1. Determine the feature's test target (Maven profile / pnpm script / pytest path) from the plan or the project's standard commands.
11	-2. Dispatch a fresh subagent via `Agent` (general-purpose) with a prompt like:
12	-
13	- ```
14	- Task: run the feature's test target and report back. Do NOT modify code. Steps:
15	- 1. Run: <command> (e.g., mvn -pl user-module test -Dtest=REQ* )
16	- 2. Report ONLY structured JSON: {"command":"<cmd>","exit_code":<int>,"passed":<int>,"failed":<int>,"failed_list":["<test>", ...],"stdout_excerpt":"<last 30 lines or most-relevant failure excerpt>"}
17	- No prose.
18	- ```
19	-
20	-3. Parse the JSON; read `templates/feature-verify-evidence-template.md`; fill slots including `subagent_id` and `conclusion`.
21	-4. If `exit_code != 0` or `failed > 0` → print the filled evidence to session and stop. Do not proceed to review.
22	-5. On pass → print the evidence; hand off to `erp-feature-review`.
23	-
24	-## Guardrails
25	-
26	-- Never paste raw test stdout into main session beyond the 30-line `stdout_excerpt`.
27	-- Evidence must be rendered from the template, never freely written.
28	-
29	-## References
30	-
31	-- `templates/feature-verify-evidence-template.md`
32	-- Delegates: `superpowers:verification-before-completion`

_pl_staging/pl_skills/erp-feature-verify/templates/feature-verify-evidence-template.md deleted

View file @55c7b70

1	-## Verify evidence — {{req_id}}
2	-
3	-- 命令: `{{command}}`
4	-- 子会话: {{subagent_id}}
5	-- 退出码: {{exit_code}}
6	-- 通过用例数: {{passed}}
7	-- 失败用例数: {{failed}}
8	-- 失败列表: {{failed_list}}
9	-
10	-关键 stdout 片段 (≤30 行):
11	-
12	-```
13	-{{stdout_excerpt}}
14	-```
15	-
16	-结论: {{conclusion}} （pass / fail）

_pl_staging/pl_skills/erp-local-test-gate/SKILL.md deleted

View file @55c7b70

1	----
2	-name: erp-local-test-gate
3	-description: The only hard gate before MR creation. Runs schema-baseline-check + placeholder-scan + scripts/test.sh. scripts/test.sh is dispatched to a fresh subagent (design principle #7). Non-zero on any check = stop.
4	----
5	-
6	-# erp-local-test-gate
7	-
8	-## Procedure
9	-
10	-1. Invoke `erp-schema-baseline-check`.
11	- - Dirty → flag #1 raised by the skill, stop.
12	-2. Invoke `erp-placeholder-scan` over `docs/*`, `.env`, `scripts/**`, `CLAUDE.md`.
13	- - Non-empty hits → stop.
14	-3. Dispatch a fresh subagent (general-purpose) to run `./scripts/test.sh`:
15	-
16	- ```
17	- Task: run the project's local test gate. Do NOT modify any code or data. Steps:
18	- 1. cd to the repo root.
19	- 2. Run: ./scripts/test.sh
20	- 3. Report ONLY JSON: {"command":"./scripts/test.sh","exit_code":<int>,"passed":<int>,"failed":<int>,"stdout_excerpt":"<last 30 lines; include any FAIL summary>"}
21	- No prose.
22	- ```
23	-
24	-4. Read `templates/test-gate-result-template.md`; fill ① ② ③ slots with the three check results.
25	-5. Write the rendered result to `docs/superpowers/module-reports/<module_id>-test-gate.md`.
26	-6. If `exit_code = 0` and both prior checks green → hand off to `erp-module-report` (print `local-test-gate: GREEN`).
27	-7. Otherwise print `local-test-gate: RED (<reason>)` and stop.
28	-
29	-## Guardrails
30	-
31	-- Never invoke `./scripts/test.sh` directly from the main session.
32	-- Never bypass via `git push --no-verify` (hook `deny-no-verify.sh` enforces).
33	-
34	-## References
35	-
36	-- `templates/test-gate-result-template.md`
37	-- Upstream guards: `erp-schema-baseline-check`, `erp-placeholder-scan`

_pl_staging/pl_skills/erp-local-test-gate/templates/test-gate-result-template.md deleted

View file @55c7b70

1	-## Local test gate — {{module_id}}
2	-
3	-执行时间: {{timestamp}}
4	-
5	-### ① Schema 基线比对
6	-{{schema_baseline_result}}
7	-
8	-### ② 占位扫描
9	-{{placeholder_scan_result}}
10	-
11	-### ③ scripts/test.sh (subagent)
12	-- 子会话: {{subagent_id}}
13	-- 命令: {{command}}
14	-- 退出码: {{exit_code}}
15	-- 通过: {{passed}} / 失败: {{failed}}
16	-- 关键 stdout (≤30 行):
17	-
18	-```
19	-{{stdout_excerpt}}
20	-```
21	-
22	-结论: {{conclusion}} （green / red）

_pl_staging/pl_skills/erp-module-report/SKILL.md deleted

View file @55c7b70

1	----
2	-name: erp-module-report
3	-description: After the local test gate is green, produce the standardized 12-section module completion report at docs/superpowers/module-reports/YYYY-MM-DD-<module_id>.md. Embeds schema-scratch and cross-module logs verbatim.
4	----
5	-
6	-# erp-module-report
7	-
8	-## Procedure
9	-
10	-1. Verify upstream: `erp-local-test-gate` returned GREEN. Otherwise stop.
11	-2. Collect inputs (by globs + git):
12	- - `git diff <module-start-commit>..HEAD` → file changes (§ ③)
13	- - `docs/superpowers/specs\|plans\|reviews/<date>-<module's REQs>.md` → § ②, § ⑨
14	- - `docs/superpowers/module-reports/<module_id>-schema-scratch.md` → § ⑥
15	- - `docs/superpowers/module-reports/<module_id>-cross-module.md` → § ⑦
16	- - `docs/superpowers/module-reports/<module_id>-test-gate.md` → § ⑤
17	- - `docs/03` + actual code (grep) → § ④ (tables read/written)
18	-3. Read `templates/module-report-template.md`; fill all 12 sections.
19	-4. Validation (hard):
20	- - § ⑥: if schema-scratch has any row with TBD → stop, ask user (via erp-schema-scratch-log) to fill.
21	- - § ⑦: if cross-module has any row with TBD → stop (erp-cross-module-log).
22	- - § ⑦: if non-empty but no 影响评估 per row → stop.
23	- - § ⑧ must enumerate every deviation from spec; if empty, explicitly write "无偏离".
24	-5. Write `docs/superpowers/module-reports/$(date +%F)-<module_id>.md`.
25	-6. Hand off to `erp-mr-create`.
26	-
27	-## References
28	-
29	-- `templates/module-report-template.md` (12 sections)
30	-- Upstream: `erp-local-test-gate`
31	-- Downstream: `erp-mr-create`

_pl_staging/pl_skills/erp-module-report/templates/module-report-template.md deleted

View file @55c7b70

1	----
2	-module_id: {{module_id}}
3	-date: {{date}}
4	-git_range: {{git_range}}
5	----
6	-
7	-# 模块完成报告 — {{module_id}} {{module_name}}
8	-
9	-## ① 模块信息
10	-- 模块 ID: {{module_id}}
11	-- 模块名: {{module_name}}
12	-- 开发区间: {{git_range}}
13	-- 开发天数: {{duration_days}}
14	-
15	-## ② REQ 完成清单
16	-{{#each reqs}}
17	-- [{{status}}] {{req_id}} — {{title}}
18	- - spec: docs/superpowers/specs/{{date}}-{{req_id}}.md
19	- - plan: docs/superpowers/plans/{{date}}-{{req_id}}.md
20	- - review: docs/superpowers/reviews/{{date}}-{{req_id}}.md
21	-{{/each}}
22	-
23	-## ③ 文件变更表
24	-\| 文件 \| 操作 \| 说明 \|
25	-\|---\|---\|---\|
26	-{{#each file_changes}}
27	-\| {{path}} \| {{action}} \| {{note}} \|
28	-{{/each}}
29	-
30	-## ④ 数据库使用表
31	-- 读: {{tables_read}}
32	-- 写: {{tables_written}}
33	-
34	-## ⑤ 测试结果
35	-- `scripts/test.sh` 最终：{{test_conclusion}}
36	-- 通过: {{passed}} / 失败: {{failed}} / 跳过: {{skipped}}
37	-- 覆盖率: {{coverage}}
38	-
39	-## ⑥ Schema 临时改动清单（软规则 S1）
40	-
41	-{{schema_scratch_contents}}
42	-
43	-回撤验证: {{rollback_verified}} （见 erp-schema-baseline-check 结果）
44	-
45	-## ⑦ 跨模块改动清单（软规则 S2）
46	-
47	-{{cross_module_contents}}
48	-
49	-## ⑧ 偏离 spec 清单
50	-{{#each deviations}}
51	-- {{req_id}}: {{deviation}} （原因: {{reason}}）
52	-{{/each}}
53	-
54	-## ⑨ AI reviewer 报告汇总
55	-{{#each reviews}}
56	-- {{req_id}}: round {{round}} — {{verdict}}（link: docs/superpowers/reviews/{{date}}-{{req_id}}.md）
57	-{{/each}}
58	-
59	-## ⑩ 已知问题
60	-{{known_issues}}
61	-
62	-## ⑪ 下一模块预览
63	-{{next_module}}
64	-
65	-## ⑫ MR 链接
66	-{{mr_url}}

_pl_staging/pl_skills/erp-module-start/SKILL.md deleted

View file @55c7b70

1	----
2	-name: erp-module-start
3	-description: Start the module loop. Locate the first `confirmed: false` module in docs/08, initialize schema-scratch & cross-module log files, print a module banner, and drive the feature loop over each REQ in order.
4	----
5	-
6	-# erp-module-start
7	-
8	-## Procedure
9	-
10	-1. Read `docs/08-模块任务管理.md`. Locate the first `confirmed: false` module; extract `module_id`, `module_name`, REQ list, dependencies.
11	-2. If no such module → all modules done; print a completion summary and stop.
12	-3. Initialize logs (idempotent):
13	- - `docs/superpowers/module-reports/<module_id>-schema-scratch.md` — if missing, write from `templates/schema-scratch-log-template.md` with `module_name` slot.
14	- - `docs/superpowers/module-reports/<module_id>-cross-module.md` — if missing, write from `templates/cross-module-log-template.md`.
15	-4. Read `templates/module-start-banner-template.md`; fill slots and print to session.
16	-5. For each REQ in order:
17	- a. `erp-red-flag-check` → stop if hit.
18	- b. `erp-feature-brainstorm`
19	- c. `erp-feature-plan`
20	- d. `erp-feature-tdd`
21	- e. `erp-feature-verify`
22	- f. `erp-feature-review`
23	- g. Any halt → stop the module; do not skip to the next REQ silently.
24	-6. After all REQs done → invoke `erp-local-test-gate`.
25	-
26	-## References
27	-
28	-- `templates/module-start-banner-template.md`
29	-- `templates/schema-scratch-log-template.md`
30	-- `templates/cross-module-log-template.md`
31	-- Downstream: `erp-feature-*`, `erp-local-test-gate`

_pl_staging/pl_skills/erp-module-start/templates/cross-module-log-template.md deleted

View file @55c7b70

1	-# 跨模块改动日志 — {{module_name}}
2	-
3	-软规则 S2：本模块开发期间对其他 `confirmed: true` 模块代码的改动记录在此；模块完成报告必须单列「跨模块改动」节完整贴入。漏留痕或未评估影响 → 升级为红旗。
4	-
5	-\| 时间戳 \| 目标模块 \| 文件 \| 改动摘要 \| 原因 \| 影响评估 \|
6	-\|---\|---\|---\|---\|---\|---\|

_pl_staging/pl_skills/erp-module-start/templates/module-start-banner-template.md deleted

View file @55c7b70

1	-## Module start — {{module_id}} ({{module_name}})
2	-
3	-- 模块依赖: {{depends_on}}
4	-- 对应需求文件: docs/01-需求清单/{{req_file}}
5	-- 功能清单:
6	-{{#each reqs}}
7	- - [ ] {{req_id}} — {{title}}
8	-{{/each}}
9	-
10	-开始功能循环（Layer 3）依次跑每个 REQ。命中红旗 → 停；完成所有 REQ → 进入模块闸门。

_pl_staging/pl_skills/erp-module-start/templates/schema-scratch-log-template.md deleted

View file @55c7b70

1	-# Schema 临时改动日志 — {{module_name}}
2	-
3	-软规则 S1：本模块开发期间对 schema 的所有临时 DDL 都应记录在此；模块闸门前必须全部回撤到基线（`docs/superpowers/schema-baseline.sql`）。未回撤 → 升级为红旗。
4	-
5	-\| 时间戳 \| SQL \| 原因 \| 预计回撤时机 \|
6	-\|---\|---\|---\|---\|

_pl_staging/pl_skills/erp-mr-create/SKILL.md deleted

View file @55c7b70

1	----
2	-name: erp-mr-create
3	-description: After the module completion report is written, git push and create a GitLab MR with the module report embedded in the description. The only action that touches the remote. Stops to wait for human review.
4	----
5	-
6	-# erp-mr-create
7	-
8	-## Pre-conditions
9	-
10	-- `erp-module-report` produced the report file.
11	-- `erp-local-test-gate` returned GREEN (re-check just before push; fail if file mtime older than latest commit).
12	-
13	-## Procedure
14	-
15	-1. Ensure current branch is a feature branch (not main/master). If needed: `git checkout -b module-<id>`.
16	-2. `git push -u origin <branch>` — do NOT use `--no-verify` (hook `deny-no-verify.sh` would block anyway).
17	-3. Read `templates/mr-title-template.md`; fill `module_id`, `module_name`.
18	-4. Read `templates/mr-description-template.md`; fill slots:
19	- - `module_report_contents` = full text of `docs/superpowers/module-reports/<date>-<module_id>.md`
20	- - `test_gate_conclusion`, `test_subagent_id`, `schema_rollback_conclusion`, `placeholder_conclusion`
21	-5. Create the MR:
22	-
23	- ```bash
24	- glab mr create --title "$(<title file)" --description "$(<description file)"
25	- ```
26	-
27	-6. Parse the returned MR URL and IID. Append to § ⑫ of the module report (edit the file in place).
28	-7. Print the MR URL to session.
29	-8. Stop — wait for human Approve + Merge. Do NOT call `erp-confirmed-update` yet.
30	-
31	-## References
32	-
33	-- `templates/mr-title-template.md`
34	-- `templates/mr-description-template.md`

_pl_staging/pl_skills/erp-mr-create/templates/mr-description-template.md deleted

View file @55c7b70

1	-## 模块完成报告
2	-
3	-见 `docs/superpowers/module-reports/{{date}}-{{module_id}}.md`（本 MR 仓库内完整贴入下方）。
4	-
5	----
6	-
7	-{{module_report_contents}}
8	-
9	----
10	-
11	-## 本地闸门证据
12	-
13	-- test.sh: {{test_gate_conclusion}}（subagent: {{test_subagent_id}}）
14	-- schema 回撤: {{schema_rollback_conclusion}}
15	-- 占位扫描: {{placeholder_conclusion}}
16	-
17	-## 审核入口
18	-
19	-- 本 MR = 模块 `{{module_id}}` 的唯一人工介入点
20	-- Approve + Merge 后告知 CC（或 CC 轮询 `glab mr view` 检测 merged），CC 自动 flip `docs/08` `confirmed: true`

_pl_staging/pl_skills/erp-mr-create/templates/mr-title-template.md deleted

View file @55c7b70

-feat({{module_id}}): {{module_name}}

_pl_staging/pl_skills/erp-mysql-mcp-setup/SKILL.md deleted

View file @55c7b70

1	----
2	-name: erp-mysql-mcp-setup
3	-description: Configure the MySQL MCP server and freeze the live schema as the baseline snapshot for future erp-schema-baseline-check diffs. Never runs DDL.
4	----
5	-
6	-# erp-mysql-mcp-setup
7	-
8	-## Pre-conditions
9	-
10	-- `.env.local` populated with DB_HOST / DB_PORT / DB_USER / DB_PASSWORD / DB_SCHEMA (no `【人工填写：` residuals).
11	-- MySQL instance exists and the schema is already created by a human (not by CC).
12	-
13	-## Procedure
14	-
15	-### A. Write .mcp.json
16	-1. Read `templates/mcp-json-template.json`.
17	-2. Fill slots from `.env.local`.
18	-3. Write `.mcp.json` at project root.
19	-4. If CC's MCP server is not yet loaded, ask user to restart the Claude Code session to pick up the MCP server.
20	-
21	-### B. Verify connectivity (subagent)
22	-Dispatch a fresh subagent to run a trivial `mcp__mcp_server_mysql__mysql_query` like `SHOW TABLES;` and return:
23	-```json
24	-{"connected": <bool>, "tables_count": <int>, "error": "<if any>"}
25	-```
26	-
27	-If `connected: false` → stop, surface error to user.
28	-
29	-### C. Freeze baseline (subagent)
30	-Dispatch a fresh subagent to run:
31	-```
32	-mysqldump --no-data --skip-comments -h<host> -P<port> -u<user> -p<password> <schema>
33	-```
34	-and return the full dump body (as a text block).
35	-
36	-The subagent must NOT modify the DB. Only mysqldump.
37	-
38	-### D. Write baseline file
39	-1. Read `templates/schema-baseline-header-template.sql`.
40	-2. Fill slots: `project_name`, `timestamp`, `schema_name`, `dump_body` (from subagent).
41	-3. Write `docs/superpowers/schema-baseline.sql`.
42	-
43	-### E. Validate
44	-Read back `docs/superpowers/schema-baseline.sql` — must contain `CREATE TABLE` statements for the tables listed in step B.
45	-
46	-Print: `mysql-mcp-setup: DONE (schema=<name>, tables=<n>, baseline=docs/superpowers/schema-baseline.sql)`.
47	-
48	-## Invariants
49	-
50	-- CC never runs DDL during setup.
51	-- Subagent prompts must explicitly forbid mutations.
52	-
53	-## References
54	-
55	-- `templates/mcp-json-template.json`
56	-- `templates/schema-baseline-header-template.sql`

_pl_staging/pl_skills/erp-mysql-mcp-setup/templates/mcp-json-template.json deleted

View file @55c7b70

1	-{
2	- "mcpServers": {
3	- "mysql": {
4	- "command": "npx",
5	- "args": ["-y", "@benborla29/mcp-server-mysql"],
6	- "env": {
7	- "MYSQL_HOST": "{{db_host}}",
8	- "MYSQL_PORT": "{{db_port}}",
9	- "MYSQL_USER": "{{db_user}}",
10	- "MYSQL_PASS": "{{db_password}}",
11	- "MYSQL_DB": "{{db_schema}}"
12	- }
13	- }
14	- }
15	-}

_pl_staging/pl_skills/erp-placeholder-scan/SKILL.md deleted

View file @55c7b70

1	----
2	-name: erp-placeholder-scan
3	-description: Scan for 占位符 residuals (`【人工填写：...】`, `your_password`, `your-secret-key`, `N.x` 版本号) in docs/, .env files, scripts/. Invoke after any Write to these locations and always before the module local-test-gate. Produces a scan result following a fixed template.
4	----
5	-
6	-# erp-placeholder-scan
7	-
8	-## What
9	-
10	-Detect unfilled placeholders. Any hit in a release-blocking scope (module gate) → stop and list residuals for user to fill.
11	-
12	-## Patterns (all case-sensitive unless noted)
13	-
14	-- `【人工填写：` — primary placeholder marker
15	-- `your_password`, `your-secret-key` — generic naked placeholders
16	-- `^\d+\.x$` or `^\d+\.\d+\.x$` — unlocked tech-stack minor versions
17	-
18	-## Scope
19	-
20	-- `docs/**`
21	-- `.env*` (not `.env.local` if the user has intentionally committed secrets? no — still scan; user decides)
22	-- `scripts/**`
23	-- `CLAUDE.md` (header section only)
24	-
25	-## Procedure
26	-
27	-1. Run ripgrep (via Grep tool) for each pattern across scope.
28	-2. Aggregate hits into a list of `(file, line, match)`.
29	-3. Read `templates/placeholder-scan-result-template.md`; fill slots.
30	-4. If hits found in module-gate context: stop the caller, print the filled template to session.
31	-5. If no hits: print `placeholder-scan: PASS` to session only.
32	-
33	-## When called by `erp-local-test-gate`
34	-
35	-A non-empty result fails the gate — caller must stop.
36	-
37	-## References
38	-
39	-- `templates/placeholder-scan-result-template.md`
40	-- `CLAUDE.md` § 🏷️ 占位符统一约定

_pl_staging/pl_skills/erp-placeholder-scan/templates/placeholder-scan-result-template.md deleted

View file @55c7b70

1	-## 占位符扫描结果
2	-
3	-扫描时间: {{timestamp}}
4	-扫描范围: {{scan_globs}}
5	-命中总数: {{hit_count}}
6	-
7	-\| 文件 \| 行号 \| 命中串 \|
8	-\|---\|---\|---\|
9	-{{#each hits}}
10	-\| {{file}} \| {{line}} \| `{{match}}` \|
11	-{{/each}}
12	-
13	-结论: {{conclusion}} （pass=无残留 / fail=需人工补齐）

_pl_staging/pl_skills/erp-red-flag-check/SKILL.md deleted

View file @55c7b70

1	----
2	-name: erp-red-flag-check
3	-description: Use before each feature-loop step (Brainstorm/Plan/TDD/Verify/Review) and before generating any major artifact. Runs the 6-item red-flag checklist from CLAUDE.md; on any hit, appends a Blocker block to the current plan file and stops silent execution.
4	----
5	-
6	-# erp-red-flag-check
7	-
8	-## What
9	-
10	-Verify none of the 6 red flags from `CLAUDE.md` § 🚩 静默执行红旗清单 are active. Halt on any hit.
11	-
12	-## When to invoke
13	-
14	-- Before starting any feature-loop step (3.1-3.5)
15	-- Before generating a module-level artifact (module report, MR description)
16	-- Any time the user's request implies a schema conflict, tech-stack boundary, or external dependency
17	-
18	-## Checklist (6 items — source of truth: CLAUDE.md)
19	-
20	-1. 需求与 schema 冲突 — needed fields/tables missing in live schema
21	-2. 需求本身歧义 — two or more reasonable interpretations
22	-3. 超技术栈边界 — requires framework/middleware outside CLAUDE.md 技术栈表
23	-4. 测试反复失败 — same test failing after 5 consecutive fix attempts in the current feature
24	-5. 要改密钥 / 账密 / 包名 — touching placeholders in `docs/07-环境配置.md`
25	-6. 外部接口不可达 — third-party API / cert / network issue
26	-
27	-## Procedure
28	-
29	-1. Read the current feature's spec/plan path (from conversation or `docs/08`).
30	-2. For each of the 6 flags, check explicitly. If none hit → print `red-flag-check: PASS` to session, exit.
31	-3. On hit:
32	- - Read `templates/red-flag-block-template.md`
33	- - Fill slots (flag_number, flag_name, description, affected_scope, recommendation, decision_needed)
34	- - Append the rendered block to the current plan file: `docs/superpowers/plans/YYYY-MM-DD-<REQ-id>.md`
35	- - Print a 1-sentence session summary pointing to the plan file
36	- - Stop — do not invoke any further skill until the user decides
37	-
38	-## Output
39	-
40	-Either `red-flag-check: PASS` (session only), or a `## 🚩 Blocker` block appended to the feature plan file.
41	-
42	-## References
43	-
44	-- `templates/red-flag-block-template.md`
45	-- `CLAUDE.md` § 🚩 静默执行红旗清单（权威 6 条）
46	-- `CLAUDE.md` § 🟡 软规则（S1/S2，不触发红旗但需留痕）

_pl_staging/pl_skills/erp-red-flag-check/templates/red-flag-block-template.md deleted

View file @55c7b70

1	-## 🚩 Blocker
2	-
3	-红旗编号: {{flag_number}} (1-6，对应 CLAUDE.md 🚩 静默执行红旗清单)
4	-红旗名称: {{flag_name}}
5	-问题描述: {{description}}
6	-影响范围: {{affected_scope}}
7	-我的建议: {{recommendation}}
8	-等待决策: {{decision_needed}}

_pl_staging/pl_skills/erp-requirements-gen/SKILL.md deleted

View file @55c7b70

1	----
2	-name: erp-requirements-gen
3	-description: From the human-authored requirement outline in docs/01-需求清单/README.md and the live MySQL schema, generate full REQ-XXX-NNN cards under docs/01 and the DB design doc docs/03.
4	----
5	-
6	-# erp-requirements-gen
7	-
8	-## Pre-conditions
9	-
10	-- `docs/01-需求清单/README.md` exists with per-module bullet outlines (author: human).
11	-- MCP + baseline ready (`erp-mysql-mcp-setup` done).
12	-
13	-## Procedure
14	-
15	-### A. Parse README outline
16	-For each module bullet, extract: `module_code` (SYS / PUR / INV / ...), `module_name`, function bullets.
17	-
18	-Ask user via `AskUserQuestion` to clarify any ambiguous mapping.
19	-
20	-### B. Generate REQ cards
21	-For each function bullet:
22	-1. Assign `REQ-<MOD>-<NNN>` (increment per module).
23	-2. Interactively fill the card via `AskUserQuestion` + inference from context:
24	- - 目标 / 输入 / 输出 / 业务规则 / 边界 / 依赖表（验证存在）/ 依赖接口（先占位）/ 验收
25	-3. Read `templates/req-card-template.md`; render.
26	-
27	-### C. Assemble per-module files
28	-For each module, read `templates/docs-01-module-template.md`, fill with `reqs[]`, write `docs/01-需求清单/<module_code>-<module_name>.md`.
29	-
30	-### D. Generate docs/03
31	-1. Dispatch subagent to query the live schema via MCP and return a structured list: tables + columns + indexes + FKs + types.
32	-2. Read `templates/docs-03-header-template.md`; fill `schema_name`, `er_overview`, `tables[]`.
33	-3. For each table, read `templates/docs-03-table-template.md`; fill and append.
34	-4. Business meaning of each column: infer from REQ cards or ask user.
35	-5. Write `docs/03-数据库设计文档.md`.
36	-
37	-### E. Sanity checks
38	-- Every REQ must reference at least one table that exists in docs/03.
39	-- Every table in docs/03 must appear in at least one REQ (else print a warning; may be an unused table or a missing requirement).
40	-
41	-Print: `requirements-gen: <M> modules, <N> REQs, <T> tables. Awaiting human review of 01/03.`
42	-
43	-## References
44	-
45	-- `templates/req-card-template.md`
46	-- `templates/docs-01-module-template.md`
47	-- `templates/docs-03-header-template.md`
48	-- `templates/docs-03-table-template.md`

_pl_staging/pl_skills/erp-requirements-gen/templates/docs-01-module-template.md deleted

View file @55c7b70

1	-# {{module_code}}-{{module_name}}
2	-
3	-模块简述: {{module_brief}}
4	-依赖模块: {{depends_on}}
5	-涉及表: {{tables}}
6	-
7	-## 功能清单
8	-
9	-{{#each reqs}}
10	-{{req_card}}
11	-{{/each}}

_pl_staging/pl_skills/erp-requirements-gen/templates/docs-03-header-template.md deleted

View file @55c7b70

1	-# 03-数据库设计文档
2	-
3	-Schema: `{{schema_name}}`
4	-基线快照: `docs/superpowers/schema-baseline.sql`
5	-生成方式: 通过 MCP (`mcp__mcp_server_mysql__mysql_query`) 从 live schema 反查生成。
6	-
7	-## ER 关系概览
8	-
9	-{{er_overview}}
10	-
11	-## 表清单
12	-{{#each tables}}
13	-- `{{table_name}}` — {{purpose}}
14	-{{/each}}

_pl_staging/pl_skills/erp-requirements-gen/templates/docs-03-table-template.md deleted

View file @55c7b70

1	-## `{{table_name}}` — {{purpose}}
2	-
3	-### 字段
4	-
5	-\| 字段 \| 类型 \| Nullable \| 默认 \| 业务含义 \|
6	-\|---\|---\|---\|---\|---\|
7	-{{#each columns}}
8	-\| {{name}} \| {{type}} \| {{nullable}} \| {{default}} \| {{business_meaning}} \|
9	-{{/each}}
10	-
11	-### 索引
12	-{{#each indexes}}
13	-- `{{name}}` ({{type}}): {{columns}}
14	-{{/each}}
15	-
16	-### 外键
17	-{{#each foreign_keys}}
18	-- `{{name}}`: {{from_col}} → {{to_table}}.{{to_col}} ({{on_delete}})
19	-{{/each}}
20	-
21	-### 业务注记
22	-{{notes}}

_pl_staging/pl_skills/erp-requirements-gen/templates/req-card-template.md deleted

View file @55c7b70

1	-### {{req_id}} {{title}}
2	-
3	-- 目标: {{goal}}
4	-- 输入: {{input}}
5	-- 输出: {{output}}
6	-- 业务规则: {{rules}}
7	-- 边界: {{constraints}}
8	-- 依赖表: {{schema_refs}}
9	-- 依赖接口: {{api_refs}}
10	-- 验收: {{acceptance}}

_pl_staging/pl_skills/erp-schema-baseline-check/SKILL.md deleted

View file @55c7b70

1	----
2	-name: erp-schema-baseline-check
3	-description: Verify the live MySQL schema matches the frozen baseline (`docs/superpowers/schema-baseline.sql`). Invoke before the module local-test-gate and before any `confirmed` flip. Any diff = 软规则 S1 未回撤 → 升级为红旗 #1. Execution is delegated to a fresh subagent per design principle #7.
4	----
5	-
6	-# erp-schema-baseline-check
7	-
8	-## What
9	-
10	-Confirm schema has been rolled back to baseline before declaring a module done.
11	-
12	-## Procedure
13	-
14	-1. Locate baseline file: `docs/superpowers/schema-baseline.sql`. If missing → stop with error "baseline not initialized; run erp-mysql-mcp-setup first".
15	-2. Read env: `DB_HOST`, `DB_PORT`, `DB_USER`, `DB_PASSWORD`, `DB_SCHEMA` from `.env.local` (or prompt user).
16	-3. Dispatch a fresh subagent via `Agent` tool (subagent_type: general-purpose) with this prompt:
17	-
18	- ```
19	- Task: verify MySQL schema matches a frozen baseline. Do NOT make any changes. Steps:
20	- 1. Run: mysqldump --no-data --skip-comments -h<host> -P<port> -u<user> -p<password> <schema> > /tmp/current-schema.sql
21	- 2. Diff against: <absolute path to baseline>
22	- 3. Report back ONLY a structured JSON object (no prose): {"diff_lines": <int>, "deviations": [{"type": "added_table\|dropped_column\|...", "object": "<name>", "change": "<one-line>"}], "conclusion": "clean\|dirty"}
23	- Limit: if the diff exceeds 200 lines, truncate deviations to the first 20 and note "truncated".
24	- ```
25	-
26	-4. Read the subagent's JSON result.
27	-5. Read `templates/schema-baseline-diff-template.md`; fill slots including `subagent_id` = the agent description/ID.
28	-6. If `conclusion = dirty` → invoke `erp-red-flag-check` with flag #1 and stop the caller.
29	-7. If `conclusion = clean` → print `schema-baseline-check: PASS` to session.
30	-
31	-## References
32	-
33	-- `templates/schema-baseline-diff-template.md`
34	-- `CLAUDE.md` § 🟡 软规则 S1

_pl_staging/pl_skills/erp-schema-baseline-check/templates/schema-baseline-diff-template.md deleted

View file @55c7b70

1	-## Schema 基线比对结果
2	-
3	-比对时间: {{timestamp}}
4	-基线文件: docs/superpowers/schema-baseline.sql
5	-当前 schema: {{schema_name}} @ {{db_host}}
6	-执行方式: subagent ({{subagent_id}})
7	-
8	-diff 行数: {{diff_lines}}
9	-
10	-### 偏离清单
11	-
12	-{{#each deviations}}
13	-- {{type}}: {{object}} — {{change}}
14	-{{/each}}
15	-
16	-结论: {{conclusion}} （clean=已回撤 / dirty=未回撤，升级红旗 #1）

_pl_staging/pl_skills/erp-schema-scratch-log/SKILL.md deleted

View file @55c7b70

1	----
2	-name: erp-schema-scratch-log
3	-description: Fill in 原因 and 预计回撤时机 for DDL stub rows that the `log-ddl.sh` hook auto-appended to `docs/superpowers/module-reports/<current>-schema-scratch.md`. Triggered by the hook's PostToolUse notification or invoked directly before running DDL.
4	----
5	-
6	-# erp-schema-scratch-log
7	-
8	-## What
9	-
10	-Soft-rule S1 enforcement: every DDL during debug must be logged with reason + rollback plan.
11	-
12	-## Procedure
13	-
14	-1. Identify the current module (first `confirmed: false` entry in `docs/08-模块任务管理.md`).
15	-2. Open `docs/superpowers/module-reports/<current>-schema-scratch.md`.
16	-3. If file does not exist → initialize it by reading `templates/schema-scratch-log-template.md` and writing with `module_name` slot filled.
17	-4. Find rows with `TBD(待填)` in 原因 or 预计回撤时机 columns.
18	-5. For each TBD row, ask the user (AskUserQuestion) or infer from recent conversation context:
19	- - 原因: what was the debug goal?
20	- - 预计回撤时机: 本功能结束前 / 本模块 gate 前 / 其他
21	-6. Edit the row (keep the same timestamp + SQL columns).
22	-7. Print a one-line confirmation: `schema-scratch-log: N rows updated`.
23	-
24	-## Invariants
25	-
26	-- Never mutate the 时间戳 or SQL columns of existing rows.
27	-- Never remove rows; rollback is tracked by `erp-schema-baseline-check`, not by deletion here.
28	-
29	-## References
30	-
31	-- `templates/schema-scratch-log-template.md` (file header)
32	-- `templates/schema-scratch-log-row-template.md` (single row)
33	-- `CLAUDE.md` § 🟡 软规则 S1

_pl_staging/pl_skills/erp-schema-scratch-log/templates/schema-scratch-log-row-template.md deleted

View file @55c7b70

-| {{timestamp}} | `{{sql}}` | {{reason}} | {{rollback_plan}} |

_pl_staging/pl_skills/erp-schema-scratch-log/templates/schema-scratch-log-template.md deleted

View file @55c7b70

1	-# Schema 临时改动日志 — {{module_name}}
2	-
3	-软规则 S1：本模块开发期间对 schema 的所有临时 DDL 都应记录在此；模块闸门前必须全部回撤到基线（`docs/superpowers/schema-baseline.sql`）。未回撤 → 升级为红旗。
4	-
5	-\| 时间戳 \| SQL \| 原因 \| 预计回撤时机 \|
6	-\|---\|---\|---\|---\|

_pl_staging/pl_skills/erp-session-start/SKILL.md deleted

View file @55c7b70

1	----
2	-name: erp-session-start
3	-description: Top-level orchestrator. Run at the start of any ERP-project session (or manually via /erp-session-start). Detects the current project phase and dispatches to the next skill. Never generates files directly.
4	----
5	-
6	-# erp-session-start
7	-
8	-## 整体流程（给用户看）
9	-
10	-本项目分两大阶段：先规划，再编码。CC 自动探测当前位置、打印阶段横幅、分发到下一步。你只在 ⏸ 卡点处介入。
11	-
12	-```
13	-┌──────────────────────────────────────────────────────┐
14	-│ 📋 阶段 A：规划（一次性） │
15	-│ │
16	-│ 锁技术栈 → 生项目骨架 → 接数据库 → 生需求/DB文档 │
17	-│ ↓ │
18	-│ 输出「理解确认报告」 │
19	-│ ↓ │
20	-│ ⏸ 等你回复「理解正确」才进入阶段 B │
21	-└──────────────────────────────────────────────────────┘
22	- ↓
23	-┌──────────────────────────────────────────────────────┐
24	-│ 🔁 阶段 B：编码（按模块循环，每模块包含多个功能） │
25	-│ │
26	-│ 一个模块 = 多个功能（REQ-XXX-NNN）： │
27	-│ │
28	-│ ┌─ 功能循环（每个 REQ 跑一遍）────────────────┐ │
29	-│ │ Brainstorm → Plan → TDD → Verify → Review │ │
30	-│ └────────────────────────────────────────────┘ │
31	-│ ↓ 本模块全部功能完成 │
32	-│ 本地测试闸门 → 写模块报告 → 建 GitLab MR │
33	-│ ↓ │
34	-│ ⏸ 等你 Approve + Merge MR │
35	-│ ↓ │
36	-│ 标记模块完成 → 自动进入下一个模块 │
37	-└──────────────────────────────────────────────────────┘
38	-
39	-⚙️ 后台守门（任意阶段命中即停下问你，不会静默继续）：
40	- • 文档/配置里有未填的【人工填写：】占位符
41	- • 命中红旗清单（schema 冲突 / 需求歧义 / 超技术栈等 6 项）
42	- • 数据库 schema 偏离已冻结的基线
43	- • 调试期间临时 DDL 未在模块结束前回撤
44	- • 改了已完成模块的代码但没记录原因和影响
45	-```
46	-
47	-## 分发梯（按优先级，首条命中即停）
48	-
49	-A 阶段 · 计划（一次性）
50	-
51	-1. A1 技术栈未锁定 — `CLAUDE.md` 顶部 4 meta slots（项目名称/简述/目标用户/部署方式）或技术栈表含 `【人工填写：`
52	- → `erp-tech-stack-lock`
53	-2. A2 骨架文件缺失 — `docs/04-技术规范.md` / `docs/07-环境配置.md` / `docs/09-项目目录结构.md` / `scripts/test.sh` / `scripts/setup-test-db.sh` / `.githooks/pre-push` / `.env.local.example` 任一缺失
54	- → `erp-skeleton-gen`
55	-3. A3 MCP + schema 基线未建立 — `.mcp.json` 或 `docs/superpowers/schema-baseline.sql` 缺失
56	- → `erp-mysql-mcp-setup`
57	-4. A4 需求 & DB 文档缺失 — `docs/01-需求清单/` 只有 README 或 `docs/03-数据库设计文档.md` 没有生成的表
58	- → `erp-requirements-gen`
59	-5. A5 下游文档缺失 — `docs/02-开发计划.md` / `docs/05-API接口契约.md` / `docs/08-模块任务管理.md` / `docs/10-验收检查清单.md` / `sql/seed-data.sql` 任一缺失
60	- → `erp-downstream-gen`
61	-6. A6 未输出过理解确认报告（且人工未回复「理解正确」）
62	- → `erp-understanding-report`
63	-
64	-横切守门
65	-
66	-7. X1 占位残留 — 内联跑 `erp-placeholder-scan`，结果非空
67	- → 停下打印清单，等人填
68	-
69	-B 阶段 · 编码（按模块循环）
70	-
71	-8. B5 待翻 confirmed — `docs/08` 当前 `confirmed:false` 模块对应的 MR 已 Merged（`glab mr view` 或用户告知）
72	- → `erp-confirmed-update`
73	-9. B1 默认 — 进入或继续模块循环
74	- → `erp-module-start`
75	-
76	-## 执行步骤
77	-
78	-1. 收集状态
79	- - 读 `CLAUDE.md` 头部
80	- - Glob `docs/`、`scripts/`、`.githooks/**`、`.mcp.json`、`docs/superpowers/schema-baseline.sql`
81	- - 读 `docs/08-模块任务管理.md`
82	- - `git log -1`；若 `glab` 可用则 `glab mr list --state=opened`
83	-
84	-2. 打印阶段横幅（必须输出给用户看）
85	-
86	- ```
87	- ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
88	- [erp-session-start]
89	- 阶段：<A 计划 \| B 编码 \| 横切守门>
90	- 命中：<编号> <label> （例：A1 技术栈未锁定）
91	- 当前模块：<module_id 或 —> （B 阶段才填）
92	- 下一步：invoke <skill>
93	- ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
94	- ```
95	-
96	-3. 红旗联动 — 分发目标属于 B 阶段（`erp-module-` / `erp-feature-`）时，先调 `erp-red-flag-check`；命中红旗则停在此不分发。
97	-
98	-4. 分发 — 通过 `Skill` 工具调用选中的下游 skill。本 skill 不直接产出任何制品。
99	-
100	-## References
101	-
102	-- `CLAUDE.md`（项目指令）
103	-- `docs/08-模块任务管理.md`（confirmed 状态）
104	-- `.claude/skills/erp-*`（下游 skills）

_pl_staging/pl_skills/erp-skeleton-gen/SKILL.md deleted

View file @55c7b70

1	----
2	-name: erp-skeleton-gen
3	-description: Generate the technical skeleton files (docs/04, docs/06 一~四节, docs/07, docs/09) and scripts/ + .githooks/ + .env.local.example. Reads the locked tech stack from CLAUDE.md; emits files from dedicated templates. All sensitive values left as `【人工填写：...】`.
4	----
5	-
6	-# erp-skeleton-gen
7	-
8	-## Pre-conditions
9	-
10	-- CLAUDE.md header is locked (`erp-tech-stack-lock` has run; no `【人工填写：` in the 4 meta slots).
11	-
12	-## Procedure
13	-
14	-### A. Read tech stack
15	-From CLAUDE.md § 🏗️ 技术栈, parse rows into memory.
16	-
17	-### B. Emit docs/
18	-For each target below, read the named template, fill stack-derived slots, Write to target path. Files that already exist → stop and ask (`overwrite? skip?`); do not silently clobber.
19	-
20	-\| Target \| Template \|
21	-\|---\|---\|
22	-\| `docs/04-技术规范.md` \| `templates/docs-04-skeleton-template.md` \|
23	-\| `docs/06-UI交互规范.md` \| `templates/docs-06-static-template.md` \|
24	-\| `docs/07-环境配置.md` \| `templates/docs-07-env-template.md` \|
25	-\| `docs/09-项目目录结构.md` \| `templates/docs-09-structure-template.md` \|
26	-
27	-Slot examples: `backend_layering`, `backend_package_convention`, `backend_class_convention`, `frontend_layout`, `controller_rule`, etc.
28	-
29	-- Where a value is project-specific (root package name / namespace), keep the placeholder `【人工填写：<说明>】` and register it in the `zero-section placeholder table` of `docs/07`.
30	-
31	-### C. Emit scripts/ and .githooks/ and .env example
32	-
33	-\| Target \| Template \|
34	-\|---\|---\|
35	-\| `scripts/test.sh` \| `templates/scripts-test-sh-template.sh` \|
36	-\| `scripts/setup-test-db.sh` \| `templates/scripts-setup-test-db-template.sh` \|
37	-\| `.githooks/pre-push` \| `templates/githooks-pre-push-template.sh` \|
38	-\| `.env.local.example` \| `templates/env-local-example-template` \|
39	-
40	-After writing, `chmod +x scripts/*.sh .githooks/pre-push`.
41	-
42	-Run: `git config core.hooksPath .githooks` (ask user confirmation before changing git config — this touches shared state).
43	-
44	-### D. Validate
45	-
46	-- `erp-placeholder-scan` over newly written files: hits are expected (we want them registered in § 零, speed-table).
47	-- Print summary: `skeleton-gen: wrote N files. Placeholders to fill: M (see docs/07 § 零、人工占位速查表).`
48	-
49	-## References
50	-
51	-- `templates/docs-04-skeleton-template.md`
52	-- `templates/docs-06-static-template.md`
53	-- `templates/docs-07-env-template.md`
54	-- `templates/docs-09-structure-template.md`
55	-- `templates/scripts-test-sh-template.sh`
56	-- `templates/scripts-setup-test-db-template.sh`
57	-- `templates/githooks-pre-push-template.sh`
58	-- `templates/env-local-example-template`

_pl_staging/pl_skills/erp-skeleton-gen/templates/docs-04-skeleton-template.md deleted

View file @55c7b70

1	-# 04-技术规范
2	-
3	-## 一、后端规范
4	-
5	-### 1.1 分层结构
6	-{{backend_layering}}
7	-
8	-### 1.2 命名约定
9	-- 包名: {{backend_package_convention}}
10	-- 类名: {{backend_class_convention}}
11	-- 方法名: {{backend_method_convention}}
12	-
13	-### 1.3 统一响应格式
14	-```json
15	-{"code": 200, "message": "", "data": {}, "timestamp": 0}
16	-```
17	-
18	-### 1.4 异常处理
19	-{{backend_exception_strategy}}
20	-
21	-### 1.5 事务
22	-{{backend_tx_strategy}}
23	-
24	-### 1.6 JWT 认证
25	-{{backend_jwt}}
26	-
27	-## 二、前端规范
28	-
29	-### 2.1 目录约定
30	-{{frontend_layout}}
31	-
32	-### 2.2 状态管理
33	-{{frontend_state}}
34	-
35	-### 2.3 请求封装
36	-{{frontend_http}}
37	-
38	-### 2.4 错误处理
39	-{{frontend_error}}
40	-
41	-## 三、共同约定
42	-
43	-### 3.1 Git 提交
44	-`<type>(<scope>): <subject> REQ-XXX-NNN`
45	-
46	-### 3.2 分页查询
47	-{{pagination_rule}}
48	-
49	-### 3.3 日期与金额
50	-{{datetime_money_rule}}

_pl_staging/pl_skills/erp-skeleton-gen/templates/docs-06-static-template.md deleted

View file @55c7b70

1	-# 06-UI交互规范
2	-
3	-## 一、整体布局
4	-
5	-### 1.1 页面框架
6	-{{layout_frame}}
7	-
8	-### 1.2 布局参数
9	-\| 参数 \| 值 \| 说明 \|
10	-\|---\|---\|---\|
11	-\| Header高度 \| 64px \| 固定定位 \|
12	-\| Sidebar宽度 \| 220px（展开）/ 64px（折叠） \| 可手动切换 \|
13	-\| 内容区内边距 \| 24px \| 四周 \|
14	-\| 最小支持宽度 \| 1280px \| 不做移动端适配 \|
15	-
16	-## 二、标准页面类型
17	-
18	-### 2.1 列表页
19	-{{list_page}}
20	-
21	-### 2.2 表单页
22	-{{form_page}}
23	-
24	-### 2.3 详情页
25	-{{detail_page}}
26	-
27	-### 2.4 树形管理页
28	-{{tree_page}}
29	-
30	-## 三、通用交互规则
31	-
32	-### 3.1 操作反馈
33	-{{feedback_rules}}
34	-
35	-### 3.2 数据展示
36	-{{display_rules}}
37	-
38	-### 3.3 权限控制（前端）
39	-{{permission_rules}}
40	-
41	-## 四、主题与颜色
42	-{{theme_rules}}
43	-
44	-## 五、页面清单（CC 生成）
45	-（由 `erp-downstream-gen` 按模块追加段落）

_pl_staging/pl_skills/erp-skeleton-gen/templates/docs-07-env-template.md deleted

View file @55c7b70

1	-# 07-环境配置
2	-
3	-## 零、人工占位速查表
4	-
5	-\| 占位符 \| 位置 \| 说明 \|
6	-\|---\|---\|---\|
7	-{{#each placeholders}}
8	-\| {{marker}} \| {{location}} \| {{note}} \|
9	-{{/each}}
10	-
11	-## 一、依赖清单
12	-{{#each deps}}
13	-- {{name}} {{version}} — {{purpose}}
14	-{{/each}}
15	-
16	-## 二、端口约定
17	-\| 服务 \| 端口 \|
18	-\|---\|---\|
19	-{{#each ports}}
20	-\| {{service}} \| {{port}} \|
21	-{{/each}}
22	-
23	-## 三、环境变量（.env.local.example）
24	-见 `.env.local.example`。敏感值 `【人工填写：...】` 由人工替换。
25	-
26	-## 四、数据库连接
27	-- Host: `【人工填写：MySQL host】`
28	-- Port: `【人工填写：MySQL port，默认 3306】`
29	-- Schema: `【人工填写：schema 名】`
30	-- 字符集: `【人工填写，例如 utf8mb4】`
31	-- 账号: `【人工填写：只读/读写账号】`
32	-- 密码: `【人工填写：对应密码】`
33	-
34	-## 五、常用命令
35	-{{#each commands}}
36	-- `{{command}}` — {{description}}
37	-{{/each}}

_pl_staging/pl_skills/erp-skeleton-gen/templates/docs-09-structure-template.md deleted

View file @55c7b70

1	-# 09-项目目录结构
2	-
3	-## 一、仓库顶层
4	-```
5	-{{repo_root_tree}}
6	-```
7	-
8	-## 二、后端目录
9	-```
10	-{{backend_tree}}
11	-```
12	-
13	-## 三、前端目录
14	-```
15	-{{frontend_tree}}
16	-```
17	-
18	-## 四、命名与放置约定
19	-- 根包: `【人工填写：Java 根包名 / C# 命名空间 / Python 顶层模块】`
20	-- Controller: {{controller_rule}}
21	-- Service: {{service_rule}}
22	-- Mapper/Repository: {{mapper_rule}}
23	-- DTO/VO: {{dto_rule}}
24	-- 前端组件: {{component_rule}}
25	-- 前端页面: {{page_rule}}

_pl_staging/pl_skills/erp-skeleton-gen/templates/env-local-example-template deleted

View file @55c7b70

1	-DB_HOST=【人工填写：MySQL host，例如 localhost】
2	-DB_PORT=【人工填写：MySQL port，默认 3306】
3	-DB_USER=【人工填写：开发账号名】
4	-DB_PASSWORD=【人工填写：对应密码】
5	-DB_SCHEMA=【人工填写：schema 名，例如 erp_dev】
6	-JWT_SECRET=【人工填写：JWT 签名密钥，256+ bit 随机串】

_pl_staging/pl_skills/erp-skeleton-gen/templates/githooks-pre-push-template.sh deleted

View file @55c7b70

1	-#!/usr/bin/env bash
2	-# .githooks/pre-push — run scripts/test.sh before every push.
3	-# No --no-verify: the claude-code hook deny-no-verify.sh also blocks it.
4	-
5	-set -euo pipefail
6	-
7	-cd "$(git rev-parse --show-toplevel)"
8	-
9	-./scripts/test.sh

_pl_staging/pl_skills/erp-skeleton-gen/templates/scripts-setup-test-db-template.sh deleted

View file @55c7b70

1	-#!/usr/bin/env bash
2	-# scripts/setup-test-db.sh — truncate + reseed only. NEVER runs DDL.
3	-# Schema is human-owned; this script only clears data and reloads seed-data.sql.
4	-
5	-set -euo pipefail
6	-
7	-source "$(dirname "$0")/../.env.local"
8	-
9	-echo "[setup-test-db] truncate tables in ${DB_SCHEMA}"
10	-mysql -h"${DB_HOST}" -P"${DB_PORT}" -u"${DB_USER}" -p"${DB_PASSWORD}" "${DB_SCHEMA}" <<'SQL'
11	-SET FOREIGN_KEY_CHECKS = 0;
12	-{{truncate_block}}
13	-SET FOREIGN_KEY_CHECKS = 1;
14	-SQL
15	-
16	-echo "[setup-test-db] reseed"
17	-mysql -h"${DB_HOST}" -P"${DB_PORT}" -u"${DB_USER}" -p"${DB_PASSWORD}" "${DB_SCHEMA}" < sql/seed-data.sql
18	-
19	-echo "[setup-test-db] done"

_pl_staging/pl_skills/erp-skeleton-gen/templates/scripts-test-sh-template.sh deleted

View file @55c7b70

1	-#!/usr/bin/env bash
2	-# scripts/test.sh — the only hard gate before merging to main.
3	-# Runs build + lint + unit + integration + E2E.
4	-# Called by .githooks/pre-push and by the erp-local-test-gate skill (via subagent).
5	-
6	-set -euo pipefail
7	-
8	-PROJECT_ROOT="$(cd "$(dirname "$0")/.." && pwd)"
9	-cd "$PROJECT_ROOT"
10	-
11	-echo "[test.sh] 1/5 setup test db"
12	-./scripts/setup-test-db.sh
13	-
14	-echo "[test.sh] 2/5 build"
15	-{{build_command}}
16	-
17	-echo "[test.sh] 3/5 lint"
18	-{{lint_command}}
19	-
20	-echo "[test.sh] 4/5 unit + integration"
21	-{{unit_integration_command}}
22	-
23	-echo "[test.sh] 5/5 E2E"
24	-{{e2e_command}}
25	-
26	-echo "[test.sh] GREEN"

_pl_staging/pl_skills/erp-tech-stack-lock/SKILL.md deleted

View file @55c7b70

1	----
2	-name: erp-tech-stack-lock
3	-description: Interactively collect project metadata (name / brief / target users / deployment) and confirm-or-edit the tech stack table, then write into CLAUDE.md header via claude-md-header-template. Invoke at project start or whenever CLAUDE.md header slots are still `【人工填写：...】`.
4	----
5	-
6	-# erp-tech-stack-lock
7	-
8	-## Procedure
9	-
10	-### A. Collect 4 metadata slots
11	-
12	-Ask the user via `AskUserQuestion` (one question per slot; use multiSelect=false; provide reasonable options where possible):
13	-
14	-1. 项目名称 — open-ended (no options; use "Other")
15	-2. 项目简述 — open-ended, one sentence
16	-3. 目标用户 — open-ended (examples: 企业内部管理人员 / 面向 C 端客户 / ...)
17	-4. 部署方式 — options: `私有化部署` / `云部署` / `Docker 容器化` / `混合`
18	-
19	-### B. Tech-stack table
20	-
21	-Default table (11 rows):
22	-
23	-\| 层级 \| 技术 \| 版本要求 \|
24	-\|---\|---\|---\|
25	-\| 前端框架 \| React \| 18.x \|
26	-\| 前端UI库 \| Ant Design \| 5.x \|
27	-\| 前端状态管理 \| Redux Toolkit \| 最新稳定版 \|
28	-\| 前端路由 \| React Router \| v6 \|
29	-\| 前端构建 \| Vite \| 最新稳定版 \|
30	-\| 前端HTTP \| Axios \| 最新稳定版 \|
31	-\| 后端框架 \| Spring Boot \| 3.x \|
32	-\| 后端ORM \| MyBatis-Plus \| 最新稳定版 \|
33	-\| 数据库 \| MySQL \| 8.x \|
34	-\| 认证方案 \| JWT \| — \|
35	-\| API风格 \| RESTful \| — \|
36	-
37	-Ask one question per row, in order. For each row, use `AskUserQuestion` with:
38	-- header: the 层级 name (e.g. "前端框架")
39	-- question: `<层级>：沿用 <默认技术默认版本>，还是替换？`
40	-- options (exactly 3):
41	- 1. `沿用 <默认技术> <默认版本>` — keep default
42	- 2. `替换为其它技术` — user picks "Other" and types the replacement (format: `技术名版本`, e.g. `Vue 3.x`)
43	- 3. `当前技术栈不需要` — drop this row entirely (e.g. 纯后端项目可移除前端各行)
44	-- multiSelect: false
45	-
46	-One row = one `question` entry. Batch as many rows as possible into each `AskUserQuestion` call (the tool's own `maxItems` caps how many fit per call; don't add artificial limits beyond that). Do NOT collapse multiple rows into one question with rows-as-options.
47	-
48	-After all 11 rows are collected, ask a final question:
49	-- question: `以上 11 项已确认。是否需要新增技术栈条目？（例如消息队列/缓存/搜索引擎）`
50	-- options (exactly 2):
51	- 1. `不新增`
52	- 2. `新增条目` — if picked, follow up: ask the user to list additions in free text, format: `层级 \| 技术 \| 版本` per line
53	-- multiSelect: false
54	-
55	-Collect the final stack_rows list (11 base rows, each either kept or replaced, plus any additions).
56	-
57	-### C. Render and write
58	-
59	-1. Read `templates/claude-md-header-template.md`.
60	-2. Fill slots: `project_name`, `project_brief`, `target_users`, `deployment`, `stack_rows[]`.
61	-3. Locate the target block in `CLAUDE.md` (§ 🎯 项目概述 + § 🏗️ 技术栈) and replace with the rendered content. Preserve all other CLAUDE.md sections verbatim.
62	-4. Verify with `erp-placeholder-scan` over `CLAUDE.md` header — must have no `【人工填写：` residuals in the 4 collected slots.
63	-5. Print `tech-stack-lock: DONE (<project_name>)`.
64	-
65	-## References
66	-
67	-- `templates/claude-md-header-template.md`

_pl_staging/pl_skills/erp-tech-stack-lock/templates/claude-md-header-template.md deleted

View file @55c7b70

1	-## 🎯 项目概述
2	-
3	-- 项目名称: {{project_name}}
4	-- 项目简述: {{project_brief}}
5	-- 目标用户: {{target_users}}
6	-- 部署方式: {{deployment}}
7	-
8	----
9	-
10	-## 🏗️ 技术栈（不可更改）
11	-
12	-\| 层级 \| 技术 \| 版本要求 \|
13	-\|---\|---\|---\|
14	-{{#each stack_rows}}
15	-\| {{layer}} \| {{tech}} \| {{version}} \|
16	-{{/each}}

_pl_staging/pl_skills/erp-understanding-report/SKILL.md deleted

View file @55c7b70

1	----
2	-name: erp-understanding-report
3	-description: Output the 6-section understanding confirmation report and stop to wait for the user's "理解正确" before any coding starts.
4	----
5	-
6	-# erp-understanding-report
7	-
8	-## Pre-conditions
9	-
10	-All planning docs present: `docs/01-需求清单/**`, `docs/02` through `docs/10`, `sql/seed-data.sql`.
11	-
12	-## Procedure
13	-
14	-1. Read (one-time, comprehensive):
15	- - CLAUDE.md
16	- - docs/01-需求清单/README.md and all module files
17	- - docs/02 through 10
18	- - docs/superpowers/schema-baseline.sql header (not body)
19	-2. Read `templates/understanding-report-template.md`.
20	-3. Fill slots:
21	- - `project_goal` — derived from CLAUDE.md 项目概述
22	- - `modules[]` — from docs/08 in topological order
23	- - `data_model` — key entity relations summarized from docs/03 (3–5 sentences)
24	- - `tech_approach` — key architectural choices from docs/04
25	- - `questions` — any ambiguity / conflict / gap you spotted; explicit list, not "no questions"
26	- - `next_module` — first `confirmed: false` in docs/08
27	-4. Print the rendered report to the main session (do NOT write a file — this is a conversation artifact).
28	-5. Stop. Do not invoke any downstream skill. Wait for the user to reply "理解正确" or equivalent.
29	-
30	-## After user confirms
31	-
32	-- Hand off to `erp-session-start` (which will detect state and dispatch to `erp-module-start`).
33	-
34	-## References
35	-
36	-- `templates/understanding-report-template.md`

_pl_staging/pl_skills/erp-understanding-report/templates/understanding-report-template.md deleted

View file @55c7b70

1	-## 📝 理解确认报告
2	-
3	-### 1. 项目目标理解
4	-{{project_goal}}
5	-
6	-### 2. 模块拆解理解
7	-{{#each modules}}
8	-- {{module_id}} {{module_name}} — {{core_functions}}
9	-{{/each}}
10	-
11	-### 3. 数据模型理解
12	-{{data_model}}
13	-
14	-### 4. 技术方案理解
15	-{{tech_approach}}
16	-
17	-### 5. 存在的疑问
18	-{{questions}}
19	-
20	-### 6. 开发计划确认
21	-按 `docs/02-开发计划.md` 拓扑序开发，首个待推进模块: {{next_module}}。
22	-
23	----
24	-
25	-⚠️ 等待人工回复"理解正确"后才开始编码。

_pl_staging/pl_指南.md deleted

View file @55c7b70

1	-# ERP项目 — 文档总览与使用指南
2	-
3	-> 本文件是整个文档体系的入口。先读这里，再按流程操作。
4	-> 核心思路：人工只填"机器不可能知道的东西"，其余交给 Claude Code 生成后人工审阅。
5	->
6	-> 阅读顺序：建议先通读一到四节（文档目录 / 分工 / 配套机制 / 关键原则），建立整体认知；然后按第五节"完整使用流程"逐步上手。
7	-
8	----
9	-
10	-## 一、文档目录
11	-
12	-```
13	-项目根目录/
14	-├── CLAUDE.md ← ★ Claude Code 的主指令文件（顶部需人工填项目概述）
15	-├── 指南.md ← 本文件
16	-├── docs/ ← 所有项目文档
17	-│ ├── 01-需求清单/ ← 功能需求全集（按模块分文件，模块可自由增删）
18	-│ │ ├── README.md ← 纲要 + 模块索引（人工写）
19	-│ │ ├── SYS-系统管理.md ← REQ-SYS-* 用户/角色/权限/部门/字典
20	-│ │ └── <其他模块>.md ← 如 PUR-采购 / SAL-销售 / HR-人事等，按业务增删，详见 README
21	-│ ├── 02-开发计划.md ← 分模块开发路线图（CC 基于需求按技术依赖重排）
22	-│ ├── 03-数据库设计文档.md ← 表结构业务含义（CC 通过 MySQL MCP 查询 live DB 生成）
23	-│ ├── 04-技术规范.md ← 通用规范 + 技术栈衍生编码规范（骨架由 CC 按技术栈生成）
24	-│ ├── 05-API接口契约.md ← 前后端接口契约（CC 基于需求+表结构生成）
25	-│ ├── 06-UI交互规范.md ← 页面布局与交互规则（模板已完整）
26	-│ ├── 07-环境配置.md ← 骨架由 CC 按技术栈生成；人工填账密/密钥/包名等占位
27	-│ ├── 08-模块任务管理.md ← ★ 人机协作控制中枢（CC 与 02 对齐）
28	-│ ├── 09-项目目录结构.md ← 骨架由 CC 按技术栈生成（前后端目录名与层级）
29	-│ └── 10-验收检查清单.md ← 每个模块的质量门（CC 基于需求生成）
30	-├── scripts/
31	-│ ├── setup-test-db.sh ← truncate 当前 schema + reseed（CC 按技术栈生成；3.3）
32	-│ └── test.sh ← 一键全量测试脚本（CC 按技术栈生成；3.3）
33	-├── .githooks/
34	-│ └── pre-push ← Git hook：push 前自动跑 test.sh（3.3）
35	-├── .env.local ← 每人独立的数据库连接（schema 名），不入 git
36	-└── <代码目录> ← 由 Step 1 技术栈决定，CC 在 Step 10 开发时生成
37	- 具体目录名与层级参见 docs/09-项目目录结构.md
38	-```
39	-
40	----
41	-
42	-## 二、文档分工：谁来填？
43	-
44	-\| 类别 \| 文档 \| 负责人 \| 说明 \|
45	-\| ---------- \| --------------------------------- \| ----------- \| ----------------------------------------------------------------------- \|
46	-\| A 必填 \| `CLAUDE.md` 顶部项目概述（4 处） \| 👤 人工 \| 项目名、简述、目标用户、部署方式 \|
47	-\| A 必填 \| `docs/01-需求清单/README.md` 纲要 \| 👤 人工 \| 模块列表 + 每模块核心功能点 + 关键业务数字 \|
48	-\| A 必填 \| `docs/07-环境配置.md` 敏感/专属占位 \| 👤 人工 \| 数据库账密、JWT secret、包名、上传路径、小版本号等 \|
49	-\| A 必填 \| MySQL schema + 表 DDL + MCP 连接 \| 👤 人工 \| 在现有 MySQL 中新建项目专用 schema 并建齐所有表；在仓库 `.mcp.json` 配置 MCP 指向该 schema \|
50	-\| B 生成+审 \| `docs/01-需求清单/<模块>.md` 完整版 \| 🤖 CC → 人工审 \| 逐模块一个文件，基于纲要扩展成 REQ-XXX-NNN 标准卡片 \|
51	-\| B 生成+审 \| `docs/02-开发计划.md` \| 🤖 CC → 人工审 \| 基于 01 需求按技术依赖拆分模块 0～N \|
52	-\| B 生成+审 \| `docs/03-数据库设计文档.md` \| 🤖 CC → 人工审 \| 通过 MySQL MCP 查 live DB 自动填字段业务说明、ER 关系 \|
53	-\| B 生成+审 \| `docs/04-技术规范.md` 骨架 \| 🤖 CC → 人工审 \| 按 `CLAUDE.md` 技术栈表推导后端 / 前端编码规范与认证实现（通用规范章节保留不变） \|
54	-\| B 生成+审 \| `docs/05-API接口契约.md` \| 🤖 CC → 人工审 \| 基于 01+03 生成 RESTful 契约 \|
55	-\| B 生成+审 \| `docs/07-环境配置.md` 骨架 & 依赖 \| 🤖 CC → 人工审 \| 按 `CLAUDE.md` 技术栈表推导主配置文件 / 依赖清单 / 端口规划 \|
56	-\| B 生成+审 \| `docs/08-模块任务管理.md` \| 🤖 CC → 人工审 \| 与 02 对齐生成任务表格 \|
57	-\| B 生成+审 \| `docs/09-项目目录结构.md` \| 🤖 CC → 人工审 \| 按 `CLAUDE.md` 技术栈表推导前后端目录名与层级 \|
58	-\| B 生成+审 \| `docs/10-验收检查清单.md` \| 🤖 CC → 人工审 \| 基于 01+08 生成验收项 \|
59	-\| B 生成+审 \| `sql/seed-data.sql` \| 🤖 CC → 人工审 \| 基于 MCP 查到的 schema 扩充业务测试数据 \|
60	-\| C 模板齐全 \| `docs/06-UI交互规范.md` \| — \| 通用规范，无需填写 \|
61	-
62	-判断标准：只有你知道 / 涉及密钥 / 体现业务意图 → A 类必填；能从需求或 schema 推导 → B 类交给 CC。
63	-
64	-### 占位符统一约定
65	-
66	-所有"需要人工填"的位置，全部用下面这种可见、可搜索的标记：
67	-
68	-```
69	-【人工填写：<简短说明>】
70	-```
71	-
72	-示例：
73	-
74	-```markdown
75	-- 项目名称: 【人工填写：公司+项目名，例如：无锡五彩印务 ERP】
76	-- 数据库密码: 【人工填写：生产库密码，走环境变量不要入库】
77	-- 销售（SAL）: 【人工填写：客户管理、报价单、销售订单、出库等核心功能点】
78	-```
79	-
80	-规则：
81	-
82	-- 填写时把整个 `【人工填写：...】` 连带中文方括号一起替换为实际值，不要保留方括号
83	- （示例：`【人工填写：数据库密码】` → `Abc@123`，不是 `【Abc@123】`）
84	-- Step 6 启动时 CC 扫描 `【人工填写：` 作为残留占位的首选特征字符串；兜底还扫通用的裸占位值：`your_password` / `your-secret-key`（技术栈特有的占位值不纳入，统一靠 `【人工填写：`）
85	-
86	----
87	-
88	-## 三、配套机制（跨步骤生效，非顺序步骤）
89	-
90	-五节的 9 步是"从零到开发"的顺序动作；本节三条不是步骤，而是始终在后台生效的规则 / 闸门 / 工具。
91	-
92	-### 3.1 confirmed 完成确认标记（模块完成清单）
93	-
94	-`confirmed` 是模块完成清单：标记哪些模块已通过人工审核、可视为已交付，从而让 CC 知道该在哪个模块上继续工作。定义在 `docs/08-模块任务管理.md`。
95	-
96	-```yaml
97	-module_1:
98	- confirmed: false # false = 待完成（CC 在此模块上开发）
99	- # true = 已完成（MR 已合入，CC 进入下一模块）
100	-```
101	-
102	-\| 操作 \| 触发方 \| 触发条件 \|
103	-\| -- \| -- \| -- \|
104	-\| 默认 `confirmed: false` \| — \| 新模块生成时 \|
105	-\| `false` → `true` \| CC \| MR 已 Approved + Merged（人工告知或 `glab mr view` 验证 merged 状态） \|
106	-\| `true` → `false`（重新开启） \| 人工或 CC \| 发现已确认模块有 bug / 需打回重做 \|
107	-
108	-授权边界：
109	-
110	-- CC 可以改 `false` → `true`，但前置条件是 MR 已合入（人工 review 是唯一审核点；CC 只是把"MR 合入"这个事实同步到清单里）
111	-- CC 不得在 MR 未 merged 时改 `true`（等于跳过人工审核）
112	-- CC 可以把 `true` 改回 `false`（发现已确认模块有 bug 时，把该模块重新开启）
113	-
114	-### 3.2 红旗中断机制（CC 行为规则）
115	-
116	-功能循环默认静默执行，只有命中"红旗"才打断等人决策。具体的 10 条红旗清单 + CC 命中后的固定动作都定义在 `CLAUDE.md` 的「🚩 静默执行红旗清单」一节——CC 启动时已自动加载，开发者无需在此重复学习。
117	-
118	-本节在指南中保留只是为了让阅读流程的开发者知道这个机制存在；运行态的权威来源是 CLAUDE.md。
119	-
120	-### 3.3 本地测试闸门（本项目唯一的硬闸门）
121	-
122	-> 设计：本项目不使用 GitLab CI/CD，所有测试集中在本地完整跑（单元 + 集成 + E2E + lint + 构建）；闸门由一键脚本 + `pre-push` Git hook + CC 自动创建 MR + 人工审核合入协同实现。
123	-
124	-#### 数据库架构
125	-
126	-- 单 MySQL 实例 + 单 schema（复用现有 MySQL 服务器，不用 Docker）
127	-- schema 命名由人工定（例如 `erp_dev`），由人工在 Step 4 建好所有表
128	-- CC 的 MCP 连接指向该 schema，作为 live 真实源供文档生成与字段核对
129	-- 本项目单开发者场景，`test.sh` 跑时 truncate + reseed 同一 schema，不存在并发问题
130	-
131	-#### 仓库里放三个产物（CC 在 Step 2 按技术栈生成）
132	-
133	-```
134	-<项目根>/
135	-├── scripts/
136	-│ ├── setup-test-db.sh ← truncate 当前 schema 所有表 + 导入 seed-data.sql
137	-│ └── test.sh ← 一键全量测试：单元 + 集成 + E2E + lint + 构建
138	-└── .githooks/
139	- └── pre-push ← Git hook：push 前自动跑 test.sh，失败则拒绝 push
140	-```
141	-
142	-> 不使用 Docker、不使用 `docker-compose.test.yml`；复用现有 MySQL。
143	-
144	-各文件职责：
145	-
146	-- `scripts/setup-test-db.sh`：读 `.env.local` 取 DB 连接 → 连 MySQL → 对当前 schema 内所有表 `TRUNCATE`（禁用 FK 检查）→ `mysql < sql/seed-data.sql`。不建表不删表（DDL 归人工）
147	-- `scripts/test.sh`：按技术栈串起来——先调 `setup-test-db.sh` 重置数据 → 后端单元 / 集成测试、前端单元测试、E2E（Playwright / Cypress）、lint、构建验证。退出码非 0 即失败
148	-- `.githooks/pre-push`：bash 脚本，`git push` 前自动触发 `scripts/test.sh`；非 0 退出码会让 `git push` 被拒绝
149	-
150	-#### 一次性 Dev Setup（每个开发者克隆后跑一次）
151	-
152	-```bash
153	-# 1. 启用仓库自带 hooks（不在 .git/hooks 里，在 .githooks/ 方便入版本控制）
154	-git config core.hooksPath .githooks
155	-
156	-# 2. 复制 .env.local.example → .env.local，填入 MySQL 连接
157	-cp .env.local.example .env.local
158	-# 编辑：DB_HOST / DB_PORT / DB_USER / DB_PASSWORD / DB_SCHEMA（项目专用 schema 名）
159	-
160	-# 3. 试跑一遍（会对当前 schema 做 truncate + reseed）
161	-./scripts/setup-test-db.sh
162	-./scripts/test.sh
163	-
164	-# 4. 配置 glab CLI（CC 自动创建 MR 用）
165	-glab auth login # 按提示填自建 GitLab 实例 URL + PAT
166	-```
167	-
168	-> 前提：MySQL 中已建好项目专用 schema 并用 DDL 建齐所有表（见 Step 4）。
169	->
170	-> CC 需要：`glab` CLI + GitLab PAT（scope: `api` / `write_repository`）；token 存 `~/.config/glab-cli/config.yml`，不入版本控制。MySQL MCP 连接在 `.mcp.json` 配置（指向项目 schema）。
171	-
172	-约定写在 `docs/07-环境配置.md` 的七节"启动 / 构建命令"，由 CC 在 Step 2 生成时同步登记。
173	-
174	-#### MR 创建与合并流程（合并前置仅 2 项）
175	-
176	-1. 本地 `scripts/test.sh` 全绿 —— `.githooks/pre-push` 自动触发，失败则 push 被拒；禁止 `--no-verify` 绕过
177	-2. CC 自动 `git push` + `glab mr create` —— 将《模块完成报告》审阅包贴入 MR 描述（含通过用例数、耗时、`test.sh` 输出结尾作为跑过测试的书面证据）；CC 输出 MR 链接后停下等人工
178	-3. 模块末人工审核（唯一人工介入点） —— 你 review 通过后：
179	- - 点 MR "Approve" + Merge
180	- - 对 CC 说"MR 已 approve + merge"（或 "继续"）
181	-4. CC 自行同步 confirmed 并进入下一模块：
182	- - CC 用 `glab mr view <mr-iid>` 验证 MR 确实已 merged
183	- - 验证通过后，在 `docs/08-模块任务管理.md` 把当前模块 `confirmed` 改为 `true`
184	- - 进入下一个 `false` 模块开始工作
185	-
186	-> 人工只做"审 + Approve + Merge + 告知 CC"四件事；`confirmed` 字段的实际写入由 CC 完成，但必须以 MR merged 为前提——CC 若在未 merged 状态下写 `true`，等于跳过人工审核，属于严重违规。
187	-
188	-#### GitLab 仓库设置（Ops 一次性配置）
189	-
190	-- Project → Settings → Repository → Protected Branches
191	- - `main`：Allowed to push = No one（强制走 MR）
192	- - Allowed to merge = Developers + Maintainers
193	-- Project → Settings → Merge Requests
194	- - ☑ All threads must be resolved
195	- - Approvals → 至少 1 人
196	-
197	-> 本项目不启用 "Pipelines must succeed"，也不配置 CI/CD Runner；本地 `scripts/test.sh` + `pre-push` hook 是唯一硬闸门。
198	-
199	----
200	-
201	-## 四、关键原则
202	-
203	-1. schema 是只读权威（MySQL MCP live 查询） — 项目专用 schema 是唯一权威来源，CC 通过 MCP 只读查询；需求围绕既有表结构展开；CC 禁止 `CREATE TABLE / ALTER TABLE / DROP TABLE`（DDL 归人工，在 MySQL 中直接执行）
204	-2. 需求与 schema 冲突必须停下来 — 若某需求在表里找不到落脚点，CC 须报告由你决策：改需求 or 人工改库
205	-3. 人工只填机器不可能知道的东西 — 意图、密钥、密码等
206	-4. 文档越精确，AI 输出越准确 — A 类纲要写得越详细，B 类生成越准
207	-5. 先确认理解，再动手编码 — CC 必须先输出《理解确认报告》
208	-6. 每份文档生成后立即审阅 — 不要积压到最后一起审
209	-7. 按模块推进，每个模块可控 — 不跳模块，不并行，逐个确认完成
210	-8. 静默执行，命中红旗才停 — 功能循环默认不打扰人；CC 仅在 `CLAUDE.md` 🚩 红旗清单 10 条之一成立时才打断主会话等人决策
211	-9. 技术栈分工：版本号单一来源 — `CLAUDE.md` 的技术栈表只做大版本锁定（`18.x` / `3.x`），作为"禁止更换技术"的约束；所有小版本号、依赖清单、具体配置模板（application.yml / pom.xml / vite.config.ts / package.json）只写在 `docs/07-环境配置.md`。两处不要重复小版本，避免漂移。
212	-10. Spec 是 source of truth — 所有代码必须能回溯到某份 spec（01 需求卡 / superpowers spec）；代码跑偏 spec 时，以 spec 为准，先改 spec 再改码。
213	-11. 验收必须可执行 — `docs/10-验收检查清单.md` 不是人工 checklist，而是可自动运行的测试用例清单（JUnit + Playwright / Vitest）。`confirmed: true` 的前提是所有用例本地 `./scripts/test.sh` 全绿。
214	-12. AI 产物必须逐行 review，但人工只在模块末做一次 — 每个功能强制跑 `superpowers:code-reviewer` 子代理审查并修复；人工 review 在模块末统一进行，依据《模块完成报告》的审阅包。
215	-13. 本地测试脚本是唯一硬闸门 — `scripts/test.sh` 跑完整测试（单元 + 集成 + E2E + lint + 构建）；`pre-push` hook 失败即拒 push；测试绿后 CC 自动 `git push + glab mr create`；本项目不配置 CI/CD；禁止 `--no-verify` 绕过。
216	-14. 业务顺序 ≠ 执行顺序 — `01-需求清单/` 按业务模块分组，顺序无所谓；`02-开发计划.md` 才是执行顺序，由 CC 按技术依赖（基础设施 → 认证 → 系统管理 → 基础资料 → 业务主流程）重排。人工不要试图在 01 里排开发顺序。
217	-15. 计划阶段 vs 开发阶段 — Step 1–9 是计划阶段，不写业务代码，通过人机反复对话把所有不确定性消解在文档里（需求卡、表结构、API 契约、任务清单、验收用例等都越厚越好）。Step 10 是开发阶段，CC 在充分的文档基础上尽可能自主推进（功能循环默认静默），人工只在模块末 review MR。文档越厚，开发越能自主；开发越自主，文档越要在计划阶段打磨——宁可在前者多花时间，也不让后者被追问打断。
218	-
219	----
220	-
221	-## 五、完整使用流程
222	-
223	-本流程分为两个阶段，严格单向推进，不回头：
224	-
225	-\| 阶段 \| 步骤 \| 核心原则 \| 交互密度 \|
226	-\|------\|------\|--------\|--------\|
227	-\| 🗂️ 计划阶段 \| Step 1–9 \| 不写业务代码，通过人机反复对话沉淀尽量丰富的文档 \| 高（每步都有人工审核 / 输入） \|
228	-\| 🏗️ 开发阶段 \| Step 10 \| 文档驱动自主开发，功能循环默认静默，人工只在模块末 review MR \| 低（每个模块唯一一次人工介入点） \|
229	-
230	-> 设计意图：把所有模糊、歧义、决策压力都挪到计划阶段解决；进入开发阶段后 CC 能一气呵成地推进功能循环，不被反复打断。文档质量 = 开发自主度的上限。
231	-
232	-> 总原则：通用开发项目都应遵循"锁定技术栈 → 生成环境配置 → 填占位 → 提供业务输入 → 生成需求文档 → 分模块开发"的单向依赖链。
233	-> ⚠️ 本项目额外约束：数据库是现有的，schema 是既定事实不可变，所以业务需求必须后于 schema。
234	->
235	-> 动手前先读完一到四节，建立整体认知；本节是具体操作步骤。
236	-
237	----
238	-
239	-## 🗂️ 计划阶段（Step 1–9）：文档厚过天
240	-
241	-> 本阶段不写任何业务代码（Step 2 生成的 scripts / 配置骨架属于开发工装，不是产品代码）。
242	-> 每一步产出都要立刻人工审阅，宁可在这里多对话几轮。
243	-> 计划阶段走完后，`docs/` 应该能回答 CC 在开发中可能遇到的 95% 以上问题。
244	-
245	-### Step 1 — 确定技术栈（人工）
246	-
247	-1. 填 `CLAUDE.md` 顶部 4 处：项目名 / 简述 / 目标用户 / 部署方式。
248	-2. 确认或调整 `CLAUDE.md` 的「🏗️ 技术栈」表。默认是 `Spring Boot 3.x + MyBatis-Plus + React 18 + Vite + Ant Design + JWT + MySQL 8`，保留或替换为你的技术选型。此表只写大版本，小版本号留到 Step 3（配置运行环境）填。
249	-
250	-> 这一步决定了 Step 2 能生成什么；变动技术栈必须回到这一步重走。
251	-
252	-### Step 2 — 生成技术骨架（CC）
253	-
254	-基于 `CLAUDE.md` 技术栈表，由 CC 一次性生成 04 / 07 / 09 的骨架部分（凡是技术栈变动就需要重生成的内容）。
255	-
256	-对 CC 说（复制粘贴即可）：
257	-
258	-```
259	-请读 CLAUDE.md（不需要读指南.md），基于 CLAUDE.md 的「🏗️ 技术栈」表，一次性生成下列骨架。
260	-前三份是 docs/ 下的纯模板文件；第四项是本地测试闸门的四件套（仓库根与 scripts/ / .githooks/ 下）。
261	-你的任务是把每一节 / 每个文件填成技术栈对应的实际内容。
262	-
263	-1. docs/07-环境配置.md —— 保留文件头与节标题不变，按技术栈填入各节内容：
264	- - 一、基础环境：列出运行时 / 包管理器 / 构建工具的大版本要求
265	- - 二、后端运行配置：给出主配置文件（如 application.yml / appsettings.json / settings.py / …）的完整结构
266	- - 三、前端构建配置：给出构建与路径配置（如 vite.config.* / next.config.* / tsconfig.json 等）
267	- - 四、后端依赖清单：按包管理器格式（pom.xml / build.gradle / requirements.txt / *.csproj / go.mod / package.json …）列核心依赖
268	- - 五、前端依赖清单：按包管理器格式列依赖
269	- - 六、端口规划：填表
270	- - 七、启动 / 构建命令：填表
271	-
272	-2. docs/09-项目目录结构.md —— 保留文件头与节标题不变，按技术栈填入：
273	- - 一、顶层结构（固定项 CLAUDE.md / 指南.md / docs / sql + 技术栈相关代码目录）
274	- - 二、后端目录结构（分层结构树）
275	- - 三、前端目录结构
276	- - 四、命名约定（表格）
277	-
278	-3. docs/04-技术规范.md —— 保留文件头与节标题不变，三节（通用规范）不要改；只填：
279	- - 一、后端编码规范（1.1 命名约定表 / 1.2 包 / 模块结构树 / 1.3 分层职责 / 1.4 代码模板）
280	- - 二、前端编码规范（2.1 命名约定表 / 2.2 目录结构 / 2.3 组件编写规范 / 2.4 API 调用规范）
281	- - 四节只填 4.6 认证实现（其余 4.1–4.5 是跨栈策略，不要改）
282	-
283	-4. 本地测试闸门三件套 + 一个环境文件（项目不配置 CI/CD；闸门完全在本地；不使用 Docker；单开发者复用现有 MySQL 中的单 schema）：
284	- - `scripts/setup-test-db.sh` —— 读 `.env.local` 取 DB 连接 → 连 MySQL → 对当前 schema 内所有表 TRUNCATE（SET FOREIGN_KEY_CHECKS=0）→ `mysql < sql/seed-data.sql`；不做 DDL（建表归人工）
285	- - `scripts/test.sh` —— 先调 `setup-test-db.sh` 重置数据 → 后端单元+集成测试 + 前端单元测试 + E2E（Playwright / Cypress，按栈选）+ lint + 前后端构建；任一失败即退出非 0
286	- - `.githooks/pre-push` —— `#!/usr/bin/env bash` + `set -e` + 调用 `./scripts/test.sh`
287	- - 根目录 `.env.local.example` —— 占位模板，列 `DB_HOST` / `DB_PORT` / `DB_USER` / `DB_PASSWORD` / `DB_SCHEMA`，值用 `【人工填写：...】`；真实 `.env.local` 入 `.gitignore`
288	- - `docs/07-环境配置.md` 需额外登记：MySQL 连接信息（host / port / 账密 / schema 名占位）+ MCP 配置说明；`glab` CLI 工具要求 + GitLab PAT 占位；E2E 测试依赖（Playwright browser install 等）
289	- - 不生成 `docker-compose.test.yml`（本项目不用 Docker）
290	-
291	-【强制规则】
292	-- 所有敏感值 / 项目专属值 / 小版本号一律用【人工填写：<简短说明>】标记，不要填实际值
293	-- 凡是"只有人工能决定"的地方（密钥、账密、命名约定等）一律用这个标记，不要自行编值
294	-- 占位标记必须用纯文本 `【人工填写：…】`，不要用 HTML 注释（`<!-- ... -->`），因为后者在 Obsidian 渲染视图会被隐藏，开发者会漏填
295	-- 每个【人工填写：...】必须带简短说明，让填写的人立刻知道这里要写什么（例如"【人工填写：JWT 签名密钥，256+ bit 随机串】"，不是"【人工填写】"）
296	-- 项目专属标识（Java 根包名 / C# 命名空间 / Python 顶层模块等）不要在本次引入新的【人工填写】，
297	- 统一引用 docs/07-环境配置.md 中已登记的占位（如在 07 里叫 `type-aliases-package`，本次生成 04 时也用该值引用）
298	-- 每插入一处新的【人工填写：...】标记，同步把它的位置登记到所在文件的「零、人工占位速查表」
299	- （04 没有零节，如果确需引入新占位，同步在 04 顶部新建一个与 07 同结构的零节；能复用 07 占位就不要新建）
300	-- 三份文件的文件头说明、节标题不要改，只填充表格行 / 章节内容
301	-
302	-四份可以连续生成，不用中间停下来确认。全部完成后统一输出：
303	- - 四份文件的绝对路径
304	- - 四份各自引入的【人工填写：...】标记总数
305	- - 07 / 09 占位速查表的最终行数（04 和测试闸门四件套若无新增占位则报"无"）
306	- - 生成过程中遇到的任何疑点
307	-
308	-然后停下等我一次性人工审核，之后进入 Step 3（配置运行环境）。不要触碰其他文件。
309	-```
310	-
311	-CC 会生成的内容参考：
312	-
313	-- 2a. `docs/07-环境配置.md` 骨架 —— 七节：基础环境 / 后端运行配置 / 前端构建配置 / 后端依赖 / 前端依赖 / 端口规划 / 启动命令
314	-- 2b. `docs/09-项目目录结构.md` 骨架 —— 四节：顶层结构 / 后端目录 / 前端目录 / 命名约定
315	-- 2c. `docs/04-技术规范.md` 骨架 —— 技术栈相关部分（一、后端规范 / 二、前端规范 / 4.6 认证实现），三节通用规范和 4.1–4.5 策略不动
316	-- 2d. 本地测试闸门三件套 + `.env.local.example` —— `scripts/setup-test-db.sh` + `scripts/test.sh` + `.githooks/pre-push` + `.env.local.example`；不生成 `docker-compose.test.yml`（本项目不用 Docker）；详见 3.3
317	-
318	-CC 不填任何敏感值，一律用 `【人工填写：...】` 标记（详见第二节「占位符统一约定」）。
319	-
320	-### Step 3 — 配置运行环境（人工）
321	-
322	-分别打开 `docs/07-环境配置.md` 和 `docs/09-项目目录结构.md` 顶部的「零、人工占位速查表」，按速查表逐行定位到正文里的 `【人工填写：...】` 标记，连同方括号一起替换为实际值。
323	-
324	-> 速查表的每一行由 Step 2 生成时自动登记，内容随所选技术栈而异（Java 栈里会有 Java 包名、JWT secret；.NET 栈里则可能是命名空间、appsettings.json 密钥等）。以你这份项目的速查表为准，不要参考其他项目的清单。
325	->
326	-> 是否填完由 Step 6 启动时 CC 自动搜索 `【人工填写：` 来核对。
327	-> 小版本号只写在此处；`CLAUDE.md` 技术栈表只锁大版本。两处重复必然漂移。
328	-
329	-### Step 4 — 建 schema 建表 + 配置 MCP（人工）
330	-
331	-本项目不使用 `sql/schema.sql` 文件；MySQL live DB 本身就是 schema 的唯一权威来源，CC 通过 MySQL MCP 查询获取。
332	-
333	-操作步骤：
334	-
335	-1. 在现有 MySQL 中建项目专用 schema（如 `erp_dev`，名字由你定；大版本需与 `CLAUDE.md` 技术栈表一致）
336	-2. 在该 schema 内建齐所有表：
337	- - 若是全新项目：人工手写 DDL 一次性建好
338	- - 若有参考库：`mysqldump --no-data <source> \| mysql <erp_dev>`
339	-3. 配置 CC 的 MCP 连接：在仓库根 `.mcp.json` 里填 `mcp_server_mysql` 的 host / port / user / password / database（指向项目 schema），账密用 `【人工填写：...】` 占位 + 实际值走环境变量
340	-4. 配置 `.env.local`：`cp .env.local.example .env.local` 填入 DB 连接与 schema 名
341	-5. 验证：跑 `./scripts/setup-test-db.sh` 能正常 truncate + reseed；CC 启动时能通过 MCP `SHOW TABLES` 查到所有表
342	-
343	-> ⚠️ CC 禁止 `CREATE / ALTER / DROP TABLE`（见 CLAUDE.md 红旗 #1 + #6）。schema 改动永远由人工在 MySQL 中直接执行。
344	->
345	-> ⚠️ DDL 文件请版本化管理（可另存库外，如团队知识库），但不要放 `sql/schema.sql`——那会被误当作 CC 的输入源。
346	-
347	-### Step 5 — 确定需求纲要（人工）
348	-
349	-在 `docs/01-需求清单/README.md` 中填写"模块 + 核心功能点"的 bullet 纲要。
350	-
351	-> ⚠️ 写之前先通过 MySQL MCP `SHOW TABLES` 看一遍库里有哪些表，确保每条需求在表里有落脚点。
352	-> ⚠️ 模块顺序不代表开发顺序——开发顺序由 CC 生成 `02` 时按技术依赖重排。
353	-
354	-示例：
355	-- 系统管理（SYS）：用户登录、用户 CRUD、角色权限、部门管理
356	-- 销售（SAL）：客户管理、报价单、销售订单、出库
357	-- 采购（PUR）：供应商管理、采购申请、采购订单、入库
358	-- ……（按业务实际增删模块）
359	-
360	-### Step 6 — 生成需求与数据库文档（CC）
361	-
362	-本步只生成需求卡（01）+ 数据库设计文档（03）。完成后停下等人工审核（可能需要修改），审核通过后再进入 Step 7 生成依赖它们的下游文档。
363	-
364	-对 CC 说（复制粘贴即可）：
365	-
366	-```
367	-请先读 CLAUDE.md（不需要读指南.md）。
368	-
369	-【第 0 步：占位核对】在生成任何 B 类文档前，先扫描 docs/07-环境配置.md、
370	-docs/09-项目目录结构.md 以及其他所有 A 类文档，匹配以下任一特征字符串视为未填：
371	- - "【人工填写：" （统一标记，详见 CLAUDE.md「🏷️ 占位符统一约定」）
372	- - "your_password" / "your-secret-key" （兜底：通用配置裸占位值）
373	- - 版本号仍为大版本占位（匹配形如 "N.x" 或 "N.N.x" 的正则，未锁定到具体小版本）
374	-
375	-如发现残留占位：停下来输出残留位置清单，等我补完 07 再重新触发本 prompt，不要进入下一步。
376	-如全部已替换：继续下面的生成流程。
377	-
378	-【生成流程：一次性生成两份文档，不用逐份停下等我确认，默认静默执行】
379	-
380	-1. 基于 docs/01-需求清单/README.md 的纲要，按模块逐个生成
381	- docs/01-需求清单/<模块缩写>-<模块名>.md（SYS / SAL / PUR / INV / …），
382	- 每个模块一个文件
383	-
384	-2. 通过 MySQL MCP 查 live DB（`SHOW TABLES` / `SHOW CREATE TABLE` / `INFORMATION_SCHEMA.COLUMNS`）填 docs/03-数据库设计文档.md 表结构业务说明
385	-
386	-全部生成完毕后【统一输出一份汇总】：
387	- - 每份文件的绝对路径
388	- - 每份的关键体量指标（01 每模块多少个功能 / 03 多少张表多少字段）
389	- - 生成过程中遇到的任何疑点（与 schema 对不上、纲要不够等）
390	-
391	-然后停下来等我做【一次性人工审核】。中途不要提问、不要等"下一份"；
392	-仅当出现以下阻塞时才中断并报告：
393	- - 需求纲要里提到的字段在 schema 中找不到
394	- - 需求本身出现无法自行消解的歧义
395	- - MySQL MCP 连接不可达（host 不通 / 账密错 / schema 为空表 0 张）
396	-
397	-严禁生成 02 / 05 / 08 / 10 / seed-data.sql——那是 Step 7 的范围，必须在 01 / 03 审核通过后才能动。
398	-```
399	-
400	-人工审核要点：
401	-- 01 需求卡是否覆盖纲要每一条 bullet？字段引用在 schema 里能否找到？
402	-- 03 表结构业务含义是否准确？ER 关系是否漏写？
403	-- 发现问题直接改文档，或让 CC 针对性重生成某模块 / 某表。审核通过后进入 Step 7。
404	-
405	----
406	-
407	-### Step 7 — 生成下游文档（CC）
408	-
409	-前置：Step 6 的 01 + 03 已通过人工审核。本步基于它们生成所有依赖文档。
410	-
411	-对 CC 说（复制粘贴即可）：
412	-
413	-```
414	-Step 6 的 01 + 03 已通过人工审核。请基于它们【一次性】生成下游文档，默认静默执行：
415	-
416	-1. 基于 01 + 03 生成 docs/02-开发计划.md
417	- —— 必须按技术依赖重排（先基础设施 / 认证 / 系统管理，再业务模块按依赖顺序），
418	- 不要沿用 01 的业务分组顺序
419	-
420	-2. 基于 01 + 03 生成 docs/05-API接口契约.md
421	-
422	-3. 与 02 对齐生成 docs/08-模块任务管理.md
423	-
424	-4. 基于 01 + 08 生成 docs/10-验收检查清单.md
425	-
426	-5. 基于 MCP 查到的 schema 扩充 sql/seed-data.sql
427	-
428	-全部生成完毕后【统一输出一份汇总】：
429	- - 每份文件的绝对路径
430	- - 每份的关键体量指标（02 多少模块 / 05 多少个 Endpoint / 08 多少 Task /
431	- 10 多少验收用例 / seed 多少行）
432	- - 生成过程中遇到的任何疑点
433	-
434	-然后停下来等我做【一次性人工审核】。中途不要提问。
435	-仅当出现以下阻塞时才中断并报告：
436	- - 01 / 03 中的需求/表在生成 02/05/08/10 时出现无法消解的歧义
437	- - MySQL MCP 连接不可达
438	-```
439	-
440	-### Step 8 — 确认 CC 理解（CC）
441	-
442	-全部文档就绪后，CC 需输出 6 节式确认报告。你回复"理解正确"后才能进入 Step 9。
443	-
444	-对 CC 说（复制粘贴即可）：
445	-
446	-```
447	-所有文档已生成完毕。请按依赖顺序完整读一遍（不要读指南.md）：
448	- CLAUDE.md →
449	- docs/01-需求清单/README.md → docs/01-需求清单/<各模块>.md →
450	- docs/02 → docs/03 → docs/04 → docs/05 → docs/06 →
451	- docs/07 → docs/08 → docs/09 → docs/10
452	-
453	-然后输出《理解确认报告》，严格 6 节：
454	-
455	-### 1. 项目目标理解（≤ 3 句话复述项目目标）
456	-### 2. 模块拆解理解（列出所有业务模块及其核心功能）
457	-### 3. 数据模型理解（核心实体之间的关系）
458	-### 4. 模块规划理解（模块 1 / 2 / …，每个模块做什么、依赖什么）
459	-### 5. 技术栈与约束理解（CLAUDE.md 技术栈表 + 认证 + 只读 schema 等约束）
460	-### 6. 风险与歧义清单（读文档过程中发现的矛盾、歧义、待确认项）
461	-
462	-报告输完停下，等我回复"理解正确"再做任何后续动作。
463	-```
464	-
465	-### Step 9 — 固化文档为 CC 参考（CC 一次性清理）
466	-
467	-Step 8 通过后，`docs/` 进入"事实只读"状态：人工不再手动改 docs，所有 docs 作为 CC 写代码时的纯参考。此步由 CC 一次性扫描并删除面向人工的流程 / 指引性内容，让文档只剩业务 / 技术事实。
468	-
469	-对 CC 说（复制粘贴即可）：
470	-
471	-```
472	-《理解确认报告》已通过我批准。现在进行一次性"文档固化"清理：把 docs/ 下所有文档
473	-转为"纯 CC 参考"状态。
474	-
475	-【不要动的文件】
476	- - docs/08-模块任务管理.md（人机协作控制中枢，CC 在每个模块末 MR 合入后改 confirmed）
477	- - 根目录指南.md（流程文档，本身就面向人）
478	- - 根目录 CLAUDE.md（保留顶部「项目概述」4 条即可，其他已是规范型内容可留）
479	-
480	-【其他所有 docs/.md、docs/01-需求清单/.md 执行删除规则】
481	-
482	-删除以下内容：
483	- 1. 文件头部"本文档由 Claude Code 在 Step X 自动生成…" / "初始状态：空模板…" 等
484	- 生命周期说明（CC 读过指南知道来源，无需每份文档重复）
485	- 2. 所有明确面向人工的操作指引 blockquote，例如：
486	- - "新增模块只需两步…"
487	- - "改名规则"
488	- - "填写方式" / "核对由 Step 6 CC 自动执行"
489	- - "⚠️ 写之前先…" / "⚠️ 顺序不代表开发顺序…"
490	- 3. 章节标题里的"（人工填写）" / "（CC 自动填）" / "（CC 参考）" 等人机角色标记，
491	- 只保留章节主标题
492	- 4. 「零、人工占位速查表」整节（此时占位已全部填完，索引表已失去用途）
493	- 5. 各节开头 "由 CC 在 Step X 基于 XX 生成" 一类节内生命周期引导 blockquote
494	- （章节内容已填妥，引导文字已完成使命）
495	- 6. "示例见 SYS-系统管理.md" / "示例见下" 等面向人的阅读引导
496	-
497	-【保留】
498	- - 所有实际业务 / 技术事实：功能卡片（REQ-XXX）、表结构、字段说明、ER 关系、API 契约、
499	- 模块规划、任务表、代码规范、依赖清单、目录结构、验收用例、seed 数据、配置值
500	- - 章节主标题（去掉括号里的角色标记）
501	- - 文档头 H1 标题
502	-
503	-【执行方式】
504	- - 先给我一份「清理前 vs 清理后」的预览 diff（每份文件列出将删除的段落摘要 + 行数变化）
505	- - 我确认"执行"后你再真正下手
506	- - 执行后再次输出每份文件的前后行数对比 + 分类删除统计
507	-
508	-执行完之后，docs/ 进入 Step 10（分模块开发）的只读参考态。
509	-```
510	-
511	----
512	-
513	-## 🏗️ 开发阶段（Step 10）：文档即 spec，CC 自主推进
514	-
515	-> 进入本阶段时，`docs/` 已固化为只读参考态（Step 9 已清理），所有业务 / 技术事实都在文档里。
516	-> 功能循环（Brainstorm → Plan → TDD → Verify → AI 自审）默认静默，CC 遇到不确定性只在命中 🚩 红旗清单时才打断人工。
517	-> 人工在本阶段的唯一介入点是模块末 review MR（一个模块一次）。
518	-> 如果此阶段 CC 频繁打断问问题，说明计划阶段文档打磨得不够，应回头补文档（必要时 Step 6/7 重生成 + 人工审核）而不是让开发"边开发边定义"。
519	-
520	-### Step 10 — 分模块开发（模块循环 + 功能循环）
521	-
522	-> 术语提示
523	-> - 模块 = 一组紧密相关、能整体交付的功能集合，对应 `docs/02-开发计划.md` 里的一个模块。模块循环就是开发一个模块。
524	-> - 功能 = 一条具体的功能需求，编号格式 `REQ-<模块缩写>-<三位序号>`（如 `REQ-SYS-001` 用户登录）。功能循环就是开发一个功能。
525	-> - confirmed = 模块完成确认标记，详见 3.1。
526	-
527	-启动新模块时对 CC 说（复制粘贴即可）：
528	-
529	-```
530	-请按 CLAUDE.md「🔄 模块循环 + 功能循环」开发下一个模块。
531	-
532	-1. 打开 docs/08-模块任务管理.md，找到第一个 confirmed: false 的模块
533	-2. 对该模块内每个功能（REQ-XXX）依次跑功能循环 5 步：
534	- Brainstorm → Plan → TDD → Verify → AI 自审
535	- 所有产物归档到 docs/superpowers/{specs,plans,reviews}/YYYY-MM-DD-<REQ-id>.md
536	-3. 命中 CLAUDE.md「🚩 静默执行红旗清单」任一条 → 立即停下、写 🚩 Blocker 节、一句话告警
537	-4. 该模块全部功能完成后产出《模块完成报告》审阅包：
538	- - 每个功能的 spec + plan + diff
539	- - 每个功能的 AI reviewer 报告
540	- - 测试总数 / 通过率 / 覆盖率 / `scripts/test.sh` 最后一次输出结尾
541	- - schema 改动清单（应为 0）
542	- - 偏离 spec 清单
543	-5. `scripts/test.sh` 本地全绿后，自动 `git push` + `glab mr create`，把审阅包贴入 MR 描述，输出 MR 链接后停下等人工审核。
544	- 此时严禁改 `confirmed`——必须等人工 Approve + Merge 后才能改（见步骤 6）。
545	-
546	-默认静默执行。除红旗场景外，不要向我提问或确认。
547	-```
548	-
549	-模块末人工 review 通过后对 CC 说（复制粘贴即可）：
550	-
551	-```
552	-MR 已 Approve + Merge。请：
553	-1. 用 glab mr view <mr-iid> 验证 MR 状态为 merged
554	-2. 验证通过后，把 docs/08-模块任务管理.md 里当前模块的 confirmed 改为 true（commit 消息格式：chore(module): confirm module_N as completed）
555	-3. 基于指南开始下一个模块（重复上面的启动 prompt）
556	-
557	-若 glab mr view 显示未 merged（opened / closed），立即停下告警，不要改 confirmed。
558	-```
559	-
560	----
561	-
562	-流程详解：
563	-
564	-每个模块走一次模块循环，模块内每个功能（REQ-XXX）走一次功能循环。
565	-
566	-模块循环：
567	-
568	-```
569	-找 docs/08 中第一个 confirmed: false 的模块
570	- ↓
571	-对模块内每个功能（REQ-XXX）依次跑功能循环（CC 静默执行，不打扰人）
572	- ↓
573	-CC 输出《模块完成报告》，打包附件（见下方"审阅包"）
574	- ↓
575	-自动化闸门：本地 `./scripts/test.sh` 全绿（见 3.3）
576	- ↓
577	-CC 自动 `git push` + `glab mr create`（审阅包贴入 MR 描述）
578	- ↓
579	-人工审核 MR（一个模块唯一一次人工介入点）
580	- ↓
581	-全部通过 → 你点 Approve + Merge
582	- ↓
583	-你对 CC 说"MR 已合入" → CC 验证 merged 状态 → CC 把 `confirmed` 改为 true → 进入下一个模块
584	-```
585	-
586	-《模块完成报告》审阅包必须包含：
587	-
588	-- 本模块所有功能的 spec、plan、diff（`git diff <module-start>..HEAD`）
589	-- 每个功能的 AI reviewer 报告（`docs/superpowers/reviews/`）
590	-- 测试结果：总用例数、通过率、覆盖率、`scripts/test.sh` 最后一次运行输出结尾（证据）
591	-- schema 改动清单（应为 0，若非 0 必须额外解释）
592	-- 偏离 spec 清单（实现中与 spec 不一致的地方，一处都不能漏报）
593	-
594	-功能循环（单个功能 REQ-XXX 级）— 静默执行，无人工打断：
595	-
596	-```
597	-1. Brainstorm （可调用 superpowers:brainstorming）
598	- 产出：≤ 1 页 spec，写入 docs/superpowers/specs/YYYY-MM-DD-<REQ-id>.md
599	- 内容：目标 / 接口 / 数据流 / 边界条件 / 测试标准
600	-
601	-2. Plan （可调用 superpowers:writing-plans）
602	- 产出：Task 级步骤，每步 2–5 分钟，含文件路径与完整代码
603	- 写入 docs/superpowers/plans/YYYY-MM-DD-<REQ-id>.md
604	-
605	-3. TDD 执行（可调用 superpowers:test-driven-development）
606	- 写失败测试 → 跑 → 实现最小代码 → 测试通过 → 提交
607	- 频繁小提交，每个 task 一个 commit
608	-
609	-4. Verify （可调用 superpowers:verification-before-completion）
610	- 声称"完成"前，必须贴出 mvn test / pnpm test 的实际输出
611	-
612	-5. AI 自审（superpowers:code-reviewer 子代理，强制）
613	- 产出：审查报告写入 docs/superpowers/reviews/YYYY-MM-DD-<REQ-id>.md
614	- CC 自行修复 reviewer 发现的问题，直到 reviewer 通过
615	-```
616	-
617	-> 人工 review 不在此发生，移到模块末统一进行（模块循环倒数第 2 步）。

agents/superpower-code-reviewer.md 0 → 100644

View file @e69a699

		1	+---
		2	+name: superpower-code-reviewer
		3	+description: \|
		4	+ Use this agent when a major project step has been completed and needs to be reviewed against the original plan and coding standards. Examples: <example>Context: The user is creating a code-review agent that should be called after a logical chunk of code is written. user: "I've finished implementing the user authentication system as outlined in step 3 of our plan" assistant: "Great work! Now let me use the code-reviewer agent to review the implementation against our plan and coding standards" <commentary>Since a major project step has been completed, use the code-reviewer agent to validate the work against the plan and identify any issues.</commentary></example> <example>Context: User has completed a significant feature implementation. user: "The API endpoints for the task management system are now complete - that covers step 2 from our architecture document" assistant: "Excellent! Let me have the code-reviewer agent examine this implementation to ensure it aligns with our plan and follows best practices" <commentary>A numbered step from the planning document has been completed, so the code-reviewer agent should review the work.</commentary></example>
		5	+model: inherit
		6	+---
		7	+
		8	+You are a Senior Code Reviewer with expertise in software architecture, design patterns, and best practices. Your role is to review completed project steps against original plans and ensure code quality standards are met.
		9	+
		10	+When reviewing completed work, you will:
		11	+
		12	+1. Plan Alignment Analysis:
		13	+ - Compare the implementation against the original planning document or step description
		14	+ - Identify any deviations from the planned approach, architecture, or requirements
		15	+ - Assess whether deviations are justified improvements or problematic departures
		16	+ - Verify that all planned functionality has been implemented
		17	+
		18	+2. Code Quality Assessment:
		19	+ - Review code for adherence to established patterns and conventions
		20	+ - Check for proper error handling, type safety, and defensive programming
		21	+ - Evaluate code organization, naming conventions, and maintainability
		22	+ - Assess test coverage and quality of test implementations
		23	+ - Look for potential security vulnerabilities or performance issues
		24	+
		25	+3. Architecture and Design Review:
		26	+ - Ensure the implementation follows SOLID principles and established architectural patterns
		27	+ - Check for proper separation of concerns and loose coupling
		28	+ - Verify that the code integrates well with existing systems
		29	+ - Assess scalability and extensibility considerations
		30	+
		31	+4. Documentation and Standards:
		32	+ - Verify that code includes appropriate comments and documentation
		33	+ - Check that file headers, function documentation, and inline comments are present and accurate
		34	+ - Ensure adherence to project-specific coding standards and conventions
		35	+
		36	+5. Issue Identification and Recommendations:
		37	+ - Clearly categorize issues as: Critical (must fix), Important (should fix), or Suggestions (nice to have)
		38	+ - For each issue, provide specific examples and actionable recommendations
		39	+ - When you identify plan deviations, explain whether they're problematic or beneficial
		40	+ - Suggest specific improvements with code examples when helpful
		41	+
		42	+6. Communication Protocol:
		43	+ - If you find significant deviations from the plan, ask the coding agent to review and confirm the changes
		44	+ - If you identify issues with the original plan itself, recommend plan updates
		45	+ - For implementation problems, provide clear guidance on fixes needed
		46	+ - Always acknowledge what was done well before highlighting issues
		47	+
		48	+Your output should be structured, actionable, and focused on helping maintain high code quality while ensuring project goals are met. Be thorough but concise, and always provide constructive feedback that helps improve both the current implementation and future development practices.

skills/internal/superpower-brainstorming/SKILL.md 0 → 100644

View file @e69a699

		1	+---
		2	+name: superpower-brainstorming
		3	+description: Internal fork of superpowers:brainstorming with approval gates stripped. Use when a parent skill needs structured Q&A + design + spec doc, without user "approve design / review spec" wait points.
		4	+user-invocable: false
		5	+---
		6	+
		7	+# Brainstorming Ideas Into Designs (Internal, Gate-Free)
		8	+
		9	+Help turn ideas into fully formed designs and specs through natural collaborative dialogue. This is an internal fork of `superpowers:brainstorming`: `<HARD-GATE>`, "approve design", "review spec", and Visual Companion have been removed so the flow can run without user-facing confirmation breaks. QA (AskUserQuestion) is still used freely for genuine ambiguity.
		10	+
		11	+Caller contract: the parent skill passes in (or this skill derives) a spec output path. Once the spec file is written and self-reviewed, control returns to the caller. This skill does NOT chain to any next skill itself.
		12	+
		13	+No human-fill markers in output. The spec you write is CC's internal reasoning artifact, not a user-review doc. Do NOT emit `【人工填写：...】` style placeholders — that convention belongs to A-phase docs (`docs/01~10`, `CLAUDE.md`, `.env.local`), not B-phase specs/plans. When a concrete value is needed:
		14	+
		15	+1. Look up first — check `.env.local`, `docs/07-环境配置.md`, `CLAUDE.md`, existing code. If the value is already resolved somewhere, cite that source in the spec (e.g., "JWT_SECRET 从 `.env.local` 读取，`application.yml` 用 `${JWT_SECRET}` 注入")
		16	+2. Ask via `AskUserQuestion` second — if no source exists, ask the user directly; record their answer in the spec
		17	+3. Never leave a 【人工填写：】 placeholder — if step 1 + 2 somehow can't resolve it, the spec must name the exact blocker (not a generic human-fill marker), and Q&A keeps going until it's resolved
		18	+
		19	+## Checklist
		20	+
		21	+Complete in order:
		22	+
		23	+1. Explore project context — check files, docs, recent commits relevant to the topic
		24	+2. Ask clarifying questions — one at a time, only for genuine ambiguity; understand purpose / constraints / success criteria
		25	+3. Pick an approach — if multiple viable approaches exist, briefly weigh trade-offs and pick the best; surface the choice only if the user's answer to a prior Q&A did not already decide it
		26	+4. Write design doc — save to the path provided by the caller (default `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` if none)
		27	+5. Spec self-review — inline check for placeholders, contradictions, ambiguity, scope; fix inline
		28	+6. Return control to caller — no further chaining
		29	+
		30	+## Process Flow
		31	+
		32	+```dot
		33	+digraph brainstorming {
		34	+ "Explore project context" [shape=box];
		35	+ "Ask clarifying questions\n(one at a time)" [shape=box];
		36	+ "Pick approach\n(weigh trade-offs only if needed)" [shape=box];
		37	+ "Write design doc" [shape=box];
		38	+ "Spec self-review\n(fix inline)" [shape=box];
		39	+ "Return to caller" [shape=doublecircle];
		40	+
		41	+ "Explore project context" -> "Ask clarifying questions\n(one at a time)";
		42	+ "Ask clarifying questions\n(one at a time)" -> "Pick approach\n(weigh trade-offs only if needed)";
		43	+ "Pick approach\n(weigh trade-offs only if needed)" -> "Write design doc";
		44	+ "Write design doc" -> "Spec self-review\n(fix inline)";
		45	+ "Spec self-review\n(fix inline)" -> "Return to caller";
		46	+}
		47	+```
		48	+
		49	+## The Process
		50	+
		51	+Understanding the idea:
		52	+
		53	+- Check current project state first (files, docs, recent commits)
		54	+- Before asking detailed questions, assess scope: if the request describes multiple independent subsystems (e.g., "build a platform with chat, file storage, billing, and analytics"), surface this immediately. Don't spend questions refining details of a project that needs to be decomposed first.
		55	+- If the project is too large for a single spec, help decompose: what are the independent pieces, how do they relate, what order to build? Then brainstorm the first sub-project through the normal design flow.
		56	+- For appropriately-scoped projects, ask questions one at a time
		57	+- Prefer multiple choice questions when possible, but open-ended is fine too
		58	+- Only one question per message
		59	+- Focus on understanding: purpose, constraints, success criteria
		60	+
		61	+Approach selection:
		62	+
		63	+- If there is a single obvious approach driven by the Q&A answers, just use it
		64	+- If trade-offs remain, briefly state 2-3 approaches + your recommendation inline in the spec (not as a confirmation gate)
		65	+
		66	+Design for isolation and clarity:
		67	+
		68	+- Break the system into smaller units that each have one clear purpose, communicate through well-defined interfaces, and can be understood and tested independently
		69	+- For each unit you should be able to answer: what does it do, how do you use it, what does it depend on
		70	+- Smaller, well-bounded units are easier to reason about and test; large files are a signal of doing too much
		71	+
		72	+Working in existing codebases:
		73	+
		74	+- Explore the current structure before proposing changes. Follow existing patterns.
		75	+- Where existing code has problems that affect the work (e.g., a file that's grown too large, unclear boundaries, tangled responsibilities), include targeted improvements as part of the design — the way a good developer improves code they're working in.
		76	+- Don't propose unrelated refactoring. Stay focused on what serves the current goal.
		77	+
		78	+## After Q&A
		79	+
		80	+Write the design doc:
		81	+
		82	+- Write the validated design (spec) to the caller-provided path (default `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`)
		83	+- Cover: goal, inputs/outputs, rules, constraints, schema/API refs, acceptance criteria — or match the template the caller expects
		84	+
		85	+Spec self-review (no user wait):
		86	+
		87	+1. Placeholder scan: any "TBD", "TODO", "【人工填写：...】", incomplete sections, vague requirements? Fix them — either resolve via file lookup, raise a `AskUserQuestion`, or rewrite the passage to be concrete.
		88	+2. Internal consistency: do any sections contradict? Does architecture match feature descriptions?
		89	+3. Scope check: focused enough for a single implementation plan, or needs decomposition?
		90	+4. Ambiguity check: could any requirement be interpreted two ways? Pick one, make it explicit.
		91	+
		92	+Fix inline. No re-review — just fix and move on.
		93	+
		94	+Terminal state:
		95	+
		96	+Return control to the caller. Do not invoke writing-plans, frontend-design, or any other skill from here.
		97	+
		98	+## Key Principles
		99	+
		100	+- One question at a time — don't overwhelm
		101	+- Multiple choice preferred — easier to answer
		102	+- QA for ambiguity only — don't fabricate confirmation questions
		103	+- YAGNI ruthlessly — remove unnecessary features from designs
		104	+- Incremental understanding — clarify when something doesn't make sense
		105	+- No approval gates — writing the spec is the commit; any disagreement surfaces as a concrete Q&A item

skills/internal/superpower-writing-plans/SKILL.md 0 → 100644

View file @e69a699

		1	+---
		2	+name: superpower-writing-plans
		3	+description: Internal fork of superpowers:writing-plans with the "Which execution approach?" handoff gate stripped. Use when a parent skill needs a bite-sized, TDD-ready implementation plan written to disk without user-facing confirmation breaks.
		4	+user-invocable: false
		5	+---
		6	+
		7	+# Writing Plans (Internal, Gate-Free)
		8	+
		9	+Write task-level implementation plans that tell the TDD executor what to do, not how to write the code. The executor is `erp-feature-tdd` (Claude itself with full context), not a mechanical copy-paster — so the plan captures file boundaries, test intent, API shapes and completion criteria, and lets the executor produce the actual code in the red-green cycle. DRY. YAGNI. TDD. Frequent commits.
		10	+
		11	+Do NOT dump full file contents (pom.xml, entity classes, config files) into the plan. The plan and the code end up as two sources of truth that drift; 2000+ line plans also waste context. Code is produced during TDD, not pre-written here.
		12	+
		13	+Caller contract: the parent skill passes in (or this skill derives) a plan output path and a spec file path. Once the plan is written and self-reviewed, control returns to the caller. This skill does NOT ask the user to choose an execution mode; the caller decides.
		14	+
		15	+Save plans to: the caller-provided path (default `docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md`).
		16	+
		17	+## Scope Check
		18	+
		19	+If the spec covers multiple independent subsystems, it should have been broken into sub-project specs during brainstorming. If it wasn't, surface this to the caller — suggest breaking into separate plans, one per subsystem. Each plan should produce working, testable software on its own.
		20	+
		21	+## File Structure
		22	+
		23	+Before defining tasks, map out which files will be created or modified and what each one is responsible for. This is where decomposition decisions get locked in.
		24	+
		25	+- Design units with clear boundaries and well-defined interfaces. Each file should have one clear responsibility.
		26	+- Files that change together should live together. Split by responsibility, not by technical layer.
		27	+- In existing codebases, follow established patterns. Don't unilaterally restructure — but if a file you're modifying has grown unwieldy, including a split in the plan is reasonable.
		28	+
		29	+This structure informs the task decomposition. Each task should produce self-contained changes that make sense independently.
		30	+
		31	+## Bite-Sized Task Granularity
		32	+
		33	+Each step is one action (2-5 minutes):
		34	+- "Write the failing test" — step
		35	+- "Run it to make sure it fails" — step
		36	+- "Implement the minimal code to make the test pass" — step
		37	+- "Run the tests and make sure they pass" — step
		38	+- "Commit" — step
		39	+
		40	+## Plan Document Header
		41	+
		42	+Every plan MUST start with this header:
		43	+
		44	+```markdown
		45	+# [Feature Name] Implementation Plan
		46	+
		47	+> Execution: Parent skill `erp-feature-tdd` executes this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
		48	+
		49	+Goal: [One sentence describing what this builds]
		50	+
		51	+Architecture: [2-3 sentences about approach]
		52	+
		53	+Tech Stack: [Key technologies/libraries]
		54	+
		55	+---
		56	+```
		57	+
		58	+## Task Structure
		59	+
		60	+Each task is a unit of red-green-commit. Capture intent and boundaries — leave code to TDD.
		61	+
		62	+````markdown
		63	+### Task N: [Component Name]
		64	+
		65	+Files:
		66	+- Create: `exact/path/to/File.java`
		67	+- Modify: `exact/path/to/Existing.java:123-145`
		68	+- Test: `tests/exact/path/to/FileTest.java`
		69	+
		70	+API shape (只写需要约束实现的签名；内部实现留给 TDD):
		71	+- `LoginService#login(LoginRequest req) : LoginResponse`
		72	+- `throws AccountLockedException when iLoginFailCount ≥ 5 within tLockUntil window`
		73	+
		74	+- [ ] Step 1: 写失败测试
		75	+ - 测试名: `LoginServiceTest#loginWithBadPassword_incrementsFailCount_returns40101`
		76	+ - 意图: 错误密码 → `iLoginFailCount += 1`；第 5 次 → 设置 `tLockUntil = now + 15min`；返回码 40101
		77	+ - 子会话确认 FAIL（函数/类不存在）
		78	+
		79	+- [ ] Step 2: 实现最小代码
		80	+ - 目标: 让 Step 1 测试通过；不多做
		81	+ - 涉及文件: `LoginService.java`, `SftLoginInfoMapper.java`
		82	+
		83	+- [ ] Step 3: 子会话验证 PASS
		84	+
		85	+- [ ] Step 4: Commit
		86	+ - `git add <文件>`
		87	+ - `git commit -m "feat(sys): 登录失败计数 + 锁定 REQ-SYS-001"`
		88	+````
		89	+
		90	+允许的代码块场景（少数例外，需要写死而非让 TDD 自由发挥的内容）：
		91	+
		92	+- DDL / migration 文件：`V_n__*.sql` 的 ALTER/CREATE 语句——因为 schema 是事实源、不是 TDD 的"红绿"产物
		93	+- 合同级常量：API 错误码表、JWT claim 名、Redis key 模式——这些跨模块被消费，必须在 plan 锁定
		94	+- 测试的断言形状（可选）：如果一句话说不清"测什么"，给个 3-5 行断言 sketch 是 OK 的
		95	+
		96	+除此之外一律用散文+签名描述，不贴完整文件。
		97	+
		98	+## No Placeholders
		99	+
		100	+Every step must contain the actual content an engineer needs. These are plan failures — never write them:
		101	+- "TBD", "TODO", "implement later", "fill in details"
		102	+- `【人工填写：...】` — this marker is A-phase only (`docs/01~10`, `CLAUDE.md`, `.env.local`). It must NEVER appear in B-phase plans. If you need a concrete value: (a) look it up in `.env.local` / `docs/07` / `CLAUDE.md` / existing code and cite the source in the plan, or (b) ask the user via `AskUserQuestion` and record the answer. The plan is CC's executable artifact, not a user-review doc.
		103	+- "Add appropriate error handling" / "add validation" / "handle edge cases"（具体到哪些错误码 / 哪些字段）
		104	+- "Similar to Task N"（相似任务各自写清楚测试意图 + 完成判据，不互相链接）
		105	+- References to types, functions, or methods not defined in any task（类/方法首次出现的 task 要给出 API 签名）
		106	+
		107	+> 散文级"做什么"是 OK 的——执行器（erp-feature-tdd）会在 TDD 循环里决定"怎么写"。plan 的义务是约束范围，不是替 TDD 写代码。
		108	+
		109	+## Remember
		110	+
		111	+- Exact file paths always
		112	+- Exact commands with expected output (for test runs and git ops)
		113	+- API signatures / class names / error codes / contract values — 必须写死
		114	+- Internal implementation code — 不写；留给 TDD 阶段
		115	+- DRY, YAGNI, TDD, frequent commits
		116	+
		117	+## Self-Review
		118	+
		119	+After writing the complete plan, look at the spec with fresh eyes and check the plan against it. This is a checklist you run yourself — not a subagent dispatch, not a user approval gate.
		120	+
		121	+1. Spec coverage: Skim each section/requirement in the spec. Can you point to a task that implements it? List any gaps.
		122	+
		123	+2. Placeholder scan: Search your plan for red flags — any of the patterns from the "No Placeholders" section above (including `【人工填写：...】`). Fix them: resolve by file lookup, raise a `AskUserQuestion`, or rewrite the step to be concrete.
		124	+
		125	+3. Type consistency: Do the types, method signatures, and property names you used in later tasks match what you defined in earlier tasks? A function called `clearLayers()` in Task 3 but `clearFullLayers()` in Task 7 is a bug.
		126	+
		127	+If you find issues, fix them inline. No re-review — just fix and move on. If you find a spec requirement with no task, add the task.
		128	+
		129	+## Terminal State
		130	+
		131	+Once the plan file is written and self-reviewed, return control to the caller. Do NOT ask the user to pick an execution approach; the caller decides how to execute.

skills/plan/erp-db-init/templates/migration-v1-header-template.sql 0 → 100644

View file @e69a699

		1	+-- Flyway migration V1 — initial schema for {{project_name}}
		2	+-- Generated: {{timestamp}}
		3	+-- Source: mysqldump --no-data {{schema_name}}
		4	+-- This is the FIRST migration; subsequent schema changes must be written
		5	+-- as new files sql/migrations/V2__<desc>.sql, V3__..., etc.
		6	+-- Apply: Flyway runs this automatically at Spring Boot startup.
		7	+-- Do not hand-edit this file after it is committed; write a new migration instead.
		8	+-- =========================================================

skills/plan/erp-db-init/templates/seed-data-sql-template.sql 0 → 100644

View file @e69a699

		1	+-- sql/seed-data.sql — 初始测试数据（INSERT only，无 DDL）
		2	+-- Project: {{project_name}}
		3	+-- Generated: {{timestamp}}
		4	+-- Source: mysqldump --no-create-info --complete-insert {{schema_name}}
		5	+-- 由 A3 erp-db-init 从本地 MySQL 导出；本地即是测试数据集。
		6	+-- 装载方式由开发者选：
		7	+-- (a) Spring Boot 测试基类 @Sql(scripts = "file:sql/seed-data.sql")
		8	+-- (b) 改名 R__seed_data.sql 放到 sql/migrations/（Flyway repeatable）
		9	+-- (c) classpath:data.sql（Spring Boot 启动自动应用）
		10	+-- ==========================================================

1	-## 🚩 Blocker
2	-
3	-红旗编号: {{flag_number}} (1-6，对应 CLAUDE.md 🚩 静默执行红旗清单)
4	-红旗名称: {{flag_name}}
5	-问题描述: {{description}}
6	-影响范围: {{affected_scope}}
7	-我的建议: {{recommendation}}
8	-等待决策: {{decision_needed}}