Validiert den Requirement-Corpus unter .codecharter/req (Format siehe Requirements), das Requirement-Pendant zu codecharter config validate. Ohne weitere Optionen öffnet der Befehl nie eine Solution oder ein Projekt, läuft deshalb schnell und braucht kein .NET SDK; mit --with-code wird der Corpus zusätzlich gegen den analysierten Code geprüft (siehe --with-code unten).

Synopsis

codecharter req check [--workspace <pfad>] [--output console|json] [--no-color] [--with-code]

Optionen

Option	Default	Bedeutung
--workspace <pfad>	aktuelles Verzeichnis	Eine Datei oder ein Verzeichnis im Repository. CodeCharter läuft davon ausgehend aufwärts, um .codecharter/req zu finden (oder die alte Ablage .codeguard/req).
--output console\|json	console	Ausgabeformat.
--no-color	aus	ANSI-Farbcodes in der Konsolenausgabe abschalten.
--with-code	aus	Zusätzlich die Solution/das Projekt analysieren und Anchors sowie Acceptance-Criteria dagegen prüfen. Siehe --with-code.
--license <pfad>	–	Pfad zu einer codecharter.license-Datei, wie bei jedem anderen lizenzgeprüften Befehl.

Prüfungen

Jede Prüfung meldet sich über den zugehörigen Code unten. Die Severity ist je Code fix, außer wo vermerkt.

Code	Severity	Gemeldet wenn
req-duplicate-id	Fehler	Dieselbe Requirement-Id ist in zwei oder mehr .req.md-Dateien deklariert, oder dieselbe Criterion-Id kommt innerhalb eines Requirements doppelt vor.
req-dangling-refines	Fehler	Ein relations.refines-Eintrag nennt eine Requirement-Id, die im Corpus nicht existiert.
req-criterion-without-carrier	Fehler	Der Carrier-Wert eines Criteriums (rule:, test:, manual:, integration: oder external:) ist leer oder besteht nur aus Whitespace.
req-implemented-open-criteria	Fehler	Ein Requirement steht auf status: implemented, während eines oder mehrere seiner Criteria noch status: open tragen.
req-without-anchor	Fehler / Warnung	Ein Requirement hat gar keinen Traceability-Anchor: Fehler, wenn status implemented oder partial ist, Warnung bei open oder in-progress.
req-documents-invalid	Fehler	Ein Strukturproblem in documents.yml, das erst beim Abgleich mit dem Corpus sichtbar wird: ein Kapitel-Slug taucht in zwei Dokumenten auf, oder eine Requirement-Id steht doppelt in einem Kapitel.
req-documents-unknown-id	Fehler	Ein Kapitel in documents.yml listet eine Requirement-Id, die im Corpus nicht existiert.
req-documents-missing-req	Warnung	Ein Requirement im Corpus steht in keinem Kapitel von documents.yml (nur geprüft, wenn documents.yml existiert).
req-unknown-conflict-id	Warnung	Ein relations.conflicts-Eintrag nennt eine Requirement-Id, die im Corpus nicht existiert.
req-corpus-empty	Warnung	Das Verzeichnis .codecharter/req fehlt oder enthält keine *.req.md-Dateien.
req-id-filename-mismatch	Warnung	Der Dateiname einer .req.md-Datei entspricht nicht <id>.req.md für die deklarierte Id.

Ein paar Strukturprobleme (ein Criterion mit null oder mehr als einem Carrier-Schlüssel, ein unbekannter Top-Level-Frontmatter-Schlüssel, ein doppelter Dokument- oder Kapitel-Slug innerhalb eines einzelnen Manifests) werden bereits beim Parsen gemeldet, unter req-schema-invalid, statt über einen der Codes oben: sie brauchen nur den Inhalt der einen Datei, nicht den zusammengesetzten Corpus.

--with-code

Ohne --with-code liest req check nur den .req.md-Corpus: der Befehl weiß dann weder, ob ein Anchor tatsächlich auf realen Code zeigt, noch ob eine gepinnte Freigabe noch zum Code passt. --with-code schließt diese Lücke: die Solution/das Projekt wird genau einmal analysiert (derselbe Acquisition-Pfad wie bei codecharter graph, mit einem auf die Bedürfnisse der Corpus-Criteria erweiterten Capability-Profil, einschließlich Body-Syntax), danach laufen drei zusätzliche Prüfungen gegen das Ergebnis:

• Anchor-Reconciliation. Jeder symbol_id- und file+selector-Anchor wird gegen den analysierten Code aufgelöst (nicht nur auf eine wohlgeformte Struktur geprüft), und jedes [Satisfies("...")]-Attribut im Code wird gegen den Corpus geprüft. Siehe Anchors für die Anchor-Arten; der Selector eines file+selector-Anchors wird mit einer geschlossenen Grammatik geprüft (literaler Teilstring, line:, heading: — keine regulären Ausdrücke).
• Co-Retrieval-Overlap. Zwei Requirements, deren transitiv gerechtfertigter Code (alles, was von ihren Anchors aus erreichbar ist) sich überschneidet, werden markiert, sodass überlappende Zuständigkeit sichtbar wird statt stillschweigend zu duplizieren.
• Acceptance-Criteria-Evaluation. Jedes rule:-, test:-, manual:-, integration:- und external:-Criterion wird gegen den analysierten Code, die Test-Bindings und die Integration-Versionen evaluiert, über dieselben Evaluatoren, die codecharter req überall sonst verwendet: ein Criterion wird für diesen Befehl nie neu implementiert.

Ohne --with-code bleiben die reinen Corpus-Prüfungen oben byteidentisch zu heute; die codeabhängigen Prüfungen laufen dann einfach nicht.

Prüfungen

Code	Severity	Gemeldet wenn
req-anchor-not-found	Fehler	Ein symbol_id-Anchor nennt eine Id, die im analysierten Code-Modell nicht vorkommt.
req-anchor-ambiguous	Fehler	Ein symbol_id-Anchor löst zu mehr als einer Deklaration auf.
req-anchor-file-missing	Fehler	Die Datei eines file+selector-Anchors existiert nicht (oder würde das Repository-Root verlassen).
req-anchor-selector-miss	Warnung	Die Datei eines file+selector-Anchors existiert, aber der Selector trifft nichts darin.
req-anchor-orphaned	Fehler	Ein [Satisfies("...")]-Attribut im Code nennt eine Requirement-Id, die im Corpus nicht existiert.
req-anchor-overlapping-scope	Info	Der transitiv gerechtfertigte Code zweier Requirements überschneidet sich (Co-Retrieval-Scope-Overlap; Stichprobe auf fünf Paare begrenzt).

Diese Codes erscheinen ausschließlich, wenn --with-code übergeben wurde; ein Lauf ohne diese Option meldet sie nie. Das eigene Verdict eines Criteriums (stale, violated, unknown) ist nie einer dieser Diagnostic-Codes — es wird immer über den Verdict-Abschnitt unten gemeldet, unabhängig von --with-code, damit es nie doppelt ausgegeben wird.

Wenn die Analyse fehlschlägt

Kann die Solution/das Projekt gar nicht analysiert werden (kein Projekt gefunden, oder der Analyse-Durchlauf selbst schlägt fehl), stürzt --with-code nie ab und meldet nie fälschlich "hält" — jede codeabhängige Prüfung wird übersprungen, ein Hinweis wird auf stderr geschrieben, der den Grund erklärt, und der Lauf endet mit Exit-Code 3 (außer ein reiner Corpus-Fehler ist ebenfalls aufgetreten, dann gewinnt weiterhin Exit-Code 1 — ein kaputter Corpus ist das handlungsrelevantere Signal). Die reinen Corpus-Prüfungen laufen weiterhin normal und werden normal gemeldet.

Exit-Codes

Code	Bedeutung
0	Keine Diagnostics der Severity Fehler (Warnungen können vorhanden sein).
1	Mindestens eine Diagnostic der Severity Fehler wurde gefunden.
2	Usage-Fehler: ein ungültiger --workspace-Pfad oder ein unbekannter --output-Wert.
3	--with-code wurde übergeben, aber das Code-Modell konnte nicht beschafft werden; jede codeabhängige Prüfung wurde übersprungen (siehe Wenn die Analyse fehlschlägt).
6	Das Lizenz-Gate hat den Lauf abgelehnt.

Ausgabe

Konsolenausgabe (Standard) bei einem Corpus mit Problemen:

Requirement check: .codecharter/req (3 requirements, 5 criteria, 1 anchors)
[ERROR] req-dangling-refines .codecharter/req/REQ-2.req.md: relations.refines references unknown requirement id 'REQ-0'.
[WARN ] req-without-anchor .codecharter/req/REQ-3.req.md: Requirement 'REQ-3' has no traceability anchor.

Found 1 error(s), 1 warning(s).

Bei einem sauberen Corpus:

Requirement corpus is valid: .codecharter/req (3 requirements).

Mit --with-code tragen dieselben Diagnostic-Zeilen die --with-code-Anchor-Codes neben den reinen Corpus-Codes (das eigene stale/violated/unknown-Verdict eines Criteriums ist nie eine dieser Zeilen — siehe Criterion-Verdicts):

Requirement check: .codecharter/req (2 requirements, 3 criteria, 2 anchors)
[ERROR] req-anchor-not-found .codecharter/req/REQ-4.req.md: symbol id 'T:Billing.Invoice' was not found in the code model.

Found 1 error(s), 0 warning(s).

Jeder FilePath in der Ausgabe (Corpus-only oder --with-code) ist workspace-relativ und wird erst beim Rendern der Diagnostic berechnet — nie gegen einen absoluten Pfad gespeichert.

--output json liefert dieselbe Information als ein einzelnes JSON-Objekt (ReqDirectory, die Summary-Zähler und ein Diagnostics-Array mit Severity, Code, FilePath, Line, Column, RequirementId und Message je Eintrag), stabil über mehrere Läufe hinweg, sodass es sauber diffbar ist und sich verlässlich scripten lässt.

Criterion-Verdicts

Unterhalb der Diagnostics (oder der "Corpus ist valide"-Zeile) gibt req check außerdem den pin-basierten Verdict jedes Criteriums aus, dessen Evidenz gerade nicht hält: ein Criterion, das hält, ist keine Zeile pro Lauf wert. Der Verdict vergleicht den Pin jedes Criteriums mit dem Code, Test oder der Version, gegen die es freigegeben wurde, ohne eine Solution zu öffnen oder einen Test auszuführen:

Verdict	Bedeutung
HOLDS	Der Pin ist freigegeben und die gepinnte Evidenz unverändert. Wird nicht ausgegeben.
STALE	Das Criterion wurde freigegeben, aber der gebundene Test, der geankerte Code oder eine Integration-/External-Version hat sich seither geändert: die Freigabe spricht nicht mehr für den aktuellen Stand.
OPEN	Das Criterion trägt gar keinen Pin oder einen unvollständigen.
UNK (Unknown)	Das Criterion lässt sich gerade weder in die eine noch die andere Richtung bewerten: kein Code-Modell, eine mehrdeutige Test-Bindung oder ein nicht auflösbarer Anchor.
VIOL (Violated)	Die mechanische Auswertung eines rule:-Criteriums fand mindestens eine Verletzung. Wird nur erzeugt, wenn --with-code ein Code-Modell beschafft hat — siehe unten.

Ohne --with-code meldet ein rule:-Criterion immer not evaluated here: req check öffnet standardmäßig nie eine Solution, mechanische Rule-Criteria liegen also außerhalb seines Geltungsbereichs. Mit --with-code löst dasselbe beschaffte Code-Modell, das auch die Anchor-Reconciliation antreibt, rule:-Criteria wirklich auf — über dieselbe Rule-Evaluation-Engine, die codecharter analyze verwendet —, sodass ein rule:-Criterion genau wie jede andere Art HOLDS, VIOL oder UNK (eine unbestätigte Analyse-Lücke) melden kann.

Criterion verdicts:
[STALE] REQ-2/AC-1 (Test): TestHashChanged
[OPEN ] REQ-3/AC-1 (Manual): PinMissing

Wenn jedes Criterion hält, gibt req check stattdessen All pinned criteria hold. aus (bzw. No pinned criteria to verify. bei einem leeren Corpus). --output json trägt dieselbe Information als Verdicts-Array (RequirementId, CriterionId, Kind, Verdict, Reason, Expected, Actual) neben Diagnostics.

Einsatz in CI

codecharter req check --with-code --output json > req-check.json

Exit-Code 1 bei jedem Fehler macht das zu einem natürlichen CI-Gate: lasst es neben codecharter analyze laufen, dann scheitert ein kaputter Requirement-Corpus — oder mit --with-code ein kaputter Anchor oder ein Criterion, dessen Freigabe nicht mehr hält — den Build genauso wie eine kaputte Regel-Konfiguration. --with-code braucht das .NET SDK wie codecharter graph/codecharter analyze, weil es die Solution/das Projekt öffnet; die reinen Corpus-Prüfungen brauchen es nicht.

req accept

Gibt ein test:- oder manual:-Acceptance-Criterion frei: berechnet dessen aktuelle Evidenz — den Content-Hash der gebundenen Testmethode für ein test:-Criterion, und/oder den Fingerprint der geankerten Coderegion für beide Arten — und pinnt sie zusammen mit Freigeber und Datum. Das ist ein menschlicher Akt: req accept ist bewusst kein MCP-Tool, damit ein KI-Agent nicht die eigene Arbeit freigeben kann.

Anders als req check analysiert req accept die Solution/das Projekt (es braucht ein Code-Modell, um Evidenz dagegen zu berechnen), dauert also etwas länger und braucht das .NET SDK.

Synopsis

codecharter req accept <req-id> <criterion-selector> [--workspace <pfad>] [--solution <pfad>] [--by <identität>]

Optionen

Option	Default	Bedeutung
req-id	–	Die Requirement-Id, zu der das Criterion gehört, z. B. REQ-12.
criterion-selector	–	Die Criterion-Id, die freigegeben werden soll, z. B. AC-1.
--workspace <pfad>	aktuelles Verzeichnis	Eine Datei oder ein Verzeichnis im Repository, verwendet sowohl zum Auffinden des Requirement-Corpus als auch (sofern --solution nicht gesetzt ist) der zu analysierenden Solution/des Projekts.
--solution <pfad>	automatisch ermittelt	Ein expliziter .sln/.slnx/.csproj-Pfad, falls die automatische Ermittlung den falschen träfe.
--by <identität>	–	Die als approved_by zu pinnende Freigeber-Identität. Siehe Freigeber-Identität unten.
--license <pfad>	–	Pfad zu einer codecharter.license-Datei, wie bei jedem anderen lizenzgeprüften Befehl.

Freigeber-Identität

req accept löst die Freigeber-Identität in dieser Reihenfolge auf und fällt niemals auf den Namen des Betriebssystem-Kontos zurück (der keine sinnvolle Freigeber-Identität ist):

1. --by <identität>
2. Die Umgebungsvariable CODECHARTER_REQ_APPROVER
3. git config user.name

Löst sich keine davon auf, schlägt der Befehl fehl, statt zu raten.

Was gepinnt wird

Bei Erfolg schreibt req accept approved_by, approved_on und den Evidenz-Pin (test_hash bei einem test:-Criterion, fingerprint bei beiden Arten) in das Frontmatter des Criteriums — der Schreibvorgang wird verifiziert, indem die Datei zurückgelesen wird, bevor Erfolg gemeldet wird; bei einer Abweichung wird der ursprüngliche Inhalt wiederhergestellt. Trug das Criterion zuvor einen Marker acceptance_requested_by/acceptance_requested_on/acceptance_request_note (aus einer vorangegangenen Freigabe-Anfrage), werden diese drei Schlüssel im selben Schreibvorgang entfernt.

Ein rule:-, integration:- oder external:-Criterion wird abgelehnt: diese werden mechanisch erzwungen, automatisch aus integrations.yml gepinnt, oder verzeichnen ihre eigene Verifikation direkt — nie über req accept.

Exit-Codes

Code	Bedeutung
0	Der Pin wurde geschrieben (oder stimmte bereits exakt überein — nichts zu schreiben).
1	Das Criterion wurde nicht freigegeben: eine abgelehnte Art, eine nicht auflösbare Freigeber-Identität, oder die Acceptance-Evidenz ließ sich nicht berechnen (z. B. eine mehrdeutige Test-Bindung, oder nichts, woran ein Fingerprint verankert werden könnte).
2	Usage-Fehler: ein ungültiger --workspace-Pfad, oder die Requirement-/Criterion-Id löst sich nicht auf.
4	Der Pin ließ sich nicht auf die Platte schreiben (I/O-Fehler, oder der Schreibvorgang bestand die Verifikation nicht).
5	Die Solution/das Projekt ließ sich nicht ermitteln oder die Analyse schlug fehl.
6	Das Lizenz-Gate hat den Lauf abgelehnt.

Ausgabe

$ codecharter req accept REQ-12 AC-1 --by alice
Accepted 'REQ-12/AC-1': approved_by=alice, approved_on=2026-09-02, fingerprint=v1:3f7a2c9e1b4d5f60

Bei einem test:-Criterion trägt die Zeile zusätzlich test_hash:

Accepted 'REQ-12/AC-2': approved_by=alice, approved_on=2026-09-02, test_hash=v1:9c1e..., fingerprint=v1:3f7a...

Eine Ablehnung erklärt, warum:

$ codecharter req accept REQ-12 AC-3
Cannot accept 'REQ-12/AC-3': 'rule:' criteria are enforced mechanically by CodeCharter's own graph analysis and are never approved by a human; fix the underlying code, or change the criterion's status to 'open' with a 'blocked_by' note instead.

req coverage

Meldet die Requirement-Corpus-Coverage in beiden Richtungen der Traceability (das vollständige Modell steht unter Requirements-Coverage): pro Requirement ein Rollup (Requirement → Code, hält die Evidenz gerade noch?) und klassifizierte unjustified Methods (Code → Requirement, welche Methoden tragen überhaupt keine [Satisfies]-Rechtfertigung?). Der Befehl ist zuerst ein Report, ein Gate nur bei aktivem Opt-in, siehe Das Gate unten.

Anders als req check hat req coverage kein --with-code-Flag: Code ist der eigentliche Gegenstand des Befehls, deshalb wird die Solution/das Projekt immer analysiert, und ein nicht verfügbares Codemodell ist ein Fehler (Exit 3), nie eine erfundene Prozentzahl.

Synopsis

codecharter req coverage [--workspace <pfad>] [--output console|json] [--no-color]
                          [--git-ref <range>] [--max-tokens <n>] [--write-baseline]

Optionen

Option	Default	Bedeutung
--workspace <pfad>	aktuelles Verzeichnis	Eine Datei oder ein Verzeichnis im Repository, dient sowohl zum Auffinden des Requirement-Corpus als auch der zu analysierenden Solution/des Projekts.
--output console\|json	console	Ausgabeformat.
--no-color	aus	ANSI-Farbcodes in der Konsolenausgabe abschalten.
--git-ref <range>	–	Schränkt die klassifizierten/Rollup-Listen auf diese Git-Range ein (z. B. main..HEAD); jede Summe und jeder Prozentwert bleibt corpus-weit (siehe Diff-Scope).
--max-tokens <n>	unbegrenzt	Ungefähre Payload-Obergrenze für die klassifizierten/Rollup-Listen; ganze Einträge werden vom Ende her entfernt, bis die Schätzung passt. Muss positiv sein, wenn angegeben.
--write-baseline	aus	Schreibt die aktuellen Identitäten unjustified Methods als tolerierte Legacy-Baseline, statt einen Report zu rendern. Nicht kombinierbar mit --git-ref: die Baseline spiegelt immer die ganze Solution. Siehe Das Gate.
--license <pfad>	–	Pfad zu einer codecharter.license-Datei, wie bei jedem anderen lizenzgeprüften Befehl.

Requirement → Code: Rollups

Jedes Criterion eines Requirements wird genau einmal evaluiert (mit demselben IReqPinEvaluator, den req check --with-code verwendet, kein Criterion wird von einem zweiten Evaluator noch einmal geprüft) und zu einem einzigen Worst-of-Verdict aufgerollt, nach dieser festen Rangfolge:

Rang	Verdict	Warum
5 (schlechtest)	violated	Nachweislich gebrochen gegen den aktuellen Code.
4	stale	War einmal erfüllt, aber die gepinnte Evidenz hat sich seitdem geändert, eine aktiv irreführende positive Aussage.
3	unknown	Auswertung konnte sich nicht entscheiden, eine ehrliche Nicht-Antwort, kein Zeichen für Zustand oder Verfall.
2	open	Eine deklarierte Lücke.
1 (best)	holds	Jedes Criterion hält.

Ein Requirement wird nie unverdient grün: eines ohne Criteria, ohne Anchors, oder nur mit unauflösbaren Anchors kann nicht zu holds aufrollen, es rollt zu open mit einem unbound-Grund (no-criteria / no-anchors / anchors-unresolved) auf und wird gesondert gelistet. Der Frontmatter-Key status fließt nie in das Rollup ein; ein Requirement, dessen deklarierter Status vom Rollup abweicht (z. B. status: implemented bei einem Rollup ungleich holds), wird als Status-Divergenz gemeldet, rein zur Sichtbarkeit.

Code → Requirement: klassifizierte Methoden

Jede Methode im analysierten Codemodell fällt in einen von drei disjunkten Buckets, gemeldet als zwei Kopfzahlen, nie als eine einzige mehrdeutige Zahl:

• justified: von mindestens einem Justification-Walk eines Nicht-Infrastructure-Requirements erreicht.
• infrastructure-declared: direkt (nie transitiv) von einem Anchor eines kind: infrastructure-Requirements benannt. Siehe Infrastructure-Exemption.
• unjustified: keines von beidem, weiter klassifiziert als:
  • dead-candidate: kein Caller und kein Dispatch-Ziel, das für den Justification-Walk sichtbar ist. Nie als bewiesen ungenutzt zu verstehen, nur als nicht erreichbar über die sichtbaren Kanten dieses Walks, der Report sagt immer "candidate", nie "dead" allein.
  • undocumented-requirement-candidate: hat sichtbare Caller, aber kein Anchor erreicht sie. Trägt einen nearest_anchored_neighbour-Hinweis (die nächste justified Method innerhalb von vier Hops), der req_draft speist.

justified_percent = justified / total; accounted_percent = (justified + infrastructure_declared) / total. Hat der Corpus überhaupt keine [Satisfies]-Anchors, sind beide 0 mit einem expliziten Hinweis und ohne klassifizierte Liste, ein Repository, das Anchoring noch nicht eingeführt hat, soll keine Wand aus "dead candidates" bekommen.

Diff-Scope

--git-ref <range> schränkt die klassifizierte Methoden- und die Rollup-Liste auf das ein, was der Diff berührt; jede Summe und jeder Prozentwert, einschließlich justified_percent/accounted_percent, bleibt corpus-weit, dasselbe Ehrlichkeitsmuster, das graph_hubs für sein eigenes scope verwendet. Nützlich im Edit-Loop: "was hat diese Änderung eingeführt oder unjustified gelassen", ohne den Blick auf die ganze Codebase zu verlieren.

Das Gate

req coverage meldet immer; gaten (Exit ungleich 0 bei einer neuen unjustified Method) tut es nur, wenn req.coverage.gate.enabled: true in .codecharter/config.yml gesetzt ist, der Default ist false. Dasselbe Tolerated-Legacy-Ratchet-Muster wie bei der Findings-Baseline:

1. Einmalig codecharter req coverage --write-baseline ausführen, um die Identität jeder aktuell unjustified Method nach .codecharter/req/coverage-baseline.json zu schreiben (oder an den unter req.coverage.baseline-path konfigurierten Pfad).
2. Ab dann rendert eine bereits in der Baseline stehende Method als tolerated und lässt den Lauf nie fehlschlagen; eine neue unjustified Method, also eine, die nach dem Schreiben der Baseline hinzukam, rendert als new und beendet den Lauf, sobald das Gate aktiv ist, mit Exit 2.

Die Baseline wird nur von Hand kleiner (erneutes --write-baseline); ein reiner Report-Lauf weitet sie nie aus. Als Identität dient die Roslyn-Deklarations-Id der Methode (mit Fallback auf einen Graph-Key, wenn der Compiler keine erzeugt hat), ein Rename macht einen Baseline-Eintrag also absichtlich ungültig, dasselbe Prinzip wie bei der Findings-Baseline und den Edge-Ids von req_acknowledge.

# .codecharter/config.yml
req:
  coverage:
    gate:
      enabled: true
    baseline-path: .codecharter/req/coverage-baseline.json

Goodhart-Hinweis. [Satisfies]-Attribute sind diff-sichtbar und werden im Review getragen, nicht automatisch abgeleitet, die Metrik ist ein Report, kein Ziel, bis das Gate für das eigene Repository existiert, und selbst dann ratcheted sie nur auf Methoden vorwärts, die bereits einmal reviewt wurden.

Exit-Codes

Code	Bedeutung
0	Der Report wurde gerendert, und das Ratchet-Gate, falls aktiv, hat bestanden.
2	Usage-Fehler (ein ungültiger --workspace-Pfad, ein unbekannter --output-Wert, ein nicht-positives --max-tokens, --write-baseline kombiniert mit --git-ref), oder das Gate ist aktiv und hat eine neue unjustified Method gefunden.
3	Das Codemodell ließ sich nicht ermitteln (kein --with-code-Fallback für diesen Befehl, siehe oben).
6	Das Lizenz-Gate hat den Lauf abgelehnt.

Ausgabe

$ codecharter req coverage
req coverage — scope: solution
  requirements: 12, criteria: 27, anchors: 9 (anchored requirements: 8)
  code: 340 methods — justified 41.18% (140), accounted 46.47% (158 incl. 18 infrastructure), unjustified 182.
By rollup verdict:
  Violated : 1
  Stale    : 0
  Unknown  : 2
  Open     : 3
  Holds    : 6
...
Code coverage (baseline .codecharter/req/coverage-baseline.json: 150 tolerated, 32 new):
[UNDOC] Billing.InvoiceService.ApplyDiscount — src/Billing/InvoiceService.cs:88 [new] nearest: Billing.InvoiceService.Charge (depth 2, req REQ-4)
...

--output json liefert denselben ReqCoverageReport, den auch das MCP-Tool req_coverage zurückgibt (siehe req_coverage), ein Aggregator, zwei Renderer, damit die Zahlen zwischen CLI und MCP-Oberfläche nie auseinanderlaufen können.

CI-Nutzung

codecharter req coverage --output json > req-coverage.json

Standardmäßig nur Report (Exit 0, unabhängig davon, wie viel unjustified ist, außer das Gate ist aktiv); in die CI einbinden, sobald das Ratchet durchgesetzt werden soll, oder als Metrik stehen lassen, die anderes Tooling aus der JSON-Ausgabe liest.