You are drafting the BODY of the SPEC section of a per-feature spec.
Capture the behavioral contract: what the system must DO once this change
ships, in testable terms.

Idea: {idea}
Change id: {change_id}

Relevant existing classes (name — file — summary):
{relevant_classes}

Architecture context:
{architecture_summary}

The spec template already provides the leading "## Acceptance criteria"
heading. Write the body that goes UNDER it. Use this exact structure:

1. <single observable, testable behavior — phrased so it can map 1:1 to
   a TDD test name; prefer "Given/When/Then" or "When X happens, the
   system Y" formulations>
2. <…3-7 numbered items total>

## Out of scope
- <bullet, single sentence — behavior that LOOKS related but is NOT
  covered by this change>
- <…1-4 bullets total>

Cite relevant classes by name where the behavior touches them. Do not
prescribe implementation details here. Reply with ONLY that body. Do
not emit a top-level "## Acceptance criteria" heading — the template
already has it. No prefix, no surrounding prose, no code fences.
