# Persist Pinia State in a Vue App from a Linear Issue

Yes. An agent turns your Linear issue into a Vue pull request that persists the user's name and language, with reload and clear-state tests.

[Run this on Rush](https://cloud.getrush.ai/run/add-pinia-persistence/vue/), in a Project that has your repository.

## What the agent does

The agent checks where the state actually lives. In `antfu-collective/vitesse`, `src/stores/user.ts` defines the Pinia user store with `savedName`, a private `previousNames` set and a `setNewName` action. Language currently lives elsewhere: `src/modules/i18n.ts` initializes the locale and exports `loadLanguageAsync`, while `src/components/TheFooter.vue` cycles through `availableLocales`. Persisting a name and a preferred language therefore requires connecting the existing owners, not assuming that the store already contains both.

It then follows initialization and navigation. `src/modules/pinia.ts` creates Pinia and restores `initialState.pinia` on the client for Vite SSG. `src/pages/hi/[name].vue` calls `user.setNewName(route.params.name)` from a watch effect. The agent defines when saved browser values are restored relative to that serialized state and the route parameter. A stored name must not unexpectedly override an explicit greeting URL, and a chosen language must be loaded through the existing translation loader.

The change stores only the preferences the issue names in `localStorage`, with a clear action that removes their saved values and updates the visible state. It treats a missing entry as a first visit and distinguishes invalid persisted data from a valid empty preference. It keeps browser access out of server rendering and checks that restoring a locale uses an entry from `availableLocales`. The prior-name set remains outside persistence unless the issue explicitly asks to retain it.

`package.json` pins `pnpm@10.30.2`, sets `test` to `vitest`, and builds through `vite-ssg build`. `vite.config.ts` selects `test/**/*.test.ts` with a jsdom environment, and `test/component.test.ts` demonstrates mounting Vue components. The agent adds reload, language-switch and clear-state coverage, runs `pnpm test --run` to finish rather than watch, then runs `pnpm build`. The static build is a separate check that a working browser test has not hidden server-side storage access.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "codex",
  "input": "A Linear issue labeled agent asks us to persist the Vue app's user name and preferred language across reloads using localStorage, with a way to clear them. Read the actual Pinia store, i18n loader, footer locale control and SSG initialization first. Extend their existing paths; do not introduce a second locale owner or persist unrelated state. Define restoration order, preserve an explicit route name, validate stored preferences and keep browser storage access out of server rendering. Add a visible clear action and tests for reloading, changing language and clearing preferences. Use the package manager declared by the repository. In Vitesse, run pnpm test --run and pnpm build. Open a pull request linking the Linear issue URL supplied in the task, with actual command results and any unresolved behavior.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app"
    }
  ]
}
```

1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.

## What comes back

The PR contains the user-store persistence change, the locale integration and a clear-preferences control, plus tests in the repository's configured test directory. Its description specifies which values survive a reload and what clearing them does. If the implementation needs a dependency, the package manifest and lockfile show it and the PR explains why the existing VueUse dependency could not carry the change.

A reviewer checks behavior across a fresh visit, a language change, an explicit greeting route and a page reload. Clearing storage must update the current page as well as the next visit. The test output and SSG build output are separate evidence: successful serialization does not establish that the saved language is loaded, and a passing locale test does not establish that static rendering avoids `window`. Unavailable checks remain named limitations in the answer.

## Run it on every Linear issue labelled persistence

Route matching issues through your own Linear webhook receiver. It supplies the issue text, URL and preference requirements as the request's `input`, substitutes your installed GitHub repository in `resources`, and calls the sessions API with an API key. Keep the storage scope in each issue so a request about display preferences cannot expand into saving authentication data. An idempotency header tied to the issue revision makes repeated webhook deliveries reuse the original request.

## Why run it on Rush?

Preference bugs often appear between browser initialization and static rendering. Rush runs the agent in its own sandbox, where it can exercise the Vue store and run the SSG build without changing your local browser preferences or disrupting a development server. The requested result includes both the diff and command output, giving a reviewer more than a proposed persistence snippet.

You can send independent persistence tasks for several Vue repositories, each with its own clone and its own tests. Read each session's final answer and transcript to see how its initialization order differs. After a turn finishes, a follow-up can ask for a different clear-state policy in the same sandbox instead of restarting the investigation from an unexplained code patch.

## Frequently asked questions

### Does the Vitesse user store already own the language?

The inspected store owns `savedName`, while `src/modules/i18n.ts` owns language loading. The footer changes the locale through that loader. The task joins those existing paths and makes the preferred language explicit instead of persisting a nonexistent store property.

### Will it persist every Pinia store?

The request limits persistence to the user's name and preferred language. Previous names, transient UI state and sensitive values stay outside that scope. Review the serialized payload in the diff before merging, particularly if your application stores session information in Pinia.

### How does the clear action behave?

The PR must state the default name and language after clearing. Tests should show that both the current view and a new store instance agree with that policy. Removing a storage key while leaving stale values on screen does not satisfy the request.

### Can this work with static generation?

That is part of the requested verification for Vitesse, whose build command uses Vite SSG. Storage restoration belongs on the client and must respect the serialized Pinia state. The agent reports the build result separately from the browser-oriented persistence tests.