GO — Healthy across the board

• Last commit today
• 76+ active contributors
• Distributed ownership (top contributor 10% of recent commits)
• MIT licensed
• CI configured
• Tests present
• ⚠ Scorecard: dangerous CI workflow (0/10)
• ⚠ Scorecard: default branch unprotected (0/10)

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against dependency CVEs from deps.dev and OpenSSF Scorecard}

awesome-go is a curated, community-maintained catalog of Go frameworks, libraries, and tools, stored as a structured README.md and rendered into a static website at awesome-go.com. The repo solves the discovery problem for Go developers by organizing hundreds of packages into categories, and enforces quality standards via automated CI checks that validate each linked repository is alive, active, and meets contribution criteria. The Go code in the repo is tooling (not a library): it generates the website from README.md and runs link/quality checks. The repo is a single Go module at root: main.go orchestrates site generation (README.md → static HTML via goldmark + goquery + tmpl/), while pkg/markdown/ handles Markdown-to-HTML conversion and pkg/slug/ generates URL slugs. CI automation lives in .github/scripts/check-pr-diff/ and .github/scripts/check-quality/, each as a self-contained main.go, and the static site template assets are in tmpl/assets/.

Go developers who need to discover vetted libraries for a specific task (e.g. HTTP routing, CLI parsing, ORMs), and open-source maintainers who want their Go project listed in a high-visibility, community-trusted catalog. Contributors are typically Go practitioners submitting PRs to add or remove entries.

Extremely mature — one of the most-starred Go repositories on GitHub, active since ~2014, with recent commits visible and a full CI pipeline defined across .github/workflows/ (tests.yaml, pr-quality-check.yaml, run-check.yaml, site-deploy.yaml). Test files (main_test.go, maturity_test.go, stale_repositories_test.go) confirm automated correctness checking. Verdict: production-ready and very actively maintained.

Low risk for consumers — it is a reference list, not a runtime dependency. The tooling code (main.go, pkg/) has a small, well-known dependency set: goquery for HTML parsing, goldmark for Markdown, slugify, and golang.org/x/oauth2 for GitHub API calls during checks. Single-maintainer risk exists (avelino is the primary owner per MAINTAINERS), but the contributor community is large enough to mitigate bus-factor concerns.

Active work includes automated stale-repository detection (stale_repositories_test.go), PR quality enforcement via .github/scripts/check-quality/main.go and the pr-quality-check.yaml workflow, and recheck automation for open PRs via recheck-open-prs.yaml. The AGENTS.md file suggests recent effort to define AI-agent contribution rules.

git clone https://github.com/avelino/awesome-go.git && cd awesome-go && go mod download && go test ./... && go run main.go # generates the static site output

Daily commands: go run main.go # generates the static website from README.md into output directory go test ./... # runs all tests including link checks, maturity checks, stale repo checks cd .github/scripts/check-quality && go run main.go # run PR quality checker standalone

• main.go — Entry point that reads README.md, validates links, generates the static site HTML, and orchestrates the entire build pipeline.
• README.md — The canonical source of truth — all Go library entries live here; every other file derives from or validates against it.
• pkg/markdown/convert.go — Core abstraction that parses the README markdown into structured data used for site generation and link checking.
• pkg/slug/generator.go — Generates URL-safe slugs for category anchors, directly affecting all generated page URLs.
• tmpl/index.tmpl.html — Primary HTML template that controls the rendered layout of the main awesome-go.com site page.
• .github/scripts/check-quality/main.go — Automated PR quality gate that enforces contribution standards by validating new entries against defined rules.
• CONTRIBUTING.md — Defines the contribution contract — entry format, acceptance criteria, and PR process every contributor must follow.

• main.go (Go stdlib, goldmark, goquery, oauth2) — Orchestrates the full build: parse, validate, render, and write output files.
  • Failure mode: Exits non-zero if any link is dead or template rendering fails, blocking CI.
• pkg/markdown/convert.go (goldmark AST) — Transforms raw README.md markdown AST nodes into typed Go structs for categories and projects.
  • Failure mode: Silently drops entries if README formatting deviates from expected heading/list structure.
• pkg/slug/generator.go (avelino/slugify) — Produces stable, unique URL slugs from heading strings for use in page routing.
  • Failure mode: Slug collisions between similarly-named categories would result in overwritten output files.
• HTML Templates (tmpl/) (Go html/template) — Define the complete visual structure of every page type on awesome-go.com.
  • Failure mode: Template parse errors abort the build; logic errors produce malformed HTML silently.
• GitHub Actions Workflows (GitHub Actions, bash, Go scripts) — Automate link checking, PR quality gating, and Netlify site deployment on every push and PR.
  • Failure mode: Rate limiting or network timeouts cause false-negative CI failures on valid PRs.
• check-quality script (Go, GitHub API via oauth2) — Validates that new README entries conform to format and content standards before merge.
  • Failure mode: Overly strict rules block legitimate entries; under-specified rules allow low-quality submissions.

• README.md → pkg/markdown/convert.go — Raw markdown text is parsed into a goldmark AST and then into typed Category/Project structs.
• pkg/markdown/convert.go → main.go — Structured category and project data is returned to the orchestrator for further processing.
• main.go → GitHub API — HTTP HEAD requests are sent to each project URL to validate liveness during link checking.
• main.go → tmpl/*.tmpl.html — Parsed data is injected into Go HTML templates to produce rendered static HTML pages.
• tmpl/ (rendered output) → Netlify CDN — Generated HTML, CSS, and asset files are deployed to Netlify for public serving.

Add a new Go library entry

1. Find the appropriate alphabetically-sorted category section and add a markdown list item following the pattern - [LibraryName](https://github.com/owner/repo) - One sentence description. (README.md)
2. Verify your entry passes the automated quality checks by reviewing the validation rules used in the PR check script. (.github/scripts/check-quality/main.go)
3. Run go test ./... locally to confirm no link-check or format tests fail before opening a PR. (main_test.go)

Add a new top-level category

1. Add a new H2 heading (## Category Name) with an H3 sub-heading if needed, plus a description paragraph and at least one entry, in alphabetical order among existing categories. (README.md)
2. Confirm the slug generator correctly handles the new heading text and produces a unique, valid URL slug. (pkg/slug/generator.go)
3. Check that the category-index template renders the new category correctly by running the build locally. (tmpl/category-index.tmpl.html)

Modify site template / UI

1. Edit the relevant HTML template file — index for the main page, category-index for per-category pages, or project for per-project pages. (tmpl/index.tmpl.html)
2. Update CSS if visual styling changes are needed. (tmpl/assets/awesome-go.css)
3. Review how templates are loaded and executed to ensure new template variables are passed correctly from the build. (main.go)

Add or modify a CI quality check

1. Update or add validation logic in the quality check script, following existing patterns for inspecting README diffs. (.github/scripts/check-quality/main.go)
2. Update the GitHub Actions workflow YAML to adjust triggers, timeouts, or pass new environment variables to the script. (.github/workflows/pr-quality-check.yaml)

• Go (static binary) — Single-binary build tool with no runtime dependencies; fast execution for link checking and template rendering at CI time.
• goldmark (markdown parser) — Spec-compliant CommonMark parser with a clean AST API, enabling reliable extraction of structured data from README.md.
• goquery (HTML/DOM querying) — jQuery-style DOM traversal used to validate and extract data from rendered HTML during tests.
• Go html/template — Standard-library templating provides safe HTML escaping and sufficient power for generating static pages without external dependencies.
• Netlify — Zero-config static site hosting with CDN, automatic deploys on merge to main, and free tier suitable for an open-source project.
• GitHub Actions — Native CI/CD tightly integrated with the repository for automated link checks, PR quality gates, and site deployments.

• README.md as the single source of truth

  • Why: Keeps contribution friction minimal — contributors edit one familiar Markdown file rather than a database or YAML config.
  • Consequence: The entire build pipeline must parse unstructured Markdown, making format enforcement critical and brittle to README formatting errors.

• Static site generation at build time

  • Why: Eliminates server-side runtime, reduces hosting cost to zero, and maximises availability.
  • Consequence: New entries only appear on the live site after a merge and redeploy; no real-time updates.

• Link checking via live HTTP requests in CI

  • Why: Catches dead or moved repositories before they are merged, keeping list quality high.
  • Consequence: CI runs are slow and flaky due to network timeouts and rate limiting from GitHub and other hosts.

• No database or CMS

  • Why: Keeps the project simple, fully auditable via git history, and accessible to contributors unfamiliar with databases.
  • Consequence: Advanced querying, filtering, or personalisation features cannot be implemented without a significant architectural change.

• Does not provide a backend API or dynamic server — output is purely static HTML.
• Does not automatically discover or add new Go libraries — all entries are manually curated.
• Does not rank or score libraries algorithmically — ordering is alphabetical within categories.
• Does not handle user authentication, accounts, or personalisation.
• Does not support real-time updates between site deploys.

• Avg cyclomatic complexity: ~4 — Most files are straightforward template rendering or linear markdown parsing; complexity is concentrated in main.go's link-check orchestration and the CI scripts.
• Largest file: README.md (8,000 lines)
• Estimated quality issues: ~5 — Code quality is generally good with clear separation into packages; main issues are the monolithic entry point, lack of retry logic for network calls, and absence of slug collision detection.

• Unstructured data source as database (Medium) — README.md + pkg/markdown/convert.go: Using a human-edited Markdown file as the sole data source requires fragile format-dependent parsing that breaks silently on minor formatting deviations.
• Network I/O in CI without retry/backoff (High) — main.go: Bulk HTTP HEAD requests to hundreds of GitHub URLs during CI are susceptible to transient failures and rate limiting without robust retry logic, causing false CI failures.
• Large monolithic entry point (Medium) — main.go: The main.go file combines link checking, template rendering, file I/O, and orchestration logic, making individual concerns hard to test or swap independently.
• Implicit slug uniqueness assumption (Low) — pkg/slug/generator.go: No collision detection is performed when generating slugs, so two categories with similar names could produce identical slugs and silently overwrite each other's output files.

• main.go — link validation loop (Network I/O / Concurrency) — Sequential or insufficiently parallelised HTTP requests to hundreds of repository URLs dominate total build time, often causing multi-minute CI runs.
• pkg/markdown/convert.go (CPU / Parse time) — Full AST traversal of the entire README on every build scales linearly with list size; not cached between runs.
• .github/workflows/run-check.yaml (CI Pipeline latency) — GitHub Actions job startup overhead and lack of dependency caching means even small changes trigger a full re-validation of all links.

The test suite (main_test.go, stale_repositories_test.go) makes live HTTP requests to GitHub's API — running tests without a GITHUB_TOKEN env var will quickly hit GitHub's unauthenticated rate limit (60 req/hr) and cause flaky failures. Set GITHUB_TOKEN before running go test ./.... Also, the PR process enforces exactly one new entry per PR (checked by check-pr-diff/main.go); multi-entry PRs are automatically rejected. The README.md format is strict — entries must follow the exact pattern '- Name - Description.' with a period at the end.

• Curated list / awesome-list format — The entire repo structure — one README.md with categorized links, strict entry formatting, single-entry PRs — follows the awesome-list convention enforced by CI scripts.
• GitHub API rate limiting — The test suite makes GitHub API calls to validate repo health; understanding authenticated vs unauthenticated rate limits (5000/hr vs 60/hr) is essential to run tests locally without failures.
• Static site generation from Markdown — main.go implements a bespoke SSG pipeline: goldmark parses README.md, goquery manipulates the resulting HTML tree, and output is written to a deploy directory — understanding this flow is required to modify the site.
• Goldmark Markdown renderer — pkg/markdown/convert.go wraps goldmark with specific options (GFM extensions, HTML rendering); knowing goldmark's extension API is needed to change how the site renders links or code blocks.
• PR diff validation as a quality gate — The check-pr-diff tool programmatically parses unified diff output to enforce contribution rules (one entry per PR, correct file targets) — a non-obvious CI pattern worth understanding before submitting changes.
• Repository maturity heuristics — maturity_test.go and stale_repositories_test.go implement automated checks (last commit date, star count, archive status) to keep the list from decaying — understanding these heuristics explains why some PRs are rejected.

• sindresorhus/awesome — The original 'awesome list' meta-repo that defines the format and quality standards that awesome-go follows.
• avelino/awesome-go-www — If it exists, would be the companion site renderer; the current repo self-contains site gen in main.go targeting awesome-go.com.
• uhub/awesome-go — An alternative curated Go library list that solves the same discovery problem with a different curation approach.
• goquery/goquery — PuerkitoBio/goquery is a direct dependency used in main.go for HTML querying during site generation.
• yuin/goldmark — The Markdown parser depended on by pkg/markdown/convert.go for transforming README.md into the website HTML.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for pkg/slug/generator.go edge cases (Unicode, special chars, consecutive hyphens)

The file pkg/slug/generator_test.go exists but slug generation for awesome-go is critical — every README entry's anchor link depends on correct slug output. Looking at the dependency on github.com/avelino/slugify, there are likely untested edge cases: entries with Unicode characters (e.g. Chinese/Japanese library names), entries with multiple consecutive special characters, entries starting or ending with hyphens, and all-uppercase acronyms like 'CLI' or 'HTTP'. Broken slugs silently produce dead anchor links on awesome-go.com, which is a real user-facing bug.

• [ ] Open pkg/slug/generator_test.go and audit existing test cases for coverage gaps
• [ ] Add table-driven test cases in pkg/slug/generator_test.go covering: Unicode input (e.g. '中文库'), consecutive special chars ('foo--bar!!baz'), leading/trailing hyphens, all-caps acronyms ('HTTP Client'), and empty string input
• [ ] Run 'go test ./pkg/slug/...' and confirm all new cases pass or fix generator.go if they expose real bugs
• [ ] Cross-check generated slugs against actual anchor links in README.md to ensure no regressions on existing entries

Add unit tests for pkg/markdown/convert.go covering malformed Markdown and edge-case README structures

pkg/markdown/convert_test.go exists but convert.go is the core pipeline that transforms README.md into the awesome-go.com website via goldmark. If convert.go silently mishandles edge cases — unclosed code fences, nested lists, sections with no links, duplicate section headings — the generated site has broken or missing content. These failure modes are not caught by current CI because the tests likely only cover the happy path. This is high-value because README.md is edited by hundreds of contributors and edge cases are common.

• [ ] Read pkg/markdown/convert.go to understand what AST transformations it performs on the goldmark output
• [ ] Open pkg/markdown/convert_test.go and identify which input variations are NOT currently tested
• [ ] Add test cases in pkg/markdown/convert_test.go for: a section heading with zero links beneath it, duplicate H2/H3 headings, an unclosed code fence block mid-section, a link whose URL contains query parameters or fragments, and a description containing inline backticks
• [ ] Ensure tests call the same entry-point function used by main.go so they reflect real production behavior
• [ ] Run 'go test ./pkg/markdown/...' and fix any discovered bugs in convert.go

Extract repository-fetching and link-validation logic from main.go into a dedicated pkg/checker package with tests

main.go is both the CLI entry point and contains link-checking / GitHub API logic (evidenced by the golang.org/x/oauth2 and PuerkitoBio/goquery dependencies and the existence of stale_repositories_test.go and maturity_test.go at the root). Having business logic in main.go makes it untestable in isolation and violates the pattern already established by pkg/markdown and pkg/slug. Extracting this into pkg/checker would allow the stale_repositories_test.go and maturity_test.go tests to import a real package instead of relying on package-level globals, and would make the GitHub API rate-limit handling and HTTP client mockable.

• [ ] Read main.go and identify all functions beyond func main() — particularly those exercised by stale_repositories_test.go and maturity_test.go
• [ ] Create pkg/checker/checker.go and move the link-validation, GitHub API calls, and maturity-classification logic into exported functions there
• [ ] Create pkg/checker/checker_test.go with unit tests that use an http.Client with a custom http.RoundTripper to mock GitHub API responses without real network calls
• [ ] Update stale_repositories_test.go and maturity_test.go to

1. Add tests in pkg/slug/generator_test.go for edge cases like slugs with consecutive hyphens, Unicode input, or all-numeric category names — coverage appears minimal. 2. pkg/markdown/convert_test.go likely lacks tests for malformed Markdown input or deeply nested list structures — add table-driven tests for error paths. 3. Document the GITHUB_TOKEN requirement and rate-limit behavior explicitly in CONTRIBUTING.md or a local development setup section, as it is a major hidden trap for new contributors running tests locally.

• Medium · OAuth2 Token Potentially Exposed in CI/CD Workflows — .github/workflows/run-check.yaml, .github/workflows/recheck-open-prs.yaml, main.go. The project uses golang.org/x/oauth2 for GitHub API authentication (likely to check repository metadata/staleness). If GitHub tokens are passed via environment variables in workflows without proper masking or scoping, they could be exposed in logs or accessible to malicious PRs via pull_request_target misuse. Fix: Ensure GitHub tokens used in workflows are scoped to minimum required permissions (read-only where possible), never echoed to logs, and that workflows triggered by external PRs (pull_request) do not have access to secrets. Use 'pull_request' (not 'pull_request_target') for untrusted contributor PRs.
• Medium · Unvalidated External URL Fetching (SSRF Risk) — main.go, stale_repositories_test.go, maturity_test.go. The codebase fetches external URLs (GitHub repositories listed in README.md) to check their status, star counts, and staleness. If any user-submitted URL in a PR is processed server-side without strict validation (e.g., only github.com URLs allowed), this could lead to Server-Side Request Forgery (SSRF) allowing probing of internal infrastructure during CI execution. Fix: Enforce strict URL allowlisting (e.g., only allow https://github.com/* URLs) before making outbound HTTP requests. Validate and sanitize all URLs extracted from README.md prior to fetching.
• Medium · Insecure Vulnerability Reporting Process — SECURITY.md. SECURITY.md instructs reporters to open a public GitHub issue for vulnerabilities. This means security vulnerabilities are publicly disclosed immediately upon reporting, before a fix is available. This is a significant process risk, as it allows attackers to exploit vulnerabilities before patches are released. Fix: Replace the public issue reporting process with a private disclosure channel such as GitHub's private vulnerability reporting feature (Security Advisories), or a dedicated security email address. Update SECURITY.md to reflect the private reporting process.
• Medium · Potential XSS via Unescaped Markdown-to-HTML Conversion — pkg/markdown/convert.go. The pkg/markdown/convert.go file converts README.md Markdown content to HTML for the static site. If the Goldmark library is configured without HTML sanitization, malicious content submitted via PRs (e.g., raw HTML in markdown, javascript: links, or inline script tags) could be rendered as unsanitized HTML in the generated site. Fix: Ensure Goldmark is configured with 'html.WithUnsafe(false)' (the default) or that an HTML sanitization pass is performed on generated output. Additionally, configure a strict Content Security Policy (CSP) header on the deployed site to mitigate XSS impact.
• Low · Missing Security Headers on Deployed Static Site — netlify.toml. The site is deployed via Netlify (netlify.toml present). Without explicit security header configuration, the site may lack important HTTP security headers such as Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy. Fix: Add security headers to netlify.toml under the [[headers]] section. At minimum, configure: Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and Permissions-Policy.
• Low · Dependency: golang.org/x/net Indirect Dependency — go.mod. golang.org/x/net v0.38.0 is used as an indirect dependency. Older versions of this package have had HTTP/2 related vulnerabilities (e.g., CVE-2023-44487 - HTTP/2 Rapid Reset). While v0.38.0 is relatively recent, extended golang.org/x packages should be kept updated as they frequently receive security patches. Fix: Regularly run 'go get -u golang.org/x/net' and 'govulncheck ./...' to detect and remediate known vulnerabilities in all dependencies. Pin to the latest stable versions.
• Low · Spammy Issue Check Workflow May Be By — undefined. undefined Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/avelino/awesome-go shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live avelino/awesome-go repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/avelino/awesome-go.

What it runs against: a local clone of avelino/awesome-go — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in avelino/awesome-go | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of avelino/awesome-go. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/avelino/awesome-go.git
#   cd awesome-go
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of avelino/awesome-go and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "avelino/awesome-go(\\.git)?\\b" \\
  && ok "origin remote is avelino/awesome-go" \\
  || miss "origin remote is not avelino/awesome-go (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "main.go" \\
  && ok "main.go" \\
  || miss "missing critical file: main.go"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "pkg/markdown/convert.go" \\
  && ok "pkg/markdown/convert.go" \\
  || miss "missing critical file: pkg/markdown/convert.go"
test -f "pkg/slug/generator.go" \\
  && ok "pkg/slug/generator.go" \\
  || miss "missing critical file: pkg/slug/generator.go"
test -f "tmpl/index.tmpl.html" \\
  && ok "tmpl/index.tmpl.html" \\
  || miss "missing critical file: tmpl/index.tmpl.html"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/avelino/awesome-go"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.