FrontEnd Architecture: Modular State with Pinia

[cstns]

Pinia Migration Plan

A comprehensive roadmap for migrating the FlowFuse frontend from Vuex 4 to Pinia.

---

TLDR

Migrate the frontend state management from Vuex 4 to Pinia by converting each Vuex module into a standalone Pinia store, replacing mutations with direct state updates in actions, implementing pinia-plugin-persistedstate for local/session storage, and migrating stores in dependency order (leaf modules first, account stores last). During the transition, Vuex and Pinia will coexist using a temporary bridge pattern until all 238 store consumers are updated.

---

Key Differences: Vuex → Pinia

Concept	Vuex	Pinia
Mutations	Required for all state changes	Eliminated — state is mutated directly in actions
Namespacing	String-based: 'account/setTeam'	Import the store: useAccountStore()
Cross-store access	rootState, rootGetters params	Import the other store directly inside the function
Composition API	useStore() + string keys	const store = useSpecificStore()
Options API	mapState, mapGetters, mapActions	storeToRefs() in setup(), or mapStores()
Global reset	$resetState action dispatched to all modules	Each store gets its own $reset()
Plugins	One global plugin	Plugin registered on the Pinia instance
Testing	Requires full store wiring	Each store is independently unit-testable

---

File Structure & Naming Convention

Pinia stores live in a flat frontend/src/stores/ directory (distinct from the existing frontend/src/store/ Vuex directory). Since Pinia has no concept of namespacing, the file names carry the domain grouping instead.

Convention: dash-separated domain prefix

frontend/src/stores/
├── account-*.js          # split TBD — see "Splitting the Account Store" below
├── context.js
├── ux-dialog.js
├── ux-drawers.js
├── ux-navigation.js      # formerly ux root module
├── ux-tours.js
├── product-brokers.js    # formerly product root module
├── product-assistant.js
├── product-expert.js
├── product-expert-ff-agent.js
├── product-expert-operator-agent.js
└── product-tables.js

The defineStore id matches the filename: defineStore('ux-dialog', ...), defineStore('ux-drawers', ...). This means the Pinia devtools and persisted localStorage keys are consistent and human-readable.

Why dash notation over dot notation: Dots in filenames look like file extensions and confuse some tooling. Dashes are the standard convention across the Vue/Pinia community for flat domain-prefixed stores. It also mirrors how CSS classes and URL slugs are commonly structured.

Why not subdirectories: Subdirectories add import path complexity (@/stores/ux/dialog vs @/stores/ux-dialog) and require index files to re-export. For a migration, keeping everything at one level makes it easier to audit what's been migrated and what hasn't.

---

Splitting the Account Store

The account Vuex module is a single file with 15 state properties, 28 getters, 19 mutations, and 17 actions — too large for a single Pinia store. It needs to be split into smaller, focused stores before migration.

The split strategy is TBD and should be decided as a team before this phase begins. Natural fault lines to consider when making that decision:

• Auth vs. team context — user identity/session data vs. which team is active and what role the user has in it
• Settings/features — settings and features power the featuresCheck getter (31 properties) and may warrant their own store given how widely that getter is consumed
• Notifications — relatively self-contained, low dependency surface

The main constraint to keep in mind: featuresCheck reads from both settings/features and the current team, so whatever stores those values must either be co-located or have a clear import order to avoid circular dependencies.

The file structure above uses account-auth.js and account-team.js as placeholders — the actual filenames should reflect whatever split is agreed on.

---

Persistence & Hydration (The localStorage Problem)

This is the most technically sensitive part of the migration. Getting it wrong means users lose their session on page reload or get stale state after logout.

How it works today (Vuex)

The existing store/plugins/storage.plugin.js does two things:

1. On init: reads all persisted keys from localStorage/sessionStorage and patches them back into the store state before the app mounts
2. On every mutation: checks if the mutated state path has a persistence config and writes the new value to the correct storage

Each module declares its persistence config in a meta.persistence object:

meta: {
  persistence: {
    team: { storage: 'sessionStorage' },
    settings: { storage: 'localStorage', clearOnLogout: false }
  }
}

The bootstrap service waits for a HYDRATE_COMPLETE mutation (or the state._hydrated flag) before considering the store ready and proceeding with user auth checks.

What changes with Pinia

Pinia has no global plugin that intercepts mutations. Instead, each store declares its own persistence config using pinia-plugin-persistedstate. The plugin handles read-on-init and write-on-change per store.

Install:

npm install pinia pinia-plugin-persistedstate@4
npm install -D @pinia/testing

Register on the Pinia instance:

// main.js
import piniaPluginPersistedstate from 'pinia-plugin-persistedstate'
const pinia = createPinia()
pinia.use(piniaPluginPersistedstate)

Each store with persistence adds a persist option:

// account-team.js
export const useAccountTeamStore = defineStore('account-team', {
  state: () => ({ team: null, teamMembership: null, settings: null, features: {} }),
  persist: [
    { pick: ['settings', 'features'], storage: localStorage },
    { pick: ['team', 'teamMembership'], storage: sessionStorage }
  ]
})

The pick array lists only the keys that should be persisted — anything not listed stays in memory only.

The clearOnLogout: false problem

In Vuex, $resetState is called globally on logout and a clearOnLogout: false flag tells it to skip certain keys. Pinia has no equivalent flag — $reset() is all-or-nothing per store.

Only settings and features in the account module have clearOnLogout: false today, but this list is likely to grow. Three options exist — Option C is the agreed approach:

Option C — skipReset Pinia plugin (recommended)

Register a global Pinia plugin in Phase 0 that wraps $reset() on every store. Stores declare a skipReset array listing state keys that survive logout. Logout calls $reset() on all stores uniformly — the plugin handles preservation automatically.

// frontend/src/stores/plugins/skip-reset.plugin.js
export function skipResetPlugin ({ store, options }) {
    const skipKeys = options.skipReset || []
    const originalReset = store.$reset?.bind(store)

    store.$reset = () => {
        const preserved = {}
        skipKeys.forEach(key => { preserved[key] = store[key] })
        if (typeof originalReset === 'function') originalReset()
        store.$patch(preserved)
    }
}

// main.js
import { skipResetPlugin } from './stores/plugins/skip-reset.plugin.js'
pinia.use(skipResetPlugin)

Usage in a store:

export const useAccountTeamStore = defineStore('account-team', {
    state: () => ({
        team: null,
        teamMembership: null,
        features: {}
    }),
    skipReset: ['features'],  // features survives $reset()
    // ...
})

Logout becomes uniform — call $reset() on every store, no exceptions needed:

async logout() {
    await userApi.logout()
    useAccountAuthStore().$reset()
    useAccountTeamStore().$reset()    // features preserved by plugin
    useContextStore().$reset()
    useUxDrawersStore().$reset()
    useUxToursStore().$reset()
    useProductBrokersStore().$reset()
    useProductExpertStore().$reset()
    useProductTablesStore().$reset()
}

Why this over Options A and B: As more state keys accumulate clearOnLogout: false behavior, Option A requires more store splits and Option B requires manually maintained reset lists per store. The plugin declares intent once in the store definition and scales without extra work.

---

Option A — Split the store

Put settings and features in their own store (e.g. account-settings). During logout, simply don't call $reset() on it. No plugin needed. Works well if the split is happening anyway for other reasons.

Option B — Override $reset() in the store

Define a custom $reset action that skips certain keys. This shadows the built-in $reset(). The tradeoff: you lose automatic reset-to-initial-state behavior and must maintain the reset list manually as state keys are added.

The hydration timing problem

This is simpler than it first appears. pinia-plugin-persistedstate restores state synchronously at store creation time — the moment useXxxStore() is called, state is already restored from localStorage. There's no async waiting needed.

During the migration (Tasks 1–11), bootstrap still uses Vuex for auth and user state, so Pinia stores self-hydrate lazily when components first use them. No coordination is needed.

At Task 12 (account stores), bootstrap needs account data before mounting. The solution is to eagerly call the account stores before checkUser() runs:

// bootstrap.service.js — Task 12 final form
async init () {
    return this.waitForAppMount()
        .then(() => {
            // Eagerly create account stores — restores from localStorage synchronously
            useAccountAuthStore()
            useAccountTeamStore()
            useAccountSettingsStore()
        })
        .then(() => this.checkUser())
        .then(() => this.mountApp())
        .then(() => this.waitForRouterReady())
        .then(() => this.markAsReady())
}

waitForStoreHydration() is removed entirely at Task 12 — Vuex is gone, and Pinia doesn't need it.

The localStorage key change

The current Vuex plugin stores all persisted state under a single store key in localStorage as a nested object. pinia-plugin-persistedstate uses the store's id as the key by default (e.g. account-team, ux-tours).

This means existing users' localStorage is silently abandoned on first load after the migration deploys — they won't be logged out (that's determined server-side), but any locally-cached state (tours completed, team context, feature flags) will be gone and re-fetched. This is acceptable behavior for a one-time migration. No migration script is needed.

---

Store Overview & Migration Order

Migrate leaf modules first (no cross-store dependencies), save the account stores for last since everything else depends on them.

Store (new name)	Vuex module	Persistence	Dependencies	Complexity	Consumers
context	context	None	None	Low	routes.js, expert getter
ux-dialog	ux/dialog	None	None	Low	dialog service, Dialog mixin, 50+ pages
ux-tours	ux/tours	localStorage	None	Low	App.vue, onboarding pages
ux-drawers	ux/drawers	None	ux-navigation (overlay)	Medium	100+ components
ux-navigation	ux root	localStorage	account stores (nav tree)	Medium	MainNav.vue
product-tables	product/tables	localStorage	account stores (team.id)	Medium	20+ Tables pages
product-assistant	product/assistant	None	account stores (settings/origins)	Medium-High	Expert assistant components
product-expert-ff-agent	product/expert/ff-agent	localStorage	None (leaf)	Low	product-expert only
product-expert-operator-agent	product/expert/operator-agent	localStorage	account stores (capabilities)	Low	product-expert only
product-expert	product/expert	localStorage	ux-drawers, ff-agent, operator-agent	High	Expert UI components
product-brokers	product root	localStorage	account stores (team.id)	Medium	Broker pages, PostHog
account stores (split TBD)	account	localStorage + sessionStorage	each other	Very High	routes.js, App.vue, bootstrap, 80+ components

---

What Needs to Change: Full Surface Area

main.js

• Create and register Pinia instance with pinia-plugin-persistedstate
• Remove store.commit('initializeStore')
• Keep app.use(vuexStore) until all modules migrated, then remove

services/bootstrap.service.js

• During migration (Tasks 1–11): waitForStoreHydration() continues to wait only for Vuex HYDRATE_COMPLETE — no Pinia changes needed
• At Task 12: Remove waitForStoreHydration() entirely, eagerly call account stores before checkUser(), replace store.dispatch('account/checkIfAuthenticated') with useAccountAuthStore().checkIfAuthenticated()

routes.js and route guards

• Replace useStore() from vuex with imports from specific Pinia stores
• ensureAdmin watches user.admin — replace Vuex watcher with Pinia watch()
• ensurePermission watches settings — same pattern

App.vue

• Largest single component consumer of the store
• Uses mapState and mapGetters from account, ux, ux/drawers
• Move all of these into a setup() function using storeToRefs

services/dialog.js

• Currently dispatches Vuex actions — replace with useUxDialogStore() calls directly

mixins/Dialog.js and mixins/Features.js

• Both are thin wrappers around store access
• After migration, replace with composables: useDialog(), useFeatures()
• This is an optional cleanup but removes an entire layer of indirection

components/drawers/navigation/MainNav.vue

• Primary consumer of mainNavContexts getter
• This getter is the most complex in the codebase — drives the entire sidebar; must be verified against all role types after migration

All 238+ store-accessing files

Find them with:

grep -rl "from 'vuex'\|mapState\|mapGetters\|mapActions\|mapMutations\|this\.\$store\|useStore()" frontend/src/

Two update patterns depending on component style:

Composition API (<script setup> or setup()):

import { storeToRefs } from 'pinia'
import { useAccountTeamStore } from '@/stores/account-team'

const { team, featuresCheck } = storeToRefs(useAccountTeamStore())
const { setTeam } = useAccountTeamStore() // actions don't need storeToRefs

Options API (no setup()):

import { mapStores } from 'pinia'
import { useAccountTeamStore } from '@/stores/account-team'

computed: {
  ...mapStores(useAccountTeamStore),
  // Access via this.accountTeamStore.team
}

---

Dividing Up the Work

Each store migration is designed to be one PR — create store, update consumers, delete Vuex module. Nothing is left in a half-migrated state between merges.

Hard gates:

• Phase 0 must merge before any store PR
• ux-navigation must merge before ux-drawers
• Account stores must be last — everything else imports them

Within those gates, stores can be worked in parallel by different engineers. Group them by domain for ownership:

Group	Stores	Internal ordering
UX	ux-dialog, ux-tours, ux-navigation, ux-drawers	navigation before drawers; dialog and tours are free
Product	product-tables, product-brokers, product-assistant	any order
Expert	product-expert-ff-agent, product-expert-operator-agent, product-expert	sub-agents before parent
Infrastructure	context, route guards, bootstrap service	any order after Phase 0
Account	account stores (split TBD) + 80+ consumer updates	last

The bridge pattern (described below) is what makes parallel work safe — Pinia stores that need account data read it from Vuex temporarily until the account stores are migrated.

---

Shipping Order

Each numbered task below is intended to be one PR. They must be merged in this order:

PR	Task	Gate
1	Phase 0 — Infrastructure	None — start here
2	ux-dialog	Phase 0 merged
3	ux-tours	Phase 0 merged
4	ux-navigation	Phase 0 merged
5	ux-drawers	ux-navigation merged
6	context	Phase 0 merged
7	product-tables	Phase 0 merged
8	product-brokers	Phase 0 merged
9	product-assistant	Phase 0 merged
10	product-expert-ff-agent	Phase 0 merged
11	product-expert-operator-agent	Phase 0 merged
12	product-expert	PRs 5, 10, 11 merged
13+	Account stores	All other PRs merged

PRs 2–4 and 6–11 can all be worked in parallel once Phase 0 is merged, subject to their individual gates. PR 5 needs PR 4. PR 12 needs PRs 5, 10, and 11. Account stores go last.

---

The Cross-Store Bridge Pattern (During Migration)

While the account stores are still on Vuex, other Pinia stores that need team/user data use a temporary bridge import:

// Temporary: import Vuex store directly during migration
import store from '@/store' // the old Vuex store
const teamId = store.state.account.team?.id

// After account-team is migrated, replace with:
import { useAccountTeamStore } from '@/stores/account-team'
const { team } = storeToRefs(useAccountTeamStore())

Similarly, the Vuex account module's clearOtherStores action needs a bridge while product stores are being migrated:

// In Vuex account module (temporary)
clearOtherStores({ dispatch }) {
  // Keep old dispatch for modules not yet migrated
  dispatch('product/tables/clearState')
  // Call Pinia store once it's migrated
  if (window.__pinia) {
    const tablesStore = useProductTablesStore()
    tablesStore.clearState()
  }
}

---

Gotchas

Non-serializable values in state

product-expert stores AbortController, setInterval references, and timer IDs in state. Vue's Proxy breaks these. Wrap with markRaw():

this.abortController = markRaw(new AbortController())
this.streamingTimer = markRaw(setInterval(...))

Circular imports

account-team imports account-auth, and other stores import account-team. If two stores ever end up importing each other, import the secondary store inside the function body rather than at the top of the file to break the cycle:

someAction() {
  const other = useOtherStore() // inside function, not top-level import
}

Getters that return functions

Some Vuex getters return a function (e.g. brokerExpandedTopics(brokerId)). Pinia supports this pattern identically:

brokerExpandedTopics: (state) => (brokerId) => {
  const { team } = useAccountTeamStore()
  return state.brokers.expandedTopics?.[team?.id]?.[brokerId] ?? []
}

$reset() only works with Options API stores

$reset() is built into Pinia's Options API store definition (defineStore(id, { state, getters, actions })). It resets all state to the initial value returned by the state factory. It is not available on Setup stores (defineStore(id, () => {...})). All stores in this migration use Options API, so $reset() is available — but any new stores added later must also use Options API if they need $reset().

storeToRefs is required for reactive destructuring

// WRONG — loses reactivity
const { user } = useAccountAuthStore()

// CORRECT — reactive
const { user } = storeToRefs(useAccountAuthStore())

// Actions are plain functions — destructure directly
const { logout } = useAccountAuthStore()

---

Testing Pinia Stores

One of Pinia's key advantages over Vuex is that each store is independently testable without wiring up the entire app.

Unit testing a store (no dependencies)

import { setActivePinia, createPinia } from 'pinia'
import { describe, it, expect, beforeEach } from 'vitest'
import { useUxDialogStore } from '@/stores/ux-dialog.js'

describe('ux-dialog store', () => {
  beforeEach(() => {
    setActivePinia(createPinia()) // fresh Pinia instance per test
  })

  it('initializes with empty state', () => {
    const store = useUxDialogStore()
    expect(store.dialog.header).toBeNull()
  })

  it('clearDialog resets state', () => {
    const store = useUxDialogStore()
    store.dialog.header = 'Test'
    store.clearDialog()
    expect(store.dialog.header).toBeNull()
  })
})

Unit testing a store that depends on another store

If a store reads from another Pinia store, just call both in the same beforeEach:

import { setActivePinia, createPinia } from 'pinia'
import { useProductAssistantStore } from '@/stores/product-assistant.js'
import { useContextStore } from '@/stores/context.js'

beforeEach(() => {
  setActivePinia(createPinia())
})

it('immersiveInstance reads from contextStore', () => {
  const context = useContextStore()
  const assistant = useProductAssistantStore()
  context.setInstance({ id: 'inst-1', url: 'http://localhost' })
  expect(assistant.immersiveInstance).toEqual({ id: 'inst-1', url: 'http://localhost' })
})

Mocking stores in component tests

Use @pinia/testing to stub stores in Vue component tests. This prevents real state from leaking between tests and lets you control what the store returns:

import { mount } from '@vue/test-utils'
import { createTestingPinia } from '@pinia/testing'
import { vi } from 'vitest'
import MyComponent from '@/components/MyComponent.vue'
import { useAccountTeamStore } from '@/stores/account-team.js'

it('renders team name', () => {
  const wrapper = mount(MyComponent, {
    global: {
      plugins: [
        createTestingPinia({
          createSpy: vi.fn,
          initialState: {
            'account-team': { team: { id: 't1', name: 'My Team' } }
          }
        })
      ]
    }
  })

  const store = useAccountTeamStore()
  expect(wrapper.text()).toContain('My Team')
  // Actions are auto-stubbed — verify they were called:
  store.setTeam({ id: 't2' })
  expect(store.setTeam).toHaveBeenCalledWith({ id: 't2' })
})

Key rule: createTestingPinia stubs all actions by default. Pass stubActions: false if you need the real action logic to run.

Note — Issue #6457: This migration is a deliberate opportunity to establish solid frontend unit testing patterns. Each store PR should be treated as a "start fresh" moment for its test coverage — don't just port existing tests, write tests that actually cover the store's contract.

---

Definition of Done

• npm uninstall vuex succeeds with no errors
• grep -r "from 'vuex'" returns zero results
• grep -r "this\.\$store" returns zero results
• frontend/src/store/ directory deleted in its entirety
• All persisted state survives a page reload
• Logout clears correct state and preserves settings and features
• All route guards work correctly for all role types
• Expert assistant streaming and session timers work end-to-end
• Full navigation tree renders correctly for Guest, Member, Owner, Admin roles
• Each migrated store has a frontend/src/tests/stores/*.spec.js file
• Existing Vitest and Cypress tests pass

[Steve-Mcl]

Please switch from dead vuex to Pinia sooner rather than later

• Vuex is dead: Well, almost. Lets call it life support. Can we get this done before its a problem?

• Native IDE Navigation: Enables the $F12 "Go to Definition"

• Zero Mutations: Removes all the pontelss boilerplate of mutations and commits.

• No More Namespacing: Each store is a standalone file that you import only where needed.

• Automatic Code Splitting: Pinia stores are naturally modular, meaning the browser only loads the store logic required for the current page (unlike the single large Vuex bundle).

• Simplified Actions: Actions no longer need context destructuring. You simply use this.myState or this.myAction(), which feels more natural like standard JavaScript!

• Vue 3 Native: Built specifically for the Vue 3 reactivity system, resulting in better performance than the Vue 2 / Vuex architecture.

[cstns]

I'd love to get this in asap too, haven't gotten a chance to sort out the planning of it. @n-lark this is an awesome opportunity to familiarize yourself with the application without completely throwing yo under the bus.

A bit of context can be found on the epic this is a part of we can go over it when you get in planning/approach wise.

[n-lark]

Pinia Component Patterns

Quick reference for updating components during the Vuex → Pinia migration. Four patterns cover every case you'll encounter.

---

Pattern A — <script setup> (most common)

<script setup>
import { storeToRefs } from 'pinia'
import { useUxDialogStore } from '@/stores/ux-dialog.js'

const dialogStore = useUxDialogStore()

// State and getters — MUST use storeToRefs to stay reactive
const { dialog, isOpen } = storeToRefs(dialogStore)

// Actions — destructure directly, no storeToRefs needed
const { showDialog, clearDialog } = dialogStore
</script>

---

Pattern B — setup() function

Same as Pattern A, just inside the setup() return:

import { storeToRefs } from 'pinia'
import { useUxDialogStore } from '@/stores/ux-dialog.js'

export default {
    setup () {
        const dialogStore = useUxDialogStore()
        const { dialog, isOpen } = storeToRefs(dialogStore)
        const { showDialog, clearDialog } = dialogStore

        return { dialog, isOpen, showDialog, clearDialog }
    }
}

---

Pattern C — Options API (no setup)

Use mapStores to expose the whole store as a computed property. Access everything via this.uxDialogStore.*:

import { mapStores } from 'pinia'
import { useUxDialogStore } from '@/stores/ux-dialog.js'

export default {
    computed: {
        ...mapStores(useUxDialogStore)
        // exposes: this.uxDialogStore
    },
    methods: {
        openIt () {
            this.uxDialogStore.showDialog({ header: 'Hello' })
        }
    }
}

The store name is derived from the defineStore id: 'ux-dialog' → uxDialogStore.

---

Pattern D — Options API component where inject/provide is unavailable

mapStores and setup() both rely on Pinia's inject/provide context. That context is broken in two situations confirmed during Task 1:

1. A mixin consumed by a pure Options API host — mixins/Dialog.js is consumed by Platform.vue which has no setup(). The mixin's setup() return values and mapStores computed properties never land on the instance.
2. A component rendered dynamically inside <ff-dialog> — Platform.vue renders <component :is="dialog.is.component" /> inside ff-dialog. This dynamic rendering breaks the inject chain for components mounted that way (AddDeviceToGroupDialog.vue, device-list.vue).

Both produce the same warning:

[Vue warn]: Property "xyz" was accessed during render but is not defined on instance.

Call useStore() directly inside each computed and method instead. Pinia stores are singletons backed by a module-level variable — every call returns the same reactive instance without needing inject/provide:

import { useUxDialogStore } from '@/stores/ux-dialog.js'

export default {
    computed: {
        dialog () { return useUxDialogStore().dialog }
    },
    methods: {
        clearDialog (cancelled = false) {
            useUxDialogStore().clearDialog(cancelled)
        },
        someAction (value) {
            useUxDialogStore().someAction(value)
        }
    }
}

When to use this pattern: any Options API component that goes through a mixin or is rendered as a dynamic <component :is="..."> inside ff-dialog. Regular Options API components mounted normally (Pattern C) work fine with mapStores.

---

The mistake everyone makes

// WRONG — looks fine, loses reactivity silently, template won't update
const { dialog } = useUxDialogStore()

// RIGHT — reactive
const { dialog } = storeToRefs(useUxDialogStore())

// ALSO RIGHT — actions don't need storeToRefs
const { showDialog } = useUxDialogStore()

Rule: if it's state or a getter, use storeToRefs. If it's an action, destructure directly.

---

Replacing Vuex patterns

Vuex	Pinia equivalent
mapState('module', ['key'])	storeToRefs(useModuleStore())
mapGetters('module', ['getter'])	storeToRefs(useModuleStore())
mapActions('module', ['action'])	const { action } = useModuleStore()
mapMutations('module', ['mutation'])	mutations are gone — call the action directly
this.$store.state.module.key	useModuleStore().key
this.$store.dispatch('module/action', payload)	useModuleStore().action(payload)
this.$store.getters['module/getter']	useModuleStore().getter

---

Import paths

Stores live in frontend/src/stores/. Use the @ alias — it's configured in both webpack and Vitest and maps to frontend/src:

import { useUxDialogStore } from '@/stores/ux-dialog.js'

This works from any depth: components, views, services, composables — no need to count ../ levels.

[cstns]

Thanks for putting this together. The proposed store namespacing and file structure looks like the right way forward. I have a few specific thoughts on the implementation details and the "Definition of Done":

1. Cleanup & Scope
We should ensure the Definition of Done includes the complete removal of the /frontend/src/store directory once the migration to Pinia is finished.

2. Options API vs. Composition API
I'm fine with sticking to the Options API for Pinia. While the argument that it's "simpler for external contributors" is debatable, it stays consistent with our current Vue implementation and lowers the friction for this migration. We can carry that pattern forward.

3. State Reset & The "Clear on Logout" Problem
I've found Pinia’s built-in $reset() to be a bit finicky: it doesn't always behave as expected. Regarding the "Option B" approach for clearing state on logout: while we currently only have a couple of properties (like features) that persist, that list will likely grow.

Instead of a manual approach, I'd suggest a more robust Pinia plugin to handle partial resets. This allows us to define a skipReset array in the store definition. Something like this:
JavaScript

// pinia global plugin
pinia.use(({ store, options }) => {
  const skipKeys = options.skipReset || [];
  const originalReset = store.$reset;

  store.$reset = () => {
    // 1. Capture current values of keys to preserve
    const preservedState = {};
    skipKeys.forEach(key => {
      preservedState[key] = store[key];
    });

    // 2. Run original reset logic
    if (typeof originalReset === 'function') {
      originalReset();
    }

    // 3. Patch preserved values back in
    store.$patch(preservedState);
  };
});

// usage in store
	export const useUserStore = defineStore('account-team', {
	  state: () => ({
	    team: {name: 'some-team'},
	    teamMembership: {...},
	    features: { awesomeFeature: true }, // We want to keep this
	  }),
	  
	  // Custom option recognized by our plugin
	  skipReset: ['features'], 

	  actions: {
	    /* ... */
	  }
	});
	```

4. Testing & Dependencies
We need to keep Issue #6457 in mind during this transition. This feels like the perfect opportunity to "start fresh" with our frontend unit testing. We are likely already using Vitest to some degree on the front-end, but we should use this migration to solidify how we test our store logic.

5. UX Store Migration
Just a heads-up: if we extract the main navigation into its own store, we are currently losing some state keys from the existing UX store. We’ll need to account for those during the refactor to ensure no UI state is dropped.