GO — Healthy across the board

• Last commit today
• 9 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 66% of recent commits
• ⚠ Scorecard: default branch unprotected (0/10)

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

Selenium is a browser automation framework that implements the W3C WebDriver specification, allowing programmatic control of web browsers across all major platforms. It provides language bindings for Java, C#, Python, Ruby, JavaScript, Rust, and C++, enabling automated testing, web scraping, and cross-browser compatibility testing without writing browser-specific code. Monorepo structured by language: java/, dotnet/, py/, rb/, javascript/, rust/, cpp/ directories each contain language-specific WebDriver implementations. Core protocol abstraction lives in common/ (images, shared specs). Build orchestration uses Bazel (BUILD files throughout) with Starlark rules. CI/CD split by language (.github/workflows/ci-*.yml) and RBE remote execution. Test infrastructure spans all languages with language-specific test runners.

QA automation engineers and test developers who need to automate browser interactions across multiple browsers and platforms; developers building end-to-end test suites; developers requiring cross-browser compatibility verification in CI/CD pipelines.

Highly mature and production-ready: SeleniumHQ/selenium is the de facto standard for browser automation with 7+ major language implementations, extensive CI/CD via GitHub Actions (ci.yml, ci-java.yml, ci-python.yml, ci-dotnet.yml, ci-ruby.yml, ci-rust.yml), established release processes (.github/workflows/release.yml), and active development across 10+ primary languages. The codebase is well-organized with Bazel build system, devcontainer support, and comprehensive issue templates.

Low technical risk due to W3C standardization, but integration risk exists: WebDriver protocol changes from browser vendors require upstream coordination; breaking changes across major versions affect 6+ language bindings simultaneously (tracked in .github/release.yml). The monorepo structure means single version number spans Java (7.2M LOC), C# (3.3M LOC), and other implementations, requiring careful coordination. Open CI/CD workflows (47+ workflow files) indicate high community maintenance burden.

Active development across all bindings with Renovate-driven dependency updates (ci-renovate-rbe.yml), ongoing RBE (Remote Build Execution) optimization (ci-rbe.yml), and nightly test runs (.github/workflows/nightly.yml). Recent focus on browser pinning (pin-browsers.yml) and release automation (release.yml, pre-release.yml). Documentation updates via GitHub Actions (update-documentation.yml) and issue/PR labeling automation indicate structured release process.

Clone the repo and install build dependencies: git clone https://github.com/SeleniumHQ/selenium.git && cd selenium. Install Bazelisk (automatically fetches correct Bazel from .bazelversion). Set JAVA_HOME to JDK 17+. For your specific language binding, navigate to that directory (e.g., cd java/ or cd py/) and consult the language-specific BUILD files. Use bazel build //path/to:target to compile.

Daily commands: Build a specific target with Bazel: bazel build //java/src/org/openqa/selenium:selenium (Java) or bazel build //py:selenium (Python). Run tests: bazel test //java/test/... or bazel test //py/test/.... For language-specific development, enter subdirectory and use language-native tools: Java uses bazel build but can also use mvn; Python uses bazel test or pytest directly; Node.js modules use npm test.

• BUILD.bazel — Root build configuration defining the entire Bazel workspace and top-level targets for all language bindings.
• WORKSPACE — Workspace definition file that declares external dependencies and repository rules for the multi-language project.
• README.md — Project overview explaining Selenium's purpose as a W3C WebDriver-compliant browser automation framework.
• .github/workflows/ci.yml — Primary CI/CD pipeline orchestrating builds and tests across Java, Python, Ruby, .NET, Rust, and Grid components.
• common/defs.bzl — Shared Bazel macro definitions and build helpers used consistently across all language-specific modules.
• CONTRIBUTING.md — Developer guide documenting contribution workflows, testing expectations, and cross-language coordination practices.
• common/devtools/README.md — Documentation for Chrome DevTools Protocol integration, critical for browser automation and debugging.

• W3C WebDriver Implementation (JavaScript, Java, Python, Ruby, C#, Rust) — Provides standardized API for element location, interaction, and navigation across all browsers.
  • Failure mode: Incompatible WebDriver API versions across language bindings; breaks cross-language test portability.
• Chrome DevTools Protocol Layer (PDL protocol definitions, browser-specific implementations) — Enables advanced browser instrumentation including network interception, performance metrics, and debugging.
  • Failure mode: Protocol version mismatch between client and browser; features unavailable in non-Chromium browsers.
• Bazel Build System (Bazel, bzlmod, BUILD.bazel rules) — Ensures hermetic, reproducible builds and fast incremental compilation across polyglot codebase.
  • Failure mode: Build rule conflicts or missing dependencies; CI pipeline failures across language bindings.
• Language-Specific Drivers (Java, Python, Ruby, .NET, Rust) (Language-native HTTP clients, WebSocket libraries, protocol serialization) — Implement W3C WebDriver and CDP protocol translation for each language's idioms and ecosystem.
  • Failure mode: Language binding lag; features implemented in one language unavailable in others.
• CI/CD Orchestration (GitHub Actions, Bazel test rules) — Runs matrix builds and tests across operating systems, browser versions, and language bindings.
  • Failure mode: Flaky tests or infrastructure outages block all PRs; release pipeline delays.
• Grid (Separate Component) (Java, Docker, WebSocket) — Distributes WebDriver commands across multiple nodes for parallel test execution and resource sharing.
  • Failure mode: Node crashes or network partition; test isolation violations or command routing failures.

• Test Code (Java/Python/Ruby/.NET/Rust) → Language-Specific WebDriver Client — Developer code invokes WebDriver API (find_element, click, etc.).
• Language-Specific WebDriver Client → Browser Driver Process (chromedriver, geckodriver, etc.) — Client serializes W3C WebDriver command as JSON and sends via HTTP POST or WebSocket.
• Browser Driver Process → Browser Engine (Chrome, Firefox, Safari, Edge) — Driver translates command to Chrome DevTools Protocol or native browser API; communicates via WebSocket or IPC.
• Browser Engine → Browser Driver Process — Browser returns DOM state, event results, screenshots, or performance metrics via protocol response.
• Browser Driver Process → Language-Specific WebDriver Client — Driver parses protocol response and returns structured result (element reference, Boolean, string) to client.
• Language-Specific WebDriver Client → Test Code — Client deserialization makes result available as language-native object for assertions or chaining.

Add Support for a New Browser Version

1. Add protocol definition files for the new Chromium version in a new subdirectory. (common/devtools/chromium/vXXX/browser_protocol.pdl)
2. Create BUILD.bazel to build the protocol rules for the new version. (common/devtools/chromium/vXXX/BUILD.bazel)
3. Update the browser versions list referenced in build configurations. (common/browsers.bzl)
4. Add CI pipeline step to test the new browser version. (.github/workflows/ci.yml)

Add a New Language Binding

1. Create a new top-level directory with language-specific BUILD.bazel and source files. (py/BUILD.bazel)
2. Define language-specific build macros and rules following existing patterns. (common/defs.bzl)
3. Create a dedicated CI workflow file for the new language. (.github/workflows/ci-newlang.yml)
4. Add the language binding to the main CI pipeline. (.github/workflows/ci.yml)
5. Document setup and contribution guidelines. (CONTRIBUTING.md)

Update WebDriver Protocol Definitions

1. Modify the Chrome DevTools Protocol schema to reflect new browser capabilities. (common/devtools/browser_protocol.json)
2. Update protocol definition files for affected Chromium versions. (common/devtools/chromium/vXXX/browser_protocol.pdl)
3. Regenerate language-specific protocol bindings using build rules. (common/devtools/BUILD.bazel)
4. Add tests validating the protocol changes across all language bindings. (.github/workflows/ci.yml)

• Bazel — Polyglot build system enabling consistent compilation of Java, Python, Ruby, .NET, and Rust bindings with hermetic environments.
• Chrome DevTools Protocol (CDP) — Standardized protocol for deep browser automation, enabling advanced features beyond W3C WebDriver specification.
• GitHub Actions — Native CI/CD integration for running matrix builds across multiple language bindings and OS platforms.
• W3C WebDriver Specification — Platform and language-neutral API standard ensuring compatibility across all major browsers.

• Polyglot architecture supporting Java, Python, Ruby, .NET, and Rust

  • Why: Maximizes developer accessibility across ecosystems and use cases.
  • Consequence: Increased complexity in build infrastructure, testing matrix, and release coordination.

• Bazel as the build system

  • Why: Enables reproducible, hermetic builds and fast incremental compilation at scale.
  • Consequence: Steeper learning curve for contributors unfamiliar with Bazel; slower initial setup.

• Chrome DevTools Protocol alongside W3C WebDriver

  • Why: Unlocks advanced browser capabilities (network interception, performance metrics) not standardized in WebDriver.
  • Consequence: Implementation complexity; some features unavailable in non-Chromium browsers.

• Centralized protocol definitions versioned per Chromium release

  • Why: Ensures protocol accuracy and browser compatibility as Chrome evolves.
  • Consequence: Manual maintenance burden; protocol files must be updated for each new browser version.

• Does not handle browser installation or version management (relies on external tools like Webdriver Manager).
• Does not provide UI test recording or visual regression detection.
• Does not include mobile native app automation (web browser automation only).
• Does not implement authentication protocols or cookie management beyond WebDriver API.
• Does not provide cross-browser cloud execution (Grid is a separate component for local/on-premise deployment).

• Avg cyclomatic complexity: ~6.5 — Polyglot architecture with 5+ language bindings, Bazel build complexity, Chrome DevTools Protocol versioning, and distributed CI/CD orchestration.
• Largest file: common/devtools/chromium/vXXX/browser_protocol.pdl (estimated) (15,000 lines)
• Estimated quality issues: ~12 — Protocol version drift, testing matrix fragmentation across languages, build rule consistency, and release coordination complexity.

• Protocol version drift (High) — common/devtools/chromium/vXXX/*.pdl files: Multiple protocol definition files manually maintained; risk of inconsistency between Chromium versions and language bindings.
• Polyglot testing matrix explosion (Medium) — .github/workflows/ci*.yml: Separate CI workflows for each language binding increase maintenance burden and inconsistent test coverage across bindings.
• Centralized browser configuration (Medium) — common/browsers.bzl: Browser versions and capabilities hardcoded in single file; updates require coordination across language bindings.

• .github/workflows/ci.yml and ci-*.yml files (Parallelization) — CI pipeline parallelization limited by orchestration overhead; matrix builds cannot dynamically skip language-specific tests.
• common/devtools/ protocol definition maintenance (Operational) — Manual protocol updates required for each new Chromium version; delays feature parity across language bindings.
• Bazel workspace dependency resolution (Build Performance) — Hermetic build isolation increases compilation time; external dependency downloads cannot be cached efficiently across CI runs.

Bazel build system is non-standard for most contributors: Bazel requires BUILD files throughout, not traditional package managers. Language-specific constraints: Java requires JDK 17+ (not JRE), must set JAVA_HOME. Apple Silicon Macs need Rosetta platform file added to .bazelrc.local. Monorepo versioning: all 6+ language bindings share single version number (avoid breaking changes that affect only one binding). Remote Build Execution (RBE) is configured but not required locally; ci-rbe.yml is separate from ci.yml workflow. WebDriver spec compliance is strict: W3C changes require coordinated updates across all bindings. GitHub Actions secrets (not in repo) required for actual releases (see release.yml).

• W3C WebDriver Protocol — Selenium is built entirely around this standardized protocol; understanding the spec (request/response format, command endpoints, element locator strategies) is essential for contributing to any language binding
• Remote Procedure Call (RPC) Architecture — WebDriver protocol uses JSON-RPC-like messages between client (test code) and server (browser driver); language bindings serialize commands and deserialize responses, requiring understanding of this pattern
• Bazel Build System — The entire monorepo uses Bazel for compilation, testing, and dependency management; you cannot effectively modify or build Selenium without understanding Bazel rules and BUILD files
• Monorepo with Language Bindings — Selenium maintains 6+ synchronized language implementations in a single repository with shared versioning; this requires careful coordination of protocol changes and release cycles across all bindings
• DOM Locator Strategies (XPath, CSS, ID, etc.) — WebDriver commands rely on element location strategies; Selenium's locator handling differs subtly across browsers and language bindings, requiring testing of edge cases
• CI/CD with GitHub Actions and Remote Build Execution (RBE) — Development workflow is heavily automated via 47+ GitHub Actions workflows; understanding RBE (ci-rbe.yml vs ci.yml split) helps with debugging build failures across language bindings
• Cross-Browser Driver Management — Selenium abstracts differences between chromedriver, geckodriver, safaridriver, etc.; WebDriver implementations must handle driver discovery, version compatibility, and capability negotiation

• appium/appium — Mobile automation framework that extends WebDriver specification for iOS/Android; shares protocol design philosophy and complements Selenium for mobile testing
• cypress-io/cypress — Alternative browser automation for JavaScript/Node; directly competes with Selenium for modern web testing use cases
• puppeteer/puppeteer — Headless Chrome automation library; narrower scope than Selenium but popular for Node.js developers wanting lighter-weight automation
• SeleniumHQ/seleniumhq.github.io — Official Selenium documentation site and user manual; critical companion for users of this codebase
• w3c/webdriver — W3C WebDriver specification repository; canonical source for protocol requirements that Selenium implements

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 comprehensive GitHub Actions workflow for WebDriver specification compliance testing

The repo has language-specific CI workflows (ci-java.yml, ci-python.yml, ci-ruby.yml, ci-rust.yml, ci-dotnet.yml) but lacks a dedicated workflow that validates W3C WebDriver spec compliance across all bindings. This would ensure consistency with the spec mentioned in the README and catch breaking changes early. A new workflow could run spec validation tests against a test server, similar to how web-platform-tests works.

• [ ] Create .github/workflows/ci-webdriver-spec.yml to run W3C spec compliance tests
• [ ] Reference existing test infrastructure in java/, py/, rb/, rust/, dotnet/ directories for spec test runners
• [ ] Integrate with existing ci.yml workflow to ensure it runs on PRs targeting trunk
• [ ] Document the new workflow in CONTRIBUTING.md (if exists) or README

Implement Bazel build validation for undocumented BUILD file patterns

The repo uses Bazel extensively (.bazelrc, .bazelversion, .bazelignore present) with language-specific CI workflows, but there's no dedicated workflow to validate that all new code properly integrates with the Bazel build system. This prevents broken build configurations from merging. Add a workflow that runs bazel build //... and bazel test //... to catch misconfigured BUILD files early.

• [ ] Create .github/workflows/ci-bazel-validation.yml with comprehensive build/test targets
• [ ] Reference .bazelrc and .bazelrc.remote for RBE configuration (existing ci-rbe.yml suggests RBE is used)
• [ ] Ensure the workflow validates cross-platform targets (Linux, macOS, Windows) using Bazel's platform definitions
• [ ] Add a job to check for missing BUILD files in directories that lack them

Add missing test coverage for GitHub issue template and release automation workflows

The repo has sophisticated GitHub automation (.github/issue-labeler-config.yml, .github/pr-labeler-config.yml, .github/label-commenter-config.yml, multiple release/prelease workflows) but no validation that these configs are syntactically valid or that label definitions are consistent. Add a lightweight linting workflow that validates YAML structure and ensures referenced labels exist in repository settings.

• [ ] Create .github/workflows/ci-github-config.yml to validate all .github/issue_template and config files
• [ ] Add YAML schema validation for issue-labeler-config.yml, pr-labeler-config.yml, and label-commenter-config.yml
• [ ] Cross-reference labels used in these configs against a canonical list (in a new .github/labels.yml or similar)
• [ ] Run this validation on PRs that modify any .github/ configuration files

• Add missing test coverage for new WebDriver protocol features in one language binding (e.g., Python py/selenium/webdriver/test/); most language-specific features lack cross-binding test parity
• Improve error messages in language-specific exception handling (java/src/org/openqa/selenium/WebDriverException.java, py/selenium/common/exceptions.py); currently generic and hard to debug for users
• Document Bazel build commands and troubleshooting in CONTRIBUTING.md with language-specific examples; many contributors unfamiliar with Bazel instead of Maven/pip/npm

The Selenium project demonstrates a mature open-source security posture with established CI/CD workflows, version control practices, and contributor guidelines. However, several areas require attention: (1) Lack of visibility into actual dependency files prevents comprehensive vulnerability assessment across multiple languages (Java, Python, Ruby, Rust, .NET); (2) GitHub Actions workflows require security audit to prevent secret exposure; (3) Configuration files in .idea/ and devcontainer should be validated for sensitive data; (4) Security headers and web component hardening should be verified. No critical vulnerabilities were identified in the visible file structure, but the absence of dependency manifests means vulnerable packages

• Medium · Potential Exposure of Configuration Files — .idea/*, .editorconfig, .gitpod.yml, .devcontainer/. The repository contains IDE configuration files (.idea directory) and environment-specific files (.editorconfig, .gitpod.yml, .devcontainer) that may contain sensitive information or expose development environment details. While git attributes suggest some filtering, IDE configs could be committed with sensitive paths or credentials. Fix: Ensure all sensitive configuration files are properly gitignored. Review .idea/ directory contents for any hardcoded credentials or paths. Consider using environment variable substitution for sensitive configuration in devcontainer and gitpod files.
• Medium · Missing Security Headers Configuration — Infrastructure/Web server configuration files (not visible in provided structure). No evidence of security headers configuration (Content-Security-Policy, X-Frame-Options, etc.) in the visible file structure. Selenium is a browser automation framework that may be used to interact with web applications, but the infrastructure itself may lack security hardening. Fix: Implement security headers in any web-facing components. Configure CSP, HSTS, X-Frame-Options, and other protective headers. Review GitHub Actions workflows for any exposed secrets in logs.
• Medium · GitHub Actions Workflows Require Security Audit — .github/workflows/*.yml. Multiple GitHub Actions workflows are present (.github/workflows/). These could potentially expose secrets through environment variables, build logs, or artifact uploads. No visibility into the actual workflow content provided. Fix: Audit all workflow files to ensure: (1) Secrets are not logged, (2) Artifacts are properly restricted, (3) Third-party actions are pinned to specific versions, (4) OIDC token permissions are minimal, (5) No sensitive data in environment variables passed between steps.
• Medium · Dependency Management Visibility Gap — Dependencies across multiple languages (Maven, pip, Gemfile, Cargo, NuGet). Multiple programming languages are supported (Java, Python, Ruby, Rust, .NET) based on CI workflows, but no dependency manifests were provided for analysis. Unable to detect outdated or vulnerable dependencies. Fix: Implement automated dependency scanning using tools like Dependabot, OWASP Dependency-Check, or Snyk. Enable security advisories on the GitHub repository. Regularly audit and update transitive dependencies.
• Low · Repository Uses Bazel Build System — .bazelrc, .bazelrc.remote, .bazelversion. The project uses Bazel (.bazelrc, .bazelversion, BUILD.bazel files). While Bazel is generally secure, the .bazelrc and .bazelrc.remote files could potentially contain credentials for remote caching or build systems. Fix: Ensure .bazelrc.remote and .bazelrc do not contain hardcoded credentials. Use credential helpers or environment variables for remote caching authentication. Keep .bazelversion pinned to prevent unexpected build tool changes.
• Low · NPM Configuration File Present — .npmrc. The presence of .npmrc suggests npm package management. This file could contain authentication tokens if misconfigured. Fix: Verify .npmrc does not contain hardcoded npm authentication tokens. Use ~/.npmrc or environment variables (NPM_TOKEN) for CI/CD authentication instead. Add .npmrc to .gitignore if it contains sensitive data.
• Low · PR Agent Configuration File — .pr_agent.toml. The .pr_agent.toml file suggests automated PR analysis tools. Configuration files for such tools may contain API keys or other sensitive settings. Fix: Review .pr_agent.toml to ensure it does not contain hardcoded API keys, credentials, or other sensitive information. Use GitHub Secrets for any sensitive configuration in CI workflows.

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/SeleniumHQ/selenium 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 SeleniumHQ/selenium repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/SeleniumHQ/selenium.

What it runs against: a local clone of SeleniumHQ/selenium — 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 SeleniumHQ/selenium | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch trunk 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 SeleniumHQ/selenium. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/SeleniumHQ/selenium.git
#   cd selenium
#
# 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 SeleniumHQ/selenium and re-run."
  exit 2
fi

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

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

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

# 4. Critical files exist
test -f "BUILD.bazel" \\
  && ok "BUILD.bazel" \\
  || miss "missing critical file: BUILD.bazel"
test -f "WORKSPACE" \\
  && ok "WORKSPACE" \\
  || miss "missing critical file: WORKSPACE"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f ".github/workflows/ci.yml" \\
  && ok ".github/workflows/ci.yml" \\
  || miss "missing critical file: .github/workflows/ci.yml"
test -f "common/defs.bzl" \\
  && ok "common/defs.bzl" \\
  || miss "missing critical file: common/defs.bzl"

# 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/SeleniumHQ/selenium"
  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.