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

docs/team/PROJECT_EXPERIENCE_SUMMARY.md

@@ -212,3 +212,60 @@
 - 完整性检查必须逐项
 - 覆盖率必须验证真实测试运行
 - 类型引用必须验证定义存在
+## 2026-04-18 从复核到修复的经验
+
+本附录记录了 2026-04-17 报告复核和 2026-04-18 文档对齐过程中提炼出的工程经验。
+
+### 1. 评审报告不是实时状态页
+
+- 一份报告可以在技术上仍然有价值，但它的门禁摘要会很快过时。
+- 团队必须把以下两类事实分开：
+  - 报告日期的发现
+  - 当前工作区的真实门禁状态
+- 如果这两类事实混写，执行顺序和优先级判断会很快漂移。
+
+### 2. 新鲜命令证据优先于继承结论
+
+- `go test ./... -count=1` 曾在评审材料里被视为红灯，但新鲜执行后在当前工作区已经转绿。
+- 与此同时，前端 `lint` 已经重新变红。
+- 经验：
+  在安排修复顺序前，必须先刷新真实门禁。
+
+### 3. stub 转 live 会带来第二波风险
+
+- `AssignRoles`、`CreateAdmin/DeleteAdmin`、`UploadAvatar` 已经越过了旧的“未实现”阶段。
+- 一旦转为 live，主导风险就会从“功能缺失”切换为：
+  - 授权边界
+  - 事务性
+  - 公开暴露面
+  - 自操作 / 最后管理员治理
+- 经验：
+  live 实现必须被当作新的安全与治理面重新复核，不能因为 stub 消失就直接标记为“闭环”。
+
+### 4. 发布阻塞往往是策略链断裂，不是没写代码
+
+- 密码登录绕过 TOTP/设备信任校验，比很多显眼的“功能缺失”更像真实发布阻塞项。
+- refresh token 吊销 fail-open 也是发布阻塞项，即使代码路径本身已经存在。
+- 经验：
+  在认证系统里，“已实现”不等于“完整”，只要安全策略链断了，就是关键缺陷。
+
+### 5. 事实成立，不代表措辞可以粗糙
+
+- LIKE 搜索问题是真实的，但把它笼统写成通用 SQL 注入，会夸大具体缺陷类型。
+- 密码重置 replay 问题也是真实的，但必须精确指出脆弱路径。
+- 经验：
+  严重级别可以保持不变，但措辞必须更精确；精确措辞能加快修复，也能减少无效争论。
+
+### 6. 主入口绿灯比局部绿灯更重要
+
+- 局部命令成功，不能替代项目正式支持的主命令成功。
+- 包装层失败或顶层命令失败，就是真实项目失败，即使更深层子命令单独能过。
+- 经验：
+  所有结论都必须对齐文档中声明的主验收入口。
+
+### 7. 文档漂移会制造返工
+
+- `REAL_PROJECT_STATUS`、评审报告和团队规范已经开始出现漂移。
+- 这种漂移会把下一轮修复引向过时优先级。
+- 经验：
+  文档更新不是交付后的清理工作，而是交付本身的一部分。