lzug 0.9.0

Added

• Der autoritative Backendprozess stellt einen gehärteten Unix-Domain-Socket
  mit direktem Go-Adapter für die Betreiber-CLI bereit.
  Liveness, Readiness und Wartungszustand sind über die Betriebsverträge
  durchgängig sichtbar.
• Artefakte können begrenzt und versioniert über denselben Admin-Socketvertrag
  gestreamt werden.

Changed

• CLI und Produktimage verwenden vollständig die bereitgestellten lokalen
  Socket-Endpunkte.
  Runtime-, Lifecycle- und Persistenzkoordination sowie Integrations-,
  Planfolgen- und Migrationsorchestrierung sind dafür in klar abgegrenzte
  Verantwortungen gegliedert.
• Backend-Fachmodule, transportneutraler Admin-Anwendungskern,
  Ressourcenautorisierung und SQL-Sichtbarkeit sind getrennt organisiert.
  Kritische Backend-Betriebsbereiche sind statisch typisiert und gezielt
  getestet; die FastAPI-Kompatibilitätsschicht wurde nach erreichter Parität
  reduziert.
• Frontend-Shell, API-Module und E2E-Suiten folgen getrennten
  Verantwortungsgrenzen.
  Echte Angular-Routen aktivieren die Feature-Einstiege, und die
  Frontend-Transporttypen werden aus dem OpenAPI-Vertrag erzeugt.
• HTTP-Observability verwendet kanonische Routenschablonen und konsistente
  Messwerte.
• Die Publikations- und Versionsarchitektur trennt Produkt, technische
  Referenzen und redaktionelle Quellen.
  Das GitHub Wiki ist kontrolliert aktiviert, Pages sind auf Produkt und
  Referenzen reduziert, und die Veröffentlichung verwendet ein reguläres
  Hugo-Projekt mit Blowfish v3.
• Release- und Snapshot-Publishing sowie Task- und Workflow-Orchestrierung
  sind in eindeutige Phasen und zentrale Zuständigkeiten gegliedert.
  Qualitäts- und Release-Evidenz wird risikobasiert konsolidiert.
• Die Entwicklungsdokumentation beschreibt bestätigte Planänderungen,
  asynchrone Task-Übergaben, Project-basierte Ausführungsprofile sowie
  dokumentierte Release-Review- und Istaufwand-Gates.

Fixed

• HTTP-Requests werden bereits beim Streaming begrenzt.
  Fehlende Ressourcen-IDs werden vor dem SQLAlchemy-Zugriff validiert.
• Die Dokumentation zu den Folgen bestätigter Planänderungen entspricht wieder
  dem bestätigten fachlichen Verhalten.

Security

• Ressourcenautorisierung und SQL-Sichtbarkeit sind transaktionsklar getrennt.
  Der lokale Admintransport verwendet gehärtete Socket-Grenzen und einen
  versionierten Vertrag.
• Datenmigrationen können kontrolliert über die Betreiber-CLI freigegeben
  werden.

Toolchain

• Hono, Ruff und holidays wurden auf die im Milestone geprüften Versionen
  aktualisiert.

lzug 0.8.0

Changed

• Self-Hosting verwendet ab v0.8.0 ausschließlich das Produktimage
  ghcr.io/lxndrp/lzug-app:<version> mit einer exakten veröffentlichten
  SemVer-Version.
  Docker Engine auf Linux mit Compose v2 ist der unterstützte und geprüfte
  Referenzbetrieb; ein von Docker aufgelöster Digest bleibt automatischer
  Herkunftsnachweis, ist aber keine regulär zu pflegende Betreibereingabe.
• Die Betreiber-CLI ist als eigenständiges Go-Modul unter operator-cli/
  gekapselt.
  Binaryname, Befehle, Exit Codes, Adminprotokoll, Plattformmatrix und
  Archivvertrag bleiben unverändert; CLI und Produktimage müssen weiterhin
  aus demselben Release stammen.
• Laufzeitkonfiguration wird einmalig über typisierte, fachlich getrennte
  Settingsmodelle assembliert und vor der Annahme von Requests validiert.
  Bestehende Umgebungsvariablen und Defaults bleiben erhalten; Produkt, Demo,
  E2E und Administration verwenden denselben geheimnisfreien
  Konfigurationsvertrag.
• Das Python-Backend wird aus dem komponentenlokalen Paket
  backend/src/backend als Wheel gebaut und identisch in Produkt- und
  Demo-Image installiert.
  FastAPI-Assembly, gemeinsame Sicherheits- und Zugriffsabhängigkeiten sowie
  Router für Stammdaten, Planung, Durchführung, Bewertung, Integrationen und
  Betrieb sind getrennt, ohne die bestehenden HTTP-, OpenAPI- oder
  Berechtigungsverträge zu verändern.
• Kalenderausgaben verwenden icalendar, Web-Push-Zustellungen pywebpush.
  Bestehende Kalenderidentitäten, P-256-PEM-VAPID-Schlüssel und registrierte
  Push-Endpunkte bleiben kompatibel.
• Anwendung und Dokumentationsportal verwenden eine gemeinsame visuelle
  Grammatik mit klarer Komponentenverantwortung.
  Öffentliche Einstiege verweisen direkt auf die erzeugte Nutzungs-,
  Betriebs- und Entwicklerdokumentation; abgelöste Prototypen,
  Zwischenartefakte und einmalige Migrationsnachweise sind entfernt.
• Pull Requests prüfen fünf stabile Domänengates selektiv und fail-closed.
  Die vollständige Produktintegration läuft nächtlich auf master sowie
  manuell für eine exakte Release-Ausgangs-SHA; Release und stabile
  Demo-Promotion verwenden diesen erfolgreichen Nachweis, statt eine zweite
  vollständige Quality-Kette auszuführen.

Fixed

• Frontend-Updates beseitigen die bekannte
  ResizeObserver-Schleifenwarnung, die verbleibende
  fast-uri-High-Warnung und Darstellungsfehler nach der Einführung von
  Lucide 1.
• Backend-Jobs schließen SQLite- und HTTP-Ressourcen auch bei Fehlern und
  wiederholter Ausführung zuverlässig.
• Die SBOM-Prüfung unterscheidet deklarierte Go-Abhängigkeiten von den
  tatsächlich in native CLI-Binaries eingebetteten Modulen und erfindet keine
  transitive Testabhängigkeit als Releasebestandteil.
• Pfadselektive Pull-Request-Prüfungen behalten die erforderlichen
  CodeQL-Sprachkonfigurationen auch bei Workflow- und anderen
  repositoryweiten Änderungen bei.

Security

• Gemeinsame FastAPI-Dependencies erzwingen Authentifizierung,
  Ausschuss-Scope, CSRF-Schutz und Betreibergrenzen konsistent an den
  modularisierten Routen; Parserfehler und Berechtigungsfehler bleiben
  unterscheidbar und geheimnisfrei.
• Typisierte Settings schützen Secrets vor Repräsentation, Dumps, Diagnose
  und Logs und lehnen ungültige URLs, Pfade, Zahlenbereiche und gekoppelte
  Providerkonfiguration vor dem Anwendungsstart ab.
• Web Push verwendet die etablierte Protokollbibliothek bei unverändertem
  datensparsamen Payload- und Fehlervertrag.
  Tool-, Action- und Basisimageversionen sind explizit gebunden;
  Standard-Lockfiles, Attestierungen, Provenance und das geprüfte
  Demo-Digestpaar bleiben die jeweiligen Integritätsnachweise.

Migration und Kompatibilität

• Bestehende Installationen stellen LZUG_IMAGE von
  ghcr.io/lxndrp/lzug:<version> oder einer Digestreferenz auf
  ghcr.io/lxndrp/lzug-app:0.8.0 um.
  Für den alten Imagenamen wird kein Alias veröffentlicht; bereits
  veröffentlichte Images und Releases bis v0.7.x bleiben unverändert.
• Podman-Unterstützung und --engine-Auswahl der Betreiber-CLI entfallen.
  Betriebsautomation muss Docker Engine auf Linux mit Compose v2 verwenden;
  OCI-Kompatibilität des Images begründet kein Supportversprechen für weitere
  Runtimes.
• Die Backend-Paket-, Datenbankressourcen- und Routerstruktur ist eine interne
  Neuordnung.
  Sie erzeugt weder eine neue Datenbankmigration noch geänderte
  Umgebungsvariablen, fachliche API-Pfade oder OpenAPI-Operationen.
  Die 28 nummerierten, checksum-gesicherten SQL-Migrationen und der
  bestehende Upgrade-only-, Backup-, Sperr- und Readiness-Vertrag bleiben
  maßgeblich; Alembic wird nicht eingeführt.
• v0.8.0 bündelt administrative Verbesserungen, Sicherheits- und
  Qualitätsstabilisierung sowie interne Architekturpflege seit v0.7.0.
  Neue fachliche Prozesse, ein externer Admintransport, Änderungen an Release-
  oder Demo-Verträgen und Inhalte späterer Milestones sind nicht enthalten.
• Dieser Vorbereitungseintrag erzeugt weder einen Tag noch einen GitHub
  Release, GHCR- oder CLI-Artefakte, Attestierungen, eine Demo-Promotion oder
  eine Environment-Freigabe.
  Diese Schritte dürfen erst nach dem Merge, einem erfolgreichen vollständigen
  Quality-Lauf für die exakte aktuelle master-SHA und der getrennten
  Maintainer-Freigabe im Release-Workflow erfolgen.

lzug 0.7.0

Added

• lzug-admin cli ergänzt die direkten Subcommands um einen zeilenorientierten,
  vollständig aus der Command Registry erzeugten Dialog für interaktive
  Betreiberaufgaben.
  Suche, Zielprüfung, schrittweise Eingabe, konkrete Bestätigungen und
  eindeutige Ergebniszustände verwenden dieselben Handler, Validierungen,
  Transportaufträge und Exit Codes wie der direkte Aufruf.
  Der Modus benötigt Ein- und Ausgabe-Terminals und ist ausdrücklich nicht für
  Automation, --json oder sitzungsweites --force vorgesehen.
• Prüfungsorte können mit Räumen, Kontaktwegen und stabilen Identitäten
  scopesicher verwaltet, aus dem bisherigen Ortsbestand migriert und in einer
  responsiven Übersicht sowie Detailansicht verwendet werden.
  Eine optionale Karten-, Geocoding- und Routenintegration bleibt an explizite
  Providerkonfiguration, Datenschutzinformation, Attribution und sichere
  Fallbacks gebunden.
• Die öffentliche Demo verwendet einen reproduzierbar generierten,
  eindeutig synthetischen Theaterensemble-Datensatz.
  Zwei voneinander isolierte und zurücksetzbare Szenarien machen Ausfall und
  Ersatz sowie Änderungen bestätigter Pläne mit Rollenwechsel,
  Benachrichtigungen und persönlichen Kalendern nachvollziehbar.
  Drei Athener Theaterreferenzen und synthetische Räume ergänzen diesen
  Katalog, ohne reale Prüfungsorte oder eine organisatorische Demo-Freigabe zu
  behaupten.

Changed

• Bedeutungsrelevante Änderungen an Prüfungsorten und Räumen zeigen vor dem
  Speichern die betroffenen zukünftigen Einplanungen sowie erwartete Kalender-
  und Benachrichtigungsfolgen.
  Kalender-IDs bleiben stabil, vergangene Ereignisse und interne Felder bleiben
  unverändert, und fehlgeschlagene Folgen können aktualitätsgeprüft erneut
  verarbeitet werden, ohne eine Planrevision zu erzeugen.
• Backup und Vollexport verwenden ab v0.7.0 das interoperable
  age-encryption.org/v1-Format mit genau einem X25519-Empfänger.
  lzug-admin verwaltet Schlüsseldateien und Fingerabdrücke, hält private
  Identitäten vollständig auf dem Bedienrechner und schützt beziehungsweise
  öffnet die vom Backend fachlich geprüften Paketströme atomar.
  Der aktive öffentliche Backup-Empfänger wird persistent und auditiert;
  v0.6-Artefakte werden mit einem eindeutigen Wiederherstellungshinweis
  abgewiesen und benötigen die veröffentlichte v0.6.0-Laufzeit.
• lzug-admin verwendet ab v0.7.0 eine statische modulare Registry und den
  einheitlichen Command-Baum lzug-admin <objekt> <aktion>.
  Hilfe, Shell-Completion und die technische Befehlsreferenz entstehen aus
  denselben Metadaten; direkte und interaktive Aufrufe verwenden
  dieselben Validierungen, Backend-Aufträge und Ergebnisdarstellungen.
• Erfolgreiche Human-Aufrufe bleiben grundsätzlich still und geben nur
  erforderliche Ergebnisse wie Einmaltoken oder Artefaktnamen auf stdout aus.
  --verbose schreibt geheimnisfreie Diagnose nach stderr, während --json
  genau ein versioniertes Ergebnisobjekt mit stabilem Exit Code ausgibt.
• Engine und Containername können als Flag, Umgebungsvariable oder in einer
  optionalen nicht geheimen JSON-Konfiguration gesetzt werden.
  Geheimnisse werden ausschließlich über stdin und am TTY ohne Echo gelesen.
  Gewöhnlich destruktive Vorgänge verlangen am Terminal eine Rückfrage oder
  --force; separate Danger-Zone-Bestätigungen werden durch --force nie
  ersetzt.
• Das gemeinsame Corporate Design führt die freigegebene Bildmarke,
  lokal ausgelieferte Inter-Schrift, semantische Design-Tokens, Hell- und
  Dunkelmodus sowie reproduzierbar geprüfte Markenreferenzen in Produkt und
  öffentlicher Dokumentation zusammen.
• Der repository-zentrierte öffentliche Einstieg verbindet Zielgruppen,
  Self-Hosting-Nachweis, Handbuch, kontextuelle Produkthilfe und eine
  ausschließlich in der Demo sichtbare Tour mit den kanonischen Quellen.
• Navigation, Reflow bei 200 Prozent, Validierungs- und
  Synchronisationsrückmeldungen sowie die wichtigsten Interaktionen wurden
  abschließend für Chromium, Firefox und WebKit geprüft und visuell
  vereinheitlicht.
• Die komplexesten Backend-Vertrags-, Repository-, Planungs-,
  Prüfungstag-, Backup- und FastAPI-Bausteine wurden ohne Änderung ihrer
  fachlichen Verträge zerlegt und um statische Typ- und Komplexitätsprüfungen
  ergänzt.
  Ruff, ESLint und Browserslist wurden innerhalb der bestehenden
  Qualitätsverträge aktualisiert.

Security

• Private age-Identitäten verbleiben auf dem Bedienrechner; Backend,
  Containertransport und CLI tauschen nur fachlich geprüfte Paketströme und
  den aktiven öffentlichen Empfänger aus.
  Temporäre Klartextartefakte, Geheimnisse in Argumenten und unvollständige
  Zieldateien werden fail-closed vermieden.
• Prüfungsortzugriffe respektieren den Ausschuss-Scope, und externe
  Kartenanbieter bleiben standardmäßig deaktiviert.
  Änderungen mit Auswirkung auf zukünftige Einplanungen verlangen eine
  explizite Vorschau und erzeugen Kalender- und Benachrichtigungsfolgen
  idempotent und revisionsgebunden.

Migration der Betreiber-CLI

Die alte flache Syntax entfällt ohne Laufzeit-Aliase.
Skripte, die das bisherige rohe Backend-JSON ausgewertet haben, verwenden
zusätzlich --json und lesen den neuen Ausgabeumschlag.

Alte Form bis v0.6.x	Neue Form ab v0.7.0
lzug-admin artifact-verify für ein Backup	lzug-admin backup verify
lzug-admin artifact-verify für einen Vollexport	lzug-admin export verify
lzug-admin backup-create	lzug-admin backup create
lzug-admin backup-restore	lzug-admin backup restore
lzug-admin bootstrap	lzug-admin account bootstrap
lzug-admin committee-bootstrap	lzug-admin committee bootstrap
lzug-admin committee-complete	lzug-admin committee complete
lzug-admin committee-deactivate	lzug-admin committee deactivate
lzug-admin committee-reactivate	lzug-admin committee reactivate
lzug-admin committee-reinvite	lzug-admin committee reinvite
lzug-admin config	lzug-admin system config
lzug-admin consume-invitation	lzug-admin account consume-invitation
lzug-admin consume-recovery	lzug-admin account consume-recovery
lzug-admin disable	lzug-admin account disable
lzug-admin doctor	lzug-admin system doctor
lzug-admin full-export	lzug-admin export create
lzug-admin invite	lzug-admin account invite
lzug-admin plan-consequences-status	lzug-admin plan-consequence status
lzug-admin process-notifications	lzug-admin notification process
lzug-admin recover	lzug-admin account recover
lzug-admin retry-plan-consequences	lzug-admin plan-consequence retry
lzug-admin rollback	lzug-admin upgrade rollback
lzug-admin status	lzug-admin system status
lzug-admin test-notification	lzug-admin notification test
lzug-admin upgrade	lzug-admin upgrade apply

Scope and compatibility

• v0.7.0 bereitet den vollständig gemergten Product-Polish- und
  Operator-Experience-Stand seit v0.6.0 vor.
  Der Umfang enthält die neue Betreiber-CLI, die geschützte Backup- und
  Exporthülle, Prüfungsorte, synthetische Demo-Szenarien, Corporate Design,
  öffentliche Produktdarstellung, finales UI-Polishing und die zugehörigen
  Qualitätsstabilisierungen, aber keine neuen fachlichen Kernprozesse.
• Die flache CLI-Syntax und das proprietäre v0.6-Backupformat werden nicht
  weiterverarbeitet.
  Bestehende Automationen müssen auf den dokumentierten Command-Baum und bei
  maschinenlesbarer Verarbeitung auf --json wechseln; v0.6-Artefakte müssen
  vor dem Upgrade mit der veröffentlichten v0.6.0-Laufzeit geöffnet oder
  wiederhergestellt werden.
• Ein externer Admintransport, die qualitative Screenreader-Abnahme aus #630,
  rechtliche oder organisatorische Produktzusagen sowie die Freigabe der
  öffentlichen Demo aus #584 bleiben außerhalb dieses Releases.
  Der vorhandene lokale Docker-/Podman-Containertransport bleibt maßgeblich.
• Dieser Vorbereitungseintrag erzeugt weder einen Produkt-Tag noch einen
  GitHub Release, GHCR- oder CLI-Artefakte, Attestations, eine Demo-Promotion
  oder eine Environment-Freigabe.
  Diese Schritte entstehen ausschließlich in den getrennt freigegebenen
  Release- und Demo-Workflows nach ihren jeweiligen Gates.

lzug 0.6.0

Added

• Self-Hosting-Instanzen können den SQLite-Datenbestand, Dokumente und
  anwendungsverwaltete Authentifizierungsschlüssel geschützt sichern,
  unabhängig prüfen, wiederherstellen und als vollständiges Exportartefakt
  ausgeben.
  Konsistenzprüfung, Verschlüsselung, Fehler-Rollback, konkurrierende Zugriffe,
  Migrationen und der Ausschluss nicht exportierbarer Daten sind vertraglich
  und für die Containerlaufzeit abgesichert.
• Die versionierte Betreiber-CLI bietet datensparsame status-, config- und
  doctor-Diagnosen sowie orchestrierte Backup-, Prüf-, Restore- und
  Vollexportvorgänge.
  Die Verträge gelten für Docker und Podman, schützen private Schlüssel vor
  Argumenten, Ausgaben und Logs und liefern nachvollziehbare Fehlerzustände.
• Upgrades und Rollbacks können releasegebunden über die Betreiber-CLI
  ausgeführt werden.
  Wartungscontainer, kanonischer GHCR-Digest, passendes Release und ein vor
  Migration erzeugtes und nicht mutierend geprüftes Vollbackup bilden dabei
  die verpflichtenden Voraussetzungen.

Changed

• Die technische Dokumentation wurde als arc42-/C4-orientierter Einstieg mit
  Architekturprinzipien, Review-Checkliste und tragfähigen Mermaid-Quellen
  aufgebaut und anschließend auf die fünf kanonischen Entwicklerbereiche
  konsolidiert.
  Betriebs-, Datenschutz-, Architektur-, Release- und Entwicklerhinweise
  verweisen nun auf den einheitlichen Betreibervertrag.
• Die Betriebsdokumentation beschreibt Installation, vollständige
  Konfiguration, Backup-Prüfung, Restore, Upgrade, Rollback,
  Datenschutzverantwortung, bekannte Grenzen und Support.
  Redundante Entwickler- und Legacyseiten wurden entfernt, gültige ADRs und
  generierte Referenzen bleiben erhalten.

Security

• Backup- und Restore-Artefakte bewahren die Konsistenz des Anwendungs- und
  Sicherheitszustands und behandeln Schlüsselmaterial mit einem festgelegten
  kryptografischen Vertrag.
  Betreiberpfade bleiben von fachlichen Berechtigungen getrennt und legen
  keine privaten Empfängerschlüssel in argv, Ausgaben oder Logs offen.
• Diagnose, Migration, Upgrade und Rollback prüfen Identität, Konfiguration,
  Persistenzrechte, freien Speicher, Releasebindung und den vorgesehenen
  Wiederanlauf fail-closed.

Scope and compatibility

• v0.6.0 ist ein kompatibler Self-Hosting- und Betreiberrelease seit
  v0.5.0.
  Der Abschnitt umfasst den vollständig gemergten Stand aus #562, #563, #564,
  #574, #575, #576 und #577 einschließlich der dafür erforderlichen
  Dokumentations-, Architektur- und Releasevertragsänderungen.
• Dieser Vorbereitungseintrag erzeugt weder einen Produkt-Tag noch einen
  GitHub Release, GHCR- oder CLI-Artefakte, Attestations, eine Demo-Promotion
  oder eine Environment-Freigabe.
  Der geschützte Release-Workflow darf erst nach separatem Maintainer-GO und
  erfolgreichem Preflight auf dem aktuellen master ausgeführt werden.
• Alternative Datenbanken, S3-kompatibler Dokumentenspeicher, externe
  Administration, PR-Previews, eine zentrale Mandantenflotte sowie rechtliche,
  datenschutzbezogene, barrierefreie und organisatorische Freigaben der
  öffentlichen Demo bleiben außerhalb dieses Releases und sind für spätere
  Entscheidungen oder Milestones vorgesehen.

lzug 0.5.0

Added

• Bestätigte Pläne können durch Vorsitz und Stellvertretung kontrolliert als
  vollständiges Aggregat geändert werden.
  Unveränderliche Vorher- und Nachher-Snapshots, Revisionsprüfung, Auditspur,
  fachliche Validierung und Konflikterkennung schützen bereits gestartete oder
  abgeschlossene Planungsteile und machen Änderungen nachvollziehbar.
• Änderungen bestätigter Pläne leiten nach dem erfolgreichen Commit
  zusammengefasste interne Benachrichtigungen und persönliche Kalenderfolgen
  revisionsbezogen, idempotent und wiederholbar ab.
  Stabile Ereignisidentitäten, getrennte Fehlerzustände und der Vorrang neuerer
  Revisionen verhindern Dubletten und den Rückfall auf ältere Planstände.
• Ein ausschließlich administrativer, atomarer Ausschuss-Bootstrap richtet den
  Ausschuss mit initialem Vorsitz und auditierbarem Nachweis ein.
  Der Workflow ist fehlgeschützt, über die Betreiber-CLI erreichbar und ersetzt
  die allgemeine Erstellung im Produkt durch den vorgesehenen Verwaltungsweg.
• Ausschussbezogene Prüfungsrunden unterstützen Eröffnung, Abschluss, Absage und
  gezielte Wiederöffnung mit revisionsgebundener Historie, Sperrwirkung,
  Nachfassaufgaben und menschen- sowie maschinenlesbaren Exporten.
  Terminale Prüflingsstatus und nachträgliche förmliche IHK-Statusangaben werden
  dabei getrennt und nachvollziehbar geführt.

Changed

• Die Oberfläche und die REST-/OpenAPI-Verträge bilden den kontrollierten
  Planänderungs- und Prüfungsrundenprozess einschließlich Rollen-, Revisions-,
  Validierungs- und Konfliktverhalten ab.
  Route-Paritätstests berücksichtigen auch PUT-Operationen und vergleichen
  Pfade unabhängig von lokalen Platzhalternamen.
• Architekturentscheidungen und öffentliche Einstiegspunkte wurden auf die
  kanonische Dokumentationsstruktur sowie das aktuelle Release- und
  Entwicklungsmodell konsolidiert.
• Die CodeQL-Verträge fallen bei fehlenden Baselines für unveränderte Sprachen
  auf eine vollständige Analyse zurück.
  Workflowtests prüfen die fachlichen Invarianten der Analyse und der weiterhin
  vollständig gepinnten Action-Revisionen.
• Abhängigkeiten und CI-Werkzeuge wurden kontrolliert aktualisiert und für
  gekoppelte Änderungen gruppiert, darunter Angular 22.1.4, Taiga UI 5.21.0,
  TypeScript ESLint 8.68.0, @axe-core/playwright 4.13.0,
  jdx/mise-action 4.3.0 sowie die CodeQL- und Azure-Login-Actions.

Security

• Planänderungen, Ausschuss-Bootstrap, Prüfungsrundenentscheidungen und Exporte
  bleiben an die zuständigen Ausschussrollen und aktuelle Revisionen gebunden.
  Betreiberkonten erhalten keinen fachlichen Zugriff; generische Schreibpfade
  für geschützte Planbestandteile bleiben gesperrt.
• Auditierbare Snapshots, Sperrwirkung, terminale Statusführung und getrennte
  Folgenzustände bewahren die Nachvollziehbarkeit auch bei Konflikten,
  Wiederanläufen, Absagen und nachträglichen Statusangaben.
• Die selektive CodeQL-Auswertung behandelt fehlende Baselines nicht als leeren
  Erfolgspfad, und die Workflow-Referenzen bleiben vollständig an unveränderliche
  40-stellige Revisionen gebunden.

Scope and compatibility

• Der für v0.5.0 vorbereitete Umfang ist seit v0.4.0 kompatibel und umfasst
  den zusammenhängenden Prozess für kontrollierte Änderungen bestätigter Pläne,
  deren Benachrichtigungs- und Kalenderfolgen, den administrativen
  Ausschuss-Bootstrap sowie den Lebenszyklus ausschussbezogener Prüfungsrunden
  einschließlich der dafür gemergten API-, Dokumentations-, CI- und
  Abhängigkeitsstabilisierungen.
• Dieser Vorbereitungseintrag beansprucht weder den Produkt-Tag noch einen
  veröffentlichten GitHub Release, neue GHCR- oder CLI-Artefakte,
  Attestations, eine öffentliche Demo-Promotion oder eine externe
  Environment-Freigabe.
  Diese Schritte entstehen erst nach separatem Maintainer-GO und erfolgreichem
  Release-Preflight auf dem aktuellen master.
• Ein globaler fachlicher Prüfungshalbjahresabschluss ist nicht Teil des
  Modells; fachlich abgeschlossen wird ausschließlich die
  ausschussbezogene Prüfungsrunde.
  Spätere betriebliche Themen wie allgemeines Upgrade, Backup, Restore,
  Produkt-Rollback und produktive Self-Hosting-Reife bleiben außerhalb dieses
  Releaseumfangs und sind für spätere Milestones vorgesehen.

lzug 0.4.0

Added

• Ein versioniertes Prüfungsprotokoll bildet für jeden tatsächlich gestarteten
  Prüfungsslot den gemeinsamen Tatsachenstand mit Beteiligten-Snapshot,
  besonderen Vorkommnissen, Reaktionen, Korrekturen und vollständiger Historie
  ab.
• Der getrennte Ergebnisvorgang bindet eine unveränderliche Bewertungsmodell-
  version, unterstützt verdeckte Einzelbewertungen, kontrollierte Offenlegung,
  Vier-Augen-Bestätigung externer Ergebnisse, reproduzierbare Berechnung,
  Feststellung, Mitteilung und nachvollziehbare Korrekturen.
• Ein revisionsgebundener Tagesabschluss prüft Durchführung, Besetzung,
  Anwesenheit, Ausfälle, Protokolle und Bewertungen gemeinsam.
  Regulärer und eng begrenzter Ausnahmeabschluss, zielgerichtete Wiederöffnung,
  Sperrwirkung, Nachfassaufgaben und maschinen- beziehungsweise menschenlesbare
  Nachweise bleiben historisch nachvollziehbar.

Changed

• Die FastAPI-Migration ist abgeschlossen.
  Laufzeit-, Authentifizierungs-, Planungs-, Domänen- und Integrationsrouten
  verwenden den gemeinsamen synchronen Anwendungskern; HTTP-, OpenAPI- und
  Sicherheitsverträge werden über Paritätstests abgesichert.
• Architektur-, Entwickler-, Betriebs- und Publikationsdokumentation wurden auf
  die aktuellen kanonischen Quellen und Runbooks konsolidiert.
  Dokumentationsgovernance, strukturelle Prüfungen, Wiki-Abgrenzung und
  Semantic Line Breaks begrenzen künftig die Entstehung widersprüchlicher
  Doppelquellen.
• Der vollständige Quality-Lauf bleibt an die geprüfte Revision gebunden.
  Fixture-Frische, Dependabot-Folgeprüfungen und die relevanten CI-Verträge
  bilden auch nach automatisierten Abhängigkeitsaktualisierungen belastbare
  Master-Nachweise.
• Demo-Auslieferung, Deployment, URL-Auflösung und App-/Seed-Paar folgen einem
  gemeinsamen unveränderlichen Vertrag.
  Oberfläche und API halten die effektiven Default-Deny-Fähigkeiten ein;
  persistente Demo-Logs und kostenpflichtige Überwachungswege entfallen, während
  Kostenbaseline und verbleibende Plattformdiagnostik dokumentiert sind.
• Benachrichtigungszustellungen beanspruchen Arbeit mit Lease und begrenzten
  Batches konkurrenzsicher.
  Ein Fehler bei der Kalendersynchronisierung verliert den bereits gespeicherten
  Slot-Status nicht.
• Build-, Test- und Frontend-Abhängigkeiten sowie die SBOM-Orchestrierung wurden
  kontrolliert auf den bestehenden, reproduzierbaren Werkzeugen gehalten.

Security

• Protokolle, Bewertungen, Ergebnisse und Tagesabschlüsse bleiben an die
  tatsächliche Beteiligung und die zuständigen Ausschussrollen gebunden;
  Betreiberkonten erhalten keinen fachlichen Zugriff.
• Migrationen erfinden keine historischen Prüfungs-, Bewertungs- oder
  Abschlussdaten.
  Demo-Schreibpfade bleiben über die ausführbare Default-Deny-Policy begrenzt.

Scope and compatibility

• v0.4.0 ist ein kompatibler Funktionsrelease seit v0.3.0 und umfasst den
  zusammenhängenden Ablauf mündlicher Prüfungstage aus #522, #528 und #529
  einschließlich Protokollierung, Bewertung, Ergebnis und Abschluss sowie die
  dafür gemergten technischen Stabilisierungen.
• Dieser Vorbereitungseintrag beansprucht weder den Produkt-Tag noch einen
  veröffentlichten GitHub Release, neue GHCR- oder CLI-Artefakte,
  Attestations, eine öffentliche Demo-Promotion oder eine erneute externe
  Environment-Freigabe.
  Diese Schritte entstehen erst nach separatem Maintainer-GO.
• Änderungen an bestätigten Plänen, der Abschluss von Prüfungshalbjahren sowie
  allgemeines Upgrade, Backup, Restore, Produkt-Rollback und produktive
  Self-Hosting-Reife bleiben außerhalb dieses Releaseumfangs und sind für
  spätere Milestones vorgesehen.

lzug 0.3.0

Added

• Ein Ausfall- und Ersatzprozess für bestätigte Besetzungen erfasst
  autorisierte Ausfallmeldungen, Fristen, Ersatzantworten, Audit-Ereignisse und
  Korrekturpfade. Tagesansicht und Prozessübersicht führen durch die jeweils
  zulässigen Aufgaben; Persistenz, OpenAPI, Migration und Benachrichtigungen
  bleiben dabei konsistent.
• Ein kanalneutraler Benachrichtigungsvertrag unterstützt idempotente Ereignisse,
  rollenbezogene Einsicht, Web Push, optionalen SMTP-Fallback, Retry- und
  Fehlerzustände sowie die Betreiber-CLI und einen Demo-Sink.
• Prüfungstermine können als persönliche, provider-neutrale Kalenderfeeds und
  einzelne ICS-Ereignisse bereitgestellt werden. Stabile Identitäten,
  Versionen, Ersetzungen und Absagen vermeiden dabei unnötige personenbezogene
  Daten; Feed-Lebenszyklus, API, Migration, Oberfläche und Dokumentation sind
  eingeschlossen.

Changed

• Stabile Produkt-Releases können nach ihrer Veröffentlichung automatisch als
  unveränderliches, provenance-geprüftes App-/Seed-Paar in die öffentliche Demo
  promotet werden. Release Candidates bleiben ausgeschlossen; Readiness,
  OIDC, SBOM- und Public-Site-Grenzen bleiben erhalten.
• Pull-Request-Sicherheitsprüfungen und Public-Site-/Wiki-Prüfungen werden nur
  für relevante Änderungen ausgeführt. Workflowtests prüfen die fachlichen
  Invarianten, ohne sich an Schrittbezeichnungen oder Reihenfolgen zu binden;
  die vollständigen Quality- und Security-Nachweise bleiben bestehen.
• Die öffentliche Demo verwendet eine reduzierte Überwachungsgrundlast ohne
  periodischen Readiness-Warm-up. Landingpage-, Fehler- und Dokumentations-
  nachweise bleiben getrennt, reproduzierbar und auf die tatsächlich benötigten
  Prüfungen begrenzt.
• Build-, Test- und GitHub-Actions-Abhängigkeiten wurden kontrolliert
  aktualisiert. Die Betriebs- und Self-Hosting-Abgrenzung dokumentiert zudem
  den evidenzbasierten Verzicht auf InSpec als gemeinsamen Infrastruktur-Harness.

Security

• Benachrichtigungen und Kalenderfeeds verwenden rollenbezogene beziehungsweise
  datensparsame Verträge; der Ausfall- und Ersatzprozess prüft Autorisierung,
  Fristen und Auditierbarkeit.
• Die selektive Pull-Request-Analyse bewahrt vollständige Quality-CodeQL- und
  unabhängige Trivy-Prüfungen für relevante Änderungen, ohne leere Auswahlpfade
  oder fehlerhafte Sicherheitsprüfungen als erfolgreich zu behandeln.

Scope and compatibility

• v0.3.0 ist ein kompatibler Funktionsrelease seit v0.2.0 und umfasst den
  zusammenhängenden Ausfall-, Benachrichtigungs- und Kalenderprozess aus #28,
  #29 und #30 sowie die dafür gemergten releasebegleitenden Korrekturen.
• Dieser Vorbereitungseintrag beansprucht weder den Produkt-Tag noch einen
  veröffentlichten GitHub Release, neue GHCR- oder CLI-Artefakte,
  Attestations, eine öffentliche Demo-Promotion oder eine erneute externe
  Environment-Freigabe. Diese Schritte entstehen erst nach separatem
  Maintainer-GO.
• Allgemeines Upgrade, Backup, Restore und Produkt-Rollback sowie Änderungen an
  bestätigten Plänen und produktive Self-Hosting-Reife bleiben außerhalb dieses
  Releaseumfangs und sind für spätere Milestones vorgesehen.

lzug 0.2.0

Added

• Vorsitz und Stellvertretung können einen Planungsvorschlag in der
  Bestätigungsstufe vollständig per Tastatur, Mobilgerät und Screenreader
  bearbeiten. Tageszuordnung und Reihenfolge der Slots, Prüfungsorte sowie
  Prüfer und Fallbacks bleiben bis zum ausdrücklichen Speichern lokal;
  Validierungs-, Berechtigungs- und Revisionskonflikte werden verständlich
  angezeigt, ohne fremde Änderungen zu überschreiben.
• Die öffentliche Demo macht Person, Rolle und den daraus folgenden
  Aufgabenpfad dauerhaft sichtbar. Navigation, Direktaufrufe und Aktionen
  folgen den effektiven Fähigkeiten; Prüfpersonen bearbeiten ausschließlich
  ihre eigene Verfügbarkeit und Anwesenheit.
• Eine reproduzierbare statische Landingpage führt mit einem begrenzten
  Scale-to-zero-Warm-up zur Demo. Manuell freigegebene, unveränderliche
  Demo-Snapshots sind an die exakte master-Revision, den vollständigen
  Quality-Nachweis und ein zusammengehöriges, attestiertes App-/Seed-Paar
  gebunden.

Changed

• Demo und Landingpage verwenden kanonische HTTPS-Origins sowie fail-closed
  Verträge für Custom Domains, TLS, CORS, Publication und Deployment. Browser-
  Tests leiten die konfigurierte Demo-Origin aus dem gebauten Artefakt ab,
  statt eine zweite feste URL vorauszusetzen.
• Prozess-Liveness und datenbankgebundene Readiness sind getrennt. Die
  Betriebsgrundlage umfasst datensparsame strukturierte Logs, rate-limitierte
  same-origin Frontend-Fehlerannahme, Aufbewahrungs- und Kostenbegrenzungen
  sowie vorbereitete Uptime-, Fehler- und Budgetalarme; externes Monitoring
  bleibt standardmäßig deaktiviert und an die kanonische Demo-Domain gebunden.
• Build-, Analyse- und Laufzeitabhängigkeiten wurden kontrolliert aktualisiert,
  darunter Angular, Taiga UI, SQLAlchemy, Ruff sowie die verwendeten GitHub-
  Actions. Die Regeln für Dependabot-Auto-Merge und die dauerhaften Planungs-
  und Umsetzungskontexte sind präzisiert.

Fixed

• Wiederholte Tabellen- und Kartenaktionen besitzen objektspezifische
  Accessible Names; Löschdialoge benennen dasselbe Ziel wie die auslösende
  Aktion.
• Optimierte Frontend-Builds laden globale Styles unter der Backend-CSP
  vollständig. Demo-Hinweis, Desktop-Sidebar, mobile Navigation und
  Sticky-Header überlagern sich auch bei umbrochenem Hinweistext nicht.
• Demo-Snapshot- und Deploymentverträge prüfen die commitgenaue Quality-
  Evidenz, Bootstrap-Reihenfolge, Environment-Aktivierungsgrenze und
  digestgebundene Runtime-Kompatibilität fail-closed. Der Compose-Lifecycle-
  Smoke diagnostiziert Stop/Start und Readiness zuverlässig.
• Publication und Betrieb validieren die tatsächlich aufgelöste Demo-URL, den
  geschützten OpenAPI-Pfad, Favicons unter dem Pages-Basepath und zustandsbehaftete
  Fehleralarme korrekt. Automatisch erzeugte Smart-Detection-Regeln werden
  datensparsam deaktiviert.

Security

• Die gesperrte pip-Version enthält die verfügbare Sicherheitskorrektur;
  Produktionsabhängigkeiten und Lieferkettenprüfungen wurden ohne bekannte
  kritische Schwachstellen verifiziert.
• Anonyme Deployment-Smokes erwarten am geschützten OpenAPI-Endpunkt
  ausdrücklich 401 Unauthorized; unsichere, abweichende oder generierte
  Demo-Origins werden vor Publication, Monitoring oder Deployment abgewiesen.

Scope and compatibility

• v0.2.0 ist ein kompatibler Funktionsrelease seit v0.1.2. Der Planeditor
  bearbeitet ausschließlich noch nicht bestätigte Planungsvorschläge; Änderungen
  bestätigter Pläne, Kandidaten- oder Slot-Struktur sowie Benachrichtigungs- und
  Kalenderfolgen sind nicht enthalten.
• Die Demo-, Publication- und Betriebsverträge sind lokal und in CI prüfbar.
  Dieser Vorbereitungseintrag beansprucht weder den Produkt-Tag noch einen
  veröffentlichten GitHub Release, neue GHCR- oder CLI-Artefakte, Attestations
  oder eine erneute externe Aktivierung; diese entstehen erst nach separatem
  Maintainer-GO.
• Allgemeines Upgrade, Backup, Restore und Produkt-Rollback sowie produktive
  Self-Hosting-Reife bleiben außerhalb dieses Releaseumfangs.

lzug 0.1.2

Fixed

• Erfolgreiche Azure-REST-Antworten ohne JSON-Body werden korrekt
  statusbasiert verarbeitet, ohne die leere Ausgabe als JSON zu parsen.
• Das Demo-Seed-Image wird genau einmal gebaut, vor Belegung des
  unveränderlichen Tags anhand der eingebetteten Datenbank, des Manifests, des
  Schemafingerprints und der Seed-Revision fail-closed geprüft und anschließend
  als exakt dasselbe Image veröffentlicht.

Scope and compatibility

• v0.1.2 bereitet ausschließlich diese kompatiblen Korrekturen seit
  v0.1.1 vor. Der Abschnitt beansprucht weder eine bereits erfolgte
  Veröffentlichung noch neue Digests; Tag, Veröffentlichung und Deployment
  bleiben getrennten Maintainer-Freigaben vorbehalten.

lzug 0.1.1

Added

• Eine taggebundene, flüchtige Demo-Assembly aus getrenntem Anwendungs- und
  Seed-Image mit synthetischen Daten, übereinstimmenden Produkt-, Commit- und
  Schemainformationen, eingeschränkten Demo-Sitzungen und einem
  Default-Deny-Schreibvertrag. Lokale Vertrags- und Smoke-Tests prüfen
  Artefaktpaar, Initialisierung und Reset-Grenzen.
• Reproduzierbare OpenTofu-Infrastruktur für eine öffentliche Demo in Azure
  Container Apps mit minimalen Identitäten, flüchtigem Datenvolume,
  Scale-to-zero und einem geplanten täglichen Neuaufbau aus dem gebundenen
  Seed-Artefakt.
• Ein OIDC-basierter Deploymentvertrag, der ausschließlich attestierte,
  unveränderliche Digests des zusammengehörigen Demo-Artefaktpaars akzeptiert,
  das Deployment prüft und einen digestgebundenen Rollback vorbereitet.
• Eine beschlossene Publikationsarchitektur für Landingpage,
  Entwicklerhandbuch, Code-Referenz und Wiki sowie ein reproduzierbarer lokaler
  Hugo-Spike. Er erstellt keine öffentliche Hosting-Ressource.

Changed

• Pull Requests verwenden selektive, merge-blockierende Prüfdomänen; der
  vollständige Quality-Workflow auf master bleibt der kanonische
  Release-Nachweis. Compose-Standardvalidierung und projektspezifische
  Self-Hosting-Policy werden dabei getrennt geprüft.
• Der Release-Workflow wird ausdrücklich auf dem aktuellen master mit dem
  vorgesehenen SemVer-Tag gestartet, verwendet den vollständigen
  Quality-Lauf derselben SHA und veröffentlicht nach Environment-Freigabe
  ausschließlich taggebundene OCI-, CLI-, SBOM- und Attestationsartefakte.
• Issue-/Milestone-Gates, einzelne Quality-Check-Abfragen, historische
  Bestandsvalidierung und v0.1.0-Sonderpfade wurden aus der aktiven
  Release-Automation entfernt.
• GoReleaser baut und verpackt die sechs reproduzierbaren Archive der
  Betreiber-CLI; der Release behält genau diese Archive und eine aggregierte
  CycloneDX-SBOM als sichtbare Assets und attestiert die gebundenen
  Lieferartefakte über GitHub.
• Pull-Request-Erstellung und Wiki-Publikation verwenden die direkten,
  dokumentierten GitHub- und Task-Schnittstellen ohne eigene parallele
  Zustands- oder Vorab-Publikationsautomation.

Scope and compatibility

• v0.1.1 ist ein kompatibler technischer Folgerelease für die vereinfachte
  Quality-, Release- und CLI-Lieferkette sowie die vorbereiteten Demo- und
  Publikationsverträge. Der offene fachliche Umfang von v0.2.0, insbesondere
  #25 und #315, ist nicht enthalten.
• Die Demo-Artefakte, Azure-Infrastruktur und Deploymentabläufe sind
  implementiert und lokal beziehungsweise in CI prüfbar, aber mit diesem
  Release noch nicht veröffentlicht oder ausgerollt. Es werden weder
  Artefakt-Digests noch eine öffentliche URL oder ein Live-Nachweis
  beansprucht; die Veröffentlichung und das Deployment bleiben getrennten,
  ausdrücklich freizugebenden Schritten vorbehalten.
• Die Publikationsarchitektur ist eine technische Entscheidung mit lokalem
  Spike. Landingpage, Handbuch, Code-Referenz und Wiki sind noch nicht über die
  vorgesehenen öffentlichen Plattformen bereitgestellt.
• v0.1.1 beansprucht weder fachliche Vollständigkeit noch produktive
  Self-Hosting-Reife. Allgemeines Backup, Restore, Upgrade und
  Produkt-Rollback bleiben außerhalb dieses Releaseumfangs.