---
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 都属于写入操作，必须在当前请求中获得明确授权，并单独记录目标环境和执行结果。