(MUSS) Für Codex: Wenn QA Plugins verwenden muss
- Browser – Steuere den In-App-Browser
- Chrome – Steuere den echten Chrome-Browser des Benutzers
- Computer Use – Steuere Windows-Apps oder installierte Artefakte, wenn QA eine echte App-Interaktion außerhalb eines Browsers erfordert.
- Playwright: Verwende dies als Automationsarm für Browser-Aktionen, Steuerungs-Sweeps, Screenshots, Videos, Traces und Berichte.
(MUSS) Für Claude oder andere Agenten:
- Verwende die äquivalente Browser-, Chrome/Session- oder Computer-Control-Fähigkeit, die von diesem Agenten/Runtime bereitgestellt wird, oder eine Playwright-ähnliche Fähigkeit, die in dieser Umgebung verfügbar ist.
QA-Laufzeitüberprüfung mit Anvien
Nutze diese Fähigkeit, um das tatsächliche Laufzeitverhalten aus der Benutzerperspektive zu überprüfen. QA ist eine reine Beobachtungsrolle: Prüfen, Ausführen, Aufzeichnen, Klassifizieren und Berichten. Repariere während der QA keine Produktcode, Tests, Spezifikationen, Fixtures oder generierte Dateien.
Anvien ist ein Discovery-Tool für QA. Es hilft, Routen, Oberflächen, Handler, APIs, Stores, Berechtigungen, Quelldateien und Datenflüsse zu kartieren. Es beweist nicht, dass ein Benutzer eine Oberfläche erreichen, ein Steuerelement klicken, den richtigen Zustand sehen oder einen Ablauf abschließen kann. Laufzeitevidenz ist die Quelle für das QA-Urteil.
Eiserne Gesetze
- QA DARF KEINEN Code reparieren. Melde nur Fehler, Blockaden, Reibungspunkte, Testlücken und eine vorgeschlagene Reparaturrichtung.
- Laufzeitverhalten ist die Quelle der QA-Wahrheit. Code-Präsenz, Tests, Screenshots oder Graph-Ausgabe allein beweisen weder Bestehen noch Nichtbestehen.
- Muss Screenshot-Evidenz haben.
- Tests verifizieren bereits korrektes Verhalten. Tests definieren kein erwartetes Verhalten und dürfen falsche UX nicht legitimieren.
- Falsche Tests sind Befunde. Ein grüner Test, der falsches Verhalten kodiert, ist kein QA-Beweis.
- Überspringe keine Schritte. Jeder Schritt in einem relevanten Ablauf zählt gleichermaßen.
- Jede relevante Oberfläche, Aktion, jeder Zustand, Datenpfad und jede Blockade benötigt ein explizites Urteil oder eine „Nicht im Umfang“-Markierung.
- Ein unvollständiges Inventar oder Aktionsprotokoll bedeutet unvollständige QA.
- Wenn eine Blockade die nachgelagerte Überprüfung verhindert, ist der nachgelagerte Umfang
Blocked, nicht bestanden. - Für die abschließende sichtbare QA öffne die echte erstellte Website, Runtime oder das generierte App-Artefakt genauso, wie ein Benutzer es öffnen würde, in einem sichtbaren Browser oder App-Fenster auf dem physischen PC des Benutzers. Headless, versteckte, reine Quellcode-, reine Test- oder reine Screenshot-Ausführung kann die abschließende sichtbare QA nicht genehmigen.
- QA muss auf der echten, offiziell erstellten Anwendung (tatsächliches Electron-Artefakt oder Release-Binärdatei) ausgeführt werden.
- Jede Aktion (Klicken von Schaltflächen, Eingeben von Daten, Ändern des Zustands) muss klare PNG-Screenshots erfassen, die nacheinander im Verzeichnis
screenshots/gespeichert werden. - Prüfe jedes erfasste Bild/jedes visuelle Artefakt visuell, um UI- und Verhaltensfehler zu erkennen; verlasse dich niemals ausschließlich auf Code-Assertions oder generierte
.json/.md-Zusammenfassungsdateien. - Akzeptiere niemals einen QA-Bericht, dem die tatsächliche Screenshot-Evidenz für jede Interaktion fehlt.
Quelle des erwarteten Verhaltens
Verwende die erste verfügbare anwendbare Autorität, in dieser Reihenfolge:
- Expliziter QA-Umfang des Benutzers und „Nicht reparieren“-Anweisung.
- Repository-Regeln wie
AGENTS.md. - Aktiver Ausführungsplan, QA-Plan oder SPEC-Familie.
- Sichtbarer Browser-Plan, wenn abschließende sichtbare QA angefordert wird oder der Plan im Umfang ist.
- Das QA-Protokoll dieser Fähigkeit.
- Abdeckungsmodell, Inventaranforderungen und Steuerungs-/Zustandsprotokolle unten.
- Anvien-Graph-Evidenz nur als Mapping-Unterstützung.
- Automatisierte Tests nur als Verifikations-Evidenz.
Wenn Autoritäten in Konflikt stehen, benenne den Konflikt und folge der höheren Autorität. Verwende niemals eine Testerwartung, um das tatsächlich erforderliche Produktverhalten zu überschreiben.
Anvien-Einsatz in der QA
Verwende Anvien, um Umfangslücken zu vermeiden und Datenflüsse zu verstehen. Verwende Anvien nicht als Ersatz für Laufzeitinteraktion.
Führe vor graph-basierter Anvien-Arbeit Folgendes aus:
anvien analyze --force
Nützliche Anvien-Auswahlen:
| QA-Bedarf | Verwende |
|---|---|
| Route, Seite, Komponente, Verhalten oder Risikobesitzer finden | anvien query "<Konzept>" --repo <repo> |
| Kandidatendateien für ein Verhalten finden | anvien query files "<Konzept>" --repo <repo> |
| Eine Datei tiefgehend prüfen | anvien file-detail <Pfad> --repo <repo> --json |
| Route-Handler und Konsumenten prüfen | anvien api route-map [Route] --repo <repo> |
| Abweichung der Antwortstruktur gegenüber Konsumenten prüfen | anvien api shape-check [Route] --repo <repo> |
| Werkzeug-/IPC-Pfade prüfen | anvien api tool-map [Werkzeug] --repo <repo> |
| Quellbesitzer für vorgeschlagene Reparaturrichtung identifizieren | anvien impact file <Pfad> --repo <repo> --direction upstream oder anvien impact symbol "<Symbol>" --repo <repo> --direction upstream |
| Graph-Evidenz prüfen, wenn Anvien veraltet oder unvollständig erscheint | anvien graph-health summary --repo <repo> --json |
Zeichne Anvien-Evidenz als Umfangs-Mapping-Evidenz auf:
- Route/Seiten-Kandidaten
- Eingehängte Einstiegspunkt-Kandidaten
- Aktion/Handler/API-Kandidaten
- Datenquelle/Store/API/DB-Kandidaten
- Berechtigungs-/Kontext-Gate-Kandidaten
- Wahrscheinliche Quelldateien für vorgeschlagene Reparaturrichtung
Markiere nichts als bestanden, nur weil Anvien es gefunden hat. Bestehen/Nichtbestehen erfordert Laufzeitevidenz.
Kern-Workflow
- Preflight → Build, Runtime, Browser (→ lies
references/runtime-and-build-rules.md) - Inventar → Oberflächen, Steuerelemente, Zustände (→ lies
references/coverage-model.md) - Automation → Screenshots, Steuerungs-Sweep (→ lies
references/automation-and-evidence-capture.md) - Datenfluss → Quelle der Wahrheit verfolgen (→ lies
references/data-flow-and-source-of-truth.md) - Locale → wenn i18n im Umfang (→ lies
references/i18n-and-locale.md) - Evidenz → sammeln, Blockaden klassifizieren (→ lies
references/evidence-and-blockers.md) - Bericht → Befunde, Urteil, Übergabe (→ lies
references/reporting.md)
Schnell-Entscheidungsbaum
- Bereite Build, Runtime oder Browser vor? →
references/runtime-and-build-rules.md - Führe Steuerungs-Sweep durch oder erfasse Screenshots? →
references/automation-and-evidence-capture.md - Erstelle Inventar oder prüfe Zustandsmatrix? →
references/coverage-model.md - Verfolge Datenfluss oder DB-Rücklesung? →
references/data-flow-and-source-of-truth.md - Umfang enthält i18n / Lokalisierung? →
references/i18n-and-locale.md - Zeichne Evidenz auf oder behandle Blockaden? →
references/evidence-and-blockers.md - Schreibe Bericht oder klassifiziere Befunde? →
references/reporting.md
Warnsignale
Stoppe, melde oder passe den Umfang an, wenn:
- QA beginnt, Code zu reparieren.
- QA Anvien, Quellcode oder Tests als Bestehen/Nichtbestehen-Beweis verwendet.
- QA für die abschließende sichtbare QA nur den headless/versteckten Browser verwendet.
- QA das Inventar überspringt.
- QA einen Schritt in einem relevanten Ablauf überspringt.
- QA nur den Happy Path klickt.
- QA deaktivierte, No-Op, abgelehnte, leere, fehlerhafte, veraltete oder blockierte Zustände ignoriert.
- QA falsche App-/kommerzielle Daten verwendet, als wären sie echter Produktionszustand.
- QA DB-/Quellrücklesung für DB-gestütztes Verhalten ignoriert.
- QA Locale/Session/Berechtigungsänderungen ignoriert, wenn sie im Umfang sind.
- QA nachgelagerten Umfang als bestanden meldet, nachdem eine vorgelagerte Blockade aufgetreten ist.
Referenzindex
| Bedarf | Datei |
|---|---|
| Build, Runtime, sichtbare Browser/App-Regeln | references/runtime-and-build-rules.md |
| Screenshot-Erfassung, Steuerungs-Sweep | references/automation-and-evidence-capture.md |
| Inventar, Urteil, Ablaufschritte, Zustandsmatrix | references/coverage-model.md |
| Datenverfolgung, DB, Quelle der Wahrheit | references/data-flow-and-source-of-truth.md |
| i18n / Locale-Umfang | references/i18n-and-locale.md |
| Evidenzquellen, Tests, Blockaden-Weitergabe | references/evidence-and-blockers.md |
| Befundklassifizierung, Berichtsvorlage, Übergabe | references/reporting.md |