Create an x-data scope

Start from the behavior you can observe. The filter panel owns query and status, while each issue row owns only its own expanded state.

x-data creates an Alpine scope; nested scopes can shadow values, so placement establishes ownership. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

It is tempting to put one giant x-data object on body so every element can mutate every value. That trades a clear decision for an assumption you will eventually have to debug. The stronger move is to place state at the smallest common ancestor that needs it and name nested values to avoid accidental shadowing. Make the boundary explicit in code and in the project notes.

Tie the decision back to the larger job: Add a small local behavior to useful HTML without turning the whole page into a client application. Record enough evidence that another developer can repeat the result without relying on your memory.

Move a value through three possible scope locations and observe which controls can access it. Repeat it once with an invalid or hostile condition and write down the boundary the failure revealed.