mxrb 0.1.0

data/docs/de-DE/oql-sql.md

@@ -0,0 +1,211 @@
+# OQL, SQL-Ansicht und lokale Datenbank
+
+MXRB stellt OQL nur bereit, wenn das native Modell tatsächlich OQL enthält.
+Erkannt werden OQL-Quellen von Datasets und Abfragen von View Entities. Eine
+Anwendung ohne OQL liefert eine leere Sammlung und erhält keine künstlichen
+Abfragedokumente.
+
+## Statische Inspektion
+
+```ruby
+Mxrb.open("Shop.mpr") do |project|
+  next unless project.oql?
+
+  project.oql_queries.each do |query|
+    puts query.qualified_name
+    puts query.oql
+    puts query.parameters
+  end
+
+  project.oql_sql_views(dialect: :postgresql).each do |view|
+    puts view.sql if view.supported?
+    warn view.warnings.join("\n")
+  end
+end
+```
+
+Die CLI liefert dasselbe typisierte Ergebnis:
+
+```sh
+bundle exec mxrb oql Shop.mpr
+bundle exec mxrb oql Shop.mpr --dialect ansi
+bundle exec mxrb oql Shop.mpr --dialect sql_server --json
+```
+
+Die SQL-Ansicht ist strikt schreibgeschützt. Parameter wie `$Customer` werden
+zu benannten Bind-Parametern wie `:Customer`; Werte werden nie interpoliert.
+Zeichenketten und Kommentare bleiben undurchsichtig. Mehrere Anweisungen und
+schreibende OQL-Operationen werden abgelehnt.
+
+Das erzeugte SQL hat die Vertrauensstufe `logical`. PostgreSQL- und
+SQL-Server-Ansichten verwenden die übliche Tabellenform `module$entity`, ANSI
+behält `Module.Entity` bei. Physische Namen müssen immer mit der Datenbank des
+exakten Mendix Runtime geprüft werden. Assoziationspfad-Joins gelten als nicht
+unterstützt, solange Runtime-Speichermetadaten den korrekten Join nicht
+beweisen können.
+
+## Dialektabhängige Analyse
+
+`Oql::Analyzer` erkennt Kosten- und Portabilitätsmuster im Originaltext,
+bewahrt das auslösende Fragment für Hervorhebungen und liefert konkrete
+Alternativen für PostgreSQL, SQL Server und ANSI:
+
+```ruby
+report = Mxrb::Oql::Analyzer.new(dialect: :postgresql)
+                            .analyze_source("SELECT * FROM Sales.Order")
+report.findings.each { puts "#{_1.rule}: #{_1.suggestions[:postgresql]}" }
+
+reports = Mxrb.open("Shop.mpr") { _1.oql_analysis(dialect: :postgresql) }
+```
+
+Regeln erfassen führende und beidseitige Wildcards, Präfixsuchen,
+`LOWER`/`UPPER`/`CAST` in `WHERE`, kartesische Produkte und `SELECT *`.
+Findings sind `hint`, `warning` oder `error`; `clean?` bedeutet keine Fehler.
+
+Die CLI verarbeitet natives OQL sowie Ad-hoc-Quellen in OQL und SQL:
+
+```sh
+bundle exec mxrb analyze Shop.mpr --dialect postgresql
+bundle exec mxrb analyze --oql "SELECT * FROM Sales.Order"
+bundle exec mxrb analyze --sql "SELECT * FROM sales$order" --json
+```
+
+## Reale Pläne und Datenbank-Performance
+
+Eine statische Analyse kann nicht beweisen, welchen Pfad der Optimierer wählt.
+Im materialisierten PostgreSQL-Workspace fragt MXRB deshalb auch den realen
+Planner im JSON-Format ab und verknüpft Planrelationen mit `pg_indexes`:
+
+```sh
+bundle exec mxrb db explain Shop.mpr \
+  "SELECT * FROM \"sales$order\" WHERE status = 'Open'"
+bundle exec mxrb db explain Shop.mpr \
+  "SELECT * FROM \"sales$order\" WHERE status = 'Open'" --analyze --json
+```
+
+Der Standardmodus verwendet `EXPLAIN` und führt die Abfrage nicht aus.
+`--analyze` ist explizit, weil es `EXPLAIN ANALYZE` verwendet; die Abfrage läuft
+mit der schreibgeschützten Rolle und liefert Zeiten und Buffer. Der Bericht
+unterscheidet kleine, möglicherweise optimale sequenzielle Scans von großen
+Scans. Außerdem meldet er viele verworfene Filterzeilen, abweichende
+Kardinalitätsschätzungen, Nested Loops mit hohem Volumen und Sortierungen auf
+Festplatte. Vorhandene Indizes dienen als Evidenz; MXRB erfindet ohne
+Selektivitäts- und Workload-Daten keine `CREATE INDEX`-Anweisungen.
+
+Auch der kumulative PostgreSQL-Workload kann untersucht werden:
+
+```sh
+bundle exec mxrb db workload Shop.mpr --limit 50
+bundle exec mxrb db workload Shop.mpr --limit 50 --json
+```
+
+Der Workspace aktiviert `pg_stat_statements` und `track_io_timing`. Der Bericht
+ordnet Query-Fingerprints nach kumulativem Aufwand und analysiert mittlere
+Latenz, Cache-Hits, I/O, temporäre Blöcke und Zeilen pro Aufruf.
+Tabellenstatistiken zeigen sequenziellen Scan-Druck; große nicht eindeutige
+Indizes ohne beobachtete Scans werden ebenfalls gemeldet. Da diese Werte seit
+dem Statistik-Reset kumulativ sind, wird eine Indexentfernung nie ohne Prüfung
+des realen Zeitfensters und Workloads empfohlen.
+
+Für ein SQL-Server-Deployment wird die Verbindung explizit mit `sqlcmd`
+angegeben:
+
+```sh
+export MXRB_SQLSERVER_PASSWORD='geheim'
+bundle exec mxrb db explain Shop.mpr \
+  "SELECT * FROM dbo.[Order] WHERE Status = 'Open'" \
+  --engine sql_server --server db.example:1433 \
+  --database Shop --user mxrb_analyst --json
+```
+
+Der geschätzte Modus nutzt `SHOWPLAN_XML`; `--analyze` verwendet `STATISTICS
+XML` und führt nur ein `SELECT`/`WITH` aus. Der Parser erkennt große Table- und
+Clustered-Scans, Nested Loops mit hohem Volumen, tempdb-Spills,
+Kardinalitätsabweichungen und Missing-Index-Hinweise. Diese Hinweise bleiben
+Optimierer-Hypothesen und werden nicht automatisch als DDL ausgeführt. Das
+Passwort wird über `SQLCMDPASSWORD` und nie per argv übertragen. Der Engine-Typ
+wird nicht aus der MPR abgeleitet, da er zur Deployment-Konfiguration gehört.
+
+## Materialisierte lokale PostgreSQL-Datenbank
+
+Eine MPR enthält das Anwendungsmodell, nicht einen Snapshot der
+Anwendungsdaten. Das Mendix Runtime verwaltet das Datenbankschema und
+synchronisiert es aus dem Modell. MXRB kann das exakte portable Runtime bauen,
+eine isolierte PostgreSQL-Datenbank starten, diese Synchronisierung ausführen
+lassen und SQL-Zugriff bereitstellen:
+
+```sh
+bundle exec mxrb db up Shop.mpr
+bundle exec mxrb db status Shop.mpr
+bundle exec mxrb db sql Shop.mpr \
+  'SELECT * FROM "sales$order" LIMIT 20'
+bundle exec mxrb db shell Shop.mpr
+```
+
+Nach einer Änderung der MPR wird unter Beibehaltung der Daten neu gebaut und
+synchronisiert:
+
+```sh
+bundle exec mxrb db sync Shop.mpr
+bundle exec mxrb db down Shop.mpr
+```
+
+`db down` stoppt die Container, bewahrt aber das PostgreSQL-Volume. Ein
+späteres `db up` verwendet Paket-Cache und Daten erneut. Der Standard-Port ist
+`127.0.0.1:55432` und kann mit `--port` geändert werden.
+
+Lokale Werkzeuge können denselben Workspace über JSON HTTP abfragen:
+
+```sh
+bundle exec mxrb serve Shop.mpr --port 4567
+curl -X POST http://127.0.0.1:4567/query \
+  -H 'Content-Type: application/json' \
+  -d '{"sql":"SELECT * FROM \"sales$order\" LIMIT 20"}'
+```
+
+Der Body akzeptiert genau ein Feld `sql` oder `oql`. Ad-hoc-OQL durchläuft den
+sicheren PostgreSQL-Übersetzer; parametrisierte Abfragen und alles außer einer
+einzelnen `SELECT`-/`WITH`-Anweisung werden abgelehnt. Antworten enthalten
+`rows`, `row_count`, `elapsed_ms`, Warnungen oder einen strukturierten Fehler.
+Der Server bindet nur an Loopback, verwendet `mxrb_reader` und bereitet den
+Workspace standardmäßig vor; `--no-up` verwendet einen bereits laufenden
+Workspace.
+
+Die dauerhafte Bereinigung ist absichtlich explizit:
+
+```sh
+bundle exec mxrb db destroy Shop.mpr --yes
+```
+
+Entfernt werden nur Ressourcen mit dem passenden MXRB-Eigentümer-Label.
+
+## Sicherheitsgrenze
+
+- PostgreSQL wird ausschließlich an die Loopback-Schnittstelle gebunden.
+- Jeder absolute MPR-Pfad erhält eigene Container, Netzwerk, Volume und
+  Zustandsdaten.
+- Zufällige Zugangsdaten liegen außerhalb des Repositorys im
+  XDG-Zustandsverzeichnis und haben den Modus `0600`.
+- `db sql`, `db shell` und `db url` verwenden `mxrb_reader`; Rolle und
+  Transaktionen sind standardmäßig schreibgeschützt.
+- `mxrb_reader` erhält im isolierten Workspace `pg_read_all_stats`, damit
+  Runtime-Fingerprints korreliert werden können; dies erlaubt keine Datenänderung.
+- `--write` wählt ausdrücklich die Eigentümerrolle des Runtime. Direkte
+  Schreibzugriffe können Mendix-Invarianten verletzen und sollten Ausnahmen
+  bleiben.
+- Der PostgreSQL-Workspace zeigt nie auf eine bestehende entfernte Datenbank.
+  Die SQL-Server-Plananalyse ist eine separate, explizite Deployment-Verbindung;
+  dafür sollte ein Read-only-Login mit SHOWPLAN-Berechtigung verwendet werden.
+  Das Passwort bleibt in einer Umgebungsvariable und mutierende Schlüsselwörter,
+  auch in schreibenden CTEs, werden abgelehnt.
+
+Das exakte Mendix-Toolchain und der Docker-Daemon müssen verfügbar sein. Für
+SQL-Server-Pläne wird zusätzlich `sqlcmd` benötigt. Eine Schemasynchronisierung
+kann bei Modelländerungen vorhandene Daten ändern oder
+ablehnen. Wertvolle lokale Volumes sollten vor riskanten Migrationen gesichert
+werden.
+
+Siehe die offizielle Mendix-Dokumentation zu
+[OQL](https://docs.mendix.com/refguide/oql/),
+[Datenspeicherung](https://docs.mendix.com/refguide/data-storage/) und
+[Runtime-Datenbankeinstellungen](https://docs.mendix.com/refguide/custom-settings/).

data/docs/de-DE/platform-api-integration.md

@@ -0,0 +1,36 @@
+# Bewertung der Mendix-API-Integration
+
+Datum: 1. August 2026. Quelle: offizieller [Mendix-API- und SDK-Index](https://docs.mendix.com/apidocs-mxsdk/).
+
+## Entscheidungsmatrix
+
+| API oder SDK | Verwendung in MXRB | Entscheidung |
+| --- | --- | --- |
+| Projects API | zugängliche Apps und Projektmetadaten | als `team-server projects` integriert; standardmäßig lesend |
+| App Repository API | Repository-Info, Branches und Commits | in Team-Server-Erkennung und Clone integriert |
+| Marketplace Content API | Module/Widgets finden und laden | in Marketplace-Operationen integriert |
+| Build API | natives Artefakt mit offiziellem Cloud-Build vergleichen | optionale Prüfung; nie Abhängigkeit des nativen Builds |
+| Deploy API v4 | Apps/Umgebungen vor Release-Prüfung inventarisieren | lesender Adapter vorgeschlagen; Änderungen nur nach Bestätigung |
+| Pipelines API | bestehende CI/CD-Pipeline starten und beobachten | Opt-in-Adapter mit Idempotenz und Statusabfrage vorgeschlagen |
+| Backups API v2 | Snapshots vor Deployment auflisten/erstellen/laden | Sicherheitsadapter vorgeschlagen; Restore/Delete bleiben explizit |
+| Runtime API 11 | eigenes Java kompilieren und Runtime-Verträge prüfen | Vertrag für Proxy-Erzeugung; Java-API, kein REST-Ersatz |
+| Client- und Pluggable-Widget-APIs | Dojo-/React-/Data-Grid-Verträge | Referenz für Webartefakte, kein HTTP-Client |
+| Catalog APIs | kontrollierte Datenquellen verwalten | zukünftiges Plugin; außerhalb von Build/Runtime |
+| Model/Platform SDKs und Studio-Pro-Erweiterung | Apps remote modellieren oder Studio Pro erweitern | bewusst keine Pflicht; MXRB bleibt mit Ruby/SQLite/BSON eigenständig |
+
+## Integrationsregeln
+
+- Remote-Aufrufe sind explizit; `generate`, `compile`, `validate` und `db up` kontaktieren nie die Mendix Cloud.
+- PATs/API-Schlüssel stammen aus geschützter Datei oder Umgebung und werden nie in Berichte, Logs, Projekte oder Git geschrieben.
+- Lesen ist Standard. Build, Deploy, Pipeline, Restore, Mitgliedschaft und Löschen benötigen eigene Befehle und Bestätigung.
+- Die Build API gilt nur für Mendix-Cloud-Apps und verwendet Account-API-Keys; sie ersetzt den lokalen Compiler nicht.
+- Versionierte Runtime-/Frontend-APIs dienen als Kompatibilitätsnachweis. MXRB verwendet exakte Schemas/Seeds und schlägt ohne passenden Vertrag oder Launcher geschlossen fehl.
+
+## Empfohlene Reihenfolge
+
+1. App-Repository-Branches/Commits in `team-server` auflisten.
+2. Lesendes Deploy-Inventar und optionales Build-Vergleichsgate.
+3. Pipeline-Status/Start mit Idempotenz und begrenztem Polling.
+4. Backup-Listen/Erstellen/Download vor Cloud-Änderungen.
+
+Catalog und Studio-Pro-Erweiterungen bleiben getrennte Adapter, da sie das Risiko des nativen Kerns nicht senken.

data/docs/de-DE/platform-operations.md

@@ -0,0 +1,243 @@
+# Betrieb, Lifecycle und Marketplace
+
+## Diagnose, Benchmark und Weiterentwicklung
+
+```sh
+mxrb doctor .
+mxrb benchmark App.mpr --iterations 5 --json
+mxrb project inspect . --json
+mxrb upgrade --mendix 11.12.1 --target .
+mxrb upgrade --mendix 11.12.1 --target . --apply
+mxrb migrate plan .
+mxrb migrate check .
+```
+
+`doctor` prüft Ruby-Projekt, Aggregatoren, MPR und lokale Toolchain.
+`benchmark` misst Öffnen, semantische Indizierung und Validierung. Ein Upgrade
+ist ohne `--apply` nur eine Vorschau. Migration erzeugt das Projekt temporär
+und vergleicht es mit dem aktuellen MPR; `check` schlägt bei Modelldrift fehl.
+
+## Frontend-Migration und Abnahme
+
+```sh
+mxrb frontend migrate App.mpr --json
+mxrb frontend migrate App.mpr --apply --json
+script/frontend_acceptance App.mpr -o frontend-round-trip.json
+script/frontend_acceptance App.mpr --mxbuild /pfad/mxbuild -o frontend.json
+script/frontend_acceptance App.mpr --mx /pfad/mx -o frontend-diagnostics.json
+script/frontend_lifecycle_acceptance --version 11.12.1 --mx /pfad/mx \
+  --mxbuild /pfad/mxbuild --strict-warnings -o frontend-lifecycle.json
+script/frontend_browser_acceptance --scenario examples/frontend-browser-scenario.json \
+  --url http://127.0.0.1:18080 --password-file /pfad/credentials.json \
+  --baseline examples/frontend-browser-baseline-11.12.1.json
+script/frontend_browser_acceptance --scenario examples/page-chain-browser-scenario.json \
+  --url http://127.0.0.1:18080 --password-file /pfad/credentials.json
+```
+
+`mxrb frontend migrate` ist standardmäßig eine unveränderliche, fail-closed
+Vorschau. Für Mendix 10 und 11 plant der Befehl Aktualisierungen installierter
+Pluggable-Widget-Schemata, alter Layout-Zeilen-Gewichte und Design Properties
+aus dem Paket-XML. `--apply` schreibt nur einen sicheren Plan in einer einzigen
+MPR-Transaktion. Unbekannte konfigurierte Properties, eine nicht unterstützte
+Generation oder eine nach der Vorschau geänderte Unit blockieren den Schreibzugriff.
+Weder Vorschau noch Anwendung rufen Mendix-Werkzeuge auf.
+
+`script/frontend_acceptance` ist das reproduzierbare 10/11-Gate. Es validiert
+Quell- und Rebuild-MPR, verlangt für beide einen kompatiblen nativen Preflight,
+exportiert nach Ruby, baut neu auf, vergleicht die Modellstruktur und prüft
+vollständige Asset-Inventare, Bytes, SHA-256-Prüfsummen und Marketplace-
+Provenienz. Die Provenienzgrenze umfasst `.mxrb/marketplace.lock.json`, den
+Paketcache und `.mxrb/marketplace-originals`; fehlende, geänderte oder
+unerwartete Dateien lassen das Gate fehlschlagen. Die akzeptierte Renderer-
+Matrix deckt jetzt Forms-Tabellen, `ListViewXPathSource`, Listen-Target-
+Objekt-Properties, strukturierte Page-Variable-Mappings und Combo-box-
+Enumerationen ab. Die Preflight-Basis sank unter 10.24 von 28 auf 0 und unter
+11.12 von 20 auf 0 Befunde.
+
+Ohne `--mxbuild` lautet der Report-Scope `round_trip`, und `frontend_ready`
+bleibt unbelegt. Mit `--mxbuild` dient MxBuild als schreibgeschütztes externes
+Orakel und der Scope lautet `frontend`; es generiert, verändert oder repariert
+das Projekt nie. Das Live-Orakel akzeptiert Erfolg nur, wenn MxBuild mit Status
+null endet und ein nicht leeres MDA erzeugt; ein Toolchain-Fehler ohne gemeldete
+Modellfehler schlägt geschlossen fehl. Am 4. August 2026 schloss die sichere
+Migration die akzeptierte Matrix 10.24.0.73019 und 11.12.1 ab: Quelle und Rebuild lieferten null
+MxBuild-Fehler, und beide Reports setzten `frontend_ready` auf `true`.
+
+`script/frontend_lifecycle_acceptance` erstellt eine App ausschließlich über
+die CLI, erzeugt das MPR, exportiert nach Ruby, ändert Home und Navigation,
+fügt Entität, Formular, Microflow, Nanoflow und Asset hinzu, erzeugt erneut,
+exportiert ein zweites Mal und verlangt einen strukturell identischen Rebuild.
+In der offiziellen Matrix 10.24.0.73019 und 11.12.1 endeten Quelle und Rebuild
+mit null Fehlern, Warnungen, Deprecations oder Empfehlungen in `mx check` sowie
+null MxBuild-Fehlern.
+
+`script/frontend_browser_acceptance` steuert Chromium über lokales CDP,
+authentifiziert ohne Passwort in der Kommandozeile und vergleicht
+deterministische Snapshots von Struktur, Geometrie, Styles und ARIA-Zustand.
+Browser-Ausnahmen, defekte Widgets und der generische Runtime-Fehlerdialog
+lassen das Gate fehlschlagen. Nur `--update-baseline` ersetzt die Baseline;
+normale Läufe vergleichen schreibgeschützt. `mx.logout()` hält das Gate auch
+unter einer Trial-Lizenz wiederholbar.
+
+`page-chain-browser-scenario.json` verwendet eine `PageChainQa`-App mit
+`DirectOrder`, `ClientOrder` und `HybridOrder`, erzeugt durch die drei Werte von
+`page --chain`. Das Szenario klickt auf jeder Seite `Refresh` und verlangt auch
+berechnetes CSS — Dokumentrand, Header-Gradient und Card-Hintergrund —, sodass
+funktionales HTML ohne Theme das Gate nicht besteht.
+
+`--mx` führt den offiziellen schreibgeschützten Checker mit Warnungen,
+Deprecations und Best-Practice-Empfehlungen aus. Das Gate validiert die
+Exit-Bitmaske und vergleicht normalisierte Signaturen von Quelle und Rebuild.
+Die akzeptierte 10.24-Fixture hat 0 Fehler, 173 paketbezogene Warnungen,
+0 Deprecations und 2 Kafka-Empfehlungen; 11.12 hat 0 Fehler, 10 paketbezogene
+Warnungen, 0 Deprecations und dieselben 2 Empfehlungen. Die JSON-Dateien von
+Quelle und Rebuild sind in beiden Generationen bytegleich; diese beobachtbaren
+Paketdiagnosen sind kein MXRB-Round-trip-Drift.
+
+## Offizieller und Community-Mendix-Marketplace
+
+MXRB verwendet die dokumentierte Mendix Marketplace Content API. Das PAT
+benötigt den Scope `mx:marketplace-content:read`:
+
+```sh
+cp .env.example .env
+# MXRB_MENDIX_PAT in .env setzen; die Datei nie committen.
+mxrb marketplace login --pat-file .env
+mxrb marketplace search "Community Commons"
+mxrb marketplace show 170
+mxrb marketplace versions 170 --mendix-version 11.12.1
+mxrb marketplace pull 170 --mpr MeineApp.mpr
+mxrb marketplace dependencies CommunityCommons --mpr MeineApp.mpr
+mxrb marketplace dependencies CommunityCommons --mpr MeineApp.mpr --apply
+mxrb marketplace dependencies CommunityCommons --mpr MeineApp.mpr --apply-resolved
+mxrb marketplace update 170@3.5.0 --mpr MeineApp.mpr
+mxrb marketplace update 170@3.5.0 --mpr MeineApp.mpr --apply
+mxrb marketplace remove CommunityCommons --mpr MeineApp.mpr
+mxrb marketplace remove CommunityCommons --mpr MeineApp.mpr --apply
+mxrb marketplace pull github:mendix/CommunityCommons
+mxrb marketplace import ./CommunityCommons.mpk --mpr MeineApp.mpr
+mxrb marketplace audit --target . --mendix-version 11.12.1
+mxrb marketplace list
+mxrb marketplace verify
+```
+
+Der empfohlene Login speichert ausschließlich den absoluten `.env`-Pfad in
+`~/.config/mxrb/credentials` (oder `$XDG_CONFIG_HOME/mxrb/credentials`). MXRB
+kopiert oder verändert die referenzierte Datei nicht und liest sie erst für
+eine authentifizierte Marketplace-Operation. Neue Scaffolds ignorieren `.env`
+und erzeugen eine geheimnisfreie `.env.example`.
+
+`mxrb marketplace login --store-pat` aktiviert die verwaltete Speicherung
+explizit; Ziel, JSON-Format und Modus `0600` werden vor der Eingabe angezeigt.
+`MXRB_MENDIX_PAT_FILE=/pfad/.env` funktioniert ohne gespeicherte Referenz.
+Details zeigt `mxrb marketplace login --help`.
+
+Die offizielle Suche umfasst öffentliche und unternehmensprivate Inhalte.
+`show` liefert Herausgeber, Typ, Support, Lizenz, Sichtbarkeit und Freigabe;
+`versions` liefert Kompatibilität, Release Notes sowie Sicherheitsstatus und
+CVE/CWE-Kennungen.
+
+Mit `--mpr` liest MXRB `package.xml` und die eingebettete `project.mpr` und
+importiert den vollständigen Modulbaum direkt über Ruby/SQLite/BSON. Dabei
+werden weder `mx` noch `mxcli`, Studio Pro oder das Model SDK ausgeführt. IDs
+bleiben erhalten, deklarierte Assets werden transaktional installiert und
+Paketcache sowie Modulidentität im Lockfile gespeichert. Kompatible offizielle
+Pakete dürfen in eine neuere Modellversion des Projekts importiert werden;
+lokale und GitHub-Imports erfordern weiterhin eine identische Modellversion.
+Bei Atlas Core werden außerdem die Legacy-Sass-Variablen verbunden, ohne
+Projektanpassungen zu überschreiben.
+
+Der offizielle `pull` ist Standard, wählt eine zum Ziel-MPR kompatible Version
+und blockiert bekannte verwundbare Versionen ohne `--allow-vulnerable`.
+`github:` bleibt als Fallback erhalten, `import` verarbeitet lokale MPKs.
+Content ID, Version ID und Sicherheitsstatus werden gesperrt; `audit` prüft
+Updates und Schwachstellen. `login` validiert und speichert das PAT außerhalb
+des Projekts mit Modus `0600`. Das PAT wird nur an die exakten offiziellen
+Hosts `marketplace-api.mendix.com` und `marketplace.mendix.com` gesendet.
+
+`marketplace dependencies` entdeckt ungelöste qualifizierte Modulreferenzen im
+eingebetteten Paket-MPR, löst sie rekursiv über die offizielle API, lädt jeden
+Kandidaten und akzeptiert ihn nur, wenn das MPK selbst die angeforderte
+Modulidentität bestätigt. Projekteigene Module erfüllen Referenzen, ohne als
+Marketplace-Pakete ausgegeben zu werden. Standard ist eine Vorschau; `--apply`
+verlangt einen vollständig sicheren Graphen und installiert Blätter zuerst mit
+Rollback. `--apply-resolved` ist die explizite Freigabe für den verifizierten
+Teilgraphen und meldet ungelöste Identitäten weiterhin als blockiert.
+
+Am 4. August 2026 importierte die authentifizierte Abnahme Kafka 2.12.0
+(Content ID 105878) und löste den offiziellen Graphen unter 10.24.0.73019 und
+11.12.1. Beide Graphen importierten DataWidgets 3.11.3 mit Content ID 116540
+und Version ID `e7b6d703-8e47-42f4-bb92-934e3601e71b`. Die abschließend
+authentifizierte Combo box ist die unabhängige offizielle Widget/clientModule-
+Komponente 219304, Version 2.9.0, Version ID
+`dce845f4-d051-4161-847c-016c01703caa`. Ihre Installation sichert und ersetzt
+das ältere Combo-2.6.x-Asset aus Atlas Core (Content ID 117187); Atlas ist der
+frühere Asset-Eigentümer, nicht die Combo-Komponente. Der 11.12-Graph enthält
+außerdem Library Logging 1.13.0, Encryption 11.1.1, Mx Model Reflection 9.1.0
+und Mendix Feedback Module 5.0.0 (Content ID 205506). Da der Namensindex
+`FeedbackModule` nicht liefert, nutzt MXRB die offizielle Content ID nur als
+Discovery-Hinweis und prüft weiterhin den internen MPK-Modulnamen.
+
+Beide Generationen bestehen jetzt das vollständige Frontend-Abnahme-Gate mit
+null Preflight-Befunden für Quelle und Rebuild, struktureller Gleichwertigkeit,
+exakten Assets und Marketplace-Provenienz sowie null MxBuild-Fehlern. Ruby-
+Export/Rebuild bewahrt den Marketplace-Lock, gecachte MPKs, Originale,
+deklarierte Assets und ihre Prüfsummen; das neu aufgebaute Projekt behält damit
+die Paketprovenienz und nicht nur die Widget-Bytes. MxBuild bleibt ausschließlich
+externe Validierung und nie eine Implementierungsabhängigkeit von MXRB.
+
+Offizielle Befehle `update` und `remove` sind ohne explizites `--apply` sichere
+Vorschauen. Vor einer Änderung vergleicht MXRB Modul und Unit-Anzahl aus dem
+Lock mit dem Cache-Paket, durchsucht alle externen Units nach Referenzen auf
+wegfallende IDs und verweigert veränderte oder fehlende Paket-Assets. Ein
+Update muss die Modul-ID und jede extern referenzierte Unit-ID erhalten. Beim
+Anwenden sichert MXRB MPR, v2-`mprcontents`, Lock, Caches, deklarierte Assets und
+die Atlas-Variablendatei; jeder Fehler stellt diese gesamte Grenze wieder her.
+Gemeinsame Assets werden nicht entfernt, solange ein anderes gesperrtes Paket
+sie beansprucht.
+
+## Protokoll-Connector-Audit
+
+`mxrb protocols` ist ein schreibgeschütztes Audit der IoT-, Industrie- und
+Messaging-Connectoren, die ein Projekt aus dem Marketplace importiert hat. Es
+führt kein Protokoll aus und installiert nichts; es meldet nur die öffentlichen
+Metadaten, die das Modell offenlegt.
+
+```sh
+mxrb protocols App.mpr
+mxrb protocols App.mpr --json
+```
+
+Erkannte Connectoren werden mit Modulname, Protokoll und Marketplace-
+Komponenten-id aufgeführt; nicht erkannte Marketplace-Module werden separat
+gelistet. Die Erkennung erfolgt über eine verifizierte `AppStoreGuid`, sodass
+ein Modul mit unbestätigter GUID als nicht erkannt gemeldet und nicht geraten
+wird.
+
+Diese Protokoll-Registry ist ein dritter Katalog, getrennt von den
+wiederverwendbaren Ruby-Modulen aus `mxrb module` und den offiziellen Paketen
+aus `mxrb marketplace`.
+
+Verifizierte öffentliche Komponenten-IDs decken derzeit MQTT, OPC-UA, Kafka,
+AMQP und WebSocket ab. Authentifizierte Abfragen der Content API und des
+offiziellen Katalogs liefern weiterhin keine Modbus-Komponente; Modbus bleibt
+daher unregistriert, bis eine offizielle Komponente oder ein echtes MPR-Fixture
+die Identität belegt. Öffentliche IDs dienen der Planung; die Erkennung im MPR
+erfordert weiterhin eine verifizierte `AppStoreGuid`.
+
+Der Ruby-Builder kann eine Installation deklarieren, ohne ein leeres Modul oder
+eine erfundene GUID zu schreiben:
+
+```ruby
+builder.connector :kafka, version: "2.12.0"
+plaene = builder.connector_plans(adapter: Mxrb::Protocols.adapter(installer:, api:))
+plaene.each { puts _1.changes }
+plaene.each(&:apply!) # explizite authentifizierte Marketplace-Operation
+```
+
+Ohne Adapter bleibt `connector_plans` eine Vorschau. `build!` schlägt bei noch
+offenen Connector-Deklarationen ebenfalls geschlossen fehl; der echte Inhalt
+muss zuerst über den offiziellen Adapter in ein MPR installiert werden.
+Marketplace-Einträge vom Typ `Module` und `Service` können aufgelöst werden,
+während das heruntergeladene MPK zusätzlich die Modul-Paketprüfungen bestehen
+muss.

data/docs/de-DE/project-structure.md

@@ -0,0 +1,32 @@
+# Struktur des exportierten Projekts
+
+[Português](../pt-BR/project-structure.md) · [English](../en-US/project-structure.md) · **Deutsch**
+
+Der von `mxrb export` erzeugte Baum trennt anwendungsweite Richtlinien,
+Modulverhalten, erhaltene native Units und Assets:
+
+```text
+project.rb
+.mxrb/{native_units.json,native_units.rb,assets.json}
+app/{security,navigation,design_system}/
+modules/Modulname/{domain,application,presentation,infrastructure,security}/
+theme/
+themesource/
+resources/
+widgets/
+javasource/
+javascriptsource/
+```
+
+`project.rb` orchestriert das Laden. Module enthalten das Verhalten. Das
+native Manifest erhält Strukturen ohne kompakte DSL; das Asset-Manifest
+speichert relative Pfade, Größen und SHA-256-Prüfsummen.
+
+Absolute Pfade, `..`-Traversal, fehlende Dateien und abweichende Prüfsummen
+schlagen beim Wiederaufbau sicher fehl. Nur Manifest-Einträge werden geschrieben.
+
+Die Struktur unterstützt Ruby zu einem neuen Mendix-Projekt, Ruby auf einem
+exportierten Baseline, Mendix zu bearbeitbarem Ruby und den strukturell
+gleichwertigen Mendix → Ruby → Mendix Round-trip.
+
+[Zurück zum Index](README.md)

data/docs/de-DE/ruby-first-roadmap.md

@@ -0,0 +1,116 @@
+# MXRB: Ruby über alles
+
+[Português](../pt-BR/ruby-first-roadmap.md) · [English](../en-US/ruby-first-roadmap.md) · **Deutsch**
+
+## Architekturprinzip
+
+Ruby ist die einzige öffentliche Sprache von MXRB. CLI-Befehle sind dünne
+Adapter. Es wird weder MDL noch eine konkurrierende DSL eingeführt. Studio Pro
+und MxBuild sind externe Validatoren, keine Abhängigkeiten des Ruby-Kerns.
+
+## Verfügbar
+
+- Tiefes Lesen und Schreiben von MPR v1/v2.
+- Export in bearbeitbare Ruby-Projekte.
+- Bearbeitbare `native_unit`-Hashes für jede native BSON-Struktur.
+- Generierung, Integritätsprüfung, Vergleich und typisierter Diff.
+- Semantischer Index, Referenzen, Caller/Callee und Impact.
+- Sichere Umbenennung mit Vorschau.
+- Sichere Entfernung eigenständiger Units mit Vorschau.
+- Statische Analyse und ausführbare Modellbewertungen.
+- Funktionale Microflow-Tests ohne JUnit.
+- Lokale oder Docker-Ausführung von `mx check`, MxBuild und Runtime.
+- Natives Coverage-Gate mit 100 % Zeilen und 100 % Branches im CI;
+  ohne explizite Grenzwerte bleibt der lokale Standard strenger bei 100/100.
+
+## Beispiel
+
+```ruby
+Mxrb.open("app.mpr") do |project|
+  project.references_to("Sales.Order")
+  project.callers_of("Sales.Recalculate")
+  project.impact_of("Sales.Order")
+  project.plan_rename("Sales.Order", to: "Invoice")
+  plan = project.plan_remove("Sales.UnusedFlow")
+  plan.apply! if plan.safe?
+  project.analyze
+end
+```
+
+Bewertungsdateien sind gewöhnliches Ruby und werden mit
+`mxrb evaluate app.mpr evaluation.rb` ausgeführt.
+
+Schreibbare Projekte speichern einen fingerprint-basierten Cache des
+semantischen Index im MPR. Schreibgeschützte Öffnungen dürfen ihn
+wiederverwenden, verändern das Projekt jedoch nie.
+`mxrb cache status`, `warm` und `clear` liefern Metriken und Wartung. Beim
+Ersetzen wird zuerst per Upsert geschrieben und erst danach ein veralteter
+Eintrag entfernt.
+
+Die exakte native Mendix-5-Validierung bleibt von Windows/Studio Pro abhängig.
+Sie ist als entfernte Legacy-Einschränkung dokumentiert und kein aktuelles
+Auslieferungs-Gate.
+
+Navigationsprofile lesen und schreiben jetzt native Mendix-Dokumente,
+einschließlich rollenbasierter Startziele und rekursiver Menüs. Theme- und
+Quell-Assets durchlaufen den Round-trip mit einem Prüfsummenmanifest;
+Design-Tokens bieten Inventar, Lint, Kontrastmetriken und eine
+Preview-basierte Migration literaler Werte.
+
+Beim Entfernen blockieren eingehende Referenzen und Kind-Units den Plan.
+Eingebettete Domain-Modellelemente benötigen ihre typisierte Mutation. Die CLI
+zeigt mit `mxrb remove app.mpr Sales.UnusedFlow` nur die Vorschau; `--apply`
+schreibt ausschließlich einen sicheren Plan.
+
+Eigenständige Units können innerhalb desselben Moduls in ein Modul oder einen
+Ordner verschoben werden:
+
+```ruby
+plan = project.plan_move("Sales.Process", to: "Sales.Automation")
+plan.apply!
+```
+
+Der Plan bewahrt den nativen Containment-Typ und blockiert Domain-
+Modellelemente, ungültige Container, Ordnerzyklen und modulübergreifende
+Verschiebungen. `mxrb move` zeigt eine Vorschau; erst `--apply` schreibt.
+
+## Offizieller Mendix Marketplace
+
+Diese Befehlsfamilie bleibt von `mxrb module` getrennt. Die dokumentierte
+Marketplace Content API unterstützt authentifizierte Suche, Details,
+kompatible Versionen, direkten Download, private Unternehmensinhalte und
+Sicherheitsaudits. GitHub und lokale MPKs bleiben Fallbacks.
+
+Lokale MPKs werden vollständig und ohne Mendix-Werkzeuge direkt über
+Ruby/SQLite/BSON in das Ziel-MPR importiert. Das PAT benötigt
+`mx:marketplace-content:read`. Verwundbare Releases werden standardmäßig
+abgelehnt; Content-/Version-IDs und Sicherheitsdaten stehen im Lockfile.
+Die authentifizierte Kafka-Abnahme und der transaktionale Lifecycle sind jetzt
+umgesetzt. `marketplace update` und `marketplace remove` zeigen standardmäßig
+nur eine Vorschau, erhalten extern referenzierte IDs, verweigern veränderte
+Assets und sichern MPR, `mprcontents`, Cache, Lock und Assets vor explizitem
+`--apply`. Auch die authentifizierten Folgeschritte sind umgesetzt:
+`marketplace dependencies` löst offizielle Pakete rekursiv aus Referenzen im
+eingebetteten MPR, prüft die tatsächliche Modulidentität jedes MPKs, erkennt
+projekteigene Module, installiert Blätter zuerst und führt atomaren Rollback
+aus. Kafka-Graphen bestanden die Abnahme unter 10.24 und 11.12; Ruby-
+Export/Rebuild bewahrt Assets, Prüfsummen und Quell-/Rebuild-Diagnosen.
+
+Die authentifizierte Matrix enthält jetzt DataWidgets 3.11.3 (Content ID
+116540, Version ID `e7b6d703-8e47-42f4-bb92-934e3601e71b`) und die unabhängige
+offizielle Combo-box-Widget/clientModule-Komponente 219304, Version 2.9.0,
+Version ID `dce845f4-d051-4161-847c-016c01703caa`. Die Installation sichert und
+ersetzt das zuvor Atlas Core (Content ID 117187) gehörende 2.6.x-Asset. Ruby-
+Roundtrips bewahren die Provenienz von Marketplace-Lock, Cache und Originalen;
+`script/frontend_acceptance` blockiert Modell-, Asset-, Prüfsummen- oder
+Provenienzdrift. Der native Renderer hat für die akzeptierten 10.24- und
+11.12-Fixtures null Preflight-Befunde in Quelle und Rebuild.
+
+Die Migrationsschnittstelle ist als `mxrb frontend migrate DATEI.mpr`
+umgesetzt: Standard ist die Vorschau, erst `--apply` schreibt einen sicheren
+transaktionalen Plan. Diese Migration ist auf der gesamten unterstützten
+Frontend-Matrix abgeschlossen. Das optionale externe MxBuild-Orakel liefert
+für Quelle und Rebuild unter 10.24 und 11.12 null Fehler; `mx check` bewahrt
+außerdem bytegleiche beobachtbare Paketdiagnosen in jedem Round-trip. MXRB
+bleibt unabhängig: `mx` und MxBuild sind nur Validierungsorakel, niemals
+Generatoren, Mutatoren oder Runtime-Abhängigkeiten.