BCE — diagnosticar, reparar y demostrar conformidad arquitectón…

BCE — diagnosticar, reparar y demostrar conformidad arquitectónica

BCE es una compuerta de conformidad arquitectónica de cierre forzoso. Un plano es política; el código fuente es la superficie de reparación normal. Prefiere el servidor MCP de BCE del repositorio para diagnóstico y verificación del árbol de trabajo. Usa la CLI solo cuando MCP no esté disponible o la operación del ciclo de vida solicitada esté intencionalmente ausente de MCP.

Elige el flujo de trabajo más corto

• El repositorio existente está en rojo: sigue el bucle de reparación MCP primero a continuación. No cargues material de creación del ciclo de vida.
• La preparación o configuración parece rota: llama a doctor_repository {} antes de la compuerta.
• Un plano o compuerta puede ser vacuo: llama a validate_blueprint, luego a assess_teeth.
• El usuario solicita crear o adoptar una nueva regla: lee references/lifecycle.md antes de actuar. Los cambios de creación y gobierno usan la CLI y requieren revisión humana.
• El usuario solicita ajustar una habilidad de agente: usa la habilidad separada skill-tuning.

Bucle de reparación MCP primero

1. Llama a run_gate {}. El servidor generado se inicia en el repositorio, así que omite repoDir a menos que el usuario apunte deliberadamente a otro árbol.
2. Lee los campos estructurados, no solo la salida del proceso:
   • gateFailed: true, outcome: "violation", o un informe verdict: "fail" es ROJO;
   • outcome: "refusal" es ROJO y no debe ser evitado;
   • el modo consultivo puede devolver exitCode: 0 mientras el veredicto sustancial sigue siendo ROJO.
3. Usa el constraintId, evidenceRef, observed y expected de cada violación para identificar la corrección más pequeña en el código fuente.
4. Cambia código, no política. No edites planos, líneas base, modo, exenciones, flujos de trabajo, configuración de MCP, habilidades instaladas o fijaciones del motor solo para limpiar una violación.
5. Vuelve a llamar a run_gate {} contra el árbol de trabajo activo. Termina solo cuando gateFailed sea falso, outcome sea pass, y cada informe seleccionado pase.
6. Reporta la violación exacta corregida, los archivos de código modificados, la puntuación/veredicto final, y si la política cambió. Una reparación normal debe decir que la política no cambió.

El servidor MCP expone seis herramientas de solo lectura:

Herramienta	Úsala para
doctor_repository	preparación de instalación, alcance, prueba, política, CI, habilidad y MCP
run_gate	diagnóstico del árbol vivo y verificación final
validate_blueprint	validación de esquema y patrones seguros
assess_teeth	evidencia de no vacuidad
check_baseline	nueva deuda y oportunidades de reducción sin cambiar política
get_report	un informe determinista ya escrito por el motor

MCP no puede ratificar, modificar, graduar, crear una línea base o debilitar la política. Esa ausencia es un límite de seguridad, no una funcionalidad faltante.

Alternativa CLI

Si el proyecto no tiene un servidor MCP de BCE funcional, usa el paquete local exacto en lugar de obtener una versión cambiante:

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

Para una reparación no confirmada, gate ya escanea el árbol vivo. Si ejecutas intencionalmente un plano directamente, añade --no-pin; de lo contrario, run califica el HEAD confirmado por defecto:

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

El código de salida 0 es una aprobación de proceso solo después de leer el estado consultivo y el veredicto del informe. El código de salida 1 es una violación calificada o rechazo estructural; el código de salida 2 es una condición de escaneo/rechazo de cierre forzoso. Trata 1 y 2 como ROJO.

Límite de política

Las siguientes son superficies gobernadas: .blueprints/**, .bce-mode.json, archivos de línea base y exención, el flujo de trabajo de BCE, la configuración del agente/MCP, las habilidades instaladas y las fijaciones del motor. No cambies una como reparación incidental. Si el contrato en sí es incorrecto, detente y propón un cambio de política revisado por separado con justificación.

Nunca:

• bajes un umbral, aumentes una línea base o reduzcas el alcance solo para obtener verde;
• interpretes la salida consultiva 0 como conformidad cuando los informes aún fallan;
• claims que una restricción funciona sin un ROJO discriminatorio;
• reports evaluator-refutable como dientes reales del extractor;
• trates un rechazo estructural como aprobación;
• claims que una ejecución operada por un agente es evidencia independiente humana.

Creación y adopción

Solo carga references/lifecycle.md cuando la tarea sea crear, validar, probar, incorporar, ratificar u operar un contrato. Contiene la gramática de restricciones, perfiles de extracción, comandos exactos, ruta consultiva/línea base/graduación e invariantes de CI.

La especificación detallada y la semántica de evidencia se incluyen con el paquete en spec/ y docs/. Prefiere esos archivos locales y con versión emparejada sobre una página web cambiante.