OpenClaw Parallels Smoke은(는) 무엇을 하나요?
이 기술은 Parallels 게스트 워크플로우 및 스모크 해석에 사용됩니다. 일반 저장소 작업에는 로드하지 마세요.
전역 규칙
- Parallels는 기본적으로 게시 후 신뢰도(postpublish-confidence) 커버리지이며, 제한된 베타-게시 단계의 전제 조건이 아닙니다. 정확히 하나의 게시된 패키지 버전에 대해 실행하고, 해당 패키지를 승인한 Validation SHA + Tooling SHA 실행 쌍을 기록하세요. Validation SHA는 Code SHA 또는 Release SHA에 매핑되며, 세 번째 릴리스 식별자가 아닙니다.
- 실패한 게시 후 Parallels 레인은 베타를 소급하여 게시 취소하지 않습니다. 이를 제품, 하네스/도구/출처, 인프라/자격 증명, 또는 래퍼 실패로 분류하세요. 확인된 제품 결함만 다음 베타에 진입합니다.
- 독립적인 게스트 제품군당 하나의 코디네이터와 하나의 레인을 사용하세요. 한 번 실패한 제품군을 진단하고 한 번 재시도한 후 재평가하고, 집계 매트릭스를 자동으로 재시작하지 마세요.
- 프로비저닝 전에 기존 VM 및 스냅샷을 인벤토리하세요. 미리 구성된 프리스틴 스냅샷이 요청된 기준과 일치하면 해당 스냅샷으로 전환하고 사용자, 도구 및 기본 설정을 재사용하세요. "새로운" 실행을 위해 새 VM을 생성하거나, macOS를 재설치하거나, 게스트 기준을 다시 구축하지 마세요.
- "새로운(Fresh)"은 가장 가까운 기존 프리스틴 스냅샷을 복원하는 것을 의미하며, 다른 스냅샷을 생성하는 것이 아닙니다. 사용자가 명시적으로 요청하거나 적합한 기준이 없는 경우가 아니라면 임시 스냅샷을 생성하지 마세요. 임시 실행 후에는 원래 스냅샷을 복원하고 게스트를 중지된 상태로 두세요.
- 복원하기 전에 스냅샷 상태를 검사하세요. 프리스틴
poweron스냅샷에는 미리 구성된 로그인 세션이 포함될 수 있습니다. Parallels가 해당 세션을 재개할 수 있도록 정상적으로 전환하세요. 실행이 의도적으로 저장된 세션을 폐기하고 로그인 창에서 부팅해야 하는 경우가 아니라면 테스트 진입 시--skip-resume을 전달하지 마세요.--skip-resume은 복원된 소스 게스트를 중지된 상태로 두어야 하는 최종 정리에 허용됩니다. - 스모크 실행에서 게이트웨이 확인은
openclaw gateway status --deep --require-rpc를 사용하세요. 단, 확인 중인 안정 버전이 아직 지원하지 않는 경우는 예외입니다. - 안정
2026.3.12업그레이드 전 진단은 일반gateway status --deep폴백이 필요할 수 있습니다. - 해당 안정 업그레이드 전 레인에서
precheck=latest-ref-fail을 기준으로 처리하고, 자동으로 회귀로 간주하지 마세요. - 기계 판독 가능한 요약을 위해
--json을 전달하세요. - 단계별 로그는 기본적으로
.artifacts/parallels/openclaw-parallels-*아래에 저장됩니다. 실행에 다른 아티팩트 볼륨이 필요한 경우OPENCLAW_PARALLELS_ARTIFACT_ROOT로 재정의하세요. - 동일한 새 작업 공간 또는 세션에서 로컬 및 게이트웨이 에이전트 턴을 병렬로 실행하지 마세요.
- 모든 최상위 Parallels 레인은 중단된 설치, 스냅샷 전환 또는
prlctl exec전송으로 인해 테스트 기간이 소모되지 않도록 호스트timeout --foreground(또는 사용 가능한 바이너리인 경우gtimeout --foreground)로 하드 캡하세요. 기본값:- macOS:
75m - Linux:
75m - Windows:
90m - 집계 npm-update 래퍼:
150m레인이 캡에 도달하면 중지하고, 가장 최근의/tmp/openclaw-parallels-*실행 디렉토리 및 단계 로그를 검사한 다음, 영향을 받는 가장 작은 레인을 수정하거나 재실행하세요. 캡된 레인을 계속 기다리지 마세요.
- macOS:
- 실제 OpenClaw npm 설치/업데이트 단계는 전체 레인 캡보다 더 엄격한 신호입니다. 설치 단계는 일반적으로 7분 이내에 완료되어야 하며, 업데이트 단계는 일반적으로 5분 이내에 의미 있는 진행 상황을 보여야 합니다.
install-main,install-latest,install-baseline또는install-baseline-package라는 이름의 단계가 420초를 초과하거나,update-dev/ 동일 게스트openclaw update라는 이름의 단계가 300초를 초과하고 새 표시가 없으면, 해당 단계 로그와 게스트 프로세스 상태부터 진단을 시작하세요. 현재 Windows 업데이트 단계는doctor --fix가 번들 플러그인 런타임 종속성을 설치할 수 있기 때문에 약 10-15분 후에도 통과할 수 있습니다. 로그가 진정으로 오래된 것이 아니라면 스크립트 하드 캡을 20분 근처로 유지하세요. - 전체 OS 매트릭스의 경우, 호스트 용량이 허용할 때 독립적인 게스트 제품군 레인을 병렬로 실행하는 것을 선호하세요:
timeout --foreground 75m pnpm test:parallels:macos -- --jsontimeout --foreground 90m pnpm test:parallels:windows -- --jsontimeout --foreground 75m pnpm test:parallels:linux -- --json각 레인을 자체 셸/세션에 유지하고 각각의 실행 디렉토리를 추적하세요. 매트릭스를 시작하기 전에 필요한 호스트 빌드/패키지 게이트를 완료하세요. 현재-main tgz 패키징이 필요할 때, 스모크 스크립트는pnpm build, 인벤토리/스테이징 및npm pack을 통해 공유 패키지 잠금을 유지합니다. 해당 잠금이 없거나 손상된 경우, 동시dist변경을 수용하는 대신 매트릭스를 직렬화하세요.
- 동일한 게스트 제품군에 대해 여러 스모크 레인을 한 번에 실행하지 마세요. Tahoe 레인은 호스트 HTTP 포트를 공유하고, Windows/Linux 레인은 두 작업이 동시에 동일한 VM을 건드리는 경우 스냅샷 복원/시작 상태에서 충돌할 수 있습니다.
- 개별 macOS/Windows/Linux 스모크 레인과 병렬로 집계
pnpm test:parallels:npm-update래퍼를 실행하지 마세요. 이는 동일한 게스트 제품군 및 스냅샷을 건드립니다. - 관련 없는 호스트 명령이
dist를 재빌드, 정리 또는 재스테이징할 수 있는 동안 Parallels 레인을 시작하지 마세요(pnpm build,pnpm ui:build,pnpm release:check,pnpm test:install:smoke, npm pack/install 스모크 또는 패키지/빌드 준비를 실행하는 Docker 레인). 관련 없는 빌드/패키지 게이트를 먼저 실행하고, 완료될 때까지 기다린 다음 VM 매트릭스를 시작하세요. 동시dist변경은 호스트npm pack이 누락된 파일로 실패하게 만들어 전체 VM 사이클을 낭비할 수 있습니다. - 매트릭스를 실행하거나 최적화하는 동안,
/tmp/openclaw-parallels-*로그에서 레인당 벽시계 시간과 가장 느린 단계를 기록하세요. 스모크 순서, 타임아웃 또는 헬퍼 동작을 변경하기 전에 해당 타이밍을 사용하세요. - 호스트 빌드가 추적된 생성 파일을 변경하는 경우, VM 시간을 소비하기 전에 중지하세요. 생성된 아티팩트를 별도로 커밋하거나 생성기 드리프트를 수정한 다음, 영향을 받는 가장 작은 레인을 재실행하세요.
main이 활성 다중 에이전트 작업 하에 이동 중인 경우, 긴 Parallels 스위트를 위해 하나의 커밋에 고정된 분리된 작업 트리를 선호하세요. 스모크 스크립트는 이제 라이브git rev-parse HEAD대신 패킹된 tgz 커밋을 확인하지만, 고정된 작업 트리는 재실행 중 시끄러운 재빌드/버전 드리프트를 피합니다.openclaw update --channel dev레인의 경우, 게스트가 로컬 작업 트리가 아닌 GitHubmain을 복제한다는 점을 기억하세요. 로컬 수정 사항이 있지만 재실행이 여전히 복제된 dev 체크아웃 내에서 실패하는 경우, 브랜치가 푸시될 때까지 이를 수정 사항의 반증으로 취급하지 마세요.prlctl exec의 경우, VM 이름을--current-user앞에 전달하세요(prlctl exec "$VM" --current-user ...). 반대 순서가 아닙니다.- 워크플로우가 사이트 설치 프로그램/npm 릴리스 대신 저장소 체크아웃에서 OpenClaw를 설치하는 경우, 실제 게스트 CLI 심을 설치하고 새 게스트 셸에서 확인하여 완료하세요. 저장소 내의
pnpm openclaw ...는 핸드오프 패리티에 충분하지 않습니다. - macOS 게스트의 경우, 사용자 전역 설치와 안정적인 PATH-가시 심을 선호하세요:
NPM_CONFIG_PREFIX="$HOME/.npm-global" npm install -g .로 설치~/.local/bin/openclaw가 존재하거나~/.npm-global/bin이 PATH에 있는지 확인- 완전히 새로운 게스트 셸에서
which openclaw및openclaw --version으로 확인
npm install 후 update
- 선호 진입점:
pnpm test:parallels:npm-update - macOS 전용 게시 릴리스 업데이트 확인의 경우, 다음을 사용하세요:
timeout --foreground 75m pnpm test:parallels:npm-update -- --platform macos --package-spec openclaw@<old-version> --update-target <target-version-or-tag> --json이는 동일 게스트openclaw update --tag ...커버리지를 유지하고, Windows/Linux 레인을 시작하지 않고 공유 macOS current-user/sudo 폴백을 사용합니다.
- 필수 커버리지: 모든 릴리스/업데이트 회귀 실행은 다음 두 레인을 모두 포함해야 합니다:
- 새 스냅샷 -> 요청된 패키지/기준 설치 -> 스모크
- 동일 게스트 기준 -> 게스트의 설치된
openclaw update ...명령어 실행 -> 다시 스모크
- 업데이트 레인은 OpenClaw의 내부 업데이터를 실행해야 합니다. 직접
npm install -g <tgz-or-spec>또는 하네스 측 패키지 교체를 업데이트 흐름 커버리지로 계산하지 마세요. 이는 설치 스모크일 뿐입니다. - 게시된 대상의 경우, 먼저 이전 기준 패키지(예:
[email protected])를 설치한 다음, 설치된 게스트 CLI를 의도된 채널/태그(예:openclaw update --channel beta --yes --json)로 실행하고, 명령어 후에openclaw --version,openclaw update status --json, 게이트웨이 RPC 및 에이전트 턴을 확인하세요. - 게시되지 않은 대상의 경우, 호스트에서 후보를 패킹하고, 하네스 HTTP 서버를 통해
.tgz를 제공하며, 게스트 업데이터가 해당 제공 패키지를 가리키도록 하세요.openclaw update --tag http://<host-ip>:<port>/openclaw-<version>.tgz --yes --json을 선호하세요. 채널 지속성도 중요한 경우,--channel <stable|beta>를 전달하고 게스트 업데이트 환경에서OPENCLAW_UPDATE_PACKAGE_SPEC을 동일한 제공 URL로 설정하세요. 테스트 중인 명령어는 여전히openclaw update여야 하며, 직접 npm이 아닙니다. - 게시되지 않은 로컬 수정 사항 검증의 경우, 이전 기준 업데이터 코드가 여전히 첫 번째 홉을 제어한다는 점을 기억하세요. 새 업데이터 코드에만 있는 수정 사항은 이미 실행 중인 이전 프로세스를 변경할 수 없습니다. 제공된 후보는 패키지/플러그인 메타데이터를 기준 호스트와 호환 가능하게 유지하거나, 기준 자체에 업데이터 수정 사항이 포함되어야 합니다.
- 베타/안정 확인의 경우, 실행 직전에 태그를 확인하세요(
npm view openclaw@beta version dist.tarball또는npm view openclaw@latest ...). 긴 VM 매트릭스가 이미 실행 중인 동안 태그가 이동할 수 있습니다. 의도된 사전 릴리스가 이전 레지스트리 404/태그-지연 검사 후에 나타나면 매트릭스를 재시작하세요. - 구성된 비밀 워크플로우를 사용하여 OpenAI/Anthropic 레인에 필요한 공급자 키만 주입하세요. 비밀 또는 환경 덤프를 인쇄하지 마세요. 게스트 실행 환경을 통해 공급자 비밀을 전달하세요.
- 동일 게스트 업데이트 확인은 에이전트 턴 전에 기본 모델을 명시적으로
openai/gpt-5.4로 설정하고, 새--session-id를 사용하여 이전 세션 모델 상태가 확인에 누출되지 않도록 하세요. - 집계 npm-update 래퍼는 신규 및 업데이트 레인 전에
parallels-linux-smoke.sh와 동일한 Ubuntu 폴백 정책으로 Linux VM을 확인해야 합니다. 정확한 기본 VM이 없는 경우 메이저 버전>= 24인 모든 Ubuntu 게스트를 허용하고, 새 poweroff 스냅샷이 있는 최신 버전의 Ubuntu 게스트를 선호하세요. Peter의 현재 호스트에서는Ubuntu 26.04를 사용하세요. - macOS 동일 게스트 업데이트 확인에서, npm 업그레이드 후
gateway status/agent전에 게이트웨이를 재시작하세요. 그렇지 않으면 launchd가 이전 프로세스가 종료되고 새 프로세스가 아직 RPC 준비되지 않은 상태에서 로드된 서비스를 보고할 수 있습니다. - npm-update 집계의 macOS 업데이트 레그는 게스트 업데이트 스크립트를 root로 작성한 다음 데스크톱 사용자로 실행합니다.
prlctl exec "$MACOS_VM" --current-user ...가 인증할 수 없는 경우, 일반 rootprlctl exec및sudo -u <desktop-user> /usr/bin/env HOME=/Users/<desktop-user> USER=<desktop-user> LOGNAME=<desktop-user> PATH=/opt/homebrew/bin:/opt/homebrew/opt/node/bin:/usr/bin:/bin:/usr/sbin:/sbin ...을 통해 재시도하세요. 이는 Parallels 전송 폴백입니다. 업데이트 후에도openclaw --version, 게이트웨이 RPC 및 에이전트 턴을 확인하세요. - Windows 동일 게스트 업데이트 확인에서, npm 업그레이드 후
gateway status/agent전에 게이트웨이를 재시작하세요. 그렇지 않으면 제자리 전역 npm 업데이트가 실행 중인 서비스에 오래된 해시된dist/*모듈 가져오기를 남길 수 있습니다. - 해당 Windows 동일 게스트 업데이트 확인에서, 하나의 0이 아닌
openclaw gateway restart를 결정적 실패로 취급하지 마세요. 현재 로그인 항목 재시작은 백그라운드 서비스가 다시 관찰 가능해지기 전에 실패를 보고할 수 있습니다. 더 긴 RPC 준비 대기를 수행하고, 준비 상태가 여전히 반환되지 않는 경우에만 복구 단계로gateway start를 사용하세요. - 해당 Windows 재시작 후, 고정된 수면 후 하나의
gateway status --deep --require-rpc호출을 신뢰하지 마세요. 약 30초 동안 RPC 준비 프로브를 재시도하고 각 시도를 기록하세요. 현재 게스트는 새 RPC 엔드포인트가 아직 올라오는 동안 포트18789를 바인딩된 상태로 유지할 수 있습니다. - Windows 동일 게스트 업데이트 확인에서, 하나의 장기 실행
prlctl exec ... powershell -EncodedCommand ...전송보다 done-file/로그 드레인 PowerShell 러너 패턴을 선호하세요. 게스트가 성공적으로 완료될 수 있지만 외부prlctl exec는 여전히 중단될 수 있습니다. - Windows 동일 게스트 업데이트 헬퍼는 tgz 다운로드 및
npm install -g와 같은 긴 단계 전에 로그에 단계 마커를 작성해야 외부 진행 모니터가 정상적이지만 조용한 설치 중에waiting for first log line에 머무르지 않습니다. - Linux 동일 게스트 업데이트 확인은 또한
HOME=/root를 내보내고,prlctl exec ... /usr/bin/env를 통해OPENAI_API_KEY를 전달하며,openclaw agent --local을 사용해야 합니다. 신선한 Linux 기준은 지속된 게이트웨이 자격 증명에 의존하지 않습니다. - npm-update 래퍼는 이제 중첩 로그 파일에서 레인별 진행 상황을 인쇄합니다. 레인이 여전히 멈춘 것처럼 보이면, 외부 래퍼가 중단되었다고 가정하는 대신
runDir의 중첩 로그(macos-fresh.log,windows-fresh.log,linux-fresh.log,macos-update.log,windows-update.log,linux-update.log)를 먼저 검사하세요. - 각 실행은
summary.json과summary.md를 모두 작성합니다. 빠른 인간 트라이지를 위해 먼저 마크다운을 읽은 다음, 자동화를 위해 JSON/타이밍을 읽으세요. - 태그가 게시된 후 전체 베타 검증의 경우, 하나의 명령어를 선호하세요:
timeout --foreground 150m pnpm test:parallels:npm-update -- --beta-validation beta3 --json이는beta3를 최신*-beta.3버전으로 확인하고, 최신->해당 버전 동일 게스트 업데이트 커버리지를 실행한 다음, 동일한 선택된 OS 매트릭스에서 해당 정확한 게시 대상에 대한 새 설치 스모크를 실행합니다.--platform macos|windows|linux를 사용하여 재실행을 좁히세요.
- 에이전트 턴이 있는 베타 4 npm 검증의 경우, 알려진 양호한 형태는 다음과 같습니다:
gtimeout --foreground 150m pnpm test:parallels:npm-update -- --beta-validation beta4 --model openai/gpt-5.4 --json특정 사전 릴리스 번호를 검증할 때openclaw@beta보다 명시적beta4별칭을 선호하세요. npm 태그는 이동할 수 있습니다.
- 래퍼가 레인을 실패하면, 먼저 자동 덤프된 꼬리를 읽은 다음 전체 중첩 로그를 읽으세요.