Une seule virgule finale dans manifest.webmanifest, et les navigateurs traitent votre application comme si elle n'avait aucun manifeste : pas de nom, pas d'icônes, pas d'invite d'installation. Une route Workbox qui sert /api/account avec StaleWhileRevalidate conserve les données de compte d'un client sur un ordinateur partagé après sa déconnexion, car la Cache API ignore Cache-Control: private. Un event.respondWith() placé après un await lève une exception, et la requête part sur le réseau comme si le worker n'existait pas. Cette skill détecte ces erreurs et les autres erreurs PWA listées ci-dessous avant la publication, et vous explique comment corriger chacune.

Votre agent lance un scanner sur les manifestes de votre application web (manifest.json, *.webmanifest, app/manifest.ts de Next.js, le manifeste dans les configurations vite-plugin-pwa), les service workers (écrits à la main, Workbox, Serwist), les configurations runtimeCaching de Workbox (workbox-config.js, vite-plugin-pwa, next-pwa, webpack), le ngsw-config.json d'Angular et les appels d'enregistrement du service worker. Il analyse les manifestes en JSON strict comme le font les navigateurs, lit JavaScript et TypeScript en mettant de côté commentaires et chaînes, compare des segments entiers de chemin d'URL (ainsi /api/session est privé, mais pas /api/sessions, le programme d'une conférence), comprend les matchers Workbox qui excluent des URL (if ... return false, une denylist de NavigationRoute) et connaît les valeurs par défaut de vite-plugin-pwa et next-pwa. Le code de service worker des modèles Workbox, Create React App, vite-plugin-pwa et Serwist passe sans aucun signalement. Il n'exécute, ne compile ni ne sert jamais votre application. Il renvoie BLOCK, REVIEW ou NOT FLAGGED, avec le fichier, la ligne, la raison et une approche plus sûre, et chaque règle renvoie à la documentation W3C, MDN, web.dev ou Chrome sur laquelle elle s'appuie. Les secrets ne sont jamais affichés.

Ce qui est vérifié

BLOCK (à corriger avant la publication)

• W01 : un manifeste qui n'est pas du JSON valide (virgule finale, commentaire, guillemets simples), qui n'est pas un objet, ou enregistré en UTF-16
• W02 : start_url hors du scope (y compris "/app" avec le scope "/app/"), ou start_url ou scope sur localhost
• W03 : routes qui répondent aux URL de session, de jeton ou de déconnexion, ou aux données de compte, de profil, de panier ou de paiement, à partir d'une copie stockée alors que l'appareil est en ligne
• W04 : importScripts() via http://, ou appelé dans un gestionnaire d'événement fetch, message ou autre
• W05 : event.respondWith() ou le premier event.waitUntil() appelés après un await ou dans un callback then()
• W06 : la même URL deux fois dans une liste cache.addAll(), y compris écrite sous la forme ./index.html et index.html (l'installation échoue)

REVIEW (à vérifier avant la sortie)

• W11 : manifestes pour lesquels Chromium ne proposera pas l'installation (pas de nom, pas d'icône de 144px ou plus, un mode d'affichage non installable, prefer_related_applications)
• W12 : aucune icône maskable, ou des icônes avec purpose "any maskable"
• W13 : manifestes sans id
• W14 : pages ou fichiers .html servis en cache-first
• W15 : caches versionnés jamais supprimés
• W16 : skipWaiting() inconditionnel dans un worker qui met l'application en précache, y compris le comportement par défaut de next-pwa
• W17 : réponses d'API servies avec CacheFirst, CacheOnly ou StaleWhileRevalidate (et dataGroups d'Angular avec la stratégie performance par défaut), et URL de session ou de jeton stockées pour une utilisation hors ligne
• W18 : gestionnaires fetch qui stockent chaque réponse avec cache.put()
• W19 : enregistrements de service worker dont le scope ne couvre pas les pages de l'application ou nécessite un en-tête Service-Worker-Allowed

Contenu inclus

• Le scanner (Python 3.9+, bibliothèque standard uniquement)
• Un guide des règles avec, pour chaque règle, la raison, l'approche plus sûre et le lien vers la source officielle
• Un projet d'exemple risqué et un projet sûr (un site statique avec un service worker écrit à la main et une boutique Vite avec vite-plugin-pwa), et le rapport réel que le scanner produit sur le projet risqué

Limites

Il lit le texte des fichiers et ne suit que quelques informations d'un fichier à l'autre (manifestes liés depuis les pages, un en-tête Service-Worker-Allowed dans les configurations serveur, autoUpdate de vite-plugin-pwa). Les matchers définis dans un autre fichier, les service workers minifiés ou générés, les fichiers d'icônes, HTTPS et les en-têtes HTTP envoyés par votre serveur ne sont pas vérifiés, et la mise en cache d'URL privées dans des gestionnaires fetch écrits à la main n'est signalée que sous forme de constats cache-first ou de mise en cache de tout. Le mode autoUpdate de vite-plugin-pwa et le modèle Serwist, qui choisissent délibérément des mises à jour immédiates, ne sont pas signalés par W16. NOT FLAGGED n'est pas une garantie.

Contenu de l'archive

Un fichier ZIP de 20 fichiers : SKILL.md, le scanner dans scripts/ (7 fichiers Python), references/rules.md (chaque règle avec sa raison et l'approche plus sûre) et examples/ (10 fichiers d'exemple plus report.md, la sortie réelle du scanner sur l'exemple risqué).

Mode d'emploi : Il s'agit d'une skill pour agent : un dossier contenant un fichier SKILL.md et des scripts Python qu'un agent de programmation IA comme Claude Code, Cursor ou Codex CLI peut exécuter. Décompressez-la dans le dossier des skills de votre agent (pour Claude Code : ~/.claude/skills/), puis demandez à votre agent de vérifier votre projet. Les scripts fonctionnent aussi seuls avec Python 3.9 ou plus récent, sans rien à installer. Ils se contentent de lire vos fichiers : aucun accès réseau, et rien n'est envoyé nulle part.