OpenClaw 릴리스 유지 관리자

OpenClaw 릴리스 유지 관리자은(는) 무엇을 하나요?

릴리스 운영에 사용하며, 일반적인 개발이나 조언용 변경에는 사용하지 마세요. 현재 정책은 docs/reference/RELEASING.md를 참조하세요. 보안 자격 증명 위치나 호스트 토폴로지를 확인하기 전에 $release-private을 로드하세요(가능한 경우). 자격 증명 작업에는 $one-password를 사용합니다.

역할 선택

• 릴리스 소유자(기본값): “이 릴리스 관리”는 준비부터 검증, 회고, 마무리까지 하나의 릴리스를 소유합니다. 짧은 프롬프트의 경우에도 소유자 라이프사이클로 시작하세요.
• 릴리스 관리자/오케스트레이터: 여러 릴리스 소유자를 조정하고, 킬오프 또는 인계 브리프를 작성하며, 핫픽스 기회를 라우팅합니다. 관리자 모드로 시작하세요. 이 역할은 소유자의 릴리스 브랜치나 게시 상태에 대해 두 번째 작성자가 되지 않습니다.

이 스킬은 일반적인 프로세스를 담당합니다. 초기 프롬프트에는 복사된 런북이 아닌 릴리스별 의도, 권한, 상태가 포함됩니다. 인계는 새 릴리스를 시작하는 대신 현재 증거를 바탕으로 해당 의도를 재개합니다.

작업 선택

선택한 단계에 필요한 참조만 읽으세요:

• 정규 베타/안정 준비 또는 게시: 정규 릴리스 - 준비 및 단계별 증거를 라우팅합니다. 요청에 stable/full이 명시되지 않은 경우 기본값은 beta이며, beta 권한은 추후 안정 프로모션을 승인하지 않습니다.
• 백포트 발견 및 포팅: 후보 인벤토리 및 작업자 브리프. 확장 안정(extended-stable)의 경우 백포트 준비도 읽으세요. SDK/설정 변경에는 눈에 띄는 유지 관리 위험 경고와 유지 관리자의 결정이 필요합니다.
• 확장 안정 .33+ 게이트웨이 게시: 확장 안정 게시. 확장 안정 입력과 함께 공유 게시자를 사용하세요. 최신(Latest)이 아닌 GitHub 릴리스는 네이티브 앱 또는 ClawHub 게시 없이 증거를 전달합니다.
• 검증 선택 또는 실패 증명: 검증 및 신뢰도 - 워크플로 실행 및 불변 매니페스트에는 $release-openclaw-ci를 사용합니다.
• 중단된 게시 또는 레지스트리 프로모션: 게시 복구.
• 네이티브 자산: 플랫폼 게시 - macOS 작업에는 $release-openclaw-mac을 사용합니다.
• 안정 게시 후 동기화 및 정확한 SHA 배포 인계: 메인 마무리.
• 릴리스 회고 및 공유 이슈 원장(모든 트랙 및 모든 인계 스냅샷): 회고.
• 릴리스 노트: $openclaw-changelog-update - 별도로 승인된 게시 후 문서 미러 경로를 포함합니다. 초기 릴리스 생성은 기존 형식을 유지합니다. 문서 게시는 릴리스 중에 자동으로 실행되지 않습니다. 요청된 공지: Discord용 $release-openclaw-announcement, X용 $release-tweets. 공지는 게시를 차단하지 않으며 명시적인 게시 승인이 필요합니다.
• 게시된 아티팩트 검증: $verify-release. GHSA 작업: 보안 워크플로 권한이 명시적으로 있는 경우에만 $openclaw-ghsa-maintainer를 사용합니다.

핫픽스 원장 관리

백포트 발견, 선택 및 결과( Tideclaw 소유 릴리스 포함)에는 공유 핫픽스 원장을 선호합니다. 후보를 재사용하고, 메인/형제 릴리스에서 발견 사항을 추가하며, 각 릴리스의 평가를 업데이트합니다. 접근이 불가능하면 로컬 증거를 유지하고 나중에 동기화합니다. 이는 권장되는 기록 관리이며, 또 다른 릴리스 게이트가 아닙니다.

공유 릴리스 경계

FRV(전체 릴리스 검증)는 고정된 P의 체크인된 릴리스 도구 정책 하에 성공으로 종료되어야 합니다. 테스트를 건너뛰거나 C/Q를 변경하지 않고 명백히 실패한 실시간 제공자 또는 Telegram 잎만 면제될 수 있습니다. 다른 모든 필수 레인(Windows 및 macOS 노드 및 기타 일반 CI 작업, 설치 스모크, 서바이버 레인, update-first-hop-compat*, pack/npm 적격성, 패키지 무결성, Linux/Windows/macOS 게이트웨이 검사(릴리스 검사의 Windows 패키지 설치/업그레이드 검사 포함)는 성공해야 합니다. 취소된 실행은 여전히 차단합니다. 첫 번째 실패를 보존하고 각각을 아래와 같이 분류한 후 복구하세요. 안정 게시에는 안정/full 증거, 소크(soak), 차단 성능이 필요합니다. 베타 프로필 증거는 안정 게시를 승인할 수 없습니다. 이러한 하드 게이트, 소크 또는 성능은 면제될 수 없습니다. Linux, Windows, macOS에서 모든 9가지 게이트웨이 설치/업그레이드 조합은 전체 그룹 적격성에 필요합니다. 신원, 출처, 완전한 증거, 기존 게시 승인을 보존하세요.

실패한 각 테스트는 명시적인 리더 결정(실제 릴리스 차단기 또는 플레이크)을 받아야 하며, 해당 증거(동일한 SHA가 다른 곳 또는 재실행에서 통과, 릴리스 델타와 관련 없음, 러너 또는 인프라 시그니처, 동일한 케이스가 플레이킹된 이력, 또는 회귀가 아닌 기존 제품 버그(예: 2026.9.6 “Assign to…” 버그))와 함께 인계에 기록되어야 합니다. 실제 차단기는 출하된 바이트 또는 동작의 회귀이거나 업데이트/설치/게시 결함입니다. 릴리스 브랜치에서 수정하세요. 플레이크는 동일한 릴리스 SHA에서 기본적으로 최대 두 번의 기록된 재실행으로 재실행하고, 증거와 함께 main에 병렬 수정 이슈 또는 PR을 제출하세요. 플레이크 때문에 재절단하지 마세요. 의도적인 도구 코드 면제는 게시자 재정의가 아닌 새로 고정된 P 하의 FRV 검증이 필요합니다. 면제되지 않은 플레이크가 계속 빨간색이면 게시를 차단합니다. 메인 전용 실패 및 인프라 실패(러너 중단, GitHub 고스트 작업, 호스티드 러너 오프로드)는 릴리스의 플레이크로 간주됩니다.

종속성 권고는 릴리스를 지연시키지 않습니다. 새로 게시된 권고는 재절단, 도구 변경 또는 검증 재실행의 이유가 되지 않습니다. 릴리스 증거와 인계에 기록한 후, 게시 후 일반 후속 작업으로 main에 종속성 범프를 제출하거나 대기열에 추가하세요. 알려진 맬웨어 발견만 게시를 중단합니다. 릴리스 종속성 증거와 릴리스에서 발송된 CI가 이를 강제합니다.

메인의 CI 상태는 릴리스를 차단하지 않습니다. 검증 및 게시는 릴리스 브랜치와 고정된 도구에서 실행되므로 빨간 main은 기다리거나 재절단하거나 일시 중지할 이유가 되지 않습니다. 릴리스에 main의 릴리스 도구 수정이 필요할 때(도구 SHA는 신뢰할 수 있는 main 커밋이어야 함), 수정이 발생시키지 않는 main 실패는 해당 랜딩을 보류해서는 안 됩니다. 깨끗한 main 체크아웃에서 해당 실패가 이미 존재함을 증명하고, PR 본문에 기록한 후 병합하세요. 활성 릴리스 중에는 정확히 그 상황에서 릴리스 도구 PR에 대해 관리자 병합이 허용됩니다. 빨간 main은 계속 수정되며, 별도 레인에서 병렬로, 릴리스의 중요 경로에서 절대 벗어나지 않습니다.

FRV 벽시계 루프를 따르세요: 원격 검증을 신속하게 시작하고, 진단이 소모됨에 따라 실패를 수리하며, 주기 간 다운타임을 최소화하세요. 다음 실행에 영향을 미치는 알려진 비플레이크 수정을 의식적으로 실패를 전달하지 않고 모두 포함하세요. 유용한 로컬 검사를 원격 검증과 중복하세요. 이는 일정을 안내할 뿐 새로운 게이트가 아닙니다.

운영 목표는 약 20분 이내에 검증을 완료하고 1시간 이내에 게시하는 것이지만, 측정된 보장은 아닙니다. 소스 전용 하위 항목은 아티팩트 생성자와 함께 시작합니다. 후보 소비자는 후보가 준비되는 즉시 시작합니다. 독립적으로 봉인된 녹색 하위 항목은 상위 항목이 실패했거나, 취소되었거나, 계속 활성 상태인 경우에도 동일한 정확한 대상 및 입력에 대해 재사용할 수 있습니다. 원래 인정된 적격성 신원(또는 역사적으로 신뢰할 수 있는 메인 워크플로 SHA)과 현재 시도를 확인하세요. 봉인된 매니페스트는 SDK 증거 다이제스트와 npm 게시 결정을 제공합니다. SDK API 변경을 인정하지 않으므로 SDK 보고서에 변경 사항이 있을 때마다 plugin_sdk_api_acknowledgement를 제공하세요. 게시자는 성공적인 FRV만 수락하며 면제를 부여할 수 없습니다. 명시적인 게시자 입력이 게시 범위를 선택합니다. 후보 도우미는 필요한 경우 명시적인 SDK 승인을 계속 검증합니다.

릴리스 관리 요청에는 소유자 라이프사이클의 권한 기본값을 사용하세요: 베타는 보류되지 않는 한 검증된 게시를 포함합니다. 안정 및 확장 안정에는 게시 승인이 필요합니다. 명시적인 준비 전용 요청은 게시를 승인하지 않습니다. 명명된 릴리스를 게시하거나 완료하라는 명시적 지시는 검증된 게시 및 검증을 통해 수행됩니다. 신원, 채널, 범위 또는 중요한 위험이 변경되지 않는 한 다시 묻지 마세요. 버전을 변경하기 전에 확인하고 기록하세요. 지정되지 않은 버전은 라이프사이클의 승인 규칙을 따릅니다. 일반 코드에 대한 출하 권한은 릴리스 권한이 아닙니다.

운영자가 명명된 릴리스를 준비하는 데 필요한 모든 작업을 수행하라는 명시적 승인은 필요한 준비 결정 및 수리에 대한 지속적인 권한입니다. 후보 및 도구 수정, 업그레이드/마이그레이션 설계, 검토된 테스트 또는 보안 인벤토리 정렬, 격리된 증명, 커밋, 푸시 및 검증 복구를 통해 이를 수행하세요. 결정, 증거 및 선택된 지원 계약을 기록하세요. 이미 승인된 작업 클래스가 구현 또는 검증 단계에 도달했다는 이유만으로 다시 묻지 마세요. 차단기를 해결하는 동안 독립적인 작업을 계속하세요. 이 권한은 결함 숨기기, 성공을 만들기 위한 게이트 낮추기, 운영자 상태에 대한 파괴적 변경, 관련 없는 작업 또는 게시를 허용하지 않습니다. 준비 전용 요청은 아티팩트 또는 브리지 버전을 릴리스하기 전에 여전히 별도의 게시 지시가 필요합니다.

인계 템플릿을 사용하여 하나의 간결한 상태 기록을 유지하세요: 유효 목표, 버전/태그/브랜치, 컷/코드/릴리스 SHA, C/Q/P ID, 활성 상위 실행 및 시도, 성공적인 하위 아티팩트, 승인된 변경 사항, 단계 및 다음 조치. 최신 운영자 지시는 대체된 범위를 무시합니다. 완료된 증거는 명명된 변경으로 무효화될 때까지 완전한 상태로 유지됩니다.

정규 릴리스의 경우 가능하면 코드 SHA를 고정하기 전에 완전한 노트를 준비하세요. 해당 노트가 최종인 경우 코드 SHA와 릴리스 SHA는 동일한 커밋입니다: 한 번의 성공적인 새로운 전체 적격성으로 두 역할과 정확한 게시 바이트를 모두 제공할 수 있습니다. 레이블을 분리하기 위해 다른 커밋을 만들거나 실행하지 마세요. 적격성 후에 노트가 변경되면, 전체 델타에 CHANGELOG/<version>.md(정확한 베타 버전 또는 안정 베이스)와 해당 항목, 일치하는 레코드 및 루트 인덱스만 포함하는 하위 항목은 split-changelog-release-v1을 사용하여 제품 증명을 재사용하면서 새 게시 바이트를 적격성 검증할 수 있습니다. 다른 소스 델타, 이름 변경 또는 삭제는 코드 SHA 루프로 돌아갑니다. 기록적인 루트 전용 영수증은 changelog-only-release-v1을 유지합니다. 새 테스트 적격성은 Q=C를 고정합니다: 후보의 테스트 워크플로 폐쇄는 후보에 속합니다. 독립적으로 신뢰할 수 있는 P(입장, 집계 결정, 검증자, 게시자)는 분리하여 유지하세요. Q 하네스 수리에는 새 C/Q 및 새로 바운드된 증거가 필요합니다. P 전용 또는 인프라 수리는 후보를 보존할 수 있습니다. 누락된 적격성 계약에는 의도적인 백포트가 필요하며, 절대 미래 메인 폴백이 아닙니다.

후보가 절단되면 그 베이스는 운영자의 결정입니다. Peter가 해당 릴리스에서 명시적으로 요청하지 않는 한 후보를 재절단(최신 main에 재베이스)하지 마세요. 묻지 않고, 이미 병합된 main 커밋을 릴리스 브랜치에 체리픽하는 것은 확인된 릴리스 차단기(고정된 후보에서 결정론적으로 실패하는 필수 레인, 또는 업데이트/설치/게시 바이트 결함)를 수정하는 경우에만 허용됩니다. 각 체리픽을 인계 기록에 이름을 지정하세요. 허용되지 않음: 기회주의적 백포트, 기능 되돌리기, 또는 작은 충돌 해결로 깔끔하게 체리픽되는 수정을 “가져오기” 위해 새 베이스를 사용하는 것. 명시적인 운영자 승인 추가는 소유자 접수 절차를 따릅니다: 변경된 범위를 기록하고 새 후보를 재적격성 검증하며, 무효화된 증명을 조용히 재사용하지 마세요. 관리자의 기회 알림은 해당 승인이 아닙니다.

릴리스 중에 이루어진 릴리스 프로세스 개선 사항은 두 브랜치에 모두 적용됩니다. 워크플로, 릴리스 스크립트, 릴리스 테스트, RELEASING.md 및 릴리스 스킬 변경 사항은 먼저 main에 병합된 후, 다음 후보 또는 패치를 위해 release/YYYY.M.PATCH에 체리픽(-x)됩니다. 이 릴리스에 필요한 적격성 수리는 새 C/Q를 고정하기 전에 적용되어야 합니다. 이미 적격성 검증된 후보에 대해 하네스를 조용히 교체하지 마세요. 브랜치에 main 전용 CI 인프라가 없는 경우, 브랜치의 표현 형식을 유지하고 로직만 포팅하세요. 릴리스 브랜치의 제품 코드는 위 규칙에 따라 차단기 전용으로 유지됩니다.

릴리스를 위해 열린 모든 수리 PR을 최종 보고서 전에 해결하세요. 아래 설명된 회고 PR은 필요한 종료 인도물이며, 해결되지 않은 수리가 아닙니다. 릴리스 중에 생성된 모든 PR을 나열하세요(gh pr list --author @me --state open 및 해당 릴리스에 바인딩된 모든 PR).