@htekdev/actions-debugger 1.0.88 → 1.0.90

package/errors/concurrency-timing/concurrency-timing-044.yml

@@ -0,0 +1,95 @@
+id: concurrency-timing-044
+title: 'Matrix jobs with a static concurrency group key serialize instead of running in parallel'
+category: concurrency-timing
+severity: silent-failure
+tags:
+  - matrix
+  - concurrency
+  - parallelism
+  - group-key
+  - strategy
+patterns:
+  - regex: 'Waiting for a pending job to finish'
+    flags: 'i'
+  - regex: 'This workflow is waiting for a pending job to complete'
+    flags: 'i'
+error_messages:
+  - 'Waiting for a pending job to finish — concurrency: ci-deploy'
+root_cause: |
+  When a workflow-level or job-level concurrency group is configured with a static
+  key that does not include the matrix dimension values, all matrix legs share the
+  same concurrency slot. GitHub Actions enforces that only one run occupies each
+  slot at a time, so instead of running N matrix legs in parallel, the legs queue
+  and execute one at a time — silently serializing a job strategy that was intended
+  to be parallel.
+
+  This can multiply workflow duration by the number of matrix dimensions (e.g., a
+  3-OS matrix that should finish in 10 minutes takes 30 minutes). The GitHub Actions
+  UI shows later matrix legs as "Waiting for a pending job to finish" which hints at
+  the problem, but developers often interpret this as runner resource contention rather
+  than a concurrency group misconfiguration.
+
+  Common patterns that trigger this:
+    concurrency:
+      group: ci-${{ github.ref }}    # all matrix legs share "ci-refs/heads/main"
+
+    concurrency:
+      group: ${{ github.workflow }}  # all legs share workflow name
+fix: |
+  Include the relevant matrix dimension values in the concurrency group key so that
+  each matrix leg gets a unique slot. If cancel-in-progress behavior is still needed,
+  it will apply per-matrix-leg rather than globally across all legs.
+
+  If you intentionally want to serialize matrix legs (e.g., sequential deploys to
+  environments), keep the static key but document the serialization intent.
+fix_code:
+  - language: yaml
+    label: 'Include matrix values in concurrency group key'
+    code: |
+      jobs:
+        test:
+          strategy:
+            matrix:
+              os: [ubuntu-latest, windows-latest, macos-latest]
+              node: [18, 20, 22]
+          runs-on: ${{ matrix.os }}
+          concurrency:
+            # Unique slot per matrix leg — allows full parallelism
+            group: ci-${{ github.ref }}-${{ matrix.os }}-${{ matrix.node }}
+            cancel-in-progress: true
+          steps:
+            - uses: actions/checkout@v4
+            - uses: actions/setup-node@v4
+              with:
+                node-version: ${{ matrix.node }}
+            - run: npm test
+  - language: yaml
+    label: 'Workflow-level concurrency must also include matrix values'
+    code: |
+      # BAD: workflow-level concurrency applies to ALL jobs, including matrix legs
+      # concurrency:
+      #   group: ci-${{ github.ref }}    # serializes all legs!
+      #   cancel-in-progress: true
+
+      # GOOD: set concurrency at the job level with matrix dimensions in the key
+      jobs:
+        build:
+          strategy:
+            matrix:
+              platform: [linux, windows, macos]
+          runs-on: ubuntu-latest
+          concurrency:
+            group: build-${{ github.ref }}-${{ matrix.platform }}
+            cancel-in-progress: true
+          steps:
+            - run: echo "Building for ${{ matrix.platform }}"
+prevention:
+  - 'Always include matrix dimension values in concurrency group keys: group: ci-${{ github.ref }}-${{ matrix.os }}'
+  - 'Check workflow execution time after adding concurrency groups — unexpected serialization increases total duration'
+  - 'Use workflow-level concurrency only for single-job workflows; for matrix jobs, always configure concurrency at the job level'
+  - 'Verify parallelism by checking the GitHub Actions timeline view — all matrix legs should show overlapping execution'
+docs:
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/using-concurrency'
+    label: 'Using concurrency in GitHub Actions'
+  - url: 'https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix'
+    label: 'Matrix strategy syntax reference'

package/errors/known-unsolved/known-unsolved-052.yml

@@ -0,0 +1,119 @@
+id: known-unsolved-052
+title: 'GitHub-hosted runner IP addresses change on every workflow run — static IP allowlisting unreliable'
+category: known-unsolved
+severity: limitation
+tags:
+  - runner
+  - ip-address
+  - firewall
+  - allowlist
+  - network
+  - hosted-runner
+patterns:
+  - regex: 'Connection refused|Connection timed out|Unable to connect'
+    flags: 'i'
+  - regex: 'connect ECONNREFUSED|ECONNRESET|ETIMEDOUT'
+    flags: 'i'
+  - regex: 'blocked by firewall|access denied.*firewall|ip.*not.*allowed'
+    flags: 'i'
+error_messages:
+  - 'Error: connect ECONNREFUSED 10.0.0.5:5432'
+  - 'curl: (7) Failed to connect to internal-api.company.com port 443: Connection refused'
+  - 'Error: connect ETIMEDOUT'
+root_cause: |
+  GitHub-hosted runners are allocated from a large, rotating pool of virtual machines.
+  The IP address assigned to each run is drawn from GitHub's published CIDR ranges
+  (available via https://api.github.com/meta under "actions") but changes on every
+  workflow run — there is no way to obtain a stable, predictable IP for a GitHub-hosted
+  runner in advance.
+
+  GitHub publishes these IP ranges for documentation purposes, but:
+  1. The ranges are broad (/20 or larger) and overlap with other GitHub services
+  2. The specific IP within the range cannot be predicted before the run starts
+  3. The ranges update periodically, requiring allowlist maintenance
+  4. On each run, the runner's IP can be any address in the published ranges
+
+  This makes static IP allowlisting in external firewalls, database security groups
+  (AWS RDS, Azure SQL, Cloudflare), or on-premise systems unreliable. Allowlisting the
+  entire published range exposes hundreds of thousands of IP addresses and violates
+  least-privilege security principles.
+
+  This is a fundamental architecture constraint of GitHub-hosted runners and has no
+  perfect solution — only workarounds.
+fix: |
+  There is no way to guarantee a stable IP for GitHub-hosted runners. Use one of these
+  patterns instead of IP allowlisting:
+
+  1. OIDC (preferred): Use OIDC tokens to authenticate to cloud providers (AWS, Azure,
+     GCP) rather than network-level access controls. No IP allowlisting needed.
+
+  2. Self-hosted runners: Deploy runners on your network with known, stable IPs.
+
+  3. Dynamic allowlisting: At workflow start, call your cloud provider API to add the
+     runner's current IP to the security group; remove it at workflow end. Brittle but
+     workable for database access.
+
+  4. VPN/tunnel action: Use actions like cloudflare/cloudflare-warp-action or a
+     WireGuard setup action to tunnel runner traffic through a fixed gateway IP.
+
+  5. Private hosted runners (GitHub Enterprise): If on GHEC, configure static IP ranges
+     via network configurations for GitHub-hosted runners.
+fix_code:
+  - language: yaml
+    label: 'Use OIDC authentication instead of IP allowlisting (AWS example)'
+    code: |
+      jobs:
+        deploy:
+          runs-on: ubuntu-latest
+          permissions:
+            id-token: write
+            contents: read
+          steps:
+            - uses: aws-actions/configure-aws-credentials@v4
+              with:
+                role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
+                aws-region: us-east-1
+                # No IP allowlisting needed — OIDC validates the token, not the IP
+            - run: aws rds describe-db-instances
+  - language: yaml
+    label: 'Dynamic security group allowlisting (temporary, for legacy systems)'
+    code: |
+      jobs:
+        test-with-db:
+          runs-on: ubuntu-latest
+          steps:
+            - name: Get runner IP
+              id: ip
+              run: echo "ip=$(curl -s https://api.ipify.org)" >> $GITHUB_OUTPUT
+
+            - name: Add runner IP to DB security group
+              run: |
+                aws ec2 authorize-security-group-ingress \
+                  --group-id sg-0abc123 \
+                  --protocol tcp \
+                  --port 5432 \
+                  --cidr "${{ steps.ip.outputs.ip }}/32"
+
+            - name: Run tests
+              run: npm test
+
+            - name: Remove runner IP from security group
+              if: always()
+              run: |
+                aws ec2 revoke-security-group-ingress \
+                  --group-id sg-0abc123 \
+                  --protocol tcp \
+                  --port 5432 \
+                  --cidr "${{ steps.ip.outputs.ip }}/32"
+prevention:
+  - 'Design CI pipelines to use token-based authentication (OIDC, API keys, mTLS) rather than IP allowlisting from the start'
+  - 'For AWS: use IAM roles with OIDC (aws-actions/configure-aws-credentials); for Azure: use azure/login with OIDC; for GCP: use google-github-actions/auth with Workload Identity Federation'
+  - 'If IP allowlisting is unavoidable, use GitHub Enterprise Cloud with a configured network allowing stable egress IPs'
+  - 'Subscribe to GitHub changelog for updates to runner IP range publications — the ranges do expand over time'
+docs:
+  - url: 'https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners#ip-addresses'
+    label: 'GitHub-hosted runner IP addresses'
+  - url: 'https://api.github.com/meta'
+    label: 'GitHub meta API — published actions IP ranges'
+  - url: 'https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-cloud-providers'
+    label: 'Configuring OIDC in cloud providers'

package/errors/silent-failures/silent-failures-082.yml

@@ -0,0 +1,93 @@
+id: silent-failures-082
+title: "pull_request_target checkout defaults to base branch, not PR head"
+category: silent-failures
+severity: silent-failure
+tags:
+  - pull_request_target
+  - checkout
+  - security
+  - fork
+  - base-branch
+patterns:
+  - regex: 'on:\s*\n\s+pull_request_target'
+    flags: 'im'
+  - regex: 'pull_request_target'
+    flags: 'i'
+error_messages:
+  - "Workflow runs on base branch code instead of PR contributor changes"
+  - "Tests pass on base but fail on PR code with no visible error in logs"
+root_cause: |
+  When a workflow is triggered by `pull_request_target`, GitHub Actions runs the workflow
+  from the TARGET repository's base branch — not the contributor's PR head. This is
+  intentional: `pull_request_target` provides write-level token access (for labeling,
+  commenting, posting status checks), so GitHub protects secrets by refusing to run
+  untrusted fork code with elevated permissions.
+
+  As a result, `actions/checkout` checks out `github.sha`, which resolves to the merge
+  base commit on the target branch. Any tests, linting, or code analysis in this
+  workflow validate the base branch, not the contributor's changes. The workflow
+  succeeds silently while testing the wrong code.
+fix: |
+  Option 1 (recommended — safe): Use `pull_request` (not `pull_request_target`) for
+  running PR code. `pull_request` triggers run with read-only tokens and check out the
+  PR head by default. Use `pull_request_target` only for privileged actions like posting
+  comments or labels.
+
+  Option 2 (explicit checkout — use with caution): Explicitly check out the PR head
+  using `github.event.pull_request.head.sha`. Only do this if you fully trust all
+  contributors and understand that fork code will execute with the repository write token.
+fix_code:
+  - language: yaml
+    label: "Recommended: use pull_request for code execution, pull_request_target for privileged writes"
+    code: |
+      # Workflow 1: run tests on PR code (read-only, safe for forks)
+      on:
+        pull_request:
+          branches: [main]
+
+      jobs:
+        test:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+              # Checks out PR head automatically — no ref: override needed
+            - run: npm test
+
+      ---
+      # Workflow 2: post labels (write access via pull_request_target)
+      on:
+        pull_request_target:
+          types: [opened]
+
+      jobs:
+        label:
+          runs-on: ubuntu-latest
+          permissions:
+            pull-requests: write
+          steps:
+            - uses: actions/labeler@v5
+              # Never runs contributor code here — only labels the PR
+  - language: yaml
+    label: "If you must run PR code under pull_request_target (risky)"
+    code: |
+      on:
+        pull_request_target:
+          branches: [main]
+
+      jobs:
+        test:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+              with:
+                ref: ${{ github.event.pull_request.head.sha }}
+                # WARNING: executes untrusted fork code with write-level token
+prevention:
+  - "Use pull_request (not pull_request_target) for workflows that run code — pull_request tokens are read-only and checkout the PR head correctly by default"
+  - "Reserve pull_request_target for privileged write-only actions: posting comments, applying labels, updating statuses — never checkout and execute untrusted PR code in these workflows"
+  - "If CI consistently passes but reviewers find bugs tests should catch, verify which commit your checkout step is using by printing github.sha vs github.event.pull_request.head.sha"
+docs:
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#pull_request_target"
+    label: "pull_request_target event — security considerations"
+  - url: "https://securitylab.github.com/research/github-actions-preventing-pwn-requests/"
+    label: "GitHub Security Lab: Preventing pwn requests (pull_request_target risks)"

package/errors/silent-failures/silent-failures-083.yml

@@ -0,0 +1,64 @@
+id: silent-failures-083
+title: "matrix strategy fail-fast true by default silently cancels all remaining jobs on first failure"
+category: silent-failures
+severity: silent-failure
+tags:
+  - matrix
+  - fail-fast
+  - cancellation
+  - strategy
+  - parallel-jobs
+patterns:
+  - regex: 'strategy:\s*\n\s+matrix:'
+    flags: 'im'
+  - regex: 'Some jobs were not executed because a previous required job failed'
+    flags: 'i'
+error_messages:
+  - "Some jobs were not executed because a previous required job failed"
+  - "Skipping this step because a previous step failed or the workflow was cancelled"
+  - "This job was cancelled because another job in the workflow failed"
+root_cause: |
+  GitHub Actions matrix strategy has `fail-fast: true` as the default. When any single
+  matrix job fails, GitHub immediately cancels all remaining in-progress and queued
+  matrix jobs from the same workflow run.
+
+  This means:
+  - You only see the failure from the first (or earliest) failing matrix combination
+  - All other combinations — whether they would pass or fail — are cancelled immediately
+  - The workflow summary shows cancelled jobs with no diagnostic information
+  - Developers may spend time fixing the first failure only to discover a second unrelated
+    failure in a different matrix combination afterward
+
+  Many developers set up matrix builds specifically to validate across multiple
+  OS/language version combinations and expect every combination to run to completion.
+fix: |
+  Explicitly set `fail-fast: false` in your matrix strategy to allow all matrix jobs to
+  run to completion regardless of individual failures. This provides a complete picture
+  of which matrix combinations are broken.
+fix_code:
+  - language: yaml
+    label: "Set fail-fast: false to run all matrix combinations to completion"
+    code: |
+      jobs:
+        test:
+          strategy:
+            fail-fast: false    # default is true — set false for full matrix visibility
+            matrix:
+              os: [ubuntu-latest, windows-latest, macos-latest]
+              node: [18, 20, 22]
+          runs-on: ${{ matrix.os }}
+          steps:
+            - uses: actions/checkout@v4
+            - uses: actions/setup-node@v4
+              with:
+                node-version: ${{ matrix.node }}
+            - run: npm test
+prevention:
+  - "Always explicitly set fail-fast: false when you want all matrix combinations to run — for example when building cross-platform or cross-version compatibility matrices"
+  - "The default fail-fast: true is intentional for workflows where you only care about any single failure (saves CI minutes), but must be changed when you need full failure visibility"
+  - "If matrix jobs are silently cancelled and show no error output, check whether fail-fast: true (or its absence — the default) is the cause"
+docs:
+  - url: "https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategyfail-fast"
+    label: "jobs.<job_id>.strategy.fail-fast documentation"
+  - url: "https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix"
+    label: "Matrix strategy documentation"

package/errors/silent-failures/silent-failures-084.yml

@@ -0,0 +1,96 @@
+id: silent-failures-084
+title: "github.sha on pull_request event is the ephemeral merge commit SHA, not the PR head commit"
+category: silent-failures
+severity: silent-failure
+tags:
+  - github-sha
+  - pull_request
+  - merge-commit
+  - docker
+  - tagging
+  - status-checks
+patterns:
+  - regex: '\$\{\{\s*github\.sha\s*\}\}'
+    flags: 'i'
+  - regex: 'github\.sha'
+    flags: 'i'
+error_messages:
+  - "Docker image tagged with SHA not found in git history"
+  - "Deployment status does not appear on the PR commit"
+  - "Commit status check not visible on pull request"
+root_cause: |
+  On `pull_request` events, `github.sha` is NOT the PR branch's head commit SHA. It is
+  the SHA of a temporary merge commit that GitHub creates automatically to simulate
+  "what would happen if this PR were merged right now." This ephemeral merge commit:
+
+  - Does NOT appear in the repository's git history
+  - Changes every time the base branch advances, even with no new PR commits
+  - Is not accessible via normal git operations outside the workflow run
+
+  Consequences developers hit in the wild:
+  - Docker images tagged with `github.sha` have tags that don't correspond to any real
+    commit, making rollbacks and tracing impossible
+  - Commit status checks or deployment markers posted to `github.sha` don't appear on
+    any commit in the PR and are effectively invisible to reviewers
+  - Scripts that fetch the commit from the API using github.sha return 404
+
+  The actual PR head commit SHA is available via `github.event.pull_request.head.sha`.
+fix: |
+  Use `github.event.pull_request.head.sha` to get the actual PR head commit on
+  pull_request events. For workflows triggered by both push and pull_request, use a
+  conditional to select the correct SHA per event type.
+fix_code:
+  - language: yaml
+    label: "Get the correct SHA for both push and pull_request events"
+    code: |
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+
+            - name: Resolve commit SHA
+              id: sha
+              run: |
+                if [ "${{ github.event_name }}" = "pull_request" ]; then
+                  echo "value=${{ github.event.pull_request.head.sha }}" >> $GITHUB_OUTPUT
+                else
+                  echo "value=${{ github.sha }}" >> $GITHUB_OUTPUT
+                fi
+
+            - name: Tag Docker image with correct SHA
+              run: |
+                docker build -t myapp:${{ steps.sha.outputs.value }} .
+                docker push myapp:${{ steps.sha.outputs.value }}
+  - language: yaml
+    label: "Post commit status to the correct PR head SHA"
+    code: |
+      on:
+        pull_request:
+
+      jobs:
+        status:
+          runs-on: ubuntu-latest
+          steps:
+            - name: Post status to actual PR commit
+              uses: actions/github-script@v7
+              with:
+                script: |
+                  // Use PR head SHA, not github.sha (merge commit)
+                  await github.rest.repos.createCommitStatus({
+                    owner: context.repo.owner,
+                    repo: context.repo.repo,
+                    sha: context.payload.pull_request.head.sha,
+                    state: 'success',
+                    description: 'Build passed',
+                    context: 'ci/build'
+                  });
+prevention:
+  - "Never tag Docker images or create commit statuses using github.sha on pull_request events — use github.event.pull_request.head.sha for the real PR head"
+  - "If deployment statuses or commit checks are missing from PR commits, verify you are not posting them to github.sha (the merge commit)"
+  - "The merge commit SHA changes every time the base branch gets new commits, even without new PR activity — this makes github.sha unstable for artifact tagging on PRs"
+docs:
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#pull_request"
+    label: "pull_request event — note on github.sha merge commit"
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#github-context"
+    label: "GitHub context — sha property"

package/errors/silent-failures/silent-failures-085.yml

@@ -0,0 +1,69 @@
+id: silent-failures-085
+title: 'actions/checkout does not initialize submodules by default — empty submodule directories silently break builds'
+category: silent-failures
+severity: silent-failure
+tags:
+  - checkout
+  - submodules
+  - git-submodule
+  - empty-directory
+  - build-failure
+patterns:
+  - regex: 'fatal: not a git repository'
+    flags: 'i'
+  - regex: 'No such file or directory'
+    flags: 'i'
+  - regex: 'cannot open.*No such file or directory'
+    flags: 'i'
+error_messages:
+  - 'fatal: not a git repository (or any of the parent directories): .git'
+  - 'CMake Error: The source directory "/home/runner/work/repo/vendor/lib" does not appear to contain CMakeLists.txt.'
+  - 'error: cannot open include file: ../vendor/lib/include/lib.h: No such file or directory'
+root_cause: |
+  actions/checkout defaults to submodules: false, meaning any Git submodules
+  defined in .gitmodules are NOT cloned — they appear as empty directories in the
+  workspace. There is no warning or error in the checkout step output; it completes
+  successfully with exit code 0.
+
+  Downstream build steps that depend on submodule content then fail with generic
+  "file not found" or "not a git repository" errors that point to the submodule
+  directory, not to the checkout configuration. This mismatch between where the error
+  appears (the build step) and its root cause (the checkout step) makes it
+  time-consuming to diagnose, especially for contributors unfamiliar with the repo's
+  submodule structure.
+
+  Affected scenarios include:
+  - CMake projects with vendored dependencies as submodules
+  - Projects using git submodule for shared library code
+  - Repos with submodules for test fixtures or documentation themes
+fix: |
+  Add submodules: true (or submodules: 'recursive' for nested submodules) to your
+  actions/checkout step. For private submodules, you may also need to set
+  token: with a PAT that has access to the submodule repositories — the default
+  GITHUB_TOKEN only has access to the current repository.
+fix_code:
+  - language: yaml
+    label: 'Initialize submodules during checkout'
+    code: |
+      - uses: actions/checkout@v4
+        with:
+          submodules: true          # 'true' for one level, 'recursive' for nested
+          # For private submodule repos, provide a PAT with access:
+          # token: ${{ secrets.SUBMODULE_PAT }}
+  - language: yaml
+    label: 'Recursive submodules for nested submodule trees'
+    code: |
+      - uses: actions/checkout@v4
+        with:
+          submodules: 'recursive'
+          fetch-depth: 0            # Full history if submodule pinning requires it
+prevention:
+  - 'Add submodules: true to actions/checkout in all workflows that build code depending on submodule content'
+  - 'Add a verification step after checkout to confirm critical submodule paths are non-empty: test -f vendor/lib/README.md'
+  - 'Document submodule requirements in your repo README and CONTRIBUTING.md'
+  - 'If the submodule repo is private, use a GitHub App token or fine-grained PAT — the default GITHUB_TOKEN cannot access other repositories'
+docs:
+  - url: 'https://github.com/actions/checkout#usage'
+    label: 'actions/checkout — submodules input reference'
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/using-submodules-in-workflows'
+    label: 'Using submodules in GitHub Actions workflows'

package/errors/triggers/triggers-060.yml

@@ -0,0 +1,86 @@
+id: triggers-060
+title: 'pull_request workflow not re-triggered when PR title or description is edited'
+category: triggers
+severity: silent-failure
+tags:
+  - pull_request
+  - edited
+  - pr-title
+  - types
+  - conventional-commits
+  - status-check
+patterns:
+  - regex: 'on:\s*\n\s*pull_request:\s*\n(?:(?!\s*types:).*\n)*'
+    flags: 'ms'
+error_messages: []
+root_cause: |
+  The default pull_request event types are [opened, synchronize, reopened]. The
+  "edited" activity type — which fires when the PR title, body, or base branch is
+  changed — is NOT included in the default set. Workflows that validate PR titles
+  (e.g., enforcing Conventional Commits format, ticket-number requirements, or length
+  limits) will never re-run when a contributor fixes the PR title after an initial
+  failure.
+
+  This creates a persistent UX problem: the required status check shows as failed
+  after the title is corrected, and the PR cannot be merged without manually
+  re-running the workflow or pushing a new commit. The fix is visible in the GitHub
+  UI and source, but the root cause is non-obvious — nothing in the failure log
+  indicates the workflow won't respond to a title edit.
+fix: |
+  Add "edited" to the pull_request types list for any workflow that validates PR
+  metadata (title, description, or target branch). The "edited" type also fires on
+  body changes and base branch changes, which is typically harmless for title-checking
+  workflows. Do not add "edited" to workflows that trigger expensive CI operations
+  unless you intend them to run on every title/body change.
+fix_code:
+  - language: yaml
+    label: 'Add edited type to re-run on PR title changes'
+    code: |
+      on:
+        pull_request:
+          types:
+            - opened
+            - synchronize
+            - reopened
+            - edited  # Re-run when PR title or description is changed
+
+      jobs:
+        lint-pr-title:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: amannn/action-semantic-pull-request@v5
+              env:
+                GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+  - language: yaml
+    label: 'Conditional execution — only validate title on edited events'
+    code: |
+      on:
+        pull_request:
+          types: [opened, synchronize, reopened, edited]
+
+      jobs:
+        check-title:
+          runs-on: ubuntu-latest
+          steps:
+            - name: Validate PR title format
+              if: >
+                github.event_name == 'pull_request' &&
+                (github.event.action == 'opened' ||
+                 github.event.action == 'edited' ||
+                 github.event.action == 'reopened')
+              run: |
+                TITLE="${{ github.event.pull_request.title }}"
+                if ! echo "$TITLE" | grep -qP '^(feat|fix|docs|chore|refactor|test|ci)(\(.+\))?: .+'; then
+                  echo "PR title does not follow Conventional Commits format: $TITLE"
+                  exit 1
+                fi
+prevention:
+  - 'Always include "edited" in pull_request types when the workflow validates PR title or description format'
+  - 'Test that your PR title validation workflow re-runs when you edit the title — do not assume it does'
+  - 'Document required PR title format in CONTRIBUTING.md so contributors know title edits (not just new commits) trigger re-checks'
+  - 'Consider adding a job summary or annotation with the exact format requirement when validation fails'
+docs:
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#pull_request'
+    label: 'pull_request event — activity types reference'
+  - url: 'https://github.com/amannn/action-semantic-pull-request'
+    label: 'action-semantic-pull-request (popular PR title lint action)'

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

@@ -0,0 +1,87 @@
+id: yaml-syntax-056
+title: "env context unavailable inside with: inputs of uses: steps"
+category: yaml-syntax
+severity: error
+tags:
+  - env-context
+  - with-inputs
+  - uses
+  - expression-context
+  - action-inputs
+patterns:
+  - regex: "Unrecognized named-value: 'env'"
+    flags: 'i'
+  - regex: 'Invalid workflow file.*Unrecognized named-value'
+    flags: 'i'
+error_messages:
+  - "Unrecognized named-value: 'env'. Located at position 1 within expression: env.MY_VAR"
+  - "Invalid workflow file: .github/workflows/ci.yml (Line 14, Col 15): Unrecognized named-value: 'env'"
+  - "The workflow is not valid. .github/workflows/build.yml: Unrecognized named-value: 'env'"
+root_cause: |
+  The `env` context is NOT available inside the `with:` input block of a `uses:` step.
+  GitHub Actions evaluates `uses:` step inputs using a restricted set of contexts, and
+  `env` is explicitly excluded because env var values may depend on previous step
+  outputs (which are also unavailable at `with:` evaluation time).
+
+  Contexts available in `with:` inputs: `github`, `needs`, `strategy`, `matrix`,
+  `secrets`, `inputs`, `vars`, and `steps` (but only from previously completed steps).
+  The `env` context, `runner` context, and job-level env vars are all unavailable.
+
+  This catches developers who define env vars at the workflow or job level and then try
+  to pass them as action inputs, which fails with "Unrecognized named-value: 'env'".
+fix: |
+  Three options:
+  1. Reference the value directly (hardcoded or via a different supported context)
+  2. Use `vars` context (repository/org variables) — available in `with:` blocks
+  3. Capture the env value in a prior step's GITHUB_OUTPUT and reference it via
+     `steps.<id>.outputs.<name>` in the subsequent `uses:` step
+fix_code:
+  - language: yaml
+    label: "Wrong: env context in with: inputs (causes parse error)"
+    code: |
+      env:
+        API_URL: https://api.example.com
+
+      jobs:
+        deploy:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: my-org/deploy-action@v1
+              with:
+                url: ${{ env.API_URL }}   # ERROR: Unrecognized named-value: 'env'
+  - language: yaml
+    label: "Fix option A: use vars context (repository variable)"
+    code: |
+      # Set API_URL as a repository variable in Settings > Secrets and variables > Variables
+      jobs:
+        deploy:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: my-org/deploy-action@v1
+              with:
+                url: ${{ vars.API_URL }}   # vars context IS available in with:
+  - language: yaml
+    label: "Fix option B: capture in prior step output, reference via steps context"
+    code: |
+      env:
+        API_URL: https://api.example.com
+
+      jobs:
+        deploy:
+          runs-on: ubuntu-latest
+          steps:
+            - id: config
+              run: echo "api_url=$API_URL" >> $GITHUB_OUTPUT
+
+            - uses: my-org/deploy-action@v1
+              with:
+                url: ${{ steps.config.outputs.api_url }}   # steps context IS available
+prevention:
+  - "In with: inputs, only use: github, needs, strategy, matrix, secrets, inputs, vars, and steps (from prior completed steps) — never env or runner"
+  - "For static configuration values, prefer repository variables (vars context) over env — vars are available everywhere env is not"
+  - "If you need a dynamically computed value (from a script or env var) in a with: block, capture it to GITHUB_OUTPUT in a prior step and reference via steps.<id>.outputs"
+docs:
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#context-availability"
+    label: "Context availability table — which contexts are valid per syntax location"
+  - url: "https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#jobsjob_idstepswith"
+    label: "jobs.<job_id>.steps[*].with syntax documentation"

package/package.json

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