Konzept: gemeinsame Gitea-Organisation für alle Mitarbeiter

Neutrales System-Konto statt knso, Organisation WEBklar mit einem
Webhook, automatischer Umzug beim Zuweisen, Pushes der letzten 30 Tage
nachtragen, Knopf "Preview einschalten", deutsche Uhrzeit.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

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

@@ -0,0 +1,305 @@
+# 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.