Behavior contracts

Define the behavior before implementation. Prove it with repeatable scenarios at the product's public boundary.

Agree the contract

Read the request, existing requirements, domain language, and acceptance scenarios. Resolve ambiguous outcomes before implementation.

Make scenarios authoritative for acceptance. Link existing requirement records instead of maintaining competing copies of the same behavior. Preserve existing requirement identifiers. Do not require a tracker or invent ticket IDs.

Use Gherkin when the project needs a shared readable format. Preserve an equivalent existing scenario format when it serves that contract. Do not install a framework merely to obtain Given-When-Then syntax.

Each scenario defines: