claw-score

O que claw-score faz?

Use este skill ao trabalhar no scorecard de maturidade do OpenClaw neste repositório. Esta é a versão openclaw-local do fluxo de trabalho claw-score do mantenedor: ele mantém os conceitos de taxonomia e scorecard, mas exclui discrawl e a antiga árvore de relatórios inventory/ commitada.

Autoridade

Este skill possui o fluxo de trabalho operacional para:

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

Mantenha fatos específicos de pessoa, privados do mantenedor, de arquivo do Discord e discrawl fora deste repositório. Se uma pontuação precisar de evidência privada, use o formato de artefato qa-evidence.json redigido gerado pelos fluxos de trabalho de QA do OpenClaw.

Modelo de Origem

• taxonomy.yaml é a fonte de verdade editada manualmente para superfícies, níveis, perfis de QA, categorias, IDs de cobertura de funcionalidades, referências de docs, substituições LTS e caminhos de instrução de completude.
• Cada funcionalidade tem exatamente uma entrada coverageIds. Mantenha esse ID de evidência único para a funcionalidade; mapeamento de evidência muitos-para-muitos mais amplo não faz parte do esquema de taxonomia atual.
• IDs de cobertura usam o formato namespace.behavior com pontos, com segmentos alfanuméricos minúsculos/traço. IDs de perfil, superfície e categoria podem permanecer com traço ou ponto.
• Mantenha nomes de categorias e funcionalidades únicos, em formato de produto e mais amplos que IDs de cobertura brutos. Não promova IDs genéricos a nomes de funcionalidades independentes.
• Evite pacotes de ID de cobertura duplicados sob nomes de funcionalidades diferentes em uma categoria.
• qa/maturity-scores.yaml é a fonte agregada commitada para estado de revisão de Quality, Completeness e LTS.
• extensions/qa-lab/src/scorecard-taxonomy.ts exporta readValidatedQaMaturityScoreSources; use-o para validar a saída do score.
• Os documentos públicos gerados são docs/maturity/scorecard.md e docs/maturity/taxonomy.md; ambos vêm de pnpm maturity:render. Não edite manualmente o Markdown gerado para alterar resultados de pontuação.
• Artefatos qa-evidence.json fornecem evidências de scorecard de QA por execução. Artefatos de perfil de lançamento são a fonte de verdade para Cobertura. Eles podem enriquecer documentos de artefato gerados, mas não são commitados como inventário.

Comandos

Execute a partir da raiz do repositório openclaw.

Validar a estrutura YAML da taxonomia e o esquema de pontuação de maturidade após edições na fonte:

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

Verificar documentos ao tocar na prosa dos documentos:

pnpm check:docs

Executar verificações focadas de QA/perfil ao alterar IDs de cobertura ou associação de perfil:

pnpm openclaw qa coverage --json

Execuções de Geração Completas

Para uma execução direta e completa do scorecard que publica o pull request do documento gerado, use a resolução flutuante de main por padrão:

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

Não resolva main localmente e passe esse commit como ref e expected_sha para uma execução de geração manual comum. O main do OpenClaw se move rapidamente, então o commit selecionado pelo chamador pode ficar desatualizado antes da validação. O fluxo de trabalho então rejeita corretamente a publicação quando a base do pull request contém entradas de maturidade mais novas, e o QA nunca inicia.

Com ref=main e um expected_sha em branco, o caminho floating_default_branch do fluxo de trabalho busca e congela a branch padrão remota atual dentro da validação antes de passar uma revisão imutável para tarefas downstream. Use um SHA explícito apenas quando a evidência solicitada deve permanecer vinculada a essa revisão exata, como uma chamada de fluxo de trabalho de candidato a lançamento ou uma reprodução histórica apenas de artefato. Se essa execução de revisão exata também solicitar publicação e main tiver alterado entradas relevantes, espere que a validação falhe e despache novamente a partir de main flutuante.

Fluxo de Trabalho de Pontuação

Quando solicitado a pontuar ou atualizar uma superfície:

1. Leia a superfície em taxonomy.yaml.
2. Leia a rubrica de completude da superfície em .agents/skills/claw-score/references/completeness/.
3. Reúna evidências públicas do repositório a partir de documentos, código, testes e metadados de cenário de QA.
4. Prefira artefatos qa-evidence.json de perfil de lançamento existentes para prova executada.
5. Atualize qa/maturity-scores.yaml apenas para Quality, Completeness e estado de revisão LTS baseados em evidências de artefatos públicos ou redigidos.
6. Execute o comando de validação de esquema deste skill.
7. Execute pnpm check:docs se a prosa dos documentos mudou, e verificações focadas de cobertura de QA se IDs de cobertura ou associação de perfil mudaram.

Para alterações subjetivas de pontuação, faça a menor edição defensável e deixe o caminho da evidência no resumo do PR ou tarefa. Mantenha a prosa manual nos documentos atuais e a pontuação em qa/maturity-scores.yaml.

Processo Padrão de Completude

A Completude é pontuada em relação ao fluxo de trabalho pretendido visível pelo operador para cada categoria, não em relação à amplitude de testes ou qualidade de implementação. Os arquivos de referência de completude em references/completeness/ definem o escopo da categoria e qualquer variação específica de superfície deste processo padrão.

Por padrão, a Completude mede o quão completamente o OpenClaw expõe o conjunto de capacidades pretendidas da superfície ao usuário, operador, autor ou persona de mantenedor para essa superfície. Pontue se cada categoria entrega o fluxo de trabalho completo esperado, incluindo configuração, uso normal, status ou inspeção, recuperação e variantes importantes de plataforma, provedor, canal, segurança ou ciclo de vida onde se aplicam.

Trate Perguntas de Pontuação Específicas da Superfície e Orientação Específica da Superfície como instruções de maior prioridade para essa superfície. As instruções da superfície podem elaborar, restringir ou entrar em conflito intencionalmente com as ideias padrão aqui; quando isso acontecer, siga as instruções da superfície e faça a justificativa da pontuação refletir essa instrução específica da superfície. Se um arquivo de referência não incluir perguntas ou orientação específicas da superfície, aplique este processo padrão ao Escopo da Categoria da superfície.

Para cada categoria, pergunte:

• O usuário ou operador pretendido pode concluir o fluxo de trabalho da categoria de ponta a ponta?
• As funcionalidades da taxonomia estão presentes como capacidades suportadas em vez de fragmentos de implementação isolados?
• Os estágios importantes do ciclo de vida estão representados: configuração, operação normal, status/inspeção, recuperação e atualização ou remoção quando relevante?
• Os ramos importantes de ambiente, provedor, plataforma, canal ou segurança estão presentes para esta superfície?
• As lacunas conhecidas deixam grandes ramos de capacidade visíveis pelo usuário ausentes?

Orientação padrão:

• Favoreça Completude maior quando a categoria suporta o fluxo de trabalho completo visível pelo operador descrito pela taxonomia e evidências da categoria.
• Reduza a Completude quando apenas o caminho feliz existe, quando variantes importantes são não documentadas ou não implementadas, ou quando caminhos de recuperação/status estão ausentes.
• Não reduza a Completude porque os testes são superficiais; isso é Cobertura.
• Não reduza a Completude porque a qualidade da implementação é frágil; isso é Quality.

Faixas de Completude padrão:

• Clawesome (95-100): completo em todos os fluxos de trabalho, variantes e ramos de recuperação esperados, com apenas pequenas lacunas de polimento.
• Stable (80-95): o conjunto de fluxos de trabalho esperado está amplamente presente, com apenas ramos ausentes limitados.
• Beta (70-80): o fluxo de trabalho principal existe, mas ramos significativos ou caminhos de recuperação ainda estão ausentes.
• Alpha (50-70): apenas um conjunto parcial de capacidades está presente; os usuários podem concluir algumas tarefas principais, mas não o fluxo de trabalho completo esperado.
• Experimental (0-50): a categoria expõe apenas fragmentos da capacidade pretendida.

Contexto de Decisão

Registre uma decision opcional ao lado de score e label para Quality/Completude de superfície e categoria, ou ao lado de supported para LTS de categoria. Em taxonomy.yaml, use level_decision opcional ao lado do level canônico da superfície.

Cada registro contém value, rationale, reviewer, evidence_refs e revalidate_when. Use um inteiro de 0–100 para Quality/Completude, um booleano para LTS e um ID de nível de taxonomia declarado para level_decision. Forneça campos de texto não vazios e pelo menos uma referência de evidência. Nomeie o revisor real e a condição que deve disparar outra revisão.

Deixe histórico indisponível ausente: é desconhecido, não um convite para inventar revisores, justificativa ou evidência. Um registro não substitui a pontuação atual, o sinalizador de suporte ou o nível canônico. Se seu valor diferir, retenha ambos; documentos gerados mostram uma divergência não bloqueante, incluindo sob validação estrita de entrada.

Não anexe decisões a Cobertura, cálculos agregados, resumos de LTS de superfície ou ao nível copiado em agregados de pontuação. O contexto de decisão não altera identidade de cobertura, cálculos de pontuação, compromissos de suporte ou portões de lançamento.

Semântica de Pontuação

• Cobertura: cobertura de validação de lançamento determinística derivada dos dados de cumprimento de funcionalidade qa-evidence.json.scorecard do perfil de lançamento.
• Quality: confiabilidade, manutenibilidade, segurança do operador e confiança de regressão para a categoria.
• Completude: quanto do fluxo de trabalho pretendido visível pelo operador existe para a categoria. Use o processo padrão de completude mais qualquer variação específica de superfície antes de alterar esta pontuação.
• LTS: derivado de Quality, Cobertura de evidência de lançamento e human_lts_override; não edite manualmente o Markdown gerado para alterar o status LTS.

Faixas:

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

Artefatos

Não adicione a árvore docs/kevinslin/maturity-scorecard/inventory/ do repositório do mantenedor ao openclaw. Saídas de scorecard enriquecidas com evidências pertencem a artefatos de curta duração, não a documentos gerados commitados, a menos que este repositório adicione um fluxo de trabalho explícito de renderizador/verificação primeiro.