還有一個附帶觀察：domain/service/bulletin_domain_service.py:16-19 的 if _filter.auth: 分支會強制覆寫 enable=1 與兩個時間旗標，而 auth 的預設值是 False。也就是說**「只顯示當前生效的公告」這個限制是呼叫端自願開啟的，不是伺服器強制的**——套件層這樣設計合理（它不知道業務規則），但這正是 B2 重點 ③ 講的那件事在套件端的源頭。

④ 五個方法各自 new 一份 repo，繞過建構子注入——有沒有因此跳過某層處理？

有結論：沒有跳過任何處理，但這是真的重複、且讓注入形同虛設。（人工核對）

get_bulletins（:35）、get_bulletin（:44）、add_bulletin（:51）、update_bulletin（:61）、delete_bulletin（:71）各自 BulletinDomainService(BulletinRepoImpl()) 就地新建，只有 get_bulletins_and_pager（:21）用了 self.bulletin_domain_service。

新建的那份與注入的那份走的是完全相同的類別與路徑，沒有任何一層被跳過，所以沒有資安後果。但後果有兩個：①建構子注入形同虛設——想換一份 repo 實作（測試用 fake、加了審計的 wrapper）對六分之五的方法無效；②BulletinService 的建構子參數看起來是契約，實際上不是。屬於設計債，不是漏洞。

⑤ add／update 的手寫欄位搬運——漏了什麼？

有結論：update() 有一個會當場崩潰的真 bug，且不覆寫 is_delete、無歸屬檢查。（人工核對，見上表 M1／M3）

M1（LOW）— 更新公告時檢查錯了對象，查無此筆會當場崩潰

Impact. 對套件版 update_bulletin() 傳一個不存在的 uid，該次請求 500 崩潰。不是資料外洩、不是權限繞過，純粹是錯誤處理寫錯。

Where. jedi_bulletin/infra/repository/bulletin_repo_impl.py:56

What. 第 55 行查出 bulletin_model，第 56 行卻寫 if not bulletin:——bulletin 是傳進來的參數（前一行第 52 行才剛檢查過它的 uid），不是查詢結果。查無此筆時 bulletin_model 是 None，而 bulletin 是個有效物件，所以檢查通過、繼續往下，第 59 行 bulletin_model.title = ... 直接 AttributeError: 'NoneType' object has no attribute 'title'。

Preconditions. 需要有人呼叫套件版的 update_bulletin() 並帶不存在的 uid。現階段沒有任何呼叫者——主專案走自己那支 app/bulletin/service/bulletin_service.py。所以目前無法觸發，這是它嚴重度只有 LOW 的唯一理由。

Fix. if not bulletin: → if not bulletin_model:。一個字的修正。

M3（INFO）— update() 不覆寫 is_delete、也不做任何歸屬檢查

update()（:59-65）覆寫 title/content/category/enable/release_time/expire_time/updated_user 七個欄位，不動 is_delete——這其實是對的（軟刪除旗標不該被一般更新順手改掉，否則更新一次就會把已刪的公告復活）。而 filter_by(uid=...) 拿到就改、不看歸屬，是套件層刻意不做安全決策的設計，真正要回答「能不能改別人的公告」的是宿主，屬 B2 範疇。

另外 add()（:36-46）沒有設定 tenant_id / org_unit_id——這兩個欄位靠 jedi-common 的 before_flush 事件（db_mw.py:63-85）從 user context 自動填。沒有 user context 時不會填，而 DB 的 tenant_id 是 nullable=False，結果是 NotNullViolation——同樣是「炸」而不是「寫進錯誤的租戶」，行為上安全。

⑥ add_bulletin 用 get_user_context().uid——無 user context 時會怎樣？

有結論：會 AttributeError 崩潰，不會寫進 NULL。（人工核對，見上表 M2）

jedi_common/session/auth/auth_context.py:17-22：get_user_context() 在 context 為空時回 None（那行 raise RuntimeError 被註解掉了）。所以 bulletin_service.py:50 的 get_user_context().uid 在背景執行緒／排程情境下是 AttributeError: 'NoneType' object has no attribute 'uid'，:62 的 update_bulletin 同樣。

這是好消息不是壞消息：崩潰比「靜默寫入 NULL 建立者」好得多——後者會讓稽核軌跡出現無主資料且無人察覺。建議修法是明確拋業務例外（帶 error code），而不是讓 AttributeError 冒到 500。

語意差異確認屬實：套件版存的是 user_context.uid，主專案版存的是 login_name。而主專案的 ExtendedBulletin（infra/bulletin/models/bulletin.py:47-57）用 created_user == User.login_name 做 relationship join——若哪天真有人改用套件版的 service 寫入，存進去的 uid 會讓那個 join 永遠對不上，created_user_name 全部變 None。現階段無害（沒人用套件版），但這是一顆埋著的地雷，值得在 README 註記。

⑦ tenant scope 掛了，但生效嗎？兩個 model 疊同一張表會不會失效？

有結論：RLS 四條 policy 都在、欄位對得上，疊加不影響。但有一個 import 時序的隱性前提。（人工核對 ＋ DEV DB 唯讀查證）

DEV 庫（guidant_ai_dev）實查（唯讀 SELECT，未做任何異動）：

bulletins | rowsecurity = t
bulletins_select | r | is_super_admin OR app_tenant_allowed_for_session(tenant_id)
bulletins_update | w | is_super_admin OR app_tenant_allowed_for_session(tenant_id)
bulletins_delete | d | is_super_admin OR app_tenant_allowed_for_session(tenant_id)
bulletins_insert | a | WITH CHECK: app_tenant_allowed_for_session(tenant_id)
                       AND (org_unit_id IS NULL OR app_org_allowed_for_session(org_unit_id))

四條齊全。INSERT 那條的「不對稱」是設計不是缺陷——INSERT 沒有 USING 子句（沒有既存列可檢查），只有 WITH CHECK，而且它比其餘三條更嚴格（多驗了 org_unit）。FR-079 README 引用的 migration 註解說它「與其餘三支不對稱」，實查結果是這個不對稱方向是安全的。

兩個 model 疊同一張表沒有問題：ExtendedBulletin（主專案）用 extend_existing=True 加的是 relationship 與 hybrid_property，沒有動任何實體欄位；tenant 欄位由 TenantScopedMixinModel 提供，兩邊都掛了同一個 mixin，欄位定義一致。

但有一個隱性前提要記下來：TenantScopedMixinModel 的 tenant_id / org_unit_id 是 @declared_attr，在 class 定義的當下讀 ENABLE_MULTI_TENANT 環境變數決定要不要產生欄位（jedi_common/session/database/model/tenant_mixin_model.py:11-22）。也就是說：任何 import 這個 model 的程式，若在 import 之前沒設好該環境變數，ORM 端就沒有 tenant 欄位，而 DB 端的 NOT NULL 與 RLS 依然在——症狀是寫入時 NotNullViolation，非常不直觀。BE 的 .env 有 ENABLE_MULTI_TENANT=true，harness 也在 import 前 setdefault（dev_app.py:40），現況都對。這是「會靜默失效的設定相依」，值得寫進 README 而不只留在 harness 的 docstring 裡。

⑧ 🔴 generate_uuid 是不是密碼學等級隨機？（卡片指定必答）

有結論：是。用的是 uuid.uuid4()，不可預測。（人工核對，卡片要求即使工具沒報也要看）

# jedi_bulletin/common/utils/common_util.py:1-5
import uuid
def generate_uuid():
    return str(uuid.uuid4())

uuid4 在 CPython 的實作是 os.urandom(16) 取 122 bits 隨機（其餘 6 bits 是版本與變體標記），走作業系統的 CSPRNG。不是 uuid1（含 MAC 位址＋時間戳，可預測）、不是時間戳、不是序號。

infra/models/bulletin.py:22-28 確認 uid 欄位的 default=generate_uuid，也就是每一則公告的 uid 都是這樣產的。

這條的跨棒意義：B2 的重點 ② 指出「單筆讀取只靠 uid、不做任何範圍檢查」。若 uid 可預測，那條路徑等於「任何人都能列舉全部公告」，會是 HIGH；現在確認 uid 是 122-bit 的密碼學隨機，列舉不可行，那條路徑退化成「必須先取得某個 uid 才打得到那一則」——B2 該條的嚴重度應據此下調，但不歸零：uid 會出現在列表 API 的回應裡、也會出現在網址上，「合法看得到列表的人事後仍能讀到已被移出可見範圍的那則公告」這個問題依然存在。

⑨ common/enum/code.py 有沒有把內部資訊帶進對外訊息？

有結論：沒有。但這整個檔案是與公告無關的殘留複製品。（人工核對）

全檔 38 行，六個常數類別：UserStatus、LogTypeCode、RoleStatusCode、EnableCode、DeleteCode、ChangePasswordTypeCode、ChangePasswordStatusCode。全是整數常數，沒有任何字串訊息、沒有表名、沒有 SQL、沒有路徑——不可能洩漏內部資訊。

但值得記一筆：這個套件叫 jedi-bulletin，而這個檔案裡有 ChangePasswordTypeCode（改密碼流程）、UserStatus（使用者狀態）、RoleStatusCode（角色狀態）——全部與公告無關，明顯是從別的套件複製過來的殘留。實際被用到的只有 EnableCode / DeleteCode 的語意（而且程式裡是直接寫 1 / 0 字面值，連這兩個都沒真的 import）。清掉它是衛生問題不是資安問題，但殘留的複製品是「這個套件抽出來時抽得不乾淨」的訊號。

⑩ harness/dev_app.py 有沒有寫死憑證／debug 開關／會被誤帶進正式環境的設定？

有結論：有寫死憑證，但打不進發行包，面板判定不成立（C2），我認同。（工具報的 ＋ 人工核對）

完整分析見上方 C2。補充三點人工核對的結果：

• harness/ 確實不進發行包——pyproject.toml:38-41 只 include jedi_bulletin。裝了這個套件的產品拿不到這個檔案。
• dev_app.py:40 的 os.environ.setdefault("ENABLE_MULTI_TENANT", "true") 是唯一的環境變數寫入，用 setdefault（不覆蓋既有值），且這是 harness 專用進入點，不會被套件本體 import。
• 沒有 debug 開關：全檔沒有 app.run(debug=True)、沒有 FLASK_DEBUG。它只建 schema、跑一輪 CRUD assert、印結果，跑完就結束。

順帶查證了 plugin.py 檔頭的兩個自陳（卡片特別警告要獨立驗證，不可複述檔頭）：

這次的自陳是真的。 但要說清楚方法論：我是自己跑 grep 驗證得到這個結論，不是因為檔頭這樣寫就採信。FR-075 S2 的教訓（docstring 把真洞寫成「刻意設計」，研究員讀了就接受）在這裡不適用——不是因為檔頭可信，而是因為這次獨立查證的結果剛好與它一致。