claw-score

Was macht claw-score?

Verwenden Sie diese Fähigkeit bei der Arbeit an der OpenClaw-Reifegrad-Scorecard in diesem Repository. Dies ist die openclaw-lokale Version des Maintainer claw-score-Workflows: Sie behält die Taxonomie- und Scorecard-Konzepte bei, schließt jedoch Discrawl und den alten committierten inventory/-Berichtsbaum aus.

Autorität

Diese Fähigkeit besitzt den operativen Workflow für:

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

Halten Sie personenbezogene, maintainer-private, Discord-Archiv- und Discrawl-Fakten aus diesem Repository heraus. Wenn ein Score private Evidenz benötigt, verwenden Sie das redigierte qa-evidence.json-Artefaktformat, das von OpenClaw-QA-Workflows generiert wird.

Quellmodell

• taxonomy.yaml ist die manuell bearbeitete Wahrheitsquelle für Oberflächen, Ebenen, QA-Profile, Kategorien, Feature-Coverage-IDs, Dokumentationsverweise, LTS-Überschreibungen und Vollständigkeitsanweisungspfade.
• Jedes Feature hat genau einen coverageIds-Eintrag. Halten Sie diese Evidenz-ID eindeutig für das Feature; eine breitere Many-to-Many-Evidenzzuordnung ist nicht Teil des aktuellen Taxonomieschemas.
• Coverage-IDs verwenden die punktierte namespace.behavior-Form, mit Kleinbuchstaben, alphanumerischen/Bindestrich-Segmenten. Profil-, Oberflächen- und Kategorie-IDs können Bindestriche oder Punkte enthalten.
• Halten Sie Kategorien und Feature-Namen eindeutig, produktförmig und breiter als rohe Coverage-IDs. Fördern Sie keine generischen IDs zu eigenständigen Feature-Namen.
• Vermeiden Sie doppelte Coverage-ID-Bündel unter verschiedenen Feature-Namen in einer Kategorie.
• qa/maturity-scores.yaml ist die committierte aggregierte Quelle für Qualitäts-, Vollständigkeits- und LTS-Review-Zustand.
• extensions/qa-lab/src/scorecard-taxonomy.ts exportiert readValidatedQaMaturityScoreSources; verwenden Sie es, um Score-Ausgaben zu validieren.
• Generierte öffentliche Dokumente sind docs/maturity/scorecard.md und docs/maturity/taxonomy.md; beide stammen von pnpm maturity:render. Bearbeiten Sie generiertes Markdown nicht von Hand, um Score-Ergebnisse zu ändern.
• qa-evidence.json-Artefakte liefern pro-Lauf QA-Scorecard-Evidenz. Release- Profil-Artefakte sind die Wahrheitsquelle für die Abdeckung. Sie können generierte Artefakt-Dokumente anreichern, werden aber nicht als Inventar committiert.

Befehle

Führen Sie sie aus dem Stammverzeichnis des OpenClaw-Repository aus.

Validieren Sie die YAML-Struktur der Taxonomie und das Reifegrad-Score-Schema nach Quell- Bearbeitungen:

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

Überprüfen Sie Dokumente, wenn Sie Dokumentationstexte berühren:

pnpm check:docs

Führen Sie fokussierte QA/Profil-Prüfungen durch, wenn Sie Coverage-IDs oder Profilmitgliedschaften ändern:

pnpm openclaw qa coverage --json

Vollständige Generierungsläufe

Für einen direkten vollständigen Scorecard-Lauf, der den Pull-Request des generierten Dokuments veröffentlicht, verwenden Sie standardmäßig die fließende main-Auflösung:

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

Lösen Sie main nicht lokal auf und übergeben Sie diesen Commit nicht als sowohl ref als auch expected_sha für einen gewöhnlichen manuellen Generierungslauf. OpenClaws main bewegt sich schnell, sodass der vom Aufrufer ausgewählte Commit vor der Validierung veraltet sein kann. Der Workflow lehnt dann korrekt die Veröffentlichung ab, wenn die Pull-Request-Basis neuere Reifegrad- Eingaben enthält, und QA startet nie.

Mit ref=main und einer leeren expected_sha holt der floating_default_branch-Pfad des Workflows den aktuellen Remote-Standardbranch innerhalb der Validierung ab und friert ihn ein, bevor Downstream-Jobs eine unveränderliche Revision erhalten. Verwenden Sie eine explizite SHA nur, wenn die angeforderte Evidenz an diese genaue Revision gebunden bleiben muss, wie z. B. bei einem Release-Candidate-Workflow-Aufruf oder einer artefaktbasierten historischen Reproduktion. Wenn dieser exakte Revisionslauf auch eine Veröffentlichung anfordert und main relevante Eingaben geändert hat, erwarten Sie, dass die Validierung fehlschlägt, und starten Sie stattdessen erneut vom fließenden main aus.

Bewertungsworkflow

Wenn Sie aufgefordert werden, eine Oberfläche zu bewerten oder zu aktualisieren:

1. Lesen Sie die Oberfläche in taxonomy.yaml.
2. Lesen Sie die Bewertungsrubrik für die Oberflächenvollständigkeit unter .agents/skills/claw-score/references/completeness/.
3. Sammeln Sie öffentliche Repository-Evidenz aus Dokumentation, Quellcode, Tests und QA-Szenario- Metadaten.
4. Bevorzugen Sie vorhandene Release-Profil qa-evidence.json-Artefakte für ausgeführte Nachweise.
5. Aktualisieren Sie qa/maturity-scores.yaml nur für Qualität, Vollständigkeit und LTS- Review-Zustand, der durch öffentliche oder redigierte Artefakt-Evidenz gestützt wird.
6. Führen Sie den Schema-Validierungsbefehl aus dieser Fähigkeit aus.
7. Führen Sie pnpm check:docs aus, wenn sich Dokumentationstexte geändert haben, und fokussierte QA-Abdeckungsprüfungen wenn sich Coverage-IDs oder Profilmitgliedschaften geändert haben.

Bei subjektiven Score-Änderungen nehmen Sie die kleinste vertretbare Bearbeitung vor und hinterlassen Sie den Evidenzpfad in der PR- oder Aufgabenübersicht. Behalten Sie manuelle Prosa in aktuellen Dokumenten und halten Sie Score-Daten in qa/maturity-scores.yaml.

Standard-Vollständigkeitsprozess

Vollständigkeit wird gegen den beabsichtigten Bediener-sichtbaren Workflow für jede Kategorie bewertet, nicht gegen die Testbreite oder Implementierungsqualität. Die Vollständigkeits-Referenzdateien unter references/completeness/ definieren den Kategorienumfang und jede oberflächenspezifische Abweichung von diesem Standardprozess.

Standardmäßig misst die Vollständigkeit, wie vollständig OpenClaw den beabsichtigten Oberflächen-Fähigkeitssatz für den Benutzer, Bediener, Autor oder Maintainer für diese Oberfläche bereitstellt. Bewerten Sie, ob jede Kategorie den vollständig erwarteten Workflow liefert, einschließlich Einrichtung, normaler Nutzung, Status oder Inspektion, Wiederherstellung und wichtigen Plattform-, Anbieter-, Kanal-, Sicherheits- oder Lebenszyklusvarianten, sofern zutreffend.

Behandeln Sie "Surface-Specific Scoring Questions" und "Surface-Specific Guidance" als Anweisungen mit höherer Priorität für diese Oberfläche. Die Oberflächenanweisungen können die Standardideen hier ausarbeiten, einschränken oder absichtlich widersprechen; wenn sie es tun, folgen Sie den Oberflächenanweisungen und lassen Sie die Score-Begründung diese oberflächenspezifische Anweisung widerspiegeln. Wenn eine Referenzdatei keine oberflächenspezifischen Fragen oder Anleitungen enthält, wenden Sie diesen Standardprozess auf den "Category Scope" der Oberfläche an.

Stellen Sie für jede Kategorie:

• Kann der beabsichtigte Benutzer oder Bediener den Kategorie-Workflow Ende-zu-Ende abschließen?
• Sind die Taxonomie-Features als unterstützte Fähigkeiten vorhanden und nicht als isolierte Implementierungsfragmente?
• Sind die wichtigen Lebenszyklusphasen repräsentiert: Einrichtung, normaler Betrieb, Status/Inspektion, Wiederherstellung und Upgrade oder Entfernung, sofern relevant?
• Sind die wichtigen Umgebungs-, Anbieter-, Plattform-, Kanal- oder Sicherheitszweige für diese Oberfläche vorhanden?
• Lassen die bekannten Lücken große benutzersichtbare Fähigkeitszweige vermissen?

Standard-Anleitung:

• Bevorzugen Sie eine höhere Vollständigkeit, wenn die Kategorie den vollständigen Bediener-sichtbaren Workflow unterstützt, der durch Taxonomie und Kategorie-Evidenz beschrieben wird.
• Niedrigere Vollständigkeit, wenn nur der Happy Path existiert, wenn wichtige Varianten undokumentiert oder nicht implementiert sind oder wenn Wiederherstellungs-/Status-Pfade fehlen.
• Senken Sie die Vollständigkeit nicht, weil Tests dünn sind; das ist Abdeckung.
• Senken Sie die Vollständigkeit nicht, weil die Implementierungsqualität fragil ist; das ist Qualität.

Standard-Vollständigkeitsbänder:

• Clawesome (95-100): vollständig über erwartete Workflows, Varianten und Wiederherstellungszweige, mit nur geringfügigen Polierlücken.
• Stable (80-95): der erwartete Workflow-Satz ist weitgehend vorhanden, mit nur begrenzten fehlenden Zweigen.
• Beta (70-80): der Hauptworkflow existiert, aber sinnvolle Zweige oder Wiederherstellungs- Pfade fehlen noch.
• Alpha (50-70): nur ein partieller Fähigkeitssatz ist vorhanden; Benutzer können einige Kernaufgaben abschließen, aber nicht den vollständig erwarteten Workflow.
• Experimental (0-50): die Kategorie stellt nur Fragmente der beabsichtigten Fähigkeit bereit.

Entscheidungskontext

Zeichnen Sie eine optionale decision neben score und label für Oberflächen- und Kategorie- Qualität/Vollständigkeit auf, oder neben supported für Kategorie-LTS. In taxonomy.yaml verwenden Sie optionale level_decision neben der kanonischen Oberflächen-level.

Jeder Datensatz enthält value, rationale, reviewer, evidence_refs und revalidate_when. Verwenden Sie eine ganze Zahl von 0–100 für Qualität/Vollständigkeit, einen Boolean für LTS und eine deklarierte Taxonomie-Ebenen-ID für level_decision. Liefern Sie nicht leere Textfelder und mindestens eine Evidenzreferenz. Nennen Sie den tatsächlichen Reviewer und die Bedingung, die eine weitere Überprüfung auslösen sollte.

Lassen Sie nicht verfügbaren Verlauf abwesend: Er ist unbekannt, keine Einladung, Reviewer, Begründungen oder Evidenzen zu erfinden. Ein Datensatz überschreibt nicht den aktuellen Score, Support-Flag oder die kanonische Ebene. Wenn sein Wert abweicht, behalten Sie beide bei; generierte Dokumente zeigen eine nicht blockierende Abweichung, auch unter strenger Eingabevalidierung.

Hängen Sie keine Entscheidungen an Abdeckung, berechnete Zusammenfassungen, Oberflächen-LTS-Zusammenfassungen oder die kopierte Ebene in Score-Aggregaten an. Der Entscheidungskontext ändert nicht die Coverage-Identität, Score-Berechnungen, Support-Verpflichtungen oder Release-Gates.

Score-Semantik

• Abdeckung: deterministische Release-Validierungsabdeckung, abgeleitet aus den Release- Profil qa-evidence.json.scorecard Feature-Erfüllungsdaten.
• Qualität: Zuverlässigkeit, Wartbarkeit, Bedienersicherheit und Regressions- Vertrauen für die Kategorie.
• Vollständigkeit: Wie viel des beabsichtigten Bediener-sichtbaren Workflows existiert für die Kategorie. Verwenden Sie den Standard-Vollständigkeitsprozess plus alle oberflächenspezifischen Abweichungen, bevor Sie diesen Score ändern.
• LTS: abgeleitet von Qualität, Release-Evidenz-Abdeckung und human_lts_override; bearbeiten Sie generiertes Markdown nicht von Hand, um den LTS- Status zu ändern.

Bänder:

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

Artefakte

Fügen Sie den docs/kevinslin/maturity-scorecard/inventory/-Baum des Maintainer-Repository nicht zu openclaw hinzu. Evidenz-angereicherte Scorecard-Ausgaben gehören in kurzlebige Artefakte, nicht in committierte generierte Dokumente, es sei denn, dieses Repository fügt zuerst einen expliziten Renderer/Check-Workflow hinzu.