Webklar-Kundenbereich/docs/superpowers/specs/2026-09-27-gitea-organisation-design.md

Gemeinsame Gitea-Organisation für alle Mitarbeiter – Konzept

Stand 27.09.2026 · Entwurf zur Durchsicht · umgesetzt ist noch nichts

Betrifft Gitea (git.webklar.com), das Kundenportal (project.webklar.com), das Ticketsystem (ticket.webklar.com) und die Lead-Automatik (/opt/webklar-automation).

1. Ausgangslage

Anlass: Justins Repo JUSN/D-ner-Nation erschien nicht in der Projektliste des Ticketsystems, und sein Push am 27.09. um 16:46 Uhr erzeugte kein Arbeitsblatt. Bei Andrej (knso/emmas-schatzkiste, Kunde „Martin“, Ticket #100111) klappte beides.

Ursachen:

1. Das Kundenportal spricht mit Gitea über Kensos persönliches Konto knso. In Justins und Andrejs eigenen Repos darf knso nur lesen.
2. Pushes erreichen das Portal nur über Webhooks, die in jedem Repo einzeln eingerichtet sein müssen. Heute gibt es 100 davon, angelegt von Hand oder von der Lead-Automatik. Auch „Neues Projekt“ im Ticketsystem legt Repos ohne Webhook an (z. B. knso/gradient-component, knso/lackwerk-kl).
3. Neue Repos erscheinen im Ticketsystem erst, nachdem jemand auf der Projekte-Seite „Gitea-Repos synchronisieren“ gedrückt hat.
4. Ein Push wird nur dann ein Arbeitsblatt, wenn das Projekt zum Zeitpunkt des Pushs schon einem Ticket oder Kunden zugewiesen ist. Frühere Pushes gehen für die Abrechnung verloren.

Außerdem gefunden:

• Push-Arbeitsblätter tragen Datum und Uhrzeit in UTC, weil der Portal-Container keine Zeitzone hat. Im Sommer stehen sie 2 Stunden hinter der deutschen Zeit.
• Pushes, die das System selbst macht (z. B. die Preview-Einstellung ins Repo schreiben), erzeugen Arbeitsblätter auf knso.
• Der Gitea-Abgleich gibt jedem Repo eine Subdomain. Die Preview-Selbstheilung behandelt jedes Projekt mit Subdomain als Preview. Mit einem Webhook für viele Repos würde dadurch jeder Push in ein abgeglichenes Repo eine Preview anlegen.
• Im Portal kommen der Gitea-Schlüssel (GITEA_API_TOKEN) und das Webhook-Geheimnis (GITEA_WEBHOOK_TOKEN) aus derselben Variable GITEA_WEBHOOK_TOKEN in /home/webklar/apps/.env. Kensos Schlüssel ist also zugleich das Geheimnis aller Webhooks. Mehrere Deploy-Container klonen ebenfalls damit.

2. Ziel

1. Alle Mitarbeiter sind gleichberechtigt. Niemand braucht Sonderrechte, und niemand muss einem anderen Rechte geben, damit etwas funktioniert.
2. Alle Mitarbeiter können in jedem Kundenprojekt arbeiten.
3. Egal wer ein Repo anlegt und wo: Es erscheint im Ticketsystem, lässt sich einem Ticket oder Kunden zuweisen, läuft auf Knopfdruck als Preview, und jeder Push wird ein Arbeitsblatt für den, der gepusht hat. So lässt sich die Zeit für die Abrechnung eintragen.
4. Kundenportal, Ticketsystem und Lead-Automatik hängen nicht mehr an Kensos Konto.

Nicht Teil dieses Konzepts:

• die rund 90 bestehenden Lead-Repos bei knso. Sie ziehen erst um, wenn sie einem Ticket zugewiesen werden.
• interne Repos (Ticketsystem, Kundenportal, Website, Emailsorter usw.) und ihre Deploy-Container. Sie bleiben, wo sie sind, und nutzen weiter den bisherigen Schlüssel.
• ein eigenes Webhook-Geheimnis getrennt von Kensos Schlüssel (siehe 9).
• ein Gitea-Konto für Nico.
• das Umbenennen von Repos (z. B. D-ner-Nation).

3. Entscheidungen

Thema	Entscheidung	Herkunft
Mitarbeit	Alle Mitarbeiter können in allen Kundenprojekten arbeiten, mit denselben Rechten	Frage, bestätigt
Ort der Kunden-Repos	Gitea-Organisation „WEBklar“, alle Mitarbeiter im Team „Owners“	Vorschlag, bestätigt
Zugang des Systems	neutrales Konto webklar-system (Gitea-Admin) statt knso	Vorschlag, bestätigt
Pushes melden	ein Webhook an der Organisation (Weg A)	Vorschlag, bestätigt
Repos in eigenen Konten	werden beim Zuweisen automatisch nach WEBklar verschoben	Frage, bestätigt
Umzug jetzt	6 Kundenprojekte (siehe 7); Lead-Previews bleiben bei knso	Frage, bestätigt
Neue Lead-Previews	entstehen in WEBklar	Frage, bestätigt
Pushes vor der Zuweisung	werden beim Zuweisen nachgetragen, letzte 30 Tage	Frage, bestätigt
Preview	Knopf „Preview einschalten“ mit änderbarem Subdomain-Vorschlag	Frage, bestätigt
Uhrzeit der Push-Arbeitsblätter	deutsche Zeit (Europe/Berlin)	Vorschlag, bestätigt
Pushes des System-Kontos	erzeugen kein Arbeitsblatt	Vorschlag, bestätigt
Subdomains beim Abgleich	werden nicht mehr automatisch vergeben	Vorschlag, bestätigt
Interne Repos	werden nie automatisch verschoben (Regel in 5.3)	Vorschlag, bitte prüfen
Sichtbarkeit der Organisation	öffentlich, wie die Kunden-Repos heute	Vorschlag, bitte prüfen
Private Repos in der Projektliste	erscheinen mit (heute 13, alle bei knso)	Vorschlag, bitte prüfen

4. Gitea-Grundlage (Phase 1)

4.1 System-Konto

• Benutzername webklar-system, E-Mail webklar-system@noreply.webklar.com, E-Mail-Benachrichtigungen aus.
• Gitea-Admin. Nur so kann es Repos aus fremden Konten verschieben und private Repos lesen.
• Zufälliges Passwort, das nirgends gespeichert wird. Niemand meldet sich mit dem Konto an.
• Zwei Schlüssel, damit sich jeder einzeln sperren lässt: portal für das Kundenportal und lead-automatik für die Lead-Automatik. Rechte je Schlüssel: write:repository, write:organization, read:user. Keine Admin-Schnittstelle.
• Angelegt über die Gitea-Befehlszeile im Container webklar-gitea (gitea admin user create --admin …, gitea admin user generate-access-token --scopes … --raw). Die Schlüssel werden direkt in die Konfiguration geschrieben und nie angezeigt.

4.2 Organisation

• Name WEBklar, Adresse https://git.webklar.com/WEBklar/…, Sichtbarkeit öffentlich.
• Team „Owners“: webklar-system, knso, jusn, andj. Alle haben dieselben Rechte: Repos anlegen, pushen, Einstellungen ändern, löschen.
• Angelegt über die Gitea-Schnittstelle mit dem System-Konto.
• Bekommt Nico ein Gitea-Konto, kommt er ins Team „Owners“. Sein Konto muss als Namen „Nico Rech“ oder als Benutzernamen sein Kürzel NIRE tragen, damit seine Pushes ihm zugeordnet werden.

4.3 Webhook der Organisation

• URL https://project.webklar.com/webhook/gitea, Inhalt JSON, nur Push-Ereignisse, alle Branches.
• Geheimnis: der heutige Wert von GITEA_WEBHOOK_TOKEN. Das Portal prüft ihn wie bisher.
• Angelegt von einem Skript im Portal-Container, damit das Geheimnis nie ausgegeben wird.
• Er gilt für jedes Repo in WEBklar, auch für künftige. Einzel-Webhooks braucht es dort nicht mehr.

4.4 Einstellungen des Portals

Dienst kundenbereich-server in /home/webklar/apps/docker-compose.yml:

• GITEA_API_TOKEN=${GITEA_SYSTEM_TOKEN} (bisher ${GITEA_WEBHOOK_TOKEN}). GITEA_SYSTEM_TOKEN kommt neu in /home/webklar/apps/.env.
• GITEA_WEBHOOK_TOKEN=${GITEA_WEBHOOK_TOKEN} bleibt unverändert.
• GITEA_DEFAULT_OWNER=WEBklar. Neu sind GITEA_ORG=WEBklar und GITEA_SYSTEM_USER=webklar-system.
• GITEA_TEMPLATE_OWNER bleibt knso, weil die Vorlage knso/webklar-preview-template nicht umzieht.
• Neu, aber ohne Eintrag in der Compose-Datei: GITEA_KEEP_IN_PLACE. Die Voreinstellung steht im Code (siehe 5.3).
• Übernahme mit docker compose up -d --no-deps kundenbereich-server. Ein docker restart übernimmt neue Werte nicht.

5. Kundenportal (Phase 2)

5.1 Neue Repos finden

• Neue Funktion importNewRepos(). Sie holt alle Repos, die das System-Konto sieht, also alle, auch private. Für jedes nicht archivierte Repo ohne Projekt-Eintrag legt sie einen an:
  • Name = Gitea-Beschreibung, sonst der Repo-Name,
  • keine Subdomain, keine Preview-Adresse,
  • Status synced.
• Bestehende Einträge bleiben unverändert.
• Schnittstelle POST /api/admin/gitea/import-repos mit der Antwort { created }.
• Der Import läuft im Portal-Prozess nie doppelt. Ein zweiter Aufruf wartet auf den ersten.
• Projekt-Einträge anlegen (Import und Webhook) läuft pro Repo unter derselben Sperre wie der Umzug (5.3). So entsteht kein doppelter Eintrag, wenn Import und erster Push zusammenfallen.

5.2 Zuweisen

• Neue Schnittstelle POST /api/admin/website-projects/:id/assign mit { customerId, ticketId }.
• Ablauf:
  1. Kunde und Ticket am Projekt speichern.
  2. Falls nötig, das Repo nach WEBklar verschieben (5.3).
  3. Pushes nachtragen (5.4).
  4. Antwort { ok, project, moved: { from, to } | null, backfilled, warnings: [] }.
• Schritt 1 ist die eigentliche Zuweisung. Scheitert Schritt 2 oder 3, bleibt sie bestehen, und warnings beschreibt in einem deutschen Satz, was fehlt.
• Eine Zuweisung entfernen bleibt wie heute: direkt in Appwrite, ohne Gitea.

5.3 Umzug nach WEBklar

• Ein Repo außerhalb von WEBklar überträgt das Portal mit POST /repos/{owner}/{repo}/transfer (new_owner: WEBklar). Weil das System-Konto Gitea-Admin ist, geschieht das sofort. Alte Links und Push-Adressen leiten weiter.
• Danach:
  • bekommt der Projekt-Eintrag den neuen Namen (repoFullName, giteaRepoUrl, giteaRepoName),
  • werden die Zwischenspeicher für alten und neuen Namen geleert,
  • wird ein alter Einzel-Webhook ans Portal gelöscht (URL beginnt mit https://project.webklar.com/webhook/gitea),
  • wird das alte Arbeitsverzeichnis preview-data/<alter Name> gelöscht.
• Während eines Umzugs wartet die Webhook-Verarbeitung für dieses Repo bis zu 10 Sekunden. Dafür gibt es eine Sperre im Portal-Prozess. So entsteht kein doppelter Projekt-Eintrag, falls genau dann ein Push ankommt.
• Nie automatisch verschoben werden interne Repos. Als intern gilt ein Repo,
  • wenn es einen Webhook hat, der nicht ans Portal geht. Heute sind das knso/Webklar.com, ANDJ/Emailsorter, JUSN/Webklar, knso/hytail-ark, JUSN/tickte-system und knso/Webklar-Kundenbereich.
  • oder wenn es in GITEA_KEEP_IN_PLACE steht. Voreinstellung: die Repos der Deploy-Container, also ANDJ/Emailsorter, ANDJ/Steuerungstechnik, JUSN/tickte-system, JUSN/Webklar, knso/eship und knso/Webklar-Kundenbereich.
  • Solche Repos werden trotzdem zugewiesen und bekommen ihre Pushes nachgetragen. Die Warnung lautet: „Internes Repo, bleibt wo es ist.“
• Gibt es in WEBklar schon ein Repo mit dem Namen, findet kein Umzug statt. Die Warnung lautet: „In WEBklar gibt es schon ein Repo namens X. Bitte in Gitea umbenennen und dann ‚Pushes nachtragen‘ klicken.“
• Selbstheilung: Meldet Gitea für den gespeicherten Namen ein Repo unter einem anderen Namen (Weiterleitung nach einem Umzug), korrigiert das Portal den Projekt-Eintrag.

5.4 Pushes nachtragen

• Quelle sind die Gitea-Aktivitäten des Repos (GET /repos/{owner}/{repo}/activities/feeds, seitenweise). Berücksichtigt werden Einträge commit_repo der letzten 30 Tage, die Commits enthalten. Einträge ohne Commits, etwa ein neu angelegter Branch, werden übersprungen.
• Für jeden Push entsteht ein Arbeitsblatt wie beim Webhook:
  • Mitarbeiter = Gitea-Anzeigename oder Benutzername dessen, der gepusht hat,
  • die Commits mit Titel und Text,
  • Ende = Push-Zeitpunkt in deutscher Zeit, Start leer. Damit erscheint „Zeit nachtragen“.
• Übersprungen werden:
  • Pushes des System-Kontos,
  • Pushes, deren Commit im Ticket schon ein Arbeitsblatt hat. Das ist dieselbe Prüfung wie heute (Commit: <7 Zeichen> in den Details).
• Die ältesten Pushes kommen zuerst, damit die Arbeitsblatt-Nummern mit der Zeit steigen.
• Hat das Projekt nur einen Kunden und kein Ticket, wird wie beim Webhook zuerst ein Webpage-Ticket angelegt (ensureProjectTicket). Das geschieht nur, wenn es mindestens einen Push nachzutragen gibt.
• Schnittstelle für den Knopf „Pushes nachtragen“: POST /api/admin/website-projects/:id/pushes. Sie holt zuerst einen fehlgeschlagenen Umzug nach und trägt dann nach. Antwort { moved, backfilled, warnings }.

5.5 Push-Arbeitsblätter

• Datum und Uhrzeit in Europe/Berlin statt UTC, beim Webhook und beim Nachtragen. Vorhandene Arbeitsblätter bleiben unverändert.
• Pushes von GITEA_SYSTEM_USER erzeugen kein Arbeitsblatt. Deploy und Projektdaten laufen trotzdem.
• Pro Ticket und Commit legt der Portal-Prozess immer nur ein Arbeitsblatt gleichzeitig an. Zusammen mit der bestehenden Prüfung entsteht auch bei doppelter Zustellung nie ein doppeltes.

5.6 Absicherung der Previews

• Der Abgleich syncReposToAppwrite (Knopf „Gitea-Repos synchronisieren“) vergibt neuen oder leeren Einträgen keine Subdomain und keine Preview-Adresse mehr. Vorhandene Subdomains bleiben.
• Die Preview-Selbstheilung (ensureRepoPreviewConfig) greift nur noch für Projekte, die wirklich gehostet sind: Typ preview, website oder template, oder Status deployed oder pending. Heute reicht eine vorhandene Subdomain.
• slugify wandelt Umlaute um (ä→ae, ö→oe, ü→ue, ß→ss) und entfernt Apostrophe, bevor andere Sonderzeichen zu Bindestrichen werden.

5.7 Schnittstellen

Methode und Pfad	Zweck	neu
POST /api/admin/gitea/import-repos	neue Repos als Projekte anlegen	ja
POST /api/admin/website-projects/:id/assign	zuweisen, verschieben, nachtragen	ja
POST /api/admin/website-projects/:id/pushes	Umzug nachholen, Pushes nachtragen	ja
PATCH /api/admin/website-projects/:id	Preview einschalten (Typ preview + Subdomain)	nein
POST /webhook/gitea	Pushes aus Gitea	nein, Verhalten nach 5.3 und 5.5

Alle Admin-Schnittstellen sind wie heute nur für Mitarbeiter (requireAppwriteStaff).

6. Ticketsystem (Phase 3)

Die Änderungen entstehen auf dem dann aktuellen Stand von test, also nach „Paket B“ der Entschlackung. Diese Arbeit läuft parallel; dort wandern die Projektinhalte des Tickets in den Tab „Details“.

Dialog „Projekte bearbeiten“ (TicketProjectsModal):

• Beim Öffnen ruft er import-repos auf und lädt danach die Listen. Solange steht dort „Suche neue Repos …“.
• In der Liste „Verfügbar“ tragen Repos außerhalb von WEBklar den Zusatz „wird beim Zuweisen nach WEBklar verschoben“.
• „Zuweisen“ ruft für jedes gewählte Projekt nacheinander assign auf und zeigt eine Zusammenfassung, z. B. „Döner Nation: nach WEBklar verschoben · 1 Push nachgetragen“. Warnungen erscheinen darunter.

Zugewiesene Projekte (AssignedProjectCard):

• Preview einschalten erscheint, wenn keine Preview läuft, also kein previewUrl vorhanden ist oder der Status nicht deployed ist.
  • Ein Eingabefeld mit Vorschlag und der Knopf „Einschalten“ senden PATCH /api/admin/website-projects/:id mit projectType: 'preview' und subdomain.
  • Fehler, etwa eine schon vergebene Subdomain, erscheinen im Dialog.
• Pushes nachtragen sendet POST …/:id/pushes und zeigt das Ergebnis als Meldung.

Subdomain-Vorschlag (neue Datei src/lib/subdomain.js):

• Grundlage ist der Kundenname des Tickets, sonst der Projektname.
• Umlaute werden umgewandelt, Apostrophe entfallen, alles wird kleingeschrieben.
• Alles außer a–z und 0–9 wird zu einem Bindestrich. Höchstens 63 Zeichen.
• Beispiele: „Döner Nation“ → doener-nation, „Emma's Schatzkiste“ → emmas-schatzkiste.

Projekte-Seite:

• „Kunde zuordnen“ nutzt ebenfalls assign.
• Der Knopf „Gitea-Repos synchronisieren“ bleibt und verhält sich nach 5.6.

7. Umzug der Kundenprojekte (Phase 4)

Projekt	heute	danach	alter Einzel-Webhook
Emma's Schatzkiste	knso/emmas-schatzkiste	WEBklar/emmas-schatzkiste	Nr. 110, wird gelöscht
Anelia Wolf	knso/Anelia-Wolf	WEBklar/Anelia-Wolf	Nr. 100, wird gelöscht
Unger Reisen	ANDJ/Unger-Bus-Unternehmen	WEBklar/Unger-Bus-Unternehmen	Nr. 13, wird gelöscht
Döner Nation	JUSN/D-ner-Nation	WEBklar/D-ner-Nation	keiner
videogen	knso/videogen	WEBklar/videogen	Nr. 59, wird gelöscht
kfz	knso/kfz	WEBklar/kfz	keiner

Das siebte Kundenprojekt aus der Zählung, JUSN/tickte-system, ist ein internes Repo und bleibt.

Ablauf:

1. Die Webhooks der 6 Repos sichern (Nummer, URL, Ereignisse), damit sie sich wiederherstellen lassen.
2. Ein Skript im Portal-Container ruft Repo für Repo dieselbe Funktion wie „Pushes nachtragen“ auf: verschieben, Projekt-Eintrag anpassen, alten Webhook löschen, Pushes der letzten 30 Tage nachtragen. Dabei entsteht auch Justins Arbeitsblatt für den Push vom 27.09. um 16:46 Uhr.
3. Für Döner Nation schreibt das Skript danach die Preview-Einstellung .webklar-preview.json ins Repo. Justin macht vor seinem nächsten Push einmal git pull.
4. Prüfung je Projekt:
   • Der Projekt-Eintrag zeigt den neuen Namen.
   • Die Preview antwortet wie vorher: 302 zum Login, bei den öffentlichen Seiten 200.
   • Die Änderungsliste im Kundenportal lädt.

Für die Mitarbeiter: Alte Push-Adressen leiten weiter. Sauberer ist git remote set-url origin https://git.webklar.com/WEBklar/<repo>.git, die Befehle kommen pro Repo.

Kunden merken nichts. Preview-Adressen und die Domains emmas-schatzkiste.de und anelia-wolf.com bleiben gleich, weil die Previews nach Subdomain abgelegt sind und nicht nach Repo-Namen.

8. Lead-Automatik (Phase 5)

Diese Phase hängt nur von Phase 1 ab und kann auch später kommen.

• config.env:
  • GITEA_TOKEN wird der Schlüssel lead-automatik des System-Kontos,
  • neu GITEA_AUTH_USER=webklar-system für die Git-Adressen,
  • neu GITEA_NEW_REPO_OWNER=WEBklar.
  • GITEA_USER=knso bleibt als Besitzer der bestehenden Lead-Repos.
• Jeder Lead speichert künftig repo_owner. Bestehende Leads ohne dieses Feld gelten als knso, neue bekommen WEBklar.
• Alle Stellen, die heute Repo-Pfade und Git-Adressen aus GITEA_USER bilden, nutzen stattdessen die Funktionen lead_repo_full(lead) und lead_git_url(lead). Das betrifft worker.py, processor.py, enrich.py und alle weiteren Dateien mit diesem Muster.
• ensure_repo legt neue Repos in WEBklar an (POST /orgs/WEBklar/repos) und setzt dort keinen Einzel-Webhook. Für Repos bei knso bleibt ensure_repo_webhook wie heute.
• Pushes der Automatik laufen dann über das System-Konto und erzeugen keine Arbeitsblätter auf knso mehr.
• Umgestellt wird direkt nach einem Morgenlauf (06:30 Uhr). Der nächste Lauf wird geprüft.

9. Sicherheit

• webklar-system ist Gitea-Admin, damit es fremde Repos verschieben kann. Seine Schlüssel dürfen nur Repos und die Organisation bearbeiten und Benutzer lesen. Die Admin-Schnittstelle ist ausgeschlossen, und Portal und Lead-Automatik haben getrennte Schlüssel.
• Das Portal kann damit alle Repos lesen und schreiben, auch private. Heute kann es das nur bei knso.
• Das Webhook-Geheimnis bleibt der heutige Wert, also Kensos Schlüssel. Wird der Schlüssel in Gitea gesperrt, fallen die Deploy-Container aus, die damit klonen. Die Webhooks prüfen nur den Wert und laufen weiter. Soll der Wert geändert werden, müssen alle Webhooks mit. Empfehlung für später: ein eigenes Geheimnis und eigene Deploy-Schlüssel.
• Admin-Schnittstellen sind wie heute nur für Mitarbeiter.

10. Fehlerfälle

Fall	Verhalten
Name existiert schon in WEBklar	kein Umzug; Warnung mit der Bitte, umzubenennen
internes Repo (5.3)	kein Umzug; Zuweisung und Nachtragen laufen; Warnung „Internes Repo, bleibt wo es ist.“
Gitea nicht erreichbar	Zuweisung gespeichert; Warnung; später „Pushes nachtragen“
Umzug gelungen, Projekt-Eintrag nicht aktualisiert	Warnung; „Pushes nachtragen“ erkennt den neuen Namen über die Weiterleitung und korrigiert
Push kommt während eines Umzugs	Webhook-Verarbeitung wartet bis zu 10 Sekunden auf den Umzug
Push kommt doppelt an	ein Arbeitsblatt
Schlüssel des System-Kontos fehlt oder ist ungültig	Fehlermeldung wie heute („GITEA_API_TOKEN fehlt“ bzw. Gitea 401)

11. Tests

Kundenportal, automatisch (npm test, ohne echte Daten):

• Umwandlung der Gitea-Aktivitäten in Pushes: nur commit_repo, 30-Tage-Grenze, Einträge ohne Commits, System-Konto.
• deutsche Zeit für Sommer, Winter und kurz nach Mitternacht UTC.
• slugify mit Umlauten und Apostrophen.
• isHostedProject.
• Umzug mit einem nachgebauten Gitea: gelungen, Name existiert, schon in WEBklar, internes Repo, Weiterleitung nach Umzug.
• Zuweisen mit nachgebautem Appwrite und Gitea: Reihenfolge der Schritte, Webhook gelöscht, Nachtragen ohne Doppelte, Warnungen bei Gitea-Ausfall.
• Sperre: zwei gleichzeitige Arbeitsblätter für denselben Commit ergeben eines.

Kundenportal, Ablauf: Das Portal läuft isoliert mit nachgebautem Appwrite und Gitea und wird über die neuen Schnittstellen von Anfang bis Ende geprüft.

Ticketsystem: Oberflächentest mit dem bestehenden esbuild- und Playwright-Aufbau:

• Beim Öffnen des Dialogs wird import-repos aufgerufen.
• Der Zusatz „wird verschoben“ erscheint.
• Die Zusammenfassung nach dem Zuweisen erscheint.
• „Preview einschalten“ schlägt doener-nation vor und lässt den Vorschlag ändern.
• „Pushes nachtragen“ funktioniert.
• Der Subdomain-Vorschlag hat eigene Tests.

Lead-Automatik: Die Pfad-Funktionen werden mit alten Leads (ohne repo_owner) und neuen Leads geprüft. Dazu kommt ein Probelauf gegen ein Wegwerf-Repo in WEBklar.

Nach dem Livegang, nur mit ausdrücklichem OK: Ein Wegwerf-Repo wird in einem eigenen Konto angelegt und einem Test-Ticket zugewiesen. Geprüft wird, dass es nach WEBklar zieht, dass ein Push darin ankommt und dass daraus ein Arbeitsblatt wird. Danach wird alles wieder entfernt.

12. Reihenfolge, Livegang und Rückweg

1. Phase 1, Gitea. Solange WEBklar leer ist, ändert sich nichts. Prüfung: Organisation, Team und Webhook sind vorhanden, der Schlüssel antwortet auf /api/v1/user.
2. Phase 2, Kundenportal. Push nach main, dann die neuen Einstellungen übernehmen. Prüfung: Start ohne Fehler, Preview-Abgleich, import-repos legt die fehlenden Einträge an.
3. Phase 3, Ticketsystem. Push nach test. Prüfung: Die ausgelieferte Oberfläche enthält den neuen Dialog.
4. Phase 4, Umzug der 6 Kundenprojekte nach 7.
5. Phase 5, Lead-Automatik nach 8.

Pushes nach main und test erfolgen wie bisher erst nach deinem OK. Gitea- und Konfigurationsschritte führe ich aus, soweit die Rechteprüfung es zulässt. Sonst bekommst du die fertigen Befehle.

Rückweg:

• Phase 2: GITEA_API_TOKEN=${GITEA_WEBHOOK_TOKEN} wiederherstellen und docker compose up -d --no-deps kundenbereich-server ausführen.
• Phase 4: Die Repos an ihre alten Besitzer zurück übertragen und die Einzel-Webhooks aus der Sicherung neu anlegen.
• Phase 5: config.env aus der Sicherung zurückholen.
• Die Organisation kann bleiben. Leer schadet sie nicht.