@dennisrepa/elevate 1.7.0 → 1.8.0

package/dist/config-DRANL4H4.js

@@ -0,0 +1,13 @@
+import {
+  ConfigError,
+  findRepositoryRoot,
+  loadConfig,
+  resolveConfig
+} from "./chunk-4YCMSRA6.js";
+export {
+  ConfigError,
+  findRepositoryRoot,
+  loadConfig,
+  resolveConfig
+};
+//# sourceMappingURL=config-DRANL4H4.js.map

package/dist/config-DRANL4H4.js.map

@@ -0,0 +1 @@
+{"version":3,"sources":[],"sourcesContent":[],"mappings":"","names":[]}

package/docs/de.md

@@ -7,10 +7,10 @@
 
 ## 🌟 Übersicht
 
-**Elevate** ist ein interaktives Terminal-Dashboard (TUI) zur sicheren, selektiven und transparenten Aktualisierung von Abhängigkeiten in **Polyglot-Monorepos** (Node/npm & Java/Maven) sowie Einzelprojekten.
+**Elevate** ist ein interaktives Terminal-Dashboard (TUI) zur sicheren, selektiven und transparenten Aktualisierung von Abhängigkeiten in **Polyglot-Monorepos** (Node/npm, Java/Maven, Rust/Cargo & Java/Gradle) sowie Einzelprojekten.
 
 * **Feder-Symbolik (`🪶`) & Orange-Brand (`#FF8800`):** Leicht, modern und übersichtlich im Terminal.
-* **Polyglot-Fähig:** Unterstützt gleichzeitig Frontend-Projekte (`package.json` mit npm Workspaces) und Backend-Projekte (`pom.xml` mit Maven).
+* **Polyglot-Fähig:** Unterstützt gleichzeitig Frontend-Projekte (`package.json` mit npm Workspaces) und Backend-Projekte (`pom.xml` mit Maven, `build.gradle` mit Gradle, `Cargo.toml` mit Cargo).
 * **Release Channels:** Filtert Vorabversionen (Beta, RC, Alpha, Milestone, Snapshot) standardmäßig heraus und schlägt ausschließlich produktionsreife Releases vor.
 * **Animiertes Begleiter-Hühnchen („Pip“ 🐣):** Begleitet den Entwickler dezent im Terminal und reagiert auf Aktionen.
 * **Bilinguales i18n:** Jederzeit umschaltbar zwischen Deutsch und Englisch via Taste **`[L]`**.
@@ -19,11 +19,12 @@
 
 ## ✨ Features & Highlights
 
-1. **🌐 Polyglot Monorepo Support (npm, pnpm & Maven):**
+1. **🌐 Polyglot Monorepo Support (npm, pnpm, Maven, Cargo & Gradle):**
    * **Node / npm:** Löst Workspaces genau wie npm auf (inklusive Glob-Mustern wie `packages/**`), berechnet SemVer-Diffs, aktualisiert `package.json`, führt `npm install` aus und prüft das Lockfile.
    * **Node / pnpm** (9 – 12): Dasselbe für pnpm-Repositories — Workspaces aus `pnpm-workspace.yaml`, das `workspace:`-Protokoll, `catalog:`-Einträge, `pnpm install` und eine Lockfile-Prüfung. Repositories mit Yarn oder Bun werden abgelehnt.
    * **Java / Maven:** Findet jede `pom.xml` (auch die Root-POM), lässt Maven die Effective POM berechnen, sucht neuere Versionen über die Repositories des Builds (Mirrors, Nexus/Artifactory, Zugangsdaten aus der `settings.xml`) und prüft die betroffenen Module mit `mvn test-compile`.
-   * **Live-Wechsel:** Ein Tastendruck auf **`[E]`** schaltet im laufenden Betrieb zwischen Frontend- und Backend-Modulen um.
+   * **Java / Gradle:** Findet die Builds des Repositories (Groovy- und Kotlin-DSL, Included Builds, `buildSrc`), fragt Gradle selbst, welche Abhängigkeiten gelten, sucht neuere Versionen über die Repositories des Builds (Mirrors, Nexus/Artifactory, Zugangsdaten), schreibt jede neue Version dorthin, wo ihr Text steht — Build-Skripte, `gradle.properties`, `ext`-Werte, der Version Catalog `gradle/libs.versions.toml`, der `plugins`-Block —, frischt Dependency Locks auf und prüft die betroffenen Projekte mit `testClasses`.
+   * **Live-Wechsel:** Ein Tastendruck auf **`[E]`** schaltet im laufenden Betrieb zwischen Node/npm-, Java/Maven-, Rust/Cargo- und Java/Gradle-Modulen um.
 
 2. **🔍 Version gezielt heraussuchen (`[V]`):**
    * Man muss nicht zwingend auf die `latest` Version aktualisieren: Taste **`[V]`** öffnet ein interaktives Such-Modal für das aktuell ausgewählte Paket.
@@ -71,12 +72,14 @@ Die URL der Registry allein entscheidet bewusst **nicht** über die Herkunft: In
 * **npm:** Schließt der Versionsbereich einer Abhängigkeit die lokale Version eines Workspace-Pakets nicht ein, verlinkt npm das Workspace **nicht**, sondern installiert ein gleichnamiges Paket aus der Registry. Elevate bietet an, den Bereich anzugleichen (z. B. `^1.0.0` ➔ `^2.0.0`). Nach `npm install` prüft es die `package-lock.json`: Jede angeglichene Abhängigkeit muss `"link": true` sein, sonst wird das Update zurückgenommen. Bereiche, die npm immer verlinkt (`*`, `file:`, `workspace:`), bleiben unberührt.
 * **pnpm:** pnpm verlinkt ein Workspace-Paket nur, wenn die Abhängigkeit mit dem `workspace:`-Protokoll geschrieben ist; ein einfacher Bereich wie `^1.0.0` wird aus der Registry aufgelöst — auch wenn die lokale Version ihn erfüllt. Elevate gleicht deshalb `workspace:^1.2.0` ➔ `workspace:^2.0.0` an (Protokoll und Präfix bleiben; `workspace:*`, `workspace:^`, `workspace:~` und `workspace:../lib` brauchen nichts) und führt einen einfachen Bereich auf ein Modul als *nicht verlinkt* (`not-linked`) auf, ohne den Namen je in einer Registry nachzuschlagen oder den Bereich umzuschreiben. Nach `pnpm install` liest es den Abschnitt `importers` der `pnpm-lock.yaml` (`lockfileVersion` 9.x): Jede angeglichene Abhängigkeit muss eine `version` mit `link:` haben, sonst wird das Update zurückgenommen.
 * **Maven:** Hängt ein Modul mit abweichender Version von einem Modul *desselben Reactors* ab (z. B. `1.0.0`, während das Modul auf `1.1.0-SNAPSHOT` steht), bietet Elevate das Angleichen an. Verweise über `${project.version}` brauchen kein Angleichen.
+* **Gradle:** Gradle ersetzt eine Abhängigkeit durch ein Projekt eines *Included Builds*, sobald Gruppe und Name passen, egal welche Version dasteht (`com.acme:lib:1.0.0` wird zum Projekt des Included Builds aufgelöst). Elevate gleicht eine solche Abhängigkeit an die Version des Projekts an und fragt den Namen nie in einem Repository ab; ein Included Build außerhalb des Repositories wird weder angeboten noch abgefragt. Ein Projekt desselben Builds wird nicht ersetzt, eine Abhängigkeit mit seinen Koordinaten ist also eine gewöhnliche.
 * Der Release Channel gilt beim Angleichen nicht: Ziel ist die lokale Version — auch `-SNAPSHOT` —, weil die Module eines Repositorys zusammen gebaut und getestet werden.
 
 ### Private Registries & Dependency Confusion
 
 * Interne Pakete werden nie in einer öffentlichen Registry abgefragt. Löst die Registry eines internen npm-Pakets zu `registry.npmjs.org` auf, wird es mit Begründung als *nicht angeboten* aufgeführt, statt abgefragt zu werden — genau diese Anfrage nach einem internen Namen nutzt ein Dependency-Confusion-Angriff aus.
-* npm-Abfragen verwenden die npm-Konfiguration (`npm config`), Maven-Abfragen Maven selbst — Mirrors, private Repositories und Zugangsdaten gelten ohne eigene Elevate-Konfiguration, und Elevate fasst nie Zugangsdaten an.
+* npm-Abfragen verwenden die npm-Konfiguration (`npm config`), Maven- und Gradle-Abfragen Maven bzw. Gradle selbst — Mirrors, private Repositories und Zugangsdaten gelten ohne eigene Elevate-Konfiguration, und Elevate fasst nie Zugangsdaten an.
+* **Gradle:** Für ein internes Paket (`internalScopes`; eine Plugin-ID zählt wie eine Gruppe) lässt Elevate Gradle dessen Gruppe beim Abfragen mit einem Content-Filter (`excludeGroupByRegex`) von jedem bekannten öffentlichen Repository fernhalten (`repo.maven.apache.org`, `repo1.maven.org`, `plugins.gradle.org`, `dl.google.com`, `jitpack.io` und einige mehr), sodass keine Anfrage nach dem internen Namen sie erreicht; ein Artifactory oder Nexus der Firma gilt als privat, auch wenn es Maven Central spiegelt. Hat der Build dafür nur öffentliche Repositories, wird die Abhängigkeit als *nicht angeboten* aufgeführt, statt abgefragt zu werden. Zugangsdaten in einer Repository-URL verlassen den Scan nie.
 
 ### Wohin Maven-Versionen geschrieben werden
 
@@ -90,6 +93,7 @@ Jedes Update läuft als ein Ablauf: **Snapshot ➔ Schreiben & Installieren ➔
 
 * **npm:** `npm ls` im Repository-Root (fehlende, ungültige oder unerfüllte Abhängigkeiten in allen Workspaces), sofern kein `postUpdateScript` gesetzt ist.
 * **Maven:** `mvn test-compile -pl <geänderte Module> -amd` im Reactor — die geänderten Module *und alle Module, die von ihnen abhängen*. Eine Änderung an der Aggregator-POM baut den ganzen Reactor.
+* **Gradle:** `testClasses` (sonst `assemble`) der Projekte, die die geänderten Dateien betreffen können: ein Projekt und jedes Projekt, das über `project(...)` von ihm abhängt; eine Änderung am Root-Projekt (Root-Skript, `gradle.properties`, Settings, `gradle/libs.versions.toml`) betrifft jedes Projekt. Tasks werden mit dem Projektpfad benannt (`:app:testClasses`), ein Modul eines Included Builds über den Namen seines Builds; ohne jeden Task läuft `help`, das den Build konfiguriert und `buildSrc` kompiliert.
 
 ### Cargo (Rust)
 
@@ -107,12 +111,71 @@ Elevate startet `cargo` aus dem `PATH` (`cargo metadata --no-deps`, `cargo updat
 
 Elevate verwendet den Maven Wrapper des Projekts (`mvnw` / `mvnw.cmd`), sonst `mvn` aus dem `PATH`. Fehlt beides, bricht der Maven-Scan mit einer klaren Meldung ab, statt zu raten. Die Plugin-Versionen sind für reproduzierbare Ergebnisse festgelegt (`maven-help-plugin` 3.5.2, `versions-maven-plugin` 2.22.0) und lassen sich je Repository mit `mavenPlugins` in der `elevate.config.json` ersetzen (siehe [Maven-Plugin-Versionen](#maven-plugin-versionen)). Scans schreiben temporäre Dateien nur nach `target/.elevate-*` und entfernen sie danach.
 
+### Wohin Gradle-Versionen geschrieben werden
+
+Eine Gradle-Build-Datei ist ein Programm, deshalb parst Elevate sie nicht. Es fragt Gradle, was gilt — die Abhängigkeiten jedes Projekts mit der Version, die sie nach Ausführung aller Skripte haben — und sucht dann in den Dateien des Builds nach dem Text, der diese Version trägt. Eine Fundstelle zählt nur, wenn dort genau die von Gradle gemeldete Version steht. Was sich nicht sicher finden lässt, wird nicht geraten, sondern mit Begründung als *nicht angeboten* aufgeführt.
+
+Der Text wird für die Abhängigkeiten eines Moduls (ein Projekt mit Build-Skript) in dieser Reihenfolge gesucht:
+
+1. String- und Map-Notation im Build-Skript des Moduls selbst;
+2. hat dieses Skript kein solches Literal, die Build-Skripte der Eltern-Projekte desselben Builds, das nächste zuerst (dort stehen `subprojects { }` und `allprojects { }`). Das erste Skript mit einem Treffer gewinnt, alle seine Treffer werden geschrieben;
+3. ist die Version ein Name (`"g:a:$v"`, `version: v`): die Definition dieses Namens — zuerst `gradle.properties` (die Datei des Moduls, dann die des Builds), dann `def`-, `ext`- und `extra`-Werte im Skript des Moduls und seiner Eltern. Ein Wert, den Gradle überschreibt, eine mehrdeutige Definition oder eine, die kein einzelnes String-Literal ist, wird *nicht angeboten*;
+4. markiert Gradle die Abhängigkeit als aus einem Version Catalog stammend: `gradle/libs.versions.toml` des Builds.
+
+Nicht durchsucht werden Convention-Plugins in `buildSrc` oder einem Included Build, mit `apply from:` eingebundene Skripte, Init-Skripte und die `gradle.properties` des Benutzers. Beide DSLs werden nach denselben Regeln gelesen — außerhalb von Kommentaren ist jedes String-Literal ein Kandidat:
+
+| Form | Groovy | Kotlin |
+| :--- | :--- | :--- |
+| String-Notation | `implementation 'g:a:1.0'`, `"g:a:1.0"`, `implementation('g:a:1.0')` | `implementation("g:a:1.0")` |
+| Classifier, Extension | `'g:a:1.0:sources@jar'` (nur `1.0` ändert sich) | `"g:a:1.0:sources@jar"` |
+| Map-Notation | `group: 'g', name: 'a', version: '1.0'` (beliebige Reihenfolge) | `group = "g", name = "a", version = "1.0"` |
+| Name als Version | `"g:a:$v"`, `"g:a:${v}"`, `version: v` | `"g:a:$v"`, `"g:a:${v}"`, `version = v` |
+| Plugin | `id 'x' version '1.0'`, `id('x') version('1.0')` | `id("x") version "1.0"`, `kotlin("jvm") version "1.9.20"` |
+
+Eine Koordinate, die ein Modul mehrfach deklariert (in mehreren Konfigurationen, als Constraint, in einem Catalog), ist ein Kandidat, und die neue Version wird an jede Deklaration geschrieben. Ihr Scope ist der erste aus *prod*, *test* und *plugin* unter ihnen; eine Konfiguration ist eine Test-Konfiguration, wenn eines der Wörter ihres camelCase-Namens `test` ist. Platforms, Enforced Platforms und die Mitglieder eines Bundles werden wie Bibliotheken angeboten, ebenso Constraints (`dependencies { constraints { } }`). Abhängigkeiten, die sich eine Versions-Property oder einen Catalog-Eintrag teilen, werden markiert, und widersprüchliche Ziele für einen gemeinsamen Text werden abgelehnt. Edits ersetzen nur den Versionstext und verweigern eine Datei, in der er oder die Zeichen daneben sich seit dem Scan geändert haben (`1.0` wird zu `1.0.1`).
+
+Als *nicht angeboten* aufgeführt wird:
+
+| Grund | Wann |
+| :--- | :--- |
+| `version-constraint` | die Version ist ein Selektor oder trägt eine Einschränkung: `1.+`, `latest.release`, `[1.0,2.0)`, `strictly`, `reject`, `prefer` — eine geänderte Zahl würde die Bedeutung ändern |
+| `declaration-mismatch` | der Text der Version lässt sich nicht sicher finden: berechnete Versionen, ein Convention-Plugin, ein `apply from:`-Skript, ein anderer Catalog als `gradle/libs.versions.toml`, ein von Gradle überschriebener Wert |
+| `invalid-name` | ein externes Modul ohne Gruppe |
+| `lookup-failed` | ein Repository-Fehler (Gradles eigene Worte, ohne Zugangsdaten) oder ein Build ohne deklariertes Repository |
+| `private-on-public-registry` | ein internes Paket, dessen Repositories alle öffentlich sind |
+
+### Version Catalogs
+
+Gradle liest `gradle/libs.versions.toml` eines Builds als Catalog `libs`. Elevate liest die Datei als TOML und ordnet eine Abhängigkeit einem Eintrag über die Koordinaten zu: der Eintrag, dessen `module` (oder `group` und `name`) die der Abhängigkeit sind und dessen wirksame Version nach Auflösung von `version.ref` genau die von Gradle gemeldete ist. Der Versionstext wird an Ort und Stelle geändert — der `[versions]`-Schlüssel bei `version.ref`, sonst der Eintrag selbst (`"g:a:1.0"`, `version = "1.0"`, `version = { require = "1.0" }`) —, und Kommentare, Abstände, Reihenfolge, Zeilenenden und eine Byte-Order-Mark bleiben. Plugin-Einträge (`[plugins]`) werden genauso behandelt, Bundles enthalten nur Aliase und ihre Mitglieder werden als Bibliotheken angeboten, und ein `[versions]`-Schlüssel, auf den mehrere Bibliotheken verweisen, wird als gemeinsam markiert und einmal geschrieben. Einträge mit `strictly`, `prefer` oder `reject` werden als *nicht angeboten* aufgeführt. Gelesen wird nur die Datei des Builds selbst: in den Settings mit `versionCatalogs { }` deklarierte Catalogs nicht, und ein Included Build hat seine eigene Datei.
+
+### Die Gradle-Läufe, die Elevate startet
+
+Elevate parst Build-Dateien nie, um zu erfahren, was gilt, und kontaktiert nie selbst ein Repository. Es startet das Gradle des Builds — den Wrapper, der dem Modul am nächsten liegt, aufwärts gesucht, aber nie oberhalb des Repository-Roots (`sh ./gradlew`, unter Windows `.\gradlew.bat`), sonst `gradle` aus dem `PATH` — im Verzeichnis des Gradle-Builds des Moduls:
+
+| Zweck | Befehl | Timeout |
+| :--- | :--- | :--- |
+| Build beschreiben (Projekte, deklarierte Abhängigkeiten, Repositories) | `-q -m --console=plain --no-configuration-cache -Delevate.mode=describe -Delevate.outDir=… -I <Skript> help` | 5 Min. |
+| neuere Versionen abfragen | dasselbe mit `-Delevate.mode=lookup -Delevate.plan=…` | 5 Min. |
+| Dependency Locks auffrischen | `-q --console=plain --no-configuration-cache :app:dependencies … --update-locks g:a,…` | 10 Min. |
+| verifizieren | `-q --console=plain :app:testClasses …` | 30 Min. |
+
+Die beiden Probe-Läufe nutzen ein kleines Groovy-Init-Skript, das Elevate mitbringt; die Antworten sind JSON-Dateien unter `.gradle/elevate-<id>/` des Builds, das nach dem Lauf in jedem Fall entfernt wird — die Standardausgabe trägt keine Antwort. `--no-configuration-cache` ist nötig: Bei aktiviertem Configuration Cache nutzt Gradle ihn im zweiten Lauf, und das Init-Skript würde nicht laufen. Weder `--daemon` noch `--no-daemon` wird übergeben: Die Läufe nutzen Gradle so, wie das Projekt es konfiguriert hat; ein kalter Daemon kostet einmal ein paar Sekunden, jeder weitere Lauf etwa eine. Ein Scan teilt sich je Gradle-Build einen Describe- und einen Lookup-Lauf, egal wie viele Module angefragt sind. Gradle älter als 7.6 wird mit einer Meldung abgelehnt.
+
+### Dependency Locking und Dependency Verification
+
+* **Locks.** Mit `dependencyLocking { lockAllConfigurations() }` liegt in jedem Projektverzeichnis eine `gradle.lockfile`, und eine angehobene Version lässt den Build scheitern, bis der Lock aufgefrischt ist. Nach dem Update einer Bibliothek frischt Elevate die Lock-Dateien des Root-Builds mit `gradle :app:dependencies :core:dependencies … --update-locks <Koordinaten>` auf — alle gemeinsam, denn ein veralteter Lock schlägt nicht immer fehl: Eine niedrigere deklarierte Version wird stillschweigend auf die gesperrte aufgelöst. Die Lock-Dateien gehören zum Snapshot, ein fehlgeschlagenes Auffrischen oder Verifizieren stellt sie wieder her. Locks von `buildSrc`, von Included Builds, vom `buildscript`-Classpath und von den Settings werden nicht aufgefrischt: Ein Update in einem Included Build oder in `buildSrc`, der Lock-Dateien hat, wird abgelehnt, bevor sich etwas ändert.
+* **Dependency Verification.** Ein Build mit `gradle/verification-metadata.xml` verweigert die Artefakte einer neuen Version. Elevate erzeugt diese Datei nie neu (`--write-verification-metadata` würde die Prüfsumme dessen festhalten, was gerade geladen wurde, und ihren Zweck aushebeln): Das Update wird mit Gradles Meldung zurückgenommen, und du entscheidest.
+
+### Voraussetzungen für Gradle
+
+Ein JDK, das das Gradle des Builds unterstützt, Gradle 7.6 oder neuer und entweder ein Gradle Wrapper im Repository oder `gradle` im `PATH`; fehlt beides, bricht der Gradle-Scan mit einer klaren Meldung ab, statt zu raten. Auf welchem JDK eine Gradle-Version läuft, bestimmt Gradle (Gradle 7.6.6 läuft zum Beispiel nicht auf JDK 21). Die Integrationstests laufen gegen Gradle 7.6.6 (JDK 17), 8.14.3 und 9.8.1 (JDK 21). Nicht abgedeckt: das Aktualisieren des Gradle Wrappers selbst, Android- und Kotlin-Multiplatform-Builds (nicht verifiziert), Windows (spezifiziert, nicht verifiziert) und Plugins aus `settings.gradle`.
+
 ### Repository-Root
 
 Elevate verhält sich gleich, egal wo im Repository es gestartet wird. Der Root wird so bestimmt:
 
 1. Das nächste Verzeichnis (vom Startverzeichnis aufwärts) mit einer `elevate.config.json` ist der Root.
-2. Sonst schlägt npm das nächste Verzeichnis vor, dessen `package.json` `workspaces` deklariert, und Maven das obere Ende der zusammenhängenden POM-Kette (ein `<parent>`, der über `<relativePath>` gefunden wird, und jeder Aggregator, der das Projekt in `<modules>` aufführt). Der äußerste Vorschlag gewinnt.
+2. Sonst schlägt npm das nächste Verzeichnis vor, dessen `package.json` `workspaces` deklariert, Maven das obere Ende der zusammenhängenden POM-Kette (ein `<parent>`, der über `<relativePath>` gefunden wird, und jeder Aggregator, der das Projekt in `<modules>` aufführt) und Gradle das nächste Verzeichnis mit einer `settings.gradle(.kts)` (`buildSrc` gehört zum umgebenden Build, und ein Build, den eine äußere Settings-Datei mit einem literalen `includeBuild` einbindet, löst zu diesem äußeren Build auf). Der äußerste Vorschlag gewinnt.
 3. Ohne jede Markierung ist das Startverzeichnis der Root.
 
 Die Suche verlässt nie den Checkout der Versionsverwaltung: Sie endet im nächsten Verzeichnis, das einen `.git`-Eintrag enthält. Eine verirrte `package.json` oder `pom.xml` oberhalb des Repositorys wird daher nie für dessen Root gehalten. Manifeste, die sich nicht lesen lassen, werden übersprungen.
@@ -178,7 +241,7 @@ src/
 │   ├── versions.ts              #   Erkennung von Vorabversionen & Versionshilfen
 │   ├── ports.ts                 #   Domain Ports (ModuleDiscoveryPort, RegistryPort, etc.)
 │   ├── ecosystem-strategy.ts    #   Strategy Pattern: Plattform-agnostisches Interface
-│   └── ecosystem-factory.ts     #   Factory Pattern: Liefert npm- oder Maven-Strategie
+│   └── ecosystem-factory.ts     #   Factory Pattern: Liefert die npm-, Maven- oder Gradle-Strategie
 │
 ├── adapters/                    # 🔌 ADAPTERS (Konkrete Implementierungen)
 │   ├── shared/                  #   🧰 XML (positionsgenau), Prozesse, Snapshots, Pooling
@@ -198,18 +261,35 @@ src/
 │   │   ├── npm-verifier.ts      #     npm ls / eigene Verifikation
 │   │   └── npm-strategy.ts      #     NpmEcosystemStrategy
 │   │
-│   └── maven/                   #   ☕ Java / Maven Adapter
-│       ├── maven-command.ts     #     Aufruf über Maven Wrapper / mvn
-│       ├── maven-pom.ts         #     Rohes POM-Modell mit editierbaren Textbereichen
-│       ├── maven-project.ts     #     Alle POMs des Repos, Parent-Ketten, Reactors
-│       ├── maven-discovery.ts   #     Module inkl. Root-POM, Versionen, Aggregator
-│       ├── maven-resolution.ts  #     Effective POM & Report des versions-maven-plugin
-│       ├── maven-locator.ts     #     Findet die Stelle, an der eine Version steht
-│       ├── maven-scanner.ts     #     Herkunft, Angleichen, Update-Kandidaten
-│       ├── maven-registry.ts    #     `elevate versions` über Maven (jeder Nexus/Artifactory)
-│       ├── maven-updater.ts     #     Formatierungserhaltende POM-Änderungen
-│       ├── maven-verifier.ts    #     mvn test-compile -pl … -amd
-│       └── maven-strategy.ts    #     MavenEcosystemStrategy
+│   ├── maven/                   #   ☕ Java / Maven Adapter
+│   │   ├── maven-command.ts     #     Aufruf über Maven Wrapper / mvn
+│   │   ├── maven-pom.ts         #     Rohes POM-Modell mit editierbaren Textbereichen
+│   │   ├── maven-project.ts     #     Alle POMs des Repos, Parent-Ketten, Reactors
+│   │   ├── maven-discovery.ts   #     Module inkl. Root-POM, Versionen, Aggregator
+│   │   ├── maven-resolution.ts  #     Effective POM & Report des versions-maven-plugin
+│   │   ├── maven-locator.ts     #     Findet die Stelle, an der eine Version steht
+│   │   ├── maven-scanner.ts     #     Herkunft, Angleichen, Update-Kandidaten
+│   │   ├── maven-registry.ts    #     `elevate versions` über Maven (jeder Nexus/Artifactory)
+│   │   ├── maven-updater.ts     #     Formatierungserhaltende POM-Änderungen
+│   │   ├── maven-verifier.ts    #     mvn test-compile -pl … -amd
+│   │   └── maven-strategy.ts    #     MavenEcosystemStrategy
+│
+│   └── gradle/                  #   🐘 Java / Gradle Adapters
+│       ├── gradle-command.ts    #     Aufruf über Wrapper / gradle, Gradles eigene Fehlertexte
+│       ├── gradle-init-script.ts #    Das Groovy-Init-Skript, das Describe-/Lookup-Läufe beantwortet
+│       ├── gradle-probe.ts      #     runDescribe / runLookup und das Scratch-Verzeichnis
+│       ├── gradle-discovery.ts  #     Build-Verzeichnisse, Repository-Root, Module aus den beschriebenen Builds
+│       ├── gradle-versions.ts   #     Gradles Versionsreihenfolge
+│       ├── gradle-repositories.ts #   Wirksame Repositories, öffentliche Hosts, Lookup-Plan, Schutz interner Gruppen
+│       ├── gradle-text.ts       #     String-Literale außerhalb von Kommentaren, formatierungserhaltende Edits
+│       ├── gradle-catalog.ts    #     gradle/libs.versions.toml: Einträge und der Text einer Version
+│       ├── gradle-locator.ts    #     Findet, wo eine Version deklariert ist
+│       ├── gradle-scanner.ts    #     Herkunft, Angleichen an Included Builds, Update-Kandidaten
+│       ├── gradle-registry.ts   #     `elevate versions` über Gradle (jeder Nexus/Artifactory)
+│       ├── gradle-locks.ts      #     gradle.lockfile finden und --update-locks
+│       ├── gradle-updater.ts    #     Formatierungserhaltende Edits, Lock-Auffrischung
+│       ├── gradle-verifier.ts   #     testClasses / assemble der betroffenen Projekte
+│       └── gradle-strategy.ts   #     GradleEcosystemStrategy
 │
 ├── application/                 # 🧭 ANWENDUNGSFÄLLE für TUI, CLI und MCP
 │   ├── scan.ts                  #     Scan-Kontext, Modulsuche, JSON-Ausgabe
@@ -283,7 +363,7 @@ node tools/updater/elevate/index.mjs update --module=apps/e2e-cockpit --packages
 node tools/updater/elevate/index.mjs update --module=apps/web --all --keep-on-failure
 ```
 
-`scan --json` liefert je Modul die `updates` (mit `action`, `origin` und bei Maven `declaredIn`) und die übersprungenen Abhängigkeiten unter `skipped` mit `reason`. `update` endet mit Exit-Code `2`, wenn das Update fehlschlug und zurückgenommen wurde.
+`scan --json` liefert je Modul die `updates` (mit `action`, `origin` und bei Maven und Gradle `declaredIn`, bei Gradle außerdem `alsoDeclaredIn`, wenn eine Version an mehreren Stellen steht) und die übersprungenen Abhängigkeiten unter `skipped` mit `reason`. `update` endet mit Exit-Code `2`, wenn das Update fehlschlug und zurückgenommen wurde.
 
 ### 2. Model Context Protocol (MCP) Server
 
@@ -307,7 +387,7 @@ In der MCP-Konfiguration hinterlegen (z. B. `claude_desktop_config.json` oder An
 #### Verfügbare MCP-Tools für LLMs:
 | Tool | Funktion |
 | :--- | :--- |
-| `elevate_discover_modules` | Erkennt alle Monorepo-Module und Workspaces für npm oder Maven |
+| `elevate_discover_modules` | Erkennt alle Monorepo-Module und Workspaces für npm, Maven, Cargo oder Gradle (Gradle-Module nennen die Art ihres Builds) |
 | `elevate_scan` | Scannt ein Modul (oder alle Module) nach Updates und anzugleichenden internen Abhängigkeiten; nennt übersprungene Abhängigkeiten mit Grund |
 | `elevate_get_versions` | Ruft die Versionshistorie aus der Registry ab (keine öffentliche Abfrage interner Pakete) |
 | `elevate_apply_updates` | Wendet Updates mit Verifikation, Major-Guardrail und Rücknahme an (`keepOnFailure` optional) |
@@ -319,7 +399,7 @@ In der MCP-Konfiguration hinterlegen (z. B. `claude_desktop_config.json` oder An
 
 | Taste | Aktion |
 | :--- | :--- |
-| **`E`** | **Ökosystem umschalten (📦 Node/npm ⇄ ☕ Java/Maven)** |
+| **`E`** | **Ökosystem umschalten (📦 Node/npm → ☕ Java/Maven → 🦀 Rust/Cargo → 🐘 Java/Gradle)** |
 | **`W`** | Modul- / Workspace-Auswahl öffnen |
 | **`V`** | **Version heraussuchen (Interaktiver Such- & Filterdialog)** |
 | **`L`** | Sprache umschalten (Deutsch ⇄ English) |
@@ -352,9 +432,9 @@ Im Wurzelverzeichnis deines Repositories kann optional eine `elevate.config.json
 * **`author`:** Optionaler Name, der oben rechts im Header erscheint.
 * **`channel`:** `"stable"` (Standard, schließt Betas/RCs aus) oder `"all"` (zeigt auch Vorabversionen).
 * **`locale`:** `"de"` (Deutsch), `"en"` (Englisch) oder `"auto"` (automatische Erkennung).
-* **`internalScopes`:** Interne npm-Scopes und Maven-groupId-Präfixe. `@my-org` trifft `@my-org/*`; `com.mycompany` trifft `com.mycompany` und `com.mycompany.*` (nicht `com.mycompanyx`). Passende Pakete werden nur in privaten Registries abgefragt. *Früher `excludeScopes`; der alte Name wird weiter gelesen und als veraltet gemeldet.*
+* **`internalScopes`:** Interne npm-Scopes und Maven-/Gradle-groupId-Präfixe (bei Gradle auch Plugin-IDs). `@my-org` trifft `@my-org/*`; `com.mycompany` trifft `com.mycompany` und `com.mycompany.*` (nicht `com.mycompanyx`). Passende Pakete werden nur in privaten Registries abgefragt. *Früher `excludeScopes`; der alte Name wird weiter gelesen und als veraltet gemeldet.*
 * **`mavenPlugins`:** Optionale Versionen der Maven-Plugins, die Elevate startet: `help` (`maven-help-plugin`, Standard `3.5.2`) und `versions` (`versions-maven-plugin`, Standard `2.22.0`). Nutze es, wenn dein Repository-Manager die Standardversionen nicht anbietet. Ungültige Werte fallen mit einer Warnung auf den Standard zurück.
-* **`postUpdateScript`:** Optionaler Befehl, der die Standard-Verifikation (`npm ls` / `mvn test-compile`) ersetzt. Läuft im Repository-Root (npm) bzw. im Modulverzeichnis (Maven).
+* **`postUpdateScript`:** Optionaler Befehl, der die Standard-Verifikation (`npm ls` / `mvn test-compile`) ersetzt. Läuft im Repository-Root (npm), im Modulverzeichnis (Maven) bzw. im Verzeichnis des Gradle-Builds des Moduls (Gradle).
 
 ---
 

package/docs/en.md

@@ -7,10 +7,10 @@
 
 ## 🌟 Overview
 
-**Elevate** is an interactive terminal dashboard (TUI) for safe, selective, and transparent dependency management across **polyglot monorepos** (Node/npm & Java/Maven) and single-package projects.
+**Elevate** is an interactive terminal dashboard (TUI) for safe, selective, and transparent dependency management across **polyglot monorepos** (Node/npm, Java/Maven, Rust/Cargo & Java/Gradle) and single-package projects.
 
 * **Feather Identity (`🪶`) & Orange Brand (`#FF8800`):** Clean, modern, and readable in any terminal.
-* **Polyglot Architecture:** Seamlessly manages frontend workspaces (`package.json` with npm workspaces) and backend modules (`pom.xml` with Maven).
+* **Polyglot Architecture:** Seamlessly manages frontend workspaces (`package.json` with npm workspaces) and backend modules (`pom.xml` with Maven, `build.gradle` with Gradle, `Cargo.toml` with Cargo).
 * **Release Channels:** Filters out pre-releases (Alpha, Beta, RC, Milestone, Snapshot) by default, suggesting only battle-tested production releases.
 * **Animated Companion ("Pip" 🐣):** A delightful chicken mascot that reacts to actions and keeps you company in the terminal.
 * **Bilingual i18n:** Toggle on the fly between English and German with the **`[L]`** key.
@@ -19,10 +19,11 @@
 
 ## ✨ Features & Highlights
 
-1. **🌐 Polyglot Monorepo Support (npm, pnpm & Maven):**
+1. **🌐 Polyglot Monorepo Support (npm, pnpm, Maven, Cargo & Gradle):**
    * **Node / npm:** Resolves workspaces exactly like npm (glob patterns such as `packages/**` included), calculates SemVer diffs, updates `package.json` (`dependencies`, `devDependencies`, `optionalDependencies`), runs `npm install` and checks the lockfile. **Node / pnpm** (9 – 12) works the same way for pnpm repositories: workspaces from `pnpm-workspace.yaml`, the `workspace:` protocol, `catalog:` entries, `pnpm install` and a lockfile check. Repositories managed by Yarn or Bun are refused.
    * **Java / Maven:** Finds every `pom.xml` (including the root POM), lets Maven compute the effective POM, looks up newer versions through the build's own repositories (mirrors, Nexus/Artifactory, credentials from `settings.xml`) and verifies the affected modules with `mvn test-compile`.
-   * **Runtime Switch:** Press **`[E]`** anytime to switch between frontend and backend modules.
+   * **Java / Gradle:** Finds the builds of the repository (Groovy and Kotlin DSL, included builds, `buildSrc`), asks Gradle itself which dependencies apply, looks up newer versions through the build's own repositories (mirrors, Nexus/Artifactory, credentials), writes each new version where its text is found — build scripts, `gradle.properties`, `ext` values, the version catalog `gradle/libs.versions.toml`, the `plugins` block — refreshes dependency locks and verifies the affected projects with `testClasses`.
+   * **Runtime Switch:** Press **`[E]`** anytime to switch between Node/npm, Java/Maven, Rust/Cargo and Java/Gradle modules.
 
 2. **🔍 Pick a Specific Version (`[V]`):**
    * You aren't restricted to upgrading only to `latest`: pressing **`[V]`** opens an interactive modal to browse and select any published version for the focused package.
@@ -70,12 +71,14 @@ The registry URL alone is deliberately **not** used to decide the origin: in mos
 * **npm:** If a dependency's range does not include the local version of a workspace package, npm does **not** link the workspace — it installs a package with the same name from the registry. Elevate offers to align the range (e.g. `^1.0.0` ➔ `^2.0.0`). After `npm install` it checks `package-lock.json`: every aligned dependency must be `"link": true`, otherwise the update is rolled back. Ranges that npm always links (`*`, `file:`, `workspace:`) are left alone.
 * **pnpm:** pnpm links a workspace package only when the dependency is written with the `workspace:` protocol; a plain range such as `^1.0.0` is resolved from the registry, even if the local version satisfies it. Elevate therefore aligns `workspace:^1.2.0` ➔ `workspace:^2.0.0` (the protocol and the prefix are kept; `workspace:*`, `workspace:^`, `workspace:~` and `workspace:../lib` need nothing) and lists a plain range on a module as *not linked* without ever looking the name up in a registry or rewriting it. After `pnpm install` it reads the `importers` section of `pnpm-lock.yaml` (`lockfileVersion` 9.x): every aligned dependency must have a `version` starting with `link:`, otherwise the update is rolled back.
 * **Maven:** If a module depends on a module of the *same reactor* with a different version (e.g. `1.0.0` while the module is at `1.1.0-SNAPSHOT`), Elevate offers to align it. `${project.version}` references need no alignment.
+* **Gradle:** Gradle substitutes a dependency by a project of an *included build* whenever group and name match, whatever version is written (`com.acme:lib:1.0.0` resolves to the included build's project). Elevate aligns such a dependency to the project's version and never looks the name up in a repository; an included build outside the repository is neither offered nor looked up. A project of the *same* build is not substituted, so a dependency with its coordinates is an ordinary one.
 * The release channel does not apply to alignment: the local version — including `-SNAPSHOT` — is the target, because modules of one repository are built and tested together.
 
 ### Private registries & dependency confusion
 
 * Internal packages are never looked up on a public registry. If the registry for an internal npm package resolves to `registry.npmjs.org`, it is listed as *not offered* with the reason, instead of being queried — asking a public registry about an internal name is exactly what a dependency-confusion attack exploits.
-* npm lookups use your npm configuration (`npm config`), Maven lookups use Maven itself — mirrors, private repositories and credentials apply without any Elevate-specific configuration, and Elevate never handles credentials.
+* npm lookups use your npm configuration (`npm config`), Maven and Gradle lookups use Maven or Gradle itself — mirrors, private repositories and credentials apply without any Elevate-specific configuration, and Elevate never handles credentials.
+* **Gradle:** for an internal package (`internalScopes`; a plugin id counts like a group) Elevate has Gradle keep its group away from every well-known public repository (`repo.maven.apache.org`, `repo1.maven.org`, `plugins.gradle.org`, `dl.google.com`, `jitpack.io` and a few more) during the lookup with a content filter (`excludeGroupByRegex`), so no request for the internal name reaches them; a company's Artifactory or Nexus counts as private even when it mirrors Maven Central. If the build has only public repositories for it, the dependency is listed as *not offered* instead of being looked up. Credentials in a repository URL never leave the scan.
 
 ### Where Maven versions are written
 
@@ -89,6 +92,7 @@ Every update runs as one workflow: **snapshot ➔ write & install ➔ integrity
 
 * **npm:** `npm ls` at the repository root (missing, invalid or unmet dependencies across all workspaces), unless `postUpdateScript` is set.
 * **Maven:** `mvn test-compile -pl <changed modules> -amd` in the reactor — the changed modules *and every module depending on them*. A change to the aggregator POM rebuilds the whole reactor.
+* **Gradle:** `testClasses` (else `assemble`) of the projects the changed files can affect: a project and every project that depends on it through `project(...)`; a change to the root project (root script, `gradle.properties`, settings, `gradle/libs.versions.toml`) affects every project. Tasks are named by project path (`:app:testClasses`), a module of an included build through the name of its build; without any task the run is `help`, which configures the build and compiles `buildSrc`.
 
 ### Cargo (Rust)
 
@@ -106,12 +110,71 @@ Elevate runs `cargo` from the `PATH` (`cargo metadata --no-deps`, `cargo update`
 
 Elevate uses the project's Maven Wrapper (`mvnw` / `mvnw.cmd`) when present, otherwise `mvn` on the `PATH`. Without either, Maven scans fail with a clear message instead of guessing. Plugin versions are pinned for reproducible results (`maven-help-plugin` 3.5.2, `versions-maven-plugin` 2.22.0) and can be replaced per repository with `mavenPlugins` in `elevate.config.json` (see [Maven plugin versions](#maven-plugin-versions)). Scans write temporary files only to `target/.elevate-*` and remove them afterwards.
 
+### Where Gradle versions are written
+
+A Gradle build file is a program, so Elevate does not parse it. It asks Gradle what applies — the dependencies every project declares, with the version each one has after all scripts have run — and then looks in the files of the build for the text that carries that version. A location counts only if the text there is exactly the version Gradle reports. What cannot be located with certainty is not guessed: it is listed as *not offered* with the reason.
+
+The text is searched in this order, for the dependencies of a module (a project with a build script):
+
+1. string and map notation in the module's own build script;
+2. when that script has no such literal, the build scripts of the parent projects of the same build, nearest first (`subprojects { }` and `allprojects { }` live there). The first script with a match wins and all its matches are written;
+3. when the version is a name (`"g:a:$v"`, `version: v`): the definition of that name — `gradle.properties` first (the module's own file, then the build's), then `def`, `ext` and `extra` values of the module's script and its parents. A value that Gradle overrides, an ambiguous definition or one that is not a single string literal is *not offered*;
+4. when Gradle marks the dependency as coming from a version catalog: `gradle/libs.versions.toml` of the build.
+
+Not searched: convention plugins in `buildSrc` or an included build, scripts applied with `apply from:`, init scripts and the user's `gradle.properties`. Both DSLs are read by the same rules — outside comments, every string literal is a candidate:
+
+| Form | Groovy | Kotlin |
+| :--- | :--- | :--- |
+| string notation | `implementation 'g:a:1.0'`, `"g:a:1.0"`, `implementation('g:a:1.0')` | `implementation("g:a:1.0")` |
+| classifier, extension | `'g:a:1.0:sources@jar'` (only `1.0` changes) | `"g:a:1.0:sources@jar"` |
+| map notation | `group: 'g', name: 'a', version: '1.0'` (any order) | `group = "g", name = "a", version = "1.0"` |
+| name as the version | `"g:a:$v"`, `"g:a:${v}"`, `version: v` | `"g:a:$v"`, `"g:a:${v}"`, `version = v` |
+| plugin | `id 'x' version '1.0'`, `id('x') version('1.0')` | `id("x") version "1.0"`, `kotlin("jvm") version "1.9.20"` |
+
+A coordinate that a module declares several times (in several configurations, as a constraint, in a catalog) is one candidate and the new version is written to every declaration. Its scope is the first of *prod*, *test* and *plugin* among them; a configuration is a test configuration when one of the words of its camelCase name is `test`. Platforms, enforced platforms and the members of a bundle are offered like libraries; constraints (`dependencies { constraints { } }`) are offered too. Dependencies that share a version property or a catalog entry are marked, and conflicting targets for a shared text are rejected. Edits replace only the version text and refuse a file in which it, or the characters around it, changed since the scan (`1.0` turning into `1.0.1`).
+
+What is listed as *not offered*:
+
+| Reason | When |
+| :--- | :--- |
+| `version-constraint` | the version is a selector or carries a constraint: `1.+`, `latest.release`, `[1.0,2.0)`, `strictly`, `reject`, `prefer` — changing one number would change its meaning |
+| `declaration-mismatch` | the text of the version cannot be located with certainty: computed versions, a convention plugin, an `apply from:` script, a catalog other than `gradle/libs.versions.toml`, a value Gradle overrides |
+| `invalid-name` | an external module without a group |
+| `lookup-failed` | a repository error (Gradle's own words, without credentials), or a build that declares no repository |
+| `private-on-public-registry` | an internal package whose repositories are all public |
+
+### Version catalogs
+
+Gradle reads `gradle/libs.versions.toml` of a build as the catalog `libs`. Elevate reads it as TOML and matches a dependency to an entry by coordinates: the entry whose `module` (or `group` and `name`) is the dependency's and whose effective version, after resolving `version.ref`, is exactly the version Gradle reports. The text of the version is edited in place — the `[versions]` key for `version.ref`, otherwise the entry itself (`"g:a:1.0"`, `version = "1.0"`, `version = { require = "1.0" }`) — and comments, spacing, order, line endings and a byte order mark stay. Plugin entries (`[plugins]`) are handled the same way, bundles hold aliases only and their members are offered as libraries, and a `[versions]` key that several libraries refer to is shown as shared and written once. Entries with `strictly`, `prefer` or `reject` are listed as *not offered*. Only the file of the build itself is read: catalogs declared in the settings with `versionCatalogs { }` are not, and an included build has its own file.
+
+### The Gradle runs Elevate makes
+
+Elevate never parses build files for what applies and never contacts a repository itself. It runs the build's own Gradle — the wrapper closest to the module, searching upwards but never above the repository root (`sh ./gradlew`, on Windows `.\gradlew.bat`), otherwise `gradle` on the `PATH` — in the directory of the module's Gradle build:
+
+| Purpose | Command | Timeout |
+| :--- | :--- | :--- |
+| describe the build (projects, declared dependencies, repositories) | `-q -m --console=plain --no-configuration-cache -Delevate.mode=describe -Delevate.outDir=… -I <script> help` | 5 min |
+| look up newer versions | the same with `-Delevate.mode=lookup -Delevate.plan=…` | 5 min |
+| refresh dependency locks | `-q --console=plain --no-configuration-cache :app:dependencies … --update-locks g:a,…` | 10 min |
+| verify | `-q --console=plain :app:testClasses …` | 30 min |
+
+The two probe runs use a small Groovy init script that Elevate carries; the answers are JSON files below `.gradle/elevate-<id>/` of the build, which is removed when the run ends, whatever the outcome — standard output carries no answer. `--no-configuration-cache` is required: with the configuration cache enabled Gradle reuses it on the second run and the init script would not run. Neither `--daemon` nor `--no-daemon` is passed: the runs use Gradle as the project configured it, so a cold daemon costs a few seconds once and every further run about a second. A scan shares one describe run and one lookup run per Gradle build, however many modules are requested. Gradle older than 7.6 is refused with a message.
+
+### Dependency locking and dependency verification
+
+* **Locks.** With `dependencyLocking { lockAllConfigurations() }` a `gradle.lockfile` sits in each project directory, and raising a declared version makes the build fail until the lock is refreshed. After an update of a library Elevate refreshes the lock files of the root build with `gradle :app:dependencies :core:dependencies … --update-locks <coordinates>` — all of them together, because a stale lock does not always fail: a lower declared version is silently resolved down to the locked one. The lock files are part of the snapshot, so a failed refresh or verification restores them. Locks of `buildSrc`, of included builds, of the `buildscript` classpath and of the settings are not refreshed: an update in an included build or `buildSrc` that has lock files is refused before anything changes.
+* **Dependency verification.** A build with `gradle/verification-metadata.xml` refuses the artifacts of a new version. Elevate never regenerates that file (`--write-verification-metadata` would record the checksum of whatever was downloaded and defeat its purpose): the update is rolled back with Gradle's message and you decide.
+
+### Requirements for Gradle
+
+A JDK that the build's Gradle supports, Gradle 7.6 or newer, and either a Gradle Wrapper in the repository or `gradle` on the `PATH`; without either, Gradle scans fail with a clear message instead of guessing. Which JDK a Gradle version runs on is Gradle's to state (for example Gradle 7.6.6 does not run on JDK 21). The integration tests run against Gradle 7.6.6 (JDK 17), 8.14.3 and 9.8.1 (JDK 21). Not covered: updating the Gradle Wrapper itself, Android and Kotlin Multiplatform builds (not verified), Windows (specified, not verified) and `settings.gradle` plugins.
+
 ### Repository root
 
 Elevate works the same wherever in the repository it is started. The root is found as follows:
 
 1. The nearest directory (from the start directory upwards) with an `elevate.config.json` is the root.
-2. Otherwise npm proposes the nearest directory whose `package.json` declares `workspaces`, and Maven proposes the top of the connected POM chain (a `<parent>` found through `<relativePath>` and any aggregator that lists the project in `<modules>`). The outermost proposal wins.
+2. Otherwise npm proposes the nearest directory whose `package.json` declares `workspaces`, Maven proposes the top of the connected POM chain (a `<parent>` found through `<relativePath>` and any aggregator that lists the project in `<modules>`), and Gradle proposes the nearest directory with a `settings.gradle(.kts)` (`buildSrc` belongs to the build around it, and a build that an outer settings file includes with a literal `includeBuild` resolves to that outer build). The outermost proposal wins.
 3. Without any marker the start directory is the root.
 
 The search never leaves the version-control checkout: it stops at the nearest directory that contains a `.git` entry, so a stray `package.json` or `pom.xml` somewhere above the repository is never mistaken for its root. Manifests that cannot be parsed are skipped.
@@ -177,7 +240,7 @@ src/
 │   ├── versions.ts              #   Pre-release detection & version helpers
 │   ├── ports.ts                 #   Domain Ports (ModuleDiscoveryPort, RegistryPort, etc.)
 │   ├── ecosystem-strategy.ts    #   Strategy Pattern: Platform-agnostic interface
-│   └── ecosystem-factory.ts     #   Factory Pattern: Resolves npm or Maven strategy
+│   └── ecosystem-factory.ts     #   Factory Pattern: Resolves the npm, Maven or Gradle strategy
 │
 ├── adapters/                    # 🔌 ADAPTERS (Concrete port implementations)
 │   ├── shared/                  #   🧰 XML (position-aware), processes, snapshots, pooling
@@ -198,18 +261,35 @@ src/
 │   │   ├── npm-verifier.ts      #     npm ls / custom verification
 │   │   └── npm-strategy.ts      #     NpmEcosystemStrategy
 │   │
-│   └── maven/                   #   ☕ Java / Maven Adapters
-│       ├── maven-command.ts     #     Maven Wrapper / mvn invocation
-│       ├── maven-pom.ts         #     Raw POM model with editable element ranges
-│       ├── maven-project.ts     #     All POMs of the repo, parent chains, reactors
-│       ├── maven-discovery.ts   #     Modules incl. root POM, versions, aggregator
-│       ├── maven-resolution.ts  #     Effective POM & versions-maven-plugin report
-│       ├── maven-locator.ts     #     Finds where a version is declared
-│       ├── maven-scanner.ts     #     Origins, alignment, update candidates
-│       ├── maven-registry.ts    #     `elevate versions` via Maven (any Nexus/Artifactory)
-│       ├── maven-updater.ts     #     Formatting-preserving POM edits
-│       ├── maven-verifier.ts    #     mvn test-compile -pl … -amd
-│       └── maven-strategy.ts    #     MavenEcosystemStrategy
+│   ├── maven/                   #   ☕ Java / Maven Adapters
+│   │   ├── maven-command.ts     #     Maven Wrapper / mvn invocation
+│   │   ├── maven-pom.ts         #     Raw POM model with editable element ranges
+│   │   ├── maven-project.ts     #     All POMs of the repo, parent chains, reactors
+│   │   ├── maven-discovery.ts   #     Modules incl. root POM, versions, aggregator
+│   │   ├── maven-resolution.ts  #     Effective POM & versions-maven-plugin report
+│   │   ├── maven-locator.ts     #     Finds where a version is declared
+│   │   ├── maven-scanner.ts     #     Origins, alignment, update candidates
+│   │   ├── maven-registry.ts    #     `elevate versions` via Maven (any Nexus/Artifactory)
+│   │   ├── maven-updater.ts     #     Formatting-preserving POM edits
+│   │   ├── maven-verifier.ts    #     mvn test-compile -pl … -amd
+│   │   └── maven-strategy.ts    #     MavenEcosystemStrategy
+│
+│   └── gradle/                  #   🐘 Java / Gradle Adapters
+│       ├── gradle-command.ts    #     Wrapper / gradle invocation, Gradle's own error words
+│       ├── gradle-init-script.ts #    The Groovy init script that answers describe / lookup runs
+│       ├── gradle-probe.ts      #     runDescribe / runLookup and the scratch directory
+│       ├── gradle-discovery.ts  #     Build directories, repository root, modules from the described builds
+│       ├── gradle-versions.ts   #     Gradle's version order
+│       ├── gradle-repositories.ts #   Effective repositories, public hosts, lookup plan, internal-group guard
+│       ├── gradle-text.ts       #     String literals outside comments, formatting-preserving edits
+│       ├── gradle-catalog.ts    #     gradle/libs.versions.toml: entries and the text of a version
+│       ├── gradle-locator.ts    #     Finds where a version is declared
+│       ├── gradle-scanner.ts    #     Origins, included-build alignment, update candidates
+│       ├── gradle-registry.ts   #     `elevate versions` via Gradle (any Nexus/Artifactory)
+│       ├── gradle-locks.ts      #     gradle.lockfile discovery and --update-locks
+│       ├── gradle-updater.ts    #     Formatting-preserving edits, lock refresh
+│       ├── gradle-verifier.ts   #     testClasses / assemble of the affected projects
+│       └── gradle-strategy.ts   #     GradleEcosystemStrategy
 │
 ├── application/                 # 🧭 USE CASES shared by TUI, CLI and MCP
 │   ├── scan.ts                  #     Scan context, module lookup, JSON output
@@ -285,7 +365,7 @@ node tools/updater/elevate/index.mjs update --module=apps/e2e-cockpit --packages
 node tools/updater/elevate/index.mjs update --module=apps/web --all --keep-on-failure
 ```
 
-`scan --json` lists, per module, the `updates` (with `action`, `origin` and — for Maven — `declaredIn`) and the `skipped` dependencies with their `reason`. `update` exits with `2` when the update failed and was rolled back.
+`scan --json` lists, per module, the `updates` (with `action`, `origin` and — for Maven and Gradle — `declaredIn`, plus `alsoDeclaredIn` when a Gradle version is written in several places) and the `skipped` dependencies with their `reason`. `update` exits with `2` when the update failed and was rolled back.
 
 ### 2. Model Context Protocol (MCP) Server
 
@@ -309,7 +389,7 @@ Register it in your agent's MCP settings (e.g., `claude_desktop_config.json` or
 #### Available MCP Tools for LLMs:
 | Tool | Purpose |
 | :--- | :--- |
-| `elevate_discover_modules` | Discovers all repository modules and workspaces for npm or Maven |
+| `elevate_discover_modules` | Discovers all repository modules and workspaces for npm, Maven, Cargo or Gradle (Gradle modules report the kind of their build) |
 | `elevate_scan` | Scans a module (or all modules) for updates and internal dependencies to align; lists skipped dependencies with reasons |
 | `elevate_get_versions` | Fetches complete published version history from registry (refuses public lookups of internal packages) |
 | `elevate_apply_updates` | Applies targeted updates with verification, major guardrails and rollback (`keepOnFailure` optional) |
@@ -321,7 +401,7 @@ Register it in your agent's MCP settings (e.g., `claude_desktop_config.json` or
 
 | Key | Action |
 | :--- | :--- |
-| **`E`** | **Switch Ecosystem (📦 Node/npm ⇄ ☕ Java/Maven)** |
+| **`E`** | **Switch Ecosystem (📦 Node/npm → ☕ Java/Maven → 🦀 Rust/Cargo → 🐘 Java/Gradle)** |
 | **`W`** | Open module / workspace selector |
 | **`V`** | **Pick specific version (Interactive search & filter modal)** |
 | **`L`** | Toggle language (English ⇄ German) |
@@ -354,9 +434,9 @@ You can place an optional `elevate.config.json` file in your repository root:
 * **`author`:** Optional name displayed in the top-right header.
 * **`channel`:** `"stable"` (default, excludes betas/RCs) or `"all"` (includes pre-releases).
 * **`locale`:** `"en"` (English), `"de"` (German), or `"auto"` (system detection).
-* **`internalScopes`:** Internal npm scopes and Maven groupId prefixes. `@my-org` matches `@my-org/*`; `com.mycompany` matches `com.mycompany` and `com.mycompany.*` (not `com.mycompanyx`). Matching packages are looked up only in private registries. *Formerly `excludeScopes`, which is still read and reported as deprecated.*
+* **`internalScopes`:** Internal npm scopes and Maven / Gradle groupId prefixes (for Gradle also plugin ids). `@my-org` matches `@my-org/*`; `com.mycompany` matches `com.mycompany` and `com.mycompany.*` (not `com.mycompanyx`). Matching packages are looked up only in private registries. *Formerly `excludeScopes`, which is still read and reported as deprecated.*
 * **`mavenPlugins`:** Optional versions of the Maven plugins Elevate runs: `help` (`maven-help-plugin`, default `3.5.2`) and `versions` (`versions-maven-plugin`, default `2.22.0`). Use it when your repository manager does not offer the defaults. Invalid values fall back to the default with a warning.
-* **`postUpdateScript`:** Optional command that replaces the default verification (`npm ls` / `mvn test-compile`). Runs in the repository root (npm) or the module directory (Maven).
+* **`postUpdateScript`:** Optional command that replaces the default verification (`npm ls` / `mvn test-compile`). Runs in the repository root (npm), the module directory (Maven) or the directory of the module's Gradle build (Gradle).
 
 ---
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dennisrepa/elevate",
-  "version": "1.7.0",
+  "version": "1.8.0",
   "description": "🪶 Elevate — Interactive Polyglot Terminal Dashboard & Agentic MCP Server for safe dependency updates across monorepos.",
   "type": "module",
   "main": "./dist/cli.js",
@@ -25,6 +25,7 @@
     "npm",
     "pnpm",
     "maven",
+    "gradle",
     "cargo",
     "rust",
     "mcp",
@@ -70,6 +71,7 @@
     "react": "^19.0.0",
     "saxes": "^6.0.0",
     "semver": "^7.6.3",
+    "smol-toml": "1.9.1",
     "toml-eslint-parser": "^1.0.3",
     "tsx": "^4.19.3",
     "yaml": "^2.9.1"