@raishin/vanguard-frontier-agentic 3.0.2 → 3.1.1

package/skills/frontend/vue-state-store-security-review/references/persistence-and-hydration.md

@@ -0,0 +1,234 @@
+# Client-Side Persistence and Server-to-Client Hydration
+
+Use this reference when reviewing `pinia-plugin-persistedstate`/`vuex-persistedstate`
+configuration, SSR store creation/singleton risk, or server-payload hydration
+(`window.__pinia`/`__INITIAL_STATE__`).
+
+## Defect (a): sensitive data persisted to localStorage/sessionStorage without scoping
+
+### What people get wrong
+
+The naive assumption is:
+
+> "I added `persist: true` so refreshes don't lose the user's cart — that's just a convenience
+> feature, not a security decision."
+
+Wrong. `persist: true` (Pinia) persists the *entire* store state to `storage` by default, and
+`pinia-plugin-persistedstate`'s `storage` option itself defaults to `localStorage`
+(`documentation-based`, via Context7 `/prazdevs/pinia-plugin-persistedstate`). If that store
+also holds an auth token, a refresh token, a session identifier, or PII — which is common when
+the same store that holds "is the user logged in" convenience state also holds the token used
+to answer that question — the token rides along into `localStorage`, a plain string store
+readable by any script running in the page's origin. Unlike an `HttpOnly` cookie, there is no
+mechanism preventing JavaScript (including injected/XSS script) from reading it.
+
+### Officially grounded rules
+
+- `pinia-plugin-persistedstate`'s `storage` option accepts `localStorage` (default),
+  `sessionStorage`, or a custom storage object implementing `getItem`/`setItem`
+  (`documentation-based`).
+- The `pick` option (an array of dotted state-path strings, e.g. `['save.me', 'saveMeToo']`)
+  restricts persistence to only the named paths; **with no `pick`, the entire state object is
+  persisted** (`documentation-based`). Legacy Vuex's `vuex-persistedstate` exposes the
+  equivalent restriction via its `paths` option.
+- A single store can use multiple persistence configs (an array of `{ pick, storage }` objects)
+  to route different fields to different storage — e.g. a non-sensitive UI field to
+  `localStorage` and nothing sensitive persisted at all (`documentation-based`).
+
+### Review procedure
+
+1. Read the full `state()` shape of the store.
+2. Read the full `persist` config (or absence of one). If `persist` is absent, there is no
+   persistence finding for this store regardless of what it contains.
+3. If `persist: true` or `persist: {}` (no `pick`/`paths`) → every field in `state()` is
+   persisted. Cross-reference against the sensitivity classification (auth/session/PII vs.
+   UI-preference/non-sensitive).
+4. If `persist: { pick: [...] }` → only the named paths are persisted. Check whether any
+   sensitive field is named in that list. If none are, the persistence finding does not apply
+   to this store (note that in the review) — but confirm no sensitive field was missed by
+   checking the full list against the full `state()` shape, not just skimming for the word
+   "token".
+5. Check `storage`. Note explicitly whether it is `localStorage` (default, worse for
+   sensitive data) or `sessionStorage`/a custom secure storage adapter — but do not treat
+   `sessionStorage` alone as clearing a finding for a sensitive field; both are readable by
+   same-origin script, meaning both are XSS-exfiltratable. The `storage` choice affects the
+   window of exposure (tab lifetime vs. persistent), not whether the data is exposed to XSS at
+   all.
+
+### Minimal safe pattern
+
+```ts
+// Only the non-sensitive UI preference is persisted; the auth token is never
+// scoped into `pick`, so it never reaches storage.
+export const useAuthStore = defineStore('auth', {
+  state: () => ({
+    token: '',           // sensitive — intentionally NOT in `pick` below
+    refreshToken: '',    // sensitive — intentionally NOT in `pick` below
+    theme: 'light',      // non-sensitive UI preference
+  }),
+  persist: {
+    pick: ['theme'],
+    storage: sessionStorage,
+  },
+})
+```
+
+### Anti-pattern (do not approve)
+
+```ts
+export const useAuthStore = defineStore('auth', {
+  state: () => ({
+    token: '',
+    refreshToken: '',
+    user: { email: '', ssn: '' },
+  }),
+  persist: true, // WRONG: entire state, including token/refreshToken/ssn, persisted
+                  // to localStorage (the plugin's default storage) with no `pick`.
+})
+```
+
+## Defect (b): store hydration from an untrusted server payload
+
+### What people get wrong
+
+The naive assumption is:
+
+> "The state blob came from our own server, so it's trusted — `JSON.parse` is safe, and
+> embedding it with `JSON.stringify` is just plumbing."
+
+Wrong in two distinct ways, both documented directly by Pinia's own SSR guide
+(`documentation-based`, via Context7 `/vuejs/pinia`):
+
+1. **Serialization-side (server → HTML):** naively interpolating
+   `JSON.stringify(pinia.state.value)` into an HTML `<script>` block is unsafe if any part of
+   that state can be influenced by user-submitted content (a bio field, a comment, any
+   value a user or another user previously submitted that flowed into the store) — which is
+   "almost always the case." A crafted value containing `</script><script>...` breaks out of
+   the tag and executes as script in every subsequent visitor's browser. Pinia's docs
+   explicitly recommend a safe-serialization library (`devalue` or equivalent) and call
+   escaping "**VERY important**."
+2. **Hydration-side (client parse):** the documented client pattern is
+   `pinia.state.value = JSON.parse(window.__pinia)` — this assigns the *entire* parsed object
+   directly into the live store state with no schema/shape check. If the value was tampered
+   with in transit, or the serialization step itself was compromised, this is a direct
+   trust-without-validation of a value that traveled through the DOM.
+
+### Review procedure
+
+1. Find the server-side code that serializes store state for hydration. Grep for
+   `JSON.stringify(` combined with a variable referencing `pinia.state`, a Vuex store's
+   `state`, or an equivalent root-state accessor, especially where the result is concatenated
+   into an HTML template string or a `<script>` tag.
+2. Determine whether that serialization uses a safe-serialization library (`devalue` or
+   equivalent) or applies explicit escaping of `<`, `>`, `/` before embedding. If it is a bare
+   `JSON.stringify` with no escaping step anywhere in the call chain → **HIGH** finding.
+3. Find the client-side hydration code — grep for `window.__pinia`, `window.__INITIAL_STATE__`,
+   or an equivalent global, and the assignment into `pinia.state.value` (or a Vuex store's
+   `replaceState`/direct state assignment).
+4. Check whether the parsed value is validated (a schema check, a shape guard, a runtime type
+   check) before being assigned/used, or is trusted as-is. Trusting as-is is a finding whenever
+   the state's contents could have been influenced by any user's prior input — treat this as
+   the default assumption unless the review can show the state is fully server-computed with no
+   user-submitted content anywhere upstream.
+
+### Minimal safe pattern
+
+```js
+// server: escape before embedding
+import devalue from 'devalue'
+// ... after rendering, pinia.state.value holds this request's root state
+const serialized = devalue(pinia.state.value) // escapes for safe HTML embedding
+// embed `serialized` in the response, e.g. `<script>window.__pinia=${serialized}</script>`
+```
+
+```js
+// client: hydrate only after confirming the shape looks like what's expected
+const raw = JSON.parse(window.__pinia)
+if (isValidPiniaStateShape(raw)) {
+  pinia.state.value = raw
+}
+```
+
+### Anti-pattern (do not approve)
+
+```js
+// server — WRONG: naive stringify with no escaping, and no validation downstream
+const html = `<script>window.__pinia=${JSON.stringify(pinia.state.value)}</script>`
+```
+
+```js
+// client — WRONG: entire parsed payload trusted with no shape/schema check
+pinia.state.value = JSON.parse(window.__pinia)
+```
+
+## Defect (c): SSR store singleton cross-request pollution
+
+### What people get wrong
+
+The naive assumption is:
+
+> "Each HTTP request gets its own function call, so a module-level `const pinia =
+> createPinia()` is fine — it's just one variable."
+
+Wrong. A Node.js SSR process is long-lived and handles many concurrent requests over shared
+module memory. A `createPinia()`/`createStore()` call sitting at module scope (executed once
+when the module is first `import`ed) is shared by every request the process ever handles after
+that — one user's cart, auth state, or session data written into that store during request A's
+handling can be read back during request B's handling, concurrently or on a subsequent request.
+
+### Officially grounded rules
+
+- Pinia's SSR pattern is to construct a fresh `createPinia()` per request and pass it into a
+  freshly created app instance for that request; the state is retrieved from that specific
+  instance's `pinia.state.value` after rendering (`documentation-based`, via Context7
+  `/vuejs/pinia`).
+- Pinia's own "outside-component usage" guidance states explicitly that in SSR apps, the pinia
+  instance must be passed explicitly to `useStore()` calls "to prevent the unintended sharing
+  of global state between different application instances during the server-side rendering
+  process" (`documentation-based`).
+- Vuex's module-reusability pattern requires `state` to be declared as a factory function
+  (`state: () => ({...})`) rather than a plain object literal, specifically so that each module
+  instance gets its own isolated state object rather than sharing one object reference
+  (`documentation-based`, via Context7 `/vuejs/vuex`) — the same "fresh instance per use"
+  principle Pinia's SSR guidance requires at the store-instance level.
+
+### Review procedure
+
+1. Grep the SSR entry file(s) for `createPinia(`, `createStore(`, `new Vuex.Store(` and
+   determine the enclosing scope of each call site: module top level (executes once at import
+   time) vs. inside an exported/invoked per-request handler function.
+2. If found at module scope and reused across requests → **HIGH** finding, `ssr-pollution`.
+3. If found inside a per-request handler, read the full body of that handler function and list
+   every variable it references from enclosing/module scope. Classify each as immutable (safe)
+   or mutable/reactive (risk). A per-request `createPinia()` call that also reads/writes a
+   module-level cache or default object is still a finding — name the specific closed-over
+   reference.
+4. For Vuex modules intended to be reusable/instantiated more than once, confirm `state` is a
+   function, not a plain object literal — a plain object literal shared across module
+   instantiations is the Vuex-specific version of this same defect class.
+
+### Minimal safe pattern
+
+```js
+// entry-server.js
+export async function render(url) {
+  const pinia = createPinia()          // fresh per request
+  const app = createApp(App)
+  app.use(pinia)
+  // ...populate state for this request only, then render...
+  return { html, piniaState: pinia.state.value }
+}
+```
+
+### Anti-pattern (do not approve)
+
+```js
+// entry-server.js — WRONG: created once at module load, shared across every request
+const pinia = createPinia()
+
+export async function render(url) {
+  const app = createApp(App)
+  app.use(pinia) // every request shares the SAME pinia instance's state
+  // ...
+}
+```

package/skills/frontend/vue-state-store-security-review/references/untrusted-payloads-and-authorization.md

@@ -0,0 +1,200 @@
+# Untrusted Payloads, Client-Side Authorization Flags, and Devtools Exposure
+
+Use this reference when reviewing `$subscribe`/`$onAction` (Pinia) or plugin/module code
+(Vuex) that consumes mutation/action payloads, when checking whether a client-held role/flag is
+being used as an authorization boundary, or when checking devtools configuration for
+production exposure.
+
+## Defect (d), part 1: store plugins / $subscribe / $onAction acting on untrusted payloads
+
+### What people get wrong
+
+The naive assumption is:
+
+> "This is my own store's hook — the payload came from my own action, so it's already trusted
+> by the time it reaches the hook."
+
+Wrong when the action's argument itself originated from user-controlled input (a route param,
+a form field, a query string, a request body forwarded into the action call) and the hook does
+something with side effects. Pinia's `$subscribe` and `$onAction` hooks are generic
+instrumentation points — they receive whatever `mutation`/`args` content the calling code
+passed, with no built-in sanitization or validation (this is an architectural fact, not a
+defect in Pinia itself: the hook is a generic observation/interception point and the trust
+boundary is defined entirely by the caller).
+
+### Officially grounded API shape (do not invent beyond this)
+
+Confirmed via Context7 `/vuejs/pinia` (`documentation-based`):
+
+- `store.$subscribe((mutation, state) => {...})` — the callback receives a `mutation` object
+  (`mutation.type`: `'direct' | 'patch object' | 'patch function'`, `mutation.storeId`,
+  `mutation.payload` for patch-object mutations) and the current `state`.
+- `store.$onAction(({ name, store, args, after, onError }) => {...})` — the callback receives
+  the action `name`, the `store` instance, an `args` array of the parameters passed to the
+  action, and `after`/`onError` hooks for post-action handling.
+- Vuex plugins receive the `store` instance directly (`store => {...}`) and can subscribe to
+  mutations/actions via `store.subscribe`/`store.subscribeAction`; a namespaced module's action
+  context includes `rootState`/`rootGetters`, giving plugin/action code reach across module
+  boundaries (`documentation-based`, via Context7 `/vuejs/vuex`).
+
+Do not describe a hook argument, method, or option beyond what is listed above — if a
+reviewed codebase appears to use something not confirmed here, treat the claim about its
+*documented* behavior as unverified and say so, rather than asserting a specific contract.
+
+### Review procedure
+
+1. Enumerate every `$subscribe`, `$onAction` (Pinia), or `store.subscribe`/
+   `store.subscribeAction`/plugin registration (Vuex) in scope.
+2. For each, read the hook body. Classify: does it only observe (log a mutation type, emit an
+   analytics event with non-sensitive metadata) or does it act (write to a DB, call an external
+   API, mutate a *different* store, log payload content that could be sensitive)?
+3. For hooks that act, trace the payload's (`mutation.payload` / `args`) origin backward to the
+   action call site. Does the action's argument ever originate from user-controlled input
+   (a route param, a form value, a request body) with no validation between that input and the
+   hook's consumption of it?
+4. If yes and the hook has a side effect on unvalidated content → **HIGH** finding,
+   `untrusted-payload`. Name the specific hook, the specific action/mutation, and the specific
+   unvalidated hop.
+5. If the hook is read-only or the payload is already validated/sanitized before the hook
+   consumes it → not a finding; state this explicitly.
+
+### Anti-pattern (do not approve)
+
+```ts
+// A plugin acts on unvalidated action args reachable from a route param.
+pinia.use(({ store }) => {
+  store.$onAction(({ name, args }) => {
+    if (name === 'updateProfile') {
+      // args[0] flows from a route param with no validation upstream —
+      // writing it straight to an external audit-log API with no sanitization.
+      auditLogApi.post('/log', { field: args[0].bio })
+    }
+  })
+})
+```
+
+## Defect (d), part 2: client-held flags used as an authorization source of truth
+
+### What people get wrong
+
+The naive assumption is:
+
+> "The store says `isAdmin: true` only after the server told us the user is an admin, so
+> checking `store.isAdmin` in the client before calling the delete endpoint is safe."
+
+Wrong. Once a value lives in client-side reactive state, it is client-writable — via browser
+devtools, a `$patch()` call from the console, direct manipulation of a hydrated store, or a
+compromised/malicious browser extension. A store flag is a UI convenience for *display*
+decisions; it is never proof of authorization for a *mutating* decision. The only correct
+authorization boundary is the server independently re-checking the authenticated user's
+permissions when the mutating request actually arrives.
+
+### Review procedure
+
+1. Grep for role/permission-flag reads gating a mutating call: patterns like
+   `if (store.isAdmin)`, `if (userStore.role === 'admin')`, `v-if="store.canDelete"` guarding an
+   action dispatch or a direct API call that performs a write (delete, update, privilege
+   change, financial transaction).
+2. For each match, determine what the guarded code actually does:
+   - Gates only UI visibility (hides/shows a button, disables a form field) with the
+     underlying mutating action's authorization enforced elsewhere → not a finding for that
+     specific gate, but confirm (or explicitly flag as unconfirmed) that the actual mutating
+     endpoint re-authorizes server-side.
+   - Gates whether the mutating network call is *made at all*, with no evidence the server
+     independently re-checks authorization on that request → **HIGH** finding,
+     `client-auth-flag`, regardless of how the flag was originally populated.
+3. If the server-side code implementing the endpoint is not in scope/not provided, say so
+   explicitly as an open question rather than assuming a check exists — do not clear the
+   finding on the assumption that "surely the backend checks this too."
+
+### Anti-pattern (do not approve)
+
+```ts
+// store.isAdmin is client-side reactive state — devtools-patchable.
+async function deleteUser(id: string) {
+  if (userStore.isAdmin) {           // WRONG: client flag treated as the auth boundary
+    await api.delete(`/users/${id}`) // if the endpoint doesn't re-check, this is a
+  }                                   // full broken-access-control vulnerability
+}
+```
+
+### Minimal safe pattern
+
+```ts
+// Client-side check is UX-only (avoids showing an error after the fact);
+// the actual authorization decision is made server-side on every request.
+async function deleteUser(id: string) {
+  if (userStore.isAdmin) {
+    // Optimistic UX gate only — the server independently re-verifies the
+    // caller's role/permissions before performing the deletion.
+    await api.delete(`/users/${id}`)
+  }
+}
+```
+
+Note: the client code above is nearly identical in shape to the anti-pattern — the difference
+is entirely in the server-side endpoint, which is why this defect class requires confirming
+(or explicitly flagging as unconfirmed) the server-side check rather than judging the client
+code in isolation.
+
+## Defect (e): devtools state exposure in production builds
+
+### What people get wrong
+
+The naive assumption is:
+
+> "Devtools only matter in development — production builds strip that stuff automatically."
+
+Not reliably true without an explicit build-time step, and Vuex exposes an *explicit runtime
+option* that can force devtools integration on regardless of environment.
+
+### Officially grounded rule
+
+Vuex's store options API documents a `devtools: boolean` option that "activates or deactivates
+devtools integration for a Vuex instance," called out specifically as useful when running
+multiple stores on a single page (`documentation-based`, via Context7 `/vuejs/vuex`). If a
+production build's store configuration sets `devtools: true` (or leaves a config path that
+defaults to enabling it reachable in production), the full state tree, mutation/action
+history, and time-travel debugging are exposed to anyone with browser devtools open — a
+meaningful exposure if the store holds any sensitive data (tokens, PII, internal flags).
+
+Context7 does not confirm an equivalent `devtools` boolean option on Pinia's `defineStore`/
+`createPinia` APIs — Pinia's devtools integration is wired through the Vue devtools browser
+extension/plugin rather than a store-constructor option. Do not assert a Pinia-specific
+`devtools` config option exists. If a codebase under review appears to force-enable a devtools
+integration in a production build (e.g., an explicit plugin registration reachable in the
+production bundle), flag that as a repo-evidence finding scoped to the specific code found —
+do not generalize it into a claim about a Pinia API that Context7 does not confirm.
+
+### Review procedure
+
+1. Grep store-configuration files for a `devtools:` option (Vuex) and determine whether the
+   value is `true`, absent (check documented default for the version in use), or explicitly
+   tied to an environment check (`process.env.NODE_ENV !== 'production'` or equivalent).
+2. If `devtools: true` (or an unguarded default) is reachable in a production build path →
+   **HIGH** finding, `devtools-exposure`.
+3. If gated behind an environment check that correctly excludes production → not a finding;
+   state this explicitly.
+4. For Pinia codebases, check only for an explicit, repo-specific forced-enable of a devtools
+   plugin in a production bundle path — do not invent or assume a `devtools` constructor
+   option exists on `createPinia()`/`defineStore()`.
+
+### Minimal safe pattern
+
+```js
+// Vuex — devtools explicitly disabled outside development
+const store = createStore({
+  // ...
+  devtools: process.env.NODE_ENV !== 'production',
+})
+```
+
+### Anti-pattern (do not approve)
+
+```js
+// Vuex — WRONG: devtools unconditionally enabled, including in production builds
+const store = createStore({
+  // ...
+  devtools: true,
+})
+```

package/skills/frontend/vue-state-store-security-review/references/workflow-and-output.md

@@ -0,0 +1,142 @@
+# Review Workflow and Findings Contract
+
+Use this reference for the step-by-step review procedure and the required output shape. Load
+the domain references only for the specific defect class the store code under review actually
+raises.
+
+## Prerequisites
+
+- Identify the store library and version in use (`package.json` — `pinia` +
+  `pinia-plugin-persistedstate`, or `vuex` + `vuex-persistedstate`/a custom persistence
+  plugin). API names and defaults differ between the two; do not apply one library's names to
+  the other.
+- Identify whether the app is SSR (an `entry-server.js`/`.ts`, a Nuxt server context, or
+  equivalent request-handling entry point exists). If not SSR, defect class (c) — SSR
+  singleton pollution — and the server-side half of defect class (b) — un-escaped
+  serialization — are out of scope; state this explicitly rather than silently skipping them.
+
+## Workflow
+
+1. **Locate every store definition** (`defineStore(...)` for Pinia, `createStore(...)`/
+   `new Vuex.Store(...)`/module objects for Vuex). For each, read the full `state` shape.
+2. **Classify every state field by sensitivity.** Auth/refresh tokens, session identifiers,
+   API keys, PII (name, email, address, government ID), and any field whose disclosure would
+   aid session hijacking or identity theft are sensitive. UI preferences, non-sensitive display
+   config, and derived/computed-only values are not.
+3. **Trace persistence configuration for every store with a `persist` option (Pinia) or a
+   `vuex-persistedstate`/custom persistence plugin registration (Vuex).** For each, determine:
+   `storage` target (`localStorage` default vs. `sessionStorage` vs. custom), and whether a
+   `pick`/`paths` restriction excludes every sensitive field identified in step 2. See
+   `references/persistence-and-hydration.md`.
+4. **Trace SSR store creation** (if SSR). Determine whether `createPinia()`/`createStore()` is
+   invoked inside the per-request handler function or at module scope, and whether the
+   per-request factory closes over any module-scope mutable/reactive reference. See
+   `references/persistence-and-hydration.md`.
+5. **Trace server-to-client state hydration** (if SSR). Find the server-side serialization of
+   store state into the HTML response (e.g. embedding `JSON.stringify(pinia.state.value)` or
+   `devalue(...)` output in a `<script>` block) and the client-side consumption
+   (`pinia.state.value = JSON.parse(window.__pinia)` or equivalent). Determine whether the
+   serialization step escapes the value for safe HTML embedding, and whether the client applies
+   any validation before hydrating. See `references/persistence-and-hydration.md`.
+6. **Enumerate every store plugin, `$subscribe`, `$onAction` (Pinia), or Vuex plugin/module
+   registration.** For each, trace what the hook does with the mutation/action payload — does
+   it write, call an external API, log, or mutate another store based on unvalidated payload
+   content? See `references/untrusted-payloads-and-authorization.md`.
+7. **Search for client-side role/permission flags used to gate a mutating action** — grep for
+   patterns like `if (store.isAdmin)`, `if (userStore.role === ...)` guarding a network call or
+   a store action that performs a write, and check whether the corresponding server endpoint
+   independently re-authorizes. See `references/untrusted-payloads-and-authorization.md`.
+8. **Check devtools configuration** for a production build — a Vuex `devtools: true` (or
+   unset, since default behavior should be checked against the version in use) in a config
+   file reachable by a production build step, or any explicit repo-specific override that
+   force-enables a devtools integration in production. See
+   `references/untrusted-payloads-and-authorization.md`.
+9. **Produce ranked findings** using the output contract below.
+
+## Decision tree
+
+- Store `state` includes a sensitive field (token/session-id/PII) AND `persist` has no
+  `pick`/`paths` restriction excluding it (or `persist: true`/`persist: {}`) → **HIGH**
+  finding, category `persistence`. Note the `storage` target explicitly (localStorage is worse
+  than sessionStorage, but both are XSS-exfiltratable — do not treat `sessionStorage` alone as
+  clearing the finding for a sensitive field).
+- Store `state` includes a sensitive field AND `pick`/`paths` demonstrably excludes every
+  sensitive field → not a finding for those fields; state this explicitly.
+- Store `state` contains only non-sensitive fields (UI prefs, non-PII display config) →  not a
+  finding regardless of persistence config; state this explicitly rather than omitting the
+  store from the review.
+- Server embeds serialized store state in the HTML response using naive `JSON.stringify`
+  interpolation with no escaping and no `devalue`/equivalent safe-serialization call → **HIGH**
+  finding, category `hydration` (XSS via state-serialization breakout).
+- Client hydrates `pinia.state.value = JSON.parse(window.__pinia)` (or Vuex equivalent) with no
+  shape/schema validation of the parsed result before use → **HIGH** finding, category
+  `hydration` (trusting an untrusted payload), unless the value is proven fully
+  server-controlled with no user-reachable content anywhere in its construction.
+- Server-side serialization is escaped (`devalue` or equivalent) and/or client-side hydration
+  validates shape before use → not a finding; state this explicitly.
+- SSR entry creates `createPinia()`/`createStore()` at module scope, reused across requests →
+  **HIGH** finding, category `ssr-pollution`.
+- SSR entry's per-request factory closes over a module-scope mutable/reactive reference (a
+  cache, a singleton, a mutable default parameter) → **HIGH** finding, category `ssr-pollution`
+  — name the specific closed-over reference.
+- SSR entry creates the store fresh inside the per-request handler with no closed-over mutable
+  state → not a finding; state this explicitly.
+- A `$subscribe`/`$onAction`/Vuex-plugin hook performs a side effect (write/external
+  call/sensitive log/cross-store mutation) using unvalidated payload content that is reachable
+  from user-controlled input (route params, form input, an action argument sourced from a
+  request) → **HIGH** finding, category `untrusted-payload`.
+- A `$subscribe`/`$onAction`/Vuex-plugin hook is read-only (observation, non-sensitive
+  analytics logging) → not a finding; state this explicitly.
+- A client-side role/permission flag gates whether a mutating network call is made, and no
+  server-side re-authorization is visible in the code under review → **HIGH** finding, category
+  `client-auth-flag`. If server-side authorization code is out of scope/not provided, state
+  this as an explicit open question rather than assuming it exists.
+- A client-side role/permission flag gates only UI visibility (hiding a button/menu item) with
+  the actual mutating action separately confirmed to be re-authorized server-side → not a
+  finding; state this explicitly.
+- Devtools integration is explicitly enabled (or left at a default that enables it) in a config
+  path reachable by the production build → **HIGH** finding, category `devtools-exposure`. Do
+  not invent a Pinia `devtools` store option — ground any Pinia-specific devtools concern in
+  the build-time devtools plugin, and label as `inference` unless a concrete repo config is
+  found; ground Vuex findings in the documented `devtools: boolean` store option.
+
+## Output contract
+
+Every response from this skill must return:
+
+1. **Scope** — the store definition(s), persistence config, SSR entry point(s), and/or
+   plugin/hook code reviewed.
+2. **Ranked findings** — each with file:line, defect category (`persistence` / `hydration` /
+   `ssr-pollution` / `untrusted-payload` / `client-auth-flag` / `devtools-exposure`), the
+   concrete data-flow trace (naming every hop), and a fix sketch matching the grounding
+   library's documented pattern.
+3. **Persistence coverage statement** — for every persistence finding, which fields are scoped
+   out by `pick`/`paths` (if any) and which are not.
+4. **Server-authorization statement** — for every client-auth-flag finding, whether a
+   server-side re-check was found, not found, or is out of scope for this review.
+5. **Evidence level per finding** — `repo evidence`, `documentation-based`, or `inference`.
+   Label structural risk findings as structural risk explicitly — do not imply confirmed
+   exploitation without live evidence.
+6. **Verdict** — approve / approve-with-notes / block.
+7. **Open questions or out-of-scope items** — e.g., "confirming actual cross-request leakage
+   requires concurrent-request load testing," "server-side authorization for this action was
+   not in the provided scope," or "v-html/URL-injection review of this same app is out of scope
+   for this skill — see `vue-ssr-security-review`."
+
+## When to push back
+
+Push back if the user asks to:
+
+- approve an unscoped `persist: true` on a store containing a token/session field because "we
+  only persist it for convenience" — convenience is not a mitigant; the field must be excluded
+  via `pick`/`paths` or persistence removed,
+- treat a client-side `isAdmin`/`role` flag as sufficient authorization because "the UI already
+  hides the button" — a hidden button does not stop a direct API call or a devtools-patched
+  store value; the server must re-check,
+- skip the SSR-singleton check because "we haven't seen cross-user leakage in production" —
+  this defect class is structural and often invisible until concurrent load exposes it,
+- accept naive `JSON.stringify` state embedding as "probably fine since it's just our own data"
+  — any state reachable from user-submitted content anywhere upstream needs escaping; assume
+  user-reachability unless proven otherwise,
+- downgrade an untraced `$subscribe`/`$onAction` finding to informational because "it's probably
+  fine" — this skill's default is HIGH for exactly this class of unproven claim.

package/skills/frontend/wcag-22-accessibility-audit/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: wcag-22-accessibility-audit
+description: Audit frontend markup, components, and design-system primitives against WCAG 2.2 Level A/AA success criteria and ARIA APG interaction patterns, separating automated-detectable violations from manual-verification-required items and flagging legal exposure, with reference material loaded progressively per success-criteria category.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-02"
+  category: compliance
+---
+
+# WCAG 2.2 Accessibility Audit
+
+## Purpose
+
+Frontend teams routinely ship components that pass visual QA but fail assistive-technology usage — missing accessible names, keyboard traps, insufficient contrast, non-conformant custom widgets. This skill audits against WCAG 2.2's exact success criteria (all four principles: Perceivable, Operable, Understandable, Robust) and the ACT Rules' machine-testable/manual-only split, without dumping the full 87-criterion spec into every review; it loads only the success-criteria category and evidence tier relevant to the review in scope. It complements — and does not duplicate — `html-semantics-accessibility-review`, which owns deep native-element/ARIA-APG keyboard-pattern matching; this skill owns the full-spectrum SC conformance sweep, automated-vs-manual evidence separation, and legal-exposure triage.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- run a WCAG 2.2 conformance audit across a page, flow, or component library (not just a single widget's ARIA pattern),
+- triage an accessibility bug report, audit finding, or demand letter against specific success criteria,
+- prepare input for a VPAT / accessibility conformance statement,
+- determine whether a finding is machine-testable (cite an ACT rule) or requires manual/assistive-technology verification before it can be closed as passing,
+- assess legal/litigation exposure of a known or suspected accessibility gap.
+
+## Context7 Documentation Protocol
+
+WCAG 2.2 SC wording, technique/failure lists, and ACT rule coverage are living documents (WCAG 2.2 added SC in 2023; techniques and ACT rules are updated independently of the SC text) — never assert SC numbering, level, or technique applicability from memory.
+
+1. Call `ToolSearch` with query `"context7"` (or `"select:mcp__Context7__resolve-library-id,mcp__Context7__query-docs"`) to load the Context7 tools if not already loaded in this session.
+2. Call `mcp__Context7__resolve-library-id` for `web.dev` (prefer `/googlechrome/web.dev` or `/websites/web_dev_learn`) when grounding testing-methodology claims (automated vs manual coverage limits, tool selection factors) — these are documented, not folklore.
+3. Call `mcp__Context7__query-docs` for the specific claim in question — e.g. "automated accessibility testing coverage limitations", "color contrast calculation formula", "focus not obscured success criterion" — before stating it as fact. Do this per audit, not once from a prior session's memory.
+4. For primary normative text (exact SC wording, Level, technique/failure IDs, ACT rule text), prefer the W3C URLs in `official_docs` over Context7 paraphrase — Context7 is for grounding testing-methodology and coverage claims, not for replacing the normative spec text itself.
+5. If Context7 is unavailable or returns no relevant match, fall back to the `official_docs` URLs and `references/` files, and mark the claim `documentation-based (Context7 unavailable)` instead of presenting it as freshly verified.
+6. Never invent a WCAG 2.2 success-criterion number, Level, technique ID, or ACT rule ID that no queried source confirms.
+
+## Lean operating rules
+
+- First classify the review scope: full-conformance audit (all applicable SC) vs targeted-criteria review (e.g. "just check contrast and focus") vs single-finding triage. Do not run a full sweep when the user asked about one criterion.
+- Separate every finding into exactly one of two evidence tiers — automated-detectable (contrast ratio, missing alt text, form-label association, duplicate IDs, missing document language, empty links/buttons) or manual-required (meaningful sequence, focus order intent, sensory characteristics, actual assistive-technology walkthrough, cognitive-load judgment calls) — and never present a manual-required item as closed by automated tooling alone.
+- Automated tooling (axe-core-class scanners, Lighthouse) is documented as catching a minority of real-world WCAG issues and can produce false positives — treat a clean automated scan as a floor, not a conformance claim, and say so explicitly in the report.
+- For any custom interactive widget, defer keyboard-pattern/ARIA-role correctness to `html-semantics-accessibility-review`'s APG matching rather than re-deriving it here; this skill's job is mapping the widget's *failure* to the correct SC and Level, and the litigation-exposure severity, not re-doing the pattern audit.
+- Never recommend an accessibility overlay or "auto-remediation" widget script as a fix; recommend the underlying semantic-markup, contrast, or structural change and cite the SC it resolves.
+- Cite the exact WCAG 2.2 success-criterion id and Level for every finding (e.g. "2.4.11 Focus Not Obscured (Minimum) — AA"), never a vague "accessibility issue" or bare SC number without Level.
+- Flag SC with documented high litigation exposure (1.4.3 Contrast Minimum, 2.1.1/2.1.2 Keyboard, 2.4.7 Focus Visible, 2.4.11 Focus Not Obscured, 4.1.2 Name Role Value, 1.1.1 Non-text Content) with elevated severity and an explicit legal-exposure note.
+- Load reference files only for the SC category and evidence question actually in scope; do not preload the full SC index for a single-criterion triage.
+
+## References
+
+Load these only when needed:
+
+- [WCAG 2.2 success-criteria index](references/wcag22-sc-index.md) — use for the full A/AA success-criteria list grouped by POUR principle, with automated-vs-manual detectability and new-in-2.2 flags, when scoping which criteria apply to a review.
+- [ACT Rules detection boundary](references/act-rules-detection-boundary.md) — use when a finding needs an explicit machine-testable-vs-manual-only determination, citing the relevant ACT rule id, before closing or escalating it.
+- [Legal exposure and severity model](references/legal-exposure-severity.md) — use when triaging a finding's litigation risk, prioritizing a remediation backlog, or preparing input for a VPAT/conformance statement.
+
+## Response minimum
+
+Return, at minimum:
+
+- the component/page/criteria category in scope,
+- each finding mapped to an exact WCAG 2.2 SC id, Level (A/AA), and automated-vs-manual evidence label,
+- evidence level for the finding itself (automated scan output, manual code review, live AT verification, or documentation-based inference),
+- safest remediation with a technique/SC reference, not an overlay or workaround,
+- explicit statement of what was NOT verified (manual checks not performed, AT combinations not tested) so no false conformance claim is implied,
+- legal-exposure flag (elevated/standard) for any finding touching a high-litigation-risk SC.