Webflow Cloud Apps (Webflow 雲端應用程式)

Webflow Cloud 應用程式

使用 data_apps_tool 來建立 GitHub 原始碼應用程式、回答營運問題，以及管理 Webflow Cloud 應用程式的環境。請從使用者的成果出發，僅收集必要的證據，並區分觀察結果與結論。

當任務需要 CLI/本地原始碼應用程式的建立或部署，或者需要建立或更新環境變數時，請使用 webflow-cli:cloud 技能。用戶端建置的輸出不會傳送至 Webflow，也無法透過 MCP 復原。

說明

1. 確立範圍

使用使用者要求或現有任務上下文所建立的 Webflow MCP 連線。如果只有一個連線處於活動狀態，請直接使用，無需要求使用者選擇或重新確認區域。如果有多個活動連線且預期目標不明確，請在進行依賴目標的操作之前，要求使用者釐清。請勿為了從缺少資源或存取錯誤中復原而切換區域。

在將現有的 MCP 應用程式或環境移交給 CLI 進行設定寫入或部署之前，請比較它們所設定的區域。如果兩者不同，請不要假定任一個是正確的，也不要靜默地重新定位任一工具。從明確的任務上下文解決預期目標；如果無法解決衝突，請詢問使用者。在衝突解決之前，暫停依賴的變更操作。

一旦確立預期區域，請驗證 CLI 能夠讀取確切的 MCP 應用程式和環境 ID，並將該區域和這些 ID 明確帶入後續的變更操作。僅憑登入狀態或區域標籤是不夠的。如果驗證失敗，請報告失敗，無需推斷其原因，並暫停依賴的變更操作。繼續進行目標已確立的獨立工作。

1. 在任何其他 Webflow MCP 工具之前，先呼叫 webflow_guide_tool。即時指南和動作模式對於目前的引數和回應具有權威性。
2. 對於 Webflow 操作，使用 Webflow MCP 工具，但明確的 CLI 交接以處理環境變數值的情況除外。絕對不要直接呼叫 Webflow API。
3. 在每次工具呼叫中包含必要的 context 參數。以第三人稱視角撰寫 15-25 個字。
4. 根據任務所需的能力進行路由：
   • 使用 data_apps_tool 來建立 GitHub 原始碼應用程式；檢查應用程式、環境、網域、部署記錄、日誌和變數元資料；管理 GitHub 原始碼和環境；以及加入 GitHub 部署佇列。
   • 使用 data_variable_tool 來處理設計師的顏色、尺寸、字型和 CSS 變數。
   • 使用 webflow-cli:cloud 來處理 CLI/本地原始碼應用程式、本地建置和部署，或建立和更新環境變數值。
5. 如果無法使用 data_apps_tool，請回報 Cloud Apps MCP 功能未啟用。不要透過直接 API 請求繞過它。

絕對不要要求使用者將環境變數值或機密貼到聊天中。對於建立或更新操作，請委派給 webflow-cli:cloud，並要求使用隱藏提示、stdin 或受保護的檔案。絕對不要將機密作為位置引數傳遞。

2. 解決目標

按以下順序發現識別碼：

list_apps -> app_id
list_environments(app_id) -> env_id
list_deployments(app_id, env_id) -> deployment_id

應用程式名稱僅在站台內是唯一的，因此請使用 site_id + name 來解析一個已命名的應用程式。如果有多個資源匹配，請呈現可區分的元資料，並要求使用者在任何變更操作之前選擇一個。使用即時指南了解篩選、分頁、游標和動作批次處理機制。

3. 遵循匹配的使用者情境

建立一個 GitHub 原始碼應用程式

1. 確立應用程式名稱、標準的 GitHub 儲存庫 URL、分支、可選描述，以及它是獨立應用程式還是附加到現有站台。
2. 對於附加到站台的應用程式，解析站台 ID。對於獨立應用程式，省略 site_id。
3. 在預覽之前套用掛載合約：
   • 獨立應用程式始終掛載在 /；省略 mount 或使用 /。
   • 附加到站台的應用程式預設掛載在 /app，拒絕 /，並在覆寫預設值時需要一個有效的非根目錄掛載點。
4. 說明建立獨立應用程式需要一個工作區範圍的使用者權杖。Webflow 會推導 GitHub 安裝並驗證儲存庫存取權；不要請求安裝 ID。
5. 使用其預設的試運行呼叫 create_app。顯示儲存庫、分支、附件、站台（如果適用）、掛載點和初始部署嘗試。
6. 要求 confirm。在確認後、執行前立即記錄開始時間並產生一個穩定的 idempotency_key；使用 dry_run: false 執行，然後記錄完成時間。僅將該金鑰重複用於此建立的確切重試。
7. 將建立和初始部署視為單獨的結果。即使 deployStatus 為 skipped 或 failed，傳回的應用程式也表示建立成功。對於 triggered，檢查環境和部署；對於 skipped，檢查分支或推送提交；對於 failed，保留應用程式並單獨檢查或重試部署。
8. 如果應用程式或結果無法讀取，請在重試前進行調解：
   • 對於附加到站台的應用程式，使用 site_id + name 收集候選項目；對於獨立應用程式，依名稱收集候選項目。
   • 在兩種情況下，將每個候選項目的名稱、sourceUrl 和 createdAt 與請求的儲存庫和記錄的執行視窗進行比較。
   • 僅在恰好一個候選項目匹配時，才繼續處理環境和部署。在建立的應用程式仍不明確時，不要重試。
9. 絕對不要因為部署失敗而自動刪除已建立的應用程式。不要將初始部署儀表板連結視為環境的公開 URL。

我正在查看哪個應用程式和環境？

1. 使用 list_apps 來尋找應用程式，並使用 get_app 來取得其元資料，包括 sourceUrl 和 siteAttached。
2. 使用 list_environments 來報告分支、掛載點、publicUrl 和最新部署狀態。如果 publicUrl 為 null，請報告沒有可用的使用者面向環境地址；不要自行建構一個。
3. 當使用者詢問應用程式在哪裡可以存取時，使用 get_app_domains。
4. 說明自訂網域結果不包括預設的 *.webflow.io 主機名稱。附加到一般 Webflow 站台的應用程式的網域可能屬於父站台，並由同級應用程式共享。

部署了什麼，並且它健康嗎？

1. 使用 list_environments 來取得環境的最新部署狀態。
2. 使用 list_deployments（最新的優先），然後使用 get_deployment 來取得所選部署的詳細時間線和版本元資料。
3. 將 starting、building 和 deploying 視為活動狀態。準確報告任何其他狀態，而不是猜測其含義。
4. 失敗的階段會設定 buildFailedAt 或 deployFailedAt，而其對應的完成時間戳記仍為 null。null 的完成時間戳記本身並不能證明該階段仍在執行。
5. 報告可觀察到的內容：所選的應用程式和環境、部署狀態、版本或提交元資料（如果傳回）、階段時間戳記和證據缺口。

部署為何失敗？

1. 使用 get_deployment 擷取部署，並從其狀態和時間戳記識別失敗的階段。
2. 僅在 logsAvailable 為 true 時才呼叫 get_build_logs。從較窄的 since 視窗或 q 篩選條件開始，然後僅在需要時才擴大範圍。
3. 當需要完整結果時，持續分頁直到 nextCursor 為 null。
4. 將 logsAvailable 視為保留和檢索信號，而不是每個階段都產生日誌條目的證明。
5. 將空結果視為「沒有匹配的可檢索伺服器端日誌」，而不是建置成功或沒有產生錯誤的證明。
6. 在使用者機器上產生的建置輸出不受 MCP 管轄。僅在使用者表示部署是使用 CLI 建置時才提及此點；將他們導向原始的 CLI 輸出以了解本地建置失敗。
7. 報告失敗的階段、相關時間戳記、最小有用的證據、推斷的原因以及任何不確定性。不要僅僅重述原始日誌。

正在執行的應用程式為何失敗？

1. 解析確切的環境並呼叫 get_runtime_logs。
2. 在檢索廣泛視窗之前，先透過 since 和 q 縮小範圍。當結論取決於某個條目的缺失時，請完整分頁。
3. 執行階段日誌可能因為保留政策而無法使用。將空結果視為無可檢索的日誌，並報告此限制。
4. 在有用時，將執行階段證據與最新的部署記錄相關聯，但不要僅憑時間推斷因果關係。
5. 報告觀察到的錯誤模式、受影響的間隔、可能的原因、證據和限制。

是否已存在必要的設定？

1. 從權威來源確立必要的金鑰集合：使用者提供的金鑰列表、專案設定模式或記錄的需求，或使用者明確指定為完整的參考環境。
2. 如果來源是包含值的受保護檔案，請在本地執行確定性的僅提取金鑰操作，並僅輸出金鑰名稱。絕不要透過對模型可見的讀取來開啟該來源，也不要在聊天或工具輸出中包含其值。
3. 從使用者、專案模式或記錄的需求，或明確指定為權威性保密的參考環境，取得每個必要金鑰的權威性保密指定。.env 檔案或純文字金鑰列表僅能確立名稱；絕不要從金鑰名稱推斷保密性。
4. 解析環境，呼叫 list_variables，並將其金鑰和保密元資料與已確立的需求進行比較。它證明的是已設定了什麼，而不是需要什麼。在得出某個金鑰缺失的結論之前，請完成所有分頁。
5. 僅報告金鑰和元資料。機密條目具有 isSecret: true 且沒有值；缺少機密值是預期的。
6. 如果必要的集合或任何保密指定未解析，請在 CLI 變更或依賴的部署之前停止，除非使用者明確確立不需要任何設定。
7. 對於缺少或錯誤分類的金鑰，路由到 webflow-cli:cloud，無需在聊天中請求值。寫入後，使用 list_variables 驗證必要的金鑰和保密性。如果部分失敗，請報告失敗的金鑰（不含值）並在部署前停止；保留成功的金鑰和環境。

為什麼這個環境正在服務錯誤的分支或路由？

1. 解析確切的環境並報告其目前的分支、掛載點、publicUrl 和最新部署狀態。報告 null 的 publicUrl，不要建構地址。
2. 將目前的分支和掛載點與使用者預期的映射進行比較。如果請求只是診斷性的，在報告不匹配後停止。
3. 如果修正會更改掛載點，請呼叫 get_app 並使用 siteAttached：僅在值為 false 時 / 才有效；附加到站台的應用程式需要一個非根目錄的掛載點。不要從 siteId 推斷附件。
4. 對於修正，顯示確切的「之前與之後」映射。說明 update_environment 是立即生效的，沒有試運行，並且不會部署程式碼。
5. 要求 confirm，呼叫 update_environment 一次，並報告傳回的環境、publicUrl 和 mountRefreshStatus。
6. 對於無法讀取或不確定的結果，找到原始的 env_id。如果使用預期的新分支作為篩選條件，僅在傳回的環境的 ID 等於該原始 env_id 時才接受它，然後將其分支和掛載點與請求的值進行比較。不同的 ID 或沒有唯一匹配的原始目標是不明確的：不要繼續或重試。在更改分支的更新之後，絕不要重複使用舊的分支篩選條件。
7. 掛載重新整理失敗或未知並不表示環境更新已被回滾。將路由報告為不確定，不要僅因為重新整理失敗而重試。
8. 如果分支已更改且使用者希望部署其程式碼，請將 trigger_deployment 視為一個單獨的、經過預覽和確認的變更操作。

為一個分支建立隔離環境並部署它

1. 解析現有的應用程式，呼叫 get_app，並在預覽變更操作之前使用 siteAttached 驗證建議的掛載點。
2. 遍歷 list_environments 的分頁以檢查請求的分支或掛載點是否已被使用。
3. 顯示建議的分支和掛載點。說明 create_environment 是立即生效的，沒有試運行，並且建立映射而不部署程式碼。
4. 產生一個穩定的 idempotency_key，要求 confirm，並呼叫 create_environment。僅將該金鑰重複用於確切的重試。
5. 報告傳回的環境、publicUrl 和 mountRefreshStatus。如果結果不確定，搜尋預期的分支並比較環境 ID、分支和掛載點；使用傳回的 ID 來區分並發的建立操作。在建立的環境仍不明確時，不要重試。
6. 重新整理失敗表示建立成功，但路由可能不完整。不要自動重試建立或刪除環境。
7. 在部署這個新環境之前，將「是否已存在必要的設定？」作為強制閘道。僅在需求與保密性得到驗證，或使用者明確確立不需要任何需求時才繼續。然後使用下面的部署工作流程進行預覽、確認、歸因和監控。

這個部署可以重試、回滾或從分支 HEAD 重建嗎？

使用變更操作的預設試運行作為能力檢查。不要從缺失的日誌、應用程式元資料或部署元資料推斷資格。

對於從連接的分支或先前的確切提交進行的新部署：

1. 解析環境。對於重試或回滾，也要解析確切的先前部署。
2. 僅在使用者請求時、部署證據表明缺少或錯誤分類的變數時、所選提交有記錄的設定需求時，或伺服器因設定問題拒絕部署時，才執行設定發現。