ARCH-4-followup-transit-live 第二棒（接線批）：ADR-012 TDX adapter 接進 Stage D-pre——預算閘下沉＋來源工廠＋端點提示＋末班車四態（1307 測試綠）¶

背景¶

第一棒（#408）落地 TdxTransitAdapter 但純 opt-in、未接線。本批把它接進排程生產路徑。核心矛盾：TDX 每金鑰 5 次/分鐘全域限速的真實阻塞 sleep vs ADR-002 同步預算——devil 前批 C1 已判「閘存在 ≠ 閘擋得住」為接線阻擋級前置。

架構（ADR-012，九項決策，全數 ）¶

• 預算閘：復用 L0-c SCHEDULING_IO_BUDGET_S 不新增第五層；三層檢查點（Day 迴圈頂端／D-pre 呼叫前／adapter 每次上游呼叫前）；關鍵語義「限速等待計入呼叫成本——會跨 deadline 即不 sleep、直接放棄」
• 降級：預算耗盡走 SC-8 既有三態省略 key；紅線＝絕不寫 departures=()（未查不得斷言無班次）
• 來源工廠：TransitSource{FIXTURE,TDX} 顯式 opt-in、預設 FIXTURE；TDX 無憑證仍建構＋WARN、絕不靜默回退 fixture（設定錯誤不得偽裝成「當地沒車」）
• 端點提示：TransitEndpointHint 來源中立；組裝層自既有節點物件建構、經 SC-6b 傳遞；缺 hint 誠實 miss 不臆測
• 其餘：negative caching＋單條網路級 WARN、service_date 逐字不變式、per-request 生命週期（單例化前必須補鎖）

devil 兩輪挑戰與修復（品質鏈完整）¶

第一輪設計挑戰後，第二輪對實作揪出兩條阻擋級（主協調者逐行親驗屬實）：

1. C1：閘只堵了限速器等待這一個閥門——OIDC token 取得與「免等待」快速路徑完全不受 deadline 約束，首次呼叫慢一點即可吃光全趟預算 → ADR-012 決策 2 修訂：閘涵蓋 adapter 每一個上游 HTTP 請求（含 token）、單次請求 timeout 收緊為 min(timeout_s, 剩餘預算)、新常量 TDX_MIN_REQUEST_TIMEOUT_S【低信心】
2. C2（安全相關）：預算短路清空 reverse anchor → 末班車終端約束靜默消失、與「本來就沒約束」不可區分，可能建議使用者排到趕不上末班車的行程 → 新決策 9／SC-14b：LastTrainConstraintStatus 四態（not_applicable/verified/inherited/unverified_not_prefetched）掛 DaySchedulingOutcome，否決臆測值填補；順帶接出 SC-8a Day 級訊號的生產出口（qa 獨立發現的既有缺口）

修復後 devil 聚焦復核確認 C1/C2 收口（含 429 退避重試 timeout 重算縫）；qa 兩輪簽核通過（補 12 條測試堵「斷言存在但打不到」缺口，含推進時鐘的假網路層——零耗時 mock 結構上測不到 C1 場景）。

驗收¶

• python -m pytest tests/ -q → 1307 passed, exit 0（#408 基準 1238 → +69；主協調者每輪獨立複跑）
• fixture 預設路徑零回歸；DaySchedulingRequest 欄位零變動（F-2 白名單未觸發）
• 全程離線假時鐘/假 adapter 驗證（本批依裁定不跑 live）

誠實界定（qa 簽核原文精神）¶

「管線接得起來」≠「使用者拿得到真實班次」：旅遊節點不是車站，站點比對命中率預期偏低——這是設計正確的結果（不得放寬比對門檻，那會產生物理錯誤的班次斷言）。正解＝「最近車站＋步行段」模型，列 followup（P1，決定可用性）。成熟度全數維持 。

殘餘¶

• station-mapping followup（P1）：POI↔車站映射模型——大眾運輸功能真正可用的關鍵前置
• 業主資訊項（待 PM 打包）：首次規劃多日大眾運輸行程時，受 5 次/分鐘限制，後段天數班次預期誠實取不到（第二次規劃因磁碟快取幾乎零呼叫）
• network-failure-signal（P2 暫緩）、ODPT/韓國源未開始、常量校準併 Q10-followup-j