在證據可見的前提下操作 CMS 平台。

正式部署狀態 — GCP Cloud Run 已上線，RLS 已接入（無新增截圖）

平台現在具備受管理的正式部署路徑：後端、CMS、web 使用 GCP Cloud Run；資料庫為透過 Auth-Proxy unix socket 存取的 Cloud SQL PG17；快取為 TLS 連線的 Upstash Valkey；密鑰在 Google Secret Manager；並建立 api、www、admin 的 Cloud Run domain mappings。本次手冊更新記錄部署狀態與操作邊界，不取代既有本機/manual 截圖。

韌性與 fail-closed 強化（無新增截圖）

一批後端／測試層級的正式環境就緒工作以多個 PR（#107/#108/#110/#111/#112/#113）提交至 dev，以可執行的 chaos 與 fail-closed 測試強化平台的失效行為，並修復過程中發現的一個真實接線缺陷。這些變更的是後端行為而非操作畫面，因此下方截圖仍然成立；此為依據 spec／PR 的內容說明，並非重新執行期擷取。對操作者的實際效果是：訊息／金流 webhook 在並發洪峰下能安全去重、資產上傳與 AI 生成皆 fail-closed（不留孤兒記錄、不洩漏 DB 連線），且 AI 配額在真正的交易路徑上獲得驗證。

• Webhook 洪峰並發去重（REQ-RCC-006，PR #113） — 於受管控的 PostgreSQL 驗證：對同一則 provider 訊息發出 8 個並發 IngestMessage → 僅有一筆草稿與一筆日誌留存，其餘去重且無孤兒記錄。封閉最後一個相鄰相依的 chaos 缺口。
• AI 生成交易洩漏修復（PR #110） — 無效的生成型別過去會在未回滾已開啟交易的情況下返回，緩慢洩漏連線池中的 DB 連線；現已修復並加上回歸守門測試。
• Fail-closed 覆蓋鎖定（PR #104/#107/#108） — 交易範圍內的 AI 配額強制、GraphRAG 在 embedding provider 失效時降級、以及資產儲存後端失效時 fail-closed（不留孤兒資產記錄）。
• 決策邏輯覆蓋（PR #111/#112） — 推薦排序（行為權重 × 時間衰減）與 MCP 連線池 LRU 淘汰，兩者先前皆未受測試守護。

正式環境就緒強化（無新增截圖）

一條後端／設定層級的強化工作以 PR #71 形式提交至 dev，源自一次全庫 mock/stub/false-green 稽核（prod-readiness-wireup-hardening）。它變更的是安全性與接線行為，而非操作畫面，因此下方截圖仍然成立；此為依據 spec／PR 的內容說明，並非重新執行期擷取。

• 租戶資料庫連線在正式環境改為 fail-closed。站台（租戶）資料庫連線過去在正式環境可能退回預設帳密與非 TLS；現在當 ENV=production 時會拒絕預設帳號/密碼並要求 TLS（require/verify-ca/verify-full），與平台資料庫的驗證一致。本機／開發行為不變。
• AI provider 金鑰改為僅伺服器端。CMS 不再讀取 NEXT_PUBLIC_*_API_KEY（會把密鑰打包進瀏覽器）；產生內容改走後端 BYOK 路徑，且管理端 endpoint 退回機制會在 Vercel 式正式環境標記下 fail-closed。
• 真實相依的健康檢查證據。一個空的占位測試被替換為真實的 chaos/resilience 測試，證明 Postgres 當機會回報 HTTP 503（unhealthy）且有界（不會卡住）。
• 文件校正。低估了已實作成熟度的模組指南（OAuth Google/Facebook/Microsoft/Cognito + SAML + LDAP、storage S3/GCS/Azure/R2/local、真實 data-binding）已更正。
• 故障注入下的可靠性已證明（PR #72–#74）。新增 chaos/resilience 測試證明平台會有界地優雅降級、絕不卡死：連線池耗盡時不超過上限且能恢復；租戶資料庫短暫中斷不會被快取、資料庫回來後路由自我修復；AI provider 卡住時以有界的具型別錯誤失敗（客戶端逾時為有限值）。
• 輸入清理器與 fail-closed 守衛已鎖定（PR #75–#77）。名稱→租戶 ID／資料庫名稱清理器，以及正式環境帳密/TLS fail-closed 守衛，新增 property-based + 接線測試，避免未來變更悄悄削弱「使用者輸入與資料庫名稱之間唯一防線」或重新開啟不安全連線路徑。

金流 / 捐款 / 電商（已於瀏覽器驗證）

一個通用、site-scoped 的金流 / 捐款 / 電商模組已以 PR #86 併入 dev（payment-plugin）。捐款只是通用 Payment* 核心的其中一個 purpose 預設。以下是直接由 DB 頁面資料、對真實後端渲染的捐款頁。

公開捐款表單 — PaymentForm（DB 驅動）

已 seed 的 NAELT /site/naelt/support/donate 頁完全由 DB 頁面資料渲染通用 PaymentForm（donation-form manifest 預設）：預設金額、自訂金額、付款人欄位，以及由供應商驅動的送出（Stripe 轉址 / 藍新金流 form-post）。密鑰不會進入瀏覽器 — 後端依 siteID 解析該站的 BYOK 供應商。

證據來源：受治理的 multi-tenant web 環境、真實後端（MSW 關閉）、Playwright 2/2。覆蓋層級：browser-full-integration。就緒狀態：DB→manifest→PaymentForm 渲染與即時 seed 預設金額 PASS；無真實外部供應商結算。

CMS 後台 — 捐款與金流 + 商品與服務

CMS 設定頁新增 捐款與金流 分頁（供應商型錄、引導設定 精靈、遮罩 BYOK 密鑰輪替、捐款/訂單清單 + ezPay 電子發票狀態）與 商品與服務 分頁（型錄 CRUD、SKU 變體、Udemy 式數位內容編輯：公開預覽 vs 付費）。後台 GraphQL 受 RBAC 控管（site.payment.* / site.catalog.*）。

證據來源：受治理的 cms-e2e bundle、真實 /api/auth/login + 真實 GraphQL（MSW 關閉）、Playwright 3/3（即時供應商型錄、型錄分頁、viewer 被拒）。覆蓋層級：browser-full-integration。就緒狀態：後台分頁 PASS；後台主動退款 + 真實結算為殘留項（ISSUE_LOG.md PAY-REFUND-001）。

能力 8 — 金流 / 捐款 / 電商。 通用公開 createPaymentCheckout(purpose) + 供應商註冊表驅動（Stripe Checkout 一次性 + 訂閱；藍新金流 MPG 2.0 + 定期定額）+ ezPay 電子發票自動開立 + BYOK 各站密鑰 + 商品/服務型錄 + 數位授權（付款後自動授予、fail-closed 存取）；donation-form page-builder 元件渲染通用 PaymentForm；單一掛載開關 PAYMENT_MODULE_ENABLED。權威：.agents/specs/payment-plugin/review.md、PR #86。

平台能力 — 端到端詳細範例

以 showcase 租戶作為標準範例（其首頁 + /components 元件展示頁已涵蓋全部 11 個 page-builder 元件），提供平台「內容創作與執行期」能力、依真實契約撰寫的詳細範例。證據層級：依真實 GraphQL／路由／manifest 契約撰寫的示意範例（後端／CLI 層級的命令與 payload 證據），非 live-demo 截圖；各能力下方標註 claim-cap。就緒與否的權威仍為各 spec 的 review.md。

1. 頁面建構器（manifest 驅動、DB 儲存、免重建）

頁面是 sections 陣列；每個 section 指定一個來自 component-manifest SSOT 的元件（componentManifests GraphQL ← backend/internal/componentmanifest/manifests.json）與其 props。CMS 的 Pages 建構器編輯 sections，並以 updatePageSections(id, sections: [JSON!]!) 整個 section 陣列覆寫儲存。公開路由為 force-dynamic，因此把已註冊元件加到頁面是 純 DB 資料變更 — 不需重建映像。

# showcase 首頁由這些 manifest 元件組成（backend/seeds/showcase-pages.json）：
HeroSection · FeatureGrid · ContentList · EventSection · ImpactStats · CTASection
# /components 展示頁額外示範：
ResourceGrid · ContentSection · EnhancedContentList · EnhancedEventCalendar

# 儲存已編輯頁面（整陣列覆寫）— 來自 CMS 頁面建構器：
mutation { updatePageSections(id: "<pageId>", sections: [ /* 完整且有序的 section 陣列 */ ]) { id } }

Claim-cap：經 manifest 驗證的 section 創作；加入已註冊元件為 runtime-proven 的純 DB 操作；不含新元件的重建路徑。權威：shadcn-component-library-a2ui-authoring/review.md。

2. AI 內容生成（後端 BYOK）

生成在伺服器端透過 generateAIContent(prompt, providerId) 執行；CMS 不在瀏覽器持有 provider 密鑰（見 2026-06-18 安全強化）。每個站台宣告自己的 provider 設定檔（Google Vertex/Gemini、AWS Bedrock、Azure AI/OpenAI、OpenAI、Anthropic、TensorZero、OpenCode），含 BYOK 密鑰 metadata 與用量帳本。

mutation { generateAIContent(prompt: "為我們的新工作室撰寫一篇上線部落格文章", providerId: "") { content model tokensUsed } }
# providerId "" = 使用站台預設設定檔；後端解析 BYOK 金鑰，瀏覽器永遠不接觸金鑰。

Claim-cap：後端路由的生成契約；本手冊不含真實外部 provider 呼叫。權威：site-byok-ai-provider-settings/review.md。

3. 內容管理（內容型別 · 草稿/發布 · 表單投稿 · RBAC）

內容以內容型別建模，並經 draft → published → unpublished 狀態生命週期（依狀態列表）。公開表單投稿進入受治理的投稿流程（送出 → 核准/退回）於 CMS 審核。每個操作皆經權限檢查（例如 site.content.*、site.social.read/manage）。

# 公開站台表單區塊（showcase /contact）→ 後端發出 submissionId → CMS 審核佇列（核准/退回）。
# 內容列表/詳情頁依 contentType（article/event）透過 ContentList/ContentSection 渲染 DB 內容。

Claim-cap：草稿/發布廣度 + 投稿流程於 unit/後端層級證明（LAUNCH-007）；受治理 bundle 執行時，CMS 審核為 backend-backed。

4. MCP 與 Agent 友善介面

每個站台提供 agent 友善的讀取介面：Model Context Protocol 端點 /mcp（list/get/search contents）、MCP 探索文件 /.well-known/mcp.json、以及每站台與平台層級的 llms.txt。非 VIP 租戶的讀取在啟用 SCHEMA_TIER_APP_USER 時由 D2 Row-Level Security（路由的非超級使用者角色）限制。

# 透過 MCP（HTTP/JSON-RPC）探索 + 讀取站台：
GET /.well-known/mcp.json        # server 描述
POST /mcp  → tools: list_contents(site) · get_content(site, slug) · search_contents(site)
GET /site/showcase/llms.txt      # agent 友善站台摘要

Claim-cap：/mcp 讀取路徑於完整本機 stack 為 backend-backed，且以非超級使用者角色於受治理 PG 受 RLS 限制；雲端部署/UAT 仍為 owner/infra（SPTR-LIVE-WIRING-001）。權威：schema-per-tenant-routing-rls/review.md。

5. Agent Skills（每站台宣告式 skill 範本）

站台定義宣告式 skill/prompt 範本（internal/skilltmpl；seeds skills-platform.json/skills-naelt.json）用於轉換/優化內容 — 無腳本/程式碼執行、無 sandbox。範本有版本控制，透過 upsertSkillTemplate 管理（建立 ⇒ v1；更新 ⇒ 版本遞增；已發布範本不可變；跨站台 fail-closed；@requirePermission("site.social.manage")）。

mutation { upsertSkillTemplate(input: { id: 0, kind: "post-conversion", name: "LINE→部落格", body: "..." }) { id version kind } }
# id:0 → 建立版本 1；id>0 → 更新 + 版本遞增。

Claim-cap：宣告式範本契約（無程式碼執行）；service + RBAC 於 enttest 層級證明。權威：messaging-ingest-social-publishing/review.md。

6. A2UI（agent 透過 manifest 創作頁面）

A2UI agent（backend/internal/adk）從同一份 component-manifest 目錄創作 page-builder sections，經 manifest 驗證關卡 + design-contract「不杜撰事實」誠實邊界 + 不可信內容邊界。它提出符合 manifest 的 sections，由你透過正常的 updatePageSections 儲存 — 因此 agent 產出與人工頁面建構編輯受完全相同的契約約束。

# A2UI 流程：目錄提示（componentManifests）→ agent 提出 sections → manifest 驗證關卡
#            → design-contract 誠實檢查 → 人工審核 → updatePageSections（儲存）。

Claim-cap：經 manifest 驗證的創作 + 誠實邊界於 unit/contract + dev-web 瀏覽器層級證明；不含 live-LLM 往返主張。權威：shadcn-component-library-a2ui-authoring/review.md。

7. 社群媒體 — 完整流程（接收 → AI 轉換 → 審核 → 發布）

平台無關、整合優先的管線（messaging-ingest-social-publishing）：入站訊息進入單一標準 webhook、正規化、經站台 AI provider + 宣告式 skill 範本轉為貼文草稿、排入審核佇列，再透過可插拔 publisher drivers 發布。全程站台範圍 RBAC（site.social.read/manage/publish/secret）；密鑰為站台 BYOK。

# 1) 接收 — providers 自我註冊；每平台/站台單一標準入站路由：
POST /api/webhooks/messaging/{platform}/{site}    # 例如 line、telegram、whatsapp（簽章驗證、fail-closed）

# 2) 轉換 — 正規化訊息 → 貼文草稿，經 SiteAIProviderResolver + 每站台 skill 範本（無 sandbox）。
# 3) 審核 — 草稿進入 CMS「Messaging & Social」審核佇列：
mutation { updatePostDraft(input: { id: "<draftId>", blocks: [...], metadata: {...} }) { id status version } }   # 已發布草稿不可變
# 4) 發布 — 透過可插拔 SocialPublisher driver（例如 Facebook Graph）：
mutation { publishPostDraft(id: "<draftId>") { id status } }   # @requirePermission("site.social.publish")

Claim-cap：repo-local 整合功能 + 受治理 cms-e2e backend-backed Messaging & Social 瀏覽器 smoke（T16.6）；不含真實 LINE/Telegram/WhatsApp 傳遞、真實 Facebook 發布、真實 OAuth、或 live-AI 品質。權威：messaging-ingest-social-publishing/review.md。

本次查核後新交付的後端工作（無新增截圖）

在下方 2026-06-16 執行期擷取之後，有兩條後端／API 層級的工作以 PR 形式提交至 dev。它們新增的是後端行為，而非新的操作畫面，因此本頁截圖仍然成立；此為依據 spec／PR 的內容說明，並非重新執行期擷取。

• Spawn 現在會佈建 VIP 實體資料庫（PR #68）。先前一個已 spawn 的 VIP 站台只是指向「不存在的資料庫」的控制平面紀錄（這正是先前備份證明必須手動建立 cms_showcase 的原因）。SpawnSite 現在會為 VIP 站台建立實體 cms_<slug> 資料庫並將 schema 遷移進去；非 VIP（SCHEMA/D2）站台則依設計維持「僅紀錄」。失敗即關閉（fail-closed）：若佈建失敗，會回滾站台紀錄，不留下懸空項目。
• Messaging & Social 草稿／範本編輯 API（PR #69）。updatePostDraft（於發佈前編輯草稿的 blocks／metadata——已發佈貼文不可變更）與 upsertSkillTemplate（建立，或更新並遞增版本，技能範本）兩個 GraphQL 操作現已實作，皆以 site.social.manage 權限把關。CMS 內對應的編輯 UI 為已追蹤的後續項目。