claw-score

Que fait claw-score ?

Utilisez ce skill lorsque vous travaillez sur la fiche de maturité OpenClaw dans ce dépôt. Il s'agit de la version openclaw-local du workflow claw-score du mainteneur : il conserve les concepts de taxonomie et de fiche de maturité, mais exclut discrawl et l'ancienne arborescence de rapports inventory/ validée.

Autorité

Ce skill possède le workflow opérationnel pour :

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

Conservez les faits propres à une personne, privés au mainteneur, d'archives Discord et de discrawl hors de ce dépôt. Si un score nécessite des preuves privées, utilisez la forme d'artefact qa-evidence.json expurgée générée par les workflows QA d'OpenClaw.

Modèle source

• taxonomy.yaml est la source de vérité éditée à la main pour les surfaces, les niveaux, les profils QA, les catégories, les ID de couverture de fonctionnalité, les références de documentation, les surcharges LTS et les chemins d'instructions d'exhaustivité.
• Chaque fonctionnalité a exactement une entrée coverageIds. Conservez cet ID de preuve unique à la fonctionnalité ; un mappage de preuves plus large many-to-many ne fait pas partie du schéma de taxonomie actuel.
• Les ID de couverture utilisent la forme pointée namespace.behavior, avec des segments alphanumériques/tirets en minuscules. Les ID de profil, de surface et de catégorie peuvent rester en tirets ou en points.
• Conservez les noms de catégories et de fonctionnalités uniques, en forme de produit et plus larges que les ID de couverture bruts. Ne promouvez pas d'ID génériques en noms de fonctionnalités autonomes.
• Évitez les doublons de bundles d'ID de couverture sous différents noms de fonctionnalités dans une catégorie.
• qa/maturity-scores.yaml est la source agrégée validée pour l'état de révision Qualité, Exhaustivité et LTS.
• extensions/qa-lab/src/scorecard-taxonomy.ts exporte readValidatedQaMaturityScoreSources ; utilisez-le pour valider la sortie du score.
• Les documents publics générés sont docs/maturity/scorecard.md et docs/maturity/taxonomy.md ; les deux proviennent de pnpm maturity:render. Ne modifiez pas à la main le Markdown généré pour modifier les résultats de score.
• Les artefacts qa-evidence.json fournissent des preuves de fiche de maturité QA par exécution. Les artefacts de profil de version sont la source de vérité pour la Couverture. Ils peuvent enrichir les documents d'artefacts générés, mais ils ne sont pas validés en tant qu'inventaire.

Commandes

Exécutez depuis la racine du dépôt openclaw.

Validez la structure YAML de la taxonomie et le schéma de score de maturité après des modifications source :

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

Vérifiez les documents lorsque vous touchez à la prose des documents :

pnpm check:docs

Exécutez des vérifications QA/profil ciblées lorsque vous modifiez des ID de couverture ou l'appartenance à un profil :

pnpm openclaw qa coverage --json

Exécutions de génération complète

Pour une exécution directe et complète de la fiche de maturité qui publie la pull request de document généré, utilisez la résolution flottante main par défaut :

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

Ne résolvez pas main localement et ne passez pas ce commit comme ref et expected_sha pour une exécution de génération manuelle ordinaire. La branche main d'OpenClaw évolue rapidement, donc le commit sélectionné par l'appelant peut devenir obsolète avant la validation. Le workflow rejette alors correctement la publication lorsque la base de la pull request contient des entrées de maturité plus récentes, et la QA ne démarre jamais.

Avec ref=main et un expected_sha vide, le chemin floating_default_branch du workflow récupère et fige la branche par défaut distante actuelle dans la validation avant de remettre une révision immuable aux tâches en aval. Utilisez un SHA explicite uniquement lorsque la preuve demandée doit rester liée à cette révision exacte, comme un appel de workflow de release candidate ou une reproduction historique uniquement par artefact. Si cette exécution de révision exacte demande également la publication et que main a modifié les entrées pertinentes, attendez-vous à un échec de validation et relancez à partir de main flottante à la place.

Workflow de notation

Lorsqu'on vous demande de noter ou de rafraîchir une surface :

1. Lisez la surface dans taxonomy.yaml.
2. Lisez la grille d'exhaustivité de la surface sous .agents/skills/claw-score/references/completeness/.
3. Rassemblez les preuves publiques du dépôt à partir des documents, du code source, des tests et des métadonnées de scénario QA.
4. Préférez les artefacts qa-evidence.json de profil de version existants pour les preuves exécutées.
5. Mettez à jour qa/maturity-scores.yaml uniquement pour l'état de révision Qualité, Exhaustivité et LTS étayé par des preuves d'artefact publiques ou expurgées.
6. Exécutez la commande de validation de schéma de ce skill.
7. Exécutez pnpm check:docs si la prose des documents a changé, et les vérifications de couverture QA ciblées si les ID de couverture ou l'appartenance à un profil ont changé.

Pour les modifications subjectives de score, effectuez la plus petite modification défendable et laissez la voie de preuve dans le résumé de la PR ou de la tâche. Conservez la prose manuelle dans les documents actuels et conservez les données de score dans qa/maturity-scores.yaml.

Processus d'exhaustivité par défaut

L'exhaustivité est évaluée par rapport au workflow visible par l'opérateur prévu pour chaque catégorie, et non par rapport à l'étendue des tests ou à la qualité de l'implémentation. Les fichiers de référence d'exhaustivité sous references/completeness/ définissent la portée de la catégorie et toute variation spécifique à la surface par rapport à ce processus par défaut.

Par défaut, l'exhaustivité mesure dans quelle mesure OpenClaw expose l'ensemble de capacités de surface prévu à l'utilisateur, à l'opérateur, à l'auteur ou au persona du mainteneur pour cette surface. Évaluez si chaque catégorie fournit le workflow attendu complet, y compris la configuration, l'utilisation normale, le statut ou l'inspection, la récupération, et les variantes importantes de plateforme, fournisseur, canal, sécurité ou cycle de vie, le cas échéant.

Traitez les Questions de notation spécifiques à la surface et les Directives spécifiques à la surface comme instructions prioritaires pour cette surface. Les instructions de surface peuvent développer, restreindre ou entrer intentionnellement en conflit avec les idées par défaut ici ; dans ce cas, suivez les instructions de surface et faites en sorte que la justification du score reflète cette instruction spécifique à la surface. Si un fichier de référence n'inclut pas de questions ou de directives spécifiques à la surface, appliquez ce processus par défaut à la Portée de la catégorie de la surface.

Pour chaque catégorie, demandez :

• L'utilisateur ou l'opérateur prévu peut-il effectuer le workflow complet de la catégorie de bout en bout ?
• Les fonctionnalités de taxonomie sont-elles présentes en tant que capacités prises en charge plutôt que fragments d'implémentation isolés ?
• Les étapes importantes du cycle de vie sont-elles représentées : configuration, fonctionnement normal, statut/inspection, récupération, et mise à niveau ou suppression, le cas échéant ?
• Les branches importantes d'environnement, fournisseur, plateforme, canal ou sécurité sont-elles présentes pour cette surface ?
• Les lacunes connues laissent-elles des branches de capacités majeures visibles par l'utilisateur manquantes ?

Directives par défaut :

• Favorisez une exhaustivité plus élevée lorsque la catégorie prend en charge le workflow complet visible par l'opérateur décrit par la taxonomie et les preuves de catégorie.
• Abaissez l'exhaustivité lorsque seul le chemin heureux existe, lorsque des variantes importantes ne sont pas documentées ou implémentées, ou lorsque les chemins de récupération/statut sont manquants.
• N'abaissez pas l'exhaustivité parce que les tests sont minces ; c'est la Couverture.
• N'abaissez pas l'exhaustivité parce que la qualité d'implémentation est fragile ; c'est la Qualité.

Niveaux d'exhaustivité par défaut :

• Clawesome (95-100) : complet sur les workflows, variantes et branches de récupération attendus, avec seulement des lacunes de polissage mineures.
• Stable (80-95) : l'ensemble de workflows attendu est largement présent, avec seulement des branches manquantes limitées.
• Bêta (70-80) : le workflow principal existe, mais des branches significatives ou des chemins de récupération sont encore absents.
• Alpha (50-70) : seul un ensemble de capacités partielles est présent ; les utilisateurs peuvent effectuer certaines tâches de base mais pas le workflow complet attendu.
• Expérimental (0-50) : la catégorie n'expose que des fragments de la capacité prévue.

Contexte de décision

Enregistrez une decision facultative à côté de score et label pour la Qualité/Exhaustivité de la surface et de la catégorie, ou à côté de supported pour la LTS de la catégorie. Dans taxonomy.yaml, utilisez level_decision facultatif à côté du level canonique de la surface.

Chaque enregistrement contient value, rationale, reviewer, evidence_refs et revalidate_when. Utilisez un entier de 0 à 100 pour la Qualité/Exhaustivité, un booléen pour la LTS, et un ID de niveau de taxonomie déclaré pour level_decision. Fournissez des champs de texte non vides et au moins une référence de preuve. Nommez le relecteur réel et la condition qui devrait déclencher une autre révision.

Laissez l'historique indisponible absent : il est inconnu, pas une invitation à inventer des relecteurs, une justification ou des preuves. Un enregistrement n'écrase pas le score actuel, l'indicateur de support ou le niveau canonique. Si sa valeur diffère, conservez les deux ; les documents générés montrent une divergence non bloquante, y compris sous validation d'entrée stricte.

N'attachez pas de décisions à la Couverture, aux cumuls calculés, aux résumés LTS de surface ou au niveau copié dans les agrégats de score. Le contexte de décision ne modifie pas l'identité de couverture, les calculs de score, les engagements de support ou les barrières de version.

Sémantique des scores

• Couverture : couverture de validation de version déterministe dérivée des données de réalisation de fonctionnalité qa-evidence.json.scorecard du profil de version.
• Qualité : fiabilité, maintenabilité, sécurité de l'opérateur et confiance de régression pour la catégorie.
• Exhaustivité : dans quelle mesure du workflow visible par l'opérateur prévu existe pour la catégorie. Utilisez le processus d'exhaustivité par défaut plus toute variation spécifique à la surface avant de modifier ce score.
• LTS : dérivé de la Qualité, de la couverture des preuves de version et de human_lts_override ; ne modifiez pas le Markdown généré à la main pour changer le statut LTS.

Niveaux :

• Clawesome : 95-100
• Stable : 80-95
• Bêta : 70-80
• Alpha : 50-70
• Expérimental : 0-50

Artefacts

N'ajoutez pas l'arborescence docs/kevinslin/maturity-scorecard/inventory/ du dépôt du mainteneur à openclaw. Les sorties de fiche de maturité enrichies de preuves appartiennent à des artefacts éphémères, pas à des documents générés validés, à moins que ce dépôt n'ajoute d'abord un workflow explicite de rendu/vérification.