docs: Phase 3 收尾 — §8 釐清零件投稿走 PR、BACKLOG 記新需求

- DECISIONS §8 釐清：執行鏈路(高頻)不依賴 CI；零件投稿(稀有)走 PR/CI 是例外、不違反精神
  （CF Workers 不能 runtime 編譯 wasm，CI 是唯一能跑 wasm 又執行者碰不到的 venue）
- BACKLOG 步驟 4 收尾（投稿改 PR，標已做/不做/未來搬 CI）
- BACKLOG 步驟 5 被 PR 方向取代；新增步驟 5b 資料外流警示（先做，需新 SDD）
- BACKLOG 待決策加：用戶 API 保護機制（入站認證，資安優勢）、recipe/part/function 架構釐清
- component-gatekeeping tasks.md 收尾狀態

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

DECISIONS.md

@@ -313,11 +313,20 @@ arcrun-gui 拖拉畫布、arcrun-mcp 命名大改、新 primitive、Gemini/Codex
 
 ---
 
-## 8. 不依賴 GitHub Actions
+## 8. 執行鏈路不依賴 GitHub Actions（零件投稿例外，2026-05-30 釐清）
 
-Arcrun 第一期的執行鏈路（init / push / run / 零件投稿）全在「用戶機器 + Cloudflare」之間，
-不經過 GitHub Actions。零件編譯 / 測試本地跑即可（TinyGo 編譯、Gherkin 測試都是本地一行指令）。
-理由見 §0 第一條。
+Arcrun 第一期的**執行鏈路**（init / push / run / recipe）全在「用戶機器 + Cloudflare」之間，
+不經過 GitHub Actions。這是常態高頻動作，用戶不該被 CI 卡住。理由見 §0 第一條。
+
+**零件投稿是例外，走 GitHub PR + CI（2026-05-30）：**
+- 零件投稿是**稀有低頻**事件（primitive 極少、未來絕大部分是 recipe；建零件要過人類閘門）。
+- 稀有事件用 PR 治理最自然：**PR 必須有人 merge = 人類閘門**（AI 偽造不了 GitHub approve）；
+  把關（假零件偵測 / 純WASI / Gherkin / 覆蓋檢查）由 **CI（PR check）跑**。
+- 為何非 CI 不可：**CF Workers 禁止 request-time 編譯 WASM** → registry Worker 跑不了 Gherkin / 向量；
+  CI 有 tinygo + 能 runtime 跑 wasm，是唯一既能跑 wasm 又「執行者碰不到」的 venue。
+- **這不違反 §8 精神**：§8 防的是「高頻執行鏈路被 CI 卡住」；零件投稿稀有、且該由 PR 把關，
+  用 PR/CI 反而更對。兩者是不同性質的事。
+- 詳見 `.agents/specs/component-gatekeeping/`。
 
 ---