Module und Versionierung

Dinge sind so gebaut, dass man sie verschieben kann, dass sie eine Struktur haben und einfacher werden. Module, zusammengesteckt und woanders ergänzt, ergeben etwas Neues. Was in einem Projekt entsteht, fließt als Baustein zurück ins Ganze.

Ein Modul wie der Chat wird an einem Ort gebaut und überall eingebaut, wo es gebraucht wird. Wird es dort verbessert, verbessert es sich überall; niemand muss überall einzeln ran.

Jedes Modul hat Versionen, damit man zurückgehen und rekonstruieren kann, wenn etwas Gutes verloren ging. Jimmy kann sagen, welche Version er haben möchte.

Es gibt das Grundmodul – Gerüst, Basis, Plattform. Wer Grundsätzliches ändern will, tut es dort. Braucht eine Webseite oder ein anderer Zweck eine Anpassung, gibt es eine Abzweigung. So muss nichts neu und doppelt gebaut werden.

Zeigt sich, dass ein Teil eines Moduls woanders hilft, wird daraus ein eigenes Modul.

Module werden einmal gebaut und wiederverwendet. Sie werden besser oder verändert, aber nicht schlechter; ihre Grundfunktion steht nicht mehr in Frage. Updates verändern nicht, was schon gut war. Das gilt universell, im ganzen System.

Sagt Jimmy „hier etwas ändern“, wird nur das geändert; alles andere bleibt. Er muss sich nicht zehnmal im Kreis drehen, während anderswo neue Fehler entstehen.

Man macht eine Kopie, baut sie um und schaut; bricht etwas, springt man auf den letzten guten Stand zurück. „Das ist so simpel, wie es nur sein kann.“

Geht es mit einer Erweiterung nicht, dann über die Bedienung des Desktops; kann es ein Modell nicht, dann ein anderes; gibt es noch keinen Weg, wird recherchiert. Genommen wird, was vorhanden ist und funktioniert.

1. stabil funktionieren, 2. am Hauptort so benutzbar, wie Jimmy es braucht, 3. erst dann Optionen und Kombinierbarkeit. Lieber eine stabile Möglichkeit als viele halbe.

Module nutzen keine fest verdrahteten Pfade, wo es nicht nötig ist, damit ein Modul mit seinem Ordner auf ein anderes Gerät umziehen kann.

Vor jedem Bau wird nachgesehen, was es schon gibt; vorhandene Fähigkeiten werden genutzt und erweitert.

Strukturen werden erhalten und geschaffen, damit nicht an vielen Stellen gearbeitet wird. Manchmal wird gesplittet oder eine Variante gemacht, aber nicht immer alles neu.

Schreibt ein Modul eine E-Mail in Jimmys Schreibweise und er schickt sie ab, ist das ein Ergebnis. Dasselbe Modul kann woanders genutzt werden, etwa für Blogs.

Wie bei Software-Bausteinen, die über Updates in viele Apps gelangen: Bestimmte Dinge bleiben auf einer Ebene und werden nicht beliebig eingebaut.

Fällt ein Modul aus, laufen die anderen weiter. Ein eingebautes Modul verschwindet nicht, wenn man es entfernt, lässt sich aber nicht mehr zentral aktualisieren; dafür gibt es Kopie oder Variante. Raum Z4 mit Deck, Notizen und Leseraum ist das Sinnbild.

Eine oder zwei sinnvolle Apps, die innen einzelne Module miteinander verbinden.

Der Hauptchat ist kein Modul, sondern ein Bildschirm, der auf den Baum der Module zugreift. Wo er sitzt – Handy, Tablet, Rechner –, ist nicht wesentlich. Screen und Stimme bleiben vorerst die Eingänge.

Texte in Jimmys Art: Jede Variante liegt an einem Ort und ist danach abrufbar, in einer App, einem neuen Werkzeug oder der Medienpipeline.

Ein Recherche-Motor mit Voreinstellungen über den Connection Hub: ein Recherchedienst, solange Guthaben da ist, sonst ein zweiter Recherchedienst oder die Bedienung des Desktops. Fehlt Guthaben, greift die nächste Voreinstellung. Was verbessert werden soll, landet an diesem einen Ort.

Eine visuelle, aktualisierbare Landkarte der Module (zuerst als Fläche in der Werkbank, später räumlich mit Würfeln je Gerät) wird Jimmys Bezugspunkt; aus ihr wird der Text für die Sprachmodelle abgeleitet, nicht umgekehrt.

Ein Modul, das nicht mehr gebraucht wird, wird eingefroren und in der Ausmusterung vermerkt; gelöscht wird über den Papierkorb.