@htekdev/actions-debugger 1.0.91 → 1.0.93

package/errors/permissions-auth/github-models-missing-models-read-permission.yml

@@ -0,0 +1,115 @@
+id: permissions-auth-052
+title: 'GitHub Models API in Actions requires models: read permission — not in default GITHUB_TOKEN scopes'
+category: permissions-auth
+severity: error
+tags:
+  - models
+  - github-models
+  - ai
+  - permissions
+  - GITHUB_TOKEN
+  - 403
+  - inference
+patterns:
+  - regex: 'models:\s*read'
+    flags: 'i'
+  - regex: 'Resource not accessible by integration.*model'
+    flags: 'i'
+  - regex: 'models.*permission.*required|permission.*models.*required'
+    flags: 'i'
+  - regex: '403.*github\.com/models|github\.com/models.*403'
+    flags: 'i'
+error_messages:
+  - 'Error: Resource not accessible by integration'
+  - '403 Forbidden — models: read permission is required'
+  - 'HttpError: 403 Resource not accessible by integration'
+  - 'Error: The models permission is required to use the GitHub Models API'
+root_cause: |
+  GitHub Models (launched in 2024) provides access to AI inference models (GPT-4o,
+  Claude, Llama, etc.) via the GitHub Models API at https://models.inference.ai.azure.com
+  and via the GitHub REST API at api.github.com/models. When workflows use these
+  endpoints with the GITHUB_TOKEN (for example, via `actions/ai-inference` or via
+  `actions/github-script` calling `github.rest.models.*`), the token must have the
+  `models: read` permission explicitly declared.
+
+  The `models: read` permission was introduced as a new GITHUB_TOKEN scope alongside
+  the GitHub Models feature. It is NOT included in the default GITHUB_TOKEN permissions
+  and is NOT implied by any other existing permission (not `contents: read`, not
+  `packages: read`, not `id-token: write`).
+
+  Common failure patterns:
+  1. Adding an AI inference step or action to an existing workflow that has a
+     permissions: block — the block narrows all unspecified permissions to none,
+     and models: read was never added.
+  2. Using GitHub Models for the first time in a workflow that relies on the
+     repository's default "Read and write" permissions — models: read is not
+     included even in the broadest default permission set.
+  3. Reusable workflow callers that use `secrets: inherit` but do NOT pass through
+     permissions — the called workflow must declare its own `models: read`.
+  4. Fine-grained PATs used as a token override: the PAT must have the "Models: read"
+     resource permission enabled for the target repository or organization.
+
+  The error message "Resource not accessible by integration" is the same 403 error
+  used for other missing permissions, making it hard to identify models: read as the
+  specific missing scope without checking the API response body.
+fix: |
+  Add `models: read` to the `permissions:` block of the job (or workflow) that calls
+  the GitHub Models API. If using a fine-grained PAT instead of GITHUB_TOKEN, ensure
+  the PAT has the "Models" permission enabled.
+fix_code:
+  - language: yaml
+    label: 'Add models: read to job permissions for AI inference steps'
+    code: |
+      jobs:
+        ai-analysis:
+          runs-on: ubuntu-latest
+          permissions:
+            contents: read
+            models: read   # Required for GitHub Models API access
+          steps:
+            - uses: actions/checkout@v4
+            - name: Run AI inference via GitHub Models
+              uses: actions/ai-inference@v1
+              with:
+                model: openai/gpt-4o
+                system-prompt: 'You are a code reviewer. Be concise.'
+                user-prompt: 'Review the changes in this PR for security issues.'
+  - language: yaml
+    label: 'Workflow with multiple permissions including models: read'
+    code: |
+      on:
+        pull_request:
+
+      permissions:
+        contents: read
+        pull-requests: write
+        models: read   # Required for any AI model inference step
+
+      jobs:
+        review:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+            - name: AI code review
+              uses: actions/github-script@v7
+              with:
+                script: |
+                  // github.rest.models requires models: read permission
+                  const response = await github.request('POST /repos/{owner}/{repo}/actions/generate-summary', {
+                    owner: context.repo.owner,
+                    repo: context.repo.repo
+                  });
+prevention:
+  - "Always add `models: read` to the permissions block when using GitHub Models API, AI inference actions, or any `github.rest.models.*` API calls"
+  - "The `models: read` scope is not inherited, implied, or included in any default permission set — it must be declared explicitly"
+  - "When upgrading a workflow to add AI features, audit the existing permissions: block and add models: read before deploying"
+  - "Fine-grained PATs used as token overrides must explicitly include the Models permission for the relevant repositories"
+docs:
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/controlling-permissions-for-github_token'
+    label: 'GitHub Docs: Controlling permissions for GITHUB_TOKEN — available scopes'
+  - url: 'https://docs.github.com/en/github-models/use-github-models/integrating-ai-models-into-your-application'
+    label: 'GitHub Docs: Using GitHub Models — authentication and permissions'
+  - url: 'https://github.com/actions/ai-inference'
+    label: 'actions/ai-inference — GitHub Models inference action'
+  - url: 'https://github.com/marketplace/actions/ai-inference'
+    label: 'GitHub Marketplace: AI Inference action'

package/errors/runner-environment/setup-go-gotoolchain-auto-download.yml

@@ -0,0 +1,122 @@
+id: runner-environment-159
+title: 'setup-go@v5 with Go 1.21+ toolchain directive — GOTOOLCHAIN=auto downloads newer Go toolchain mid-CI'
+category: runner-environment
+severity: warning
+tags:
+  - setup-go
+  - go
+  - gotoolchain
+  - toolchain-directive
+  - go-version
+  - network
+  - go-mod
+patterns:
+  - regex: 'go: downloading go1\.\d+\.\d+ \(linux/amd64\)'
+    flags: 'i'
+  - regex: 'go: module requires GOTOOLCHAIN at least go1\.'
+    flags: 'i'
+  - regex: 'go: toolchain.*not available'
+    flags: 'i'
+  - regex: 'toolchain go1\.\d+\.\d+ required, have go1\.'
+    flags: 'i'
+error_messages:
+  - 'go: downloading go1.22.3 (linux/amd64)'
+  - 'go: module requires GOTOOLCHAIN at least go1.22.0'
+  - 'go: toolchain download not available: dial tcp: lookup proxy.golang.org: no such host'
+  - 'toolchain go1.22.3 required, have go1.21.13'
+root_cause: |
+  Go 1.21 introduced the `toolchain` directive in `go.mod` and `go.sum`, along with the
+  `GOTOOLCHAIN` environment variable that controls toolchain version management. The default
+  value `GOTOOLCHAIN=auto` causes the Go runtime to automatically download a newer Go
+  toolchain if the installed version is older than the version specified by the `toolchain`
+  directive (or the `go` directive when no explicit `toolchain` key exists).
+
+  When `actions/setup-go@v5` installs Go 1.21.x but the project's `go.mod` contains:
+    toolchain go1.22.3
+  Go will automatically attempt to download the go1.22.3 toolchain from proxy.golang.org
+  at runtime — during `go build`, `go test`, or any go command. This download adds
+  15-120 seconds to CI jobs and can fail entirely in:
+  - Self-hosted runners in air-gapped or network-restricted environments
+  - Runners with strict egress firewall rules blocking proxy.golang.org
+  - Flaky network conditions during toolchain resolution
+
+  The behavior is often invisible in logs because the download proceeds silently before
+  each `go` invocation. The symptom is slower-than-expected build times or a cryptic
+  `dial tcp: lookup proxy.golang.org: no such host` error that appears unrelated to
+  the Go version.
+
+  Note: This is distinct from the Go 1.23 telemetry cache tar collision
+  (runner-environment-041). That is a cache restore bug; this is an unexpected network
+  download triggered by the toolchain directive.
+fix: |
+  Option 1 (recommended): Set `GOTOOLCHAIN=local` to prevent auto-downloads and fail fast
+  if the installed version doesn't satisfy the toolchain directive. Then configure
+  `actions/setup-go@v5` to install exactly the required Go version.
+
+  Option 2: Use `go-version-file: go.mod` so that setup-go installs the exact Go version
+  matching the `go` line in go.mod — ensure this matches or exceeds the `toolchain`
+  directive to prevent downloads.
+
+  Option 3: Remove the `toolchain` directive from `go.mod` if it is not intentionally
+  pinning a minimum toolchain version. The directive was added automatically by
+  `go mod tidy` in Go 1.21+ and many projects don't need it.
+fix_code:
+  - language: yaml
+    label: 'Set GOTOOLCHAIN=local to prevent mid-CI toolchain downloads'
+    code: |
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          env:
+            GOTOOLCHAIN: local   # Never auto-download; use only the installed toolchain
+          steps:
+            - uses: actions/checkout@v4
+            - uses: actions/setup-go@v5
+              with:
+                go-version: '1.22.x'   # Install the exact version needed by go.mod
+                cache: true
+            - run: go build ./...
+  - language: yaml
+    label: 'Use go-version-file to pin version from go.mod'
+    code: |
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          env:
+            GOTOOLCHAIN: local
+          steps:
+            - uses: actions/checkout@v4
+            - uses: actions/setup-go@v5
+              with:
+                go-version-file: go.mod   # Reads 'go' directive from go.mod
+                cache: true
+            # go.mod should specify 'go 1.22.3' matching or exceeding the toolchain directive
+            - run: go build ./...
+  - language: yaml
+    label: 'Remove toolchain directive from go.mod to avoid the download trigger'
+    code: |
+      # In go.mod, remove the toolchain line if your project does not require a
+      # minimum toolchain version beyond what setup-go installs:
+      # BEFORE (triggers GOTOOLCHAIN=auto download):
+      # go 1.21
+      # toolchain go1.22.3
+      #
+      # AFTER (no automatic download):
+      # go 1.22.3
+      # (no toolchain directive)
+      #
+      # Run `go mod tidy` with GOTOOLCHAIN=local after editing go.mod to clean up.
+prevention:
+  - "Set `GOTOOLCHAIN: local` as a job-level env var in all Go workflows to prevent unexpected toolchain downloads"
+  - "When upgrading Go versions, use `go-version-file: go.mod` in setup-go so CI always installs the correct version"
+  - "After running `go mod tidy` locally with Go 1.21+, check whether a `toolchain` directive was added to go.mod before committing"
+  - "In air-gapped environments, always set GOTOOLCHAIN=local and pre-bake the required toolchain into the self-hosted runner image"
+docs:
+  - url: 'https://go.dev/doc/toolchain'
+    label: 'Go Toolchains — official documentation for GOTOOLCHAIN and toolchain directive'
+  - url: 'https://go.dev/blog/toolchain'
+    label: 'Go Blog: Go Toolchains (Go 1.21 announcement)'
+  - url: 'https://github.com/actions/setup-go/blob/main/README.md'
+    label: 'actions/setup-go README — go-version-file input'
+  - url: 'https://pkg.go.dev/cmd/go#hdr-Go_toolchain_management'
+    label: 'go command: toolchain management — GOTOOLCHAIN environment variable'

package/errors/runner-environment/windows-max-path-260-npm-build-failure.yml

@@ -0,0 +1,87 @@
+id: runner-environment-158
+title: 'Windows MAX_PATH 260-character limit causes npm and build tool failures'
+category: runner-environment
+severity: error
+tags:
+  - windows
+  - max-path
+  - npm
+  - node_modules
+  - path-length
+  - enoent
+  - build
+patterns:
+  - regex: 'The filename or extension is too long'
+    flags: 'i'
+  - regex: 'ENOENT.*node_modules.*node_modules'
+    flags: 'i'
+  - regex: 'error MSB3095.*path.*too long'
+    flags: 'i'
+  - regex: 'The system cannot find the path specified'
+    flags: 'i'
+error_messages:
+  - "The filename or extension is too long."
+  - "ENOENT: no such file or directory, open 'C:\\Users\\runner\\work\\..."
+  - "error MSB3095: Invalid argument. 'path' is too long."
+  - "npm ERR! path C:\\Users\\runner\\work\\..."
+root_cause: |
+  Windows enforces a 260-character maximum path length (MAX_PATH) inherited from
+  the Win32 API. Deep node_modules dependency trees easily exceed this limit: the
+  GitHub-hosted runner workspace is already at
+  C:\Users\runner\work\<repository>\<repository>\ (~50 characters) before any
+  source files are added. A typical transitive npm dependency path like
+  node_modules\pkg\node_modules\sub\node_modules\deep\index.js can push the total
+  well past 260 characters. MSBuild, Java build tools, and other Windows toolchains
+  have the same limitation.
+
+  GitHub-hosted Windows runners (windows-2022, windows-latest) have the
+  LongPathsEnabled registry key set to 1 at the OS level, but Git must still be
+  separately configured with core.longpaths = true, and some Node.js internal APIs
+  call the legacy Win32 CreateFile path which ignores the registry opt-in unless
+  the application explicitly declares long-path awareness in its executable manifest.
+  The result is ENOENT or "path too long" failures that appear to indicate missing
+  files rather than a path-length limit.
+fix: |
+  Option 1 (most effective): Use a short path: in actions/checkout to reduce the
+  base path length. path: a sets the workspace to C:\...\work\repo\a.
+  Option 2: Configure Git long paths and use --legacy-peer-deps to flatten
+  npm dependency nesting.
+  Option 3: Shorten the repository name, which directly reduces the workspace
+  path length.
+fix_code:
+  - language: yaml
+    label: 'Use short checkout path to reduce base path length'
+    code: |
+      jobs:
+        build:
+          runs-on: windows-latest
+          steps:
+            - uses: actions/checkout@v4
+              with:
+                path: a   # Reduces base path by ~20-30 characters vs default
+            - run: npm ci
+              working-directory: a
+  - language: yaml
+    label: 'Enable Git long paths and flatten npm tree'
+    code: |
+      jobs:
+        build:
+          runs-on: windows-latest
+          steps:
+            - name: Configure Git long paths
+              run: git config --global core.longpaths true
+            - uses: actions/checkout@v4
+            - name: Install with flattened dependencies
+              run: npm ci --legacy-peer-deps
+prevention:
+  - 'Use path: a (or another single-char name) in actions/checkout to reduce baseline path length on Windows'
+  - 'Keep GitHub repository names short when Windows CI is required'
+  - 'Avoid deeply nested workspace directory structures'
+  - 'Run npm ci --legacy-peer-deps to reduce node_modules nesting on npm 7+ which introduced deeper trees'
+docs:
+  - url: 'https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation'
+    label: 'Microsoft Docs: Maximum file path limitation (MAX_PATH)'
+  - url: 'https://git-scm.com/docs/git-config#Documentation/git-config.txt-coreprotectNTFS'
+    label: 'Git: core.longpaths config'
+  - url: 'https://docs.npmjs.com/cli/v10/commands/npm-ci'
+    label: 'npm ci — clean install'

package/errors/silent-failures/pull-request-branches-filter-not-inherited.yml

@@ -0,0 +1,73 @@
+id: silent-failures-086
+title: 'on.pull_request does not inherit branches filter from sibling on.push trigger'
+category: silent-failures
+severity: silent-failure
+tags:
+  - pull_request
+  - push
+  - branches-filter
+  - trigger
+  - unexpected-runs
+  - filter-inheritance
+patterns:
+  - regex: 'on:\s*\n\s*push:\s*\n\s*branches:\s*\n.*\n\s*pull_request:\s*\n(?!\s*branches:)'
+    flags: 'ms'
+error_messages: []
+root_cause: |
+  When a workflow defines multiple triggers under on:, each trigger's configuration
+  is fully independent — there is no filter inheritance between sibling triggers.
+  A common pattern is to restrict on.push to specific branches (e.g., main,
+  release/**) while adding on.pull_request with no branches: key, expecting the
+  PR trigger to respect the same branch scope.
+
+  In YAML mapping semantics, on.push.branches: [main] applies exclusively to push
+  events. on.pull_request with no branches: key means "trigger for pull requests
+  targeting ANY branch in the repository." This causes the workflow to run on every
+  PR opened against feature branches, release candidates, or any other branch —
+  running expensive CI on PRs the developer intended to exclude.
+
+  The GitHub Actions UI shows these runs as triggered by pull_request with no
+  indication that the branches: filter was missing. The behavior appears correct
+  (workflow ran) but occurs on unintended PRs.
+fix: |
+  Explicitly add a branches: filter to on.pull_request that defines the target
+  branches for which CI should run. Note that on.pull_request.branches matches the
+  BASE branch (the branch the PR targets), not the head/feature branch.
+fix_code:
+  - language: yaml
+    label: 'Explicit branches filter on both triggers'
+    code: |
+      on:
+        push:
+          branches: [main, 'release/**']
+        pull_request:
+          branches: [main, 'release/**']  # Required — NOT inherited from on.push
+      jobs:
+        ci:
+          runs-on: ubuntu-latest
+          steps:
+            - run: npm test
+  - language: yaml
+    label: 'Common mistake — missing branches on pull_request'
+    code: |
+      # WRONG — pull_request triggers for ALL target branches
+      on:
+        push:
+          branches: [main]
+        pull_request:           # No branches filter — triggers for every PR
+      # CORRECT
+      on:
+        push:
+          branches: [main]
+        pull_request:
+          branches: [main]      # Only PRs targeting main
+prevention:
+  - 'Review each trigger block independently — on.push and on.pull_request filters are never shared'
+  - 'Add an explicit branches: under on.pull_request whenever you use branches: under on.push'
+  - 'Remember: on.pull_request.branches matches the BASE branch of the PR, not the feature branch'
+  - 'Use actionlint to validate trigger configurations before committing'
+docs:
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#using-filters'
+    label: 'GitHub Docs: Using filters — each trigger is configured independently'
+  - url: 'https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore'
+    label: 'GitHub Actions: pull_request branches filter matches base branch'

package/errors/triggers/delete-event-fires-branch-and-tag.yml

@@ -0,0 +1,75 @@
+id: triggers-061
+title: 'on.delete fires for branch and tag deletion — no ref_type filter at trigger level'
+category: triggers
+severity: silent-failure
+tags:
+  - delete
+  - ref_type
+  - branch
+  - tag
+  - unexpected-runs
+patterns:
+  - regex: 'on:\s*\n\s*delete:'
+    flags: 'ms'
+error_messages: []
+root_cause: |
+  The on.delete event fires whenever any branch or tag is deleted in the repository.
+  Unlike some events that support a types: activity filter, on.delete has no types
+  option — there is no trigger-level way to restrict it to branch deletions only or
+  tag deletions only. Workflows that perform branch-specific cleanup (removing
+  temporary deployment environments, rotating secrets, updating external project
+  boards, or archiving feature branch artifacts) run for EVERY tag deletion as well,
+  unless an explicit runtime condition is added inside the workflow.
+
+  The on.create event has the same dual-fire behavior (documented separately). Both
+  events expose github.event.ref_type in the workflow context as either 'branch' or
+  'tag', but this value is only available inside the workflow body — it cannot be
+  used as a trigger-level filter.
+
+  A common scenario: a workflow cleans up branch-specific cloud environments on
+  delete. When a developer deletes the release tag v1.2.3, the workflow fires
+  unexpectedly — potentially tearing down a production environment that was deployed
+  from that tag.
+fix: |
+  Add an if: condition using github.event.ref_type to guard jobs or steps that
+  should only execute for one type of deletion. Use 'branch' or 'tag' as the
+  comparison value.
+fix_code:
+  - language: yaml
+    label: 'Guard cleanup by ref_type at the job level'
+    code: |
+      on:
+        delete:
+      jobs:
+        cleanup-branch-environment:
+          # Only run for branch deletions — skip tag deletions
+          if: github.event.ref_type == 'branch'
+          runs-on: ubuntu-latest
+          steps:
+            - name: Remove branch-specific deployment
+              run: echo "Cleaning up env for branch ${{ github.event.ref }}"
+  - language: yaml
+    label: 'Separate jobs for branch vs tag deletion'
+    code: |
+      on:
+        delete:
+      jobs:
+        cleanup-branch:
+          if: github.event.ref_type == 'branch'
+          runs-on: ubuntu-latest
+          steps:
+            - run: echo "Branch deleted ${{ github.event.ref }}"
+        cleanup-tag:
+          if: github.event.ref_type == 'tag'
+          runs-on: ubuntu-latest
+          steps:
+            - run: echo "Tag deleted ${{ github.event.ref }}"
+prevention:
+  - 'Always guard on.delete workflow jobs with if: github.event.ref_type == ''branch'' or ''tag'''
+  - 'Be aware that on.create has the same behavior — both create and delete fire for branches and tags'
+  - 'Test delete workflows by deleting both a branch and a tag to verify they behave as expected'
+docs:
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#delete'
+    label: 'GitHub Docs: delete event — fires for branches and tags'
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/contexts#github-context'
+    label: 'GitHub Docs: github.event.ref_type context'

package/errors/triggers/deployment-status-all-types-default.yml

@@ -0,0 +1,123 @@
+id: triggers-063
+title: 'on.deployment_status fires for all deployment lifecycle statuses by default — add types: to filter'
+category: triggers
+severity: warning
+tags:
+  - deployment_status
+  - deployment
+  - event-types
+  - trigger
+  - duplicate-runs
+  - types-filter
+patterns:
+  - regex: 'on:\s*\n\s*deployment_status:'
+    flags: 'ms'
+  - regex: 'deployment_status:\s*$'
+    flags: 'i'
+error_messages:
+  - '(no error — workflow fires unexpectedly multiple times per deployment)'
+root_cause: |
+  The `on.deployment_status` event fires whenever the status of a deployment changes.
+  A single end-to-end deployment lifecycle emits SIX distinct status events in sequence:
+    created → queued → in_progress → success (or failure / error)
+  Plus `inactive` when an older deployment is superseded by a new one.
+
+  When a workflow uses `on: deployment_status:` without a `types:` filter, it runs for
+  EVERY one of these status transitions. For a typical deployment:
+  - GitHub creates the deployment (fires `deployment_status` with state `created`)
+  - The deployment starts running (fires `in_progress`)
+  - The deployment completes (fires `success`)
+  - Any prior deployment for the same environment becomes inactive (fires `inactive`)
+
+  This causes a workflow to run 3-4 times per deployment. Common consequences:
+  - Post-deployment smoke tests run before the deployment is complete (`in_progress` run)
+  - Notification steps send duplicate Slack/email messages for each status transition
+  - Downstream `workflow_run` triggers fire multiple times, causing race conditions
+  - GitHub-billed Actions minutes are wasted on unwanted runs
+
+  The `deployment_status` event does not have sensible defaults for status filtering —
+  unlike `pull_request` (which defaults to `opened`, `synchronize`, `reopened`),
+  `deployment_status` has no default type filter and fires for everything.
+
+  Note: This is analogous to `on.pull_request_review` firing for all review types by
+  default (documented in triggers-062). Both events require explicit `types:` filters
+  to limit scope to meaningful actions.
+fix: |
+  Add a `types:` filter to `on.deployment_status` to limit which status transitions
+  trigger the workflow. For most use cases:
+  - Post-deployment tests: use `types: [success]`
+  - Deployment monitoring: use `types: [failure, error]`
+  - Full lifecycle tracking: use `types: [in_progress, success, failure, error]`
+
+  Additionally, add an `if:` condition using `github.event.deployment_status.state`
+  for fine-grained control when multiple types are needed.
+fix_code:
+  - language: yaml
+    label: 'Filter to success only — post-deployment smoke tests'
+    code: |
+      on:
+        deployment_status:
+          types:
+            - success   # Only runs when deployment reaches success state
+
+      jobs:
+        smoke-test:
+          runs-on: ubuntu-latest
+          steps:
+            - name: Run smoke tests against deployed environment
+              run: |
+                ENV_URL="${{ github.event.deployment_status.environment_url }}"
+                echo "Testing $ENV_URL"
+                curl -f "$ENV_URL/health"
+  - language: yaml
+    label: 'Filter to failure and error — deployment monitoring'
+    code: |
+      on:
+        deployment_status:
+          types:
+            - failure
+            - error
+
+      jobs:
+        alert:
+          runs-on: ubuntu-latest
+          steps:
+            - name: Notify on deployment failure
+              run: |
+                echo "Deployment failed: ${{ github.event.deployment_status.state }}"
+                echo "Environment: ${{ github.event.deployment.environment }}"
+  - language: yaml
+    label: 'Multiple types with runtime if: check for nuanced handling'
+    code: |
+      on:
+        deployment_status:
+          types:
+            - success
+            - failure
+            - error
+
+      jobs:
+        post-deploy:
+          runs-on: ubuntu-latest
+          steps:
+            - name: Run tests on success
+              if: github.event.deployment_status.state == 'success'
+              run: echo "Running post-deployment tests"
+
+            - name: Alert on failure
+              if: |
+                github.event.deployment_status.state == 'failure' ||
+                github.event.deployment_status.state == 'error'
+              run: echo "Alerting on deployment failure"
+prevention:
+  - "Always add `types:` to `on.deployment_status` — the default of no filter fires for all 6 status transitions"
+  - "Check `github.event.deployment_status.state` in workflow conditions when using multiple status types"
+  - "Use `environment_url` from `github.event.deployment_status` to target the correct environment in post-deployment tests"
+  - "Monitor your Actions run history after deploying — multiple runs per deployment indicates a missing types: filter"
+docs:
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#deployment_status'
+    label: 'GitHub Docs: deployment_status event — activity types'
+  - url: 'https://docs.github.com/en/rest/deployments/statuses?apiVersion=2022-11-28'
+    label: 'GitHub REST API: Deployment statuses — state values'
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/contexts#github-context'
+    label: 'GitHub Docs: github.event.deployment_status context fields'

package/errors/triggers/pull-request-review-all-types-default.yml

@@ -0,0 +1,69 @@
+id: triggers-062
+title: 'on.pull_request_review fires for all review types (submitted, edited, dismissed) when types is omitted'
+category: triggers
+severity: silent-failure
+tags:
+  - pull_request_review
+  - review
+  - types
+  - dismissed
+  - submitted
+  - unexpected-runs
+patterns:
+  - regex: 'on:\s*\n\s*pull_request_review:\s*\n(?!\s*types:)'
+    flags: 'ms'
+error_messages: []
+root_cause: |
+  The pull_request_review event fires for three activity types:
+    - submitted: a new review is posted (approved, changes_requested, or commented)
+    - edited: a reviewer edits their review comment text
+    - dismissed: an existing approval or changes_requested review is dismissed
+
+  When on.pull_request_review: is specified without a types: filter, GitHub fires
+  the workflow for ALL three activity types. Developers typically use this event to
+  trigger a deployment or notification on PR approval. Without types: [submitted],
+  the workflow also runs when a reviewer edits their comment spelling or when an
+  approval is dismissed by a maintainer — often causing incorrect or failed workflow
+  runs in contexts where the PR is no longer in an approved state.
+
+  This behavior mirrors on.pull_request without types: (which fires for opened,
+  synchronize, and reopened by default) but is arguably more surprising because
+  "editing a review comment" and "dismissing a review" are far less common
+  developer actions than submitting a new review.
+fix: |
+  Add types: [submitted] to restrict the trigger to new review submissions.
+  If you only want to react to approvals specifically, also add an if: condition
+  checking github.event.review.state == 'approved'.
+fix_code:
+  - language: yaml
+    label: 'Restrict to submitted reviews only'
+    code: |
+      on:
+        pull_request_review:
+          types: [submitted]   # Only new review submissions — not edited or dismissed
+      jobs:
+        notify-on-review:
+          runs-on: ubuntu-latest
+          steps:
+            - run: echo "Review state ${{ github.event.review.state }}"
+  - language: yaml
+    label: 'Trigger only on PR approvals'
+    code: |
+      on:
+        pull_request_review:
+          types: [submitted]
+      jobs:
+        deploy-on-approval:
+          if: github.event.review.state == 'approved'
+          runs-on: ubuntu-latest
+          steps:
+            - run: echo "PR approved — proceeding with staging deploy"
+prevention:
+  - 'Always specify types: [submitted] under on.pull_request_review unless dismissed or edited is explicitly needed'
+  - 'Combine types: [submitted] with if: github.event.review.state == ''approved'' for approval-gated workflows'
+  - 'Test pull_request_review workflows by also dismissing reviews to ensure unexpected runs are avoided'
+docs:
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#pull_request_review'
+    label: 'GitHub Docs: pull_request_review event — activity types'
+  - url: 'https://docs.github.com/en/webhooks/webhook-events-and-payloads#pull_request_review'
+    label: 'GitHub Webhooks: pull_request_review payload — review.state values'

package/errors/yaml-syntax/workflow-call-boolean-input-default-string.yml

@@ -0,0 +1,122 @@
+id: yaml-syntax-058
+title: 'on.workflow_call.inputs boolean default must be YAML boolean not a quoted string — default: ''true'' causes validation error'
+category: yaml-syntax
+severity: error
+tags:
+  - workflow-call
+  - reusable-workflow
+  - inputs
+  - boolean
+  - default
+  - validation-error
+  - type-mismatch
+patterns:
+  - regex: 'Unexpected\s+value\s+''true'''
+    flags: 'i'
+  - regex: 'Unexpected\s+value\s+''false'''
+    flags: 'i'
+  - regex: 'on\.workflow_call\.inputs\.[^.]+\.default.*''(?:true|false)'''
+    flags: 'i'
+  - regex: 'default:\s+''(?:true|false)'''
+    flags: 'i'
+error_messages:
+  - "Invalid workflow file: .github/workflows/deploy.yml: on.workflow_call.inputs.dry_run.default: Unexpected value 'true'"
+  - "Unexpected value 'true'"
+  - "Unexpected value 'false'"
+  - "on.workflow_call.inputs.X.default: Unexpected value 'true'"
+root_cause: |
+  In GitHub Actions, `on.workflow_call.inputs` supports three types: `string`, `boolean`,
+  and `number`. When declaring a `type: boolean` input, the `default:` value must be
+  a YAML boolean literal (`true` or `false`), NOT a quoted string (`'true'` or `'false'`).
+
+  Quoted strings ('true', 'false') are YAML string scalars. GitHub Actions validates
+  the `default:` value against the declared input `type:`, and when a string is given
+  where a boolean is expected, workflow validation fails with:
+    "on.workflow_call.inputs.X.default: Unexpected value 'true'"
+
+  This mistake is extremely common for two reasons:
+  1. Developers working with YAML often quote boolean-like values defensively to avoid
+     YAML parsing surprises — but in this specific field, the quotes cause the error.
+  2. The error message "Unexpected value 'true'" is confusing: `true` is expected, but
+     the quotes around it in the error output make it look like 'true' is a bad value,
+     not that the quotes themselves are the problem.
+
+  This is distinct from `silent-failures/workflow-call-boolean-input-string-coercion.yml`
+  which covers the receiving side: even when defaults are declared correctly, the called
+  workflow receives boolean input values as strings ('true'/'false') in the `inputs`
+  context and must compare using `== 'true'` not `== true`. This entry is about the
+  DECLARATION error before the workflow even runs.
+fix: |
+  Remove the quotes from the `default:` value for `type: boolean` inputs in
+  `on.workflow_call.inputs`. Use bare YAML booleans `true` and `false`.
+
+  If you want to document the type explicitly, add a `description:` field instead of
+  relying on the default value to communicate the type.
+fix_code:
+  - language: yaml
+    label: 'WRONG: quoted string default causes validation error'
+    code: |
+      # BROKEN: 'true' is a string, not a boolean — validation fails
+      on:
+        workflow_call:
+          inputs:
+            dry_run:
+              type: boolean
+              default: 'true'   # ERROR: Unexpected value 'true'
+              description: 'Run in dry-run mode'
+  - language: yaml
+    label: 'CORRECT: bare YAML boolean for default value'
+    code: |
+      # FIXED: true (no quotes) is a YAML boolean — validation passes
+      on:
+        workflow_call:
+          inputs:
+            dry_run:
+              type: boolean
+              default: true    # Correct YAML boolean literal
+              description: 'Run in dry-run mode (default: enabled)'
+            skip_tests:
+              type: boolean
+              default: false   # Correct YAML boolean literal
+              description: 'Skip test suite'
+  - language: yaml
+    label: 'Complete reusable workflow with correct boolean inputs'
+    code: |
+      # .github/workflows/deploy-reusable.yml
+      on:
+        workflow_call:
+          inputs:
+            environment:
+              type: string
+              required: true
+              description: 'Target environment: staging or production'
+            dry_run:
+              type: boolean
+              default: false    # bare boolean, no quotes
+              description: 'Perform a dry run without making changes'
+            notify:
+              type: boolean
+              default: true     # bare boolean, no quotes
+              description: 'Send Slack notification on completion'
+
+      jobs:
+        deploy:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+            # Note: inputs.dry_run arrives as the STRING 'true' or 'false'
+            # in the job body — compare with == 'true', not == true
+            - if: inputs.dry_run != 'true'
+              run: echo "Deploying to ${{ inputs.environment }}"
+prevention:
+  - "Never quote boolean default values in workflow_call inputs — use bare `true` or `false`"
+  - "Remember that while the DECLARATION requires bare booleans, the VALUE received by steps is always a string: compare with `== 'true'`, not `== true`"
+  - "Run `actionlint` locally to catch input type/default mismatches before pushing"
+  - "Validate workflow files with `gh workflow view` or push to a test branch to surface validation errors early"
+docs:
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#workflow_call'
+    label: 'GitHub Docs: workflow_call inputs — supported types and default values'
+  - url: 'https://docs.github.com/en/actions/sharing-automations/reusing-workflows#using-inputs-and-secrets-in-a-reusable-workflow'
+    label: 'GitHub Docs: Reusable workflow inputs'
+  - url: 'https://github.com/orgs/community/discussions/39357'
+    label: 'GitHub Community: workflow_call input type validation discussion'

package/package.json

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