grahama1970/acceptance-contract

acceptance-contract은(는) 무엇을 하나요?

브리프, 티켓, 이메일, README, ZIP 번들 또는 증거 패킷을 실행 가능한 승인 기준으로 변환해야 하는 경우, 구현 전에 이를 사용하세요.

구현 작업의 첫 번째 명령:

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

ensure는 기계적 가드입니다. 기존 acceptance_bundle.json의 유효성을 검증하고, 없을 경우 자동 추출하며, 제공된 소스 번들이 동결된 계약이 작성된 이후 변경된 경우 오류와 함께 실패합니다. JSON 출력에는 percent, checks, outstanding, next_steps를 포함하는 acceptance_contract.progress.v1 미터가 포함됩니다. ensure가 status=PASS를 반환하고 진행 미터가 남은 작업을 표시할 때까지는 브리프를 기반으로 구현하지 마세요.

클라이언트 브리프, ZIP 번들 또는 의도적으로 준비된 사양 디렉토리를 입력으로 전달하세요. CLI는 기본적으로 리포지토리 루트를 거부하므로 구현 파일이 조용히 승인 소스가 될 수 없습니다. 사람이 명시적으로 리포지토리 전체 계약을 요청하는 경우에만 --allow-repo를 사용하세요.

고위험 클라이언트 브리프의 경우, 구현 전에 브리프/ZIP과 acceptance_bundle.json에 대해 2차 $ask 라운드테이블 검토를 실행하세요. 가능한 경우 WebGPT를 검토자 중 하나로 포함하세요. 명확하게 질문하세요: "이 계약 요구사항이 올바른가요? 놓친 것이 있나요?" 검토자는 동결된 계약에서 누락된 클라이언트 의무사항(특히 표현 클래스, 타입화된 값, 경계 조건, 실격 처리 실패 모드)이 없는지 확인해야 합니다. 검토는 조언적 증거이며, 결정적 게이트는 여전히 PASS/FAIL을 결정합니다. oai-trial 검토 결과, 타입화된 스칼라 커버리지는 표준 동치(정규화된 정책 문자열, 숫자 전용 숫자 스칼라, 10진수 형식, 과학적 표기법, SQLite 숫자 값)도 필요하다는 것이 밝혀졌습니다.

기능

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

출력:

• acceptance_bundle.json — pydantic으로 검증된 진실 공급원
• acceptance_report.json — create_report.report.v1 JSON
• acceptance_report.md — $create-report를 통해 렌더링됨
• IMMUTABLE_GOAL.draft.md — 목표 텍스트 초안 또는 수정 제안

명령:

• extract는 항상 제공된 소스로부터 새로운 초안 번들/보고서를 작성합니다.
• ensure는 동결된 번들의 유효성을 검증하거나 생성하며, 오래된 소스 해시를 거부합니다.
• validate는 기존 acceptance_bundle.json의 유효성만 검증하고 진행 미터를 출력합니다.
• status는 기존 acceptance_bundle.json을 읽고 기계 판독 가능한 진행 미터만 출력합니다.

목표 정책

기본 동작은 초안 작성, 변형 금지입니다.

• --goal-mode create는 새로운 불변 목표 초안을 작성합니다.
• --goal-mode amend는 수정 제안을 작성하며, 조용히 편집하지 않습니다.
• --goal-mode none은 목표 텍스트 없이 요구사항을 추출합니다.

실제 불변 목표는 사람의 승인 후에만 생성 또는 수정되어야 합니다. 이 규칙은 oai-trial이 구현에 의해 정의된 테스트가 클라이언트 브리프를 대신했을 때 실패했기 때문에 존재합니다.

경계

이 스킬은 제공된 로컬 파일에서 명확하고 소스에 기반한 요구사항을 추출합니다. 소스 번들이 모호한 경우 추출된 계약이 완전하다고 주장하지 않습니다. 모호함은 open_questions[]와 Needs Changes 보고서가 됩니다. 기본적으로 리포지토리 루트를 거부합니다. oai-trial이 코드 형태의 검사가 전달된 브리프를 대신했을 때 실패했기 때문입니다.

Battle의 경우, 결과 acceptance_bundle.json을 경기장의 acceptance_floor로 전달하고 각 acceptance_cases[].id를 Battle 캠페인 프로필의 required_case_ids에 있는 하나 이상의 생성기 케이스 ID에 매핑하세요. 매핑된 케이스는 퍼즈 또는 계약 외 공격이 인정되기 전에 통과해야 하는 계약 기준입니다. Battle이 요구사항을 발명하게 하지 마세요.