blueprint-conformance/bce

BCE — diagnosticar, reparar e provar conformidade arquitetural

BCE é uma porta de conformidade arquitetural que fecha com falha. Um blueprint é política; o código-fonte é a superfície normal de reparo. Prefira o servidor MCP do BCE do repositório para diagnóstico e verificação da árvore de trabalho. Use o CLI apenas quando o MCP estiver indisponível ou a operação de ciclo de vida solicitada estiver intencionalmente ausente do MCP.

Escolha o fluxo de trabalho mais curto

• O repositório existente está vermelho: siga o loop de reparo MCP-first abaixo. Não carregue material de autoria de ciclo de vida.
• A prontidão ou configuração parece quebrada: chame doctor_repository {} antes da porta.
• Um blueprint ou porta pode ser vazio: chame validate_blueprint, depois assess_teeth.
• O usuário pede para criar ou adotar uma nova regra: leia references/lifecycle.md antes de agir. Alterações de autoria e governança usam o CLI e exigem revisão humana.
• O usuário pede para ajustar uma Skill de Agente: use a skill separada skill-tuning.

Loop de reparo MCP-first

1. Chame run_gate {}. O servidor gerado inicia no repositório, portanto omita repoDir a menos que o usuário deliberadamente almeje outra árvore.
2. Leia os campos estruturados, não apenas a saída do processo:
   • gateFailed: true, outcome: "violation", ou um relatório verdict: "fail" é VERMELHO;
   • outcome: "refusal" é VERMELHO e não deve ser contornado;
   • modo consultivo pode retornar exitCode: 0 enquanto o veredito substantivo ainda é VERMELHO.
3. Use o constraintId, evidenceRef, observed e expected de cada violação para identificar a menor correção no código-fonte.
4. Altere código, não política. Não edite blueprints, baselines, modo, waivers, fluxos de trabalho, configuração MCP, skills instaladas ou pinos do mecanismo meramente para limpar uma violação.
5. Chame run_gate {} novamente contra a árvore de trabalho ativa. Termine apenas quando gateFailed for falso, outcome for pass e cada relatório selecionado passar.
6. Relate a violação exata corrigida, arquivos de código alterados, pontuação/veredito final e se a política mudou. Um reparo normal deve dizer que a política não mudou.

O servidor MCP expõe seis ferramentas somente leitura:

Ferramenta	Use para
doctor_repository	instalação, escopo, prova, política, CI, skill e prontidão MCP
run_gate	diagnóstico da árvore ativa e verificação final de conclusão
validate_blueprint	validação de esquema e padrões seguros
assess_teeth	evidência de não vacuidade
check_baseline	nova dívida e oportunidades de redução sem alterar política
get_report	um relatório determinístico já escrito pelo mecanismo

O MCP não pode ratificar, alterar, graduar, criar uma baseline ou enfraquecer política. Essa ausência é um limite de segurança, não funcionalidade faltante.

CLI como fallback

Se o projeto não tiver um servidor MCP BCE funcional, use o pacote local exato em vez de buscar uma versão mutável:

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

Para um reparo não commitado, gate já escaneia a árvore ativa. Se você intencionalmente executar um blueprint diretamente, adicione --no-pin; caso contrário, run avalia o HEAD commitado por padrão:

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

Saída 0 é uma aprovação de processo apenas após ler o estado consultivo e o veredito do relatório. Saída 1 é uma violação classificada ou recusa estrutural; saída 2 é uma condição de varredura/recusa com falha fechada. Trate 1 e 2 como VERMELHO.

Limite de política

As seguintes são superfícies governadas: .blueprints/**, .bce-mode.json, arquivos de baseline e waiver, o fluxo de trabalho BCE, configuração de agente/MCP, skills instaladas e pinos do mecanismo. Não altere uma como reparo incidental. Se o contrato em si estiver errado, pare e proponha uma mudança de política revisada separadamente, com justificativa.

Nunca:

• abaixe um limite, aumente uma baseline ou reduza escopo apenas para obter verde;
• interprete saída consultiva 0 como conformidade quando os relatórios ainda falham;
• afirme que uma restrição funciona sem um VERMELHO discriminatório;
• relate evaluator-refutable como dentes reais de extrator;
• trate uma recusa estrutural como aprovação;
• afirme que uma execução operada por agente é evidência humana independente.

Autoria e adoção

Carregue references/lifecycle.md apenas quando a tarefa for criar, validar, provar, integrar, ratificar ou operar um contrato. Ele contém a gramática de restrição, perfis de extração, comandos exatos, caminho consultivo/baseline/graduação e invariantes de CI.

A especificação detalhada e a semântica de evidência acompanham o pacote em spec/ e docs/. Prefira esses arquivos locais e com versão correspondente em vez de uma página web mutável.