chore: 文档与 IDE 配置整理

- .kiro/specs/ → docs/specs/（41 个历史需求 spec 迁移，移除 .config.kiro）
- CLAUDE.md 三层拆分：根文件精简 + apps/backend/CLAUDE.md + .claude/commands/
- 新增 /spec-close、/pre-change 两个工作流命令
- DDL 基线刷新（从测试库重新导出 11 个文件，dws 35→38 表，biz 18→21 表）
- BD_Manual → BD_manual 命名统一（48 个文件）
- 修复 3 处文档与数据库不一致（auth.users.status 默认值、scheduled_tasks 字段、RLS 视图数）
- 新增 BD_manual_public_rbac_tables.md（public schema 8 张 RBAC/工作流表）
- 合并 biz.trigger_jobs 文档（10→12 字段，归档独立文档）
- docs/database/README.md 索引更新

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

.claude/commands/pre-change.md

@@ -0,0 +1,65 @@
+# /pre-change — 逻辑改动前置调研
+
+对即将修改的模块进行全面调研，输出上下文摘要供用户确认后再动手。
+
+## 适用场景
+
+任何逻辑改动（ETL/业务规则/API/数据模型/前端交互），写代码前执行。
+
+## 执行步骤
+
+### 第 1 步：识别改动范围
+
+从用户需求中提取：
+- 要修改的模块和文件
+- 涉及的数据表/API/页面
+- 预期的行为变化
+
+### 第 2 步：委托 Explore 子代理调研
+
+启动 Explore 子代理（thoroughness: very thorough），调研以下内容：
+
+1. **目标模块文件**：读取要修改的文件及其直接依赖
+2. **历史审计**：搜索 `docs/audit/changes/` 中相关模块的历史变更记录
+3. **相关文档**：README、PRD（`docs/prd/`）、BD 手册（`docs/database/`）、API 参考
+4. **调用关系**：要修改文件的调用方和被调用方
+5. **数据流向**：上游（数据从哪来）→ 当前模块 → 下游（数据到哪去）
+6. **影响范围**：哪些模块/页面/任务可能受影响
+
+### 第 3 步：输出「改动前上下文摘要」
+
+格式：
+
+```
+## 改动前上下文摘要
+
+### 模块职责
+<模块做什么，在系统中的角色>
+
+### 历史变更
+<近期审计记录中的相关改动，特别是踩坑记录>
+
+### 数据流向
+上游: <数据来源>
+当前: <本模块处理>
+下游: <消费方>
+
+### 影响范围
+- <受影响的模块/页面/任务列表>
+
+### 风险点
+- <可能的副作用、边界条件、兼容性问题>
+
+### 建议方案
+<基于调研结果的实施建议>
+```
+
+### 第 4 步：等待用户确认
+
+输出摘要后，等待用户确认或调整方向，确认后再进入编码实施。
+
+## 例外（无需执行此流程）
+
+- 纯格式调整、注释/文档纯文字修改
+- 用户明确说"直接改/跳过调研"
+- 新建文件且不涉及已有逻辑

.claude/commands/spec-close.md

@@ -0,0 +1,63 @@
+# /spec-close — Spec 收尾通用流程
+
+当一个功能 spec 开发完成时，执行此收尾检查清单确保质量闭环。
+
+## 执行步骤
+
+### 步骤 1：最终测试检查点（必选）
+
+- 运行 Monorepo 属性测试：`cd /c/NeoZQYY && pytest tests/ -v`
+- 运行模块单元测试：`cd <模块路径> && pytest tests/ -v`
+- 确保所有测试通过，有问题询问用户
+
+### 步骤 2：前后端联调验证（涉及 API + 前端时必选）
+
+- 启动后端服务，使用测试库验证各端点完整请求-响应链路
+- 验证 JSON 响应结构与 Schema 定义一致（camelCase 序列化）
+- 验证权限校验和数据隔离（`SET LOCAL app.current_site_id`）在真实请求中生效
+- 前端联调验证：确认前端页面能正确调用 API 并渲染数据
+- 验证空数据/降级场景下前端不崩溃
+
+### 步骤 3：数据库变更审计与 DDL 合并（涉及 DB 改动时必选）
+
+- 审计本次实现中对数据库的所有改动（新建表、新增字段、新增索引、FDW 映射变更等）
+- **必须通过 pg MCP 工具实际执行迁移 SQL**（禁止仅标记完成而不执行）
+- 执行后用查询验证表/字段/索引已正确创建
+- RLS 视图双 schema：后端查询 `app.v_*` 视图，新建 DWS RLS 视图时必须同时在原 schema 和 `app` schema 下创建
+- 合并到主 DDL 基线文件（ETL → `docs/database/ddl/etl_feiqiu__<schema>.sql`，业务 → `docs/database/ddl/zqyy_app__<schema>.sql`）
+- 编写回滚脚本（逆序 DROP/ALTER）
+
+### 步骤 4：BD 手册更新（涉及 DB 改动时必选）
+
+- 业务库 → `docs/database/BD_manual_*.md`
+- ETL 库 → `apps/etl/connectors/feiqiu/docs/database/<层级>/main/BD_manual_*.md`
+- FDW → `docs/database/BD_manual_fdw*.md`
+- 每份手册必须包含：字段明细、约束与索引、验证 SQL（≥3 条）、兼容性影响、回滚策略
+
+### 步骤 5：项目文档同步更新（按涉及范围裁剪）
+
+根据改动类型选择需要更新的文档：
+
+| 文档 | 更新条件 |
+|------|----------|
+| 模块 README | 模块内部结构变更时 |
+| `apps/backend/docs/API-REFERENCE.md` | 新增/修改后端路由时 |
+| `docs/contracts/openapi/backend-api.json` | 新增/修改 API 端点时 |
+| `docs/DOCUMENTATION-MAP.md` | 新增任何文档条目时 |
+
+### 步骤 6：变更审计收口（涉及高风险路径时必选）
+
+执行 `/audit` 命令完成审计流程。
+
+### 步骤 7：服务清理（启动了运行时服务时必选）
+
+- 关闭浏览器实例、停止后端和前端服务、清理资源
+
+## 按 Spec 类型裁剪
+
+| 类型 | 必选步骤 |
+|------|---------|
+| ETL 类（ODS/DWD/DWS） | 1, 3, 4, 5, 6 |
+| 后端 API 类 | 1, 2, 5, 6 |
+| 全栈类（前后端 + DB） | 1, 2, 3, 4, 5, 6 |
+| 重构类 | 1, 5, 6 |