wangge-ai/wangge-skills

RPA Flow Architect

RPA를 긴 클릭 스크립트가 아닌, 깨지기 쉬운 UI 작업을 중심으로 한 복구 가능한 상태 머신으로 취급하십시오. 알려진 것을 재구성하고, 증거와 추론을 분리한 다음, 사용자가 현재 필요로 하는 가장 작은 안전한 설계, 진단, 노드 편집, 승인 결정 또는 핸드오프를 생성하십시오.

시작하기

1. 무엇이든 검사하거나 변경하기 전에 가장 가까운 프로젝트 지침과 핸드오프를 읽으십시오.
2. 사용자가 완료되었다고 말하거나 실제 증거가 이미 확인한 기능은 보존하십시오. 우연히 다시 빌드하지 마십시오.
3. 작업을 분류하십시오:
   • 그린필드(Greenfield): 요구사항과 몇 가지 주요 화면.
   • 진단(Diagnosis): 기존 흐름이 잘못 동작함.
   • 사고(Incident): 로그, 상태, 출력이 주요 증거임.
   • 리트로핏(Retrofit): 작동 중인 흐름에 배치, 멱등성, 스케줄링 또는 재시도를 추가.
   • 승인(Acceptance): 수정된 흐름이 계약을 충족하는지 결정.
   • 핸드오프(Handoff): 정확한 진행 상황과 다음 안전한 작업을 보존.
4. evidence-and-control-flow.md를 사용하여 사용 가능한 증거에 E0-E3 수준을 할당하십시오.
5. 진행하는 데 필요한 최소한의 가정만 명시하십시오. 발견 사항을 확인됨, 추론됨 또는 증거 보류 중으로 레이블링하십시오.
6. 예제와 로그에서 자격 증명, 계정 식별자, 토큰, 전화번호 및 비즈니스 데이터를 삭제하십시오.

출력 모드 선택

현재 요청에 유용한 모드만 반환하십시오.

아키텍처(Architecture)

요구사항이 충분하지만 기존 흐름이 없거나 관련이 없을 때 사용하십시오. 다음을 생성하십시오:

• 비즈니스 작업 모델 및 작업 키;
• 제어 흐름 계층 구조;
• 변수 및 구성 경계;
• 상태 머신 및 안정적인 오류 코드;
• 계층화된 재시도 및 정리 정책;
• 파일/아카이브 계약;
• 구현 순서 및 승인 매트릭스.

보이지 않는 노드의 위치나 정확한 필드를 절대 발명하지 마십시오. 완전한 대상 아키텍처는 E0에서 허용됩니다. 현재 편집기에 대한 주장은 허용되지 않습니다.

진단(Diagnosis)

사용자가 기존 흐름, 스크린샷 또는 실패 증거를 제공할 때 사용하십시오. 다음을 생성하십시오:

• 한 문장의 결과;
• 재구성된 현재 토폴로지;
• 확인된 사실 및 제한된 추론;
• 문제, 증거, 영향, 신뢰도 및 근본 원인;
• 건드리지 말아야 할 이미 완료된 경계;
• 최소 수정 큐;
• 정확한 배치가 여전히 알려지지 않은 경우 다음으로 가장 작은 증거 요청.

노드 이동을 권장하기 전에 중첩을 재구성하십시오. Continue, Exit Loop, Exit Flow, Close Page, 서브프로세스 호출 및 오류 처리기의 실제 범위를 확인하십시오.

단일 노드 안내(One-Node Guidance)

취약한 비주얼 편집기나 사용자가 스크린샷별 안내를 요청할 때 사용하십시오. 정확히 하나의 현재 노드 수정 카드를 제공하십시오:

위치:
작업: 추가 | 수정 | 이동 | 비활성화
노드 유형:
필요한 부모 및 이웃:
필드 값:
오류 처리:
이유:
예상 편집기 모양:
반환할 스크린샷:
롤백:

스크린샷이 반환된 후, 다음 카드를 제공하기 전에 들여쓰기, 부모/자식 범위, 순서, 값 모드, 변수 유형, 출력 이름 및 오류 처리를 확인하십시오. screenshot-node-guidance.md를 따르십시오.

승인(Acceptance)

로그, 상태 및 아티팩트를 함께 사용하십시오. 다음을 보고하십시오:

• 상태별 예상 및 실제 개수;
• RUN/SKIP/RETRY 타임라인 및 통과 횟수;
• 완료되지 않았거나 오래된 running 항목;
• 상태-아티팩트 불일치;
• 통과, 조건부 통과 또는 실패;
• 다음으로 가장 작은 수정 또는 검증 작업.

편집기만의 스크린샷은 런타임 성공을 절대 증명하지 않습니다. logging-and-acceptance.md를 사용하십시오.

핸드오프(Handoff)

전체 기록을 다시 말하지 않고 현재 사실을 기록하십시오:

• 목표 및 현재 실제 상태;
• 완료되고 보호된 경계;
• 순서대로 남은 작업;
• 키 파일 및 편집기 전용 구성 요소;
• 테스트 및 실제 실행 증거;
• 정확한 다음 노드 또는 명령;
• 금지 사항, 개인정보 규칙 및 해결되지 않은 결정.

신뢰성 불변 조건 적용

모든 설계와 진단을 다음 불변 조건에 대해 감사하십시오:

1. 시작된 모든 항목은 최종 상태 또는 명시적 재시도 가능 실패에 도달합니다. running을 무기한 유지하지 마십시오.
2. success는 다운로드된 아티팩트가 검증되고 최종 경로에 아카이브된 후에만 기록됩니다.
3. 모든 종료 경로는 페이지, 창, 프로세스, 잠금 및 임시 리소스를 닫거나 안전하게 포기합니다.
4. 건너뛰기는 단순히 유사하게 명명된 파일이 아닌 동일한 작업 키와 선언된 최종 상태를 기반으로 합니다.
5. 재시도는 제한되며 노드 재시도, 항목 재시도 및 배치 재생으로 분리됩니다. 최악의 시도 횟수를 계산하십시오.
6. 자격 증명 오류, 로그인 시간 초과, CAPTCHA/위험 제어, 페이지 변경, 데이터 없음, 다운로드 실패 및 아카이브 실패는 고유한 상태 또는 안정적인 오류 코드를 가집니다.
7. 비밀번호 또는 자격 증명 실패는 자동으로 무한 재시도가 되지 않습니다. 재시도 가능성을 변경하기 전에 정책을 확인하십시오.
8. 작업 계획 생성은 각 작업의 재시도 및 항목 루프 외부에 있습니다. 각 날짜 또는 비즈니스 작업은 독립적인 작업 키와 상태 범위를 소유합니다.
9. 비즈니스 종료 날짜와 UI 쿼리 종료 날짜는 대상 시스템이 오른쪽 열린 간격을 사용할 때 분리된 상태로 유지됩니다.
10. 기본 구성 또는 계획 오류는 폐쇄 실패합니다. 하나의 비즈니스 항목 실패는 정리되고 소유 루프로 반환됩니다.
11. 로그는 항목을 안전한 시퀀스 번호 또는 별칭으로 식별하며, 자격 증명이나 민감한 운영 데이터는 절대 식별하지 않습니다.
12. CAPTCHA 및 액세스 제어 처리는 공식 검증, 허용된 인간 개입, 제한된 재시도 또는 실패-계속만 사용합니다. 우회를 설계하지 마십시오.

기본 토폴로지는 다음과 같습니다:

entry
  -> task-plan generation
  -> task loop
     -> bounded batch-pass loop
        -> business-item loop
           -> should-run / idempotency decision
           -> mark running
           -> UI subprocess
           -> validate and archive artifact
           -> commit terminal or retryable state
           -> cleanup page/resources
  -> reconciliation and acceptance summary

상태, 재실행, 배치-패스 또는 날짜-작업 논리를 변경하기 전에 state-retry-idempotency.md를 읽으십시오. 로그인, CAPTCHA, 대기, 선택기, 다운로드 또는 페이지 정리를 변경하기 전에 ui-auth-downloads.md를 읽으십시오.

최소 상태 계약 사용

프로젝트는 이 테이블을 확장할 수 있지만, 편차를 명시적으로 밝혀야 합니다.

상태	최종	기본 재시도 가능	필요한 정리
success	예	아니오	페이지 닫기; 아티팩트 존재
no_data	예	아니오	페이지 닫기
running	아니오	시간 초과 후 예	복구 또는 교체; 영원히 유지 금지
captcha_failed	아니오	예, 제한됨	페이지 닫기
failed	오류 코드별 정책	오류 코드별 정책	페이지 닫기
credential_failed	정책 결정	확인될 때까지 아니오	페이지 닫기

credential_error, login_timeout, captcha_failed, element_not_found, download_timeout, archive_failed, state_write_failed와 같은 안정적인 코드를 사용하십시오. 사람 메시지를 기계 안정 코드와 분리하여 유지하십시오.

번들 감사자 사용

사본 또는 정리된 증거에 대해 스크립트를 실행하십시오. 명시적 출력 경로가 제공되지 않는 한 읽기 전용입니다.

• python scripts/parse_run_log.py <log> CSV, JSONL 또는 텍스트 로그를 정규화하고 항목 타임라인 및 열린 RUN 이벤트를 찾습니다.
• python scripts/audit_state.py <state.json> [--artifact-root DIR] 불법 상태, 오래된 running 항목 및 상태/아티팩트 불일치를 찾습니다.
• python scripts/validate_rpa_spec.py <spec.json> 정규화된 대상 설계를 제한된 재시도, 정리, 상태 종료, 아카이브 순서 및 보안 위반에 대해 정적으로 감사합니다.

스크립트 출력을 증거로 취급하되, 관련 흐름이나 비즈니스 계약을 검사하는 대체품으로 취급하지 마십시오.

플랫폼 세부 정보 경로 지정

ShadowBot/影刀의 경우, 노드 이름을 지정하거나 편집기 스크린샷을 해석하기 전에 shadowbot-adapter.md를 읽으십시오. 플랫폼 버전이 다릅니다. 기억에 의존하지 말고 노드의 일반 탭, 오류 처리 탭, 출력 변수 및 가시적 중첩을 확인하십시오.

다른 플랫폼의 경우, ShadowBot 레이블을 복사하는 대신 의미를 번역하십시오. 보편적인 질문은 다음과 같습니다: 루프를 소유한 것은 무엇인가, 변경되는 것은 무엇인가, 실패가 어떻게 종료되는가, 정리되는 것은 무엇인가, 어떤 증거가 성공을 확정하는가.

증거 기반 다음 단계로 마무리

다음 중 하나로 끝내십시오:

• 가정을 포함한 완전한 아키텍처;
• 하나의 검증된 진단과 가장 작은 안전한 수정;
• 하나의 노드 수정 카드와 다음에 필요한 스크린샷;
• 로그, 상태 및 아티팩트로 뒷받침되는 승인 판정;
• 다른 작업이 기록을 재구성하지 않고 계속할 수 있는 핸드오프.

다이어그램이 올바르게 보인다고 해서 완료라고 주장하지 마십시오. 요청된 설계 또는 변경 사항이 존재하고 그에 상응하는 검증이 통과된 경우에만 완료를 주장하십시오.