{
  "compilerOptions": {
    "target": "ES2023",
    "moduleDetection": "force",
    "useDefineForClassFields": true,
    "skipLibCheck": true,

    /* ── strict und darüber hinaus ───────────────────────────────────
       `strict` allein reicht nicht: die folgenden Optionen fangen genau
       die Fehlerklassen ab, die in Electron-Projekten teuer werden
       (undefinierte Array-Zugriffe, unsaubere IPC-Nutzlasten).        */
    "strict": true,
    "noImplicitOverride": true,
    "noUncheckedIndexedAccess": true,
    "exactOptionalPropertyTypes": true,
    "noFallthroughCasesInSwitch": true,
    "noImplicitReturns": true,
    "noPropertyAccessFromIndexSignature": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "allowUnusedLabels": false,
    "allowUnreachableCode": false,

    /* ── Modulauflösung (Bundler: Vite/Rollup) ───────────────────── */
    "module": "ESNext",
    "moduleResolution": "bundler",
    "verbatimModuleSyntax": true,
    "isolatedModules": true,
    "resolveJsonModule": true,
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true

    /* Kein "noEmit" hier: die Teilprojekte sind `composite` (für
       Editor-Projektreferenzen). Die npm-Skripte rufen deshalb
       `tsc --noEmit -p <projekt>` auf. Beides verträgt sich seit
       TypeScript 5.x; es entstehen keine Übersetzungsartefakte, nur die
       `.tsbuildinfo`-Dateien unter `node_modules/.tmp/` (also außerhalb der
       Versionsverwaltung). Die zwischenzeitliche Notlösung
       `--composite false` ist entfallen – sie hatte den Typprüfer nur
       ruhiggestellt, statt die Projektzuschnitte zu ordnen. */
  }
}