Files
shz-backend/.codex/skills/shz-full-development/SKILL.md

78 lines
6.3 KiB
Markdown
Raw Normal View History

---
name: shz-full-development
description: 仅当用户在当前请求中明确授权完成 SHZ 全流程开发时使用。支持代码实现、本地验证、测试环境 SQL 执行、测试环境部署、Chrome DevTools/日志/只读数据库调试、功能验收、代码提交以及测试通过后的正式 SQL 生成和执行状态记录。没有当前请求中的明确全流程授权时,不得使用此 skill 执行提交、写入 SQL、远程部署或服务重启。
---
# SHZ 全流程开发
## 授权门槛
只有当用户在**当前请求**中明确要求完成全流程开发,并明确允许相应远程操作时,才能使用此 skill。以下表述才算明确授权允许提交代码、执行测试环境 SQL、部署测试环境、调试验证或明确要求执行完整开发流程。
以下表述不构成全流程授权:修复问题、完成开发、测试一下、准备上线、给出部署命令、描述 SQL、验证修复或“继续处理”。没有明确授权时使用 `$shz-pc-debug``$query-shz-highgo``$inspect-shz-logs` 完成只读诊断、本地修改和验证。
授权范围必须逐项确认:
- 代码修改:允许修改哪些仓库和模块;
- 测试 SQL允许在测试环境写入哪些数据库和 SQL 文件;
- 测试部署允许部署后端、PC 前端或两者;
- 测试调试:允许使用哪个测试角色和页面;
- 正式 SQL是否只生成正式 SQL还是额外允许执行正式环境 SQL。
正式环境 SQL 执行和生产部署不从“全流程开发”自动推断。它们必须有当前请求中的单独明确授权,并且必须提供目标和精确执行命令或批准的项目流程。
## 硬性安全规则
1. 默认使用测试环境,生产环境保持只读。
2. 不得读取、复制、打印、提交或报告密码、Token、cookies、授权请求头或无关个人数据。
3. 远程写入操作必须使用项目已有的受保护流程,不得临时拼接绕过安全检查的 SSH、psql 或部署命令。
4. 每个远程操作前确认目标环境、目标组件、SQL 文件、角色和授权范围。
5. 任一 SQL、构建、部署或功能验证失败时立即停止后续晋级不得生成“已通过”或“已执行”的状态标记。
6. 不得把测试环境执行成功推断为正式环境执行成功。
7. 不得把正式 SQL 已生成推断为正式 SQL 已执行。
## 全流程顺序
严格按以下顺序执行:
1. **确认范围和授权**:确认角色、环境、页面/接口、代码仓库、SQL 文件、目标组件和允许的远程操作。阅读 [references/deployment.md](references/deployment.md) 和 [references/sql-workflow.md](references/sql-workflow.md)。
2. **检查工作区**:分别检查 `shz-backend` 和涉及的 `shz-admin` 工作树、`git status` 和 diff保留用户已有改动。按 [shz-pc-debug 的项目结构参考](../shz-pc-debug/references/project-topology.md) 选择最小范围。
3. **调查和实现**:使用 CodeGraph 定位代码;没有可用索引时使用 `rg`。按需调用 `$shz-pc-debug` 复现和定位、`$query-shz-highgo` 查询只读数据、`$inspect-shz-logs` 检查日志。实施最小代码修改。
4. **本地验证**运行变更模块适用的测试、构建、类型检查、lint 或其他静态检查。未通过时先修复,不得执行远程写操作。
5. **测试 SQL 执行**:按照 [references/sql-workflow.md](references/sql-workflow.md) 检查 SQL、记录执行目标并且只在测试环境执行。成功后将 SQL 文件标记为测试已执行,但不得标记为正式已执行。
6. **中文代码提交**:本地代码和测试 SQL 验证通过后,检查 diff使用中文提交信息创建聚焦 commit。提交规则见“代码提交规则”。除非用户明确要求 push否则不得推送。
7. **部署测试环境**:只部署当前请求明确授权的组件。部署命令和授权条件见 [references/deployment.md](references/deployment.md)。
8. **测试环境调试和验收**:使用隔离 Chrome 会话复现目标流程,检查 DOM、控制台、网络、截图、日志和必要的只读数据库状态。测试失败时停止不得生成正式 SQL。
9. **生成正式 SQL**:只有当所有约定功能和回归检查通过后,才从已测试 SQL 生成正式执行 SQL并按 [references/sql-workflow.md](references/sql-workflow.md) 更新内容和文件名。此时只能标记为 `test-verified-production-ready`,不能标记为正式已执行。
10. **正式环境 SQL可选**:只有当前请求单独明确授权正式 SQL 执行时,才执行正式环境 SQL。执行成功后更新 SQL 状态注释和文件名为 `test-and-production-executed`。未获授权时保留正式 SQL 供人工审批,不得执行。
11. **最终报告**:报告测试环境、提交 hash、测试 SQL 执行结果、部署组件、浏览器验证结果、正式 SQL 文件状态以及未执行的正式环境操作。
## 代码提交规则
代码提交必须使用中文。提交前检查以下要求:
- commit subject 的实际说明必须是中文;
- commit body如有必须使用中文
- 可以保留 `feat:``fix:``refactor:``chore:` 等固定类型前缀,但冒号后的说明必须是中文;
- 禁止使用纯英文提交信息;
- 每次提交只包含当前任务相关文件不得提交密码、Token、日志、截图、临时构建产物或无关改动
- 未经用户明确要求不得 push。
推荐格式:
```text
feat: 新增户外招聘会小程序二维码接口
fix: 修复企业招聘会图片地址处理
chore: 更新测试环境迁移状态
```
## 失败和回滚处理
- 本地验证失败:不执行测试 SQL、不提交、不部署。
- 测试 SQL 失败:停止部署,保留失败证据;只有修复 SQL 并重新通过测试执行后,才更新 SQL 状态。
- 测试部署失败:检查有界测试日志,修复并重新本地验证;不得生成正式 SQL。
- 浏览器功能验证失败保留控制台、网络、DOM、截图和日志证据不得标记为 `test-verified-production-ready`
- 正式 SQL 执行失败:立即停止,不得标记 `test-and-production-executed`;保留正式环境错误证据并等待用户决定回滚或修复。
任何回滚或反向 SQL 都属于写入操作,必须在当前请求中获得明确授权,并单独记录目标环境和执行结果。