Demos and local dev both have the same small friction, you land on the login screen and have to remember which seeded account you wanted. The test users control is a floating button in the bottom left that lists the accounts for the current app and fills the form when you pick one. It lives in shared/features/managers/TestUsers.vue and mounts once in each app's App.vue, next to the dialog manager.
VITE_TEST_USERS does two jobs at once. It enables the control and it names which roster to show, so the value is app or admin rather than a boolean. Anything else, including an empty value or the variable being absent, renders nothing at all. That keeps one variable where two would otherwise be needed, and it means a production build with the variable unset can't accidentally ship a half-configured panel.
The rosters live in the component itself, keyed by app and then by route name. Only the login route has entries out of the box, but the shape is there if you want a different set of accounts on another screen later.
Picking a user sets value on the matching input[name="..."] and dispatches an input event. That looks wrong at first glance, since every other form in the starter goes through vee-validate.
The reason is placement. The control mounts at the app root so a single import covers every page, which puts it outside the form's provide tree. vee-validate's form context only flows down to descendants, so the form API genuinely isn't reachable from there. The alternative is registering each form in a module-scoped list for the panel to find, which is more machinery than a dev widget deserves.
Dispatching the event rather than just assigning the value is the part that matters. Vue's v-model doesn't watch the property, it listens for the event, so the assignment alone would update the DOM and leave the form state untouched. With the event, vee-validate sees it as ordinary typing and validation behaves normally. It's the same approach password managers use.
The tradeoff is that this couples to the name attribute in the markup instead of to a typed API, so renaming a field breaks the fill silently. For a control that only exists in dev and breaks nothing when it fails, that's a fair trade.
Add an entry to the roster with an email, a password, and an i18n key, then add that key under manager.test_users in each locale's features.json. The description is translated like everything else, so a new account means touching the locale files too.