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/GoAdminGroup/go-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.

WAIT — Slowing — last commit 11mo ago

• Last commit 11mo ago
• 17 active contributors
• Distributed ownership (top contributor 47% of recent commits)
• Apache-2.0 licensed
• Tests present
• ⚠ Slowing — last commit 11mo ago
• ⚠ 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 GoAdminGroup/go-admin repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/GoAdminGroup/go-admin.

What it runs against: a local clone of GoAdminGroup/go-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 GoAdminGroup/go-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 ≤ 347 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "GoAdminGroup/go-admin(\\.git)?\\b" \\
  && ok "origin remote is GoAdminGroup/go-admin" \\
  || miss "origin remote is not GoAdminGroup/go-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 "engine/engine.go" \\
  && ok "engine/engine.go" \\
  || miss "missing critical file: engine/engine.go"
test -f "adapter/adapter.go" \\
  && ok "adapter/adapter.go" \\
  || miss "missing critical file: adapter/adapter.go"
test -f "context/context.go" \\
  && ok "context/context.go" \\
  || miss "missing critical file: context/context.go"
test -f "modules/auth/auth.go" \\
  && ok "modules/auth/auth.go" \\
  || miss "missing critical file: modules/auth/auth.go"
test -f "go.mod" \\
  && ok "go.mod" \\
  || miss "missing critical file: go.mod"

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

GoAdmin is a Go framework that generates a production-ready admin panel and data visualization dashboard in ~10 minutes by introspecting your database schema. It provides RBAC authentication, theming with AdminLTE, and plugin system out-of-the-box—inspired by Laravel Admin but built for Go's ecosystem. Monorepo with adapter/ directory containing pluggable bridge implementations for each web framework (gin, echo, chi, beego, etc.), context/ package providing unified request/response handling, and data/ containing schema files for multiple databases (SQLite, PostgreSQL, MSSQL). CLI tool (adm) scaffolds new projects; themes and HTML generation delegated to separate published packages (GoAdminGroup/themes, GoAdminGroup/html).

Go backend developers building internal tools, dashboards, or CMS-like applications who want rapid admin UI generation without writing frontend code. DevOps and data teams needing quick visualization of database records across multiple Go web frameworks (Gin, Echo, Chi, Buffalo, etc.).

Production-ready with 1.4M+ lines of Go code, active CI/CD via Drone, comprehensive test coverage, and documented support for 14+ web frameworks. Project shows consistent maintenance and community engagement (Discord, Telegram, forum). Follows semantic versioning and has stable v1 API.

Large dependency surface (excelize, xorm, 14 framework adapters, UI themes package) creates maintenance burden. Last visible commit age not provided in snapshot, but Drone CI integration and 2-3 year old framework versions (Beego v1.12.1, Gin v1.3.0) suggest potential staleness. Single organization maintainer (GoAdminGroup) with potential single-point-of-failure on core features.

Active development across framework adapters (Beego v2, GoFrame v2 support added alongside v1). Project maintains dual-language docs (English/Chinese) and demo sites. Recent work likely includes plugin ecosystem expansion and UI theme additions (themes package versioned at v0.0.48).

mkdir new_project && cd new_project
go install github.com/GoAdminGroup/adm@latest
adm init web

Then follow generated scaffolding. For contributing to core, clone the repo and run tests via make (Makefile present).

Daily commands:

make test          # Run test suite
make build         # Build CLI binary

Exact dev server startup depends on generated app using adm init (generates example server in chosen framework).

• engine/engine.go — Core engine initialization and orchestration—every contributor must understand how go-admin bootstraps and manages the admin panel lifecycle
• adapter/adapter.go — Abstract adapter interface that enables framework-agnostic integration; critical for supporting 15+ web frameworks (Gin, Echo, Fiber, etc.)
• context/context.go — Request context wrapper that standardizes HTTP handling across all supported frameworks; essential for middleware and request routing
• modules/auth/auth.go — Authentication and authorization core logic; every admin panel depends on user identity verification and permission checks
• go.mod — Dependency declarations and Go version constraint (1.22.10); defines all framework adapters and critical libraries
• examples/datamodel/tables.go — Canonical example of data model registration; demonstrates the primary API developers use to define admin CRUD tables
• modules/auth/middleware.go — Middleware chain for request interception; integrates authentication and context propagation across all adapters

Add a new admin CRUD table

1. Define a new data model struct with database tags in examples/datamodel/ (examples/datamodel/posts.go)
2. Create a table configuration object using the go-admin table builder API (examples/datamodel/tables.go)
3. Register the table in the bootstrap initialization function (examples/datamodel/bootstrap.go)
4. Run database migrations to create the underlying schema (data/migrations/)

Support a new web framework

1. Implement the Adapter interface defined in adapter/adapter.go (adapter/adapter.go)
2. Create framework-specific binding in adapter/{framework}/{framework}.go wrapping the framework's router and request/response types (adapter/gin/gin.go)
3. Add a minimal integration example in examples/{framework}/main.go showing engine initialization (examples/gin/main.go)

Extend authentication and authorization

1. Define custom permission logic in modules/auth/auth.go or extend existing functions (modules/auth/auth.go)
2. Add authorization middleware hooks in modules/auth/middleware.go for request filtering (modules/auth/middleware.go)
3. Update the admin user schema in data/migrations/ if new permission columns are needed (data/migrations/admin_2020_04_14_100427_mysql.sql)

Customize request handling and context

1. Extend the Context interface or add helper methods in context/context.go (context/context.go)
2. Implement URL routing and parameter extraction logic in context/trie.go if needed (context/trie.go)
3. Wire custom context initialization in the engine setup within engine/engine.go (engine/engine.go)

• Multi-framework adapter pattern (Gin, Echo, Fiber, Chi, Gorilla, Beego, etc.) — Golang developers use different frameworks; adapters provide unified abstraction so a single data model works with any framework without rewriting
• SQL database abstraction (MySQL, PostgreSQL, SQLite, MSSQL) — Admin panels often manage legacy databases; multi-dialect support keeps tool flexible across enterprise schemas
• Middleware-based request interception (auth, context wrapping) — Centralized cross-cutting concerns (auth, logging, permission checks) are easier to test and modify than scattered route handlers
• HTML templating with themed UI (GoAdminGroup/themes, GoAdminGroup/html) — Pre-built responsive UI components reduce development friction; external theme package allows customization without forking core
• Context trie for URL routing and parameter extraction — Fast route matching and parameter binding across heterogeneous framework APIs (Gin's *gin.Context vs Echo's echo.Context differ; trie normalizes this)

• Adapter pattern instead of monolithic router

  • Why: Golang ecosystem has competing web frameworks with incompatible APIs
  • Consequence: Each adapter must reimplement request/response handling; increases maintenance burden but enables zero-breaking-change framework upgrades

• External theme package (GoAdminGroup/themes) rather than embedded templates

  • Why: Allows runtime theme switching and community contributions without core repo bloat
  • Consequence: Harder to track UI changes; theme versioning can cause visual regressions if not pinned carefully

• Data models defined in Go code (datamodel/tables.go) rather than DSL/YAML

  • Why: Type safety and IDE autocomplete; leverages Go's compile-time checking
  • Consequence: Schema changes require code recompilation; not suitable for schema-first/database-first workflows

• Request context wrapper abstraction instead of framework-native context

  • Why: Uniform interface for middleware and handlers across all 15 frameworks
  • Consequence: Extra allocation per request; developers cannot use framework-specific features without casting back to native context

• Real-time data updates (no WebSocket/SSE infrastructure built-in)
• GraphQL API generation (REST/table-driven only)
• Horizontal scaling/distributed caching (single-process or external Redis only, no cluster coordination)
• Mobile admin app (HTML5 browser-based only)
• Multi-tenancy (single admin database per deployment)
• AI-powered schema suggestions (purely CRUD-based)
• Custom business logic DSL (Go code only, no workflow engine)

Database initialization: projects must provide schema files (examples in data/admin.db, data/admin.pgsql, data/admin.mssql) or use CLI migrations—no auto-migration by default. Framework-specific context: each adapter maps Go framework context differently; middleware ordering matters for auth. Theme package versioning: themes imported from separate GoAdminGroup/themes repo at v0.0.48—version mismatches can break UI rendering. SQLite version constraint: mattn/go-sqlite3 v2.0.3 requires CGO enabled (breaks pure Go cross-compilation). Driver selection: must explicitly import relevant database driver (go-sql-driver/mysql, lib/pq, go-mssqldb) or operations fail silently.

• Adapter Pattern (Framework Abstraction) — GoAdmin's core design: 14 different Go web frameworks (Gin, Echo, Chi, etc.) are pluggable via adapters that implement a common interface—understanding this is essential to modify framework support or add a new one
• Middleware Chain & RBAC — GoAdmin's authentication flows through framework-native middleware; incorrect middleware ordering breaks role-based access control, so contributors must understand how adapters chain auth middleware
• Schema Introspection & Dynamic UI Generation — GoAdmin reads your database schema at startup and auto-generates CRUD forms and tables; understanding ORM reflection and how XORM maps schemas to UI is critical for adding custom field types or validators
• Role-Based Access Control (RBAC) — Built-in permission system for admin panel users; required for understanding auth middleware and plugin security boundaries in contributed extensions
• Plugin Architecture — GoAdmin's extensibility model allows third-party plugins for custom widgets, data sources, and validators; understanding plugin lifecycle is needed to add new features without forking
• Unified Request/Response Context Abstraction — context/context.go wraps framework-specific HTTP contexts (Gin's *gin.Context vs Echo's *echo.Context) into a single interface—critical for writing framework-agnostic middleware or handlers
• ORM-Driven Code Generation — Unlike traditional code generators, GoAdmin uses XORM's runtime schema reflection to generate UI without code generation step—affects how schema changes propagate and how custom column types are handled

• GoAdminGroup/themes — Official UI theme package (v0.0.48) that go-admin imports; contributes the AdminLTE and other visual themes to generated dashboards
• GoAdminGroup/html — Companion package (v0.0.1) for HTML template generation; used to render admin panel components and forms
• z-song/laravel-admin — Original inspiration and predecessor in the Laravel ecosystem; GoAdmin is the Go port of this mature admin framework design
• ent/ent — Alternative Go ORM with schema-first design that could replace XORM; many Go projects migrating from XORM use Ent for admin panel generation
• grafana/grafana — Alternative for data visualization dashboards in Go; focuses on metrics and time-series rather than CRUD admin panels, but overlaps on visualization needs

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 adapter integration tests

The repo supports 14+ web framework adapters (Gin, Echo, Beego, Fiber, etc.) but adapter/ directory lacks unit tests. Currently only context_test.go exists. Each adapter should have integration tests verifying request/response handling, middleware chain compatibility, and context passing. This prevents regressions when adapter code is modified.

• [ ] Create adapter/gin/gin_test.go with tests for request/response binding using the gin.Context adapter pattern
• [ ] Create adapter/echo/echo_test.go testing Echo's context wrapping and route parameter extraction
• [ ] Create adapter/gofiber/gofiber_test.go for Fiber's async context handling
• [ ] Add test utilities in adapter/adapter_test_utils.go for shared adapter testing patterns
• [ ] Update Makefile test target to run all adapter tests via 'go test ./adapter/...'

Add missing database migration verification tests

The data/migrations/ directory contains SQL scripts for MySQL, PostgreSQL, SQLite, and MSSQL (8 migration files total), but there's no test suite verifying these migrations execute correctly against actual databases. This is critical for catching syntax errors and schema inconsistencies across database types before they reach users.

• [ ] Create data/migrations/migrations_test.go with database connection setup for each DB type using docker-compose
• [ ] Add test cases that apply migrations sequentially (2020_04_14 then 2020_08_04) and verify table schemas match expected structure
• [ ] Verify migrations work for all 4 database types: MySQL, PostgreSQL, SQLite (data/admin.db), MSSQL
• [ ] Add test to ensure migrations are idempotent (can re-run without errors)
• [ ] Update .drone.yml or create GitHub Actions workflow to run migration tests against live database containers

Implement context.go trie-based routing test suite

The context/trie.go file implements a custom trie data structure for route matching but context_test.go only has basic tests. No tests exist for edge cases like wildcard matching, parameter extraction from complex paths, or trie insertion/lookup performance. This is foundational for request routing.

• [ ] Expand context/context_test.go with TestTrieWildcardMatching covering patterns like '/users/:id/posts/:post_id'
• [ ] Add TestTrieEdgeCases for empty paths, trailing slashes, special characters, and duplicate route registration
• [ ] Add TestTrieLookupPerformance benchmarking trie.Get() with 1000+ routes to verify O(n) behavior acceptable
• [ ] Add TestTrieParameterExtraction verifying named parameters are correctly extracted from matched paths
• [ ] Document trie behavior in context/context.go with usage examples for maintainers

• Add integration test coverage for adapter/iris/iris.go and adapter/gear/gear.go (context_test.go pattern shows test structure) to ensure RBAC middleware chains correctly across all 14 frameworks
• Document the required schema migrations for PostgreSQL and MSSQL in CONTRIBUTING.md or create helper functions in data/ to auto-detect database type and apply correct schema from admin.pgsql / admin.mssql
• Implement missing error handling in adapter/fasthttp/fasthttp.go and adapter/gofiber/gofiber.go for context extraction failures—currently no visible validation that HTTP context was successfully unwrapped before RBAC checks

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.