grahama1970/contrato-de-aceptacion

contrato-de-aceptación

Úsalo antes de la implementación cuando un resumen, ticket, correo electrónico, README, paquete zip o carpeta de evidencia necesite convertirse en criterios de aceptación ejecutables.

Primer comando para el trabajo de implementación:

skills/acceptance-contract/run.sh ensure <zip|directorio|archivo> \
  --out /tmp/contrato-de-aceptacion \
  --project-name oai-trial \
  --goal-mode create

ensure es el guardián mecánico: valida un acceptance_bundle.json existente, lo extrae automáticamente si falta y falla cuando el paquete fuente suministrado ha cambiado desde que se escribió el contrato congelado. Su recibo JSON incluye un medidor acceptance_contract.progress.v1 con percent, checks, outstanding y next_steps. No implementes a partir de un resumen hasta que ensure devuelva status=PASS y el medidor de progreso indique lo que queda.

Pasa el resumen del cliente, paquete zip o directorio de especificaciones deliberadamente preparado como entrada. La CLI rechaza las raíces de repositorio por defecto para que los archivos de implementación no puedan convertirse silenciosamente en la fuente de aceptación. Usa --allow-repo solo cuando el humano solicite explícitamente un contrato para todo el repositorio.

Para resúmenes de cliente de alto riesgo, ejecuta una revisión de segunda línea $ask en el resumen/zip más acceptance_bundle.json antes de la implementación. Incluye WebGPT como revisor cuando esté disponible. Pregunta claramente: "¿Son correctos estos requisitos del contrato, y hemos omitido algo?". Solicita a los revisores que verifiquen si falta alguna obligación del cliente en el contrato congelado, especialmente clases de representación, valores tipificados, condiciones de contorno y modos de fallo descalificantes. La revisión es evidencia consultiva; las puertas deterministas siguen siendo las dueñas de PASS/FAIL. La revisión de oai-trial encontró que la cobertura escalar tipificada también debe requerir equivalencia canónica: cadenas de política formateadas, escalares numéricos solo dígitos, formas decimales, notación científica y valores numéricos de SQLite no pueden ser universos de aceptación separados.

Qué hace

skills/acceptance-contract/run.sh extract <zip|directorio|archivo> \
  --out /tmp/contrato-de-aceptacion \
  --project-name oai-trial \
  --goal-mode create

Salidas:

• acceptance_bundle.json — fuente de verdad validada por pydantic
• acceptance_report.json — JSON create_report.report.v1
• acceptance_report.md — renderizado a través de $create-report
• IMMUTABLE_GOAL.draft.md — texto de borrador de objetivo o propuesta de modificación

Comandos:

• extract siempre escribe un nuevo paquete/informe borrador a partir de la fuente suministrada.
• ensure valida o crea el paquete congelado y rechaza hashes de fuente obsoletos.
• validate valida solo un acceptance_bundle.json existente e imprime el medidor de progreso.
• status lee un acceptance_bundle.json existente e imprime solo el medidor de progreso legible por máquina.

Política de objetivo

El comportamiento predeterminado es borrador, no mutar.

• --goal-mode create escribe un nuevo borrador de objetivo inmutable.
• --goal-mode amend escribe una propuesta de modificación, no una edición silenciosa.
• --goal-mode none extrae requisitos sin texto de objetivo.

Un objetivo inmutable real debe crearse o modificarse solo después de la aprobación humana. Esa regla existe porque oai-trial falló cuando pruebas definidas por la implementación sustituyeron al resumen del cliente.

Límite

Esta habilidad extrae requisitos claros y respaldados por la fuente de archivos locales suministrados. No afirma que el contrato extraído esté completo cuando el paquete fuente es ambiguo. La ambigüedad se convierte en open_questions[] y un informe de Necesita Cambios. Rechaza raíces de repositorio por defecto porque oai-trial falló cuando comprobaciones con forma de código sustituyeron al resumen entregado.

Para Battle, pasa el acceptance_bundle.json resultante como el acceptance_floor de la arena y mapea cada acceptance_cases[].id a uno o más ids de casos generadores en required_case_ids del perfil de campaña de Battle. Esos casos mapeados son el piso del contrato que debe pasar antes de que los ataques de fuzzing o más allá del contrato puedan ser acreditados. No hagas que Battle invente los requisitos.