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/yudao-cloud 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.

GO — Healthy across all four use cases

• Last commit 3d ago
• 7 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Single-maintainer risk — top contributor 90% of recent commits

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

What it runs against: a local clone of YunaiV/yudao-cloud — 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/yudao-cloud | 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 ≤ 33 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "YunaiV/yudao-cloud(\\.git)?\\b" \\
  && ok "origin remote is YunaiV/yudao-cloud" \\
  || miss "origin remote is not YunaiV/yudao-cloud (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-dependencies/pom.xml" \\
  && ok "yudao-dependencies/pom.xml" \\
  || miss "missing critical file: yudao-dependencies/pom.xml"
test -f "yudao-gateway" \\
  && ok "yudao-gateway" \\
  || miss "missing critical file: yudao-gateway"
test -f "yudao-framework" \\
  && ok "yudao-framework" \\
  || miss "missing critical file: yudao-framework"
test -f "yudao-module-system/pom.xml" \\
  && ok "yudao-module-system/pom.xml" \\
  || miss "missing critical file: yudao-module-system/pom.xml"

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

yudao-cloud is a Spring Cloud Alibaba-based microservices backend management system with MyBatis Plus and Vue 3 frontend, providing RBAC, multi-tenancy, data permissions, workflow, payment, SMS, e-commerce, CRM, ERP, MES, IoT, and AI model integration. It solves rapid enterprise application development by offering pre-built modular features (system, infra, member, BPM, pay, report, mall, CRM, ERP, MES, IoT) deployable independently or as a complete platform. Multi-module monorepo: yudao-gateway (API Gateway), yudao-framework (shared utilities), yudao-server (entry point), then feature modules under yudao-module-* (system, infra, bpm, pay, mall, crm, erp, iot, mes). Frontend lives in separate repos (yudao-ui-admin-vue3, yudao-ui-admin-vben, yudao-ui-admin with vue2). Databases use SQL scripts in .sql files for each module.

Full-stack developers and enterprises building internal management systems, SaaS platforms, or e-commerce solutions who need a production-ready, modular backend with extensive out-of-box features (workflow, payment processing, CRM, ERP) and don't want to build these from scratch. Contributors are Chinese-focused developers working on open-source ERP/CRM backends.

Production-ready and actively maintained. The project has substantial code (14.7 MB Java, 4.9 MB PL/pgSQL, 1.3 MB TSQL), comprehensive documentation (quick-start, video tutorials, migration guides), CI/CD via GitHub Actions/Maven, and an active single maintainer (YunaiV/艿艿) shipping updates regularly. Offers both JDK 8 + Spring Boot 2.7 (master) and JDK 17/21 + Spring Boot 3.2 (master-jdk17) branches.

Single-maintainer risk is significant (one person, YunaiV, drives core development), though the project is well-established with extensive community. Heavy dependency on Alibaba ecosystem (Nacos, Seata, Sentinel) which is stable but creates vendor lock-in. Breaking changes between major feature releases (see migration docs) require planning. No visible test coverage metrics in the file list, and database schema migrations span multiple SQL dialects (MySQL, Oracle, PostgreSQL, SQL Server, DM, TiDB), increasing maintenance burden.

Active development on Spring Boot 3.2 + JDK 17/21 compatibility (master-jdk17 branch), feature modules for IoT and MES, AI model integration (commented out in pom.xml pending Spring AI maturity), and mobile support via uni-app. Issues processed via GitHub/Gitee templates; migration tooling being refined to help users adapt between full and mini versions.

Clone from GitHub or Gitee: git clone https://github.com/YunaiV/yudao-cloud.git (or use master-jdk17 for JDK 17+). Build with Maven: mvn clean install -DskipTests. Start Nacos, MySQL, Redis as per https://cloud.iocoder.cn/quick-start/. Run yudao-server module. Frontend: clone yudao-ui-admin-vue3 or yudao-ui-admin-vben separately, run npm install && npm run dev.

Daily commands: Backend: mvn clean package -DskipTests then java -jar yudao-server/target/yudao-server-*.jar (requires Nacos, MySQL, Redis running). Frontend: cd yudao-ui-admin-vue3 && npm install && npm run dev (dev server on http://localhost:5173). Demos at http://dashboard-vue3.yudao.iocoder.cn (Vue3+element-plus), http://dashboard-vben.yudao.iocoder.cn (Vue3+vben), http://dashboard.yudao.iocoder.cn (Vue2+element-ui).

• pom.xml — Root Maven POM defining all dependencies, module structure, and version management for the entire Spring Cloud Alibaba microservices ecosystem
• yudao-dependencies/pom.xml — Centralized dependency version management module ensuring consistent versions across all microservices (Spring Cloud, MyBatis Plus, etc.)
• yudao-gateway — API Gateway module providing unified entry point, routing, rate limiting, and authentication for all microservices
• yudao-framework — Core framework module containing shared utilities, base classes, common exceptions, and cross-cutting concerns (logging, security, data permissions)
• yudao-module-system/pom.xml — System management module handling RBAC, users, roles, departments, menus, and dynamic permissions core functionality
• yudao-module-infra/pom.xml — Infrastructure module providing file management, SMS, payment integration, and third-party service abstractions
• README.md — Project overview with architecture decisions, version compatibility matrix, and deployment instructions for all team members

Add a New Microservice Module

1. Create new module directory under yudao-server or as peer module with standard Maven structure (pom.xml)
2. Add module reference in root pom.xml <modules> section and inherit from yudao-dependencies for version management (pom.xml)
3. Implement controllers inheriting from framework base classes, use MyBatis Plus for data access (yudao-framework)
4. Register routes in API Gateway configuration for service discovery and routing (yudao-gateway)

Add a New API Endpoint with Permission Control

1. Create Controller class in yudao-module-system or appropriate module inheriting from BaseController (yudao-module-system/pom.xml)
2. Add @RequiresPermissions annotation to methods for RBAC enforcement, define permission in system menu data (yudao-module-system/pom.xml)
3. Implement Service layer using MyBatis Plus mapper for data persistence with dynamic SQL (yudao-module-system/pom.xml)
4. Add DTO/VO classes for request/response serialization, leverage Lombok @Data to reduce boilerplate (lombok.config)

Integrate Third-Party Service (SMS, Payment, etc.)

1. Create interface contract in yudao-module-infra under appropriate service abstraction layer (yudao-module-infra/pom.xml)
2. Implement provider-specific adapter (e.g., AlibabaSmsSender) with configuration properties from application.yml (yudao-module-infra/pom.xml)
3. Add configuration model class in yudao-framework for type-safe property binding from Spring Config (yudao-framework)
4. Wire implementation via Spring @Bean in infra module, expose via REST API in yudao-server (yudao-server)

Enable Multi-Tenant Data Isolation

1. Framework provides TenantFilter and interceptors in yudao-framework for automatic tenant context extraction (yudao-framework)
2. MyBatis Plus configurations in yudao-module-system automatically append tenant_id WHERE clause to all queries (yudao-module-system/pom.xml)
3. Define tenant-scoped resources and permissions in system module, user login sets TenantContextHolder (yudao-module-system/pom.xml)
4. Update Docker Compose to configure Nacos with separate tenant configurations if needed (script/docker/docker-compose.yml)

• Spring Cloud Alibaba 2021 + Spring Boot 2.7.18 — Mature, production-grade microservices framework with Nacos service discovery, built-in circuit breakers, and distributed tracing support
• MyBatis Plus — ORM with automatic CRUD generation, dynamic SQL builders, and built-in support for multi-tenant isolation and permission filtering
• Vue 3.2 + Element Plus — Modern reactive frontend with component library providing rich admin UI; multiple UI variants (Vben/AntDesign) available
• Spring Cloud Gateway — Unified API gateway handling routing, authentication, rate limiting, and cross-cutting concerns before requests reach microservices
• Docker Compose — Local development orchestration for MySQL, Redis, Nacos, and all services in reproducible environment

• Monolithic database with Spring Cloud Alibaba microservices (not database-per-service)

  • Why: Simplifies transactions, data consistency, and multi-tenant isolation; reduces operational complexity for CRUD-heavy admin systems
  • Consequence: Tight coupling on data layer; harder to scale individual modules independently; migration complexity if module separation needed later

• MyBatis Plus for all data access rather than JPA

  • Why: More explicit SQL control, better performance tuning, superior support for complex dynamic queries and multi-tenant filtering
  • Consequence: More boilerplate SQL; less automatic relationship management; developers must write explicit queries vs. JPQL annotations

• No separate versioning of framework vs. modules (single pom.xml revision)

  • Why: Ensures all modules use compatible Spring Cloud/Boot versions; reduces dependency hell and version mismatch bugs
  • Consequence: Cannot upgrade individual modules independently; entire project releases together

• Support multiple UI variants (Vue 3 + Element, Vue 3 + Vben, Vue 2 + ElementUI) from single backend

  • Why: Flexibility for different team preferences and backward compatibility; all variants use same REST API contracts
  • Consequence: Higher UI maintenance burden; inconsistent UX if not kept in sync; increased deployment complexity

• Real-time pub/sub messaging (no built-in event bus; uses RPC via Spring Cloud)
• GraphQL API support (REST-only; built around RESTful contracts)
• Offline-first mobile app (backend-centric design; front-end consumes real-time APIs)
• Multi-region replication (single-datacenter MySQL design; no built-in cross-region sync)
• Machine learning model serving (AI references are feature integrations, not core ML ops platform)

Nacos (registry+config center) must be running before starting modules, or service discovery fails silently. MySQL/Redis/RabbitMQ (or Event queue) required; exact version constraints in yudao-dependencies/pom.xml. Multi-module builds may fail if dependencies aren't installed in correct order (yudao-dependencies → yudao-framework → others). TSQL and PL/pgSQL scripts exist but MySQL is the primary tested dialect; other DB compatibility varies. Spring AI module (AI LLM) requires JDK17+, commented out in default master branch. Seata distributed transaction requires separate Seata server setup. Multi-tenant isolation is implemented at row-level but requires careful SQL authoring; see yudao-framework/src/main/java/cn/iocoder/yudao/framework/mybatis/core/mapper/ for data permission interceptors.

• Spring Cloud Alibaba (Nacos, Seata, Sentinel) — yudao-cloud's entire microservices backbone relies on Alibaba's suite for service discovery (Nacos), distributed transactions (Seata), and resilience (Sentinel); understanding these is non-negotiable for deployment and troubleshooting
• Row-Level Security (RLS) / Data Permissions — yudao-cloud implements multi-tenant data isolation via MyBatis interceptors (yudao-framework/mybatis/) that inject WHERE clauses based on user/tenant context; critical for SaaS safety
• BPMN 2.0 Workflow Engines — yudao-module-bpm implements business process workflows using BPMN specification; essential for understanding approval chains, task routing, and process definition in yudao-cloud
• Distributed Transactions (Saga Pattern via Seata) — yudao-cloud uses Seata's AT mode (automatic recovery) and TCC (Two-Phase Commit) for cross-module transactions; crucial for payment and order workflows without losing consistency
• MyBatis Plus Dynamic SQL & Interception Chain — yudao-cloud's core data layer uses MybatisPlus interceptors for tenant isolation, data permissions, and soft deletes; understanding the interceptor chain prevents data leakage bugs
• Role-Based Access Control (RBAC) with Dynamic Permissions — yudao-module-system implements RBAC where roles are assigned permissions dynamically at runtime (not hardcoded); enables multi-tenant and multi-organization authorization without code recompilation
• Circuit Breaker Pattern (Sentinel) — yudao-cloud integrates Alibaba Sentinel for request rate limiting, flow control, and circuit breaking across microservices; prevents cascade failures in distributed system

• YunaiV/ruoyi-vue-pro — Direct predecessor monolithic architecture (Spring Boot 2.x + Vue) that yudao-cloud refactored into microservices; reference for feature parity and migration patterns
• yudaocode/yudao-cloud-mini — Lightweight variant of yudao-cloud (system+infra only, no CRM/ERP/MES); used for starter projects or resource-constrained deployments
• alibaba/spring-cloud-alibaba — Upstream dependency providing Nacos, Seata, Sentinel; essential for understanding registry, config, circuit-breaking in yudao-cloud
• baomidou/mybatis-plus — ORM framework powering all yudao-module-* database access; used for query generation, pagination, and data permission interception
• xuxueli/xxl-job — Distributed job scheduler integrated in yudao-cloud for cron tasks, report generation, and async workflows

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 integration tests for yudao-gateway module

The repo has a Maven workflow (.github/workflows/maven.yml) but lacks visible test coverage for the critical gateway service. Given this is a microservices architecture with Spring Cloud Alibaba, the gateway is a single point of failure. Adding integration tests would validate routing rules, authentication flows, and rate limiting across multiple modules (system, infra, pay, mall, etc.).

• [ ] Create yudao-gateway/src/test/java/cn/iocoder/cloud/gateway/integration/ directory
• [ ] Add test cases for route configuration validation against yudao-module-system, yudao-module-pay, yudao-module-mall endpoints
• [ ] Implement tests for auth token validation and RBAC permission enforcement at gateway level
• [ ] Add performance tests for multi-tenant isolation in gateway filters
• [ ] Update maven.yml to run gateway integration tests as separate step

Add GitHub Action workflow for multi-module dependency conflict detection

With 13+ modules (system, infra, member, bpm, pay, report, mp, mall, erp, crm, iot, mes, ai), dependency version conflicts are likely. The current maven.yml only does basic compilation. Adding a dependency tree analyzer would catch transitive dependency conflicts early, especially critical given Spring Cloud Alibaba's complex dependency graph.

• [ ] Create .github/workflows/dependency-check.yml workflow file
• [ ] Add steps using maven-dependency-plugin to generate dependency trees for each module
• [ ] Integrate conflict detection tools (e.g., com.google.guava versions across modules) to fail builds on conflicts
• [ ] Add reporting step to create dependency conflict summaries in PR comments
• [ ] Document findings in a DEPENDENCY_MANAGEMENT.md file in repo root

Add database schema documentation generator for yudao-module-* modules

The file list shows database documentation images (.image/数据库文档.jpg) exist, but there's no visible automation for keeping schema docs in sync with MyBatis Plus entities. With MyBatis Plus as the ORM across all modules, adding an automated schema doc generator would prevent drift between code and documentation, critical for modules like ERP, CRM, and MES which have complex data models.

• [ ] Create yudao-framework/src/main/java/cn/iocoder/cloud/framework/doc/SchemaDocGenerator.java to introspect MyBatis Plus entities
• [ ] Add Maven plugin configuration in yudao-dependencies/pom.xml to generate schema markdown during build
• [ ] Create docs/schema/ directory structure mirroring module layout (docs/schema/system.md, docs/schema/mall.md, etc.)
• [ ] Add GitHub Action in .github/workflows/schema-docs.yml to validate schema docs are updated on entity changes
• [ ] Update .gitignore to track generated schema docs in version control

• Add comprehensive unit test coverage for yudao-module-system/src/main/java/cn/iocoder/yudao/module/system/controller/ using JUnit5 + Mockito; currently ~5% test file presence in Java codebase
• Document the Seata distributed transaction setup and failover scenarios in a new docs/seata-setup.md with concrete Docker Compose example for yudao-cloud
• Create a migration script (Python/Shell) to auto-detect database dialect and apply correct schema from yudao-module-*/src/main/resources/db/migration/ without manual SQL intervention

Failed to generate security analysis.

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.