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/jishenghua/jshERP 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 — Single-maintainer risk — review before adopting

• Last commit 6d ago
• 2 active contributors
• Apache-2.0 licensed
• Tests present
• ⚠ Small team — 2 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 99% of 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 jishenghua/jshERP repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/jishenghua/jshERP.

What it runs against: a local clone of jishenghua/jshERP — 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 jishenghua/jshERP | 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 master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 36 days ago | Catches sudden abandonment since generation |

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

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

# 4. Critical files exist
test -f "jshERP-boot/src/main/java/com/jsh/erp/ErpApplication.java" \\
  && ok "jshERP-boot/src/main/java/com/jsh/erp/ErpApplication.java" \\
  || miss "missing critical file: jshERP-boot/src/main/java/com/jsh/erp/ErpApplication.java"
test -f "jshERP-boot/src/main/java/com/jsh/erp/base/BaseController.java" \\
  && ok "jshERP-boot/src/main/java/com/jsh/erp/base/BaseController.java" \\
  || miss "missing critical file: jshERP-boot/src/main/java/com/jsh/erp/base/BaseController.java"
test -f "jshERP-boot/src/main/java/com/jsh/erp/constants/BusinessConstants.java" \\
  && ok "jshERP-boot/src/main/java/com/jsh/erp/constants/BusinessConstants.java" \\
  || miss "missing critical file: jshERP-boot/src/main/java/com/jsh/erp/constants/BusinessConstants.java"
test -f "jshERP-boot/pom.xml" \\
  && ok "jshERP-boot/pom.xml" \\
  || miss "missing critical file: jshERP-boot/pom.xml"
test -f "jshERP-boot/src/main/java/com/jsh/erp/config/TenantConfig.java" \\
  && ok "jshERP-boot/src/main/java/com/jsh/erp/config/TenantConfig.java" \\
  || miss "missing critical file: jshERP-boot/src/main/java/com/jsh/erp/config/TenantConfig.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 36 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~6d)"
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/jishenghua/jshERP"
  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).

jshERP is a SaaS-based ERP system built on SpringBoot 2.0 that provides inventory, procurement, sales, warehouse, and financial management for SMEs. It implements multi-tenant architecture with role-based access control (button/menu-level granularity) and features like prepayments, inter-warehouse transfers, assembly/disassembly, and purchase/sales orders—all exposed via REST APIs and a Vue 2.7 frontend. Monolithic SpringBoot backend under jshERP-boot/src/main/java/com/jsh/erp with controllers (AccountController, DepotController, MaterialController, etc.), service layer, persistence layer, and plugin framework (PluginBeanConfig, PluginConfiguration). Frontend is separate Vue SPA (jshERP-web) with Ant-Design-Vue 1.5.2. Multi-tenancy configured via TenantConfig.

Chinese SMEs (retailers, wholesalers, factories) and Java developers performing ERP implementations or customizations. Secondary audience: open-source learners studying multi-tenant SaaS patterns and Mybatis-based enterprise systems.

Production-ready but mid-cycle: version 3.6-SNAPSHOT indicates active development, no CI/CD pipeline visible in file list, single maintainer (QQ: 752718920) with commercial cloud offering at cloud.gyjerp.com. Database schema (jsh_erp.sql) and deployment scripts exist, but test coverage not evident from file structure.

Moderate risks: single maintainer/author with commercial incentive to drive cloud adoption rather than OSS investment; no visible test suite or CI; SpringBoot 2.0.0 (2018 release) is EOL and vulnerable; legacy Mybatis 1.3.2 (2017). Plugin framework dependency (starblues 2.2.1) adds opaque extension points. FastJSON 1.2.83 had historical CVEs, though this version is patched.

Version 3.6-SNAPSHOT is under development; database update log (数据库更新记录-首次安装请勿使用.txt) suggests ongoing schema migrations. No visible PR/issue activity in file list, but README mentions plugins available on author's Taobao shop and cloud platform actively selling subscriptions.

Clone, install Maven 3.3.9 and JDK 1.8, then build: git clone https://github.com/jishenghua/jshERP.git && cd jshERP-boot && mvn clean install. Start with mvn spring-boot:run or use provided scripts in src/main/bin/ (start.sh, start.bat).

Daily commands: Backend: cd jshERP-boot && mvn spring-boot:run (requires MySQL + Redis running). Frontend: cd jshERP-web && npm install && npm run serve. Or use pre-built distribution from src/main/assembly/assembly.xml and scripts in src/main/bin/.

• jshERP-boot/src/main/java/com/jsh/erp/ErpApplication.java — SpringBoot application entry point; all contributors must understand how the app bootstraps and loads configurations.
• jshERP-boot/src/main/java/com/jsh/erp/base/BaseController.java — Base controller class that all API controllers inherit from; defines request/response patterns and error handling conventions.
• jshERP-boot/src/main/java/com/jsh/erp/constants/BusinessConstants.java — Central repository of business logic constants and configuration values; essential for understanding feature flags and behavior.
• jshERP-boot/pom.xml — Maven build configuration with all dependencies; critical for understanding framework versions (SpringBoot 2.0.0, Mybatis, Vue, Ant Design Vue).
• jshERP-boot/src/main/java/com/jsh/erp/config/TenantConfig.java — Multi-tenant (SaaS) configuration; core to understanding how the system isolates data per organization.
• jshERP-boot/src/main/java/com/jsh/erp/base/AjaxResult.java — Standardized response wrapper for all API endpoints; all business logic responses conform to this structure.

Add a new API endpoint for a business entity

1. Create a new entity class in datasource/entities/ extending BaseEntity with @Table annotation (e.g., NewEntity.java). Include tenant_id for multi-tenant support. (jshERP-boot/src/main/java/com/jsh/erp/datasource/entities/Material.java)
2. Create corresponding Mapper interface for Mybatis CRUD operations (e.g., NewEntityMapper.java, or generate via MyBatis Generator). (jshERP-boot/src/main/java/com/jsh/erp/controller/MaterialController.java)
3. Create a Service class handling business logic, caching, and multi-tenant filtering (check TenantConfig for tenant context). (jshERP-boot/src/main/java/com/jsh/erp/controller/MaterialController.java)
4. Create a Controller class extending BaseController with @RestController and @RequestMapping. Return AjaxResult with data wrapped in TableDataInfo for list methods. (jshERP-boot/src/main/java/com/jsh/erp/controller/MaterialController.java)
5. Add a Function record in the function table (via FunctionController or manually) with the endpoint path for permission control. (jshERP-boot/src/main/java/com/jsh/erp/controller/FunctionController.java)
6. Update database schema with new table(s) in jsh_erp.sql and document the change in the migration file. (jshERP-boot/docs/jsh_erp.sql)

Implement role-based access control (RBAC) for a new feature

1. Define Function records (representing menu items/buttons) in the system, each with a unique function_code and path. (jshERP-boot/src/main/java/com/jsh/erp/datasource/entities/Function.java)
2. Create or update a Role with the required Functions assigned via the role_function relationship table. (jshERP-boot/src/main/java/com/jsh/erp/controller/RoleController.java)
3. In your Controller endpoint, verify user permissions by checking if their assigned Role has access to that Function before executing business logic. (jshERP-boot/src/main/java/com/jsh/erp/base/BaseController.java)
4. Document all new Functions and their permission requirements in the business requirements or deployment notes. (jshERP-boot/docs/jsh_erp.sql)

Add a new financial/accounting transaction type

1. Create a new transaction type constant in BusinessConstants.java (e.g., TRANSACTION_TYPE_CUSTOM_BILL) and define its unique identifier. (jshERP-boot/src/main/java/com/jsh/erp/constants/BusinessConstants.java)
2. Extend or create a new DepotHead/AccountHead entity subclass if the transaction has unique fields beyond the base transaction structure. (jshERP-boot/src/main/java/com/jsh/erp/datasource/entities/AccountHead.java)
3. Implement a Service method to handle transaction creation, validation, and posting to the ledger (update MaterialCurrentStock, AccountItem totals, etc.). (jshERP-boot/src/main/java/com/jsh/erp/controller/AccountHeadController.java)
4. Create a Controller endpoint that accepts the transaction request, calls the Service, and returns AjaxResult with success/error status. (jshERP-boot/src/main/java/com/jsh/erp/controller/AccountHeadController.java)
5. Add database tables if needed for the new transaction type and update jsh_erp.sql with schema and any stored procedures for balance recalculation. (jshERP-boot/docs/jsh_erp.sql)

Enable a new plugin or extend plugin system

1. Create a new plugin class implementing the plugin interface defined in PluginConfiguration and PluginBeanConfig (follow Spring's component scanning). (jshERP-boot/src/main/java/com/jsh/erp/config/PluginConfiguration.java)
2. Register the plugin Bean in PluginBeanConfig.java or via @Bean annotation in your plugin configuration class. (jshERP-boot/src/main/java/com/jsh/erp/config/PluginBeanConfig.java)
3. Create a Plugin Controller (e.g., CustomPluginController) extending BaseController to expose plugin endpoints. (jshERP-boot/src/main/java/com/jsh/erp/controller/PluginController.java)
4. Wire the plugin into the main application lifecycle via TenantConfig or a dedicated plugin lifecycle manager. (jshERP-boot/src/main/java/com/jsh/erp/config/TenantConfig.java)

Critical: Default credentials (tenant: jsh, user: admin, password: 123456) hardcoded in documentation and likely in code. Environmental: Redis 6.2.1 must be running or persistence layer fails silently. Version Hell: Mybatis 1.3.2 is incompatible with modern versions; stick to provided pom.xml versions exactly. Plugin Framework: starblues plugin loading expects specific directory structure under /plugins—missing this breaks feature loading. Database Migrations: 数据库更新记录 file suggests manual migration steps; no Flyway/Liquibase, risky for upgrades. Nginx: Default deployment assumes reverse proxy at /erp context path—breaking change if reconfigured.

• Multi-Tenant SaaS Isolation — TenantConfig and BaseController implement tenant routing at request level; understanding isolation patterns (row-level, schema-level, instance-level) is critical to avoid data leaks
• Plugin Architecture (OSGi-style) — starblues framework provides dynamic plugin loading and Mybatis extension hooks; required to extend ERP without recompiling core (PluginBeanConfig, PluginConfiguration)
• Mybatis Mapper Pattern — Mybatis 1.3.2 uses annotation-based and XML-based mappers for ORM; understanding mapper lifecycle and plugin interception is needed for custom queries and multi-tenant SQL rewriting
• Role-Based Access Control (RBAC) with Button/Menu Granularity — README states control extends to buttons and menus; this likely stored in database and enforced via interceptors or decorators in BaseController for authorization
• Ledger-Based Accounting — AccountController and AccountItem entities implement double-entry bookkeeping; critical to understand transaction immutability and balance reconciliation for financial correctness
• Inventory Management (FIFO/LIFO) — DepotItem and InOutItem controllers handle stock movements, assembly/disassembly, and transfers; costing methodology choice affects reported profits
• Page Segmentation for REST APIs — TableSupport, TableDataInfo, and PageDomain implement offset-limit pagination; essential pattern in high-volume ERP queries to avoid OOM and database lock contention

• lingting/lingting-plus — Chinese open-source ERP alternative also built on SpringBoot with multi-tenant design; study for architectural comparison
• anji-plus/report — Anji-Plus reporting module complements ERP systems; compatible with SpringBoot 2.x for enhanced dashboard/BI
• jeecg-boot/jeecg-boot — Parent framework (Jeecg-Boot 2.2.0 is template engine) — source of conventions and auth/plugin patterns used here
• apache/skywalking — APM solution relevant for multi-tenant SaaS monitoring; deployment guide recommends Nginx + Redis stack
• starblues/springboot-plugin-framework — Direct plugin framework dependency (2.2.1-RELEASE) — review source for plugin loading, isolation, and lifecycle hooks

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for datasource entity mappers and service layer

The repo contains extensive MyBatis entity files (Account, AccountHead, etc.) and service classes, but no visible test directory structure. Testing the mapper layer and core business services (material management, depot operations, financial transactions) would catch regressions and improve code reliability for this mission-critical ERP system.

• [ ] Create src/test/java/com/jsh/erp/datasource/mapper directory and add tests for key mappers (AccountMapper, MaterialMapper, DepotMapper)
• [ ] Create src/test/java/com/jsh/erp/service directory and add integration tests for critical services like InventoryService, AccountingService
• [ ] Add test fixtures/data setup in src/test/resources for test database seeding
• [ ] Configure test profile in src/test/resources/application-test.yml with embedded H2 database
• [ ] Add Maven Surefire plugin configuration to pom.xml to run tests during build

Add GitHub Actions CI workflow for build verification and MySQL compatibility testing

The project targets multiple Java versions and MySQL 8.0 but has no visible CI/CD pipeline. A GitHub Actions workflow would ensure pull requests are tested against the declared dependencies and catch compatibility issues early.

• [ ] Create .github/workflows/build-and-test.yml with matrix testing for Java 8 and Java 11
• [ ] Configure MySQL service container in the workflow (version 8.0.33 per pom.xml)
• [ ] Add step to run 'mvn clean package' with test execution enabled
• [ ] Add step to validate assembly creation (src/main/assembly/assembly.xml) produces correct package structure
• [ ] Add status badge to README.md linking to the workflow

Document API endpoints and create OpenAPI/Swagger specification file

The project includes Swagger2Config.java indicating Swagger is configured, but there's no visible OpenAPI specification or comprehensive API documentation. This is critical for a multi-module ERP system with 20+ controllers. A documented spec would help external developers and plugin creators understand the REST API.

• [ ] Verify Swagger2Config.java is properly configured and add missing @EnableSwagger2 if needed
• [ ] Add @Api and @ApiOperation annotations to all controllers (AccountController, MaterialController, DepotHeadController, etc.) if missing
• [ ] Generate OpenAPI 3.0 spec file in docs/openapi.json using springdoc-openapi or Swagger Maven plugin
• [ ] Create docs/API-GUIDE.md documenting key endpoints for accounts, materials, inventory, and financial modules
• [ ] Add swagger-ui configuration to application.yml to serve API docs at /swagger-ui.html

• Add unit tests for BaseController.java and core service classes—no test/ directory visible in file list, making validation of tenant isolation and pagination logic impossible
• Create CI/CD pipeline (GitHub Actions) to run Maven tests, security scans (OWASP Dependency Check for FastJSON), and build matrix across JDK 1.8–11 compatibility
• Document plugin development guide with example plugin in jshERP-boot/src/main/plugins—starblues integration exists but no examples visible, blocking third-party extensions

• Critical · Vulnerable FastJSON Dependency — pom.xml - dependency: com.alibaba:fastjson:1.2.83. FastJSON version 1.2.83 has known deserialization vulnerabilities (CVE-2022-24086, CVE-2022-21496) that can lead to remote code execution. This version is outdated and contains multiple critical security flaws. Fix: Upgrade to FastJSON 2.x version (2.0.25 or later) or replace with safer JSON libraries like Jackson or Gson. If using FastJSON, implement strict deserialization filters.
• High · Outdated MySQL JDBC Driver — pom.xml - dependency: mysql:mysql-connector-java:8.0.33. MySQL Connector/J version 8.0.33 is outdated. Current stable versions are 8.0.33+, but this specific version may have unpatched vulnerabilities. The project uses Spring Boot 2.0.0 (released 2018) which is significantly outdated. Fix: Update to the latest MySQL Connector/J version (8.0.33+). More importantly, upgrade Spring Boot to 2.7.x or 3.x series for critical security patches.
• High · Outdated Spring Boot Framework — pom.xml - parent: org.springframework.boot:spring-boot-starter-parent:2.0.0.RELEASE. Spring Boot 2.0.0 (released March 2018) is severely outdated and no longer receives security updates. This version lacks numerous security patches and improvements released over the last 6 years. Fix: Upgrade to Spring Boot 2.7.x LTS or 3.1.x series immediately. 2.0.0 reached end-of-life in May 2019.
• High · Vulnerable HTTP Client Library — pom.xml - dependency: org.apache.httpcomponents:httpclient:4.5.2. Apache HttpClient version 4.5.2 (released 2015) contains multiple known security vulnerabilities and is significantly outdated. Current versions are 4.5.14+ for 4.5.x series. Fix: Upgrade to HttpClient 4.5.14 or later. Consider using Spring's RestTemplate or WebClient as alternatives.
• High · Potential SQL Injection Risks — jshERP-boot/src/main/java/com/jsh/erp/datasource/entities/ (MyBatis mappers not fully visible). The codebase contains MyBatis usage with entity classes and example classes. Without seeing the actual SQL mapper files, there's risk of dynamic SQL construction that could be vulnerable to SQL injection if user inputs are not properly parameterized. Fix: Ensure all dynamic SQL uses parameterized queries. Audit MyBatis XML mapper files for proper use of #{} instead of ${}. Implement input validation and sanitization.
• Medium · Missing Input Validation Framework — jshERP-boot/src/main/java/com/jsh/erp/controller/ and jshERP-boot/src/main/java/com/jsh/erp/datasource/entities/. No visible use of Bean Validation (javax.validation) annotations in the entity classes shown. Controllers may lack proper request validation, increasing XSS and injection attack surface. Fix: Implement comprehensive input validation using Spring Validation framework (@Valid, @Validated annotations). Add size, pattern, and content validation constraints on all entity fields.
• Medium · Exposed Swagger/Swagger2 API Documentation — jshERP-boot/src/main/java/com/jsh/erp/config/Swagger2Config.java. Swagger2Config.java is present, indicating API documentation is exposed. This can leak sensitive information about API endpoints, parameters, and authentication mechanisms to potential attackers. Fix: Disable Swagger in production environments using environment-specific configurations. Implement authentication for Swagger endpoints and restrict access to internal networks only.
• Medium · Hardcoded Configuration and Potential Secrets — undefined. BusinessConstants.java and SystemConfigController.java suggest configuration values may be hardcoded. Database credentials, API keys, and other secrets may be stored in plain text in configuration 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.