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/cq-panda/Vue.NetCore 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 2mo ago
• 2 active contributors
• MIT licensed
• Tests present
• ⚠ Small team — 2 contributors active in recent commits
• ⚠ Concentrated ownership — top contributor handles 70% 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 cq-panda/Vue.NetCore repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/cq-panda/Vue.NetCore.

What it runs against: a local clone of cq-panda/Vue.NetCore — 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 cq-panda/Vue.NetCore | 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 ≤ 91 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "cq-panda/Vue.NetCore(\\.git)?\\b" \\
  && ok "origin remote is cq-panda/Vue.NetCore" \\
  || miss "origin remote is not cq-panda/Vue.NetCore (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 "vol.api.sqlsugar/VOL.Core/DBManager/SqlSugarRegister.cs" \\
  && ok "vol.api.sqlsugar/VOL.Core/DBManager/SqlSugarRegister.cs" \\
  || miss "missing critical file: vol.api.sqlsugar/VOL.Core/DBManager/SqlSugarRegister.cs"
test -f "vol.api.sqlsugar/VOL.Core/BaseProvider/ServiceBase.cs" \\
  && ok "vol.api.sqlsugar/VOL.Core/BaseProvider/ServiceBase.cs" \\
  || miss "missing critical file: vol.api.sqlsugar/VOL.Core/BaseProvider/ServiceBase.cs"
test -f "vol.api.sqlsugar/VOL.Core/BaseProvider/RepositoryBase.cs" \\
  && ok "vol.api.sqlsugar/VOL.Core/BaseProvider/RepositoryBase.cs" \\
  || miss "missing critical file: vol.api.sqlsugar/VOL.Core/BaseProvider/RepositoryBase.cs"
test -f "vol.api.sqlsugar/VOL.Core/Controllers/Basic/VolController.cs" \\
  && ok "vol.api.sqlsugar/VOL.Core/Controllers/Basic/VolController.cs" \\
  || miss "missing critical file: vol.api.sqlsugar/VOL.Core/Controllers/Basic/VolController.cs"
test -f "vol.api.sqlsugar/VOL.Core/Extensions/AutofacManager/AutofacContainerModule.cs" \\
  && ok "vol.api.sqlsugar/VOL.Core/Extensions/AutofacManager/AutofacContainerModule.cs" \\
  || miss "missing critical file: vol.api.sqlsugar/VOL.Core/Extensions/AutofacManager/AutofacContainerModule.cs"

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

Vue.NetCore is a full-stack low-code rapid development framework combining Vue 2/3 frontend with .NET Core/.NET8 backend, featuring a built-in code generator that automatically produces CRUD operations, master-detail forms, approval workflows, and tree/chart components from database schema configuration. It supports multiple databases (SqlServer, MySQL, PostgreSQL, Oracle, DM) and mobile platforms (iOS, Android, H5, WeChat mini-programs via UniApp), eliminating boilerplate through automatic key/value binding and data source mapping. Monorepo with dual-backend architecture: vol.api.sqlsugar/ contains SqlSugar-based ORM implementation (IRepositories/IServices pattern with partial class extensions in Services/Core/Partial/), while legacy EF Core version exists separately. Frontend lives in separate Vue project (inferred, not shown). Code generation engine in VOL.Builder/ uses Sys_TableInfo metadata to scaffold full CRUD stacks. Database scripts segregated by vendor in DB/ (sqlserver/, mysql/, pgsql/, oracle/, etc.).

Full-stack developers and small-to-medium team leads building enterprise CRUD-heavy applications who need to ship features without hand-coding repetitive database access layers, form bindings, and API endpoints. Particularly suited for teams building internal admin panels, mobile apps, and data management systems who want to focus on business logic rather than infrastructure.

Actively maintained and production-ready. The project shows substantial maturity with ~3.5M lines of C# code, comprehensive multi-database support, and a complete UI framework (Element Plus/Element UI). Recent activity includes SqlSugar adapter rewrite (2023.10), .NET 8.0 upgrade documentation, and active community (QQ groups with >1000 members). However, GitHub stars and commit recency are not visible in provided data.

Heavy reliance on code generation creates tight coupling between generator output and business logic—regenerating schemas can overwrite customizations unless careful about partial classes. Single-maintainer risk is present (primary contact QQ: 283591387). Large monolithic codebase (3.5M C# lines) suggests potential difficulty in dependency management; no visible package.lock or explicit dependency constraints provided. Documentation is in Chinese, potentially limiting community contributions.

Primary active work: SqlSugar adapter rewrite (separate from EF Core version, fully maintained). Recent milestone: .NET 8.0 migration documentation (files: 3.ef后台升级.net8.0.docx, 4.sugar后台升级net8.0.docx). Mobile/UniApp support is mature with code generation for mini-programs. No active PRs visible in file list, but community forums (Bilibili videos, QQ groups, cctalk) show ongoing ecosystem engagement.

git clone https://github.com/cq-panda/Vue.NetCore.git
cd Vue.NetCore/vol.api.sqlsugar
# Restore .NET dependencies
dotnet restore
# Configure database connection in appsettings.json
# Run migrations and seed from DB/{sqlserver,mysql,pgsql,oracle}/*.sql
dotnet run --project VOL.Builder/VOL.Builder.csproj
# Access code generator UI (port inferred from launchSettings.json)

Frontend setup in separate Vue project (see http://www.volcore.xyz for Vue3 or http://v2.volcore.xyz for Vue2 docs). Demo credentials: admin666/123456.

Daily commands:

# Backend (from vol.api.sqlsugar/VOL.Builder/)
dotnet run
# Opens code generator UI at default Kestrel port

# Frontend (inferred from Vue project structure)
cd frontend/
npm install
npm run dev  # Vite dev server
# Or for production
npm run build

Requires configured database connection (sqlserver/mysql/pgsql/oracle) in appsettings.json. See VOL.Builder/Properties/launchSettings.json for port settings.

• vol.api.sqlsugar/VOL.Core/DBManager/SqlSugarRegister.cs — Core database initialization and SqlSugar ORM registration—essential for understanding data access layer setup across all database types (SQL Server, MySQL, PostgreSQL, Oracle, DM).
• vol.api.sqlsugar/VOL.Core/BaseProvider/ServiceBase.cs — Base service class that all business services inherit from—defines CRUD and query patterns used throughout the application.
• vol.api.sqlsugar/VOL.Core/BaseProvider/RepositoryBase.cs — Generic repository implementation providing data access abstractions—every data operation flows through this layer.
• vol.api.sqlsugar/VOL.Core/Controllers/Basic/VolController.cs — Base controller for all API endpoints—handles request routing, response formatting, and permission checks for the entire API.
• vol.api.sqlsugar/VOL.Core/Extensions/AutofacManager/AutofacContainerModule.cs — Dependency injection container configuration—registers all services, repositories, and controllers in the IoC container.
• vol.api.sqlsugar/VOL.Core/CacheManager/Service/RedisCacheService.cs — Redis caching abstraction used throughout the framework—critical for performance optimization and distributed caching.
• vol.api.sqlsugar/VOL.Builder/Services/Core/Sys_TableInfoService.cs — Code generation service that orchestrates the automatic generation of CRUD operations and entity mappings from database metadata.

Add a New Data Entity & Auto-Generate CRUD API

1. Create database table in your target database (SQL Server, MySQL, PostgreSQL, Oracle, or DM) (DB/sqlserver/表结构与数据.sql or DB/mysql/mysql表结构与表数据.sql)
2. Use the code generator (VOL.Builder) to scan table metadata via Sys_TableInfoService (vol.api.sqlsugar/VOL.Builder/Services/Core/Sys_TableInfoService.cs)
3. Generator creates entity class, repository interface, and service interface in IRepositories and IServices folders (vol.api.sqlsugar/VOL.Builder/IRepositories/Core/ISys_TableInfoRepository.cs)
4. Generator creates repository and service implementations inheriting from RepositoryBase and ServiceBase (vol.api.sqlsugar/VOL.Core/BaseProvider/RepositoryBase.cs)
5. Generator creates controller inheriting from VolController to expose REST endpoints with automatic CRUD (vol.api.sqlsugar/VOL.Core/Controllers/Basic/VolController.cs)
6. Register new service and repository in Autofac container module if not auto-registered (vol.api.sqlsugar/VOL.Core/Extensions/AutofacManager/AutofacContainerModule.cs)

Extend an Existing Service with Custom Business Logic

1. Locate the auto-generated service in vol.api.sqlsugar/VOL.Builder/Services/Core/YourEntityService.cs (vol.api.sqlsugar/VOL.Builder/Services/Core/Sys_TableInfoService.cs)
2. Find or create the partial service extension file in vol.api.sqlsugar/VOL.Builder/Services/Core/Partial/YourEntityService.cs (vol.api.sqlsugar/VOL.Builder/Services/Core/Partial/Sys_TableInfoService.cs)
3. Add custom methods to the partial class—inject IRepository<Entity> via constructor (already in ServiceBase) (vol.api.sqlsugar/VOL.Core/BaseProvider/ServiceBase.cs)
4. Update the service interface in vol.api.sqlsugar/VOL.Builder/IServices/Core/Partial/YourEntityService.cs to define method contracts (vol.api.sqlsugar/VOL.Builder/IServices/Core/Partial/ISys_TableInfoService.cs)
5. Access SqlSugar query builder via base.GetIRepository().Context or use caching via ICacheService (inherited) (vol.api.sqlsugar/VOL.Core/CacheManager/IService/ICacheService.cs)

Add Custom Caching to a Service Method

1. Open the service class where you want caching (inherits from ServiceBase which provides _cacheService) (vol.api.sqlsugar/VOL.Core/BaseProvider/ServiceBase.cs)
2. Call _cacheService.Get<T>(cacheKey) to retrieve cached data, or _cacheService.Set(cacheKey, value, ttl) to store (vol.api.sqlsugar/VOL.Core/CacheManager/IService/ICacheService.cs)
3. Use CacheKeyExtensions to generate consistent cache keys based on entity type and parameters (vol.api.sqlsugar/VOL.Core/Extensions/CacheKeyExtensions.cs)
4. For distributed caching, RedisCacheService is automatically used if Redis is configured in AppSetting (vol.api.sqlsugar/VOL.Core/Configuration/AppSetting.cs)

Support a New Database Provider (Beyond SQL Server/MySQL/PG/Oracle/DM)

1. Define new database type constant in vol.api.sqlsugar/VOL.Core/Const/DataBaseType.cs (vol.api.sqlsugar/VOL.Core/Const/DataBaseType.cs)
2. Add SqlSugar connection string and DbType mapping in SqlSugarRegister.cs RegisterAssembly method (vol.api.sqlsugar/VOL.Core/DBManager/SqlSugarRegister.cs)
3. Add SQL dialect translation if needed in SqlSugarExtension.cs (vol.api.sqlsugar/VOL.Core/DBManager/SqlSugarExtension.cs)
4. Update database schema migration scripts in DB/ folder with new provider directory and SQL files (DB/sqlserver/表)

1. Code generation overwrites: Auto-generated files are regenerated on schema changes; customizations must live in Partial/ classes or they will be lost. 2. Database metadata dependency: Sys_TableInfo table must exist and be correctly populated; misconfigured table properties (the 30+ mentioned) will generate broken code. 3. Multi-database connection string: appsettings.json must explicitly configure which DB vendor (SqlServer vs MySql vs PGSql); wrong vendor string will cause silent connection failures. 4. Chinese documentation: Most docs and error messages are in Chinese; non-Chinese speakers may struggle with troubleshooting. 5. Partial class fragility: Regenerating code can fail if partial class signatures don't match generated base class—requires careful version management across regenerations.

• Metadata-Driven Code Generation — VOL.NetCore's entire value proposition relies on reading database schema and Sys_TableInfo configuration (30+ properties) to auto-generate full CRUD stacks—understanding this pattern is critical to extending the generator or debugging generated code
• Repository Pattern with Partial Classes — Generated code uses partial classes to separate auto-generated base logic from hand-written extensions, preventing regeneration from wiping customizations—this C# pattern is core to safe modification workflow
• Master-Detail Relationships (One-to-Many) — Framework auto-generates both parent-child form UI and back-end cascade updates for master-detail entities without hand-coding JOIN logic—understanding this pattern is essential for using the advanced features
• Dependency Injection with Autofac — VOL.NetCore uses Autofac for IoC container management; registering custom services, extending interfaces, or modifying DI scopes requires understanding Autofac's module/registration patterns
• Multi-Tenant/Multi-Database Abstraction — Framework supports SqlServer/MySQL/PostgreSQL/Oracle/DM with single codebase via abstraction layer—understanding how VOL switches DB providers is crucial for adding new database support or debugging vendor-specific bugs
• SignalR Real-Time Communication — Approval workflow and data sync features use SignalR for push notifications—understanding hub setup and client subscription is needed for real-time feature customization
• Quartz.NET Job Scheduling — Framework includes Quartz.NET for background tasks (likely batch approvals, data exports)—customizing scheduled job logic requires understanding cron expressions and Quartz job interfaces

• dotnet/aspnetcore — The .NET Core/8.0 foundation that VOL.NetCore builds on—understanding Kestrel, routing, and DI is essential for modifying backend behavior
• sqlsugar-db/sqlsugar — The ORM powering the primary SqlSugar adapter—VOL.NetCore's data access layer is built atop this; custom repository extensions require SqlSugar API knowledge
• vuejs/vue — The frontend framework; understanding Vue 2/3 reactivity and component lifecycle is required for front-end code generation customization
• dcloudio/uni-app — The mobile/mini-program framework VOL.NetCore uses for cross-platform code generation—required for iOS/Android/WeChat mini-program features
• jeecg/jeecg-boot — Comparable Chinese low-code framework with similar CRUD-automation philosophy but EFCore-only; studying its architecture highlights VOL's dual-ORM advantage

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 database initialization scripts documentation and validation helpers for multi-DB support

The repo supports 5+ database systems (SqlServer, MySQL, PostgreSQL, Oracle, DM) with separate SQL scripts in DB/ folder, but lacks documentation on which script to use and automated validation. Create a helper utility and comprehensive guide to prevent setup failures for new contributors.

• [ ] Create DB/README.md documenting each database setup process with prerequisites (SqlServer 2019+, MySQL 5.7+, etc.)
• [ ] Add DB/validation-scripts/ folder with PowerShell/Bash scripts to verify database connectivity and schema creation for each DB type
• [ ] Create vol.api.sqlsugar/VOL.Core/DbInitializer/ class to auto-detect and validate active database configuration against matching SQL scripts
• [ ] Document in main README.md the database selection workflow during initial setup

Add comprehensive unit tests for VOL.Core/BaseProvider classes (RepositoryBase, ServiceBase)

The framework's core abstractions (RepositoryBase.cs, ServiceBase.cs, IRepository.cs, IService.cs) lack unit tests. These are critical for ensuring code generation reliability and preventing regressions when maintainers add new features.

• [ ] Create vol.api.sqlsugar/VOL.Core.Tests/BaseProvider/RepositoryBaseTests.cs with tests for CRUD operations, pagination, and filtering
• [ ] Create vol.api.sqlsugar/VOL.Core.Tests/BaseProvider/ServiceBaseTests.cs with tests for service layer caching and business logic composition
• [ ] Add integration tests in vol.api.sqlsugar/VOL.Core.Tests/Integration/ for each supported database (SqlServer, MySQL, PostgreSQL) using TestContainers
• [ ] Document test execution in CONTRIBUTING.md with database setup requirements

Create automated code generation validation tests and GitHub Actions workflow

The code generator (vol.api.sqlsugar/VOL.Builder) is critical but has no automated tests or CI validation. Generated code quality directly impacts all projects using this framework. Adding tests and CI prevents broken code generation in releases.

• [ ] Create vol.api.sqlsugar/VOL.Builder.Tests/ with unit tests for code template generation (ISys_TableInfoService.cs, repository/service stub generation)
• [ ] Add tests validating generated code compiles and follows expected interfaces (inherits from ServiceBase, RepositoryBase)
• [ ] Create .github/workflows/code-generation-ci.yml to run on each PR: build Builder project, execute code generation against test schema, verify compilation
• [ ] Document in 1.项目说明.txt the code generation validation process and expected output structure

• Add English translations to error messages and code comments in VOL.Builder/Services/Core/Sys_TableInfoService.cs—currently Chinese-only, blocking non-Chinese contributors from understanding generation logic.
• Create comprehensive integration tests for the three database adapters (SqlServer/MySQL/PostgreSQL) in DB/ scripts—no test directory visible, making it unclear if generated CRUD code works across all vendors.
• Document the 30+ code generation configuration properties mentioned in README but not explained anywhere—create a property reference guide mapping each Sys_TableInfo column to its generated code effect (e.g., what does 'IsShowByDefault' actually do?).

• Critical · Potential SQL Injection via Code Generation — vol.api.sqlsugar/VOL.Builder, vol.api.sqlsugar/VOL.Core/DBManager. The codebase heavily relies on automatic code generation for SQL queries (evident from Sys_TableInfoRepository and builder components). If the code generator doesn't properly parameterize SQL queries or sanitize user inputs, it could expose the application to SQL injection attacks. The presence of multiple database support (SqlServer, MySQL, PostgreSQL, Oracle) without visible input validation mechanisms increases risk. Fix: Implement comprehensive input validation and parameterized queries in the code generator. Enforce ORM usage (SqlSugar) for all database operations. Audit generated code templates for SQL injection vulnerabilities. Use stored procedures with parameterized inputs where applicable.
• High · Hardcoded Configuration Files Without Encryption — vol.api.sqlsugar/VOL.Builder/Properties/launchSettings.json, Configuration files throughout the project. File structure indicates presence of configuration files (launchSettings.json, config files) which may contain sensitive information. No evidence of encrypted configuration sections or secrets management (Azure Key Vault, HashiCorp Vault, etc.) is visible in the provided structure. Fix: Never commit sensitive credentials to version control. Use secure secrets management: implement ASP.NET Core User Secrets in development, Azure Key Vault or similar service in production. Encrypt sensitive configuration sections. Implement .gitignore for local config files.
• High · Missing Dependency Vulnerability Information — Project root dependencies - vol.api.sqlsugar/**/*.csproj, package.json. No package dependency file (packages.config, .csproj, package.json) content was provided for analysis. This prevents verification of known vulnerable versions of libraries like SqlSugar, Entity Framework, JWT libraries, Autofac, and frontend dependencies (Vue, Axios, etc.). Fix: Provide and review all dependency files. Run OWASP Dependency-Check or NuGet vulnerability scanner regularly. Update all packages to latest secure versions. Use Software Composition Analysis (SCA) tools in CI/CD pipeline to detect vulnerable dependencies.
• High · Insecure JWT Implementation Risk — vol.api.sqlsugar/VOL.Core/Controllers/Basic, JWT middleware implementation (not shown). The framework uses JWT for authentication (mentioned in dependencies), but no visible JWT validation, signature verification, or secure key management is evident in the provided structure. Risk of weak secret keys, algorithm confusion attacks, or missing token expiration validation. Fix: Implement strong JWT validation: use RS256 (asymmetric) instead of HS256 where possible. Store keys securely (never hardcoded). Implement proper token expiration, refresh token rotation, and revocation mechanisms. Use industry-standard JWT libraries with security reviews.
• High · No Visible CORS Configuration — vol.api.sqlsugar/VOL.Core/Controllers/Basic/ApiBaseController.cs, Startup/Program configuration. Frontend-backend separation with Vue + API architecture indicates cross-origin requests. Without visible CORS configuration controls, the API may be vulnerable to unauthorized cross-origin requests or overly permissive CORS policies. Fix: Implement strict CORS policy: whitelist only trusted origins, specify allowed methods (GET, POST, etc.), validate credentials. Never use '*' for Access-Control-Allow-Origin in production. Implement CORS validation for all API endpoints.
• High · Docker Image Security Issues — vol.api.sqlsugar/Dockerfile, vol.api.sqlsugar/.dockerignore. Dockerfile and .dockerignore present but content not shown. Common Docker risks include: using latest/no versioned base images, running as root, exposing sensitive data in layers, missing security scanning, and improper multi-stage builds. Fix: Use specific versioned base images (not 'latest'). Run container as non-root user. Use multi-stage builds to minimize image size and attack surface. Implement Docker image scanning in CI/CD. Include .dockerignore properly to prevent credential leakage.
• Medium · Code Generation Security Risks — vol.api.sqlsugar/VOL.Builder. The framework's heavy reliance on automatic code generation (30+ configurable properties) increases complexity. Generated code may contain security flaws if generator doesn't enforce secure patterns (e.g., missing authorization checks, inadequate input validation, unsafe data binding). 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.