Scaffolds or extends a Gradle Kotlin DSL monorepo with Kotlin, Java toolchain, Spring Boot apps ({group}-api) and Kotlin libraries ({group}-core), plus optional nested groups (e.g. shared-libs/auth). Use when the user asks to create a monorepo, add a domain module (e.g. running/running-api, running-core), or mentions multimodule Kotlin, Spring Boot, Gradle version catalog, módulo-raiz, modulo-app-spring boot, or modulo-library.
| Placeholder | Descrição | Exemplo |
|---|---|---|
{MONOREPO} | rootProject.name / pasta do repo | healthy |
{GROUP} | Slug do domínio (minúsculas, um segmento) | running |
{GROUP_API} | App Spring Boot | {GROUP}-api → running-api |
{GROUP_CORE} | Biblioteca Kotlin | {GROUP}-core → running-core |
{BASE_PKG} | Pacote base | com.{empresa}.{GROUP} — se empresa não vier, usar o group do Gradle do projeto (ex.: com.healthy) |
Regra fixa de nomes: {GROUP}-api e (kebab-case nos paths Gradle).
{GROUP}-core{MONOREPO}/
└── {GROUP}/
├── {GROUP}-api/ # Spring Boot — depende de :{GROUP}:{GROUP}-core
└── {GROUP}-core/ # Kotlin JVM library
settings.gradle.kts: include("{GROUP}:{GROUP}-api", "{GROUP}:{GROUP}-core").
Para libs transversais (reutilizadas por vários domínios), usar a pasta raiz shared-libs/:
shared-libs/
├── {LIB_A}/ # ex.: auth (Kotlin lib)
└── {LIB_B}/ # ex.: events (Kotlin lib)
include("shared-libs:{LIB_A}", "shared-libs:{LIB_B}"). Paths físicos: shared-libs/{LIB_A}/.
Observações:
kotlin("jvm").{BASE_PKG_ROOT}.sharedlibs.{LIB} (nomes de pacote não aceitam hífen, por isso sharedlibs).*-api de outros domínios consomem via implementation(project(":shared-libs:{LIB}")).settings.gradle.kts, build.gradle.kts), version catalog gradle/libs.versions.toml.kotlin-jvm, kotlin-spring, spring-boot, dependency-management com apply false; Foojay em settings se o projeto já usar (org.gradle.toolchains.foojay-resolver-convention).*-api: kotlin("jvm"), kotlin("plugin.spring"), org.springframework.boot, io.spring.dependency-management; implementation(project(":{GROUP}:{GROUP}-core")), spring-boot-starter-web; testes com spring-boot-starter-test + JUnit Platform se o repo já padronizar assim.*-core: só org.jetbrains.kotlin.jvm.{BASE_PKG}.api na app (*Application, controllers), {BASE_PKG}.core na library; application.yml com spring.application.name: {GROUP}-api.jvmToolchain, e KotlinCompile jvmTarget ao mesmo nível (ex.: 25). Kotlin que gera bytecode JVM 25 requer versão compatível do compilador (ver reference.md).server.port em cada application.yml.{MONOREPO}, {GROUP} e {BASE_PKG} (ou derivar de subprojects { group = "..." } existente).settings.gradle.kts, catalog e build.gradle.kts raiz; só adicionar include e módulos novos.build passando.Input: criar domínio running com API e core.
Resultado: pastas running/running-api, running/running-core; projetos :running:running-api, :running:running-core; dependência da API no core.
Versões, matriz Boot/Java/Kotlin e detalhes extras: reference.md.