真實資料端到端試跑批（FT-1~FT-14）＋ ADR-014 fieldtest 產物 C-7 落地與既有違規止血¶

背景¶

至上一批（#417）為止，排程鏈、TDX 真實 adapter、車站映射兩棒全部完成，但從來沒有人看過這套系統用真實資料跑出來的完整行程長什麼樣。ARCH-2-followup-l 結案時明文把「tps 真實資料排程複核」延後至「live 資料上量後一併」——本批兌現該延後項。

順序判斷（architect 同意但理由更強）：試跑先於 ARCH-5 呈現層。ADR-012／ADR-013 已把四項 ARCH-5 呈現義務定為上線前置，而那些文案的優先序與密度取決於真實輸出中各狀態的實際分布；先做 ARCH-5 等於對著臆測的分布設計。但反向界線同樣寫死：試跑結果不得成為 ARCH-5 的規格來源——義務清單已由 ADR 定死，不因試跑增刪。

變更內容¶

一、試跑執行（engineering-fieldtest）¶

• 場景：4 天 3 夜、2 Destination（台北車站周邊 → 九份）、Day1 抵達日／Day2 純中間日／Day3 轉場日皆大眾運輸、Day4 離開日自駕。住宿手動注入，明文禁止啟動住宿爬蟲管道（避免 7~9 分鐘量級雜訊灌進 wall-clock 使耗時觀測失去解析力）。
• 結果：1 次完整冷啟動執行、exit 0、wall_clock 5.03s、零程式碼缺陷；另 1 次窄範圍 TDX 暖態探針滿足冷/暖分列。
• 呼叫：Google 38 次（Geocoding 4／Nearby 4／Place Details 30，全 200 OK，未超單次 ≤45、全批 ≤70）；TDX 資料 4 ＋ token 1（未超 ≤12／≤4）。成本外推 Enterprise 30~45%，未達 FT-2 的 70% 降級觸發線。
• 未做第二次完整執行——無真實缺陷需「修正後驗證」，且 38+38=76 會超全批預算。

二、ADR-014：fieldtest 產物的 C-7 落地（起因是逐檔核實發現的既有違規，非預防性設計）¶

• 原始 API 回應 → gitignored 本機保留（否決「就地遮蔽」：遮蔽清單是白名單的反面，Google 新增欄位即靜默漏網；否決「完全不落地」：ARCH-2-followup-l 的全部價值來自對照原始 JSON 才發現的 field mask bug）。
• RESULTS.md 可寫／不可寫封閉清單；tps 領域複核走本機 raw 檔＋匿名識別回寫（否決「為可讀性例外允許名稱」——該例外無自然邊界）。
• 不新增 constraint：全部內容是 C-7 既有字面在新載體上的操作化（版控＝永久儲存），同 DM-S1 之於 trip JSON。

三、既有 C-7 違規止血（業主已拍板 (A) 案）¶

• git rm --cached 移出 11 檔（arch2-followup-l/raw_output/ 8 ＋ raw_output_round1_403/ 3），本機保留。
• .gitignore 新增 experiments/*/raw_output*/，註解明寫理由為 C-7 而非體積（既有 TDX 那條寫的是體積，沿用同款措辭會讓未來有人為了「這個檔很小」移出忽略清單時不察覺），並補「非 Google 來源需 git add -f」使例外留痕。
• 止血後發現擴散更廣：arch2-followup-l/RESULTS.md 正文本身（第一次止血只處理 raw JSON、漏查正文）、以及 ADR-010 治理文件正文皆含真實 POI 名稱與營業時間原值 → 均已改為結構性描述，技術結論零損失。
• 真正的擴散路徑是「引用」而非「產出」：Content 被人從 raw_output/ 摘抄進論證裡。ADR-014 決策 3 射程因此由「fieldtest 產物」改為「版控中的全部檔案」，判準改繫在載體而非產物類別。
• 已界定非射程項：agent 憑訓練知識構造的假想例歸鐵則 3，避免稽核把 C-7 擴張成「文件不得出現地名」而讓真違規淹沒在偽陽性裡。
• 業主決策紀錄含條件性觸發：repo 經確認 PRIVATE／0 fork，(A) 案成立；若日後轉公開，(A) 案即失效，須在轉公開前重評。

試跑推翻的三項認知（本批最大價值）¶

1. architect 的高信心預測落空，機制完全不同¶

FT-11 (1) 預測「L0-c 預算在 3 個大眾運輸日冷啟動下耗盡」——未發生。真實機制是 exempt-pair 過濾使某些日對 TDX 的請求量結構上為 0。

工程初次歸納「walkable 節點數 < 2 則零查詢」，architect 逐行核實後更正為「非豁免節點數 < 2」——三種 UNRESOLVED_* 不在豁免集合、照常組對查詢。本次兩者恰好相等（29/29 全 resolved），但一般不等；推廣成 walkable 版會在站點稀疏的非都會區系統性低估呼叫量——那裡 UNRESOLVED_NO_STATION 多、非豁免節點反而多。即原歸納在最該擔心的場景下方向是反的。

→ ADR-012 已知弱點 1：上界不變、「必然發生」措辭撤回。不得據此認為 L0-c 預算已驗證充足（三層閘零觸發、未受壓力測試）。

2. 工程的「composition root 缺口」定性被推翻（主協調者抽查確認）¶

AccommodationSelection 恆空 → 4 天末班車狀態恆 not_applicable 是事實，但不是缺口：ADR-011 決策 6 標題逐字寫著「不併入 build_trip_with_itinerary」，業主拍板「選定＝使用者點選確認制，系統不自動代選」。正確序列是三步：build_trip_with_itinerary() → select_accommodation() → reschedule_days()。

真正的錯在 architect 自己寫的試跑協定：FT-7 要求觀測五態，但指定的執行方式結構上只可能產出 not_applicable——它要求了一個自己已裁定為不可能的觀測。下批試跑協定必做：要觀測 SC-14b 非 not_applicable 態須跑滿三步；單呼叫該入口的結果一律不得記為「未觸發」（會讓讀者誤以為是機率性未命中）。

3. tps 的因果方向被推翻，且方向錯了會導致反效果（主協調者已驗證表值）¶

tps 判定「dwell 扁平化系統性推高負載」。逐值核對：13 個景點 key 中 ≥60 有 10 個、>60 有 6 個（theme_park/amusement_park 各 240、museum/zoo 120、art_gallery/aquarium 90），<60 僅 3 個 → 把景點全壓成 60 更可能是低估 → 接線後超載可能更嚴重而非緩解。若照原方向行動（放寬 PACE_PROFILE），會使超載更嚴重。

新發現的規格層缺口¶

• dwell 全 60 零變異＝「設計了但生產路徑到不了」家族第五例：DWELL_DEFAULTS_BY_PLACES_TYPE 表確實被查了，但 field mask 從未請求 types／primaryType、schema 無承載欄位 → 每次必然退回粗值，而 _attraction_default／_restaurant_default 恰皆為 60。淨效果：12 個細分 key 在生產路徑上從未生效。（家族計數經 architect 更正為第五次而非第六次——「同一家族第 N 次」的論證若計數不準，本身就會失去說服力。）
• opening_hours 缺失 → 景點零硬窗，是結構性保證而非邊角：POI_CANDIDATES_PER_DAY(10) × 天數 > POI_DETAIL_ENRICHMENT_SOFT_CAP(30) ⟺ **天數 > 3**（兩常量值已獨立驗證）。任何 4 天以上行程都必然有節點在無營業時間資料下被排入。與 ADR-010 已知弱點 1 同一種錯誤形狀：兩個各自合理的常量，比例關係把「例外處置」變成「常態路徑」。維持不加杜撰門檻（ADR-010 決策 8 已兩度否決，壞例子不提供新的來源依據）；補記決策 8 當初漏掉的第三案（未 enrich 者不排入行程），本批不裁定採否。
• 逐日候選選取不感知類別／日容量／enrich 上限（單一決策面，三項合併）：select_poi_candidates_for_day() 僅依距離＋原序取前 10 筆 → 10 個名額可全給餐廳；Stage E 下游確實依日身分折算容量但選取層不讀它。下游 _insert_restaurant_two_pass 無 bug——兩個各自正確的機制疊起來產出不合理行程。明確不採「加 MAX_RESTAURANTS_PER_WINDOW」（下游補閘擋上游送太多，且與趟 2 band-permissive 語義衝突）。
• transit_adapter 單插槽：注入真實 TDX 後自駕段必然全部 Tier 3（過去全 fixture 批次中結構上不可見）。明文禁止試跑批臨時打造 composite adapter 掩蓋它。
• FT-7 (16) 停車觀測落點錯誤：本專案從無 node_type="parking"，Parking 是掛在節點上的子物件欄位——「零 parking 節點」是在不存在的地方找東西，其為 0 不承載任何資訊。architect 誠實分類為自己的 FT-7 規格債。

驗收標準¶

• 試跑 1 次冷啟動 exit 0、wall_clock 5.03s、全部預算未超
• python -m pytest tests/ -q → 1426 passed（未改任何生產程式碼，僅新增 experiments 腳本）
• C-5 金鑰雙查通過（機械掃描＋人工複查，零洩漏）
• C-7 閘機械驗證：git add -n experiments/e2e-live-fieldtest/ 僅 3 檔（RESULTS.md＋2 腳本），raw_output/ 確實被擋
• 全庫掃描 Huashan|Linjiang|Raohe|Taipei Zoo → 0 命中（止血後復查）
• FT-7 十七項觸發矩陣逐列標「觸發／未觸發／fixture」，未觸發者一律不得描述為「已驗證」
• FT-11 十項預測逐項對照，3 項誠實分類為機制理解錯（非運氣）
• tree 節點：ADR-014 新增、ADR-013 補「exempt 機制 → ADR-012 呼叫量算術」Reversal 邊、兩者轉 verified

成熟度與封頂（全部 ，本批零 升級、零降級）¶

• tier=engineering-fieldtest，依接地上限條款封頂 。ARCH-4 ／ARCH-1 ／ARCH-2 全維持。
• weekday 自檢首次取得鑑別性樣本（21/28 非均勻班表、has_malformed_periods 0/28）——升級誘因已明確擋下，僅允許措辭由「無鑑別力樣本」改述為「已由 21 筆具鑑別力樣本通過帳號內執行期自檢，仍為 IN-ACCOUNT 證據」，自檢分支不得移除。
• 場景刻意構造（選「台北車站」而非「台北市」是為讓 walkable 路徑真被觸發；選九份是為保證取得豁免樣本）→ walkable／豁免比例絕不得被引用為真實命中率，這是最容易被誤用的數字。
• 新增封頂聲明：ARCH-5 未實作且 EnrichmentSkippedDiagnostic 目前無任何消費者 → 今日實際狀態是「4 天以上行程必然含無營業時間保護的節點，且無任何使用者可見標記」；在 ARCH-5 上線前不得宣稱行程對營業時間撲空有保護。
• 「大眾運輸功能對使用者可用」仍不成立（ADR-012 已知弱點 3／ADR-013 已知弱點 9 逐字有效）。

衍生 followup（8 條入 open-questions）¶

ARCH-2-followup-places-types-sku（P1，須 research agent 查證，擋住 dwell 細分表＋夜市偵測兩條線；architect 明說「我無查證能力」且不得憑印象歸層）／ARCH-1-followup-dwell-signal-wiring（含 gate 邊界與二選一解除條件，防死鎖）／ARCH-2-followup-poi-candidate-allocation（三項合併，須 devil；含「業主『餐廳全列不套門檻』管的是呈現不過濾、不等於排程不限數量」的明文界線）／ARCH-1-followup-enrichment-coverage-ratio／ARCH-2-followup-fieldtest-artifact-audit（射程已擴大至全庫）／ARCH-4-followup-driving-source-adapter／ARCH-1-followup-accommodation-anchor-entry-alignment／ARCH-4-followup-exempt-pair-call-volume-transmission＋FT-7-16-parking-observation-redo、ARCH-4-followup-station-mapping-scope-note