⚡ Zeus RPG PromptKit – Evidence-first Analyse für IBM i, RPG und gewachsene Legacy-Systeme

🧩 Warum IBM i mehr Kontext braucht als ein einzelnes Source-Member

Viele KI-Demos zur Softwareentwicklung sehen beeindruckend aus: Code erklären, Dokumentation erzeugen, Tests vorschlagen oder Modernisierungsschritte planen. Auch für IBM i kann das sehr hilfreich sein.

In realen Landschaften reicht ein einzelnes RPG-Source-Member jedoch selten aus. Eine Anwendung besteht typischerweise aus einem Netz miteinander verbundener Elemente:

• RPG-, CL- und DDS-Quellen
• Programme, Prozeduren, Serviceprogramme und Call-Strukturen
• Source-Member in unterschiedlichen Bibliotheken
• physische und logische Dateien
• Db2-Tabellen, Views, Aliase, Keys und Trigger
• Feldverwendungen und Datenflüsse
• dynamisches SQL und externe Schnittstellen
• historisch gewachsene Sonderlogik

Fehlt dieser Zusammenhang, entstehen schnell plausible, aber unsichere Schlussfolgerungen. Eine KI kann sprachlich sehr überzeugend erklären, was ein Programm vermutlich tut – und trotzdem eine indirekte Abhängigkeit, einen Trigger oder eine nur dynamisch aufgelöste Referenz übersehen.

Zeus RPG PromptKit bereitet diesen Kontext so auf, dass aufgelöste Beziehungen, offene Fragen und Quellen der Analyse sichtbar bleiben.

⚙️ Was eine Evidence Preparation Layer leistet

Zeus versteht sich nicht als magische Modernisierungsmaschine, sondern als technische Zwischenschicht. Das Toolkit sammelt Evidenz aus Quellen und Metadaten, normalisiert sie und erzeugt daraus ein strukturiertes, überprüfbares Modell.

Das Ziel ist nicht, Unsicherheit zu verstecken. Im Gegenteil: Sicher aufgelöste Beziehungen sollen von unvollständigen oder weiterhin offenen Referenzen unterscheidbar bleiben.

Damit lassen sich unter anderem folgende Fragen besser bearbeiten:

• Welche Programme, Prozeduren, Dateien und Tabellen hängen zusammen?
• Wo wird ein bestimmtes Feld gelesen, verändert oder weitergereicht?
• Welche Auswirkungen könnte eine geplante Änderung haben?
• Welche Referenzen sind sicher aufgelöst – und welche bleiben unklar?
• Welche Db2-Metadaten fehlen noch für eine belastbare Einordnung?
• Welcher Kontext kann kontrolliert an eine KI übergeben werden?

Zeus ist dabei KI-anbieterneutral. Die erzeugten Artefakte können mit ChatGPT, GitHub Copilot, Claude, lokalen Modellen oder vollständig ohne KI in Architektur-Reviews, Tickets, Dokumentationen und QA-Prozessen genutzt werden.

🔄 Vom Source-Code zum prüfbaren Analysemodell

Der typische Arbeitsablauf bleibt bewusst nachvollziehbar:

Dieser Ablauf ist absichtlich weniger spektakulär als ein „Ein Klick modernisiert alles“-Versprechen. Für geschäftskritische Systeme ist genau diese Nüchternheit aber ein Vorteil.

✨ Was Zeus heute bereits abdeckt

Seit der ersten Fassung dieses Artikels ist das Projekt deutlich breiter geworden. Aus dem ursprünglichen Fokus auf Analyse und KI-Prompts ist eine erweiterbare, safety-first ausgerichtete Analyseplattform entstanden.

Nicht jede Funktion ist gleich weit produktisiert. Besonders MCP, Viewer, PUI- und VS-Code-Funktionen sind weiterhin als experimentelle Integrationen zu verstehen. Die verbindliche Referenz für aktuelle Befehle, Optionen und Safety-Level ist der automatisch erzeugte Tool-Katalog im Repository.

📊 Reports, Graphen und kanonische Analyseartefakte

Nach einem Analyse-Lauf entsteht kein einzelner unprüfbarer Text, sondern ein Satz miteinander verbundener Dateien.

Wichtige Abgrenzung: ai-knowledge.json ist keine dauerhaft wiederverwendbare Wissensdatenbank. Die Datei ist eine Projektion eines konkreten Analyse-Laufs und kann projektspezifische oder sensible Informationen enthalten.

Für zukünftige, projektneutrale Wissensbausteine besitzt Zeus eine getrennte Knowledge-Pipeline mit klaren Bereichen für Roh-Evidenz, redaktierte Kandidaten, finale Katalogverträge und fail-closed Privacy-Gates. Source-abgeleitete Projektdaten werden nicht automatisch zu wiederverwendbarem Toolkit-Wissen.

🔍 Investigation, Impact und Review-Workflows

Eine Analyse ist selten mit einem einzigen Report abgeschlossen. Häufig entstehen beim Lesen neue Fragen: Woher kommt ein bestimmter Wert? Welche Fehlerpfade existieren? Welche Programme verwenden ein Feld indirekt? Welche Tabellen könnten von einer Änderung betroffen sein?

Dafür bietet Zeus inzwischen eigene Such-, Investigation- und Review-Pfade. Zu den relevanten Befehlen gehören unter anderem:

• investigate – vorhandene Analyseergebnisse zielgerichtet vertiefen
• search-source – lokale Quellen nach konkreten Mustern durchsuchen
• field-search – Feld- und Tabellenverwendungen lokal oder remote untersuchen
• trace und xref – Beziehungen und Verwendungen verfolgen
• impact – Reverse-Impact-Analysen nach Programm, Feld oder Ziel erzeugen
• assess-risk – technische Risiken strukturiert zusammenfassen
• generate-test – Testszenarien und Testpläne vorbereiten
• generate-checklist – Change- und Deployment-Checklisten erzeugen
• qa – QA-Ergebnisse als Markdown, JSON oder Jira-nahe Ausgabe aufbereiten
• bundle – ausgewählte Artefakte für Review oder sichere Weitergabe bündeln

Zusätzlich existieren Workflow-Presets für typische Aufgaben wie Onboarding, Architektur-Review, Security-Review, Modernisierungsbewertung, Dependency-Risiken, Refactoring und Testgenerierung.

node cli/zeus.js analyze \
  --source ./rpg_sources \
  --program ORDERPGM \
  --out ./output \
  --optimize-context \
  --dense full

node cli/zeus.js investigate \
  --program ORDERPGM \
  --profile dev \
  --goal "Fehlerpfade und Seiteneffekte prüfen"

node cli/zeus.js impact \
  --field RECORD_ID \
  --program ORDERPGM \
  --source ./rpg_sources \
  --out ./output

🛠️ CLI-first und reproduzierbar

Zeus RPG PromptKit bleibt bewusst CLI-first. Die Kommandozeile ist kein Notbehelf, sondern der unterstützte Hauptpfad für reproduzierbare Analyse- und Kontext-Workflows.

Das bringt mehrere Vorteile:

• Befehle lassen sich dokumentieren und wiederholen.
• Profile und Umgebungen bleiben nachvollziehbar.
• Ausgaben können versioniert, verglichen und in CI-Prozesse eingebunden werden.
• Menschen sehen, welcher Schritt welche Artefakte erzeugt hat.
• KI-Clients greifen nicht auf eine unsichtbare Blackbox zu, sondern auf definierte Tools und Dateien.

Nützliche Optionen für größere Programme und stabile Läufe sind unter anderem:

Die lokale Browser-Ansicht über serve kann vorhandene Reports und Graphen komfortabel darstellen. Sie ersetzt jedoch weder das Laden der Shell-Umgebung noch die CLI- und MCP-Kommandos für Analyse, Fetch, Db2 oder Remote-Prüfungen.

🤖 Lokale MCP-Integration für kontrollierte KI-Agenten

Ein wichtiger Entwicklungsschritt ist die lokale MCP-Integration. Über MCP kann Zeus ausgewählte Werkzeuge und Ressourcen für kompatible KI-Clients bereitstellen.

Der Ansatz lautet ausdrücklich nicht: „Der Agent darf alles.“

Stattdessen stehen Begrenzung und Nachvollziehbarkeit im Mittelpunkt:

• lokaler stdio-Transport statt frei erreichbarem Remote-Service
• sichere, read-orientierte Default-Oberfläche
• explizite Tool-Allowlist für konkrete Aufgaben
• Maskierung typischer Secrets in Antworten und Fehlermeldungen
• append-only Audit-Trail unter .local/mcp/audit/
• Timeouts und Limits für Antwortgrößen
• Workspace-Grenzen auch für absolute Pfade
• standardmäßig blockierte Schreiboperationen

node cli/zeus.js mcp serve --stdio true --verbose

Besonders strikt ist der Umgang mit SQL-Schreiboperationen. Planung und tatsächliche Ausführung sind getrennt. Ein Apply-Pfad benötigt mehrere explizite Freigaben, passende Profilregeln und ein Bestätigungstoken. Produktionsprofile bleiben für solche Pfade blockiert.

Das ist ein wichtiger Unterschied zu vielen Agenten-Demos: Nicht maximale Autonomie ist das Ziel, sondern kontrollierte Unterstützung mit klaren Grenzen.

🧩 Erweiterbare API und VS-Code-Integration

Neben der CLI exportiert das Paket eine Programmatic API. Damit können eigene Analyzer, Analyse-Stages, Plugins und MCP-Tools registriert werden.

const { zeus } = require('zeus-rpg-promptkit/api');

zeus.analyzers.registerAnalyzer('my-analyzer', {
  run(context) {
    return { customEvidence: true };
  }
});

zeus.registerPlugin(myPlugin);

Damit entwickelt sich Zeus von einem fest verdrahteten Kommandozeilenwerkzeug zu einer erweiterbaren Analyse- und Kontext-Engine.

Parallel entsteht unter vscode-extension/ eine experimentelle Editor-Integration. Sie soll:

• das aktuell geöffnete RPG-Programm oder Member analysieren,
• lokale Analysen und Reports direkt im Editor anzeigen,
• dieselbe Zeus API wie CLI und MCP verwenden,
• neben Code for IBM i arbeiten können,
• und mit lokalem Fallback auch ohne aktive IBM-i-Verbindung nutzbar bleiben.

Die Extension ist derzeit eine Grundlage in Entwicklung und noch nicht der primäre Produktpfad. Strategisch ist sie trotzdem interessant: Die Analyse-Engine rückt damit näher an den täglichen Arbeitsplatz von IBM-i-Entwicklerinnen und -Entwicklern.

⚡ Lokaler Schnellstart

Für einen ersten Eindruck ist keine Verbindung zu einem IBM-i-System erforderlich. Das Repository enthält ein synthetisches Mini-System mit reproduzierbaren Demo-Artefakten.

Voraussetzungen

• Node.js 20 oder neuer
• Java 11 oder neuer für JT400- und Db2-nahe Funktionen
• optional: IBM-i-Zugang für Fetch-, Discovery- oder Db2-Workflows

Installation und Demo

git clone https://github.com/gzeuner/zeus-rpg-promptkit.git
cd zeus-rpg-promptkit
npm install
npm run demo:run

Typische Demo-Ausgaben:

examples/demo-rpg-mini-system/output-baseline/report.md
examples/demo-rpg-mini-system/output-baseline/architecture-report.md
examples/demo-rpg-mini-system/output-baseline/ai-knowledge.json
examples/demo-rpg-mini-system/output-baseline/dependency-graph.mmd

Optional kann der lokale Viewer gestartet werden:

node cli/zeus.js serve \
  --source-output-root ./examples/demo-rpg-mini-system/output-baseline

Danach ist die lokale Ansicht unter http://127.0.0.1:4782 erreichbar.

Eigene lokale Quellen analysieren

node cli/zeus.js analyze \
  --source ./rpg_sources \
  --program ORDERPGM \
  --out ./output \
  --optimize-context \
  --dense full

Für ein neues IBM-i-System empfiehlt sich der dokumentierte Ablauf:

1. lokales Profil anlegen,
2. Umgebungsvariablen laden,
3. doctor --probe --show-resolved ausführen,
4. die Umgebung read-only mit discover-environment untersuchen,
5. Objekte mit resolve-object verifizieren,
6. Quellen holen und anschließend lokal analysieren.

👥 Für wen Zeus RPG PromptKit gedacht ist

Das Toolkit richtet sich an Menschen und Teams, die gewachsene IBM-i-Landschaften besser verstehen, dokumentieren oder kontrolliert modernisieren möchten.

Typische Zielgruppen sind:

• IBM-i- und RPG-Entwicklerinnen und -Entwickler
• Software- und Lösungsarchitektinnen und -architekten
• Modernisierungs- und Migrationsteams
• QA- und Test-Teams
• Consultants und technische Projektleitungen
• Onboarding- und Dokumentationsteams
• Teams mit KI-gestützten Analyse- oder Review-Workflows

Besonders wertvoll ist Zeus dort, wo das System zuverlässig läuft, das Wissen darüber aber auf viele Köpfe, Source-Member, Bibliotheken und historische Dokumente verteilt ist.

Viele Legacy-Systeme leiden nicht in erster Linie darunter, dass sie alt sind. Sie leiden darunter, dass ihre Zusammenhänge schwer sichtbar sind.

🧭 Was das Toolkit bewusst nicht ersetzt

Zeus RPG PromptKit ersetzt weder Fachwissen noch verantwortliche Entwicklung.

Das Projekt:

• schreibt nicht autonom Business-Code auf IBM i,
• führt keine ungeprüften Produktionsänderungen aus,
• garantiert bei unvollständigen Quellen keine vollständige Analyse,
• macht aus einer KI-Ausgabe nicht automatisch eine verlässliche Entscheidung,
• ersetzt keine Tests, Reviews, Freigaben oder Betriebsprozesse,
• ist kein offizielles IBM-Produkt und nicht mit IBM verbunden.

Auch ein sehr guter Dependency-Graph bleibt ein Modell der verfügbaren Evidenz. Dynamische Aufrufe, externe Systeme, generierter Code oder fehlende Quellen können Grenzen setzen. Seriöse Analyse bedeutet deshalb auch, diese Grenzen sichtbar zu lassen.

🌍 Open Source, Transparenz und Herstellerhinweis

Zeus RPG PromptKit steht unter der Apache License 2.0 und wird öffentlich auf GitHub entwickelt.

Zum Transparenzansatz gehören:

• offener Quellcode,
• lokale Ausführung,
• reproduzierbare CLI-Befehle,
• sichtbare Reports und JSON-Artefakte,
• ein generierter Tool-Katalog als verbindliche Referenz,
• klare Safety-Level und dokumentierte Guardrails,
• die Trennung zwischen Toolkit, KI-Client und menschlicher Verantwortung.