[governance → hashmatrix] M2 首张业务表的租户隔离模型与动态 schema 建表机制（阻塞 #27/WP1）

[uniquehole]

背景

• 提问方：governance（HashMatrixData/hashmatrix-governance）
• 目标方：hashmatrix（主仓 · docs/architecture/05-多租户与控制平面 owner）
• 触及：M2 数据治理第一次落业务表（metadata_asset，见 governance platform-parent: spring-boot repackage 替换主制品 → failsafe 集成切片找不到 @SpringBootConfiguration（service 仓 CI 红） #27/WP1）的租户隔离落地模型与建表机制

M2「数据目录·资产登记」需 governance 落首张业务表。落地前发现一处未决的架构决策，属"不可返工"性质（子仓不擅自发明），故请主仓拍板。

疑问 / 讨论点

1. 隔离模型相互冲突：
   • 本仓既定模型 = schema-per-tenant（docs/architecture/05 §5、本仓 TenantSchema=gov_<tenant>、JdbcEsConnectivityAdapter 经 SET LOCAL search_path 路由，注释明言"引擎 libs-java：platform-parent + BOM + starter-tenant，发布 GitHub Packages #1 落地业务查询应复用此范式"，row-level tenant_id 仅为兜底过滤）；
   • 但 M2 governance 自拆解简报 WP1 写的是单表 + tenant_id 列 + 按 X-Tenant-Id 过滤（row-level 为主）。
   • metadata_asset 到底走 schema-per-tenant 还是 row-level？还是 M2 先 row-level interim、待 libs-java：platform-parent + BOM + starter-tenant，发布 GitHub Packages #1 引擎收敛到 schema-per-tenant？
2. 动态租户 schema 的建表机制无主：若走 schema-per-tenant，gov_<tenant> schema 当前无人物理创建（control-plane 仅在 Tenant.db_schema 记录、provisioning 为 stub、无 CREATE SCHEMA；Flyway 启动期也无法对动态租户 schema 建表）。建表 hook 由谁出——control-plane provisioning 回调？governance 首次访问惰性建表？主仓统一约定？
3. 该决策影响 governance platform-parent: spring-boot repackage 替换主制品 → failsafe 集成切片找不到 @SpringBootConfiguration（service 仓 CI 红） #27（建表/entity/Flyway）、[security → main] starter-security 0.2.0 已发布制品非不可变且预认证缺陷 —— 子仓 CI 红 #28（read adapter 路由）、feat: M1 privacy 部署接线（chart 镜像/端口/探针 + gateway 路由 + 编排层契约） #29（写端点），希望一次定清避免返工（R2）。

期望与引用

• 期望：主仓就 metadata_asset（及后续业务表）的隔离模型与动态 schema 建表机制给出可落地结论；若为 interim row-level，请明确收敛到 schema-per-tenant 的时机/负责方。
• 引用（胜于粘贴）：
  • docs/architecture/05-多租户与控制平面.md §5 / 行 88（数据隔离 = schema/db-per-tenant）
  • governance TenantSchema、JdbcEsConnectivityAdapter（既有 gov_<tenant> 路由范式）
  • governance starter-security: 默认 permit-paths 未覆盖 /actuator/health/** —— K8s readiness/liveness 探针被 401 #26（M2 自拆解简报）/ platform-parent: spring-boot repackage 替换主制品 → failsafe 集成切片找不到 @SpringBootConfiguration（service 仓 CI 红） #27（WP1 建表）
  • 主仓 docs/milestones/M2-页面真实操作-可写纵切链.md §2 D9、§6 R2

可能的落点

• 澄清即可（无需改动）
• 落成 Issue（结论清晰后落主仓 arch 05 修订 / governance 建表机制任务）
• 其它

[uniquehole]

✅ 主仓拍板：M2 行级 tenant_id 先行级,升档后置,建表 hook 归 control-plane

你发现的「冲突」是表面的——arch 05 §3「数据」维度的 schema/db-per-tenant 是目标强档,而该档位本身是递进（行级 tenant_id → schema/db → 独立栈）。结论:

1. metadata_asset（及 M2 首批业务表）走"先行级"= 行级 tenant_id 列 + 按 X-Tenant-Id 强制过滤。

• 与 D9 一致（写落 tenant_id、读强制过滤）;且前向兼容——升 schema-per-tenant 后,行级 tenant_id 过滤仍作兜底保留(正如你本仓注释所述),不返工(守 R2)。M2 简报 WP1 的 row-level 写法正确,可直接落。

2. 升档（行级 → schema-per-tenant）后置到元模型/采集引擎落地阶段(非 M2),届时复用你既有的 gov_<tenant> search_path 路由范式。M2 阶段不要求动态租户 schema。

3. 动态租户 schema 建表 hook 归属（升档时生效）= control-plane provisioning。
开通租户时由 provisioning 统一 CREATE SCHEMA + 触发各数据面 owner 的 migration 回调,不由子仓首访惰性各自发明;M2 期 provisioning 仍 stub、单 ns demo 不触发。子仓勿擅自 CREATE SCHEMA。

已把以上落档为 arch 05 的「D9 落地档位说明」:➡️ PR #59（合入后即权威）。

对 governance 子任务:#27 按行级 tenant_id 建表 + JSONB 可扩展(R2)、#28 read adapter 按 tenant_id 过滤、#29 写端点落 tenant_id——均无返工风险,可动工。本讨论结论清晰,关闭。