@htekdev/actions-debugger 1.0.5 → 1.0.7

package/errors/caching-artifacts/cache-10gb-limit-eviction.yml

@@ -0,0 +1,135 @@
+id: caching-artifacts-011
+title: "Repository Cache Storage Limit (10 GB) — Silent Eviction Causes Cache Miss Spike"
+category: caching-artifacts
+severity: silent-failure
+tags:
+  - cache
+  - storage-limit
+  - eviction
+  - cache-miss
+  - actions/cache
+  - 10gb
+  - lru
+patterns:
+  - regex: "cache.*evict|evict.*cache"
+    flags: "i"
+  - regex: "cache size.*limit|limit.*cache size"
+    flags: "i"
+  - regex: "exceeds.*10.*GB|10.*GB.*limit"
+    flags: "i"
+  - regex: "cache.*storage.*limit.*exceeded"
+    flags: "i"
+error_messages:
+  - "Cache entry is too big. Maximum cache size is 10GB"
+  - "Warning: Cache size of XY GB (ZZZZ MB) is over the 10 GB limit, so some older caches will be removed"
+  - "Failed to save cache entry. Exiting with error: Cache storage quota has been reached for the current repository"
+root_cause: |
+  GitHub limits the total Actions cache storage per repository to **10 GB**. When the
+  10 GB limit is reached, GitHub automatically evicts the **least-recently-used (LRU)**
+  cache entries to make room for new ones. Additionally, cache entries that have not been
+  accessed in **7 days** are automatically deleted.
+
+  **This is a silent failure** because:
+  - Eviction happens asynchronously — the job that triggers eviction does not fail.
+  - The workflow that was relying on an evicted cache simply gets a cache miss on the
+    next run and reinstalls from scratch, adding minutes to build time.
+  - There is no notification, no warning in the workflow log, and no failed check.
+  - Engineers often diagnose this as a "flaky cache" without realizing the 10 GB limit
+    is being hit regularly.
+
+  **Common causes of limit exhaustion:**
+  1. **Matrix builds with many OS/version combinations** each storing large dependency
+     caches (node_modules, .cargo, ~/.gradle, etc.).
+  2. **Large monorepo caches** where the entire dependency tree exceeds 10 GB.
+  3. **Docker layer caches** stored via `actions/cache` for repeated builds.
+  4. **Accumulation without cleanup** — cache keys rotate on every dependency update
+     but old entries aren't explicitly purged.
+
+  **How to check current cache usage:**
+  Repository → Actions → Management → Caches (or via `gh cache list --repo owner/repo`).
+fix: |
+  Reduce total cache storage by improving cache key strategy and explicitly pruning old
+  cache entries.
+
+  **Immediate steps:**
+  1. Audit current cache usage with `gh cache list --repo owner/repo --sort size --order desc`
+  2. Delete oversized or stale entries with `gh cache delete <id> --repo owner/repo`
+  3. Review matrix build cache keys — large matrices with OS+version combinations
+     multiply cache storage proportionally.
+
+  **Structural fixes:**
+  - Use more specific cache keys to avoid storing redundant versions.
+  - Split large caches into smaller focused caches (dependencies vs. build outputs).
+  - Add a periodic workflow to prune old caches before the limit is reached.
+  - For Docker layer caches, consider using GitHub Container Registry or a dedicated
+    cache registry instead of Actions cache.
+fix_code:
+  - language: yaml
+    label: "Check cache usage and delete stale entries in a workflow"
+    code: |
+      jobs:
+        cleanup-caches:
+          runs-on: ubuntu-latest
+          steps:
+            - name: List and clean old caches
+              env:
+                GH_TOKEN: ${{ github.token }}
+              run: |
+                # List all caches sorted by last accessed time (oldest first)
+                gh cache list \
+                  --repo ${{ github.repository }} \
+                  --sort last-accessed \
+                  --order asc \
+                  --limit 100 \
+                  --json id,key,sizeInBytes,lastAccessedAt \
+                  | jq -r '.[] | "\(.id)\t\(.sizeInBytes)\t\(.lastAccessedAt)\t\(.key)"'
+  - language: yaml
+    label: "Prune caches older than N days using the Actions API"
+    code: |
+      jobs:
+        prune-caches:
+          runs-on: ubuntu-latest
+          permissions:
+            actions: write
+          steps:
+            - name: Delete caches not accessed in 5 days
+              env:
+                GH_TOKEN: ${{ github.token }}
+                REPO: ${{ github.repository }}
+              run: |
+                CUTOFF=$(date -d '5 days ago' --iso-8601=seconds)
+                gh api "repos/$REPO/actions/caches" \
+                  --paginate \
+                  --jq ".actions_caches[] | select(.last_accessed_at < \"$CUTOFF\") | .id" \
+                | xargs -I{} gh api --method DELETE "repos/$REPO/actions/caches/{}"
+  - language: yaml
+    label: "Optimize matrix builds to share a single cache entry"
+    code: |
+      jobs:
+        build:
+          strategy:
+            matrix:
+              os: [ubuntu-latest, windows-latest, macos-latest]
+              node: ['18', '20', '22']
+          runs-on: ${{ matrix.os }}
+          steps:
+            - uses: actions/cache@v4
+              with:
+                path: ~/.npm
+                # Share cache across Node versions — hash only package-lock.json
+                key: npm-${{ runner.os }}-${{ hashFiles('**/package-lock.json') }}
+                restore-keys: npm-${{ runner.os }}-
+prevention:
+  - "Monitor total cache usage regularly with `gh cache list --repo owner/repo` or the GitHub UI (Actions → Caches) — set up an alert when approaching 8 GB."
+  - "Add a weekly scheduled workflow that prunes caches older than 5-7 days to stay well under the 10 GB limit."
+  - "Use `actions: write` permission and the REST API to manage caches programmatically as part of your CI housekeeping."
+  - "Design cache keys to be OS-specific but NOT dependency-version-specific where possible — this reduces the number of unique cache entries stored simultaneously."
+  - "For Docker layer caches, prefer GitHub Container Registry or an external caching service to avoid eating into the 10 GB Actions cache budget."
+  - "Check for cache key patterns that change too frequently (e.g., including `github.run_id`) — these create orphaned entries that accumulate until evicted."
+docs:
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/caching-dependencies-to-speed-up-workflows#usage-limits-and-eviction-policy"
+    label: "GitHub Docs: Cache usage limits and eviction policy"
+  - url: "https://docs.github.com/en/rest/actions/cache?apiVersion=2022-11-28"
+    label: "GitHub REST API: Actions cache endpoints"
+  - url: "https://github.com/actions/cache/blob/main/tips-and-workarounds.md"
+    label: "actions/cache: Tips and workarounds"

package/errors/runner-environment/dockerhub-pull-rate-limit.yml

@@ -0,0 +1,125 @@
+id: runner-environment-024
+title: "Docker Hub Pull Rate Limit — toomanyrequests in GitHub Actions"
+category: runner-environment
+severity: error
+tags:
+  - docker
+  - docker-hub
+  - rate-limit
+  - container
+  - pull
+  - authentication
+patterns:
+  - regex: "toomanyrequests: You have reached your pull rate limit"
+    flags: "i"
+  - regex: "You have reached your unauthenticated pull rate limit"
+    flags: "i"
+  - regex: "pull rate limit reached"
+    flags: "i"
+  - regex: "ERROR: toomanyrequests"
+    flags: "i"
+  - regex: "429 Too Many Requests.*docker"
+    flags: "i"
+error_messages:
+  - "toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit"
+  - "Error response from daemon: toomanyrequests: You have reached your unauthenticated pull rate limit."
+  - "pull access denied, repository does not exist or may require 'docker login'"
+root_cause: |
+  Docker Hub enforces anonymous pull rate limits on all IP addresses. GitHub-hosted
+  runners share a pool of egress IPs — multiple concurrent workflow runs from different
+  repositories hit Docker Hub from the same IP address, exhausting the shared quota
+  rapidly.
+
+  **Rate limit tiers (as of 2024):**
+  - **Unauthenticated (anonymous):** 100 pulls per 6 hours per IP
+  - **Authenticated free account:** 200 pulls per 6 hours per account
+  - **Docker Hub Pro/Team/Business:** unlimited
+
+  Because GitHub-hosted runners use a small set of shared egress IPs, popular runners
+  can hit the anonymous 100-pull limit within minutes during peak hours. The error
+  surfaces as a hard failure when the runner attempts `docker pull` for job containers,
+  service containers, container actions, or explicit `docker pull` commands in steps.
+
+  Even after adding `docker/login-action`, workflows can still hit the limit if they use
+  actions that internally pull images (e.g., `docker/build-push-action`, `docker/bake-action`)
+  before the login step has executed.
+fix: |
+  Add `docker/login-action` as the **first step** in any job that pulls from Docker Hub.
+  The action authenticates with Docker Hub, switching from anonymous to authenticated rate
+  limits (200 pulls/6 hours per account) or unlimited for Pro/Team accounts.
+
+  **Recommended approach:**
+  1. Create a Docker Hub account (free tier) or use an existing one.
+  2. Store credentials as repository secrets: `DOCKERHUB_USERNAME` and `DOCKERHUB_TOKEN`
+     (use an Access Token, not your password — generate at hub.docker.com > Account Settings > Security).
+  3. Add the login step before any image-pulling step.
+
+  **For self-hosted runners:** Configure a Docker Hub mirror or use GitHub Packages /
+  Amazon ECR / Google Artifact Registry to cache images and avoid Docker Hub entirely.
+fix_code:
+  - language: yaml
+    label: "Authenticate with Docker Hub before pulling images"
+    code: |
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          steps:
+            # Login FIRST — before any step that pulls from Docker Hub
+            - name: Log in to Docker Hub
+              uses: docker/login-action@v3
+              with:
+                username: ${{ secrets.DOCKERHUB_USERNAME }}
+                password: ${{ secrets.DOCKERHUB_TOKEN }}
+
+            - uses: actions/checkout@v4
+
+            - name: Build and push
+              uses: docker/build-push-action@v5
+              with:
+                push: true
+                tags: myorg/myimage:latest
+  - language: yaml
+    label: "Authenticate for jobs using a container image"
+    code: |
+      jobs:
+        test:
+          runs-on: ubuntu-latest
+          container:
+            image: python:3.12
+            credentials:
+              username: ${{ secrets.DOCKERHUB_USERNAME }}
+              password: ${{ secrets.DOCKERHUB_TOKEN }}
+          steps:
+            - uses: actions/checkout@v4
+            - run: python -m pytest
+  - language: yaml
+    label: "Authenticate for service containers pulling from Docker Hub"
+    code: |
+      jobs:
+        test:
+          runs-on: ubuntu-latest
+          services:
+            postgres:
+              image: postgres:16
+              credentials:
+                username: ${{ secrets.DOCKERHUB_USERNAME }}
+                password: ${{ secrets.DOCKERHUB_TOKEN }}
+              env:
+                POSTGRES_PASSWORD: postgres
+          steps:
+            - uses: actions/checkout@v4
+prevention:
+  - "Store a Docker Hub access token (not password) in secrets and use docker/login-action@v3 in all jobs that pull images."
+  - "Place the docker/login-action step first in the job — before any action that internally pulls Docker Hub images."
+  - "Consider mirroring frequently-used base images to GitHub Container Registry (ghcr.io) or your cloud provider's registry to eliminate Docker Hub dependency."
+  - "Use Docker Hub's Automated Builds or a scheduled workflow to keep mirror images up to date."
+  - "For service containers and job containers, always provide `credentials:` block alongside `image:` when pulling from Docker Hub."
+docs:
+  - url: "https://docs.docker.com/docker-hub/download-rate-limit/"
+    label: "Docker Hub: Download rate limit documentation"
+  - url: "https://github.com/docker/login-action"
+    label: "docker/login-action — GitHub Marketplace"
+  - url: "https://docs.github.com/en/actions/use-cases-and-examples/publishing-packages/publishing-docker-images"
+    label: "GitHub Docs: Publishing Docker images"
+  - url: "https://github.com/actions/runner-images/issues/1445"
+    label: "actions/runner-images #1445 — Did Docker Hub rate limit affect GitHub Action?"

package/errors/runner-environment/service-container-localhost-vs-hostname.yml

@@ -0,0 +1,130 @@
+id: runner-environment-025
+title: "Service Container Network: localhost Works on Runner, Service Name Required in Container Jobs"
+category: runner-environment
+severity: error
+tags:
+  - service-containers
+  - networking
+  - localhost
+  - postgres
+  - mysql
+  - redis
+  - container-jobs
+  - docker-networking
+patterns:
+  - regex: "Connection refused.*(?:localhost|127\\.0\\.0\\.1).*(?:5432|3306|6379|27017)"
+    flags: "i"
+  - regex: "could not connect to server.*Connection refused.*localhost"
+    flags: "i"
+  - regex: "ECONNREFUSED.*(?:5432|3306|6379|27017)"
+    flags: "i"
+  - regex: "dial tcp 127\\.0\\.0\\.1:\\d+: connect: connection refused"
+    flags: "i"
+error_messages:
+  - "Error: connect ECONNREFUSED 127.0.0.1:5432"
+  - "could not connect to server: Connection refused (Is the server running on host \"localhost\" (127.0.0.1) and accepting TCP/IP connections on port 5432?)"
+  - "OperationalError: connection to server at \"localhost\" (127.0.0.1), port 5432 failed: Connection refused"
+  - "Error: getaddrinfo ENOTFOUND postgres"
+root_cause: |
+  GitHub Actions service containers run as Docker containers on the runner machine.
+  The correct hostname to reach them depends on **how the job itself runs**:
+
+  **Scenario A — Job runs directly on the runner (no `container:` key):**
+  The runner process runs natively on the VM. Docker maps service container ports to the
+  runner's loopback interface. Services are reachable at `localhost:<mapped_port>`.
+  Using the service name (e.g. `postgres`) as a hostname will **fail** with ENOTFOUND.
+
+  **Scenario B — Job runs inside a container (`container:` key present):**
+  Both the job container and service containers are on the same Docker user-defined network.
+  Docker's built-in DNS resolves container names. Services are reachable by their
+  **service name** (e.g. `postgres`, `redis`) as the hostname, NOT `localhost`.
+  Using `localhost` here will produce "Connection refused" because the service port is
+  not bound to the job container's loopback interface.
+
+  This asymmetry is the root of most service container connectivity bugs:
+  developers copy a working non-containerized workflow config into a containerized job
+  (or vice versa) without updating the hostname.
+
+  Additionally, when using `ports:` mapping in service definitions, the runner maps the
+  container port to a randomly assigned host port (unless pinned with `host:container`
+  syntax). The `${{ job.services.postgres.ports['5432'] }}` expression returns the
+  actual host-side port, which may differ from 5432.
+fix: |
+  **For jobs running directly on the runner (no `container:` key):**
+  Connect to services via `localhost` (or `127.0.0.1`) and the mapped port.
+  Use `${{ job.services.<service>.ports['<container_port>'] }}` to get the dynamic host port
+  when not using explicit port pinning.
+
+  **For jobs running in a container (`container:` key):**
+  Connect to services via the **service name** as the hostname and the container's
+  internal port directly. No port mapping is required — both containers share the same
+  Docker network and communicate directly.
+
+  Use the `options: --add-host` trick only if you need the same workflow YAML to work
+  in both contexts (rare — avoid this complexity).
+fix_code:
+  - language: yaml
+    label: "Correct connectivity for a runner-native job (no container:)"
+    code: |
+      jobs:
+        test:
+          runs-on: ubuntu-latest
+          # No 'container:' key — job runs directly on the runner VM
+          services:
+            postgres:
+              image: postgres:16
+              env:
+                POSTGRES_PASSWORD: postgres
+              ports:
+                - 5432:5432    # pin host:container port for simplicity
+              options: >-
+                --health-cmd pg_isready
+                --health-interval 10s
+                --health-timeout 5s
+                --health-retries 5
+          steps:
+            - uses: actions/checkout@v4
+            - name: Run tests
+              env:
+                # Use localhost — runner-native job maps service ports to loopback
+                DATABASE_URL: postgres://postgres:postgres@localhost:5432/testdb
+              run: npm test
+  - language: yaml
+    label: "Correct connectivity for a containerized job (container: key present)"
+    code: |
+      jobs:
+        test:
+          runs-on: ubuntu-latest
+          container:
+            image: node:20  # Job itself runs inside a container
+          services:
+            postgres:
+              image: postgres:16
+              env:
+                POSTGRES_PASSWORD: postgres
+              # NO ports: mapping needed — containers share the Docker network
+              options: >-
+                --health-cmd pg_isready
+                --health-interval 10s
+                --health-timeout 5s
+                --health-retries 5
+          steps:
+            - uses: actions/checkout@v4
+            - name: Run tests
+              env:
+                # Use service NAME "postgres" — Docker DNS resolves it within the network
+                DATABASE_URL: postgres://postgres:postgres@postgres:5432/testdb
+              run: npm test
+prevention:
+  - "When your job uses `container:`, always connect to services via the service name (e.g. `postgres`, `redis`), NOT `localhost`."
+  - "When your job runs natively (no `container:`), always connect to services via `localhost` and the mapped host port."
+  - "Use `options: --health-cmd / --health-interval / --health-retries` on service containers to ensure they are ready before steps execute."
+  - "Avoid using `localhost` as the database hostname in connection strings — parameterize it so the same code works in both runner-native and containerized jobs."
+  - "If you move a job from runner-native to containerized (or vice versa), always audit all service hostnames in env variables and connection strings."
+docs:
+  - url: "https://docs.github.com/en/actions/use-cases-and-examples/using-containerized-services/about-service-containers"
+    label: "GitHub Docs: About service containers"
+  - url: "https://docs.github.com/en/actions/use-cases-and-examples/using-containerized-services/creating-postgresql-service-containers"
+    label: "GitHub Docs: Creating PostgreSQL service containers"
+  - url: "https://docs.github.com/en/actions/use-cases-and-examples/using-containerized-services/creating-redis-service-containers"
+    label: "GitHub Docs: Creating Redis service containers"

package/errors/runner-environment/setup-python-cache-no-dependency-file.yml

@@ -0,0 +1,126 @@
+id: runner-environment-027
+title: "actions/setup-python cache Fails — No Dependency File Found for pip/poetry/pipenv"
+category: runner-environment
+severity: error
+tags:
+  - setup-python
+  - cache
+  - pip
+  - poetry
+  - pipenv
+  - cache-dependency-path
+  - requirements.txt
+  - pyproject.toml
+patterns:
+  - regex: "No file.*found for the supported package managers"
+    flags: "i"
+  - regex: "Error: No file in .* found for the supported package managers"
+    flags: "i"
+  - regex: "setup-python.*cache.*dependency.*not found"
+    flags: "i"
+  - regex: "dependencies were not found for the cache-dependency-path"
+    flags: "i"
+  - regex: "Could not find .* in .*requirements"
+    flags: "i"
+error_messages:
+  - "Error: No file in /home/runner/work/my-repo/my-repo found for the supported package managers (pip, pipenv, poetry), file patterns (requirements*.txt, Pipfile.lock, poetry.lock)"
+  - "Error: No file in /home/runner/work found for the supported package managers (pip), file patterns (requirements*.txt)"
+  - "dependencies were not found for the cache-dependency-path input"
+root_cause: |
+  When `actions/setup-python` is configured with `cache: 'pip'` (or `'poetry'` /
+  `'pipenv'`), it looks for a dependency lockfile to use as the cache key. The action
+  searches the repository for these file patterns:
+
+  | Cache type | File patterns searched                             |
+  |------------|---------------------------------------------------|
+  | `pip`      | `requirements*.txt`, `requirements/*.txt`         |
+  | `poetry`   | `poetry.lock`                                     |
+  | `pipenv`   | `Pipfile.lock`                                    |
+
+  If no matching file is found (either because the project uses a non-standard layout,
+  the file has a custom name, or the lockfile is gitignored), the action fails with this
+  error.
+
+  **Common causes:**
+  1. **Non-standard requirements file name**: `deps.txt`, `dev-requirements.txt` (outside
+     `requirements*.txt` glob), or stored in a subdirectory not matching the search path.
+  2. **pyproject.toml without poetry.lock**: Modern Python projects using `pyproject.toml`
+     with pip or flit don't generate a lockfile by default.
+  3. **Monorepo layout**: The requirements file is in a subdirectory (e.g.,
+     `backend/requirements.txt`) but the default search is from the repo root.
+  4. **Gitignored lockfiles**: `poetry.lock` or `Pipfile.lock` is in `.gitignore`, so
+     setup-python can't find it on the runner.
+
+  The `cache-dependency-path` input was added (actions/setup-python #361) to address
+  non-standard layouts, but is often overlooked in workflow templates.
+fix: |
+  Set the `cache-dependency-path` input to point to your actual dependency file, or
+  ensure the file follows the default naming convention.
+
+  **Option 1 (preferred):** Use `cache-dependency-path` to specify the exact path or glob.
+  **Option 2:** Rename your requirements file to match the default patterns (`requirements.txt`
+  or `requirements-*.txt`).
+  **Option 3:** If you don't need caching, remove `cache:` from the setup-python step entirely.
+  **Option 4 (pyproject.toml):** If using pip with pyproject.toml, create a
+  `requirements.txt` (or use `pip-compile`) to generate a lockfile for cache keying.
+fix_code:
+  - language: yaml
+    label: "Specify custom requirements file path with cache-dependency-path"
+    code: |
+      - uses: actions/setup-python@v5
+        with:
+          python-version: '3.12'
+          cache: 'pip'
+          cache-dependency-path: |
+            backend/requirements.txt
+            backend/requirements-dev.txt
+  - language: yaml
+    label: "Use cache-dependency-path glob for monorepo with multiple requirements files"
+    code: |
+      - uses: actions/setup-python@v5
+        with:
+          python-version: '3.12'
+          cache: 'pip'
+          cache-dependency-path: '**/requirements*.txt'
+  - language: yaml
+    label: "Poetry project with explicit cache-dependency-path"
+    code: |
+      - uses: actions/setup-python@v5
+        with:
+          python-version: '3.12'
+          cache: 'poetry'
+          cache-dependency-path: 'pyproject/poetry.lock'
+  - language: yaml
+    label: "pyproject.toml project using pip — generate a lockfile for cache keying"
+    code: |
+      - uses: actions/setup-python@v5
+        with:
+          python-version: '3.12'
+          # No cache here — use actions/cache manually with hash of pyproject.toml
+      - uses: actions/cache@v4
+        with:
+          path: ~/.cache/pip
+          key: ${{ runner.os }}-pip-${{ hashFiles('**/pyproject.toml') }}
+          restore-keys: |
+            ${{ runner.os }}-pip-
+  - language: yaml
+    label: "Skip caching entirely when no lockfile exists"
+    code: |
+      - uses: actions/setup-python@v5
+        with:
+          python-version: '3.12'
+          # Omit 'cache:' entirely — no caching, no failure
+      - run: pip install -r deps.txt
+prevention:
+  - "Always set `cache-dependency-path` explicitly rather than relying on the default file search — it makes the workflow self-documenting and prevents surprises on rename."
+  - "Commit `poetry.lock` and `Pipfile.lock` to version control — these files serve as both the reproducible install spec and the cache key."
+  - "In monorepos, use a glob pattern like `**/requirements*.txt` to match files across subdirectories."
+  - "If pyproject.toml is your only dependency file, use `actions/cache@v4` directly with `hashFiles('pyproject.toml')` instead of setup-python's built-in cache."
+  - "Pin to `actions/setup-python@v5` or later — older versions have different cache file discovery behavior."
+docs:
+  - url: "https://github.com/actions/setup-python?tab=readme-ov-file#caching-packages-dependencies"
+    label: "actions/setup-python: Caching packages dependencies"
+  - url: "https://github.com/actions/setup-python/issues/361"
+    label: "actions/setup-python #361: Support cache-dependency-paths outside the current directory"
+  - 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/ubuntu-latest-to-24-04-migration.yml

@@ -0,0 +1,138 @@
+id: runner-environment-026
+title: "ubuntu-latest Switched to Ubuntu 24.04 — Breaks Python 3.8/3.9, System Packages, OpenSSL"
+category: runner-environment
+severity: error
+tags:
+  - ubuntu
+  - ubuntu-24.04
+  - runner-image
+  - python
+  - openssl
+  - apt
+  - migration
+  - breaking-change
+patterns:
+  - regex: "Unable to locate package python3\\.[89]"
+    flags: "i"
+  - regex: "python3\\.[89].*not found.*ubuntu.*24"
+    flags: "i"
+  - regex: "E: Package 'python3\\.[89]' has no installation candidate"
+    flags: "i"
+  - regex: "error.*openssl.*libssl1\\.1.*not available"
+    flags: "i"
+  - regex: "deadsnakes.*ppa.*focal.*not available.*noble"
+    flags: "i"
+  - regex: "ubuntu-latest.*ubuntu 24"
+    flags: "i"
+error_messages:
+  - "E: Package 'python3.8' has no installation candidate"
+  - "E: Package 'python3.9' has no installation candidate"
+  - "E: Package 'libssl1.1' has no installation candidate"
+  - "Error: The version '3.8' with architecture 'x64' was not found for Ubuntu 24.04"
+  - "Error: deadsnakes/ppa does not provide Python 3.8 packages for Ubuntu Noble (24.04)"
+root_cause: |
+  GitHub began rolling out Ubuntu 24.04 as the new target for `ubuntu-latest` on
+  **December 5, 2024**, completing the transition on **January 17, 2025** (tracked in
+  actions/runner-images #10636, 266 👍 reactions). Any workflow using `runs-on: ubuntu-latest`
+  without explicit version pinning now runs on Ubuntu 24.04 ("Noble Numbat") instead of 22.04.
+
+  **Key breaking changes in Ubuntu 24.04:**
+
+  1. **Python 3.8 and 3.9 are end-of-life and not available** — not via `apt` and not via
+     the `deadsnakes/ppa` PPA (which only backports for supported Ubuntu releases). Workflows
+     that `apt-get install python3.8` or use `setup-python` with version `3.8` or `3.9` fail.
+
+  2. **OpenSSL 1.1 removed** — Ubuntu 24.04 ships only OpenSSL 3.x. Packages and Python
+     versions that were compiled against OpenSSL 1.1 (`libssl1.1`) will fail to install or
+     run. This affects older Ruby gems, some Go binaries, and legacy pip packages.
+
+  3. **System Python is 3.12** — the `python3` system binary points to Python 3.12, which
+     may break scripts that relied on the 3.10 default in 22.04.
+
+  4. **`apt` package name changes** — some packages were renamed or split between 22.04 and
+     24.04 (e.g., `python3-distutils` is gone; functionality merged into `python3`).
+
+  5. **`/usr/bin/python` symlink absent by default** — workflows calling bare `python`
+     (not `python3`) fail with "python: command not found".
+fix: |
+  **Short-term — pin to ubuntu-22.04:**
+  Replace `runs-on: ubuntu-latest` with `runs-on: ubuntu-22.04` to freeze the runner image
+  while you migrate. Note: ubuntu-22.04 will eventually reach end-of-support (~April 2027).
+
+  **Long-term — migrate to supported Python/package versions:**
+  - Replace Python 3.8/3.9 with Python 3.10, 3.11, or 3.12 using `actions/setup-python`.
+    `actions/setup-python` downloads a pre-built binary from the tool cache — it works
+    regardless of the runner's system Python.
+  - Replace `libssl1.1` dependencies by upgrading the affected package to an OpenSSL-3
+    compatible version, or adding a compatibility shim if available.
+  - Replace bare `python` calls with `python3`.
+
+  **For `deadsnakes` PPA users:** `deadsnakes/ppa` only provides Python 3.8/3.9 for
+  Ubuntu 20.04 (Focal) and 22.04 (Jammy) — not 24.04 (Noble). There is no supported
+  workaround; upgrade to a supported Python version.
+fix_code:
+  - language: yaml
+    label: "Pin to ubuntu-22.04 as a short-term fix while migrating"
+    code: |
+      jobs:
+        test:
+          # Pin explicitly until Python 3.8/3.9 dependencies are upgraded
+          runs-on: ubuntu-22.04
+          steps:
+            - uses: actions/checkout@v4
+            - run: python3.9 -m pytest
+  - language: yaml
+    label: "Use actions/setup-python to install any Python version on ubuntu-latest"
+    code: |
+      jobs:
+        test:
+          runs-on: ubuntu-latest  # Now 24.04
+          steps:
+            - uses: actions/checkout@v4
+            - name: Set up Python
+              uses: actions/setup-python@v5
+              with:
+                # setup-python downloads pre-built binaries — works on any runner OS
+                python-version: '3.9'
+            - run: python --version  # 3.9.x from setup-python's tool cache
+            - run: pip install -r requirements.txt
+  - language: yaml
+    label: "Test matrix against multiple Python versions to find breakages early"
+    code: |
+      jobs:
+        test:
+          runs-on: ubuntu-latest
+          strategy:
+            matrix:
+              python-version: ['3.9', '3.10', '3.11', '3.12']
+          steps:
+            - uses: actions/checkout@v4
+            - uses: actions/setup-python@v5
+              with:
+                python-version: ${{ matrix.python-version }}
+            - run: pip install -r requirements.txt && pytest
+  - language: yaml
+    label: "Fix bare 'python' command not found on Ubuntu 24.04"
+    code: |
+      steps:
+        - name: Ensure python symlink exists
+          run: |
+            # Ubuntu 24.04 no longer creates /usr/bin/python by default
+            sudo ln -sf /usr/bin/python3 /usr/bin/python
+        # Or: use actions/setup-python which sets up the PATH correctly
+prevention:
+  - "Pin `runs-on: ubuntu-22.04` explicitly if your workflow depends on Python 3.8/3.9, libssl1.1, or other 22.04-specific packages."
+  - "Use `actions/setup-python@v5` to install a specific Python version instead of relying on `apt-get install python3.x` — it works across all Ubuntu versions."
+  - "When you upgrade Ubuntu runner versions, scan `apt-get install` lines in run steps for packages that may not exist in the new Ubuntu release."
+  - "Replace bare `python` invocations with `python3` or use `actions/setup-python` which adds an alias."
+  - "Test your workflows against `ubuntu-24.04` explicitly before `ubuntu-latest` changes, by running on both runner images in a matrix."
+  - "Subscribe to https://github.com/actions/runner-images/issues for announcements about upcoming `ubuntu-latest` image transitions."
+docs:
+  - url: "https://github.com/actions/runner-images/issues/10636"
+    label: "actions/runner-images #10636 — Ubuntu-latest workflows will use Ubuntu-24.04 image"
+  - url: "https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md"
+    label: "Ubuntu 24.04 runner image — installed software reference"
+  - url: "https://github.com/actions/setup-python"
+    label: "actions/setup-python — install any Python version on any runner"
+  - url: "https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources"
+    label: "GitHub Docs: Supported runners and hardware resources"

package/errors/silent-failures/github-output-multiline-truncated.yml

@@ -0,0 +1,112 @@
+id: silent-failures-011
+title: "GITHUB_OUTPUT Multiline Values Silently Truncated — Heredoc EOF Required"
+category: silent-failures
+severity: silent-failure
+tags:
+  - github-output
+  - multiline
+  - output
+  - heredoc
+  - truncation
+  - environment-files
+patterns:
+  - regex: "echo\\s+['\"]?\\w+=.*\\$\\([^)]+\\).*>>\\s+\\$GITHUB_OUTPUT"
+    flags: "i"
+  - regex: "invalid value.*GITHUB_OUTPUT.*contains newline"
+    flags: "i"
+  - regex: "Error: Unable to process file command 'output'"
+    flags: "i"
+  - regex: "GITHUB_OUTPUT.*multiline"
+    flags: "i"
+error_messages:
+  - "Error: Unable to process file command 'output' successfully."
+  - "Invalid format 'key=line1\\nline2' - value contains newline, use heredoc syntax"
+  - "Warning: Unexpected input(s) 'output', valid inputs are"
+root_cause: |
+  The `GITHUB_OUTPUT` environment file protocol (introduced November 2022 as a replacement
+  for the deprecated `::set-output` command) uses a line-based key=value format that does
+  NOT support literal newline characters in values when using simple `echo "key=value"` syntax.
+
+  When a step sets a multiline output using the naive approach:
+  ```bash
+  echo "REPORT=$(cat report.txt)" >> $GITHUB_OUTPUT
+  ```
+  the shell expands `$(cat report.txt)` into a multiline string, which is then written as:
+  ```
+  REPORT=line1
+  line2
+  line3
+  ```
+  The runner reads the first newline as end-of-value for `REPORT`, then tries to parse `line2`
+  as a new key=value entry (which fails silently or errors). The downstream step reading
+  `${{ steps.id.outputs.REPORT }}` receives only `line1` — or an empty string if the parser
+  rejects the entry entirely.
+
+  This is a **silent failure** because the workflow step itself does not fail — the `echo`
+  command exits successfully. The broken output only surfaces downstream, often as an empty
+  variable or a truncated value that's hard to trace back to the output-setting step.
+
+  The same issue affects `$GITHUB_ENV` for multiline environment variable values.
+fix: |
+  Use the **heredoc (multi-line delimiter) syntax** documented by GitHub for multiline values.
+  The format is:
+  ```
+  {name}<<{delimiter}
+  {value}
+  {delimiter}
+  ```
+  where `{delimiter}` is any string that does NOT appear in the value itself. `EOF` is the
+  conventional choice, but using a random string (e.g. `$(uuidgen)`) prevents injection
+  attacks if the value is untrusted.
+
+  **For `$GITHUB_ENV` multiline values:** use the identical heredoc pattern with `$GITHUB_ENV`.
+
+  **For JavaScript/TypeScript actions:** use `core.setOutput('name', value)` from
+  `@actions/core` — it handles serialization automatically and is not subject to this limitation.
+fix_code:
+  - language: yaml
+    label: "Correct multiline GITHUB_OUTPUT using heredoc EOF syntax"
+    code: |
+      - name: Set multiline output
+        id: report
+        run: |
+          # WRONG: echo "REPORT=$(cat report.txt)" >> $GITHUB_OUTPUT
+          # Correct: heredoc syntax
+          echo "REPORT<<EOF" >> $GITHUB_OUTPUT
+          cat report.txt >> $GITHUB_OUTPUT
+          echo "EOF" >> $GITHUB_OUTPUT
+
+      - name: Use multiline output
+        run: |
+          echo "${{ steps.report.outputs.REPORT }}"
+  - language: yaml
+    label: "Use random delimiter to prevent injection from untrusted content"
+    code: |
+      - name: Set multiline output safely
+        id: data
+        run: |
+          DELIMITER=$(openssl rand -hex 16)
+          echo "JSON_OUTPUT<<${DELIMITER}" >> $GITHUB_OUTPUT
+          curl -s https://api.example.com/data >> $GITHUB_OUTPUT
+          echo "${DELIMITER}" >> $GITHUB_OUTPUT
+  - language: yaml
+    label: "Multiline GITHUB_ENV using heredoc (same pattern)"
+    code: |
+      - name: Set multiline environment variable
+        run: |
+          echo "CHANGELOG<<EOF" >> $GITHUB_ENV
+          git log --oneline -10 >> $GITHUB_ENV
+          echo "EOF" >> $GITHUB_ENV
+prevention:
+  - "Never use `echo \"KEY=$(command)\" >> $GITHUB_OUTPUT` when the command output may span multiple lines."
+  - "Always use the heredoc EOF syntax for any output value that could contain newlines: `echo \"KEY<<EOF\" >> $GITHUB_OUTPUT && <value> >> $GITHUB_OUTPUT && echo \"EOF\" >> $GITHUB_OUTPUT`."
+  - "Use a random delimiter (`$(openssl rand -hex 16)`) instead of `EOF` when the value originates from untrusted input to prevent delimiter injection."
+  - "In JavaScript/TypeScript actions, use `@actions/core`'s `core.setOutput()` which handles serialization automatically."
+  - "Test multiline outputs locally with `act` or by printing `cat $GITHUB_OUTPUT` in a subsequent step to verify the full value was captured."
+docs:
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#multiline-strings"
+    label: "GitHub Docs: Workflow commands — Multiline strings"
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/passing-information-between-jobs"
+    label: "GitHub Docs: Passing information between jobs"
+  - url: "https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/"
+    label: "GitHub Changelog: Deprecating save-state and set-output commands"

package/errors/triggers/merge-group-trigger-missing.yml

@@ -0,0 +1,122 @@
+id: triggers-007
+title: "merge_group Trigger Missing — Required Checks Never Run in Merge Queue"
+category: triggers
+severity: silent-failure
+tags:
+  - merge_group
+  - merge-queue
+  - required-checks
+  - branch-protection
+  - triggers
+  - pull_request
+patterns:
+  - regex: "merge_group"
+    flags: "i"
+  - regex: "Expected.*Waiting.*merge queue"
+    flags: "i"
+  - regex: "merge queue.*required.*status check.*waiting"
+    flags: "i"
+error_messages:
+  - "Required check 'CI' is expected — Waiting"
+  - "All checks have passed except those that are waiting for merge queue"
+  - "The merge queue is waiting for the required check to pass"
+root_cause: |
+  GitHub's merge queue (enabled via branch protection rules → "Require merge queue")
+  creates a `merge_group` event when a PR is added to the queue. This event is distinct
+  from `pull_request` and `push` — a workflow must explicitly declare `on: merge_group:`
+  to receive it.
+
+  When a workflow is required by branch protection but does NOT include `merge_group`
+  as a trigger, the merge queue adds the PR to a temporary merge group branch (format:
+  `gh-readonly-queue/{base}/{pr-number}`) but the required workflow **never starts**.
+  GitHub shows the required check as "Expected — Waiting" indefinitely, and the PR
+  cannot merge.
+
+  **Why this is subtle:**
+  - The workflow runs fine for normal `pull_request` events (dev branch → PR, all checks
+    pass).
+  - The failure only manifests once the PR is actually added to the merge queue.
+  - The "Waiting" status in the merge queue looks different from a failed check, making
+    it unclear that the workflow trigger is misconfigured.
+
+  **The merge_group event payload** is slightly different from `pull_request`:
+  - `github.event.merge_group.base_ref` — the base branch
+  - `github.event.merge_group.head_sha` — the merged commit SHA to test
+  - `github.event.merge_group.head_ref` — the temporary merge branch name
+fix: |
+  Add `merge_group:` to the `on:` block of every workflow that is listed as a required
+  status check for merge queue-protected branches.
+
+  **Important:** `merge_group` does NOT automatically run `pull_request` workflows — it
+  is a completely separate event type. You must add it explicitly.
+
+  If your workflow has conditions that reference `github.event_name == 'pull_request'`,
+  update those conditions to also allow `merge_group` events, or restructure them to
+  check `github.event.pull_request || github.event.merge_group`.
+fix_code:
+  - language: yaml
+    label: "Add merge_group trigger to an existing CI workflow"
+    code: |
+      on:
+        pull_request:
+          branches: [main, develop]
+        merge_group:          # <-- Add this to receive merge queue events
+          types: [checks_requested]
+
+      jobs:
+        ci:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+            - name: Run tests
+              run: npm test
+  - language: yaml
+    label: "Conditional logic that handles both pull_request and merge_group"
+    code: |
+      on:
+        pull_request:
+        merge_group:
+          types: [checks_requested]
+
+      jobs:
+        ci:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+
+            # Access the base SHA correctly for both event types
+            - name: Get base SHA
+              id: base
+              run: |
+                if [ "${{ github.event_name }}" = "merge_group" ]; then
+                  echo "sha=${{ github.event.merge_group.base_sha }}" >> $GITHUB_OUTPUT
+                else
+                  echo "sha=${{ github.event.pull_request.base.sha }}" >> $GITHUB_OUTPUT
+                fi
+  - language: yaml
+    label: "Reusable workflow that supports merge_group via workflow_call"
+    code: |
+      # In the caller workflow:
+      on:
+        pull_request:
+        merge_group:
+          types: [checks_requested]
+
+      jobs:
+        ci:
+          uses: ./.github/workflows/ci-reusable.yml
+          with:
+            ref: ${{ github.event.pull_request.head.sha || github.event.merge_group.head_sha }}
+prevention:
+  - "When enabling merge queue on a branch protection rule, immediately check that every required workflow has `merge_group` in its `on:` triggers."
+  - "Add a repository-level workflow audit that lists all required status checks and verifies each has a matching `merge_group` trigger."
+  - "Test the merge queue setup by creating a test PR and attempting to add it to the queue — if checks show 'Waiting', add the trigger."
+  - "Third-party Actions and path-filter actions (dorny/paths-filter, tj-actions/changed-files) may need explicit `merge_group` support — check their changelogs."
+  - "GitHub's documentation now includes a merge queue section — review it when enabling the feature in your organization."
+docs:
+  - url: "https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue"
+    label: "GitHub Docs: Managing a merge queue"
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#merge_group"
+    label: "GitHub Actions: merge_group event trigger"
+  - url: "https://github.blog/changelog/2023-02-08-pull-request-merge-queue-public-beta/"
+    label: "GitHub Changelog: Pull request merge queue public beta (Feb 2023)"

package/errors/yaml-syntax/set-output-deprecated-commands.yml

@@ -0,0 +1,130 @@
+id: yaml-syntax-015
+title: "Deprecated ::set-output:: / ::save-state:: / ::add-path:: Workflow Commands"
+category: yaml-syntax
+severity: warning
+tags:
+  - set-output
+  - save-state
+  - add-path
+  - deprecated
+  - GITHUB_OUTPUT
+  - GITHUB_ENV
+  - GITHUB_PATH
+  - workflow-commands
+patterns:
+  - regex: "The `set-output` command is deprecated"
+    flags: "i"
+  - regex: "The `save-state` command is deprecated"
+    flags: "i"
+  - regex: "The `set-env` command is disabled"
+    flags: "i"
+  - regex: "::set-output name="
+    flags: ""
+  - regex: "::save-state name="
+    flags: ""
+  - regex: "::add-path::"
+    flags: ""
+  - regex: "workflow commands.*deprecated.*will be disabled"
+    flags: "i"
+error_messages:
+  - "Warning: The `set-output` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter"
+  - "Warning: The `save-state` command is deprecated and will be disabled soon. Please upgrade to using Environment Files."
+  - "Error: The `set-env` command is disabled. Please upgrade to using Environment Files."
+  - "Error: The `add-path` command is disabled. Please upgrade to using Environment Files."
+root_cause: |
+  GitHub Actions introduced a new Environment Files mechanism in 2020 to replace the
+  older `echo "::command::"` workflow commands. The old commands were deprecated in
+  October 2022 (security advisory: injection attacks could hijack `::set-output::` via
+  untrusted log output) and disabled shortly after.
+
+  **Deprecated commands and their replacements:**
+  | Old command                         | Replacement                                    |
+  |-------------------------------------|------------------------------------------------|
+  | `echo "::set-output name=K::V"`     | `echo "K=V" >> $GITHUB_OUTPUT`                 |
+  | `echo "::save-state name=K::V"`     | `echo "K=V" >> $GITHUB_STATE`                  |
+  | `echo "::set-env name=K::V"`        | `echo "K=V" >> $GITHUB_ENV`                    |
+  | `echo "::add-path::PATH"`           | `echo "PATH" >> $GITHUB_PATH`                  |
+
+  These commands still appear in:
+  - Third-party GitHub Actions that haven't been updated to a newer major version
+  - Scripts copied from old Stack Overflow answers or blog posts
+  - Custom scripts that use the `::set-output::` form directly
+  - Older composite actions where steps use `echo "::set-output name=result::$value"`
+
+  When the runner encounters these commands, it emits a deprecation warning. If the
+  commands are later hard-disabled for a repository (or for a specific runner version),
+  the output variable is simply never set — creating a silent downstream failure.
+fix: |
+  Replace all deprecated `::command::` syntax with the Environment Files equivalents
+  in your workflow YAML, composite action scripts, and any shell scripts that produce
+  outputs or modify the environment.
+
+  **Key rules:**
+  - `GITHUB_OUTPUT`, `GITHUB_ENV`, `GITHUB_STATE`, `GITHUB_PATH` are all file paths
+    that are set as environment variables by the runner.
+  - Append to these files — never overwrite them (`>>` not `>`).
+  - For multiline values, use the heredoc delimiter syntax (see fix_code below).
+  - On Windows (PowerShell), use `"K=V" | Out-File -FilePath $env:GITHUB_OUTPUT -Append`
+    or simply `echo "K=V" >> $env:GITHUB_OUTPUT` (cmd-style append works in pwsh too).
+fix_code:
+  - language: yaml
+    label: "Replace ::set-output:: with GITHUB_OUTPUT (bash)"
+    code: |
+      - name: Set output (modern)
+        id: my-step
+        run: |
+          # Old (deprecated):
+          # echo "::set-output name=version::1.2.3"
+
+          # New (use environment file):
+          echo "version=1.2.3" >> $GITHUB_OUTPUT
+
+      - name: Use output downstream
+        run: echo "Version is ${{ steps.my-step.outputs.version }}"
+  - language: yaml
+    label: "Replace ::set-output:: with GITHUB_OUTPUT (PowerShell)"
+    code: |
+      - name: Set output (PowerShell modern)
+        id: my-step
+        shell: pwsh
+        run: |
+          # Old (deprecated):
+          # Write-Output "::set-output name=version::1.2.3"
+
+          # New:
+          "version=1.2.3" | Out-File -FilePath $env:GITHUB_OUTPUT -Encoding utf8 -Append
+  - language: yaml
+    label: "Replace ::save-state:: with GITHUB_STATE"
+    code: |
+      - name: Save state in pre step
+        run: echo "cleanup_token=${{ secrets.TOKEN }}" >> $GITHUB_STATE
+
+      - name: Read state in post step
+        run: echo "Token was $STATE_CLEANUP_TOKEN"
+        # State values are exposed as STATE_<NAME> environment variables
+  - language: yaml
+    label: "Multiline output value with heredoc delimiter"
+    code: |
+      - name: Set multiline output
+        id: changelog
+        run: |
+          EOF=$(dd if=/dev/urandom bs=15 count=1 status=none | base64)
+          echo "notes<<$EOF" >> $GITHUB_OUTPUT
+          echo "Line 1 of release notes" >> $GITHUB_OUTPUT
+          echo "Line 2 of release notes" >> $GITHUB_OUTPUT
+          echo "$EOF" >> $GITHUB_OUTPUT
+prevention:
+  - "Audit all workflows and composite actions for `::set-output::`, `::save-state::`, `::set-env::`, and `::add-path::` patterns before they become hard failures."
+  - "Add a CI lint step using `grep -r '::set-output' .github/` to catch regressions."
+  - "When using third-party Actions, pin to a version tag that uses the modern file-based outputs — check the action's CHANGELOG for 'GITHUB_OUTPUT migration'."
+  - "For cross-platform workflows, test the `$GITHUB_OUTPUT` / `$env:GITHUB_OUTPUT` equivalence — both work on ubuntu/macos/windows runners."
+  - "Enable the 'Deprecation warnings as errors' setting in your organization's Actions policy to catch deprecated commands in CI before they silently fail."
+docs:
+  - url: "https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter"
+    label: "GitHub Actions: Setting an output parameter (Environment Files)"
+  - url: "https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/"
+    label: "GitHub Changelog: Deprecating save-state and set-output commands (Oct 2022)"
+  - url: "https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/"
+    label: "GitHub Changelog: Deprecating set-env and add-path commands (Oct 2020)"
+  - url: "https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#understanding-the-risk-of-script-injections"
+    label: "Security hardening: Understanding the risk of script injections"

package/package.json

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