cloudapper은(는) 무엇을 하나요?
CloudApper는 노코드 플랫폼입니다. 앱은 폼(데이터 모델), 메뉴(내비게이션), 역할, UI 워크플로(클라이언트 측), 백엔드 워크플로(자동화), DevExpress 보고서로 구성되며, App Studio에서 편집하고(폼과 메뉴는 /design/..., 워크플로는 /studio/...), 런타임 앱(/<clientId>/app/<appId>/...)에서 사용합니다.
이 파일은 모든 작업에 적용되는 규칙을 포함합니다. 작업을 수행하기 전에 작업과 일치하는 참조를 읽으십시오:
| 작업 | 읽을 파일 |
|---|---|
| 플랫폼 작동 방식 이해(폼, 필드, 워크플로, 보고서, 캐싱) | references/platform-model.md |
| API 호출(레코드, 워크플로, 폼, 메뉴, 역할, UI 워크플로, 보고서) | references/api-reference.md |
| 워크플로 구축 또는 변경; "실행되지 않음" 또는 느린 워크플로 디버깅 | references/workflow-patterns.md |
| Playwright MCP로 브라우저 구동 | references/playwright-efficiency.md |
| 한 앱/계정에서 다른 앱으로 기능 또는 전체 앱 복사 | references/copy-between-apps.md |
| 디자이너에서 새 앱 또는 폼 구축 | references/building-apps.md |
| 설계, 명명 또는 검토(CloudApper의 SOLID, 명명 규칙, 워크플로/설정/보고서 규칙) | references/conventions.md |
| 솔루션 또는 통합 아키텍처 설계(UKG, REST, 웹훅, SFTP, 미들웨어; 확장성 및 효율성) | references/architecture.md |
| 앱 문서화(기술/문제 해결 가이드 또는 PM 인계 가이드) | references/documentation.md |
| 앱 검토 및 결과/권장 사항 작성 | references/app-review-checklist.md |
| UKG(Pro, WFM, Recruiting, HRSD) 커넥터 작업 | references/integrations-ukg.md |
| 사용자가 CloudApper 작업 방법이나 이 스킬에 포함된 내용을 묻는 경우 | references/learning-and-prompting.md |
환경: 변경 전에 물어보기
대부분의 CloudApper 고객은 Production 앱과 UAT(테스트) 앱을 보유하며, 종종 다른 계정에 있습니다. 변경(폼 저장, 워크플로 편집/활성화 전환, 레코드 편집, 보고서 가져오기, 메뉴 변경)을 수행하기 전에 사용자가 현재 대화에서 이미 언급하지 않은 한 변경 대상이 어떤 환경인지 확인하십시오:
- 질문: "이것은 Production인가요 UAT인가요?"라고 묻고 현재 로그인한 계정/앱 이름을 함께 알려주어 사용자가 불일치를 발견할 수 있도록 하십시오.
- 기본값은 UAT입니다. Production은 읽기 전용으로 취급합니다. 변경, 워크플로 실행, 로그인 또는 읽기를 사용자가 특정 작업을 명시적으로 요청하지 않는 한 수행하지 마십시오. Production 에서 복사하는 것은 읽기 작업입니다. Production 으로 복사하는 것은 변경 작업입니다.
- 모든 쓰기 작업 전에 URL의 클라이언트 ID를 확인하십시오(
/<clientId>/app/<appId>). 쓰기 스크립트는 페이지가 잘못된 클라이언트에 있을 때 실행을 거부해야 합니다. - 프로젝트 정보(계정, 클라이언트/앱 ID, 어떤 앱이 Production인지)는 이 스킬에 저장되지 않습니다. 프로젝트 자체의 노트나 문서 및 메모리에서 찾으십시오. 없으면 사용자에게 물어보십시오.
모든 작업에 적용되는 안전 규칙
- 절대 스스로 워크플로를 실행, 활성화 또는 트리거하지 마십시오. 사용자가 실행을 시작합니다. 정의를 저장하거나 켜기/끄기 전환은 요청받은 경우에만 수행하십시오. 전환이 라이브 동작을 변경할 때는 명확히 알리십시오.
- 편집하기 전에 백업하십시오. 변경할 모든 워크플로/폼의 현재 정의를 로컬의 날짜별 폴더에 먼저 저장하고, 사용자가 결과를 확인할 때까지 보관하십시오. (백업을 너무 일찍 삭제하면 롤백이 불가능해진 경우가 있었습니다.)
- 비밀 정보. 워크플로 커넥터에는 자격 증명(UKG, 기타 공급업체 API, 키)이 포함되어 있습니다. 절대 인쇄, 기록 또는 문서에 포함하지 마십시오. 워크플로 JSON을 검사할 때는 password/secret/apikey/token/clientId와 같은 키를 마스킹하고 구조만 인쇄하십시오. 완료되면 비밀이 포함된 원시 덤프를 삭제하고, 사용자에게 어떤 로컬 폴더에 아직 비밀이 있는지 알리십시오.
- 사용자가 로그인합니다. 절대 비밀번호를 입력하지 마십시오. 사용자에게 Playwright 브라우저에서 로그인하고 완료되면 알려달라고 요청하십시오.
- 개인 데이터. 보관하거나 공유하는 스크린샷에서 이름, 이메일 및 ID를 흐리게 처리하십시오.
- 정직하게 보고하십시오. 테스트에서 작동하지 않은 것이 발견되면 증거(타임스탬프, 상태, 로그 라인)와 함께 말하고 다음 수정을 제안하십시오.
가장 놀라움을 유발하는 6가지 플랫폼 사실
경험적으로 얻은 지식입니다. 자세한 내용과 증거는 references/workflow-patterns.md에 있습니다.
- 워크플로 순서가 중요합니다 (WP-001). 워크플로에 의해 생성/업데이트된 레코드는 워크플로 목록에서 더 나중에(더 높은 Sequence) 위치한 워크플로만 트리거합니다. 대상보다 앞에 위치한 워크플로는 아무것도 트리거하지 않습니다. 환경 간에 목록 순서를 동일하게 유지하십시오.
- 디자이너는 API가 수행하지 않는 숨은 작업을 수행합니다. 디자이너에서 폼을 생성하면 admin 역할에 대한 액세스 권한(권한 32655)도 부여됩니다. API를 통해 폼 본문을 저장하면 폼과 기본 메뉴가 생성되지만 권한은 생성되지 않아 런타임에서 메뉴가 숨겨진 상태로 유지됩니다. 하위 폼도 자체 부모-자식 관계 호출이 필요합니다.
- 상태 트리거는 실제 변경이 필요합니다 (WP-002).
Status _IsUpdated에서 트리거되는 워크플로는 새 값이 이전 값과 같으면 시작되지 않습니다("Running" 상태에서 멈춘 레코드는 다시 "Running"으로 설정해도 재실행할 수 없습니다). - 하나의 워크플로에 대한 트리거된 실행은 한 번에 하나씩 진행되며, 루프가 항상 이를 기다리지는 않습니다 (WP-005). 24개의 레코드를 업데이트하는 루프는 몇 초 만에 완료되지만, 트리거된 24개의 워크플로 실행은 다음 시간 동안 실행됩니다. 그 사이에 두 번째 배치가 시작되면 트리거된 실행이 손실됩니다. 한 번에 하나의 배치를 실행하십시오.
- 런타임은 앱을 캐싱합니다. 디자인 변경 후 앱 이름 옆에 있는 새로 고침 아이콘을 클릭하거나 다시 로그인하십시오. 역할이 액세스할 수 없는 폼의 메뉴는 숨겨지므로 새 폼에는 역할 권한이 필요합니다(복사 체크리스트 참조).
- 라우터는 조건이 참인 모든 경로를 실행합니다 (WP-009). 첫 번째 경로만 실행하는 것이 아닙니다. 하나의 결과만 필요한 경우 경로 조건을 상호 배타적으로 만드십시오.
효율적으로 작업하는 방법
- API를 클릭보다 선호하십시오. 더 빠르고 정확하며 비용이 적게 듭니다. 알려진 API가 없는 경우와 사용자가 보게 될 내용을 확인하기 위해 UI만 사용하십시오.
- Playwright에서는 파일에서 코드를 실행하고(
browser_run_code_unsafewithfilename), 큰 페이로드는 로컬호스트 헬퍼에서 제공하며, 간결한 요약(개수, 이름, 상태)을 반환하고 전체 JSON을 절대 반환하지 마십시오.references/playwright-efficiency.md를 참조하십시오. - 워크플로를 편집하기 전에 디자이너를 열지 말고 API에서 노드 트리(이름, 작업 유형, 폼)를 읽으십시오.
- 모든 변경 후에는 읽기로 확인(API)하고, 워크플로의 경우 빌더를 한 번 열어 렌더링되는지 확인하십시오.
- 대규모 또는 반복 작업: 기존 노드의 템플릿에서 JSON을 생성하는 작은 빌더 스크립트(Python)와 보호된 적용 스크립트를 작성하십시오. 변경이 반복 가능하고 검토 가능하도록 둘 다 프로젝트에 보관하십시오.
문서화 기본값
마크다운만 사용(요청 시에만 PDF), 내부 대상만(고객 이메일 없음), 문서 내 질문은 이유/목적과 함께 제시, 다이어그램은 실행 중인 앱과 사용자/외부 시스템만 표시합니다. 전체 방법: references/documentation.md. 앱에 이미 문서 또는 프로젝트 노트가 있는 경우 앱을 다시 탐색하기 전에 먼저 읽으십시오.
이 스킬에 지식 추가
사용자가 이 CloudApper 스킬에 무언가를 추가하라고 요청할 때("cloudapper 스킬에 이거 추가해줘"):
- 이 스킬 폴더의
inbox/TEMPLATE.md를 읽고 초안을inbox/<yyyy-mm-dd>-<short-name>.md에 상태Hypothesis로 작성하십시오. 일반적으로 작성하십시오. 고객, 앱, 폼, 워크플로 또는 사람 이름, ID, 실제 호스트 또는 자격 증명을 포함하지 마십시오. references/에서 초안이 확인하거나 반박하는 항목을 검색하고, 초안의 검토 노트에 나열하십시오.- 사용자가 검토된 변경 사항을 적용하는 관리자라고 말하지 않는 한
SKILL.md또는references/를 직접 편집하지 마십시오. 사용자에게 초안을 사용하여 Pull Request를 열도록 알리십시오(CONTRIBUTING.md에 흐름이 있습니다).