Expo Exact 試用前先驗收什麼？Contract、agent 時鐘與平台邊界

先確認自己能承擔工具鏈#

目前使用 source checkout，README 列 Bun 1.4.2 與 Rust；Apple host 另需 Xcode 27.1+。setup 會安裝工具鏈、target、Hermes bundle 與依賴，首次試用應預留下載與編譯時間。固定 commit 可讓測試紀錄與文件對得上：

1
git clone https://github.com/expo/exact.git
2
cd exact
3
git checkout --detach 1b13f53347c09e9dd4cb362f200724f98fd0fdf5
4
bun --version
5
bun scripts/exact.mjs setup --check

最後一個命令是 README 提供的離線環境檢查，可能因依賴尚未準備而失敗。記下缺什麼再決定是否執行 bun scripts/exact.mjs setup；在正式專案外試用，可避免把原專案的依賴與工具鏈混進結果。

UI 不是 JSX／React tier，現有元件需要重新評估。README 與程式碼的能力仍快速變動，「不能 import 任意 npm 套件」這類概括說法需要逐個套件確認 runtime、bundle 與平台依賴；本篇沒有驗證第三方套件相容性。

用 Caltrain 檢查 tree、state 與時鐘#

完成官方 setup 後，README 的 web 流程是：

1
bun host/web/build.mjs caltrain-web
2
bun scripts/agent.mjs web tree "tap change-station" "type station-search Palo" state "screenshot out.png"
3
bun scripts/agent.mjs web --test apps/caltrain/app.test.contract

每個操作是一個 shell argument，含空格的操作要保留引號。先讀 tree 找可操作目標，再 tap、type，接著讀 state 與截圖；文字輸入成功與畫面呈現正確要分別觀察。

官方 Caltrain 測試會從首頁進車站選擇頁，輸入 Palo 後確認列表含 Palo Alto、缺 Mountain View，再選取並核對首頁與站名。另一個案例用 clock +60000 推進時間，同時檢查仍停留在 home。這些案例能說明 Contract test 的斷言方式；單獨一個「推進後仍在首頁」還不足以驗證計時功能準確。

若要評估自己的倒數或動畫，另外設計一個最小測試 app：記下初始 state 與畫面，在期限前一毫秒推進一次、跨過期限再推進一次，檢查預期欄位與元件確實只在邊界後改變。這是新增的驗收設計，並非已存在或已執行的測試檔。外部網路回應、真實裝置權限與付款等副作用，也需要各自可控制的測試替身或隔離環境。

同一來源跑多平台，還要留各自證據#

README 列出的十種操作是 tree、screenshot、tap、type、state、layout、logs、clock、prefer、perf。相同操作入口能降低測試介面的差異，平台能力仍須逐項核對。

截至本文查核，README 已列早期 Android build、test 與 agent 路徑，但尚無 delivery／store packaging；Windows 仍有一般控制項一致性與交付缺口。因此只需要四個既有主要 host 的小型原型，與需要完整 Android／Windows 發布的產品，會得到不同採用判斷。請以固定版本實際跑過的案例決定範圍。

若需求只是讓 agent 操作既有網站，可先用 瀏覽器工具驗收方法檢查現有 web app。Exact 值得試的條件是願意用 Contract 建新 UI，並能把跨平台狀態與畫面驗收納入工作流程；已有大量 React 元件時，先算移植成本。

參考資料：

expo/exact：固定版本 README

Exact：agent.mjs

Exact：Caltrain tests

Exact：package.json