diff --git a/errors/runner-environment/windows-2025-azurerm-azure-powershell-modules-removed.yml b/errors/runner-environment/windows-2025-azurerm-azure-powershell-modules-removed.yml
new file mode 100644
index 0000000..da2e613
--- /dev/null
+++ b/errors/runner-environment/windows-2025-azurerm-azure-powershell-modules-removed.yml
@@ -0,0 +1,96 @@
+id: re-499
+title: "Windows Server 2025: AzureRM and Azure PowerShell modules removed from default install"
+category: runner-environment
+severity: error
+tags:
+  - windows-2025
+  - windows-latest
+  - powershell
+  - azurerm
+  - azure-module
+  - runner-image-update
+patterns:
+  - regex: 'Import-Module\s*:\s*The specified module\s+[''"]?Azure(?:RM)?[''"]?\s+was not loaded because no valid module file was found'
+    flags: i
+  - regex: 'PackageManagement\s*:\s*No match was found for the specified search criteria and module name\s+[''"]?Azure(?:RM)?[''"]?'
+    flags: i
+  - regex: 'The term\s+[''"]?(?:Get|Set|New|Remove|Connect)-Azure(?:RM)?[A-Za-z]+[''"]?\s+is not recognized'
+    flags: i
+error_messages:
+  - "Import-Module : The specified module 'AzureRM' was not loaded because no valid module file was found in any module directory."
+  - "Import-Module : The specified module 'Azure' was not loaded because no valid module file was found in any module directory."
+  - "PackageManagement : No match was found for the specified search criteria and module name 'AzureRM'."
+  - "The term 'Login-AzureRmAccount' is not recognized as the name of a cmdlet, function, script file, or operable program."
+  - "The term 'Connect-AzureRmAccount' is not recognized as the name of a cmdlet, function, script file, or operable program."
+root_cause: |
+  When `windows-latest` migrated from Windows Server 2022 to Windows Server 2025 (rolled out September 2025),
+  GitHub removed the legacy `AzureRM` and `Azure` PowerShell modules from the pre-installed software list on the
+  Windows Server 2025 runner image. These modules were deprecated by Microsoft in favour of the `Az` PowerShell
+  module (introduced in December 2018) and their inclusion was dropped from windows-2025 images as part of the
+  disk-space reduction effort documented in actions/runner-images#12677.
+
+  Workflows that call legacy cmdlets such as `Login-AzureRmAccount`, `Get-AzureRmResource`, `New-AzureRmResourceGroup`,
+  or that run `Import-Module AzureRM` / `Import-Module Azure` without first installing the modules at runtime will fail
+  immediately with a "module not found" error on `windows-latest` (windows-2025) runners.
+
+  The `Az` module (modern replacement) is pre-installed and fully functional on both windows-2022 and windows-2025
+  images. `Az` cmdlets follow the naming convention `*-Az*` (e.g. `Connect-AzAccount`, `Get-AzResource`).
+fix: |
+  Migrate from the legacy `AzureRM`/`Azure` modules to the modern `Az` PowerShell module. The `Az` module ships
+  pre-installed on all supported runner images and is fully supported.
+
+  If you cannot migrate immediately, install `AzureRM` at runtime as a workaround (not recommended for new workflows):
+
+  ```powershell
+  Install-Module -Name AzureRM -Repository PSGallery -Force -AllowClobber
+  ```
+
+  The recommended long-term fix is to update all cmdlets:
+  - `Login-AzureRmAccount`      → `Connect-AzAccount`
+  - `Get-AzureRmResource`       → `Get-AzResource`
+  - `New-AzureRmResourceGroup`  → `New-AzResourceGroup`
+  - `Get-AzureRmSubscription`   → `Get-AzSubscription`
+  (Full migration guide: https://docs.microsoft.com/en-us/powershell/azure/migrate-from-azurerm-to-az)
+fix_code:
+  - language: yaml
+    label: "Migrate to Az module (windows-2025 compatible)"
+    code: |
+      jobs:
+        deploy:
+          runs-on: windows-latest   # Now windows-2025; Az is pre-installed
+          steps:
+            - name: Login to Azure
+              uses: azure/login@v2
+              with:
+                creds: ${{ secrets.AZURE_CREDENTIALS }}
+
+            - name: Get resource group
+              shell: pwsh
+              run: |
+                # Az module (pre-installed on windows-2025)
+                Get-AzResourceGroup -Name "my-rg"
+                # NOT: Get-AzureRmResourceGroup (removed on windows-2025)
+  - language: yaml
+    label: "Runtime install workaround (migration not yet complete)"
+    code: |
+      jobs:
+        deploy:
+          runs-on: windows-latest
+          steps:
+            - name: Install AzureRM module at runtime
+              shell: pwsh
+              run: |
+                Install-Module -Name AzureRM -Repository PSGallery -Force -AllowClobber -Scope CurrentUser
+                Import-Module AzureRM
+prevention:
+  - "Use the modern `Az` PowerShell module (`*-Az*` cmdlets) instead of the deprecated `AzureRM`/`Azure` modules."
+  - "Pin `runs-on: windows-2022` temporarily if migration to Az is not yet possible, then schedule migration."
+  - "Prefer the `azure/login@v2` GitHub Action with `Az` for Azure authentication in CI — avoids module management entirely."
+  - "Run `Get-Module -ListAvailable Az*` in your workflow to verify Az module availability and version on the runner."
+docs:
+  - url: "https://github.com/actions/runner-images/issues/12677"
+    label: "actions/runner-images#12677 — Windows Server 2025 becomes windows-latest (breaking changes table)"
+  - url: "https://docs.microsoft.com/en-us/powershell/azure/migrate-from-azurerm-to-az"
+    label: "Microsoft: Migrate Azure PowerShell from AzureRM to Az"
+  - url: "https://docs.microsoft.com/en-us/powershell/azure/install-az-ps"
+    label: "Microsoft: Install the Azure Az PowerShell module"
diff --git a/errors/runner-environment/windows-2025-nsis-removed-makensis-not-found.yml b/errors/runner-environment/windows-2025-nsis-removed-makensis-not-found.yml
new file mode 100644
index 0000000..99b1fa4
--- /dev/null
+++ b/errors/runner-environment/windows-2025-nsis-removed-makensis-not-found.yml
@@ -0,0 +1,90 @@
+id: re-500
+title: "Windows Server 2025: NSIS removed — makensis command not found"
+category: runner-environment
+severity: error
+tags:
+  - windows-2025
+  - windows-latest
+  - nsis
+  - installer
+  - runner-image-update
+  - makensis
+patterns:
+  - regex: '''makensis''\s+is not recognized as an internal or external command'
+    flags: i
+  - regex: 'makensis\s*:\s*The term\s+.+\s+is not recognized as the name of a cmdlet'
+    flags: i
+  - regex: "makensis['\"]?\\s*:?\\s*command not found"
+    flags: i
+  - regex: 'Error\s*:\s*Could not find NSIS'
+    flags: i
+error_messages:
+  - "'makensis' is not recognized as an internal or external command, operable program or batch file."
+  - "makensis : The term 'makensis' is not recognized as the name of a cmdlet, function, script file, or operable program."
+  - "Error: Could not find NSIS. Please install NSIS and make sure makensis is in your PATH."
+root_cause: |
+  NSIS (Nullsoft Scriptable Install System) was removed from the Windows Server 2025 runner image when
+  `windows-latest` migrated from Windows Server 2022 to Windows Server 2025 in September 2025
+  (actions/runner-images#12677). NSIS was pre-installed on windows-2019 and windows-2022 images but was
+  excluded from windows-2025 due to low usage and disk-space constraints.
+
+  Workflows that build Windows installers using NSIS scripts (`.nsi` files) via `makensis` will fail immediately
+  with a "command not found" error on `windows-latest` (windows-2025) runners. This affects any workflow that:
+  - Calls `makensis` directly in a `run:` step
+  - Uses build tools that invoke `makensis` internally (e.g. electron-builder, cmake-nsis, create-react-app
+    Windows installer scripts)
+  - References `$env:NSIS_DIR` or hardcodes `C:\Program Files (x86)\NSIS\makensis.exe`
+fix: |
+  Install NSIS at runtime using Chocolatey (pre-installed on all Windows runner images):
+
+  ```yaml
+  - name: Install NSIS
+    run: choco install nsis --yes
+    shell: pwsh
+  ```
+
+  Alternatively, pin your workflow to `windows-2022` if NSIS is a critical dependency and runtime
+  installation adds too much overhead, then plan a migration to WiX Toolset or MSIX packaging.
+fix_code:
+  - language: yaml
+    label: "Install NSIS at runtime via Chocolatey"
+    code: |
+      jobs:
+        build-installer:
+          runs-on: windows-latest   # windows-2025: NSIS not pre-installed
+          steps:
+            - uses: actions/checkout@v4
+
+            - name: Install NSIS
+              shell: pwsh
+              run: choco install nsis --yes --no-progress
+
+            - name: Build installer
+              shell: pwsh
+              run: |
+                $makensis = "C:\Program Files (x86)\NSIS\makensis.exe"
+                & $makensis /V4 installer.nsi
+  - language: yaml
+    label: "Pin to windows-2022 (NSIS pre-installed) as temporary workaround"
+    code: |
+      jobs:
+        build-installer:
+          runs-on: windows-2022   # NSIS pre-installed; migrate to windows-2025 + choco install
+          steps:
+            - uses: actions/checkout@v4
+            - name: Build installer
+              run: makensis /V4 installer.nsi
+prevention:
+  - "Install NSIS explicitly via `choco install nsis` rather than relying on runner image pre-installation."
+  - "Use `actions/cache` to cache the Chocolatey package downloads and avoid repeated install overhead."
+  - "Consider migrating to WiX Toolset (wix.io) or MSIX packaging for modern Windows installer builds — both are pre-installed on windows-2025."
+  - "Pin `runs-on: windows-2022` in the short term if runtime installation is not feasible, with a TODO to migrate."
+docs:
+  - url: "https://github.com/actions/runner-images/issues/12677"
+    label: "actions/runner-images#12677 — Windows Server 2025 becomes windows-latest (NSIS removed)"
+  - url: "https://github.com/actions/runner-images/issues/11754"
+    label: "actions/runner-images#11754 — Request to add NSIS to windows-2025 image"
+  - url: "https://nsis.sourceforge.io/Main_Page"
+    label: "NSIS — Nullsoft Scriptable Install System"
+  - url: "https://community.chocolatey.org/packages/nsis"
+    label: "Chocolatey: NSIS package"
diff --git a/errors/silent-failures/sf-233.yml b/errors/silent-failures/sf-233.yml
new file mode 100644
index 0000000..f6b3c1a
--- /dev/null
+++ b/errors/silent-failures/sf-233.yml
@@ -0,0 +1,115 @@
+id: sf-233
+title: "Windows Server 2025: default Java silently changed from 8 to 17, breaking Maven/Gradle builds"
+category: silent-failures
+severity: silent-failure
+tags:
+  - windows-2025
+  - windows-latest
+  - java
+  - maven
+  - gradle
+  - java-version
+  - runner-image-update
+patterns:
+  - regex: 'Source option \d+ is no longer supported\. Use \d+ or later'
+    flags: i
+  - regex: 'error:\s+source release \d+ requires target release \d+'
+    flags: i
+  - regex: 'InaccessibleObjectException.*Unable to make.*accessible.*module java\.base'
+    flags: i
+  - regex: 'Unsupported class file major version \d+'
+    flags: i
+  - regex: 'JAVA_HOME\s*=\s*C:\\Program Files\\(?:Eclipse Adoptium|Microsoft)\\jdk-17'
+    flags: i
+error_messages:
+  - "error: Source option 8 is no longer supported. Use 11 or later."
+  - "error: source release 8 requires target release 8"
+  - "java.lang.reflect.InaccessibleObjectException: Unable to make field ... accessible: module java.base does not 'opens java.lang' to unnamed module"
+  - "Unsupported class file major version 61"
+  - "[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!"
+root_cause: |
+  When `windows-latest` migrated from Windows Server 2022 to Windows Server 2025 (September 2025,
+  actions/runner-images#12677), the default pre-installed Java version changed from **Java 8 (JDK 8)**
+  to **Java 17 (JDK 17)**. On windows-2022, `java -version` returned a 1.8.x JDK. On windows-2025,
+  `java -version` returns a 17.x JDK.
+
+  This is a silent failure because:
+  1. Workflows that do NOT use `actions/setup-java` and rely on the system Java receive a different runtime
+     version without any explicit error or warning in the workflow log about the version change.
+  2. Maven or Gradle builds configured with `<source>1.8</source>/<target>1.8</target>` in pom.xml may
+     continue to compile (Java 17 supports `--release 8`) but hit runtime failures when code uses
+     reflection patterns that Java 17's strong encapsulation (JEP 396, JEP 403) now restricts.
+  3. Projects using Lombok, certain Spring Boot versions, JPA/Hibernate older versions, or AspectJ may
+     fail or produce different behavior under Java 17 strong encapsulation.
+  4. Hardcoded `JAVA_HOME` paths pointing to a JDK 8 install directory will break silently when the
+     path no longer exists on windows-2025.
+
+  This does NOT affect workflows that explicitly use `actions/setup-java` with a `java-version:` input,
+  as that action installs and pins the requested version regardless of runner image defaults.
+fix: |
+  Always use `actions/setup-java` with an explicit `java-version:` to avoid dependence on the runner image
+  default Java version. This is the recommended practice regardless of runner OS or image version.
+
+  If you need to stay on Java 8:
+  ```yaml
+  - uses: actions/setup-java@v4
+    with:
+      distribution: temurin
+      java-version: '8'
+  ```
+
+  If migrating to Java 17 (recommended), audit your build for:
+  - Reflective access warnings/errors (add `--add-opens` JVM flags if needed)
+  - Outdated Lombok version (upgrade to 1.18.22+)
+  - Spring Boot 2.x reflection issues (upgrade to 2.6+ or 3.x for Java 17 support)
+fix_code:
+  - language: yaml
+    label: "Pin Java version explicitly with actions/setup-java (prevents silent version drift)"
+    code: |
+      jobs:
+        build:
+          runs-on: windows-latest   # windows-2025: default Java is now 17, not 8
+          steps:
+            - uses: actions/checkout@v4
+
+            - name: Set up Java 17
+              uses: actions/setup-java@v4
+              with:
+                distribution: temurin
+                java-version: '17'
+                cache: maven  # or 'gradle'
+
+            - name: Build with Maven
+              run: mvn -B package --file pom.xml
+  - language: yaml
+    label: "Pin to Java 8 explicitly if legacy compatibility required"
+    code: |
+      jobs:
+        build:
+          runs-on: windows-latest
+          steps:
+            - uses: actions/checkout@v4
+
+            - name: Set up Java 8
+              uses: actions/setup-java@v4
+              with:
+                distribution: temurin
+                java-version: '8'
+                cache: gradle
+
+            - name: Build with Gradle
+              run: ./gradlew build
+prevention:
+  - "Always specify `java-version:` in `actions/setup-java` — never rely on the runner's system Java."
+  - "Add `actions/setup-java` as a required step in all Java workflow templates to prevent version drift."
+  - "Set `fail-fast: true` in your matrix to surface Java version incompatibilities immediately."
+  - "Use `.mvn/jvm.config` or `gradle.properties` to enforce the expected Java version at the build tool level."
+docs:
+  - url: "https://github.com/actions/runner-images/issues/12677"
+    label: "actions/runner-images#12677 — Windows Server 2025 becomes windows-latest (Java default 8→17)"
+  - url: "https://github.com/actions/setup-java"
+    label: "actions/setup-java — Install and configure a specific Java version"
+  - url: "https://openjdk.org/jeps/403"
+    label: "JEP 403: Strongly Encapsulate JDK Internals (Java 17)"
+  - url: "https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners#supported-software"
+    label: "GitHub Docs: Supported software on GitHub-hosted runners"