評估現有行動端產品是否以及如何遷移至 React Native。適用於：審查一或多個產品程式庫的遷移準備程度（包含 iOS、Android 及其他用戶端分屬不同目錄或程式庫的產品）；選擇 Brownfield（混合式）、Greenfield（全新開發）或基於 Checkpoint（檢查點）的路徑；定義具代表性的試驗專案；或在實作前準備基準線與 ROI 決策。當缺乏產品範疇或關鍵事證時，每輪只向利益相關者提出一個問題進行深入追問，而非發送問卷。
評估 React Native 遷移
產出僅供參考與決策用的遷移評估結果。負責診斷產品與交付系統，但不直接執行遷移實作。
確定產品範疇
請在能存取最多正式環境用戶端程式碼庫的工作區中執行評估。當前檢出的程式碼庫並不代表已包含完整產品。
在評估準備程度之前：
- 檢查當前程式庫以及 Agent 可用的每個工作區根目錄。
- 從產品文件、CI、發布組態、工作區清單（manifests）、子模組（submodules）以及同級程式庫的引用中，推斷支援的用戶端平台。
- 定位每個正式用戶端程式碼庫，包含獨立的原生 iOS 與 Android 程式庫、應用程式變體（app variants），以及任何與人力配置或程式碼共享提案相關的 Web 用戶端。
- 記錄一份平台清單，列出用戶端、程式庫或路徑、屬於該產品的事證以及存取狀態。
當同時支援 iOS 與 Android 時，在推薦路徑之前必須先檢查這兩個原生程式碼庫。若某個程式碼庫無法存取，請將其事證標記為 unknown（未知），說明評估僅涵蓋可存取的平台，並相應降低信心度。切勿單憑當前程式庫中缺少某個平台的專案，就推斷該平台不受支援。
範疇關卡（Scope gate）： 已列出所有支援的正式用戶端，且每個程式碼庫皆為可存取、明確標示為無法存取，或已確認不存在。
首輪回應關卡
當範疇關卡未通過時，首輪回應必須完全如下：
**Question:** 在哪裡可以存取此產品支援的各用戶端平台正式程式碼庫？（若同時存在 iOS 與 Android，請一併提供）
**Why it matters:** 僅基於單一平台所制定的遷移路徑，可能會遺漏會改變最終決策的原生相依套件、產品行為與交付限制。
在通過範疇關卡後，若缺乏程式庫事證，請採用「逐一深入追問」而非發送整份問卷調查。
若可衡量的遷移驅動因素（driver）仍未知，首輪回應必須完全如下：
**Question:** React Native 遷移預計要解決什麼可衡量的交付或業務問題？
**Why it matters:** 這將決定遷移是否具有必要性，以及評估過程必須驗證哪些成果。
若驅動因素已知，請使用相同的兩行格式，僅針對影響程度次高的未知事項提問。在提出問題與原因後立即結束該輪對話。切勿加入開場白、問卷、建議或實作指導。
原則規範
- 將每個正式發布的 App 視為唯一事實來源（Source of truth），包含未記錄在文件中的行為。
- 在提問前，先檢查現有的程式碼、CI、測試、發布組態、產品文件與執行階段事證。
- 若 iOS 與 Android 在實作、行為、相依套件、交付或產品路線圖（roadmap）上存在差異，應進行明確比較。
- 全產品層面的主張必須僅建立在所有受支援平台的事證之上，否則應明確限定其涵蓋的平台範圍。
- 將關鍵主張標示為
observed（觀察到）、measured（量測到）、reported（回報）、assumed（假設）或unknown（未知）。 - 根據客觀事證給出建議，而非依據綜合準備程度分數。
- 預設先收集事證，而非直接預設選擇 Brownfield、Greenfield 或遷移本身。
- 主導決策階段。在 Path A 被採納之前，請勿套用實作技能或在 Expo 與純 React Native（bare）之間做選擇。
- 僅計算 React Native 相較於現有原生系統所帶來的邊際價值（marginal value）。
- 以被採納並經驗證的工作成果來衡量 Agent，而非 Token 數量、產生的程式碼或 Pull Request。
- 不對工期、成本、程式碼共享率、Agent 生產力或 ROI 做一概而論的泛化宣稱。
選擇事證收集模式
當可取得原始碼或交付產物時，採用「基於程式庫的評估」：
- 完成平台清單，並確認評估流程可檢查哪些程式庫。
- 針對每個可存取的行動端程式碼庫，定位其應用程式變體、CI、測試、發布組態、架構紀錄與產品文件。
- 搜尋各原生程式碼庫中的 SDK、權限設定、App 擴充功能（app extensions）、儲存機制、身份驗證、推播、深度連結（deep links）、分析統計、實驗功能（experiments）以及平台特有行為。
- 當程式碼庫相互獨立時，請引用程式庫名稱以及檔案路徑與行號，確保事證源頭可被追溯。
- 僅在缺少程式碼庫位置，或程式庫無法提供產品、組織與營運層面的事實時，才向利益相關者提問。
當程式碼庫無法存取或仍缺少關鍵事證時，採用「訪談式評估」：
- 除非使用者已主動提供，否則先從可衡量的交付或業務問題開始著手。
- 每輪僅提出一個會影響決策的關鍵問題。
- 用一句話說明該回答會影響哪條路徑、風險或假設。
- 對於模糊或矛盾的回答，應提出更具體的追問，而非直接將其採信為事證。
- 記錄回答、更新事證狀態，並選擇下一個影響最大的未知事項。
- 當進一步的回答已無法改變建議、信心度或 Checkpoint 時，即停止追問。
在通過事證關卡之前，每輪回應必須僅包含：
**Question:** [一個問題]
**Why it matters:** [一句說明]
在這些對話輪次中，切勿包含問卷、路徑建議、Checkpoint 或實作指導。若使用者中斷訪談，請回傳當前的事證狀態與影響最大的單一未知事項，切勿假裝評估已完成。
訪談輪次關卡（Interview turn gate）： 已要求提供一個回答、明確指出其對決策的影響，且未出現第二個問題。
1. 收集決策事證
說明決策內容、截止期限、現有替代方案以及可衡量的驅動因素。對特定框架的偏好不能作為驅動因素。
檢視以下維度：
| 維度 | 最少所需事證 |
|---|---|
| 產品層面 (Product) | 支援平台、應用程式變體、共享與平台特有之路線圖、核心流程、無障礙功能 (Accessibility)、分析統計與邊界情況 (Edge cases) |
| 原生介面 (Native surface) | SDK、模組、權限、背景作業、App 擴充功能、支付、硬體 API、自訂繪製以及可行的 React Native 路徑 |
| 連貫性 (Continuity) | 身份驗證與 Session、安全與持久化儲存、推播 Token、深度連結 (Deep links)、訂閱、現有使用者更新、法律、安全性與離線限制 |
| 驗證機制 (Verification) | 可重複建置 (Reproducible builds)、測試帳號、手動與自動化 QA、實機控管、原生對照事證、效能基準線與獨立審查 |
| 發布流程 (Release) | 現有發布頻率與復原機制、內部分發、Feature flags、實驗、商店上架分批釋出，以及預期的 Binary 與可選的 OTA 管道 |
| 所有權 (Ownership) | 產物、功能對齊 (Parity)、原生邊界、共享基礎架構、驗證與發布的決策權限與負責人 (Owners) |
| Agent 管治 (Agent governance) | 核可的模型與原始碼界線、受保護的機密與測試資料、最小權限存取、事證保留、稽核軌跡，以及人工架構與發布審核 |
| 交付基準線 (Delivery baseline) | 重複實作與審查、等待與交接時間、對齊落差 (Parity gap)、雙平台驗證、發布指標、缺陷率、重做成本與維護成本 |
對於依賴 OTA 的計畫，必須指定負責人，並包含執行階段相容性、釋出策略、可觀測性（observability）、回滾（rollback）或重新發布機制以及稽核政策。單純「具備 OTA 能力」本身不能算作遷移效益。
組成精簡的遷移核心小組，結合現有的產品與原生知識以及 React Native 遷移專業。僅針對可能改變決策的缺漏事實提問；其餘部分則明確標示為假設。
關卡： 每個維度皆已具備事證或明確標示為未知，且所有阻礙路徑決策的未知事項皆已被列出。
2. 選擇路徑
選擇一個最終結果，並說明為何其他替代方案未獲採用。
| 結果 | 建議時機 |
|---|---|
| Path A: Brownfield（混合式遷移） | 發布或現有使用者的連貫性為首要考量、原生耦合度深、業務流程可獨立遷移，或全 App 一次性切換（cutover）風險無法接受。須納入 Host 邊界與雙重架構的維持成本。 |
| Path B: Greenfield（全新重構） | 原有行為可復原、原生相依套件有可靠替代方案、連貫性可被證明、驗證機制完善，且舊有系統範疇在被替換前可受控。 |
| Path C: Greenfield 優先 checkpoint 並保留 Brownfield 備案 | Greenfield 提供更簡單的目標，但仍存在關鍵不確定性，且完成的 React Native 工作能在擴大規模前，先在原生 Host 內部獲得驗證。 |
| Defer（暫緩） | 商業效益合理，但缺少事證、驗證機制、所有權、預算或發布準備度。請列出最小範圍的準備工作與重新啟動評估的條件。 |
| Do not migrate（不遷移） | 現有原生系統即可滿足預期成果、雙平台重複交付問題並不嚴重、路線圖不對稱、平台特有工作佔主導地位，或經風險調整後的投報率不具說服力。 |
請將 Path C 視為 Callstack 在 2025 年後興起的新型營運模式，而非業界通用標準。Agent 的存取能力使行為移植更加可行；但唯有針對該產品進行實測 Checkpoint，才能確立速度與品質。
當 Path A 被採納後，請將實作規劃移交給 react-native-brownfield-migration。切勿重複其 Expo、XCFramework、AAR 或 Host 整合的指導內容。
關卡： 有決定性事證支持單一結果、未採用的替代方案皆附帶理由，且信心度能反映事證品質。
3. 定義具代表性的 Checkpoint
在採用 Path C 時，或當單一不確定性可能使推薦路徑失效時，請使用 Checkpoint。設定由組織提供的固定時程與人力預算。選擇二至三個垂直業務流程：
- 涵蓋 UI、資料、分析統計與導覽（navigation）的通用流程。
- 涵蓋持久化、錯誤處理與 Session 行為的已驗證狀態流程。
- 最可能推翻計畫的邊界，例如原生 SDK、背景任務、硬體 API、離線行為、App 擴充功能、無障礙功能需求，或低階 Android 裝置限制。
將每個流程連結至原生原始碼引用、執行階段事證、負責人與對齊情境（parity scenarios）。切勿僅選擇簡單的畫面。
相較於現有產品，定義可衡量的驗收標準：
- 行為、狀態、驗證、錯誤、分析統計、無障礙功能與視覺輸出皆與原生對照組一致。
- 身份驗證、儲存、深度連結 (Deep links)、推播與指定原生邊界在要求的裝置與 OS 版本上運作正常。
- 啟動速度、互動、記憶體與 Crash 行為符合約定的基準線或容忍度。
- CI、內部分發、可觀測性以及預期的發布管道運作夠穩定，足以繼續推進。
- 每個流程都有裝置層面的事證，以及在不受干擾上下文（clean context）下完成的獨立審查。
- Path C 在每個要求的原生 Host 中打包並開啟至少一個具代表性的 React Native 流程。
對至少一個流程執行兩輪實作：
- 忠實還原輪 (Faithful pass)： 完整保留行為、分析統計、無障礙功能、狀態與邊界情況。記錄為了達到對齊（parity）而保留的原生風格架構。
- 語意化重構輪 (Idiomatic pass)： 引入 React 元件組合（composition）、清晰的狀態界線、強型別導覽、可複用基元（primitives）、合適的測試與量測後的效能。重複進行對齊與裝置檢查。
在擴大規模之前，為 MIGRATION.md、SCREENS.tsv、STATE_AND_STORAGE.tsv、DEPENDENCIES.tsv、EVENTS.tsv 與 PARITY_CHECKS.md 指派負責人。Dur
<!-- truncated for translation batch; full body continues in source -->
