2026-07-08・給 George、Eason。先說結論：四個包不是四份新工作，是同一條線。最重的三件（兩個 P0＋三套準則）PM 已經修好、附現成 patch——你們的工作是 review＋合併，不是從頭寫。每項任務都照「為什麼要改 → 改什麼 → 怎麼改」講清楚。
每項固定三段：為什麼要改（現在的行為、會出什麼錯）→ 改什麼（目標）→ 怎麼改（做法）。驗收與檔案路徑收在「做完的定義＋細節」。標籤：套現成 patch＝review＋合併；要動手寫＝照工單實作；部署／維運＝改設定或重部署。
公司名稱查詢服務現在是 404——現場輸統編查不到公司，demo 直接穿幫。而且它掛掉時會把「查無登記」寫進快取，之後修好了這些統編還是永遠查無（快取毒化）；稅籍庫就算查到，也沒把公司名稱帶回來，分公司、行號只有稅籍庫才有。
proxy 部回去；查詢改「經濟部工商庫＋財政部稅籍庫」雙庫交叉；快取只記「真的查無」。
重新部署 Cloud Run 的 gcis-proxy；worker 的稅籍 fallback 補回 company_name／location；只有「兩庫都明確查無」才寫入 company_cache，網路錯誤一律不寫。
?tax_id=88432799 查得回公司資料SIIR 送審文件已經宣稱有這個功能（查核點 T200／G-05／G-06），7/13 現場委員會要看——正式版沒有＝當場穿幫。George 之前問的「三套準則要怎麼做」就是這項。
財報頁加準則選擇器（商業會計法／EAS／IFRS for SMEs）＋準則徽章與副標，以及「跨準則差異分錄試算」分頁（現場要能看到折舊差異：商會法/EAS 24,000 vs IFRS 30,000）。
不用從頭寫：patch、完整 diff、規格書都在交付包 03 資料夾（前後端已做過真整合測試）。套 patch → review → 合併 → 部到現場機。demo 主秀「差異試算」分頁（報表切準則只變標示、數字不重算——這是誠實呈現層）。
feat/accounting-standard-switch 合併並部署（base：backend 610b940／frontend 181d0dc）config/accounting_standards.php。7/13 現場要展示 etax-rpa 自動申報全流程；step7（上傳）的座標版沒在現場那台機器驗過，當場點不動就難看。
etax-rpa 的 step0 到 step7 在現場那台 Windows（BLR）完整跑通一次。
實機演練＋座標校準，照工單 08 的步驟；若跑不通，提前回報 PM 換 demo 方案，不要拖到現場。
檔案代理拿到 path 就給檔，不驗這個檔是不是你的——任何一個登入者把網址參數換成別人的檔名，就能列舉下載全站發票掃描圖（統編、金額、買賣方，全是 PII），直接踩個資法。
檔案存取加「擁有者檢查」，檔名改成猜不到的。
patch 已寫好：用既有 ocr_logs 反查檔案屬於誰＋path 白名單＋新檔名改 uuid4。套 01 資料夾 patch → review → 合併。⚠️ 部署 gate 不做等於沒修：prod 要開 OCR_IAM_VERIFY_ENABLED=true＋OCR_IAM_AUDIENCE（或 Cloud Run --no-allow-unauthenticated），並清掉 uploads/ 既有的舊 timestamp 檔。
fix/p0a-ocr-file-idor，git am 套 patch（conflict 就改 git apply --3way）。base：backend 610b940／ocr-service 1739e9e。計算層用 OR 分兩桶：bill_type=input 或 invoice_type 開頭 4010 → 進項桶；output 或 4011 → 銷項桶。上游 OCR 有系統性錯誤會產生「bill_type=input 但 invoice_type=40111」的自相矛盾發票——兩桶都中，同一張同時算銷項又算進項：401 銷項稅虛增、應納稅額錯，還寫進匯出的申報檔。三聯式是最主流進項憑證，幾乎每個真實用戶都踩到。
分桶從 OR 改成互斥——一張發票只可能落一桶。
patch 已寫好：新函式 resolveBillDirection() 以 bill_type 為單一準據（與統計卡同口徑），bill_type 缺漏才用 invoice_type 推定；進項桶內誤帶的銷項碼 deterministic 折回 4010x；附 4 個回歸測試。套 02 資料夾 patch → review → 合併。
fix/p0b-input-tax-double-count，套 02-P0B-三聯式雙重計數/ 的 patch。申報 PDF 和媒體檔放在 public 路徑——不用登入、直接打網址就能下載別人的申報資料。
檔案移出 public，改由帶權限檢查的端點供檔。
檔案搬到 private disk，下載走授權 API（比對檔案擁有者才給），照工單 01 的規格。
/storage/<路徑> 回 403/404；B 的 token 取 A 的檔回 403。辨識一張要 7.6 秒，用戶拍完照得乾等；現在用的模型還開著 thinking，白花時間。
預設模型換 gemini-2.5-flash、關掉 thinking，速度進 2–3 秒。
ai_service.py 改預設模型＋thinkingBudget:0（基本上改一行設定），改完抽 10–20 張對比，確認準度不掉。
沒有常駐實例，冷啟第一張要等 16.7 秒；而且 prod 還在跑 Flask 開發用 server，扛不了併發。
服務常駐（不再冷啟）＋換正式的 WSGI server。
Cloud Run 設 min-instances=1／cpu 2／memory 1Gi／concurrency 8；Dockerfile 從 Flask dev server 改 gunicorn。
金流商審核會看隱私權、服務條款、退費政策和公司揭露——網站缺這些，送審直接退件。
三個政策頁（隱私／條款／退費）＋footer 公司揭露（含統編）。
3 個 patch 已寫好：frontend repo main（base 181d0dc）開 branch → git am smarttaxer-patches/*.patch → 合回 main（push 即 GitLab CI 自動部署）。改完長什麼樣，包裡有 4 張截圖可對照。半小時內能收工。
npm run build 過。同樣為了金流送審；而且站上法人名稱新舊混用（「offcode 離碼」vs「你的空間有限公司」），審核方會質疑收款主體是誰。
① footer 加公司揭露（你的空間有限公司／統編 83772050／地址／電話）② 隱私政策法人名統一 ③ 新增免登入的 /refund 退費頁 ④ 服務條款帶正式法人名。
需求書含可直接貼上的文案（退費政策有全文）。repo 在你們手上；不方便做的話，把 GitLab 帳號 lgscvb 加 collaborator，PM 開 MR 給你們 review。
精靈 Step4→5 會卡死；而且沒有完成度檢查——空資料也能一路按到送出申報。
每一步加完成度 gate、擋空資料送出，並排查 Step4→5 卡死的原因。
照 SIIR工程師交辦包-20260706-稽核工單/09-P0-稅額雙重計數與申報精靈gate.md 後半的規格逐步做。
稽核抓到六個上線後會出事的風險：登入零限流（可無限暴力試密碼，實質偏重、別排最後）、/ocr/* 越權、免稅進項幻影 5%（會短漏報稅）、RPA 重複送件、媒體檔沒進 GCS、精靈換期不清狀態。
六項逐條修；順手確認 prod 的 APP_DEBUG=false。
照 SIIR工程師交辦包-20260706-稽核工單/10-上線前深度稽核-資安與稅額與送件.md，每條有 file:line 與修法。
現在一張圖丟給 Gemini 一次呼叫同時猜「這是什麼票」＋「所有欄位」，所有憑證共用同一份 schema——種類猜錯、欄位跟著全錯；收據、車票這種沒稅額的被套上發票語意，誤標應稅、誤發紅旗。QR code 有解，但只是辨識完的事後覆蓋，不是最上游。前端拍照入口難找、失敗沒引導。
辨識拆兩層：第一層只判「這是哪種憑證」，第二層按種類抽欄位；信任鏈翻正成 QR ＞ 確定性規則 ＞ 模型；前端補拍照入口／進度／錯誤引導／稅金鎖定。
QR 解碼層置最上游（有 QR 直接取權威值）；無 QR 讓模型做「單選題」分類，信心低丟回給使用者選；第二層按類型各走欄位集與金額語意（三聯式未稅分列、二聯式含稅內含、收據不勾稽不紅旗）。06 是 04／05／07 的共同前提，先做 06。細節：7/06 包工單 04–06。
① 進銷項還是模型說了算——統編比對只在模型沒給值時才跑，模型錯就整筆反向（真實案例：停車費收據買方明明是本公司，Gemini 說 output 就被判銷項）。② 金額交叉驗證 ocr-service 端其實已經做了（220 張紅旗從 196 收斂到 3），但紅旗傳到 backend 入庫就被丟掉——DB 不存、前端不顯示，錯帳靜靜流進分錄和 401。③ 公司名稱查詢的 worker 修正要同步進正式版。
① 進銷項改「統編優先」：七條決策樹當主判定（賣方統編＝客戶→銷項、買方統編＝客戶→進項……依序命中即止），模型排最後，每筆修正留軌跡。② 驗證紅旗活著走完全程：存進 DB、確認頁用四符號標示（✓一致／－推算／－不適用／✗不一致），讓人只盯 ✗。③ 雙庫查詢＋快取修正進正式版。
照 7/02 包規格 01／02／03 實作。②的 ocr-service 端已完成，只剩 backend 的 PHP normalizer 保留 validation 欄位＋前端顯示；③等 A-1 的 gcis-proxy 修好後做。
統編檢查碼演算法有，但驗不過只丟一句 warning、錯的原值照存不修——熱感紙發票 0 被讀成 8 這種，明明救得回來。而且同一套正規化邏輯 Python（ocr-service）和 PHP（backend）各刻一份，改一邊忘另一邊，兩條路遲早算出不同結果。
從「只會挑錯」變「會自動救回」；兩份邏輯收斂成一份。
OCR 易混字（0↔8、1↔7、5↔6…）窮舉候選 → 打登記庫驗證存在 → 唯一解才自動救回，多解／無解保留原值並標註；正規化以 Python 為單一事實源、PHP 只消費結果。（登記庫要用哪個資料源，先跟 PM 確認再動工。）細節：7/06 包工單 07。
照時間看就懂：先開問題清單，後面的包把最重的活做成了現成解法。
最早的交辦：7/13 現場急件第一次提出＋三份 OCR 後處理規格。急件部分已被後面兩包細化（看本頁 A 層即可）；三份規格還有效＝本頁 D-14。
上線前稽核抓到的問題清單（工單 01–10，分 P0／P1／P2／急件）。本頁 A、B、D 層的原始工單都在這包。
現成解法：PM 把最重的三件（P0-A 個資外洩、P0-B 算錯稅、三套會計準則）在本地修好並通過獨立驗收，以 git patch 交付、未 push。對應 7/06 包的工單 09、10-A 和急件 8-1——這三項不用從頭寫，套 patch → review → 合併。
獨立支線，跟上面互不相依：兩個站要申請金流，送審前補公司揭露／政策頁。smarttaxer 已附現成 patch；good-aidea 要動手改四處（文案都寫好了）＝本頁 C 層。
*-patches/ 資料夾。git status＋git pull，確認 branch 沒落後。git apply --3way 配同資料夾的 *-完整diff.txt；再不行直接丟訊息給 PM，不要硬解。