The JVM Edition

What it is

The JVM Edition is content-aware Java / Kotlin (JVM) detection in faf-cli. You run faf auto in a project with a root-level pom.xml, build.gradle, or settings.gradle(.kts); it classifies from build signals you already ship, then writes durable project context into project.faf so AI agents know what they’re standing in.

It classifies your project as one of:

• MCP server — official io.modelcontextprotocol.sdk, Spring AI MCP starters, Kotlin MCP SDK
• Backend — Spring Boot (plugin / parent / starters), Quarkus, Micronaut, Ktor server
• CLI — Gradle application + mainClass; Picocli; Clikt
• Library — bare Maven jar / aggregator pom, java-library, no host signals. Libraries stay libraries.
• Mobile — com.android.application (AGP 9 shape; no kotlin-android required). Android is a facet, not a second brand.

Also recorded: build tool (Maven / Gradle), main language signal (Java · Kotlin · both), framework label, facets (android · multiplatform), and an inspectable found-line. Not a black box.

Why it exists

Every JVM project has a pom or a gradle file. Not every JVM project is a Spring service.

Aggregators, pure libraries, Spring Boot apps, MCP servers, Picocli tools, and Android apps all ship build files. Filename-only tooling treats them as the same thing — often “some Java backend” — and the agent brief invents controllers you don’t have or refactors a jar like an API.

Wrong brief: “Java web service — add controllers.”
Right brief: library · or backend + Spring Boot · because the build said so.

The build already encoded the shape: plugins, then parents / packaging, then deps and starters, and on Gradle often libs.versions.toml plus a multi-module settings graph. The JVM Edition exists so the first fact agents get is the one you already declared — what the project actually is.

What’s in it for JVM devs

• Agents that match the repo. Spring stays Spring. Classlibs stay classlibs. No invented web host from a bare build file.
• Zero new config. No tags, no extra manifest — it reads the pom / Gradle you already ship, including version catalogs.
• Honest unknowns. Unrecognized plugins fall through to library — not a fake backend label. One brand JVM; Android / KMP are facets.

Try it

Needs Node (or Bun). No account for the CLI. Pin 7.5.1 — don’t rely on a stale global.

Open project.faf — read project.type and the # found: line: bare library / aggregator → library (and tech_stack stays Java, not Spring). Boot plugin or parent → backend + Spring Boot.

RED or Yellow score on a new repo is normal — human slots empty. Detection ≠ Trophy. Shape first; fill who/what/why when you want ✪ 100%.

Daily use: npm install -g faf@7.5.1 (short name) or faf-cli@7.5.1, then faf auto && faf score. Cold-checked on the public registry for this pin.

Bounds

• Does: static classify from root Maven/Gradle + settings modules + libs.versions.toml (plugins · parents · packaging · deps). Spring Boot on tech_stack only when the file body says so.
• Does not: treat every pom / gradle as Spring · run Gradle · resolve every build-logic convention · know every GAV on Maven Central. Unknown → library, not a fake backend.