@the-bearded-bear/claude-craft 8.22.0 → 8.23.0

package/Dev/i18n/fr/Symfony/rules/08-quality-tools.md

@@ -240,7 +240,7 @@ $finder = Finder::create()
 return (new Config())
     ->setRules([
         '@Symfony' => true,
-        '@PSR12' => true,
+        '@PER-CS3x0' => true,
 
         // ✅ Règles strictes supplémentaires
         'array_syntax' => ['syntax' => 'short'],

package/Dev/i18n/fr/Symfony/rules/16-i18n.md

@@ -175,6 +175,8 @@ Usage :
 $this->translator->trans('client.created', [], 'messages', $locale);
 ```
 
+Messages pluriels/genrés : ICU MessageFormat (MF1 via le domaine `+intl-icu` de Symfony) ; **MessageFormat 2.0** est stable dans CLDR 47 (mars 2025) — vérifier le support de la bibliothèque avant de migrer.
+
 ## Checklist i18n
 
 - [ ] Country enum utilisé partout

package/Dev/i18n/fr/Symfony/rules/17-async.md

@@ -188,3 +188,4 @@ final class MessengerEventSubscriber implements EventSubscriberInterface
 - [ ] Workers supervisord en prod
 - [ ] Monitoring des failed messages
 - [ ] Tests avec `messenger:consume --limit=1`
+- [ ] Messages exposés à d'autres systèmes documentés avec AsyncAPI 3.x (3.1.0)

package/Dev/i18n/fr/Symfony/rules/19-aggregates.md

@@ -23,6 +23,7 @@ namespace App\Commercial\Domain\Client;
 use App\Shared\Domain\AggregateRoot;
 use Doctrine\Common\Collections\ArrayCollection;
 use Doctrine\Common\Collections\Collection;
+use DateTimeImmutable;
 
 class Client extends AggregateRoot
 {

package/Dev/i18n/fr/Symfony/rules/20-domain-events.md

@@ -15,6 +15,7 @@ namespace App\Commercial\Domain\Client\Event;
 
 use App\Shared\Domain\DomainEvent;
 use DateTimeImmutable;
+use DateTimeInterface;
 
 final readonly class ClientCreated implements DomainEvent
 {

package/Dev/i18n/fr/Team/commands/delivery.md

@@ -517,7 +517,7 @@ Pour 1 EPIC, 5 US, ~25 tâches :
 | **Temps total** | **~120 min** | **~55 min** | **~2.2x** |
 | Coût total* | ~$28 | ~$17 | **-38%** |
 
-*Économies de coût car Sonnet ($3/$15/M) gère la majorité du travail vs Opus ($15/$75/M) en mode séquentiel.
+*Économies de coût car Sonnet 5.5 ($2/$10/M) gère la majorité du travail vs Opus 5.5 ($4/$20/M) en mode séquentiel.
 
 ## Attentes de performance
 

package/Dev/i18n/fr/Vercel/CLAUDE.md.template

@@ -8,7 +8,7 @@
 
 **Périmètre** : uniquement les fonctionnalités de plateforme indépendantes de tout framework — vercel.json, Functions, ISR, Cron, Storage. Explicitement hors périmètre : Next.js, ainsi que tout adaptateur de déploiement propre à un framework.
 
-> **Note :** Vercel (ce stack) couvre uniquement la **surface de la plateforme de déploiement indépendante de tout framework** : la configuration `vercel.json` (rewrites, redirects, headers, regions), les Serverless Functions sur le runtime Node.js / Fluid Compute, les primitives de cache ISR, les Cron Jobs, le Vercel Storage (Blob natif ; Postgres/KV via le Marketplace — Neon/Upstash), Analytics/Speed Insights, et le workflow variables d'environnement/Preview Deployment. Ce n'est **pas** un stack Next.js — Next.js lui-même est hors périmètre et n'est pas une technologie claude-craft supportée (aucun namespace `/nextjs:*` n'existe). Le routage, le rendu ou les patterns de récupération de données propres à un framework relèvent du stack propre à ce framework (`/react:*`, `/vuejs:*`, `/angular:*`) — consulter le `tooling.md` de ce stack pour savoir comment il s'intègre avec la sortie de build de Vercel. Par ailleurs, l'Edge Runtime (`export const runtime = 'edge'`) est **déprécié par Vercel** depuis 2026 au profit du Fluid Compute sur le runtime Node.js ; ce stack documente l'Edge Runtime uniquement pour aider à identifier et migrer du code legacy, pas comme un pattern recommandé pour du nouveau code.
+> **Note :** Vercel (ce stack) couvre uniquement la **surface de la plateforme de déploiement indépendante de tout framework** : la configuration `vercel.json` (rewrites, redirects, headers, regions), les Serverless Functions sur le runtime Node.js / Fluid Compute, les primitives de cache ISR, les Cron Jobs, le Vercel Storage (Blob natif ; Postgres/KV via le Marketplace — Neon/Upstash), Analytics/Speed Insights, et le workflow variables d'environnement/Preview Deployment. Ce n'est **pas** un stack Next.js — Next.js lui-même est hors périmètre et n'est pas une technologie claude-craft supportée (aucun namespace `/nextjs:*` n'existe). Le routage, le rendu ou les patterns de récupération de données propres à un framework relèvent du stack propre à ce framework (`/react:*`, `/vuejs:*`, `/angular:*`) — consulter le `tooling.md` de ce stack pour savoir comment il s'intègre avec la sortie de build de Vercel. Par ailleurs, l'Edge Runtime (`export const runtime = 'edge'`) est **déconseillé par Vercel**, qui privilégie le Fluid Compute sur le runtime Node.js ; ce stack documente l'Edge Runtime uniquement pour aider à identifier et migrer du code legacy, pas comme un pattern recommandé pour du nouveau code.
 
 ### Structure du projet
 ```
@@ -38,7 +38,7 @@ Voir `rules/02-architecture.md` pour les patterns complets.
 | Règle | Raison |
 |------|--------|
 | vercel.json validé contre `$schema` | Détecte les globs/clés mal orthographiés avant qu'ils échouent silencieusement au déploiement |
-| Node.js/Fluid Compute est le runtime par défaut | L'Edge Runtime (`runtime: 'edge'`) est déprécié — cible de migration legacy uniquement |
+| Node.js/Fluid Compute est le runtime par défaut | L'Edge Runtime (`runtime: 'edge'`) est déconseillé — cible de migration legacy uniquement |
 | Variables d'environnement jamais en dur ni commitées | Les secrets appartiennent au store de variables d'environnement de Vercel, scopés par environnement |
 | Les endpoints Cron vérifient l'en-tête secret | Un chemin cron non protégé peut être déclenché par quiconque le trouve |
 | Couverture 80%+ sur la logique des handlers | Assurance qualité pour la logique métier des Functions et du middleware |

package/Dev/i18n/fr/Vercel/agents/vercel-reviewer.md

@@ -221,10 +221,10 @@ Une Function déclare-t-elle export const config = { runtime: 'edge' } (ou
 "runtime": "edge" dans le bloc functions de vercel.json) ?
   OUI --> Cette Function est-elle nouvellement ajoutée ou récemment modifiée
           (pas du code purement legacy, non touché) ?
-          OUI --> MAJEUR : l'Edge Runtime est déprécié par Vercel — migrer vers le
+          OUI --> MAJEUR : l'Edge Runtime n'est pas recommandé par Vercel — migrer vers le
                   Fluid Compute sur le runtime Node.js (par défaut) pour un accès
                   complet aux API Node, des cold starts avec cache de bytecode
-                  (Node 20+), et une tarification Active CPU
+                  (Node 22+), et une tarification Active CPU
           NON --> MINEUR : marquer comme dette de migration legacy, ne pas bloquer
                   du code non modifié
   NON --> La Function s'exécute sur le défaut Node.js/Fluid Compute --> passer à la
@@ -237,7 +237,7 @@ Une Function déclare-t-elle export const config = { runtime: 'edge' } (ou
 La version Node.js est-elle épinglée (package.json "engines.node", ou le réglage
 Node.js Version du projet Vercel) sur 20.x ou plus récent ?
   NON --> MINEUR : une version Node non épinglée/ancienne renonce à l'amélioration
-          de cold-start du cache de bytecode de Fluid Compute (spécifique à Node 20+)
+          de cold-start du cache de bytecode de Fluid Compute (spécifique à Node 22+)
           et risque une dérive silencieuse de runtime entre les redéploiements
   OUI --> OK
 ```
@@ -260,7 +260,7 @@ avant de l'utiliser ?
 
 **Edge Runtime sur du code nouveau/modifié :**
 ```typescript
-// INTERDIT — Edge Runtime déclaré sur une Function nouvellement ajoutée : pattern déprécié
+// INTERDIT — Edge Runtime déclaré sur une Function nouvellement ajoutée : pattern déconseillé
 export const config = { runtime: 'edge' };
 
 export default function handler(req: Request) {
@@ -269,7 +269,7 @@ export default function handler(req: Request) {
 }
 
 // CORRECT — défaut Node.js/Fluid Compute, accès complet aux API Node, cold starts
-// plus rapides sur Node 20+ via le cache de bytecode
+// plus rapides sur Node 22+ via le cache de bytecode
 export const config = { maxDuration: 10 };
 
 export default function handler(req: VercelRequest, res: VercelResponse) {
@@ -297,7 +297,7 @@ export default function handler(req: VercelRequest, res: VercelResponse) {
 ```
 ```typescript
 // api/legacy.ts
-// TODO(JIRA-1234): migrer hors de l'Edge Runtime — déprécié par Vercel, voir Fluid Compute
+// TODO(JIRA-1234): migrer hors de l'Edge Runtime — déconseillé par Vercel, voir Fluid Compute
 export const config = { runtime: 'edge' };
 ```
 
@@ -350,7 +350,7 @@ export default async function handler(req: VercelRequest, res: VercelResponse) {
 |---------|----------|--------------|
 | Runtime | Défaut Node.js/Fluid Compute | `runtime: 'edge'` sur du code nouveau/modifié |
 | Edge Runtime legacy | Marqueur de migration ticketé (TODO + référence d'issue) | Edge Runtime silencieux, non signalé, laissé en place |
-| Version Node | Épinglée sur 20+ (`engines.node` ou réglage du projet) | Non épinglée, dérive du défaut |
+| Version Node | Épinglée sur 22.x ou 24.x (Node 20 est déprécié sur Vercel depuis le 2026-10-01) (`engines.node` ou réglage du projet) | Non épinglée, dérive du défaut |
 | Input du handler | Validé/parsé (zod, garde manuelle) avant utilisation | `req.body`/`req.query` brut utilisé sans vérification |
 | Sortie du handler | Status explicite + body typé sur chaque chemin | 200 implicite, forme d'erreur incohérente |
 | Vigilance cold-start | Imports lourds chargés paresseusement/différés quand non toujours nécessaires | Chaque dépendance importée avec empressement en haut du module |
@@ -836,7 +836,7 @@ describe('api/cron/daily', () => {
 | Sujet | À vérifier |
 |-------|---------------|
 | **Fluid Compute** | Confirmer que les Functions passent par défaut en Fluid Compute (tarification Active CPU), pas l'ancienne facturation Serverless Functions à concurrence fixe |
-| **Dépréciation de l'Edge Runtime** | Tout `runtime: 'edge'` trouvé doit porter une référence de ticket de migration, jamais être présenté comme le pattern recommandé pour du nouveau code |
+| **Edge Runtime déconseillé** | Tout `runtime: 'edge'` trouvé doit porter une référence de ticket de migration, jamais être présenté comme le pattern recommandé pour du nouveau code |
 | **Packages Storage dépréciés** | Les imports `@vercel/kv`/`@vercel/postgres` sont un constat MAJEUR quelle que soit la date d'ajout — signaler pour migration Marketplace (Neon/Upstash) |
 | **Primitive de cache ISR vs headers de vercel.json** | La revalidation native du framework et les `headers` de vercel.json ne doivent jamais cibler la même route pour `Cache-Control` |
 | **Limites de plan Cron** | Le plan Hobby plafonne les Cron Jobs à 1/jour — vérifier que la planification déclarée correspond au palier de plan réellement utilisé |

package/Dev/i18n/fr/Vite/CLAUDE.md.template

@@ -6,7 +6,7 @@
 
 **Stack** : Vite {{VITE_VERSION}}, TypeScript {{TS_VERSION}}
 
-**Périmètre** : usage de Vite indépendant de tout framework uniquement — applications vanilla JS/TS, création de librairies (build.lib), applications multi-pages (rollupOptions.input), points d'entrée Workers/WASM. Ne couvre pas la configuration du serveur de développement React/Vue/Angular/Svelte — voir le tooling.md propre à ce stack.
+**Périmètre** : usage de Vite indépendant de tout framework uniquement — applications vanilla JS/TS, création de librairies (build.lib), applications multi-pages (rolldownOptions.input), points d'entrée Workers/WASM. Ne couvre pas la configuration du serveur de développement React/Vue/Angular/Svelte — voir le tooling.md propre à ce stack.
 
 ### Structure du projet
 ```
@@ -32,7 +32,7 @@ project-root/
 ### Architecture : {{ARCHITECTURE_PATTERN}}
 - **Point d'entrée** : `index.html` à la racine du projet (ou `root`), jamais dans `public/`
 - **Mode librairie** : `build.lib` + `vite-plugin-dts` pour les packages publiés sur npm
-- **Multi-pages** : `build.rollupOptions.input` nommant explicitement chaque entrée HTML
+- **Multi-pages** : top-level `input` nommant explicitement chaque entrée HTML
 - **Workers/WASM** : `new Worker(new URL(...), { type: 'module' })`, suffixes `?init`/`?url`
 
 Voir `rules/02-architecture.md` pour les patterns complets.

package/Dev/i18n/fr/Vite/agents/vite-reviewer.md

@@ -1,6 +1,6 @@
 ---
 name: vite-reviewer
-description: Spécialiste de revue de code Vite 8.x indépendant de tout framework — applications vanilla JS/TS, création de librairies (build.lib), applications multi-pages (rollupOptions.input), points d'entrée Workers/WASM, configuration de plugins
+description: Spécialiste de revue de code Vite 8.x indépendant de tout framework — applications vanilla JS/TS, création de librairies (build.lib), applications multi-pages (rolldownOptions.input), points d'entrée Workers/WASM, configuration de plugins
 model: haiku
 effort: low
 maxTurns: 6
@@ -14,13 +14,13 @@ skills: [solid-principles, testing, security]
 
 ## Identité
 
-Je suis un spécialiste de la revue de code Vite 8.x, **indépendant de tout framework** par conception. Mon périmètre couvre l'usage pur de Vite : applications vanilla JS/TS (index.html comme point d'entrée source, jamais dans public/), création de librairies via build.lib et vite-plugin-dts, applications multi-pages via build.rollupOptions.input, et points d'entrée Workers/WASM. Je ne couvre PAS les intégrations Vite spécifiques à React, Vue, Angular ou Svelte — ces stacks documentent déjà leur propre intégration de serveur de développement dans leur fichier tooling.md respectif. Je ne réalise pas un audit générique — je détecte ce qui casse le graphe de modules, alourdit le bundle, ou complique inutilement une configuration Vite.
+Je suis un spécialiste de la revue de code Vite 8.x, **indépendant de tout framework** par conception. Mon périmètre couvre l'usage pur de Vite : applications vanilla JS/TS (index.html comme point d'entrée source, jamais dans public/), création de librairies via build.lib et vite-plugin-dts, applications multi-pages via build.rolldownOptions.input, et points d'entrée Workers/WASM. Je ne couvre PAS les intégrations Vite spécifiques à React, Vue, Angular ou Svelte — ces stacks documentent déjà leur propre intégration de serveur de développement dans leur fichier tooling.md respectif. Je ne réalise pas un audit générique — je détecte ce qui casse le graphe de modules, alourdit le bundle, ou complique inutilement une configuration Vite.
 
 ## Système de notation (100 points)
 
 | Catégorie | Points | Focus |
 |----------|--------|-------|
-| Config et Architecture Vite | 30 | vite.config.ts, index.html, build.lib, rollupOptions.input, plugins |
+| Config et Architecture Vite | 30 | vite.config.ts, index.html, build.lib, rolldownOptions.input, plugins |
 | TypeScript et Qualité | 20 | tsconfig strict, moduleResolution bundler, vite-plugin-dts |
 | Tests | 25 | Config/couverture Vitest, tests sur le build publié |
 | Sortie de build et Performance | 25 | Taille du bundle, tree-shaking, externalisation, code-splitting |
@@ -49,7 +49,7 @@ Le package est-il consommé par d'autres packages/apps (publié sur npm) ?
   OUI --> build.lib est-il configuré ?
     NON --> CRITIQUE : sans build.lib, Vite produit un bundle d'application
             (index.html requis, pas de formats ESM/CJS multiples, pas d'externalisation des peer deps)
-    OUI --> rollupOptions.external couvre-t-il toutes les peerDependencies ?
+    OUI --> rolldownOptions.external couvre-t-il toutes les peerDependencies ?
       NON --> MAJEUR : le runtime du framework hôte sera dupliqué chez le consommateur
       OUI --> vite-plugin-dts est-il configuré ?
         NON --> MAJEUR : pas de typages publiés, package inutilisable en TypeScript strict
@@ -62,7 +62,7 @@ Le package est-il consommé par d'autres packages/apps (publié sur npm) ?
 ```
 Le projet a-t-il plusieurs pages HTML distinctes (pas seulement des routes côté client) ?
   NON --> SPA classique : un seul index.html, routage côté client
-  OUI --> build.rollupOptions.input est-il un objet nommant chaque page ?
+  OUI --> build.rolldownOptions.input est-il un objet nommant chaque page ?
     NON --> MAJEUR : les pages secondaires ne sont pas buildées ou dépendent d'un
             chemin de chargement manuel, non optimisé
     OUI --> Les pages partagent-elles des dépendances lourdes ?
@@ -133,7 +133,7 @@ export default defineConfig({
       formats: ['es', 'cjs'],
       fileName: (format) => `my-lib.${format}.js`,
     },
-    rollupOptions: {
+    rolldownOptions: {
       // Ne jamais bundler les peer dependencies
       external: ['react', 'react-dom'],
       output: {
@@ -144,7 +144,7 @@ export default defineConfig({
 });
 ```
 
-**rollupOptions.input pour les applications multi-pages :**
+**rolldownOptions.input pour les applications multi-pages :**
 ```typescript
 // MAUVAIS : pages secondaires non déclarées dans la config
 export default defineConfig({});
@@ -155,7 +155,7 @@ import { defineConfig } from 'vite';
 
 export default defineConfig({
   build: {
-    rollupOptions: {
+    rolldownOptions: {
       input: {
         main: resolve(__dirname, 'index.html'),
         about: resolve(__dirname, 'pages/about.html'),
@@ -225,8 +225,10 @@ export function vitePluginMyTransform(): Plugin {
 | index.html | À la racine de `root`, transformé comme entrée source | Copié dans public/ |
 | public/ | Assets statiques uniquement (favicon, robots.txt) | HTML/JS source importé depuis public/ |
 | build.lib | Configuré pour chaque package publié | Bundle d'application publié comme librairie |
-| rollupOptions.external | Peer deps externalisées | Framework hôte bundlé dans la librairie |
-| rollupOptions.input | Objet nommant chaque page HTML (multi-pages) | Chargement manuel, non optimisé |
+| rolldownOptions.external | Peer deps externalisées | Framework hôte bundlé dans la librairie |
+| rolldownOptions.input | Objet nommant chaque page HTML (multi-pages) | Chargement manuel, non optimisé |
+| rollupOptions / worker.rollupOptions / optimizeDeps.esbuildOptions | Équivalents rolldownOptions (dépréciés depuis Vite 8) | Alias dépréciés conservés dans la config |
+| Node.js | `^20.19.0` ou `>=22.12.0` (prérequis Vite 8) | Node 18 ou 20 < 20.19 |
 | Plugins custom | Préfixe vite-plugin-*, propriété `name` explicite | Plugin anonyme sans nom |
 | Variables d'environnement | Préfixe VITE_ pour l'exposition client | Secrets non préfixés référencés côté client |
 
@@ -237,7 +239,7 @@ export function vitePluginMyTransform(): Plugin {
 | vite.config.ts correct (defineConfig, alias synchronisés avec tsconfig) | 8 |
 | index.html à la racine du bon dossier, jamais dans public/ | 6 |
 | build.lib correctement configuré (entry, formats, external, vite-plugin-dts) | 8 |
-| rollupOptions.input pour le multi-pages, plugins nommés selon la convention vite-plugin-* | 8 |
+| rolldownOptions.input pour le multi-pages, plugins nommés selon la convention vite-plugin-* | 8 |
 
 ---
 
@@ -441,7 +443,7 @@ package.json déclare-t-il "sideEffects": false ?
 ### Arbre de décision : Code-splitting multi-pages
 
 ```
-L'application a-t-elle plusieurs pages (rollupOptions.input) ?
+L'application a-t-elle plusieurs pages (rolldownOptions.input) ?
   OUI --> manualChunks isole-t-il un chunk vendor partagé ?
     NON --> MAJEUR : chaque page duplique les mêmes dépendances lourdes
     OUI --> Le plus gros chunk lazy dépasse-t-il 80KB gzip ?
@@ -486,14 +488,14 @@ export { formatDate, parseDate } from './utils';
 // MAUVAIS : le framework hôte est bundlé dans la librairie publiée
 export default defineConfig({
   build: { lib: { entry: 'src/index.ts', formats: ['es'] } },
-  // pas de rollupOptions.external
+  // pas de rolldownOptions.external
 });
 
 // BON : peer deps explicitement externalisées
 export default defineConfig({
   build: {
     lib: { entry: 'src/index.ts', formats: ['es', 'cjs'] },
-    rollupOptions: {
+    rolldownOptions: {
       external: (id) => /^(react|react-dom|vue)/.test(id),
     },
   },
@@ -507,7 +509,7 @@ export default defineConfig({
 
 // BON : chunk vendor partagé entre toutes les pages
 build: {
-  rollupOptions: {
+  rolldownOptions: {
     output: {
       manualChunks(id) {
         if (id.includes('node_modules')) return 'vendor';
@@ -564,8 +566,8 @@ build: {
 
 ### Phase 2 : Configuration spécifique Vite (15 min)
 
-1. Si librairie : vérifier build.lib, formats, rollupOptions.external, vite-plugin-dts
-2. Si multi-pages : vérifier rollupOptions.input, manualChunks
+1. Si librairie : vérifier build.lib, formats, rolldownOptions.external, vite-plugin-dts
+2. Si multi-pages : vérifier rolldownOptions.input, manualChunks
 3. Si Workers/WASM : vérifier new URL(...import.meta.url), suffixes ?init/?url
 4. Vérifier la convention de nommage des plugins custom (vite-plugin-*, propriété name)
 5. Vérifier les variables d'environnement (préfixe VITE_, aucun secret exposé côté client)

package/Dev/i18n/fr/Vite/commands/check-compliance.md

@@ -36,7 +36,7 @@ Exécuter la vérification complète de configuration et d'architecture :
 - Correction de vite.config.ts (defineConfig, alias synchronisés avec tsconfig) (8 pts)
 - Emplacement d'index.html à la racine du projet, jamais dans public/ (6 pts)
 - Configuration build.lib pour les librairies (entry, formats, external, vite-plugin-dts) (8 pts)
-- rollupOptions.input pour les applications multi-pages, convention de nommage des plugins (vite-plugin-*) (8 pts)
+- rolldownOptions.input pour les applications multi-pages, convention de nommage des plugins (vite-plugin-*) (8 pts)
 
 **Référence** : `.claude/agents/vite-reviewer.md` (section 1)
 
@@ -151,7 +151,7 @@ Sous-scores :
   • Correction de vite.config.ts     : XX/8
   • Emplacement d'index.html         : XX/6
   • Configuration build.lib          : XX/8
-  • rollupOptions.input / plugins    : XX/8
+  • rolldownOptions.input / plugins    : XX/8
 
 Points forts :
 - [Points forts architecture]

package/Dev/i18n/pt/Angular/agents/angular-reviewer.md

@@ -46,8 +46,8 @@ O estado e sincrono e usado para renderizacao?
 
 **Zoneless por padrao (estavel) :**
 - Economia de ~33 KB de bundle (Zone.js opcional)
-- +30-40% de melhoria de performance de renderizacao segundo Angular DevRel
-- API estavel: `provideZonelessChangeDetection()` de `@angular/core` (nao mais `Experimental`)
+- Ganhos de performance variam conforme a aplicacao (o numero "+30-40%" vem de uma fonte de 2024): medir, nao assumir
+- Nenhum provider necessario na v21+/v22: `provideZonelessChangeDetection()` so e necessario na v20 (https://angular.dev/guide/zoneless)
 
 **Signal Forms (estavel v22) :**
 - Alternativa nativa baseada em signals aos Reactive Forms, **pronto para producao**
@@ -421,7 +421,7 @@ A aplicacao utiliza deteccao de mudancas zoneless?
     SIM --> Os event listeners disparam corretamente o CD?
   NAO --> Zone.js e utilizado?
     SIM --> MENOR em v22+: migracao para zoneless recomendada (economiza ~33 KB)
-    NAO --> Verificar que provideZonelessChangeDetection() esta configurado (estavel desde v20.2)
+    NAO --> Verificar que nenhum provideZoneChangeDetection() reativa o Zone.js (zoneless por padrao desde a v21)
 
 httpResource() e usado para requisicoes HTTP repetitivas?
   NAO --> Os componentes usam signal + effect + HttpClient?

package/Dev/i18n/pt/Common/agents/devops-engineer.md

@@ -7,6 +7,20 @@ maxTurns: 8
 tools: [Read, Glob, Grep, Edit, Write, Bash, WebFetch, WebSearch]
 permissionMode: default
 skills: [security, git-workflow]
+disallowedTools:
+  - "Bash(rm -rf:*)"
+  - "Bash(dd:*)"
+  - "Bash(mkfs:*)"
+  - "Bash(kubectl delete:*)"
+  - "Bash(helm uninstall:*)"
+  - "Bash(terraform destroy:*)"
+  - "Bash(tofu destroy:*)"
+  - "Bash(docker system prune -a*)"
+  - "Bash(docker volume rm:*)"
+  - "Bash(curl * | sh*)"
+  - "Bash(wget * | sh*)"
+  - "Bash(git push --force*)"
+  - "Bash(git push -f*)"
 ---
 
 # Agente Engenheiro DevOps
@@ -31,7 +45,7 @@ Você é um **Engenheiro DevOps Sênior** com mais de 10 anos de experiência em
 | Docker | Multi-stage builds, otimização de imagem, security scanning |
 | Docker Compose | Orquestração local, profiles, extensions |
 | Kubernetes | Deployments, Services, Ingress, ConfigMaps, Secrets |
-| Helm | Charts, values, templating | 4.2.0 (MAJOR — server-side apply, plugins WASM, API v4 ; Helm 3 EOL segurança nov. 2026) |
+| Helm | Charts, values, templating | 4.2.2 (Helm 4 = MAJOR — server-side apply, plugins WASM, API v4 ; Helm 3 EOL segurança nov. 2026) |
 
 ### Provedores de Nuvem
 | Provedor | Serviços |

package/Dev/i18n/pt/Common/agents/ralph-conductor.md

@@ -5,6 +5,17 @@ model: opus
 effort: xhigh
 maxTurns: 10
 memory: user
+disallowedTools:
+  - "Bash(rm -rf:*)"
+  - "Bash(dd:*)"
+  - "Bash(mkfs:*)"
+  - "Bash(:(){:|:&};:*)"
+  - "Bash(sudo:*)"
+  - "Bash(chmod 777:*)"
+  - "Bash(curl * | sh*)"
+  - "Bash(wget * | sh*)"
+  - "Bash(git push --force*)"
+  - "Bash(git push -f*)"
 ---
 
 # Agente Ralph Conductor v2.0

package/Dev/i18n/pt/Common/agents/refactoring-specialist.md

@@ -7,6 +7,15 @@ maxTurns: 8
 tools: [Read, Glob, Grep, Edit, Write, Bash, WebFetch, WebSearch]
 permissionMode: default
 skills: [solid-principles, testing, kiss-dry-yagni]
+disallowedTools:
+  - "Bash(rm -rf:*)"
+  - "Bash(dd:*)"
+  - "Bash(mkfs:*)"
+  - "Bash(:(){:|:&};:*)"
+  - "Bash(sudo:*)"
+  - "Bash(chmod 777:*)"
+  - "Bash(curl * | sh*)"
+  - "Bash(wget * | sh*)"
 ---
 
 # Agente Especialista em Refatoração

package/Dev/i18n/pt/Common/agents/security-auditor.md

@@ -22,13 +22,16 @@ Você é um **Auditor de Segurança Sênior** com mais de 15 anos de experiênci
 
 | # | Ameaça | Foco da auditoria |
 |---|--------|-------------------|
-| 1 | Broken Access Control (inclui SSRF) | Verificar permissões por requisição, negar por padrão |
-| 2 | Cryptographic Failures | TLS 1.3, Argon2id, sem MD5/SHA1 em código novo |
-| 3 | Injection | Consultas parametrizadas, validação, sanitização |
-| 4 | Insecure Design | Modelagem de ameaças, rate limiting |
-| 5 | Security Misconfiguration | Hardening, mensagens de erro genéricas em produção |
-| 6 | Software Supply Chain Failures | SLSA, SBOM, Sigstore keyless |
-| 7 | Mishandling of Exceptional Conditions | Registrar erros, nunca expor stack traces |
+| A01 | Broken Access Control (inclui SSRF) | Verificar permissões por requisição, negar por padrão |
+| A02 | Security Misconfiguration | Hardening, mensagens de erro genéricas em produção |
+| A03 | Software Supply Chain Failures | SLSA, SBOM, Sigstore keyless, Dependabot/Renovate, Trivy/Grype, `npm audit --audit-level=moderate` |
+| A04 | Cryptographic Failures | TLS 1.3, Argon2id, sem MD5/SHA1 em código novo |
+| A05 | Injection | Consultas parametrizadas, validação, sanitização |
+| A06 | Insecure Design | Modelagem de ameaças, rate limiting |
+| A07 | Authentication Failures | MFA, protecao contra forca bruta, JWT EdDSA, sessoes invalidadas no logout |
+| A08 | Software or Data Integrity Failures | Verificacao de assinaturas/checksums, CI/CD seguro, atualizacoes assinadas |
+| A09 | Security Logging and Alerting Failures | Centralizar logs, alertas em anomalias, retencao >= 1 ano, nunca registrar credenciais/tokens |
+| A10 | Mishandling of Exceptional Conditions | Registrar erros, nunca expor stack traces |
 
 ### Domínios de auditoria
 

package/Dev/i18n/pt/Common/agents/tdd-coach.md

@@ -7,6 +7,15 @@ maxTurns: 8
 tools: [Read, Glob, Grep, Edit, Write, Bash, WebFetch, WebSearch]
 permissionMode: default
 skills: [testing, solid-principles]
+disallowedTools:
+  - "Bash(rm -rf:*)"
+  - "Bash(dd:*)"
+  - "Bash(mkfs:*)"
+  - "Bash(:(){:|:&};:*)"
+  - "Bash(sudo:*)"
+  - "Bash(chmod 777:*)"
+  - "Bash(curl * | sh*)"
+  - "Bash(wget * | sh*)"
 ---
 
 # Agente Coach TDD/BDD

package/Dev/i18n/pt/Common/agents/uiux-orchestrator.md

@@ -4,8 +4,17 @@ description: UI-UX coordination and orchestration
 model: sonnet
 effort: medium
 maxTurns: 10
-tools: [Read, Glob, Grep, Edit, Write, Bash, Task, WebFetch, WebSearch]
+tools: [Read, Glob, Grep, Edit, Write, Bash, Agent, WebFetch, WebSearch]
 permissionMode: default
+disallowedTools:
+  - "Bash(rm -rf:*)"
+  - "Bash(dd:*)"
+  - "Bash(mkfs:*)"
+  - "Bash(:(){:|:&};:*)"
+  - "Bash(sudo:*)"
+  - "Bash(chmod 777:*)"
+  - "Bash(curl * | sh*)"
+  - "Bash(wget * | sh*)"
 ---
 
 # Agente Orquestrador UI/UX

package/Dev/i18n/pt/Common/commands/getting-started.md

@@ -70,7 +70,7 @@ Based on the detected stack, recommend 3 contextualized commands that provide im
 - `/vuejs:check-security` — XSS, CSP, OWASP audit
 
 **Laravel:**
-- `/laravel:check-code-quality` — PSR-12, Pest 4, coding standards
+- `/laravel:check-code-quality` — PER-CS 3.0, Pest 4/5, coding standards
 - `/laravel:check-testing` — Test coverage with Pest
 - `/laravel:check-security` — OWASP audit, Sanctum config
 
@@ -91,7 +91,7 @@ Based on the detected stack, recommend 3 contextualized commands that provide im
 
 **PHP (standalone):**
 - `/php:check-code-quality` — PSR-12, PHPStan Level 10
-- `/php:check-testing` — Pest 4 test coverage
+- `/php:check-testing` — Pest 5 test coverage
 - `/php:check-security` — Security best practices
 
 **Unknown/Multi-stack:**

package/Dev/i18n/pt/Common/commands/setup-rtk.md

@@ -75,9 +75,9 @@ echo "CLAUDE_CODE_FORK_SUBAGENT=${CLAUDE_CODE_FORK_SUBAGENT:-NÃO DEFINIDO}"
 Se não estiverem definidas, recomendar adicionar a `~/.bashrc` (ou `~/.zshrc`):
 
 ```bash
-# Usar Sonnet 4.6 para sub-agents (exploração, grep, leitura de ficheiros) em vez de Opus
+# Usar Sonnet 5.5 para sub-agents (exploração, grep, leitura de ficheiros) em vez de Opus
 # → 40-60% de redução de custo nas invocações de sub-agents
-export CLAUDE_CODE_SUBAGENT_MODEL="sonnet"
+export CLAUDE_CODE_SUBAGENT_MODEL="claude-sonnet-5-5"
 
 # Executar sub-agents em contextos isolados (Claude Code 2.1.117+, ver COMPATIBILITY.md)
 # → Evita poluir a janela de contexto principal com o estado intermédio dos sub-agents

package/Dev/i18n/pt/Common/rules/04-solid-principles.md

@@ -357,7 +357,7 @@ A logica de negocio e isolada dos detalhes tecnicos
 
 #### SRP
 - [ ] Cada classe tem uma unica responsabilidade claramente definida
-- [ ] Os metodos fazem uma unica coisa (< 20 linhas)
+- [ ] Os metodos fazem uma unica coisa (meta < 10, max 20 linhas)
 - [ ] Sem metodos com "e" ou "ou" no nome
 
 #### OCP

package/Dev/i18n/pt/Common/rules/05-kiss-dry-yagni.md

@@ -29,7 +29,7 @@ O codigo mais simples e frequentemente o melhor codigo.
 
 ### Regras KISS
 
-1. **Metodos curtos:** Maximo 20 linhas por metodo
+1. **Metodos curtos:** Meta < 10 linhas, limite maximo 20 linhas por metodo
 2. **Complexidade ciclomatica:** Maximo 10 por metodo
 3. **Profundidade de indentacao:** Maximo 3 niveis
 4. **Parametros:** Maximo 4 parametros por metodo
@@ -369,7 +369,7 @@ class ConcreteRepository         // Infrastructure
 ### Antes de cada commit
 
 #### KISS
-- [ ] Metodos < 20 linhas
+- [ ] Metodos < 10 linhas (limite 20)
 - [ ] Complexidade ciclomatica < 10
 - [ ] Indentacao max 3 niveis
 - [ ] Parametros max 4 por metodo
@@ -395,11 +395,14 @@ class ConcreteRepository         // Infrastructure
 |---------|------|--------|
 | Linhas por metodo | < 10 | < 20 |
 | Complexidade ciclomatica | < 5 | < 10 |
+| Complexidade cognitiva | < 7 | < 10 |
 | Linhas por classe | < 150 | < 200 |
 | Duplicacao | 0% | < 3% |
 | Cobertura de testes | > 80% | > 70% |
 | Dependencias por classe | < 5 | < 7 |
 
+> Os limites de Cognitive Complexity (SonarQube S3776) < 7 / < 10 sao uma escolha interna, deliberadamente mais estrita que o padrao do Sonar (15 por funcao); relaxe-os se o contexto da equipe exigir.
+
 ---
 
 ## Recursos

package/Dev/i18n/pt/Common/rules/10-documentation.md

@@ -289,7 +289,7 @@ docs/
 ### OpenAPI (Swagger)
 
 ```yaml
-openapi: 3.1.1
+openapi: 3.2.1  # current (3.1.x remains valid if your tooling lags)
 info:
   title: User API
   version: 1.0.0