昨天把店家資料搬進 Firestore，讓 Laravel 讀取後交給 React，再用修改店名、重新整理頁面的方式核對資料。
今天沿用同一個 Firebase 專案，加入 Google 登入。開始前，先確認店家仍能正常載入，昨天測試用的店名也已還原。
登入入口會放在原本的頁面裡。只是想找間咖啡廳的人，還是可以直接搜尋、篩選和看店家。

這次登入的是使用者

昨天建立的 reader 和 importer，是 Laravel 讀取與匯入資料使用的服務帳戶。今天的 Firebase Authentication 則是辨識打開網站的人。
店家資料仍走原本的路徑：

Firestore → Laravel → Inertia props → React

Google 登入交給 Firebase Authentication，店家資料照原本的方式讀取。昨天下載的服務帳戶 JSON 私鑰仍留在後端。
這次先處理登入、重新整理後保留身分，以及登出。前端登入成功後，如果要呼叫需要使用者身分的後端功能，Laravel 還得驗證 Firebase ID token，也就是用來核對身分的憑證。ID token 驗證說明

先請 Agent 看目前的登入入口

先讓 Agent 看目前的版型和資料流程，提出登入入口的位置與修改範圍：

先閱讀 docs/ 的 CURRENT 規格與 README，
並檢查以下現有實作（若檔案已移動，請找出對應檔案）：
- app/Services/FirestoreCafeService.php
- config/services.php
- routes/web.php
- resources/js/Pages/Home.tsx
- resources/js/Layouts/ 下的共用版型
- package.json 與既有 Firebase 初始化程式

目前店家資料由 Laravel 從 Firestore 讀取，
經 Inertia props 傳給 React，請先確認實際程式是否符合。
先列計畫，不修改程式或雲端設定。

今天要加入 Firebase Authentication 的 Google 登入。
請確認：
1. 現有登入入口放在哪裡；若規格未定，提出最小改動方案。
2. Firebase Web SDK 初始化與登入狀態放在哪裡。
3. 未登入、狀態初始化中、登入中、已登入與失敗如何呈現。
4. 重新整理、同一來源的新分頁、取消登入及登出如何處理。
5. 預計修改檔案、所需 Console 設定與驗證方法。

這次先做前端身分狀態，不新增會員中心或後端會員功能。
未登入也能搜尋、篩選與看店家。
保留 Firestore → Laravel → Inertia → React 的店家讀取流程。
不要把服務帳戶私鑰放進前端。
列完計畫後先停下，待確認再實作。

在原本的 Firebase 專案啟用 Google 登入

打開 Firebase Console，選擇 Day 17 使用的專案，不用另建專案或資料庫。文章中的專案識別值一律以 YOUR_PROJECT_ID 代替。

1. 進入 Authentication；第一次使用時點「開始使用」。
2. 開啟 Sign-in method／登入方式，選擇 Google。
3. 啟用 Google，依畫面填寫專案公開名稱、選擇支援電子郵件，儲存。
4. 到 Settings／設定 → Authorized domains／授權網域，確認本機網站實際使用的主機名稱。

例如本機網址是 http://localhost:8000，授權網域就要有 localhost。新專案不一定會自動加入，少了就手動新增。測試期間固定使用同一個網址，避免換主機名稱後讀到不同的登入狀態。Google 登入設定 · 授權網域說明

📸 圖片 1｜Firebase Authentication 啟用 Google 登入

準備前端使用的 Firebase 設定

在「專案設定 → 一般設定 → 你的應用程式」查看是否已有 Web 應用程式。沒有的話，點 Web 圖示新增；這一步不需要同時部署 Firebase Hosting。
在該 Web 應用程式的「SDK 設定和配置」選擇設定物件，找到 apiKey、authDomain、projectId、appId 等欄位。讓 Agent 列出專案需要的環境變數名稱，再將對應值填進本機設定，並確認 projectId 與 Firestore 使用的是同一個專案。
這份 Web 設定會供瀏覽器使用，與昨天下載的服務帳戶 JSON 不同，不能放入私鑰。文章範例以 YOUR_PROJECT_ID 等佔位值呈現。
設定填好後，重新啟動 Vite 開發伺服器；如果使用建置後的檔案，則重新執行 build，讓前端載入更新的設定。

接上登入按鈕與帳號狀態

計畫確認、Console 設定完成後，再讓 Agent 實作：

請在現有 Laravel＋Inertia＋React 專案加入 Firebase Authentication Google 登入。

先閱讀 docs/ 的 CURRENT 規格、README、package.json，
檢查 FirestoreCafeService、config/services.php、routes/web.php、
Home.tsx、共用版型與既有 Firebase 初始化程式。
店家資料繼續由 Laravel 從 Firestore 讀取，經 Inertia props 傳給 React。

Firebase Authentication 應使用與現有 Firestore 相同的專案。
從本機設定核對 FIRESTORE_PROJECT_ID，
使用該專案的 Firebase Web app 設定，不要猜測設定值或另建專案。
缺少 Web app 設定時，列出需要補齊的變數；不要讀取或輸出私鑰內容。
登入入口沿用現有規格與版型；若沒有定義，先提出位置供確認。
以 Firebase SDK 管理登入狀態與持久化，
監聽 SDK 的狀態變化，不以自存的布林值判定登入。
初始化尚未完成時顯示適當狀態，避免閃出錯誤的登入畫面。

處理 Google 登入、取消、彈出視窗遭阻擋、失敗與登出。
說明採用 popup 或 redirect 的理由與限制，
並設定明確的登入持久化方式，讓重新整理與同來源新分頁能恢復身分。
登入中的按鈕避免重複操作，失敗後可以重試。
已登入顯示名稱、頭像與登出；缺少頭像或名稱時有替代顯示。

未登入仍可讀取店家、搜尋、使用 Filter 與切換檢視。
不修改 cafes 欄位、匯入指令、Marker 或既有篩選規則。
不建立會員中心、收藏或資料編輯功能。
不要把前端登入狀態當成 Laravel 已完成身分驗證。
不要把服務帳戶 JSON、私鑰或 token 寫進文章與日誌。

執行 typecheck、build 與必要測試，
回報修改檔案、實際結果與未驗證項目。
不要自動 commit 或 push。

登入按鈕不能只分成「登入前」和「登入後」。頁面剛打開、正在等待 Google 回應，以及使用者取消操作時，也要能正常顯示：

實作完成後，先登出，確認搜尋與卡片仍可使用，截下登入入口和店家列表。接著用測試帳號登入，重新整理一次，等帳號狀態恢復後，再截同一個位置。兩張圖使用相同的視窗大小，方便比較。

📸 圖片 2-1｜未登入時仍能瀏覽店家

📸 圖片 2-2｜登入後的帳號狀態

登入之後，試著重新整理和登出

接著測幾個容易漏掉的操作：重新整理、開新分頁、取消登入，再登出重來。下面列的是預期結果，實測時要逐項核對：

完成登入後，再到 Firebase Console → Authentication → Users，重新整理清單，找到測試帳號。這張圖記錄 Firebase 建立的使用者，搭配前面的網站畫面一起看。

📸 圖片 3｜Authentication Users 的測試帳號

先把登入這件事做好

昨天用修改店名來確認資料讀取，今天則從登入、重新整理到登出，檢查同一個帳號在網站上的狀態。
這次範圍先留在這裡：有登入入口，也能登出，找店功能照常使用。之後真的加入需要帳號的操作，再處理 Laravel 的身分驗證與權限。