Output:
Chunk ID: 4e6242
Wall time: 0.0000 seconds
Process exited with code 0
Original token count: 4261
Output:
# SESSION_HANDOFF — kube-bot

Stand: 2026-06-14 09:53 UTC

## Aktueller Zustand
- IT15 ist Management-Ziel.
- One-Node-K3s auf IT15 läuft.
- Neues Argo CD auf IT15 läuft im Namespace `argocd`, Service `argocd-server`, bewusst nur `ClusterIP`/nicht exponiert.
- Bestehendes DMZ-Argo-CD bleibt unverändert bis Parallelbetrieb + Rollback-Gate erfolgreich sind.
- Infisical auf IT15 läuft lokal in Docker/WSL; API erreichbar unter `http://192.168.1.121:8088`.
- Infisical Backup/Restore-Gate war grün.
- Keine Secretwerte werden in Slack/Logs ausgegeben.

## Infisical Stand
- Fachliche Ziel-Organisation für Cattaro-Betrieb: `cattaro_gmbh`.
- `Admin Org` ist nicht mehr Default/Fachgrenze für Cattaro-Infrastruktur.
- Runtime-Variablen aktuell vorhanden:
  - `INFISICAL_CLIENT_ID` gesetzt.
  - `INFISICAL_AUTH_KEY` gesetzt.
- Universal Auth Login mit aktueller Cattaro-Client-ID erfolgreich getestet am 2026-06-14 09:52 UTC.
- Token wurde empfangen, aber nicht ausgegeben.
- `/api/v1/projects` liefert genau 1 sichtbares Projekt:
  - Name: `platform-kubernetes`
  - Slug: `platform-kubernetes-lk-mr`
  - ID: `c5e8661f-4b7a-43e1-80b0-8674f30950dc`
- `/api/v2/projects` existiert auf dieser Instanz nicht / 404.

## Konzeptentscheidung Mandanten / Fachanwendungen
- Cattaro GmbH wird als eigene fachliche Grenze modelliert.
- Externe Mandanten werden später separat modelliert.
- Zielmodell:
  - Infisical: Org `cattaro_gmbh`; Projekt `platform-kubernetes` für Cattaro-Platform/Kubernetes; später `tenant-cattaro` oder app-/mandantenspezifische Projekte nach Bedarf.
  - Argo CD: Platform-AppProjects (`platform-core`, `platform-security`, `platform-observability`) und Tenant-AppProject `tenant-cattaro`.
  - Kubernetes: Platform-Namespaces getrennt von Fachanwendungs-Namespaces, z.B. `platform-argocd`, `platform-secrets`, `tenant-cattaro-stage`, `tenant-cattaro-prod`.
- Keine mandantenübergreifenden Machine Identities.
- Keine globalen Tokens in Argo CD oder Workloads.
- Produktiv-/Stage-/Dev-Identities strikt trennen.
- Konzeptdatei aktualisiert:
  - `/home/node/.openclaw/workspace/INFISICAL_ARGO_K3S_KONZEPT.md`

## Guardrails
- Kein DB-Bootstrap als nächster Schritt.
- DB-Bootstrap nur letzte Option, mit frischem Backup/Restore-Gate und explizitem OK von Mislav.
- Keine schreibenden Infisical-Änderungen ohne explizites OK.
- Keine Argo-CD Credential-Rotation ohne explizites OK.
- Keine Änderungen an DMZ-K3s ohne explizites OK.
- Secrets/Tokens/kubeconfigs niemals im Klartext posten.

## Nächste sichere Schritte
1. Lesend weiter prüfen, welche Environments/Secrets-Metadaten im Projekt `platform-kubernetes` vorhanden sind, ohne Secretwerte auszugeben.
2. Minimalen Zielpfad für kube-bot/Argo-CD Credentials festlegen.
3. Danach mit OK: Argo-CD Admin-Credential rotieren und direkt in Infisical speichern.
4. Danach mit OK: DMZ-K3s mit eingeschränktem Pilot-ServiceAccount/RBAC an IT15-Argo-CD anbinden.
5. Danach Pilotdeployment für unkritische Cattaro-App in `tenant-cattaro-stage`.

## Wichtige Pfade / IDs
- Plan: `/home/node/.openclaw/workspace/ARGOCD_IT15_INFISICAL_PIDOKA_PLAN.md`
- Handoff: `/home/node/.openclaw/workspace/SESSION_HANDOFF.md`
- Konzept: `/home/node/.openclaw/workspace/INFISICAL_ARGO_K3S_KONZEPT.md`
- IT15: `Misla@192.168.1.121`
- Infisical app path: `/opt/infisical`
- Infisical backup grün: `/root/infisical-backups/backup-20260613-080228`

## Ergänzung — Zielkorrektur und offene Aufgaben (2026-06-15 08:34 UTC)

- SSH ist jetzt als Zugriffspfad für den operativen DMZ-K3s-Kontext vorgesehen.
- Ziel bleibt: IT15/Intranet-Argo-CD steuert Deployments in den operativen DMZ-K3s-Cluster.
- Die Dummy-Testanwendung darf nicht auf dem IT15-Management-K3s verbleiben; sie ist als Pilot für den DMZ-Zielcluster zu verwenden.
- Vor dem Pilotdeployment ist read-only zu prüfen, ob und wo die irrtümliche Dummy-App auf IT15 existiert, damit sie später nach explizitem OK sauber entfernt oder ignoriert werden kann.
- Zusätzlich offene Secret-Aufgabe: kube-bot/OpenClaw SSH-Private-Keys sollen in Infisical gesichert werden, weil lokale SSH-Keys nach OpenClaw-Updates verloren gehen können.
- Für SSH-Key-Sicherung gilt: keine Private-Key-Inhalte in Slack/Logs; Ablage nur über sicheren Infisical-Write-Pfad und nur nach explizitem OK.

## Demo Deployment Status — 2026-06-15 12:36 UTC

- SSH/sudo Zugriff auf DMZ Control-Plane `kube-bot@192.168.20.40` funktioniert.
- IT15 Management-K3s und Argo CD sind gesund.
- IT15 kann DMZ Kubernetes API `192.168.20.40:6443` erreichen.
- Pilot-Namespace im DMZ-Cluster angelegt: `tenant-cattaro-stage`.
- Restricted Argo CD ServiceAccount im DMZ-Cluster angelegt: `tenant-cattaro-stage/argocd-demo-manager`.
- IT15 Argo CD Zielcluster-Secret registriert für DMZ-Cluster, beschränkt auf Namespace `tenant-cattaro-stage`.
- Demo-Application in IT15 Argo CD: `argocd/demo-guestbook-cattaro-stage`.
- Quelle: `https://github.com/argoproj/argocd-example-apps.git`, Pfad `guestbook`.
- Ziel: DMZ-Cluster Namespace `tenant-cattaro-stage`.
- Status: `Synced` / `Healthy`.
- Direkte DMZ-Verifikation: `deployment/guestbook-ui` rollout erfolgreich; Service `guestbook-ui` intern per curl erreichbar.

Hinweise:
- Kein Ingress/Public Exposure für die Demo-App angelegt.
- RBAC für den Pilot ist namespace-weit administrativ plus minimale Discovery-Rechte, aber nicht cluster-admin.
- Tokens/Secrets wurden nicht in Slack ausgegeben.

## SSH-Zugangsmerker — 2026-06-15 13:00 UTC

- Aktuelle OpenClaw Runtime: User `node`, Host/Container `0e9d9d0b8619`.
- Lokaler SSH-Key: `/home/node/.ssh/kube-bot-it15-ed25519`.
- Funktionierender DMZ-Control-Plane-Zugang: `kube-bot@192.168.20.40` mit `-i ~/.ssh/kube-bot-it15-ed25519`.
- Auf `192.168.20.40` funktioniert `sudo kubectl --kubeconfig=/etc/rancher/k3s/k3s.yaml ...`.
- Nicht verwenden: `sudo KUBECONFIG=/etc/rancher/k3s/k3s.yaml kubectl ...`, weil sudo das Setzen von `KUBECONFIG` blockiert.
- IT15 `Misla@192.168.1.121` ist aus aktueller Runtime derzeit nicht per SSH erreichbar (`Permission denied`); User/Key muss bestätigt oder neu eingerichtet werden.
- Keine SSH-Private-Key-Inhalte in Slack oder Markdown dokumentieren.

## IT15 SSH-Korrektur — 2026-06-15 14:15 UTC

- Korrektes IT15 SSH-Ziel aus OpenClaw Runtime: `Misla@192.168.1.121`.
- Korrektes Kommandomuster: `ssh -i /home/node/.ssh/kube-bot-it15-ed25519 Misla@192.168.1.121`.
- IT15 ist Windows; Linux/K3s-Kontext läuft in WSL Distribution `Ubuntu`.
- Korrektes WSL-Kommandomuster: `ssh -i /home/node/.ssh/kube-bot-it15-ed25519 Misla@192.168.1.121 "wsl.exe -d Ubuntu -e bash -lc '<command>'"`.
- Verifiziert: IT15 Management-K3s `it15-mgmt` Ready, Argo CD Pods Running.
- ArgoCD Apps gefunden:
  - `demo-guestbook-cattaro-stage`: dest `https://192.168.20.40:6443`, namespace `tenant-cattaro-stage`, `Synced/Healthy` — korrektes DMZ-Ziel.
  - `guestbook`: dest `https://kubernetes.default.svc`, namespace `tenant-cattaro-stage`, `Synced/Healthy` — lokale/Intranet-App, später nach explizitem OK entfernen.

## Infisical Recovery-Ablage — kube-bot SSH Keys — 2026-06-15 14:29 UTC

- SSH-Recovery-Secrets liegen in Infisical:
  - Projekt: `platform-kubernetes` (`c5e8661f-4b7a-43e1-80b0-8674f30950dc`)
  - Environment: `prod`
  - Pfad: `/bots/kube-bot/ssh`
- Secret-Namen: `SSH_KEY_IT15_PRIVATE`, `SSH_KEY_IT15_PUBLIC`, `SSH_KEY_IT15_FINGERPRINT`, `SSH_HOST_IT15`, `SSH_KEY_IT15_LOCAL_PATH`, `SSH_HOST_DMZ_CONTROL_PLANE`, `SSH_HOST_DMZ_WORKER`.
- Fingerprint: `SHA256:v1vAeRvbpSAkVQe2kTdjZjwNexaFJ59XWt8+QlOXgmE`.
- Recovery: Key aus Infisical lesen -> `/home/node/.ssh/kube-bot-it15-ed25519` schreiben -> `chmod 600` -> Fingerprint prüfen -> SSH testen.
- Verification 2026-06-15 14:29 UTC: Infisical-readback in temporärer Datei + SSH-Probe auf IT15 erfolgreich; temporäre Datei gelöscht.
- Niemals Private-Key-Inhalte ausgeben.

## Ergänzung Infisical — DMZ SSH Key-Namenssatz — 2026-06-15 14:35 UTC

- DMZ-spezifische SSH-Secrets ergänzt im Pfad `platform-kubernetes/prod:/bots/kube-bot/ssh`:
  - `SSH_KEY_DMZ_PRIVATE`, `SSH_KEY_DMZ_PUBLIC`, `SSH_KEY_DMZ_FINGERPRINT`, `SSH_KEY_DMZ_LOCAL_PATH`, `SSH_HOST_DMZ_CONTROL_PLANE`, `SSH_HOST_DMZ_WORKER`.
- Das Keymaterial ist aktuell identisch mit dem OpenClaw/kube-bot Key für IT15, aber unter separaten DMZ-Namen abgelegt, damit Recovery/Automation nicht an IT15-Namen hängt.
- Verification: Infisical-readback + temporärer SSH-Test auf `kube-bot@192.168.20.40` erfolgreich; temporäre Datei gelöscht.

## SSH Verifikation — DMZ Worker `192.168.20.45` — 2026-06-15 15:03 UTC

- `kube-bot@192.168.20.45` funktioniert mit `/home/node/.ssh/kube-bot-it15-ed25519`.
- sudo NOPASSWD funktioniert.
- Host meldet `mini-it13-02`.
- Key ist über Infisical DMZ-Namenssatz dokumentiert: `platform-kubernetes/prod:/bots/kube-bot/ssh`.

## SSH Verifikation — Nginx Proxy Host `192.168.20.20` — 2026-06-15 15:14 UTC

- `kube-bot@192.168.20.20` funktioniert mit `/home/node/.ssh/kube-bot-it15-ed25519`.
- sudo NOPASSWD funktioniert.
- Host meldet `raspi`.
- Alter Authorized-Key-Kommentar `kube-bot@openclaw-k3s-diagnostics` wurde entfernt; aktueller Key `kube-bot@openclaw-it15-20260614` bleibt.
- Backup der ursprünglichen `authorized_keys` wurde auf dem Zielhost angelegt.

## Ergänzung Infisical — Nginx/Raspi SSH Key-Namenssatz — 2026-06-15 15:16 UTC

- Nginx/Raspi-spezifische SSH-Secrets ergänzt im Pfad `platform-kubernetes/prod:/bots/kube-bot/ssh`:
  - `SSH_KEY_NGINX_PRIVATE`, `SSH_KEY_NGINX_PUBLIC`, `SSH_KEY_NGINX_FINGERPRINT`, `SSH_KEY_NGINX_LOCAL_PATH`, `SSH_HOST_NGINX_PROXY`.
- Ziel: `kube-bot@192.168.20.20`.
- Das Keymaterial ist aktuell identisch mit dem OpenClaw/kube-bot Key, aber unter separaten Nginx-Namen abgelegt.
- Verification: Infisical-readback + temporärer SSH-Test auf `kube-bot@192.168.20.20` erfolgreich; temporäre Datei gelöscht.

## Arbeitsregel ergänzt — Proaktive Schlussfolgerungen — 2026-06-15 15:30 UTC

- Kube-bot soll nach Aktivitäten proaktiv Schlussfolgerungen ziehen, sichere Folgearbeiten erledigen, Merker aktualisieren und nächste Schritte empfehlen.
- Diese Regel gilt allgemein, nicht nur für SSH-Zugänge.
- Grenze bleibt: riskante/schreibende/destructive Infrastruktur-, Cluster-, Firewall-, Secret- oder Deployment-Aktionen nur mit explizitem OK von Mislav.

## Read-only Migrationsinventur — ArgoCD/Mandanten — 2026-06-15 15:45 UTC

- Migrationsmatrix erstellt: `/home/node/.openclaw/workspace/inventory/argocd-mandanten-migrationsmatrix-20260615.md`.
- Rohdaten abgelegt unter: `/home/node/.openclaw/workspace/inventory/migration-20260615/`.
- Ergebnis: IT15-ArgoCD ist Zielsystem; DMZ-ArgoCD `infra-argocd` verwaltet aktuell `n8n`, `hf-mautic`, `hf-espocrm`, `suitecrm`, `apps`.
- Pilot-App `demo-guestbook-cattaro-stage` läuft auf DMZ, aber noch im IT15-ArgoCD Project `default`; nächster sauberer Mandantenmodell-Schritt ist Überführung ins Project `tenant-cattaro`.
- Empfohlene erste echte App-Migration: `hf-n8n`, nach read-only Detailcheck zu Helm-Werten, Secrets-Metadaten, PVC/Backup und Ingress.
- Keine Secrets ausgegeben, keine Cluster-Änderungen durchgeführt.

## Mandanten-Pilot IT15 ArgoCD — 2026-06-15 15:48 UTC

- Freigegeben durch Mislav: Demo-App in Mandantenmodell überführen.
- Änderung durchgeführt:
  - IT15 ArgoCD AppProject `tenant-cattaro` um Destination `https://192.168.20.40:6443` / Namespace `tenant-cattaro-stage` erweitert.
  - Application `demo-guestbook-cattaro-stage` von Project `default` nach `tenant-cattaro` verschoben.
- Verifikation:
  - IT15 ArgoCD: `demo-guestbook-cattaro-stage` ist `Synced/Healthy`, Project `tenant-cattaro`.
  - DMZ-K3s: `tenant-cattaro-stage/guestbook-ui` Deployment/Service/Pod laufen weiter; Pod auf Worker `mini-it13-02`.
- Roh-/Verify-Ausgabe: `/home/node/.openclaw/workspace/inventory/migration-20260615/demo-project-move-verification.txt`.
- Schlussfolgerung: Mandanten-AppProject-Modell funktioniert grundsätzlich für IT15-ArgoCD -> DMZ-K3s.
- Nächster empfohlener Schritt: read-only Detailcheck für erste echte Migration `hf-n8n` (altes DMZ-ArgoCD -> IT15 ArgoCD / tenant-pidoka), inkl. Helm-Werte, Secret-Metadaten, PVC/Longhorn, Ingress/NPM und Rollback-Pfad.

## ArgoCD GitHub-Verbindung — Check 2026-06-15 15:50 UTC

- Frage geprüft: Ist neues IT15-ArgoCD schon wie altes DMZ-ArgoCD mit GitHub verbunden?
- Ergebnis: Nein, nicht gleichwertig.
- IT15-ArgoCD hat aktuell keine Repository-/Repo-Creds-Secrets (`argocd.argoproj.io/secret-type=repository|repo-creds`) gefunden.
- IT15 kann öffentliche GitHub-Repos nutzen; Demo-App zieht `https://github.com/argoproj/argocd-example-apps.git` erfolgreich ohne Credentials.
- Altes DMZ-ArgoCD hat Repository-Credential für `https://github.com/GitMasterOne/ArgoCD.git` mit Username/Password vorhanden (Werte nicht ausgegeben).
- Schlussfolgerung: Für Migration der echten Apps aus `GitMasterOne/ArgoCD(.git)` muss im IT15-ArgoCD noch ein GitHub Repo Credential angelegt oder aus Infisical/Token-Flow sauber bereitgestellt werden.
- Rohcheck: `/home/node/.openclaw/workspace/inventory/migration-20260615/argocd-github-connectivity-check.txt`.

## IT15 ArgoCD Readiness Check — 2026-06-15 15:52 UTC

- Readiness-Check dokumentiert: `/home/node/.openclaw/workspace/inventory/argocd-readiness-20260615/README.md`.
- Wichtigste vergessene/offene Punkte:
  1. IT15-ArgoCD hat noch keine GitHub/Repository-Credentials für `GitMasterOne/ArgoCD.git`.
  2. `default` AppProject ist noch breit offen; echte Apps nicht dort betreiben.
  3. `tenant-cattaro` ist noch Pilot-offen (`sourceRepos: *`, Namespace-Ressourcen `*/*`).
  4. `tenant-pidoka` fehlt.
  5. Platform-AppProject(s) fehlen.
  6. Initial Admin Secret existiert noch; Rotation/Ablage in Infisical offen.
  7. ArgoCD CLI fehlt in IT15/WSL PATH.
- Keine Änderungen durchgeführt, nur read-only.

## GitHub PAT für GitOps — Infisical Ablage — 2026-06-15 16:11 UTC

- Mislav hat einen GitHub PAT bereitgestellt; Tokenwert wurde nicht in Markdown dokumentiert.
- Token wurde gegen GitHub verifiziert:
  - Login: `GitMasterOne`
  - Scopes: `repo`
- Token wurde in Infisical abgelegt:
  - Projekt: `platform-kubernetes` (`c5e8661f-4b7a-43e1-80b0-8674f30950dc`)
  - Environment: `prod`
  - Pfad: `/platform/gitops/github`
  - Secret: `GITHUB_PAT_PLATFORM_GITOPS`
- Weitere Metadaten-Secrets: `GITHUB_PAT_PLATFORM_GITOPS_OWNER`, `GITHUB_PAT_PLATFORM_GITOPS_SCOPES`, `GITHUB_REPO_PLATFORM_GITOPS`, `GITHUB_REPO_PLATFORM_GITOPS_URL`.
- Slack-Delete des Token-Posts wurde versucht, schlug aber fehl (`cant_delete_message`). Empfehlung: Mislav löscht die Slack-Nachricht selbst oder rotiert den Token nach Einrichtung.

## GitHub Repo `platform-gitops` + IT15 ArgoCD Credential — 2026-06-15 16:18 UTC

- Repo geprüft: `GitMasterOne/platform-gitops` existiert, ist privat.
- Repo war leer/ohne Inhalt; initiale GitOps-Struktur wurde gepusht.
- Commit: `ae57069` (`Initial GitOps structure for platform and tenants`).
- Enthält Grundstruktur:
  - `clusters/it15-mgmt/argocd/projects/`
  - `clusters/it15-mgmt/argocd/apps/`
  - `clusters/dmz-k3s/bootstrap/`
  - `platform/`
  - `tenants/cattaro/`
  - `tenants/pidoka/`
  - `shared/`
- IT15 ArgoCD Repository Secret erstellt: `argocd/repo-platform-gitops`.
  - URL: `https://github.com/GitMasterOne/platform-gitops.git`
  - Username: `x-access-token`
  - Password/PAT aus Infisical; Wert nicht dokumentiert.
- ArgoCD-Verifikation: Application `platform-argocd-projects` erstellt, Quelle `platform-gitops`, Pfad `clusters/it15-mgmt/argocd/projects`, Status `Synced/Healthy`, Revision `ae57069dc1e0ff38a6134194d47e8d1a75961b22`.
- Hinweis: `platform-argocd-projects` läuft aktuell noch im ArgoCD Project `default`, weil sie die AppProjects selbst verwaltet. Später ggf. Bootstrap/Platform-Project sauber modellieren.
- Direkter `git ls-remote` im repo-server Pod schlug ohne Credentials erwartbar fehl und ist kein valider ArgoCD Credential-Test.

## Zammad Longhorn Migration — 2026-06-17 22:40 UTC

- Fokus nach Mislavs OK: Zammad von alten `local-path` PVCs auf Longhorn-PVCs migrieren, nicht weg von PVCs generell.
- Vorherige GitOps-Adoption war bereits grün:
  - `pidoka-hf-zammad`: `Synced/Healthy`
  - `pidoka-hf-zammad-secrets`: `Synced/Healthy`
  - Secrets laufen über ESO/Infisical; keine Secretwerte dokumentiert.
- Fresh final backup vor Storage-Freeze:
  - Pfad: `/home/kube-bot/backups/zammad-longhorn-20260617T222011Z`
  - DB-Dump: `zammad-postgresql-final.sql.gz`
  - gzip-Test und SHA256-Check waren erfolgreich.
- Neue Longhorn-PVCs:
  - `zammad-postgresql-data-longhorn` -> `pvc-e8dd7160-96c9-4409-b9b8-0e15e1a2ba5f`
  - `zammad-elasticsearch-data-longhorn` -> `pvc-34a029bc-ec9c-4ae6-8dfe-3e40905b8ca4`
  - `zammad-redis-data-longhorn` -> `pvc-61d812f1-d3f3-4d63-a194-782128ae536f`
  - `zammad-var-longhorn` -> `pvc-ed7727c1-57f6-4ed0-8dc2-3f7854de1339`
- Alte `local-path` PVCs bleiben bewusst erhalten und dürfen noch nicht gelöscht werden:
  - `data-zammad-postgresql-0`
  - `data-zammad-elasticsearch-master-0`


Output:
Chunk ID: 99a645
Wall time: 0.0000 seconds
Process exited with code 0
Original token count: 0
Output:


Output:
Chunk ID: a3442e
Wall time: 0.0000 seconds
Process exited with code 0
Original token count: 195
Output:
# Morgen: DMZ Infisical Wiedereinstieg

## Ziel
DMZ-Infisical sicher bootstrappen, ohne Firewall-Öffnung oder Public Exposure.

## Startzustand
- ArgoCD grün: `platform-infisical-dmz`, `platform-argocd-projects`, `demo-guestbook-cattaro-stage`.
- DMZ Namespace `platform-infisical` grün.
- Infisical `/api/status`: `Ok`.
- Service nur `ClusterIP`.

## Reihenfolge
1. Status erneut verifizieren.
2. Temporären Port-Forward öffnen.
3. Admin-Erstzugang durchführen.
4. Initial-Secrets/Recovery sichern.
5. Backup/Restore-Konzept für PostgreSQL/PVC festlegen.
6. Danach Operator/Secret-Sync für `n8n`.

## Wichtig
- Keine Secretwerte in Slack/Markdown.
- Kein Ingress/Public Exposure für Bootstrap.
- Keine Cluster-Änderungen ohne explizites OK, außer read-only/status.


Output:
Chunk ID: c1b276
Wall time: 0.0000 seconds
Process exited with code 0
Original token count: 1966
Output:
# Plattformaufgaben — kube-bot Spur

Stand: 2026-06-11
Status: Entwurf / read-only / keine Umsetzung

## Fokus kube-bot

- K3s Plattform-Runtime
- Argo CD / GitOps
- Namespaces / Mandantentrennung
- Ingress / DMZ-Exposure
- NetworkPolicies
- Cluster-/Storage-Risiken aus Kubernetes-Sicht

## P0 — Sofort zu klärende Plattformrisiken

### 1. DMZ-Exposure administrativer Dienste prüfen

Bekannte/zu prüfende Dienste:
- Argo CD: `argocd.cattaro.eu` -> K3s/Ingress
- Kubernetes Dashboard: Namespace `kubernetes-dashboard`, NodePort sichtbar in Inventur
- Portainer: Namespace `portainer`, NodePort/ServiceLB sichtbar
- Longhorn UI: Namespace `longhorn-system`
- Nginx Proxy Manager UI auf Reverse Proxy `192.168.20.20:81`
- später Infisical: bevorzugt nicht in DMZ, sondern Synology/Intranet-Pilot

Ziel:
- keine breit öffentliche Admin-UI
- Zugriff nur Intranet/VPN/ZTNA/IP-Allowlist
- dokumentierte Proxy-/Firewall-Regeln
- klare Owner je Admin-Dienst

### 2. Argo CD Risikostand

Ist-Zustand aus Inventur:
- Argo CD läuft in `infra-argocd`
- mehrere Applications nutzen Project `default`
- einige Apps melden `Unknown`, u.a. wegen Git-Auth-Problemen
- Mandantentrennung über AppProjects noch nicht sauber sichtbar

Risiko:
- Default-Project kann zu breit sein
- Mandanten-Apps und Platform-Apps sind nicht ausreichend getrennt
- Git-Auth/Token-Thema passt direkt zur Infisical-/Secrets-Roadmap

Ziel:
- `platform-*` AppProjects
- `tenant-cattaro`
- `tenant-pidoka` / `tenant-heckenfels` oder sauberer Firmen-/Mandantenname festlegen
- keine Mandantenproduktion im Argo-CD-Default-Project

### 3. K3s / Node / Longhorn Risiken

Bekannt:
- 2 Nodes: `192.168.20.40` control-plane, `192.168.20.45` worker
- K3s-Versionen uneinheitlich: v1.28.4 vs v1.29.3
- Longhorn 3 Replicas bei nur 2 Nodes -> dauerhaft degraded
- Backup Target für Longhorn war leer/nicht verfügbar

Ziel:
- Backup/Restore vor Storage-Änderungen klären
- K3s Upgrade-Pfad definieren
- Longhorn Replica-Konzept festlegen
- dritter Node bzw. Intranet-Management-Node planen

## P1 — Zielstruktur GitOps / Mandanten

### Namespaces Zielbild

Platform:
- `platform-argocd`
- `platform-ingress`
- `platform-secrets`
- `platform-monitoring`
- `platform-logging`
- `platform-backup`
- `platform-storage`

Mandanten:
- `tenant-cattaro-stage`
- `tenant-cattaro-prod`
- `tenant-pidoka-stage` oder `tenant-heckenfels-stage`
- `tenant-pidoka-prod` oder `tenant-heckenfels-prod`

Offene Entscheidung:
- Mandantenname für heckenfels.com/Pidoka sauber festlegen: `pidoka` vs `heckenfels`.

### Argo CD AppProjects Zielbild

Platform:
- `platform-core`
- `platform-network`
- `platform-security`
- `platform-observability`

Tenant:
- `tenant-cattaro`
- `tenant-pidoka` / `tenant-heckenfels`

Grundregeln:
- Tenant-Projekte dürfen nur eigene Namespaces deployen.
- Cluster-scoped Ressourcen nur Platform-Projekten erlauben.
- Repos pro Projekt begrenzen.
- Produktionssyncs mit klarer Approval-Regel.

### GitOps Repo-Struktur — Vorschlag

Variante A: ein Plattform-Repo mit klaren Verzeichnissen

```text
platform-gitops/
  clusters/
    dmz-k3s/
      platform/
      tenants/
        cattaro/
        pidoka/
  projects/
    platform-core/
    tenant-cattaro/
    tenant-pidoka/
  apps/
    platform/
    tenants/
  charts/
  docs/
```

Variante B: getrennte Repos

```text
platform-gitops-infra/
tenant-cattaro-gitops/
tenant-pidoka-gitops/
```

Empfehlung:
- Kurzfristig Variante A wegen kleiner Umgebung und besserer Übersicht.
- Später bei echten DevSecOps-Teams ggf. Mandanten-/Team-Repos trennen.

## P1 — DevSecOps Request Templates

Benötigte Templates:
- Service-Onboarding
- Namespace/AppProject Request
- Secret/Infisical Request
- Ingress/DNS Request
- Storage/PVC Request
- Backup/Restore Request
- Production Change Request
- Incident Report / Post-Incident Review

## Nächste kube-bot Schritte

1. DMZ-Exposure-Matrix aus vorhandener Inventur detaillieren.
2. Argo-CD-AppProject-Zieldefinition ausarbeiten.
3. GitOps-Repo-Struktur als konkreten Vorschlag formulieren.
4. Request-Templates als Markdown-Entwürfe erstellen.

Keine Umsetzung ohne explizites OK.

## Entscheidung — Mandantenname Pidoka

Entscheidung durch Mislav am 2026-06-11:
- Für heckenfels.com/Pidoka-Bereich wird `pidoka` als Mandantenname verwendet.

Standard:
- Namespaces: `tenant-pidoka-stage`, `tenant-pidoka-prod`
- Argo-CD-AppProject: `tenant-pidoka`
- Infisical-Projekt: `tenant-pidoka`
- Labels: `tenant: pidoka`, `owner: pidoka`

Begründung:
- Pidoka ist die organisatorische/rechtliche Einheit; heckenfels.com ist Domain-/Service-Kontext.

## P0.1 Ergebnis — DMZ-Exposure administrativer Dienste

Stand: 2026-06-11, read-only geprüft durch kube-bot.

### Befund

Administrativ relevante Dienste sind innerhalb der DMZ direkt über NodePorts/LoadBalancer-Ports auf beiden K3s-Nodes erreichbar:

- Portainer UI
  - Service: `portainer/portainer`
  - Type: `LoadBalancer`
  - IPs: `192.168.20.40`, `192.168.20.45`
  - Ports: `30777/http`, `30779/https`, `30776/edge`
  - Test: Ports offen, UI liefert HTTP 200

- Kubernetes Dashboard
  - Service: `kubernetes-dashboard/kubernetes-dashboard`
  - Type: `NodePort`
  - Port: `31351/https`
  - Test: Port offen, UI liefert HTTP 200

- Keycloak
  - Service: `keycloak/keycloak`
  - Type: `LoadBalancer`, EXTERNAL-IP pending, aber NodePort `32184/http`
  - Test: Port offen, UI liefert HTTP 200
  - Zusätzlich `svclb-keycloak` war in früherer Inventur auffällig/pending.

- Argo CD
  - Service: `infra-argocd/argocd-server` ClusterIP
  - Ingress: `argocd.cattaro.eu` über Traefik
  - Traefik LoadBalancer: `192.168.20.40/45`, NodePorts `31797/http`, `30508/https`
  - Extern über `https://argocd.cattaro.eu` erreichbar, HTTP 200.

- Longhorn UI
  - Service: `longhorn-system/longhorn-frontend`
  - Type: ClusterIP
  - Kein direkter NodePort/Ingress gefunden.
  - Bewertung: besser als Portainer/Dashboard; weiterhin intern schützen.

### Risiko

In einer DMZ sind direkt erreichbare Admin-UIs riskant, selbst wenn sie nur intern/über Firewall erreichbar sind. Besonders kritisch:

1. Portainer: Container-/Kubernetes-Verwaltung, potentiell hoher Impact.
2. Kubernetes Dashboard: direkter Cluster-Admin-/Token-Bezug möglich.
3. Argo CD: Deployment-Kontrolle; sollte langfristig Management-Zone/Intranet werden.
4. Keycloak: Identitätsdienst, öffentlich/interner Scope muss geklärt werden.

### Empfohlene Maßnahmen ohne direkte Umsetzung

P0-a:
- Mit OPNsense/Nginx Proxy Manager abgleichen, welche dieser Ports aus welchen Netzen erreichbar sind.
- Extern/Internet darf kein direkter Zugriff auf NodePorts bestehen.

P0-b:
- Kubernetes Dashboard nicht per NodePort offen halten; bevorzugt nur temporär via `kubectl proxy`/Port-forward/VPN oder intern streng begrenzt.

P0-c:
- Portainer Zugriff auf VPN/ZTNA/Intranet/IP-Allowlist begrenzen; Edge-Port 30776 prüfen, ob benötigt.

P0-d:
- Argo CD UI/API Zugriff einschränken; langfristig in Intranet/Management-Zone ziehen.

P0-e:
- Keycloak Scope klären: produktiver IdP vs Legacy/Test. Falls nicht benötigt, Exposition reduzieren.

### Keine Änderungen durchgeführt

Alle Checks waren read-only. Keine Services, Ingresses, Firewall-Regeln oder Deployments wurden geändert.

## P0.2 Ergebnis — Proxy-/DMZ-Sicht und Backup-/Intranet-Grenze

Stand: 2026-06-11, read-only geprüft.

### Proxy Host 192.168.20.20 / raspi

Host-/Port-Sicht:
- `80/tcp`, `443/tcp`: Nginx Proxy Manager Frontend
- `81/tcp`: Nginx Proxy Manager Management UI
- `8000/tcp`, `9000/tcp`: Portainer/Portainer Agent Docker-Ports auf dem Proxyhost

Risiko:
- Nginx Proxy Manager UI (`81`) und Portainer (`9000/8000`) sind Management-Oberflächen auf dem Reverse-Proxy-Host.
- Diese sollten nicht öffentlich erreichbar sein und möglichst nur über Intranet/VPN/ZTNA/IP-Allowlist zugänglich sein.


Der lokale Handoff enthält bereits einen Eintrag von gestern Abend zur Zammad-Longhorn-Migration. Ich lese den restlichen Abschnitt und die betroffenen Inventar-/Backup-Notizen, damit ich den Tagesstand sauber zusammenfasse.


sed -n '1,260p' backup-plans/longhorn-restore-return-path-addendum.md


sed -n '1,260p' backup-plans/longhorn-restore-test-kube-review.md


rg -n "2026-06-17|Zammad|Longhorn|morgen|heute|offen|Needs|OK|n8n|Infisical" -S . --glob '!camofox-browser/node_modules/**' --glob '!repos/**'


Output:
Chunk ID: cc609d
Wall time: 0.0000 seconds
Process exited with code 0
Original token count: 4016
Output:
  - `data-zammad-elasticsearch-master-0`
  - `redis-data-zammad-redis-master-0`
  - `zammad-var-zammad-0`
- GitOps-Commits:
  - `1e74cfd Prepare Zammad Longhorn storage migration`
  - `669b006 Pin Zammad workloads during Longhorn migration`
- Wichtiger Zwischenfall:
  - Erste PostgreSQL-Tar-Copy erzeugte auf dem Ziel ein defektes/0-Byte `PG_VERSION`; erkannt durch PostgreSQL-Startfehler.
  - PostgreSQL-Daten wurden danach kalt mit `cp -a /old/. /new/` neu kopiert; `PG_VERSION=15` und Start anschließend OK.
- Weiterer Befund:
  - Worker `mini-it13-02` konnte alte Bitnami-Image-Tags nicht pullen (`not found`).
  - Zammad Workloads wurden deshalb live und in GitOps per `nodeSelector` auf `mbrkanov-mini-it13` gepinnt, bis Image-Strategie aktualisiert ist.
- Abschlussprüfung:
  - Pods: `zammad-0` 4/4 Running, PostgreSQL/Redis/Elasticsearch/Memcached Running, alle ohne Restarts seit Migration.
  - Laufende Pods mounten die neuen Longhorn-Claims.
  - Longhorn meldet alle vier neuen Volumes `attached` / `healthy`.
  - Datenzählung unverändert: 370 Users, 393 Tickets, 1182 Ticket-Artikel, 4 Organisationen.
  - Letzte Ticket-/Artikel-Updates: 2026-06-17 19:10 UTC.
  - Extern: `https://service.heckenfels.com/` HTTP 200.
  - ArgoCD IT15: `pidoka-hf-zammad` und `pidoka-hf-zammad-secrets` beide `Synced/Healthy` auf Revision `669b0061283f5f7c3ccba9594bcadb14a9db38dd`.
- Empfehlung:
  - Alte local-path PVCs mindestens über eine Beobachtungsphase behalten.
  - Als nächstes Image-Tags/Registry-Strategie für die alten Bitnami-Images bereinigen, damit der nodeSelector wieder entfernt und Scheduling-Flexibilität wiederhergestellt werden kann.

## Altes ArgoCD Repo Audit — 2026-06-15 19:15 UTC

- Audit gestartet nach Mislavs Hinweis auf mögliche Passwörter/Tokens und uneinheitliche ArgoCD-YAML-Struktur.
- Repo geklont: `GitMasterOne/ArgoCD`, Branch `main`, Commit `8882e3c3a9f0414c0fa9f22772a798f1c2be8155`.
- Audit-Dokument: `/home/node/.openclaw/workspace/audits/argocd-repo-20260615/README.md`.
- Befund:
  - Apps sind uneinheitlich modelliert: App-of-apps, externes Helm Chart, lokale Charts, inline `values`, `valuesObject`, `valueFiles`.
  - Passwort-Verdachtsstellen in `espocrm/values*.yaml` und `charts/suitecrm/values.yaml`; keine Secretwerte in Summary ausgegeben.
  - `n8n` ist sauberster erster Migrationskandidat: externes Helm Chart, Secrets über `n8n-secret` referenziert, PVC Longhorn 5Gi, Ingress `n8n.heckenfels.com`.
- Achtung: Eine erste Live-Secret-Abfrage gab Base64-Werte aus; die persistente Datei wurde sofort sanitisiert und enthält nur Secret-/Key-Namen. Künftig bei Secrets nur JSON/Python-Auswertung mit Key-Namen nutzen, niemals `.data` roh ausgeben.
- Empfehlung: altes Repo nicht direkt reorganisieren; App-für-App neu in `platform-gitops` modellieren. Nächster Schritt: n8n-Migrationsmanifest in `platform-gitops` vorbereiten, aber Cutover/Synchronisation nur mit explizitem OK.

## Vertiefung altes ArgoCD Repo — Git-History Scan — 2026-06-15 19:26 UTC

- Git-History Scan ergänzt: `/home/node/.openclaw/workspace/audits/argocd-repo-20260615/git-history-secret-scan-summary.md`.
- 174 Commits gescannt, 102 maskierte eindeutige Verdachtsfunde.
- Keine GitHub PATs/Private Keys/JWTs gefunden, aber viele Passwort-/Secret-Key-Felder in aktuellen und historischen Dateien.
- Konsequenz: altes Repo samt History als secret-belastet behandeln; nicht in neues Repo übernehmen; betroffene Passwörter perspektivisch rotieren.
- Normalisierungsziel für neues `platform-gitops` dokumentiert: pro App `application.yaml`, `values.yaml`, `external-secrets.yaml`, optional `kustomization.yaml`, `README.md`; keine inline Secretwerte; keine History-Übernahme.
- Nächster sicherer Schritt: für `n8n` Zielstruktur in `platform-gitops` vorbereiten und Secretstrategie definieren. Noch kein Sync/Cutover ohne explizites OK.

## DMZ Infisical via IT15 ArgoCD deployed — 2026-06-15 20:56 UTC

- Architekturentscheidung umgesetzt: DMZ-lokales Infisical statt Firewall-Öffnung DMZ -> IT15.
- GitOps Repo `GitMasterOne/platform-gitops` aktualisiert:
  - Commit `06a7f5c`: `Add DMZ Infisical platform app`
  - Commit `58d807d`: `Allow guestbook demo repo for Cattaro tenant project`
- Neue ArgoCD Application: `platform-infisical-dmz` im Project `platform`.
- Helm Chart: `infisical-standalone` `1.9.0`, Image `infisical/infisical:v0.158.0`.
- Namespace: `platform-infisical`.
- Exposure: nur `ClusterIP`, kein Ingress, kein Public/NPM-Exposure.
- Storage: Longhorn PVCs:
  - PostgreSQL `8Gi`: `data-postgresql-0`
  - Redis `2Gi`: `redis-data-redis-master-0`
- Initial runtime secrets wurden direkt im DMZ-K3s erstellt und NICHT ins Git geschrieben:
  - `infisical-secrets`
  - `postgresql`
  - `redis`
- ArgoCD DMZ Cluster Credential korrigiert:
  - gemeinsamer ServiceAccount `platform-infisical/argocd-dmz-manager`
  - RoleBindings in `platform-infisical` und `tenant-cattaro-stage`
  - ArgoCD Cluster Secret `dmz-k3s-tenant-cattaro-stage` nutzt jetzt den gemeinsamen Token und Namespaces `tenant-cattaro-stage,platform-infisical`
  - temporäres Cluster Secret `dmz-k3s-platform-infisical` wurde gelöscht
- Verification:
  - `platform-infisical` Pods: Infisical/PostgreSQL/Redis Running
  - `/api/status` cluster-intern: `Ok`, `redisConfigured=true`, `inviteOnlySignup=true`
  - IT15 ArgoCD Apps final: `platform-infisical-dmz`, `demo-guestbook-cattaro-stage`, `platform-argocd-projects` alle `Synced/Healthy`
- Auffälligkeit: Infisical-App hatte beim ersten Start 3 Restarts, weil PostgreSQL noch initialisierte. Danach stabil und healthy.
- Nächste Schritte:
  1. Admin-Erstzugang/Bootstrap für DMZ-Infisical klären, vorzugsweise per Port-Forward, nicht öffentlich.
  2. Initial runtime secrets (AUTH_SECRET, ENCRYPTION_KEY, DB/Redis) sicher sichern/Recovery-Konzept festlegen. Aktuell nur in Kubernetes Secrets/PVCs, nicht in Infisical/Markdown.
  3. Backup/Restore-Konzept für DMZ-Infisical PostgreSQL/Longhorn definieren.
  4. Danach Infisical Operator/External Secret Integration für n8n vorbereiten.

## Tagesabschluss / Wiedereinstieg morgen — DMZ Infisical — 2026-06-15 21:39 UTC

### Aktueller verifizierter Zustand

- IT15 ArgoCD:
  - `platform-infisical-dmz`: `Synced / Healthy`
  - `demo-guestbook-cattaro-stage`: `Synced / Healthy`
  - `platform-argocd-projects`: `Synced / Healthy`
- DMZ K3s Namespace: `platform-infisical`
  - Infisical Pod: `1/1 Running`, neuer Pod ohne Restarts beim letzten Check
  - PostgreSQL: `1/1 Running`
  - Redis: `1/1 Running`
  - PVCs: Longhorn `Bound`
- Cluster-interner Healthcheck:
  - `GET http://infisical-infisical-standalone-infisical:8080/api/status`
  - Antwort: `message=Ok`, `redisConfigured=true`, `inviteOnlySignup=true`
- Exposure:
  - Nur `ClusterIP`
  - Kein Ingress
  - Keine Firewall-Öffnung
  - Kein öffentliches/NPM Exposure

### Was heute geändert wurde

- DMZ-lokales Infisical per IT15-ArgoCD eingeführt.
- GitOps Repo `GitMasterOne/platform-gitops`:
  - Commit `06a7f5c`: `Add DMZ Infisical platform app`
  - Commit `58d807d`: `Allow guestbook demo repo for Cattaro tenant project`
- ArgoCD DMZ Cluster Credential korrigiert:
  - ein gemeinsamer namespace-beschränkter ServiceAccount für `tenant-cattaro-stage` und `platform-infisical`
  - keine Cluster-weiten Adminrechte für diesen Flow dokumentiert
- Initial runtime Kubernetes Secrets in `platform-infisical` erzeugt:
  - `infisical-secrets`
  - `postgresql`
  - `redis`
- Keine Secretwerte ins Git oder in Markdown geschrieben.

### Sicherheits-/Betriebsnotizen

- Aktuell ist DMZ-Infisical funktional, aber noch nicht produktionsfertig gebootstrappt.
- Kritischster offener Punkt: Recovery/Backup für Initial-Secrets und PostgreSQL/PVCs.
- Die Initial-Secrets existieren aktuell nur als Kubernetes Secrets im DMZ-Cluster; Werte nicht ausgeben.
- Erstzugang sollte nur temporär per Port-Forward erfolgen, nicht per Ingress/Public Exposure.
- `inviteOnlySignup=true`, also keine offene Registrierung.

### Morgen empfohlene Reihenfolge

1. Kurzstatus prüfen:
   - IT15 ArgoCD Apps `platform-infisical-dmz`, `platform-argocd-projects`, `demo-guestbook-cattaro-stage`
   - DMZ Pods/PVCs in `platform-infisical`
   - `/api/status`
2. Temporären Port-Forward für Mislav öffnen:
   - Von einem erreichbaren Rechner aus per SSH/Kubectl gegen DMZ Control Plane.
   - Ziel: lokaler Browser `http://localhost:<port>` -> Service `infisical-infisical-standalone-infisical:8080`.
   - Kein Firewall-Change, nur laufende Session.
3. Admin-Erstzugang/Bootstrap durchführen.
4. Direkt danach Recovery absichern:
   - Initial-Secrets sicher in IT15-Infisical oder anderem vereinbarten Recovery-Pfad ablegen.
   - Keine Secretwerte in Slack/Markdown posten.
5. Backup-Konzept für DMZ-Infisical festlegen:
   - mindestens PostgreSQL Dump oder Longhorn recurring snapshot/backup
   - Recovery-Probe planen
6. Danach erst Infisical Operator / Secret-Sync für `n8n` vorbereiten.

### Wenn morgen wenig Zeit ist

Minimal sicherer nächster Schritt:
- Nur Status prüfen + Port-Forward erklären/öffnen.
- Bootstrap/Recovery erst machen, wenn Mislav genug Zeit hat.

### Kurzbefehl-Idee für Status morgen

- IT15 ArgoCD App Status via WSL auf IT15.
- DMZ Status via SSH `kube-bot@192.168.20.40` und `/etc/rancher/k3s/k3s.yaml`.

## DMZ Infisical Bootstrap / kube-bot Machine Identity — 2026-06-16 18:33 UTC

- DMZ-Infisical ist temporär via Port-Forward erreichbar unter `http://192.168.20.40:18080`.
- Mislav hat Organisation und Projekt in DMZ-Infisical angelegt.
- DMZ-Infisical Projekt sichtbar für kube-bot:
  - Name: `platform-kubernetes`
  - ID: `d66f3d3b-1484-46f6-8142-f6fc32222b4d`
  - Slug: `platform-kubernetes-pqmd`
- Machine Identity in DMZ-Infisical:
  - Name: `kube-bot`
  - Client-ID: `9d47b9d2-c994-4449-afa1-5bbbf271eda0`
- Client Secret wurde nicht in Slack/Markdown ausgegeben.
- Recovery-/Bootstrap-Secrets liegen in IT15-Infisical:
  - Projekt: `platform-kubernetes` (`c5e8661f-4b7a-43e1-80b0-8674f30950dc`)
  - Environment: `prod`
  - Pfad: `/platform/kube-bot`
  - Secret-Namen: `DMZ_INFISICAL_KUBE_BOT_CLIENT_ID`, `DMZ_INFISICAL_KUBE_BOT_CLIENT_SECRET`, `DMZ_INFISICAL_URL`
- Verification: kube-bot Universal Auth Login gegen DMZ-Infisical erfolgreich; `/api/v1/projects` zeigt `platform-kubernetes`.
- Hinweis: Wunsch-Zielpfad `/platform/infisical/dmz/bootstrap` wurde noch nicht befüllt, weil die verfügbare API-Create-Route encrypted payload erwartet. Aktueller Pfad `/platform/kube-bot` ist funktional und verifiziert.

## Korrektur Tenant-Zuordnung — 2026-06-16 18:53 UTC

- Mislav hat klargestellt:  gehört fachlich zur **PIDOKA GmbH**, nicht zur Cattaro GmbH.
- Für n8n-GitOps ist daher das Ziel-AppProject/der Zielpfad  zu verwenden bzw. entsprechend zu erweitern.
- Bestehender Namespace ist aktuell ; fachliche Zielzuordnung: PIDOKA.

## Korrektur Tenant-Zuordnung — 2026-06-16 18:53 UTC

- Mislav hat klargestellt: n8n gehört fachlich zur **PIDOKA GmbH**, nicht zur Cattaro GmbH.
- Für n8n-GitOps ist daher das Ziel-AppProject/der Zielpfad `tenant-pidoka` zu verwenden bzw. entsprechend zu erweitern.
- Bestehender Namespace ist aktuell `hf-n8n`; fachliche Zielzuordnung: PIDOKA.

## PIDOKA n8n GitOps Vorbereitung — 2026-06-16 19:08 UTC

- Fachliche Korrektur: n8n gehört zur PIDOKA GmbH.
- Bestehendes n8n läuft in DMZ Namespace `hf-n8n` und wird aktuell noch vom alten DMZ-ArgoCD `infra-argocd/n8n` verwaltet.
- IT15-ArgoCD AppProject `tenant-pidoka` erlaubt bereits Zielnamespace `hf-n8n` und Source `8gears.container-registry.com`.
- Neue GitOps-Manifeste wurden im Repo `GitMasterOne/platform-gitops` vorbereitet und gepusht:
  - Commit: `8a58482 Add PIDOKA n8n GitOps migration manifest`
  - `applications/tenants/pidoka/n8n.yaml`
  - `tenants/pidoka/prod/n8n/values.yaml`
  - `tenants/pidoka/prod/n8n/README.md`
- Ziel der neuen App: IT15-ArgoCD Application `pidoka-n8n`, Project `tenant-pidoka`, Destination `https://192.168.20.40:6443`, Namespace `hf-n8n`.
- SyncPolicy der neuen App bewusst vorsichtig: `prune=false`, `selfHeal=false`.
- Kubernetes server-side dry-run auf IT15-ArgoCD war erfolgreich: `application.argoproj.io/pidoka-n8n created (server dry run)`.
- Noch nicht erledigt: IT15-ArgoCD Application tatsächlich anlegen/syncen; alter DMZ-ArgoCD-Controller wurde nicht verändert.
- Risiko: Zwei ArgoCD-Controller dürfen n8n nicht dauerhaft gleichzeitig verwalten. Cutover braucht explizites OK.

## PIDOKA n8n Cutover auf IT15-ArgoCD — 2026-06-16 19:28 UTC

- Freigabe durch Mislav: n8n direkt migrieren und danach ArgoCD UI bereitstellen.
- Neue IT15-ArgoCD Application: `pidoka-n8n`, Project `tenant-pidoka`.
- Ziel: DMZ `https://192.168.20.40:6443`, Namespace `hf-n8n`.
- GitOps Repo Commit-Stand:
  - `8a58482` initiale PIDOKA n8n Migration-Manifeste
  - `814792f` IT15-App auf manual sync gesetzt
  - `a10207a` Helm `releaseName: n8n`, damit bestehende Ressourcen übernommen statt neu erzeugt werden
- IT15-ArgoCD Cluster Secret `dmz-k3s-tenant-cattaro-stage` wurde um Namespace `hf-n8n` erweitert.
- DMZ RBAC namespace-scoped für ServiceAccount `platform-infisical/argocd-dmz-manager` in `hf-n8n` angelegt/erweitert.
- Alter DMZ-ArgoCD Application-Controller für n8n wurde entkoppelt:
  - `infra-argocd/n8n` Application gelöscht, vorher Backup auf DMZ Host: `/tmp/old-n8n-argocd-application-backup.yaml`
  - n8n-Ressourcen wurden nicht gelöscht/pruned.
- IT15-ArgoCD Status nach Cutover:
  - `pidoka-n8n`: `Synced / Healthy`
  - Ressourcen: ConfigMap/PVC/Service/ServiceAccount/Deployment/Ingress `n8n` in `hf-n8n` synced
- DMZ Live-Status nach Cutover:
  - Deployment `n8n`: `1/1`, Image `n8nio/n8n:1.122.4`
  - PVC `n8n`: Bound, Longhorn 5Gi
  - Ingress `n8n.heckenfels.com` unverändert
- Hinweis: IT15-ArgoCD zeigt noch `SharedResourceWarning` mit alter App-ID `n8n`; funktional ist die App grün. Ursache sind alte ArgoCD tracking/instance Cache-/Tracking-Reste aus der Übernahme.
- Temporärer IT15 ArgoCD UI Port-Forward läuft:
  - IT15 WSL PID: `892996`
  - URL aus Intranet voraussichtlich: `https://192.168.1.121:18081`
  - Kein Ingress/Public Exposure.

## Legacy DMZ-ArgoCD n8n Quelle entfernt — 2026-06-16 19:59 UTC

- Mislav gab grünes Licht, die alte n8n-Quelle im Legacy-DMZ-ArgoCD zu entschärfen.
- Im alten Repo `GitMasterOne/ArgoCD.git` wurde `applications/n8n.yaml` entfernt:
  - Commit: `f8a3e69 Remove n8n from legacy DMZ ArgoCD app-of-apps`
- Legacy Parent-App `infra-argocd/apps` wurde refreshed und ist danach `Synced / Healthy` auf Revision `f8a3e69`.
- Legacy `infra-argocd/n8n` Application ist danach absent.
- DMZ n8n Workloads blieben bestehen und healthy:
  - Deployment `hf-n8n/n8n`: `1/1`
  - PVC `hf-n8n/n8n`: Bound, Longhorn 5Gi
  - Ingress `n8n.heckenfels.com` unverändert
- IT15-ArgoCD `pidoka-n8n` bleibt `Synced / Healthy`.
- IT15-ArgoCD listet nur noch eine n8n-App: `pidoka-n8n`.
- Resthinweis: `pidoka-n8n` zeigt aktuell noch `SharedResourceWarning` mit alter App-ID `n8n`; keine zweite IT15-App existiert und Legacy-DMZ-App ist entfernt. Vermutlich stale resource-tracking/cache aus der Übernahme; funktional ist der Zustand grün.

## Recovery-Zwischenstand — PIDOKA HF Matomo Migration — 2026-06-17 11:04 UTC

Rekonstruiert aus lokalem Chat-/Sessionverlauf bis 2026-06-17 ca. 08:00 UTC. Dieser Abschnitt ist der aktuelle Wiedereinstiegspunkt nach Runtime-Abbruch.

### n8n Abschluss

- `n8n` gehört fachlich zur PIDOKA GmbH / HF-Servicegruppe.
- IT15-ArgoCD verwaltet n8n produktiv:
  - Application `pidoka-n8n`: zuletzt `Synced / Healthy`.
  - Application `pidoka-n8n-secrets`: nach Normalisierung ebenfalls `Synced / Healthy`.
- n8n Secret-Sync über ESO ist aktiv:
  - `ExternalSecret/hf-n8n/n8n-secret` Ready / SecretSynced.
  - `Deployment/hf-n8n/n8n` nutzt Secret-Refs für `N8N_BASIC_AUTH_USER`, `N8N_BASIC_AUTH_PASSWORD`, `N8N_ENCRYPTION_KEY`.
- Letzte relevante GitOps-Commits:
  - `559f471 Fix n8n chart extraEnv placement`
  - `48b5515 Normalize n8n ExternalSecret defaults`
- Keine Secretwerte wurden dokumentiert.


Output:
Chunk ID: 9e5b20
Wall time: 0.0000 seconds
Process exited with code 0
Original token count: 372
Output:
# Longhorn Restore-Test Addendum — Synology Return Path

Stand: 2026-06-09 12:18 UTC

## Erkenntnis
Longhorn sieht den Backupstand `backup-e4f3dcd9692e4f50` aktuell im bestehenden BackupTarget `/srv/longhorn-backup-staging`. Ein Restore daraus beweist den Longhorn-Restore aus dem DMZ-Staging, aber noch nicht den Rückweg aus der DiskStation-Kopie.

## Empfohlene Phasen

### Phase A — Restore aus aktuellem DMZ-Staging
Ziel: Prüfen, ob Longhorn aus dem aktuellen BackupTarget ein Test-Volume wiederherstellen kann.

Scope:
- isolierter Namespace, z. B. `restore-test-longhorn`
- Test-PVC/Test-Pod
- nur Mount/Dateisichtbarkeit
- keine App-Integration
- keine produktiven PVCs

Braucht explizites OK, weil Cluster-Schreibaktion.

### Phase B — Rückweg aus Synology-Kopie
Ziel: Prüfen, ob die von Synology gehaltene Kopie wieder als Longhorn-Backupquelle nutzbar gemacht werden kann.

Sicheres Prinzip:
- nicht den aktiven `/srv/longhorn-backup-staging/backupstore` überschreiben
- separate temporäre Restore-Staging-Quelle verwenden, z. B. neuer isolierter Pfad/Mount
- Synology kopiert Backupdaten in diesen separaten Pfad zurück
- Longhorn BackupTarget temporär oder testweise auf diesen separaten Pfad zeigen lassen

Braucht explizites OK, weil mehrere Schreib-/Konfigurationsaktionen beteiligt sind.

## Nicht tun
- Keine Synology-Rückkopie in das aktive Backupstore ohne Review.
- Kein Restore gegen produktive PVCs.
- Kein `--delete`.
- Keine Retention-Löschung.


Output:
Chunk ID: e80f02
Wall time: 0.0000 seconds
Process exited with code 0
Original token count: 493
Output:
# Longhorn Restore-Test — kube-bot Review

Stand: 2026-06-09 12:16 UTC

## Ziel
Nachweisen, dass aus dem von Synology gepullten Longhorn-Backupbestand ein nutzbares Test-Volume wiederhergestellt werden kann, ohne produktive PVCs oder Workloads zu verändern.

## Aktuell validiert
- Longhorn BackupTarget: `nfs://192.168.20.40:/srv/longhorn-backup-staging`, `available=true`
- Synology Pull: read-only NFS + `rsync -a --stats --exclude lost+found/`, kein `--delete`
- Letzter Sync: `STATUS=ok`, Source/Target exakt gleich
- Nodes Ready, Longhorn Manager Running
- Staging-Export für Synology: `192.168.13.10(ro,insecure,root_squash)`

## Restore-Test-Prinzip
1. Nicht gegen produktive Namespaces/PVCs testen.
2. Isolierten Namespace verwenden, z. B. `restore-test-longhorn`.
3. Test-PVC aus Longhorn-Backup wiederherstellen.
4. Nur lesenden/harmlosen Test-Pod starten, z. B. BusyBox/Alpine, um Mount und Dateien zu prüfen.
5. Ergebnis dokumentieren: PVC bound, Pod running/completed, erwartete Daten sichtbar.
6. Danach Testressourcen entfernen — Löschung ebenfalls nur mit explizitem OK, weil Cluster-Änderung.

## Wichtige offene Entscheidung vor Ausführung
- Welcher Backupstand wird getestet?
  - Kandidat: Testbackup `backup-e4f3dcd9692e4f50` von Volume `pvc-f6714be0-39b1-47e6-baa2-2e1ae801d907` (`hf-matomo/matomo-pvc`).
- Soll der Restore-Test nur Longhorn-Volume-Mount prüfen oder auch applikationsspezifische Konsistenz?
  - Empfehlung erster Lauf: nur Volume-Restore/Mount/Dateisichtbarkeit, keine App-Integration.

## Nicht ohne explizites OK
- Restore ausführen
- Namespace/PVC/Pod anlegen
- produktive PVCs verändern/überschreiben
- Longhorn Settings, Replica Counts, StorageClasses ändern
- Retention-Pruning oder `--delete`

## Empfehlung
Nächster sinnvoller Schritt ist Review des DiskStation-Restore-Testplans gegen diese Guardrails. Danach Mislav gezielt um OK für einen isolierten Restore-Test bitten, wenn er ihn ausführen möchte.


Output:
Chunk ID: 5adfc3
Wall time: 0.0001 seconds
Process exited with code 0
Original token count: 28525
Output:
Total output lines: 859

./SOUL.md:10:- Destructive Actions nur nach explizitem OK von Mislav
./backup-plans/longhorn-restore-return-path-addendum.md:1:# Longhorn Restore-Test Addendum — Synology Return Path
./backup-plans/longhorn-restore-return-path-addendum.md:6:Longhorn sieht den Backupstand `backup-e4f3dcd9692e4f50` aktuell im bestehenden BackupTarget `/srv/longhorn-backup-staging`. Ein Restore daraus beweist den Longhorn-Restore aus dem DMZ-Staging, aber noch nicht den Rückweg aus der DiskStation-Kopie.
./backup-plans/longhorn-restore-return-path-addendum.md:11:Ziel: Prüfen, ob Longhorn aus dem aktuellen BackupTarget ein Test-Volume wiederherstellen kann.
./backup-plans/longhorn-restore-return-path-addendum.md:20:Braucht explizites OK, weil Cluster-Schreibaktion.
./backup-plans/longhorn-restore-return-path-addendum.md:23:Ziel: Prüfen, ob die von Synology gehaltene Kopie wieder als Longhorn-Backupquelle nutzbar gemacht werden kann.
./backup-plans/longhorn-restore-return-path-addendum.md:29:- Longhorn BackupTarget temporär oder testweise auf diesen separaten Pfad zeigen lassen
./backup-plans/longhorn-restore-return-path-addendum.md:31:Braucht explizites OK, weil mehrere Schreib-/Konfigurationsaktionen beteiligt sind.
./backup-plans/longhorn-restore-test-kube-review.md:1:# Longhorn Restore-Test — kube-bot Review
./backup-plans/longhorn-restore-test-kube-review.md:6:Nachweisen, dass aus dem von Synology gepullten Longhorn-Backupbestand ein nutzbares Test-Volume wiederhergestellt werden kann, ohne produktive PVCs oder Workloads zu verändern.
./backup-plans/longhorn-restore-test-kube-review.md:9:- Longhorn BackupTarget: `nfs://192.168.20.40:/srv/longhorn-backup-staging`, `available=true`
./backup-plans/longhorn-restore-test-kube-review.md:12:- Nodes Ready, Longhorn Manager Running
./backup-plans/longhorn-restore-test-kube-review.md:18:3. Test-PVC aus Longhorn-Backup wiederherstellen.
./backup-plans/longhorn-restore-test-kube-review.md:21:6. Danach Testressourcen entfernen — Löschung ebenfalls nur mit explizitem OK, weil Cluster-Änderung.
./backup-plans/longhorn-restore-test-kube-review.md:23:## Wichtige offene Entscheidung vor Ausführung
./backup-plans/longhorn-restore-test-kube-review.md:26:- Soll der Restore-Test nur Longhorn-Volume-Mount prüfen oder auch applikationsspezifische Konsistenz?
./backup-plans/longhorn-restore-test-kube-review.md:29:## Nicht ohne explizites OK
./backup-plans/longhorn-restore-test-kube-review.md:33:- Longhorn Settings, Replica Counts, StorageClasses ändern
./backup-plans/longhorn-restore-test-kube-review.md:37:Nächster sinnvoller Schritt ist Review des DiskStation-Restore-Testplans gegen diese Guardrails. Danach Mislav gezielt um OK für einen isolierten Restore-Test bitten, wenn er ihn ausführen möchte.
./win-portproxy-final-8088.ps1:10:if (-not (Get-NetFirewallRule -DisplayName 'Infisical IT15 TCP 8088' -ErrorAction SilentlyContinue)) {
./win-portproxy-final-8088.ps1:11:  New-NetFirewallRule -DisplayName 'Infisical IT15 TCP 8088' -Direction Inbound -Action Allow -Protocol TCP -LocalPort 8088 -Profile Any | Out-Null
./wsl-real-restore-infisical.ps1:35:# normalize common Infisical mappings to 8088:8080
./run-final-backup-restore-test.sh:15:sed -n '1,120p' "$LATEST/manifest.txt" | sed -E 's/(PASSWORD|SECRET|KEY|TOKEN|AUTH|ENCRYPTION).*/[REDACTED]/I' || true
./win-check-open-8088.ps1:7:Get-NetFirewallRule -DisplayName '*Infisical*8088*' -ErrorAction SilentlyContinue | Select-Object DisplayName,Enabled,Direction,Action,Profile | Format-Table -AutoSize
./win-check-open-8088.ps1:9:if (-not (Get-NetFirewallRule -DisplayName 'Infisical IT15 TCP 8088' -ErrorAction SilentlyContinue)) {
./win-check-open-8088.ps1:10:  New-NetFirewallRule -DisplayName 'Infisical IT15 TCP 8088' -Direction Inbound -Action Allow -Protocol TCP -LocalPort 8088 -Profile Any | Out-Null
./win-check-open-8088.ps1:12:Get-NetFirewallRule -DisplayName 'Infisical IT15 TCP 8088' | Select-Object DisplayName,Enabled,Direction,Action,Profile | Format-Table -AutoSize
./IDENTITY.md:15:kube-bot führt keine eigenständigen Änderungen aus. Destructive Actions benötigen immer ein explizites OK von Mislav im Chat.
./wsl-fix-infisical-key.ps1:16:enc=secrets.token_hex(16)  # Infisical requires random 16-byte hex string (32 hex chars)
./INFISICAL_ARGO_K3S_KONZEPT.md:1:# Konzeptnotiz — Argo CD + K3s + Infisical
./INFISICAL_ARGO_K3S_KONZEPT.md:8:Argo CD steuert Deployments deklarativ aus Git. Infisical verwaltet Secrets zentral. K3s führt Workloads aus.
./INFISICAL_ARGO_K3S_KONZEPT.md:14:- eigenes Infisical-Projekt oder streng getrennte Infisical-Struktur pro Mandant
./INFISICAL_ARGO_K3S_KONZEPT.md:20:Empfohlene Regel: ein Mandant = ein Argo-CD-AppProject + ein Namespace-Set + ein Infisical-Projekt + eigene Sync-Identity.
./INFISICAL_ARGO_K3S_KONZEPT.md:24:Bestimmte Dienste wie Infisical, Argo CD, Ingress, Monitoring, Logging, Backup, Zertifikatsmanagement oder ggf. Registry/Storage werden mandantenübergreifend bereitgestellt.
./INFISICAL_ARGO_K3S_KONZEPT.md:69:## Infisical Struktur
./INFISICAL_ARGO_K3S_KONZEPT.md:71:### Infisical als Plattformdienst
./INFISICAL_ARGO_K3S_KONZEPT.md:78:### Infisical Projekte
./INFISICAL_ARGO_K3S_KONZEPT.md:101:- pro Mandant eigene Infisical Machine Identity
./INFISICAL_ARGO_K3S_KONZEPT.md:103:- pro Workload eigene ExternalSecret/InfisicalSecret Definition
./INFISICAL_ARGO_K3S_KONZEPT.md:105:- Rotation über Infisical, Reconcile über Operator
./INFISICAL_ARGO_K3S_KONZEPT.md:112:- Infisical Betrieb
./INFISICAL_ARGO_K3S_KONZEPT.md:120:- Zugriff auf eigene Infisical-Projekte
./INFISICAL_ARGO_K3S_KONZEPT.md:143:4. Infisical Projekt tenant-cattaro anlegen.
./INFISICAL_ARGO_K3S_KONZEPT.md:162:   - Mandantenübergreifende Infrastruktur wie Argo CD, Infisical, Ingress, cert-manager, Monitoring, Logging, Backup, Storage.
./INFISICAL_ARGO_K3S_KONZEPT.md:174:- Longhorn ist mit 3 Replicas konfiguriert, aber nur 2 Nodes vorhanden; Volumes dauerhaft degraded.
./INFISICAL_ARGO_K3S_KONZEPT.md:175:- Longhorn Backup Target war leer/nicht verfügbar.
./INFISICAL_ARGO_K3S_KONZEPT.md:180:- Infisical nicht öffentlich verfügbar machen, außer zwingend notwendig und dann nur mit starker Auth/MFA, IP-/VPN-Beschränkung und WAF/Proxy-Härtung.
./INFISICAL_ARGO_K3S_KONZEPT.md:192:- Infisical nur nach Backup/Restore-Konzept und möglichst mit externer/Longhorn-gesicherter Datenbank.
./INFISICAL_ARGO_K3S_KONZEPT.md:201:## Vorbereitende Aufgaben vor Infisical-Produktivbetrieb
./INFISICAL_ARGO_K3S_KONZEPT.md:203:1. Backup-Ziel für Longhorn/Infisical klären.
./INFISICAL_ARGO_K3S_KONZEPT.md:206:4. Longhorn Replica-Konzept für 2 oder 3 Nodes festlegen.
./INFISICAL_ARGO_K3S_KONZEPT.md:207:5. DMZ-Exposure für Argo CD, Infisical, Dashboard, Portainer prüfen.
./INFISICAL_ARGO_K3S_KONZEPT.md:210:8. Infisical-Projekte und Machine Identities mandantenscharf modellieren.
./INFISICAL_ARGO_K3S_KONZEPT.md:227:- Infisical
./INFISICAL_ARGO_K3S_KONZEPT.md:242:## Infisical-Variante
./INFISICAL_ARGO_K3S_KONZEPT.md:246:- Infisical läuft im Intranet.
./INFISICAL_ARGO_K3S_KONZEPT.md:247:- DMZ-Workloads erhalten keine breit berechtigten Infisical-Zugriffe.
./INFISICAL_ARGO_K3S_KONZEPT.md:269:## Ergänzung NAS-/Backup-Sicht: Sync-Richtung Infisical / DMZ
./INFISICAL_ARGO_K3S_KONZEPT.md:271:Wichtiger Architekturpunkt: Viele Secret-Operator-Modelle arbeiten als Pull aus dem Cluster. Wenn der Operator in der DMZ läuft und Infisical im Intranet steht, entsteht technisch DMZ -> Intranet Traffic. Das darf nicht unbewusst oder breit erlaubt werden.
./INFISICAL_ARGO_K3S_KONZEPT.md:278:Fallback-Variante, falls DMZ -> Infisical technisch nötig ist:
./INFISICAL_ARGO_K3S_KONZEPT.md:279:- ausschließlich HTTPS zur konkreten Infisical-Adresse
./INFISICAL_ARGO_K3S_KONZEPT.md:292:Stand: Es gibt aktuell keinen freien Intranet-Node für Infisical/Argo-CD-Management-Zone.
./INFISICAL_ARGO_K3S_KONZEPT.md:305:- Wenn DiskStation-Bot/NAS-Sicht keine harten Einwände hat, Infisical bevorzugt übergangsweise im Intranet auf der DiskStation betreiben.
./INFISICAL_ARGO_K3S_KONZEPT.md:316:- Einschätzung: geeignet als Übergang/Pilot für Infisical, nicht als dauerhafte Plattform-Zentrale.
./INFISICAL_ARGO_K3S_KONZEPT.md:319:- Infisical darf übergangsweise auf der Synology DiskStation im Intranet betrieben werden.
./INFISICAL_ARGO_K3S_KONZEPT.md:320:- Kein öffentlicher Zugriff auf Infisical.
./INFISICAL_ARGO_K3S_KONZEPT.md:328:Diese Übergangslösung ist sicherheitlich besser als Infisical in der DMZ, koppelt aber Secret-Management und NAS/Backup enger. Deshalb nur als Pilot/Übergang nutzen und bewusst klein halten.
./INFISICAL_ARGO_K3S_KONZEPT.md:346:- Erst read-only; Änderungen nur nach explizitem OK.
./INFISICAL_ARGO_K3S_KONZEPT.md:353:- Infisical, Secret-Rotation, Machine Identities, Zugriffspfade, Audit, MFA, Key-Lifecycle.
./INFISICAL_ARGO_K3S_KONZEPT.md:376:- Infisical-Projekte/Environments pro Mandant/App
./INFISICAL_ARGO_K3S_KONZEPT.md:398:- Änderungen nur mit explizitem OK von Mislav oder definiertem Owner
./INFISICAL_ARGO_K3S_KONZEPT.md:408:- secrets-bot: Infisical, Machine Identities, Rotation, Audit
./INFISICAL_ARGO_K3S_KONZEPT.md:413:Kein Bot darf alles. Standard ist lesend/prüfend. Schreibaktionen nur im eigenen Verantwortungsbereich; produktive/destruktive Aktionen nur mit explizitem OK.
./INFISICAL_ARGO_K3S_KONZEPT.md:418:- Infisical-Projekt
./INFISICAL_ARGO_K3S_KONZEPT.md:436:- Entscheidungsprotokolle, Architekturentscheidungen und offene Aufgaben nachhalten
./INFISICAL_ARGO_K3S_KONZEPT.md:443:- keine eigenständige technische Ausführung ohne Owner-OK
./INFISICAL_ARGO_K3S_KONZEPT.md:581:- später secrets-bot: Infisical, Rotation, Machine Identities, Audit
./INFISICAL_ARGO_K3S_KONZEPT.md:594:# Aktualisierung — 2026-06-14 — Organisationsgrenze Infisical
./INFISICAL_ARGO_K3S_KONZEPT.md:597:- Für Cattaro-Infrastruktur und Cattaro-Fachanwendungen wird in Infisical die Organisation `cattaro_gmbh` verwendet.
./INFISICAL_ARGO_K3S_KONZEPT.md:602:## Infisical
./INFISICAL_ARGO_K3S_KONZEPT.md:615:  - bevorzugt eigenes Infisical-Projekt `tenant-<mandant>` innerhalb einer passend verwalteten Organisation, falls Cattaro den Betrieb zentral verantwortet;
./INFISICAL_ARGO_K3S_KONZEPT.md:616:  - alternativ eigene Infisical-Organisation je externem Mandanten, wenn rechtliche/operative Trennung, Audit oder Admin-Delegation das erfordern.
./INFISICAL_ARGO_K3S_KONZEPT.md:649:- Kein globales Infisical-Token in Argo CD oder Workloads.
./INFISICAL_ARGO_K3S_KONZEPT.md:650:- Secrets bleiben in Infisical; Git enthält nur Referenzen/ExternalSecret-Definitionen.
./INFRASTRUCTURE.md:56:- n8n.heckenfels.com → https://192.168.20.40:443
./INFRASTRUCTURE.md:60:- Änderungen nur nach explizitem OK von Mislav pro konkreter Änderung.
./INFRASTRUCTURE.md:87:  - `n8n.heckenfels.com`
./INFRASTRUCTURE.md:98:  - Änderungen nur nach explizitem OK von Mislav
./INFRASTRUCTURE.md:114:- Änderungen über SSH nur nach explizitem OK von Mislav und mit konkretem Scope.
./INFRASTRUCTURE.md:116:- Offene Aufgabe: kube-bot/OpenClaw SSH-Private-Keys sicher in Infisical ablegen, damit sie nach OpenClaw-Updates nicht verloren gehen.
./INFRASTRUCTURE.md:125:- Änderungen an Backup-Konfigurationen nur nach explizitem OK von Mislav.
./INFRASTRUCTURE.md:148:- Betriebsregel bleibt: SSH primär read-only Diagnose; Änderungen nur nach explizitem OK von Mislav.
./INFRASTRUCTURE.md:157:### Infisical Recovery-Ablage — kube-bot SSH Keys — 2026-06-15 14:29 UTC
./INFRASTRUCTURE.md:159:- Infisical Instanz: `http://192.168.1.121:8088`.
./INFRASTRUCTURE.md:172:- Recovery-Prinzip: Private Key aus Infisical lesen, nach `/home/node/.ssh/kube-bot-it15-ed25519` schreiben, `chmod 600`, Fingerprint prüfen, SSH-Test ausführen.
./INFRASTRUCTURE.md:173:- Verifiziert: temporär aus Infisical gelesener Key konnte mit `chmod 600` für SSH auf `Misla@192.168.1.121` genutzt werden. Temporäre Datei wurde gelöscht.
./INFRASTRUCTURE.md:176:### Ergänzung Infisical — DMZ SSH Key-Namenssatz — 2026-06-15 14:35 UTC
./INFRASTRUCTURE.md:178:- Ergänzt im bestehenden Infisical-Pfad `platform-kubernetes/prod:/bots/kube-bot/ssh`:
./INFRASTRUCTURE.md:192:- Key: `/home/node/.ssh/kube-bot-it15-ed25519` bzw. Infisical `platform-kubernetes/prod:/bots/kube-bot/ssh/SSH_KEY_DMZ_PRIVATE`.
./INFRASTRUCTURE.md:206:### Ergänzung Infisical — Nginx/Raspi SSH Key-Namenssatz — 2026-06-15 15:16 UTC
./INFRASTRUCTURE.md:208:- Ergänzt im bestehenden Infisical-Pfad `platform-kubernetes/prod:/bots/kube-bot/ssh`:
./INFRASTRUCTURE.md:219:### DMZ Infisical — deployed via IT15 ArgoCD — 2026-06-15 20:56 UTC
./INFRASTRUCTURE.md:221:- Zweck: DMZ-lokaler Secret Store für K3s Workloads, ohne Firewall-Öffnung zur IT15-Infisical-Instanz.
./INFRASTRUCTURE.md:225:- Helm Chart: Infisical `infisical-standalone` `1.9.0`, Image `infisical/infisical:v0.158.0`.
./INFRASTRUCTURE.md:227:- Storage: Longhorn PVCs für PostgreSQL 8Gi und Redis 2Gi.
./install-socat-infisical-proxy.sh:18:Description=Infisical WSL TCP proxy 8088 to Docker localhost 18080 via socat
./setup-infisical-wsl-proxy.sh:57:Description=Infisical WSL TCP proxy 8088 to Docker localhost 18080
./read-backup-status.sh:11:  [ -f "$d/manifest.txt" ] && { echo 'manifest:'; sed -n '1,80p' "$d/manifest.txt" | sed -E 's/(PASSWORD|SECRET|KEY|TOKEN|AUTH|ENCRYPTION).*/[REDACTED]/I'; }
./check-wsl-network-infisical.sh:11:  curl -fsS --max-time 3 "http://$h:8088/api/status" >/tmp/curl.out 2>/tmp/curl.err && echo OK || { echo FAIL; cat /tmp/curl.err; }
./win-portproxy-final-8088-v3.ps1:14:if (-not (Get-NetFirewallRule -DisplayName 'Infisical IT15 TCP 8088' -ErrorAction SilentlyContinue)) {
./win-portproxy-final-8088-v3.ps1:15:  New-NetFirewallRule -DisplayName 'Infisical IT15 TCP 8088' -Direction Inbound -Action Allow -Protocol TCP -LocalPort 8088 -Profile Any | Out-Null
./win-portproxy-final-8088-v3.ps1:17:Get-NetFirewallRule -DisplayName 'Infisical IT15 TCP 8088' | Select DisplayName,Enabled,Direction,Action,Profile | Format-Table -AutoSize
./spikes/infisical-dmz/dmz-helm-chart-info.txt:2:infisical-helm-charts/infisical               	0.4.2        	1.17.0     	A helm chart for a full Infisical application
./spikes/infisical-dmz/dmz-helm-chart-info.txt:3:infisical-helm-charts/infisical               	0.4.1        	1.17.0     	A helm chart for a full Infisical application
./spikes/infisical-dmz/dmz-helm-chart-info.txt:4:infisical-helm-charts/infisical               	0.4.0        	1.17.0     	A helm chart for a full Infisical application
./spikes/infisical-dmz/dmz-helm-chart-info.txt:5:infisical-helm-charts/infisical               	0.3.5        	1.17.0     	A helm chart for a full Infisical application
./spikes/infisical-dmz/dmz-helm-chart-info.txt:6:infisical-helm-charts/infisical               	0.3.4        	1.17.0     	A helm chart for a full Infisical application
./spikes/infisical-dmz/dmz-helm-chart-info.txt:7:infisical-helm-charts/infisical               	0.3.3        	1.17.0     	A helm chart for a full Infisical application
./spikes/infisical-dmz/dmz-helm-chart-info.txt:8:infisical-helm-charts/infisical               	0.3.2        	1.17.0     	A helm chart for a full Infisical application
./spikes/infisical-dmz/dmz-helm-chart-info.txt:9:infisical-helm-charts/infisical               	0.3.1        	1.17.0     	A helm chart for a full Infisical application
./spikes/infisical-dmz/dmz-helm-chart-info.txt:10:infisical-helm-charts/infisical               	0.3.0        	1.17.0     	A helm chart for a full Infisical application
./spikes/infisical-dmz/dmz-helm-chart-info.txt:11:infisical-helm-charts/infisical               	0.2.1        	1.17.0     	A helm chart for a full Infisical application
./spikes/infisical-dmz/dmz-helm-chart-info.txt:12:infisical-helm-charts/infisical               	0.1.17       	1.17.0     	A helm chart for a full Infisical application
./spikes/infisical-dmz/dmz-helm-chart-info.txt:13:infisical-helm-charts/infisical               	0.1.16       	1.17.0     	A helm chart for a full Infisical application
./spikes/infisical-dmz/dmz-helm-chart-info.txt:14:infisical-helm-charts/infisical               	0.1.15       	1.17.0     	A helm chart for a full Infisical application
./spikes/infisical-dmz/dmz-helm-chart-info.txt:15:infisical-helm-charts/infisical               	0.1.14       	1.17.0     	A helm chart for a full Infisical application
./spikes/infisical-dmz/dmz-helm-chart-info.txt:16:infisical-helm-charts/infisical               	0.1.13       	1.17.0     	A helm chart for a full Infisical application
./spikes/infisical-dmz/dmz-helm-chart-info.txt:17:infisical-helm-charts/infisical               	0.1.12       	1.17.0     	A helm chart for a full Infisical application
./spikes/infisical-dmz/dmz-helm-chart-info.txt:18:infisical-helm-charts/infisical               	0.1.11       	1.17.0     	A helm chart for a full Infisical application
./spikes/infisical-dmz/dmz-helm-chart-info.txt:19:infisical-helm-charts/infisical               	0.1.10       	1.17.0     	A helm chart for a full Infisical application
./spikes/infisical-dmz/dmz-helm-chart-info.txt:20:infisical-helm-charts/infisical               	0.1.9        	1.17.0     	A helm chart for a full Infisical application
./spikes/infisical-dmz/dmz-helm-chart-info.txt:21:infisical-helm-charts/infisical               	0.1.8        	1.17.0     	A helm chart for a full Infisical application
./spikes/infisical-dmz/dmz-helm-chart-info.txt:22:infisical-helm-charts/infisical               	0.1.6        	1.16.0     	A helm chart for a full Infisical application
./spikes/infisical-dmz/dmz-helm-chart-info.txt:23:infisical-helm-charts/infisical               	0.1.5        	1.16.0     	A helm chart for a full Infisical application
./spikes/infisical-dmz/dmz-helm-chart-info.txt:24:infisical-helm-charts/infisical               	0.1.4        	1.16.0     	A helm chart for a full Infisical application
./spikes/infisical-dmz/dmz-helm-chart-info.txt:25:infisical-helm-charts/infisical               	0.1.3        	1.16.0     	A helm chart for a full Infisical application
./spikes/infisical-dmz/dmz-helm-chart-info.txt:26:infisical-helm-charts/infisical               	0.1.2        	1.16.0     	A helm chart for a full Infisical application
./spikes/infisical-dmz/dmz-helm-chart-info.txt:27:infisical-helm-charts/infisical               	0.1.1        	1.16.0     	A helm chart for a full Infisical application
./spikes/infisical-dmz/dmz-helm-chart-info.txt:28:infisical-helm-charts/infisical               	0.1.0        	1.16.0     	A helm chart for a full Infisical application
./spikes/infisical-dmz/dmz-helm-chart-info.txt:29:infisical-helm-charts/infisical-agent-injector	0.1.12       	0.1.12     	A Helm chart for Infisical Kubernetes Agent Inj...
./spikes/infisical-dmz/dmz-helm-chart-info.txt:30:infisical-helm-charts/infisical-agent-injector	0.1.11       	0.1.11     	A Helm chart for Infisical Kubernetes Agent Inj...
./spikes/infisical-dmz/dmz-helm-chart-info.txt:46:description: A helm chart to deploy Infisical
./spikes/infisical-dmz/dmz-helm-chart-info.txt:58:  # -- Enable Infisical chart deployment
./spikes/infisical-dmz/dmz-helm-chart-info.txt:64:    # -- Enable auto-bootstrap of the Infisical instance
./spikes/infisical-dmz/dmz-helm-chart-info.txt:68:      # -- Infisical Infisical CLI image tag version
./spikes/infisical-dmz/dmz-helm-chart-info.txt:81:    # -- Infisical organization to create in the Infisical instance during auto-bootstrap
./spikes/infisical-dmz/dmz-helm-chart-info.txt:105:  # -- Override for the full name of Infisical resources in this deployment
./spikes/infisical-dmz/dmz-helm-chart-info.txt:107:  # -- Custom annotations for Infisical pods
./spikes/infisical-dmz/dmz-helm-chart-info.txt:109:  # -- Custom annotations for Infisical deployment
./spikes/infisical-dmz/dmz-helm-chart-info.txt:115:    # -- Image repository for the…18525 tokens truncated…d57jvTyVEzG6XACx4yn0n2ZY88fPGERir1FHrj65wSPUDDiuz+eaWTWvgVf1xEQFlYxwqa61XMfEOkd9M8jskUGK8kUptR0ausLzsNobfaoIWsUjiAs0ZR6yH48Auqq+T/tZ7W8vFvcLtcQQcVUGaZmSZJAHZ2lLC/mv12vWklJ3Pz6Z5lX16v13WJ5u75tZa4vF//OeXvFJudm0V5vkMTpKB5MpvFgMoZ6E4Es2H2IOKb5Dl1/r6S16Hoqz6okTuMUTjmLUqmFUZIfIIOb7dzQwqFHTfDckyrvEbe9Zh9RQ/aRrGfuFsYRZCEewc54ao+7MZwhw416ImATgUNvSscxtFMQEXnpJB0ujSZ8oKYNmWW5VJIkHntOCMh+wPx6fXdx9e1mDpu6DjR9QMM0HX2yhi9W/DINwz7e0jBNR2caNuNujK/VcPrp9/Dlil+l4fSdezh9cQ+nHfdw+n/fw01nqT94Tsq3pdVIsbRVGkt7tzXuJ3OiTSjUm2YX7S/4vGWVEAEZhe7pSRS+4dstcoIM5mbFdyhKFZx8j4HYYPM9ZxTGwUGdRkIfDKVgno7vGBuwmjfA9YP05BvF/wvkybx6VjGNryIfMS6dJMmZuhDCaH+r1aG7YBP8rbSCEa7IMcL7Q6A1eKTU99+bwNH7H75rVjGpWK4QskFw94MNrC3Pchu/JEZloyQvnUNN87LI0T0dVECWRCDQS4eiK6SbuW/S+47pJTJxgCyp678DAAD//0x/7KHyCgAA",
./inventory/k8s-objects.json:15825:                    "objectset.rio.cattle.io/applied": "H4sIAAAAAAAA/7xUT2/jthP9Kj/MWZbl9Z+NCfwOQRIUQbuOYXt7WRjBiBrFrCmSIEfauIG+e0HZSZWukw16KHwwyHnzNHzzZp4AnfqdfFDWgAB0LgybESSwV6YAAddIlTVrYkigIsYCGUE8ARpjGVlZE+LR5n+Q5ECcemVTicyaUmWHKnJA8mbcfjfkBw/NHgQMm1Hyv1+VKf6/Jt8oST/NM1gRCPgTqwqLD6GDQ9lLaROQnrpnbFRFgbFyIEytdQIac9LvPm6HYQcCZkjzyaik2UjOJqNins/LXI7zSYafxvNpdjGV0/kMy1hgaKS0hr3Vmny6H4cem7EFBdIk2XoQUKIO9JOU0Mh/SvAB+I8anEhCI3U+OF4PPstpOSs/f4Jj+DlpX+c0CIfAVMXM4EhGif4u/AkqZLn77UU9dO5N7rZNgKlyGpm61J7DPtCY96j/C+V6AmDNtrK14ZN3L6WMp43dkwHRNTOByI/KkA8gvj0Bmab7P1WyXl3dL+9WG0igQV3Hq4vsIoM2eQVZXS5+uVn3QFna/YavkNc36839cnW3ueshN1fLHzHvf7HD3C773xtl6WScjrJpOr6AdpuAqvAhBjwauSM/3GvlHPmBzkWTpZN0AifMstZ6abWSBxBwWy4sLz0FMgwvHtT5gKUbdGUk4Kzno1Yv0i2tZxAxnsDOBu6fz3N4y1Za/fz+bQKegq29pGii2EOStVd8uLKG6ZE786HDXGnFio5OKwoQ32Bxs7m/vP5yu4Bt20amM6nhECTr0O+sIU6Vayapcvel9d/RF309od12VfSNs+iNJCTAVpN/XrfROmVJkkHAwq7ljopax12xpyhsXCQDbzWlcVi9IaYQTVxhYPJxTbrI1W2Zm0cVOHQN/zeUp4EZOI2G3mQ+clx5xUqiviwKa8Kd0YfzCds4VrUrkGnNHpkeDlHWOJfKPHztAsc18/jVYINKY64JxCjukoOLqq1eYbsxZeS666SsvSfDi7rKyT8/tACRJVBQUJ6KcyHT3X1RIZy5XhEWBxBZ2/4VAAD//94BRlFOBwAA",
./inventory/k8s-objects.json:17699:                    "argocd.argoproj.io/tracking-id": "n8n:/PersistentVolumeClaim:hf-n8n/n8n",
./inventory/k8s-objects.json:17700:                    "kubectl.kubernetes.io/last-applied-configuration": "{\"apiVersion\":\"v1\",\"kind\":\"PersistentVolumeClaim\",\"metadata\":{\"annotations\":{\"argocd.argoproj.io/tracking-id\":\"n8n:/PersistentVolumeClaim:hf-n8n/n8n\"},\"labels\":{\"app.kubernetes.io/instance\":\"n8n\",\"app.kubernetes.io/managed-by\":\"Helm\",\"app.kubernetes.io/name\":\"n8n\",\"app.kubernetes.io/version\":\"1.122.4\",\"helm.sh/chart\":\"n8n-2.0.1\"},\"name\":\"n8n\",\"namespace\":\"hf-n8n\"},\"spec\":{\"accessModes\":[\"ReadWriteOnce\"],\"resources\":{\"requests\":{\"storage\":\"5Gi\"}},\"storageClassName\":\"longhorn\"}}\n",
./inventory/k8s-objects.json:17711:                    "app.kubernetes.io/instance": "n8n",
./inventory/k8s-objects.json:17713:                    "app.kubernetes.io/name": "n8n",
./inventory/k8s-objects.json:17715:                    "helm.sh/chart": "n8n-2.0.1"
./inventory/k8s-objects.json:17717:                "name": "n8n",
./inventory/k8s-objects.json:17718:                "namespace": "hf-n8n",
./inventory/service-matrix.md:17:| Pidoka GmbH | `n8n.heckenfels.com` | `https://192.168.20.40:443` | hf-n8n/n8n / → svc/n8n:80 | `hf-n8n` | n8n (ClusterIP 80->http) | Deployment/n8n | n8n Bound longhorn 5Gi | n8n Synced/Healthy |
./inventory/service-matrix.md:25:- `n8n.heckenfels.com` → 8gears.container-registry.com library/n8n
./inventory/service-matrix.md:29:- Gut GitOps-sichtbar: `n8n.heckenfels.com` (`Synced/Healthy`).
./inventory/argocd-apps.json:453:                    "argocd.argoproj.io/tracking-id": "apps:argoproj.io/Application:infra-argocd/n8n",
./inventory/argocd-apps.json:454:                    "kubectl.kubernetes.io/last-applied-configuration": "{\"apiVersion\":\"argoproj.io/v1alpha1\",\"kind\":\"Application\",\"metadata\":{\"annotations\":{\"argocd.argoproj.io/tracking-id\":\"apps:argoproj.io/Application:infra-argocd/n8n\"},\"name\":\"n8n\",\"namespace\":\"infra-argocd\"},\"spec\":{\"destination\":{\"namespace\":\"hf-n8n\",\"server\":\"https://kubernetes.default.svc\"},\"project\":\"default\",\"source\":{\"chart\":\"library/n8n\",\"helm\":{\"values\":\"main:\\n  enabled: true\\n\\n  ports:\\n    http: 5678\\n\\n  config:\\n    n8n:\\n      basic_auth:\\n        active: true\\n\\n  persistence:\\n    enabled: true\\n    type: dynamic\\n    storageClass: longhorn\\n    accessModes:\\n      - ReadWriteOnce\\n    size: 5Gi\\n\\nextraEnv:\\n  - name: N8N_BASIC_AUTH_USER\\n    valueFrom:\\n      secretKeyRef:\\n        name: n8n-secret\\n        key: BASIC_AUTH_USER\\n\\n  - name: N8N_BASIC_AUTH_PASSWORD\\n    valueFrom:\\n      secretKeyRef:\\n        name: n8n-secret\\n        key: BASIC_AUTH_PASSWORD\\n\\n  - name: N8N_ENCRYPTION_KEY\\n    valueFrom:\\n      secretKeyRef:\\n        name: n8n-secret\\n        key: ENCRYPTION_KEY\\n\\n  - name: N8N_HOST\\n    value: \\\"n8n.heckenfels.com\\\"\\n  - name: N8N_PROTOCOL\\n    value: \\\"https\\\"\\n  - name: N8N_PORT\\n    value: \\\"5678\\\"\\n  - name: WEBHOOK_URL\\n    value: \\\"https://n8n.heckenfels.com\\\"\\n\\ningress:\\n  enabled: true\\n  className: traefik\\n  hosts:\\n    - host: n8n.heckenfels.com\\n      paths:\\n        - path: /\\n          pathType: Prefix\\n  tls: []\\n\\nservice:\\n  type: ClusterIP\\n  port: 80\\n\"},\"repoURL\":\"8gears.container-registry.com\",\"sourceType\":\"Helm\",\"targetRevision\":\"2.0.1\"},\"syncPolicy\":{\"automated\":{\"prune\":true,\"selfHeal\":true},\"syncOptions\":[\"CreateNamespace=true\"]}}}\n"
./inventory/argocd-apps.json:458:                "name": "n8n",
./inventory/argocd-apps.json:465:                    "namespace": "hf-n8n",
./inventory/argocd-apps.json:470:                    "chart": "library/n8n",
./inventory/argocd-apps.json:472:                        "values": "main:\n  enabled: true\n\n  ports:\n    http: 5678\n\n  config:\n    n8n:\n      basic_auth:\n        active: true\n\n  persistence:\n    enabled: true\n    type: dynamic\n    storageClass: longhorn\n    accessModes:\n      - ReadWriteOnce\n    size: 5Gi\n\nextraEnv:\n  - name: N8N_BASIC_AUTH_USER\n    valueFrom:\n      secretKeyRef:\n        name: n8n-secret\n        key: BASIC_AUTH_USER\n\n  - name: N8N_BASIC_AUTH_PASSWORD\n    valueFrom:\n      secretKeyRef:\n        name: n8n-secret\n        key: BASIC_AUTH_PASSWORD\n\n  - name: N8N_ENCRYPTION_KEY\n    valueFrom:\n      secretKeyRef:\n        name: n8n-secret\n        key: ENCRYPTION_KEY\n\n  - name: N8N_HOST\n    value: \"n8n.heckenfels.com\"\n  - name: N8N_PROTOCOL\n    value: \"https\"\n  - name: N8N_PORT\n    value: \"5678\"\n  - name: WEBHOOK_URL\n    value: \"https://n8n.heckenfels.com\"\n\ningress:\n  enabled: true\n  className: traefik\n  hosts:\n    - host: n8n.heckenfels.com\n      paths:\n        - path: /\n          pathType: Prefix\n  tls: []\n\nservice:\n  type: ClusterIP\n  port: 80\n"
./inventory/argocd-apps.json:504:                            "chart": "library/n8n",
./inventory/argocd-apps.json:518:                            "chart": "library/n8n",
./inventory/argocd-apps.json:532:                            "chart": "library/n8n",
./inventory/argocd-apps.json:534:                                "values": "main:\n  enabled: true\n\n  ports:\n    http: 5678\n\n  config:\n    n8n:\n      basic_auth:\n        active: true\n\n  persistence:\n    enabled: true\n    type: dynamic\n    storageClass: longhorn\n    accessModes:\n      - ReadWriteOnce\n    size: 5Gi\n\nextraEnv:\n  - name: N8N_BASIC_AUTH_USER\n    valueFrom:\n      secretKeyRef:\n        name: n8n-secret\n        key: BASIC_AUTH_USER\n\n  - name: N8N_BASIC_AUTH_PASSWORD\n    valueFrom:\n      secretKeyRef:\n        name: n8n-secret\n        key: BASIC_AUTH_PASSWORD\n\n  - name: N8N_ENCRYPTION_KEY\n    valueFrom:\n      secretKeyRef:\n        name: n8n-secret\n        key: ENCRYPTION_KEY\n\n  - name: N8N_HOST\n    value: \"n8n.heckenfels.com\"\n  - name: N8N_PROTOCOL\n    value: \"https\"\n  - name: N8N_PORT\n    value: \"5678\"\n  - name: WEBHOOK_URL\n    value: \"https://n8n.heckenfels.com\"\n\ningress:\n  enabled: true\n  className: traefik\n  hosts:\n    - host: n8n.heckenfels.com\n      paths:\n        - path: /\n          pathType: Prefix\n  tls: []\n\nservice:\n  type: ClusterIP\n  port: 80\n"
./inventory/argocd-apps.json:558:                                    "name": "n8n"
./inventory/argocd-apps.json:575:                                "message": "ingress.networking.k8s.io/n8n unchanged",
./inventory/argocd-apps.json:576:                                "name": "n8n",
./inventory/argocd-apps.json:577:                                "namespace": "hf-n8n",
./inventory/argocd-apps.json:585:                            "chart": "library/n8n",
./inventory/argocd-apps.json:587:                                "values": "main:\n  enabled: true\n\n  ports:\n    http: 5678\n\n  config:\n    n8n:\n      basic_auth:\n        active: true\n\n  persistence:\n    enabled: true\n    type: dynamic\n    storageClass: longhorn\n    accessModes:\n      - ReadWriteOnce\n    size: 5Gi\n\nextraEnv:\n  - name: N8N_BASIC_AUTH_USER\n    valueFrom:\n      secretKeyRef:\n        name: n8n-secret\n        key: BASIC_AUTH_USER\n\n  - name: N8N_BASIC_AUTH_PASSWORD\n    valueFrom:\n      secretKeyRef:\n        name: n8n-secret\n        key: BASIC_AUTH_PASSWORD\n\n  - name: N8N_ENCRYPTION_KEY\n    valueFrom:\n      secretKeyRef:\n        name: n8n-secret\n        key: ENCRYPTION_KEY\n\n  - name: N8N_HOST\n    value: \"n8n.heckenfels.com\"\n  - name: N8N_PROTOCOL\n    value: \"https\"\n  - name: N8N_PORT\n    value: \"5678\"\n  - name: WEBHOOK_URL\n    value: \"https://n8n.heckenfels.com\"\n\ningress:\n  enabled: true\n  className: traefik\n  hosts:\n    - host: n8n.heckenfels.com\n      paths:\n        - path: /\n          pathType: Prefix\n  tls: []\n\nservice:\n  type: ClusterIP\n  port: 80\n"
./inventory/argocd-apps.json:599:                        "name": "n8n-app-config",
./inventory/argocd-apps.json:600:                        "namespace": "hf-n8n",
./inventory/argocd-apps.json:606:                        "name": "n8n",
./inventory/argocd-apps.json:607:                        "namespace": "hf-n8n",
./inventory/argocd-apps.json:613:                        "name": "n8n",
./inventory/argocd-apps.json:614:                        "namespace": "hf-n8n",
./inventory/argocd-apps.json:620:                        "name": "n8n",
./inventory/argocd-apps.json:621:                        "namespace": "hf-n8n",
./inventory/argocd-apps.json:628:                        "name": "n8n",
./inventory/argocd-apps.json:629:                        "namespace": "hf-n8n",
./inventory/argocd-apps.json:636:                        "name": "n8n",
./inventory/argocd-apps.json:637:                        "namespace": "hf-n8n",
./inventory/argocd-apps.json:646:                        "http://n8n.heckenfels.com/"
./inventory/argocd-apps.json:649:                        "n8nio/n8n:1.122.4"
./inventory/argocd-apps.json:655:                            "namespace": "hf-n8n",
./inventory/argocd-apps.json:659:                            "chart": "library/n8n",
./inventory/argocd-apps.json:661:                                "values": "main:\n  enabled: true\n\n  ports:\n    http: 5678\n\n  config:\n    n8n:\n      basic_auth:\n        active: true\n\n  persistence:\n    enabled: true\n    type: dynamic\n    storageClass: longhorn\n    accessModes:\n      - ReadWriteOnce\n    size: 5Gi\n\nextraEnv:\n  - name: N8N_BASIC_AUTH_USER\n    valueFrom:\n      secretKeyRef:\n        name: n8n-secret\n        key: BASIC_AUTH_USER\n\n  - name: N8N_BASIC_AUTH_PASSWORD\n    valueFrom:\n      secretKeyRef:\n        name: n8n-secret\n        key: BASIC_AUTH_PASSWORD\n\n  - name: N8N_ENCRYPTION_KEY\n    valueFrom:\n      secretKeyRef:\n        name: n8n-secret\n        key: ENCRYPTION_KEY\n\n  - name: N8N_HOST\n    value: \"n8n.heckenfels.com\"\n  - name: N8N_PROTOCOL\n    value: \"https\"\n  - name: N8N_PORT\n    value: \"5678\"\n  - name: WEBHOOK_URL\n    value: \"https://n8n.heckenfels.com\"\n\ningress:\n  enabled: true\n  className: traefik\n  hosts:\n    - host: n8n.heckenfels.com\n      paths:\n        - path: /\n          pathType: Prefix\n  tls: []\n\nservice:\n  type: ClusterIP\n  port: 80\n"
./inventory/argocd-apps.json:877:                                    "name": "n8n"
./inventory/argocd-apps.json:891:                                "message": "application.argoproj.io/n8n configured",
./inventory/argocd-apps.json:892:                                "name": "n8n",
./inventory/argocd-apps.json:940:                        "name": "n8n",
./inventory/argocd-readiness-20260615/README.md:17:2. AppProject `default` ist noch offen (`sourceRepos: *`, `destinations: *`, `clusterResourceWhitelist: *`).
./inventory/argocd-readiness-20260615/README.md:19:3. AppProject `tenant-cattaro` ist noch Pilot-weit offen bei `sourceRepos: *` und `namespaceResourceWhitelist: */*`.
./inventory/argocd-readiness-20260615/README.md:24:   - Admin-Credential sollte in Infisical abgelegt/rotiert werden; Secretwert nicht ausgeben.
./inventory/argocd-readiness-20260615/README.md:32:Vor `hf-n8n` Migration zuerst GitHub/Repo-Credential für IT15-ArgoCD sauber einrichten, idealerweise als Secret-Quelle über Infisical dokumentiert. Danach `tenant-pidoka` AppProject anlegen und `hf-n8n` read-only Detailcheck durchführen.
./inventory/argocd-readiness-20260615/README.md:36:- GitHub PAT wurde in Infisical abgelegt: `platform-kubernetes/prod:/platform/gitops/github/GITHUB_PAT_PLATFORM_GITOPS`.
./inventory/argocd-readiness-20260615/README.md:39:- Nächster Schritt: neues Repo `GitMasterOne/platform-gitops` anlegen oder vorhandenes prüfen; danach IT15-ArgoCD Repository-Credential aus Infisical/Token anlegen.
./inventory/argocd-readiness-20260615/README.md:48:- Noch offen: Token nach Abschluss/Rotation neu ausstellen, weil er kurz im Chat sichtbar war.
./inventory/longhorn-health-report.md:1:# Longhorn Health Report
./inventory/longhorn-health-report.md:3:Quelle: read-only `kubectl` Longhorn CRDs. Keine Änderungen durchgeführt.
./inventory/longhorn-health-report.md:6:Longhorn läuft, aber *alle 12 sichtbaren Longhorn-Volumes sind nicht `healthy`*: 11 sind `attached/degraded`, 1 ist `detached/unknown`. Hauptursache sehr wahrscheinlich: Longhorn/StorageClass erwartet 3 Replicas, der Cluster hat aber nur 2 Longhorn-Nodes. Dadurch kann Longhorn die gewünschte Replica-Anzahl nie vollständig erreichen.
./inventory/longhorn-health-report.md:8:## Longhorn Nodes / Disks
./inventory/longhorn-health-report.md:31:| `hf-n8n` | `n8n` | 5Gi | attached | degraded | `mbrkanov-mini-it13` | 2 | 1 |
./inventory/longhorn-health-report.md:40:- Longhorn `backuptarget/default`: `AVAILABLE=false`; URL leer/nicht gesetzt.
./inventory/longhorn-health-report.md:41:- Damit ist kein funktionierendes Longhorn Backup Target sichtbar.
./inventory/longhorn-health-report.md:45:- Das reduziert nicht zwingend sofort die Verfügbarkeit aller Apps, aber es bedeutet: Longhorn befindet sich dauerhaft außerhalb des gewünschten Zielzustands.
./inventory/longhorn-health-report.md:49:1. Backup-Ziel/Backup-Strategie klären, bevor Longhorn repariert/geändert wird.
./inventory/longhorn-health-report.md:51:3. Danach Longhorn Settings/StorageClass und existierende Volumes geplant angleichen.
./inventory/longhorn-health-report.md:54:## Needs OK
./inventory/longhorn-health-report.md:56:- Jede Änderung an Longhorn Settings, StorageClass, Replicas oder Volumes braucht dein explizites OK.
./inventory/layered-inventory.md:20:- Longhorn ist installiert (`longhorn-system`).
./inventory/layered-inventory.md:32:| `hf-n8n` | Pidoka/heckenfels.com vermutlich | 4 |
./inventory/layered-inventory.md:59:| `n8n.heckenfels.com` | `https://192.168.20.40:443` | Pidoka | force SSL, http2, block exploits |
./inventory/layered-inventory.md:69:| `hf-n8n` | `n8n` | `n8n.heckenfels.com` |
./inventory/layered-inventory.md:91:| `hf-n8n` | Deployment | `n8n` | 1/1 |
./inventory/layered-inventory.md:145:| `hf-n8n` | `n8n` | Bound | `longhorn` | 5Gi | ReadWriteOnce |
./inventory/layered-inventory.md:165:| `n8n` | `infra-argocd` | `default` | Synced | Healthy | `8gears.container-registry.com` | `library/n8n` | `hf-n8n@https://kubernetes.default.svc` |
./inventory/layered-inventory.md:181:- Ebene 4: K3s Plattformdienste: Traefik, CoreDNS, ServiceLB, Longhorn
./camofox-browser/README.md:221:The default directory is `~/.camofox/cookies/`. Override with `CAMOFOX_COOKIES_DIR`.
./camofox-browser/README.md:618:| `CAMOFOX_COOKIES_DIR` | Directory for cookie files | `~/.camofox/cookies` |
./inventory/migration-20260615/app-details.txt:2:n8n project=default repo=8gears.container-registry.com path= chart=library/n8n target=2.0.1 dest=https://kubernetes.default.svc ns=hf-n8n sync=Synced health=Healthy
./inventory/migration-20260615/raw-inventory.txt:2:/home/node/.openclaw/workspace/ARGOCD_IT15_INFISICAL_PIDOKA_PLAN.md
./inventory/migration-20260615/raw-inventory.txt:31:hf-n8n                 Active   258d
./inventory/migration-20260615/raw-inventory.txt:61:hf-n8n                 deployment.apps/n8n                                1/1     1            1           147d     n8n                         n8nio/n8n:1.122.4                                                                                app.kubernetes.io/instance=n8n,app.kubernetes.io/name=n8n,app.kubernetes.io/type=master
./inventory/migration-20260615/raw-inventory.txt:145:hf-n8n                 service/n8n                                 ClusterIP      10.43.43.21     <none>                        80/TCP                                         147d     app.kubernetes.io/instance=n8n,app.kubernetes.io/name=n8n,app.kubernetes.io/type=master
./inventory/migration-20260615/raw-inventory.txt:156:hf-n8n         ingress.networking.k8s.io/n8n                 traefik   n8n.heckenfels.com        192.168.20.40,192.168.20.45   80      147d
./inventory/migration-20260615/raw-inventory.txt:182:hf-n8n        persistentvolumeclaim/n8n                                   Bound    pvc-50ca2f7c-5180-41c9-b22f-c7dbd59b7c52   5Gi        RWO            longhorn       147d     Filesystem
./inventory/migration-20260615/raw-inventory.txt:185:infra-argocd   n8n          Synced        Healthy         2.0.1                                      default
./camofox-browser/package-lock.json:136:      "integrity": "sha512-RgHBCvtjbOK2gXSNBNIkNoEc9qoVEtau3hj8gEqKQuL3HZAibKarWFEI3Lfm6EYKkLalOh8eSrj9b+ch9H/VBA==",
./camofox-browser/package-lock.json:2285:      "integrity": "sha512-WUj2qlxaQtO4g6Pq5c29GTcWGDyd8itL8zTlipgECz3JesAiiOKotd8JU6otB3PACgG6xkJUyVhboMS+bje/jA==",
./camofox-browser/package-lock.json:2375:      "integrity": "sha512-XYfuKMvj4O35f/pOXLObndIRvyQ+/+6AhODh+OKWj9S9498pHHn/IMszH+gt0fBCRWMNfk1ZSp5x3AifmnI2vg==",
./camofox-browser/package-lock.json:3016:      "integrity": "sha512-MAfYan7e+OK0JI70aHc2Qz92O4EaMXAsI1awQcwN0hGIFgbhf8z3q/XIbyy6h67aV1+L8DZYoITxvHoba1CEhg==",
./camofox-browser/package-lock.json:3074:      "integrity": "sha512-k/vGaX4/Yla3WzyMCvTQOXYeIHvqOKtnqBduzTHpzpQZzAskKMhZ2K+EnBiSM9zGSoIFeMpXKxa4dYeZIQqewQ==",
./camofox-browser/package-lock.json:4097:      "integrity": "sha512-D4CgpyCt+61f6z2jHjJS1OmZPviAWM57iJ9OKdFFWSNgS7Udj9QVWqyGs/cveVNF57XpZmhSvMdVIV5mjLA7Vg==",
./camofox-browser/package-lock.json:4284:      "integrity": "sha512-sPU4uV7dYlvtWJxwwxHD0PuihVNiE7TyAbQ5SWxDCB9mUYvOgroQOwYQQOKPJ8CIbE+1ETVlOoK1UC2nU3gYvg==",
./camofox-browser/package-lock.json:4500:      "integrity": "sha512-kbpaSSGJTWdAY5KPVeMOKXSrPtr8C8C7wodJbcsd51jRnmD+GZu8Y0VoU6Dm5Z4vWr0Ig/1NKuWRKf7j5aaYSg==",
./camofox-browser/package-lock.json:4740:      "integrity": "sha512-9bW6zvX/m0lEbgTKJ6YppOKx8H3VOPBMOCFh2irXFOT4BbHgrx5hPjwJYLT40Lu+4qtD36qKc/Hn56StUW57IA==",
./camofox-browser/package-lock.json:5399:      "integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==",


Der Stand ist jetzt klarer: nach dem Verbindungsabbruch wurden offenbar n8n/Matomo und später Zammad dokumentiert. Ich hole noch den Abschnitt ab „Recovery-Zwischenstand“, um nichts auszulassen.


nl -ba SESSION_HANDOFF.md | sed -n '360,620p'