Webflow Cloud Apps

Webflow Cloud Apps은(는) 무엇을 하나요?

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. 환경 변수 값에 대한 명시적 CLI 핸드오프를 제외한 Webflow 작업에는 Webflow MCP 도구를 사용합니다. Webflow API를 직접 호출하지 마십시오.
3. 모든 도구 호출에 필수 context 매개변수를 포함합니다. 15-25단어를 3인칭 시점으로 작성합니다.
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. 기본 dry run으로 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. 실패한 단계는 해당 완료 타임스탬프가 null로 남아 있는 동안 buildFailedAt 또는 deployFailedAt을 설정합니다. 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는 즉시 실행되고, dry run이 없으며 코드를 배포하지 않는다고 설명합니다.
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는 즉시 실행되고, dry run이 없으며, 코드를 배포하지 않고 매핑을 생성한다고 설명합니다.
4. 하나의 안정적인 idempotency_key를 생성하고 confirm이 필요하며 create_environment를 호출합니다. 해당 키는 정확한 재시도에만 재사용합니다.
5. 반환된 환경, publicUrl 및 mountRefreshStatus를 보고합니다. 결과가 불확실한 경우, 예상 브랜치를 검색하고 환경 ID, 브랜치 및 마운트를 비교합니다. 반환된 ID를 사용하여 동시 생성을 구분합니다. 생성된 환경이 모호한 상태에서는 재시도하지 않습니다.
6. 실패한 새로 고침은 생성이 성공했지만 라우팅이 완료되지 않았을 수 있음을 의미합니다. 생성을 다시 시도하거나 환경을 자동으로 삭제하지 마십시오.
7. 이 새 환경을 배포하기 전에 '필요한 구성이 있나요?'를 필수 게이트로 따릅니다. 요구 사항 및 비밀이 확인되거나 사용자가 필요하지 않다고 명시적으로 설정한 경우에만 계속합니다. 그런 다음 아래 배포 워크플로를 사용하여 미리보기, 확인, 귀속 및 모니터링을 수행합니다.

이 배포를 재시도, 롤백 또는 브랜치 HEAD에서 재빌드할 수 있나요?

변경의 기본 dry run을 기능 확인으로 사용합니다. 누락된 로그, 앱 메타데이터 또는 배포 메타데이터에서 적격성을 추론하지 마십시오.

연결된 브랜치 또는 이전 정확한 커밋에서 새 배포의 경우:

1. 환경을 확인합니다. 재시도 또는 롤백의 경우 정확한 이전 배포도 확인합니다.
2. 사용자가 요청하는 경우, 배포 증거가 누락되거나 잘못 분류된 변수를 나타내는 경우, 선택한 커밋에 문서화된 구성 요구 사항이 있는 경우, 또는 서버가 구성을 위해 배포를 거부하는 경우에만 구성 검색을 수행합니다.