verify-release (릴리스 검증)

릴리스 검증 (Verify Release)

OpenClaw 릴리스가 완전히 게시, 발행, 프로모션, 스모크 테스트 또는 라이브 검증되었는지 묻는 경우 사용하세요. 이는 게시 스킬이 아닌 검증 스킬입니다. 릴리스 상태를 변경하기 전에 $release-openclaw-maintainer를 사용하세요.

규칙 (Rules)

• .27과 같은 짧은 접미사를 현재 날짜/컨텍스트의 구체적인 CalVer 버전으로 변환한 후, 확인된 버전을 말합니다.
• 먼저 트랙을 식별합니다. 두 트랙 모두 공유 GitHub 릴리스 증명 원장을 사용합니다. 일반 베타/안정은 플랫폼 그래프도 사용합니다. 확장 안정은 해당 정식 브랜치, npm 선택기, 게이트웨이 표면을 사용합니다. 한 트랙의 네이티브 또는 ClawHub 아티팩트를 다른 트랙에 요구하지 마세요.
• 라이브 상태를 확인하세요. 로컬 체크아웃 상태, 릴리스 노트 또는 오래된 기억을 현재 진실로 신뢰하지 마세요.
• 체크아웃이 더티(dirty)하거나 분기된 경우, 스크립트/참조용으로만 사용하세요. 버전 메타데이터의 경우 GitHub 릴리스/태그에서 가져오거나 /tmp 아래에 태그 tarball을 풀어 사용하세요.
• 비밀(secrets)을 출력하지 마세요.
• 최종 응답을 간결하게 유지하세요: yes/no, 증거 목록, 주의 사항, 정리.

일반 베타/안정 검사 (Regular beta/stable checks)

이 검사는 일반 오케스트레이션 릴리스 트랙에만 사용합니다.

1. GitHub 릴리스:
   • gh release view v<VERSION> --repo openclaw/openclaw --json tagName,name,publishedAt,isDraft,isPrerelease,targetCommitish,url,body,assets
   • 안정 릴리스가 초안(draft)이나 프리릴리스(prerelease)가 아닌지 확인합니다.
   • 릴리스 본문에 예상되는 npm, CI, 플러그인 npm, ClawHub, mac/appcast 증명 링크가 포함되어 있는지 확인합니다.
   • 안정 맥 릴리스에 예상되는 자산(asssets)이 업로드되었는지 확인합니다: zip, dmg, dSYM, 의존성 증명, 불변 전체 검증 매니페스트, 게시 후 증명, 안정 메인 마무리 매니페스트.
   • 각 불변 증명 자산과 .sha256 동반 파일을 다운로드한 후, 체크섬을 확인하여 릴리스 기록을 신뢰하기 전에 검증합니다.
2. 루트 npm:
   • npm view openclaw@<VERSION> version dist-tags.latest dist.tarball dist.integrity time.<VERSION> --json
   • 안정의 경우 latest가 <VERSION>과 같아야 합니다.
   • tarball, integrity, 게시 시간을 기록합니다.
   • 릴리스 게시 후 증명이 npmRegistrySignaturesVerified: true 및 npmProvenanceAttestationMatched: true를 기록하는지 확인합니다.
3. 플러그인 게시 세트:
   • GitHub에서 정확한 태그 메타데이터를 가져옵니다(로컬 체크아웃이 더티인 경우 로컬 체크아웃 사용 안 함): https://api.github.com/repos/openclaw/openclaw/tarball/v<VERSION>를 /tmp/openclaw-v<VERSION>-src로 다운로드합니다.
   • 기록된 릴리스 도구 SHA의 표준 게시 계획자/수집기를 사용하여, 정확한 태그의 패키지 메타데이터로 해당 릴리스 트랙에 대한 전체 예상 npm 및 ClawHub 패키지 세트를 도출합니다. 원시 게시 플래그를 그대로 계산하지 마세요: openclaw.build.bundledDist === true는 게시 플래그가 설정되어 있어도 외부 게시를 명시적으로 연기합니다. 연기된 패키지 이름과 이유를 별도로 기록합니다.
   • 예상 패키지 아이덴티티, 버전 및 개수를 원본 게시, 이전에 게시된 버전, 선택된 복구 실행 전체에 걸쳐 불변 게시 계획, 레지스트리 읽기, 워크플로 잡을 사용하여 조정합니다. 선택된 복구 하위 집합은 전체 예상 릴리스 세트를 좁혀서는 안 됩니다: gh api repos/openclaw/openclaw/actions/runs/<RUN>/jobs --paginate.
   • 각 예상 npm 플러그인에 대해, 해당 불변 게시 계획의 계획된 버전과 npm 선택기를 확인합니다. 일반 베타는 beta에 게시합니다. latest를 이동하도록 요구하지 마세요. 계획된 미러 태그는 별도로 확인합니다.
4. ClawHub:
   • 플러그인 ClawHub 릴리스 워크플로 결론과 게시 잡 수를 확인합니다.
   • 라이브 레지스트리 증명을 위해 OpenClaw 자체를 사용합니다: openclaw plugins search <known-plugin> --json.
   • 격리된 HOME에서 ClawHub의 정확한 요청 릴리스 버전에서 공식 플러그인 하나를 설치합니다: openclaw plugins install clawhub:@openclaw/matrix@<VERSION>. 해당 플러그인이 예상 세트에 없는 경우 matrix 대신 다른 플러그인을 선호합니다. ClawHub 버전은 spec에 속합니다. --pin은 npm 설치에만 지원됩니다.
5. 릴리스 워크플로:
   • 릴리스 노트 증명 링크에 대한 결론을 확인합니다: 전체 릴리스 검증, OpenClaw 릴리스 검사, OpenClaw NPM 릴리스, 플러그인 NPM 릴리스, 플러그인 ClawHub 릴리스, 안정 맥 자산이 예상되는 경우 mac preflight/validation/publish.
   • 안정의 경우 OpenClaw Stable Main Closeout이 성공했으며 해당 매니페스트가 일치하는 릴리스 태그, 현재 롤백 드릴, 안정 소크(soak) 및 차단 성능 증거를 기록하는지 확인합니다.
   • 관련 있는 성공/실패한 작업만 요약합니다. 루틴하게 건너뛴 선택적 레인은 릴리스 본문에서 약속하지 않은 한 무시합니다.

확장 안정 검사 (Extended-stable checks)

확장 안정은 공유 릴리스 증명이 포함된 GitHub 릴리스를 가지지만 네이티브 또는 ClawHub 아티팩트는 없습니다. 라이브 태그, 워크플로, 레지스트리, 출처 및 이미지 상태와 함께 검증합니다.

1. 아이덴티티: 접미사가 없는 extended-stable/YYYY.M.33에 포함된, 패치 33+의 최종 v<VERSION>을 요구합니다. 활성 후보만 팁(tip)과 같아야 합니다. 루트와 모든 게시 가능한 공식 플러그인은 <VERSION>을 선언해야 합니다. Git 태그와 제목 및 정식 본문이 태그와 일치하는 공개적이고 프리릴리스가 아닌 GitHub 릴리스를 요구합니다. isLatest=false, 의존성 증명, 불변 전체 릴리스 검증 매니페스트, 게시 후 증명 및 해당 체크섬을 요구합니다. 네이티브 또는 ClawHub 자산을 요구하지 않습니다.
2. 워크플로 체인: 성공한 상위 릴리스 실행과 해당 preflight, 완전 검증, 플러그인 npm 및 핵심 게시 하위 실행을 찾습니다. 보호된 release-publish/* 상위와 검증된 워크플로 SHA 출처가 있는 정식 release-ci/* 검증 프로듀서를 요구합니다. 검증은 rerun_group=all, release_profile=stable, 차단 소크/성능 및 저장된 시도를 사용해야 합니다. 핵심 게시는 세 개의 실행 ID를 모두 참조하고 해당 매니페스트, 워크플로 ref 및 tarball 다이제스트를 릴리스 SHA에 바인딩해야 합니다.
3. 레지스트리: 정확한 선택기와 extended-stable 선택기가 루트, 모든 preflight corePackageTarballs 항목, 태그에서 파생된 publishToNpm === true인 모든 공식 플러그인에 대해 <VERSION>을 반환해야 합니다. 플러그인 계획, 작업 및 전체 읽기 결과를 비교합니다. diffs에서 인벤토리를 유추하지 마세요.
4. 출처: 신뢰할 수 있는 현재 도구에서 node --import tsx scripts/openclaw-npm-postpublish-verify.ts <VERSION>을 실행합니다. 서명, 정식 브랜치 출처 및 게시/preflight 다이제스트가 릴리스 SHA에 바인딩되어야 합니다. 출력 및 워크플로 URL을 보존합니다.
5. Docker: 두 레지스트리에서 정확한 기본, 슬림, 브라우저 및 아키텍처 이미지와 증명을 확인합니다. 세 개의 extended-stable* 별칭만 해당 다이제스트로 확인되어야 합니다. 성공한 OpenClaw Release Publish 상위 실행과 완료된 Docker 검증을 요구합니다. 일반 경로는 그 후에 최종화됩니다. 명시적으로 요청된 빠른 경로는 GitHub를 먼저 활성화할 수 있습니다. 재빌드 없이 정확한 태그에 대한 현재 메인 Docker Channel Promotion을 통해 별칭을 복구합니다.
6. 복구: 절대 다시 게시하지 마세요. 루트 선택기(접미사 없는 최종 패치 33+)에 대해 openclaw/releases dist-tag 워크플로의 promote_extended_stable을 사용하고 승인된 자격 증명 격리 도구를 다른 항목에 사용합니다. 그런 다음 전체 읽기 결과를 반복합니다. ClawHub, 네이티브/모바일 앱, 웹사이트, 개인 dist-tag 또는 일반 latest를 요구하지 마세요. 공유 릴리스 증명은 요구하지만 일반 네이티브 또는 ClawHub 자산은 요구하지 않습니다.

게시된 패키지 스모크 (Published package smoke)

트랙별 게시 검사 후, 격리된 OpenClaw 상태로 일회용 설치/캐시를 사용합니다:

• npm exec --yes --package openclaw@<VERSION> -- openclaw --version.
• 게시된 CLI 표면에 영향을 주는 무해한 명령을 하나 이상 실행합니다. 예: plugins --help 또는 gateway --help.

사전 릴리스 검사로 추가 로컬 게이트웨이를 시작하거나 임시 라이브 모델 턴을 실행하지 마세요. 위의 표준 릴리스 검증 워크플로 및 게시 증명을 사용하세요. 이것은 필요한 레인을 제거하지 않습니다. 추가 수동 라이브 검사는 명시적으로 요청된 경우에만 실행하세요.

보고할 주의 사항 (Caveats to Report)

• Dist-tag 주의 사항: 안정 latest가 릴리스 진실입니다. 선택적 beta 미러가 여전히 베타 버전을 가리키는 경우, 사용자가 베타 프로모션을 확인하도록 요청하지 않는 한 안정 릴리스 차단 항목이 아닌 주의 사항으로 보고하세요.
• 트랙 주의 사항: 트랙 이름과 의도적으로 부재한 표면을 명시하세요. 누락된 일반 릴리스 아티팩트를 확장 안정 실패라고 부르지 마세요.
• 체크아웃 분기 주의 사항: 로컬 소스 SHA가 릴리스 태그나 원본과 다른 경우와 대신 사용된 라이브 소스를 명시하세요.