建議 model：Opus，effort：medium——動 session_scope 的 is_super 判定，錯了是靜默壞。本卡由 CM-1559 拆出（決策者 2026-09-14 裁「拆兩刀，1.20.0 只做第二刀」），原卡結案。前置：.1a CM-1767（沿用它開的 is_system_context 欄位）。

問題是什麼（白話）

資料庫隔離靠 session_scope() 在每次查詢前設定「這個人是誰、能看哪些租戶」。現在的判定有一條「tenant_id 是空值（None 或 0）就當超級管理員」——這是從「缺值」推論出最高權限，方向反了。X-Tenant-ID: 0 那條路已被 FR-069.16 擋死、DEV 40 個使用者 tenant_id 都不是 NULL，所以現在打不到，但它是縱深防禦少的一層，而且 jedi-iam 的 signed-token 流程刻意把 tenant_id 設成 None 來「借用」這個洞取得最高權限——洞補了它會壞，所以要一起改。

首腦核對（沿用 CM-1559 第一步盤點 2026-09-06 ＋ 2026-09-14 複查）：

• jedi-common jedi_common/session/database/db.py:102 is_super = (not user_ctx.tenant_id) or _session_paths_have_root(...)——要拿掉 not user_ctx.tenant_id。
• jedi-iam jedi_iam/authz/signed_token.py:83-100 _set_minimal_context()：docstring 自己寫明「tenant_id=None → is_super」是刻意依賴洞。
• signed-token 四處用途：OTP QR code（jedi-iam api/routes/otp_route.py:53，讀 users 有 RLS，會壞要一起改）、框架 OSCAL 下載（主專案 api/oscal/routes/framework/oscal_framework_version_route.py:131，framework／catalog 無 RLS，不壞）、問卷匯入範本（jedi-survey survey_route.py:236，純靜態檔，不壞）、檔案下載／PDF 預覽（jedi-file-upload，upload_files 無 RLS，不壞）。
• token payload 是 {scope, resource_uid, user_id}，user_id 是 uid、不含租戶。要填真實租戶得先查 user，而 users 有 RLS——引導悖論。現成解法：jedi_iam/middleware/context.py:80 build_user_context() 與 JWT 路徑同源；查 user 那一句用 jedi_iam/infra/elevated_session.py:38 elevated_readonly_session() 窄提權（只包那一句查詢）。
• setup 開站精靈（app/setup/service/setup_wizard_service.py:355）雖傳 tenant_id=None，但同時給 allowed_tenant_paths='/1/' → 走 root-path 分支仍是 super，本刀不影響。

在哪裡

~/Projects/Jedicogy/module/jedi-python-package/jedi-common/jedi_common/session/database/db.py:100-104    is_super 判定（拿掉 not tenant_id）
~/Projects/Jedicogy/module/jedi-python-package/jedi-iam/jedi_iam/authz/signed_token.py:83-100            _set_minimal_context（改填真實身分）
~/Projects/Jedicogy/module/jedi-python-package/jedi-iam/jedi_iam/middleware/context.py:80             build_user_context（現成組裝邏輯，沿用）
~/Projects/Jedicogy/module/jedi-python-package/jedi-iam/jedi_iam/infra/elevated_session.py:38          elevated_readonly_session（窄提權樣板）
~/Projects/Jedicogy/module/jedi-python-package/jedi-iam/jedi_iam/api/routes/otp_route.py:53           OTP QR 端點（改完要驗）

怎麼修

• ① 先驗前置：git log 看到 CM-1767 的 commit、grep is_system_context 在 jedi-common 有命中。沒有就停下回寫。
• ② db.py：is_super = user_ctx.is_system_context or _session_paths_have_root(user_ctx.allowed_tenant_paths)。不動 elif is_pg: 無 context 那條（那是第一刀 CM-<第一刀卡號>，延後）。把「無 tenant_id 的系統情境亦為 super_admin」那行過時註解收掉。
• ③ signed_token.py：_set_minimal_context(user_id) 改成：用 elevated_readonly_session() 包一句查 user（by uid），拿到 UserDTO 後呼叫 build_user_context(user, tenant_id_override=None) 設 context。先查再寫：build_user_context 需要 user 含 tenants／org_units，確認 elevated 查法能 load 到；不要另寫第二套組裝。user 不存在 → 401，不要 fallback 成 super。
• ④ 手測四處 signed-token 用途（見核對段），OTP QR 是必壞必修的那條。

要寫測試

• jedi-common tests：tenant_id=0 且非 system context、路徑非 root → app.is_super_admin 為 'f'；tenant_id=None 同上為 'f'；is_system_context=True → 't'。
• 突變：把 not user_ctx.tenant_id 加回去 → 前兩個測試要紅。
• jedi-iam tests：signed-token 消費後 get_user_context().tenant_id 是該 user 的真實租戶、allowed_tenant_paths 非空。主專案 test/test_authz_signed_token.py 既有測試跑一次。