GO — Healthy across the board

• Last commit today
• 42+ active contributors
• Distributed ownership (top contributor 13% of recent commits)
• Other licensed
• CI configured
• Tests present
• ⚠ Non-standard license (Other) — review terms

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

n8n is a fair-code, self-hostable workflow automation platform built in TypeScript that lets users visually connect 400+ services (HTTP, databases, SaaS APIs) and inject custom JavaScript/Python code at any node. It ships native LangChain-based AI agent capabilities, meaning users can build RAG pipelines, tool-calling agents, and chat interfaces directly inside workflows without leaving the platform. This is a pnpm monorepo where packages/cli is the main runnable server, packages/core holds the workflow execution engine, and packages/nodes-base contains all 400+ integration node implementations. The frontend editor lives as a Vue 3 SPA (large Vue codebase at ~6.9MB), agent/skill documentation for AI-assisted development is under .agents/skills/, and infrastructure/CI config is at the repo root (.actrc, HCL files).

DevOps engineers, backend developers, and technical teams who need Zapier/Make-level automation but require self-hosting for data sovereignty, want to write real code inside automations, or are building LLM-powered internal tools. Also targets open-source contributors familiar with TypeScript monorepos adding new integration nodes.

n8n is production-ready and extremely actively developed — it has hundreds of thousands of self-hosted deployments, a cloud offering at app.n8n.cloud, enterprise licensing, SSO, and air-gapped deployment support. The repo has a mature CI setup (.actrc, HCL infrastructure config), comprehensive test scaffolding (mutation health scripts, SBOM/license compliance checks), and an organized agent/skill documentation system under .agents/. Commit activity and the breadth of tooling (cdxgen for SBOM, conventional-changelog) indicate a professional engineering team.

The dependency surface is enormous — 400+ integrations means hundreds of third-party API client libraries, and the SBOM generation pipeline (scripts/licenses/) exists precisely because license compliance is a real risk at this scale. The fair-code Sustainable Use License is non-standard OSI licensing, which can be a blocker for embedding n8n in commercial products without an Enterprise License. Tight coupling between the visual frontend (Vue/SCSS) and the workflow engine (TypeScript core) means frontend and backend changes often need to be coordinated across packages.

Active work is visible in the .agents/ skill system — recently added skills include db-migrations, protect-endpoints, node-add-oauth, spec-driven-development, and experiments, suggesting the team is investing in AI-assisted engineering workflows for contributors. The .claude/plugins/n8n directory shows integration with Claude for developer tooling. License compliance automation (SBOM via cdxgen, enrich-sbom, render-licenses-md) appears to be a recent addition given its dedicated scripts.

git clone https://github.com/n8n-io/n8n.git cd n8n corepack enable pnpm install pnpm build pnpm start

Editor available at http://localhost:5678

Or for quick trial without cloning:

npx n8n

Daily commands:

Development mode with hot reload:

pnpm dev

Run specific package:

pnpm --filter @n8n/cli dev

Run tests:

pnpm test

Docker:

docker volume create n8n_data && docker run -it --rm --name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n

• .github/CLAUDE.md — Primary contributor guide describing coding conventions, PR process, and architectural decisions every contributor must follow.
• .agents/skills/conventions/SKILL.md — Defines enforced code conventions and patterns used across the entire n8n codebase that all contributors must adhere to.
• .agents/skills/db-migrations/SKILL.md — Critical guide for writing database migrations correctly, since incorrect migrations can corrupt production data.
• .agents/skills/protect-endpoints/SKILL.md — Documents the required security patterns for protecting API endpoints, essential for any backend contributor.
• .github/CODEOWNERS — Defines which teams own which parts of the codebase, determining who must review any given PR.
• .github/actions/ci-filter/ci-filter.mjs — Core CI filtering logic that determines which tests and pipelines run for a given change, affecting all contributor feedback loops.
• .agents/skills/experiments/SKILL.md — Describes how feature flags and experiments are managed, critical for any feature work that needs gradual rollout.

• CLI / Backend (Node.js, TypeScript, Express) — Hosts the REST API, workflow engine, execution queue, and all business logic.
  • Failure mode: API unavailable; workflows cannot be triggered or managed.
• Editor UI (Vue.js, TypeScript) — Visual workflow builder frontend that communicates with the backend API.
  • Failure mode: Users cannot create or modify workflows but existing automated executions continue.
• Core nodes package (TypeScript) — Contains all 400+ built-in integration node definitions and executors.
  • Failure mode: Specific integrations fail; other nodes continue to work.
• Workflow engine (TypeScript, in-process) — Parses workflow graphs and orchestrates node execution order including error handling.
  • Failure mode: All workflow executions fail or produce incorrect results.
• Database layer (TypeScript, TypeORM, SQLite/PostgreSQL/MySQL) — Persists workflows, credentials, execution history, and user data.
  • Failure mode: Data loss or inability to load workflows; complete platform outage.
• AI/LangChain layer (LangChain, TypeScript) — Provides LLM-powered agent nodes and AI tool integrations within workflows.
  • Failure mode: AI workflow nodes fail; non-AI workflows unaffected.

• External trigger (webhook/schedule) → CLI API server — Incoming HTTP request or timer event initiates a workflow execution.
• CLI API server → Workflow engine — Execution request is passed with workflow definition and input data.
• Workflow engine → Node executors — Each node is executed in DAG order, passing output data as input to the next.
• Node executors → External APIs / LLMs — Integration nodes make authenticated HTTP calls to third-party services.
• Workflow engine → Database — Execution results, logs, and status are persisted for history and debugging.
• Editor UI → CLI API server — User actions (save workflow, view executions) are sent via REST API calls.

Add a new n8n integration node

1. Review OAuth patterns if the service requires OAuth authentication (.agents/skills/node-add-oauth/SKILL.md)
2. Create a lint rule for community node if publishing externally (.agents/skills/create-community-node-lint-rule/SKILL.md)
3. Ensure PR meets community readiness standards before submitting (.agents/skills/community-pr-readiness-check/SKILL.md)

Add a new API endpoint

1. Follow endpoint protection patterns to add authentication and authorization guards (.agents/skills/protect-endpoints/SKILL.md)
2. Follow general coding conventions for controller and service structure (.agents/skills/conventions/SKILL.md)
3. Add any required database migration following safe migration patterns (.agents/skills/db-migrations/SKILL.md)

Add a new feature with gradual rollout

1. Create a feature flag/experiment following the experiments framework (.agents/skills/experiments/SKILL.md)
2. Follow coding conventions when implementing the feature code (.agents/skills/conventions/SKILL.md)
3. Create a PR following the standard PR creation process (.agents/skills/create-pr/SKILL.md)

Add a database schema change

1. Read the DB migration skill to understand safe forward/backward migration patterns (.agents/skills/db-migrations/SKILL.md)
2. Verify CI filter will run relevant database migration tests for your change (.github/actions/ci-filter/ci-filter.mjs)
3. Submit PR and verify code ownership review requirements are satisfied (.github/CODEOWNERS)

• TypeScript — Provides type safety across a large monorepo with complex data models shared between frontend and backend.
• pnpm workspaces — Manages the monorepo with efficient dependency deduplication across 400+ integration packages.
• LangChain — Powers native AI agent workflow capabilities with a standardized abstraction over multiple LLM providers.
• Docker — Enables consistent self-hosted deployments and reproducible dev environments via dev containers.
• GitHub Actions — CI/CD with intelligent path-based filtering to avoid running unnecessary test suites on large PRs.

• Fair-code license instead of fully open-source

  • Why: Allows sustainable development by restricting commercial use without a license while keeping code visible.
  • Consequence: Community forks cannot be used commercially, which may reduce some external contributions.

• Monorepo structure for all packages

  • Why: Simplifies cross-package refactoring and ensures type compatibility between core, nodes, and UI packages.
  • Consequence: CI times are longer and require intelligent filtering to remain manageable at scale.

• Self-hostable with cloud option

  • Why: Targets technical teams who need data sovereignty while also offering managed hosting for simplicity.
  • Consequence: Feature development must consider both deployment models, increasing complexity for infrastructure features.

• Agent/skill-based developer tooling embedded in repo

  • Why: Codifies institutional knowledge about conventions and patterns to assist AI-powered development workflows.
  • Consequence: Adds maintenance burden to keep skill files updated as the codebase evolves.

• Not a real-time streaming data processing platform (batch/event-driven execution only)
• Does not provide its own authentication identity provider (integrates with external SSO/SAML providers)
• Does not build or host the 400+ third-party integration services it connects to
• Not a general-purpose programming environment — code execution is sandboxed within workflow nodes only

• Avg cyclomatic complexity: ~4 — The visible file list is dominated by configuration, documentation, and agent skill markdown files rather than complex application logic; actual workflow engine code complexity is not visible in this file set.
• Largest file: .github/actions/ci-filter/ci-filter.mjs (400 lines)
• Estimated quality issues: ~3 — Potential skill/plugin duplication, CI filter manual maintenance burden, and risk of agent skill documentation drift are the primary quality concerns visible from the file structure.

• Skill documentation drift (Medium) — .agents/skills/: Agent skill files may fall out of sync with actual codebase conventions as the code evolves, causing AI assistants to give outdated guidance.
• Monorepo CI scope creep (High) — .github/actions/ci-filter/ci-filter.mjs: As the repo grows, the CI filter mapping must be manually maintained; missing mappings cause under-testing of changes.
• Duplicated plugin/skill definitions (Low) — .claude/plugins/n8n/skills/: Skills are symlinked or duplicated between .agents/skills/ and .claude/plugins/n8n/skills/, creating a maintenance synchronization risk.

• .github/actions/ci-filter/ci-filter.mjs (Single point of failure) — All CI pipeline decisions flow through this single file; bugs here cause incorrect test execution across the entire repo.
• .agents/skills/db-migrations/SKILL.md (Deployment bottleneck) — Database migrations are a serialized, irreversible operation that blocks deployments if they fail on large datasets.

1. pnpm is required (not npm/yarn) — use corepack enable before installing. 2) Many nodes require external service credentials to test; there's no universal mock layer, so integration tests need real API keys or careful mocking. 3) The Sustainable Use License means forking for commercial redistribution requires an Enterprise License — check before building a product on top. 4) The SBOM pipeline (pnpm generate-licenses) requires the compiled/ directory to exist, so it must run after pnpm build. 5) Node.js version is constrained — check .node-version or engines field in root package.json before switching Node versions.

• Fair-code License — n8n uses the Sustainable Use License, not MIT/Apache — understanding fair-code is essential before embedding or redistributing this platform commercially.
• LangChain Tool-Calling Agents — n8n's AI nodes are built on LangChain.js agent abstractions; understanding how tool-calling agents loop over actions is needed to build or debug AI workflow nodes.
• CycloneDX SBOM — n8n generates a Software Bill of Materials via cdxgen for license compliance — contributors need to understand SBOM format when adding new dependencies.
• TypeORM Migrations — All database schema changes go through TypeORM migration files; running migrations out of order or skipping them corrupts user data in self-hosted deployments.
• Webhook Trigger Nodes — n8n supports two execution modes per node (poll vs. webhook); understanding the webhook lifecycle (register, receive, deregister) is non-obvious and required for real-time trigger integrations.
• pnpm Workspaces — The monorepo uses pnpm workspaces with strict hoisting rules — running npm or yarn instead of pnpm breaks symlinks between internal packages like @n8n/core and @n8n/cli.
• Mutation Testing — The repo includes mutation health scripts (scripts/mutation-health/) to measure test suite effectiveness — understanding mutation scores helps evaluate whether new tests actually catch regressions.

• zapier/zapier-platform — Direct commercial competitor — the SDK for building Zapier integrations, useful for comparing node/integration architecture patterns.
• activepieces/activepieces — Open-source alternative to n8n with similar self-hostable workflow automation, also TypeScript-based, useful for benchmarking feature parity.
• langchain-ai/langchainjs — n8n's AI agent nodes are built on LangChain.js — understanding this repo is essential for working on AI-native workflow nodes.
• n8n-io/n8n-nodes-starter — Official template repo for building community nodes — the canonical starting point for external node developers targeting this platform.
• temporalio/temporal — Inspiration/predecessor pattern for durable workflow execution — n8n's core execution engine solves overlapping problems around reliable task orchestration.

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 SBOM license enrichment and rendering scripts

The repo has test infrastructure in workflow-scripts covering stale, slack, and quality checks, but the license pipeline scripts (enrich-sbom.mjs, render-licenses-md.mjs, check-sbom-licenses.mjs under ../../scripts/licenses/) only have partial test coverage based on the test glob pattern. These scripts are critical for compliance reporting yet a bug in them could silently produce incorrect THIRD_PARTY_LICENSES.md or miss license violations. Adding targeted unit tests with mocked CycloneDX JSON fixtures would catch regressions in the license compliance pipeline before it hits CI.

• [ ] Inspect scripts/licenses/enrich-sbom.mjs, render-licenses-md.mjs, and check-sbom-licenses.mjs to map all exported functions and edge-case branches (e.g. missing license refs, unknown SPDX expressions, --allow-ref flag handling)
• [ ] Create fixture files (e.g. scripts/licenses/__fixtures__/sample.cdx.json) with minimal valid and intentionally malformed CycloneDX 1.6 payloads to drive the tests
• [ ] Write scripts/licenses/enrich-sbom.test.mjs, render-licenses-md.test.mjs, and check-sbom-licenses.test.mjs using Node's built-in --experimental-test-module-mocks pattern already used in the repo (see the test script in workflow-scripts/package.json)
• [ ] Ensure the new test files are picked up by the existing test script glob (../../scripts/licenses/*.test.mjs is already listed) so no CI changes are needed
• [ ] Verify edge cases: duplicate components, LicenseRef-n8n-sustainable-use and LicenseRef-n8n-enterprise allow-listing, components with no license, and output Markdown structure for THIRD_PARTY_LICENSES.md

Extract and modularize the community-PR-readiness-check skill into discrete, testable modules

The community PR readiness check under .agents/skills/community-pr-readiness-check/ is split across four reference markdown files (checks.md, label-flow.md, re-review.md, teams.md) and a single SKILL.md entry point. The actual GitHub Actions workflow logic that consumes these rules lives as a monolithic script. Splitting the label-flow and checks logic into separate importable JS/TS modules with unit tests would make the automation far easier to maintain, extend (e.g. adding a new label rule), and verify without triggering real GitHub API calls.

• [ ] Read .agents/skills/community-pr-readiness-check/reference/checks.md and label-flow.md to enumerate every discrete rule (e.g. 'has breaking change label', 'linked issue present', 'team routing logic')
• [ ] Create workflow-scripts/community-pr-readiness-check/checks.mjs and label-flow.mjs that export pure functions implementing each rule, taking a plain PR-data object so they are testable without network I/O
• [ ] Write workflow-scripts/community-pr-readiness-check/checks.test.mjs and label-flow.test.mjs using the repo's existing Node test runner pattern; use --experimental-test-module-mocks to stub @actions/github and @octokit/core
• [ ] Add the new test files to the glob in workflow-scripts/package.json (e.g. ./community-pr-readiness-check/*.test.mjs)
• [ ] Update the consuming GitHub Actions workflow or SKILL.md to import from the new modules instead of inline logic, and document the module API in .agents/skills/community-pr-readiness-check/SKILL.md

Add a GitHub Actions workflow to

undefined

1. Add missing test coverage for scripts/licenses/enrich-sbom.mjs — the test suite in workflow-scripts only covers check-sbom-licenses and render-licenses-md, leaving enrich-sbom untested. 2) Extend the .agents/skills/reproduce-bug/SKILL.md with a concrete example workflow showing how to isolate a failing execution in packages/core — currently the skill exists but the reference examples directory is sparse compared to community-pr-readiness-check. 3) Add a SKILL.md under .agents/skills/ for 'add-webhook-trigger' — the node-add-oauth skill exists but there's no equivalent guide for the very common pattern of adding webhook-based trigger nodes, which is a frequent community contribution type.

• Medium · Outdated/Pinned Dependencies with Potential Known CVEs — .github/workflows/scripts/package.json. Several dependencies are pinned to specific versions that may contain known vulnerabilities. Notably: @actions/github@9.0.0, @octokit/core@7.0.6, conventional-changelog@7.2.0, and debug@4.4.3. While these appear to be recent versions, pinning without regular auditing creates risk. The 'debug' package has historically had ReDoS vulnerabilities in older versions. The semver@7.7.4 package should be verified against recent advisories. Fix: Run 'pnpm audit' regularly against the dependency tree. Enable automated dependency update tooling (Dependabot or Renovate). Consider using 'pnpm audit --fix' in CI pipelines to catch newly disclosed CVEs before they reach production.
• Medium · brace-expansion Override May Mask Transitive Vulnerability — .github/workflows/scripts/package.json (pnpm.overrides). The pnpm overrides section forces 'brace-expansion@5' to '^5.0.5', suggesting a known vulnerability exists in the default resolved version of this transitive dependency. Using an override is a valid workaround but signals the dependency tree contains at least one package pulling in a vulnerable version of brace-expansion. If the override is ever removed or the range is resolved incorrectly, the vulnerable version could re-enter. Fix: Document why the override exists (reference the CVE or advisory). Ensure the override is tested in CI. Once upstream packages release fixes, remove the override and rely on direct dependency resolution. Monitor glob@13.0.6 and minimatch@10.2.4 which are common consumers of brace-expansion.
• Medium · Potential Secret Exposure via .env.local.example and CI Configuration — .env.local.example. The presence of '.env.local.example' in the repository root indicates environment variables (potentially including secrets, API keys, database credentials) are used in the project. If the actual '.env.local' or similar files are accidentally committed, or if the example file reveals the structure of secrets expected by the application, it aids reconnaissance by attackers. Fix: Ensure .env, .env.local, and all secret-containing environment files are listed in .gitignore. Audit git history for accidental secret commits using tools like git-secrets or trufflehog. Use a secrets manager (e.g., Vault, AWS Secrets Manager) rather than file-based secrets in production deployments.
• Medium · SBOM Generation Fetches External License Data at Build Time — .github/workflows/scripts/package.json (scripts.generate-sbom). The 'generate-sbom' script uses 'FETCH_LICENSE=true' with cdxgen, which causes the tool to make outbound HTTP requests to external registries/services during the build process. This introduces supply chain risk: a compromised or spoofed external endpoint could inject malicious license metadata, and build systems with outbound network access are a wider attack surface. Fix: Run SBOM generation in an isolated environment. Consider caching license data locally and using FETCH_LICENSE=false in air-gapped or security-sensitive build pipelines. Validate the integrity of the generated SBOM before publishing.
• Low · AI Agent Skill Files May Contain Sensitive Operational Context — .agents/skills/, .claude/plugins/n8n/skills/. The repository contains numerous agent skill definition files under '.agents/skills/' and '.claude/plugins/n8n/' including skills like 'protect-endpoints', 'db-migrations', and 'node-add-oauth'. These SKILL.md and reference files may contain internal architectural details, security controls, endpoint naming conventions, or OAuth flow details that could assist an attacker in understanding the internal security model of the platform. Fix: Review all SKILL.md and reference markdown files to ensure they do not contain sensitive implementation details, internal endpoint paths, credential formats, or security bypass information. Consider whether these files need to be public or should be restricted to internal repositories.
• Low · Claude AI Plugin Configuration Exposed in Repository — .claude. The '.claude/plugins/n8n/' directory contains plugin configuration files including 'marketplace.json' and 'plugin.json'. If these files reference API keys, webhook URLs, internal service endpoints, or authentication tokens for AI integrations, they represent a credential exposure risk. Even without direct credentials, exposing AI plugin marketplace configuration may reveal integration architecture. 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/n8n-io/n8n 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 n8n-io/n8n repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/n8n-io/n8n.

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

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

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

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

# 4. Critical files exist
test -f ".github/CLAUDE.md" \\
  && ok ".github/CLAUDE.md" \\
  || miss "missing critical file: .github/CLAUDE.md"
test -f ".agents/skills/conventions/SKILL.md" \\
  && ok ".agents/skills/conventions/SKILL.md" \\
  || miss "missing critical file: .agents/skills/conventions/SKILL.md"
test -f ".agents/skills/db-migrations/SKILL.md" \\
  && ok ".agents/skills/db-migrations/SKILL.md" \\
  || miss "missing critical file: .agents/skills/db-migrations/SKILL.md"
test -f ".agents/skills/protect-endpoints/SKILL.md" \\
  && ok ".agents/skills/protect-endpoints/SKILL.md" \\
  || miss "missing critical file: .agents/skills/protect-endpoints/SKILL.md"
test -f ".github/CODEOWNERS" \\
  && ok ".github/CODEOWNERS" \\
  || miss "missing critical file: .github/CODEOWNERS"

# 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/n8n-io/n8n"
  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.