rezuki-flow: Umsetzungsplan
Stand: 13.09.2026, Entwurf von Robert für Nils Grundlage: Lastenheft „Kalender-, Buchungs- und Abrechnungsplattform“ v1.0 (02.09.2026), Prozessbeschreibung der drei Kernprozesse (01.09.2026), Gespräch Nils/Robert vom 31.08.2026 Arbeitsstand dieser Datei: Vorschlag. Alles, was Nils ändern will, direkt hier ändern oder in FEEDBACK.md notieren.
1. Was rezuki-flow ist
rezuki-flow ist der AI Managed Service, der den Beratungskreislauf von ReZuKi trägt: Partnerinnen stellen freie Stunden ein, Mitarbeitende der Kundenunternehmen buchen daraus mit einem Einmalcode, jede durchgeführte Stunde verbraucht den Code und wird zur Abrechnungsgrundlage.
Es ist eine eigenständige Webanwendung mit eigener Datenbank, die neben der Tanagra-Box von ReZuKi läuft. Kein externer Nutzer bekommt Zugang zur Agentenplattform, auch nicht mittelbar. Die Agenten der Box (Kodeki, Bonnie, webki) arbeiten mit rezuki-flow nur über zwei schmale Wege: sie pflegen die öffentlichen Seiten im Workspace, und sie lesen über eine begrenzte Schnittstelle pseudonymisierte Termindaten für den Rechnungsabgleich und die Kontingentmeldungen.
In der Systematik unserer Managed Services ist das Bauart C: statische Seiten plus eigener API-Stack mit eigener Datenbank, wie service-job oder die Szenario-Werkstatt-Portale von MFS.
Nicht im Auftrag (aus dem Lastenheft, unverändert)
Keine Kalender-Synchronisation (stattdessen ICS-Kopie), kein Praxisverwaltungssystem, keine eigene Videotechnik, keine Zahlungsabwicklung, kein KI-Matching, keine Freitextangaben zum Beratungsanlass.
2. Das Vertraulichkeitsmodell als Architekturvorgabe
| Rolle | kennt | kennt nicht |
|---|---|---|
| Kundenunternehmen / HR | Code und Person | ob und bei wem ein Code eingelöst wurde |
| ReZuKi | Code und Partnerin | welche Person hinter einem Code steht |
| Partnerin | Code und Person | die einzige Stelle, an der beides zusammenkommt |
Daraus folgt für den Bau:
- Die Zuordnung „wer wurde von wem beraten“ liegt nur in der Tabelle
buchungdieser Anwendung. Sie wird nie ins CRM, in den Vault, in eine Wissensdatenbank oder eine Tabelle exportiert. - Die Verwaltungssicht von ReZuKi zeigt Buchungen nur als Vorgangscode plus Partnerin plus Zeit. Kein Name, keine E-Mail der buchenden Person.
- Die buchende Person hinterlässt keinen Klarnamen im System. Sie identifiziert sich über kundenweites Passwort plus Einmalcode plus selbst gewählte PIN (Vorschlag zu Entscheidung 04). Eine E-Mail-Adresse ist optional und dient nur der Terminerinnerung; sie wird nach dem Termin gelöscht.
- Auswertungen an Arbeitgeber laufen über eine einzige Abfrage, die Gruppen unter fünf Personen in der Datenbank unterdrückt, nicht erst in der Anzeige.
- Protokolle enthalten Vorgangskennungen, nie Namen oder Anlässe.
- Die Anwendung läuft auf der Infrastruktur für personengebundene Coaching-Daten (Zwei-Server-Beschluss im ReZuKi-Vault). Siehe Entscheidung 07.
3. Architektur
Internet
│ https://rezuki-flow.tanagra.cloud (später eigene Domain, z. B. flow.rezuki.de)
▼
Dalia (Reverse Proxy, TLS) ──VPN──► Server für Coaching-Daten
├─ rezuki-flow-api (Node/Express, Port 4000)
│ ├─ / statische Seiten (Partner, Nutzer, Verwaltung)
│ ├─ /api/partner/* Partnerkonto, Profil, Verfügbarkeiten, Termine
│ ├─ /api/buchung/* Kundenpasswort, Filter, Buchung, Code, PIN, ICS
│ ├─ /api/admin/* Verwaltung ReZuKi
│ └─ /api/intern/* lesend, Token, pseudonymisiert (für N8, N12)
└─ rezuki-flow-postgres (eigene Datenbank, nur intern)
Tanagra-Box rezuki (Nala) ── liest /api/intern/* mit Token ──► Kontingentmeldung, Rechnungsabgleich
Workspace _ReZuKi/rezuki-flow/website ── Agenten pflegen Texte, Startseite, Hilfe ──► sofort liveBausteine
| Baustein | Vorschlag |
|---|---|
| Code | Repository robertv42/rezuki-flow-api, Klon auf Dalia /opt/apps/rezuki-flow-api/, Image 10.0.0.1:5000/rezuki-flow-api |
| Laufzeit | Node 22, Express, PostgreSQL 16, Sitzungen per signiertem Cookie, Passwörter mit Argon2 |
| Stack | docker-compose.rezuki-flow.yml mit rezuki-flow-api und rezuki-flow-postgres, .env mit Geheimnissen (chmod 600) |
| Frontend | Statische Seiten ohne Framework, im Workspace _ReZuKi/rezuki-flow/website/ (agentenpflegbar), im Container als /app/public eingehängt. Repo-Stand ist nur der Seed |
Brevo über eine ReZuKi-Absenderadresse (Vorschlag termine@rezuki.de), Vorlagen ohne Anlass und ohne Namen | |
| ICS | Stabile UID je Buchung, SEQUENCE bei Änderung, METHOD:CANCEL bei Absage, SUMMARY „ReZuKi-Beratung · Vorgang <Code>“ |
| Video | V1 zum Start: Linkfeld je Buchung, manuell oder automatisch befüllbar. V2 OpenTalk-Kopplung hinter einer schmalen internen Schnittstelle, austauschbar |
| Backup | Nächtlich nach Leela (Datenbank-Dump plus Uploads), Wiederherstellung einmal geprobt und dokumentiert |
| Protokoll | Zugriffe und Änderungen mit Vorgangskennung, Rolle, Zeit. Keine Inhalte |
| Löschung | Aufbewahrung je Objekt in einer Tabelle konfiguriert, nächtlicher Lauf löscht abgelaufene Datensätze, Export als CSV/JSON |
Warum eigener Stack und nicht ein Werkzeug in der Box: Die Box ist die Organisationsplattform von ReZuKi mit Vault-Spiegel, CRM und Agentenakten. Buchungsdaten dort abzulegen würde Vorgabe B1 verletzen. Ein eigener Stack ist zudem einfacher zu sichern, zu löschen und zu prüfen.
4. Datenmodell (erster Schnitt)
Aus Abschnitt 11 des Lastenhefts, ergänzt um die Felder, die die Vorgaben erzwingen.
| Tabelle | Wesentliche Felder | Regel |
|---|---|---|
partner | id, email, passwort_hash, name, foto, kurzprofil, qualifikation, honorarsatz_cent, status (angelegt, freigeschaltet, deaktiviert) | Freischaltung nur durch ReZuKi |
leistung | id, art (sprache, schwerpunkt, format), bezeichnung, aktiv | von ReZuKi pflegbar, ohne Code |
partner_leistung | partner_id, leistung_id | trägt die Filterung |
verfuegbarkeit | id, partner_id, beginn, ende, status (frei, gebucht, zurueckgezogen) | konkrete Stunden, Normalzustand nicht buchbar |
kunde | id, organisation, ansprechperson, segment, passwort_hash, aktiv | keine Endnutzerdaten |
kontingent | id, kunde_id, stunden, satzart (standard, fuehrung), gueltig_von, gueltig_bis | Grundlage der 70/90-Prozent-Meldung |
code | id, kontingent_id, code, status (offen, eingeloest, zurueckgebucht), eingeloest_am, pin_hash | ein Code ist eine Stunde, PIN bei erster Einlösung |
buchung | id, code_id, partner_id, verfuegbarkeit_id, status (gebucht, durchgefuehrt, abgesagt_partner, abgesagt_nutzer), meeting_link, ics_uid, ics_sequence, erinnerungs_email (nullable, wird nach Termin gelöscht), bestaetigt_partner_am, bestaetigt_nutzer_am | die einzige Stelle mit der Zuordnung; eindeutiger Index auf verfuegbarkeit_id schließt Doppelbuchung aus |
rechnungslauf | id, zeitraum_von, zeitraum_bis, art (kunde, partner), kunde_id oder partner_id, positionen (json), status (entwurf, freigegeben, versandt) | Entwurf, Freigabe, Versand getrennt |
protokoll | id, zeit, rolle, konto_id, aktion, vorgang | ohne Inhalte |
aufbewahrung | tabelle, frist_tage | steuert die Löschläufe |
5. Phasenplan und Termine
Die Termine aus dem Lastenheft sind gesetzt: 15.11.2026 Statusprüfung, 05.12.2026 Partnerseite produktiv, Januar 2027 Marktstart. Rückwärts geplant:
| Phase | Zeitraum | Inhalt | Meilenstein |
|---|---|---|---|
| 0 Entscheiden | 13.09. bis 20.09. | Prototyp durchsehen, Entscheidungen 01 bis 09 treffen, Repo und Stack anlegen, Testfenster rezuki-flow.tanagra.cloud (steht seit 13.09.) | 20.09.: Entscheidungen liegen vor, Bau beginnt |
| 1 Partnerseite bauen | 21.09. bis 18.10. | P1 Login und Passwort-Zurücksetzung, P2 Profil, P3 Leistungen, P4 Verfügbarkeiten, P5 Terminübersicht, P6 Absage, P7 Honorarsatz, P8 Verwaltungssicht. Datenbank, Protokoll, Mailversand | 18.10.: Partnerseite auf der Testumgebung durchklickbar |
| 2 Prüfen und härten | 19.10. bis 14.11. | Testlauf mit Katrin und zwei Partnerinnen, Backup und Wiederherstellung, Löschläufe, Protokollprüfung, Wiederkehrender Anstoß zur Pflege (Ü3), Vorlauffrist (Ü2) | 15.11.: Statusprüfung. P1 bis P5 testbar, sonst Umstieg auf eingekauftes Werkzeug |
| 3 Partnerseite produktiv | 15.11. bis 04.12. | Domain scharf, Zugänge für Kohorte 1 (5 bis 8 Partnerinnen), Anleitung für Partnerinnen, Bereitschaft für Störungen | 05.12.: Partnerseite produktiv am Tag des Onboarding-Abschlusses |
| 4 Nutzerseite | 01.12. bis 15.01.2027 | N1 Anmeldung mit Kundenpasswort, N2 gefilterte Auswahl, N3 Buchung mit Code, N4 Bestätigungen mit ICS, N5 Wiederabruf mit PIN, N6 Absage, N7 Durchführungsbestätigung, V1 Videolink | Januar 2027: Marktstart |
| 5 Abrechnung | 15.01. bis 28.02.2027 | N8 Kontingentprüfung wöchentlich, N9 Dashboard, N10 Kundenrechnung als Entwurf, N11 Rechnungsvorlage Partnerin, N12 Abgleich über /api/intern. Darf zum Start manuell laufen | 28.02.: erster automatischer Monatsabschluss |
| 6 Ausbau | ab März 2027 | V2 bis V4 OpenTalk-Kopplung, Rechnungswerkzeug-Anbindung, weitere Kohorten | offen |
Phase 4 überlappt Phase 3 bewusst: die Nutzerseite hängt am gleichen Datenbestand und wird im Dezember begonnen, sobald die Partnerseite stabil ist.
Grobe Aufwandsschätzung
Mit Claude Code als Bauhelfer, Robert als Umsetzender, Nils als Fachseite. Zahlen sind Arbeitstage, nicht Kalendertage, und Schätzung, keine Zusage.
| Phase | Arbeitstage |
|---|---|
| 1 Partnerseite | 8 bis 10 |
| 2 Prüfen und härten | 4 bis 5 |
| 3 Produktivstellung | 2 |
| 4 Nutzerseite | 8 bis 10 |
| 5 Abrechnung | 5 bis 7 |
| 6 OpenTalk-Kopplung (V2) | 4 bis 6 |
6. Offene Entscheidungen
Die Nummern 01 bis 06 stammen aus Abschnitt 10 des Lastenhefts, 07 bis 09 sind aus unserer Seite dazugekommen. Zu jeder steht ein Vorschlag. Nils markiert: übernehmen, ändern, vertagen.
| Nr. | Frage | Vorschlag | Entscheidet |
|---|---|---|---|
| 01 | Technologiewahl und Architektur | Abschnitt 3 dieses Plans | Robert, Nils bestätigt |
| 02 | Zuständigkeit laufender Betrieb ab Januar 2027 | Tanagra betreibt (Updates, Sicherung, Störungsannahme werktags), Passwort-Zurücksetzung läuft automatisch, Freischaltungen macht ReZuKi selbst in der Verwaltungssicht. Vertrag: Nutzungsbedingungen Tanagra-Box plus Auftrag, wie bei den anderen Managed Services | Nils und Robert |
| 03 | Rechnungswerkzeug (GoBD, mit Schnittstelle) | Kandidaten lexoffice, sevDesk, easybill. Alle drei GoBD-zertifiziert, alle mit REST-Schnittstelle. Empfehlung nach kurzer Prüfung bis 20.09.; zum Marktstart genügt der Rechnungsentwurf als PDF aus rezuki-flow, die Übergabe ans Werkzeug kommt in Phase 6 | Nils, Empfehlung Robert |
| 04 | Absicherung des Wiederabrufs (N5) | PIN einführen. Bei der ersten Einlösung setzt die buchende Person eine vier- bis sechsstellige PIN; Wiederabruf und Absage verlangen Code plus PIN. Aufwand gering, schließt die Lücke im Vertraulichkeitsmodell | Nils |
| 05 | Videokanal und Kopplungstiefe | V1 (Linkfeld) zum Marktstart, verpflichtend. OpenTalk-Kopplung (V2) parallel prüfen: selbst betrieben auf demselben Server (Betrieb, Updates, TURN-Server, Aufwand geschätzt 4 bis 6 Tage Aufbau plus laufende Pflege) gegen betreute Variante (ab 7,50 Euro je Monat und Nutzer, keine Verbindungsdaten bei Dritten außerhalb des Auftragsverarbeiters). Empfehlung: betreute Variante mit AVV, Kopplung in Phase 6 | Nils |
| 06 | Zuschnitt der maschinellen Prüfung (N12) | Lesender Endpunkt /api/intern/termine?von=&bis=&partner= mit eigenem Token, liefert nur Vorgangscode, Partnerin, Datum, Dauer, Satzart. Keine Personen, keine Anlässe. Kodeki auf der Box gleicht damit eingegangene Rechnungen ab und legt das Ergebnis einem Menschen vor | Nils, Robert |
| 07 | Standort des Stacks | Zwei-Server-Beschluss im Vault: Buchungsdaten gehören auf den Server für Coaching-Daten. Option A: eigener Stack auf Nala neben der Box (schnell, gleiche Maschine wie Organisationsdaten). Option B: eigener Stack auf einem freien Server der Flotte, der als Server 1 für Coaching-Daten gilt. Empfehlung B, weil der Vault-Beschluss sonst nur auf dem Papier steht | Nils, Robert |
| 08 | Domain und Absender | Test: rezuki-flow.tanagra.cloud (steht). Produktiv: Vorschlag flow.rezuki.de für alle drei Rollen oder getrennt partner.rezuki.de und buchen.rezuki.de. Mailabsender termine@rezuki.de über Brevo | Nils |
| 09 | Erinnerungsmail an die buchende Person | Optional, freiwillige E-Mail nur für Erinnerung, nach dem Termin gelöscht. Oder ganz verzichten und nur den Portal-Wiederabruf anbieten | Nils, Katrin |
7. Risiken und Gegenmittel
| Risiko | Gegenmittel |
|---|---|
| 15.11. nicht gehalten | Partnerseite zuerst und ohne Gestaltung bauen. Nutzerseite erst danach. Wochenweise Stand auf der Testumgebung |
| Vertraulichkeit an einer Stelle unterlaufen | PIN (04), Verwaltungssicht ohne Personen, Aggregation in der Abfrage, Protokolle ohne Inhalte. Vor Produktivstellung eine gezielte Prüfung: kann eine Rolle etwas sehen, was sie nicht kennen darf |
| Überbuchung gegen Praxistermine | Freigabe statt Sperrung, Vorlauffrist 48 Stunden, wöchentlicher Anstoß, Absageweg mit Rückbuchung |
| Mail landet im Spam | Brevo mit SPF und DKIM für rezuki.de, Absender festlegen (08) |
| Videoanbieter offen | V1 macht den Start unabhängig, Kopplung austauschbar hinter interner Schnittstelle |
| Betrieb ab Januar nicht geregelt | Entscheidung 02 vor Baubeginn |
| Nils und Katrin sehen den Stand zu spät | Testumgebung ab Phase 1 offen, Prototyp seit 13.09., Feedback in FEEDBACK.md |
8. Wie Nils jetzt weiterarbeitet
- Prototyp durchklicken: https://rezuki-flow.tanagra.cloud/prototyp/ zeigt Partnerseite, Nutzerseite und Verwaltung als klickbare Attrappe ohne Backend. Was fehlt, was falsch ist, was anders heißen soll: in
FEEDBACK.mdnotieren. - Entscheidungen 01 bis 09 in Abschnitt 6 markieren.
- Katrin den Prototyp zeigen, vor allem P4 Verfügbarkeiten und P5 Terminübersicht. Sie kennt die Partnerpraxis.
- Texte und Startseite können webki und die anderen Agenten der Box direkt in
website/pflegen. Änderungen sind sofort live. Regeln inREADME-fuer-Agenten.md. - Was nicht in den Workspace gehört: Backend, Datenbank, Geheimnisse, Personendaten. Das kommt in das Repository und den Stack.
9. Bezug
- Lastenheft und Prozessbeschreibung: tanagra.ai-Workspace
business/devops/006-development/rezuki/ - Gespräch 31.08.2026:
business/devops/009-gespraeche/plaud/2026-08-31_08-31-planung-der-prozessautomatisierung-… - Vault:
plattform/kalender-buchung-abrechnung,plattform/infrastruktur-dsgvo,konzept/datenschutz-compliance - Muster in der Flotte: service-job (Rocky), mfs-mvv-regioplan (Sulu)