公車到站時間預測：長期記錄歷史資料建立經驗式 ETA baseline（取平均只是起點）

[kiki830621]

Problem

Original text:
「我在想要怎麼最佳的推測公車什麼時候到，是不是長時間爬蟲記錄然後取平均」
— Source: 對話直接輸入（2026-06-03，延續 270 公車「9:24 經過南港」反推討論）

如何最佳化公車到站時間（ETA）的預測？目前 TDX 只給即時 snapshot（A2 車輛位置 / A1 到站預估）+ 班表 / 班距，沒有歷史——所以「過去某時某車在哪」只能用 kinematic back-projection 近似（見對話中 270 案例：靠現在位置 + 路線旅行時間反推，誤差 ±3~5 分、折返車無法追蹤）。

使用者提出的方向：長時間爬蟲記錄，然後取平均，建立經驗式的到站／旅行時間模型。

Type

feature（研究方向 / 路由引擎資料採集層；對應 North Star Stage 3+）

背景：為什麼這條路是對的

這正是 CLAUDE.md 北極星點明的「誠實天花板」——路由準度上限是資料形態不是演算法。NAVITIME 之所以準，靠的是實測資料（班次 phase + 即時誤點 + 站間實測旅行時間），不是祕密演算法。要逼近 NAVITIME 的公車／捷運準度 = 資料採集問題（補 phase 時刻表 + 站間旅行時間分布），屬 Stage 3+，不是改演算法能解。

所以「長期記錄 + 統計」確實是正路。但「取平均」是起點不是終點——下面是把它做對的設計考量。

「取平均」的天真版 vs 該做的版本

維度	天真版（單純平均）	該做的版本
統計量	算術平均	分位數（P50/P80/P90）。到站時間分布右偏（塞車是長尾），平均會被長尾拉高且無法表達「最壞情況」
時間分桶	全天混在一起	按 time-of-day（尖峰／離峰）、weekday/weekend、國定假日 分桶
空間粒度	只記端點到站	記 站間（segment）旅行時間，可組合任意 O/D 並偵測哪一段塞
情境變因	無	天氣、特殊事件（路線改道，如 issue 板上看到的扶輪年會 / 花季改道）、施工
不確定性	點估計	回傳區間（如「8–14 分，P80=12」），符合 CLAUDE.md「不假裝精確」原則

要記錄什麼訊號（待設計）

TDX 公車有多種即時 feed，各有取捨：

• A2（車輛位置 GPS）：最原始，可推站間旅行時間，但要 map-match 到站序。
• A1（到站預估 / 進站事件）：較高階，直接給「某車到某站」事件，適合建到站時間分布。
• StopOfRoute / 班表：靜態骨架，用來定義站序與名目班距。

開放問題（Open Questions）

1. 輪詢頻率 vs rate limit：TDX free tier = 50/min。要記多少路線 × 多少頻率才不爆？是否需要 per-city / per-route 取樣策略？
2. 儲存：時序資料量會快速累積。DuckDB / SQLite / Parquet？保留多久（retention）？
3. 記錄 host：MCP 本身是 read-only stateless，logger 應該是獨立常駐服務（cron / launchd / 遠端機器），不是塞進 MCP。
4. 回灌路徑：統計模型建好後，怎麼透過 tool 服務回去？新 tool（如 bus_eta_predict）還是讓既有 bus_status_arrivals 在 frequency-only 時 fallback 到歷史 baseline？
5. 冷啟動：記錄前無資料的路線怎麼辦？誠實標 source: no-history。
6. 驗證：怎麼量測預測準度？需要 hold-out 比對「預測 vs 實際到站」。

Impact

• 把目前「frequency-only 路線抵達誠實從缺」的缺口，用經驗 baseline 補上（source: historical）。
• 是路由引擎從 Stage 3 走向 NAVITIME 等級準度的關鍵資料層，影響所有 frequency-based 的公車／捷運段。
• 同時解鎖「歷史回放」能力（對話中 9:24 反推查不到的根因）。

註

這是設計 / 研究方向 issue，不是即刻實作。下一步建議 idd-diagnose 釐清 MVP scope（先記單一城市單一路線、A1 到站事件、DuckDB 落地、P50/P80 分位數）再談實作。

---

Current Status

• Phase: design-decided (discuss done, 2026-06-04)
• Complexity: Spectra（新子系統：A2 經驗 ETA logger + 模型 + 回灌 tool）
• Diagnosis: 見 comment（含 TDX 原料盤點 A2/A1/N1 + MVP 策略）
• Next: /spectra-discuss（對齊 MVP 門檻 / 訊號取捨 / schema / 回灌 surface / rate-limit 路線數）
• Hardware: NV3 2TB + PROBOX USB4 盒（已下單）
• Discuss: concluded → BCNF+SCD2 schema, Python-ingest/R-model/Swift-serve, 大臺北 capture-feasibility MVP; next /spectra-propose

[kiki830621]

Decision — 開放問題 #2（儲存）storage + 存取架構 baseline

討論脈絡：2026-06-03 對話釐清。使用者 mini 內建只有 256G（系統碟），且已持有一個 Thunderbolt 5 / TB4 的 M.2 2280 NVMe 外接盒（空盒）；想知道資料放 mini 後能否從另一台 Mac（Mac Pro）經 Thunderbolt 存取。

結論架構

角色	機器 / 媒介	用途
系統碟	mini 內建 256G	只跑 macOS + logger 程式，不放會長大的 log
主存（熱+全量）	TB 外接盒 + 1–2TB M.2 2280 NVMe	Parquet 全落這裡（city=/date= 分區），DuckDB 直查
運算節點	mini 本機	DuckDB query 在資料旁邊跑（compute-next-to-data）
遠端存取	Mac Pro 經 TB Bridge	SSH 進 mini 跑 query / 偶爾 SMB 搬檔
異地備份	Dropbox（已有）/ Cloudflare R2	冷備份第二份

採購

• 不用買盒子（已有 TB5/TB4 M.2 外接盒），只缺一條 1–2TB M.2 2280 NVMe。1TB ≈ 單城市全覆蓋十幾年。
• 選哪條無關痛癢：此 workload 瓶頸不在 SSD 頻寬（每分鐘幾 MB 寫、掃 GB 級壓縮 Parquet），測速榜首速度用不到。建議 Crucial T500 / WD SN850X（有 DRAM、可靠、價格甜），不必上 990 Pro。
• 耐久度(TBW)非問題：每年寫 ~100GB 等級，消費級碟數百 TBW 跑幾十年磨不壞。
• HDD 不要買：量級不到、SSD 體驗差太多。

多機存取（關鍵釐清）

• 外接 SSD 是單一 host 獨佔：同一顆碟同一時間只能被一台 Mac 掛載。不能用 TB 線把 mini 上的碟同時直接掛到 Mac Pro（硬掛會 corrupt）。
• 正解走 Thunderbolt Bridge（IP-over-TB）的檔案分享 / SSH，非 block-level 直掛。

SMB over TB Bridge 效能（為什麼 query 要在 mini 本地跑）

• 頻寬不慢：SMB over TB Bridge 實測 ~800–1,500 MB/s（比 10GbE 還快、比 Gigabit 快十倍）。循序搬整份檔案很 OK。
• 延遲會咬 query：DuckDB 掃 Parquet 是大量「seek + range read」隨機存取，每次 range read 走 SMB 都付一次毫秒級網路 round-trip（本機 NVMe 是微秒級，差三個數量級）。頻寬用不滿、卻卡在等往返。
• 定論：SMB 留給「偶爾抓整份 Parquet 回 Mac Pro 看」；日常分析一律 ssh mini 在本機跑 DuckDB、只回傳聚合後的小結果（分位數表，幾 KB）。compute-next-to-data 永遠贏。

一句話 baseline

mini = logger + 資料（TB 外接 NVMe）+ 運算節點；Mac Pro 經 TB Bridge SSH 跑 query / SMB 搬檔；系統碟只留系統；Dropbox/R2 異地備份。永遠別把 DuckDB query 隔著 SMB 跑、永遠別買 HDD。

---

decision logged 2026-06-03 via 對話討論；屬本 issue 開放問題 #2 的 storage baseline，待 diagnose 時採用。

[kiki830621]

Decision addendum — 開放問題 #2 硬體形態定案（NVMe over HDD + 外接盒 DIY）

討論脈絡：2026-06-03 對話後續。承上一則 storage baseline，進一步釐清「HDD vs NVMe」與「外接盒 DIY vs 成品密封 SSD」，以及「在自己電腦分析」的存取方式。

1. 媒介：NVMe，否決 HDD

• 曾考慮 WD My Book 18TB 3.5" HDD（$15,475）一次買齊，否決，兩個理由：
  • 容量爆量浪費：資料 GB 級（單城市 ~70GB/年），18TB 十幾年用不到 5%；花 $15,475 解 ~$4,000 的問題。
  • 讀取速度：要在自己電腦做分析時讀取速度有感，HDD 隨機讀（~10ms/seek）會拖；NVMe 微秒延遲、秒級完成。
• HDD 本身對「純循序掃描聚合」其實堪用（~150–250 MB/s），但綜合成本與速度不划算。只有「本來就想要大容量備份/影音歸檔碟」才該買 18TB，公車 log 當小房客搭便車——本案非此情境。

2. 形態：外接盒 + 裸 NVMe（DIY），否決成品密封 SSD

決定軸 = 「這顆碟固定不動還是會被帶著走？」本案是桌邊固定 24/7 logger 倉：

軸	外接盒 + 裸 NVMe（選用）	成品密封 SSD
可升級 / 換容量	✅	❌ 鎖死
可維修	✅ 盒壞換盒、碟壞換碟	❌ 控制器壞整顆報廢
同容量成本	✅ 較便宜	❌ 偏貴
散熱（24/7）	✅ 帶散熱片盒撐持續運作	⚠️ 密封易溫升
攜帶 / 防摔 / 免組裝	❌	✅ 但固定機用不到

成品 SSD 的唯一優勢（攜帶/防摔/免組）對固定 logger 無意義 → DIY 外接盒全勝。

3. 速度等級：NVMe 即可，不必 TB5 頂規

GB 級 Parquet 掃描，便宜 NVMe(~1GB/s) 與 TB5(~6GB/s) 都秒級、差 1–3 秒。所以：

• mini logger = 中階 NVMe 外接盒（USB 3.2 Gen2 ~1GB/s，帶散熱片）+ 1–2TB 裸 NVMe。
• TB5 快盒子留給 MacBook Pro 重活（避免把頂規閒置在 mini，且 mini 多半只 TB4 吃不滿 TB5）。

4. 「在自己電腦分析」的兩種正解（都吃得到 NVMe 速度）

讀取速度只在「讀取端與碟同機」時才實現；隔 SMB 即時讀會被網路延遲吃掉。故：

做法	怎麼跑	為何快
A. SSH 進 mini	ssh mini → 本機跑 DuckDB	碟是 mini 本地 NVMe
B. 拷回筆電	rsync mini→MacBook（循序大檔，TB Bridge ~1GB/s 幾秒）→ 在筆電內建 SSD 跑	資料變筆電本地碟

資料僅 GB 級 → 做法 B 特別漂亮（循序拷貝快、筆電本地分析爽）。禁忌：別讓 DuckDB 隔 SMB 即時讀。

最終硬體形態定案

mini logger = 中階 NVMe 外接盒（DIY，帶散熱片）+ 1–2TB 裸 NVMe（建議 Crucial T500 / WD SN850X）。
MacBook Pro = 保留 TB5 快盒子。
分析 = SSH 進 mini，或 rsync GB 級 Parquet 回筆電本地跑。
否決：18TB HDD（爆量+慢）、成品密封 SSD（固定機用不到其優勢）。

---

decision addendum logged 2026-06-03 via 對話討論；補充本 issue 開放問題 #2 的硬體形態定案。

[kiki830621]

Decision addendum — 開放問題 #2 具體採購建議（容量 + 型號 + 外接盒）

討論脈絡：2026-06-03 對話，評估 PChome 上 Kingston NV3 4TB M.2 2280 NVMe（$15,866，原價灌水 $26,999）是否該買。

結論：等級對、容量錯

項目	判斷
顆粒等級	NV3 是入門 DRAM-less（HMB）。弱點只在「持續高速隨機寫 / 寫到快滿」現形，涓流 logger 永不觸發 → 對本用途完全夠用，不必上 KC3000/SN850X 高階款
耐久度	4TB=1280 TBW，但年寫 ~100GB(~0.1TBW) → 規格大到沒意義
容量	❌ 4TB 過量：單城市 ~70GB/年 → 4TB≈57 年。需要的是 <1TB
價格	NV3 是「便宜線」，$15,866 等於買「只需 1–2TB」容量的兩倍價；原價 $26,999 是灌水錨定，忽略

具體採購建議

• SSD：買 1TB 或 2TB 入門 TLC NVMe（NV3 級即可），不要 4TB。2TB 給多城市 + 多年 headroom 已綽綽有餘，省一半錢。
• 外接盒：Transcend CM10G M.2 PCIe/SATA 外接盒（$1,299）——USB ~10Gbps(~1GB/s)，對上先前定的「中階 NVMe 盒」。Gen4 碟被限速到 ~1GB/s，分析用足夠。
• 整套估價：1–2TB NV3(~$4–8k) + CM10G($1,299) ≈ $5–9k，比單買那顆 4TB($15,866)還便宜，且容量剛好、可升級、符合 DIY 外接盒定案。

一句話

買 1–2TB 入門 NVMe（如 Kingston NV3）+ Transcend CM10G 外接盒；避免 4TB over-buy（18TB HDD 之後的同類錯誤）。等級不必高階——涓流 logger 用 DRAM-less 入門款即可。

---

decision addendum logged 2026-06-03 via 對話討論；本 issue 開放問題 #2 的具體採購清單。

[kiki830621]

Decision (PROCURED) — 開放問題 #2 硬體採購結案

討論脈絡：2026-06-03 對話，比較「外接盒 vs 硬碟座(dock)」後下單。

形態定案：enclosure，否決 dock

面向	硬碟座 dock	外接盒 enclosure（選用）
碟保護	❌ 外露，怕碰撞/灰塵/靜電	✅ 包覆殼內
連接穩定	⚠️ 直立插槽易鬆脫 → 24/7 資料中斷風險	✅ 固定，set-and-forget
核心賣點	「方便熱插拔換碟」—— 永久單碟用不到	——
速度	10Gbps	同

決定軸 = 「裝一次永久掛 mini、再也不碰」→ 要包覆 + 連接牢固，不要為熱插拔設計的外露 dock。

實際下單（2026-06-03，訂單 20260603292195）

品項	規格	實付
伽利略 USB3.2 10G M.2 NVMe 上掀式外接盒	10Gbps(~1GB/s)、上掀免螺絲	~$748
Kingston NV3 2TB Gen4 PCIe NVMe	入門 DRAM-less、2TB	~$8,873
合計		$9,621

全部符合先前定案：

• ✅ NVMe（非 HDD）
• ✅ 外接盒（非 dock、非成品密封）
• ✅ 2TB（非 4TB over-buy）
• ✅ 10Gbps 級（非 40Gbps/TB5 over-buy）
• ✅ NV3 入門級（涓流 logger 用 DRAM-less 足夠）

價格註：NV3 2TB ~$8,873 在當前 NAND 漲價行情下屬合理——同站其他 2TB Gen4（KIOXIA $9,900 / TEAM $10,449–11,399 / KC3000 $13,666）都更貴，NV3 是最便宜的 2TB 選項。市場本身偏貴，非選錯。

開放問題 #2 結論

Storage 硬體層結案：mini 掛「伽利略 10G 上掀外接盒 + Kingston NV3 2TB」為 logger 主存（Parquet 落此）；分析走 SSH-on-mini 或 rsync 回筆電本地；TB5 快盒子留 MacBook；Dropbox/R2 異地備份。軟體層（DuckDB + Parquet city/date 分區 + 記憶體 buffer 批次 flush）待 diagnose 採用。

---

decision logged 2026-06-03 via 對話討論；硬體已下單，開放問題 #2 硬體層結案。

[kiki830621]

Errata — 開放問題 #2 外接盒更正（10G → USB4 40Gbps）

更正對象：前一則 PROCURED comment 記「伽利略 USB3.2 10G 上掀外接盒 ($748)」。實際最終改買 PROBOX USB4 40Gbps NVMe 外接盒 (HM7-P4C, $2,199)。

變更內容

	原記錄	更正後
外接盒	伽利略 USB3.2 10G（~1GB/s、帶風扇）	PROBOX USB4 40Gbps（~3.8GB/s 實測、無風扇）
價格	~$748	$2,199
SSD	Kingston NV3 2TB（不變）	同

變更理由

1. 不想降速：10Gbps 盒把 NV3（原生 6,000 MB/s）砍到 ~1,000（1/6）；USB4 40Gbps 拉到 ~3,800（listing 實測於 M4 Pro mini TB5）。註：40Gbps 仍非「不降速」——理論 ~5GB/s、實測 ~3.8GB/s，到不了原生 6GB/s（只有直插主機 PCIe 才有）。是「砍 6 倍 → 砍 1.5 倍」。
2. 無風扇靜音：比原帶風扇款更適合 24/7——零移動零件、不會壞、不吵。解掉先前對風扇可靠性/噪音的疑慮。
3. 可一物多用：40Gbps + 相容 TB3/4/5，不綁死 logger；日後拿去 MacBook Pro 剪片/搬大檔速度有感。

誠實註記

• 純看 logger 用途仍是 over-spec（涓流寫 + GB 級 Parquet 掃描，1GB/s 就夠，3.8GB/s 用不到）。但「無風扇 + 可多用」兩個好處讓它對整體硬體庫是合理投資，故不視為 over-buy 錯誤。
• NV3 是 DRAM-less 入門碟：長時間連續寫滿 SLC 快取後速度會掉（顆粒等級決定，非盒子問題）；對 logger 涓流寫無感，搬超大檔則未必穩定維持 3.8GB/s。相容性 OK（NV3 是 NVMe，盒支援 PCIe NVMe）。
• 待辦：取消舊訂單 #20260603292195 內的伽利略 10G 盒（狀態尚未請款/出貨），避免重複購買兩個外接盒。

更新後硬體結論

mini logger 主存 = PROBOX USB4 40Gbps 無風扇盒 + Kingston NV3 2TB；分析走 SSH-on-mini 或 rsync 回筆電本地；TB5 快盒子（另有）留 MacBook；Dropbox/R2 異地備份。實際 I/O 上限 ~3.8GB/s（USB4），遠超 logger 所需。

---

errata logged 2026-06-03 via 對話討論；更正前一則 PROCURED comment 的外接盒型號。

[kiki830621]

Diagnosis

Type

feature（新子系統：公車 ETA 經驗預測 logger + 模型 + 回灌 tool）

目標釐清（使用者 2026-06-03）

「我的目標就是要用這個方式知道一個公車什麼時候會到哪裡，TDX 原本有哪些東西可以抓？」

把目標 operationalize 成一句話：持續記錄 TDX 公車即時資料 → 建立 per-(路線, 站, 方向, 時段) 的實際到站時間分布 → 用分布回答「某路線下一班幾點到某站」並給信賴區間。 下面先盤點原料（TDX 可抓什麼），再定策略。

---

TDX 公車可抓的資料（原料盤點）

分兩類：靜態骨架（偶爾更新）和即時時序（logger 持續輪詢的核心）。endpoint 為本 repo TDXEndpoints.swift 已驗證者 + TDX 有但本 MCP 尚未接者。

A. 靜態骨架（記一次 / 週更，不需高頻）

資料集	TDX endpoint	關鍵欄位	用途
路線 Route	v2/Bus/Route/City/{city}	RouteUID, 路線名, 起訖站	識別路線
站牌 Stop	v2/Bus/Stop/City/{city}	StopUID, 站名, 經緯度	站位置
站序 StopOfRoute	v2/Bus/StopOfRoute/City/{city}	每路線每方向的站順序	定義「站 Y 在路線第幾站」
班表 Schedule	v2/Bus/Schedule/City/{city}	Timetables（班次時刻）+ Frequencys（班距 Min/MaxHeadwayMins）	名目時刻 / 班距 baseline
車輛 Vehicle	v2/Bus/Vehicle/City/{city}（MCP 未用）	車牌→車型（低地板等）	車輛屬性（可選）

B. 即時時序（logger 要持續記的核心）⭐

資料集	TDX endpoint	關鍵欄位	對「何時到哪」的價值
A2 進離站事件 RealTimeNearStop	v2/Bus/RealTimeNearStop/City/{city}/{route}	PlateNumb, StopUID, StopSequence, A2EventType（1=進站 / 0=離站）, GPSTime, 經緯度	⭐ 黃金 ground truth：實際到站/離站事件。「車牌X 於 09:24:13 進站 站Y」直接就是你要的答案
A1 GPS 動態 RealTimeByFrequency	v2/Bus/RealTimeByFrequency/City/{city}（MCP 未用）	PlateNumb, 經緯度, Speed, Azimuth, StopSequence, DutyStatus	連續軌跡（每 ~15–30s）→ 算站間旅行時間、補 A2 缺漏
N1 預估到站 EstimatedTimeOfArrival	v2/Bus/EstimatedTimeOfArrival/City/{city}	StopUID, RouteUID, EstimateTime（秒）, StopStatus, (PlateNumb)	TDX 自家預估 → 當 baseline 對照「我的模型 vs TDX 誰準」

核心結論：對「知道公車什麼時候到哪裡」，A2（RealTimeNearStop）是主力資料——它記的就是「進站/離站事件 + 時刻 + 站 + 車牌」，正是真值。N1 當對照 baseline、A1 補站間旅行時間。

C. ⚠ 重要架構發現：不要走 MCP 工具抓，要直打 TDX raw

本 MCP 現有 model 是有損的（只解 routing 需要的欄位）：

• BusLivePosition（RealTimeNearStop）只解 plateNumb / routeUID / direction / busPosition——沒解 A2EventType / StopSequence / StopUID / GPSTime（剛剛 bus_status_positions(270) 回傳只有 plate/route/direction 即此故）。
• BusArrival（EstimatedTimeOfArrival）解 estimateTime / stopStatus——沒解 PlateNumb。

→ logger 必須直接打 TDX raw endpoint 抓全欄位（尤其 A2EventType / GPSTime / PlateNumb），而非透過 read-only MCP 工具。logger 是獨立的 ingestion 服務，與 MCP 分離。

---

Impact（影響範圍）

新子系統，跨三塊：

1. Ingestion service（新）：常駐 logger，輪詢 TDX raw（A2 主、N1 baseline、A1 可選）→ 寫 Parquet。獨立於 read-only MCP，跑在 mini。
2. Storage + 模型（新）：DuckDB + Parquet（city/date 分區）；衍生 per-(route, stop, direction, 時段桶, 平假日) 的到站分布（P50/P80）。
3. 回灌 surface（未來）：新 MCP tool（如 bus_eta_predict）或讓 bus_status_arrivals 在 frequency-only 時 fallback 歷史 baseline，標 source: historical。

Strategy（MVP → 擴展）

MVP 先窄後寬，先證明「能記、能還原、能預測」：

• 採集（MVP）：logger 針對單城市少數路線（如 Taipei 270 + 鄰近）輪詢 A2 RealTimeNearStop（主）+ N1 EstimatedTimeOfArrival（baseline）。輪詢 ~20–30s，注意 TDX free tier 50 req/min 上限 → A2 是 per-route（要逐路線打），需控管路線數 × 頻率。
• 儲存：raw 事件寫 Parquet（city=/date= 分區，已採購 NV3 2TB + PROBOX 盒掛 mini）；記憶體 buffer 批次 flush。
• 去重 / 事件化：A2 同一進站事件會重複回報 → 以 (PlateNumb, StopUID, A2EventType, 時間窗) 去重成單一「到站事件」。
• 建模（MVP）：per-(route, stop, direction) 先做全天平均→再加 time-of-day 分桶 + 平假日；統計量用 P50/P80 分位數（右偏，不用平均）。
• 驗證：hold-out 比對「模型預測 vs 實際 A2 到站」；同時對照 N1（TDX 自家）看誰準。
• 回灌（後續）：定 tool surface（bus_eta_predict vs 既有 fallback）。
• 擴展：加 A1 GPS 算站間旅行時間、多城市、天氣/事件變因。

Complexity

Spectra

• Layer 2（necessary）命中：最終會對外暴露 published tool surface 給 future callers（新 bus_eta_predict MCP tool，或改 bus_status_arrivals 的 source 契約），且其 behavior contract（歷史 baseline 如何計、source: historical 語意）應寫成 documented spec。
• Layer 3（confirmation）命中：①架構決策、長期維護——新增獨立 ingestion 子系統 + 儲存 schema，會被未來持續維護；②儲存 schema 是 frozen contract（Parquet 欄位、事件去重規則、分桶定義），下游查詢長期依賴。
• 非 Plan（不只是內部 refactor）、非 Simple（不是單檔 clear-fix）。

Risks

• TDX rate limit（50/min）：A2 是 per-route endpoint，路線數 × 頻率易爆 → MVP 必須限路線數；或評估 A1（per-city bulk）替代覆蓋。
• A2 事件去重：重複回報、漏報、GPSTime 與抓取時間的時差 → 去重規則錯會污染到站時刻真值。
• 冷啟動：無歷史的路線/站只能 fallback N1 或標 source: no-history，不可假裝。
• DRAM-less SSD 持續寫：涓流寫無感（已評估），但若日後高頻多城市需重評。
• logger 中斷造成的資料空洞：mini 須常駐；空洞要記錄（哪段沒資料），避免被當成「沒車」。

Residue

（NSQL §4.6 — 無法 operationalize 的意圖殘留）

• 「臺灣版 NAVITIME」的願景層：本 issue 只能 operationalize 成「公車 A2 經驗 ETA」，但 North Star 的「全運具、實測轉乘步行、即時情報整合」是 horizon，非本 issue 能收斂——明確標記為長期方向，不在此 scope 內假裝涵蓋。
• 「準到什麼程度才算成功」的價值判準：屬 discuss 要對齊的開放項（MVP 成功門檻、可接受誤差），本診斷不替使用者預設。

Vagueness Pre-check

• V1 (vague WHAT): 3 — 目標已 operationalize（記 TDX 即時資料→建到站分布→預測），WHAT 清楚。
• V4 (vague ACCEPTANCE): 3 — 成功門檻/可接受誤差未定，但屬 research umbrella 設計，acceptance-definition 是 discuss 的工作而非 issue 缺陷。
• Triggered: no — both axes ≤ 3

[kiki830621]

Spectra-discuss Conclusion — 公車 ETA 經驗預測 logger 子系統

2026-06-04 discuss 收斂結論。作為 /spectra-propose 的基礎。

Decision

自建常駐 logger 子系統。沒有任何現成歷史資料可用（已查證，見下）→ build，不是 reuse。

「真的沒有歷史資料」的查證（pivotal）

• TDX：有「歷史服務」tier 但只含國道(ETag/VD)、YouBike、路徑——無公車動態。官方文件：公車動態僅保留每車最新一筆、滾動 ~2 小時、無 date/時間範圍參數 → 結構上 live-only。
• 其他來源全無：data.taipei（即時快照原地覆蓋不留檔）、data.gov.tw/各縣市（live feed wrapper）、GTFS-RT 封存（只有 GTFS 靜態時刻表、台灣無 GTFS-RT 歷史）、學術（業者 proprietary 未公開）、GitHub（爬蟲 code 無公開資料集）。
• 根因：TDX 源頭 2h 即丟 → 上游無歷史可鏡像 → 誰先記誰獨有（對齊 CLAUDE.md 北極星「補 phase = 資料採集問題、Stage 3+」）。
• 來源：TDX 公車動態使用注意事項（2h 保留）、TDX_Guide endpoint inventory、data.taipei dataset 頁、Transitland/Mobility Database feed 頁。

Scope / MVP（capture-feasibility 先於 accuracy）

MVP = 對大臺北（Taipei + NewTaipei）全路線持續跑 N 天，證明在 rate-limit + 儲存內維持全覆蓋。 量測：coverage %、gap 分鐘數、去重正確性。

• ETA 準度（P50 ±3 分等）退為 Phase 2 建模里程碑（有資料後才談）。先證「記得齊、記得穩」，再證「算得準」。

可行性（大臺北全公車）

• Rate（free tier 50/min）：per-city bulk，每輪 2 feed × 2 城 = 4 base call。
• 唯一硬風險（留 propose spike）：N1（站×路線 ETA）量級大、可能逼出 TDX $top/$skip 分頁 → 請求數放大。對策：A2 高頻(~30s，真值、payload 小) + N1 低頻(~60–120s、量大)；仍緊則申請較高 TDX tier。
• spike 要量的數字：台北/新北 A2、N1 各單輪實際記錄數 + TDX $top 上限/分頁行為 → 精確請求預算 + 輪頻；併驗 per-city A2 形式可用。
• 儲存非問題（~0.1–0.2TB/年壓縮 → 2TB NVMe 撐 10+ 年）；mini 吞吐非問題。
• 可靠性=一等公民：snapshot 非 queryable，logger 中斷 = 永久空洞、不可回補。

Stack

Python(httpx + pyarrow；爬蟲一等公民) 抓 → Parquet(city/date 分區) on mini 外接 NVMe → R + DuckDB 建模 → 小 JSON/SQLite 預算表 → Swift bus_eta_predict serving

• Ingestion = Python（為未來爬蟲擴張下注）；建模 = R + DuckDB（母語、與 l4 框架一致）；serving = Swift（讀預算表、不碰 raw Parquet、不動 live bus_status_arrivals、source: historical）。
• 直打 TDX raw 抓全欄位（繞過 MCP 有損 model）。

訊號

• A2 RealTimeNearStop（per-city bulk）= 到站真值主力 + N1 EstimatedTimeOfArrival = baseline 對照；A1 GPS（站間旅行時間）= Phase 2。三者皆 live-only/2h。
• 去重：A2 同 (plate, stop_uid, direction) 90s 窗收斂成單一進站事件、取最早 GPSTime。

資料庫 Schema（BCNF + SCD Type-2）

原則：thin-fact（事件只存 FK + 量測 + 時間，不重複名稱）→ BCNF-correct 且省儲存；dim 用 SCD-2 保歷史保真。

Dimension（SCD-2：route/stop/vehicle/bridge；city/operator 用 Type-1）

• 每個 SCD-2 dim：surrogate *_sk PK + natural key + valid_from/valid_to/is_current + 屬性。BCNF：*_sk → 全部、(natural_key, valid_from) 亦 candidate key ✓。
• dim_city(city_code PK) / dim_operator(operator_id PK) / dim_route(route_sk; route_uid, city_code FK, route_id, name_zh/en, dep/dest_stop, operator_id FK) / dim_stop(stop_sk; stop_uid, city_code FK, stop_id, name_zh/en, lat, lon) / dim_vehicle(vehicle_sk; plate, vehicle_type, operator_id FK) / bridge_route_stop(rs_sk; route_uid, direction, stop_sequence, stop_uid FK)。
• SCD-2 維護 = 靜態骨架刷新（每日/週）時 diff 現況、屬性變了 insert 新版本——與高頻輪詢分離。

Fact（append-only；存 natural FK + event_ts，建模時對 dim 做 as-of join natural_key 同 ∧ ts∈[valid_from,valid_to)）

• fact_arrival_event PK (plate, route_uid, direction, stop_uid, event_type, event_ts) + gps_lat/lon, gps_time, captured_at, source。
• fact_eta_snapshot PK (captured_at, route_uid, direction, stop_uid) + estimate_time_sec, stop_status, plate(FK), source。
• fact_vehicle_position（Phase 2）PK (captured_at, plate) + lat, lon, speed, azimuth, route_uid(FK), direction, cur_stop_seq, duty_status。
• Fact 存 natural FK（非 surrogate）→ logger 只寫 id、最簡單、fact 不依賴 dim 版本 churn。

Serving（物化聚合，"app_data" 等價）

• agg_arrival_distribution PK (route_uid, direction, stop_uid, tod_bucket, daytype) + p50_sec, p80_sec, n_samples, updated_at。Swift 只讀這張。

便利寬 view：另物化一張 denormalized 寬表給臨時分析——可重建、非 canonical（儲存成本暫時）。
邏輯/物理正交：BCNF 是邏輯層；Parquet 仍按 city_code/date 實體分區。

下一步

/spectra-propose（複雜度 Spectra）。propose 的第一個 spike = 量 N1/A2 記錄數 + $top 分頁 → 定請求預算與輪頻。

---

discuss conclusion captured 2026-06-04。