先講結論：taiwan-parking 的 CI 監工上線當晚就開了第一張單——issue #6。不是誤報，是停車場數字真的在漂：9/19 實測 1,177 場，9/20 文件改成 1,174，當晚 CI 抓到 1,180，隔天晚上又 FAIL 一次。寫進文件的「基準數字」撐不到一天，這正是 check-counts.py 存在的原因。

兩支 feed 的基本格局

台北市停管處（TCMSV）給的是兩支免 key 的 JSON，搭配使用：

• TCMSV_allavailable.json（即時剩位，2026-09-22 實測 474KB、1,180 場）：只有 id 和各車種可停數（availablecar、availablemotor、availablebus、身障格、孕婦親子格、大貨車），部分場附充電樁狀態。
• TCMSV_alldesc.json（靜態資料，同日實測 2.8MB、1,773 場）：場名、行政區、地址、電話、費率說明、總格數、TWD97 坐標。

兩個數字不一樣不是 bug：1,773 是「有建檔的場」，1,180 是「有即時回傳的場」，差了 593 場有名字但沒即時數。查法固定兩步：先抓靜態表用地名找 id，再抓即時表用 id 取剩位，回答時一定要附即時表的 UPDATETIME（今天實測與查詢時刻只差 7 分鐘，近即時）。

地雷圖鑑：-9 不是停滿

availablecar = -9 的意思是「該場無此車種資料」，不是客滿、也不是錯誤。2026-09-22 實測 1,180 場裡 83 場是 -9（9/20 是 88 場——這個數字自己也會動）。把 -9 當 0，就等於騙使用者「這裡停滿了」；只能如實說「無資料」。

實測：中山區現在哪裡有位置

curl -sm 30 -o /tmp/park.json 'https://tcgbusfs.blob.core.windows.net/blobtcmsv/TCMSV_allavailable.json'
curl -sm 30 -o /tmp/parkdesc.json 'https://tcgbusfs.blob.core.windows.net/blobtcmsv/TCMSV_alldesc.json'

jq -r --slurpfile d /tmp/parkdesc.json '
  ($d[0].data.park | map({key:.id, value:{name:.name, area:.area, addr:.address}}) | from_entries) as $info
  | .data.park[] | select(.availablecar > 0 and $info[.id].area == "中山區")
  | "\($info[.id].name)|\(.availablecar)|\($info[.id].addr)"' /tmp/park.json \
  | sort -t'|' -k2 -rn | head -8

2026-09-22 02:37（台灣時間）實測結果：

順帶一提，此刻全市剩位最多的是臺北大巨蛋園區停車場：1,907 位（信義區）。巨蛋沒活動的日子，停車場比誰都空。

數字會漂移，所以要讓 CI 每晚重問一次

0.8.1 加進來的 check-counts.py，把文件裡的基準數字變成每晚重驗的測試：博物館 144 館、圖書館 5,207 列、健保院所 37,133 筆、停車場 1,174／1,773 場。結果上線當晚就 FAIL：文件寫 1,174，實測 1,180——早上才剛從 1,177 改到 1,174 的數字，晚上就漂走了。隔天晚上再 FAIL 一次，health-check 自動開的 issue #6 到現在還開著。

這是設計問題不是資料問題：即時場數會因為場站上線、下線、暫停回傳而每天小幅波動，用 exact match 盯它就是天天挨打。候選做法有兩個——基準值加容許範圍，或把這種會漂的檢查降成 WARN。哪個好還沒定案，issue 開著慢慢想；但「CI 真的抓得到東西」這件事本身，先記一筆。

錯誤處理與邊界（寫進 SKILL 的老規矩）

• 只涵蓋台北市停管處場站，其他縣市不要硬查，如實回「目前只支援台北市」。
• 路邊計費停車格沒有公開即時 feed，這支是停車場。
• tw97x／tw97y 是 TWD97 投影坐標不是經緯度，算距離要先轉換。
• feed 抓不到（blob.core.windows.net 暫時連不上）就稍後重試，持續失敗回報資料源異常——不編剩位數字。

第 15 天，repo 學會了自己開 issue。原則還是那句：能驗證的才寫進文件；寫進文件的，每晚重驗一次。