docs: add 2026-04-18 optimization baseline to governance documents
- Add optimization baseline appendix to QUALITY_STANDARD.md defining current baseline gates for all future optimization work - Update REAL_PROJECT_STATUS.md with latest project status - Add experience summary to PROJECT_EXPERIENCE_SUMMARY.md - Add technical guide updates to TECHNICAL_GUIDE.md - Add FULL_CODE_REVIEW_REPORT_2026-04-17.md as reference document
This commit is contained in:
@@ -302,3 +302,66 @@ npm.cmd run e2e:full:win
|
||||
- 验证方法:`grep -r “type IntegrationRedisSuite” internal/repository/` 必须返回定义位置。
|
||||
- 禁止:测试文件引用未定义的类型,即使该测试有 `//go:build integration` 标签。
|
||||
|
||||
## 2026-04-18 优化修复前治理基线
|
||||
|
||||
本附录定义了后续任何优化或修复工作开始前必须遵守的治理基线。若旧章节与本附录冲突,以本附录为准。
|
||||
|
||||
### 1. 当前门禁真相优先
|
||||
|
||||
- 任何“当前状态”“已绿”“阻塞中”“可继续”的表述,都必须绑定当前工作区的新鲜命令证据。
|
||||
- 报告日期事实与当前工作区事实必须分开书写。
|
||||
- 历史绿灯结果不能复用为当前门禁证据。
|
||||
|
||||
### 2. 当前优化修复的最低门禁
|
||||
|
||||
在声称一批修复已完成前,必须执行并记录:
|
||||
|
||||
```powershell
|
||||
go build ./cmd/server
|
||||
go vet ./...
|
||||
go test ./... -count=1
|
||||
|
||||
cd frontend/admin
|
||||
npm.cmd run lint
|
||||
npm.cmd run build
|
||||
```
|
||||
|
||||
- 若改动涉及认证、会话、路由守卫、导航、`window` 防线或用户主流程,还必须执行:
|
||||
|
||||
```powershell
|
||||
cd frontend/admin
|
||||
npm.cmd run e2e:full:win
|
||||
```
|
||||
|
||||
- 超时不算通过。
|
||||
- 包装脚本失败就是真实失败。
|
||||
- 成功摘要后仍有浏览器原生弹窗噪声,不算干净通过。
|
||||
|
||||
### 3. 安全敏感修复必须 fail closed
|
||||
|
||||
- refresh token 轮换在吊销持久化失败时必须 fail closed。
|
||||
- 与 MFA 相关的登录逻辑在 TOTP/设备信任策略完成执行前,不能签发最终 token。
|
||||
- CORS 必须拒绝危险默认组合,例如通配来源配合 credentials 开启。
|
||||
- 任何由用户可控 ID 定位资源的接口,都必须在路由层或 handler 边界做显式授权检查。
|
||||
|
||||
### 4. 正确性修复必须遵守契约
|
||||
|
||||
- cursor pagination 只能支持与游标谓词一致的排序;不支持的排序必须显式拒绝。
|
||||
- 多步写操作必须具备事务性,或具备显式回滚逻辑。
|
||||
- 基于缓存的安全计数器或一次性验证码必须使用原子语义,不能继续使用 best-effort 的读改写序列。
|
||||
|
||||
### 5. 文档同步是强制项
|
||||
|
||||
- 若新鲜验证改变了真实门禁状态,必须在同一批次更新 `docs/status/REAL_PROJECT_STATUS.md`。
|
||||
- 若评审改变了长期工程约束,必须在同一批次更新本文和 `docs/team/TECHNICAL_GUIDE.md`。
|
||||
- 若评审产出了可复用经验,必须在同一批次更新 `docs/team/PROJECT_EXPERIENCE_SUMMARY.md`。
|
||||
|
||||
### 6. 强制修复顺序
|
||||
|
||||
除非有更窄的依赖关系强制改变顺序,否则按以下次序执行:
|
||||
|
||||
1. 刷新当前门禁真相并写入文档。
|
||||
2. 先修发布阻塞级别的安全与授权缺陷。
|
||||
3. 为每个确认接受的修复补回归测试。
|
||||
4. 重新执行受影响的完整门禁。
|
||||
5. 只有在以上完成后,才进入结构清理或一般优化。
|
||||
|
||||
Reference in New Issue
Block a user