cfgmon: CFGMON-11 Gitea-CI-Rueckbau nach GitLab-Umzug, CFGMON-10 verworfen

Entscheidung 2026-07-30: Build-CI zieht ins Homelab-GitLab
(git.lab/axion1337.chat). CFGMON-11 haelt fest, was auf Gitea-Seite danach
zurueckgebaut werden kann (Actions-Toggles, Workflow-Dateien, ggf. der
Runner-Service) inkl. Token-Bilanz (npm-Token in .npmrc revoken, neuer
Registry-Push-Token fuer GitLab-CI als Gegenstueck). CFGMON-10 als
verworfen geschlossen - die Ressourcen-Hypothese wurde durch den
ThreadNet-Web-Webpack-OOM (Job 3442, heap out of memory bei 92%) im Kern
bestaetigt, aber der Fix entfaellt durch den Umzug.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

hosts/cfgmon.md

@@ -189,34 +189,83 @@ Voraussetzungen, beide beim User:
    geprüft 2026-07-30) — Key generieren und den Public Key in der Storage Box
    hinterlegen (Robot-Webinterface oder einmalig per Passwort-Login).
 
-## CFGMON-10 — threadnet-call-CI schlägt am Artifact-Schritt fehl
+## CFGMON-11 — Gitea-CI-Rückbau nach GitLab-Umzug
 
-**Status:** offen
+**Status:** offen — wartet auf funktionierende GitLab-CI im Lab
 
-Ausgelöst durch einen Push nach `threadnet-call` am 2026-07-30: der Runner (`builder-1`,
-siehe CFGMON-02) verarbeitet mehrere geerbte Upstream-Workflows (`build.yaml`,
-`publish-embedded-packages.yaml`, u. a.), die meisten scheitern am selben Punkt —
-Checkout/Dependencies/teils sogar der Build-Schritt selbst laufen durch, aber
-**"📥 Download built element-call artifact"** bzw. **"Upload Artifact"** schlagen fehl.
+Entscheidung vom 2026-07-30: Build-CI/CD zieht ins Homelab-GitLab
+(`git.lab/axion1337.chat`, Gruppe mit importierten Projekten angelegt; die Domain ist
+**nur im Homelab auflösbar** — von CFGMON/MATRIX aus nicht erreichbar, was für den
+Build-Anwendungsfall in Ordnung ist: Prod läuft bei Lab-Ausfall weiter, nur neue Builds
+pausieren). Der am 2026-07-30 auf Gitea-Seite aufgebaute CI-Unterbau wird damit teilweise
+überflüssig. **Erst zurückbauen, wenn die GitLab-CI nachweislich läuft.**
 
-**Nicht verifizierte Hypothese**: das Job-Container-Limit in `runner/config.yaml`
-(2,2 GiB / 1,5 CPU, Kommentar dort: "2 parallele Electron-Builds ... enden im OOM — bei
-Host-Upgrade hochsetzen") ist für einen Element-Call-Build knapp. Kein OOM-Log direkt
-eingesehen — reine Vermutung aus dem Fehlerbild, nicht bestätigt.
+### Sicher rückbaubar
 
-**Nächster Schritt:** Job-Logs des Runners (nicht nur die Gitea-Actions-UI) auf
-OOM-Kill-Meldungen prüfen, bevor das Limit angehoben wird. Falls bestätigt: Kapazität/Limit
-in `thread-net-git`s `runner/config.yaml` anpassen (Trade-off gegen den knappen
-Host-Speicher, siehe CFGMON-02).
+- **Actions-Toggle** `has_actions` bei `ThreadNet-Web` (am 2026-07-30 per API aktiviert)
+  wieder deaktivieren, ebenso bei `threadnet-call` (stoppt die fehlschlagende
+  Workflow-Kaskade dort).
+- **`.github/workflows/` in `ThreadNet-Web`** (der kuratierte 6-Dateien-Satz) — wird durch
+  `.gitlab-ci.yml` ersetzt. Die Erkenntnisse aus den Läufen vom 2026-07-30 mitnehmen:
+  kein `layered.sh` (würde den js-sdk-Pin mit Upstream-develop überschreiben, braucht
+  außerdem jq), stattdessen `pnpm install --frozen-lockfile`; webpack-Build braucht
+  real ~4 GB Heap; `contains(needs.*.result, ...)`-Gates sind act-spezifisch kaputt.
+- **Geerbte Upstream-Workflows in `threadnet-call`** (build/publish/test/translations/
+  zizmor/pr-deploy) — gleiches Schicksal.
+- **Runner-Identität**: wenn der Runner-Service entfällt (siehe unten), `builder-1` in
+  der Gitea-Admin-UI deregistrieren und `runner-data/.runner` auf dem Host entfernen.
+- **Token: npm-Token in `threadnet-call`s untracked `embedded/web/.npmrc`** (Klartext im
+  Arbeitsverzeichnis, Fund vom 2026-07-30): revoken/rotieren. Der GitLab-CI-Publish
+  bekommt einen eigenen, frisch erzeugten Token als GitLab-CI-Variable — der alte
+  verschwindet von der Platte.
 
-Getrackt (inkl. der separaten npm-Registry-Fehlkonfiguration) als
-[threadnet-call#1](https://rohana.axion1337.de/sorb/threadnet-call/issues/1) - dort die
-eigentliche Arbeit, hier nur der Host-seitige Aspekt (Runner-Ressourcenlimit).
+### Entscheidungsabhängig
+
+- **Runner-Service in `thread-net-git` ganz entfernen?** Hängt daran, ob das gitops-Repo
+  seinen leichten `deploy-on-push.yml` (YAML-Validierung/Notification, läuft sauber)
+  behält — dann bleibt ein Minimal-Runner nötig. Bei Komplett-Entfernung als
+  Revert-Commit in `thread-net-git`: Compose-Service `runner`, `runner/config.yaml`,
+  `.env.example` (RUNNER_TOKEN), Cache-Port-Bindung 8088, `runner-data/`.
+- **Registry-Ziel für `@sorb/threadnet-call-embedded`**: bleibt die Gitea-npm-Registry
+  (dann braucht GitLab-CI einen Push-Token dorthin — Neuanlage) oder wandert in die
+  GitLab-Package-Registry (dann läuft die Gitea-Package-Seite leer).
+- **Container-Images bleiben in der rohana-Registry** (Flux/k8s pullt von dort — spricht
+  stark für Beibehalt). Gegenstück zur Token-Bilanz: GitLab-CI braucht dann einen
+  **neuen** Deploy-/Push-Token für die rohana-Registry (Neuanlage, kein Rückbau).
+
+### Explizit nicht rückbaubar
+
+Gitea selbst, gitops-Repo als Flux-Source, Issues/Wiki/dieses Backlogs-Repo, der
+API-Token für Issue-Verwaltung, das Gitea-Backup-Script (CFGMON-09).
+
+Betroffene Issues (werden bei der GitLab-Migrations-Planung umformuliert):
+[ThreadNet-Web#2](https://rohana.axion1337.de/sorb/ThreadNet-Web/issues/2),
+[threadnet-call#1](https://rohana.axion1337.de/sorb/threadnet-call/issues/1).
+
+**Nächster Schritt:** GitLab-CI aufbauen (eigene Planung), erst danach die Punkte oben
+abarbeiten.
 
 ---
 
 ## Erledigt
 
+### CFGMON-10 — threadnet-call-CI schlägt am Artifact-Schritt fehl · verworfen 2026-07-30
+
+Ausgelöst durch einen Push nach `threadnet-call` am 2026-07-30: der Runner (`builder-1`)
+verarbeitete mehrere geerbte Upstream-Workflows, die meisten scheiterten am
+Artifact-Upload/-Download-Schritt. Ursprünglich unverifizierte Hypothese: das
+Job-Container-Limit (2,2 GiB / 1,5 CPU) ist zu knapp.
+
+**Hypothese inzwischen im Kern bestätigt** — beim parallelen ThreadNet-Web-CI-Versuch
+starb der webpack-Build bei 92 % mit `FATAL ERROR: ... JavaScript heap out of memory`
+(Job 3442, 2026-07-30): diese Build-Klasse braucht real ~4 GB, der Host (3,7 GiB gesamt,
+ohne Swap, trägt daneben Gitea/Traefik/Monitoring) kann das strukturell nicht liefern.
+
+**Verworfen statt gefixt**: Limit-Anhebung/Swap wird bewusst nicht weiterverfolgt —
+Build-CI zieht ins Homelab-GitLab um (siehe
+[CFGMON-11](#cfgmon-11--gitea-ci-rückbau-nach-gitlab-umzug)), CFGMON bleibt bei leichten
+Jobs. Issue-Seite: [threadnet-call#1](https://rohana.axion1337.de/sorb/threadnet-call/issues/1).
+
 ### CFGMON-02 — Traefik, Gitea, cAdvisor und Runner unter IaC gebracht · erledigt 2026-07-30
 
 Liefen ursprünglich im Compose-Projekt `thread-net-git` aus `/data/compose/8`, einem von