Profiles

What a profile carries, what it deliberately does not, and why the active one is remembered per account.

A profile is a named set of your own work. Switching one is a click at the top of the panel.

What a profile carries

Your saved scripts and their libraries. Your wildcards. Your custom commands. Your recorded tests. The assistant's four permissions. The preferences that belong to how you work rather than to the machine you are on.

One profile per customer, or per kind of work, is the usual arrangement. The snippets and rules you want on one engagement are rarely the ones you want on the next, and a single list holding both is a list you stop reading.

What it does not carry

Themes belong to the account rather than to a profile: switching profile does not change the colours.

Which instance you are on, which update set is active, and whether dark mode is on are properties of where you are rather than of who you are, so they are not in a profile either.

The credential vault is per account as well, encrypted with a passphrase only you have.

The active profile is remembered per account

The selected profile is stored under a key that carries your user id.

That is not tidiness. Without it, signing in as somebody else on a shared machine would load the previous account's profile, which your account cannot see: an empty list, under the previous person's profile name, with no explanation. The same applies to the name shown before the list has finished loading.

Where the work actually lives

The scripts, wildcards and commands are rows on your account, read into the panel when a profile loads.

Two caches make them work where the panel is not. The rules a form frame needs in order to fire, and the libraries a script needs in order to resolve, are written by the top frame into the instance's own storage and read back by the form frames. That is the same cross-frame pattern the update set status uses, and it is why a rule can fire inside a form frame that has no panel in it.