blueprint-conformance/bce

BCE — Architekturkonformität diagnostizieren, reparieren und nachweisen

BCE ist ein fehlschließendes Architektur-Konformitäts-Gate. Ein Blueprint ist eine Richtlinie; Quellcode ist die normale Reparaturoberfläche. Bevorzugen Sie den BCE MCP-Server des Repositorys für Diagnose und Überprüfung des Arbeitsverzeichnisses. Verwenden Sie das CLI nur, wenn MCP nicht verfügbar ist oder die angeforderte Lebenszyklusoperation absichtlich nicht im MCP enthalten ist.

Wählen Sie den kürzesten Workflow

• Vorhandenes Repository ist rot: Befolgen Sie die unten stehende MCP-first-Reparaturschleife. Laden Sie kein Lebenszyklus-Authoring-Material.
• Bereitschaft oder Einrichtung scheint defekt: Rufen Sie doctor_repository {} vor dem Gate auf.
• Ein Blueprint oder Gate könnte leerlaufen (vacuously true): Rufen Sie validate_blueprint auf, dann assess_teeth.
• Der Benutzer bittet um Erstellung oder Übernahme einer neuen Regel: Lesen Sie references/lifecycle.md, bevor Sie handeln. Authoring- und Governance-Änderungen verwenden das CLI und erfordern menschliche Überprüfung.
• Der Benutzer bittet um Anpassung eines Agent Skills: Verwenden Sie den separaten Skill skill-tuning.

MCP-first-Reparaturschleife

1. Rufen Sie run_gate {} auf. Der generierte Server startet im Repository, lassen Sie daher repoDir weg, es sei denn, der Benutzer zielt bewusst auf einen anderen Baum ab.
2. Lesen Sie die strukturierten Felder, nicht nur den Prozess-Exit-Code:
   • gateFailed: true, outcome: "violation" oder ein Bericht verdict: "fail" ist ROT;
   • outcome: "refusal" ist ROT und darf nicht umgangen werden;
   • Der Advisory-Modus kann exitCode: 0 zurückgeben, während das inhaltliche Urteil immer noch ROT ist.
3. Verwenden Sie die constraintId, evidenceRef, observed und expected jeder Verletzung, um die kleinste Quellcode-Korrektur zu identifizieren.
4. Ändern Sie Code, nicht die Richtlinie. Bearbeiten Sie keine Blueprints, Baselines, Modus, Waiver, Workflows, MCP-Konfiguration, installierte Skills oder Engine-Pins, nur um eine Verletzung zu beseitigen.
5. Rufen Sie run_gate {} erneut gegen den live-Arbeitsbaum auf. Beenden Sie erst, wenn gateFailed falsch ist, outcome pass ist und jeder ausgewählte Bericht bestanden hat.
6. Melden Sie die genaue behobene Verletzung, die geänderten Codedateien, die endgültige Punktzahl/das Urteil und ob sich die Richtlinie geändert hat. Eine normale Reparatur muss angeben, dass sich die Richtlinie nicht geändert hat.

Der MCP-Server stellt sechs schreibgeschützte Werkzeuge bereit:

Werkzeug	Verwenden Sie es für
doctor_repository	Installation, Umfang, Nachweis, Richtlinie, CI, Skill und MCP-Bereitschaft
run_gate	Live-Baum-Diagnose und die finale Erledigungsprüfung
validate_blueprint	Schema- und Sicherheitsmuster-Validierung
assess_teeth	Nachweis der Nicht-Leerheit (non-vacuity evidence)
check_baseline	Neue Schulden und Schrumpfmöglichkeiten ohne Richtlinienänderung
get_report	Einen bereits vom Motor geschriebenen deterministischen Bericht

MCP kann keine Richtlinien ratifizieren, ändern, graduieren, eine Baseline erstellen oder Richtlinien abschwächen. Diese Abwesenheit ist eine Sicherheitsgrenze, keine fehlende Funktionalität.

CLI-Fallback

Wenn das Projekt keinen funktionierenden BCE MCP-Server hat, verwenden Sie das exakte lokale Paket anstatt eine sich ändernde Version zu laden:

bce gate --repo . --extractor ast --all

Für eine nicht committete Reparatur scannt gate bereits den live-Baum. Wenn Sie absichtlich einen einzelnen Blueprint direkt ausführen, fügen Sie --no-pin hinzu; andernfalls bewertet run standardmäßig den committeten HEAD:

bce run --blueprint <path> --ct-repo . --no-pin --extractor ast --out compliance-report.json

Exit-Code 0 ist nur nach Prüfung des Advisory-Status und des Berichtsurteils ein Prozess-Bestehen. Exit-Code 1 ist eine bewertete Verletzung oder strukturelle Verweigerung; Exit-Code 2 ist ein fehlschließender Scan-/Verweigerungszustand. Behandeln Sie 1 und 2 als ROT.

Richtliniengrenze

Die folgenden Oberflächen sind reglementiert: .blueprints/**, .bce-mode.json, Baseline- und Waiver-Dateien, der BCE-Workflow, Agenten-/MCP-Konfiguration, installierte Skills und Engine-Pins. Ändern Sie keine davon als beiläufige Reparatur. Wenn der Vertrag selbst falsch ist, stoppen Sie und schlagen Sie eine separate, überprüfte Richtlinienänderung mit Begründung vor.

Niemals:

• einen Schwellenwert senken, eine Baseline vergrößern oder den Umfang verkleinern, nur um Grün zu erhalten;
• Advisory-Exit-Code 0 als Konformität interpretieren, wenn Berichte immer noch fehlschlagen;
• behaupten, eine Einschränkung funktioniere ohne ein unterscheidendes ROT;
• evaluator-refutable als extraktor-reale Zähne melden;
• eine strukturelle Verweigerung als Bestehen behandeln;
• behaupten, ein agentenbetriebener Durchlauf sei unabhängiger menschlicher Nachweis.

Authoring und Übernahme

Laden Sie references/lifecycle.md nur, wenn die Aufgabe darin besteht, einen Vertrag zu erstellen, zu validieren, nachzuweisen, einzubinden, zu ratifizieren oder zu betreiben. Es enthält die Einschränkungsgrammatik, Extraktionsprofile, genaue Befehle, Advisory-/Baseline-/Graduierungspfad und CI-Invarianten.

Die detaillierte Spezifikation und Beweissemantik werden mit dem Paket unter spec/ und docs/ ausgeliefert. Bevorzugen Sie diese lokalen, versionsabgestimmten Dateien gegenüber einer sich ändernden Webseite.