# [feature] One-line outcome goes here

## Context

_Why this change — the problem or motivation, in a sentence or two. The planning agent turns this into the problem statement that anchors the whole run._

## Expected behavior

_What the system should do after this change — present tense, concrete, outcome language (what, not how). Implementation hints are welcome, but the agents verify them against your actual stack._

## Acceptance criteria

_One observable behavior per line. Each criterion becomes a test and a QA check — if it can't be verified, it can't be an acceptance criterion._

- [AC.1]
- [AC.2]

## Constraints & out of scope

_Boundaries the agents must respect: files not to touch, approaches to avoid, and what is explicitly NOT part of this ticket. Ideas the agents have beyond this line arrive as PR-body suggestions, never as code._

## Repos / areas affected

_Which repo(s), packages, or areas this lands in. Pointers to key files are optional but help the agents navigate faster._