DE

// die plattform für entwicklung mit agenten · in entwicklung

Dein Vorhaben. Auf Kurs.

Kernonaut soll Produktziele, Agentenarbeit und Prüfergebnisse verbinden. Du siehst, was sich geändert hat, welche Arbeit betroffen ist und was für den aktuellen Stand noch bestätigt werden muss.

./vormerken./beispiel-ansehen
  • statusin entwicklung
  • corerust
  • zuerstlinux · windows
  • fürteams mit agenten
vorhaben  Rundenspiel mit eigener Engine
ziel      Runde unter 3 Minuten         v2
├─ auftrag   Spiel: Regeln, Balancing    betroffen
├─ auftrag   Engine: Rendering           gilt weiter
└─ nachweis  Spieltest 1                 neu prüfen

Ein Produkt entsteht über viele Entscheidungen

Du beginnst mit einer Idee, probierst etwas aus und lernst dazu. Mit jeder Erkenntnis verändert sich, was gebaut werden soll. Gleichzeitig arbeiten Menschen und Agenten an Code, Tests und Teilprodukten.

Kernonaut soll diese Arbeit am Vorhaben ausrichten. Ziele haben eine Geschichte, Aufträge beziehen sich auf einen bestimmten Stand, Ergebnisse zeigen, was geprüft wurde und was noch offen ist. Ändert sich die Richtung, wird sichtbar, welche Arbeit neu betrachtet werden muss.

Ein Beispiel: Die Runden sollen kürzer werden

  1. Ziel ändern. Ein Spiel und seine Engine werden getrennt geführt. Nach dem ersten Spieltest sollen die Runden kürzer werden. Die neue Zielversion wird sichtbar, alte Entscheidungen und Abnahmen bleiben lesbar.
  2. Auswirkung prüfen. Bekannte Abhängigkeiten zeigen, welche Arbeiten und Nachweise betroffen sind. Vermutete Auswirkungen werden zur Prüfung markiert.
  3. Arbeit fortsetzen. Ein Lauf endet an einem definierten Checkpoint. Ein anderer passender Worker übernimmt Arbeitsstand, Kontext und offene Schritte.
  4. Erneut abnehmen. Nachweise gehören zu einer konkreten Ziel-, Code- und Umgebungsversion. Ob das Spiel jetzt besser ist, entscheidest du.
ziel geändert  v1 → v2
betroffen      Regeln, Balancing
vermutet       Tutorial-Texte   prüfen
gilt weiter    Rendering Linux, Windows
→ nachweis fehlt: Spieltest 2

Worauf wir beim Bauen achten

  • Unsicherheit wird sichtbar

    Vermutete Auswirkungen sollen als solche erkennbar sein. Ein fehlender Link beweist keine Unabhängigkeit.

  • Tests sind nicht die Abnahme

    Technisch erfolgreiche Tests und die fachliche Abnahme deines Produkts bleiben getrennte Entscheidungen.

  • Du entscheidest

    Ziele, Fachentscheidungen und Freigaben gehören einer verantwortlichen Person. Kein Agent gibt sich selbst frei.

  • Klein anfangen

    Kernonaut soll mit wenig Modellierungsaufwand starten, damit das Modell weniger Pflege kostet, als es spart.

  • Worker mit Freigabe

    Eigene Rechner und Cloudworker sollen nur nach ausdrücklicher Freigabe für einen bestimmten Bereich arbeiten.

  • Auch für Mobil und Hardware

    Runner sollen auch mobile und eingebettete Ziele anbinden. Rechner, Zielplattform und Gerätefähigkeiten werden dafür getrennt beschrieben.

Stand heute

  1. Der Kern steht: ein getesteter Revisionskern in Rust mit lokaler SQLite-Persistenz und Kommandozeile. Produktdefinitionen, Produktstände sowie Ziel- und Auftragsrevisionen bleiben über Neustarts erhalten.
  2. Als Nächstes folgen Server, Oberfläche, Worker und die Prüfung von Identitäten und Befugnissen.
  3. Ausgeliefert werden soll ein Programm pro Plattform, mit Kontroll-, CLI- und Workermodus und ohne zusätzliche Pflichtdienste. Linux und Windows kommen zuerst, macOS später.
$ kernonaut demo --json
# synthetisches Beispiel, ohne Dateien, Aufträge oder Netzwerk

Zu den Ersten gehören?

Wir bauen Kernonaut für kleine professionelle Teams, die mehrere Agenten einsetzen, mit bestehenden Repositories arbeiten und ihre Anforderungen regelmäßig ändern. Merk dich vor, dann melden wir uns, sobald Teams Kernonaut ausprobieren können.

./vormerkencd ../fuer-entwickler