aceitação-contrato

contrato de aceitação

Use isto antes da implementação quando um briefing, ticket, e-mail, README, pacote zip ou pacote de evidências precisar se tornar critérios de aceitação executáveis.

Primeiro comando para trabalho de implementação:

skills/acceptance-contract/run.sh ensure <zip|diretorio|arquivo> \
  --out /tmp/acceptance-contract \
  --project-name oai-trial \
  --goal-mode create

ensure é o guardião mecânico: ele valida um pacote acceptance_bundle.json existente, extrai automaticamente um quando ausente e falha de forma segura quando o pacote fonte fornecido mudou desde que o contrato congelado foi escrito. Seu recibo JSON inclui um medidor acceptance_contract.progress.v1 com percent, checks, outstanding, e next_steps. Não implemente a partir de um briefing até que ensure retorne status=PASS e o medidor de progresso indique o que resta.

Passe o briefing do cliente, pacote zip ou diretório de especificação deliberadamente preparado como entrada. A CLI recusa raízes de repositório por padrão para que arquivos de implementação não possam se tornar silenciosamente a fonte de aceitação. Use --allow-repo apenas quando o humano solicitar explicitamente um contrato para todo o repositório.

Para briefings de clientes de alto risco, execute uma revisão de segunda linha com $ask no briefing/zip mais o acceptance_bundle.json antes da implementação. Inclua WebGPT como um revisor quando disponível. Pergunte claramente: "Estes requisitos do contrato estão corretos, e perdemos algo?" Exija que os revisores verifiquem se alguma obrigação do cliente está faltando no contrato congelado, especialmente classes de representação, valores tipados, condições de contorno e modos de falha desqualificantes. A revisão é evidência consultiva; portões determinísticos ainda possuem PASS/FAIL. A revisão do oai-trial descobriu que a cobertura escalar tipada também deve exigir equivalência canônica: strings de política formatadas, escalares numéricos apenas com dígitos, formas decimais, notação científica e valores numéricos do SQLite não podem ser universos de aceitação separados.

O que faz

skills/acceptance-contract/run.sh extract <zip|diretorio|arquivo> \
  --out /tmp/acceptance-contract \
  --project-name oai-trial \
  --goal-mode create

Saídas:

• acceptance_bundle.json — verdade absoluta validada por pydantic
• acceptance_report.json — JSON create_report.report.v1
• acceptance_report.md — renderizado através de $create-report
• IMMUTABLE_GOAL.draft.md — texto de rascunho de meta ou proposta de alteração

Comandos:

• extract sempre escreve um novo pacote/relatório rascunho a partir da fonte fornecida.
• ensure valida ou cria o pacote congelado e rejeita hashes de fonte desatualizados.
• validate valida apenas um acceptance_bundle.json existente e imprime o medidor de progresso.
• status lê um acceptance_bundle.json existente e imprime apenas o medidor de progresso legível por máquina.

Política de meta

O comportamento padrão é rascunho, não mutar.

• --goal-mode create escreve um novo rascunho de meta imutável.
• --goal-mode amend escreve uma proposta de alteração, não uma edição silenciosa.
• --goal-mode none extrai requisitos sem texto de meta.

Uma meta imutável real deve ser criada ou alterada somente após aprovação humana. Essa regra existe porque o oai-trial falhou quando testes definidos pela implementação substituíram o briefing do cliente.

Limite

Este skill extrai requisitos claros e baseados na fonte a partir de arquivos locais fornecidos. Ele não afirma que o contrato extraído está completo quando o pacote fonte é ambíguo. Ambiguidade se torna open_questions[] e um relatório de Necessita Alterações. Ele recusa raízes de repositório por padrão porque o oai-trial falhou quando verificações em forma de código substituíram o briefing entregue.

Para Battle, passe o acceptance_bundle.json resultante como o acceptance_floor da arena e mapeie cada acceptance_cases[].id para um ou mais IDs de caso gerador no perfil da campanha Battle, em required_case_ids. Esses casos mapeados são o piso do contrato que deve passar antes que ataques de fuzz ou além do contrato possam ser creditados. Não faça Battle inventar os requisitos.