docs: add multi-round review learnings to team quality docs

- PRODUCTION_CHECKLIST: add RBAC/admin governance checklist section
- PROJECT_EXPERIENCE_SUMMARY: add lessons from 2026-04-10 reviews (live ≠ done, main-entry green > local green, test noise = quality issue, docs lag = rework)
- QUALITY_STANDARD: add stub→live review threshold rules

docs/team/PROJECT_EXPERIENCE_SUMMARY.md

@@ -151,3 +151,33 @@
   - 补充 Playwright 未覆盖的交互场景
   - 增加复杂业务流程的端到端验证
   - 提供更灵活的用户操作模拟能力
+
+## 17. 2026-04-10 多轮 Review 的新增经验
+
+- 2026-04-08、2026-04-09、2026-04-10 的连续 review 证明：真正难的不是把 stub 改成 live，而是把 live 链路补到可治理、可回滚、可验证。
+- `GetUserRoles`、`AssignRoles`、`CreateAdmin`、`DeleteAdmin` 从 stub 变成 live 后，问题从“功能没实现”升级成“权限边界、事务一致性、管理员治理是否成立”。
+- 经验教训：
+  - “功能通了”不是结束，live 后第一轮就应该补越权读取、越权修改、自删管理员、最后管理员、失败回滚等负向验证。
+  - 高风险治理面不能靠默认假设，必须用显式规则和测试守住。
+
+## 18. 主入口绿灯比局部绿灯更重要
+
+- 连续 review 反复说明：`go vet ./...`、`go build ./cmd/server`、`go test ./... -short -count=1` 的绿灯，不能代替全量 `go test ./... -count=1` 与 `npm.cmd run e2e:full:win`。
+- 2026-04-10 的 review 里，`LL_001` 仍让全量后端测试失败，`e2e:full:win` 仍卡在包装入口；这说明“单步可过”与“主入口可过”是两件不同的事。
+- 经验教训：
+  - 发布判断必须跟着文档支持的主入口走。
+  - 任何脚本包装层失败都算真实失败，不应被下层局部绿灯掩盖。
+
+## 19. 测试噪声也是质量问题
+
+- 前端 `test:run` 与 `test:coverage` 即使最终返回成功，只要仍输出 `window.alert` 的 jsdom `Not implemented` 噪声，就说明代码库里还保留着会破坏真实交互的缺陷信号。
+- 经验教训：
+  - “success summary 之后还有噪声”不算干净通过。
+  - 原生弹窗与 popup 应继续按缺陷治理，而不是按低优先级美观问题处理。
+
+## 20. 文档如果慢于代码，会制造第二轮返工
+
+- 多轮 review 的另一个稳定结论是：状态文档、质量规范、发布清单、技术指引如果不跟着真实结论更新，很快就会反向误导后续协作。
+- 经验教训：
+  - review 一旦改变了真实结论，当轮就要同步文档。
+  - 文档不是收尾材料，而是下一轮决策的输入。