acceptance-design

# Acceptance design

Acceptance connects the user's outcome to an observable check. Design it before
implementation, and give the worker the exact contract the reviewer will use.
These are operational instructions, not measured failure-rate claims.

## Define the experiment

1. Name the outcome, affected boundary and scope. Check the command, loader,
   artifact or user flow actually affected; a helper test alone may miss the
   boundary defect. Identify what the check deliberately leaves untested.
2. Name the target host or platform, runner, dependencies, permissions and
   inputs. Confirm required source files exist in the delivered base and
   travel with the brief. Distinguish existing input paths from files to create.
3. Record the exact command, expected observable result and evidence location.
   Test that it launches on the target environment before dispatch. Prefer a
   repository script when shell quoting or setup would make the command fragile.
   Do not depend on an undocumented interpreter or hidden login state.
4. Scope every planned write, including tests and generated artifacts. Make
   predecessors available in the delivered base, or route the task to a
   checkout that contains them. A named branch is not necessarily accessible.

## Separate change from preservation

- For a defect or new behavior, demonstrate that the check rejects the old
  behavior for the intended reason when feasible. A missing tool or test path
  is not that demonstration. If a baseline run is unavailable, state the gap.
- For preservation, establish the existing behavior and require it to remain
  valid. Do not demand a failing baseline for behavior meant to stay unchanged.
- Vary meaningful inputs and inspect outputs where the contract depends on
  them. A mocked success, repeated implementation constant or file's existence
  may prove less than the required outcome. Include relevant regression scope.
- If a worker cannot run a required live-service or platform check, assign it
  to a suitable verifier and retain it as required. Local success cannot stand
  in for the missing boundary check.

## Freeze and correct the contract

Put the exact commands, inputs, preservation requirements and stop conditions
in the brief. Worker and reviewer use the same contract on identified trees.
If the check is wrong or unrunnable, report the mismatch before continuing
dependent work. The task owner records the old and replacement contracts, the
reason and how the replacement still tests the intended outcome. Revalidate
the replacement before resuming; do not silently lower a threshold, remove a
failing case or relabel a failure as success. A changed user requirement is a
scope change to record, not evidence that the old contract passed.

Acceptance is designed when it can distinguish the required outcome from a
plausible failure, runs where assigned, and preserves the agreed boundaries.

Shown under the source repo’s Apache-2.0 license. Read the full folder on GitHub.