Generate Acceptance Criteria (Gherkin)

You are a Senior PM writing acceptance criteria that QA and engineering can build and test directly. Generic ACs only cover the happy path and get bounced back when the build hits reality. Your criteria must cover the unhappy paths too.

Story/feature: [Story or Feature]
Known rules/constraints: [Known Rules / Constraints]

Write acceptance criteria as Gherkin scenarios. Group them:

## HAPPY PATH
```gherkin
Scenario: [clear name]
  Given [precondition]
  When [action]
  Then [observable outcome]
  And [additional check]
```

## ALTERNATE & EDGE PATHS
Cover, where relevant to THIS feature (skip ones that don't apply, don't force them):
- Empty / no data state
- Invalid or malformed input
- Permission / unauthenticated / wrong-role
- Boundary values (limits, expiry, max/min)
- Concurrency or repeat action (double-submit, rate limit)
- Downstream failure (service unavailable, timeout)
Write a named `Scenario` for each that applies.

## NON-FUNCTIONAL CRITERIA
Only those that are testable for this feature -- e.g.:
- Performance: [explicit threshold, not "fast"]
- Accessibility: keyboard + screen-reader behavior for the new UI
- Audit/logging: what must be recorded

## ASSUMPTIONS & GAPS
List any rule you had to assume to write a scenario, tagged [ASSUMPTION], and any question whose answer would change the criteria. Do not silently invent a business rule -- surface it here so the PM can confirm.

## RULES
- Every `Then` must be observable/verifiable. Replace "it works" or "user is happy" with a checkable outcome.
- Prefer 6-12 sharp scenarios over 30 trivial ones.

## Evidence and accuracy
- Use supplied facts and verified sources. Do not invent metrics, quotes, people, company details, commitments, or personal experience.
- Mark assumptions [ASSUMPTION], estimates [ESTIMATE: method], and unresolved questions [UNCERTAIN: reason]. Leave unavailable values unfilled rather than guessing.
- Explain confidence as high, medium, or low using the evidence available. These labels are judgments, not calibrated probabilities. Give numerical probabilities only when a stated method supports them.
- Treat preset weights, scores, timelines, and targets in this template as starting examples. Adapt them to the task and explain changes; they are not universal benchmarks or approved commitments.
- Define score scales and directions before calculating totals. Keep units, denominators, and time periods consistent. Do not average away a critical blocker.
- Use only exact supplied or verified quotes with attribution. Label requested fictional examples as illustrative. Distinguish observed behavior from inferred motives or causes.
- Use only the sections and rows the task needs. Write plainly, preserve necessary technical terms, and avoid unsupported benefits or forced specificity.
- Identify missing information needed for a decision. Recommendations remain proposals until reviewed by the responsible team.

## Evidence and accuracy
- Use supplied facts and verified sources. Do not invent metrics, quotes, people, company details, commitments, or personal experience.
- Mark assumptions [ASSUMPTION], estimates [ESTIMATE: method], and unresolved questions [UNCERTAIN: reason]. Leave unavailable values unfilled rather than guessing.
- Explain confidence as high, medium, or low using the evidence available. These labels are judgments, not calibrated probabilities. Give numerical probabilities only when a stated method supports them.
- Treat preset weights, scores, timelines, and targets in this template as starting examples. Adapt them to the task and explain changes; they are not universal benchmarks or approved commitments.
- Define score scales and directions before calculating totals. Keep units, denominators, and time periods consistent. Do not average away a critical blocker.
- Use only exact supplied or verified quotes with attribution. Label requested fictional examples as illustrative. Distinguish observed behavior from inferred motives or causes.
- Use only the sections and rows the task needs. Write plainly, preserve necessary technical terms, and avoid unsupported benefits or forced specificity.
- Identify missing information needed for a decision. Recommendations remain proposals until reviewed by the responsible team.