Pilotprojekt · Hanseatisches Institut

LeadOS

Digitales Führungswerkzeug für die Aufgabenübergabe zwischen Unternehmer und Mitarbeiter.
Prototyp zum Testen
leados-design-foundation.lovable.app
↗ Prototyp öffnen
Öffnet der Button nicht direkt (z. B. in der Claude-App)? Link kopieren und im Browser einfügen.
Aktuell: Einladungsübersicht (S1b-3) und Kontoverwaltung (Konto entfernen, Kontostatus) sind umgesetzt, die Abnahme läuft. Einladungs-E-Mails werden derzeit nicht zugestellt: Störung beim Mail-Dienst der Plattform, der Anbieter ist informiert. Bis zur Behebung ruhen die Prüfungen, die eine ankommende E-Mail brauchen.Stand: 18.10.2026, 17:47 Uhr

Programmplan: pilotreif bis Weihnachten 2026

LeadOS soll bis Weihnachten 2026 funktionierend, dokumentiert und gut strukturiert sein. Pilotreif (GG-1) ist für Freitag, 18.12.2026, geplant; die drei Arbeitstage bis 23.12. sind Puffer. Der Plan zeigt den Bau in sieben Sprints, die Dokumentation daneben und die Kontrollpunkte. Hält der Plan nicht, entscheiden wir über den Umfang und nicht über die Qualität. Alle Termine sind Annahmen, keine Zusagen.
Zeitstrahl vom 15.10. bis 23.12.2026: Bau in den Sprints SP-1 bis SP-7 mit Puffer, Dokumentation D-1 bis D-6, Kontrollpunkte KP-1 bis KP-5, Meilenstein M-U am 01.12. und pilotreif GG-1 am 18.12.2026.
Letzte Aktualisierung: 16.10.2026. Zum vollständigen Programmplan mit Kontrollpunkten, Dokumentationspaket und Rückfallstufe.

Wo wir stehen

✓Grundlagen

Ziel, Zielgruppe und Rollen festgelegt

21.08.
✓Design & Ablauf

Aussehen und die fünf Arbeitsschritte festgelegt

22.08.
✓Klickbarer Ablauf

Alle fünf Schritte durchgängig nutzbar

25.08.
✓Fachliche Prüfung

Dieter hat die Inhalte geprüft und freigegeben

25.08.
✓Technische Absicherung

Arbeitsumgebung eingerichtet und abgesichert

27.08.
✓Usability-Test

Mit Jan durchgeführt, 5 Befunde protokolliert

08.09.
✓Nacharbeit

SystemCheck Teil 2, 3-Felder-Struktur, Rollenkennzeichnung

13.09.
✓Terminologie- & Muss-Check-Revision

Unternehmer als einheitlicher Begriff (PR #8), D-009/D-010 dokumentiert, Hinweis statt Reset

15.–17.09.
✓KI-Vorschlagsfunktion & Feldergänzungen

L-1–L-4: KI-Vorschlagsbutton und drei neue Felder umgesetzt und verifiziert

17.09.
✓MVP-Planung

Architekturkonzept, Backlog/Sprintplan und Rollenmodell-Arbeitshypothese erarbeitet

17.09.
✓Persistenz & Live-Abgleich

Echte Datenbank-Speicherung statt Zwischenspeicher im Browser; gleichzeitige Bearbeitung mit Zeitstempel-Schutz erkannt

13.–21.09.
✓Entwürfe & Startseite

Laufende Aufnahmen bleiben bis zum Abschluss unsichtbar; eigene Begrüßungs-Startseite mit Systemstatus und Git-Sync-Anzeige

26.09.
✓Hilfeseite & Barrierefreiheit

Hilfeseite mit Z-AVKK-Erklärung; Qualitätsprüfung mit Nacharbeit (Überschriften, Fokus, Kontrast)

06.–08.10.
✓Passwort & Profil

Passwort zurücksetzen und Profilseite zum Lesen umgesetzt, geprüft und abgenommen

09.10.
✓Dieter-Treffen, Teil 1

Beschlüsse zu Rollenmodell, Sichtbarkeit, Änderungsprotokoll und Profil; Gegenzeichnung durch Dieter vorgesehen

09.10.
✓Sitzung 2 mit Dieter

Pilotzeitraum und Freigaberegel bestätigt; Sichtbarkeit in der Firma festgelegt; Liste „Unvollständig“ bestätigt

14.10.
✓Plan v0.4

Acht Sprints bis zur Freigabe „pilotreif“ und darüber hinaus; Termine sind Annahmen, keine Zusagen

15.10.
●Sprint 1: Einladen und Annehmen

Regeln und Verwaltung der Einladungen, Ladefehler der Anmeldeseite (A2) sowie Versand und Annahme der Einladungen (S1b-2) abgenommen; als Nächstes die Übersicht der Einladungen (S1b-3)

läuft
○Liste „Unvollständig“ (Meilenstein M-U)

Mit erfundenen Daten vorführbar; danach Treffen mit Dieter

geplant
○Freigabe „pilotreif“

Bernd gibt frei, Dieter bestätigt fachlich; danach acht Wochen Pilot mit echten Daten

danach

Was jetzt gebraucht wird

Trag deine Antwort direkt hier ein — sie ist sofort für die weitere Planung sichtbar. Falls „Antwort senden" hier nicht geht (reiner Lesezugriff), schick die Antwort stattdessen per Nachricht zurück — sie wird dann hier nachgetragen.
✓ Beantwortet am 08.09.2026, 09:00 Uhr

Usability-Test: Teammitglied & Termin

Teammitglied
Jan
Termin
08.09.2026 (im laufenden Gespräch vereinbart)
✓ Eingetragen am 08.09.2026, 09:40 Uhr

Testergebnis dokumentieren

Testdatum
08.09.2026
Rückfragen
nicht als Einzelzahl erfasst – stattdessen 5 strukturierte Befunde protokolliert (siehe Beobachtungen)
Einschätzung
Erfolgreich mit Einschränkungen
Beobachtungen
Jan (Testperson): (1) Schritt 2 SystemCheck – zweiter Teil fehlt: negative Auswirkungen bei Zielerreichung, Gegenmaßnahmen, Umsetzungssituation je Maßnahme. (2) Schritt 3 – 3 separate Felder nötig für das MA-Verständnis von Aufgabe, Verantwortung, Kompetenzen. (3) Schritt 3/übergreifend – Kacheln müssen die ausfüllende Rolle (MA/FK) kennzeichnen. (4) Muss-Check-Logik bestätigt: Nichterfüllung → Abbruch, zurück zum Start. (5) Erläuterungstext dazu final festgelegt: „Wird dieser Muss-Check nicht bestätigt, kann nicht fortgefahren werden – der Ablauf beginnt von vorn.“
✓ Beantwortet am 08.09.2026, 10:05 Uhr

Abbruchkriterium für den Piloten (D-006)

Antwort
Scheitern liegt vor, wenn (a) niemand das Tool anwendet, (b) es keinen Nutzen bringt, oder (c) das inhaltliche Ziel des Z-AVKK-Ablaufs nicht erreicht wird. Schwellenwert: 8 Wochen ohne Nutzung/Nutzen. Gilt für den gesamten Fünf-Schritte-Ablauf. Entscheidung wird gemeinsam von Dieter und Bernd getroffen.
✓ Beantwortet am 08.09.2026, 10:15 Uhr

Glossar-Formulierung „SystemCheck“ bestätigen

Antwort
Passt so für die vier bestehenden Leitfragen. Wird zusätzlich um ein Beispiel ergänzt (liefert Dieter nach). Hinweis: Die Definition deckt bisher nur die vier ursprünglichen Leitfragen ab – der im Usability-Test gefundene zweite Teil (negative Auswirkungen, Gegenmaßnahmen, Umsetzungssituation) macht eine Erweiterung wahrscheinlich, sobald er umgesetzt ist.
Weitere Fragen erscheinen hier, sobald es welche gibt.

Nächste Schritte

Nach dem Testdurchlauf: gemeinsame Auswertung mit Dieter, danach die Pilotentscheidung — fortsetzen, anpassen oder stoppen.

Offene Punkte ohne Dieter

Was noch zu erledigen ist, bevor Dieters Rückmeldung kommt.

Verlauf

Aktuelle Berichte

Protokolle und Tagesberichte ab September 2026 werden hier laufend nachgeladen – neue Berichte erscheinen automatisch, ohne dass diese Seite selbst geändert werden muss.
Lade Berichte …

Alle Berichte & Dokumente

Das komplette Archiv – Memos, Tagesprotokolle und Unterlagen, jederzeit abrufbar.

Memos an Dieter

26.08.2026

Code-Verwaltung & KI-Unterstützung

Wir haben die Code-Verwaltung in eine eigene, gemeinsame Arbeitsumgebung verschoben – schützt besser vor Datenverlust und passt zu unserer Zusammenarbeit. Zusätzlich lassen wir die KI jetzt direkter am Code mitarbeiten, um technische Aufgaben schneller zu erledigen. Beides ändert nichts am App-Stand oder am Zeitplan für den Usability-Test. Ob du Zugriff auf die neue Arbeitsumgebung bekommst, besprechen wir im nächsten Meeting.

27.08.2026

Bedarf für den Usability-Test

Der Ablauf und Beobachtungsbogen liegen fertig vor. Gebraucht wird von dir noch ein Teammitglied für die Mitarbeiter-Rolle, ca. 20–30 Minuten für einen gemeinsamen Durchlauf mit dem Demodatensatz – wann das bei euch am besten passt, entscheidest du. Sobald ihr Zeit gefunden habt, schicken wir den Zugriffslink.

08.–09.10.2026

Offene Fragen an Dieter (Vorab-Mail und Teil-2-Mail)

Vorab-Mail versendet 08.10.2026, Teil-2-Mail versendet 09.10.2026. Frist für alle Antworten: Mi 14.10.2026. Rückfallregel: Ohne Antwort gilt der Vorschlag als dokumentierte Annahme (nicht bei 2.1, 5.3, M5 und M6). In Sitzung 1 am 09.10. beschlossen, Gegenzeichnung durch Dieter vorgesehen: M1 – Schritt-5-Formular bleibt, „Neu starten“ als neuer Durchlauf (Lesart A). M3 – Änderungsprotokoll im ersten Ausbau, früh. Offen, jeweils Status „offen“, Frist 14.10.2026: M2 – DSGVO: Aufbewahrung nach Austritt, verantwortliche Stelle, Einwilligung; externer Dienst der KI-Prüfung. Vorschlag: Löschung nach Frist, per Konfiguration änderbar. M4 – Regelwerk der KI-Prüfung als aktueller Stand. Vorschlag: schriftlich bestätigen oder korrigieren. M5 – SystemCheck-Formulierung und Glossar-Beispiel. Vorschlag: als Text per E-Mail (kein Rückfall). M6 – Quelle und Autor in der Hilfe: Freigabe, Schreibweise, Institut, URL, Anrede. (kein Rückfall). T-1 – Was heißt „sein Team“ beim Unternehmer? Vorschlag: nur die zugeordneten Mitarbeiter, Zuordnung bei der Einladung. Muss vor den Zugriffsregeln (S3) bestätigt sein. T-2 – Was sind „eigene“ Einträge eines Mitarbeiters? Vorschlag: was ihm zugeordnet ist, Auswahl aus dem Team in Schritt 1. Muss vor den Zugriffsregeln (S3) bestätigt sein. U-1 – Wandert ein Eintrag aus der U-Liste nach bestandenem Durchlauf automatisch zurück in die Z-AVKK-Liste? Vorschlag: ja. U-2 – Name „Unvollständig“ beibehalten? Vorschlag: ja, im Glossar erklären. U-3 – Wann ist ein Eintrag unvollständig? Vorschlag: Durchlauf nicht abgeschlossen, ein Prüfpunkt fehlt, keine Ressourcen oder kein Zuständiger. 2.1 – Pilotentscheidung und Startdatum der 8 Wochen. Vorschlag: Go, 09.10. bis 04.12.2026 (kein Rückfall). 2.2 – Nachträgliche Freigabe der vorab gebauten Teile; Bestätigung von D-008, D-009-Revision und D-014. Vorschlag: ja. 2.3 – Testdaten aus dem Piloten. Vorschlag: erfundene Testdaten zurücksetzen. Block 4 – Firmen und Anmeldung: Firmen streng getrennt, Bernd und Dieter als firmenübergreifende Admins; es melden sich nur Mitarbeiter und Unternehmer an; Anmeldung mit E-Mail und Passwort, später bei Bedarf Single Sign-on. Vorschlag: jeweils ja. Block 5 – SystemCheck-Button: dieselben Fragen aus Sicht des Mitarbeiters; Antworten in der gemeinsamen Sitzung für beide sichtbar, gespeichert wird nur, was beide bestätigen; Wortlaut der Fragen (5.3, kein Rückfall).

Entscheidungen

21.08.2026Zielgruppe des PilotenAngenommen
Der Pilot konzentriert sich auf die Beziehung Inhaber–Mitarbeiter. Die Erweiterung um die Führungskraft-Ebene ist bewusst für eine spätere Phase vorgesehen.
21.08.2026Kernproblem des PilotenAngenommen
Der Führungskreislauf bricht typischerweise an vier Stellen: Ziele werden ohne SystemCheck festgelegt, Aufgaben werden ohne Rückprüfung übergeben, Verantwortung wird nicht als Gefühl geprüft, und Kompetenzen/Ressourcen werden nicht kontrolliert.
21.08.2026Der getestete AblaufAngenommen
Fünf Schritte, gemeinsam am Bildschirm von Inhaber und Mitarbeiter durchlaufen – kein Alleingang. Vertiefte Themen (Verantwortungs- und Kompetenzprüfung) folgen erst in späteren Sprints.
21.08.2026Rollen im ProjektAngenommen
Dieter trägt die fachliche Verantwortung. Bernd trägt Produkt- und Umsetzungsverantwortung. Claude unterstützt bei Architektur und technischer Struktur – mit Dieters Vetorecht, sobald es fachliche Auswirkungen hat.
21.08.2026Testpersonen und TestdatenAngenommen
Dieter testet mit seinem eigenen Team und moderiert selbst. Es wird ausschließlich mit erfundenen, klar gekennzeichneten Testdaten gearbeitet – volle Transparenz, kein verstecktes Bewerten einzelner Personen.
08.09.2026Wann gilt der Test als erfolgreich? / Abbruchkriterium PilotAngenommen
Testerfolg: Der Ablauf wird ohne zusätzliche mündliche Erklärung verstanden (von Dieter am 25.08. bestätigt). Ergänzend am 08.09. geklärt: Der Pilotbetrieb (nach Start) gilt als gescheitert, wenn niemand das Tool anwendet, es keinen Nutzen bringt, oder das inhaltliche Ziel nicht erreicht wird – Schwellenwert 8 Wochen, gilt für den gesamten Ablauf, Entscheidung gemeinsam durch Dieter und Bernd. Löst die zuvor rein auf Rückfragen-Anzahl gestützte, noch offene Formulierung ab.
22.08.2026Technische ArbeitsumgebungAngenommen
Die technische Arbeitsumgebung für die Code-Verwaltung wurde eingerichtet und mehrfach angepasst, zuletzt am 26.08. in eine gemeinsame, besser abgesicherte Umgebung verschoben (siehe Memo).
–Technische Basis nach dem PrototypVertagt
Diese Entscheidung wird bewusst erst nach dem Usability-Test getroffen, wenn klar ist, wie es mit dem Piloten weitergeht.
25.08.2026Umfang von Schritt 2 (SystemCheck)Angenommen
Schritt 2 bekommt die echte SystemCheck-Struktur (Vorteile der Gegenwart, Maßnahmen, Umsetzung, Aktionsplan-Übersicht) – aber in einfacher, statischer Form ohne KI-generierte Vorschläge, PDF-Export oder dauerhafte Speicherung. Die volle Version bleibt bewusst spätere Zukunftsvision.
29.08.2026Organisationsstruktur für TDF/ADFAngenommen
TDF und ADF liegen jetzt in einer eigenen, projektneutralen Organisation (bmarnau-standards, GitHub Team) statt in LeadOS-Org – damit bleiben die projektübergreifenden Engineering-Standards organisatorisch von LeadOS getrennt, auch wenn das eine zusätzliche Team-Lizenz kostet.
15.09.2026Terminologie-Vereinheitlichung UnternehmerAngenommen
„Führungskraft“ und „Inhaber“ im Rollenmodell zu einem einheitlichen Begriff „Unternehmer“ zusammengeführt (Badge-Kürzel „FK“ bleibt bestehen). Umgesetzt in leados-design-foundation via Pull Request #8.
15.09.2026D-009-Revision: KI-Vorschläge im SystemCheck erlaubtAngenommen
SystemCheck (Schritt 2) erhält an zwei Stellen einen KI-Vorschlagsbutton (zustandsloser LLM-Aufruf, Auswahl statt Autofill) – ergänzt D-009. PDF-Export, dauerhafte Speicherung und ein Assistent bleiben weiterhin ausdrücklich ausgeschlossen.
15.09.2026Muss-Check-Verhalten: Hinweis statt ResetAngenommen
Ersetzt das bisherige Reset-Verhalten aus Befund 4 (Usability-Test M1-006): Inline-Hinweis am fehlenden Feld plus Sprungmöglichkeit statt komplettem Neustart des Ablaufs. Kein Datenverlust bei fehlender Angabe mehr.
17.09.2026MVP-ZieldefinitionAngenommen
MVP startet mit einer Firma und zwei Rollen (Unternehmer, Mitarbeiter). Servicebereich (Begrüßung, Kontopflege, Stammdatenpflege, Backup, Servicestatus, PDF-Export, Hilfe/Handbuch) ist Teil des MVP. Sprintlänge 2 Wochen, Dieter testet und gibt nach jedem Sprint frei, bevor der nächste als abgeschlossen gilt.
17.09.2026Rollenmodell-ArbeitshypotheseVorgeschlagen
Aus Dieters Rückmeldung abgeleitet: Unternehmer wird zur operativen Spitze, Inhaber zum reinen Eigentums-Attribut ohne eigene Zugriffsrechte (statt eigener Hierarchiestufe). Noch NICHT bestätigt – vier Detailfragen dazu liegen Dieter vor (siehe Auftragssammlung).
18.09.2026Sprint 1.5 — Z-AVKK-Liste lokal (Epic G)Angenommen
Die Z-AVKK-Liste wird vorgezogen und unabhängig von Auth und Persistenz (Sprint 2) als eigener Sprint 1.5 umgesetzt – lokal im Browser gespeichert, spätere Migration in die Datenbank mit Sprint 3. Ein Ziel kann mehrere Aufgaben haben; der Unternehmer legt weitere Aufgaben manuell an (kein KI-Vorschlag). Auf-/Ab-Buttons statt Drag & Drop, Kapazitätsrechnung und KI-Prüfung der Gesamtliste sind Teil des Umfangs, Export als CSV/Excel und als PDF/Druck.
21.09.2026Referenzierte externe Standards (bmarnau-standards)Angenommen
LeadOS referenziert ab sofort die Standardfamilie unter bmarnau-standards (AI Development Governance, Technical Documentation Framework, Application Quality Gate Standard, Security Standard, DSGVO Compliance, AI Act Compliance) als ergänzende, projektübergreifende Grundlage – ersetzt nicht AGENTS.md, die LeadOS-Verfassung oder den Pilot Charter. Konkrete technische Einbindung (z. B. ein Quality-Gates-Profil) ist damit noch nicht verbunden, siehe ADR-0006 in leados-design-foundation.
28.09.2026Änderungen am Hauptzweig (main) nur noch geprüftAngenommen
Am Programmcode (leados-design-foundation) und an den Standards (bmarnau-standards) wird nicht mehr direkt geändert, sondern nur über einen Pull Request, den Bernd freigibt; beim Programmcode muss zusätzlich die automatische Prüfung grün sein. Ausnahme: der GitHub-Abgleich von Lovable. Berichts- und Statusseiten dürfen direkt geändert werden, aber nur mit signierten Änderungen. Auf GitHub technisch eingerichtet. Siehe D-012 in DECISIONS.md.
28.09.2026Handbuch, Glossar und Entwicklungstagebuch in der AppAngenommen
„Was ist neu“ sehen alle Angemeldeten. Das technische Handbuch erscheint in der App nur für Plattform-Admins. Fachliche Glossar-Begriffe gibt Dieter frei, technische Bernd. Inhalte werden vorerst nur im Repository gepflegt, nicht in der App. Das Glossar liegt als strukturierte Daten vor, Handbuch und Tagebuch als Markdown. Siehe D-013 in DECISIONS.md.
08.10.2026D-009-Revision: Ablauf-Entwurf wird gespeichertEntscheidung von Bernd am 08.10.2026 · Frage 2.2 am 14.10.2026 nicht besprochen, gilt als dokumentierte Annahme
ADR-0007 ersetzt die bisherige Nicht-Speicherung für den Ablauf-Entwurf. Auflage: Bis die Zugriffsregeln stehen, werden nur erfundene Testdaten verwendet. Siehe D-009 in DECISIONS.md.
08.10.2026D-008-Nachtrag: Technische BasisEntscheidung von Bernd am 08.10.2026 · Frage 2.2 am 14.10.2026 nicht besprochen, gilt als dokumentierte Annahme
Technische Basis: Supabase, Drizzle, TanStack Start, Lovable. Die Risiken sind benannt. Hosting und Betrieb nach dem Piloten bleiben eine offene Frage. Siehe D-008 in DECISIONS.md.
08.10.2026D-012-Ergänzung: Paketänderungen durch LovableEntscheidung von Bernd am 08.10.2026
Paketänderungen durch Lovable sind erlaubt, wenn die automatische Prüfung (CI) grün ist. Sie werden im Diff-Check und im CHANGELOG gemeldet; Hauptversionen werden geprüft. Siehe D-012 in DECISIONS.md.
08.10.2026D-014 (Arbeitsannahme): Zugriffsregeln vor dem Rest der SpeicherungEntscheidung von Bernd am 08.10.2026 · Frage 2.2 am 14.10.2026 nicht besprochen, gilt als dokumentierte Annahme
Arbeitsannahme: Die Zugriffsregeln werden umgesetzt, bevor der Rest der dauerhaften Speicherung folgt. Siehe D-014 in DECISIONS.md.
09.10.2026Beschluss Sitzung 1: Rollen, Einladung, Sichtbarkeit, Löschen, ÄnderungsprotokollBeschluss Sitzung 1 vom 09.10.2026 · Sichtbarkeit abgelöst durch D-038 (14.10.2026)
Rollen: drei Rollen (Admin, Unternehmer, Mitarbeiter); Admin bleibt ein Kennzeichen. Einladung: Admin lädt Unternehmer ein, Unternehmer lädt Mitarbeiter ein; Firma und Rolle kommen mit der Einladung, nie automatisch. Sichtbarkeit: Entwürfe und U-Liste zeigen eigene Einträge, der Unternehmer sieht sein Team. Löschen: nur der Admin löscht endgültig; Archiv mit drei Generationen (Testannahme). Offboarding: Einträge ohne Zuständigen wandern automatisch in die U-Liste. Rollenänderung: Der Unternehmer darf Rollen ändern, vergibt aber keine Admin-Rechte, und der letzte Unternehmer einer Firma bleibt. Änderungsprotokoll: im ersten Ausbau, früh; Umfang Rollenänderung, Löschung, Änderung an Ziel und Aufgabe; Lesezugriff zunächst nur Admin, keine Auswertung. Schritt-5-Formular bleibt (Lesart A). Profil: jetzt, nur lesend (inzwischen umgesetzt). Rahmen: bis auf Weiteres nur erfundene Testdaten. Nachtrag 14.10.2026: Die Regel zur Sichtbarkeit ist durch D-038 abgelöst (in einer Firma sehen alle alle Einträge, ändern darf nur der Autor).
14.10.2026D-031: Pilotzeitraum – acht Wochen ab Freigabe „pilotreif“Angenommen
Der Pilot dauert acht Wochen und beginnt mit der Freigabe „pilotreif“ (Golden Gate 1). Davor wird nur mit erfundenen Testdaten gearbeitet, ohne Bewertung. Ziel ist die Freigabe bis 04.12.2026; zeichnet sich bis 20.11.2026 keine Freigabe ab, wird mit Dieter gesprochen. Vorgeschlagen von Bernd am 13.10.2026, von Dieter am 14.10.2026 bestätigt.
14.10.2026D-035: Freigabe und StellvertretungAngenommen
Bernd gibt frei, Dieter bestätigt fachlich und vertritt bei Abwesenheit. KI-Werkzeuge entscheiden nie. Von Dieter am 14.10.2026 bestätigt.
13.10.2026D-036: Fehlermeldungen der App werden 30 Tage aufbewahrtAngenommen
Fehlermeldungen der App werden nach 30 Tagen automatisch gelöscht. Entscheidung von Bernd, umgesetzt und in der Produktion geprüft.
14.10.2026D-037: Einheitliche Einstellungen der RepositoriesAngenommen
Die drei GitHub-Repositories haben einheitliche Schutzeinstellungen; übernommen wird nur noch per Squash-Merge. Entscheidung von Bernd, umgesetzt.
14.10.2026D-038: Sichtbarkeit und Schreibrecht innerhalb der FirmaAngenommen
Alle Nutzer einer Firma sehen alle Einträge der Firma, auch Entwürfe. Ändern und archivieren darf nur, wer den Eintrag angelegt hat; endgültig löschen darf nur der Admin. Das Team des Unternehmers sind alle Mitarbeiter der Firma. Firmen bleiben streng getrennt. Fachliche Entscheidung von Dieter in der Sitzung vom 14.10.2026; löst die Sichtbarkeitsregel aus Sitzung 1 ab. Umsetzung mit den Zugriffsregeln (S3).
15.10.2026D-039: Plan v0.4 als ArbeitsgrundlageAngenommen
Plan v0.4 ist ab 15.10.2026 Arbeitsgrundlage und ersetzt die Reihenfolge aus Plan v0.3. Das Änderungsprotokoll kommt nach der Liste „Unvollständig“; die Behebung des Ladefehlers der Anmeldeseite (A2) kommt vor Versand und Annahme der Einladungen; der Wortlaut der Aufträge entsteht erst zum Sprintstart; Zwischenziel ist die Liste „Unvollständig“ mit erfundenen Daten (Meilenstein M-U), danach Treffen mit Dieter. Entscheidung von Bernd.
15.10.2026D-040: Nachlauf S1b-1 nachträglich angenommenAngenommen
Zusätzliche Server-Prüfungen und Tests, die beim Lauf für Regeln und Verwaltung der Einladungen (S1b-1) über den Auftrag hinaus entstanden sind, wurden geprüft und nachträglich angenommen. Solche Tests stehen künftig ausdrücklich im Auftrag. Entscheidung von Bernd.
15.10.2026D-041: Widerruf abgelaufener Einladungen fremder Mandanten bleibt erlaubtAngenommen
Eine abgelaufene Einladung darf weiterhin widerrufen werden, auch vom Unternehmer; der Widerruf ändert nur ihren gespeicherten Status. Entscheidung von Bernd.
15.10.2026D-042: Abnahme LP-1.2 (A2) mit AuflagenAngenommen
Ladefehler der Anmeldeseite messbar gemacht, Sprache der Seite auf Deutsch, deutsche Fehlerseite; geprüft und mit Auflagen abgenommen, die Auflagen sind behoben. Entscheidung von Bernd.
16.10.2026D-043: Annahme der Einladung beim Versand (Variante A)Angenommen
Eine Einladung gilt als angenommen, sobald sie versendet ist; das Konto entsteht dabei. Keine Änderung der Datenbank nötig. Die Adresse wird vor dem Versand zur Bestätigung angezeigt. Entscheidung von Bernd.
16.10.2026D-044: Zuschnitt S1b-2Angenommen
Eigene Seite zur Annahme der Einladung, geprüfte Zieladresse für den Link, höchstens 20 Einladungen je Firma und Tag, Versand vorab automatisch getestet. Entscheidung von Bernd, bestätigt am 16.10.2026.
16.10.2026D-045: Freigabe nur durch BerndAngenommen
Einen Umsetzungslauf gibt nur Bernd frei. Das ausführende Werkzeug ergänzt keine Freigabe selbst und bricht ab, wenn sie fehlt oder abweicht. Entscheidung von Bernd.
16.10.2026D-046: Abnahme LP-1.3 (S1b-2) mit BefundenAngenommen
Versand und Annahme der Einladungen (S1b-2) sind umgesetzt, automatisch und mit einer Testeinladung geprüft und abgenommen. Zwei kleinere Befunde sind für später vermerkt. Entscheidung von Bernd.

Tagesprotokoll

20.–21.08.2026Grundlagen & Sprint-00-Gespräch
Projektunterlagen gesichtet, offene Fragen vorbereitet. Am 21.08. gemeinsames Gespräch mit Dieter: Zielgruppe, Kernproblem, die fünf Arbeitsschritte, Pilotumfang, Rollen und Testrahmen besprochen und freigegeben.
22.08.2026Design & erste Umsetzung
Optik festgelegt (Navy/Blau), alle fünf Arbeitsschritte als klickbarer Entwurf umgesetzt, Arbeitsumgebung für die Code-Verwaltung eingerichtet.
25.08.2026Ablauf fertiggestellt & fachlich geprüft
Schritt 2 (SystemCheck) fachlich ausgebaut – damit ist der komplette Ablauf inhaltlich fertig. Dieter hat die Inhalte im Gespräch geprüft und freigegeben. Leitfaden für den Usability-Test (Beobachtungsbogen, Interviewfragen) erstellt.
26.08.2026Technische Absicherung
Arbeitsumgebung in eine eigene, gemeinsame Umgebung verschoben und gegen versehentliches Löschen abgesichert; die KI arbeitet seither direkter am Code mit. Zusätzlich eine 4-seitige Management-Übersicht (Topologie, Plan bis MVP) erstellt, siehe Dokumente unten.
27.08.2026Letzte Prüfung & Testvorbereitung
Letzte technische Prüfung abgeschlossen, Erfolgskriterien und Beobachtungsbogen bestätigt. Neue Regel eingeführt: Termine mit Dieter werden nicht mehr mit Kalendertagen vorgeschlagen, sondern nur der Bedarf genannt – den Zeitpunkt bestimmt Dieter. Diese zentrale Übersichtsseite eingerichtet, auf der ab jetzt alle Informationen und offenen Fragen gesammelt abrufbar sind.
28.08.2026M1-004d an Codex und Lovable übergeben
Dieter hat das PDF-Ausweichformular erhalten und testet den Ablauf in der kommenden Woche; bis dahin werden hier die Punkte bearbeitet, die ohne Dieter möglich sind. M1-004d wurde in zwei aufeinander abgestimmten Aufträgen fertiggestellt: ein Lovable-Auftrag stellt die Muss-Check-Gates in Schritt 1–3 selbst her bzw. prüft sie, ein Codex-Auftrag deckt sie mit einer automatisierten Playwright-Testsuite ab. Beide respektieren dieselbe Regel: keine neuen data-testid-Attribute, da die Tests bewusst auf Rollen, Labels und sichtbaren Text setzen. Codex hat bereits geantwortet; der Lovable-Auftrag ist jetzt offen.
29.08.2026Lovable-Auftrag verifiziert: Muss-Check-Gates aktiv
Lovable meldet alle drei Gates gesetzt und verifiziert: Schritt 1 sperrt „Weiter“ bis „Ziel und Aufgabe für Inhaber klar?“ bestätigt ist, Schritt 2 bis „SystemCheck durchgeführt?“, Schritt 3 bis alle drei Muss-Checks bestätigt sind (Test bestätigt: nach Check 1 und 2 weiterhin gesperrt, erst nach Check 3 frei). Solange ein Gate geschlossen ist, erscheint ein Hinweistext neben dem Button. Vollständiger Demodurchlauf funktioniert, Ziel/Aufgabe erscheinen weiterhin in Schritt 2/3, Labels („Ziel“, „Aufgabe“, „Antwort 1“, „Maßnahme 1“, „Rückmeldung“) und Zugänglichkeit (role="checkbox"/aria-checked) sind erhalten. Schritte 4/5 sowie Texte und Gestaltung wurden nicht verändert. Der Codex-Auftrag (automatisierte Tests) ist damit die einzige noch offene Teilaufgabe von M1-004d.
29.08.2026M1-004d abgeschlossen: Testautomatisierung gemergt, CI grün
Codex' Pull Request enthielt eigene Änderungen an denselben drei Gate-Dateien wie Lovables Umsetzung – ein Merge-Konflikt, der bewusst zugunsten von Lovables bereits verifizierter Version aufgelöst wurde. Ein zweiter, nachgereichter Pull Request stabilisierte die Tests gegen asynchrones Laden. Ergebnis: automatisierter Testlauf ist grün, deckt alle fünf Schritte, die Dateneingabe, die Zustandsübergabe zwischen den Schritten und die Muss-Check-Gates ab. Keine Lovable-Komponenten dauerhaft verändert. Damit ist M1-004d – die Testautomatisierung vor dem Usability-Test – vollständig abgeschlossen.
29.08.2026Governance-Infrastruktur: Branch-Protection scharf geschaltet
GitHub Free erzwingt Branch-Protection-Regeln auf privaten Repos nicht – das wurde bei der Einrichtung entdeckt. Als Lösung wurde eine neue, projektneutrale Organisation (bmarnau-standards, GitHub Team) angelegt und TDF sowie ADF dorthin verschoben, statt sie in die bestehende, LeadOS-spezifische Organisation zu legen. Auf main gilt in beiden Repos jetzt: Pull-Request-Pflicht (0 Pflicht-Approvals) und signierte Commits – beides einzeln geprüft und bestätigt. Require-status-checks bleibt vorerst aus, da an diesem Standort noch kein CI-Lauf vorliegt und GitHub sonst keinen Check zur Auswahl anbietet. Offen: lokale Commit-Signierung bei Bernd einrichten (Voraussetzung für den nächsten eigenen Push auf main), Status der Claude-GitHub-App in der neuen Organisation bmarnau-standards prüfen (separat von der unten bestätigten LeadOS-Org-Installation).
29.08.2026M1-008 geprüft: bereits erledigt
Letzter Punkt der „ohne Dieter“-Liste geprüft: Claude GitHub App war bereits seit 26.08.2026 organisationsweit in LeadOS-Org installiert (Zugriff auf alle Repos), der Workflow .github/workflows/claude.yml in leados-design-foundation korrekt konfiguriert (Trigger auf @claude-Kommentare, kein Auslösen durch eigene Bot-Antworten), die Zugangsdaten hinterlegt. Aus der Lauf-Historie bestätigt: 8 Workflow-Läufe, davon mindestens 2 erfolgreiche, echte @claude-Antworten auf Issue #2. Es war keine weitere Handlung nötig – der Punkt war lediglich noch nicht als erledigt dokumentiert. Damit ist die aktuelle Liste der ohne Dieter bearbeitbaren Punkte für heute abgearbeitet.
31.08.2026GitHub-App-Status bmarnau-standards geklärt: nur Organisations-Installation fehlte
Auf Bernds Frage „was können wir heute ohne Dieter umsetzen“ wurden die drei verbliebenen offenen Punkte vom 29.08. angegangen. Zuerst wurde eine Schritt-für-Schritt-Anleitung zur lokalen SSH-Commit-Signierung an Bernd übergeben (Schlüsselerzeugung, Git-Konfiguration, Hinterlegung als Signing Key bei GitHub, Verifizierung per Test-Commit) – die Ausführung liegt bei Bernd selbst, da kein Terminalzugriff auf seinen Rechner besteht und privates Schlüsselmaterial ohnehin nicht extern erzeugt werden sollte. Mit Bernds ausdrücklicher Freigabe wurde anschließend die Claude GitHub App organisationsweit (alle Repositories) in bmarnau-standards installiert. Dabei stellte sich eine ursprüngliche Annahme als falsch heraus: Workflow-Datei (.github/workflows/claude.yml) und die Zugangsdaten existierten in TDF und ADF bereits seit EXT-001 (27.08.) und hatten den Organisationsumzug am 29.08. unbeschädigt überstanden – die einzige tatsächliche Lücke war die fehlende App-Installation auf Organisationsebene. Ein anschließender Funktionstest per @claude-Kommentar auf dem bestehenden Test-Issue #9 (TDF) bestätigte Lesezugriff und korrekte Funktion ohne ungewollte Änderungen. Damit ist dieser Punkt vollständig abgeschlossen; offen bleiben die SSH-Signierung (bei Bernd) und die davon abhängigen Require-status-checks.
31.08.2026Nachfrage nach weiteren Punkten: verwaiste PR gefunden und geschlossen
Auf Bernds Nachfrage „was koennen wir noch ohne Dieter tun“ wurde der Repository-Zustand aller drei Code-Repos (leados-design-foundation, TDF, ADF) systematisch gegengeprueft, nicht nur die bekannte offene Liste. Dabei kam eine Diskrepanz zum Vorschein: Pull Request #6 in leados-design-foundation („stabilize M1-004d five-step E2E flow“) hatte alle Checks gruen und keine Konflikte, war aber nie tatsaechlich gemergt worden, obwohl der Projektstatus vom 29.08. M1-004d bereits als vollstaendig abgeschlossen dokumentiert hatte. Mit Bernds ausdruecklicher Freigabe wurde der PR gemergt (main jetzt bei Commit e8500b8) und der Feature-Branch geloescht. Zusaetzlich wurde das laengst erledigte Issue #2 (M1-001, Governance-Dateien) geschlossen, das seit dem 26.08. offen geblieben war. TDF und ADF wurden ebenfalls gegengeprueft: beide 0 offene Pull Requests. Lehre daraus: ein als „abgeschlossen“ dokumentierter Meilenstein ersetzt keine Pruefung des tatsaechlichen Repository-Zustands (Merge-Status), da beides auseinanderlaufen kann.
08.–09.09.2026Usability-Test durchgeführt, offene Fragen geklärt, Berichts-Infrastruktur aufgebaut
Jan hat den Fünf-Schritte-Ablauf getestet und fünf strukturierte Befunde geliefert (SystemCheck-Erweiterung um negative Auswirkungen/Gegenmaßnahmen/Umsetzungssituation, 3-Felder-Struktur für das MA-Verständnis in Schritt 3, Rollenkennzeichnung auf den Kacheln, sowie die Muss-Check-Abbruchlogik und ihr finaler Erläuterungstext). Anschließend wurden mit Dieter alle verbliebenen Fragen aus dem Fragenkatalog geklärt: D-006 (Abbruchkriterium für den Pilotbetrieb: keine Nutzung/kein Nutzen/Ziel verfehlt, Schwellenwert 8 Wochen, gesamter Ablauf, gemeinsame Entscheidung Dieter+Bernd), das Glossar „SystemCheck“ (Formulierung bestätigt, Beispiel von Dieter in Aussicht) und M1-007 (automatische Freigabe der Pilotentscheidung nach Umsetzung der drei Testbefunde). Parallel wurde eine dauerhafte Lösung für die wachsende Berichtsliste dieser Seite umgesetzt: ein eigenes, öffentliches Repository (leados-reports) speichert Berichte künftig als einzelne, versionierte JSON-Dateien; diese Seite lädt sie zur Laufzeit und zeigt sie filterbar an, statt jeden Bericht einzeln in den Seitencode einzutragen. Im Zuge dessen wurde diese Übersichtsseite selbst von der bisherigen claude.ai-Artifact-Ansicht auf eine eigenständige, statische GitHub-Pages-Seite umgestellt, da in der bisherigen Ansicht keine Bearbeitungssitzung mehr erreichbar war.

Dokumente

Programmplan Pilot-MVP

Weg bis pilotreif (GG-1) am 18.12.2026: Sprints, Dokumentation und Kontrollpunkte

↗ öffnen

Management-Übersicht LeadOS

4 Seiten – Aufbau des Projekts, Plan bis zum fertigen Piloten (MVP)

wird separat per Nachricht verschickt

Tagesbericht 27.08.2026

Governance-Synchronisation (EXT-001) abgeschlossen, drei bestehende Framework-Pull-Requests geprüft

↗ öffnen

Tagesbericht 28.08.2026

M1-004d an Codex und Lovable übergeben, Dieters Testtermin für kommende Woche bestätigt

↗ öffnen

Tagesbericht 29.08.2026

M1-004d und M1-008 abgeschlossen, Branch-Protection auf TDF/ADF scharf geschaltet, Organisationsumzug bmarnau-standards

↗ öffnen

Plan im Überblick

Reine Info zur Orientierung – nicht interaktiv.
  • Grundlage: Umsetzungsplan v0.4 (15.10.2026, Entscheidung D-039). Er ersetzt die Fassung v0.3. Termine sind Annahmen, keine Zusagen; Qualität geht vor Datum.Aktuell
  • P0 — Sofortmaßnahmen: Passwort zurücksetzen, Mindestlänge für Passwörter, Hinweis bei gleichem Passwort, Profilseite zum Lesen.Erledigt
  • B7 — Profil bearbeiten: Vorname und Nachname, Passwort ändern (B7a, B7b, B7c).Erledigt
  • SP-1 — Einladen und Annehmen: Regeln und Verwaltung der Einladungen (S1b-1), Ladefehler der Anmeldeseite mit deutscher Fehlerseite (A2) sowie Versand und Annahme der Einladungen (S1b-2) erledigt, 3 von 7 Läufen; als Nächstes Übersicht der Einladungen (S1b-3).Läuft
  • SP-2 — Zugriffsregeln (S3): Innerhalb einer Firma sehen alle alle Einträge, ändern darf nur der Autor; Firmen streng getrennt (D-038).Geplant
  • SP-3 — Ablauf speichern: Die Schritte 1 bis 5 werden dauerhaft gespeichert; Voraussetzung der Liste „Unvollständig“.Geplant
  • SP-4 — Liste „Unvollständig“ mit Filter, Sortierung und Farbe. Meilenstein M-U: mit erfundenen Daten vorführbar, danach Treffen mit Dieter.Geplant
  • SP-5 — Änderungsprotokoll (S3A).Geplant
  • SP-6 — Datenschutz-Mechanik (S4): Einwilligung, Auskunft, Löschfrist, Archiv; muss vor echten Daten fertig sein.Geplant
  • SP-7 — Referenzdaten und Gesamtprüfung; Freigabe „pilotreif“: Bernd gibt frei, Dieter bestätigt fachlich (D-035).Geplant
  • SP-8 — Vollausbau nach Pilotstart: Komfort und Sicherheit, mehrere Firmen absichern.Geplant
  • Testkonzept: seit 21.09. bekommt jeder Sprint einen eigenen, expliziten E2E-Test-Prompt (Claude Code), nicht mehr implizit vorausgesetzt.Aktuell

Entwicklungsverlauf

Reine Info zur Orientierung – nicht interaktiv.
  • 20.08.2026Projektgrundlagen zusammengetragen, offene Fragen für das erste Gespräch mit Dieter vorbereitet.
  • 21.08.2026Gespräch mit Dieter: Ziele, Zielgruppe, Rollen und Testrahmen besprochen und freigegeben.
  • 22.08.2026Design festgelegt, alle fünf Arbeitsschritte als klickbaren Entwurf umgesetzt, Arbeitsumgebung eingerichtet.
  • 25.08.2026Ablauf fachlich vervollständigt, mit Dieter geprüft und freigegeben; Leitfaden für den Usability-Test erstellt.
  • 26.08.2026Arbeitsumgebung in eine gemeinsame, abgesicherte Umgebung verschoben.
  • 26.08.2026Management-Übersicht (4 Seiten) erstellt.
  • 27.08.2026Letzte technische Prüfung abgeschlossen.
  • 27.08.2026Neue Terminregel für Dieter eingeführt; Vorbereitungs-Memo entworfen.
  • 27.08.2026Diese Übersichtsseite entworfen, gebaut und veröffentlicht.
  • 27.08.2026Archiv mit Memos, Tagesprotokoll und Dokumenten ergänzt.
  • 27.08.2026Zwei zusätzliche offene Fragen ergänzt (Abbruchkriterium, Glossar-Bestätigung).
  • 27.08.2026Freigabe für Dieter eingerichtet; Link verschickt.
  • 27.08.2026Entscheidungsübersicht sowie dieser Plan- und Entwicklungsverlauf ergänzt.
  • 27.08.2026Prototyp-Link ergänzt und Erreichbarkeit geprüft (öffentlich, fünf Schritte durchgängig verlinkt).
  • 27.08.2026Claude GitHub App auf beiden externen Standard-Repos (ADF, TDF) eingerichtet und getestet.
  • 27.08.2026Zwei Governance-Funde behoben und gemergt: fehlende Repo-Struktur in TDF, verallgemeinerte KI-Rollenbezeichnung in ADF.
  • 27.08.2026Drei bestehende TDF-Pull-Requests geprüft: zwei gemergt, eine bewusst als Entwurf geparkt.
  • 27.08.2026Tagesbericht erstellt und veröffentlicht (siehe Dokumente oben).
  • 27.08.2026Prototyp-Link auf aktuelle Adresse (sysingdashboard.lovable.app) umgestellt, geprüft (öffentlich erreichbar, Anmeldung nötig) und als gut sichtbares Element direkt unter der Überschrift platziert.
  • 27.08.2026Eingabefeld „Testergebnis dokumentieren” ergänzt (Datum, Anzahl Rückfragen gemäß D-006, Einschätzung, Beobachtungen) – Ergebnis wird direkt beim Absenden veröffentlicht und ist damit für alle abrufbar.
  • 27.08.2026Fehler gefunden und behoben: In der Claude-App öffnete der Prototyp-Link-Button nicht (App fängt die Navigation ab, nur auf dem Handy betroffen – am PC funktioniert es). Ausweichlösung ergänzt: „Link kopieren“-Button plus sichtbares Textfeld mit dem Link zum manuellen Kopieren.
  • 27.08.2026Falschen Prototyp-Link korrigiert: zurück auf die korrekte, bereits seit Wochen verwendete und öffentlich ohne Anmeldung erreichbare Adresse leados-design-foundation.lovable.app.
  • 28.08.2026Dieter hat das zweiseitige PDF-Ausweichformular erhalten; Usability-Test findet in der kommenden Woche statt.
  • 28.08.2026M1-004d-Prompt (Codex, Testautomatisierung) um Randbedingung zum Schutz der Lovable-Direct-Push-Synchronisation ergänzt (keine data-testid-Attribute, keine Änderung an Lovable-verwalteten Komponenten).
  • 28.08.2026Sendefertiger Codex-Auftrag für M1-004d fertiggestellt und übergeben; ein zuvor verfrühter Statuseintrag hierzu wurde korrigiert.
  • 28.08.2026Ergänzender Lovable-Auftrag zu den Muss-Check-Gates (Schritt 1–3) fertiggestellt und im PR hinterlegt (LOVABLE_M1-004D_MUSS-CHECKS.md).
  • 28.08.2026Rückmeldung von Codex zu M1-004d eingegangen; der Lovable-Auftrag ist jetzt offen.
  • 28.08.2026Tagesbericht für den 28.08. erstellt und veröffentlicht (siehe Dokumente oben).
  • 29.08.2026Lovable-Rückmeldung zu den Muss-Check-Gates erhalten und geprüft: alle drei Gates (Schritt 1–3) gesetzt und verifiziert, Demodurchlauf, Labels und Zugänglichkeit bestätigt.
  • 29.08.2026Codex-Rückmeldung erhalten: Pull Request mit Testsuite (2 Tests) erstellt, lokaler Build erfolgreich. Grüner PR-Lauf steht noch aus – Ursache identifiziert (Trigger-Bootstrapping + vorbestehender roter main-Lauf), Lösungsweg festgelegt. Vor dem Merge wird geprüft, ob sich Codex' und Lovables Änderungen an den Gate-Dateien überschneiden.
  • 29.08.2026Merge-Konflikt in den drei Gate-Dateien bestätigt (Codex hatte die Gate-Logik redundant selbst implementiert) und zugunsten von Lovables verifizierter Version aufgelöst; Pull Request gemergt.
  • 29.08.2026Zweiter Pull Request von Codex stabilisiert die Tests gegen asynchrone Client-Hydratisierung. CI (Linux, maßgeblich) grün in 1:22 min; lokal Build und Testsuite (2/2) ebenfalls grün. M1-004d damit vollständig abgeschlossen, noch vor Beginn des Usability-Tests.
  • 29.08.2026TDF-PR #1 als bereits erledigt erkannt (0 offene PRs); PRs #4–#8 geprüft und als Arbeiten anderer, TDF-mitnutzender Projekte eingeordnet – kein LeadOS-Handlungsbedarf.
  • 29.08.2026Recherchiert: GitHub Free erzwingt keine Branch-Protection auf privaten Repos; GitHub Team hebt diese Einschränkung auf (~$4/Nutzer/Monat).
  • 29.08.2026Neue, projektneutrale Organisation bmarnau-standards angelegt (GitHub Team), um TDF/ADF von der LeadOS-spezifischen Organisation zu trennen.
  • 29.08.2026TDF und ADF nach bmarnau-standards transferiert (beide weiterhin privat).
  • 29.08.2026Branch-Protection auf main in beiden Repos eingerichtet und einzeln verifiziert: Pull-Request-Pflicht (0 Approvals) und signierte Commits aktiv; Require-status-checks mangels vorhandener CI-Läufe zurückgestellt.
  • 29.08.2026M1-008 (Claude GitHub App für leados-design-foundation) geprüft: bereits seit 26.08. vollständig eingerichtet und funktional bestätigt (8 Workflow-Läufe, mind. 2 erfolgreiche @claude-Antworten) – keine weitere Handlung nötig.
  • 29.08.2026Tagesbericht 29.08.2026 erstellt und veröffentlicht (siehe Dokumente oben); Tag damit abgeschlossen.
  • 31.08.2026Vier offene „ohne Dieter“-Punkte aus dem 29.08. identifiziert und mit Bernd priorisiert.
  • 31.08.2026Schritt-für-Schritt-Anleitung zur lokalen SSH-Commit-Signierung (Schlüsselerzeugung, Git-Konfiguration, GitHub-Hinterlegung, Verifizierung) an Bernd übergeben.
  • 31.08.2026Mit Bernds Freigabe: Claude GitHub App organisationsweit in bmarnau-standards installiert (Scope: alle Repositories, analog LeadOS-Org).
  • 31.08.2026Fehlannahme korrigiert: Workflow-Datei und Zugangsdaten waren in TDF und ADF bereits aus EXT-001 vorhanden und hatten den Organisationsumzug überstanden.
  • 31.08.2026Funktionstest per @claude-Kommentar auf Issue #9 (TDF) erfolgreich: Lesezugriff und korrekter Default-Branch bestätigt, keine ungewollten Änderungen.
  • 31.08.2026Auf Nachfrage nach weiteren Punkten: alle drei Code-Repos systematisch auf offene PRs/Issues geprüft (nicht nur die bekannte Liste).
  • 31.08.2026Verwaiste PR #6 in leados-design-foundation gefunden (grüne Checks, nie gemergt trotz als abgeschlossen dokumentiertem M1-004d); mit Freigabe gemergt (main bei e8500b8), Branch gelöscht.
  • 31.08.2026Erledigtes Issue #2 (M1-001) geschlossen; TDF und ADF gegengeprüft: beide 0 offene Pull Requests.
  • 08.09.2026Usability-Test mit Jan durchgeführt: 5 Befunde protokolliert (SystemCheck Teil 2, 3-Felder-Struktur Schritt 3, Rollenkennzeichnung, Muss-Check-Abbruchlogik, finaler Erläuterungstext).
  • 08.09.2026D-006 (Abbruchkriterium Pilotbetrieb), Glossar „SystemCheck“ und M1-007 (Pilotentscheidungs-Ablauf) mit Dieter vollständig geklärt.
  • 08.09.2026Öffentliches Repository leados-reports angelegt: Berichte künftig als einzelne, versionierte JSON-Dateien statt als wachsender Seitentext; Datenmodell, Schema und zwei Beispielberichte erstellt und live verifiziert (HTTP 200 über raw.githubusercontent.com).
  • 09.09.2026Diese Übersichtsseite von der claude.ai-Artifact-Ansicht auf eine eigenständige, statische GitHub-Pages-Seite (leados-org.github.io/leados-arbeitsstand) umgestellt und um die laufend aktualisierte Berichtsauswahl ergänzt.
  • 11.09.2026Abgleich der SystemCheck-Formulierung mit der aktuellen Institutswebsite ergab eine Abweichung von der bisherigen Projektfassung; Klärungsfragen dazu an Dieter formuliert.
  • 13.09.2026Alle vier Usability-Test-Befunde in Lovable umgesetzt und getestet (SystemCheck Teil 2, drei MA-Felder in Schritt 3, Rollenkennzeichnung FK/MA, finaler Muss-Check-Text); vollständiger Durchlauf Schritt 1–5 fehlerfrei.
  • 13.09.2026SystemCheck-Feldlabels an die Website-Formulierung angepasst, ohne auf Dieters Bestätigung zu warten (siehe Sprintentscheidung).
  • 13.09.2026Git-Hygiene-Check durchgeführt: keine offenen Pull Requests oder Issues in leados-design-foundation; Commit-Signierung in TDF/ADF nach Schlüsselrotation erfolgreich verifiziert (Branch-Protection verhindert wie vorgesehen Direct-Push auf main).
  • 13.09.2026RBAC-Konzept v0.1 für die Post-Pilot-Phase erarbeitet (einheitliches 3-Rollen-Modell Admin/Führungskraft/Mitarbeiter, Multi-Tenancy, Supabase-Auth-Details, DSGVO-Anforderungen) — mehrere Punkte an Dieter delegiert.
  • 13.09.2026Sechs-Sprint-Umsetzungsplan erarbeitet, der vollständige Datenpersistenz (Fünf-Schritte-Ablauf) und das RBAC-Konzept in eine verzahnte Reihenfolge bringt.
  • 15.09.2026Terminologie auf „Unternehmer“ vereinheitlicht (ersetzt „Führungskraft“/„Inhaber“); d009 revidiert (KI-generierte Vorschläge im SystemCheck jetzt erlaubt, einfacher zustandsloser LLM-Aufruf); Muss-Check-Verhalten überarbeitet (Hinweis statt Reset, ersetzt Befund 4 aus M1-006); D-009-Kurzbezeichnungen an aktuellen UI-Wortlaut angeglichen; fünf weitere UI-Änderungswünsche konzipiert; alle zehn resultierenden Aufträge für Claude Code und Lovable konsolidiert und versioniert.
  • 17.09.2026Vier Lovable-Feldergänzungen (L-2, L-3, L-4) und KI-Vorschlagsbutton (L-1) umgesetzt und getestet; alle vier Claude-Code-Aufträge (CC-1–CC-4) abgeschlossen. Abschlussprüfung durchgeführt: main kurzzeitig CI-rot (3 Prettier-Fehler), behoben, danach vollständig grün; L-1-Architektur empirisch verifiziert (API-Key serverseitig, vierfache Fallback-Absicherung, kein Autofill). Sechs verwaiste Branches gelöscht, BACKLOG.md M1-006-Eintrag korrigiert. Offen: L-7 (Inhalt), M1-007 (Pilotentscheidung), Rollenmodell-Frage (RBAC-relevant) – warten auf nächsten Dieter-Termin.
  • 17.09.2026Architekturkonzept Track C signiert committet (docs/2026-09-17_Architekturkonzept_Track-C.md, leados-design-foundation) – Entwurf für Mehrmandantenfähigkeit, erweitertes Rollenmodell, Anmeldung, wartet auf Dieters Antworten zu acht offenen Punkten.
  • 17.09.2026Planungssession: MVP-Ziel festgelegt (eine Firma, zwei Rollen – Unternehmer, Mitarbeiter), Servicebereich (Begrüßung, Kontopflege, Stammdatenpflege, Backup, Servicestatus, PDF-Export, Hilfe/Handbuch/Entwicklungstagebuch) als Teil des MVP bestätigt, neues Datenmodell-Feld für den Servicestatus-Zugriff, Sprint-Abnahmeprinzip mit Dieter-Testgates nach jedem Sprint, Sprintlänge 2 Wochen. Architekturkonzept entsprechend aktualisiert, vollständiger Backlog mit Vier-Sprint-Sequenz (Epics A-E) in docs/2026-09-17_Backlog_Sprintplan_MVP.md neu angelegt (beides leados-design-foundation, signierte Commits).
  • 17.09.2026Statusgrafik auf dieser Seite umgesetzt: Meilenstein-Leiste durch farbige Status-Karten plus Fortschritts-Punktleiste ersetzt, liest weiterhin dieselben Meilenstein-Daten, keine neue Abhängigkeit.
  • 17.09.2026Rollenmodell-Arbeitshypothese aus Dieters Rückmeldung ins Architekturkonzept übernommen (Unternehmer wird operative Spitze, Inhaber wird Attribut ist_inhaber/anteil_prozent statt eigener Rolle), RBAC-Matrix und Datenmodell entsprechend angepasst. Auftragssammlung vollständig auf den aktuellen Stand gebracht. Fehlende Rollenmodell-Grafik entdeckt, tote Bildreferenz zunächst entfernt, dann durch eine neu erstellte, korrekte SVG-Grafik ersetzt. Vier Detailfragen zur Arbeitshypothese noch offen.
  • 18.09.2026Gespräch mit Dieter: Rollenmodell-Rückmeldung erhalten (Bestätigung steht aus), Ziel-Aufgabe-Struktur (ein Ziel kann mehrere Aufgaben haben) geklärt, Z-AVKK-Liste vollständig spezifiziert, Sprint 1.5 neu eingeplant.
  • 21.09.2026Sprint 1.5 (Epic G) vollständig abgeschlossen: G1–G7, G10 umgesetzt und verifiziert (Zwei-Ebenen-Struktur, Button „weitere Aufgabe“, Z-AVKK-Liste mit allen zwölf Feldern, KI-Prüfung als Arbeitsversion, Kapazitätsrechnung, Erledigt-Kennzeichen, Bestätigt-FK/MA), dazu Layout- und Farbverfeinerungen. Live-Verifikation auf leados-design-foundation.lovable.app bestätigt: Terminologie „Unternehmer“, G2-Button und Z-AVKK-Liste funktionieren vollständig. Neuer Diskussionspunkt für Dieter: Navigation zwischen Z-AVKK-Liste und Fünf-Schritte-Ablauf fehlt noch (bewusst zurückgestellt), Vorschläge liegen vor. Im Anschluss AQGS-Hygiene-Diagnose durchgeführt: CI-Rot behoben, Branch-Schutz eingerichtet, E2E-Tests für G3/G5 ergänzt, Standards-Familie (D-011/ADR-0006) dokumentiert. Keine offenen technischen Blocker.
  • 21.09.2026Live-Testsitzung mit Dieter deckte einen echten Logikfehler auf: der Ablauf sprang fälschlich nach Schritt 2 direkt zur Z-AVKK-Liste, Schritt 3–5 wurden komplett übersprungen. Korrigiert (G11): Ablauf ist wieder linear (1→2→[3+4 je Aufgabe wiederholt]→5→Liste), aktiver Schritt jetzt farblich hervorgehoben. Weitere gefundene und behobene Fehler: doppelte Übernahme bei Browser-Zurück (G13), veralteter Aufgaben-Index bei Rücksprung (G13), fehlender Sprung zu Schritt 5 bei vollständig bearbeiteten Aufgaben (G14). Fachlich geklärt: der Mitarbeiter kann in Schritt 3 keine neuen Aufgaben vorschlagen, alle vom Unternehmer gestellten Aufgaben müssen aber durchlaufen werden (bereits durch G11 erfüllt). Zusätzlich: Zeitart ("Pro Tag"/"Pro Woche") je Aufgabe und unabhängiges Wochenlimit eingeführt (G16), danach grundlegend korrigiert (G18) — "Bis wann" hat keine Bedeutung mehr für die Kapazitätsrechnung, reiner Informationshinweis; neues Modell rein fortlaufend ohne Datumsbezug. Dauer-Parsing-Bug gefunden (Minuten werden als Stunden gelesen), Korrektur beauftragt (G17). Neuer Auftrag unterwegs: Inhalt Schritt 3/4 zurücktauschen plus Neustart-Option-Konsistenz.
  • 21.09.2026Live-Testsitzung mit Dieter abgeschlossen (G11–G21, siehe vorheriger Bericht). Neues Zwischenziel „Speicherung ohne RBAC“ definiert und als B1/B4/H1/H2 durchgeplant, Reihenfolge B2 → B1 → B4 → H1 → H2 — läuft unabhängig von Dieters noch ausstehender vollständiger Anmeldemethode-Antwort (Arbeitsannahme: E-Mail/Passwort via Supabase Auth, später austauschbar).
  • 22.09.2026Kapazitätsrechnung vollständig durch Dieters eigene Spezifikation ersetzt (G22): Rhythmus vierwertig (einmalig/pro Tag/pro Woche/pro Monat), Abnahmetest exakt bestanden. Datenbank-Anbindung: B2, B1, B4 bestätigt umgesetzt (mandant/ziel/aufgabe-Tabellen, Login/Registrierung/Passwort-vergessen über Lovables Cloud/Auth, ein Sicherheitsbefund behoben). Korrektur: entgegen ursprünglicher Annahme ist auch H1 (echte Speicherung der Z-AVKK-Liste) bereits umgesetzt (code-verifiziert) — Lovable fokussiert aktuell auf Stabilität/Sicherheit der DB-Anbindung.
  • 11.09.2026Abgleich der SystemCheck-Formulierung mit der Institutswebsite ergab eine Abweichung; Klärungsfragen an Dieter formuliert.
  • 13.09.2026Alle vier Usability-Test-Befunde umgesetzt und getestet (SystemCheck Teil 2, drei MA-Felder Schritt 3, Rollenkennzeichnung FK/MA, finaler Muss-Check-Text); vollständiger Durchlauf Schritt 1–5 fehlerfrei.
  • 13.09.2026Git-Hygiene-Check durchgeführt: keine offenen Pull Requests/Issues in leados-design-foundation; Commit-Signierung in TDF/ADF nach Schlüsselrotation erfolgreich verifiziert.
  • 13.09.2026RBAC-Konzept v0.1 für die Post-Pilot-Phase erarbeitet (3-Rollen-Modell Admin/Führungskraft/Mitarbeiter, Multi-Tenancy, Supabase-Auth, DSGVO); Sechs-Sprint-Umsetzungsplan erstellt.
  • 15.09.2026Terminologie auf „Unternehmer" vereinheitlicht; d009 revidiert (KI-Vorschläge im SystemCheck erlaubt); Muss-Check-Verhalten auf „Hinweis statt Reset" revidiert (D-010); zehn Aufträge für Claude Code/Lovable konsolidiert.
  • 17.09.2026Vier Lovable-Feldergänzungen (L-1–L-4) umgesetzt und verifiziert, alle vier Claude-Code-Aufträge (CC-1–CC-4) abgeschlossen. CI kurzzeitig rot (Prettier), noch am selben Tag behoben. Sechs verwaiste Branches gelöscht.
  • 17.09.2026Architekturkonzept „Track C" (Mehrmandantenfähigkeit, erweitertes Rollenmodell, Anmeldung) und MVP-Backlog/Sprintplan (Epics A–E) als Entwurf angelegt – ausdrücklich ohne Vorziehen des Pilotumfangs, wartet auf Dieters Antworten.
  • 18.09.2026Gespräch mit Dieter: Ziel-Aufgabe-Struktur geklärt (ein Ziel kann mehrere Aufgaben haben), Z-AVKK-Liste vollständig spezifiziert, Sprint 1.5 eingeplant.
  • 21.09.2026Sprint 1.5 (Epic G) abgeschlossen: Z-AVKK-Liste mit allen Feldern, Kapazitätsrechnung, Erledigt-/Bestätigt-Kennzeichen. AQGS-Hygiene-Diagnose: CI-Rot behoben, Branch-Schutz eingerichtet, E2E-Tests ergänzt, D-011/ADR-0006 (bmarnau-standards) dokumentiert.
  • 21.09.2026Live-Testsitzung mit Dieter: echter Logikfehler gefunden (Ablauf sprang nach Schritt 2 direkt zur Liste, Schritt 3–5 übersprungen) und behoben (G11); weitere Fixes (G13, G14). Kapazitätsrechnung grundlegend korrigiert (G16, G18), Dauer-Parsing-Bug gefunden (G17).
  • 23.–25.09.2026Test-Mandanten-Infrastruktur für automatisierte Tests aufgebaut; ein fehlerhafter Live-Anmeldung-Test sowie ein Konflikt-Test repariert; eine Fehlerseite ergänzt.
  • 26.09.2026H3: Entwürfe-Mechanismus umgesetzt – ein neues Ziel oder eine zu einem bestehenden Ziel nachgetragene Aufgabe wird ab Schritt 1 in der Datenbank angelegt (neues Feld `freigegeben`, Default false) und bei jedem Schritt aktualisiert, erscheint aber erst nach Abschluss (Bulk-Update auf `freigegeben = true`) in der Z-AVKK-Liste; höchstens ein offener Entwurf je Person; feste Navigationsleiste („Ablauf“/„Z-AVKK-Liste“) erlaubt jederzeit Wechsel und Fortsetzen an der verlassenen Stelle.
  • 26.09.2026H4: nativer Browser-`confirm()` beim Fortsetzen/Verwerfen eines unfertigen Entwurfs durch einen eigenen Dialog mit eindeutig beschrifteten Buttons ersetzt (vermeidet Verwechslung mit „OK“/„Abbrechen“). H5 (Schutz gegen gleichzeitige Bearbeitung derselben Aufnahme in zwei Tabs) bewusst zurückgestellt.
  • 26.09.2026E8–E10 (nach Prüfung gegen den echten Repo-Stand freigegeben und umgesetzt): Startseite für Angemeldete (zeitabhängige Begrüßung, Fortsetzen-/Neu-Knopf, Kacheln, Systemstatus-Kachel nur für Plattform-Admins); Repo-Statuszeile mit echtem GitHub-Sync-Abgleich (Lesezugriff auf main, „Sync nicht prüfbar“ statt erfundenem Status); Zombie-Aufräumen im Systemstatus (unfertige Entwürfe >24h oder Aufgabe ohne gültiges Ziel, serverseitig geprüft, freigegebene Einträge werden nie angefasst).
  • 26.09.2026CI-Pipeline „CI Build & Lint“ war an jedem Lauf des Tages rot (zunächst 468 automatisch behebbare ESLint/Prettier-Fehler, danach 26 verbleibende, danach generierte Supabase-Integrationsdateien im Linting): schrittweise behoben, letzter Lauf (Commit 8d9233d) grün. Dabei aufgefallen: Die vollständigen E2E-Tests liefen dort nie wirklich mit; als Gegenmaßnahme laufen auf GitHub jetzt drei schnelle Basisprüfungen ohne Datenbankzugriff, die vollständigen Tests weiterhin lokal bei Lovable.
  • 26.09.2026Befund beim Nachpflegen dieser Seite: Eine frühere Session hatte den Stand vom 26.09. bereits `nachgetragen`, dabei aber nur die statische Vorab-Darstellung (das HTML-Fallback-Markup) geändert, nicht STATE selbst – dasselbe Muster wie am 21.09. schon einmal aufgetreten und dort behoben. Da `mount(STATE)` beim Laden das Markup bedingungslos überschreibt, war die Aktualisierung für Besucher unsichtbar. Diesmal STATE direkt aktualisiert und das Markup aus STATE neu erzeugt (nicht von Hand geschrieben), um diesen Fehler künftig auszuschließen.
  • 28.09.2026CI-Testdatenbank: Umstellung von einer geteilten Supabase-Testinstanz auf eine ephemere lokale Instanz je CI-Lauf. Acht Anläufe, Endstand 59f54f3: 21/21 E2E grün. Neues Spec-File 00-beispieldaten-erstaufruf.spec.ts (4720b67) prüft H1 gegen einen garantiert leeren Mandanten. AQGS PR #24 (G5: Migrations-Replay-Nachweis gegen isolierte Instanz bei verwalteten Plattformen) gemergt.
  • 28.09.2026Migrationshistorie vervollständigt: Lovable ergänzte 00000_baseline_profiles.sql (auf der Produktivdatenbank per Journal-Zeitstempel übersprungen) und 0008_einstellungen.sql (idempotent, nur aktuelle Admin-Regel), Commit 69814b1, drizzle-kit check ohne Fehler. CI (PR #20, 0e27322): CI-Hilfsdatei entfernt; Migrationen werden mit drizzle-kit migrate statt supabase migration up angewendet, weil die Supabase-CLI Versionen als Text sortiert (0000 vor 00000). D-012 auf GitHub umgesetzt: Pull-Request-Pflicht für leados-design-foundation und AQGS, Signaturpflicht für leados-reports und leados-arbeitsstand.
  • 03.10.2026Dokumentation, keine Umsetzung: Ideenspeicher docs/IDEEN.md (IDEE-001 Merker-Methodik, IDEE-002 Vertretung bei Abwesenheit) und PROJECT-STATUS.md auf Stand 03.10. in leados-design-foundation per PR #27 (Merge durch Bernd); Umsetzungsplan Persistenz/RBAC um Abschnitt „Nachgelagerte Ideen“ ergänzt, Sprints unverändert. Befund: letzter CI-Lauf auf main (9547900) rot wegen der Einrichtung der CI-Werkzeuge, nicht codebedingt.
  • 06.10.2026Hilfeseite /hilfe (P-012) durch Lovable umgesetzt (923a057), Folgekorrekturen bis 07.10. (449b1de). Paketänderungen durch Lovable (TanStack Router/Start, vite-tanstack-config 2.25.2, seroval 1.6.8), im Repo-CHANGELOG nachgetragen.
  • 07.10.2026Claude-Code-Lesebericht zum Projektstand (main = 449b1de, CI grün) als Grundlage für das Dieter-Treffen.
  • 08.10.2026Lovable-Läufe B4 (Überschriftenebenen in PanelCard, Fokusring der Muss-Checks, docs/QUALITAET-BEFUNDE.md) und B5 (Hilfe-Textkorrekturen), main = a8307df, CI grün. Diff-Check durch Claude Code: B4 gelb (nicht gemeldete Paketänderung vite-tanstack-config 2.25.3, neuer Überschriftensprung h2 → h4), B5 grün. Nachbesserung per PR #28 (h3 in Schritt 2, Kontrast Petrol-Badge 6,68:1, CHANGELOG und PROJECT-STATUS nachgezogen), Squash-Merge durch Bernd als acb8858, „CI Build & Lint“ grün. Bestandsaufnahme B6/B7 (Passwort-Reset, Profilseite) rein lesend.
  • 09.10.2026Lovable-Läufe B6 (Passwort zurücksetzen, fbcb470) und P0 (Mindestlänge 8, Hinweis bei gleichem Passwort, Profilseite zum Lesen, 73a14b3), CI grün. Diff-Checks durch Claude Code: B6 gelb, P0 grün; beide abgenommen. Datenbankänderung B7a (Vorname und Nachname im Profil) per PR #31 übernommen (0b25997); Datenbankteil S1a (Rollen und Einladungstabelle) per PR #32 übernommen (7b5701e); main = 7b5701e, CI grün.
  • 09./10.10.2026Lovable-Läufe B7b (Profil bearbeiten, e4f38ff), B8 (Hilfe-Link im selben Tab, 5bb2a5b) und B7c (Meldung bei falschem aktuellem Passwort, 90edf11), jeweils CI grün; Diff-Check B7b/B8 durch Claude Code: gelb, kein roter Befund. Git-Hygiene über alle LeadOS-Repositories: Bericht erstellt, neun übernommene Arbeitszweige nach Freigabe gelöscht; CHANGELOG und Projektstatus per PR #34 nachgezogen.
  • 10.10.2026Lovable-Läufe B7d (ca0e99e), B9 (1d8ad0d), Datenbank-Kennzahlen mit Migration 0011 (2f320d5) und B9c (51b21b6). Diff-Checks durch Claude Code: B7c/B7d/B9 gelb ohne roten Befund; ab 2f320d5 rot wegen der automatischen Prüfung. Nacharbeiten per Pull Request #35 bis #39 (Formatierung, Snapshot 0011, Größenanzeige, Repository der Karte, Korrektur von Migration 0010), alle von Bernd übernommen, automatische Prüfung grün. GitHub: automatisches Löschen gemergter Branches, nur Squash-Merge; neue Arbeitskopien außerhalb von OneDrive.
  • 11.10.2026Datenbankteil S1a (Migration 0010) in der Produktion angewendet, Kontrollabfrage vorher und nachher. D-023: Migrationen nur per Pull Request. Öffentliche Berichte und Projektseite bereinigt (E-27).
  • 12.10.2026Härtung Stufe 1 (Migration 0013, D-027), angewendet und geprüft. Datenbank-Tests nur gegen eine lokale Instanz (D-028). Schema-Inventur der Produktion gegen die Migrationen ohne Abweichung. Wächter für geschützte Pfade und Konvention zur Dateiübergabe.
  • 13.10.2026Sprintplan, DECISIONS.md und Risikoregister im Repository (PR #57 bis #60). Migration 0014: Aufbewahrung der Fehlermeldungen 30 Tage (D-036), angewendet; Test gegen liegengebliebene Plattform-Kopien von Migrationen.
  • 14.10.2026Einstellungen der drei Repositories vereinheitlicht, Merge nur per Squash (D-037). Sitzung 2 mit Dieter: D-031 und D-035 bestätigt, D-038 (Sichtbarkeit und Schreibrecht in der Firma) festgelegt.
  • 15.10.2026Ergebnisse der Sitzung im Repository (PR #67). Plan v0.4 als Arbeitsgrundlage (PR #68, D-039). Lovable-Lauf S1b-1 (Regeln und Verwaltung der Einladungen), automatische Prüfung grün, 180 Unit-Tests; Diff-Check durch Claude Code gelb, abgenommen (PR #69, D-040). Analyse A2 (Ladefehler Anmeldeseite, englische 404-Seite) ohne feste Ursache im Code; Behebung mit einem Lauf vorbereitet.
  • 16.10.2026Lovable-Lauf LP-1.2 (A2: Ladefehler Anmeldeseite, Sprache der Seite, deutsche 404-Seite) vom 15.10. abgenommen mit Auflagen (PR #72, D-042), automatische Prüfung grün, 196 Unit-Tests; Auflagen 2 und 3 behoben (PR #71), Zeitangabe der manuellen Prüfung berichtigt (PR #73). Programmplan Pilot-MVP auf der Projektseite.
  • 16.10.2026Lovable-Lauf LP-1.3 (S1b-2: Versand und Annahme der Einladungen), automatische Prüfung grün, 210 Unit-Tests; mit einer Testeinladung geprüft und abgenommen (PR #80, D-045, D-046). Testumgebung für den Mailversand und Entscheidungen D-043/D-044 vorbereitet (PR #74, #75).
  • 18.10.2026Kontoverwaltung für Einladungen umgesetzt und teilweise geprüft. Einladungs-E-Mails werden wegen einer Störung beim Mail-Dienst der Plattform derzeit nicht zugestellt; der Anbieter hat den Fall bestätigt und bearbeitet ihn. Prüfregeln für die Zustellung ergänzt.
Bisheriger Gesamtaufwand (grobe Schätzung, keine gemessene Zeiterfassung): deutlich über 48 Stunden seit Projektstart am 20.08.2026 (letzte belastbare Teilschätzung: rund 48 Std. bis 09.09.; seither mehrere weitere Arbeitstage mit Persistenz-, Live-Abgleich-, Entwürfe- und Git-Hygiene-Arbeiten – keine neue Gesamtsumme gebildet, um keine ungenaue Zahl vorzutäuschen) seit Projektstart am 20.08.2026.