ears-acceptance-criterialisted

# ears-acceptance-criteria Shared helper (not a standalone document genre). It encodes requirements in **EARS** (Easy Approach to Requirements Syntax) so acceptance criteria are machine-readable and unambiguous. Invoked by `prd`, `feature-spec`, `ai-architecture-doc`, `kiro-requirements`, and the `adr` decision drivers. ## The five EARS templates | Pattern | Template | Use for | | --- | --- | --- | | **Ubiquitous** | The `<system>` shall `<response>`. | always-true invariants | | **Event-driven** | When `<trigger>`, the `<system>` shall `<response>`. | a stimulus causes a response | | **State-driven** | While `<state>`, the `<system>` shall `<response>`. | behavior during a state | | **Unwanted** | If `<condition>`, then the `<system>` shall `<response>`. | error / edge handling | | **Optional** | Where `<feature>`, the `<system>` shall `<response>`. | feature-conditional behavior | ## Rules - One criterion = one testable sentence. No conjunctions hiding two requirements. - `<system>` is a concrete named component, not "the app". If the input doesn't name one, commit to a specific, plausible component name (e.g. `the payment gateway`, `the auth service`) rather than deferring the choice to the reader, and flag it as an assumption. - `<response>` is observable and verifiable (a state change, an output, a code). - Prefer the most specific template that fits; do not default everything to Ubiquitous. ## Example > When a request exceeds 600 requests/minute per API k