# 網站維護 SOP — 酒桃數位服務坊

## 一、每日檢查清單

### 自動檢查（cron 驅動）
- `🕐 08:00` — 推播排程（農民曆 07:00 / 星座 08:00 / 代課 08:30）
- `🕐 09:00` — 網站健康檢查（所有頁面回應 200 + 內容完整性）
- `🕐 每小時` — LINE Webhook 回應正常（cron job: site-healthcheck）

### 人工檢查（Stone 有空時看一眼）
- 打開網站首頁 → 輪播正常、今日運勢 Widget 正常
- 打開 LINE 官方帳號 → 收到今天的推播
- 抽查任一子頁面（天機閣/七桃家/黃金家）

---

## 二、維護機制

### 2.1 網站健康檢查（by 龍蝦粥）
- 腳本：`/tmp/site-healthcheck.js`
- 檢查 14 個頁面：狀態碼 200、內容長度門檻、關鍵字檢測
- cron 排程：每小時執行一次
- 異常時通知 Stone

### 2.2 內容更新機制（各蝦負責）

| 內容 | 更新頻率 | 執行者 | 狀態 |
|------|---------|--------|------|
| 農民曆 | 每日（推播時自動生成） | line-push.js | ✅ 自動 |
| 星座運勢 | 每日（推播時自動生成） | line-push.js | ✅ 自動 |
| 代課公告 | 每日 08:30（或暫存檔案） | 健身蝦→line-push.js | 🔄 半自動 |
| 旅遊內容 | 每週 | 七桃蝦 | 📅 排程 |
| 財經報告 | 每日 | 黃金蝦 | 📅 排程 |
| 命理服務 | 靜態（無需更新） | — | ✅ 穩定 |
| 匯率換算 | 即時（API 驅動） | exchange.html | ✅ 即時 |

### 2.3 異常處理流程

```
發現異常（自動檢查 / Stone 回報）
  ↓
龍蝦粥確認是否為真實問題
  ├─ 是：判斷修復對象
  │   ├─ 網站前端問題 → 龍蝦粥修復 server.js / HTML
  │   ├─ 推播問題 → 檢查 line-push.js / LINE token
  │   ├─ 內容過期 → 通知對應蝦蝦更新
  │   └─ 部署問題 → 重新 deploy
  └─ 否：調整健康檢查腳本的判斷條件
```

---

## 三、部署規則（強制遵守）

### 3.1 部署前置檢查

**任何部署前，必須確認：**
1. ✅ 所有變更已 commit（避免 deploy 版本不一致）
2. ✅ server.js / line-push.js syntax 檢查通過
3. ✅ `scripts/deploy.sh` 執行（自動打包 + 部署 + 健康檢查）
4. ✅ 所有 14 頁面健康檢查通過
5. ❌ **禁止使用 `gcloud run deploy --image=...` 單獨部署** — 這會沿用舊 image，新 code 不會生效
6. ❌ **禁止直接編輯 Cloud Run 的 revision 設定** — 只透過 `deploy.sh` 或 `gcloud run deploy --source .`

### 3.2 部署指令（唯一正解）
```bash
cd /Users/lobsterbisque/.openclaw/workspace/destiny-portal
./scripts/deploy.sh
```

或手動三步驟（僅在 deploy.sh 無法使用時）：
```bash
cd /Users/lobsterbisque/.openclaw/workspace/destiny-portal
gcloud builds submit --tag asia-east1-docker.pkg.dev/lobsterbisque-web-access/cloud-run-source-deploy/destiny-portal
gcloud run deploy destiny-portal --image=asia-east1-docker.pkg.dev/lobsterbisque-web-access/cloud-run-source-deploy/destiny-portal --region asia-east1 --platform managed --allow-unauthenticated --quiet
```

⚠️ 重點：一定要 `gcloud builds submit`（從原始碼建立新 image），不能只 `deploy --image=old-image`。

### 3.3 部署後的立即確認
- 健康檢查自動執行（deploy.sh 第 5 步）
- 手動打開首頁確認渲染正常
- 確認 LINE Webhook 仍正常回應
- 若有異常：`gcloud run revisions list` 找到前一個正常版本，`gcloud run deploy --revision=...`

### 3.4 版本記錄
- 每次部署寫入 `deploy-revisions.log`
- 格式：`YYYYMMDD-HHMMSS | COMMIT | PASS=14 FAIL=0 | URL`
- 若部署失敗，可快速回退到上一個 PASS=14 的 revision

---

## 四、功能維護

### 4.1 LINE Push 排程（三 cron jobs）

| 時間 | 內容 | Cron Job ID |
|------|------|-------------|
| 07:00 | 農民曆推播 | — |
| 08:00 | 星座運勢推播 | —（原 12:00 已移到 08:00） |
| 08:30 | 代課公告推播 | — |

### 4.2 LINE Rich Menu
- 最終版 ID: 視當前 active 而定（見 memory/2026-05-09.md）
- 設計規格：emoji 300px + 文字 96px 粗體，2x3 網格
- 修改方式：透過 LINE API 刪除重建
- 圖片：需小於 1MB PNG

### 4.3 LINE Token 管理
- Channel Access Token 儲存於 server.js + line-push.js
- 過期時需重新發行 ↔ 更新兩個檔案 → 重新部署
- Webhook URL: `https://destiny-portal-949811055845.asia-east1.run.app/webhook`

### 4.4 Cloud Run 部署

```bash
cd /Users/lobsterbisque/.openclaw/workspace/destiny-portal
gcloud run deploy destiny-portal --source . --quiet
```

- 專案：`lobsterbisque-web-access`
- 區域：`asia-east1`
- 部署後需確認所有頁面正常回應

---

## 五、重大變更流程

1. 修改程式 → 本地測試 → 部署 Cloud Run
2. 部署後執行健康檢查確認全部通過
3. 通知 Stone 變更完成
4. 更新記憶檔（memory/YYYY-MM-DD.md）

---

## 六、應急處理

| 狀況 | 處理方式 |
|------|---------|
| 網站全掛（500/無回應） | 重新 deploy 上一版 revision |
| LINE 推播失敗 | 檢查 token 是否過期，重新發行 |
| 單一頁面壞掉 | 檢查對應 HTML，修復後 deploy |
| 匯率 API 掛了 | exchange.html 有 fallback 靜態值 |
| 廣告點擊追蹤 404 | 重啟 server.js 的 `/api/track-click` 端點 |
| 內容過期 | 通知對應蝦蝦產出新內容 |