Store nodes

Store nodes represent shared client state. They live in the Structure tab's State view, which shows the route tree so you can attach a store to the routes that read or write it — one brush sweep attaches it to every route it crosses.

When state belongs in a store

If several components reach for the same value, that is usually the sign it belongs in one shared place rather than being threaded through props or duplicated. Attaching the store to each route that uses it keeps ownership explicit: the board answers "who depends on this state?" without reading any code. How to structure a Zustand store covers the design side of that decision.

Selecting a store records the state it holds, its actions, and the zustand middlewares it uses — persist, devtools, and friends — so the exported module is a ready-to-fill store, not an empty file. A store node maps to stores/use-<name>-store.ts.

Ordering

Stores are emitted first in the export's build order, ahead of components and pages, because both can import them. That ordering also makes stores a good first thing to plan — deciding what state exists tends to clarify which components need to exist around it. When starter code is generated, each store is implemented before anything that reads it, so downstream files are written against its real exports.

In the wider plan

Stores appear in Traceability, so a feature can be traced to the state that satisfies it — and the API endpoints a store talks to are planned one tab over, in Backend.