---
tags: [部署, 平台原則, 架構決策]
gloss: 執行鏈路（workflow/recipe/API 呼叫）不依賴 CI，走本地 script 部署。零件投稿（稀有）才走 PR/CI 讓人做閘門。
---
# 不依賴 CI — 執行鏈路 vs 零件投稿

← [[decisions/00-INDEX]]

**來源**：`system-dev/wiki/decisions-summary.md`（不依賴 CI）、`.claude/rules/05-deploy-convention.md`
**最後更新**：2026-06-27

## 摘要
用戶操作（workflow、recipe、API 呼叫）頻繁，走 CI 會有分鐘級延遲，不可接受。故執行鏈路用本地 script（`scripts/local-deploy.sh`）同步到 Hetzner。零件投稿稀有、走 PR/CI 把關，人 merge=天然閘門，CI 驗收 WASI 沙箱。

## 重點
- **執行鏈路**（高頻）：用戶實時操作（`acr run`、`acr workflow push`、API call），不能等 CI 跑（分鐘延遲 unacceptable）→ 用本地 script 直接同步。
- **本地部署機制**：`scripts/local-deploy.sh` 透過 `scp` / `rsync over ssh` 把更新推到 Hetzner `/opt/mira` 等目錄，直接、快速。
- **零件投稿**（稀有）：幾周到幾月一次新零件 → 走 GitHub PR → 人 review + merge → CI 驗收（WASI 沙箱、Gherkin、假零件檢測）。
- **為什麼 CI 驗收零件**：CI 容器支援 runtime 執行 wasm、檢驗行為；CF Worker 沒有 wasm runtime（sandboxed 沒有 syscall），無法驗證。
- **人 merge 的價值**：GitHub merge 需人類 approve，無法被 AI 偽造，天然的人類閘門。
- **不走 GitHub Actions 執行鏈路**：Actions 容易被濫用（當初 richblack 被 flag 的成因），且分鐘延遲。

## 實體
- **執行鏈路**（execution path）— 用戶實時操作的頻繁路徑：workflow 建立、recipe 推送、API 呼叫。
- **本地部署**（local deployment）— 透過 ssh/scp 直接從本機同步到伺服器，無 CI 介入。
- **零件投稿**（component submission）— 新零件上傳的稀有操作，走 GitHub PR。
- **PR/CI 把關**（PR/CI gatekeeping）— 零件投稿需人 merge 且 CI 驗收，雙層防護。

## 關聯
### 內文知識關係
- 執行鏈路 >> 高頻且實時 >> 不走 CI
- 本地部署 >> 支撑 >> 執行鏈路
- 零件投稿 >> 稀有且一次性 >> PR/CI 把關
- 人 merge >> 提供 >> 人類閘門
### 卡片關係
- [[不依賴CI-執行鏈路vs零件投稿]] >> 同源於避免被flag鐵律 >> [[self-hosted部署-共享install加指紋跳過]]