leaudit-platform-backend/docs/权限与地区隔离/权限与租户改造当前进度总览.md

权限与租户改造当前进度总览

适用范围：leaudit-platform 当前权限、地区隔离、租户化、多租户入口模块改造现状
更新日期：2026-05-21
文档定位：给当前研发/评审快速判断“已经做到哪里、哪些只是方案、哪些已经进代码/数据库、下一步该做什么”。

冻结验收入口：

• 冻结版进度盘点与最小冒烟验收-2026-05-21.md
• Pytest全链路验收说明.md

---

1. 当前结论

目前这轮改造已经不是纯方案阶段，已经进入：

1. 文档体系基本齐全
2. 数据库租户底座已补齐
3. 登录/当前用户/租户解析/入口模块读取链路，已经有第一轮兼容代码
4. RBAC 用户租户设置与首页入口显示，已经完成真实联调修复
5. RBAC 管理域与交叉评查任务建单入口，已完成一轮 tenant-first 高风险边界收口
6. 统一权限执行器、统一数据范围收口、角色去硬编码全域治理，还没有完成

换句话说：

• 租户主数据底座 + 兼容层：已开始落地
• 入口模块租户化：已部分落地，首页读链路已打通
• RBAC 用户租户维护：已完成首轮接口与前端联调
• RBAC/CrossReview 高风险边界：已完成首轮 tenant-first 收口
• 权限统一执行器：仍主要停留在设计和骨架层
• 业务模块全量 scope 化：仅零散改动，未形成统一闭环
• 前端去角色化：未系统完成

补充一个必须纠偏的认知：

• 评查点/评查组 当前不能再被简单理解成老 evaluation_points 主表治理问题
• 新平台真实运行主链路，已经转为 入口模块 -> 一级业务大类 -> 二级业务子类型 -> 规则集 -> YAML 规则版本 -> 文档评查结果
• 老 /api/v3/evaluation-points 与老评查点页面，只能视为兼容链路，不再是新平台主模型

对应专项文档：

• 新平台评查点与评查组真实模型梳理.md

---

2. 文档层进度

2.1 已完成的核心文档

docs/权限与地区隔离/ 下当前已具备以下主文档：

1. 架构总方案
   • 权限架构全面优化改造方案.md
2. 现行权限模型
   • 用户与地区权限完整设计方案.md
   • 用户权限与权限点清单.md
3. 统一执行器设计
   • 统一数据范围执行器设计.md
   • 统一执行器落地代码骨架与接入示例.md
4. 接口/SQL/测试/排期
   • 权限接口矩阵与数据边界清单.md
   • 权限字段映射与SQL改造规范.md
   • 权限测试验收与回归用例清单.md
   • 权限改造实施任务拆解与排期.md
5. 角色去硬编码专题
   • 角色硬编码与接口影响专项补充分析.md
   • 角色去硬编码迁移清单.md
6. 地区租户化/多租户专题
   • 地区租户化与自定义租户扩展改造方案.md
   • 租户主数据模型设计.md
   • 权限、租户能力与数据范围职责边界说明.md
   • 地区到租户编码映射清洗清单.md
   • 入口模块租户配置表迁移方案.md
   • 自定义租户功能连带影响深度补充.md

结论：

• 文档覆盖面已经够全
• 现在缺的不是“再补大方向设计稿”
• 现在更缺“按文档逐步落代码、落表、落验证”

2.2 文档导航状态

当前存在两套导航：

1. 新总导航
   • 权限文档总导航与阅读顺序.md
2. 旧导航
   • 权限与地区隔离文档导航.md

其中旧导航仍保留了这类旧口径：

• 只做 RBAC + 单地区数据隔离
• 用户地区只认 sso_users.area
• 角色主线只保留 provincial_admin/admin/common

这和当前已经推进的“地区租户化、tenant_code、租户主数据、入口模块租户映射”方向已经不一致。

结论：

• 旧导航不能再作为现行总入口
• 后续阅读应以 权限文档总导航与阅读顺序.md 为准

补充一个当前必须单列的新专题：

• 规则域多租户方案A实施计划.md

这个文档的作用不是重复讲租户大方向，而是专门收口：

1. 新平台规则配置
2. 评查组与规则绑定
3. 规则集与规则版本
4. 评查运行结果链路

它已经明确把规则域定案为：

1. 共享业务树
2. 租户规则绑定
3. TENANT -> PROVINCIAL -> PUBLIC 生效顺序
4. 运行结果快照 tenant-first

当前规则域代码进度已推进到：

1. 读侧 tenant-first 已完成
2. 规则组绑定写侧 tenant 化已完成
3. 规则配置来源态字段已完成
4. 规则版本 lineage 快照已完成第一轮
5. 剩余主要是新库执行迁移 SQL 与前端来源态联调

---

3. 数据库层进度

3.1 已完成

数据库底座已经补齐并执行过：

1. schema_tenant_foundation.sql
2. schema_entry_module_tenants.sql

已落地对象包括：

1. sys_tenants
2. sys_tenant_aliases
3. sys_tenant_feature_flags
4. leaudit_entry_module_tenants
5. sso_users.tenant_code

同时已做过：

1. 基础租户种子数据初始化
2. 历史 area -> tenant_code 回填
3. 入口模块旧 areas JSON 到租户关系表的初始化迁移

3.2 当前意义

这一步很关键，因为它说明当前系统已经不再只是“设计租户化”，而是数据库已经具备：

1. 租户主数据查询基础
2. 历史地区别名兼容基础
3. 功能级租户启用开关基础
4. 入口模块按租户配置的关系化基础

3.3 仍未完成

数据库层目前仍不是“全量租户化完毕”，主要还差：

1. 更多业务表是否需要补 tenant_code
2. 历史 area/region/default/省级/空值 残留数据的全量清洗
3. 其他模块是否仍只靠中文地区名落库/查询
4. 更完整的租户写接口与后台维护能力

---

4. 代码层进度

4.1 已明确落地的后端能力

当前已经落地了一批“租户兼容层”代码，不再只是文档：

1. 统一租户解析器
   • tenantResolver.py
2. 旧 sso_users 结构兼容
   • ssoUserCompat.py
3. 租户主数据服务
   • tenantServiceImpl.py
4. 租户接口控制器
   • tenantController.py
5. 登录/当前用户租户解析接入
   • authServiceImpl.py
6. 首页入口模块按租户过滤读取
   • homeServiceImpl.py
7. 入口模块管理页租户化读写兼容
   • entryModuleAdminServiceImpl.py
8. RBAC 用户租户设置能力与首轮 scope 收口
   • rbacAdminServiceImpl.py
   • rbacAdminController.py
9. 交叉评查任务建单租户边界收口
   • crossReviewServiceImpl.py
10. 首页入口前端兼容修复

• home.ts
• minimal-scope.ts

11. 发布级 pytest 黑盒验收基座

• tests/release/conftest.py
• tests/release/test_g1_rbac_context.py
• tests/release/test_g2_g3_tenant_entry_chain.py
• tests/release/test_role_tenant_matrix.py
• tests/release/test_g4_documents.py
• tests/release/test_g5_rag.py
• tests/release/test_g5_rule_cross_review_matrix.py

4.2 当前已经解决了什么

这些代码至少已经开始处理下面几类真实问题：

1. 旧环境 sso_users 没有 tenant_code 时，避免直接 SQL 崩溃
2. 旧环境没有 sys_tenants/sys_tenant_aliases/leaudit_entry_module_tenants 时，服务层可降级
3. 登录返回和当前用户接口，开始统一产出 tenant_code/tenant_name/tenant_type
4. 首页入口模块和后台入口模块管理，开始从“按 areas JSON”过渡到“按租户关系表”
5. RBAC 用户已可通过标准接口设置 tenant_code
6. 首页入口前端已兼容识别 route_path / routePath / target_path / targetPath / path
7. 入口模块管理端列表/详情接口已收口为 tenants 主输出，不再对管理端返回 areas
8. 首页交叉评查入口判断已切到 tenants 优先，首页后端租户过滤已收紧过宽 fallback
9. T8 首页入口 + 入口模块后台收口 已可视为完成
10. 租户页与角色权限页的职责边界已补专项文档，后续实现统一按“权限管人、租户能力管挂载、数据范围管边界”收口
11. RBAC 组织树节点已改为 tenant_code 优先分组，目标用户角色查询/分配已补跨租户拦截
12. CrossReview 创建任务前的“成员用户 + 任务文档”校验已改为 tenant_code 优先，旧 area/region 仅作兼容回退
13. T5 评查点 首轮已切到 tenant_code 优先读取/写入，旧 area 仅在遗留表无字段时兼容回退
14. CrossReview 已补“单任务不得混挂多租户成员/文档”约束，补传文档开始按任务真实挂载内容反推租户边界
15. CrossReview 任务列表已开始同时返回标准化 evaluationTenants，前端仍保留 evaluationRegion 兼容消费
16. T5-1 评查点读链路 已完成：当前用户租户上下文与显式筛选租户条件已拆分，读范围判断不再互相污染
17. T5-2 评查点写链路 已完成第一轮：创建/更新不再把原始 area 文本直接作为归属主语义，统一从解析后的 writable_scope 写入 area/tenant_code/tenant_name
18. T5-2 评查点写链路 已完成第一轮：PUBLIC/PROVINCIAL 与 公共/省级/default 共享域写入已统一归一化到标准租户编码，未显式指定归属范围的全局写入会被直接拒绝
19. T5-3 评查点读链路 已完成第一轮：共享域筛选已优先按 PUBLIC/PROVINCIAL 匹配，旧 公共/default/空值/省局/省级 仅作为无 tenant_code 历史数据 fallback
20. T5-4 评查点角色判定 已完成第一轮：主链路的全局/管理能力已改为 roles.data_scope + evaluation_point:* 权限推断，不再直接硬编码 super_admin/provincial_admin/admin
21. T5-5 评查点 fallback 收口 已完成第一轮：查不到数据库用户上下文时，已移除 payload.user_role 角色名兜底；fallback 默认不再推断全局范围
22. 发布门禁 G1-G3 已不再只靠人工回放，已沉淀为可重复执行 pytest 黑盒验收
23. 多租户、多角色的基础矩阵验收已落地，可直接验证：

• 全局管理员跨租户查询
• 租户管理员本租户范围限制
• 普通用户管理面 403 与业务入口可见性

24. tenantServiceImpl 的租户 alias 重复更新 500 已修复，租户更新写链路幂等性补齐了一处高频故障点
25. Document 主链路已通过发布级黑盒验收：

• 上传、列表、详情、更新、附件追加、删除均已验证租户边界
• mergeMode=new 附件追加的当前真实行为已确认为“生成新版本”

26. RAG 第一轮黑盒验收已完成：

• 本租户与公共应用可见性边界已验证
• 数据集详情读取边界已验证
• 当前权限种子下，数据集管理接口仍偏全局管理员模型，这一现实已被测试固化

27. 规则集 / 评查组 / 交叉评查 第一轮黑盒验收已完成：

• 规则集元数据全局可读
• 规则绑定与评查组树按入口模块租户映射过滤
• 交叉评查任务建单已验证“成员/文档不得混租户”

4.2.2 新平台主链路本轮新增进度

围绕新平台真实主链路 入口模块 -> 一级业务大类 -> 二级业务子类型 -> 规则集 -> 规则版本 -> 文档评查结果，本轮又补了 3 个高风险收口点：

1. T4 规则控制器鉴权 已落代码
   • ruleController.py
   • 已补 verify_access_token
   • 已补 PermissionServiceImpl
   • 权限键已严格对齐 scripts/创建sql/user_rbac_seed.sql 中现有 rules:* 种子
   • CreateRuleVersion / Publish / Rollback 的操作人已改为只认当前 token 用户，不再信任前端 body 传入用户ID
2. T1 上传显式 tenant_code 已落代码
   • FilesUploadClient.tsx
   • files-upload.ts
   • 上传前端已开始同时传 tenant_code + region
   • 其中 tenant_code 作为主边界，region 仅保留给旧链路兼容展示与后端兼容解析
3. T2 文档 tenant/region 混用收口 已完成第一轮
   • documentServiceImpl.py
   • _document_tenant_filter_sql 已去掉“tenant_code 非空时仍放宽匹配空 tenant_code + region”逻辑
   • _find_latest_version_candidate 已去掉“有正式 tenant_code 仍可把历史空租户同 region 文档并入版本链”的放宽分支
   • 当前版本归并边界已经收紧为：
     • 有 tenant_code：只认同编码文档
     • 无 tenant_code：才允许按 region 兼容命中历史空租户数据
4. T3 评查组/规则绑定租户边界 已完成第一轮
   • evaluationPointGroupController.py
   • evaluationPointGroupService.py
   • evaluationPointGroupServiceImpl.py
   • ruleController.py
   • ruleService.py
   • ruleServiceImpl.py
   • evaluation-point-groups 全部 controller -> service 入口已显式传入 CurrentUserId
   • evaluationPointGroupServiceImpl 已补“当前用户租户上下文 -> 可访问 entry_module -> 可访问 group/binding”的第一轮统一收口
   • ListGroups / ListAllGroups / ListGroupsByDocumentTypes / GetGroup / GetChildren 已按 entry_module -> leaudit_entry_module_tenants 过滤
   • Create/Update/Delete/Rebind/Batch* 及 CreateBinding/UpdateBinding/DeleteBinding/GetRuleTemplate/CreateRuleDraft 已补当前租户可访问性校验
   • ruleServiceImpl 当前只对 ListBindings/CreateBinding/UpdateBinding/DeleteBinding 四个绑定面接口补租户收口，仍未把 ListSets/GetVersions/GetContent 这种全局规则资产接口租户化
5. T3-1 rule-groups SSR 缓存串租户风险 已完成修补
   • page.tsx
   • 进程级 __ruleGroupsTreeCache__ 已从单桶改为按 token 分桶
   • 后端开启按租户收口后，不再把 A 租户分组树缓存直接复用于 B 租户 SSR 请求

这一轮的定位不是“把整条新平台主链路全部租户化完成”，而是先收掉 3 个最危险问题：

1. 规则管理接口裸奔无鉴权
2. 上传链路不显式提交 tenant_code
3. 文档与历史版本归并仍可能因为 region fallback 错并到错误租户
4. 评查组/规则绑定仍可跨入口模块查看和写入
5. rule-groups SSR 缓存可能跨租户串数据

4.2.3 新平台主链路当前仍未完成的点

截至本轮，以下问题仍然存在，且属于后续优先级较高的剩余项：

1. ruleServiceImpl / ruleGroupSupport.py 仍以全局规则集与分组关系为主，未形成真正的“规则集/版本资产级”租户边界
2. evaluationPointGroupServiceImpl 当前第一轮收口完全依赖 entry_module -> leaudit_entry_module_tenants；历史未绑定 entry_module 的脏数据，对非全局用户会直接不可见，仍需专项清洗
3. 文档列表/详情虽然已开始 tenant-first，但部分链路仍保留 region 兼容消费，需要继续审计调用点是否会把展示值误当边界键
4. 首页入口、上传页、文档列表页前端 scope 仍有 sessionStorage + documentTypeIds + selectedModuleId 主导的旧思路，尚未做到“显式 tenant scope 全链路透传”
5. 旧兼容评查点链路与新平台主链路之间的权限/租户语义还没有彻底拆开
6. 规则域多租户仍未整体完成，数据库脚本已准备但尚未在新库执行，当前只完成“方案 A 定案 + 第一轮运行链路 + 只读侧最小落地”
7. T11-R1/R4 已开始首轮落地：
   • 已新增规则域迁移 SQL：
     • schema_rule_domain_tenant_phase1.sql
     • precheck_rule_domain_tenant_phase1.sql
     • verify_rule_domain_tenant_phase1.sql
   • auditServiceImpl 已接入 TENANT -> PROVINCIAL -> PUBLIC 的最小运行时选择逻辑
   • storage_adapter 已支持结果/错误/指标写入租户快照字段的兼容模式
   • ruleServiceImpl / ruleConfigServiceImpl 已完成第一轮只读侧租户作用域接入：
     • ListSets / GetVersions / GetContent 已支持按当前用户 tenant_code 解析有效规则集
     • ruleConfig 的 ListPacks / ListPackSummaries / GetPack 已支持按当前用户命中有效绑定
     • 规则配置摘要缓存已按用户维度隔离，避免串租户
   • ruleServiceImpl 已完成第一轮写侧收口：
     • CreateVersion 已接入当前用户租户上下文，不再默认全局命中 rule_type -> rule_set
     • Publish / Rollback 已增加“当前租户可写规则集”校验，避免跨租户切换生效链
   • 当前仍未进入规则派生复制完整闭环、业务组绑定写侧租户化、前端“来源态展示”的阶段

4.2.1 评查点模块状态纠偏

这里需要单独说明，避免后续继续按错方向推进：

1. 当前仓库里确实还保留旧评查点链路
   • EvaluationPointController
   • EvaluationPointServiceImpl
   • 前端 rules/list、rules/new
   • 后端仍连老库 docauditai.evaluation_points
2. 但新平台真实主链路已经不是这套
   • 前端 rule-groups 页
   • 后端 evaluationPointGroupServiceImpl
   • leaudit_evaluation_point_groups
   • leaudit_rule_group_bindings
   • leaudit_rule_sets
   • leaudit_rule_versions
   • leaudit_documents.group_id
3. 因此前面 T5 评查点 的第一轮改动，只能定义为：
   • “旧兼容评查点链路的 tenant-first 收口”
   • 不能定义为“新平台评查点主链路改造完成”

当前正确判断应该是：

• T5-legacy：旧评查点兼容链路已做首轮 tenant-first 收口
• T5-main：新平台评查组/规则集主链路的租户边界、权限边界、数据范围边界，还需要重新单列分析和排期

当前这部分已经不再是“待分析”状态，而是：

• 已完成单列方案定案
• 已形成专项实施计划
• 下一步应直接按 规则域多租户方案A实施计划.md 执行

4.4 最近一次真实联调结论

本轮已用真实接口和真实前端链路验证通过：

1. 000 / admin06111 可登录后端和前端
2. PUT /api/v3/rbac/users/5/tenant 可成功更新用户租户
3. /api/auth/me 已能返回正确 tenant_code=MZ
4. 后端 /api/home/entry-modules 对 000 实际返回 5 个入口模块
5. 前端此前“首页无入口”的根因不是后端过滤，而是首页兼容层只认 route_path
6. 修复前端兼容层后，/api/auth/session-data 已真实返回 entryModules=5

因此当前关于“000 用户首页没入口”这一问题，已经不是待分析状态，而是已修复并已验证状态。

4.3 当前还不能说“已完成”的部分

虽然代码有落地，但整体仍不能算改造完成，原因是：

1. 统一权限决策模型还没成为全项目公共底座
2. Document/Govdoc/UsageStats/RAG/RBAC 还没全量切到统一执行器
3. 角色硬编码还存在于多个 controller/service/前端 guard
4. 现在很多地方是“兼容层 + fallback”，不是最终收口态

4.4 高风险第一批最新进展

当前已正式开始按“高风险优先”执行，不再停留在方案阶段。

本轮已新增并推进：

1. 中高低风险修复优化计划.md
2. 高风险数据库迁移清单与执行顺序.md
3. schema_tenant_code_high_risk_phase1.sql

其中已经实际落地的第一批代码变更包括：

1. 合同模板服务已从“接口表面支持 tenant_code、实际按 region 查”推进到“写入真实 tenant_code/tenant_name，查询优先 tenant_code，旧数据按 region 兼容回退”
2. 合同模板上传去重已从 region + template_code 收口为“优先 tenant_code + template_code，旧数据兼容 region”
3. 合同模板列表、详情返回已不再伪造空 tenant_code
4. 高风险 SQL 迁移脚本已从不安全的多匹配回填写法，修正为“按主键逐表稳定回填”的确定性写法
5. 评查点模块已补专用数据库草案：
   • schema_evaluation_points_tenant_cleanup.sql
6. 评查点模块已补专用收尾文档：
   • 评查点模块收尾清单.md
7. 评查点模块已补执行前预检与执行说明：
   • precheck_evaluation_points_tenant_cleanup.sql
   • 评查点数据库执行说明与验证SQL.md
8. 评查点模块已补预检结果判读模板：
   • 评查点预检结果判读模板.md

这意味着：

• T6 合同模板模块 已完成第一轮高风险 tenant-first 收口
• schema_tenant_code_high_risk_phase1.sql 已具备进入数据库执行评审的基础
• T5 旧评查点兼容链路 已进入“代码首轮收口完成，待决定是否继续兼容 / 迁移 / 只读化”的阶段
• T5 新平台评查组主链路 不能再按“给 evaluation_points 补字段”推进，需改按新模型重新拆租户边界
• 下一步应继续推进 RBAC 管理域 scope 化 与剩余业务派生查询的统一执行器接入

---

5. 按实施排期对照当前状态

以 权限改造实施任务拆解与排期.md 为基线，当前大致进度如下。

5.1 P1 能力层建设

状态：未完成

判断依据：

1. 文档里定义了 ScopeContext / PermissionGrant / PermissionDecision / ScopeClause
2. 但当前代码里还没有形成稳定、统一、被各模块复用的完整执行器主链
3. 现有改动以租户兼容和入口模块租户过滤为主，不是统一权限执行器成型

结论：

• P1 仍处于“设计已完成，工程底座未完整落地”

5.2 P2 RAG 双轨治理

状态：进行中

判断依据：

1. 当前已实际落地 rag_dataset / rag_chat_app 的 tenant_code 字段兼容补齐与索引补齐
2. 数据集后台创建、更新、删除、列表、详情已经改为 tenant_code 优先，area 退为兼容展示/回退
3. 数据集可见性与聊天应用可见性已开始按 tenant_code + PUBLIC/PROVINCIAL + public dataset 收口
4. 前端 /api/v3/dify/area-datasets* 代理链路已改为 tenant_code 优先，知识库配置页已接入真实租户选项源，不再只靠已有知识库反推地区列表
5. service 内部大部分显式 provincial_admin/admin/super_admin 白名单已移除，但统一 permission + decision + policy 公共执行器仍未彻底接入

结论：

• P2 已从“仅触达代码”进入“后端主链已收口一轮、前端管理链路已改 tenant_code 优先、首轮黑盒已完成”的阶段
• 但当前黑盒也明确暴露出一个现实：RAG 管理接口在现有权限种子下仍主要由全局管理员持有
• 剩余重点在于：
  1. 更深层文档/分段/检索派生接口的统一策略收口
  2. 会话写链路与消息链路补测
  3. 前端页面彻底去 area 命名心智
  4. 统一执行器正式接入 RagPolicy

5.3 P3 文档、公文、统计接入

状态：部分完成

判断依据：

1. 这些文件目前有修改痕迹：
   • documentServiceImpl.py
   • govdocServiceImpl.py
   • usageStatsServiceImpl.py
2. 其中 usageStatsServiceImpl.py 已完成一轮真实租户收口：
   • 登录审计补 tenant_code_snapshot / tenant_name_snapshot
   • 用户、文档、审计聚合查询改为 tenant_code 优先
   • GetUsers/GetAreas/GetDetails 的跨租户统计串数问题已修正
3. Document/Govdoc 已完成第一轮高风险 tenant-first 收口，但尚未全部统一接入一套执行器
4. 当前更需要防范“半改状态”，因为最容易出现范围判断不一致

结论：

• P3 不能整体宣称完成
• 但 T7 使用统计 可以视为本轮已完成
• Document 主链路已从“第一轮代码收口”进入“发布级黑盒已验证”的阶段
• Govdoc/合同模板 仍未进入同等强度的黑盒验收
• Document/Govdoc 后续重点转向统一执行器接入、剩余派生查询复核与验收

5.4 P4 RBAC、合同模板、首页接入

状态：部分进行中

判断依据：

1. 首页相关租户读取逻辑已开始落地，且前端首页兼容层问题已修复
2. rbacAdminServiceImpl.py、rbacAdminController.py 已新增用户租户设置链路并完成联调
3. RBAC 组织树、目标用户角色分配/查询已完成一轮 tenant-first 收口
4. contractTemplateServiceImpl.py 第一轮高风险已完成，但还没接入统一策略闭环
5. 还没形成“统一策略 + 统一范围判定”的闭环

结论：

• P4 中的“RBAC 首轮租户设置能力”“RBAC 首轮 scope 收口”和“首页入口可见性修复”已落地
• P4 中的“合同模板统一策略接入”和“RBAC policy 化”仍需继续推进

5.5 P5 前端去角色化与验收收口

状态：基本未完成

判断依据：

1. 前端目录有租户 API 接入痕迹
2. 但没有证据表明菜单、按钮、guard 已系统改成按权限/能力快照
3. 验收矩阵文档虽已写完，自动化和完整联调未见闭环

---

6. 当前最真实的完成度分层

如果按“真实可用进度”划分，当前可以这样看：

6.1 已完成

1. 权限与租户改造文档体系
2. 租户主数据基础表与入口模块租户关系表建表脚本
3. 目标库 schema 执行与基础数据初始化
4. sso_users.tenant_code 字段补齐与历史回填
5. RBAC 用户租户设置接口与前端弹窗联调
6. 首页入口前端标准化兼容修复

6.2 已落地但属于第一轮兼容

1. 登录/当前用户租户解析
2. 租户解析器与旧字段兼容
3. 租户选项服务 fallback
4. 首页入口模块读链路租户过滤
5. 后台入口模块读写链路租户关系表兼容
6. 首页前端会话聚合链路兼容 targetPath/routePath
7. 入口模块管理端消费层已完成 tenants 化，首页链路保留 areas 仅作兼容展示
8. 首页入口主判断链路已改为 tenants 优先，areas 已退为兼容展示

6.3 正在改但还不能验收

1. RAG
2. 文档的派生链路
3. 公文
4. RBAC 管理域全量 scope 化
5. 合同模板
6. 交叉评查任务与文档关系链统一策略接入

补充说明：

1. 统计 已从“正在改”转为“本轮后端收口已完成，待后续统一执行器接入时再做第二轮整合”
2. RAG 当前属于“后端主链 + 前端管理链路第一轮完成，且首轮黑盒验收已完成；但还未做最终权限模型收口”
3. 文档/公文 当前属于“文档主链路黑盒已通过；公文与更多派生链路尚未完成统一执行器接入与全链路回归”
4. RBAC 当前属于“用户租户设置 + 用户列表/组织树/角色分配第一轮 tenant-first 已完成；但 policy 化和统一执行器未完成”
5. CrossReview 当前属于“任务建单入口高风险边界已收口且首轮黑盒已验证；但任务详情、关系列表、后续动作链路尚未统一 policy”

6.4 仍未系统展开

1. 全局统一权限执行器正式接入
2. 全模块去角色硬编码
3. 前端去角色化
4. 多业务表租户字段标准化
5. 交叉评查/评查点等剩余 tenant-name 边界残留收口
6. 回归用例逐条落测

6.5 当前黑盒验收基线

截至 2026-05-21，发布级黑盒验收基线已经扩展为 16 passed。

这 16 条通过目前表达的是：

1. G1-G3 门禁链路已经稳定
2. G4 文档跨租户读写边界已被可重复执行测试固定
3. G5 RAG 当前真实权限模型已被固定
4. G6 规则集/评查组只读矩阵与交叉评查建单边界已被固定

同时也要明确：

1. 这不代表所有设计稿都已实现
2. 这不代表规则资产已经完全租户化
3. 这不代表 RAG 已经完全去角色化
4. 这不代表交叉评查后续深链路已经验收完成

---

7. 当前主要风险

7.1 文档口径和代码口径并存

风险点：

旧导航还在强调“只认 area、单地区隔离”，会误导后续开发继续写旧逻辑。

7.2 代码处于半改状态

风险点：

有些链路已经开始认 tenant_code，有些链路仍认 area/region/default，很容易出现：

1. 查得到列表，查不到详情
2. 登录后有租户，实际查询仍按旧地区字段
3. 新入口模块配置了租户，但其他下游仍用旧 JSON 或旧地区名

7.3 统一执行器未成型前，范围逻辑容易继续分叉

风险点：

如果继续一口气在各模块手写过滤，很可能又会堆出第二套、第三套范围判断。

7.4 租户接口虽然有代码，但还要看联通性

当前已存在 tenantController.py，控制器扫描注册机制也支持自动注册。

但仍需联调确认：

1. /api/v3/tenants
2. /api/v3/tenants/options
3. /api/v3/tenants/{tenantCode}

是否都已真实可用并满足前端需要。

---

8. 下一步建议顺序

基于当前状态，后续不建议再先写大而全新方案，而应按下面顺序推进：

1. 进入 T9 租户主数据维护写能力
   • 补租户新增、编辑、启停、别名、feature flag 管理接口
2. 再做“剩余高风险残留扫描”
   • 重点扫 region/area/default/省级/省局 是否仍会导致落错数据或查错范围
3. 然后按主数据风险顺序推进业务模块
   • 交叉评查后续关系链
   • 评查点配置
   • RBAC policy 化
   • 文档/公文剩余派生查询与统一执行器接入
   • RAG 二轮收口
4. 最后再进入统一执行器全量收口和前端去角色化

---

9. 建议你现在把它理解成什么阶段

最准确的描述是：

“权限与租户改造已经完成方案设计和第一批数据库/兼容层落地，当前处于从兼容接入向统一执行器正式收口过渡的中间阶段。”

补充一句更贴近当前真实状态的话：

“入口模块首页可见性和 RBAC 用户租户维护已经打通，但业务主数据域仍大量停留在 area/region 兼容阶段。”

不是：

• 还停留在纸面方案

也不是：

• 已经完成全量权限租户化改造

---

10. 当前阅读建议

如果你现在只想判断“接下来该盯哪里”，建议直接看这几份：

1. 权限与租户改造当前进度总览.md
2. 权限改造实施任务拆解与排期.md
3. 地区租户化与自定义租户扩展改造方案.md
4. 入口模块租户配置表迁移方案.md
5. 模块级开发任务单.md

如果你要判断“某个模块现在到底能不能继续开发”，再回头对照：

1. 权限接口矩阵与数据边界清单.md
2. 角色去硬编码迁移清单.md
3. 模块级真实落地清单与下一步动作.md