GO — Healthy across all four use cases

• Last commit 1d ago
• 5 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Single-maintainer risk — top contributor 93% 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}

RuoYi-Vue-Pro is a full-stack enterprise management platform built on Spring Boot 2.7 + MyBatis Plus + Vue 3, providing a modular backend (yudao-server with pluggable modules: system, infra, bpm, crm, erp, iot, mes, ai) and multi-frontend support (Vue3 element-plus/vben, Vue2 element-ui, uni-app mobile). It solves rapid enterprise SaaS development by bundling RBAC/data permissions, multi-tenancy, Flowable workflows, payment/SMS/storage integrations, and code generation—enabling teams to scaffold production systems in days rather than months. Maven monorepo with three tiers: yudao-dependencies (BOM), yudao-framework (shared utilities: Spring Security, MyBatis Plus, Redis, logging), yudao-server (main app entry), and pluggable business modules (yudao-module-system, yudao-module-infra, yudao-module-bpm, etc.). Frontend mirrors this: Vue 3 admin-ui (element-plus and vben variants), plus uni-app mobile for cross-platform support. Modules can be disabled via commented <module> tags in pom.xml.

Chinese enterprise developers and startups building internal management systems, CRM/ERP solutions, or SaaS platforms who need a pre-built, battle-tested foundation with modern tech stack; also attracts contributors interested in learning production-grade Spring Boot architecture and Vue 3 patterns at enterprise scale.

Highly mature and actively developed: 15M+ lines of Java code, hundreds of real-world deployments (implied by feature completeness), comprehensive CI/CD via GitHub Actions (maven.yml, yudao-ui-admin.yml workflows), recent stable release (2026.04 versioning suggests continuous updates), and explicit statement that all code is permanently open-source. Production-ready for enterprise use with strong community backing.

Low technical risk but medium organizational risk: single primary maintainer (YunaiV, 'artisanal contributor' per README), no visible automated test suite in listed files (risk for regression), heavy dependency on Flowable/Spring Security ecosystems. Major architectural coupling between modules means isolated deployment is difficult. Chinese-first documentation (README, issues in zh-CN) may slow non-Mandarin contributors.

Actively maintaining JDK 8 (master branch, Spring Boot 2.7) and JDK 17/21 (master-jdk17, Spring Boot 3.2) tracks in parallel. Recent additions evident from feature flags: AI module (commented out, requires separate setup per doc), IoT/MES/CRM/ERP modules in matrix. GitHub Actions workflows suggest ongoing CI/CD refinement for UI builds. Multiple demo environments live (dashboard-vue3.yudao.iocoder.cn, dashboard-vben.yudao.iocoder.cn).

Clone and build the monorepo: git clone https://github.com/YunaiV/ruoyi-vue-pro.git && cd ruoyi-vue-pro && mvn clean install -DskipTests. Backend: edit pom.xml to uncomment needed modules (e.g., yudao-module-bpm), then run yudao-server via IDE or mvn spring-boot:run. Frontend: cd yudao-ui-admin && npm install && npm run dev (for element-plus) or choose vben/vue2 variant. Requires MySQL 5.7+, Redis 6.0+ (see quickstart docs at doc.iocoder.cn/quick-start/).

Daily commands: Backend: mvn spring-boot:run -pl yudao-server (requires MySQL/Redis up). Frontend (element-plus): cd yudao-ui-admin && npm run dev (Vite dev server on port 5173). Frontend (vben): cd yudao-ui-admin-vben && npm run dev. Ensure application.yml in yudao-server/src/main/resources points to correct MySQL host (default localhost:3306) and Redis (default localhost:6379).

• pom.xml — Root Maven POM defining all dependencies, module structure, and build configuration for the entire Spring Boot + Vue monorepo
• yudao-server — Main server application entry point; contains the Spring Boot application bootstrapping and core API routing
• yudao-framework — Shared framework layer providing common utilities, interceptors, exception handling, and cross-cutting concerns used across all modules
• yudao-module-system — Core system module implementing RBAC, user/role/permission management, and foundational admin features
• yudao-module-infra — Infrastructure module handling file management, configuration, logging, monitoring, and operational tooling
• .github/workflows/maven.yml — CI/CD pipeline configuration for automated Maven builds and deployments on each commit

Add a new REST API endpoint with RBAC permissions

1. Create a new controller in yudao-module-system/src/main/java/cn/iocoder/yudao/module/system/controller/admin with @RestController and @RequestMapping annotations (yudao-module-system)
2. Inject the corresponding Service (e.g., @Resource private UserService userService) which implements business logic with @Transactional (yudao-module-system)
3. Add @PreAuthorize annotations on controller methods (e.g., @PreAuthorize("@aaa.hasPermission('system:user:query')")) to enforce RBAC (yudao-framework)
4. Register the permission in the system_menu or system_permission table via SQL INSERT; the frontend fetches these dynamically

Add a new business module with domain model

1. Create a new Maven module under yudao-modules folder mirroring yudao-module-infra structure: controller, service, dal (mapper/entity), dto directories (pom.xml)
2. Add module declaration in root pom.xml <modules> section (pom.xml)
3. Create entity class extending BaseEntity, using MyBatis Plus @TableName annotation in dal/entity (yudao-module-infra)
4. Implement Mapper interface extending BaseMapper and add CRUD Service extending BaseServiceImpl in service layer (yudao-module-infra)
5. Create controller with DTO converters (MapStruct) for request/response separation (yudao-module-system)

Integrate a new external service (payment, SMS, third-party login)

1. Add the third-party SDK as Maven dependency in yudao-dependencies/pom.xml (yudao-dependencies)
2. Create a new @Component or @Service in yudao-module-infra implementing a standardized interface (e.g., PaymentGateway, SmsProvider) (yudao-module-infra)
3. Externalize credentials (API keys, secrets) to application.yml configuration and use @ConfigurationProperties for type-safe binding (yudao-module-infra)
4. Add integration tests in src/test/java using Mockito to stub external API calls (yudao-module-infra)

Add a new Vue 3 admin page with data table and form modal

1. Create a new .vue component in yudao-ui-admin src/views/{module}/{feature}.vue using script setup syntax and Composition API (.github/workflows/yudao-ui-admin.yml)
2. Use Element Plus el-table with remote pagination and el-form with validation rules; call the backend API via import from src/api/{module}.ts (.github/workflows/yudao-ui-admin.yml)
3. Implement CRUD modal using v-if and defineExpose to expose methods; leverage useRouter and usePermission composables from framework (.github/workflows/yudao-ui-admin.yml)
4. Add route to router/modules/{module}.ts and ensure backend endpoint has matching @PreAuthorize permission check (.github/workflows/yudao-ui-admin.yml)

• Spring Boot 2.7 + Spring Cloud — Enterprise-grade framework providing dependency injection, AOP for cross-cutting concerns (logging, auth), and built-in actuator for monitoring
• MyBatis Plus + MySQL — ORM abstraction with automatic CRUD generation reduces boilerplate; MySQL for reliable transactional ACID compliance and widespread hosting support
• Redis — In-memory cache for session tokens, permission caches, and hot data to reduce database load and improve API latency
• Vue 3 + Element Plus / Vben — Modern reactive frontend with component-driven UI; Element Plus provides rich admin controls; Vben offers enterprise layout patterns
• Flowable BPM engine — Integrated workflow orchestration for business processes (approvals, leave requests) with visual designer and audit trail
• Docker + docker-compose — Containerized local development environment ensuring consistency across team and simplifying onboarding

• Monolithic multi-module Maven structure vs. microservices

  • Why: Faster development iteration, simpler operational overhead for teams <50 engineers, shared codebase for domain models
  • Consequence: Scaling is constrained to vertical (single JVM) unless refactored to microservices; all modules share same deployment lifecycle

• Dynamic RBAC stored in database vs. static role config files

  • Why: Admin users can grant/revoke permissions at runtime without code deployment; supports SaaS multi-tenancy with per-tenant role definitions
  • Consequence: Every request requires permission lookups (mitigated by Redis caching); introduces audit burden for compliance

• Vue 3 with Element Plus as primary UI vs. single-page-app per module

  • Why: Unified admin experience, shared design system, easier navigation and feature discovery for users
  • Consequence: Single frontend codebase must remain in sync with backend API contract; large bundle if not properly code-split

• Flowable embedded in same JVM vs. external BPM service

  • Why: Simpler deployment, direct access to Spring beans for process variable binding, no network latency for workflow operations
  • Consequence: Workflow engine shares thread pool and memory with API requests; scaling requires horizontal pod replication

• Does not provide Kubernetes manifests or helm charts (Docker Compose for local dev only)
• Does not include client-side end-to-end encryption for sensitive fields (relies on HTTPS + database encryption at rest)
• Does not implement GraphQL (REST API only)
• Does not provide official mobile app (open source community has built WeChat mini-app and uni-app adapters)
• Does not manage external payment provider reconciliation automatically (webhook handlers must be custom-coded per provider)

MySQL migration: Flyway auto-runs SQL in yudao-module-*/impl/src/main/resources/db/migration/; schema must exist before app startup, or migrations fail silently. Redis required: Many features (token cache, distributed locks, WebSocket cluster) fail hard without Redis—cannot be disabled. Module interdependencies: yudao-module-bpm, yudao-module-crm depend on yudao-module-system; uncomment selectively or face classpath conflicts. JWT secret: Default in application.yml must be changed in production (yudao.jwt.secret property). Multi-tenancy opacity: Tenant filtering is transparent via MyBatis Plus interceptor—developers must remember to explicitly exclude system users via tenantIgnore() on queries. China-centric integrations: WeChat, Alipay, Tencent Cloud SDKs are baked into yudao-module-pay and yudao-module-mp; non-China deployments should exclude these modules.

• Row-Level Security (RLS) via MyBatis Plus Interceptor — Core mechanism in yudao for multi-tenancy and data permissions—automatically appends WHERE tenant_id = ? or WHERE dept_id IN (...) to all queries without explicit code; underpins SaaS isolation.
• RBAC with Dynamic Menu Loading — yudao stores role-permission mappings in system_role_menu table and loads them into Redis on login; frontend dynamically renders routes only for granted menus—enables zero-restart permission updates.
• Flowable Workflow Engine Integration — Embedded in yudao-module-bpm for BPM/OA; handles multi-step approval chains, dynamic form binding, and task delegation—avoids hand-coded state machines.
• MyBatis Plus Code Generation — yudao-module-infra contains a code generator that outputs Entity → DTO → Controller → Service → Mapper boilerplate from a database table definition; shipped demo shows it generating a full CRUD module in <1 minute.
• JWT Token with Redis Blacklist — yudao-framework-security uses JWT for stateless auth but stores revoked tokens in Redis (logout, role change) to enforce immediate invalidation without token expiry wait.
• Multi-Tenancy via Transparent Filtering — Tenants share a single database schema; yudao enforces isolation via tenant_id column + MyBatis interceptor—critical for SaaS deployments where data isolation must be bulletproof.
• Redisson Distributed Locks — yudao uses Redisson (Redis-backed locks) for coordinating across clustered instances (e.g., preventing duplicate payment processing); avoids database contention in high-concurrency scenarios.

• YunaiV/yudao-cloud — Microservices evolution of ruoyi-vue-pro using Spring Cloud Alibaba; same author, same product roadmap but cloud-native deployment model.
• YunaiV/yudao-boot-mini — Lightweight stripped-down variant of this repo (system + infra modules only); recommended starting point for simpler projects before adding BPM/CRM/ERP.
• baomidou/mybatis-plus — Core ORM dependency; yudao uses MyBatis Plus's BaseMapper and plugins (pagination, multi-tenancy interceptor) throughout all modules.
• flowable/flowable-engine — Workflow orchestration engine integrated in yudao-module-bpm; provides visual process designer, dynamic form handling, and multi-instance task support.
• spring-projects/spring-security — Authentication/authorization backbone; yudao wraps it with custom JWT, multi-tenant, and dynamic permission resolution in yudao-framework.

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 unit tests for yudao-framework core utilities

The yudao-framework module likely contains critical utility classes and helpers (common, web, security, etc.) that support all business modules. These core utilities typically have high impact on system stability. Adding unit tests for framework modules would improve reliability across all dependent modules (system, infra, bpm, crm, erp, etc.) and serve as documentation for how to properly use framework APIs.

• [ ] Examine yudao-framework/yudao-framework-core/src/main to identify key utility classes lacking test coverage
• [ ] Create yudao-framework/yudao-framework-core/src/test directory structure mirroring main source
• [ ] Write unit tests for framework utilities (e.g., common result wrappers, security helpers, validation utilities)
• [ ] Add parameterized tests for edge cases in data transformation utilities
• [ ] Ensure >80% code coverage for framework-core module and document in README

Create GitHub Actions workflow for automated dependency vulnerability scanning

With 50+ modules and complex Maven dependency management (evidenced by yudao-dependencies module), this project is vulnerable to supply chain attacks and outdated dependencies. The existing maven.yml workflow only handles build/test. A dedicated dependency security scanning workflow (using OWASP Dependency-Check or GitHub's native Dependabot integration) would proactively identify CVEs and help maintain security compliance.

• [ ] Create .github/workflows/dependency-check.yml with OWASP Dependency-Check Maven plugin configuration
• [ ] Configure to run on: pull_request, push to main/develop, and weekly schedule
• [ ] Generate HTML reports and upload as workflow artifacts for review
• [ ] Add job to fail workflow if HIGH or CRITICAL vulnerabilities are detected
• [ ] Document security scanning process in CONTRIBUTING.md

Add integration tests for cross-module RPC/EventBus communication patterns

RuoYi-Vue-Pro uses a modular architecture with 15+ optional modules (BPM, CRM, ERP, IoT, MES, AI, etc.). These modules likely communicate via service calls or event buses. Currently, there's no visible test suite validating inter-module contracts or event propagation. Adding integration tests would prevent regression when refactoring shared interfaces and serve as documentation for module integration patterns.

• [ ] Create yudao-server/src/test/java/integration for cross-module integration tests
• [ ] Write test cases validating BPM -> OA workflow triggers and event notifications
• [ ] Add tests for CRM -> Payment module integration when creating orders
• [ ] Test message publishing/consumption patterns between modules using test containers (Docker)
• [ ] Document module dependency graph and integration patterns in docs/ARCHITECTURE.md

• Add unit test coverage for yudao-framework/yudao-spring-boot-starter-security/src/main/java/cn/iocoder/yudao/framework/security/core/util/SecurityFrameworkUtils.java (utility methods for extracting user/tenant from context)—currently untested, critical for all authenticated endpoints.
• Document the data permission system (yudao-module-system service layer): create a tutorial explaining row-level filtering by user department/role via yudao.data-permission config in application.yml with a runnable example (missing from doc.iocoder.cn).
• Implement missing I18n for yudao-ui-admin: extract hardcoded Chinese strings in yudao-ui-admin/src/views/system/user/ and yudao-ui-admin/src/views/system/role/ into i18n/en.json and i18n/zh.json, then bind via {{ $t('key') }} pattern.

• High · Outdated Spring Boot Version — pom.xml - Spring Boot 2.7.18. The project uses Spring Boot 2.7.18, which is in maintenance mode and approaching end-of-life. Spring Boot 2.7.x will no longer receive security updates after December 2023. This exposes the application to known security vulnerabilities that won't be patched. Fix: Upgrade to Spring Boot 3.2 or later (as indicated by the JDK 17/21 version track mentioned in README). Ensure all dependencies are compatible with the newer version.
• High · Java 8 Target with Outdated Security Baseline — pom.xml - <java.version>1.8</java.version>. Java 8 reached end-of-life in December 2022 for most vendors. Using Java 8 as the target version means the codebase doesn't benefit from critical security improvements in Java 9+, including stronger cryptography defaults, improved memory safety features, and modern security APIs. Fix: Migrate to Java 11 LTS minimum, preferably Java 17 LTS or Java 21 LTS for long-term security support. Update maven.compiler.source and maven.compiler.target accordingly.
• High · Missing Dependency Version Management — pom.xml - Missing yudao-dependencies module content. The pom.xml shows a parent project structure (yudao-dependencies) but the full dependency declaration and version constraints are not visible in the provided snippet. This could lead to transitive dependency vulnerabilities if versions are not properly pinned and managed. Fix: Implement a comprehensive dependency management strategy in the parent pom. Use a dependency check plugin (OWASP) in the Maven build to identify known vulnerabilities. Pin versions explicitly rather than relying on version ranges.
• Medium · Multiple Disabled Modules Without Clear Security Rationale — pom.xml - Commented module declarations. Several modules are commented out in pom.xml (member, bpm, report, mp, pay, mall, crm, erp, iot, mes, ai). These commented modules may represent unreviewed or potentially vulnerable code paths. If re-enabled without proper security review, they could introduce risks. Fix: Document the security review status of each disabled module. Either fully remove commented code or maintain it in a separate branch. When re-enabling modules, perform security assessments including dependency scanning and code review.
• Medium · Complex Microservices Architecture Without Visible Security Controls — Project structure - Multiple enabled and disabled modules. The project supports complex features (multi-tenant SaaS, third-party logins, payment processing, IoT, etc.) across multiple modules. The provided snippets don't show evidence of API gateway security, rate limiting, authentication/authorization implementations, or secrets management strategies. Fix: Implement API security controls: API gateway with rate limiting, input validation framework, output encoding library, CORS policy definition, authentication tokens (JWT) with proper expiration, authorization checks using RBAC. Document security architecture.
• Medium · No Visible Secrets Management — Project configuration - No .env or vault-config visible. The file structure shows configuration management but no evidence of secrets vault integration, encrypted configuration, or environment-based credential management. Database passwords, API keys, and OAuth secrets may be stored insecurely. Fix: Implement secrets management using: Spring Cloud Config Server with encrypted properties, HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. Never commit credentials to repository. Use environment variables for sensitive data.
• Medium · Payment and Financial Data Handling Without Visible Security Framework — yudao-module-pay and related modules. The project includes payment processing module (yudao-module-pay) and CRM/ERP features that likely handle sensitive financial and personal data. No evidence of encryption at rest, encryption in transit, data masking, or PCI-DSS compliance measures in the provided snippets. Fix: Implement: TLS 1.2+ for all data transmission, encryption at rest for sensitive fields (database encryption), data masking for logs, PCI-DSS compliance if handling credit cards, regular security audits, audit logging for financial transactions.
• Medium · Third-Party Authentication Integration Without Visible OAuth/OIDC Security — undefined. README mentions 'three-party login' 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/YunaiV/ruoyi-vue-pro 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 YunaiV/ruoyi-vue-pro repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/YunaiV/ruoyi-vue-pro.

What it runs against: a local clone of YunaiV/ruoyi-vue-pro — 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 YunaiV/ruoyi-vue-pro | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | 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 ≤ 31 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "YunaiV/ruoyi-vue-pro(\\.git)?\\b" \\
  && ok "origin remote is YunaiV/ruoyi-vue-pro" \\
  || miss "origin remote is not YunaiV/ruoyi-vue-pro (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 master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "pom.xml" \\
  && ok "pom.xml" \\
  || miss "missing critical file: pom.xml"
test -f "yudao-server" \\
  && ok "yudao-server" \\
  || miss "missing critical file: yudao-server"
test -f "yudao-framework" \\
  && ok "yudao-framework" \\
  || miss "missing critical file: yudao-framework"
test -f "yudao-module-system" \\
  && ok "yudao-module-system" \\
  || miss "missing critical file: yudao-module-system"
test -f "yudao-module-infra" \\
  && ok "yudao-module-infra" \\
  || miss "missing critical file: yudao-module-infra"

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