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/dromara/lamp-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.

WAIT — Solo project — review before adopting

• Last commit 2d ago
• Apache-2.0 licensed
• Tests present
• ⚠ Solo or near-solo (1 contributor active in recent commits)
• ⚠ No CI workflows detected

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

What it runs against: a local clone of dromara/lamp-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 dromara/lamp-cloud | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch java17/5.x exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 32 days ago | Catches sudden abandonment since generation |

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

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

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

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

# 4. Critical files exist
test -f "lamp-base/pom.xml" \\
  && ok "lamp-base/pom.xml" \\
  || miss "missing critical file: lamp-base/pom.xml"
test -f "A极其重要/01-docs/sql/mysql/1.先执行我,创建数据库.sql" \\
  && ok "A极其重要/01-docs/sql/mysql/1.先执行我,创建数据库.sql" \\
  || miss "missing critical file: A极其重要/01-docs/sql/mysql/1.先执行我,创建数据库.sql"
test -f "A极其重要/01-docs/docker/03.docker运行项目.md" \\
  && ok "A极其重要/01-docs/docker/03.docker运行项目.md" \\
  || miss "missing critical file: A极其重要/01-docs/docker/03.docker运行项目.md"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "A极其重要/01-third-party/nacos/nacos_config_export_20250826005017.zip" \\
  && ok "A极其重要/01-third-party/nacos/nacos_config_export_20250826005017.zip" \\
  || miss "missing critical file: A极其重要/01-third-party/nacos/nacos_config_export_20250826005017.zip"

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

Lamp-cloud is a multi-tenant microservices backend development platform built on Spring Cloud (Java 17/21) that provides pluggable tenant isolation solutions (database, schema, and field-level isolation) and can function as either a SaaS platform or traditional monolithic application. It accelerates mid-to-backend system development with built-in support for open platform architectures and complex multi-tenancy scenarios. Modular Maven monorepo: lamp-base-biz, lamp-base-entity, lamp-system-biz, lamp-file-sdk modules represent layered microservices (API/entity/business/infrastructure), with Docker compose configs in A极其重要/01-docs/dockerfile/ for local orchestration (Nacos, MySQL8, Redis, RabbitMQ, MinIO). Tenant isolation logic injected via lamp-databases and lamp-echo-starter foundational libraries.

Java backend engineers and SaaS architects building enterprise multi-tenant platforms who need production-ready isolation patterns, service mesh infrastructure (Nacos, RabbitMQ, Redis), and rapid CRUD scaffold generation without rewriting tenant separation logic for each microservice.

Actively developed and production-ready: currently on java17/5.x branch (actively maintained with new features), stars indicate community adoption, comprehensive Docker deployment docs present, and modular architecture shows deliberate design. However, prior 3.x/4.x branches in maintenance-only mode indicates some version fragmentation.

Moderate risk: heavy dependency on external services (Nacos, MySQL, Redis, RabbitMQ, MinIO) with no obvious local dev setup automation visible; complex multi-tenancy code paths mean schema/field isolation bugs could affect all tenants silently; single primary maintainer (zuihou) concentration; Java 17/21 version pins may create future JDK upgrade debt.

Unable to infer from provided snapshot, but repo structure shows active maintenance path: 5.x branch (java17/21) receives new features while older branches frozen; Docker infrastructure (Nacos init scripts, MySQL 8 configs, MinIO setup) indicates recent DevOps focus; presence of both JDK 8 and 17 branches suggests gradual migration cycle ongoing.

git clone https://github.com/dromara/lamp-cloud.git
cd lamp-cloud
git checkout java17/5.x  # or latest branch
mvn clean install
docker-compose -f A极其重要/01-docs/docker/03.docker运行项目.md up  # per docs

Note: Requires Docker, MySQL 8+, Nacos, Redis running locally or via provided Docker configs.

Daily commands: After Maven install: run individual lamp-*-service modules as Spring Boot apps with active profiles (e.g., spring.profiles.active=dev,nacos) or orchestrate via Docker compose using provided scripts in A极其重要/01-docs/dockerfile/. Requires Nacos running at configured registry address; database migrations auto-applied on startup.

• lamp-base/pom.xml — Root Maven POM defining the multi-module project structure, dependency versions, and build configuration for the entire lamp-cloud microservices platform
• A极其重要/01-docs/sql/mysql/1.先执行我,创建数据库.sql — Initial database schema creation script—must be executed first to set up the foundational data model for all tenant isolation strategies
• A极其重要/01-docs/docker/03.docker运行项目.md — Docker deployment documentation explaining how to containerize and orchestrate all microservices in the platform
• README.md — Project overview and branch guidance; explicitly directs new users to java17/5.x branch which is the actively maintained version
• A极其重要/01-third-party/nacos/nacos_config_export_20250826005017.zip — Nacos service configuration export containing critical microservice registry and configuration management settings
• A极其重要/01-docs/image/架构图/lamp-cloud架构图.png — High-level architecture diagram showing microservice topology, tenant isolation layers, and component interactions
• lamp-base-biz/pom.xml — Business module POM defining dependencies for core business logic services and entity models

Add a New Microservice Module

1. Create a new Maven module directory under lamp-base with subdirectories for -api, -biz, and -entity (lamp-base/pom.xml)
2. Add module POM with parent reference to lamp-base and declare business dependencies (similar to lamp-base-biz/pom.xml) (lamp-base-biz/pom.xml)
3. Create Nacos configuration properties in the exported config export and reload service registry (A极其重要/01-third-party/nacos/nacos_config_export_20250826005017.zip)
4. Add service startup script in docker/dockerfile directory and add entry to docker-compose or Kubernetes manifests (A极其重要/01-docs/dockerfile/nginx/conf/nginx.conf)

Configure Tenant Isolation Strategy

1. Initialize tenant-specific database schema using appropriate SQL script (MySQL, Oracle, SQLServer, or Dameng) (A极其重要/01-docs/sql/mysql/lamp_none.sql)
2. Update MySQL configuration to support multiple schemas or add field-level isolation annotations in entity classes (A极其重要/01-docs/dockerfile/mysql8/conf/my.cnf)
3. Configure tenant context interceptors in Nacos service configuration and reload through registry (A极其重要/01-third-party/nacos/nacos_config_export_20250826005017.zip)

Deploy Platform to Docker Environment

1. Execute database initialization script to create base schema and tenant metadata tables (A极其重要/01-docs/sql/mysql/1.先执行我,创建数据库.sql)
2. Build all microservice modules using Maven, referencing the root POM version properties (lamp-base/pom.xml)
3. Follow Docker deployment guide to containerize services and configure Nginx reverse proxy routing (A极其重要/01-docs/docker/03.docker运行项目.md)
4. Deploy infrastructure services (Redis, RabbitMQ, MinIO, Nacos) using provided Dockerfiles and configuration files (A极其重要/01-docs/dockerfile/redis/redis.conf)

• Spring Cloud + Nacos — Provides microservice architecture with service discovery, configuration management, and circuit breaking for polyglot tenant isolation
• MySQL 8 / Oracle / SQLServer / Dameng — Supports multiple database backends with tenant isolation at database, schema, or field level depending on deployment model
• Redis — Distributed caching layer for tenant context, session management, and reducing database load across microservices
• RabbitMQ — Asynchronous event-driven communication between microservices maintaining tenant data boundaries
• MinIO / FastDFS — S3-compatible object storage for multi-tenant file management with isolated bucket policies per tenant
• Docker + Nginx — Container orchestration and reverse proxy routing enabling scalable multi-tenant deployment across JDK versions
• SkyWalking / Zipkin — Distributed tracing and APM observability for debugging request flows across tenant-isolated microservices

• Support JDK 8, 17, and 21 simultaneously

  • Why: Maximize backward compatibility and allow enterprises to upgrade Java versions incrementally
  • Consequence: Build complexity, testing burden across three Java versions, potential for version-specific bugs

• Pluggable tenant isolation (DATABASE/SCHEMA/FIELD strategies)

  • Why: Enable flexible deployment models for different SaaS vs. single-tenant use cases
  • Consequence: Increased codebase complexity, more configuration paths to test, higher operational cognitive load

• Use Nacos for centralized configuration over file-based configs

  • Why: Enable runtime configuration changes without redeployment across distributed microservices
  • Consequence: Operational dependency on Nacos availability, network latency for config fetches, potential consistency issues during failure

• Multi-database vendor support (MySQL, Oracle, SQLServer, Dameng)

  • Why: Serve enterprise customers with existing database investments and regulatory constraints
  • Consequence: SQL dialect abstraction complexity, increased testing matrix, potential performance variations by vendor

• Not a frontend application—Vue3 UI is separate from this backend cloud platform
• Does not handle real-time communication—async messaging via RabbitMQ, not WebSocket-based streaming
• Not a workflow engine—integrates with external workflow platforms, does not embed workflow execution
• Does not manage container orchestration—expects external Kubernetes or Docker Compose deployment, no built-in orchestrator

1. Nacos must be running before any microservice starts — no embedded fallback; check custom.properties for registry URL. 2. MySQL requires specific init scripts per A极其重要/01-docs/dockerfile/mysql8/conf/my.cnf — wrong charset/collation breaks multi-tenancy field isolation. 3. RabbitMQ mandatory for transactional message publishing between services; sync calls will timeout if broker unavailable. 4. FreeMarker template engine embedded for code generation — custom code scaffold templates may collide if not isolated by plugin name. 5. Tenant context propagated via request headers/ThreadLocal — async tasks must explicitly carry tenant ID or will execute in default tenant context.

• Pluggable Tenant Isolation — lamp-cloud's core differentiator; understanding database vs schema vs field isolation modes determines where to add tenant filtering logic and how data leakage risks scale
• Service Mesh / Nacos Service Discovery — Microservices register themselves dynamically in Nacos; new developers must understand how inter-service calls route (Feign + Nacos lookup) vs direct JDBC in monolithic mode
• ThreadLocal Tenant Context — Tenant ID is stored in ThreadLocal during request handling; async operations, thread pools, and async libraries (WebClient, completable futures) can lose context without explicit propagation
• Dynamic SQL Rewriting / Query Interceptor Pattern — Field isolation mode requires intercepting SQL at MyBatis or JDBC layer to add WHERE clauses for tenant filtering; developers need to understand when lamp-databases injects filtering vs when it doesn't
• RabbitMQ Topic Exchange vs Direct for Event Sourcing — Transactional consistency across microservices relies on reliable message ordering; multi-tenant mode requires routing message events to correct tenant consumers without cross-contamination
• FreeMarker Code Generation Templates — lamp-cloud auto-scaffolds CRUD endpoints and entities; developers modifying or extending entity definitions must understand how template markers map to generated class fields and SQL migrations
• Multi-Datasource Routing / Tenant-Aware DataSource Proxy — Database isolation mode requires routing JDBC connections to tenant-specific schemas or databases at runtime; understanding how Spring manages DataSource switching prevents connection pool exhaustion and leaks

• alibaba/nacos — Service discovery and config server that lamp-cloud depends on for microservice registration and inter-service communication
• spring-cloud/spring-cloud-alibaba — Spring Cloud integration layer providing Nacos client, RabbitMQ binder, and distributed tracing that lamp-cloud builds on
• ruoyi/RuoYi-Vue — Alternative open-source admin backend platform (non-SaaS, monolithic); useful for comparison if building single-tenant vs multi-tenant architectures
• jeecg/jeecg-boot — Similar Java low-code backend platform; also targets rapid development but with different multi-tenancy strategy (can compare isolation modes)
• dromara/lamp-web — Companion Vue3 frontend for lamp-cloud SaaS platform; provides full-stack reference implementation for tenant-aware UI

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 Docker Compose orchestration for multi-tenant setup with Nacos + MySQL + Redis + MinIO

The repo has individual Dockerfile configurations scattered across 'A极其重要/01-docs/dockerfile/' (mysql, mysql8, nacos, redis, rabbitmq, MinIO) but lacks a unified docker-compose.yml that orchestrates the full stack for local development. This is critical for a microservices multi-tenant platform where developers need to spin up the entire environment quickly. A docker-compose.yml with proper networking, volume management, and environment variables would significantly reduce setup friction and onboarding time.

• [ ] Create docker-compose.yml in 'A极其重要/01-docs/docker/' that includes services: nacos, mysql/mysql8, redis, rabbitmq, minio, nginx
• [ ] Reference existing Dockerfile configs from 'A极其重要/01-docs/dockerfile/' subdirectories (mysql/conf/my.cnf, nacos/init.d/custom.properties, nginx/conf/nginx.conf)
• [ ] Add environment variable substitution for JDK versions (21, 17, 8) and multi-tenant schema initialization
• [ ] Include health checks and dependency ordering so Nacos starts before microservices
• [ ] Create a '.env.example' file documenting all configurable variables
• [ ] Update docker documentation at 'A极其重要/01-docs/docker/03.docker运行项目.md' with docker-compose usage instructions

Add Maven integration tests for multi-tenant data isolation scenarios across database/schema/field strategies

The repo's core feature is '插拔式数据库隔离、SCHEMA隔离、字段隔离' (pluggable database/schema/field isolation), but there's no visible test suite validating these isolation strategies work correctly across different JDK versions (8, 17, 21). This is a critical feature gap—tests should verify that tenant data doesn't leak across isolation layers. Adding integration tests in a new 'lamp-base-biz/src/test/java/' directory would ensure data isolation integrity.

• [ ] Create test class 'TenantIsolationStrategyIntegrationTest' in 'lamp-base-biz/src/test/java/top/tangyh/lamp/base/biz/tenant/'
• [ ] Write test cases for database-level isolation (separate DB per tenant)
• [ ] Write test cases for schema-level isolation (shared DB, separate SCHEMA per tenant)
• [ ] Write test cases for field-level isolation (shared schema, tenant_id column filtering)
• [ ] Add cross-tenant query validation to ensure queries return only tenant-specific data
• [ ] Update pom.xml dependencies if needed (testcontainers for MySQL, ensure JDK 8/17/21 compatibility via maven-surefire-plugin configuration)

Create API documentation for multi-tenant tenant isolation endpoints with OpenAPI 3.0 annotations

The repo includes Swagger integration (visible in 'A极其重要/01-docs/image/业务/swagger.png') but lacks formalized OpenAPI 3.0 annotations for tenant isolation management endpoints. Since lamp-cloud is a multi-tenant platform with pluggable isolation strategies, API consumers need clear documentation on how to interact with tenant-specific data retrieval, tenant lifecycle management, and isolation strategy configuration. This would improve developer experience and API discoverability.

• [ ] Identify tenant management controller classes in 'lamp-system-biz' module (referenced in pom.xml dependencies)
• [ ] Add @Operation, @Parameter, @Schema annotations following OpenAPI 3.0 spec to tenant isolation-related endpoints
• [ ] Document request/response examples showing how isolation works (e.g., 'X-Tenant-Id' header, expected field/schema filtering)
• [ ] Create a new markdown file 'A极其重要/01-docs/MULTI_TENANT_API.md' with isolation strategy selection guide and API examples
• [ ] Add Swagger configuration in a Spring

• Add integration tests for field-level isolation mode in lamp-base-biz: currently only database/schema modes have visible test examples; write @SpringBootTest covering SELECT/INSERT/UPDATE with field masking across 2+ tenants
• Document the Nacos service naming convention used by lamp services: A极其重要/01-docs/docker/03.docker运行项目.md mentions registration but doesn't list actual service IDs (e.g., 'lamp-system-service', 'lamp-file-service') — update README with curl examples to verify Nacos registry
• Create a minimal non-Docker local dev quick-start: current setup requires 6+ services via Docker; write Gradle/Maven profile that embeds H2 (single-tenant), local RabbitMQ (testcontainers), and disables Nacos for 'hello world' SaaS tenant module

• High · Incomplete POM File Analysis — pom.xml. The provided POM file (pom.xml) is truncated and incomplete, cutting off mid-dependency definition. This prevents full dependency analysis for known CVEs and insecure versions. Fix: Provide the complete pom.xml file. Run 'mvn dependency:check' or use OWASP Dependency-Check plugin to scan for vulnerable dependencies. Update all dependencies to their latest secure versions, especially for Spring Cloud, Spring Boot, and database libraries.
• High · Multi-Database Support Without Clear Isolation Validation — lamp-base-biz, lamp-databases modules. The project supports multiple database isolation strategies (database isolation, SCHEMA isolation, field isolation) for multi-tenancy. Without visible validation code in the analysis, there is risk of tenant data leakage through SQL injection or improper isolation logic. Fix: Implement strict parameterized queries/prepared statements for all database operations. Add comprehensive integration tests validating tenant isolation across all three isolation modes. Conduct security review of multi-tenancy implementation, especially around dynamic SCHEMA/database switching.
• High · File Upload Handling via lamp-file-sdk — lamp-file-sdk dependency, dockerfile/MinIo configuration. The presence of lamp-file-sdk dependency and FastDFS/MinIO file storage suggests file upload functionality. Without visible validation code, risks include arbitrary file upload, path traversal, and malicious file execution. Fix: Implement strict file type validation (whitelist approach), scan uploads for malware, enforce file size limits, store files outside web root, implement proper access controls, and disable script execution in file storage directories.
• High · Exposed Docker Infrastructure Components — A极其重要/01-docs/dockerfile/. Multiple docker configurations visible (MySQL, Redis, RabbitMQ, Nacos, Nginx, MinIO) with startup scripts suggest potential for misconfigured credentials or exposed ports in containers. Fix: Use environment variables for all credentials (MySQL root password, Redis auth, RabbitMQ credentials). Implement network segmentation/docker networks. Use secrets management (Docker Secrets, Kubernetes Secrets). Verify all services bind to localhost/internal networks only. Enable TLS/authentication for all services.
• High · Missing HTTPS/TLS Configuration Visibility — A极其重要/01-docs/dockerfile/nginx/conf/nginx.conf. Nginx configuration files are present but no clear visibility into HTTPS enforcement, certificate management, or security headers configuration. Fix: Enforce HTTPS with permanent redirects from HTTP. Configure strong SSL/TLS versions (TLS 1.2+), implement HSTS headers, add security headers (CSP, X-Frame-Options, X-Content-Type-Options). Use certificate automation (Let's Encrypt).
• Medium · Potential Hardcoded Configuration in Docker Scripts — A极其重要/01-docs/dockerfile/*/start.sh, A极其重要/01-docs/shells/. Shell scripts (start.sh, restart.sh) may contain hardcoded credentials, connection strings, or sensitive configuration values. Fix: Remove all hardcoded secrets from shell scripts. Use environment variables, .env files (not in git), or secrets management solutions. Implement secret rotation policies.
• Medium · OAuth Implementation Security Concerns — OAuth service module. Project includes oauth module (restart-oauth.bat, implied oauth service) but implementation details are not visible. OAuth implementations commonly have vulnerabilities around state validation, token handling, and scope enforcement. Fix: Ensure OAuth 2.0 best practices: validate state parameter, use PKCE for public clients, implement token expiration/refresh, validate redirect URIs, enforce scope restrictions, sanitize user data from providers, implement rate limiting on token endpoints.
• Medium · Gateway Security Implementation Not Visible — Gateway service module. Gateway module present (restart-gateway.bat) but security configurations for request filtering, rate limiting, and authentication are not visible in provided analysis. Fix: Implement comprehensive gateway security: rate limiting, API key validation, JWT token verification, request/response filtering, CORS policies, WAF rules, and detailed request logging.
• Medium · Nacos Configuration Server Security — 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.