acceptance-matrix

Turn the source promises into a testable agreement: state the intended outcome, split it into atomic requirements, and say how each one will be checked.

This skill plans acceptance. It does not implement, verify, or publish. New matrices contain evidence plans, not completed verification verdicts.

Build the matrix

1. Read the source and any applicable parent contract. If no source contract can be established, report that gap and stop.
2. Extract every material promise: behavior, negative requirements, state changes, data preservation, authorization, operational limits, and necessary invariants. Do not promote implementation preferences or speculative edge cases.
3. Make each row one observable claim that a concrete counterexample could falsify. Preserve source references and stable IDs; keep input variations in boundaries.
4. Record relevant boundaries such as empty/one/many, retries, restart, auth, concurrency, and operational failure when the source or code path supports them.
5. Inspect the public interface, existing tests, constraints, and configured commands before proposing evidence. If no credible evidence path exists, say so.