mss-boot-admin

English | 简体中文

mss-boot-admin is an Agent-native management-system development foundation. It combines a production-oriented Gin + React + Ant Design reference application with machine-readable project contracts, Feature and AdminModule specifications, deterministic full-stack generation, repository Skills, a project MCP server, reproducible setup, change-aware verification, Agent Evals, versioned application Blueprints, and conflict-aware downstream upgrades.

The runtime admin platform still provides identity, RBAC, organization, configuration, audit, notification, task, internationalization, storage, WebSocket, and observability capabilities. Runtime dynamic models, virtual CRUD, and browser-facing code generation have been removed; new business modules use development-time specifications, the offline deterministic cmd/mss generator, and compiled vertical modules.

business intent
  → Feature and Acceptance contract
  → AdminModule contract
  → deterministic generation
  → Agent implements non-template business rules
  → change-aware verification and Evals
  → reviewable PR and upgradeable downstream application

./mss context --format json
./mss doctor --strict --format json
./mss setup
./mss dev --detach
./mss verify --changed
./mss eval run --all

The project has undergone comprehensive polish rounds focusing on:

• Stability (P0): Fixed nil dereference risks, boundary checks, panic prevention, auth coverage, and polling cleanup
• Code Quality: Eliminated all TypeScript errors, unified page structures, removed duplicate keys
• Abstraction: Created reusable components (AuthShell, useMonitorData hook), unified API response format
• Testing: Documented 70+ test cases, executed core scenarios successfully
• Documentation: Added CHANGELOG, CONTRIBUTING guide, and comprehensive configuration tutorial

Beta Environment

Swagger

Online documentation Video tutorial

All active development now happens in this repository. The former standalone repositories are retained only as migration history and compatibility references.

Experience address

Account: admin Password: 123456

• Support internationalization
• Standard Restful API development specifications
• RBAC permission management based on Casbin
• Database storage based on Gorm
• Middleware development based on Gin
• Swagger document generation based on Gin
• Support oauth2.0 third-party login
• Support swagger document generation
• Support multiple configuration sources (local files, embed, object storage s3, etc., databases supported by gorm, mongodb)
• Support database migration
• Support governance-oriented admin modules such as users, roles, menus, departments, posts, APIs, and configuration
• Support operational modules such as notices, tasks, monitoring, and statistics
• Agent-native contracts, deterministic generation, project MCP tools, change-aware verification, downstream Blueprints, and three-way foundation upgrades

• User management: Users are system operators, and this function mainly completes the configuration of system users.
• Department management: Maintain organization hierarchy and ownership boundaries.
• Post management: Maintain post data for organization and permission collaboration.
• Role management: Role menu permission allocation, set role data range permission division by organization.
• Menu management: Configure system menus, operation permissions, button permission identifiers, etc.
• API management: Maintain API registry information for governance and permission mapping.
• Option management: dynamically configure enumerations.
• System configuration: Manage the configuration of various environments.
• Notice announcement: user notification message.
• Task management: Manage scheduled tasks, including execution logs.
• Internationalization management: Manage internationalization resources.
• Account and token management: Support OAuth2 binding and personal access tokens.
• Monitoring and statistics: Provide runtime visibility and statistics querying capabilities.

• Install Go 1.26+
• Optional for backend integration testing: MySQL 8.0+ and Redis 7+
• Frontend development: Node.js 22+ and pnpm 9+

git clone https://github.com/mss-boot-io/mss-boot-admin.git
cd mss-boot-admin

./mss doctor --strict --format json
./mss setup
./mss dev --detach
./mss dev status --format json

Create or validate development contracts before editing repetitive code:

./mss spec validate .mss/features/example-supplier-onboarding.yaml
./mss feature plan .mss/features/example-supplier-onboarding.yaml
./mss module generate .mss/modules/example-supplier.yaml --format json
./mss verify --changed

The manual backend, frontend, migration, Blueprint, upgrade, Skills, MCP, and Eval workflows are documented under docs/docs/agent/.

				mss-boot-io
telegram🔥🔥🔥	WeChat	WeChat MP🔥🔥🔥		bilibili🔥🔥🔥

The mss-boot-io project has always been developed in the GoLand integrated development environment under JetBrains, based on the free JetBrains Open Source license(s) genuine free license. I would like to express my gratitude.

1. ant-design
2. ant-design-pro
3. umi
4. gin
5. casbin
6. gorm
7. gin-swagger
8. jwt-go
9. oauth2

If you think this project helped you, you can buy a glass of juice for the author to show encouragement 🍹

The project follows strict testing requirements to ensure code quality and reliability.

make test runs go test -coverprofile=coverage.out ./.... Before opening a backend PR, check these local prerequisites:

• Use Go 1.26+, matching go.mod and GitHub Actions.
• Run make deps once after pulling dependency or go.sum changes.
• Redis-backed tests generally use miniredis, but a local Redis 7 instance is useful when validating cache/session behavior manually.
• No real production DSN, token, Kubernetes cluster, or private credential is required for make test.
• CI starts Redis 7 with supercharge/redis-github-action, then runs make deps, make test, and make build.

If a local test fails because an optional external service is unavailable, mention that in the PR verification notes and include the exact command output. Do not paste real credentials or production endpoints.

• Location: *_test.go alongside source files
• Minimum coverage: 80%
• Run command:

  go test ./... -v -coverprofile=coverage.out

• Verify coverage:

  go tool cover -html=coverage.out
  # Or check terminal summary
  go tool cover -func=coverage.out | grep total

• Focus: API endpoints with database interactions
• Test databases: Use test databases (SQLite in-memory for unit tests, real DB for integration)
• Run command:

  go test -tags=integration ./...

• Verify: Database migrations, API contracts, and service integrations

• Full Stack Testing: Uses Playwright for browser automation
• Critical user flows: login, CRUD operations, permissions
• Run command: pnpm e2e (executed in frontend project)

1. DEVELOPMENT PHASE
   └── Write code
   └── Write tests (TDD preferred)
   └── Ensure compilation

2. TESTING PHASE (MANDATORY)
   ├── Unit Tests: go test ./...
   ├── Integration Tests: go test -tags=integration ./...
   └── E2E Tests: pnpm e2e (for major features)

3. VERIFICATION PHASE
   ├── Check test coverage (≥80%)
   ├── All tests must pass
   └── Document test results

// service/user_test.go
package service

import (
    "testing"
    "github.com/stretchr/testify/assert"
)

func TestUserService_Create(t *testing.T) {
    // Setup
    db := setupTestDB(t)
    svc := &UserService{}
    
    // Execute
    user, err := svc.Create(ctx, &CreateUserRequest{...})
    
    // Verify
    assert.NoError(t, err)
    assert.NotNil(t, user)
    assert.Equal(t, "expected", user.Field)
}

Before committing, run:

# Run all tests
go test ./... -v -race -coverprofile=coverage.out

# Check coverage meets requirements
go tool cover -func=coverage.out | grep total # Must be ≥ 80.0%

MIT

Copyright (c) 2024 mss-boot-io