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

package/Dev/i18n/de/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/de/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/de/Team/commands/delivery.md

@@ -517,7 +517,7 @@ Für 1 EPIC, 5 US, ~25 Aufgaben:
 | **Gesamtzeit** | **~120 Min.** | **~55 Min.** | **~2,2x** |
 | Gesamtkosten* | ~$28 | ~$17 | **-38%** |
 
-*Kosteneinsparungen, weil Sonnet ($3/$15/M) die meiste Arbeit übernimmt vs. Opus ($15/$75/M) im sequenziellen Modus.
+*Kosteneinsparungen, weil Sonnet 5.5 ($2/$10/M) die meiste Arbeit übernimmt vs. Opus 5.5 ($4/$20/M) im sequenziellen Modus.
 
 ## Leistungserwartungen
 

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

@@ -8,7 +8,7 @@
 
 **Geltungsbereich**: ausschließlich framework-agnostische Platform-Features — vercel.json, Functions, ISR, Cron, Storage. Ausdrücklich nicht Next.js, nicht der eigene Deploy-Adapter irgendeines Frameworks.
 
-> **Hinweis:** Vercel (dieser Stack) deckt ausschließlich die **framework-agnostische Deployment-Platform-Oberfläche** ab: `vercel.json`-Konfiguration (Rewrites, Redirects, Headers, Regionen), Serverless Functions auf der Node.js-Laufzeit / Fluid Compute, ISR-Cache-Primitiven, Cron Jobs, Vercel Storage (Blob nativ; Postgres/KV über den Marketplace — Neon/Upstash), Analytics/Speed Insights sowie den Workflow für Umgebungsvariablen/Preview-Deployments. Es ist **kein** Next.js-Stack — Next.js selbst liegt außerhalb des Geltungsbereichs und ist keine unterstützte claude-craft-Technologie (es existiert kein `/nextjs:*`-Namespace). Framework-spezifische Routing-, Rendering- oder Data-Fetching-Muster gehören zum jeweils eigenen Stack des Frameworks (`/react:*`, `/vuejs:*`, `/angular:*`) — dort ist in der `tooling.md` nachzulesen, wie die Integration mit Vercels Build-Output funktioniert. Zusätzlich ist die Edge Runtime (`export const runtime = 'edge'`) seit 2026 von Vercel **deprecated** zugunsten von Fluid Compute auf der Node.js-Laufzeit; dieser Stack dokumentiert die Edge Runtime nur, um Legacy-Code zu identifizieren und zu migrieren, nicht als empfohlenes Muster für neue Arbeiten.
+> **Hinweis:** Vercel (dieser Stack) deckt ausschließlich die **framework-agnostische Deployment-Platform-Oberfläche** ab: `vercel.json`-Konfiguration (Rewrites, Redirects, Headers, Regionen), Serverless Functions auf der Node.js-Laufzeit / Fluid Compute, ISR-Cache-Primitiven, Cron Jobs, Vercel Storage (Blob nativ; Postgres/KV über den Marketplace — Neon/Upstash), Analytics/Speed Insights sowie den Workflow für Umgebungsvariablen/Preview-Deployments. Es ist **kein** Next.js-Stack — Next.js selbst liegt außerhalb des Geltungsbereichs und ist keine unterstützte claude-craft-Technologie (es existiert kein `/nextjs:*`-Namespace). Framework-spezifische Routing-, Rendering- oder Data-Fetching-Muster gehören zum jeweils eigenen Stack des Frameworks (`/react:*`, `/vuejs:*`, `/angular:*`) — dort ist in der `tooling.md` nachzulesen, wie die Integration mit Vercels Build-Output funktioniert. Zusätzlich wird die Edge Runtime (`export const runtime = 'edge'`) von Vercel **nicht empfohlen**; Vercel bevorzugt Fluid Compute auf der Node.js-Laufzeit; dieser Stack dokumentiert die Edge Runtime nur, um Legacy-Code zu identifizieren und zu migrieren, nicht als empfohlenes Muster für neue Arbeiten.
 
 ### Projektstruktur
 ```
@@ -38,7 +38,7 @@ Vollständige Muster siehe `rules/02-architecture.md`.
 | Regel | Begründung |
 |------|--------|
 | vercel.json gegen `$schema` validiert | Fängt vertippte Globs/Schlüssel ab, bevor sie beim Deploy stillschweigend fehlschlagen |
-| Node.js/Fluid Compute ist die Laufzeit-Vorgabe | Die Edge Runtime (`runtime: 'edge'`) ist deprecated — nur Ziel für Legacy-Migrationen |
+| Node.js/Fluid Compute ist die Laufzeit-Vorgabe | Die Edge Runtime (`runtime: 'edge'`) wird nicht empfohlen — nur Ziel für Legacy-Migrationen |
 | Umgebungsvariablen niemals hartkodiert oder committet | Secrets gehören in Vercels Umgebungsvariablen-Store, pro Umgebung skopiert |
 | Cron-Endpunkte prüfen den Secret-Header | Ein ungeschützter Cron-Pfad kann von jedem ausgelöst werden, der ihn findet |
 | >= 80% Coverage auf der Handler-Logik | Qualitätssicherung für die Business-Logik von Functions und Middleware |

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

@@ -211,9 +211,9 @@ Deklariert irgendeine Function export const config = { runtime: 'edge' } (oder
 "runtime": "edge" im functions-Block der vercel.json)?
   JA --> Wurde diese Function neu hinzugefügt oder kürzlich geändert (nicht rein
           legacy, unangetasteter Code)?
-          JA --> SCHWERWIEGEND: die Edge Runtime ist von Vercel deprecated — Migration
+          JA --> SCHWERWIEGEND: die Edge Runtime wird von Vercel nicht empfohlen — Migration
                   zu Fluid Compute auf der Node.js-Laufzeit (Standard) für vollen
-                  Node-API-Zugriff, Bytecode-gecachte Cold Starts (Node 20+) und
+                  Node-API-Zugriff, Bytecode-gecachte Cold Starts (Node 22+) und
                   Active-CPU-Pricing
           NEIN --> GERINGFÜGIG: als Legacy-Migrationsschuld markieren, unmodifizierten
                   Code nicht blockieren
@@ -228,7 +228,7 @@ Ist die Node.js-Version gepinnt (package.json "engines.node", oder die "Node.js
 Version"-Einstellung des Vercel-Projekts) auf 20.x oder neuer?
   NEIN --> GERINGFÜGIG: eine ungepinnte/alte Node-Version verzichtet auf die
           Cold-Start-Verbesserung durch Fluid Computes Bytecode-Caching
-          (spezifisch für Node 20+) und riskiert stillschweigende Laufzeit-Drift
+          (spezifisch für Node 22+) und riskiert stillschweigende Laufzeit-Drift
           über Redeploys hinweg
   JA --> OK
 ```
@@ -251,7 +251,7 @@ bevor er ihn verwendet?
 
 **Edge Runtime bei neuem/geändertem Code:**
 ```typescript
-// VERBOTEN — Edge Runtime bei einer neu hinzugefügten Function deklariert: deprecatetes Muster
+// VERBOTEN — Edge Runtime bei einer neu hinzugefügten Function deklariert: nicht empfohlenes Muster
 export const config = { runtime: 'edge' };
 
 export default function handler(req: Request) {
@@ -260,7 +260,7 @@ export default function handler(req: Request) {
 }
 
 // KORREKT — Node.js-/Fluid-Compute-Vorgabe, voller Node-API-Zugriff, schnellere
-// Cold Starts auf Node 20+ via Bytecode-Caching
+// Cold Starts auf Node 22+ via Bytecode-Caching
 export const config = { maxDuration: 10 };
 
 export default function handler(req: VercelRequest, res: VercelResponse) {
@@ -286,7 +286,7 @@ export default function handler(req: VercelRequest, res: VercelResponse) {
 ```
 ```typescript
 // api/legacy.ts
-// TODO(JIRA-1234): weg von der Edge Runtime migrieren — von Vercel deprecated, siehe Fluid Compute
+// TODO(JIRA-1234): weg von der Edge Runtime migrieren — von Vercel nicht empfohlen, siehe Fluid Compute
 export const config = { runtime: 'edge' };
 ```
 
@@ -339,7 +339,7 @@ export default async function handler(req: VercelRequest, res: VercelResponse) {
 |---------|----------|--------------|
 | Laufzeit | Node.js-/Fluid-Compute-Vorgabe | `runtime: 'edge'` bei neuem/geändertem Code |
 | Legacy Edge Runtime | Tickettierter Migrations-Marker (TODO + Issue-Referenz) | Stillschweigende, unmarkierte Edge Runtime belassen |
-| Node-Version | Auf 20+ gepinnt (`engines.node` oder Projekteinstellung) | Ungepinnt, driftende Vorgabe |
+| Node-Version | Auf 22.x oder 24.x gepinnt (Node 20 ist bei Vercel seit 2026-10-01 deprecated) (`engines.node` oder Projekteinstellung) | Ungepinnt, driftende Vorgabe |
 | Handler-Input | Validiert/geparst (zod, manueller Guard) vor Verwendung | Rohes `req.body`/`req.query` ungeprüft verwendet |
 | Handler-Output | Expliziter Status + typisierter Body auf jedem Pfad | Implizites 200, inkonsistente Fehlerform |
 | Cold-Start-Bewusstsein | Schwere Imports lazy geladen/verzögert, wenn nicht immer benötigt | Jede Abhängigkeit eager am Modul-Top importiert |
@@ -816,7 +816,7 @@ describe('api/cron/daily', () => {
 | Thema | Zu prüfen |
 |-------|---------------|
 | **Fluid Compute** | Bestätigen, dass Functions standardmäßig auf Fluid Compute laufen (Active-CPU-Pricing), nicht auf dem legacy Serverless-Functions-Billing mit fixer Concurrency |
-| **Deprecation der Edge Runtime** | Jedes gefundene `runtime: 'edge'` sollte eine Migrationsticket-Referenz tragen, niemals als empfohlenes Muster für neuen Code präsentiert werden |
+| **Edge Runtime nicht empfohlen** | Jedes gefundene `runtime: 'edge'` sollte eine Migrationsticket-Referenz tragen, niemals als empfohlenes Muster für neuen Code präsentiert werden |
 | **Deprecatete Storage-Pakete** | `@vercel/kv`/`@vercel/postgres`-Imports sind unabhängig vom Hinzufügungszeitpunkt ein SCHWERWIEGENDER Befund — für Marketplace-Migration (Neon/Upstash) markieren |
 | **ISR-Cache-Primitive vs. vercel.json-Headers** | Framework-native Revalidierung und vercel.json-`headers` dürfen niemals dieselbe Route für `Cache-Control` adressieren |
 | **Cron-Plan-Limits** | Der Hobby-Plan begrenzt Cron Jobs auf 1/Tag — verifizieren, dass der deklarierte Zeitplan zur tatsächlich genutzten Plan-Stufe passt |

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

@@ -6,7 +6,7 @@
 
 **Stack**: Vite {{VITE_VERSION}}, TypeScript {{TS_VERSION}}
 
-**Geltungsbereich**: ausschließlich framework-agnostische Vite-Nutzung — Vanilla JS/TS-Anwendungen, Bibliotheksentwicklung (build.lib), Multi-Page-Anwendungen (rollupOptions.input), Worker-/WASM-Einstiegspunkte. Nicht zuständig für die Dev-Server-Konfiguration von React/Vue/Angular/Svelte — siehe dazu die jeweilige tooling.md des betreffenden Stacks.
+**Geltungsbereich**: ausschließlich framework-agnostische Vite-Nutzung — Vanilla JS/TS-Anwendungen, Bibliotheksentwicklung (build.lib), Multi-Page-Anwendungen (rolldownOptions.input), Worker-/WASM-Einstiegspunkte. Nicht zuständig für die Dev-Server-Konfiguration von React/Vue/Angular/Svelte — siehe dazu die jeweilige tooling.md des betreffenden Stacks.
 
 ### Projektstruktur
 ```
@@ -32,7 +32,7 @@ project-root/
 ### Architektur: {{ARCHITECTURE_PATTERN}}
 - **Einstiegspunkt**: `index.html` im Projekt-Root (bzw. in `root`), niemals innerhalb von `public/`
 - **Bibliotheksmodus**: `build.lib` + `vite-plugin-dts` für Pakete, die auf npm veröffentlicht werden
-- **Multi-Page**: `build.rollupOptions.input` benennt jeden HTML-Einstiegspunkt explizit
+- **Multi-Page**: top-level `input` benennt jeden HTML-Einstiegspunkt explizit
 - **Worker/WASM**: `new Worker(new URL(...), { type: 'module' })`, Suffixe `?init`/`?url`
 
 Siehe `rules/02-architecture.md` für vollständige Muster.

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

@@ -1,6 +1,6 @@
 ---
 name: vite-reviewer
-description: Spezialist für framework-agnostische Code-Reviews von Vite 8.x — Vanilla JS/TS-Anwendungen, Bibliotheksentwicklung (build.lib), Multi-Page-Anwendungen (rollupOptions.input), Worker-/WASM-Einstiegspunkte, Plugin-Konfiguration
+description: Spezialist für framework-agnostische Code-Reviews von Vite 8.x — Vanilla JS/TS-Anwendungen, Bibliotheksentwicklung (build.lib), Multi-Page-Anwendungen (rolldownOptions.input), Worker-/WASM-Einstiegspunkte, Plugin-Konfiguration
 model: haiku
 effort: low
 maxTurns: 6
@@ -14,13 +14,13 @@ skills: [solid-principles, testing, security]
 
 ## Identität
 
-Ich bin ein Spezialist für Code-Reviews von Vite 8.x und arbeite bewusst **framework-agnostisch**. Mein Geltungsbereich umfasst die reine Vite-Nutzung: Vanilla-JS/TS-Anwendungen (index.html als Quell-Einstiegspunkt, niemals innerhalb von public/), Bibliotheksentwicklung über build.lib und vite-plugin-dts, Multi-Page-Anwendungen über build.rollupOptions.input sowie Worker-/WASM-Einstiegspunkte. Ich decke KEINE Vite-Integrationen ab, die spezifisch für React, Vue, Angular oder Svelte sind -- diese Stacks dokumentieren ihre eigene Dev-Server-Integration bereits in ihrer jeweiligen tooling.md-Datei. Ich führe kein generisches Audit durch -- ich erkenne, was den Modulgraph zerstört, das Bundle aufbläht oder eine Vite-Konfiguration unnötig verkompliziert.
+Ich bin ein Spezialist für Code-Reviews von Vite 8.x und arbeite bewusst **framework-agnostisch**. Mein Geltungsbereich umfasst die reine Vite-Nutzung: Vanilla-JS/TS-Anwendungen (index.html als Quell-Einstiegspunkt, niemals innerhalb von public/), Bibliotheksentwicklung über build.lib und vite-plugin-dts, Multi-Page-Anwendungen über build.rolldownOptions.input sowie Worker-/WASM-Einstiegspunkte. Ich decke KEINE Vite-Integrationen ab, die spezifisch für React, Vue, Angular oder Svelte sind -- diese Stacks dokumentieren ihre eigene Dev-Server-Integration bereits in ihrer jeweiligen tooling.md-Datei. Ich führe kein generisches Audit durch -- ich erkenne, was den Modulgraph zerstört, das Bundle aufbläht oder eine Vite-Konfiguration unnötig verkompliziert.
 
 ## Bewertungssystem (100 Punkte)
 
 | Kategorie | Punkte | Fokus |
 |----------|--------|-------|
-| Konfiguration und Architektur Vite | 30 | vite.config.ts, index.html, build.lib, rollupOptions.input, Plugins |
+| Konfiguration und Architektur Vite | 30 | vite.config.ts, index.html, build.lib, rolldownOptions.input, Plugins |
 | TypeScript und Qualität | 20 | strict tsconfig, moduleResolution bundler, vite-plugin-dts |
 | Tests | 25 | Vitest-Konfiguration/Coverage, Tests auf dem veröffentlichten Build |
 | Build-Ausgabe und Performance | 25 | Bundle-Größe, Tree-Shaking, Externalisierung, Code-Splitting |
@@ -50,7 +50,7 @@ Wird das Paket von anderen Paketen/Anwendungen konsumiert (auf npm veröffentlic
     NEIN --> KRITISCH: ohne build.lib erzeugt Vite ein App-Bundle (index.html
             erforderlich, keine mehreren ESM/CJS-Formate, keine Externalisierung
             von Peer Dependencies)
-    JA --> Deckt rollupOptions.external alle peerDependencies ab?
+    JA --> Deckt rolldownOptions.external alle peerDependencies ab?
       NEIN --> SCHWERWIEGEND: die Laufzeitumgebung des Host-Frameworks wird für
               den Konsumenten dupliziert
       JA --> Ist vite-plugin-dts konfiguriert?
@@ -65,7 +65,7 @@ Wird das Paket von anderen Paketen/Anwendungen konsumiert (auf npm veröffentlic
 ```
 Hat das Projekt mehrere eigenständige HTML-Seiten (nicht nur client-seitige Routen)?
   NEIN --> Klassische SPA: eine einzige index.html, client-seitiges Routing
-  JA --> Ist build.rollupOptions.input ein Objekt, das jede Seite benennt?
+  JA --> Ist build.rolldownOptions.input ein Objekt, das jede Seite benennt?
     NEIN --> SCHWERWIEGEND: sekundäre Seiten werden nicht gebaut oder hängen von
             einem manuellen, nicht optimierten Ladepfad ab
     JA --> Teilen sich die Seiten schwere Abhängigkeiten?
@@ -136,7 +136,7 @@ export default defineConfig({
       formats: ['es', 'cjs'],
       fileName: (format) => `my-lib.${format}.js`,
     },
-    rollupOptions: {
+    rolldownOptions: {
       // Peer Dependencies niemals bündeln
       external: ['react', 'react-dom'],
       output: {
@@ -147,7 +147,7 @@ export default defineConfig({
 });
 ```
 
-**rollupOptions.input für Multi-Page-Anwendungen:**
+**rolldownOptions.input für Multi-Page-Anwendungen:**
 ```typescript
 // SCHLECHT: sekundäre Seiten in der Konfiguration nicht deklariert
 export default defineConfig({});
@@ -158,7 +158,7 @@ import { defineConfig } from 'vite';
 
 export default defineConfig({
   build: {
-    rollupOptions: {
+    rolldownOptions: {
       input: {
         main: resolve(__dirname, 'index.html'),
         about: resolve(__dirname, 'pages/about.html'),
@@ -228,8 +228,10 @@ export function vitePluginMyTransform(): Plugin {
 | index.html | Im Root von `root`, als Quell-Einstiegspunkt transformiert | Nach public/ kopiert |
 | public/ | Nur statische Assets (favicon, robots.txt) | Quell-HTML/JS aus public/ importiert |
 | build.lib | Für jedes veröffentlichte Paket konfiguriert | App-Bundle als Bibliothek veröffentlicht |
-| rollupOptions.external | Peer Dependencies externalisiert | Host-Framework in der Bibliothek gebündelt |
-| rollupOptions.input | Objekt, das jede HTML-Seite benennt (Multi-Page) | Manuelles, nicht optimiertes Laden |
+| rolldownOptions.external | Peer Dependencies externalisiert | Host-Framework in der Bibliothek gebündelt |
+| rolldownOptions.input | Objekt, das jede HTML-Seite benennt (Multi-Page) | Manuelles, nicht optimiertes Laden |
+| rollupOptions / worker.rollupOptions / optimizeDeps.esbuildOptions | rolldownOptions-Äquivalente (seit Vite 8 veraltet) | Veraltete Aliase in der Config beibehalten |
+| Node.js | `^20.19.0` oder `>=22.12.0` (Vite-8-Voraussetzung) | Node 18 oder 20 < 20.19 |
 | Benutzerdefinierte Plugins | Präfix vite-plugin-*, explizite `name`-Eigenschaft | Anonymes Plugin ohne Namen |
 | Umgebungsvariablen | Präfix VITE_ für Client-Exposition | Ungeprefixte Secrets client-seitig referenziert |
 
@@ -240,7 +242,7 @@ export function vitePluginMyTransform(): Plugin {
 | vite.config.ts korrekt (defineConfig, Aliase synchron mit tsconfig) | 8 |
 | index.html im Root des richtigen Ordners, niemals in public/ | 6 |
 | build.lib korrekt konfiguriert (entry, formats, external, vite-plugin-dts) | 8 |
-| rollupOptions.input für Multi-Page, Plugins gemäß Konvention vite-plugin-* benannt | 8 |
+| rolldownOptions.input für Multi-Page, Plugins gemäß Konvention vite-plugin-* benannt | 8 |
 
 ---
 
@@ -447,7 +449,7 @@ Deklariert package.json "sideEffects": false?
 ### Entscheidungsbaum: Code-Splitting für Multi-Page
 
 ```
-Hat die Anwendung mehrere Seiten (rollupOptions.input)?
+Hat die Anwendung mehrere Seiten (rolldownOptions.input)?
   JA --> Isoliert manualChunks einen gemeinsamen Vendor-Chunk?
     NEIN --> SCHWERWIEGEND: jede Seite dupliziert dieselben schweren Abhängigkeiten
     JA --> Überschreitet der größte Lazy-Chunk 80KB gzip?
@@ -492,14 +494,14 @@ export { formatDate, parseDate } from './utils';
 // SCHLECHT: das Host-Framework wird in der veröffentlichten Bibliothek gebündelt
 export default defineConfig({
   build: { lib: { entry: 'src/index.ts', formats: ['es'] } },
-  // kein rollupOptions.external
+  // kein rolldownOptions.external
 });
 
 // GUT: Peer Dependencies explizit externalisiert
 export default defineConfig({
   build: {
     lib: { entry: 'src/index.ts', formats: ['es', 'cjs'] },
-    rollupOptions: {
+    rolldownOptions: {
       external: (id) => /^(react|react-dom|vue)/.test(id),
     },
   },
@@ -513,7 +515,7 @@ export default defineConfig({
 
 // GUT: gemeinsamer Vendor-Chunk über alle Seiten hinweg
 build: {
-  rollupOptions: {
+  rolldownOptions: {
     output: {
       manualChunks(id) {
         if (id.includes('node_modules')) return 'vendor';
@@ -570,8 +572,8 @@ build: {
 
 ### Phase 2: Vite-spezifische Konfiguration (15 Min.)
 
-1. Bei Bibliothek: build.lib, formats, rollupOptions.external, vite-plugin-dts prüfen
-2. Bei Multi-Page: rollupOptions.input, manualChunks prüfen
+1. Bei Bibliothek: build.lib, formats, rolldownOptions.external, vite-plugin-dts prüfen
+2. Bei Multi-Page: rolldownOptions.input, manualChunks prüfen
 3. Bei Worker/WASM: new URL(...import.meta.url), Suffixe ?init/?url prüfen
 4. Namenskonvention benutzerdefinierter Plugins prüfen (vite-plugin-*, name-Eigenschaft)
 5. Umgebungsvariablen prüfen (Präfix VITE_, keine client-seitig exponierten Secrets)

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

@@ -36,7 +36,7 @@ Vollständige Konfigurations- und Architekturprüfung ausführen:
 - Korrektheit von vite.config.ts (defineConfig, Aliase synchron mit tsconfig) (8 Pkt.)
 - Platzierung von index.html im Projekt-Root, niemals in public/ (6 Pkt.)
 - Konfiguration von build.lib für Bibliotheken (entry, formats, external, vite-plugin-dts) (8 Pkt.)
-- rollupOptions.input für Multi-Page-Anwendungen, Namenskonvention der Plugins (vite-plugin-*) (8 Pkt.)
+- rolldownOptions.input für Multi-Page-Anwendungen, Namenskonvention der Plugins (vite-plugin-*) (8 Pkt.)
 
 **Referenz**: `.claude/agents/vite-reviewer.md` (Abschnitt 1)
 
@@ -151,7 +151,7 @@ Teilpunktzahlen:
   • Korrektheit von vite.config.ts   : XX/8
   • Platzierung von index.html       : XX/6
   • Konfiguration von build.lib      : XX/8
-  • rollupOptions.input / Plugins    : XX/8
+  • rolldownOptions.input / Plugins    : XX/8
 
 Stärken:
 - [Architekturstärken]

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

@@ -46,8 +46,8 @@ Is the state synchronous and used for rendering?
 
 **Zoneless by default (stable) :**
 - ~33 KB bundle savings (Zone.js optional)
-- +30-40% rendering performance improvement according to Angular DevRel
-- Stable API: `provideZonelessChangeDetection()` from `@angular/core` (no longer `Experimental`)
+- Performance gains vary by application (the "+30-40%" figure comes from a 2024 source): measure, do not assume
+- No provider required in v21+/v22: `provideZonelessChangeDetection()` is only needed in v20 (https://angular.dev/guide/zoneless)
 
 **Signal Forms (stable v22) :**
 - Native signal-based alternative to Reactive Forms, **production-ready**
@@ -421,7 +421,7 @@ Does the application use zoneless change detection?
     YES --> Do event listeners correctly trigger CD?
   NO --> Is Zone.js used?
     YES --> MINOR in v22+: migration to zoneless recommended (saves ~33 KB)
-    NO --> Verify provideZonelessChangeDetection() is configured (stable since v20.2)
+    NO --> Verify no provideZoneChangeDetection() re-enables Zone.js (zoneless by default since v21)
 
 Is httpResource() used for repetitive HTTP requests?
   NO --> Do components use signal + effect + HttpClient?

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

@@ -17,6 +17,20 @@ permissionMode: default
 skills:
   - git-workflow
   - security
+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*)"
 ---
 
 # DevOps Engineer Agent
@@ -41,7 +55,7 @@ You are a **Senior DevOps Engineer** with 10+ years of experience in CI/CD, cont
 | Docker | Multi-stage builds, image optimization, security scanning |
 | Docker Compose | Local orchestration, profiles, extensions |
 | Kubernetes | Deployments, Services, Ingress, ConfigMaps, Secrets |
-| Helm | Charts, values, templating | 4.2.0 (MAJOR — server-side apply, WASM plugins, API v4 ; Helm 3 EOL security Nov. 2026) |
+| Helm | Charts, values, templating | 4.2.2 (Helm 4 = MAJOR — server-side apply, WASM plugins, API v4 ; Helm 3 EOL security Nov. 2026) |
 
 ### Cloud Providers
 | Provider | Services |

package/Dev/i18n/en/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*)"
 ---
 
 # Ralph Conductor Agent v2.0

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

@@ -17,6 +17,15 @@ skills:
   - solid-principles
   - kiss-dry-yagni
   - testing
+disallowedTools:
+  - "Bash(rm -rf:*)"
+  - "Bash(dd:*)"
+  - "Bash(mkfs:*)"
+  - "Bash(:(){:|:&};:*)"
+  - "Bash(sudo:*)"
+  - "Bash(chmod 777:*)"
+  - "Bash(curl * | sh*)"
+  - "Bash(wget * | sh*)"
 ---
 
 # Refactoring Specialist Agent

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

@@ -22,13 +22,16 @@ You are a **Senior Security Auditor** with 15+ years of experience in pentesting
 
 | # | Threat | Audit Focus |
 |---|--------|-------------|
-| 1 | Broken Access Control (includes SSRF) | Verify permissions per request, deny by default |
-| 2 | Cryptographic Failures | TLS 1.3, Argon2id, no MD5/SHA1 in new code |
-| 3 | Injection | Parameterized queries, validation, sanitization |
-| 4 | Insecure Design | Threat modeling, rate limiting |
-| 5 | Security Misconfiguration | Hardening, generic error messages in production |
-| 6 | Software Supply Chain Failures | SLSA, SBOM, Sigstore keyless |
-| 7 | Mishandling of Exceptional Conditions | Log errors, never expose stack traces |
+| A01 | Broken Access Control (includes SSRF) | Verify permissions per request, deny by default |
+| A02 | Security Misconfiguration | Hardening, generic error messages in production |
+| 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, no MD5/SHA1 in new code |
+| A05 | Injection | Parameterized queries, validation, sanitization |
+| A06 | Insecure Design | Threat modeling, rate limiting |
+| A07 | Authentication Failures | MFA, brute-force protection, JWT EdDSA, sessions invalidated on logout |
+| A08 | Software or Data Integrity Failures | Signature/checksum verification, secured CI/CD, signed updates |
+| A09 | Security Logging and Alerting Failures | Centralize logs, alert on anomalies, retention >= 1 year, never log credentials/tokens |
+| A10 | Mishandling of Exceptional Conditions | Log errors, never expose stack traces |
 
 ### Audit Domains
 

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

@@ -17,6 +17,15 @@ 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*)"
 ---
 
 # TDD/BDD Coach Agent

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

@@ -10,10 +10,19 @@ tools:
   - Grep
   - Edit
   - Write
-  - Task
+  - 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*)"
 ---
 
 # UIUX Orchestrator Agent

package/Dev/i18n/en/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/en/Common/commands/setup-rtk.md

@@ -75,9 +75,9 @@ echo "CLAUDE_CODE_FORK_SUBAGENT=${CLAUDE_CODE_FORK_SUBAGENT:-NOT SET}"
 If not set, recommend adding to `~/.bashrc` (or `~/.zshrc`):
 
 ```bash
-# Use Sonnet 4.6 for sub-agents (exploration, grep, file reading) instead of Opus
+# Use Sonnet 5.5 for sub-agents (exploration, grep, file reading) instead of Opus
 # → 40-60% cost reduction on sub-agent invocations
-export CLAUDE_CODE_SUBAGENT_MODEL="sonnet"
+export CLAUDE_CODE_SUBAGENT_MODEL="claude-sonnet-5-5"
 
 # Run sub-agents in isolated contexts (Claude Code 2.1.117+, see COMPATIBILITY.md)
 # → Avoids polluting the main context window with sub-agent intermediate state

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

@@ -357,7 +357,7 @@ Business logic is isolated from technical details
 
 #### SRP
 - [ ] Each class has a single, clearly defined responsibility
-- [ ] Methods do one thing (< 20 lines)
+- [ ] Methods do one thing (target < 10 lines, max 20)
 - [ ] No methods with "and" or "or" in the name
 
 #### OCP

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

@@ -29,7 +29,7 @@ The simplest code is often the best code.
 
 ### KISS Rules
 
-1. **Short methods:** Maximum 20 lines per method
+1. **Short methods:** Target < 10 lines, hard limit 20 lines per method
 2. **Cyclomatic complexity:** Maximum 10 per method
 3. **Indentation depth:** Maximum 3 levels
 4. **Parameters:** Maximum 4 parameters per method
@@ -369,7 +369,7 @@ class ConcreteRepository         // Infrastructure
 ### Before each commit
 
 #### KISS
-- [ ] Methods < 20 lines
+- [ ] Methods < 10 lines (hard limit 20)
 - [ ] Cyclomatic complexity < 10
 - [ ] Max 3 indentation levels
 - [ ] Max 4 parameters per method
@@ -395,11 +395,14 @@ class ConcreteRepository         // Infrastructure
 |--------|--------|-------|
 | Lines per method | < 10 | < 20 |
 | Cyclomatic complexity | < 5 | < 10 |
+| Cognitive complexity | < 7 | < 10 |
 | Lines per class | < 150 | < 200 |
 | Duplication | 0% | < 3% |
 | Test coverage | > 80% | > 70% |
 | Dependencies per class | < 5 | < 7 |
 
+> Cognitive Complexity (SonarQube S3776) thresholds < 7 / < 10 are an internal, deliberately stricter choice than Sonar's default of 15 per function; relax them if your team context requires it.
+
 ---
 
 ## Resources

package/Dev/i18n/en/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