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/jeequan/jeepay 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.

WAIT — Mixed signals — read the receipts

• Last commit 2w ago
• 6 active contributors
• LGPL-3.0 licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 50% of recent commits
• ⚠ LGPL-3.0 is copyleft — check downstream compatibility

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

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

What it runs against: a local clone of jeequan/jeepay — 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 jeequan/jeepay | Confirms the artifact applies here, not a fork | | 2 | License is still LGPL-3.0 | 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 ≤ 45 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of jeequan/jeepay. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/jeequan/jeepay.git
#   cd jeepay
#
# 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 jeequan/jeepay and re-run."
  exit 2
fi

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(LGPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"LGPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is LGPL-3.0" \\
  || miss "license drift — was LGPL-3.0 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 "jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/model/AbstractMQ.java" \\
  && ok "jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/model/AbstractMQ.java" \\
  || miss "missing critical file: jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/model/AbstractMQ.java"
test -f "jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/vender/IMQSender.java" \\
  && ok "jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/vender/IMQSender.java" \\
  || miss "missing critical file: jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/vender/IMQSender.java"
test -f "jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/vender/IMQMsgReceiver.java" \\
  && ok "jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/vender/IMQMsgReceiver.java" \\
  || miss "missing critical file: jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/vender/IMQMsgReceiver.java"
test -f "jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/constant/MQVenderCS.java" \\
  && ok "jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/constant/MQVenderCS.java" \\
  || miss "missing critical file: jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/constant/MQVenderCS.java"
test -f "jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/vender/activemq/ActiveMQConfig.java" \\
  && ok "jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/vender/activemq/ActiveMQConfig.java" \\
  || miss "missing critical file: jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/vender/activemq/ActiveMQConfig.java"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 45 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~15d)"
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/jeequan/jeepay"
  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).

Jeepay is an open-source payment aggregation system for Chinese internet enterprises, built on Spring Boot 3.3.7 + JDK 17. It consolidates WeChat Pay, Alipay, UnionPay (UPACP), and QR code payments into a single platform supporting merchant mode, multi-channel service provider mode, and SaaS payment middleware with pluggable MQ backends (RocketMQ, ActiveMQ, RabbitMQ). Monorepo structure: core payment engine at jeepay-core, pluggable MQ abstraction layer at jeepay-components/jeepay-components-mq, three deployable applications (conf/manager for admin, conf/merchant for merchant UI, conf/payment for payment kernel). Separate docker/ directory with Compose templates for local + cloud deployments (baota.yml, swr-*.yml for Huawei Cloud SWR).

Platform operators and fintech companies building self-hosted payment infrastructure without reliance on third-party aggregators; merchants needing white-label multi-channel settlement; second-stage developers maintaining long-term payment systems. Originally built by the XxPay team with deep payment industry expertise.

Production-ready and actively maintained. The codebase shows mature architecture (1.8M+ lines of Java), Docker/Kubernetes-native deployment patterns, multi-environment configs (dev/test/prod), and CI/CD via GitHub Actions. Recent commits and Docker build tooling indicate active development. However, issue visibility on GitHub/Gitee is not quantified in provided data.

Moderate risk: the system mandates MQ infrastructure (no in-process option), making deployment non-trivial for smaller deployments. Heavy Chinese market targeting means documentation and API contracts are primarily in Mandarin. Single organizational steward (jeequan team) creates centralization risk. JDK 17+ requirement excludes legacy environments. Spring Boot 3.3.7 is current but requires Java 17+, constraining container base images.

Active Spring Boot 3.3.7 + JDK 17 migration (shown in badge/config). Docker containerization and multi-MQ abstraction layer refinement (RabbitMQ moved to scope=provided, suggesting decoupling from specific vendors). CI/CD pipeline exists (.github/workflows/ci.yml). Deployment documentation expanded (6 docs/deploy/*.md files covering shell, Docker, HTTPS, baota, compose, troubleshooting).

git clone https://github.com/jeequan/jeepay.git
cd jeepay
mvn clean install -DskipTests
# For Docker-based dev environment:
docker-compose -f docker-compose.yml up -d
# Or shell-based install on CentOS/Debian:
bash docs/install/config.sh

Daily commands: Local dev: mvn spring-boot:run -pl jeepay-payment for payment service (listens default 8080); mvn spring-boot:run -pl jeepay-merchant for merchant dashboard. Production: Use provided Docker Compose (docker-compose.yml) or shell scripts (docs/deploy/shell.md). All three apps (manager, merchant, payment) deploy independently; payment service is the core and must run first. Requires MySQL 5.7+, Redis 5.0+, and chosen MQ broker.

• jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/model/AbstractMQ.java — Base abstraction for all MQ message models; all custom messages inherit from this class, making it essential for understanding the message contract
• jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/vender/IMQSender.java — Core interface defining the contract for message sending across all MQ vendors (ActiveMQ, RocketMQ); any new vendor integration requires implementing this
• jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/vender/IMQMsgReceiver.java — Core interface for message receiving; all vendor-specific receivers implement this abstraction
• jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/constant/MQVenderCS.java — Constants defining supported MQ vendors and their configurations; critical for understanding available message broker options
• jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/vender/activemq/ActiveMQConfig.java — ActiveMQ broker configuration and bean setup; demonstrates the pattern for vendor-specific initialization
• jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/vender/aliyunrocketmq/AliYunRocketMQFactory.java — RocketMQ factory and initialization; shows the production-grade vendor integration pattern with connection pooling
• jeepay-components/jeepay-components-mq/pom.xml — Maven POM defining dependencies and build configuration; required to understand external library versions and build process

Add a new MQ message type

1. Create a new Java class extending AbstractMQ in the mq/model directory (jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/model/AbstractMQ.java)
2. Define the message payload fields and constructor matching existing message classes like PayOrderMchNotifyMQ (jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/model/PayOrderMchNotifyMQ.java)
3. Create receiver implementations for each vendor (ActiveMQ and RocketMQ) following the pattern in existing receivers (jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/vender/activemq/receive/PayOrderMchNotifyActiveMQReceiver.java)
4. Register the new message type in MQVenderCS constants with topic/queue names (jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/constant/MQVenderCS.java)

Add support for a new MQ vendor

1. Create a new vendor directory under jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/vender/ (jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/vender/activemq/ActiveMQConfig.java)
2. Implement IMQSender interface with vendor-specific sender logic (jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/vender/IMQSender.java)
3. Create concrete receiver classes for each message type by extending a vendor-specific abstract receiver (jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/vender/aliyunrocketmq/AbstractAliYunRocketMQReceiver.java)
4. Add vendor initialization in Spring configuration (similar to ActiveMQConfig) and register in MQVenderCS (jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/constant/MQVenderCS.java)
5. Add Maven dependencies for the new vendor to pom.xml (jeepay-components/jeepay-components-mq/pom.xml)

Implement a custom message receiver

1. Choose the target vendor and extend the appropriate abstract receiver (e.g., AbstractAliYunRocketMQReceiver for RocketMQ) (jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/vender/aliyunrocketmq/AbstractAliYunRocketMQReceiver.java)
2. Implement the receiveMsg(MQModel msg) method with business logic to handle the message type (jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/vender/aliyunrocketmq/receive/PayOrderMchNotifyAliYunRocketMQReceiver.java)
3. Configure the consumer group and topic/queue subscription in the constructor (jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/constant/MQVenderCS.java)
4. Register the receiver as a Spring component using @Component annotation to enable auto-instantiation (jeepay-components/jeepay-components-mq/src/main/java/com/jeequan/jeepay/components/mq/vender/activemq/receive/PayOrderMchNotifyActiveMQReceiver.java)

MQ is mandatory: No in-memory queue fallback; payment service crashes if MQ broker unreachable (no graceful degradation). Java 17+ hard requirement: Cannot run on Java 11 or lower despite Spring Boot 3.3.7's theoretical support; Docker base images must be openjdk:17-slim or later. Dual environment config: MySQL, Redis, and MQ broker connection strings are environment-specific in .env.example and per-app application.yml files; mixing configs across dev/test/prod causes data leaks. Payment channel credentials unencrypted in config: WeChat AppID/Secret and Alipay MKEY are stored in application.yml as plaintext; must rotate before prod deploy. Chinese default: Documentation, error messages, and audit logs default to Mandarin; non-Chinese operators need translation layer. Monorepo Maven structure: Three separate apps share jeepay-core but don't inherit transitive deps cleanly; local mvn install of core required before building payment/merchant apps.

• Service Provider Model (SPM) Payment Splitting — Jeepay's core differentiation: one payment processor can serve multiple merchant sub-accounts with split settlement; critical for understanding multi-tenant merchant isolation and commission flow in jeepay-core
• Idempotent Payment Webhook (At-Least-Once Delivery) — Payment callbacks from WeChat/Alipay can arrive multiple times; Jeepay uses MQ + idempotency keys in settlement to prevent double-charging (see async payment event patterns in jeepay-components-mq)
• QR Code Aggregation (聚合码) — Jeepay supports single static QR code that accepts WeChat/Alipay/UnionPay payments; requires channel routing logic based on payment method detected by scanner, not merchant selection
• Event-Driven Async Settlement via MQ — Payment confirmations are published to RocketMQ/ActiveMQ/RabbitMQ for async settlement workers; decouples payment collection from merchant account crediting and reduces transaction latency on hot path
• Spring Security OAuth 2.0 / JWT Token Management — Merchant API authentication and admin dashboard SSO implemented via Spring Security; understanding token lifecycle and scope restrictions is essential for custom auth extensions in jeepay-payment and jeepay-merchant
• Transactional Outbox Pattern — Payment events must be reliably published to MQ even if database commit fails; Jeepay likely uses outbox table + MQ publisher pattern to guarantee no lost settlement notifications (verify in jeepay-core payment event handling)
• Chinese Payment Gateway API Conventions (WeChat Pay v3, Alipay OpenAPI) — Jeepay abstracts WeChat Pay (API v3 with mTLS), Alipay (RSA signature), and UnionPay (UPACP) behind unified interfaces; each has unique signature schemes and callback formats required to integrate custom channels

• jeequan/jeepay-ui — Official frontend (Ant Design Vue) for merchant dashboard and admin console; consumed by jeepay backend via API endpoints
• longtai-cn/payment-spring-boot-starter — Lightweight Spring Boot payment abstraction layer for multiple Chinese payment gateways; alternative if you don't need full platform + multi-tenant features
• anji-plus/payment — Similar open-source Chinese payment aggregator with WeChat/Alipay support; good for comparative architecture study
• alibaba/spring-cloud-alibaba — Provides RocketMQ Spring integration and service mesh primitives; Jeepay uses RocketMQ for async settlement, this repo offers cloud-native patterns
• spring-projects/spring-boot — Upstream dependency (Spring Boot 3.3.7); Jeepay's architecture relies on Spring Security, Spring Data JPA, and Spring Messaging from this ecosystem

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 MQ provider abstraction layer and unit tests for jeepay-components-mq

The pom.xml shows ActiveMQ, RabbitMQ, and RocketMQ are all included with mixed scope declarations (compile vs provided). There's no visible abstraction layer or factory pattern to switch between MQ providers. Add a provider interface/factory pattern with comprehensive unit tests for each MQ implementation to improve modularity and testability. This is critical since the comment in pom.xml acknowledges Docker/deployment scenarios have dependency issues.

• [ ] Create jeepay-components-mq/src/main/java/com/jeequan/mq/MQProvider.java (interface)
• [ ] Create jeepay-components-mq/src/main/java/com/jeequan/mq/factory/MQProviderFactory.java
• [ ] Create provider implementations: ActiveMQProvider, RabbitMQProvider, RocketMQProvider
• [ ] Add jeepay-components-mq/src/test/java unit tests for each provider with Spring Boot Test
• [ ] Update jeepay-components-mq/pom.xml to properly scope dependencies based on active provider
• [ ] Document provider selection in conf/devCommons/config/application.yml with examples for each MQ type

Create integration tests for payment channel adapters (WeChat, Alipay, UnionPay)

The README mentions integrated payment channels (微信支付, 支付宝, 云闪付) but there's no visible test directory structure. Create integration test suite with mock payment gateway responses for each channel to catch adapter bugs before production and serve as integration documentation.

• [ ] Create docs/test/payment-integration-tests.md documenting test strategy for each channel
• [ ] Add src/test/java/com/jeequan/payment/channel/WeChatPayAdapterIntegrationTest.java with MockRestServiceServer
• [ ] Add src/test/java/com/jeequan/payment/channel/AlipayAdapterIntegrationTest.java with MockRestServiceServer
• [ ] Add src/test/java/com/jeequan/payment/channel/UnionPayAdapterIntegrationTest.java with MockRestServiceServer
• [ ] Create src/test/resources/payment-responses/ with sample JSON responses for each gateway
• [ ] Add GitHub Actions workflow .github/workflows/payment-integration-tests.yml

Add Docker health check configurations and compose validation tests

Multiple docker-compose files exist (docker-compose.yml, docker-compose.baota.yml, docker-compose.swr-*.yml) but there are no HEALTHCHECK directives in the Dockerfiles, and no validation that all compose files are syntactically correct. Add health checks and a CI validation step to prevent deployment issues.

• [ ] Add HEALTHCHECK instruction to docker/activemq/Dockerfile (e.g., checking ActiveMQ web console port 8161)
• [ ] Add HEALTHCHECK instruction to docker/rabbitmq/Dockerfile (e.g., checking RabbitMQ management port 15672)
• [ ] Add HEALTHCHECK instruction to docker/rocketmq/Dockerfile (e.g., checking broker port 10911)
• [ ] Create docs/docker/health-checks.md documenting health check strategy
• [ ] Add GitHub Actions workflow .github/workflows/docker-compose-validation.yml using docker-compose config --quiet
• [ ] Add service dependency waits in docker-compose.yml using depends_on with condition: service_healthy

• Add English i18n for payment channel error messages: WeChat/Alipay/UPACP error responses in jeepay-core/src/main/java/com/jeequan/jeepay/payment/channel/ are translated to Chinese; add parallel English error code mappings and MessageSource bundle files (messages_en_US.properties) so non-Chinese merchants see actionable errors
• Write integration tests for RabbitMQ MQ adapter: jeepay-components-mq pom.xml shows RabbitMQ scope=provided (not compiled by default). Add test case in src/test/ that spins up embedded RabbitMQ (testcontainers), exercises payment event publishing, and verifies settlement async message delivery—mirrors existing ActiveMQ/RocketMQ test patterns
• Document multi-MQ failover strategy: Current docker-compose.yml runs single MQ instance; add architecture doc explaining how to configure RocketMQ HA (broker replication) or RabbitMQ clustering, and update docs/deploy/troubleshooting.md with MQ recovery runbooks (broker down, message queue backlog recovery)

• Critical · Hardcoded Database Credentials in Docker Compose — docker-compose.yml. The docker-compose.yml file contains hardcoded database credentials (MYSQL_ROOT_PASSWORD: 'rootroot', MYSQL_USER: 'jeepay', MYSQL_PASSWORD: 'jeepay') in plain text. These are default weak credentials that should never be used in production. Fix: Use environment variables with strong, randomly generated passwords. Move credentials to .env files (which should be .gitignored) or use Docker secrets for production deployments. Example: MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD} with secure values in .env
• High · Exposed Database Port in Docker Configuration — docker-compose.yml (ports: '13306:3306'). MySQL port 3306 is mapped to host port 13306 without authentication restrictions, making the database potentially accessible from the network. Combined with weak default credentials, this creates a critical attack surface. Fix: In production, do not expose database ports directly to the network. If remote access is required, use a bastion host, VPN, or internal-only networks. Implement network policies and firewall rules to restrict access to the database port.
• High · Incomplete Dependency Configuration - Commented Out Scopes — jeepay-components/jeepay-components-mq/pom.xml. In the pom.xml, several MQ dependencies (ActiveMQ, pooled-jms) have their <scope>provided</scope> commented out, meaning they are included in the compiled JAR. This may cause conflicts or unexpected behavior depending on the deployment environment. RocketMQ comments indicate awareness of this issue but similar pattern exists for ActiveMQ. Fix: Explicitly define and document the dependency scope strategy. Use 'provided' for application server-supplied libraries and 'compile' only when necessary. Document which MQ implementations are production-supported and ensure proper scope management.
• High · Truncated POM File Content — jeepay-components/jeepay-components-mq/pom.xml (truncated). The pom.xml dependency file appears to be truncated mid-dependency (RocketMQ section ends abruptly with '<dependency>\n <groupId>o'), indicating the actual dependency list is incomplete and cannot be fully analyzed for vulnerable packages. Fix: Complete the full pom.xml analysis. Verify all dependencies against known vulnerability databases (CVE, SNYK, Sonatype). Implement automated dependency scanning in CI/CD pipeline using tools like OWASP Dependency-Check, Maven dependency:analyze, or Snyk.
• Medium · Default Spring Boot Versions May Have Known Vulnerabilities — README (Spring Boot 3.3.7, JDK 17). The codebase uses Spring Boot 3.3.7 and Java 17. While these are relatively recent versions, without seeing the complete dependency tree (pom.xml is truncated), it's unclear if all transitive dependencies are kept up-to-date, which could include vulnerable libraries. Fix: Implement regular dependency updates and vulnerability scanning. Use 'mvn dependency:tree' to review transitive dependencies. Set up automated tools (Dependabot, Snyk) to alert on new vulnerabilities. Create a process for regular security patches.
• Medium · Missing .env File in Repository — .env.example. Only .env.example is present in the repository. If developers or CI/CD systems copy this directly without changing credentials, the default values would be used, creating a security risk. Fix: Ensure .env is properly listed in .gitignore and never committed. Document in CONTRIBUTING.md that developers must create their own .env with secure values. Implement validation in the application startup to ensure required credentials have been changed from defaults.
• Medium · Insecure Default Credentials Pattern — docker-compose.yml, .env.example, configuration files. The pattern of using identical default credentials ('jeepay'/'jeepay' for database user/password) throughout configuration files suggests a potential pattern of weak security practices in the deployment pipeline. Fix: Establish a security baseline requiring: (1) unique credentials per environment, (2) minimum password complexity requirements, (3) automated credential rotation for service accounts, (4) audit logging of database access.
• Medium · Docker — 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

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