@htekdev/actions-debugger 1.0.134 → 1.0.136

package/errors/caching-artifacts/caching-artifacts-080.yml

@@ -0,0 +1,116 @@
+id: caching-artifacts-080
+title: 'Windows runner silently exits during `actions/cache` restore — job proceeds without cached content'
+category: caching-artifacts
+severity: silent-failure
+tags:
+  - actions-cache
+  - windows
+  - silent-failure
+  - cache-restore
+  - node-crash
+  - post-job
+patterns:
+  - regex: 'Cache hit for:.*\nPost job cleanup\.'
+    flags: 'im'
+  - regex: 'Cache hit for:.*\nPost job cleanup\.\s*\nPost job cleanup\.\s*\nCache up-to-date\.'
+    flags: 'ims'
+  - regex: 'punycode.*DeprecationWarning.*\nPost job cleanup\.'
+    flags: 'im'
+error_messages:
+  - "Cache hit for: <key>"
+  - "Post job cleanup."
+  - "Cache up-to-date."
+  - "(node:1288) [DEP0040] DeprecationWarning: The `punycode` module is deprecated."
+root_cause: |
+  On Windows runners (`windows-latest`, `windows-2022`, `windows-2025`), `actions/cache` can
+  silently exit immediately after reporting a cache hit, without actually extracting the cached
+  content into the workspace.
+
+  The observable log pattern:
+  1. `Cache hit for: <key>` — cache entry is found on the server
+  2. Immediately followed by `Post job cleanup.` (out of order — should appear at end of all steps)
+  3. `Cache up-to-date.` — the save post-step fires but there is nothing to save
+  4. A Node.js `[DEP0040] DeprecationWarning: The punycode module is deprecated` message appears
+
+  The result: the job continues with an EMPTY workspace as if the cache was never restored.
+  No error is thrown, the step exit code is 0, and subsequent build steps fail with "file not
+  found" errors that appear unrelated to caching.
+
+  Root cause: The `actions/cache` Node.js process running in the runner encounters an unhandled
+  internal rejection during archive extraction on Windows and exits silently. The `punycode`
+  deprecation warning appearing alongside the premature `Post job cleanup` is a telltale signature
+  of this failure mode — it indicates the Node.js process used for the cache action is crashing
+  before extraction completes. This pattern is observed sporadically on all Windows runner images
+  and correlates with periods of elevated artifact service latency or specific image versions.
+
+  Reported by multiple projects (Rust/Cargo workflows, f3d, RustPython, linktime) as a roughly
+  5% failure rate increase on Windows beginning May 2026.
+fix: |
+  1. **Add `continue-on-error: true` as an immediate workaround** — this prevents the workflow
+     from failing hard on the cache step. Your build will be slower (no cache hit) but will not
+     fail.
+
+  2. **Re-run the failed job** — the failure is transient and intermittent. Most re-runs succeed.
+
+  3. **Upgrade `actions/cache` to the latest version** — the `actions/cache@v5` release line
+     includes improved error handling for Windows. Pin to `v5.4.0` or later.
+
+  4. **Use `save-always: false` and add a diagnostic step** — log the cache extraction result
+     explicitly to detect silent failures:
+     ```yaml
+     - run: |
+         if (-not (Test-Path "expected-file-from-cache")) {
+           Write-Host "##[warning]Cache may not have been restored (file missing)"
+         }
+       shell: pwsh
+     ```
+
+  5. **Split cache and build into separate jobs** — this forces a fresh runner for the build
+     job and avoids the Windows Node.js process issue affecting the current runner slot.
+fix_code:
+  - language: yaml
+    label: 'Immediate workaround — add continue-on-error to cache step'
+    code: |
+      - name: Restore Cargo cache
+        id: cache-cargo
+        uses: actions/cache@v5
+        continue-on-error: true    # ← prevents silent exit from blocking the job
+        with:
+          path: |
+            ~/.cargo/registry/index/
+            ~/.cargo/registry/cache/
+            ~/.cargo/git/db/
+          key: ${{ runner.os }}-cargo-${{ hashFiles('**/Cargo.lock') }}
+          restore-keys: |
+            ${{ runner.os }}-cargo-
+
+      - name: Verify cache restoration
+        shell: pwsh
+        run: |
+          if (Test-Path "$env:USERPROFILE\.cargo\registry\index") {
+            Write-Host "Cache restored successfully"
+          } else {
+            Write-Host "##[warning]Cache not restored — building from scratch"
+          }
+
+  - language: yaml
+    label: 'Use actions/cache@v5 with latest patch version'
+    code: |
+      - uses: actions/cache@v5          # v5.4.0+ has improved Windows extraction error handling
+        with:
+          path: ~/.cargo/registry
+          key: ${{ runner.os }}-cargo-${{ hashFiles('**/Cargo.lock') }}
+          restore-keys: ${{ runner.os }}-cargo-
+prevention:
+  - 'Always pin `actions/cache` to a recent v5.x release — older versions have known Windows Node.js crash issues'
+  - 'Add `continue-on-error: true` to cache restore steps to prevent silent failures from blocking CI'
+  - 'Add a post-cache verification step on Windows to confirm expected files exist before running the build'
+  - 'Monitor Windows job failure rates — a sudden 3-5% increase often signals a cache extraction regression'
+  - 'Use `ACTIONS_RUNNER_DEBUG=true` in repository secrets to surface the Node.js exit code diagnostic line'
+docs:
+  - url: 'https://github.com/actions/cache/issues/1754'
+    label: 'actions/cache#1754 — Windows runner randomly dies in actions/cache (May 2026)'
+  - url: 'https://github.com/actions/cache'
+    label: 'actions/cache — GitHub Actions caching documentation'
+  - url: 'https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows'
+    label: 'GitHub Docs — Caching dependencies to speed up workflows'

package/errors/runner-environment/runner-environment-249.yml

@@ -0,0 +1,144 @@
+id: runner-environment-249
+title: '`actions/github-script@v9` breaking changes — `const getOctokit` SyntaxError + `require(''@actions/github'')` ERR_REQUIRE_ESM'
+category: runner-environment
+severity: error
+tags:
+  - github-script
+  - v9
+  - breaking-change
+  - getOctokit
+  - esm
+  - require
+  - SyntaxError
+  - octokit
+patterns:
+  - regex: 'SyntaxError.*Identifier.*getOctokit.*already been declared'
+    flags: 'i'
+  - regex: "require.*@actions/github.*ERR_REQUIRE_ESM|ERR_REQUIRE_ESM.*@actions/github"
+    flags: 'i'
+  - regex: 'github-script.*v9.*const getOctokit|const getOctokit.*github-script.*v9'
+    flags: 'i'
+  - regex: "require.*@actions/github.*ES Module.*not supported"
+    flags: 'i'
+error_messages:
+  - "SyntaxError: Identifier 'getOctokit' has already been declared"
+  - "Error [ERR_REQUIRE_ESM]: require() of ES Module /node_modules/@actions/github/lib/github.js is not supported."
+  - "Instead change the require of index.js to a dynamic import() which is available in all CommonJS modules."
+root_cause: |
+  `actions/github-script@v9.0.0` (released April 9, 2026) introduced two breaking changes
+  compared to v8 and earlier:
+
+  BREAKING CHANGE 1: `getOctokit` is now an injected function parameter
+  In v9, the `getOctokit` factory function is injected directly into the script's
+  execution context as a named function parameter (alongside `github`, `context`, `core`,
+  etc.). This means `getOctokit` is now a declared parameter name in the script scope.
+
+  If a script re-declares `getOctokit` using `const` or `let`, JavaScript throws a
+  SyntaxError at parse time because re-declaring a `const`/`let` binding that already
+  exists in scope is illegal:
+
+    const getOctokit = require('@octokit/rest').Octokit  // ❌ SyntaxError in v9
+    let getOctokit = ...                                  // ❌ SyntaxError in v9
+
+  Using `var` avoids this issue because `var` allows redeclaration in the same scope
+  (though the injected value will be shadowed).
+
+  BREAKING CHANGE 2: `require('@actions/github')` no longer works
+  `@actions/github` v9 is an ESM-only package. The `github-script` execution context
+  is CommonJS (CJS). Calling `require('@actions/github')` from within a script will
+  fail at runtime:
+
+    const { getOctokit } = require('@actions/github')   // ❌ ERR_REQUIRE_ESM in v9
+
+  This pattern was previously used in v7/v8 scripts to create secondary Octokit
+  clients with custom tokens. In v9, this is replaced by the injected `getOctokit`
+  function parameter, which eliminates the need to require `@actions/github` at all.
+
+  Impact: Scripts that used `require('@actions/github')` to create custom clients
+  (e.g., for cross-organization access or GitHub App tokens) will fail when the
+  action is upgraded or when `@latest` resolves to v9.
+fix: |
+  FIX FOR BREAKING CHANGE 1 (SyntaxError: 'getOctokit' already declared):
+  Remove or rename the local `getOctokit` variable declaration. The injected
+  `getOctokit` is available directly in the script scope without any import.
+  If you need to keep the variable name, use `var` instead of `const`/`let` — or
+  simply rename the local variable to something else.
+
+  FIX FOR BREAKING CHANGE 2 (ERR_REQUIRE_ESM from require('@actions/github')):
+  Replace the `require('@actions/github')` pattern with the injected `getOctokit`
+  function. In v9, `getOctokit(token)` is available directly in the script context
+  and accepts a PAT or GitHub App token to create a secondary authenticated client.
+
+  General recommendation: pin to `actions/github-script@v9` explicitly and
+  migrate your scripts using the patterns below.
+fix_code:
+  - language: yaml
+    label: 'Fix SyntaxError — use injected getOctokit directly, remove const/let redeclaration'
+    code: |
+      - uses: actions/github-script@v9
+        with:
+          script: |
+            # ❌ v8 and earlier — required declaration to get getOctokit:
+            # const { getOctokit } = require('@actions/github')
+            # const myOctokit = getOctokit(process.env.MY_TOKEN)
+
+            # ❌ v9 SyntaxError — can't redeclare the injected getOctokit parameter:
+            # const getOctokit = require('@actions/github').getOctokit   // SyntaxError!
+
+            # ✅ v9 — getOctokit is injected directly; use it without any import:
+            const myOctokit = getOctokit(process.env.MY_TOKEN)
+            const result = await myOctokit.rest.repos.get({
+              owner: 'my-org',
+              repo: 'my-private-repo',
+            })
+            core.info(`Repo: ${result.data.full_name}`)
+        env:
+          MY_TOKEN: ${{ secrets.MY_CROSS_REPO_TOKEN }}
+
+  - language: yaml
+    label: 'Fix ERR_REQUIRE_ESM — replace require(''@actions/github'') with injected getOctokit'
+    code: |
+      - uses: actions/github-script@v9
+        with:
+          script: |
+            # ❌ v8 pattern — fails with ERR_REQUIRE_ESM in v9:
+            # const { getOctokit } = require('@actions/github')
+            # const crossOrgClient = getOctokit(process.env.CROSS_ORG_TOKEN)
+
+            # ✅ v9 pattern — use injected getOctokit directly:
+            const crossOrgClient = getOctokit(process.env.CROSS_ORG_TOKEN)
+            await crossOrgClient.rest.issues.create({
+              owner: 'other-org',
+              repo: 'other-repo',
+              title: 'Cross-org issue from Actions',
+              body: 'Created via github-script v9 getOctokit factory'
+            })
+        env:
+          CROSS_ORG_TOKEN: ${{ secrets.CROSS_ORG_PAT }}
+
+  - language: yaml
+    label: 'Use dynamic import() as alternative for @actions/github internals'
+    code: |
+      - uses: actions/github-script@v9
+        with:
+          script: |
+            # If you need @actions/github internals beyond getOctokit/github,
+            # use dynamic import() — ESM packages can be imported this way in github-script:
+            const actionsGithub = await import('@actions/github')
+            const customClient = actionsGithub.getOctokit(process.env.MY_TOKEN)
+            core.info('Loaded via dynamic import')
+        env:
+          MY_TOKEN: ${{ secrets.MY_TOKEN }}
+prevention:
+  - "Pin `uses: actions/github-script@v9` (not `@latest`) to control when you upgrade and avoid surprise breaking changes"
+  - "Remove all `require('@actions/github')` calls from github-script scripts — use the injected `getOctokit` function parameter instead"
+  - "Never re-declare `getOctokit`, `github`, `context`, `core`, `exec`, `glob`, `io`, `fetch`, or `require` with `const`/`let` — these are all injected parameters in v9"
+  - "When creating secondary Octokit clients, use `getOctokit(token)` directly without any imports — this pattern works in all versions of github-script that inject the factory"
+  - "Review the v9.0.0 release notes when upgrading from v8: https://github.com/actions/github-script/releases/tag/v9.0.0"
+docs:
+  - url: 'https://github.com/actions/github-script/releases/tag/v9.0.0'
+    label: 'actions/github-script v9.0.0 release notes — breaking changes (April 9, 2026)'
+  - url: 'https://github.com/actions/github-script#creating-additional-clients-with-getoctokit'
+    label: 'actions/github-script README — Creating additional clients with getOctokit (v9 pattern)'
+  - url: 'https://github.com/actions/github-script/pull/700'
+    label: 'actions/github-script PR#700 — add getOctokit to script context, upgrade @actions/github v9'

package/errors/runner-environment/runner-environment-250.yml

@@ -0,0 +1,125 @@
+id: runner-environment-250
+title: '`dotnet-version: 10.0.x` resolves to non-existent patch version — aka.ms redirect misconfigured during .NET release cycle'
+category: runner-environment
+severity: error
+tags:
+  - setup-dotnet
+  - dotnet
+  - version-not-found
+  - aka-ms-redirect
+  - install-scripts
+  - wildcard-version
+  - net10
+patterns:
+  - regex: 'Could not find \.NET Core (SDK|Runtime) with version = \d+\.\d+\.\d+'
+    flags: 'i'
+  - regex: 'dotnet-install: The resource at aka\.ms link.*is not available'
+    flags: 'i'
+  - regex: 'Failed to install dotnet.*exit code: 1.*Could not find.*version = \d+\.\d+\.\d+'
+    flags: 'ims'
+  - regex: 'Attempting to download using aka\.ms link.*dotnet-(sdk|runtime)-\d+\.\d+\.\d+-.*\.tar\.gz.*404'
+    flags: 'ims'
+error_messages:
+  - "dotnet_install: Error: Could not find `.NET Core SDK` with version = 10.0.201"
+  - "dotnet_install: Error: Could not find `.NET Core Runtime` with version = 10.0.5"
+  - "dotnet-install: The resource at aka.ms link 'https://builds.dotnet.microsoft.com/dotnet/Sdk/10.0.201/dotnet-sdk-10.0.201-linux-x64.tar.gz' is not available."
+  - "Error: Failed to install dotnet, exit code: 1."
+  - "curl: (22) The requested URL returned error: 404 Not Found"
+root_cause: |
+  `actions/setup-dotnet` and the underlying `dotnet/install-scripts` use `aka.ms` redirect
+  URLs maintained by Microsoft to resolve the "latest" version for a given channel (e.g.,
+  `10.0.x`, `LTS`, `STS`). These redirects point to a specific patch version build URL.
+
+  When Microsoft publishes a new .NET patch version, the `aka.ms` redirects are briefly updated
+  to point to the new version's build artifacts. If the redirect is updated BEFORE the actual
+  build artifacts are published to `builds.dotnet.microsoft.com`, every workflow using a wildcard
+  version spec (e.g., `dotnet-version: 10.0.x` or `dotnet-version: LTS`) will attempt to
+  download a version that doesn't exist yet, receiving a 404.
+
+  This race condition between the redirect update and the artifact publication means that all
+  GitHub Actions workflows using `actions/setup-dotnet` with wildcard versions simultaneously
+  fail for a period of 15 minutes to several hours until the artifacts are published.
+
+  The pattern recurred:
+  - **March 10, 2026**: `LTS` redirect pointed to `10.0.5` / SDK `10.0.201` before they existed
+  - **May 16, 2026**: Same issue returned, confirmed by multiple users
+
+  The `dotnet-install.sh` script constructs the download URL directly from the version number
+  returned by the `aka.ms` redirect, so there is no fallback to the previous known-good version.
+
+  Note: This is distinct from the `.NET 6/7 EOL` version-not-found issue (`runner-environment-166`),
+  which is caused by Microsoft permanently removing old build artifacts. This issue is a transient
+  race condition during new-version rollout and typically self-resolves within hours.
+fix: |
+  **Immediate action**: Re-run failed workflow jobs — the issue is transient and self-resolves
+  once Microsoft finishes publishing the new .NET artifacts (usually within 1-4 hours).
+
+  **Pin to an exact version** to avoid hitting the redirect race condition:
+  Use `dotnet-version: '10.0.4'` (or whichever the last confirmed-working patch is) instead of
+  `dotnet-version: '10.0.x'`. Check https://dotnet.microsoft.com/en-us/download/dotnet/10.0 for
+  the latest stable version.
+
+  **Use the global.json approach** with a `rollForward` policy instead of the wildcard spec:
+  Create a `global.json` file with a safe `latestPatch` roll-forward policy that lets the
+  installed SDK satisfy your version requirement without fetching a specific patch.
+
+  **File an issue at dotnet/core** if the outage persists — the root cause is in the aka.ms
+  redirect management maintained by the .NET team at Microsoft.
+fix_code:
+  - language: yaml
+    label: 'Pin to an exact .NET 10 version instead of wildcard to avoid redirect race'
+    code: |
+      - uses: actions/setup-dotnet@v4
+        with:
+          # Exact version — immune to aka.ms redirect race conditions
+          dotnet-version: '10.0.4'
+          # Or use global.json for project-level version pinning:
+          # dotnet-version-file: 'global.json'
+
+  - language: yaml
+    label: 'Use global.json with latestPatch roll-forward for safer version resolution'
+    code: |
+      # global.json at repo root:
+      # {
+      #   "sdk": {
+      #     "version": "10.0.100",
+      #     "rollForward": "latestPatch"
+      #   }
+      # }
+
+      # In your workflow:
+      - uses: actions/setup-dotnet@v4
+        with:
+          dotnet-version-file: 'global.json'    # resolves from the file, not aka.ms
+
+  - language: yaml
+    label: 'Add retry logic with continue-on-error + fallback to cached SDK'
+    code: |
+      - name: Setup .NET (with retry)
+        id: setup-dotnet
+        uses: actions/setup-dotnet@v4
+        continue-on-error: true
+        with:
+          dotnet-version: '10.0.x'
+
+      - name: Fallback — install pinned .NET if wildcard failed
+        if: steps.setup-dotnet.outcome == 'failure'
+        uses: actions/setup-dotnet@v4
+        with:
+          dotnet-version: '10.0.4'    # last known-good version
+
+prevention:
+  - 'Prefer exact version pins (`10.0.4`) over wildcards (`10.0.x`) in production CI — reduces exposure to aka.ms redirect race conditions'
+  - 'Use `dotnet-version-file: global.json` with `rollForward: latestPatch` for project-level SDK pinning that avoids direct aka.ms resolution'
+  - 'Monitor https://github.com/dotnet/install-scripts and https://github.com/actions/setup-dotnet for known regressions before major .NET patch days'
+  - 'Subscribe to dotnet/core announcements to anticipate .NET patch releases — aka.ms redirects are updated around Patch Tuesday each month'
+  - 'Add `continue-on-error: true` + a fallback step to tolerate transient outages without blocking CI entirely'
+docs:
+  - url: 'https://github.com/actions/setup-dotnet/issues/711'
+    label: 'actions/setup-dotnet#711 — dotnet-version: 10.0.x tries to download non-existent version 10.0.5 (March 2026, 48 reactions)'
+  - url: 'https://github.com/dotnet/install-scripts'
+    label: 'dotnet/install-scripts — underlying install script that resolves aka.ms redirects'
+  - url: 'https://dotnet.microsoft.com/en-us/download/dotnet/10.0'
+    label: '.NET 10 download page — latest stable SDK/runtime versions'
+  - url: 'https://learn.microsoft.com/en-us/dotnet/core/tools/global-json'
+    label: 'global.json overview — SDK version selection with rollForward policies'

package/errors/runner-environment/runner-environment-251.yml

@@ -0,0 +1,141 @@
+id: runner-environment-251
+title: '.NET SDK 10.0.200+ requires MSBuild 18.0 but `windows-2022` only ships MSBuild 17 (VS 2022)'
+category: runner-environment
+severity: error
+tags:
+  - dotnet
+  - msbuild
+  - windows-2022
+  - net10
+  - visual-studio-2022
+  - version-incompatibility
+  - setup-dotnet
+patterns:
+  - regex: 'Version \d+\.0\.\d{3} of the \.NET SDK requires at least version 18\.0\.0 of MSBuild'
+    flags: 'i'
+  - regex: 'The current available version of MSBuild is 17\.\d+\.\d+'
+    flags: 'i'
+  - regex: 'Could not resolve SDK.*Microsoft\.NET\.Sdk.*version 18\.0\.0 of MSBuild'
+    flags: 'i'
+  - regex: 'MSBuild version.*requires.*18\.0.*current.*17\.'
+    flags: 'i'
+error_messages:
+  - "Version 10.0.200 of the .NET SDK requires at least version 18.0.0 of MSBuild. The current available version of MSBuild is 17.14.40.60911."
+  - "D:\\a\\...\\MyApp.csproj : error : Could not resolve SDK \"Microsoft.NET.Sdk\"."
+  - "Change the .NET SDK specified in global.json to an older version that requires the MSBuild version currently available."
+  - "error MSB4236: The SDK 'Microsoft.NET.Sdk.Web' specified could not be found."
+root_cause: |
+  Starting with .NET SDK **10.0.200** (released around March 2026), the .NET SDK toolchain
+  requires **MSBuild 18.0 or later** to build projects. This requirement was introduced because
+  .NET SDK 10.0.200 includes MSBuild features that depend on capabilities added in MSBuild 18.
+
+  The `windows-2022` GitHub Actions runner ships with **Visual Studio 2022**, which provides
+  MSBuild 17.x (currently 17.14.x). MSBuild 18.0 is only included in **Visual Studio 2026**
+  (VS 18.x), which ships with `windows-2025-vs2026` and `windows-latest` (as of June 2026).
+
+  Trigger scenario:
+  1. Workflow uses `runs-on: windows-2022` (deliberately pinned or using legacy config)
+  2. Workflow installs .NET 10 SDK via `actions/setup-dotnet` with `dotnet-version: '10.0.x'`
+     or `dotnet-version: '10.x'`
+  3. `dotnet build`, `dotnet restore`, or NuGet restore attempts to invoke MSBuild
+  4. MSBuild 17.14 is found on PATH from VS 2022 installation
+  5. .NET SDK rejects MSBuild 17.x and throws the version incompatibility error
+
+  Note: This does NOT affect `windows-latest` users as of June 8, 2026, because `windows-latest`
+  now resolves to VS 2026 (MSBuild 18.x). The issue is specific to workflows explicitly pinning
+  to `windows-2022` (which keeps VS 2022/MSBuild 17.x) while also installing .NET SDK 10.0.200+.
+
+  NuGet-based restores (e.g., via `NuGetCommand@2` or `nuget.exe`) are also affected because
+  NuGet's MSBuild auto-detection picks up the VS 2022 MSBuild binary and .NET SDK 10.0.200+
+  then rejects it during SDK resolution.
+fix: |
+  **Option 1 — Switch to windows-latest or windows-2025-vs2026** (recommended):
+  These runner labels ship with Visual Studio 2026 (MSBuild 18.x), which satisfies the
+  .NET SDK 10.0.200+ MSBuild requirement.
+
+  **Option 2 — Pin to an older .NET SDK that supports MSBuild 17.x**:
+  .NET SDK 10.0.100 (the initial .NET 10 release) works with MSBuild 17.x. Pin via `global.json`
+  or `dotnet-version: '10.0.100'` if you must stay on `windows-2022`.
+
+  **Option 3 — Install VS Build Tools 2026 in your workflow**:
+  Install the VS 2026 Build Tools workload as a workflow step to get MSBuild 18.x on
+  `windows-2022`. This is slow (~5-10 min) but avoids the runner label change.
+
+  **Option 4 — Use the .NET SDK's bundled MSBuild**:
+  When you call `dotnet build` (not `msbuild` directly), .NET SDK 10.0.200+ uses its own
+  bundled MSBuild. This bypasses the VS 2022 MSBuild detection. Use `dotnet build` instead
+  of `msbuild` to work around the issue on `windows-2022`.
+fix_code:
+  - language: yaml
+    label: 'Switch to windows-latest (VS 2026, MSBuild 18.x) — simplest fix'
+    code: |
+      jobs:
+        build:
+          runs-on: windows-latest     # now VS 2026 + MSBuild 18.x as of June 2026
+          # was: runs-on: windows-2022  ← VS 2022, MSBuild 17.x — incompatible with .NET 10.0.200+
+          steps:
+            - uses: actions/checkout@v4
+            - uses: actions/setup-dotnet@v4
+              with:
+                dotnet-version: '10.0.x'
+            - run: dotnet build
+
+  - language: yaml
+    label: 'Pin .NET SDK to 10.0.100 (MSBuild 17-compatible) if staying on windows-2022'
+    code: |
+      jobs:
+        build:
+          runs-on: windows-2022       # VS 2022 / MSBuild 17.x
+          steps:
+            - uses: actions/checkout@v4
+            - uses: actions/setup-dotnet@v4
+              with:
+                # Pin to 10.0.100 — the last .NET 10 SDK version that works with MSBuild 17.x
+                dotnet-version: '10.0.100'
+            - run: dotnet build       # uses dotnet's bundled MSBuild, not VS 2022 MSBuild
+
+  - language: yaml
+    label: 'Use dotnet build (bundled MSBuild) instead of msbuild.exe directly'
+    code: |
+      jobs:
+        build:
+          runs-on: windows-2022
+          steps:
+            - uses: actions/checkout@v4
+            - uses: actions/setup-dotnet@v4
+              with:
+                dotnet-version: '10.0.x'
+            # Use 'dotnet build' — uses the SDK's bundled MSBuild (18.x), not VS 2022's MSBuild
+            - run: dotnet build MyApp.sln /p:Configuration=Release
+            # Avoid: msbuild MyApp.sln — this finds VS 2022's MSBuild 17.x and fails
+
+  - language: yaml
+    label: 'Matrix build — test against both windows-2022 and windows-latest'
+    code: |
+      jobs:
+        build:
+          strategy:
+            matrix:
+              os: [windows-2022, windows-latest]
+          runs-on: ${{ matrix.os }}
+          steps:
+            - uses: actions/checkout@v4
+            - uses: actions/setup-dotnet@v4
+              with:
+                dotnet-version: '10.0.x'
+            - run: dotnet build
+prevention:
+  - 'Use `windows-latest` for .NET 10+ workflows — as of June 2026 it ships with VS 2026 (MSBuild 18.x)'
+  - 'Call `dotnet build` / `dotnet publish` instead of invoking `msbuild.exe` directly — the SDK bundled MSBuild always matches the SDK requirements'
+  - 'When pinning to `windows-2022`, also pin the .NET SDK to a version compatible with MSBuild 17.x (10.0.100 or earlier) if you need both'
+  - 'Check MSBuild version compatibility before upgrading .NET SDK patch versions: dotnet.microsoft.com/en-us/download/dotnet/10.0'
+  - 'Subscribe to actions/runner-images announcements to know when `windows-latest` changes its VS version so you can plan migrations'
+docs:
+  - url: 'https://github.com/actions/runner-images/issues/13789'
+    label: 'runner-images#13789 — NuGet restore fails with NET 10 starting after March 9, 2026 update'
+  - url: 'https://github.com/actions/runner-images/issues/14017'
+    label: 'runner-images#14017 — windows-latest and windows-2025 migrate to VS 2026 in June 2026'
+  - url: 'https://learn.microsoft.com/en-us/dotnet/core/tools/sdk-errors/netsdk1045'
+    label: 'NETSDK1045 — The current .NET SDK does not support targeting .NET X.0'
+  - url: 'https://dotnet.microsoft.com/en-us/download/dotnet/10.0'
+    label: '.NET 10 download — SDK/Runtime version history'

package/errors/yaml-syntax/yaml-syntax-078.yml

@@ -0,0 +1,125 @@
+id: yaml-syntax-078
+title: '`vars.*` context returns empty string for undefined configuration variables, causing "unexpected value ''" in reusable workflow with: inputs'
+category: yaml-syntax
+severity: error
+tags:
+  - vars-context
+  - reusable-workflow
+  - workflow-call
+  - configuration-variables
+  - empty-string
+  - unexpected-value
+patterns:
+  - regex: 'evaluate reusable workflow inputs.*unexpected value'
+    flags: 'i'
+  - regex: 'vars\.\w+.*unexpected value|unexpected value.*vars\.\w+'
+    flags: 'i'
+  - regex: 'unexpected value ''''.*reusable.*input|reusable.*input.*unexpected value '''''
+    flags: 'i'
+error_messages:
+  - "evaluate reusable workflow inputs: key 'my-input': unexpected value ''"
+  - "evaluate reusable workflow inputs: unexpected value '' for boolean input"
+  - "Error: evaluate reusable workflow inputs: ... unexpected value ''"
+root_cause: |
+  When a caller workflow passes a `vars.*` context expression to a reusable workflow's
+  `with:` input, and that configuration variable is not defined in the repository or
+  organization settings, `${{ vars.SOME_VAR }}` evaluates to an empty string `""`.
+
+  Reusable workflow inputs that are typed as `boolean` or `number` (or have strict
+  validation) reject the empty string `""` with the error:
+    evaluate reusable workflow inputs: ... unexpected value ''
+
+  For `type: boolean` inputs, the only valid values are `"true"` or `"false"`.
+  An empty string `""` is not a valid boolean and triggers this error.
+  For `type: number` inputs, `""` is not parseable as a number.
+
+  Even for `type: string` inputs with `required: true`, some versions of the runner
+  treat `""` as "not provided" and reject it with this error.
+
+  Root causes of the empty string:
+  1. The developer never created the configuration variable in the repository/organization
+     Settings → Variables UI. `vars.*` is the context for configuration variables (set
+     in the UI), NOT for environment variables set with `env:` in the workflow YAML.
+  2. The variable was created at the wrong scope — e.g., created as an environment-level
+     variable but the workflow doesn't reference a matching environment.
+  3. The variable name was mistyped — `vars.MY_VAR` but the setting is named `MY_VAr`
+     (case-sensitive match is required).
+
+  This is a common confusion: developers sometimes set `env:` workflow-level variables
+  expecting them to be accessible via `vars.*`, but `vars.*` only resolves variables
+  set in the GitHub repository/organization/environment Settings UI.
+fix: |
+  Option 1 — Create the configuration variable in GitHub Settings:
+  Go to your repository (or organization/environment) Settings → Secrets and variables
+  → Actions → Variables tab, and create the variable `SOME_VAR` with the desired value.
+  The `vars.SOME_VAR` expression will then resolve correctly.
+
+  Option 2 — Provide a fallback default using the `||` operator in the caller workflow:
+  Pass `${{ vars.SOME_VAR || 'default-value' }}` to avoid passing an empty string when
+  the variable is unset. The reusable workflow input then receives `'default-value'`
+  instead of `''`.
+
+  Option 3 — Use the `inputs.` default in the reusable workflow definition:
+  In the reusable workflow's `on.workflow_call.inputs`, set a `default:` value so the
+  input has a sensible fallback even when the caller passes an empty string.
+
+  For boolean inputs specifically — always coerce `vars.*` to boolean in the caller:
+  Use `${{ vars.ENABLE_FEATURE == 'true' }}` to convert the string variable value to
+  a proper boolean rather than passing the raw string.
+fix_code:
+  - language: yaml
+    label: 'Caller workflow — provide default fallback for undefined vars.*'
+    code: |
+      jobs:
+        call-reusable:
+          uses: org/repo/.github/workflows/reusable.yml@main
+          with:
+            # ❌ Fails with "unexpected value ''" if SOME_ARG_A is not set:
+            # some-arg-a: ${{ vars.SOME_ARG_A }}
+
+            # ✅ Provide a fallback when the variable is unset:
+            some-arg-a: ${{ vars.SOME_ARG_A || 'default-value' }}
+
+            # ✅ For boolean inputs — convert the string to actual boolean:
+            # enable-feature: ${{ vars.ENABLE_FEATURE == 'true' }}
+
+  - language: yaml
+    label: 'Reusable workflow — define a default for the input'
+    code: |
+      # In the reusable workflow definition:
+      on:
+        workflow_call:
+          inputs:
+            some-arg-a:
+              type: string
+              required: false   # Make it optional if a default makes sense
+              default: 'default-value'
+              description: 'Argument A (can be overridden by vars.SOME_ARG_A in caller)'
+
+      # ✅ Now even if caller passes '' or omits the input, the default is used
+
+  - language: yaml
+    label: 'Caller workflow — coerce vars.* string to boolean for boolean inputs'
+    code: |
+      jobs:
+        call-reusable:
+          uses: org/repo/.github/workflows/reusable.yml@main
+          with:
+            # ❌ Passing vars.ENABLE_FEATURE ('true'/'false' string or '') to bool input:
+            # enable-feature: ${{ vars.ENABLE_FEATURE }}
+
+            # ✅ Coerce the string value to an actual boolean:
+            enable-feature: ${{ vars.ENABLE_FEATURE == 'true' }}
+prevention:
+  - "Use `vars.*` only for configuration variables set in the GitHub repository/organization/environment Settings UI — not for `env:` YAML workflow variables"
+  - "Always provide a `||` fallback when passing `vars.*` to a reusable workflow input: `${{ vars.MY_VAR || 'default' }}`"
+  - "For boolean reusable workflow inputs, coerce `vars.*` strings with `${{ vars.FLAG == 'true' }}` instead of passing the raw string"
+  - "Verify the variable name and scope in Settings → Secrets and variables → Actions → Variables before using it in a workflow"
+  - "Set `required: false` with a `default:` in the reusable workflow definition to make inputs resilient to empty string values"
+docs:
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/variables#using-the-vars-context-to-access-configuration-variable-values'
+    label: 'GitHub Docs — vars context for configuration variables (distinct from env: YAML variables)'
+  - url: 'https://docs.github.com/en/actions/sharing-automations/reusing-workflows#using-inputs-and-secrets-in-a-reusable-workflow'
+    label: 'GitHub Docs — Using inputs in a reusable workflow (types, required, defaults)'
+  - url: 'https://stackoverflow.com/questions/79949037/consumers-callers-vars-value-passed-and-blank-strings-for-reusable-inputs'
+    label: "Stack Overflow — Consumer's/caller's vars value passed and blank strings for reusable inputs (May 2026)"

package/errors/yaml-syntax/yaml-syntax-079.yml

@@ -0,0 +1,148 @@
+id: yaml-syntax-079
+title: 'Invalid (non-IANA) timezone value in on.schedule.cron — actionlint "invalid timezone must be a valid IANA timezone name" + GitHub workflow validation failure'
+category: yaml-syntax
+severity: error
+tags:
+  - schedule
+  - cron
+  - timezone
+  - IANA
+  - actionlint
+  - validation
+  - common-mistake
+patterns:
+  - regex: 'invalid timezone.*must be a valid IANA timezone name'
+    flags: 'i'
+  - regex: 'invalid timezone.*schedule event'
+    flags: 'i'
+  - regex: 'schedule.*timezone.*not.*valid.*IANA|IANA.*timezone.*invalid.*schedule'
+    flags: 'i'
+error_messages:
+  - 'invalid timezone "PST" in schedule event. it must be a valid IANA timezone name [events]'
+  - 'invalid timezone "EST" in schedule event. it must be a valid IANA timezone name [events]'
+  - 'invalid timezone "Asia/Somewhere" in schedule event. it must be a valid IANA timezone name [events]'
+  - 'invalid timezone "UTC+5" in schedule event. it must be a valid IANA timezone name [events]'
+  - 'invalid timezone "India" in schedule event. it must be a valid IANA timezone name [events]'
+root_cause: |
+  GitHub Actions added IANA timezone support for scheduled workflows in March 2026. The
+  `timezone:` field under `on.schedule` accepts an IANA Time Zone Database name
+  (e.g., `America/New_York`, `Europe/London`, `Asia/Tokyo`). GitHub and actionlint both
+  validate that the provided string is a recognized IANA timezone name.
+
+  The most common mistakes are using timezone ABBREVIATIONS or OFFSET STRINGS instead
+  of proper IANA names:
+
+  | Invalid (rejected)     | Valid IANA replacement          |
+  |------------------------|---------------------------------|
+  | PST                    | America/Los_Angeles             |
+  | EST                    | America/New_York                |
+  | CST                    | America/Chicago                 |
+  | MST                    | America/Denver                  |
+  | BST                    | Europe/London                   |
+  | CET / CEST             | Europe/Berlin or Europe/Paris   |
+  | IST                    | Asia/Kolkata                    |
+  | JST                    | Asia/Tokyo                      |
+  | AEST                   | Australia/Sydney                |
+  | UTC+5 / GMT+5 / +05:30 | Asia/Karachi or Asia/Kolkata    |
+  | India                  | Asia/Kolkata                    |
+
+  IANA timezone abbreviations (PST, EST, etc.) are NOT part of the IANA Time Zone
+  Database specification — they are informal abbreviations used in human communication
+  that map ambiguously to multiple official zones. Similarly, UTC offset strings like
+  "UTC+5" or "GMT-8" are not valid IANA names.
+
+  The only valid form is the `Region/City` (or `Region/Sub-Region/City`) format used
+  in the IANA TZ database, or the special zones like `UTC`, `Etc/UTC`, `Etc/GMT+N`.
+
+  Note: actionlint validates IANA timezone strings as of v0.7.4 (March 30, 2026),
+  released to support the new `timezone:` field. The check was further fixed in commit
+  f48c0a4 to ensure completeness of the timezone validation.
+fix: |
+  Replace the timezone abbreviation or offset string with the correct IANA timezone name.
+  The IANA Time Zone Database uses `Region/City` format (e.g., `America/New_York`).
+
+  You can look up your timezone at:
+  - https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
+  - https://www.iana.org/time-zones
+  - https://nodatime.org/TimeZones (interactive timezone selector)
+
+  Common fixes:
+  - `timezone: PST` → `timezone: America/Los_Angeles`
+  - `timezone: EST` → `timezone: America/New_York`
+  - `timezone: IST` → `timezone: Asia/Kolkata`
+  - `timezone: UTC+5:30` → `timezone: Asia/Kolkata`
+fix_code:
+  - language: yaml
+    label: 'Use IANA timezone names — common US timezone fixes'
+    code: |
+      on:
+        schedule:
+          # ❌ PST is NOT a valid IANA name:
+          # - cron: '0 9 * * 1-5'
+          #   timezone: 'PST'
+
+          # ✅ Use the IANA Region/City format:
+          - cron: '0 9 * * 1-5'
+            timezone: 'America/Los_Angeles'  # Pacific (handles PST/PDT automatically)
+
+          # Other US regions:
+          # timezone: 'America/New_York'    # Eastern (EST/EDT)
+          # timezone: 'America/Chicago'     # Central (CST/CDT)
+          # timezone: 'America/Denver'      # Mountain (MST/MDT)
+          # timezone: 'Pacific/Honolulu'    # Hawaii (HST)
+
+  - language: yaml
+    label: 'Use IANA timezone names — India, Europe, Asia fixes'
+    code: |
+      on:
+        schedule:
+          # ❌ IST is NOT a valid IANA name:
+          # - cron: '30 9 * * *'
+          #   timezone: 'IST'
+
+          # ✅ India Standard Time:
+          - cron: '30 9 * * *'
+            timezone: 'Asia/Kolkata'
+
+          # Other common IANA names:
+          # timezone: 'Europe/London'       # UK (BST/GMT)
+          # timezone: 'Europe/Berlin'       # Germany (CET/CEST)
+          # timezone: 'Europe/Paris'        # France (CET/CEST)
+          # timezone: 'Asia/Tokyo'          # Japan (JST)
+          # timezone: 'Asia/Shanghai'       # China (CST)
+          # timezone: 'Australia/Sydney'    # Australia Eastern (AEST/AEDT)
+
+  - language: yaml
+    label: 'Fix UTC offset strings — use Etc/GMT or a Region/City name'
+    code: |
+      on:
+        schedule:
+          # ❌ UTC offset strings are NOT valid IANA names:
+          # - cron: '0 8 * * *'
+          #   timezone: 'UTC+5:30'   # wrong
+          # - cron: '0 8 * * *'
+          #   timezone: 'GMT+5'      # wrong
+
+          # ✅ Use the Region/City form instead:
+          - cron: '0 8 * * *'
+            timezone: 'Asia/Karachi'  # UTC+5 (Pakistan)
+
+          # Note: Etc/GMT zones use inverted sign convention (POSIX):
+          # Etc/GMT-5 is UTC+5 (confusingly inverted) — prefer Region/City names
+prevention:
+  - "Always use `Region/City` IANA timezone names (e.g., `America/New_York`) — never abbreviations like PST, EST, IST"
+  - "Look up the correct IANA name using the Wikipedia tz database list before using a new timezone"
+  - "Run `actionlint` locally (v0.7.4+) before pushing — it validates IANA timezone strings in on.schedule"
+  - "Use `UTC` explicitly for UTC schedules — it is a valid IANA name unlike `GMT+0` or `UTC+0`"
+  - "Remember that IANA names handle DST automatically (America/New_York switches between EST and EDT); abbreviations like EST are fixed-offset and ambiguous"
+docs:
+  - url: 'https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#onschedule'
+    label: 'GitHub Docs — on.schedule syntax including timezone field'
+  - url: 'https://en.wikipedia.org/wiki/List_of_tz_database_time_zones'
+    label: 'Wikipedia — List of IANA tz database timezone names'
+  - url: 'https://github.com/rhysd/actionlint/blob/main/docs/checks.md#cron-syntax-and-iana-timezone-string-at-onschedule'
+    label: 'actionlint docs — CRON syntax and IANA timezone string validation at on.schedule'
+  - url: 'https://github.com/rhysd/actionlint/issues/638'
+    label: 'actionlint #638 — Add support for timezone schedule triggers (fixed in v0.7.4)'
+  - url: 'https://github.com/rhysd/actionlint/commit/f48c0a493f9e25e99443136b413cde503258c745'
+    label: 'actionlint commit f48c0a4 — fix timezone check is incomplete (March 30, 2026)'

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@htekdev/actions-debugger",
-  "version": "1.0.134",
+  "version": "1.0.136",
   "description": "65+ real GitHub Actions errors, queryable by agents. CLI + MCP server + Copilot skills + error database.",
   "type": "module",
   "main": "./dist/index.js",