Architectural governance for AI-generated Spring Boot code

Why governance matters in Spring Boot

Spring Boot's value comes from convention: auto-configuration wires beans based on what is on the classpath, and Actuator exposes health, metrics, and management endpoints for production. Enterprise teams layer their own intentional architecture on top — controller, service, repository, and domain packages with a strict dependency direction, an approved set of starters, defined transaction boundaries, and a hardened security and observability posture.

An AI coding agent optimizing for a passing build does not know any of that is load-bearing. It will reach for the repository from a controller, add a starter to "just make it work," or relax a security rule to unblock a test. Each shortcut is plausible in isolation and corrosive in aggregate. Mneme keeps the enterprise architecture in the agent's context and checks the diff before it merges.

What Mneme can govern

Mneme governs the architectural decisions a Spring Boot team has already made — expressed as repo-native rules in a decision corpus, not as a built-in Spring rule pack. Common surfaces:

• Layered boundaries — controller, service, repository, and domain responsibilities stay separated.
• Package structure and dependency direction — the approved module layout and import direction are preserved.
• Approved starters and dependencies — additions to the build are constrained to a vetted list.
• Spring Security configuration — authentication and authorization rules are not silently weakened.
• Actuator exposure — management endpoint exposure follows the approved policy.
• Transaction boundaries — @Transactional ownership stays in the service layer.
• DTO, persistence, exception-handling, and observability conventions — organization-specific patterns hold.

Five concrete examples of what the governance layer catches in Spring Boot repos under AI-assisted development:

// AI-generated in web/UserController.java
@RestController
class UserController {
    private final UserRepository repo;   // repository injected into the web layer

    @GetMapping("/users/{id}")
    User get(@PathVariable Long id) {
        return repo.findById(id).orElseThrow();
    }
}

<!-- AI added to pom.xml during a refactor -->
<dependency>
  <groupId>org.unvetted</groupId>
  <artifactId>spring-boot-starter-quick-fix</artifactId>
</dependency>

# AI-generated in application.properties
management.endpoints.web.exposure.include=*
management.endpoint.env.show-values=always

// AI-generated in config/SecurityConfig.java
http.csrf(csrf -> csrf.disable())
    .authorizeHttpRequests(reg -> reg.anyRequest().permitAll());

// AI-generated in web/TransferController.java
@PostMapping("/transfer")
@Transactional   // transaction boundary in the web layer
void transfer(@RequestBody TransferRequest req) {
    accountService.debit(req.from(), req.amount());
    accountService.credit(req.to(), req.amount());
}

Example governance decisions

These are illustrative rules a Spring Boot team would author in its own decision corpus. Mneme does not ship them as defaults — it enforces the decisions you record.

How governance fits the workflow

Mneme sits between your architectural decisions and the AI coding tools writing Java. The loop is the same one Mneme runs for any repository:

1. Decisions and ADRs are recorded

   Your architectural decisions live as records in .mneme/project_memory.json — each with a scope, constraints, and anti-patterns. ADRs can be imported into the same corpus.

2. Mneme retrieves the relevant intent

   On a prompt or a file write, Mneme retrieves the decisions in scope for the change and injects them into the agent's context — governance before generation, not review after the fact.

3. The AI coding agent changes the code

   Claude Code, Cursor, Copilot, or a custom agent edits controllers, services, repositories, configuration, and the build with that context in hand.

4. Mneme checks the proposed change

   mneme check evaluates the diff against the corpus: a matched constraint surfaces as WARN, an anti-pattern hit as FAIL. Aligned changes pass cleanly.

5. CI gates the merge

   In --mode strict a WARN exits 1 and a FAIL exits 2, so the regression blocks the PR; --mode warn annotates without blocking. One corpus serves the editor, the terminal agent, and the CI runner.

Where it fits in a Java codebase

Spring Boot governance is repository-level governance applied to a layered JVM project: paths, package boundaries, dependency direction, and configuration files such as pom.xml, build.gradle, and application.properties. The decision corpus lives at .mneme/project_memory.json; mneme check --mode strict gates PR diffs in CI. Java sits at the repo-level tier today — Spring-aware semantic packs are roadmap, not a current claim. See the full coverage matrix for where Java fits.

Bring existing decisions in through ADR import, set up the editor and terminal with the Cursor and Claude Code integrations, and gate merges with GitHub Actions.