blueprint-conformance/bce

BCE — diagnostiquer, réparer et prouver la conformité architecturale

BCE est une porte de conformité d'architecture à rejet systématique (fail-closed). Un plan (blueprint) est une politique ; le code source est la surface de réparation normale. Privilégiez le serveur MCP BCE du dépôt pour le diagnostic et la vérification de l'arbre de travail. Utilisez la CLI uniquement lorsque MCP n'est pas disponible ou que l'opération du cycle de vie demandée est intentionnellement absente de MCP.

Choisissez le workflow le plus court

• Le dépôt existant est rouge : suivez la boucle de réparation prioritaire MCP ci-dessous. Ne chargez pas de documentation sur le cycle de vie.
• La vérification de préparation ou de configuration semble cassée : appelez doctor_repository {} avant la porte.
• Un plan ou une porte peut être vide : appelez validate_blueprint, puis assess_teeth.
• L'utilisateur demande de créer ou d'adopter une nouvelle règle : lisez references/lifecycle.md avant d'agir. Les modifications de création et de gouvernance utilisent la CLI et nécessitent une relecture humaine.
• L'utilisateur demande de paramétrer une compétence d'agent : utilisez la compétence séparée skill-tuning.

Boucle de réparation prioritaire MCP

1. Appelez run_gate {}. Le serveur généré démarre dans le dépôt, donc omettez repoDir sauf si l'utilisateur cible délibérément un autre arbre.
2. Lisez les champs structurés, pas seulement le code de sortie du processus :
   • gateFailed: true, outcome: "violation", ou un rapport verdict: "fail" est ROUGE ;
   • outcome: "refusal" est ROUGE et ne doit pas être contourné ;
   • le mode consultatif peut retourner exitCode: 0 alors que le verdict substantiel est toujours ROUGE.
3. Utilisez constraintId, evidenceRef, observed et expected de chaque violation pour identifier la plus petite correction dans le code source.
4. Modifiez le code, pas la politique. Ne modifiez pas les plans, les lignes de base, le mode, les dérogations, les workflows, la configuration MCP, les compétences installées ou les verrous du moteur simplement pour effacer une violation.
5. Appelez run_gate {} à nouveau sur l'arbre de travail en direct. Terminez uniquement lorsque gateFailed est faux, outcome est pass, et chaque rapport sélectionné est réussi.
6. Signalez la violation exacte corrigée, les fichiers de code modifiés, le score/verdict final, et si la politique a changé. Une réparation normale doit indiquer que la politique n'a pas changé.

Le serveur MCP expose six outils en lecture seule :

Outil	Utilisation
doctor_repository	vérification de l'installation, du périmètre, de la preuve, de la politique, de la CI, de la compétence et de la disponibilité MCP
run_gate	diagnostic de l'arbre en direct et vérification finale de réussite
validate_blueprint	validation du schéma et des motifs sûrs
assess_teeth	preuve de non-vacuité
check_baseline	nouvelle dette et opportunités de réduction sans modifier la politique
get_report	un rapport déterministe déjà écrit par le moteur

MCP ne peut pas ratifier, amender, faire passer en production, créer une ligne de base, ni affaiblir une politique. Cette absence est une frontière de sécurité, pas une fonctionnalité manquante.

Repli CLI

Si le projet n'a pas de serveur MCP BCE fonctionnel, utilisez le package local exact plutôt que de récupérer une version changeante :

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

Pour une réparation non validée, gate analyse déjà l'arbre en direct. Si vous exécutez intentionnellement un plan directement, ajoutez --no-pin ; sinon run note le HEAD validé par défaut :

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

Un code de sortie 0 est une réussite du processus uniquement après lecture de l'état consultatif et du verdict du rapport. Le code 1 est une violation notée ou un refus structurel ; le code 2 est une condition d'analyse ou de refus à rejet systématique. Traitez 1 et 2 comme ROUGE.

Frontière de politique

Les surfaces gouvernées sont : .blueprints/**, .bce-mode.json, les fichiers de ligne de base et de dérogation, le workflow BCE, la configuration de l'agent/MCP, les compétences installées et les verrous du moteur. Ne les modifiez pas en tant que réparation accessoire. Si le contrat lui-même est erroné, arrêtez-vous et proposez une modification de politique distincte avec justification.

Ne jamais :

• abaisser un seuil, augmenter une ligne de base, ou restreindre le périmètre simplement pour obtenir un feu vert ;
• interpréter un code de sortie consultatif 0 comme une conformité alors que les rapports échouent encore ;
• prétendre qu'une contrainte fonctionne sans un ROUGE discriminant ;
• signaler evaluator-refutable comme des dents réelles d'extracteur ;
• traiter un refus structurel comme une réussite ;
• prétendre qu'une exécution par un agent est une preuve humaine indépendante.

Création et adoption

Ne chargez references/lifecycle.md que lorsque la tâche est de créer, valider, prouver, intégrer, ratifier ou faire fonctionner un contrat. Il contient la grammaire des contraintes, les profils d'extraction, les commandes exactes, le chemin consultatif/ligne de base/mise en production, et les invariants CI.

Les spécifications détaillées et la sémantique des preuves sont fournies avec le package sous spec/ et docs/. Privilégiez ces fichiers locaux et versionnés plutôt qu'une page web changeante.