Zum Inhalt springen

Changelog

Jedes Release und was es für die Benutzer von Heinzel Pro ändert, das neueste zuerst. Was vor einem Upgrade zu tun ist, steht im Abschnitt der Version; das Kapitel Upgrade hält die Schritte älterer Versionen fest und den Weg eine Version zurück. Welche Version hier läuft, steht rechts unten auf jeder Seite.

2.72.0 (2026-10-25)

  • Das Changelog ist jetzt ein Kapitel der Dokumentation, unter /docs auf Deutsch und Englisch und vom ersten Release an: jede Version mit dem, was sie für die Benutzer von Heinzel Pro ändert. Die Version rechts unten auf jeder Seite führt dorthin.
  • In ein Major-Release gerät niemand mehr aus Versehen: Das Release merkt sich, welche Version auf der Datenbank lief, und ein neues Major startet nur auf einer Datenbank, auf der zuletzt das letzte Release des Majors davor lief; sonst sagt es das und hält an, bevor es etwas anfasst. Das Image trägt neben der Version die Tags seines Majors und Minors (2, 2.71), so dass HEINZEL_VERSION=2 jedes 2.x per docker compose pull nimmt und nie 3.0. Was ein Betreiber von Hand tut, steht in einem Kasten oben im Abschnitt des Majors im Changelog.

2.71.0 (2026-10-25)

  • Die Installationsanleitung sagt, dass nichts von Hand heruntergeladen wird, dass der Image-Name eine Adresse für Docker ist und keine Webseite, und wie Sie die aktuelle Version finden, bevor Sie sie in die .env schreiben.
  • Die Voraussetzungen der Installationsanleitung sind eine Checkliste mit einem Kästchen je Eintrag statt einer Tabelle; eine Aufgabenliste liest sich jetzt in jedem Kapitel so.
  • Ein fünftes Kochrezept in der Dokumentation: Ollama jede Woche per Zeitplan aktualisiert statt per Cronjob, mit den Prüfungen danach und dem Weg zurück in der Aufgabe.
  • Die Dokumentation hat einen Abschnitt Kochrezepte: ein Kapitel je Fall aus dem Alltag der Beispiel GmbH, das erst das Problem nennt und dann Schritt für Schritt die Lösung. Er ersetzt das Kapitel Beispiele, dessen Adresse zu den Rezepten führt.

2.70.1 (2026-10-25)

  • Jeder Befehl, der in eine Shell gehört, beginnt in der Dokumentation mit $, auch in den Kapiteln API, Administration und Lizenzen, damit sich ein Befehl vom Inhalt einer Datei und von der Ausgabe eines Befehls abhebt.
  • Die Installationsanleitung wurde auf einem echten Host durchgespielt und dort korrigiert, wo sie scheiterte: Das nächtliche Backup-Skript beginnt jetzt mit seiner Zeile #!/bin/sh, damit cron es ausführt; Postfix auf dem Docker-Host bekommt ein festes Compose-Netz und eine Firewall-Regel; nginx hört auf IPv6 und holt sein Zertifikat von certbot; Ollama braucht OLLAMA_CONTEXT_LENGTH. Ein neuer Abschnitt unter Betrieb entfernt Heinzel Pro wieder. Das Protokoll der Installation sagt auf Deutsch, dass Mail „eingerichtet“ ist statt „einrichten“, und nennt die Annahme der Nutzungsbedingungen in der Sprache des Lesers.

2.70.0 (2026-10-25)

  • Die Kapitel Rechte, Sessions und Server der Dokumentation unter /docs beschreiben die Matrix der Richtlinie: Was eine Klasse auf jeder Stufe tut, ist eine Tabelle unter Einstellungen, Richtlinie, ein Server stellt eine Zelle nur strenger, und eine Sperrregel kann einen Befehl in eine höhere Klasse heben. Der Screenshot der Richtlinien-Seite zeigt die Matrix, und das Recht „die zweite Freigabe geben“ sagt, dass es überall gilt, wo die Matrix zwei Personen verlangt, nicht nur bei unumkehrbaren Befehlen.
  • Die vier Beispiele der Beispiel GmbH (Backup-Alarm, Sicherheitsupdates jede Nacht, ein Befund wird behoben, php2shell auf 13 Servern) sind jetzt ein Kapitel der Dokumentation, unter /docs gleich nach den ersten Schritten, mit jedem Screenshot; heinzel-pro.de führt sie nicht mehr. Die Übersicht sagt in einer Zeile, dass die Dokumentation alles an der fiktiven Beispiel GmbH erklärt.

2.69.0 (2026-10-25)

  • Die Dokumentation ist jetzt Teil jeder Installation, unter /docs und in der Navigation unter Nachschlagen, lesbar ohne Konto und ohne Weg ins Internet: eine Übersicht und acht Kapitel auf Deutsch und Englisch, von der ersten Anmeldung bis zu Installation, Upgrade und Betrieb, mit Screenshots der Anwendung und einem Beispiel zu jedem Schritt, und die Referenzen daneben.
  • Was ein Befehl jeder Klasse auf jeder Stufe tut, ist jetzt eine Tabelle unter Einstellungen, Richtlinie: läuft sofort, wartet auf eine Person, auf zwei, oder läuft nie; das Formular eines Servers stellt eine Zelle für diesen Server allein strenger. Aus dem Vier-Augen-Schalter wurden die zwei Zeilen, für die er stand. Eine Sperrregel kann einen Befehl in eine höhere Klasse heben, statt ihn zu sperren („zählt als“).
  • Die Session-Seite, die Übersicht und die Server-Seite lesen weit weniger aus der Datenbank, während ein Agent arbeitet: Ein Broadcast erneuert nur den Teil, den er nennt, ein Schwall davon kostet ein Nachladen, und die Zeitpläne-Seite fragt nur nach Läufen, solange einer unterwegs ist. Die Listen der Sessions, Server und Zeitpläne teilen sich eine Leiste für Filter und Sortierung, und die beiden „Sind Sie sicher“-Dialoge sehen gleich aus.

2.68.2 (2026-10-24)

  • Die öffentliche Demo unter /demo ist wieder weg, mit ihren simulierten Servern und Link-Mails.

2.68.1 (2026-10-24)

  • Eine Demo-Session darf jetzt Hosts jenseits ihres gespielten Servers nennen, etwa einen Zeitserver oder einen Paketspiegel (sie werden ebenfalls gespielt), damit sich die Backup- und die Update-Jobs beheben lassen; der gespielte Host behält eine Uhr, und die Demo beginnt auf rwx, wenn der Besucher nicht rw wählt.

2.68.0 (2026-10-24)

  • Die Mail mit dem Link in die Demo sagt jetzt, dass das Transkript am Ende an Sie gemailt wird, und spricht von älteren statt von alten Modellen.
  • Die Startseite der Demo ist jetzt eine Auswahl: „Wählen Sie eine Demo-Session“, die zwei Stufen als Karten mit Symbol, die sieben Server als Kacheln mit ihrem System, und die Aufgabe des gewählten Jobs in einem Feld, das der Besucher ändern kann, bevor es losgeht. Auf einer Session-Seite steht die Regelzeile für sich über den Knöpfen statt zwischen ihnen.

2.67.0 (2026-10-24)

  • Die Mail mit dem Link in die Demo sagt jetzt in ein paar schlichten Zeilen, was die Demo ist, an wen man Fragen schreibt und dass ein Transkript aufbewahrt wird.
  • Eine Session, deren Aufgabe erledigt, deren Zusammenfassung geschrieben und in der seither nichts gefragt wurde, schließt sich nach drei ruhigen Stunden von selbst statt nach den vollen Stunden des Mandanten; eine weitere Anfrage in dieser Zeit hält sie offen.
  • In der Demo wählt ein Besucher jetzt, ob Heinzel vor jeder Änderung fragt (rw) oder allein ändert (rwx), beides in schlichten Worten erklärt, und sucht aus sieben Problemservern statt aus drei: eine volle Platte auf Rocky Linux, eine Datenbank auf FreeBSD, die nach einem Neustart nicht wiederkam, ein Zertifikat auf einem Debian-Proxy, das sich nicht mehr erneuert, und ein Mac mini, dessen Builds seit dem Xcode-Update fehlschlagen.
  • Das Transkript einer Demo geht jetzt an den Besucher, gezeichnet wie die Session-Seite, mit einer Kopie an den Betreiber; die Demo-Seite sagt das dort, wo die Adresse eingegeben wird, und die Adresse wird gelöscht, sobald das Transkript hinaus ist.
  • Das Menü „Mehr“ einer Session führt seine Aktionen als ruhige Zeilen, fasst die zwei Downloads zusammen und setzt „Session schließen“ ab; lange Beschriftungen brechen nicht mehr in zentrierte Zeilen um.

2.66.0 (2026-10-24)

  • Eine öffentliche Demo unter /demo: Ein Besucher fordert mit einer Mailadresse einen Link an, die gelöscht wird, sobald der Link benutzt ist, und gibt dem echten Agenten einen von drei vorbereiteten Jobs auf drei simulierten Problemservern, fünfzehn Minuten lang, mit Freigaben, Plan und Audit-Protokoll wie in Produktion. Das Transkript geht an die Adresse in DEMO_REPORT_TO; mix heinzel.demo.setup legt den Mandanten und seine Server an.

2.65.0 (2026-10-23)

  • Die Anzeige des Platzes und die Zusammenfassung einer langen Session arbeiten jetzt mit jedem Modell: Ein OpenAI-kompatibles Modell wird in schlichten Worten um die Zusammenfassung gebeten, das Kontextfenster eines Modells lässt sich auf seiner Seite eintragen, wo der Katalog es nicht kennt, und eine Session, deren Modellfenster selbst für die Zusammenfassung zu klein ist, sagt das.
  • Die Session-Seite zeigt, wie viel vom Platz des Modells eine Session verbraucht hat, und eine Session, die darüber hinauswächst, macht mit einer Zusammenfassung weiter: Anthropic fasst die Nachrichten vor der letzten Antwort des Modells zusammen, die Seite sagt das und zeigt, was das Modell stattdessen liest. In der Session bleibt alles in voller Länge erhalten.

2.64.0 (2026-10-23)

  • Ein Befehl in der Form command rm …, wie Heinzels Regeln cp, mv und rm schreiben, um einen Alias zu umgehen, wird jetzt nach dem beurteilt, was hinter command steht. Bisher verdeckte das Wort es: command rm -rf / war ein gewöhnlicher Schreibbefehl statt gesperrt, und ein Neustart oder ein neues Dateisystem dahinter fragte wie jede Änderung. command -v zählt als Lesen.
  • Nutzungsbedingungen. Heinzel ist ein KI-Agent und kann sich irren; die Bedingungen sagen das, legen Backups und Freigaben in die Hand des Kunden und begrenzen die Haftung. Jede Person nimmt sie auf der nächsten Seite an, die sie öffnet, und ein Administrator nimmt sie einmal für den Kunden an und sagt dabei, ob es ein Unternehmen, eine Organisation oder eine Privatperson ist. Bis dahin warten die Seiten, und die API antwortet mit
    1. Jede Zustimmung wird mit ihrer Version und dem gezeigten Text aufbewahrt. Eine Zeile unter jedem Aufgabenfeld und ein Hinweis auf der Zugriffsseite sagen, dass Heinzel Fehler machen kann.
  • Die Klasse der Befehle, die Daten löschen, Zugangsdaten rotieren oder eine Partitionstabelle schreiben, heißt auf Deutsch jetzt „unumkehrbar“, nicht mehr „zerstörerisch“. Das alte Wort urteilte über den Befehl, und niemand will ein Werkzeug, das Dinge kaputt macht; das neue sagt, warum zwei Personen darauf sehen: Es lässt sich nicht rückgängig machen. Englisch bleibt bei „destructive“.

2.63.0 (2026-10-21)

  • Die Seite Geheimnisse zeigt, wie eine Aufgabe ein Geheimnis nennt: die Aufgabe, wie eine Person sie schreibt, der Befehl, den Heinzel daraus macht, mit der Variablen darin, und ein Knopf, der eine Session mit dieser Aufgabe startet, sobald das genannte Geheimnis hinterlegt ist. Die Seite API-Tokens zeigt ein Shell-Beispiel gegen die eigene Adresse dieses Mandanten und einen seiner Server: das Token aus einer Datei, die Server aufgelistet, eine Session gestartet.
  • Die Liste der Sessions sucht, filtert, sortiert und blättert jetzt: Ein Suchfeld findet eine Session über ein Wort ihrer Aufgabe, ihres Servers, ihrer Person oder ihres Modells, ein Schalter zeigt alle Sessions, die, die Sie brauchen, die laufenden, Ihre eigenen oder die geschlossenen, jede mit ihrer Zahl, und die Reihenfolge kann sein, was Sie braucht (wie bisher), die letzte Änderung, die Aufgabe, der Server, die Person oder die Kosten, in beide Richtungen. Fünfundzwanzig Sessions füllen eine Seite, und jede Session ist erreichbar: Bisher endete die Liste bei den neuesten hundert.

2.62.1 (2026-10-21)

  • Die Anfragen einer Session an Anthropic bleiben jetzt die ganze Session über im Cache des Modells: Die Notizen des Hosts in den Anweisungen ändern sich zwischen den Schritten nicht mehr, alte Ausgabe wird nicht mehr mitten im Gesprächsverlauf gekürzt, und während ein Befehl auf eine Person wartet oder lange auf dem Host läuft, wird der Cache alle vier Minuten warm gehalten, bis zu einer Stunde. Schritte nach einer Änderung an Gedächtnis oder To-do, nach Nachricht 40 und nach einer Wartezeit von mehr als fünf Minuten wurden bisher voll bezahlt; jetzt lesen sie aus dem Cache.
  • Ein Neustart, der nicht wiederkommt, wird jetzt diagnostiziert statt beobachtet: Die Regeln sagen, zu lesen, wo er stehen blieb (die Konsole, dann das Journal des beendeten Boots), und dem Benutzer zu sagen, was der nächste Neustart braucht. Sie nennen auch die Falle dahinter auf einer ARM64-VM unter QEMU mit Apples Hypervisor (UTM): Ein Neustart aus Linux hängt in den ersten Zeilen des nächsten Kernels, weil die übrigen CPUs nie zurückgesetzt werden. Sie vorher offline zu nehmen, von Hand oder über eine Shutdown-Unit, die die Regeln mitgeben, lässt den Neustart durch.

2.62.0 (2026-10-21)

  • Die alte Adresse eines Mandanten funktioniert weiter, nachdem sein Kurzname geändert wurde: Lesezeichen, Links in früher verschickten Mails, die API und eingehende Alarme führen zur neuen weiter, und ein früherer Kurzname bleibt dem Mandanten vorbehalten. Die Einstellungen führen die früheren Namen unter der Adresse auf.
  • Der Kasten unter einem laufenden Befehl heißt jetzt „Live-Ausgabe, letzte Zeilen“ (englisch „Live output, last lines“) statt „Letzte Zeilen, wie sie kommen“.
  • Ein neues Linux, das Heinzel installiert, liegt auf LVM, ein neues FreeBSD auf ZFS, wenn Sie nichts anderes wollen: Root und Swap als logische Volumes, der Rest der Platte bleibt frei, damit eine Partition später ohne Ausfall wächst und das nächste Upgrade einen Snapshot als Weg zurück hat. Vor dem ersten Neustart prüft Heinzel, dass lvm2, der initramfs-Hook und der Boot-Eintrag da sind; ein Cloud-Image wird in das Volume kopiert, nicht als Ganzes geschrieben.
  • Wenn Heinzel ein neues Betriebssystem installiert, sucht es auf jedem OS das kleinste Medium, das das Projekt veröffentlicht und das bootet: ein Bootstrap-Werkzeug vor dem reinen Installer, der vor einem Cloud-Image, nie eine DVD oder ein Live-Image. Es installiert die minimale Variante des Systems, prüft vor dem Schreiben, dass Kernel, Bootloader, SSH, Netz und Paketmanager da sind, installiert alles Weitere danach über das Netz und löscht das Medium, sobald das neue System bootet.

2.61.0 (2026-10-21)

  • Ein laufender Befehl zeigt seinen dunklen Ausgabekasten erst, wenn der Server etwas geschrieben hat, nicht einen leeren mit Platzhalter.
  • Ein Modell, das sein Hersteller abschaltet, wird angekündigt, bevor es ausfällt: Der Katalog trägt die Termine, das Modell ist unter Modellanbieter und auf der Übersicht mit dem Tag und seinem Nachfolger markiert, ein Klick stellt es um, während Zugriff, Bindungen und Standard bleiben, ein Alarm geht in drei Stufen hinaus, und eine Session, die auf ein abgeschaltetes Modell trifft, sagt, was zu tun ist.
  • Was eine andere Session auf einem Host geändert hat, steht einem Befehl fünf Minuten im Weg statt fünfzehn, und eine Person kann eine Session trotzdem laufen lassen: Der Knopf unter dem Hinweis gibt den Befehl frei, und die Session wartet bis zu ihrem Schließen auf niemandes Arbeit mehr.
  • route -n show, route get und ein bloßes route zählen wieder als Lesen. Bis jetzt wurde eine Bestandsaufnahme, die die Routing-Tabelle ausgab, als Firewall-Änderung für eine Person zurückgehalten und stand jeder anderen Session auf dem Host im Weg.

2.60.0 (2026-10-21)

  • Ein Administrator kann im Formular eines Benutzers das Modell nennen, auf dem die Sessions dieser Person beginnen; es geht den Teams der Person vor, und die Seite des Modells führt die Personen auf, die darauf stehen.
  • Ein Modell lässt sich vorschreiben statt wählen: Ein Administrator bindet einen Server oder eine Servergruppe in ihrem Formular an ein Modell, so dass jede Session darauf dort läuft und kein Ersatzmodell nimmt; ein Team nennt das Modell, auf dem seine Sessions beginnen; und die Richtlinie kann die Wahl ganz aus dem Session-Formular nehmen. Das Session-Formular sagt, welches Modell gilt und wo das eingestellt ist, und die Seite des Modells führt auf, wo es vorgeschrieben ist.
  • Eine Session auf einem Anthropic-Modell kostet weniger: Der Anbieter behält die Anweisungen und den Verlauf der Session zwischen den Schritten in seinem Cache, so dass ein Schritt für das Neue zahlt statt für alles noch einmal. Was sich von Schritt zu Schritt ändert, etwa das Gedächtnis des Hosts, wird getrennt vom Gleichbleibenden geschickt, und alte Ausgabe wird in Blöcken von zwanzig Nachrichten gekürzt statt einzeln, damit der Cache hält. Der Schalter steht unter Einstellungen, Sessions, anfangs an.

2.59.0 (2026-10-20)

  • Server hinzufügen stellt drei Fragen: wo Heinzel ihn findet, als wer es sich anmeldet und was irgendjemand dort höchstens darf. Gruppen, weitere Adressen, der Takt der Aktualisierung, abgeschaltete Fähigkeiten, das Teilen von Sessions, Übergabenotizen und der Fingerabdruck des Host-Keys sind ins Bearbeitungsformular des Servers gewandert, das jetzt in Abschnitte geteilt ist. Ob Heinzel direkt, über ein VPN oder über einen Sprungserver geht, ist eine Wahl aus dreien. Mit einem VPN sagt das Formular, welche Adresse es will, und trägt die ein, die es kennt; ohne Verbindung führt es zum Einrichten einer, deren Seite zurückführt. Die Übergabenotizen zeigen ihr Beispiel wie ein Terminal.

2.58.1 (2026-10-19)

  • Ein Server, der sich über seine eigene VPN-Verbindung bei Heinzel meldet, wird erreicht, mit welcher Adresse er auch eingetragen wurde, etwa seiner Adresse im Heimnetz. Heinzel geht von selbst an sein Ende des Tunnels; der Host-Key bestätigt weiterhin, dass es dieselbe Maschine ist.

2.58.0 (2026-10-19)

  • Wenn Heinzel ein Betriebssystem ersetzt, macht es das neue zum Standard der Firmware und startet einmal ohne One-Shot neu, bevor es das alte formatiert. Bisher galt ein neues System, das einmal über BootNext gebootet hatte, als bestätigt, und der nächste gewöhnliche Neustart ging zum alten Loader, der nichts mehr zu starten fand.
  • Eine ruhende Session wird mit einem Knopf neben „Senden“ am Ende des Verlaufs geschlossen, nicht nur aus dem Menü oben. Ein Befehl, den ein Stopp übersprungen hat, sagt das in der Sprache des Lesers statt „the session was stopped“.
  • Wartet ein Befehl, weil eine andere Ihrer eigenen Sessions auf demselben Server arbeitet, sagt die Karte das, verlinkt diese Session und erklärt, dass diese Session wieder allein entscheidet, sobald jene gestoppt oder geschlossen ist.
  • Während ein Befehl läuft, zeigt die Ecke seiner Karte, wie ausgelastet der Server ist: fünf kleine Balken und die Last in Prozent, blau im Leerlauf, grün bei Arbeit, gelb ab 70 % und rot, wenn Arbeit wartet.
  • Ein laufender Befehl zeigt, wie lange er schon läuft, und seine letzten drei Ausgabezeilen, wie sie kommen. Einer, der mehr Zeit als üblich angefragt hat, bekommt dazu einen Balken bis zu seinem Zeitlimit. Die Zeile unter dem Verlauf nennt den Server, auf den Heinzel wartet, und führt zum Befehl. All das verschwindet, sobald der Befehl beendet ist.
  • Wo eine Antwort von Heinzel eine Seite der Einstellungen nennt, etwa „Einstellungen → Richtlinie“, sind diese Worte ein Link auf die Seite.
  • Das Image trägt Heinzels Regeln 3.3.1: die NetBSD-Regel, eine Änderung auf Probe, die zum Standard wird, bevor der alte Zustand geht, und keine größere Platte beim Anbieter, wenn Sie nicht darum bitten. Die Regeln-Seite führt NetBSD unter den Systemen auf.
  • Auf NetBSD fragt eine Session auf „Ändert allein“ nicht mehr vor jedem Befehl. export PATH=/sbin:/usr/sbin:/usr/pkg/sbin:$PATH, womit dort jeder Befehl beginnt, galt als unbekannte Änderung und kollidierte so mit jeder anderen Session auf dem Host; jetzt zählt es als Lesen, ebenso dkctl listwedges, swapctl -l, modstat, pkg_info und pkgin avail.
  • Wenn Heinzel ein Betriebssystem ersetzt, sichert es das alte als Dateien, solange es noch läuft, mit dessen eigenen Werkzeugen und ohne die Build-Images der Migration, und nie nach /boot. Ein rohes dd-Image bleibt für den Fall, dass nichts mehr das alte Dateisystem liest, und sobald das neue System bestätigt ist, fragt Heinzel vor einem langen Backup, das nur zum alten zurückführt.
  • Wenn Heinzel ein Betriebssystem ersetzt, wägt es zuerst jeden Weg ab, Platz für das neue zu schaffen: freier Platz auf der Platte oder in einer Volume Group, ein Dateisystem verkleinern, das sich verkleinern lässt, große Verzeichnisse auf ein Dateisystem mit Platz verschieben, ein kleines Rettungssystem auf der Swap-Partition, von dem aus sich das laufende Root verkleinern lässt, und erst dann das Staging im Swap. Seine Bestandsaufnahme hält Volume-Manager, RAID und Verschlüsselung fest. Es vergrößert die Platte nie beim Anbieter oder im Hypervisor und schlägt das auch nicht vor, wenn Sie es nicht ansprechen.
  • Die Regeln für OS-Austausch, Partitionieren, Cloud-Images und den FreeBSD-Loader sagen Heinzel nicht mehr, dass eine Person jeden unumkehrbaren Befehl liest. In einer Session, die allein ändert (rwx), wartet keiner, also behandelt Heinzel seinen Plan und den Weg zurück als die einzige Prüfung.
  • Die VPN-Seite hat einen eigenen Block für NetBSD, das WireGuard im Kernel hat, aber kein wg-quick: Er schreibt /etc/ifconfig.wg0, lädt das Modul beim nächsten Boot und hält den Tunnel mit einem Ping offen, weil NetBSD kein PersistentKeepalive kennt. Die npf-Regel für SSH steht daneben.
  • Ein Server, der über eine VPN-Verbindung erreicht wird, lässt sich nicht mehr mit einer Adresse speichern, die die Verbindung nicht trägt, etwa der eigenen Adresse der Maschine in ihrem Heimnetz. Das Formular nennt die Adresse, die funktioniert, statt dass der Verbindungstest nur sagt, der Host habe nicht geantwortet.

2.57.1 (2026-10-19)

  • Eine private Adresse im Server-Formular bekommt auf einer gehosteten Installation kein bloßes „diese Installation verbindet sich nicht mit dieser Adresse“ mehr: Die Meldung sagt, unter „Erreichbar über“ eine VPN-Verbindung oder einen Bastion-Host zu wählen.

2.57.0 (2026-10-18)

  • Ein Modellanbieter kann in Ihrem eigenen Netz stehen: Unter „Erreichbar über“ wählen Sie eine Ihrer VPN-Verbindungen oder einen Ihrer Server, und Heinzel Pro ruft ihn dort an, etwa LM Studio auf einem Laptop in Ihrem Tailnet oder ein Ollama, das nur auf dem localhost eines GPU-Servers hört. Auf der gehosteten Installation darf der Administrator eines Mandanten eine solche Adresse setzen.
  • Die Anmeldeseite schaltet zwischen Passwort und Anmeldelink um, statt den Link hinter „Passwort vergessen?“ zu verstecken. Wer sich angemeldet noch einmal anmeldet, erfährt die Adresse, an die der Link ging. Die Rolle in der Seitenleiste und die Übersicht nennen den Mandanten, und Tastenkürzel lauten auf einem Mac ⌘.

2.56.0 (2026-10-18)

  • „Neue Session“ fragt zuerst, wo Heinzel arbeitet: auf einem Server, auf mehreren zusammen in einer Session, oder dasselbe auf vielen parallel. Server sind eine Liste mit einem Auswahlpunkt, jede Stufe sagt in einem Satz, was sie bedeutet, und das Aufgabenfeld ist eine Zeile höher.
  • Auf „Neue Session“ wird der Zugang, den ein Server anbietet („als root“, „als stefan“), in der Zeile des Servers gewählt statt in einer Zeile unter der Liste.

2.55.0 (2026-10-18)

  • Die Seite eines Servers beginnt mit „Arbeiten auf …“: eine Zeile je Zugang mit einer Session als dieser Zugang und „Zugang hinzufügen“ gleich darunter. Das Gedächtnis ist auf eine eigene Seite gezogen; die Seite des Servers behält die offenen To-dos und das, was sich geändert hat.

2.54.1 (2026-10-18)

  • Freigaben stehen unter ihrer Session: die Aufgabe einmal, ihre Befehle darunter, und ein Knopf für alle, wo keiner eine zweite Person braucht. Was über den Host bekannt ist, klappt sich hinter „Über diesen Host“ ein, außer sein letzter Lauf ist fehlgeschlagen oder seine Notizen haben etwas zu sagen.

2.54.0 (2026-10-18)

  • Sessions, Freigaben, Befunde, Server, Zeitpläne und Regeln erklären ihr Wort in einem Satz unter dem Titel, bis Sie „Verstanden“ drücken; die neue Seite Begriffe unter Nachschlagen behält jeden Satz, dazu Gedächtnis, Journal, Übergabe, Deckel, Team und Servergruppe.
  • Die Übersicht begrüßt einen neuen Mandanten mit dem, was Heinzel Pro ist, und vier Schritten bis zur ersten Session, jeder mit dem Knopf, der ihn erledigt: ein Modell anschließen, einen Server anlegen, den Schlüssel dort hinterlegen (die Server-Seite zeigt jetzt den einen Befehl, der dort auszuführen ist), Heinzel ihn in einer lesenden Session kennenlernen lassen. Eine Session, die am Modellanbieter gescheitert ist, führt Administratoren zur Einstellung; ein Server, den Heinzel nie erreicht hat, bietet keine Session an, bis es ihn erreicht.
  • Rechte lesen sich zuerst als Worte: „liest nur“, „fragt vor Änderungen“, „ändert allein“, mit r--, rw- und rwx daneben; der Deckel heißt auf Deutsch „Obergrenze“. Der Untertitel jeder Hauptseite sagt, was Sie dort tun, aus „Braucht dich“ auf der Übersicht wurde „Wartet auf Sie“, und ein Host heißt überall Server.

2.53.0 (2026-10-18)

  • Eine Boot-Änderung hat ihren Weg zurück vor dem ersten Neustart: Der Agent bootet den neuen Kernel, Eintrag oder die Loader-Einstellung einmal (BootNext, grub-reboot, bootctl set-oneshot, nextboot) und macht sie erst zum Standard, nachdem ein Login hinein gelungen ist. Er nennt, was den zweiten Boot auslöst, wenn das neue System hängt, und bewahrt vor dem Schreiben eines MBR oder Bootsektors die alten Sektoren außerhalb des Hosts auf und prüft, dass das Rettungssystem erreichbar ist. Das Image trägt Heinzels Regeln 3.2.1, mit den neuen Regeln zum Weg zurück und zum Rollback-Timer, die der Regelbrowser unter Sicherheit und Änderungen machen einordnet.
  • Das Stoppen eines Rollback-Timers von Heinzel geht über einen neuen Login hinaus statt über die offene Verbindung, die eine Firewall überlebt, die neue Logins schon abweist. Scheitert dieser Login, scheitert der Stopp mit ihm, und der Server nimmt die Änderung selbst zurück. Auf rwx entscheidet Heinzel den Stopp allein. Nachdem es die IP-Adresse eines Servers geändert hat, folgt Heinzel dem Server von selbst dorthin, sobald die neue Adresse den festgehaltenen Host-Key zeigt; niemand muss sie ins Formular eintragen. Ein Server, der unter einem Namen geführt wird, folgt seinem DNS, und die Session sagt das auf dem Befehl, der den Timer stellt, und auf einem gescheiterten Stopp, damit niemand vergisst, den DNS zuerst auf die neue Adresse zu zeigen.
  • Eine Session auf rwx wartet nicht mehr auf die Freigabe eines Plans: Wo Heinzel auf jedem Server des Plans allein ändert, wird der Plan gezeigt, im Änderungsnachweis festgehalten, und die Arbeit geht weiter. Ein so freigegebener Plan steht für niemanden, also fragt ein Befehl, der eine Person fragen würde, weiterhin.

2.52.0 (2026-10-18)

  • Wer was darf, ist jetzt eine Regel: der höchste Zugriff der Teams einer Person auf die Gruppen, in denen ein Server ist, nie über einen Deckel. Teams und Servergruppen sind flach und haben Verwalter, die Personen und Server hinein- und herausnehmen und Zugriffe vergeben; die Besitzerzeile eines Servers wird sein Deckel, das „alle auf allen Servern“ des Mandanten eine Grundregel; ein Zugang nennt, wer ihn nutzen darf. Die neue Seite „Wer darf was“ unter Gruppen erklärt Server für Server, was eine Person hat und warum.
  • Der Import eines Servers, dessen Benutzer kein Unix-Benutzername ist, etwa Admin@web4, meldet diese Zeile, statt den ganzen Import abzubrechen, und eine anders geschriebene IPv6-Adresse wird als Server erkannt, den Sie schon haben.
  • Seit 2.51.1 geht ein Rollback höchstens bis 2.51.0 zurück: Die eigenen Benutzerspalten des Servers sind weg, und ihre Migration lässt sich jetzt nicht mehr rückgängig machen, statt sie auf jedem Server als root mit sudo zurückzubringen. Die Upgrade-Hinweise sagen das.
  • Ein Zeitplan, der alle Server in einer Session ausführt, lässt einen Server ohne seinen Benutzer aus, wie die Dokumentation sagt, statt den ganzen Lauf zu verweigern.

2.51.1 (2026-10-17)

  • Für die Menschen, die es benutzen, ändert sich nichts; nur das Innere.

2.51.0 (2026-10-17)

  • Ein Zeitplan und ein Rollout sagen, als welcher Benutzer sie sich auf jedem ihrer Server anmelden, und ein Zugang bekommt eigene Ausnahmen: Eine Gruppe darf dort mehr als alle anderen, nie mehr als die Besitzer-Buchstaben des Zugangs.

2.50.0 (2026-10-17)

  • „Änderungsprotokoll“ im Menü der Session heißt jetzt „Download Änderungsprotokoll“, und die deutschen Seiten sagen überall „Änderungsprotokoll“ statt manchmal „Änderungsnachweis“.
  • „Neue Session zum Beheben öffnen“ an einem Befund öffnet die gewohnte Seite für eine neue Session, mit Server und Aufgabe des Befunds ausgefüllt, so dass Stufe (r--, rw-, rwx), Modell und die Reichweite zu anderen Hosts wie bei jeder Session gewählt werden. Die Aufgabe steht jetzt in Ihrer Sprache.
  • „Wissen“ heißt jetzt „Hauswissen“ und steht unter Regeln, neben dem Regelwerk und Ihren eigenen Regeln. Jede der drei Seiten zeigt, unter einer Zeile eingeklappt, was eine Session in welcher Reihenfolge liest und was was ändern darf.
  • Strg+S (Cmd+S auf dem Mac) öffnet „Neue Session“ von jeder Seite aus, außer Sie tippen gerade in ein Feld oder ein Dialog ist offen. Der Knopf zeigt die Taste.
  • Ein Server kann mehrere Zugänge haben, etwa root und stefan, jeder mit Buchstaben, die die des Servers einengen. Einem Benutzer außer root lässt sich sudo verwehren: Heinzel lehnt dann jeden Befehl mit sudo, su, doas, pkexec oder run0 ab. Eine neue Session fragt, als welcher Zugang sie arbeitet, und nur wer als dieser Zugang arbeiten darf, gibt ihre Befehle frei.
  • Eine Session, die aus einem Befund geöffnet wurde, schließt ihn, sobald Heinzel ihn behoben hat und nicht mehr findet. Bisher blieb der Befund offen bis zum nächsten Lauf seines Zeitplans.
  • „Störungsbericht (Entwurf)“ im Menü der Session heißt jetzt „Download Störungsbericht (Entwurf)“ und sagt damit, was Sie bekommen.
  • Die Seite „Aufgaben“ und ihr Eintrag in der Seitenleiste sind weg; gespeicherte Prompts mit Lücken hat noch niemand benutzt. Sessions, die aus einer gestartet wurden, bleiben, wie sie sind.

2.49.0 (2026-10-17)

  • Ein Befund hat jetzt zwei Knöpfe: „Neue Session zum Beheben öffnen“ und „Schließen“. Schließen fragt, ob wieder erinnert werden soll: Ein ohne Erinnerung geschlossener Befund, etwa ein absichtlich geöffneter Port, wird nicht mehr gemeldet, außer eine Prüfung findet ihn schlimmer vor, wartet in einem eigenen Reiter, und „Wieder erinnern“ holt ihn zurück. „Ich kümmere mich“ ist weg.

2.48.1 (2026-10-17)

  • Die Knöpfe eines Befunds sagen, was sie tun: „Mit Heinzel beheben“ öffnet die Aufgabe für eine neue Session, „Ich kümmere mich“ sagt es Ihren Kollegen und ändert nichts auf dem Server. Beim Darüberfahren wird beides erklärt.
  • Heinzel schreibt Befunde, Nachrichten und Berichte für Menschen, die keine Administratoren sind: zuerst, was es bedeutet, dann die technischen Fakten, mit Begriffen wie 0.0.0.0 beim ersten Mal erklärt. Der Vorschlag eines Befunds erscheint als gewöhnlicher Text statt als Code. Offene Befunde bekommen die neue Fassung beim nächsten Lauf ihrer Prüfung.

2.48.0 (2026-10-17)

  • Eine Session und ein Zeitplan dürfen wieder Hosts jenseits Ihrer Server erreichen, etwa api.github.com für ein Ollama-Update: ein Schalter dort, wo sie gestartet werden, anfangs an und als Ihre Wahl für die nächste gemerkt. Ihre anderen Server bleiben so oder so zu; ohne den Haken erreicht die Session nichts jenseits ihrer eigenen Server. curl -o und wget -o gelten nicht mehr als Umleiten der Verbindung.
  • Nachrichten, Befehle und Pläne einer Session nehmen Reaktionen und Kommentare an, wie auf GitHub: die acht Emoji von dort, und Kommentare in Markdown mit Vorschau. Jeder, der die Session lesen darf, reagiert und kommentiert, ab r--, auch nach dem Schließen; ein Link ohne Konto liest die Session nur. Eigene Kommentare bearbeitet und löscht man selbst, ein Administrator löscht jeden. Heinzel liest sie nie. Jede Antwort von Heinzel nennt das Modell, das sie geschrieben hat.
  • Was Heinzel zwischen zwei Befehlen notiert und nachschlägt, nimmt in der Session eine Zeile ein: Sie nennt die Arten der Schritte und ihre Zahl und klappt auf zu einer Zeile je Schritt mit dem Ergebnis darin. Notizen zu einem Host und angekündigte Änderungen stehen jetzt in Worten statt unter ihren internen Namen.
  • Ein Server, der seinen Host-Key zeigt und die Anmeldung dann nie abschließt, bekommt nicht mehr die Firewall in die Schuhe geschoben: Die Meldung nennt Tailscale SSH im Modus „check“ und wie man es abschaltet oder Heinzel Pro hineinlässt.

2.47.0 (2026-10-16)

  • „Gegenzeichnen“ erscheint im Menü nur, wenn der Mandant es in seiner Freigaberichtlinie eingeschaltet hat.
  • Eine Session wechselt den Besitzer nur, wenn ihr Besitzer sie abgibt: im Teilen-Bereich der Session, an jemanden, mit dem sie namentlich zum Schreiben geteilt ist. Ein Administrator schaltet das unter Einstellungen, Richtlinie, Sessions ein, und ein Server kann es für seine Sessions verbieten. Niemand übernimmt mehr eine Session für sich. Das Protokoll der Session zeigt, wer sie bis wann besaß und wer sie abgegeben hat, das Audit-Protokoll ebenso.
  • Eine Session wird geteilt, während sie läuft, und nur so weit, wie der Mandant es erlaubt. Ein Administrator stellt das unter Einstellungen, Richtlinie, Sessions ein (---, r--, rw-, rwx), und ein Server kann in seinem Formular weniger erlauben. Eine neue Session ist privat; ihr Besitzer teilt sie aus der Session heraus mit allen, einer Gruppe oder einer Person und nimmt jede davon dort wieder zurück. Die Session führt ein Protokoll, wer wann was geteilt und wer es beendet hat, und ihr Kopf nennt, mit wem sie geteilt ist und wer sie gerade offen hat. Nur der Besitzer und Administratoren teilen; wer eingeladen ist, lädt nie andere ein. rw- lässt einen Kollegen schreiben, wobei jede Änderung auf eine Freigabe wartet, rwx lässt Heinzel auch für ihn allein ändern. Die Seite „Teilen meiner Sessions“ ist weg. Was schon geteilt war, bleibt geteilt, und ein Mandant, der vorher geteilt hat, erlaubt bis rw-. In einer Richtliniendatei heißt die Einstellung jetzt share_max.
  • Eine Session für mehrere Server sagt jetzt, warum sie die Ausnahme ist: Eine Session erreicht aus Sicherheitsgründen nur einen Server, und diese erreicht jeden gewählten Server, direkt oder von einem zum anderen.

2.46.0 (2026-10-16)

  • Der erste Weg zu einer VPN-Verbindung sagt, was er ist: Der Server öffnet einen verschlüsselten WireGuard-Tunnel zu Heinzel Pro und hält ihn von innen offen. Seine Seite erklärt jetzt auch die Einrichtung auf einem Mac, mit der WireGuard-App aus dem App Store, und verweist für FreeBSD und OpenBSD auf das WireGuard-Projekt.
  • Ein Rollout ist eine Zeile in der Liste der Sessions und führt zu seiner Seite. Die Seite „Auf vielen Servern“ und ihr Eintrag in der Seitenleiste sind weg: Rollouts starten aus einer neuen Session.

2.45.0 (2026-10-16)

  • Die Seitenleiste ist nach Rhythmus sortiert: „Heute“ hält Sessions, Freigaben und Befunde, „Einrichten“ die Server, Zeitpläne, Aufgaben, Wissen und Regeln, „Nachschlagen“ das Audit-Protokoll. „Neue Session“ ist ein Knopf über der Liste. Ein Eintrag, hinter dem nichts steht, ist abgeblendet, öffnet aber weiter, und jeder Eintrag sagt beim Darüberfahren, was seine Seite ist und was gerade dahintersteht. Die Suchseite hat die Liste verlassen: Strg K findet Seiten und Einträge nach Namen und bietet die Volltextsuche als letzte Zeile an.
  • Eine neue Session beginnt mit dem, was Heinzel tun soll, und das wird ihre erste Nachricht. Der zuletzt benutzte Server ist schon gewählt, die anderen zuletzt benutzten sind einen Klick entfernt, in einer Reihenfolge, die jede Person einmal festlegt (zuletzt, oft, A–Z), und eine Suche nach Name, regulärem Ausdruck oder #tag erscheint, wo es mehr Server gibt als das. „Auf mehreren Servern arbeiten“ öffnet die seltenen Fälle: eine Session, die die anderen erreicht, oder dieselbe Aufgabe auf allen parallel, was einen Rollout startet; ein Filter nach regulärem Ausdruck oder #tag nimmt alle Treffer auf einmal dazu. Was Heinzel allein tut, heißt jetzt r--, rw- oder rwx: r-- liest und ändert nichts, auch nicht mit Freigabe, und ersetzt „Jeder Befehl wartet“ für neue Sessions. Modell und Aufwand falten sich hinter eine Zeile.
  • „Auf allen parallel dasselbe“ kann die Sessions sich absprechen lassen: Sie starten auf einmal, eine je Server und höchstens zehn, ohne einen ersten Server zum Probieren. Sie hinterlassen einander Notizen auf einer Pinnwand des Rollouts, etwa die Adresse eines neuen Primary oder den Pfad eines Schlüssels, und eine Session, die auf eine andere wartet, macht weiter, sobald die ihr eine Notiz hinterlässt. Jeder Befehl braucht weiter seine eigene Freigabe. Die Seite des Rollouts zeigt die Pinnwand, und jede Session sagt, mit wem sie arbeitet.

2.44.0 (2026-10-16)

  • Eine Navigation statt zwei: Die Seiten von Einstellungen, Sessions, Regeln, Benutzern und Gruppen klappen unter ihrem Eintrag in der Seitenleiste auf, und das Menü neben der Seite ist weg. Der Pfeil neben einem Eintrag öffnet seine Seiten, ohne die zu verlassen, auf der Sie sind. Auf dem Handy nennt eine Leiste über der Seite, wo Sie sind, und klappt die Seiten daneben aus.

2.43.0 (2026-10-16)

  • Das Regelwerk von Heinzel aktualisiert sich selbst: Jede Stunde holt die Installation das neueste Release der benutzten Hauptversion, protokolliert es und behält die fünf jüngsten Regelwerke für einen Weg zurück mit einem Klick. Eine neue Hauptversion wartet auf einen Administrator, und ein Weg zurück wird vom nächsten Lauf nicht rückgängig gemacht. Administratoren der Installation schalten es unter Installation, Einstellungen, Regelwerk ab. Der Agent weiß jetzt auch: Wo eine Regel von Heinzel 3 eine Aufgabe Heinzel Pro überlässt, ist sie seine eigene.
  • Der Besitzer eines Hosts kann ihn mit allow_changes = false in /etc/heinzel.conf gegen Änderungen sperren, wie es das offene Heinzel schon beachtet. Heinzel Pro liest die Datei, bevor es eine Änderung vorschlägt, und noch einmal, bevor eine freigegebene läuft, verweigert die Änderung mit dem Grund des Besitzers und schreibt, verschiebt oder löscht die Datei nie. Lesen läuft wie bisher.

2.42.1 (2026-10-15)

  • Das Release 2.42.0 hat kein Image gebaut: Das Manifest der Fähigkeiten lag als Quelldatei in priv/rules_pro, und das verweigert die Prüfung des Images. Es liegt jetzt neben dem Code, der es beim Kompilieren liest, so dass das Image dort Regeldateien und sonst nichts enthält.

2.42.0 (2026-10-15)

  • Heinzel 3.0 liest Partitionstabellen, Bootloader, Konten und Secrets und ändert nichts davon; Heinzel Pro tut es, hinter drei Schaltern auf der Richtlinien-Seite: Identität (Konten, SSH-Schlüssel, sudo-Rechte; an), Partitionieren und OS-Austausch (Dateisysteme, rohe Platten, Bootloader, EFI-Einträge; beide aus, bis ein Administrator es sagt). Ein Schalter gibt dem Agenten die Regeln für die Arbeit und lässt die Befehle zugleich durch: Jeder wartet auf eine Person, auf zwei, wo unumkehrbare Befehle es tun, und keiner läuft unbeaufsichtigt. Ist er aus, wird der Befehl verweigert, und der Agent berichtet stattdessen. Das Formular eines Servers schaltet einen für diesen Server allein wieder aus. Die Regeln-Seite zeigt jede Pro-Regel mit ihrer Fähigkeit; die mitgelieferte Kopie des offenen Regelwerks ist Heinzel 3.0.0, und mix heinzel.rules.sync <version> ersetzt sie durch ein getaggtes Release.
  • Eine Servergruppe trägt ein Wartungsfenster: Wochentage, von, bis, in der Zeitzone des Mandanten, wenn nötig über Mitternacht. Außerhalb liest Heinzel auf den Servern der Gruppe nur noch allein: Jede Änderung wartet auf eine Person, auf zwei, wo unumkehrbare Befehle es tun, und ein geplanter Lauf überspringt, was er geändert hätte, und listet es. Die Richtlinien-Prüfung auf der Befehle-Seite zeigt es, und wer außerhalb des Fensters freigibt, setzt sich darüber hinweg, im Audit-Protokoll.
  • Ihre eigenen Regeln, in der Form, in der Heinzel sie hält: unter Regeln ein Text je Regel (oder „alle“) aus Abschnitten ## Add:, ## Replace: und ## Remove:, für jeden Server oder für einen, angewandt nach dem Regelwerk, so wie Heinzel seine Override-Kette anwendet. Einige Regeln nehmen nur Ergänzungen an (die Verbindungs-Pipeline, die Anomalie-Erkennung, die Secrets-Hygiene, die eigenen Regeln von Heinzel Pro) und die Ethik-Regel keine: Ein abgelehnter Abschnitt bleibt mit seinem Grund im Formular stehen und geht ins Audit-Protokoll. Die Dateien eines Heinzel-Checkouts (memory/custom-rules/*.md, die rules.md eines Servers) werden übernommen, wie sie sind, mit einer Vorschau, was genommen und was übersprungen wird.
  • Ein verwalteter Pfad bekommt einen Modus, wie die geschützten Pfade von Heinzel: von einem Werkzeug verwaltet (eine Änderung wird mit dem Hinweis verweigert, wohin sie gehört, wie bisher), nur lesen (jede Änderung wird verweigert), verborgen (der Inhalt wird nie gelesen, nicht einmal eine Zeilenzahl) oder Änderungen warten auf eine Person (was auch immer die Session allein darf). Der Agent bekommt die Liste mit jedem Modus. Ein Team, das von Heinzel umzieht, bringt das Gedächtnis seiner Server mit: memory.md und todo.md eines Checkouts gehen über den Import unter Eigene Regeln in Gedächtnis und To-do des Servers.
  • Sechs eigene Regeln von Heinzel Pro, jede für Arbeit, die das offene Regelwerk liest und nicht tut: Konten, Schlüssel und sudo-Rechte als ein Stück Arbeit mit Anmeldetest und Weg zurück (Identität); eine Secret-Rotation, die jeden Verbraucher findet, bevor sich etwas ändert, und Zertifikate, die über die Flotte beobachtet und erneuert werden (hinter einem neuen Schalter, Secrets und Zertifikate, von Anfang an an); OS-Upgrades in Wellen über einen Rollout; eine Versionsmatrix über eine Gruppe als Befunde; und was ein Wartungsfenster für den Agenten bedeutet.
  • Eine Session arbeitet auf einer geschlossenen Menge von Servern, gewählt beim Öffnen: der Zielserver und, für eine Aufgabe über mehrere Server, weitere unter „Auch auf“ angehakte. Der Agent erreicht diese und keinen anderen, was auch immer ein Aufgabentext oder die Ausgabe eines Hosts von ihm verlangt, und eine Übertragung von einem davon (rsync, scp, ssh, curl, ein Datenbank-Client) wird nur zu einem anderen Server der Menge durchgelassen, erkannt an seinem Hostnamen oder an den Namen und Adressen, die die Seite eines Servers jetzt auflistet. Eine Aufgabe, die doch einen Server mehr braucht, beendet die Session, die eine neue mit der größeren Menge anbietet. Wer nicht jeden Server der Menge sieht, liest die Session. Ein Server, den die Session geändert hat, bekommt eine Journalzeile, bevor der Durchgang endet; wo der Agent keine schreibt, bekommt das Protokoll eine. Ein Zeitplan auf einer Servergruppe sagt beim Anlegen, ob jeder Server eine eigene Session bekommt oder alle eine teilen.

2.41.1 (2026-10-15)

  • Listen lesen sich gut auf dem Tablet und dem Handy: Eine Tabelle wird zu Karten, wenn der Platz neben der Seitenleiste für ihre Spalten zu schmal ist. Zeitpläne zeigen den letzten Lauf unter Wann sowie Besitzer und Stufe unter Zugang; Mandanten, Benutzer, SSH-Schlüssel, die Audit-Protokolle und die Zugriffsdurchsicht haben ebenfalls Spalten verloren. Ein Feld und der Schalter oder Knopf daneben stehen auf einer Zeile auf einer Höhe. Erklärungen zu Seiten erscheinen auf dem Handy vollständig, Befehle und Hostnamen brechen an Leerzeichen um, und der deutsche Text sagt durchgehend Sie.

2.41.0 (2026-10-15)

  • Ein Neustart für eine neue Version wartet nicht mehr feste drei Minuten, sobald jemand in Heinzel Pro ist. Er wartet auf eine ruhige Minute (niemand tippt, kein Schritt läuft, kein Zeitplan fällig) und zählt dann eine halbe Minute herunter; das Banner nennt den spätesten Zeitpunkt, zehn Minuten später, und ein Administrator der Installation kann den Countdown sofort starten.

2.40.0 (2026-10-15)

  • Zwei Rollen: Ein Mitglied hat, was die Buchstaben auf jedem Server geben, dazu die Wissensbasis und das Audit-Protokoll; ein Administrator hat alles. Die zehn Rechte, die aus den Buchstaben folgen, erscheinen als solche auf der Rechteseite und lassen sich weiter einzeln nehmen. Betrachter, Operator, Freigeber und „von sich aus nichts“ wirken weiter wie bisher, bis eine Rolle neu gespeichert wird.

2.39.0 (2026-10-15)

  • Rechte werden geschrieben wie der Modus einer Datei: r-- sieht, rw- arbeitet (Heinzel liest allein, ändert nach einer Freigabe), rwx lässt Heinzel allein ändern. Jeder Server hat einen Besitzer und eine Zeile wie bei ls -l, die Buchstaben des Besitzers und die aller anderen, die Serverliste und Serverseite zeigen; die Buchstaben des Besitzers deckeln dort jeden, Administratoren eingeschlossen. Zugriffe von Gruppen und Personen sind Ausnahmen, mit einem + markiert. Dieselben Buchstaben nennen den Deckel des Mandanten, die Stufe eines Zeitplans und die Wahl einer Session; „alles fragen“ bleibt eine Wahl für die Session und ist keine Grenze mehr, so dass ein Server, der alles fragte, jetzt allein liest, wie unbeaufsichtigte Läufe es immer taten. Die Seite einer Flotte setzt Besitzer und Buchstaben auf allen ihren Servern auf einmal.

2.38.0 (2026-10-14)

  • Gruppen von Personen und Gruppen von Servern, mit einem Zugriff zwischen beiden, der „sieht“ oder „arbeitet“ sagt: Wer welche Server erreicht, wird je Team, Person, Flotte oder Server festgelegt, auf der Seite der Gruppe, der Person oder des Servers. Ein Zeitplan gehört einer Gruppe von Personen, deren Mitglieder ihn ändern, und läuft auf einer Servergruppe. Jede Person und jeder Server ist eine Gruppe für sich, so dass Teilen, Modellfreigaben und Zeitpläne nur Gruppen nennen. Ein Mandant beginnt wie bisher: Alle arbeiten auf allen Servern.
  • Jede Tabelle richtet den Inhalt ihrer Zellen oben aus, so dass ein Name über zwei Zeilen Datum und Knöpfe daneben nicht mehr schweben lässt.
  • Ein pausierter Zeitplan ist in der Liste abgeblendet und trägt das Abzeichen „pausiert“, so dass auf einen Blick klar ist, dass er nicht läuft.

2.37.0 (2026-10-14)

  • Die Liste der Zeitpläne durchsucht jedes Wort, sortiert nach jeder Spalte, blättert wie die Serverliste und filtert laufende, fehlgeschlagene und pausierte Läufe. Ein laufender Lauf zeigt seine letzten Schritte, wie ausgelastet, warm und voll sein Host ist, und einen Weg in die Session; seine Knöpfe bleiben gesperrt, und er lässt sich nach einer Warnung stoppen.
  • Eine Session, deren Plan auf Freigabe wartet, sagt das auch am Ende des Verlaufs, mit einem Sprung zur Plan-Karte darüber, und das Nachrichtenfeld nennt den Plan statt eines Befehls.

2.36.0 (2026-10-14)

  • Die Stufenlisten in den Richtlinien-Einstellungen und auf einer Gruppe sagen, welche Stufen die Installation dem Mandanten nicht erlaubt, statt sie wortlos wegzulassen, und verlinken für den Administrator der Installation auf den Mandanten.
  • Die Installation hat eigene Seiten, außerhalb jedes Mandanten, hinter dem Eintrag Installation unten in der Navigation: Mandanten, Tarife, Mailversand und die Einstellungen zu Anmeldung, Lizenz und Regelwerk sind dorthin gezogen, und zwei Seiten sind neu: Konten (alle, die sich anmelden können, mit ihren Mandanten; von hier aus lässt sich eine Person in einen Mandanten setzen oder herausnehmen) und Protokoll (die eigene Audit-Kette der Installation und ob die Installation läuft). Navigation und Audit-Protokoll eines Mandanten sind jetzt für alle gleich.
  • Ist „Ändert allein“ auf einem Zeitplan abgeblendet, sagt das Formular, welche Einstellung es zurückhält (die Grenze der Installation für den Mandanten, Ihre Gruppen oder die Vorgabe des Mandanten), und verlinkt dorthin für den, der es ändern darf.

2.35.0 (2026-10-14)

  • Die Zeit eines Zeitplans wird gewählt, nicht als cron geschrieben: täglich, an gewählten Wochentagen, an einem Tag im Monat oder alle paar Stunden, mit der Uhrzeit. Die nächsten drei Läufe stehen darunter, mit Wochentag, und die Liste der Zeitpläne nennt jede Zeit in Worten. Ein Cron-Ausdruck bleibt die letzte Wahl. Beide Stufen, „Nur Lesen“ und „Ändert allein“, stehen immer im Formular; eine, die Sie nicht geben dürfen, bleibt abgeblendet und sagt warum.
  • Ein Administrator der Installation sieht Mandanten von außen und betritt nur die, in denen er Mitglied ist, mit der Rolle, die er dort hat. Ein neuer Mandant nennt seinen ersten Administrator, der per Mail eingeladen wird und jedes Recht hat, sobald er zusagt. Die Seite Mandanten zeigt zu jedem Mandanten Adresse, Startdatum, Tarif und Administratoren. Ein geschlossener Mandant lässt sich mit allem darin löschen, Audit-Protokoll eingeschlossen, sobald seine Adresse eingetippt ist. Tarife (Mandanten, Tarife) geben Plätze, Server und Deckel eines Mandanten vor; vier werden zum Start angelegt. Siehe die Upgrade-Hinweise: Wer sich darauf verließ, jeden Mandanten betreten zu können, braucht jetzt eine Einladung.

2.34.0 (2026-10-14)

  • Das Audit-Protokoll endet nicht mehr bei den neuesten 200 Ereignissen: Ältere laden nach, wenn Sie ans Ende scrollen, innerhalb des gesetzten Filters.
  • Das Gegenzeichnen dessen, was ohne Freigabe lief (bisher „Durchsicht“), ist ein Schalter in der Freigaberichtlinie und aus, bis ein Mandant es einschaltet. Die Seite Sessions zeigt den Knopf „Gegenzeichnen“ nur, solange etwas wartet, mit der Zahl.
  • Eine neue Seite „Regeln“ listet jede Regel, die eine Session liest, die von Heinzel und die eigenen von Heinzel Pro, neben dem, was Heinzel über jeden Server weiß: Gedächtnis, To-dos, Fakten und Journal. Eine Suche grenzt die Liste beim Tippen ein, und eine Regel verlinkt auf die Regeln, die sie nennt, und auf die, die sie nennen.
  • Ein Zeitplan nennt, was seine Läufe dürfen: „Nur Lesen“, wie bisher, oder „Ändert allein“, das so weit geht, wie eine Session seines Besitzers auf diesem Server allein gehen könnte, und den Rest für einen Operator überspringt. Nur wer eine Session allein ändern lassen darf, kann es wählen; bestehende Zeitpläne lesen. Mail von Heinzel Pro (Berichte von Zeitplänen und Sessions, Nachrichten, die der Agent sendet) trägt ihr Markdown als HTML neben dem Text, mit den Befehlen eines Berichts in Codeblöcken.
  • Die Seite eines Servers beginnt mit vier Kästen, die sich wie seine Zeile in der Serverliste lesen: Zustand, System, Platten und Last. Der Zugang klappt ein, sobald der Host antwortet, die Fakten klappen unter das Gedächtnis, und das Entfernen eines Servers hat einen eigenen Kasten am Fuß der Seite. Die Seite listet keine Bereiche mehr.
  • Eine Session lässt sich aus ihrem Menü „Mehr“ schließen und schließt sich nach 24 Stunden ohne Aktivität von selbst; ein Mandant stellt die Stunden unter Einstellungen ein, 0 für nie. Eine geschlossene Session nimmt keine Nachricht mehr an und verlangt niemandes Aufmerksamkeit. „In neuer Session weitermachen“ startet eine auf demselben Server, die zuerst ihre Zusammenfassung liest. Das Schreibfeld steht jetzt am Ende des Verlaufs, statt ihn zu verdecken, die Seite öffnet dort, und ein Knopf führt nach dem Hochscrollen wieder nach unten.
  • Jede Seite ist aus denselben Teilen gebaut: eine Karte mit einer Überschriftengröße, ein Hinweiskasten für Warnungen und Ergebnisse, ein Fuß unter jedem Formular mit Speichern rechts und Abbrechen daneben, und „Entfernen“, wo immer etwas weggenommen wird. Aufgaben, Wissen, Suche, API-Tokens, Zugriffsdurchsicht und Server importieren stehen in Karten wie die anderen Seiten; Zeitpläne ist eine Tabelle wie Benutzer und Gruppen; die Serverliste hält ihre Filter in einem Kasten, der auf dem Handy einklappt; Befunde wechseln mit einem Schalter zwischen offen und geschlossen; die Session-Seite beginnt mit demselben Link „Zurück“ und Titel wie jede Seite unter einer anderen.
  • Bereiche sind weg. Wer nach seinen Rechten „nur in seinen Bereichen“ durfte, sieht jetzt keinen Server, bis ein Administrator Server für ihn wählt, und eine Session, die in einem Bereich lief, führt nichts mehr aus. Was ein Bereich auf einem Host eingerichtet hat, bleibt dort: sein Konto mit dem Schlüssel von Heinzel in ~/.ssh/authorized_keys, /etc/sudoers.d/heinzel-area-<account> und die heinzel-<account>.conf des Webservers. Entfernen Sie sie von Hand, wo Sie sie nicht mehr wollen.

2.33.0 (2026-10-14)

  • Die Serverliste zeigt 25 Server je Seite, sortiert nach jeder Spalte, zeichnet jede Platte als Kreis (rot belegt, grün frei; /boot ausgelassen) und die Last als Balken gegen die Prozessoren des Hosts. Eine Spalte Zustand ersetzt Zustand, Modus, letzten Kontakt und Einrichtung, und die Liste nennt, wer auf einem Host angemeldet ist. Wie oft die Liste einen Host aktualisiert, wird je Server in seinem Formular eingestellt oder für jeden Server der Liste auf einmal, bis hin zu nie.
  • Ein Befehl, der in sein Zeitlimit gelaufen ist, sagt „Zeitlimit erreicht“ und wie lange er lief, statt „fehlgeschlagen“ mit dem Exit-Code „–“. Das Änderungsprotokoll sagt dasselbe.

2.32.1 (2026-10-14)

  • Releases kommen aus einem Zug, zweimal am Tag oder auf Anfrage, mit allem, was seit dem letzten gemerged wurde; ein Pull Request trägt kein eigenes Release mehr. Jeder Pull Request wird getestet, bevor er merged.

2.32.0 (2026-10-14)

  • Das Entfernen eines Servers fragt in einem Dialog, der sagt, was mitgeht (Gedächtnis, Zeitpläne, die über ihn erreichten Server), und verlangt den Namen des Servers noch einmal getippt; die eigene Frage des Browsers ist weg.
  • Der Administrator eines Mandanten ändert die Adresse des Mandanten unter Einstellungen, Allgemein. Die alte Adresse hört auf zu funktionieren, die API- und Alarmadressen mit ihr.
  • Die Seite API-Tokens zeigt die Adresse der API ohne den Mandanten zweimal darin.

2.31.0 (2026-10-14)

  • Die Autonomie eines Servers lässt sich nicht mehr auf Zeit erhöhen. Sein eigener Deckel, die Stufe der Session und die Grenze jeder Person zählen, immer. Eine Erhöhung, die beim Start dieses Release in Kraft ist, endet mit ihm; das Protokoll behält die früheren.

2.30.0 (2026-10-13)

  • Der Audit-Export, die Übergabedatei eines Servers und die Sprungpalette verlangen das Recht, das ihre Seite verlangt; sie standen jedem angemeldeten Mitglied offen.
  • Niemand entfernt ein Mitglied, das mehr Rechte hält als er selbst, und ein wartender Plan wird nur dem gezeigt, der seinen Server sieht.
  • Ist ein zweiter Faktor Pflicht, erreicht jemand ohne einen die Kontoseite, um ihn einzurichten; bisher lief er im Kreis.
  • Beide VPN-Seiten bleiben offen, wenn anderswo im Mandanten ein Befehl vorgeschlagen oder entschieden wird.
  • Ein Zeitplan über Tags zählt als Beobachter jedes seiner Server. Die üblichen Zeiten im Zeitplan-Formular füllen das Feld und sind übersetzt.
  • Die API lehnt eine Nachricht an eine arbeitende Session sofort mit 409 ab, ebenso einen Hostnamen, den zwei Server mit ihren vollen Namen teilen.
  • Ein Alarm zu einem Befehl, dessen Server entfernt wurde, wird gesendet, und Alarme nennen eine Wartezeit in Stunden und Minuten.
  • Adressen sagen, wie die Seite heißt: Die Anmeldung liegt unter /auth/login und /auth/register, das eigene Konto unter /account, und drei Einstellungsseiten unter /settings/models, /settings/alerts und /settings/sign-in. Die alten Adressen leiten weiter, auch die Anmeldelinks in älteren Mails; der Callback des Single Sign-on bleibt. Siehe die Upgrade-Hinweise zu 2.30.
  • Der Freigabemodus, die zweite Freigabe und die übrigen Einstellungen der Richtlinie verlangen das Recht, das festlegt, was Heinzel zurückhält, auf der Einstellungsseite wie in der Richtliniendatei.
  • Listen nennen die Person, der eine Session, eine Notiz oder ein Journaleintrag gehört, beim Namen, wo sie einen hat. Wer einen Befehl freigegeben oder abgelehnt hat, steht weiter als Mailadresse.
  • Jede Seite unter einer Liste hat denselben Link zurück zu ihr, Entfernen ist überall rot, und das Deutsche sagt durchgehend „Sie“.
  • Ein Befehl, der etwas geändert hat, steht im Journal des Servers, wer auch immer ihn laufen ließ; er fehlte bei jemandem, der die Notizen des Servers nicht bearbeiten darf. Sessions in einem Bereich schreiben wie bisher keinen.
  • Die Fälligkeit eines Zeitplans wird erst zusammen mit dem Einreihen seines Laufs verbraucht, so dass ein Knoten, der dazwischen stoppt, nichts verliert.
  • Niemand zieht die Einladung von jemandem zurück, der mehr Rechte hält, und die Zahl der Freigaben in der Navigation enthält die Pläne, die die Seite jemandem zeigt, der nur einige Server sieht.
  • Die Schwere eines Befunds, der Zustand eines Servers in einem Rollout und der Status eines Plans tragen ein Symbol neben ihrer Farbe.

2.29.2 (2026-10-13)

  • Eine for-Schleife über Wörter, die auf der Zeile ausgeschrieben sind, wird als ihre Rümpfe gelesen, einer je Wort, so dass for d in /dev/sda /dev/sdb; do parted -s $d print; done als Lesen läuft. Ein Wort in Anführungszeichen, ein Glob, eine geschweifte Klammer, $ oder ~ in der Liste, eine while-Schleife oder eine verschachtelte Schleife fragen weiter. Der Agent erfährt, was der Classifier nachvollziehen kann.

2.29.1 (2026-10-13)

  • Die Partitionswerkzeuge lesen, wenn sie nur ausgeben: parted print, sfdisk -l, fdisk -l, sgdisk -p, gdisk -l und wipefs ohne -a laufen ohne Freigabe, ebenso pvs, vgs, lvs und die -display-Formen. Ein schreibendes Wort, eine Option, die nicht als lesend bekannt ist, oder ein Gerät in einer Shell-Variablen lässt den Befehl unumkehrbar; wipefs -a bleibt gesperrt.

2.29.0 (2026-10-13)

  • Ein Server hat keine Gruppe mehr: Das Feld ist aus dem Serverformular, den Listen, dem Import, der API und den Anweisungen an den Agenten verschwunden. Sperrregeln und Dauerfreigaben gelten auf jedem Server oder auf einem; eine Person sieht Server nach Tag oder Name; eine verwaltete Datei gilt auf jedem Server. Was eine Gruppe nannte, wird auf die Server umgeschrieben, die darin waren, siehe die Upgrade-Hinweise zu 2.29. Die Gruppen von Personen bleiben unberührt.

2.28.3 (2026-10-13)

  • Eine Übergabenotiz verweist zurück auf ihre Session, solange niemand das abschaltet: „Mit Link“ ist, womit Einstellungen, Richtlinie und das Serverformular beginnen. Bestehende Mandanten bekommen den Link auch; ein Server, der etwas anderes sagt, behält, was er hat.

2.28.2 (2026-10-13)

  • Ein neuer Server hinterlässt Übergabenotizen auf seinem Host, so wie er sie schon liest. Wer Server betreut, kann beides abschalten; bestehende Server behalten, was sie haben.
  • Einstellungen, Richtlinie zeigt die Übergabenotizen wie das Serverformular: die Beispielzeile oben, die jeder Wahl folgt, und die Wahlmöglichkeiten nebeneinander statt als Auswahllisten.
  • Das Serverformular sagt, wo die Übergabenotizen aller Server eingestellt werden: Der Link steht neben „Wie jeder Server“ und öffnet Einstellungen, Richtlinie in einem neuen Tab, damit das Formular bleibt, wie es ist.

2.28.1 (2026-10-13)

  • Ein neuer Server liest die Übergabenotizen, die er auf seinem Host findet; das Hinterlassen bleibt aus, bis ein Administrator es einschaltet. Bestehende Server behalten, was sie haben.
  • Das Serverformular stellt eine Frage dazu, was eine Übergabenotiz sagt: „Wie jeder Server“ oder „Anders auf diesem Server“. Nur die zweite Antwort zeigt die fünf Einstellungen, als Wahlmöglichkeiten nebeneinander statt als fünf Auswahllisten, und die Beispielzeile steht darüber. Das Formular spricht nicht mehr von einem Mandanten.

2.28.0 (2026-10-13)

  • Übergabenotizen im Systemjournal eines Hosts lassen sich einstellen. Sie zu schreiben und frühere zu lesen sind zwei Entscheidungen eines Servers. Wer genannt wird (niemand, der Name, Name und Mailadresse, eine Kontaktadresse des Mandanten), die Sprache (24 zur Wahl), kurz oder ausführlich, nur bei Änderungen oder bei jeder Session, und ein Link zurück zur Session werden je Mandant gesetzt (Einstellungen, Richtlinie), und ein Server darf abweichen. Das Serverformular zeigt die Zeile, die die aktuelle Wahl ergibt. Heinzel Pro setzt die Zeile zusammen und schreibt sie; das Modell liefert den Satz mit dem neuen Werkzeug leave_host_note, und ein eigenes logger -t heinzel wird abgelehnt.
  • Eine Lizenz für den Quellcode (LICENSE.md) und eine Beitragsvereinbarung (docs/de/contributor-agreement.md) für Kunden, die den Code bekommen und Änderungen zurückschicken. Ein Pull Request fällt durch seine Prüfung contributors, solange sein Autor nicht in .github/contributors steht.

2.27.0 (2026-10-13)

  • Ein Mandant kann neben seinen Plätzen eine Zahl von Servern bekommen (Mandanten, Bearbeiten). Das Serverformular weist an der Grenze ab und nennt sie; ein entfernter Server macht seinen Platz frei. Das Formular zeigt, was die Lizenz der ganzen Installation erlaubt. Für ein kleines kostenloses Konto: ein Platz, ein Mandant, ein paar Server.

2.26.0 (2026-10-13)

  • Das Serverformular stellt eine Frage, „Was darf Heinzel auf diesem Server?“, mit sechs Antworten von „Nichts“ bis „Alles, ohne zu fragen“. Sie ersetzt den Zugriffsmodus und die Stufe daneben, deren neun Paare sechs verschiedene Dinge ergaben. Ein neuer Server beginnt bei „Nichts“.
  • Entfernt: Ein Zeitplan ändert keinen Server mehr. Er liest, und was etwas ändern würde, wird übersprungen und aufgelistet, wie vor 2.11.0. Ein Zeitplan, der auf „Änderungen warten“ oder „Ändert allein“ stand, liest ab diesem Release; die Einstellungen dafür sind aus Zeitplänen, Servern, Gruppen und dem Mandanten verschwunden.
  • Entfernt: Wartungsfenster. Fenster, die ein Server hatte, halten keine Änderung mehr zurück. Die Spalten von beidem bleiben für ein Release in der Datenbank.

2.25.0 (2026-10-12)

  • Jede Seite endet mit einer Zeile, die das Copyright und die Versionen von Heinzel Pro und der verwendeten Heinzel-Regeln nennt, die Anmeldeseite eingeschlossen. Auf der Installation, die wir hosten, verlinkt sie außerdem unser Impressum und unsere Datenschutzerklärung, in der Sprache des Lesers. Eine eigene Installation verlinkt keines von beiden: Beides ist Sache des Betreibers.

2.24.1 (2026-10-12)

  • Behoben: Auf einem Telefon zeigte jede Seite das Banner eines angekündigten Neustarts („Es dauert etwa eine Minute …“, mit „Neustart abbrechen“ für einen Administrator), obwohl nichts angekündigt war. Ein Stil von uns für schmale Bildschirme zeigte das Banner, das die Seite versteckt hatte.
  • Eine abgelehnte ausgehende Verbindung wird mit der Adresse protokolliert, für die sie abgelehnt wurde. Die Zeile sagte auch bei einem Nachbarn in HEINZEL_REFUSED_NETWORKS „führt zu diesem Host“.

2.24.0 (2026-10-12)

  • Ein angekündigter Neustart erreicht keine offene Seite ohne Countdown. Eine Seite, die zehn Minuten niemand berührt hatte, zeigte sofort „Heinzel Pro startet neu“; jetzt zählt ihr Banner die letzte halbe Minute herunter, und ein Deploy wartet diese halbe Minute. Ein laufender Countdown rückt auf eine halbe Minute vor, sobald niemand mehr arbeitet.

  • Ein Modellanbieter trägt keine Kennzeichnung mehr, wo er Daten verarbeitet. Sie war eine Aussage, die Heinzel Pro nicht prüfen konnte, und stand neben dem Namen des Modells, wo eine Session gestartet wird. Was eingetragen wurde, wird nicht mehr gezeigt; die Spalte bleibt für dieses Release in der Datenbank.

  • Eine Installation, die für Mandanten gehostet wird, die ihr Betreiber nicht kennt (HEINZEL_HOSTED=true), lehnt Adressen ab, die zu ihr selbst zurückführen: ein Webhook, ein Modellanbieter, ein Audit-Kollektor, ein Monitoring-Endpunkt, ein Server oder die Gegenseite eines VPN auf der Loopback-Adresse, auf einer Adresse der eigenen Schnittstellen der Maschine, in einem privaten oder Link-local-Bereich oder in einem Netz, das HEINZEL_REFUSED_NETWORKS nennt. Ein Name wird nach der Adresse beurteilt, zu der er beim Verbinden aufgelöst wird, und die Verbindung geht an diese Adresse. Ohne die Einstellung ändert sich nichts: Eine Installation im eigenen Rechenzentrum erreicht Ihr Netz wie bisher.

  • Eine Installation gegen eine PostgreSQL, die der Host schon betreibt: deploy/hosted/docker-compose.yml, ein Container im Netz des Hosts ohne den Dienst db, und in der Installationsanleitung „Mit Ihrer eigenen PostgreSQL“. Eine Rolle, der ihre Datenbank gehört, reicht.

  • deploy/hosted/deploy.sh nimmt die Version, die ausgerollt werden soll (HEINZEL_DEPLOY_VERSION), schreibt sie in die .env und gelingt nur, wenn /health diese Version ohne ausstehende Migration meldet; bisher gab es sich mit jeder Antwort zufrieden, auch der des alten Release. Ein Image, das sich nicht holen lässt, lässt die .env, wie sie war.

  • Die gehostete Installation übernimmt ein Release von selbst: release.yml ruft die neue deploy.yml auf dem eigenen Runner des Hosts auf, solange die Repository-Variable HOSTED_DEPLOY auf on steht. deploy/hosted/README.md sagt, wer dort was darf.

  • docker-compose.yml fällt nicht mehr auf das Image-Tag latest zurück: HEINZEL_VERSION in der .env nennt die Version, .env.example kommt mit ihr ausgefüllt, und ohne sie startet nichts. Ein docker compose pull auf einer Installation, die die Variable nie gesetzt hatte, holte, was gerade das Neueste war, ein Major-Release eingeschlossen. Siehe docs/en/upgrade.md.

  • Die Sicherheitsarchitektur nennt jede Stelle, zu der eine Installation eine Verbindung öffnet („Was die Installation verlässt“), und ein Test schlägt fehl, wenn der Code eine öffnet, die dort nicht steht.

  • Behoben: Kommentare in .env.example und vier weiteren Dateien zeigten auf docs/installation.md und docs/upgrade.md, die nach docs/en/ und docs/de/ umgezogen sind; der Schnellstart der README ließ HEINZEL_BASE_URL aus.

2.23.0 (2026-10-12)

  • Die Einstellungen sind zehn Seiten statt sechs Reiter, mit einer Navigation daneben: Allgemein, Richtlinie, Befehle, Richtlinie als Datei, Modellanbieter, Alarme und Anbindungen für den Mandanten; Anmeldung, Lizenz und Regelwerk für die Installation. Jede Seite verlinkt die, von denen sie abhängt. Die Adressen /settings/llm, /settings/notifications, /settings/sso, /settings/license und /settings/rules bleiben.
  • Der Modellkatalog wird unter Modellanbieter eingespielt. Er saß in der Lizenzseite und wurde nur gezeigt, solange die Installation keine Lizenz hatte.
  • Entfernt: das Monatsbudget für Modellaufrufe, mit seiner Warnung bei 80 % und seiner Zeile auf der Übersicht. Was ein Mandant ausgibt, wird für den Monatsbericht weiter gezählt.
  • Entfernt: das Kundenportal mit seiner Rolle „Kunde (nur Portal)“. Ein Mitglied, das die Rolle hatte, behält die Mitgliedschaft mit der Rolle „Von sich aus nichts“ und ohne einzelne Rechte; geben Sie einer solchen Person unter Benutzer eine Rolle oder entfernen Sie sie.
  • Die Seite Kontrollen hat ein neues Layout: wie viele Kontrollen jeder Norm sie anspricht, ein Symbol je Schutzmaßnahme, die Einstellung des Mandanten im Ton dessen abgesetzt, was sie bedeutet, und die Nachweise als Knöpfe. Eine Audit-Aufbewahrung von 0 Tagen liest sich „unbegrenzt aufbewahrt“ statt „0 Tage aufbewahrt“.
  • Entfernt: die Vorgabe des Mandanten, wo Prompts verarbeitet werden dürfen. Ein Anbieter behält seine Kennzeichnung, die dort gezeigt wird, wo ein Modell gewählt wird. Siehe docs/upgrade.md.

2.22.0 (2026-10-12)

  • Eine Session berichtet an Menschen. Auf ihrer Seite nimmt unter Mehr „Bericht und Nachrichten“ entgegen, wohin der Bericht geht: Mailadressen und der Kanal des Teams, wo der Mandant einen Webhook hat. Der Bericht geht hinaus, wenn Heinzel eine Aufgabe erledigt und seine Zusammenfassung geschrieben hat, und wenn die Session fehlschlägt; ein Knopf sendet ihn jederzeit, und das Feld listet, was gesendet wurde und ob es hinausging. Unter Konto legt eine Person die Ziele fest, die alle ihre Sessions mitnehmen.
  • Heinzel sendet eine Nachricht, wenn ein Prompt darum bittet („und dann schick mir eine Mail an ops@example.com“), mit dem neuen Werkzeug send_message. Es schreibt nur dorthin, wohin ein Mensch gezeigt hat: eine Adresse aus einer Nachricht der Session, die Ziele der Session, ihre Personen, der Kanal des Teams. Eine Adresse, die es auf einem Host gelesen hat, wird abgelehnt, ebenso jede Adresse in einer Session, die ein Alarm gestartet hat. Zehn Nachrichten je Stunde und Session, von Geheimnissen befreit, protokolliert.
  • Ein Zeitplan berichtet neben der Mail auch an den Kanal des Teams.
  • Kanäle sind Module hinter HeinzelPro.Outbox.Channel; ein neuer, etwa Slack, ist ein Modul und erscheint in jedem Formular und beim Agenten.

2.21.0 (2026-10-11)

  • Mail geht den Weg, den die Installation hat. MAIL_TRANSPORT nennt ihn: smtp für einen Mailserver, einen Anbieter oder ein Konto bei Gmail oder Microsoft 365; sendmail für das Mail-Kommando der Maschine; msgraph für Microsoft 365 ohne SMTP; oder einer von vierzehn Mail-Diensten über HTTPS, für ein Netz, das kein SMTP hinauslässt. SMTP_HOST allein heißt wie bisher smtp. Eine Einrichtung, die nicht senden könnte, hält den Start an und nennt die Variable. Siehe docs/installation.md, „Mail“.
  • Behoben: Ein Mailserver, der STARTTLS anbietet, bekam keine Mail. Die Verbindung wird jetzt verschlüsselt und das Zertifikat des Servers geprüft, gegen die Stellen des Systems oder SMTP_CA_FILE; SMTP_TLS_VERIFY=false nimmt jedes an. Port 465 ist TLS vom ersten Byte an, ohne SMTP_SSL.
  • Upgrade-Hinweis: Mit gesetztem SMTP_USERNAME und SMTP_PASSWORD wird ein Server abgelehnt, der keine Verschlüsselung anbietet, wo das Passwort bisher im Klartext hinausging. SMTP_TLS=never behält das alte Verhalten.
  • Verwaltung, Mailversand zeigt einem Administrator der Installation, wie Mail hinausgeht, ohne die Geheimnisse, und schickt eine Testmail, die sagt, warum sie gescheitert ist. HeinzelPro.Release.test_mail/1 tut dasselbe aus einer Shell.
  • Ein Mail-Kommando, das eine Mail ablehnt, und ein Adapter, der abstürzt, sind Fehler im Log und auf der Seite, keine Mail mehr, die stumm nirgends ankam.
  • Ein Hinweis oben rechts schließt sich von selbst: nach sechs Sekunden, ein Fehler nach zwölf. Ein Balken darunter zeigt, wie lange er bleibt, und er wartet, solange der Zeiger auf ihm ruht oder der Tab im Hintergrund ist. Der Hinweis auf eine verlorene Verbindung bleibt, bis die Verbindung zurück ist.
  • Die Navigation führt einen neuen Mandanten durch seine Einrichtung. Bis ein Modellanbieter eingerichtet ist, sind nur die Übersicht, das Audit-Protokoll, die Verwaltung und das Konto offen; danach die Server und das Wissen, und mit dem ersten Server alles andere. Ein Eintrag, der wartet, wird grau gezeigt und sagt beim Überfahren, worauf er wartet, und der nächste Schritt steht als Link unter dem Eintrag der Übersicht. Wer den Schritt nicht tun kann, erfährt, dass ein Administrator es tun muss. Was ein Mandant getan hat, bleibt erreichbar, wenn sein Server oder Anbieter später weg ist.
  • Das Regelwerk im Image ist Heinzel 2.30.1. Seine Regeln sind die von 2.30.0; das Release korrigiert einen Verweis auf das Housekeeping, den Heinzel Pro nicht trägt.

2.20.0 (2026-10-11)

  • Ein Befehl, der etwas ändert oder ein längeres Zeitlimit bekommen hat, läuft als Job auf seinem Host und überlebt einen Neustart von Heinzel Pro: Nach einem Deploy, einem Absturz oder einem Reboot des Hosts, auf dem Heinzel Pro läuft, bekommt die Session den echten Exit-Code und die echte Ausgabe, wo sie bisher „unterbrochen, Ergebnis unbekannt“ bekam. Die Ausgabe erscheint auf der Session-Seite, während der Befehl läuft. Das Stoppen der Session, ein Zeitlimit und der Not-Aus beenden den Job auf dem Host. Lesende Befehle, und Befehle, denen ein Geheimnis oder eine Datei übergeben wird, laufen wie bisher in ihrem SSH-Kanal. Siehe docs/upgrade.md und docs/security.md, „Was auf einem Host liegen bleibt“.
  • Ein geplanter Neustart wird angekündigt. Der Host fragt zuerst mit POST /ops/drain: Arbeitet niemand, darf er sofort neu starten, sonst zeigt jede offene Seite ein Banner mit Countdown und Grund, voreingestellt drei Minuten im Voraus. Eine halbe Minute vor dem Zeitpunkt beginnt Heinzel nichts Neues und beendet den Schritt, in dem es ist. Ein Administrator der Installation kann am Banner abbrechen. Eine Seite, die sich mit einem neueren Release neu verbindet, sagt das. Die Adresse steht nur dem Host offen und braucht HEINZEL_OPS_TOKEN; deploy/hosted enthält das Skript und eine systemd-Unit für das Herunterfahren des Hosts. Siehe docs/installation.md, „Neustart ankündigen“.
  • Zwei Releases können sich für die Minute eines Deploys die Datenbank teilen. Eine Session wird von genau einem Runner geführt, der eine Lease auf sie hält; ein Release, das stoppt, gibt seine Sessions zurück, und das andere nimmt sie wieder auf, bei seinem Start und jede Minute, was auch einen Absturz abdeckt. Ein Container, der gestoppt wird, endet geordnet (stop_grace_period: 90s): Ein Job auf einem Host läuft weiter, und nichts wird zweimal wieder aufgenommen. deploy/hosted enthält eine Compose-Datei für zwei Slots, den nginx-Schnipsel und das Skript, das zwischen ihnen umschaltet; siehe docs/installation.md, „Zwei Slots“, und docs/upgrade.md, „Welche Releases nebeneinander laufen dürfen“.
  • Ein Release ist nur dort ein Erlang-Knoten, wo es dazu bestimmt wird (HEINZEL_NODE_ADDRESS), und dann nur mit einem HEINZEL_CLUSTER_COOKIE der eigenen Installation. Vorher war jeder Container ein Knoten mit dem Cookie, mit dem sein Image gebaut wurde.
  • Eine VPN-Verbindung, deren Port noch das Release hält, das gerade abgelöst wird, sagt, dass sie darauf wartet, statt eine Störung zu melden.
  • Das Regelwerk sind Daten. Die Einstellungen haben einen Reiter Regelwerk für Administratoren der Installation: die verwendete Version, eine Prüfung auf ein neueres Tag des öffentlichen Heinzel-Repositories, ein Update ohne Neustart, ein Upload für Installationen ohne Weg nach draußen und die aufbewahrten Versionen, zu denen man zurückkehren kann. Eine Session behält das Regelwerk, mit dem sie begonnen hat, und bietet „Regeln neu laden“ in ihrem Menü an, sobald ein neueres in Gebrauch ist. HEINZEL_RULES_DIR steht weiter darüber. Siehe docs/upgrade.md, „Regelwerk“.
  • Ein Mandant kann eine eigene Zahl von Plätzen bekommen. Ein Administrator der Installation setzt sie im Formular des Mandanten; die Seite Benutzer des Mandanten zeigt die Belegung, und eine Rolle, ein Recht zum Handeln oder eine angenommene Einladung, die sie überschritte, wird mit Nennung der Grenze abgewiesen. Die Gesamtzahl der Lizenz bleibt der Deckel über allen Mandanten und zählt eine Person einmal. Ohne Zahl ändert sich nichts. Siehe docs/administration.md, „Plätze pro Mandant“.
  • Releases sind von jetzt an Images. Ein Tag v<version> baut ghcr.io/wintermeyer/heinzel-pro:<version> und :latest für amd64 und arm64 in GitHub Actions und veröffentlicht das Release mit dem Abschnitt dieser Datei zur Version. Jedes Image wird vor dem Push geprüft: keine Debug-Informationen, kein Quellcode, keine .env. docker compose up -d zieht es; --build baut weiter aus dem Quellcode.
  • Das Regelwerk im Image ist Heinzel 2.30.0.

2.19.0 (2026-10-11)

  • Die Zusammenfassung einer Session sagt auf einen Blick, was die Session war: Zähler oben (Änderungen, Prüfungen, offene Punkte, Schritte zurück) und darunter nur die Teile, in denen etwas steht, einer unter dem anderen. Ein leerer Teil ist ein gestrichelter Zähler und keine halbe Karte mehr. Ein Schritt zurück steht in einem eigenen Kasten, genau so, wie er geschrieben wurde.
  • Eine Zusammenfassung spricht nur dort von einem Weg zurück, wo etwas geändert wurde. Heinzel soll ihn nach einer Session, die nur geschaut hat, weglassen, und eine Zusammenfassung, die ohne Änderung einen Weg zurück nennt, geht an es zurück. Früher geschriebene Zusammenfassungen behalten, was sie sagen.
  • Behoben: Der Hinweis, dass eine Zusammenfassung vor der letzten Anfrage geschrieben wurde, und zwei Hinweise auf der Rechteseite einer Person waren kaum lesbar, heller Text auf hellem Grund. Ein Schritt zurück in der Zusammenfassung begann mit überzähligen Leerzeilen.

2.18.0 (2026-10-11)

  • Ein Browser-Tab arbeitet in dem Mandanten, den seine Adresse nennt: Jede Adresse innerhalb eines Mandanten beginnt mit dessen Kürzel (/acme/sessions/…). Zwei Tabs arbeiten in zwei Mandanten nebeneinander, und ein Tab, der neu geladen wird oder sich neu verbindet, bleibt, wo er war. Das Wechseln schließt die Seiten des verlassenen Mandanten nicht mehr. Adressen von früher, in Lesezeichen und Mails, werden in den zuletzt benutzten Mandanten weitergeleitet. Bei mehreren Mandanten nennt der Titel des Tabs den Mandanten. Siehe docs/upgrade.md.
  • Der Tab einer Session sagt in seinem Titel, was diese Session braucht: eine Freigabe, einen Blick auf einen Fehlschlag, oder dass Heinzel geantwortet hat. Unter mehreren Session-Tabs sticht der heraus, zu dem man gehen sollte. Die Zahl aller Sessions, die Sie brauchen, bleibt im Titel der anderen Seiten.
  • Zwei Tabs einer Session zeigen dasselbe: Dateien, die auf die nächste Nachricht warten, eine herausgenommene oder durchgelassene Datei, und was in einem Tab gelesen wurde, ist im anderen gelesen.
  • Ein Browser hält ein Konto. Wer sich mit einem anderen Konto anmeldet, während eines angemeldet ist, wird mit „Melde dich erst ab“ abgewiesen, statt die offenen Tabs des ersten Kontos in einem eigenen Zustand zurückzulassen.
  • Nach einer verlorenen Verbindung ist eine Seite früher wieder aktuell: Sie verbindet sich neu, sobald das Netz zurück ist oder der Tab nach vorn kommt, und versucht es dazwischen alle zwei Sekunden statt alle fünf.

2.17.0 (2026-10-10)

  • Datenbank und Code sagen „session“, wo sie „conversation“ sagten: die Tabellen sessions, session_reads und session_shares, die Spalte session_id, die Einstellungen session_sharing und session_retention_days, die Rechte run_sessions, view_sessions und read_all_sessions. Eine Migration benennt sie um und nimmt die Rechte der Personen und die wartenden Jobs mit. Der Alarm-Webhook und die Richtliniendatei verwenden die neuen Namen; das Audit-Protokoll behält die alten. Siehe docs/upgrade.md.

2.16.0 (2026-10-10)

  • Die Seite einer Session gehört ihrem Verlauf. Eine Zeile sagt, welche Session es ist, auf welchem Server, in welchem Zustand und was Heinzel ohne zu fragen tun darf. Personen, der Änderungsnachweis, der Vorfallsentwurf sowie Besitzer, Modell, Tokens und Kosten warten hinter einem Knopf. Die Liste Ihrer anderen Sessions ist von der Seite verschwunden: „Sessions“ in der Navigation führt zu ihr zurück und zählt die, die Sie brauchen.
  • Während Heinzel arbeitet oder auf eine Entscheidung wartet, ist das Nachrichtenfeld eine Zeile und liegt nicht mehr über dem Befehl, der freizugeben ist.
  • Sessions liegen unter /sessions/…, nicht mehr unter /conversations/…. Eine alte Adresse in einer Mail oder einem Lesezeichen öffnet sich nicht mehr.

2.15.0 (2026-10-10)

  • Zwei Listen zeigten mehr, als die Rechte einer Person erlauben, beide seit 2.14.0. Wer nur ausgewählte Server sieht, sah auf der Seite Freigaben die Befehle, die geplante Läufe auf jedem Server übersprungen hatten, und konnte sie übernehmen oder verwerfen. Und ein API-Token listete weiter Server, Sessions, Freigaben, Befunde und Zeitpläne, nachdem seine Person das Recht verloren hatte, sie zu sehen. Beide halten sich jetzt an das, was die Person gerade hat.
  • Die Navigation sagt, wie viel hinter einem Eintrag steckt: die Server, die Sie sehen, die Zeitpläne, die laufen, mit denen abgesetzt, die Heinzel anhalten musste, und die offenen Befunde, rot, wenn einer kritisch ist, und gelb bei einer Warnung. Ein Eintrag ohne etwas dahinter zeigt keine Zahl.
  • Behoben: Wer nur einige Server sieht, bekam die Befunde jedes Servers des Mandanten. Jetzt findet er die seiner Server.
  • Behoben: Eine kurze Zahl las sich 1.0K, und auf Deutsch 2.150,0. Jetzt ist es 1K, und das schlichte 2.150, wo das Deutsche keine kurze Form hat.

2.14.0 (2026-10-10)

  • Rechte lassen sich je Person setzen. Eine Rolle bleibt der Ausgangspunkt; unter Benutzer listet „Rechte“ jedes Recht als Satz und lässt Sie ein Recht geben, das der Rolle fehlt, oder eines nehmen, das sie hat. „Alles außer diesem“ ist ein Administrator mit einer Zeile auf „Nein“, „nichts außer diesen“ die neue Rolle „Von sich aus nichts“ mit zwei oder drei Zeilen auf „Ja“. Die Seite sagt das Ergebnis in einem Satz, bevor Sie speichern. Was ein Administrator konnte, sind jetzt 12 eigene Rechte (Benutzer, Geheimnisse, API-Tokens, Sicherheitsregeln, Modellanbieter und so weiter), so dass sich jedes einzeln vergeben lässt. Niemand ändert die eigenen Rechte oder gibt mehr, als er hält. Eine geschlossene Seite nennt das fehlende Recht, die Navigation zeigt, was eine Person öffnen darf, und die Kontoseite listet die eigenen Rechte einer Person. Ein Recht zum Handeln belegt einen Platz, was auch immer die Rolle ist.
  • Eine Person kann nur einige Server sehen, gewählt nach Gruppe, Tag oder Name. Die anderen gibt es für sie nicht, in Listen, in der Suche, in Freigaben und für den Agenten in ihren Sessions. Rechte, die über den ganzen Mandanten reichen, fallen für sie weg.
  • Bereiche: ein Teil eines Servers, auf den jemand beschränkt ist, etwa eine Website und eine Datenbank. Ein Bereich ist ein eigenes Konto auf dem Host, dem die Verzeichnisse des Bereichs gehören, das nginx oder Apache testen und neu laden darf und sonst nichts davon, und das eine PostgreSQL-, MySQL- oder MariaDB-Datenbank erreicht. Heinzel zeigt das Einrichtungsskript vollständig, führt es auf Klick aus, meldet sich dann als das Konto an und prüft, dass es eingezäunt ist; Sessions des Bereichs melden sich als dieses Konto an und laufen nur, solange diese Prüfung hält. Nur Linux. Die Migration 20261010162948 ergänzt Spalten und zwei Tabellen und ändert keine bestehende Zeile.

2.13.0 (2026-10-10)

  • Die Seite Backups ist weg, und mit ihr der tägliche Blick auf die beobachteten Verzeichnisse. Ein Zeitplan, der das Verzeichnis liest, kann ihre Stelle einnehmen und auch je Nacht ein Unterverzeichnis lesen. Die Migration 20261010161139 löscht die beobachteten Verzeichnisse mit ihrer Historie und schließt die Befunde, die sie offen ließen.

2.12.0 (2026-10-10)

  • Die Seite Zertifikate ist weg. Sie beobachtete nur die Hostnamen, die jemand in ihre Liste getippt hatte, und das Zertifikat, das abläuft, ist das, das niemand eingetragen hat. Die Liste wird mit dem Update gelöscht, und die Befunde, die sie offen ließ, werden geschlossen. Ein Zeitplan, der Zertifikate auf einem Host prüft, hält weiter fest, was er findet, auf der Seite Befunde.

2.11.0 (2026-10-10)

  • Ein Zeitplan kann einen Server ändern, wo es ihm erlaubt ist. Bis jetzt las ein Lauf, bei dem niemand dabei ist, nur. Ein Zeitplan nennt jetzt seine eigene Stufe: nur lesen, Änderungen warten auf eine Freigabe (eine Dauerfreigabe zählt dort), oder Änderungen allein. Das Niedrigste aus vier Einstellungen zählt: diese Stufe, was der Besitzer des Zeitplans einem Zeitplan überlassen darf (eine Vorgabe je Mandant, oder eine Gruppe), was der Server von einem Zeitplan annimmt, und der Deckel des Mandanten. Alle beginnen bei Lesen, also ändert sich nichts, bis ein Administrator jede einzeln öffnet. Bei „Änderungen allein“ wartet nichts, unumkehrbare Befehle eingeschlossen, und jede Stelle, die es einstellt, sagt das in Rot. Ein Zeitplan ändert einen Server nur innerhalb seiner Wartungsfenster, und wer ändert, was ein ändernder Zeitplan verlangt oder wo er läuft, übernimmt ihn.

2.10.0 (2026-10-10)

  • Für einen Host wird kein Passwort mehr aufbewahrt. Das Feld für das sudo-Passwort ist aus dem Serverformular verschwunden, und die Passwörter, die darin eingetragen wurden, löscht das Update. sudo muss für Heinzels Benutzer ohne Passwort gehen; wo es eines verlangt, scheitert ein Befehl mit sudo sofort.

2.9.1 (2026-10-10)

  • Die Seiten, die täglich gebraucht werden, bekommen den Platz. In der Seitenleiste klappen die Verwaltungsseiten ein, bis eine davon offen ist, und die ganze Navigation passt auf einen Laptop-Bildschirm. Auf dem Handy sitzen die selten gebrauchten Knöpfe einer Seite in einem Menü „Mehr“, ihre Erklärung ist zwei Zeilen lang, bis man sie antippt, die Serverliste ist eine kurze Karte je Host, und der Filter des Audit-Protokolls und das Zertifikatsformular öffnen sich auf Wunsch. Die Übersicht beginnt mit dem, was Sie braucht.

  • Eine neue Session von der Seite eines Servers aus beginnt auf diesem Server, und auf dem einzigen Server, wo es nur einen gibt.

2.9.0 (2026-10-10)

  • VPN-Verbindungen: Ein Server, der aus dem Internet nicht erreichbar ist (hinter dem Router zu Hause, im Büronetz, ohne öffentliche Adresse), wird durch einen WireGuard-Tunnel erreicht. Entweder wählt sich der Server oder das Netz des Mandanten bei Heinzel Pro ein, mit einem Textblock zum Einfügen, den Heinzel erzeugt, oder Heinzel Pro wählt einen Router an, aus der Datei, die der Router exportiert. Jede Verbindung ist ein eigener Tunnel im Userspace, Mandanten mit demselben privaten Netz begegnen sich also nie; SSH darin behält seinen Schlüssel und seinen Host-Key. Die Seite einer Verbindung zeigt live, ob der Tunnel steht, und führt durch die Schritte der Gegenseite. Installationen öffnen dafür UDP 51900 bis 51919, siehe docs/upgrade.md.

  • Eine VPN-Verbindung kann stattdessen ein Gerät in einem Tailscale-Netz sein (auch mit einem Headscale-Server): Heinzel Pro tritt mit einem Auth-Key bei, den der Mandant erzeugt, einmal, und ist nach jedem Neustart dasselbe Gerät. Auf den Servern wird nichts installiert. Tailscale SSH wird nicht benutzt; SSH behält auch hier seinen Schlüssel und seinen Host-Key.

  • Markdown wird auch an den übrigen Stellen so gezeigt, wie es gemeint ist: die Punkte der Zusammenfassung einer Session (auch im Kundenportal), Ziel, Schritte, Risiken und Weg zurück eines Plans, und die Notizen zu einem Host neben einem Befehl. Befehle bleiben, wie sie geschrieben sind.

  • Markdown wird so gezeigt, wie es gemeint ist: Antworten des Agenten, Notizen des Wissens sowie Gedächtnis und To-dos eines Servers erscheinen als Überschriften, Listen, Fettdruck, Code und Tabellen, nicht mehr als Quelltext. Das HTML entsteht aus einer geschlossenen Menge von Elementen; HTML im Text wird als Wörter gezeigt, ein Link führt nur ins Web oder zu einer Mailadresse, und kein Bild wird geladen.

  • Eine Session anzuhalten braucht eine Zeile: Der Knopf sitzt neben „Heinzel arbeitet…“, und das Feld für einen Grund öffnet sich nur für den, der danach fragt.

2.8.0 (2026-10-09)

  • Ankündigungen: Vor einer Aufgabe mit mehreren Schritten sagt eine Session mit dem neuen Werkzeug announce_change, was sie auf einem Server ändern wird (Dienste, Pfade, Pakete, den ganzen Host). Das hält sie von da an, die Seite des Servers und die Liste zeigen es mit einem Satz für Menschen, und ein anderer Agent erfährt die Namen und nie den Satz, so dass keine Session einer anderen auf diesem Weg Anweisungen geben kann.

  • Servergedächtnis: Was eine Session in das Gedächtnis oder die To-dos eines Servers schreibt, wird nur übernommen, wenn der Text noch der ist, den sie gelesen hat. Hat eine andere Session oder eine Person ihn inzwischen geändert, wird nichts geschrieben, und die Session bekommt den aktuellen Text, um ihre Änderung dort einzutragen. Bisher ersetzte der letzte Schreiber stillschweigend die Notizen des anderen.

  • Mehrere Sessions auf einem Server: Eine Session hält, was ihre Befehle geändert haben (einen Dienst, eine Datei oder ein Verzeichnis, den Paketmanager, den ganzen Host), eine Viertelstunde lang, und zwei Stunden, solange sie noch arbeitet. Ein Befehl einer anderen Session, der dort hineingreift, wird einer Person vorgelegt, auch auf „alles allein“ und was immer ein Plan oder eine Dauerfreigabe sagt, und seine Karte nennt, wer was hält. Eine Änderung, deren Ziel sich dem Befehl nicht ablesen lässt, gilt als Zugriff auf alles. Lesen wird nie aufgehalten.

  • Vier Augen: Wo ein Mandant keine zwei Personen hat, die zusammen freigeben könnten (eine, die freigibt, eine andere, die die zweite Freigabe geben darf), wartet ein unumkehrbarer Befehl nicht mehr auf eine zweite Freigabe, die niemand geben könnte. Eine Freigabe entscheidet; die Karte des Befehls, das Audit-Protokoll und die Compliance-Seite sagen das.

  • Classifier: apt-get -s autoremove und die anderen simulierten Entfernungen von apt und aptitude gelten als Lesen, wie simulierte Installationen schon zuvor.

  • Serverliste: Jeder erreichte Host zeigt Last, Speicher, Temperatur und die vollste Platte, abgefragt alle 30 Sekunden, solange die Liste offen ist. Eine Abfrage je Host versorgt jede offene Liste und Seite.

  • Wer auf einem Server arbeitet: Die Serverliste und die Seite des Servers nennen die Sessions, die dort laufen oder auf Freigabe warten, und die, die in der letzten Viertelstunde etwas geändert haben. Eine Session erfährt dasselbe über ihren eigenen Server mit jedem Schritt.

  • Serverseite: Last, Speicher, Temperatur und Platten des Hosts, alle fünf Sekunden gelesen, solange die Seite offen ist. Abgefragt über die SSH-Verbindung des Servers, von node_exporter, wo einer auf dem Host lauscht, und aus /proc und /sys, wo keiner läuft; nichts zu installieren, kein Port zu öffnen.

  • Kundenportal: eine Rolle, die eine Gruppe von Servern sieht und sonst nichts vom Mandanten: die Server, offene Befunde, den Monat in Zahlen und die Arbeit als Zusammenfassungen und Änderungsnachweise (#61).

  • API: Tokens je Mandant (mit Bereichen, widerrufbar, protokolliert) für Server, Sessions, Freigaben, Befunde und Zeitpläne unter /api/v1/<tenant>, und ein kleiner Befehl heinzel obendrauf (cli/heinzel). Ein Token lehnt einen Befehl ab und gibt nie einen frei (#37).

  • Rollouts: eine Aufgabe auf vielen Servern. Sie läuft auf dem ersten als Canary; nach dem Go einer Person läuft sie auf den anderen, wo ein auf dem Canary freigegebener Befehl nicht noch einmal fragt (#1).

  • Verwaltete Dateien: Ein Mandant nennt die Dateien, die sein Konfigurationsmanagement schreibt; der Agent erfährt es, eine Änderung von Hand wird mit dem Hinweis verweigert, wohin die Änderung gehört, und eine Datei, die selbst sagt, dass sie verwaltet ist, wird erkannt (#53).

  • Anhänge: Das Nachrichtenfeld einer Session nimmt Screenshots, PDFs und Textdateien über die Dateiauswahl, durch Ablegen und Einfügen; sie liegen je Mandant in der Datenbank und gehen als das, was sie sind, an das Modell (#152, #44).

  • Dateiänderungen: Der Agent schreibt eine Datei mit einem eigenen Werkzeug, und die Befehlskarte zeigt den Unterschied zum Bestehenden; eine Kopie der alten Datei bleibt daneben liegen (#18).

  • Pläne: Für eine Aufgabe mit mehreren Schritten schreibt der Agent einen Plan (Ziel, genaue Befehle, Risiken, Rücknahme), den eine Person als Ganzes freigibt; seine Befehle laufen dann je einmal, wie geschrieben, alles andere fragt für sich (#11).

  • Hosts, auf denen sudo ein Passwort verlangt: Das Serverformular bewahrt es auf, und ein Befehl mit sudo bekommt es auf dem Host an sudo gereicht, außerhalb der Befehlszeile und in der Ausgabe geschwärzt (#35).

  • Geheimnisse: Ein Mandant hinterlegt Passwörter und Tokens unter einem Namen; der Agent schreibt $HEINZEL_SECRET_NAME in einen Befehl, der Wert wird auf dem Host gesetzt und in der Ausgabe geschwärzt, und ein solcher Befehl wartet immer auf eine Person (#19).

  • Backups: Ein Mandant nennt die Verzeichnisse, in denen seine Backups landen; jedes wird einmal am Tag auf eine Datei geprüft, die jung ist und etwa so groß wie die davor, und alles andere wird ein Befund (#48).

  • Kontrollen: eine Seite, die die Schutzmaßnahmen des Produkts ISO/IEC 27001:2022 Anhang A, den Common Criteria von SOC 2 und dem BSI IT-Grundschutz zuordnet, mit dem Stand im Mandanten und dem Ort des Nachweises (#54).

  • Die Richtlinie als Datei: Autonomie, Vier-Augen-Regel, Teilen, Zeitlimits, Sperrliste und Dauerfreigaben eines Mandanten als JSON mit einem Hash; ein Import zeigt, was sich ändern würde, bevor er angewendet wird (#56).

  • Sicherheit: Befehle, die eine Datei schreiben oder ein Programm starten können, obwohl ihr Name auf der Leseliste steht (sed-Skripte mit e oder w, tar mit einer Checkpoint-Aktion, find -fprint, openssl -out, git --output und -c, Datenbank-Clients, die eine Shell erreichen, Prozesssubstitution), gelten nicht mehr als Lesen und verlangen eine Freigabe (#150). Eine zweite Runde schließt weitere: Clients, die jedes Wort ausführen, das sie bekommen, erlaubte Optionen neben ändernden, Kurzformen, Dateien, die an einen anderen Host gehen, und Variablen oder Pfade vor einem Befehl (#153).

  • Ein Modell kann ein stärkeres nennen: Eine Session, die auf dem günstigen Modell begonnen hat, übergibt der Agent, wenn die Aufgabe schwer ist, oder eine Person, und die Seite zeigt, was jedes Modell getan hat (#29).

  • Jeder ändernde Befehl wird mit seiner Rücknahme vorgeschlagen, die auf seiner Karte steht, und eine Session bietet Zurückrollen an: die Rücknahme-Notizen, die neueste zuerst, als Aufgabe einer neuen Session, die eine Person liest und abschickt (#17).

  • Zertifikate: Ein Mandant listet Hostnamen, jeder wird einmal am Tag von einem seiner Server aus geprüft, und einer, der binnen dreißig Tagen abläuft, wird ein Befund, kritisch in der letzten Woche (#42).

  • Ein Alarm aus dem Monitoring (der Webhook von Alertmanager, oder Host, Titel und Text) startet auf dem genannten Server eine Session, die nur lesend nachsieht; ein Token je Mandant, und eine Grenze pro Stunde (#7). Eine solche Session schreibt keine Notizen über irgendeinen Server, ein geplanter Lauf nur über seinen eigenen (#147).

  • Ein Modell kann ein anderes nennen, das einen Schritt beantwortet, wenn sein Anbieter ausfällt; die Session vermerkt den Wechsel, und das Audit-Protokoll hält ihn fest (#30).

  • Befehle, die etwas ändern, werden in den Graphen des Monitorings als Annotationen markiert (API von Grafana): Host, Befehl, wer freigegeben hat (#52).

  • Eine Session gibt den Entwurf eines Vorfallsberichts heraus: die Zeitleiste aus dem Audit-Protokoll, die Befehle, die Zusammenfassung des Agenten, und die Teile, die ein Mensch schreiben muss, als TODO markiert (#49).

  • Die Seite eines Servers gibt eine Übergabe heraus: was der Server ist, wie man hineinkommt, die Notizen des Agenten, was offen ist, das Journal, seine Sessions und seine Zeitpläne, als Markdown (#23).

  • Ein Server lässt sich über einen Sprungserver erreichen, einen anderen Server des Mandanten, wie mit ProxyJump: jeder mit eigenem Schlüssel und festgehaltenem Host-Key (#34). Eine Änderung an einem Sprungserver beendet die Verbindungen, die durch ihn laufen (#144).

  • Befunde: Was geplante Prüfungen und Sessions als falsch finden, steht auf einer eigenen Seite, bis ein späterer Lauf es nicht mehr sieht oder jemand es schließt, mit einer Person, die es übernimmt, und einer Session, die es behebt (#6). Eine Session hält Befunde nur für ihren eigenen Server fest (#141, #142).

  • Ein Zeitplan kann Tags statt eines Servers nennen: Er läuft dann auf jedem Server, der sie trägt, vier zugleich, und schickt einen Bericht mit den Hosts, die zuerst jemanden brauchen (#3). Ein Lauf, den der Not-Aus, das Budget oder die Lizenz abbricht, sagt das und startet keine weiteren Hosts (#140).

  • Eine Session endet mit der Zusammenfassung des Agenten (geändert, geprüft, noch offen, Weg zurück) oben über dem Verlauf, im Änderungsnachweis und, als Zahl offener Punkte, in der Liste; offene Punkte kommen auf das To-do des Servers (#26).

  • Die deutsche Oberfläche zeigt die eigenen Validierungsmeldungen der Anwendung auf Deutsch; 27 davon waren englisch (#137).

  • Die Zusammenfassung einer Session behält einen Rücknahmeschritt, wie er geschrieben wurde, und vergleicht offene Punkte mit ganzen Einträgen des To-dos (#138); die Befehlspalette öffnet nicht mehr einen Treffer der vorigen Suche (#139).

  • Server tragen Tags (env:prod, role:db); die Serverliste filtert danach, und der Agent sieht sie, wenn er Server auflistet (#2).

  • Eine Befehlspalette auf Strg+K (Cmd+K) springt zu Seiten, Servern, Sessions und Zeitplänen nach Namen und bietet die wichtigsten Aktionen der aktuellen Seite an (#40).

  • Die Audit-Ereignisse eines Mandanten gehen an einen HTTPS-Endpunkt, sobald sie geschrieben sind, je eine Zeile JSON mit Position und Hash in der Kette; was der Endpunkt nicht annimmt, wird jede Minute erneut versucht (#32).

  • Ein Monatsbericht je Mandant für seine Administratoren: Sessions und Befehle, nach Server, wer freigegeben und abgelehnt hat, und was die Modelle gekostet haben (#27).

  • Die Serverseite sagt, was sich in der letzten Woche geändert hat: System, Kernel, Füllstand der Root-Platte, ein Neustart, und seit wann einer aussteht (#5).

  • Befehlsausgabe, die sich wie Anweisungen an den Agenten liest, wird dem Modell vorenthalten; die Karte sagt das, und wer in die Session schreiben darf, kann sie durchlassen (#58).

  • Die ganze Ausgabe eines Befehls lässt sich von seiner Karte als Textdatei herunterladen (#44, erste Hälfte).

  • Ein Modellanbieter trägt, wo er Daten verarbeitet (EU, USA, eigenes Netz), die Angabe steht überall, wo ein Modell gewählt wird, und ein Mandant kann einen Ort verlangen; Anbieter ohne diese Angabe sind dann nicht wählbar (#57).

  • Ein Server mit leerem Gedächtnis bekommt seine ersten Notizen vom Host, sobald ein Verbindungstest gelingt: laufende Dienste, Platten, was lauscht, und ob sudo ein Passwort verlangt (#45).

  • Die zweite Freigabe eines unumkehrbaren Befehls verlangt eine Anmeldung, die höchstens fünf Minuten alt ist (#21).

  • Ein Monatsbudget für Modellaufrufe je Mandant: eine Warnung bei 80 %, keine neue Arbeit bei 100 %, und die Ausgaben gegen das Budget auf der Übersicht (#28).

  • Eine Wochenmail je Mandant mit dem, was liegen geblieben ist: offene To-dos auf Hosts, was geplante Läufe übersprungen haben, Zeitpläne, die fehlschlugen oder pausiert wurden, Server, die neunzig Tage nicht erreicht wurden. Ein neues Benachrichtigungsereignis zum Einschalten; eine Woche, in der es nichts zu sagen gibt, schickt nichts (#51).

  • Server werden in Menge importiert, aus einer eingefügten Liste, einer CSV, einer ssh config oder einem Ansible-Inventar, mit einem Skript, das die Schlüssel auf die Hosts bringt (#36).

  • Eine Session exportiert einen Änderungsnachweis als Markdown: wer gefragt hat, was vorgeschlagen wurde, wer entschieden hat, wie es ausging, und die Position und der Hash jedes seiner Einträge in der Audit-Kette (#31).

  • Eine Freigabe, die länger wartet als eine Zeit, die der Mandant festlegt, wird einmal eskaliert, als eigenes Benachrichtigungsereignis, und ihre Karte sagt das (#10).

  • Wartungsfenster je Server: Außerhalb liest Heinzel dort nur, wer auch immer fragt und auf welcher Stufe auch immer, auch für einen Befehl, der freigegeben wurde, als das Fenster noch offen war (#43).

  • Eine Session, in der Heinzel etwas geändert hat, ohne dass jemand es freigegeben hat, wird nachträglich von einer zweiten Person gezeichnet, einzeln oder alle auf einmal; die Unterschrift steht im Audit-Protokoll, und die Übersicht zählt, was wartet (#59).

  • Eine Zugriffsüberprüfung je Mandant, von der Seite Benutzer aus: wer fragen und freigeben kann, wer Heinzel allein arbeiten lässt, wer sich ein Quartal lang nicht angemeldet hat, wer keinen zweiten Faktor hat; ein Administrator bestätigt sie, und die Bestätigung steht im Audit-Protokoll (#55).

  • Dauerfreigaben: Ein Administrator listet Befehle, die immer in Ordnung sind, auf jedem Server, einem Server oder einer Gruppe. Ein exakter Treffer läuft ohne Person und wird so protokolliert; unumkehrbare Befehle, die Sperrlisten, Nur-Lese-Server und geplante Läufe bleiben unberührt (#12).

  • Ein Wissen je Mandant: kurze Notizen, wie die Dinge hier gemacht werden, die jede Session beim Start neben dem Gedächtnis ihres Servers liest (#22).

  • Suche, in der Navigation: Sessions nach Titel und nach dem, was darin gesagt wurde, Befehle nach Text und Host, und die Journale der Server, innerhalb dessen, was die Person lesen darf (#25).

  • Die Serverliste zeigt, was über jeden Host bekannt ist (System, Laufzeit, Füllstand der Platten, ein ausstehender Neustart), gesammelt beim Verbindungstest, und lässt sich danach durchsuchen und sortieren; ein veralteter Wert sagt, wie alt er ist (#4).

  • Erhöhte Stufe auf Zeit: Ein Administrator hebt die Autonomie auf einem Server für eine gewählte Zeit an, mit einem Grund. Es wird protokolliert, die Administratoren erfahren es (ein neues Benachrichtigungsereignis zum Einschalten), und es endet von selbst (#16).

  • Die Karte eines wartenden Befehls sagt, was er auf seinem Host bedeutet: was der Host ist, wann derselbe Befehl dort zuletzt lief und wie er ausging, und was die Notizen des Hosts über das sagen, was er berührt (#50).

  • Eine Bibliothek gespeicherter Aufgaben je Mandant: ein Prompt mit Lücken wie {domain}, gestartet auf einem Server mit ausgefüllten Lücken, mit der Zahl seiner Läufe und seiner letzten Session (#24).

  • Was ein geplanter Lauf ändern wollte und überspringen musste, wartet eine Woche auf der Seite Freigaben, mit der Begründung des Laufs: in eine eigene Session übernehmen oder verwerfen (#47).

  • Die Seite Freigaben fasst denselben Befehl, der auf mehreren Hosts wartet, zusammen und gibt die Gruppe auf einmal frei oder lehnt sie ab; jeder Befehl wird weiter für sich geprüft und protokolliert (#62).

  • Server, die im selben Moment angelegt werden, können die Zahl, die die Lizenz erlaubt, nicht mehr überschreiten (#122).

  • Ein Zeitplan, der keine Stunde nennt (alle fünf Minuten, jede Stunde), läuft durch die Stunde, in der die Uhren im Herbst zurückgestellt werden, statt dafür zu pausieren (#120).

  • Die Benutzerseite sagt, wenn ein Anmeldelink oder eine Einladung nicht verschickt werden konnte, statt Erfolg zu melden, und der Bericht oder die Pausenmeldung eines Zeitplans, die nicht hinausging, wird erneut versucht, je Empfänger (#121).

  • Zwei-Faktor-Codes, die im selben Moment geschickt werden, werden einzeln gezählt, so dass ein Schwall nicht mehr Codes prüft, als die Grenze erlaubt (#118).

  • Eine Sperrregel als Muster sperrt einen Befehl, für den sie sich nicht entscheiden lässt, statt einen aufgefüllten Befehl durchzulassen (#119).

  • Der Not-Aus hält, wo er es nicht tat: Ein Befehl, der hinter einem anderen auf demselben Host wartete, läuft nicht mehr, sobald der erste abgebrochen ist, eine fehlgeschlagene Session lässt sich nicht wiederholen, ein wartender geplanter Lauf wird verworfen, ohne eine Session zu hinterlassen, und der Schalter wird aus der Datenbank gelesen, so dass ein zweiter Knoten ihn sieht. Ein Befehl, der mitten im Lauf abgebrochen wurde, gilt als unbekannt statt als nie gelaufen (#117).

  • Die Einstellungen haben ein Feld, um einen Befehl gegen die Richtlinie zu prüfen: seine Klasse, den Grund, und was auf einem Server auf jeder Autonomiestufe und in einem geplanten Lauf geschähe. Nichts wird ausgeführt (#15).

  • Die Übersicht sagt, was einen Menschen braucht: Freigaben mit dem Alter der ältesten, Sessions und geplante Läufe, die am letzten Tag fehlschlugen, Zeitpläne, die Heinzel pausiert hat, Hosts, die nicht bereit sind, und die ersten Schritte für einen Mandanten, der noch nicht begonnen hat (#41).

  • Die Serverliste sagt, was auf jedem Host noch einzurichten ist (Schlüssel nicht eingetragen, letzter Kontakt fehlgeschlagen, nichts bekannt, eine Woche nicht erreicht, kein Zeitplan) und filtert nach den Hosts, die nicht bereit sind (#46).

  • Ein Mandant hat eine eigene Sperrliste (Einstellungen, Allgemein): Befehle, die Heinzel dort nie ausführt, überall, auf einem Server oder auf einer Gruppe, in Worten oder als regulärer Ausdruck. Geprüft beim Vorschlag eines Befehls und noch einmal direkt vor dem Ausführen (#13).

  • Ein Not-Aus je Mandant (Einstellungen, Allgemein) und einer für die Installation (Mandanten): Er stoppt jede Session, bricht laufende Befehle ab, nimmt wartende zurück und lässt die Zeitpläne ruhen, bis er aufgehoben wird, mit wer und warum im Audit-Protokoll und einem Banner auf jeder Seite (#60).

  • Die Seite Freigaben zeigt, wofür ein wartender Befehl ist: die Aufgabe und die Befehle davor mit ihrer Ausgabe, für Sessions, die der Freigebende lesen darf (#14).

  • Eine laufende Session lässt sich von ihrer Seite aus anhalten. Der Befehl, der gerade läuft, läuft zu Ende, nichts Weiteres startet, ein Befehl, der auf Freigabe wartete, wird zurückgenommen, und das Protokoll sagt, wer sie angehalten hat und warum (#20).

  • Behoben: Der Link in einer Alarmmail oder Chat-Nachricht öffnet die Session wieder (#68).

  • Behoben: Lange Ausgabe mit Umlauten, oder Ausgabe, die gar kein UTF-8 ist, lässt die Session nicht mehr scheitern; sie wird zwischen Zeichen gekürzt und mit ersetzten fehlerhaften Bytes gespeichert (#66).

  • Behoben: Ein Befehl, der nie aufhört zu drucken (tail -f, ping), wird nach Ablauf seines Zeitlimits beendet und blockiert seinen Server nicht mehr (#63).

  • Behoben: Nach dem Neustart eines Hosts öffnet der nächste Befehl eine neue Verbindung, statt zehn Minuten lang zu scheitern (#64).

  • Behoben: Ein Server, dessen Hostname, Port oder SSH-Benutzer sich geändert hat, führt seinen nächsten Befehl dort aus, nicht über die Verbindung zur alten Adresse (#65).

  • Behoben: Ein Befehl, der hinter einem anderen auf demselben Server wartet, wird nicht mehr als fehlgeschlagen gemeldet, während er noch läuft (#70).

  • Behoben: Zwei Server mit einem Hostnamen auf verschiedenen Ports lassen nicht mehr jeden Befehl abstürzen; der Agent nennt sie host:port (#67).

  • Behoben: Das Zeitlimit, das Heinzel für einen langen Befehl (ein Upgrade) anfragt, wird eingehalten, bis zu einer neuen Einstellung, 3600 s als Vorgabe, und dem gezeigt, der den Befehl freigibt (#69).

  • Behoben: Ohne gültige Lizenz hinterlässt ein fälliger Zeitplan nicht mehr bei jedem Versuch eine leere Session; der Lauf wird einmal abgelehnt und protokolliert (#71).

  • Behoben: Ein Zeitplan, dessen Besitzer gegangen ist oder sein Modell verloren hat, wird mit dem Grund pausiert, und seine Empfänger erfahren es, statt einen nächsten Lauf zu zeigen, der nie kommt. Wer ihn wieder einschaltet, lässt ihn im eigenen Namen laufen (#72).

  • Behoben: Ein Zeitplan überspringt einen fälligen Zeitpunkt, solange sein voriger Lauf noch läuft, statt eine zweite Session darüber zu starten (#73).

  • Behoben: Das Entfernen eines Servers nennt die Zeitpläne, die mit ihm entfernt werden, in der Rückfrage und im Audit-Protokoll (#74).

  • Behoben: Eine zu große Zahl oder ein Organisationsname über 255 Zeichen ist ein Fehler am Feld der Einstellungen, kein Absturz mehr, und eine geleerte Zahl ist ein Fehler statt einer stillen Rückkehr zur Vorgabe (#76, #91).

  • Behoben: Das Einladungsformular lehnt einen Namen über 120 Zeichen am Feld ab, statt abzustürzen, und sagt, wenn die Person schon Mitglied ist (#90, #94).

  • Behoben: Ein Webhook, der fehlschlägt, wird von selbst erneut versucht; die Alarmmail geht nicht mehr mit jedem Versuch erneut hinaus (#78).

  • Behoben: Eine Session lässt sich nicht ohne Server starten, was auch immer das Formular schickt (#97).

  • Behoben: Alarmadressen werden geprüft wie der Webhook daneben, und die, die keine Adresse ist, wird genannt (#96).

  • Behoben: Ein zweiter Mandant mit einem Namen, den es gibt, wird angelegt, unter einem eigenen nummerierten Link, statt wortlos zu scheitern (#95).

  • Behoben: Das Audit-Protokoll filtert nach einem Zeitraum, den die Seite jetzt anbietet, und der CSV-Export wird in Stücken gesendet, statt im Speicher gebaut zu werden (#80).

  • Behoben: Das Leeren des Felds für den Lizenzschlüssel entfernt die Lizenz, statt das Formular abstürzen zu lassen (#88).

  • Behoben: Die Anmeldebegrenzung vergisst eine Adresse, sobald ihre Minute vorbei ist, statt jede zu behalten, solange der Knoten läuft (#87).

  • Behoben: Die zu lange offene Kontoseite schickt Sie zur Anmeldung, wenn Sie Adresse oder Passwort ändern, statt abzustürzen (#86).

  • Behoben: Ein Anmeldelink für ein Konto mit Passwort und unbestätigter Adresse bestätigt die Adresse und meldet an, statt abzustürzen; das traf den ersten Administrator jeder Installation (#92).

  • Behoben: Der Link in einer Einladung gilt sieben Tage, nicht fünfzehn Minuten, und die Mail sagt, wer in welchen Mandanten einlädt und bis wann (#83).

  • Behoben: Die Anmeldebegrenzung und das Audit-Protokoll glauben nicht mehr der Adresse, die ein Client in X-Forwarded-For schreibt; sie nehmen den Eintrag, den Ihr eigener Proxy angehängt hat. Neue Einstellung TRUSTED_PROXIES, siehe installation.md (#115).

  • Behoben: Ein Server lässt sich über seine IPv6-Adresse anlegen; mit Port nennt der Agent ihn [address]:port (#82).

  • Behoben: Arbeit in einer offenen Seite zählt gegen die Abmeldung nach Untätigkeit; ein Tag in einem Tab endet nicht mehr mit der Abmeldung (#81).

  • Behoben: Ohne SMTP_HOST ist eine Mail ein Fehler im Log und eine Warnung auf der Übersicht des Administrators, nicht mehr angenommen und verworfen (#77).

  • Behoben: Ein Administrator ohne Modell wird zu den Modelleinstellungen geschickt, statt gebeten zu werden, einen Administrator zu fragen (#108).

  • Behoben: Eine Seite, die jemand nicht benutzen darf, sagt das überall mit denselben Worten (#114).

  • Behoben: Ein Betrachter kommt nur zum Lesen in eine Session; die Leiste Personen bietet kein Schreiben mehr an, das die Rolle zurücknähme (#103).

  • Behoben: Ein Server, der nicht erreichbar ist, sagt in Worten, warum („der Hostname wurde nicht gefunden“), statt in Erlang-Begriffen, und der Knopf sagt, dass er testet (#98).

  • Behoben: Der Kopf der Serverseite zeigt die erste Zeile einer langen Beschreibung und den Rest darunter, statt alles auf einmal (#111).

  • Behoben: Die Annahme der Einladung in den einzigen Mandanten führt hinein, nicht in eine Liste mit einem Eintrag; eine geänderte Sprache wird in dieser Sprache bestätigt (#112).

  • Behoben: Die Mail über einen fehlgeschlagenen geplanten Lauf nennt den Fehler einmal, die Liste der Zeitpläne zeigt den nächsten Lauf ohne Sekunden, und „Jetzt ausführen“ läuft im Namen dessen, der es drückt (#107).

  • Behoben: Ein neues Konto übernimmt bei der ersten Anmeldung die Sprache des Browsers, so dass ein deutscher Browser keine englische Anwendung mehr bekommt (#105).

  • Behoben: Die Zahl der Server, die eine Lizenz nennt, wird beim Anlegen eines Servers durchgesetzt und auf der Lizenzseite gezeigt; eine Lizenz ohne Zahl hat keine Grenze, wie bisher (#89).

  • Behoben: Das Audit-Protokoll nennt seine Aktionen in der Sprache des Lesers und zeigt Details als Wörter; die gespeicherten Schlüssel bleiben, was Filter und Exporte benutzen (#100).

  • Behoben: Eine Session nimmt keine weitere Nachricht an, solange einer ihrer Befehle auf eine Entscheidung wartet; eine solche Nachricht ließ die Session scheitern, während der Befehl noch wartete (#99).

  • Behoben: Eine fehlgeschlagene Session sagt, was passiert ist und wer es beheben kann, über den Worten des Anbieters, und Wiederholen sagt, dass es versucht hat (#102).

  • Behoben: Eine Seite, die es nicht mehr gibt, ist eine Seite der Anwendung, die das sagt und zurückführt, und das Audit-Protokoll verlinkt nur, was sich noch öffnen lässt (#104).

  • Behoben: Freigeben und Ablehnen, Gedächtnis speichern, eine Notiz anlegen, einen Benutzer deaktivieren und einen Link zurücknehmen sagen jeweils, was passiert ist; eine leere Notiz wird abgelehnt statt ignoriert, und das Zurücknehmen eines Links fragt vorher (#106).

  • Behoben: Mails an ein Konto sind in der Sprache dieser Person geschrieben, ein Anmeldelink heißt nicht mehr „Confirmation instructions“, und die Seite, zu der er führt, hat keinen unübersetzten Hinweis (#101).

  • Behoben: Die Übersicht wird nicht mehr breiter als ein Handy, wenn eine Session einen langen Titel hat; derselbe Fehler ist auf zwölf weiteren Rastern geschlossen (#93).

  • Behoben: Die Reiter der Einstellungen brechen auf dem Handy um, statt über den Rand zu laufen (#109).

  • Behoben: Auf dem Handy ist das Audit-Protokoll eine Zeile je Ereignis, mit den Details hinter einem Tipp, statt einer Karte mit zehn Zeilen je Eintrag (#110).

  • Behoben: Der Gedächtnis-Editor behält, was Sie tippen, wenn Heinzel in dasselbe Gedächtnis schreibt, sagt, dass es sich geändert hat, und überschreibt diese Änderung nicht mehr ungefragt (#84).

  • Behoben: Alarme an Teams gehen als Adaptive Card hinaus, das Format eines mit Workflows angelegten Webhooks; nicht gegen ein echtes Teams geprüft (#79).

  • Behoben: Das Einrichten der Zwei-Faktor-Anmeldung gibt zehn Recovery-Codes heraus, jeder gut für eine Anmeldung ohne das Handy; ein verlorenes Handy sperrt den letzten Administrator nicht mehr aus. Ein- und Ausschalten wird einmal protokolliert (#85).

  • Behoben: Fünf falsche Zwei-Faktor-Codes pausieren den zweiten Schritt dieses Kontos für fünfzehn Minuten und alarmieren seine Mandanten; Rateversuche waren nur je Adresse begrenzt (#116).

  • Behoben: Ein Mandant hat eine Zeitzone. Zeitpläne laufen danach, durch Sommer- und Winterzeit, und jede Zeit auf dem Bildschirm wird darin gezeigt. Bestehende Mandanten bleiben auf UTC, bis ein Administrator wählt (#75).

  • Behoben: Die nicht geöffneten Reiter der Einstellungen sind im hellen Modus lesbar (Kontrast 6,2:1 statt 3,3:1) (#113).

2.7.0 (2026-10-08)

  • Ein Anbieter bietet mehrere Modelle an: ein Konto, ein Schlüssel, und die Modelle angekreuzt aus denen, die Heinzel Pro kennt, oder nach ID eingetippt. Ein neuer Schlüssel erreicht jedes Modell des Anbieters.
  • Jedes Modell hat eine eigene Seite für Aufwand, Preise und wer es nutzen darf; die Liste der Modelle ist nach Anbieter gruppiert.
  • Upgrade: Jeder bestehende Anbieter wird ein Anbieter mit einem Modell.

2.6.0 (2026-10-08)

  • Arbeiten in mehreren Mandanten: Eine Anmeldung bleibt in ihrem Mandanten, bis ihr Inhaber wechselt. Eine in einem Mandanten gerenderte Seite verbindet sich nicht mehr in einen anderen (mit ihrem halb ausgefüllten Formular), ein Mandant, der jemandem geschlossen ist, schickt ihn zur Auswahl, statt ihn woandershin zu tragen, ein Link, der einen Mandanten nennt, sagt das und wird protokolliert, und eine geänderte Rolle in einem Mandanten lässt die Seiten eines anderen in Ruhe.
  • Der Audit-Export enthält eine Kette: Die Datei eines Mandanten enthält das Protokoll der Installation nicht mehr. Administratoren der Installation exportieren dieses getrennt.
  • Gemeinsam genutzte Hosts: Ein Server nimmt Heinzels Übergabenotizen in sein Systemjournal nur, wenn sein Formular das sagt; neue Server tun es nicht, und ein solcher Befehl wird dann im Code abgelehnt. Der Schlüsselkommentar in authorized_keys trägt nicht mehr den Namen eines gemeinsamen Schlüssels.

2.5.1 (2026-10-08)

  • Konversationen heißen Sessions, in der Oberfläche und in den Docs. Die Adressen (/conversations/…) und die Namen im Audit-Protokoll bleiben.
  • Das Teilen ist in die Session gezogen: Personen zeigt, wer dabei ist, und der Besitzer holt einen Kollegen oder eine Gruppe hinzu, ändert ihre Stufe oder sperrt sie aus, einzeln und sofort. Die eigene Seite zum Teilen ist weg; die Vorgabe für neue Sessions steht weiter unter Sessions, Freigaben.

2.5.0 (2026-10-08)

  • Mehrere Konversationen zugleich: Die Liste und eine Leiste neben der offenen Konversation zeigen, was jede gerade tut (braucht dich, beantwortet, arbeitet, bereit), live, mit dem, was Sie braucht, oben.
  • Ein Hinweis, wenn eine Ihrer Konversationen auf eine Freigabe wartet, fehlschlägt oder fertig ist: eine Zahl in der Navigation und im Titel des Tabs, und eine Browser-Benachrichtigung, wo Sie sie erlauben.

2.4.0 (2026-10-08)

  • Teilen: Eine Konversation gehört ihrem Besitzer und wird für alle im Mandanten, für Gruppen oder für Personen geöffnet, zum Lesen oder zum Schreiben. Ein Kollege mit Schreibrecht macht weiter, wo der Besitzer aufgehört hat, oder übernimmt die Konversation.
  • Jede Nachricht zeigt, wer sie geschickt hat; Teilen, Links und Übernehmen stehen im Audit-Protokoll, das auslässt, was in Konversationen geschah, die der Leser nicht öffnen darf.
  • Ein Link lässt Menschen ohne Konto eine Konversation für begrenzte Zeit lesen, mit ausgelassenen Namen und geschwärzten Geheimnissen. Aus, bis ein Administrator es erlaubt.
  • Vorgaben je Mandant und je Mitglied, mit wem neue Konversationen geteilt werden.
  • Upgrade: Bestehende Konversationen und die Vorgabe des Mandanten bleiben für alle Mitglieder offen, wie bisher.

2.3.0 (2026-10-08)

  • Wie viel Heinzel allein tut, in drei Stufen: jeden Befehl fragen, Lesen allein, alles allein (Vollautomatik). Gesetzt als Obergrenze je Mandant durch die Installation, als Vorgabe je Mandant, je Gruppe, je Server (nur von Administratoren angehoben) und je Konversation; das Niedrigste zählt, für den Besitzer und für den, der die Nachricht geschickt hat. Ein Befehl aus mehreren Teilen läuft nur allein, wenn jeder Teil es darf.
  • Classifier: sudo -n … und Befehle neben einem Here-Document rutschen nicht mehr an der Sperrliste vorbei. -n und -s gelten nur dort als Probelauf, wo der Paketmanager das so meint. awk, rpm, sort, uniq, nvme, journalctl, date, hostname, ss, dmesg, ifconfig und andere gelten nur mit Argumenten, die nur lesen, als nur lesend.
  • Aufwand je Modell: Ein Anbieter listet die Stufen, die er anbietet, und jedes Mitglied, eine Gruppe oder eine Person darf bis zu einer gesetzten gehen.
  • Modellkatalog: Das Anbieterformular bietet bekannte Modelle an und füllt ihre Aufwandstufen aus. Der Hersteller signiert zwischen Releases einen neueren Katalog (mix heinzel.catalog sign); ein Administrator der Installation fügt ihn unter Einstellungen, Lizenz ein. Aus dem Netz wird nichts geholt.
  • Upgrade: „Nur Lesen automatisch“ wird „Lesen allein“; die Obergrenze jedes Mandanten beginnt dort. Operatoren können nicht mehr anheben, was ein Server allein ausführt. Migration 20261008124115 lässt sich nicht zurückrollen.

2.2.0 (2026-10-08)

  • Das Starten einer Konversation fragt nach Modell und Aufwand. Das Modell wird immer gezeigt, mit der Vorgabe vorausgewählt, damit klar ist, was antworten wird. Der Aufwand ist Standard (wie der Anbieter eingerichtet ist), Niedrig, Mittel oder Hoch, dieselben Wörter für jede Art von Anbieter; die Seite der Konversation zeigt, was gewählt wurde. Ein Anbieter kann die Wahl für einen Server abschalten, der die Einstellung nicht kennt. Migration 20261008123128.

2.1.0 (2026-10-08)

  • Mehrere Modellanbieter je Mandant, jeder mit eigenem Namen, Modell und Schlüssel. Ein Anbieter steht jedem Mitglied offen oder ist auf Gruppen und Personen beschränkt; einer ist der Standard. Wer mehrere nutzen darf, wählt beim Start einer Konversation, und ein Zeitplan kann einen nennen.
  • Gruppen: benannte Mengen der Mitglieder eines Mandanten, verwaltet unter Verwaltung, so dass Zugriff je Team vergeben wird statt Person für Person.
  • Der Zugriff wird im Kern durchgesetzt, beim Anlegen einer Konversation und wieder mit jeder Nachricht. Eine Konversation behält ihren Anbieter; wird er abgeschaltet oder entfernt oder der Zugriff entzogen, endet sie dort, und kein anderes Modell übernimmt.
  • Modell und Kosten in der Liste der Konversationen und auf der Seite der Konversation. Ein Anbieter kann die Preise tragen, die sein Mandant je Million Tokens zahlt; jeder Modellaufruf wird dann im Moment des Aufrufs bepreist, mit gecachter Eingabe getrennt von frischer. Nichts wird geschätzt: Ohne eingetragene Preise, und für Konversationen von vor diesem Release, werden keine Kosten gezeigt.
  • Ein Zeitplan läuft als sein Besitzer auf einem Anbieter, den der Besitzer nutzen darf; wer Aufgabe oder Modell ändert, wird Besitzer. Ein abgelehnter Lauf wird festgehalten und abgebrochen. Eine fehlgeschlagene Konversation zu wiederholen braucht das Recht, Konversationen zu führen.
  • Upgrade: Das eingestellte Modell wird der erste Anbieter, offen für alle. Migration 20261008120857 lässt sich nicht zurückrollen; 20261008122252 ergänzt Preise und Kosten.

2.0.2 (2026-10-08)

  • Ein Durchgang über jede Seite in Desktop- und Handybreite, hell und dunkel:
    • Mandanten: „Sie sind hier“ steht in der Spalte für den Zustand statt neben der Zeile der Knöpfe. Reihen von Knöpfen und Marken sind überall zentriert.
    • Benutzer: Die Liste behält Bearbeiten und Entfernen; Anmeldelink schicken, zweiten Faktor zurücksetzen, Passkeys entfernen, Installationsrechte und die Sperre sind auf die Seite des Benutzers gezogen, wo sie nicht mehr in zwei Zeilen umbrechen.
    • Zeilen kleiner Angaben (Host, Person, Zeit) brechen zwischen den Angaben um und beginnen nicht mehr mit einem verirrten Punkt.
    • Serverseite: Der Algorithmus und „Schlüssel erneuern“ sind ein Element; der Hinweis „beim ersten Verbinden festgehalten“ bricht nicht mehr mitten im Wort um.
    • Audit-Protokoll: Ereignisse der Installation sind markiert, und die Details stehen unter der Aktion, statt aus der Tabelle zu laufen.
    • Die Reiter der Einstellungen bleiben auf dem Handy in einer Zeile; die Checkbox des Zeitplanformulars steht in der Flucht; Alarme sind auf dem Handy zentriert.

2.0.1 (2026-10-08)

  • Jeder Schlüssel ist eine UUID v7, und die Datenbank setzt das jetzt durch: Migration 20261008103455 ergänzt bei jeder Tabelle eine Prüfung der Version von id. Die Anwendung hat seit 1.0.0 nichts anderes erzeugt. Sollte eine Tabelle doch einen Schlüssel einer anderen Version halten, läuft das Upgrade trotzdem; die Prüfung gilt dann nur für neue Zeilen, und das Log nennt die Tabelle.
  • Mandanten, nach einer zweiten Durchsicht von 2.0.0:
    • Das Rotieren des Vault-Schlüssels scheiterte an der ersten Mandantentabelle; es schreibt jetzt die Geheimnisse aller Mandanten neu.
    • Die Anmeldung nimmt keine Einladung an: Jede eingeladene Person sagt Ja auf der Seite, auf der sie landet. Eine offene Seite lädt neu, wenn sich Rolle oder Mitgliedschaft ihres Benutzers ändert, auch nachdem das Sitzungstoken erneuert wurde.
    • Das Formular zum Ändern der eigenen Adresse verrät nicht mehr, ob eine Adresse zu einem anderen Konto gehört. Das Anheben einer Rolle braucht einen freien Platz, auch wenn das Konto über einen anderen Mandanten einen hält.
    • Änderungen an Anmelderegeln, Single Sign-on und Lizenz stehen in der Audit-Kette der Installation. Ein Link, der einen Mandanten nennt, verbindet die im vorigen offen gelassenen Seiten neu. Der Mandant, in dem man steht, lässt sich nicht schließen.
    • Die Sperre für Abfragen lehnt Mandantentabellen auch in jeder verschachtelten Abfrage ab.
  • Die Demodaten für die Entwicklung funktionieren wieder mit Einladungen.

2.0.0 (2026-10-08)

  • Mandanten: Eine Installation bedient mehrere Kunden, Abteilungen oder Umgebungen. Jeder Mandant hat eigene Server, SSH-Schlüssel, Konversationen, Zeitpläne, ein eigenes Audit-Protokoll, einen eigenen Modellanbieter, eigene Richtlinien und Alarme; nichts davon ist aus einem anderen Mandanten sichtbar, weder für Menschen noch für den Agenten.
  • Konten gehören zur Installation, Rollen zu einem Mandanten. Eine Person mit mehreren Mandanten arbeitet in einem zur Zeit und wechselt oben in der Navigation. Administratoren der Installation legen Mandanten an, schließen sie und betreten jeden als Administrator.
  • Anmelderegeln, Single Sign-on und die Lizenz gelten für die ganze Installation und sind auf einen Reiter Anmeldung gezogen, den nur ihre Administratoren sehen. Nur sie ändern Adresse, Sperre, zweiten Faktor oder Passkeys einer anderen Person; der Administrator eines Mandanten setzt Rollen und entfernt Mitglieder.
  • Die Trennung wird unterhalb des Anwendungscodes durchgesetzt: Ein Prozess, der an keinen Mandanten gebunden ist, kann keine Mandantendaten lesen, und Fremdschlüssel tragen den Mandanten.
  • Einladungen brauchen das Ja der eingeladenen Person; bis dahin sieht der Mandant die Adresse und nichts vom Konto. Jeder Mandant hat eine eigene Audit-Kette; Anmeldungen werden für die Installation festgehalten. Eine geänderte Rolle, ein Entfernen oder ein geschlossener Mandant trennt die offenen Seiten.
  • Adressen, die der Server aufruft (Basis-URL des Modells, Webhook), legen nur die Administratoren der Installation fest. Das Sitzungscookie ist verschlüsselt.
  • Behoben: Ein Zeitplan, dessen Cron-Ausdruck keine Termine mehr hatte, stoppte alle geplanten Läufe; der Sitzungstest hing von der Tageszeit ab.
  • Links in Alarmen und Berichten nennen ihren Mandanten.
  • Die Rotation des Vault-Schlüssels verschlüsselt jetzt auch gemeinsame SSH-Schlüssel neu, die sie übersprang.
  • Upgrade: Bestehende Daten wandern in einen Mandanten, bestehende Administratoren verwalten auch die Installation. Die Migrationen 20261008094017 und 20261008095012 lassen sich nicht zurückrollen und melden jeden einmal ab; siehe docs/en/upgrade.md.

1.5.1 (2026-10-08)

  • Die Kontoseite, auf der Passkeys, der zweite Faktor und die Geräte liegen, ist ein Eintrag der Hauptnavigation („Konto und Anmeldung“) und wird hervorgehoben, solange sie offen ist. Vorher führte nur ein kleiner Knopf neben „Abmelden“ dorthin.

1.5.0 (2026-10-08)

  • Schlüsselalgorithmen: Der eigene Schlüssel eines Servers und ein gemeinsamer Schlüssel sind Ed25519 wie bisher, oder ECDSA (P-256, P-384, P-521) oder RSA 4096, wo ein Host oder eine Richtlinie es verlangt. Der Algorithmus wird beim Anlegen eines Schlüssels gewählt; eine Rotation behält ihn oder wechselt ihn. RSA-Schlüssel signieren nur mit SHA-2.
  • Kopierknöpfe: Die Schlüsselübersicht und jede Zeile mit einem öffentlichen Schlüssel kopieren die authorized_keys-Zeile in die Zwischenablage. Die Übersicht nennt auch den Algorithmus jedes Schlüssels.
  • Keine Migration: Der öffentliche Schlüssel hält den Algorithmus fest.

1.4.0 (2026-10-08)

  • Passkeys: Benutzer legen einen auf der Kontoseite an und melden sich danach mit Fingerabdruck, Gesicht oder Geräte-PIN an, ohne eine Adresse zu tippen. Der Authenticator muss seinen Benutzer prüfen, deshalb zählt ein Passkey als beide Faktoren und überspringt den TOTP-Code. Bis zu zehn je Benutzer; Administratoren entfernen die Passkeys eines Benutzers, wenn ein Gerät verloren geht.
  • Passkeys sind an die öffentliche Adresse gebunden (PHX_HOST, PHX_SCHEME). Sie brauchen HTTPS, oder localhost, und funktionieren nicht mehr, wenn sich die Adresse ändert.
  • Migration 20261008074304 ergänzt die Tabelle user_passkeys.

1.3.0 (2026-10-08)

  • Geräte: Die Kontoseite listet jeden Browser, in dem Sie angemeldet sind, mit System, Adresse und letzter Aktivität, und meldet einen davon oder alle anderen ab, von wo auch immer Sie sind. Ein irgendwo angemeldet gebliebenes Gerät braucht keine Passwortänderung mehr, um es loszuwerden.
  • Die Oberfläche funktioniert auf dem Handy: eine untere Leiste für Übersicht, Konversationen, Freigaben und Server, Tabellen, die zu Karten werden, Bedienelemente von mindestens 44 px Höhe, kein seitliches Scrollen.
  • Lesbar ohne Farbe: Jede Statusmarke trägt ein Symbol, Links sind unterstrichen, Text und Knöpfe erreichen einen Kontrast von 4,5:1 im hellen und im dunklen Thema. Geprüft mit simulierter Rot-Grün-Schwäche und in Graustufen.
  • Knöpfe, die eigene Klassen übergeben bekamen, verloren ihr Knopf-Styling, darunter beide Anmeldeknöpfe.
  • Migration 20261008073229 ergänzt die Sitzungstokens um Gerätespalten.

1.2.0 (2026-10-08)

  • SSH-Zertifizierungsstellen, nur lesend: Der Verbindungstest hält fest, welcher User-CA ein Host vertraut, wo Principals und Sperrlisten liegen und wann seine Host-Zertifikate ablaufen. Die Serverseite zeigt es und warnt 14 Tage, bevor ein Host-Zertifikat abläuft; der Agent bekommt eine passende Regel (ssh-certificates). Heinzel Pro meldet sich weiter mit dem eigenen Schlüssel an: Der Erlang-SSH-Client kann kein Zertifikat vorlegen, und sshd-Direktiven bleiben beim Operator.

1.1.0 (2026-10-08)

  • Gemeinsame SSH-Schlüssel: Administratoren legen benannte Schlüsselpaare an, die mehrere Server nutzen, so dass eine öffentliche Zeile über das Konfigurationsmanagement hinausgeht. Die Rotation behält den vorigen Schlüssel als zurückgezogen, bis jeder Host die neue Zeile trägt; Server, die noch am zurückgezogenen Schlüssel hängen, werden markiert. Private Schlüssel werden weiterhin nie importiert oder exportiert.
  • SMTP_TLS=never für ein Relay auf dem Host, dessen Zertifikat der Container nicht prüfen kann. Eine abgelehnte Zustellung schreibt jetzt eine Fehlerzeile ins Log.

1.0.2 (2026-10-08)

  • Mail über ein Relay ohne Zugangsdaten (SMTP_HOST gesetzt, SMTP_USERNAME leer) scheiterte bei jedem Versand.
  • Das Formular „Anmeldelink schicken“ gab ohne JavaScript 500 zurück; es schickt den Link jetzt wie die Variante mit Skript.

1.0.1 (2026-10-08)

Fehlerbehebungen aus der ersten Installation auf einem echten Host.

  • FORCE_SSL=true brach den Start ab: Phoenix liest force_ssl zur Compile-Zeit. Umleitung und HSTS kommen jetzt aus einem Laufzeit-Plug; localhost bleibt unverschlüsselt.
  • Leere Zeilen in .env wie SMTP_HOST= schalten keinen kaputten SMTP-Adapter mehr ein und heben keine Vorgabe mehr auf: Jede leere Variable gilt als nicht gesetzt.
  • Die Compose-Datei bindet die Anwendung an 127.0.0.1:4000 statt an jede Schnittstelle, weil Docker Ports an der Firewall des Hosts vorbei veröffentlicht.
  • Das Datenbankpasswort reist in DATABASE_PASSWORD statt in DATABASE_URL, wo / oder + die Verbindung brachen.
  • Der erste Administrator setzt bei der Registrierung ein Passwort und ist sofort angemeldet. Vorher wartete das Konto auf einen Anmeldelink per Mail, den eine frische Installation oft noch nicht verschicken kann.
  • Neu: bin/login-link EMAIL gibt einen einmaligen Anmeldelink aus, für Operatoren, die ohne funktionierende Mail ausgesperrt sind.
  • Mail über SMTP scheiterte mit :mimemail undefined: gen_smtp fehlte im Release.
  • Das Build-Image ist auf Elixir 1.20.3 (CVE-2026-49762) und ein aktuelles Debian gezogen.

1.0.0 (2026-10-07)

Erstes Release.

  • Konversationen mit einem KI-Sysadmin-Agenten auf Linux-, FreeBSD- und macOS-Hosts, die über SSH verwaltet werden
  • Risikoeinstufung jedes Befehls, Freigabe-Workflow, Vier-Augen-Prinzip für unumkehrbare Befehle
  • Nur anhängbares, hash-verkettetes Audit-Protokoll mit CSV-Export
  • Eigenes Modell: Anthropic und jeder OpenAI-kompatible Anbieter
  • Benutzer mit Rollen, Zwei-Faktor-Authentifizierung, Single Sign-on über OpenID Connect
  • Geplante unbeaufsichtigte Läufe mit Berichten per Mail
  • Alarme per E-Mail und Webhook (Slack, Teams, generisch)
  • Offline prüfbare Abonnement-Lizenzen mit Testphase und Kulanzfrist
  • Deutsche und englische Oberfläche