本卡為 FR-087 唯一一棒，也是母卡。只盤不修、不改任何一行程式碼、不動任何環境。 來源是 FR-080 併入 FR-075 當日的交接（docs/features/FR-080-2609-jedi-consolidation-and-service-path/handoff/fr080-to-fr075-HANDOFF.md §二），決策者裁定隔離修正歸資安線這邊。

這一棒在做什麼（白話）

我們的產品是多家客戶共用一套系統的，靠資料庫的一道機制把各家資料隔開（RLS，就是「每個客戶只能看自己資料」的資料庫隔離機制）。2026-09-11 決策者實測發現：切換到被指派的子租戶之後，還是看得到別家客戶的待辦任務與專案。 這一棒要做的是：把「哪些資料該被誰看到」這件事逐張表盤清楚，列出現況與應有狀態的差距，交給決策者決定怎麼修。不修、不改、不套 migration。

為什麼要做

• 這是一個修好一個洞才露出來的更大洞。 以前沒人切過租戶——切租戶要先被指派成別租戶的角色，而那個功能在 CM-1661 修好前根本不能用。修好之後才發現後面的隔離沒做。
• 不是理論風險，已實測。 拿一把指向不存在租戶的鑰匙去查，待辦列表應該回 0 筆、實際回 39 筆；專案應該 0 筆、實際 213 筆（首腦在 DEV 用受隔離的應用帳號重跑過，數字與交接檔一致）。
• 目前客戶端還沒炸：跨租戶指派在 STG／POC 是 0 筆。但這個功能已經可用了，所以是「還沒有人踩到」而不是「踩不到」。
• 與 FR-086 是同一個病的兩種形狀：FR-086 是應用層四層全空（只驗身分不驗歸屬），這批是資料庫層該擋沒擋。兩者合起來才知道一個租戶到底能碰到多少不該碰的東西，所以決策者裁定放在一起看。

決策者已定的產品模型（這是判準，不要重新設計）

垂直向下可管理（父租戶看得到子孫），不同分支互相隔離；平台級資源（法規框架、控制項目錄、內建範本）全租戶可讀、只有原廠可寫。

這個模型 2026-06-29 就定了，原文在 docs/changelog/2026-06-29-feat-tenant-scope-data-model-b2.md 與 2026-06-30-feat-compliance-framework-platform-write.md。動手前先讀那兩份——決策者提過「當初設計時合規資源庫有踩過雷」，那兩份記的就是踩雷後定下來的做法。標準的隔離規則寫法見 docs/system-design/database/RLS_DESIGN.md。

🔴 盤點什麼（首腦已在 DEV 實查，數字可信）

首腦已用唯讀查詢核對過交接檔的每一項，13 張表與 4 支 view 一字不差。你的工作不是重查一遍數字，是回答「每一張該是哪一層、差什麼、誰在讀、開了會不會弄斷東西」。

① 13 張有租戶欄位但隔離沒生效的表

政策寫好了但沒開（開關打開即可）：

• compliance.projects（4 條政策）— 這是實測看得到 213 筆的那張。被關掉的來源是 2026-06-25-align-poc-to-stg-... 第 124 行，標 envs=poc，理由只寫「以 STG 為主」。要查清楚當初為什麼關，別直接開了弄壞什麼。
• compliance.workflow_templates（4 條）／public.tenant_drive_integrations（4 條）

政策不完整：compliance.workflow_executions（只有 3 條、缺 SELECT，11,016 筆）

連政策都沒有（要照標準模式各補 4 條）：

• compliance.job_executions（11,065 筆）／compliance.information_systems／compliance.poams／compliance.evidence_classification_runs／compliance.evidence_classification_ground_truth／oscal.framework_parse_jobs／config.log_forwarding_settings／public.user_roles／public.user_tenants