claw-score

claw-score은(는) 무엇을 하나요?

이 레포지토리에서 OpenClaw 성숙도 스코어카드를 작업할 때 이 스킬을 사용하세요. 이것은 유지보수자 claw-score 워크플로우의 openclaw-로컬 버전입니다: 분류 체계와 스코어카드 개념은 유지하지만, discrawl과 이전에 커밋된 inventory/ 보고서 트리는 제외합니다.

권한

이 스킬은 다음에 대한 운영 워크플로우를 소유합니다:

• taxonomy.yaml
• qa/maturity-scores.yaml
• docs/concepts/qa-e2e-automation.md
• qa/scenarios/index.yaml

개인별 정보, 유지보수자 전용 데이터, Discord 아카이브, discrawl 팩트를 이 레포지토리에 포함하지 마세요. 점수에 비공개 증거가 필요한 경우, OpenClaw QA 워크플로우에서 생성된 수정된 qa-evidence.json 아티팩트 형태를 사용하세요.

소스 모델

• taxonomy.yaml은 표면, 수준, QA 프로필, 범주, 기능 커버리지 ID, 문서 참조, LTS 재정의, 완전성 지시 경로에 대한 수동 편집된 진실 공급원입니다.
• 각 기능에는 정확히 하나의 coverageIds 항목이 있습니다. 증거 ID를 기능에 고유하게 유지하세요; 더 광범위한 다대다 증거 매핑은 현재 분류 체계 스키마의 일부가 아닙니다.
• 커버리지 ID는 소문자 영숫자/대시 세그먼트를 사용하여 점으로 구분된 namespace.behavior 형식을 사용합니다. 프로필, 표면 및 범주 ID는 대시 또는 점으로 구분된 상태로 유지될 수 있습니다.
• 범주와 기능 이름을 고유하고, 제품 형태를 가지며, 원시 커버리지 ID보다 더 광범위하게 유지하세요. 일반 ID를 독립형 기능 이름으로 승격시키지 마세요.
• 하나의 범주에서 다른 기능 이름 아래에 중복된 커버리지 ID 번들을 피하세요.
• qa/maturity-scores.yaml은 품질, 완전성 및 LTS 검토 상태에 대한 커밋된 집계 소스입니다.
• extensions/qa-lab/src/scorecard-taxonomy.ts는 readValidatedQaMaturityScoreSources를 내보냅니다; 이를 사용하여 점수 출력을 검증하세요.
• 생성된 공개 문서는 docs/maturity/scorecard.md와 docs/maturity/taxonomy.md입니다; 둘 다 pnpm maturity:render에서 비롯됩니다. 점수 결과를 변경하기 위해 생성된 Markdown을 수동으로 편집하지 마세요.
• qa-evidence.json 아티팩트는 실행별 QA 스코어카드 증거를 제공합니다. 릴리스 프로필 아티팩트는 커버리지에 대한 진실 공급원입니다. 생성된 아티팩트 문서를 풍부하게 할 수 있지만, 인벤토리로 커밋되지는 않습니다.

명령어

openclaw 레포지토리 루트에서 실행하세요.

소스 편집 후 분류 체계 YAML 구조와 성숙도 점수 스키마를 검증하세요:

node --import tsx --input-type=module <<'NODE'
import fs from "node:fs";
import YAML from "yaml";
import { readValidatedQaMaturityScoreSources } from "./extensions/qa-lab/src/scorecard-taxonomy.ts";

for (const file of ["taxonomy.yaml", "qa/scenarios/index.yaml"]) {
  YAML.parse(fs.readFileSync(file, "utf8"));
}
readValidatedQaMaturityScoreSources();
NODE

문서 산문을 건드릴 때 문서를 확인하세요:

pnpm check:docs

커버리지 ID나 프로필 멤버십을 변경할 때 집중 QA/프로필 검사를 실행하세요:

pnpm openclaw qa coverage --json

전체 생성 실행

생성된 문서 풀 리퀘스트를 게시하는 직접적인 전체 스코어카드 실행의 경우, 기본적으로 부동 main 해석을 사용하세요:

gh workflow run maturity-scorecard.yml \
  --repo openclaw/openclaw \
  --ref main \
  -f ref=main \
  -f expected_sha='' \
  -f publish_pull_request=true \
  -f allow_failures=true

일반적인 수동 생성 실행을 위해 main을 로컬에서 해석하고 해당 커밋을 ref와 expected_sha로 모두 전달하지 마세요. OpenClaw의 main은 빠르게 이동하므로, 호출자가 선택한 커밋은 검증 전에 오래될 수 있습니다. 그러면 워크플로우는 풀 리퀘스트 베이스에 더 새로운 성숙도 입력이 포함될 때 게시를 올바르게 거부하며 QA는 시작되지 않습니다.

ref=main과 빈 expected_sha를 사용하면 워크플로우의 floating_default_branch 경로가 다운스트림 작업에 불변 개정을 전달하기 전에 검증 내에서 현재 원격 기본 브랜치를 가져와 고정시킵니다. 요청된 증거가 해당 정확한 개정에 바인딩되어야 하는 경우에만 명시적 SHA를 사용하세요(예: 릴리스 후보 워크플로우 호출 또는 아티팩트 전용 기록 재현). 해당 정확한 개정 실행이 게시를 요청하고 main이 관련 입력을 변경한 경우, 검증 실패를 예상하고 부동 main에서 다시 디스패치하세요.

점수 매기기 워크플로우

표면을 점수 매기거나 새로고침하라는 요청을 받으면:

1. taxonomy.yaml에서 표면을 읽습니다.
2. .agents/skills/claw-score/references/completeness/ 아래에서 표면 완전성 루브릭을 읽습니다.
3. 공개 저장소 증거를 문서, 소스, 테스트 및 QA 시나리오 메타데이터에서 수집합니다.
4. 실행된 증거에 대해 기존 릴리스 프로필 qa-evidence.json 아티팩트를 선호합니다.
5. 공개 또는 수정된 아티팩트 증거로 뒷받침되는 Quality, Completeness 및 LTS 검토 상태에 대해서만 qa/maturity-scores.yaml을 업데이트합니다.
6. 이 스킬의 스키마 검증 명령어를 실행합니다.
7. 문서 산문이 변경된 경우 pnpm check:docs를 실행하고, 커버리지 ID나 프로필 멤버십이 변경된 경우 집중 QA 커버리지 검사를 실행합니다.

주관적인 점수 변경의 경우, 가장 작은 방어 가능한 편집을 하고 PR 또는 작업 요약에 증거 경로를 남깁니다. 수동 산문을 현재 문서에 유지하고 점수 데이터를 qa/maturity-scores.yaml에 유지하세요.

기본 완전성 프로세스

완전성은 테스트 범위나 구현 품질이 아닌 각 범주에 대해 의도된 운영자 대상 워크플로우를 기준으로 점수가 매겨집니다. references/completeness/ 아래의 완전성 참조 파일은 범주 범위와 이 기본 프로세스의 모든 표면별 변형을 정의합니다.

기본적으로 완전성은 OpenClaw가 해당 표면에 대해 사용자, 운영자, 작성자 또는 유지보수자 페르소나에게 의도된 표면 기능 세트를 얼마나 완전히 노출하는지 측정합니다. 각 범주가 설정, 정상 사용, 상태 또는 검사, 복구, 그리고 적용 가능한 중요한 플랫폼, 제공자, 채널, 보안 또는 수명 주기 변형을 포함하여 예상되는 전체 워크플로우를 제공하는지 점수를 매기세요.

표면별 점수 매기기 질문과 표면별 지침을 해당 표면에 대해 더 높은 우선순위 지침으로 취급하세요. 표면 지침은 여기의 기본 아이디어를 구체화하거나, 축소하거나, 의도적으로 충돌할 수 있습니다; 그럴 때는 표면 지침을 따르고 점수 근거가 해당 표면별 지침을 반영하도록 하세요. 참조 파일에 표면별 질문이나 지침이 포함되지 않은 경우, 이 기본 프로세스를 표면의 범주 범위에 적용하세요.

각 범주에 대해 물어보세요:

• 의도된 사용자 또는 운영자가 범주 워크플로우를 처음부터 끝까지 완료할 수 있습니까?
• 분류 체계 기능이 격리된 구현 조각이 아닌 지원되는 기능으로 존재합니까?
• 중요한 수명 주기 단계(설정, 정상 운영, 상태/검사, 복구, 그리고 관련된 업그레이드 또는 제거)가 표현되어 있습니까?
• 이 표면에 대해 중요한 환경, 제공자, 플랫폼, 채널 또는 보안 분기가 존재합니까?
• 알려진 격차가 주요 사용자 대상 기능 분기를 누락시키고 있습니까?

기본 지침:

• 범주가 분류 체계와 범주 증거로 설명된 전체 운영자 대상 워크플로우를 지원하는 경우 더 높은 완전성을 선호하세요.
• 해피 패스만 존재하고, 중요한 변형이 문서화되지 않았거나 구현되지 않았거나, 복구/상태 경로가 누락된 경우 완전성을 낮추세요.
• 테스트가 부족하다고 완전성을 낮추지 마세요; 그것은 커버리지입니다.
• 구현 품질이 취약하다고 완전성을 낮추지 마세요; 그것은 Quality입니다.

기본 완전성 밴드:

• Clawesome (95-100): 예상 워크플로우, 변형 및 복구 분기 전반에 걸쳐 완전하며, 사소한 다듬기 격차만 있습니다.
• Stable (80-95): 예상 워크플로우 세트가 대체로 존재하며, 제한된 누락 분기만 있습니다.
• Beta (70-80): 주요 워크플로우가 존재하지만, 의미 있는 분기 또는 복구 경로가 여전히 없습니다.
• Alpha (50-70): 부분적인 기능 세트만 존재합니다; 사용자는 일부 핵심 작업을 완료할 수 있지만 전체 예상 워크플로우는 아닙니다.
• Experimental (0-50): 범주는 의도된 기능의 조각만 노출합니다.

결정 컨텍스트

표면 및 범주 Quality/Completeness에 대해 score와 label 옆에 선택적 decision을 기록하거나, 범주 LTS에 대해 supported 옆에 기록하세요. taxonomy.yaml에서는 정식 표면 level 옆에 선택적 level_decision을 사용하세요.

각 레코드에는 value, rationale, reviewer, evidence_refs 및 revalidate_when이 포함됩니다. Quality/Completeness에는 0-100의 정수를, LTS에는 부울을, level_decision에는 선언된 분류 체계 수준 ID를 사용하세요. 비어 있지 않은 텍스트 필드와 하나 이상의 증거 참조를 제공하세요. 실제 검토자 이름과 다른 검토를 트리거해야 하는 조건을 명시하세요.

사용할 수 없는 기록은 남겨두지 마세요: 알 수 없는 것이며, 검토자, 근거 또는 증거를 발명하라는 초대가 아닙니다. 레코드는 현재 점수, 지원 플래그 또는 정식 수준을 덮어쓰지 않습니다. 값이 다른 경우 둘 다 유지하세요; 생성된 문서는 엄격한 입력 검증 하에서도 차단하지 않는 불일치를 보여줍니다.

커버리지, 계산된 롤업, 표면 LTS 요약 또는 점수 집계에 복사된 수준에 결정을 첨부하지 마세요. 결정 컨텍스트는 커버리지 정체성, 점수 계산, 지원 약속 또는 릴리스 게이트를 변경하지 않습니다.

점수 의미

• 커버리지: 릴리스 프로필 qa-evidence.json.scorecard 기능 충족 데이터에서 파생된 결정적 릴리스 검증 커버리지입니다.
• Quality: 해당 범주에 대한 신뢰성, 유지보수성, 운영자 안전성 및 회귀 신뢰도입니다.
• 완전성: 해당 범주에 대해 의도된 운영자 대상 워크플로우가 얼마나 존재하는지입니다. 이 점수를 변경하기 전에 기본 완전성 프로세스와 모든 표면별 변형을 사용하세요.
• LTS: Quality, 릴리스 증거 커버리지 및 human_lts_override에서 파생됩니다; LTS 상태를 변경하기 위해 생성된 Markdown을 수동으로 편집하지 마세요.

밴드:

• Clawesome: 95-100
• Stable: 80-95
• Beta: 70-80
• Alpha: 50-70
• Experimental: 0-50

아티팩트

유지보수자 저장소의 docs/kevinslin/maturity-scorecard/inventory/ 트리를 openclaw에 추가하지 마세요. 증강된 스코어카드 출력은 이 저장소가 명시적 렌더러/체크 워크플로우를 먼저 추가하지 않는 한, 커밋된 생성 문서가 아닌 수명이 짧은 아티팩트에 속합니다.