FR-094 第 5 棒（.2c）乙組其餘＋排程相依表——poams／evidence_classification_runs／ground_truth／job_executions／framework_parse_jobs 補 4 條 policy＋開；information_systems 對齊基線；驗兩支排程在 RLS 開後仍掃得到（1 支 migration）

建議 model：Sonnet 5，effort：medium——policy 是標準樣板，難點在「開了之後兩支凌晨排程還掃不掃得到」要實際觸發驗。本卡屬 FR-094（母卡見兄弟卡段），.2 開隔離的第 3 棒（整案第 5 棒）。🔴 前置：.1a（兩支排程系統身分）與 CM-1559（fail-open 收緊）都收完才可派——順序反了清理程式會安靜失效。

問題是什麼（白話）

五張客戶資料表連隔離規則都沒寫：缺失改善計畫（POA&M）、證據自動分類的執行紀錄與答案對照表、每個稽核任務的執行紀錄（job_executions，11,656 筆，是「我的任務」的底層之一）、法規框架解析暫存工作。其中 job_executions 與 framework_parse_jobs 各有一支半夜排程在掃全表，開隔離後排程必須用 .1a 給的系統身分才掃得到。

首腦核對（2026-09-13 DEV localhost 實查；括號內為 FR-087 盤點於 188 快照的數字）：

compliance.poams：RLS 關、0 policy、92 筆。讀者：稽核輪次頁 app service，非背景。
compliance.evidence_classification_runs：關、0、8 筆；compliance.evidence_classification_ground_truth：關、0、1 筆。讀者：jedi-evidence-classification 套件內部，無背景程式。先查該套件 migrations/002-evidence-classification-grants.sql 有沒有已寫 policy 沒套——有就用套件的（FR-093 攤平後會套），本棒只補 ENABLE 與基線對齊；沒有才自己寫。
compliance.job_executions：關、0、11,656 筆。🔴 讀者：03:10 孤兒清理 core/scheduler.py:386（.1a 已接系統身分）；vw_user_job_queue view（.2d 加 security_invoker 後，view 查詢會以呼叫者身分套本表 policy）；infra/flow_control/repository/flow_control_job_repo_impl.py。
oscal.framework_parse_jobs：關、0、30 筆。🔴 讀者：01:00 清理 core/scheduler.py:202（.1a 已接）；框架匯入 app service。
compliance.information_systems：DEV 已開 RLS、4 policy（含 is_super_admin 分支），91 筆——與盤點報告（關、0）不同，是 jedi-asset migrations/002-asset-rls-grants.sql 在本機套過（該檔頭註明 DEV owner 是 cm_app 的陷阱）。基線 02-schema.sql grep 無 information_systems policy → 基線未開。本棒只做「基線庫對齊」：確認 FR-093 攤平機制是否會把 jedi-asset 002 套進基線；若會就不重複寫，若不會就在本棒 migration 補同款 policy＋ENABLE。回寫本卡寫清楚走哪條。

在哪裡

~/Projects/Billows/Audit-Manager/compliance-manager-be/scripts/sql/2026-09-XX-fr094-cm<本卡號>-rls-poams-evidence-jobs-parse-jobs.sql   （新）本棒 migration
~/Projects/Billows/Audit-Manager/compliance-manager-be/scripts/sql/manifest.tsv                              加一列
~/Projects/Billows/Audit-Manager/compliance-manager-be/core/scheduler.py:202,386                             兩支排程 tick（.1a 已改，本棒只驗不改）
~/Projects/Billows/Audit-Manager/compliance-manager-be/.venv/lib/python3.11/site-packages/jedi_evidence_classification/migrations/002-evidence-classification-grants.sql   先查有無現成 policy
~/Projects/Billows/Audit-Manager/compliance-manager-be/.venv/lib/python3.11/site-packages/jedi_asset/migrations/002-asset-rls-grants.sql   information_systems 已有 policy 的來源
~/Projects/Billows/Audit-Manager/compliance-manager-be/scripts/sql/2026-04-23-google-drive-oauth-integration.sql:48-79   4 條 policy 樣板

怎麼修

① 先驗前置：git log --oneline -5 看到 .1a 與 CM-1559 的 commit；log/app.log 有 system context entered: job_binding_orphan_cleanup。沒有就停下回寫。
② migration：五張表各 4 條（select／update／delete USING (is_super_admin='t' OR app_tenant_allowed_for_session(tenant_id))，insert WITH CHECK (app_tenant_allowed_for_session(tenant_id))）＋ ENABLE ROW LEVEL SECURITY。先查每張表有沒有 tenant_id 欄位（\d）——framework_parse_jobs／evidence_classification_* 若沒有，回寫本卡問首腦（JOIN-based 或加欄位），不自己猜。information_systems 依上段判定處理。
③ 開前 vs 開後對照：模擬 blsit 查五張表筆數，開前全量、開後只剩 102 路徑；is_super_admin='t' 仍全量。貼數字。
④ 驗兩支排程：手動觸發 tick（同 .1a 手測法）→ log 看到系統身分進入＋清理程式真的掃到列（例如在 DEV 造一筆 created_at 8 天前的 framework_parse_jobs 樣本，觸發後應被軟刪）。這一步是本棒存在的理由，不可省。
⑤ 套基線庫 → 重產 02 → diff 只多本棒 policy＋ENABLE。

要寫測試

碎片 case 預設不寫 unit test；以③對照＋④排程實跑（貼 log）為驗證。
突變：暫時把孤兒清理 tick 的 with system_context(...) 拿掉再觸發 → 掃到 0 列（或 .1a 守衛紅）→ 還原後再掃到。這證明「開了 RLS 之後排程確實依賴系統身分」。