Building a Go Admin Framework Around Governance, Not Just CRUD

#ai

I maintain mss-boot-admin, an open-source Go + React admin project.

This is not a launch post, and I am not asking for stars. I am looking for architecture and governance feedback from developers who have built or maintained internal admin systems.

Why governance matters more than CRUD

CRUD is usually the visible part of an admin system. The hard part starts after the first screens exist:

who can see which menu
which role can call which API
how configuration changes are tracked
how migrations are reviewed
how operational state is exposed
how tests and release notes stay connected to real behavior
how contributors can understand the project without private maintainer memory

That is the direction I want mss-boot to move toward: not just generating admin pages, but making backend governance easier to reason about.

What mss-boot-admin is today

The project currently combines:

Go backend code around the mss-boot framework
Gin and GORM in the backend stack
Casbin for authorization concerns
React, Ant Design v5, and Umi on the frontend side
modules around users, roles, menus, APIs, configuration, notices, tasks, monitoring, and statistics

The broader organization is also moving toward a GitHub-first open-source workflow: CI, CodeQL, OpenSSF Scorecard, issue/PR templates, docs, release notes, and Discussions as the public source of truth.

The architecture question

One design shape in the backend is:

Controller -> Action -> Provider

The goal is to keep controllers thin, keep resource operations consistent, and give cross-cutting concerns a place to live: permissions, context, hooks, data scope, audit behavior, and later better observability.

The tradeoff is obvious: Go developers are rightfully skeptical of abstraction that hides behavior.

So the question is not "can this reduce repetition?" It can. The better question is:

Does it stay debuggable, testable, and understandable as the project grows?

That is the part I want feedback on.

Why I am moving away from generator-first thinking

Code generation can be useful for setup. But if an admin system becomes important, generation is not the main problem anymore.

The harder problems are:

consistent authorization
safe configuration changes
migration discipline
documentation that stays current
release and environment separation
reviewable changes from external contributors
visibility into what changed and why

This is also why I do not want to make legacy dynamic/virtual model features the main direction. They may still matter for existing installations, but the current direction is standard Go code, API-first development, clear tests, and maintainable contracts.

How AI fits into the workflow

I use AI as a maintainer assistant, not as the owner of the project.

The useful parts are:

summarizing PR risk
finding docs gaps
preparing test plans
reviewing dependency upgrades
turning repeated issues into FAQ candidates
keeping project memory in docs instead of private chat history

The maintainer still owns the decisions. That distinction matters.

What I would like feedback on

I would really appreciate criticism on these points:

Does an Action/Hook style layer make sense for a Go admin backend, or does it hide too much behavior?
Where would you draw the line between generic resource actions and explicit service methods?
How would you make hook execution observable and testable?
What would make the README or onboarding more credible to Go developers?
Which parts would you distrust most without stronger tests?

Useful links: