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/TECHNICAL_GUIDE.md

@@ -59,3 +59,25 @@ npm.cmd run e2e:full:win
 - 规则变更：更新 `docs/team/QUALITY_STANDARD.md`
 - 发布门槛变更：更新 `docs/team/PRODUCTION_CHECKLIST.md`
 - 阶段性经验：更新 `docs/team/PROJECT_EXPERIENCE_SUMMARY.md`
+
+## 6. 2026-04-10 多轮 Review 实操指引
+
+### 6.1 如何判断“是否闭环”
+
+- 结论优先级：文档支持的主入口 > repo 内单步命令 > 局部 smoke、单个用例、`-short` 结果。
+- 只要 `go test ./... -count=1` 仍被 `LL_001` 卡住，或 `npm.cmd run e2e:full:win` 仍未跑通，就不能把项目表述为“全量验证通过”。
+- `go build ./cmd/server` 通过，只能证明 repo 内该命令通过；不能自动推出包装脚本里的 build 路径也稳定。
+
+### 6.2 如何审查 stub 转 live 的高风险改动
+
+- 先看权限边界：调用者是否真的具备读取或修改目标资源的资格。
+- 再看治理边界：是否存在 `self-action`、`last-admin`、越权枚举、越权提升等问题。
+- 再看一致性：多步写操作是否在事务内；失败时是否有显式回滚。
+- 最后看文档与测试：是否补了负向测试、边界测试、回滚测试，以及状态文档与规范文档。
+
+### 6.3 当前需要持续关注的热点
+
+- `internal/service/scale_test.go`：`LL_001` 仍是全量 `go test ./... -count=1` 的门槛。
+- `frontend/admin/scripts/run-playwright-auth-e2e.ps1`：需要优先保证文档支持的 `e2e:full:win` 入口自身稳定，而不是只验证子命令。
+- `frontend/admin/src/components/common/ui-consistency.test.tsx`：原生弹窗噪声仍会污染测试结果，应继续清理。
+- `internal/api/handler/user_handler.go` 与 `internal/service/user_service.go`：RBAC / 管理员治理逻辑需要持续按越权、事务、自删、最后管理员等维度审查。