@raishin/vanguard-frontier-agentic 3.0.1 → 3.1.0

package/skills/frontend/vue-ssr-security-review/references/cross-request-state-pollution.md

@@ -0,0 +1,98 @@
+# Cross-Request State Pollution
+
+Use this reference only when reviewing an SSR entry point, tracing app/store/router creation, or investigating a suspected cross-request data-leak symptom (a user reporting they saw another user's data on load).
+
+## What people get wrong
+
+The naive assumption is:
+
+> "The server renders each request separately, so state can't leak between users."
+
+Wrong. A Node.js SSR server is a single long-lived process handling many concurrent requests on shared module-level memory. If the Vue app instance, its store, or any reactive state it reads is created once at module load time — rather than freshly for each request — every request after the first reads and mutates the *same* in-memory objects. One user's session data, cart contents, or auth state can render into another user's response. This is not a rare edge case; it is the default failure mode of naively porting client-only Vue code to an SSR entry point.
+
+## Officially grounded requirement
+
+Vue's own server-side-rendering guidance is explicit and non-negotiable on this point: **each incoming request must get a fresh, isolated instance of the root Vue app** (and, by extension, any store or router it depends on) rather than sharing one instance across requests. This is the single most important structural rule for SSR safety and is documented as a requirement, not a recommendation (`documentation-based`, Vue SSR guide).
+
+The practical shape of the rule:
+
+- The SSR entry point exports (or defines inline) a per-request factory function.
+- That factory function is invoked once per incoming request.
+- Inside that factory, `createSSRApp()` (or the toolchain-equivalent app-creation call) runs fresh — along with any Pinia/Vuex store instance and router instance the app needs — and only *that* freshly created instance is used to render the current request's response.
+- Nothing about the freshly created instance is retained, cached, or reused for a subsequent request.
+
+## Non-negotiable design rules
+
+### 1. Trace app creation to its actual call site, not its apparent location
+
+Do not accept "there's a `createSSRApp()` call in this file" as sufficient. Confirm it executes *inside* the function that runs per request, not at module top level where it would execute once when the server process starts.
+
+### 2. Store and router instances follow the same rule as the app instance
+
+A correctly per-request `createSSRApp()` call does not fix a module-scope Pinia store or a module-scope router instance created once and imported into every request's app tree. Check store/router creation with the same rigor as the app instance itself — these are frequently overlooked because the app-creation call "looks right" while the store creation nearby does not.
+
+### 3. Closures over shared mutable state defeat an otherwise-correct factory
+
+A per-request factory function that itself creates a fresh app can still leak if it closes over a module-level cache, singleton, or a mutable default parameter supplied from outer scope. Read the full body of the factory function, not just its `createSSRApp()` line — check every variable it references from enclosing scope, and classify each as immutable/safe or mutable/reactive/shared.
+
+### 4. Immutable constants are not the risk; mutable and reactive state is
+
+A module-scope `const ROUTES = [...]` frozen route table, a static config object with no runtime mutation path, or a compiled template string is safe to share across requests — it never changes after module load. The risk is specifically state that is either declared with `ref()`/`reactive()` (Vue's reactivity primitives, which are designed to be mutated and observed) or is a plain mutable object/array that request-handling code writes to. Classify every module-scope declaration on this axis before flagging it.
+
+### 5. Reachability from the SSR-rendered tree is required for a finding
+
+A mutable module-scope object that no SSR-rendered component or composable ever imports, reads, or writes is not a reachable risk in this review's scope (it may still be dead code or a different kind of bug, but it is not a cross-request pollution finding). Trace the import graph from the flagged declaration to at least one component or composable actually rendered during SSR before calling it a finding.
+
+## Minimal safe implementation pattern
+
+The safe shape, matching Vue's documented guidance:
+
+```js
+// entry-server.js
+export async function render(url, context) {
+  // Fresh, per-request instances — nothing here is created at module scope.
+  const { app, router, store } = createApp()
+
+  router.push(url)
+  await router.isReady()
+
+  // Populate store state for this request only; store was just created above.
+  const html = await renderToString(app, context)
+
+  // app, router, store all go out of scope when this function returns.
+  return html
+}
+```
+
+Anti-pattern (module-scope creation — do not approve):
+
+```js
+// entry-server.js — WRONG: created once at module load, shared across all requests
+const app = createApp()
+const store = createStore()
+
+export async function render(url, context) {
+  router.push(url)
+  await router.isReady()
+  return renderToString(app, context) // every request renders the SAME app/store instance
+}
+```
+
+## Adversarial checklist
+
+Before clearing an SSR entry point as safe from cross-request pollution, answer these:
+
+- Does the app-creation call execute inside the per-request handler, or at module scope?
+- Does the store (if any) get created fresh inside that same per-request scope, or is it a module-level singleton imported into the app?
+- Does the router get created fresh inside that same per-request scope?
+- Does the per-request factory function close over any variable from its enclosing module scope that is mutable or reactive?
+- Is there any module-scope cache (e.g., a component-render cache, a computed-property memoization keyed loosely, a "last user" convenience variable) that a developer might have added for performance and forgotten carries cross-request state?
+- If two requests from different users hit this entry point concurrently, is there any shared object either request's handling code could write to that the other request's handling code could read?
+
+If any answer reveals a "yes" to shared mutable reachable state, or the app/store/router creation cannot be confirmed as per-request, the finding is HIGH and structural — report it even without a reproduced incident.
+
+## Verification targets
+
+- Grep the SSR entry file for `createApp(` / `createSSRApp(` / `createStore(` / `createRouter(` and confirm each call site's enclosing scope (module-level `import`/top-level statement vs. inside an exported/invoked function).
+- Grep for `let `/`var `/mutable `const` object or array literals at module scope in files imported by the SSR entry point or any SSR-rendered component.
+- Grep for `ref(`/`reactive(` calls outside of a component's `setup()` or a composable function body — a `ref()`/`reactive()` call at true module scope (not inside any function) is the clearest structural signal of this defect class.

package/skills/frontend/vue-ssr-security-review/references/injection-and-dynamic-urls.md

@@ -0,0 +1,120 @@
+# Injection: v-html and Dynamic URL Bindings
+
+Use this reference only when the review scope includes a `v-html` usage or a dynamic `:href`/`:src` binding. The OWASP XSS citation below is loaded only when a `v-html` finding is actually present in the review — do not cite it preemptively in a review that has no `v-html` usage.
+
+## What people get wrong
+
+The naive assumption is:
+
+> "Vue escapes everything by default, so if I'm using `v-html` I must already know it's a special case and I've handled it."
+
+Partially wrong. Vue's default text interpolation (`{{ }}`) does auto-escape, and that is precisely why `v-html` exists as an explicit escape hatch — but "I chose `v-html` on purpose" is not the same as "I sanitized the content that flows into it." The recurring real-world failure is not developers being unaware `v-html` is dangerous; it is developers sanitizing at one layer (e.g., a markdown renderer) while a *different* unsanitized value reaches the same `v-html` binding through a later code change, or trusting a third-party API response as "safe" because it isn't literally user-typed input even though it echoes user-submitted content back.
+
+## Officially grounded rules
+
+Vue's own security best-practices guidance states directly:
+
+- **`v-html` on untrusted content is unsafe.** Dynamically rendering arbitrary HTML on your site via `v-html` can be dangerous because it can easily lead to XSS vulnerabilities. Only use `v-html` on content you can trust to be safe, or content sanitized by a dedicated library before it reaches the binding (`documentation-based`, Vue security guide).
+- **Dynamic attribute/URL bindings need scheme validation.** Vue's docs specifically call out `:href`/`:src`-style dynamic bindings as an injection surface distinct from `v-html`: unvalidated user-provided URLs bound dynamically can carry a `javascript:` (or similarly dangerous non-`http(s)`) scheme, executing script when the element is interacted with, even though no HTML markup or `v-html` was involved.
+- **Template injection is a separate, related risk** for any code path that compiles user-supplied strings as Vue templates at runtime — out of scope for a typical SSR entry/template review unless the app does this explicitly (e.g., a CMS that lets users author raw Vue template syntax); flag its presence if found, but it is not the default pattern to hunt for.
+
+The low-level mechanism, confirmed by Vue's own compiler source (`repo evidence` via Context7 `/vuejs/vue`): `v-html` compiles directly to setting the element's `innerHTML` DOM property with the bound value stringified — there is no implicit sanitization step anywhere in that compilation path. Sanitization, if it happens at all, must be applied by application code before the value reaches the binding.
+
+## Non-negotiable design rules
+
+### 1. Trace the full origin-to-sink path before judging a v-html binding
+
+Do not evaluate `v-html="someVar"` in isolation. Follow `someVar` backward: is it a literal string in the template file? A prop? A computed value derived from store state? Store state populated from an API response? An API response that itself echoes a value the current user (or any user) submitted at some point? The finding depends on where that trace terminates, not on the binding syntax alone.
+
+### 2. A sanitizer import elsewhere in the codebase does not clear a specific finding
+
+If the trace reveals user-reachable input reaching a `v-html` binding, the only thing that clears the finding is a *named sanitizer call* (e.g., `DOMPurify.sanitize(...)`) visibly present *on that exact path* — between the untrusted origin and the binding. "This codebase has a `sanitizeHtml` utility used elsewhere" is not evidence the specific path under review calls it.
+
+### 3. Third-party API responses are not automatically trusted
+
+An API response is not "safe by default" just because it did not come directly from the current request's form input. If the API itself stores and echoes content that any user (not necessarily the current one) previously submitted — a comment system, a CMS with contributor accounts, a product-review feed — that response is user-reachable input for this review's purposes and needs the same sanitizer-on-path check.
+
+### 4. Dynamic URL bindings need scheme validation, not HTML sanitization
+
+`:href`/`:src` bindings are a distinct injection surface from `v-html` — do not conflate the two fixes. The correct control for a dynamic URL binding fed by user-reachable input is scheme validation (an allowlist accepting only `http:`/`https:`/`mailto:` as appropriate, rejecting `javascript:` and other schemes), not HTML sanitization. A `v-html`-appropriate sanitizer call does not clear a URL-injection finding and vice versa.
+
+### 5. Origin-controlled content is not automatically a false positive to skip silently
+
+If a `v-html` trace terminates at fully origin-controlled content (static marketing copy authored only through the app's own trusted CMS with no user-submission path anywhere upstream), it is correctly not a finding — but state this explicitly in the output rather than omitting the binding from the review entirely. A future code change could introduce a user-reachable path into the same binding, and an explicit "reviewed, not a finding, because X" record is more useful than silence.
+
+## Minimal safe implementation pattern
+
+```vue
+<script setup>
+import DOMPurify from 'dompurify'
+import { computed } from 'vue'
+
+const props = defineProps<{ rawComment: string }>()
+
+// Sanitizer call sits directly on the path between the untrusted prop and the binding.
+const safeComment = computed(() => DOMPurify.sanitize(props.rawComment))
+</script>
+
+<template>
+  <div v-html="safeComment"></div>
+</template>
+```
+
+Anti-pattern (untraced or missing sanitizer — do not approve):
+
+```vue
+<template>
+  <!-- userBio comes from a profile API that echoes user-submitted text.
+       No sanitizer call anywhere between the API response and this binding. -->
+  <div v-html="userBio"></div>
+</template>
+```
+
+Dynamic URL scheme validation:
+
+```vue
+<script setup>
+const ALLOWED_SCHEMES = ['http:', 'https:', 'mailto:']
+
+function safeHref(url) {
+  try {
+    const parsed = new URL(url, window.location.origin)
+    return ALLOWED_SCHEMES.includes(parsed.protocol) ? url : '#'
+  } catch {
+    return '#'
+  }
+}
+</script>
+
+<template>
+  <a :href="safeHref(userProvidedUrl)">Link</a>
+</template>
+```
+
+## Adversarial checklist
+
+Before clearing a `v-html` binding, answer these:
+
+- What is the literal origin of the bound value — a template literal, a prop, computed state, store state, or an API response?
+- Does any point along that trace involve content any user (current or otherwise) previously submitted?
+- Is there a named sanitizer call visible on the exact path traced, or only "a sanitizer exists somewhere in this codebase"?
+- Could a later code change (a refactor that swaps the data source, or a new field added to an existing API response) reach this same binding without re-triggering a security review?
+
+Before clearing a dynamic `:href`/`:src` binding, answer these:
+
+- Does the bound value's origin include user-reachable input?
+- Is there scheme validation (allowlist) on the path, or only implicit trust that "URLs are just links"?
+- Would a crafted `javascript:` (or `data:`, `vbscript:`) value reach this binding unmodified?
+
+If any answer is unclear or reveals a gap, the finding is HIGH (for `v-html`) or MEDIUM-to-HIGH (for URL bindings, per reachability) — do not soften it to "worth double-checking."
+
+## OWASP grounding (load only when a v-html finding is present)
+
+Cross-Site Scripting (XSS) is the general vulnerability class that unsanitized `v-html` produces: an attacker-controlled or attacker-influenced string is rendered as live HTML/script in another user's browser session. The OWASP XSS reference and OWASP Top Ten (both listed in this skill's `official_docs`) provide the vendor-neutral grounding for why this defect class is treated as HIGH severity by default — it typically enables session/token theft, credential harvesting via injected forms, or full account takeover in the victim's authenticated context, not merely a cosmetic rendering issue. Cite these only in the specific finding write-up for a confirmed or suspected `v-html`/XSS defect, not as boilerplate in every review.
+
+## Verification targets
+
+- Grep the template scope (`.vue` files, render functions) for `v-html` and enumerate every match.
+- Grep for `:href=` and `:src=` bindings (and their shorthand `v-bind:href=`/`v-bind:src=`) bound to a non-literal expression.
+- For each match, grep backward through the component's props, computed properties, and any imported store/composable for the value's origin.
+- Grep for a sanitizer import (`dompurify`, or an equivalent project-specific sanitizer utility) and confirm its call site is on the traced path, not merely present in the file or module.

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

@@ -0,0 +1,48 @@
+# Review Workflow and Findings Contract
+
+Use this reference for the step-by-step review procedure and the required output shape. Load the other two references only for the specific defect class the SSR code or template under review actually raises.
+
+## Prerequisites
+
+- Confirm the app is actually SSR: a request-handling entry point exists (`entry-server.js`/`.ts`, a Nuxt/framework server route, or equivalent) that renders Vue output on the server per incoming request. If no such entry point exists, cross-request state pollution is out of scope — flag this explicitly and move directly to the injection-only concerns (`v-html`, dynamic URL bindings), which apply to any Vue app regardless of rendering mode.
+- Identify the Vue major and SSR toolchain in use (`package.json` — `vue`, `vue-server-renderer` for Vue 2, `@vue/server-renderer` or a meta-framework for Vue 3). Per-request creation APIs and exact guidance differ by major.
+
+## Workflow
+
+1. **Locate every SSR entry point.** For each, read the full request-handling function from the top.
+2. **Trace app/store/router creation.** For each entry point, determine whether `createSSRApp()` (or the toolchain's equivalent app-factory call) — and any store (Pinia/Vuex) or router instance the app depends on — is created *inside* the per-request handler function, freshly, for every request. See `references/cross-request-state-pollution.md` for the decision tree.
+3. **Enumerate module-scope declarations reachable from SSR-rendered components.** Grep for `ref()`, `reactive()`, plain mutable object/array literals, and module-level caches or singletons declared outside any per-request factory function. For each, check reachability: is it imported, read, or written by any component or composable in the SSR-rendered component tree?
+4. **Enumerate every `v-html` binding in scope.** For each, trace its data source backward through props, computed values, store state, and API responses to the origin. Determine whether the origin includes user-reachable input (route params, query strings, request bodies, or a third-party API response that itself echoes user input) and whether a named sanitizer call sits on that exact path. See `references/injection-and-dynamic-urls.md`.
+5. **Enumerate every dynamic `:href`/`:src` binding in scope.** For each, trace its data source the same way. Check for scheme validation (an allowlist rejecting `javascript:` and other non-`http(s)` schemes) when the source includes user-reachable input.
+6. **Produce ranked findings** using the output contract below.
+
+## Decision tree
+
+- SSR entry point creates the app/store/router at module scope (outside the per-request handler) → **HIGH** finding, cross-request state pollution risk. Cite the Vue SSR guide's per-request-instance requirement directly (`documentation-based`).
+- SSR entry point's per-request factory function closes over a shared module-level mutable cache, singleton, or default parameter from outer scope → **HIGH** finding — the factory pattern alone does not guarantee isolation; name the specific closed-over reference.
+- A mutable or reactive module-scope declaration (not an immutable constant) is reachable — read or written — from any SSR-rendered component's render path → **HIGH** finding regardless of whether pollution has been observed yet; the risk is structural, not conditional on an incident report.
+- Module-scope declaration is an immutable, non-reactive constant (static config, compiled route table, frozen lookup object) with no runtime mutation path → not a finding.
+- `v-html` binding's traced data source includes user-reachable input and no sanitizer call is present on that exact path → **HIGH** finding, XSS. Do not accept "a sanitizer exists elsewhere in this codebase" as clearing this — the trace must show the sanitizer on the specific path reviewed.
+- `v-html` binding's traced data source is fully origin-controlled with no user-reachable input anywhere in the trace (e.g., static marketing copy authored by the app's own CMS with no user-submission path) → not a finding, but state this explicitly in the output rather than silently omitting it.
+- Dynamic `:href`/`:src` binding's traced source includes user-reachable input with no scheme allowlist/validation → **MEDIUM-to-HIGH** finding depending on reachability (public unauthenticated surface vs. requiring an authenticated session to trigger).
+- Dynamic `:href`/`:src` binding's source is either fully origin-controlled or already passes through scheme validation → not a finding.
+
+## Output contract
+
+Every response from this skill must return:
+
+1. **Scope** — the SSR entry point(s), module-scope declarations, and/or template bindings reviewed.
+2. **Ranked findings** — each with file:line, defect category (`state-pollution` / `xss` / `url-injection`), the concrete data-flow trace (the module-scope declaration and its reachability path, or the full origin-to-sink path for the injection finding, naming every hop), and a fix sketch matching Vue's documented pattern.
+3. **Sanitizer status per `v-html` finding** — an explicit statement of whether a sanitizer call is present on the traced path; never infer one exists.
+4. **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 (e.g., a captured cross-user response, a load-test reproduction).
+5. **Verdict** — approve / approve-with-notes / block.
+6. **Open questions or out-of-scope items** — e.g., "confirming actual cross-request leakage requires concurrent-request load testing, not static review," or "hydration-mismatch risk in this same file is out of scope — recommend a hydration-focused review if the framework is Angular-equivalent, otherwise out of scope for this Vue-focused skill."
+
+## When to push back
+
+Push back if the user asks to:
+
+- approve a `v-html` usage because "we sanitize elsewhere in the app" without a sanitizer call visible on the specific traced path — that is not evidence, it is an assumption,
+- treat a per-request `createSSRApp()` call as sufficient in isolation without checking what it closes over — the factory call passing a surface-level check is not the same as proving isolation,
+- skip the cross-request-pollution check because "we haven't seen it happen in production" — this defect class is structural and often invisible until concurrent load or a specific request-timing race exposes it; absence of a reported incident is not evidence of absence of the risk,
+- downgrade an untraced `v-html` finding to informational because "it's probably fine" — this skill's default is HIGH for exactly this class of unproven claim.

package/skills/frontend/vue-state-store-security-review/SKILL.md

@@ -0,0 +1,168 @@
+---
+name: vue-state-store-security-review
+description: Statically review Pinia and legacy Vuex state stores for sensitive data persisted to localStorage/sessionStorage without scoping, untrusted server-payload hydration (window.__pinia/__INITIAL_STATE__) with un-escaped state serialization, SSR store-singleton cross-request pollution, store plugins/$subscribe/$onAction acting on untrusted payloads, client-held role flags used as an authorization source of truth, and devtools state exposure in production builds.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-03"
+  category: security
+---
+
+# Vue State Store Security Review
+
+## Purpose
+
+Review Pinia and legacy Vuex state-store code for the security-critical defect classes that
+are specific to *state stores* as a component — not general Vue architecture, not composable
+design, and not SSR hydration/injection issues that belong to `vue-ssr-security-review`. This
+skill exists to keep the review anchored to five documented defect classes: (a) sensitive data
+persisted client-side without scoping, (b) store hydration from an untrusted server payload
+with un-escaped serialization, (c) SSR store-singleton cross-request pollution, (d) store
+plugins/hooks acting on untrusted payloads and client-held flags used as an authorization
+source of truth, and (e) devtools state exposure in production. It does not re-litigate
+general reactivity/composable architecture, v-html/URL-injection review (covered by
+`vue-ssr-security-review`), or Composition API design quality (covered by
+`vue-composition-api-architecture-review`) in every response.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review a Pinia store definition (`defineStore`) or a legacy Vuex module/store for security
+  issues,
+- assess whether `pinia-plugin-persistedstate` / `vuex-persistedstate` configuration is safe
+  (what gets persisted, and where),
+- review SSR store creation/hydration code (`entry-server.js`, a Nuxt server plugin, an
+  Express/Node handler that constructs `createPinia()`/`createStore()`) for cross-request
+  pollution risk,
+- review a store plugin, `$subscribe`/`$onAction` hook, or Vuex plugin that consumes
+  mutation/action payloads,
+- investigate whether a client-side role/permission flag (`isAdmin`, `role`) is being trusted
+  as an authorization boundary,
+- perform a pre-launch security review of a Pinia/Vuex-based application's state layer.
+
+Do not use this skill for:
+
+- `v-html`/dynamic-URL injection review or SSR entry-point app/router creation — use
+  `vue-ssr-security-review` for those; this skill covers the *store* specifically, not the
+  broader SSR rendering surface (load both skills together if the review spans both),
+- Composition API/composable architecture quality with no security angle — use
+  `vue-composition-api-architecture-review` instead,
+- a general "which state-management library should we pick" architecture decision with no
+  security defect in scope — use `state-management-decision-review` instead,
+- a bug that requires live traffic reproduction (concurrent-request capture, a devtools
+  screen-recording of production, live token exfiltration) to confirm exploitation — static
+  analysis proves the structural risk, not that it has already been exploited.
+
+## Context7 Documentation Protocol
+
+- Resolve library IDs with `resolve-library-id` before citing any store-behavior claim. This
+  skill's three grounding libraries: `/vuejs/pinia` (Pinia core — SSR hydration, plugins,
+  `$subscribe`/`$onAction`), `/prazdevs/pinia-plugin-persistedstate` (persistence defaults and
+  `pick`/`storage` config), `/vuejs/vuex` (legacy Vuex — `state` as function, `devtools`
+  option, plugin/module API).
+- Use `query-docs` against `/prazdevs/pinia-plugin-persistedstate` to confirm persistence
+  defaults before flagging a persistence config: `storage` defaults to `localStorage` when
+  unset; `pick` (an array of dotted state-path strings) restricts persistence to named paths;
+  with no `pick`, the entire state is persisted. Cite these as `documentation-based`.
+- Use `query-docs` against `/vuejs/pinia` to confirm SSR hydration mechanics before flagging a
+  hydration finding: the documented client-side pattern is
+  `pinia.state.value = JSON.parse(window.__pinia)`, and Pinia's own SSR guide states escaping
+  the serialized state is "**VERY important** if the content of the state can be changed by
+  the user, which is almost always the case," recommending `devalue` (or equivalent) over naive
+  `JSON.stringify`. Cite as `documentation-based`.
+- Use `query-docs` against `/vuejs/pinia` to confirm `$subscribe`/`$onAction` hook signatures
+  (mutation object with `type`/`storeId`/`payload`; action object with `name`/`store`/`args`/
+  `after`/`onError`) before describing a plugin-hook finding — do not invent a hook name or
+  argument Context7 does not confirm.
+- Use `query-docs` against `/vuejs/vuex` to confirm the `state: () => ({...})` factory pattern
+  (module reusability without shared state) and the `devtools: boolean` store option before
+  citing either — do not assume Pinia has an equivalent `devtools` boolean on `defineStore`/
+  `createPinia`; Context7 does not confirm that API surface for Pinia, so any Pinia-devtools
+  concern must be scoped to "a build-time devtools plugin explicitly force-enabled in
+  production," not a Pinia store option, and labeled `inference` unless a repo-specific config
+  is found.
+- Read `package.json` first to confirm which store library is in play (`pinia`,
+  `pinia-plugin-persistedstate`, `vuex`, `vuex-persistedstate`) and its major version — API
+  names and defaults differ between Pinia and Vuex and across Vuex 3/4; do not apply one
+  library's API names to the other.
+- If Context7 is unavailable, fall back to the `official_docs` URLs in this skill's
+  `metadata.json` and label the claim `documentation-based, unverified against current
+  release`.
+
+## Lean operating rules
+
+- Findings in every defect class below default to HIGH severity: unscoped sensitive-data
+  persistence, untrusted/un-escaped state hydration, SSR store-singleton pollution, untrusted
+  payload handling in store plugins/hooks, client-side-flag-as-authorization, and production
+  devtools exposure. Do not downgrade a structural finding to MEDIUM because it has not been
+  observed exploited — the risk is in the structure.
+- Trace every finding to a concrete file:line and a concrete data-flow path. "This store might
+  leak sensitive data" or "this hydration looks risky" without naming the specific
+  `persist`/`pick`/`storage` config, the specific module-scope `createPinia()`/`createStore()`
+  declaration, or the specific untraced payload sink is not a valid finding — it is a guess.
+- Before flagging a persistence config, read the full `state()` shape and the full `persist`
+  config together. A `persist: true` (or `persist: {}`) with no `pick`/`paths` array persists
+  the entire state — treat every sensitive field in that state as persisted unless a `pick`
+  list demonstrably excludes it. A `pick` list that omits the sensitive field(s) clears the
+  finding for those fields specifically (not for the whole store, if other sensitive fields
+  remain unscoped).
+- Before flagging SSR store creation as cross-request pollution, confirm mutability/reachability
+  the same way `vue-ssr-security-review` requires for app instances: is the `createPinia()`/
+  `createStore()` call inside the per-request handler, and does that handler close over any
+  module-scope mutable/reactive reference? An immutable module-scope constant (a frozen config
+  object, a static route table) is not the risk; a store instance or mutable cache is.
+- Do not approve a client-side role/permission flag (`isAdmin`, `role`, `permissions`) as an
+  authorization boundary for a mutating action unless the review also confirms (via visible
+  server-side code, or an explicit statement that server-side authorization is out of scope for
+  this static review) that the actual mutation is re-checked server-side. A store flag gating
+  only UI visibility (hiding a button) is not itself a finding; a store flag gating whether a
+  mutating network call is *made* is a finding regardless of UI-layer intent, because the flag
+  is client-writable.
+- Do not treat every `$subscribe`/`$onAction`/Vuex-plugin hook as risky. Only hooks that act on
+  the payload with a side effect (write, external call, log of sensitive data, mutate another
+  store) and lack payload validation are findings; read-only observation (e.g., analytics event
+  naming) is not.
+- Never execute, build, or run application code, and never send live requests, as part of this
+  review; this is a static-review skill (Read/Grep/Glob only).
+- Load only the reference needed for the concern in scope.
+
+## References
+
+Load these only when needed:
+
+- [Review workflow and findings contract](references/workflow-and-output.md) — use for the
+  step-by-step review procedure, the decision tree across all five defect classes, and the
+  required output shape.
+- [Client-side persistence and hydration](references/persistence-and-hydration.md) — load when
+  reviewing `pinia-plugin-persistedstate`/`vuex-persistedstate` configuration, SSR store
+  creation/singleton risk, or server-payload hydration (`window.__pinia`/`__INITIAL_STATE__`).
+- [Untrusted payloads and authorization](references/untrusted-payloads-and-authorization.md) —
+  load when reviewing `$subscribe`/`$onAction`/Vuex-plugin hooks, client-held role/permission
+  flags used for access control, or devtools production exposure.
+- [Acceptance rubric](references/acceptance-rubric.md) — the enumerated defect/false-positive
+  list this skill's rules were authored against; load if you need the underlying catch list
+  rather than the operating rules derived from it.
+
+## Response minimum
+
+Return, at minimum:
+
+- the store definition(s), persistence config, SSR entry point(s), and/or plugin/hook code in
+  scope,
+- ranked findings with file:line evidence, defect category (`persistence`, `hydration`,
+  `ssr-pollution`, `untrusted-payload`, `client-auth-flag`, or `devtools-exposure`), the
+  concrete data-flow trace (state field → persist config, or server payload → hydration call,
+  or module-scope declaration → per-request reachability, or payload → sink), and a fix sketch
+  matching the grounding library's documented pattern,
+- for every persistence finding, an explicit statement of which state fields are covered by
+  `pick`/`paths` (if any) and which are not,
+- for every client-side-flag finding, an explicit statement of whether a server-side
+  authorization re-check was found, not found, or is out of scope for this static review,
+- evidence level per finding (`repo evidence`, `documentation-based`, or `inference`), with
+  structural risk findings explicitly labeled as structural risk, not as confirmed-exploited,
+- verdict (approve / approve-with-notes / block),
+- open questions or scope the review could not cover (e.g., "confirming actual cross-request
+  leakage requires concurrent-request load testing," or "v-html/URL-injection review of this
+  same app is out of scope for this skill — see `vue-ssr-security-review`").

package/skills/frontend/vue-state-store-security-review/metadata.json

@@ -0,0 +1,30 @@
+{
+  "id": "vue-state-store-security-review",
+  "name": "Vue State Store Security Review",
+  "type": "skill",
+  "provider": "frontend",
+  "harnesses": [
+    "claude-code",
+    "cursor",
+    "codex",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Reviews Pinia and legacy Vuex state stores for sensitive data persisted to localStorage/sessionStorage without scoping, untrusted server-payload hydration (window.__pinia/__INITIAL_STATE__) with un-escaped state serialization, SSR store-singleton cross-request pollution, store plugins/$subscribe/$onAction acting on untrusted payloads, client-held role flags used as an authorization source of truth, and devtools state exposure in production builds, grounding claims via Context7 and each library's own documentation.",
+  "source_type": "original",
+  "official_docs": [
+    "https://pinia.vuejs.org/ssr/",
+    "https://pinia.vuejs.org/core-concepts/plugins.html",
+    "https://github.com/prazdevs/pinia-plugin-persistedstate/blob/main/docs/guide/config.md",
+    "https://vuex.vuejs.org/guide/modules.html",
+    "https://vuex.vuejs.org/api/",
+    "https://owasp.org/www-project-top-ten/",
+    "https://owasp.org/www-community/attacks/xss/"
+  ],
+  "security_notes": "This skill's entire scope is security-critical: unscoped client-side persistence of tokens/PII is an XSS-exfiltratable data-exposure vector, untrusted/un-escaped state hydration is an XSS and data-integrity vector, SSR store-singleton pollution is a cross-tenant/cross-user data-exposure defect, untrusted payload handling in store plugins/hooks can drive unsanitized writes or calls, client-held role flags used as an authorization source of truth is a broken-access-control defect, and production devtools exposure leaks the full state tree to any user with browser devtools open. Every finding in this skill defaults to HIGH severity unless proven otherwise with concrete evidence (a pick/paths scope, an escaping call, a per-request creation trace, a server-side re-check). Static-review-only skill: it reads and greps store definitions, persistence config, SSR entry points, and plugin/hook code but never executes, builds, or runs application code, and never sends live requests.",
+  "last_verified": "2026-07-03",
+  "path": "skills/frontend/vue-state-store-security-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/frontend/vue-state-store-security-review/references/acceptance-rubric.md

@@ -0,0 +1,101 @@
+# Acceptance Rubric (write before the rest of the skill — this is the failing test)
+
+This rubric enumerates every defect a correct Vue state-store (Pinia / legacy Vuex) security
+review MUST catch, and the benign patterns it MUST NOT flag. `SKILL.md` and the other
+references are only "done" once every numbered item below is covered by an explicit operating
+rule, decision-tree branch, or reference section. `selfCheck` in the final structured output
+must map each item to the rule/reference that satisfies it.
+
+## MUST CATCH
+
+1. **Sensitive data persisted via `pinia-plugin-persistedstate` / `vuex-persistedstate` with no
+   `pick`/`paths` restriction.** A store whose `state` includes an auth token, refresh token,
+   session identifier, or PII field, and whose `persist: true` (or `persist: {}` with no
+   `pick`/`paths` array) config persists the *entire* state object — the sensitive field rides
+   along by default. `storage` defaults to `localStorage`, which is readable by any script in
+   the page's origin (XSS-exfiltratable, no `HttpOnly`-equivalent protection).
+
+2. **Sensitive data persisted to `localStorage` explicitly (not just by default) when
+   `sessionStorage` or a narrower `pick` would suffice.** E.g. `storage: localStorage` combined
+   with a `pick` list that still includes `token`/`accessToken`/`user.ssn`/etc.
+
+3. **Store hydration from an untrusted/unvalidated server payload.** Client code that reads
+   `window.__pinia`, `window.__INITIAL_STATE__`, or an equivalent global and feeds it directly
+   into `pinia.state.value = JSON.parse(...)` (or assigns into a Vuex store's state) with no
+   schema/shape validation and no evidence the server-side serialization step escaped the value
+   before embedding it in the HTML response.
+
+4. **Un-escaped state serialization into the HTML response on the server side.** Server entry
+   code that builds the embedded state string via naive `JSON.stringify(state)` interpolated
+   directly into a `<script>` block (e.g. a template literal like
+   `` `<script>window.__pinia=${JSON.stringify(state)}</script>` ``) with no escaping of
+   `<`, `>`, `/`, or use of a safe-serialization library (`devalue` or equivalent) — a stored
+   value containing `</script><script>alert(1)</script>` breaks out of the tag and executes.
+
+5. **SSR store singleton created once at module scope instead of freshly per request.** A
+   `const pinia = createPinia()` (or `const store = new Vuex.Store({...})` /
+   `createStore({...})` assigned to a module-level `const`/`let`) declared at the top level of
+   an SSR entry file (`entry-server.js`/`.ts`, a Nuxt server plugin, an Express/Node request
+   handler module) and reused/imported across requests instead of being constructed inside the
+   per-request handler function. This leaks one user's cart/auth/session state into another
+   concurrent user's response.
+
+6. **A per-request store factory that still closes over module-scope mutable/reactive state.**
+   The factory function itself calls `createPinia()`/`createStore()` fresh each invocation, but
+   also reads or writes a module-level cache, singleton, or mutable default parameter from
+   enclosing scope — the factory call looking correct does not prove isolation.
+
+7. **`$subscribe` / `$onAction` plugin hooks (or a Vuex plugin) that consume `mutation`/`args`
+   payloads and act on them (write to a DB, call an external API, log, mutate other stores)
+   without validating/sanitizing the payload shape or origin** — especially when the
+   store/action is reachable from a component that accepts route params, query strings, or
+   other user-controlled input as the action's argument.
+
+8. **Client-side store flags (`isAdmin`, `role`, `isPremium`, `permissions`) used as an
+   authorization source of truth for gating a sensitive action or UI-triggered mutation**,
+   with no corresponding server-side authorization check on the actual mutating request. A
+   client can set/patch its own store state (via devtools, `$patch`, or direct console access),
+   so `if (store.isAdmin) { await deleteUser(id) }` with no server-side re-check is a broken
+   access-control finding, not merely a UX nicety.
+
+9. **Devtools integration left enabled in a production build.** Vuex's `devtools: true`
+   (or an unset/default-true devtools option) shipped in a production store configuration
+   exposes full state-tree contents, mutation/action history, and time-travel debugging to
+   anyone with browser devtools open — a state/PII exposure risk if the store holds sensitive
+   data. (Pinia's devtools integration is dev-only-by-default at build time via the Vue
+   devtools plugin; flag only if a codebase explicitly force-enables it in a production
+   config — do not invent a `devtools` option on Pinia's `defineStore`/`createPinia` APIs,
+   which Context7 does not confirm exists.)
+
+## MUST NOT FLAG (explicit false-positive guards)
+
+10. **An immutable, non-sensitive constant persisted intentionally.** A `pick`-scoped
+    persistence of a UI preference (`theme`, `locale`, `sidebarCollapsed`) with no
+    auth/session/PII content is not a finding, even though it uses `localStorage` — state this
+    explicitly as reviewed-and-cleared rather than omitting it silently.
+
+11. **A store correctly re-created per request.** An SSR entry point whose `createPinia()` (or
+    `createStore()`) call sits inside the exported per-request handler function, with no
+    closed-over mutable module-scope state, is not a finding — do not flag the mere presence of
+    `createPinia()` in an SSR file without checking its enclosing scope.
+
+12. **Server-sent state that is properly escaped/serialized (`devalue` or equivalent) before
+    embedding, and validated/schema-checked on the client before hydration.** Not a finding —
+    state this explicitly as reviewed.
+
+13. **`$subscribe`/`$onAction` hooks used for read-only observation** (e.g. analytics logging
+    of a mutation type, a devtools-only debug logger) with no write/mutating side effect and no
+    unsanitized use of the payload in a sink — not a finding, but note it was reviewed.
+
+14. **A client-side role/flag used only for non-authoritative UI purposes** (e.g. hiding a menu
+    item) where the actual protected action is independently re-authorized server-side — not a
+    finding for that specific action, though the review should still confirm the server check
+    exists rather than assuming it.
+
+## Traceability requirement
+
+Every finding above must cite a concrete file:line and the exact data-flow path (store
+declaration → persistence config / hydration call / SSR entry scope / action-payload sink /
+authorization check) — a finding that says "this store might leak" without naming the specific
+`persist`/`pick`/`storage` config, the specific module-scope declaration, or the specific
+untraced sink is not valid per this skill's traceability rule.