@raishin/vanguard-frontier-agentic 3.0.2 → 3.1.1

package/skills/frontend/product-analytics-experimentation-review/references/consent-and-pii-in-events.md

@@ -0,0 +1,57 @@
+# Consent and PII in Events
+
+Use this reference when reviewing whether tracking calls are properly consent-gated and whether event payloads leak personally identifiable information (PII).
+
+## What people get wrong
+
+The naive story is:
+
+> "We have a cookie consent banner, so our tracking is compliant."
+
+Wrong. A consent banner existing somewhere on the page proves nothing about whether any *specific* tracking call actually respects the user's choice. Compliance is a property of the call site, not the page.
+
+## Officially grounded shape
+
+Per web.dev's Permissions API guidance (`permissions-best-practices`), browser permission state is queried per capability via `navigator.permissions.query({name: ...})`, returns a `state` of `granted` / `denied` / `prompt`, and — critically — **permission grants are scoped per-origin**: a grant on one origin does not transfer to a different origin or subdomain. This same non-transferability logic applies to consent state in analytics/marketing tooling: a consent decision recorded for one property/origin should not be silently assumed to apply to another origin or a cross-subdomain deployment without an explicit, documented consent-propagation mechanism (e.g. a shared consent cookie deliberately scoped for that purpose).
+
+Google's Consent Mode (referenced by GA4 tooling) works by adjusting or blocking specific measurement signals based on granted/denied consent state, rather than by a single all-or-nothing toggle — treat "consent" as a set of distinct signals (e.g. analytics storage, ad storage, ad personalization) each with independent gating, not one binary flag, unless the reviewed implementation is verified via Context7/current docs to behave otherwise.
+
+## Non-negotiable design rules
+
+1. **Consent must be checked at the call site of the tracking function**, immediately before or as a guard condition on the SDK call itself — not only at page load in a separate initialization block that the actual event-firing code doesn't reference. If the tracking call does not read live consent state (or a consent-derived flag) at the point it fires, treat the call as unverified for compliance regardless of banner presence.
+2. **Default state before consent is granted must be "no non-essential tracking"**, not "track now and revoke later" — later revocation does not undo data already collected and transmitted.
+3. **Consent scope is per-origin/per-property by default.** Any claim that a consent decision on one domain covers a subdomain, related property, or downstream data-sharing partner must point to an explicit propagation mechanism (documented shared cookie, server-side consent state sync) — never assume it transfers implicitly.
+4. **Every event-schema field must be classified**: essential/functional (may be exempt from consent gating under most frameworks), or analytics/marketing (must be consent-gated). Do not let a field's classification be assumed from its name alone — check what it actually contains.
+5. **PII must never appear in event payloads in plaintext** — this includes free-text search/input fields, full email addresses, exact geolocation (lat/long or address-level), payment instrument details, and raw URLs containing query-string parameters that carry any of the above. Hash, truncate, bucket (e.g. city-level geo instead of lat/long), or drop these fields before the event is considered shippable.
+6. **A schema field added for a new feature is not "safe by default."** Every new or changed field must be re-evaluated against rules 4 and 5, not grandfathered in because prior fields passed review.
+
+## Minimal safe review flow
+
+1. Enumerate every distinct tracking/event-firing call site touched by the change (not just the SDK initialization).
+2. For each call site, trace backwards to the actual conditional (if any) gating that call on consent state — confirm it reads a live consent value, not a stale/default-true flag.
+3. For each event's payload fields, classify each field as essential, analytics, or marketing, and flag any field whose content could plausibly contain PII regardless of its name.
+4. For any field flagged as potential PII, confirm it is hashed, truncated, generalized (e.g. geo bucketed to region), or removed before the event ships — do not accept "we'll filter it downstream" as sufficient, since the payload has already left the client by then.
+5. If the deployment spans multiple origins/subdomains, confirm the consent-propagation mechanism explicitly, rather than assuming a shared consent state.
+
+## Adversarial checklist
+
+Before approving an instrumentation change as consent/PII compliant, answer these:
+
+- Does the exact line of code that fires this tracking call check a live consent value, or does it fire unconditionally and rely on something else (a tag-manager rule, a server-side filter) to suppress it later?
+- What is the default consent state before the user makes any choice — is non-essential tracking off by default?
+- If this property has multiple subdomains or related origins, is there an explicit, documented mechanism sharing consent state, or is that being assumed?
+- For every new field in this event's payload, what raw value does it actually carry at runtime — has anyone printed a sample payload, or is the field's safety being assumed from its name?
+- If a field carries free text (search box, comment, form input), is there any scrubbing before it reaches the event payload, or does it pass through verbatim?
+
+If any of these cannot be answered, the compliance posture is unverified, not confirmed.
+
+## When to push back
+
+Push back if the user asks to:
+
+- fire analytics/marketing events before consent is granted "just to see the data, we'll filter it later,"
+- treat a consent banner's presence on the page as sufficient evidence that a specific new tracking call is compliant,
+- add a free-text or geolocation field to an event schema without a scrubbing/generalization step,
+- assume a consent decision made on the main domain automatically applies to a newly added subdomain or partner property.
+
+Those are not shortcuts. They are compliance and privacy exposure shipped as a schema change.

package/skills/frontend/product-analytics-experimentation-review/references/privacy-consent-depth-for-analytics.md

@@ -0,0 +1,83 @@
+# Privacy & Consent Depth for Analytics
+
+Use this reference when the review needs standard-specific depth beyond the general consent/PII posture covered in `consent-and-pii-in-events.md` — specifically IAB TCF v2.2 purpose-granular consent, Google Consent Mode v2's default-denied timing requirement, Global Privacy Control / Do-Not-Track honoring, cookie categorization/expiry, and analytics-endpoint data residency. This is static-review guidance only; there is no detection corpus behind it (this skill is not a security-category skill).
+
+## What people get wrong
+
+The naive story is:
+
+> "We call `gtag('consent', 'update', ...)` when the CMP loads, so we're Consent Mode compliant."
+
+Wrong. Consent Mode v2 distinguishes **defaults** from **updates**. The *default* consent state — set before the CMP has rendered or the user has answered anything — must itself be `denied` for the relevant signals, and it must be set **synchronously**, before any `gtag`/GTM tag fragment can fire. An `update` call arriving later is the correct mechanism for what happens *after* the user answers; it does nothing to undo tags that already fired under a missing or async-set default.
+
+A second naive story:
+
+> "We have a TCF consent string cookie (`euconsent-v2`), so every downstream vendor call is covered."
+
+Wrong. TCF v2.2 consent is granular **per purpose ID**, not a single yes/no. A vendor may be consented for "measurement" (Purpose 1/analytics-adjacent purposes) but not for "personalized ads" (Purpose 4) or cross-context targeting. A tracking call that fires because *a* TC string cookie exists, without checking whether *that specific vendor and purpose combination* is granted, is not actually gated — it is gated by presence, not by scope.
+
+## Officially grounded shape
+
+**Google Consent Mode v2 (doc-based, via Context7 `/websites/developers_google_tag-platform_security_guides`):**
+
+- The default consent call must set at minimum all four parameters — `ad_storage`, `analytics_storage`, `ad_user_data`, `ad_personalization` — and per the consent-debugging guide, **"Ensure that the default consent statuses are not set asynchronously"** and the default block "should be placed at the top of your page, before any tag fragments or other code that might use consent settings."
+- The documented pattern is: `gtag('consent', 'default', {ad_storage: 'denied', ad_user_data: 'denied', ad_personalization: 'denied', analytics_storage: 'denied'})` executed synchronously, before the gtag.js/GTM snippet loads — then `gtag('consent', 'update', {...})` later once the user answers the CMP.
+- An optional `wait_for_update` parameter (e.g. `500` ms) exists specifically to give an asynchronous CMP banner time to call `update` before tags evaluate the default state — its presence in an implementation is a signal the team is aware of the timing requirement, not a substitute for a synchronous default block.
+- Treat any implementation that sets defaults inside an async-loaded script, inside a CMP callback, or after the main gtag/GTM snippet as **non-compliant with the documented requirement**, regardless of whether an `update` call exists later.
+
+**IAB TCF v2.2 (standard-based — no TCF library resolved in Context7 at time of review; treat as standard-based inference, not Context7-verified):**
+
+- Consent and legitimate-interest signals are structured **per purpose ID and per vendor**, encoded into a single TC string. A compliant integration checks a specific `(vendorId, purposeId)` pair — commonly via a decoded consent object exposing something equivalent to `vendorConsents.has(purposeId)` — not merely "does a TC string exist."
+- The TC string is the standard mechanism for **communicating** consent state to downstream vendors/partners. A server-side or third-party tracking call that omits the TC string (or an equivalent consent signal) gives the receiving party no way to honor purpose-specific restriction, even if the client-side call itself was gated correctly.
+- Purpose-level gating and vendor-level gating are independent: a vendor consented for one purpose is not automatically consented for another. Do not treat "CMP shows a green banner" as equivalent to "this specific vendor/purpose pair is granted."
+
+## Non-negotiable design rules
+
+1. **Consent Mode defaults must be synchronous and denied-by-default**, set in the page `<head>` before the gtag.js/GTM snippet and before any `gtag('event', ...)` call — not inside a CMP callback, not behind a `DOMContentLoaded`/async script boundary.
+2. **No tracking call — pixel, `gtag`, `sendBeacon`, `fetch`, image-tag — fires before a consent signal exists**, whether that signal is a Consent Mode default/update pair or a decoded TCF TC string. "We'll gate it with CSS/display:none" or "we'll filter server-side" does not prevent the HTTP request from having already left the client with its payload.
+3. **PII must never ride in event properties**, regardless of consent state: raw email address, full legal name, unhashed user ID, phone number, precise address. Consent governs *whether tracking may happen*, not *what may be sent once it does* — a consented-but-PII-laden event is still a data-minimization violation.
+4. **Every cookie set by analytics/marketing code must be categorized (essential / functional / analytics / marketing) and carry an explicit, bounded expiry.** An uncategorized cookie cannot be selectively cleared by a CMP, and an unbounded/session-spanning expiry on a cookie that should be short-lived is itself a flag.
+5. **Global Privacy Control (`navigator.globalPrivacyControl === true`) and Do-Not-Track (`navigator.doNotTrack === "1"`) must be checked and honored as an opt-out signal** for non-essential tracking, alongside — not instead of — explicit CMP consent state. Treat code that reads a TC string or Consent Mode flag but never checks `navigator.globalPrivacyControl`/`doNotTrack` as an incomplete opt-out surface.
+6. **Data residency of the analytics endpoint must be identified, not assumed.** Note whether the destination (vendor domain, region-specific ingestion endpoint, self-hosted collector) is documented against any residency commitment made to users (e.g. "EU data stays in the EU"); flag payloads sent to a default/global endpoint when a residency-scoped endpoint is available and expected.
+
+## Minimal safe review flow
+
+1. Find the Consent Mode default-consent call (if Google tooling is in use). Confirm it (a) sets all relevant parameters to `denied`, (b) executes synchronously in `<head>`, before the gtag.js/GTM snippet — not inside a CMP callback or async script.
+2. Find every tracking call site (pixel `<img>`/`new Image()`, `gtag('event', ...)`, `sendBeacon`, `fetch` to an analytics/marketing endpoint). For each, confirm it is temporally *after* a consent signal is available — not merely after the page has "loaded."
+3. If TCF is in use, confirm the guarding logic checks a specific vendor/purpose pair from the decoded TC string, not just TC-string presence.
+4. For each event's payload, scan for PII fields regardless of consent state (see `consent-and-pii-in-events.md` rule 5 for the field list).
+5. List every cookie set by the code under review; confirm each has a declared category and an explicit `Max-Age`/`Expires` — flag any cookie set without either.
+6. Confirm the code checks `navigator.globalPrivacyControl` and/or `navigator.doNotTrack` and suppresses non-essential tracking when either signals opt-out, independent of CMP state.
+7. Identify the destination host/endpoint of each analytics call and note whether it matches any stated data-residency commitment; flag mismatches as unverified, not assumed-fine.
+
+## Concrete sinks to grep for
+
+- **Unguarded pixel/image tracking**: `<img src="https://` or `new Image().src =` pointed at a tracking/analytics domain, with no preceding consent/TC-string/Consent-Mode check in the same code path. Risk: the HTTP GET — and any query-string PII on it — is unrecoverable once sent, unlike a suppressed JS event.
+- **`gtag('event', ...)` before `gtag('consent', 'default', ...)`**: search for `gtag('event'` occurrences and confirm a `gtag('consent', 'default'` call precedes them in load order (ideally same `<head>` block, before the gtag.js `src` script tag). Risk: Consent Mode has no default state yet, so Google's tags apply undefined/permissive behavior.
+- **PII literals in event payload construction**: `email`, `user.email`, `fullName`, `userId` (raw, unhashed) passed directly into an analytics `track()`/`gtag('event', ...)`/`sendBeacon()` call's properties object. Risk: PII leaves the client in plaintext regardless of consent state.
+- **Cookie set without `Max-Age`/`Expires` and without a category comment/constant**: `document.cookie = "<name>=<value>"` with no `Max-Age=`/`Expires=` attribute, or a cookie name with no mapping in a consent-category config. Risk: cannot be selectively honored, cleared, or excluded by a CMP.
+
+## Adversarial checklist
+
+- Is the Consent Mode (or equivalent) default set synchronously in `<head>`, or does it live behind an async script/CMP callback where tags could fire first?
+- Does the code check a *specific* vendor/purpose grant from the TC string, or only "a TC string cookie is present"?
+- Does any tracking call — pixel, beacon, fetch — execute before any consent signal (default, TCF string, or otherwise) is available at all?
+- Does any event payload carry a raw email, name, phone number, or unhashed user ID, independent of whether consent was granted?
+- Does every cookie set by this code have both a declared category and an explicit expiry, or are any "just set and never revisited"?
+- Does the code check `navigator.globalPrivacyControl` / `navigator.doNotTrack` and suppress non-essential tracking on either signal, or does it only look at CMP-recorded consent?
+- Is the destination endpoint for this analytics call known and checked against any data-residency commitment, or is "it's probably fine" being assumed?
+
+If any of these cannot be answered from the code itself, treat the privacy/consent posture as **unverified**, not compliant.
+
+## When to push back
+
+Push back if the user asks to:
+
+- ship a Consent Mode default that is set asynchronously or after the gtag.js/GTM snippet, "since we'll call update quickly anyway,"
+- gate a tracking call on "a TC string cookie exists" rather than the specific vendor/purpose grant it needs,
+- add a raw email/name/unhashed user ID to an event's properties because "it's useful for support lookups,"
+- set a new analytics/marketing cookie without an expiry or category because "we'll clean it up later,"
+- skip checking Global Privacy Control/Do-Not-Track because "the CMP already covers consent,"
+- send analytics payloads to a default global endpoint when a region-scoped endpoint exists and residency commitments apply.
+
+Those are not shortcuts. They are unrecoverable data exposure and standards non-compliance shipped as an analytics change.

package/skills/frontend/product-analytics-experimentation-review/references/srm-and-bucketing-integrity.md

@@ -0,0 +1,64 @@
+# SRM and Bucketing Integrity
+
+Use this reference when auditing user-assignment/bucketing logic for an A/B or multivariate experiment, or when diagnosing a suspected sample-ratio mismatch (SRM).
+
+## What people get wrong
+
+The naive story is:
+
+> "We split traffic 50/50 in the config, so the experiment is randomized correctly."
+
+Wrong. A correct config value does not guarantee correct *realized* assignment. SRM — where the observed split between variants diverges from the configured split by more than chance — is one of the most common silent killers of experiment validity, and it is caused by implementation bugs, not by the experimentation platform's randomization algorithm.
+
+## Common root causes of SRM
+
+- **Non-deterministic bucketing**: assignment computed from `Math.random()` or an unseeded RNG on each page load/render instead of a stable hash of a persistent identifier (user ID, device ID, or a consistently-stored anonymous ID). This causes the same user to bounce between variants across requests, corrupting both the split and the per-user experience.
+- **Redirect/loading-time asymmetry**: one variant triggers a client-side redirect or has a slower paint path, so users on slow connections/devices disproportionately bounce before the exposure event fires, undercounting that variant.
+- **Bot/crawler contamination**: bot traffic is not filtered before assignment and is unevenly distributed across variants (e.g. one variant's URL gets crawled more).
+- **Caching bypass**: a CDN or browser cache serves a cached response for one variant to users who should have been freshly assigned, without going through the bucketing code path at all.
+- **Post-assignment filtering that isn't symmetric**: an error-handling or feature-guard path silently excludes users from one variant's exposure logging but not the other's (e.g. a try/catch around only the treatment code path).
+- **Multiple exposure events per user**: a user is bucketed once but the exposure/"experiment viewed" event fires multiple times (e.g. once per re-render), inflating one variant's logged count without inflating actual unique users.
+
+## Non-negotiable design rules
+
+1. **Assignment must be deterministic per stable identifier.** Given the same user identifier and experiment ID, the bucketing function must return the same variant every time, computed via a consistent hash (not re-rolled per request). If the review cannot point to the exact hash/seed input, treat this as a blocking finding.
+2. **The identifier used for bucketing must survive the user's session.** An identifier that resets on page reload, tab close, or unauthenticated-to-authenticated transition will fragment the same real user across variants — verify what the identifier actually is (cookie, local storage, logged-in user ID) and its persistence.
+3. **The exposure/assignment log event must fire exactly once per unique assigned user**, at the point the user is committed to see the variant-specific experience — not on every render, not before the variant is actually applied, and not skipped on an error path.
+4. **Bot and internal-traffic filtering must run before or as part of assignment**, and must be applied identically to all variants — an asymmetric filter is itself an SRM source.
+5. **The chi-squared goodness-of-fit test is the standard tool for detecting SRM** on the ratio between logged variant counts and the configured allocation ratio; a low p-value (commonly p < 0.001 is used as a conservative SRM-alert threshold given how much SRM checks are run) on that test at meaningful sample volume is a signal to halt and debug before trusting any of the experiment's results, not something to explain away as "probably fine."
+
+## Minimal safe review flow
+
+1. Identify the exact code path that computes variant assignment. Confirm it is a pure function of `(stable_user_id, experiment_id)` via a documented hash — not `Math.random()`, not time-based, not re-evaluated per render.
+2. Confirm the identifier's lifetime matches or exceeds the experiment's intended duration and survives the user journeys the experiment covers (e.g. anonymous → logged-in transition, cross-device if applicable).
+3. Trace the exposure-logging call site: confirm it fires once per assigned user, only after the variant is actually rendered/applied (not merely "assigned" in memory before an early return/error).
+4. Check for asymmetric guards: any `try/catch`, feature flag, cache rule, or redirect that could apply to one variant's code path but not the equivalent point in the other variant's path.
+5. If actual counts are available, compute the chi-squared statistic against the configured ratio; treat a materially significant deviation as a blocking finding requiring root-cause before results are trusted.
+
+## Adversarial checklist
+
+Before approving an experiment's bucketing as sound, answer these:
+
+- What exact value is hashed to produce the variant assignment, and where is it read from?
+- Does that value exist and stay stable before the user has logged in, accepted cookies, or completed onboarding?
+- Is there any code path (error handler, feature gate, redirect, cache rule) that can prevent the exposure event from firing for one variant but not the other?
+- If a user's assignment identifier changes mid-experiment (e.g. anon ID merges into logged-in ID), what happens to their variant — do they get reassigned, and if so, does that reassignment apply identically across variants?
+- Has anyone actually looked at the realized split of exposure-event counts, or is "50/50" only ever been checked in the config file?
+
+If any of these cannot be answered, the SRM risk is unverified, not absent.
+
+## High-risk assumptions to kill
+
+- "The experimentation platform's randomization is trustworthy, so the split will be fine" — the platform's RNG is rarely the source of real-world SRM; the surrounding application code is.
+- "We looked at the config and it says 50/50" — config intent is not realized assignment; only logged exposure counts prove realized assignment.
+- "A small split deviation doesn't matter" — at low absolute counts a deviation may be noise, but the correct response is to run the chi-squared test at the actual observed volume, not to eyeball it.
+
+## When to push back
+
+Push back if the user asks to:
+
+- launch an experiment where bucketing logic cannot be traced to a deterministic, persistent-identifier hash,
+- treat an experiment's result as valid without ever having checked the realized split against the configured ratio,
+- ship an experiment where the exposure-logging event fires before the variant is actually applied (this inflates "assigned" counts independent of any real exposure).
+
+Those are not shortcuts; they are how invalid experiment results ship as product decisions.

package/skills/frontend/product-analytics-experimentation-review/references/stopping-rules-and-peeking.md

@@ -0,0 +1,61 @@
+# Stopping Rules and Peeking
+
+Use this reference when evaluating whether an experiment's statistical significance claim or stop/continue decision is actually valid, given how it was monitored.
+
+## What people get wrong
+
+The naive story is:
+
+> "The dashboard shows p < 0.05, so the result is significant — let's ship it."
+
+Wrong. A p-value computed under a fixed-sample-size assumption is only valid if the experiment was actually analyzed that way — once, at a pre-determined sample size or duration. Checking the dashboard daily and stopping the moment it crosses a significance threshold ("peeking") inflates the true false-positive rate far above the nominal 5%, often dramatically, because each look is an additional opportunity for noise to cross the threshold by chance.
+
+## Officially grounded shape
+
+There is no single universally-mandated statistical framework across experimentation platforms — some use fixed-horizon frequentist testing, some use sequential testing frameworks (e.g. always-valid p-values, mSPRT-based methods) or Bayesian frameworks specifically designed to tolerate continuous monitoring. The review's job is not to mandate one specific framework, but to verify that **the stopping behavior actually used matches the statistical framework the experiment claims to be using.** A fixed-horizon test monitored continuously and stopped early on a significant read is invalid regardless of which platform produced the number.
+
+## Non-negotiable design rules
+
+1. **A primary metric and a minimum detectable effect (MDE) must be pre-registered before the experiment starts.** If the "significant" result was found by scanning a dashboard of many metrics after the fact and picking whichever moved, that is not a valid experiment result — it is multiple-comparisons-inflated noise. Treat the absence of a pre-registered primary metric as a blocking finding.
+2. **The required sample size/duration must be computed from the pre-registered MDE, baseline rate, and desired power *before* the experiment launches**, not decided retroactively based on how the data looks partway through.
+3. **If the experiment uses a fixed-horizon test, it must not be stopped early based on an interim significant read** — continuous or frequent peeking with a fixed-horizon test invalidates the significance claim. Verify the actual monitoring cadence against the analysis method actually used.
+4. **If continuous monitoring genuinely is required (e.g. to catch a severe regression fast), the experiment must use a sequential-testing-aware method** built for that purpose — confirm the platform/analysis actually implements one rather than assuming a standard p-value naturally tolerates repeated looks.
+5. **A minimum runtime should be enforced even for a positive early read** to cover known cyclical effects (day-of-week traffic mix, novelty effects that fade, weekly business cycles) — a result significant after two days is not the same evidence as the same result sustained across a full business cycle.
+6. **Secondary/guardrail metrics must be declared in advance too**, distinct from the primary metric, so that a regression on a guardrail metric (e.g. latency, error rate, unsubscribe rate) is caught by design rather than discovered only if someone happens to check.
+
+## Minimal safe review flow
+
+1. Confirm a primary metric and MDE were declared before the experiment launched — ask for the pre-registration artifact (ticket, doc, experiment-platform config) rather than accepting a post-hoc description.
+2. Identify which statistical framework is actually in use (fixed-horizon frequentist, sequential/always-valid, Bayesian) from the platform's documented behavior — verify via Context7/current docs rather than assuming.
+3. Check the actual monitoring/stop history: was the experiment checked once at the planned endpoint, or repeatedly with a stop-on-significance pattern? If the platform's dashboard was checked daily and the experiment stopped as soon as it crossed significance, and the underlying method is fixed-horizon, flag this as invalid regardless of the reported p-value.
+4. Confirm a minimum runtime (commonly at least one to two full business cycles, e.g. two weeks, adjusted for the app's actual traffic pattern) was respected even if an early read looked positive.
+5. Confirm guardrail/secondary metrics were declared and checked, not just the metric that happened to move favorably.
+
+## Adversarial checklist
+
+Before accepting a "statistically significant" result as ship-worthy, answer these:
+
+- What was the pre-registered primary metric, and does the "significant" result match that metric — or is it a different metric that happened to move?
+- What analysis method is this platform's significance number actually based on (fixed-horizon, sequential, Bayesian), and was the monitoring behavior (single look vs. continuous dashboard checking) consistent with that method's assumptions?
+- Was there a pre-declared minimum sample size or runtime, and was the experiment stopped before, at, or after that point?
+- Were guardrail metrics (latency, errors, revenue-adjacent metrics not directly targeted) checked, or only the primary metric that moved favorably?
+- If the same experiment had been stopped a few days earlier or later, is there reason to believe the result would look materially different (day-of-week effects, novelty effects)?
+
+If any of these cannot be answered, the significance claim is unverified, not confirmed.
+
+## High-risk assumptions to kill
+
+- "It says p < 0.05 so it's real" — without knowing the analysis method and monitoring history, a p-value alone proves nothing.
+- "We checked it every day and stopped as soon as it looked good" — this is the textbook peeking failure mode, not diligence.
+- "We'll just ship whichever metric moved" — post-hoc metric selection without pre-registration is multiple-comparisons noise, not a finding.
+
+## When to push back
+
+Push back if the user asks to:
+
+- ship a result based on a metric that was not the pre-registered primary metric,
+- stop a fixed-horizon experiment early because an interim dashboard check crossed a significance threshold,
+- skip a minimum-runtime requirement because an early read "already looks clearly positive,"
+- run an experiment with no declared guardrail metrics on latency, errors, or adjacent business metrics.
+
+Those are not efficiency gains. They are how false positives become shipped product decisions.

package/skills/frontend/pwa-offline-readiness-review/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: pwa-offline-readiness-review
+description: Validates installability against W3C manifest criteria and tests real offline navigation behavior end to end, rejecting a manifest-schema-valid but practically non-installable or non-functional-offline PWA.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-07-02"
+  category: operational
+---
+
+# PWA Offline Readiness Review
+
+## Purpose
+
+A `manifest.json` that passes JSON-schema validation, and a Lighthouse PWA badge that reads 100, both prove far less than they appear to. The W3C manifest spec, `beforeinstallprompt` behavior, and offline-fallback rendering are three separate systems that must each work — a pass on one says nothing about the other two. The common failure mode is "checklist theater": a team ships a schema-valid manifest and a registered service worker, calls the app a PWA, and only discovers in production that the install banner never fires (`display: browser` left at a framework default) or that a network drop shows the browser's stock offline error page instead of a designed fallback. This skill performs the end-to-end verification — install criteria against the live origin, service-worker activation state, and an actual offline-throttle navigation test — that a static manifest read cannot substitute for.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- audit whether an app is a "real" installable PWA, not just manifest-schema-valid,
+- debug why the install prompt / `beforeinstallprompt` never fires despite a Lighthouse PWA pass,
+- review offline-fallback behavior, or debug a network drop showing the browser's default error page instead of a designed offline page,
+- validate manifest fields (`name`, icons, `start_url`, `scope`, `display`) against W3C installability criteria before a release.
+
+## When not to use
+
+- Caching-strategy correctness for an already-installable app (route classification, `CacheFirst` vs. `NetworkFirst`, authenticated-response caching risk) — hand off to `service-worker-cache-strategy-review`; that skill owns caching-strategy depth and this one does not duplicate it.
+- General HTTP `Cache-Control`/CDN caching review with no manifest or service-worker installability question involved.
+
+## Context7 Documentation Protocol
+
+Manifest-injection defaults, precache-manifest generation, and offline-fallback wiring differ by framework PWA plugin and by version — never assert a gap is "the app's fault" without checking the plugin's current documented default first.
+
+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. Always ground manifest-field and installability-criteria claims against the W3C manifest spec directly (`official_docs`), not a vendor summary of it — vendor blog posts routinely lag or simplify the spec's `display`/`purpose`/icon-size language.
+3. If the project uses `vite-plugin-pwa`, resolve `/websites/vite-pwa-org_netlify_app` and query its manifest-generation, `generateSW`/`injectManifest`, and precache `globPatterns`/`maximumFileSizeToCacheInBytes` behavior before asserting an asset or route is missing from precache "because the app didn't configure it" — the plugin has documented defaults and size ceilings that silently exclude assets.
+4. If the project uses `next-pwa` (`@ducanh2912/next-pwa`), resolve `/ducanhgh/next-pwa` and query its `fallbacks` config (`document`/`data`/`image`/`audio`/`video`/`font`) and default-offline-page conventions (`pages/_offline.tsx` / `app/~offline/page.tsx`) before concluding a fallback route is absent — the plugin auto-wires a default path if the file exists at the conventional location.
+5. If the underlying precaching/fallback mechanism is hand-rolled Workbox (not a framework plugin), resolve `/googlechrome/workbox` and query `offlineFallback`/`setCatchHandler`/`precacheAndRoute` semantics — confirm whether the fallback handler checks the precache before an `offline-fallbacks` cache, since a bug in that check order is a common cause of the fallback silently failing.
+6. Query for the exact behavior in question per review, not from memory of a prior session — plugin defaults and Workbox recipe internals change across major versions.
+7. If Context7 is unavailable or has no relevant match, fall back to `official_docs` / the bundled references, and mark the claim `documentation-based (Context7 unavailable)` rather than presenting it as freshly verified.
+8. Never invent a manifest field, plugin config key, or Workbox API that no queried source confirms.
+
+## Lean operating rules
+
+- Verify HTTPS on the actual target origin first — the W3C-implementing browsers refuse installability outright without it (localhost is the only common documented exception); if HTTPS is not confirmed, stop there, because every downstream installability check is moot until it is fixed.
+- Treat `display: browser` as a deliberate product choice to surface and confirm with the user, not a silent bug to "fix" — it is valid per spec, but it disqualifies the install-prompt flow by design, and teams frequently leave it at a framework default without realizing the consequence.
+- Do not declare an app "installable" from manifest JSON validity alone — confirm HTTPS, a service worker that reaches the `activate` state, and a qualifying `display` value together; each is independently necessary and none is sufficient alone.
+- Do not declare an app "offline-ready" from precache-manifest file lists or service-worker registration code alone — perform an actual DevTools offline-throttle navigation to a previously unvisited route and observe what renders; precaching and route-matching are separate concerns, and a precached fallback page with an unmatched route still fails offline.
+- Confirm the offline-fallback page is itself guaranteed precached, including its own dependencies (fonts, inline API calls, images) — a fallback page that depends on an uncached asset fails to render exactly when it is needed.
+- Treat the Lighthouse PWA category score as a secondary, corroborating signal only — it can pass on stale audit state and does not reproduce the live `beforeinstallprompt` browser signal; require the manual browser-session listener test as the primary proof of installability.
+- Flag any `start_url`, icon, or fallback-asset reference pointing to an HTTP origin or an unpinned third-party CDN — a mixed-content or unverifiable icon source undermines both installability and the fallback page's guarantee of availability.
+- Never recommend caching user-specific or authenticated content inside the offline-fallback route — it must render identically and safely for any unauthenticated network-offline visitor; if the app's fallback design leaks account state, that is a blocker, not a caching-strategy nuance for the sibling skill to solve.
+- Label every claim as `live evidence`, `spec-cited`, `documentation-based`, or `inference` so the reviewer knows what was actually tested versus reasoned about from file contents.
+
+## References
+
+Load these only when needed:
+
+- [W3C manifest installability checklist](references/manifest-installability-checklist.md) — use when validating manifest field-by-field against W3C installability criteria (`name`/`short_name`, icons, `start_url`/`scope`, `display`) and when diagnosing a missing install prompt.
+- [Offline fallback precache patterns](references/offline-fallback-precache-pattern.md) — use when reviewing how the offline-fallback route is registered and precached, across hand-rolled Workbox, `vite-plugin-pwa`, and `next-pwa` conventions.
+- [Live installability and offline verification protocol](references/live-verification-protocol.md) — use for the step-by-step manual test procedure (HTTPS check, service-worker activation, `beforeinstallprompt` listener, DevTools offline-throttle navigation) and for interpreting Lighthouse-vs-live divergence.
+
+## Response minimum
+
+Return, at minimum:
+
+- pass/fail verdict per W3C installability field (HTTPS, `name`/`short_name`, icons, `start_url`/`scope`, `display`), each labeled with its evidence level,
+- service-worker registration and activation status (not just "registered" — confirm `activate` was reached),
+- the actual (not inferred) offline-navigation test result for at least one previously unvisited route, and the offline-fallback page's precache/dependency-precache status,
+- explicit note on whether `display` disqualifies install prompts by design and whether that was confirmed as intentional with the user,
+- a handoff note to `service-worker-cache-strategy-review` if the gap identified is a caching-strategy implementation detail rather than an installability/offline-navigation gap.

package/skills/frontend/pwa-offline-readiness-review/metadata.json

@@ -0,0 +1,29 @@
+{
+  "id": "pwa-offline-readiness-review",
+  "name": "PWA Offline Readiness Review",
+  "type": "skill",
+  "provider": "frontend",
+  "harnesses": [
+    "claude-code",
+    "cursor",
+    "codex",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Validates installability against W3C manifest criteria and tests real offline navigation behavior end to end, rejecting a manifest-schema-valid but practically non-installable or non-functional-offline PWA.",
+  "source_type": "original",
+  "official_docs": [
+    "https://w3c.github.io/manifest/",
+    "https://web.dev/articles/installable-manifest",
+    "https://web.dev/articles/offline-fallback-page",
+    "https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Manifest",
+    "https://developer.mozilla.org/en-US/docs/Web/API/BeforeInstallPromptEvent",
+    "https://web.dev/articles/lighthouse-pwa"
+  ],
+  "security_notes": "Manifest and service-worker files must be served over HTTPS (a hard W3C/browser installability requirement, not a preference); flag any start_url or icon reference pointing to an HTTP origin or third-party CDN without integrity guarantees. Do not recommend caching the offline-fallback page's embedded data if it contains anything user-specific/authenticated -- the fallback route must be static/public content only.",
+  "last_verified": "2026-07-02",
+  "path": "skills/frontend/pwa-offline-readiness-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/frontend/pwa-offline-readiness-review/references/live-verification-protocol.md

@@ -0,0 +1,67 @@
+# Live Installability and Offline Verification Protocol
+
+Use this reference for the step-by-step manual test procedure that turns a static-file read into an evidence-backed verdict, and for interpreting divergence between the Lighthouse PWA category score and live browser behavior.
+
+## What people get wrong
+
+The naive story is:
+
+> "Lighthouse gave the PWA category a 100, so it's installable and offline-ready."
+
+Wrong, or at least insufficient. Lighthouse's PWA audit historically diverges from live installability criteria for several documented reasons: it can run against a cached or stale service-worker state, it evaluates a fixed audit checklist that has changed across Lighthouse versions (some historical PWA-specific badge criteria were deprecated/removed from newer Lighthouse releases entirely), and — critically — it does not reproduce the actual `beforeinstallprompt` event firing in a live user session, which is the real signal a browser uses to decide whether to show an install affordance. A high Lighthouse score is a corroborating signal, not proof.
+
+## Step-by-step protocol
+
+### 1. Confirm HTTPS on the actual deployed origin
+
+Check the origin Lighthouse (or any static review) was run against versus the actual production/target origin. It is a common gap for a review to validate a staging or preview URL that differs in TLS configuration from the real deployment target. Record this as `live evidence` only if checked against the real target origin; otherwise label `documentation-based` / `inference`.
+
+### 2. Confirm service-worker registration reaches `activate`
+
+In a real browser session (DevTools > Application > Service Workers), confirm:
+- a service worker is listed for the correct scope,
+- its status is `activated and is running` (not merely `installed` or stuck in `waiting`),
+- there are no registration errors in the console (common causes of registration failure: scope mismatch between the registering script's location and the intended `scope`, a JavaScript error thrown during script evaluation, or an incorrect MIME type served for the service-worker script causing the browser to refuse it).
+
+A service worker that never reaches `activate` cannot serve precached content or a fallback route, regardless of what the source code says it should do.
+
+### 3. Listen for `beforeinstallprompt` directly
+
+In a real browser session on the target origin, add a listener before any other interaction:
+
+```js
+window.addEventListener('beforeinstallprompt', (e) => {
+  console.log('beforeinstallprompt fired', e);
+});
+```
+
+If this event never fires despite all manifest and service-worker criteria appearing correct on paper, treat that as the authoritative negative signal and re-check (in order): `display` value, HTTPS on the exact origin under test, service-worker `activate` state, and whether the browser under test has already recorded a prior install/dismissal for this origin (some browsers suppress repeat prompts for a cooldown period after a user dismisses one — check for a documented per-browser dismissal-cooldown behavior before concluding the app itself is broken).
+
+### 4. Offline-throttle navigation test (the non-negotiable step)
+
+This is the step most reviews skip, and skipping it is the single most common cause of a false "offline-ready" verdict.
+
+1. Load the app normally first (to allow the service worker to install/activate and precache assets).
+2. In DevTools > Network, set throttling to **Offline** (not just slow 3G — must be a hard offline state to exercise the fallback path, not a slow-network path).
+3. Navigate to a route the user has **not** previously visited in this session (revisiting an already-cached page proves only that specific page's cache entry works, not the fallback mechanism).
+4. Observe what renders:
+   - **The browser's default offline error page (e.g., the dinosaur game / "No internet" interstitial)** — the fallback route/catch-handler is missing, misconfigured, or the fallback document itself was not precached. This is a hard fail; report per `references/offline-fallback-precache-pattern.md`.
+   - **The app's designed offline page** — record as `live evidence` pass. Additionally confirm the page rendered with its full intended styling/images (a fallback page that renders as unstyled HTML because its CSS was not precached is a partial fail, not a full pass).
+5. While still offline, attempt navigation to a second previously-unvisited route to confirm the fallback is not a one-off fluke tied to a specific route's cache warm state.
+
+### 5. Confirm the fallback page's own dependencies
+
+With DevTools still offline, inspect the rendered fallback page's network panel for any failed sub-resource requests (fonts, inline API calls, tracking scripts). A fallback page that fails to render its intended appearance because of an uncached font or a blocking synchronous API call is a partial failure — report it distinctly from a fully missing fallback.
+
+## Interpreting Lighthouse-vs-live divergence
+
+| Lighthouse PWA signal | Live signal | Verdict |
+|---|---|---|
+| High score | `beforeinstallprompt` fires, offline test passes | Corroborated pass — cite both. |
+| High score | `beforeinstallprompt` never fires | Live signal wins. Report the divergence explicitly and investigate `display`, origin mismatch, or per-browser dismissal-cooldown before concluding a manifest defect. |
+| High score | Offline navigation shows default browser error page | Live signal wins. This is the checklist-theater failure mode this skill exists to catch — report as a blocker regardless of the Lighthouse score. |
+| Low/missing score | Live signals pass | Investigate why Lighthouse diverges (stale audit run, outdated Lighthouse version, audit run against wrong origin) before treating the live pass as unreliable — a passing live test is still the stronger evidence. |
+
+## Verdict discipline
+
+Never present a Lighthouse score alone as proof of either installability or offline readiness in the final response. Every "offline-ready" or "installable" verdict in the response must cite the specific live test performed (service-worker activation check, `beforeinstallprompt` listener result, offline-throttle navigation outcome) as the primary evidence, with Lighthouse noted only as a secondary, corroborating data point.

package/skills/frontend/pwa-offline-readiness-review/references/manifest-installability-checklist.md

@@ -0,0 +1,41 @@
+# W3C Manifest Installability Checklist
+
+Use this reference when validating a `manifest.json` field-by-field against W3C installability criteria, or when diagnosing why an install prompt never appears.
+
+## What people get wrong
+
+The common bad assumption is:
+
+> "My `manifest.json` validates against the schema, so my app is installable."
+
+That is incomplete. Schema validity (correct JSON shape, valid enum values) and installability (the specific subset of fields and runtime conditions a browser actually requires before it will fire `beforeinstallprompt`) are different bars. A manifest can be perfectly schema-valid and still never trigger an install prompt, because installability additionally depends on:
+
+1. **transport** — the manifest and its origin must be served over HTTPS,
+2. **service-worker presence** — most implementing browsers additionally require an active, fetch-handling service worker before treating the app as installable, not the manifest alone,
+3. **specific field values**, not just field presence — a `display` value of `browser` is schema-valid but disqualifies the install flow by design.
+
+## Field-by-field checklist (W3C manifest spec)
+
+Work through each field and record a pass/fail with evidence label (`spec-cited`, `live evidence`, `documentation-based`, or `inference`):
+
+- **`name` / `short_name`** — at least one must be present and non-empty; `short_name` is used where display space is constrained (home-screen label). Missing both is an outright installability blocker.
+- **`icons`** — at least one icon meeting the browser's minimum size requirement (commonly a 192×192 and/or 512×512 PNG/SVG/WebP entry is expected by major implementations, though the spec itself does not hardcode a single universal minimum — cite the specific browser's documented threshold, do not assume one number applies everywhere). Check `purpose` values (`any`, `maskable`, `monochrome`) are correctly set — a maskable-only icon set with no `any` fallback can render badly on platforms that do not support maskable icons.
+- **`start_url`** — must resolve to a same-origin (or explicitly permitted scope-relative) URL. Verify it is not a URL that 404s or redirects to a different origin.
+- **`scope`** — must contain `start_url`. If `scope` is narrower than the app's actual navigable routes, navigations outside `scope` will open in a regular browser tab/window even from an installed app, breaking the installed-app experience.
+- **`display`** — must be one of `standalone`, `fullscreen`, or `minimal-ui` for the app to be eligible for the install-prompt flow at all. `display: browser` is spec-valid but is explicitly the "opt out of app-like display" value; if found, treat it as a deliberate choice to confirm with the user, not a bug to silently patch.
+- **`theme_color` / `background_color`** — not installability-blocking per spec, but their absence produces a visibly broken splash-screen/status-bar experience during install and first launch; flag as a quality issue, not a hard blocker.
+- **`id`** (where supported) — used to distinguish app identity across updates to `start_url`; note if absent on a manifest that has changed `start_url` historically, since that can cause duplicate installs.
+
+## HTTPS is not optional
+
+The W3C manifest spec and every major implementing browser refuse to treat an app as installable over plain HTTP (the common documented exception is `localhost` for local development). This is a transport-layer precondition, not a manifest field — check it first, separately from the field-by-field pass, because no amount of manifest correctness compensates for a missing HTTPS origin.
+
+## Service worker as a co-requirement
+
+A manifest satisfying every field above does not by itself make most browsers fire `beforeinstallprompt`. The commonly documented additional requirement is a registered service worker that reaches the `activate` lifecycle state and handles at least the `fetch` event for the page. Confirm activation state directly (see `references/live-verification-protocol.md`) rather than assuming registration code in the source implies a running, activated worker in the deployed environment.
+
+## Common false negatives to rule out before blaming the manifest
+
+- The manifest `<link rel="manifest">` tag is present in HTML but points to a 404 or a path blocked by CSP/robots rules.
+- The manifest is served with an incorrect `Content-Type` that the browser refuses to parse as a manifest.
+- A framework PWA plugin (see `references/offline-fallback-precache-pattern.md`) generated a manifest with `display: browser` as its own default, unrelated to any explicit app configuration — verify the plugin's current documented default via Context7 before concluding the app team made this choice deliberately.

package/skills/frontend/pwa-offline-readiness-review/references/offline-fallback-precache-pattern.md

@@ -0,0 +1,65 @@
+# Offline Fallback Precache Patterns
+
+Use this reference when reviewing how an app's offline-fallback route is registered and guaranteed-precached, across hand-rolled Workbox, `vite-plugin-pwa`, and `next-pwa` conventions. Query Context7 for the specific plugin/version in scope before asserting a default (see the Context7 Documentation Protocol in `SKILL.md`) — the exact config keys and default file paths below are current as queried, but plugin defaults change across major versions.
+
+## What people get wrong
+
+The naive story is:
+
+> "I have a service worker and it precaches my app shell, so offline works."
+
+Wrong. Precaching an asset and having a route match a failed navigation to a fallback are two independent mechanisms. An app can precache a hundred files and still show the browser's default offline error page on every dropped-network navigation, because nothing registered a catch handler that serves a specific fallback document for failed `document`-destination requests. Conversely, an app can have a beautifully designed `/offline.html` page that is never precached, so the one time it is needed — when the network is down — the browser cannot fetch it either.
+
+Both halves — a precached fallback document, and a route/catch-handler that serves it on navigation failure — must be verified independently.
+
+## Officially grounded shape (per queried sources)
+
+### Hand-rolled Workbox (`workbox-recipes` `offlineFallback` / `workbox-routing` `setCatchHandler`)
+
+The documented pattern (`workbox-recipes/src/offlineFallback.ts`) sets a global catch handler keyed on `request.destination`:
+
+- for `document` (navigation) requests, it looks up the fallback page first via `matchPrecache(pageFallback)`, then falls back to a secondary `workbox-offline-fallbacks` cache,
+- optionally does the same for `image` and `font` destinations,
+- returns `Response.error()` if neither matches — meaning if the fallback page itself was never precached and never separately cached, the catch handler produces a network error rather than a rendered page.
+
+Review checklist for a hand-rolled implementation:
+- Confirm the fallback page path passed to `offlineFallback()` (or an equivalent hand-written `setCatchHandler`) is one of the entries in the `precacheAndRoute()` manifest, not just a same-looking path.
+- Confirm `precacheAndRoute()` was actually called (not just `precache()` alone) — `precache()` without `addRoute()`/`precacheAndRoute()` populates the cache but does not register the intercepting route, meaning normal navigations to precached pages would fall through to network first (relevant to caching-strategy review, but also affects whether the fallback lookup via `matchPrecache` finds a served entry).
+- Confirm the catch handler is registered globally (`setCatchHandler`), not only on a subset of routes, or navigations outside those routes will surface the raw browser error page.
+
+### `vite-plugin-pwa` (Vite / `generateSW` or `injectManifest`)
+
+`vite-plugin-pwa` does not auto-designate an offline-fallback page by default — precache coverage is controlled by `workbox.globPatterns` (which files get swept into the precache manifest) and `workbox.maximumFileSizeToCacheInBytes` (default documented ceiling around 2 MiB; assets above it are silently excluded from precache even if `globPatterns` would otherwise match them). Review checklist:
+- Confirm the offline-fallback HTML file's glob pattern is actually included in `globPatterns` (a common gap: `globPatterns: ['**/*.{js,css,html}']` looks like it covers an `offline.html`, but if the file lives outside the configured `public`/build output directory scanned by the plugin, it will not appear in the manifest).
+- Confirm the fallback file is under the size ceiling, or that `maximumFileSizeToCacheInBytes` was explicitly raised for it.
+- Because `vite-plugin-pwa` does not wire the catch-handler/fallback-routing logic for you by default under `generateSW`, confirm the project either uses `injectManifest` with a custom service-worker source implementing `offlineFallback`/`setCatchHandler`, or has added equivalent `runtimeCaching` navigation-fallback configuration. Do not assume "precached" implies "served as a navigation fallback" — verify the routing half separately, per the "what people get wrong" framing above.
+
+### `next-pwa` (`@ducanh2912/next-pwa`)
+
+This plugin's documented `fallbacks` option explicitly separates fallback routes by destination (`document`, `data`, `image`, `audio`, `video`, `font`), each pointing to a precached path, e.g.:
+
+```js
+fallbacks: {
+  document: "/~offline",
+  data: "/fallback.json",
+  image: "/fallback.webp",
+}
+```
+
+Its internal fallback handler (`self.fallback`) branches on `request.destination` and matches against those precached paths via `caches.match(fallbackResponse, { ignoreSearch: true })`, returning `Response.error()` if no destination-specific fallback is configured. Review checklist:
+- If no explicit `fallbacks.document` is configured, confirm whether the project instead relies on the plugin's documented convention path (`pages/_offline.tsx` or `app/~offline/page.tsx`) — the plugin auto-wires a default at that conventional location if the file exists; absence of explicit config is not automatically a gap if the convention file is present.
+- If neither explicit `fallbacks.document` nor the convention file exists, the app has no navigation fallback at all — this is the direct cause of a raw browser offline error page and should be reported as a blocker, not a style nit.
+- Confirm the fallback path itself is excluded from any auth-gating middleware — a fallback route that requires authentication to render defeats its own purpose during an offline navigation.
+
+## Minimal safe verification flow
+
+1. Identify which of the three patterns above (hand-rolled Workbox, `vite-plugin-pwa`, `next-pwa`) the project uses; do not assume, check the dependency and config file.
+2. Confirm the specific fallback document path is present in the generated/inspectable precache manifest (build output, or DevTools Application > Cache Storage after first load).
+3. Confirm a catch-handler/fallback route actually exists and targets that exact path — not merely that the path is precached.
+4. Run the live offline-throttle navigation test from `references/live-verification-protocol.md` to confirm the fallback actually renders end to end; steps 1–3 alone are necessary but not sufficient proof.
+
+## High-risk assumptions to kill
+
+- "It's in the precache manifest, so offline works." — precache and fallback-routing are separate mechanisms; both must be verified.
+- "The plugin handles this by default." — only true for the specific documented convention path/config key for that plugin and version; verify via Context7, do not assume parity across `vite-plugin-pwa` and `next-pwa` defaults.
+- "The fallback page has no external dependencies, so it's safe offline." — verify this; a fallback page pulling a web font from a CDN, or making an inline API call for personalization, fails exactly when offline.