acceptance-contract

Turn source promises into a candidate-independent acceptance contract. This skill plans acceptance. It does not implement, verify, or publish.

Before planning, read the acceptance contract protocol. It defines the spec envelope, revision rules, evidence terms, and handoffs.

Build the contract

1. Resolve the canonical contract location using the protocol's durable handoff convention. Read the source, existing contract, pending amendments, and applicable parent contract. If the source cannot be established, report the gap and stop.
2. Reconcile existing acceptance criteria, including GitHub checkboxes, with the contract. Extract every material promise and necessary invariant. Keep source references so each criterion maps to its requirements without duplication.
3. Give each independently falsifiable promise one row. Split compound criteria, merge duplicate claims, and record ID mappings when restructuring existing rows. Preserve existing IDs across reruns and allocate unused IDs for new rows.
4. Record boundaries supported by the source or required outcome: empty inputs, retries, restart, authorization, concurrency, or partial failure where relevant. Keep speculative behavior outside the contract.
5. Inspect agreed specification and TDD seams, public interfaces, existing tests, constraints, and configured commands. Reuse those seams and name an independent oracle and concrete evidence path for each row. Mark missing credible paths gap and explain what is missing.
6. Apply the protocol's revision rules. Record authorized material changes and retain prior revisions. Surface unresolved changes as questions rather than silently altering the agreement.

Audit and hand off

Account for every source promise and justify every added invariant by the outcome that requires it. Trace the workflow through completion, including necessary state, persistence, and failure behavior. Check both missing substance and unrequested scope. Keep implementation preferences out of requirements.

Return the contract using the shape below. Use only planned or gap for plan state. Move any legacy proof verdicts into a separately identified proof report with their original candidate and context, or flag missing provenance as a gap.

Include a storage handoff naming the canonical destination and revision, and whether saving remains pending. The invoking workflow saves the returned text and confirms retrieval as the protocol requires; planning does not publish it.

Output

# Acceptance contract: <source>

Contract revision: v1
Source: <issue/spec and precise criterion references>
Parent contract: <reference and revision, or None>

Intended outcome: <observable user or operator outcome>

## Acceptance matrix

| ID | Source | Requirement | Boundaries / counterexamples | Seam | Oracle | Planned evidence | Plan state |
|---|---|---|---|---|---|---|---|
| R1 | <criterion> | <one observable promise> | <what would falsify it> | <agreed public interface> | <independent expected result> | <named case and assertion, invariant check, or exact command> | planned |

## Unresolved gaps

- <missing evidence path, seam, or oracle, or None>

## Open questions

- <unresolved product or design decision, or None>

## Out of scope

- <excluded nearby concern, or None>

## Change notes

- <revision, affected IDs, old/new agreement and authorization; ID mappings, or Initial contract>

## Implementation handoff

Implement the smallest complete solution inside the spec envelope.
Preserve requirement IDs and promised outcomes.

## Proof handoff

Evaluate every requirement against this contract revision and one fixed candidate.
Record actual evidence and verdicts in a separate proof report.