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/flipped-aurora/gin-vue-admin 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 the board

• Last commit 2d ago
• 11 active contributors
• Distributed ownership (top contributor 44% of recent commits)
• Apache-2.0 licensed
• CI configured
• ⚠ No test directory 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 flipped-aurora/gin-vue-admin repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/flipped-aurora/gin-vue-admin.

What it runs against: a local clone of flipped-aurora/gin-vue-admin — 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 flipped-aurora/gin-vue-admin | 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 main 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 flipped-aurora/gin-vue-admin. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/flipped-aurora/gin-vue-admin.git
#   cd gin-vue-admin
#
# 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 flipped-aurora/gin-vue-admin and re-run."
  exit 2
fi

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

# 4. Critical files exist
test -f "server/api/v1/enter.go" \\
  && ok "server/api/v1/enter.go" \\
  || miss "missing critical file: server/api/v1/enter.go"
test -f "server/config/config.go" \\
  && ok "server/config/config.go" \\
  || miss "missing critical file: server/config/config.go"
test -f "server/cmd/mcp/main.go" \\
  && ok "server/cmd/mcp/main.go" \\
  || miss "missing critical file: server/cmd/mcp/main.go"
test -f "server/api/v1/system/sys_user.go" \\
  && ok "server/api/v1/system/sys_user.go" \\
  || miss "missing critical file: server/api/v1/system/sys_user.go"
test -f "server/api/v1/system/sys_auto_code.go" \\
  && ok "server/api/v1/system/sys_auto_code.go" \\
  || miss "missing critical file: server/api/v1/system/sys_auto_code.go"

# 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/flipped-aurora/gin-vue-admin"
  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).

Gin-Vue-Admin is an enterprise-grade full-stack development platform combining Vite + Vue3 + Gin that generates production-ready frontend and backend code with a single click. It provides a code generator, form builder, and AI-assisted development via MCP (Model Context Protocol) support, eliminating boilerplate for JWT auth, role-based access control, dynamic routing, and CRUD operations across Go backend and Vue3 frontend. Monorepo structure: server/ contains the Go backend (Gin framework, GORM ORM, Casbin RBAC via server/api/v1/), web/ contains the Vue3 frontend, and deploy/ holds Docker, Kubernetes, and docker-compose templates. Code generation tools live in server/cmd or similar, allowing round-trip scaffolding from CLI.

Full-stack developers and small-to-medium startup teams who need to rapidly scaffold enterprise applications with built-in authentication, authorization, and admin dashboards. Specifically targets teams using Go on the backend and Vue3 on the frontend who want to minimize handwritten boilerplate for data-driven apps.

Actively maintained and production-ready: the repository shows recent commit activity with Go 1.24 and Vue 3.3.4, includes CI/CD workflows (.github/workflows/ci.yaml), Docker/Kubernetes deployment configs, and comprehensive documentation in multiple languages. The project has significant LOC (1.1M Go, 912K Vue) and pre-built examples, indicating maturity.

Moderate risk: the project has 30+ external Go dependencies (AWS SDK, Casbin, MongoDB, Redis, file storage providers) which increases supply-chain surface area. Single-repo maintainer structure (flipped-aurora) and no visible test coverage metrics could impact reliability. Monitor the GitHub issues and commit frequency for sign of stalling.

Active development on AI/MCP integration (referenced in README as 'MCP辅助服务' and GvaClaw plugin ecosystem), Vite + Vue3 modernization, and Kubernetes deployment templates. Recent additions include Go 1.24 toolchain compatibility and enterprise storage provider support (Aliyun OSS, AWS S3, MinIO, Huawei OBS, Qiniu, Tencent COS).

Clone the repo: git clone https://github.com/flipped-aurora/gin-vue-admin.git. For the backend: cd server && go mod download && go run main.go. For the frontend: cd web && npm install && npm run dev. See server/README.md and web package.json for specific runtime requirements (Node 16+, Go 1.20+).

Daily commands: Backend: cd server && make run (Makefile present). Frontend: cd web && npm run dev (Vite dev server). Or use docker-compose: cd deploy/docker-compose && docker-compose up. Check server/Dockerfile and deploy/docker/Dockerfile for containerized setup.

• server/api/v1/enter.go — Entry point for all v1 API route registration; defines the contract all API handlers must implement
• server/config/config.go — Core configuration struct and loader; all runtime settings derive from this single source of truth
• server/cmd/mcp/main.go — MCP service bootstrap; critical for AI-assisted code generation and skills management features
• server/api/v1/system/sys_user.go — User authentication and JWT flow; foundational for permission management and multi-login interception
• server/api/v1/system/sys_auto_code.go — Code generation engine; demonstrates the full request-response cycle and form/table generation patterns
• server/api/v1/system/sys_menu.go — Dynamic route and permission binding; shows how visibility control and RBAC integrate
• server/config/gorm_mysql.go — Database initialization pattern; demonstrates multi-database support strategy (MySQL, PostgreSQL, SQLite, Oracle, MSSQL)

Add a New API Endpoint

1. Create handler file in server/api/v1/system/ or server/api/v1/example/ following naming convention sys_<feature>.go (server/api/v1/system/sys_user.go)
2. Define request/response structs and implement the Gin handler function (receiver: *SystemApi). Use request binding (c.ShouldBindJSON) and middleware guards. (server/api/v1/system/sys_user.go)
3. Register route in server/api/v1/enter.go by adding a new method to SystemApiGroup that groups related endpoints. Follow pattern: group.POST("/path", handler) (server/api/v1/enter.go)
4. Add API record to database (sys_api table) with method, path, and description for Casbin permission binding. Use sys_api.go CreateApi endpoint. (server/api/v1/system/sys_api.go)
5. Assign permission to role via Casbin policy (sys_casbin.go) or use web UI menu to auto-bind visibility (server/api/v1/system/sys_casbin.go)

Add a New Database Model & Auto-Generate CRUD API

1. Define struct in server/model/ directory with gorm tags (e.g. json, gorm). Example: type ExaCustomer struct { ID uint, Name string, ... } (server/api/v1/system/sys_auto_code.go)
2. Use sys_auto_code.go endpoint to auto-generate: POST /system/autoCode with structName, packageName, fieldData array. Engine creates API handlers, service layer, request/response types. (server/api/v1/system/sys_auto_code.go)
3. Generated files appear in server/api/v1/<module>/ and server/service/. Review and override auto_code_template.go if custom template needed. (server/api/v1/system/auto_code_template.go)
4. Call CreateApi to register endpoints in sys_api table. Assign role permissions via sys_casbin.go UI. (server/api/v1/system/sys_api.go)

Integrate a New OSS Provider (e.g., MinIO)

1. Create server/config/oss_<provider>.go (e.g. oss_minio.go) with provider-specific config struct and init function (server/config/oss_aliyun.go)
2. Add config field to root Config struct in server/config/config.go, e.g. OssMinio: OssMinio{} (server/config/config.go)
3. Create service/upload/ adapter that implements UploadFile, DeleteFile, GetFileList interfaces for your provider (server/api/v1/example/exa_file_upload_download.go)
4. Update exa_file_upload_download.go handler to instantiate your new provider based on config. Support multi-provider selection via sys_params.go. (server/api/v1/example/exa_file_upload_download.go)

Add a Custom AI Workflow via MCP Skills

1. Create workflow definition in server/cmd/mcp/skills/ (YAML or JSON) with input schema, LLM prompt template, output schema (server/cmd/mcp/main.go)
2. Register skill in sys_skills.go using POST /system/skills with name, description, workflow_ref, permission_role (server/api/v1/system/sys_skills.go)
3. MCP service (server/cmd/mcp/main.go) loads skill on startup and listens for invocation. Skill calls auto_code_mcp.go API to trigger code generation. (server/cmd/mcp/main.go)
4. Frontend (Vue3) invokes skill via AI workflow session (ai_workflow_session.go) with user input; streams SSE response. (server/api/v1/system/ai_workflow_session.go)

Database initialization: server expects MySQL/PostgreSQL/SQLite to be running and configured via environment variables (check server/config/ for .yaml files specifying DB_HOST, DB_PORT, DB_USER, DB_PASS). Redis is optional but required for production caching. JWT secret key must be set and rotated. Frontend requires Node 16+ and npm/pnpm; Vite build output goes to web/dist/. Casbin RBAC rules are database-driven, so seeding role_casbin_rules table is essential for first startup. Multi-instance deployments need shared Redis for session state.

• Role-Based Access Control (RBAC) with Casbin — Gin-Vue-Admin uses Casbin for declarative permission policies; understanding RBAC models, policy rules, and role-to-action mappings is essential to adding new permissions to generated code
• JWT (JSON Web Token) Authentication — Backend uses golang-jwt to issue and validate stateless tokens for API endpoints; token payload structure and expiration logic affect security and session management
• Model Context Protocol (MCP) — Gin-Vue-Admin integrates MCP servers for AI-assisted code generation and tooling; understanding MCP resources, tools, and prompts enables custom AI workflows
• GORM Hooks and Callbacks — Backend models rely on GORM hooks (BeforeCreate, AfterFind) for soft deletes, audit logging, and timestamp management; essential for custom data validation logic
• Vue3 Composition API and Reactive State Management — Frontend uses Composition API pattern for component logic; understanding reactive(), ref(), and custom composables is critical for extending form generation and CRUD UIs
• Code Generation and Template Rendering — Gin-Vue-Admin's core feature is one-click code generation from templates; understanding Go template syntax and file scaffolding patterns allows customization of generated code style
• Multi-Database Abstraction Layer (GORM Dialects) — Project supports MySQL, PostgreSQL, SQLite, and Oracle via GORM dialects; understanding dialect-specific SQL generation is crucial for complex query optimization

• go-admin/go-admin — Alternative Go + Vue admin dashboard generator with similar RBAC and code generation, but more tightly coupled to specific database schemas
• ory/kratos — Dedicated identity and user management system (auth, MFA, recovery) that could replace Gin-Vue-Admin's JWT auth for enterprise compliance
• casbin/casbin — The underlying RBAC engine used by this project; deep dive into policy rules, adapters, and enforcement logic
• element-plus/element-plus — The Vue3 UI component library that Gin-Vue-Admin frontend depends on; source for all form, table, and modal components
• gin-gonic/gin — Core Go web framework powering the backend; understanding routing, middleware, and context is essential for extending the server

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

Add comprehensive unit tests for server/api/v1/system/sys_api.go and sys_casbin.go

The repo has critical authorization and API management endpoints but the file structure shows no visible test files in server/api/v1/system/. Given this is an enterprise-grade platform with JWT auth and permission management, these core security modules need unit test coverage to prevent regressions. This is especially important since casbin handles RBAC and sys_api manages endpoint permissions.

• [ ] Create server/api/v1/system/sys_api_test.go with tests for CRUD operations on API endpoints
• [ ] Create server/api/v1/system/sys_casbin_test.go testing role/permission enforcement logic
• [ ] Add test fixtures for casbin rules and authority models in server/test/fixtures/
• [ ] Ensure tests cover edge cases like permission conflicts and token expiration

Add GitHub Actions workflow for Go server build/lint/test on each PR

The repo has .github/workflows/ci.yaml but based on the file structure, it appears to lack comprehensive Go-specific CI. With Go 1.24.0 and multiple complex dependencies (gorm, casbin, multiple cloud SDKs), automated linting, testing, and security scanning for the server would catch issues early. This is critical for a platform used in enterprise deployments.

• [ ] Create .github/workflows/server-go-ci.yaml with steps for: go vet, golangci-lint, go test ./..., and govulncheck
• [ ] Add matrix testing across Go 1.23.x and 1.24.x versions
• [ ] Configure code coverage reporting and fail on coverage drops below threshold
• [ ] Add dependency audit steps for go.mod vulnerabilities

Create server/docs/API_ARCHITECTURE.md documenting the relationship between sys_api, sys_casbin, and sys_authority

The codebase has sophisticated permission/authorization logic spread across multiple files (sys_api.go, sys_casbin.go, sys_authority.go, sys_authority_btn.go) but no visible architecture documentation explains how these components interact. New contributors will struggle to understand the permission flow, especially when adding new endpoints or modifying authorization rules. This is a critical gap for an open-source enterprise platform.

• [ ] Document the permission grant flow: user → authority → casbin rules → api endpoint access
• [ ] Create sequence diagrams showing how JWT token validation integrates with casbin RBAC checks
• [ ] Add examples of: adding a new protected endpoint, assigning permissions to roles, and handling button-level permissions
• [ ] Reference the specific files: server/api/v1/system/sys_api.go, sys_casbin.go, sys_authority.go for implementation details

• Add unit tests for server/api/v1/example/exa_attachment_category.go (currently no test files in that directory); helps enforce CRUD patterns for new contributors.
• Document the code generation CLI in server/cmd/ (if present) with step-by-step examples in docs/ for scaffolding a new resource end-to-end.
• Create a web/src/components/FormBuilder example component that demonstrates the built-in form generation feature mentioned in the README but not visible in the file list.

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.