diff --git a/.github/workflows/sonarqube.yml b/.github/workflows/sonarqube.yml
index a9ed067..456eb6f 100644
--- a/.github/workflows/sonarqube.yml
+++ b/.github/workflows/sonarqube.yml
@@ -36,13 +36,20 @@ jobs:
       - name: Unit tests
         run: npm run test:unit
 
-      # SONAR_TOKEN ist als Repo-Secret nicht gesetzt (Stand 12.09.2026) -- ohne
-      # continue-on-error wuerde dieser Schritt sonst den ganzen Workflow rot faerben,
-      # obwohl Typecheck/Lint/Tests laengst gruen sind. Deckt gleichzeitig den Fall ab,
-      # dass der selbst gehostete SonarQube-Server mal nicht erreichbar ist. Ein "if:" auf
-      # "secrets.SONAR_TOKEN != ''" waere die naheliegende Alternative, macht den Workflow
+      # continue-on-error bleibt auch mit gesetztem SONAR_TOKEN sinnvoll: der selbst
+      # gehostete SonarQube-Server kann mal nicht erreichbar sein, ohne dass das den Rest
+      # des Workflows mitreissen soll. Ein "if:" auf "secrets.SONAR_TOKEN != ''" waere die
+      # naheliegende Alternative fuer den Fall eines fehlenden Secrets, macht den Workflow
       # bei diesem Runner aber ungueltig (0s-Fehlschlag ohne jeden Job-Log) -- deshalb
       # bewusst nur continue-on-error statt eines bedingten Schritts.
+      #
+      # sonar.javascript.node.maxspace=4096: der Standard-Node-Heap der Analyse-Bridge
+      # (rund 2,2 GB) reicht auf dem GitHub-Hosted-Runner fuer dieses Repo nicht --
+      # WeeklyView.tsx allein ist riesig. Ohne das stirbt die Bridge mit "Node.js process
+      # running out of memory", der Scan schlaegt fehl (aufgefangen von continue-on-error,
+      # aber dann laeuft gar keine Analyse). Live beobachtet beim ersten echten Testlauf
+      # mit gueltigem Token am 12.09.2026 -- exakt dieselbe Ursachenklasse wie der
+      # OOM-Absturz von "next build" auf dem Produktionscontainer (siehe CHANGELOG v1.119.4).
       - name: SonarQube scan
         continue-on-error: true
         uses: SonarSource/sonarqube-scan-action@v8.1.0
@@ -54,5 +61,6 @@ jobs:
             -Dsonar.projectKey=mARTin-B78_My-Weekly-ToDo-List_e038f066-0063-4a1e-9c33-03fdd5ab3c3a
             -Dsonar.sources=src,scripts
             -Dsonar.exclusions=**/node_modules/**,**/.next/**,**/*.spec.ts
+            -Dsonar.javascript.node.maxspace=4096
             -Dsonar.qualitygate.wait=true
             -Dsonar.qualitygate.timeout=300
diff --git a/CHANGELOG.md b/CHANGELOG.md
index f247f63..6ddd5f1 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -2,6 +2,18 @@
 
 All notable changes to this project are documented in this file.
 
+## [1.125.3] - 2026-09-12
+
+### Fixed
+- `SONAR_TOKEN`/`SONAR_HOST_URL` sind jetzt als GitHub-Secret/-Variable gesetzt (frisches
+  Token vom Besitzer erhalten, gleichzeitig `~/.sonar-token` auf dem Spark wiederhergestellt
+  — der nächtliche lokale Scan lief seit mindestens 09.09. fehl). Der Sonar-Schritt im
+  Workflow authentifiziert jetzt erfolgreich, scheiterte im ersten echten Testlauf aber an
+  einem neuen, unabhängigen Problem: der Standard-Node-Heap der JS/TS-Analyse-Bridge
+  (~2,2 GB) reicht auf dem GitHub-Hosted-Runner für dieses Repo nicht — dieselbe
+  Fehlerklasse wie der `next build`-OOM-Absturz von v1.119.3/v1.119.4. Behoben mit
+  `-Dsonar.javascript.node.maxspace=4096`.
+
 ## [1.125.2] - 2026-09-12
 
 ### Fixed
diff --git a/package.json b/package.json
index 13f5185..600acfa 100644
--- a/package.json
+++ b/package.json
@@ -1,6 +1,6 @@
 {
   "name": "my-weekly-todo-list",
-  "version": "1.125.2",
+  "version": "1.125.3",
   "description": "A web-based weekly task management application that organizes to-dos and calendar events in a single, intuitive weekly view",
   "main": "index.js",
   "scripts": {