本卡屬 FR-080（母卡 CM-1612），第 5 棒：app 與 domain 層（jedi monorepo）。只掃不修。⚠️ 40 檔略超 30 檔尺，見下方說明。

這一棒在做什麼（白話）

掃問題單的業務邏輯層（40 檔）：建單、改單、查單、標籤、成員、附件的流程編排，以及誰能做什麼的判斷。

⚠️ 檔數說明（40 檔，略超尺）

每棒 ≤30 檔是實測邊界（FR-078 兩棒 30／18 檔面板完整跑完，FR-077 的 42 檔全滅）。本棒 40 檔在兩者之間，是刻意的一次邊界測試：app/ 與 domain/ 拆開會把「用例編排」與「業務規則」切在接縫上，而權限漏洞正是活在那裡（手冊第一節「不要按 DDD 分層水平切」）。

🔴 若面板未完整跑完（stamp verification.status 不是 verified，或 incomplete_panel_candidates > 0），不要重跑整棒——回報首腦，由首腦決定是否拆成 app/（22 檔）＋domain/（18 檔）兩棒。40 檔中有 18 個是空的或極短的 __init__.py，實質內容約 22 檔，實際負擔比數字小。

重點看什麼

• 🔴 檔頭自陳不可信。 jedi_issue/api/__init__.py:11-13 自稱「GitLab／GitHub 整合沒在用，約佔 58%」——首腦已證偽（宿主 feedback_service.py 六處實際呼叫）。工具已知盲點二（會被註解說服）的教科書形狀，FR-075 S2 即此。本套件 docstring 一律當待查證的宣稱。
• ① 授權判斷在哪一層、有沒有。 app/issue/service/issue_service.py（105 行）、app/project_member/service/project_member_service.py（103 行）、app/member/service/member_service.py（75 行）、app/label/service/label_service.py（64 行）、app/issue_attachment/。要追：這些 service 有沒有任何權限檢查，還是全部外包給宿主。若是後者，而宿主只有一道 @jwt_required()（見 I2 ⑥／I4 ①），就是整條鏈沒有授權。
• ② 歸屬檢查。 改單／刪單／改標籤／改指派時，有沒有驗「這張單是不是你的／你的租戶的」——FR-079 F16 就是「只驗你能不能改，不驗這是不是你的」，本專案已知會重犯。
• ③ provider 參數怎麼流。 issue_service 的方法多半吃 provider= 決定走 LOCAL／GITLAB／GITHUB。要追這個值從呼叫端一路傳下來的過程有沒有被驗證（與 I4 ⑤、I1 呼應）。
• ④ @transaction 與 session 紀律。 CLAUDE.md 鐵則：app service 每個 public method 都要 @transaction，repo __init__ 不可 get_session()。要查有沒有違反（違反的症狀是 500，但也可能是跨請求共用 session 的併發問題）。
• ⑤ domain/ 三個子域（member／label／issue_upload_file 各 7 檔）的 repository interface 與 domain service。要追業務規則（狀態轉換、標籤合法性、成員資格）有沒有可繞過的路徑。
• ⑥ 查詢條件的組裝方式。 FR-079 的重點 ④ 在本專案是通病——_gen_filters() 型的「拿物件 __dict__ 當白名單」動態組裝，配上收 **kwargs 的 query entity，會讓呼叫端的鍵變成查詢條件。要查 domain／app 層有沒有同款。
• ⑦ 租戶隔離。 這些 service 有沒有任何 tenant 概念？還是完全靠 DB 的 RLS？若是後者，要在報告中明講「隔離的唯一防線是 RLS」，那是 I6 棒與 DB 查證的事。

怎麼做

第一步：確認主 session 是 Opus 5 (1M context)（不是 Sonnet），並讀過首腦手冊第二節。

第二步：驗 scope 檔數，對上 40 才啟動：

cd ~/Projects/Jedicogy/module/jedi-python-package/jedi-issue && \
  git ls-files -- jedi_issue/app/ jedi_issue/domain/ | wc -l

（40 檔中有 18 個是空的或極短的 __init__.py，實質約 22 檔。數字對上 40 即可。）