Agenten-Verifikation und Skill-Entwicklung

Grundprinzip

Ein Agent darf bei überprüfbaren technischen Aufgaben nicht zugleich Ausführender und alleinige Verifikationsquelle sein.

Wiederholt zeigte sich: plausible Erfolgsberichte können falsch sein, obwohl ein Tool-Aufruf formal erfolgreich war. Deshalb gilt:

Selbstauskunft des Agenten ist ein Hinweis, kein Abnahmenachweis.

Verifikationsprinzipien

1. Ground Truth vor dem Test festlegen. Testdaten oder erwartete Systemzustände müssen über einen unabhängigen Kanal bekannt sein.
2. Verhalten in Batches testen. Ein Einzellauf beweist keine Zuverlässigkeit. Wiederholte Läufe zeigen Fehlerquote und Streuung.
3. Infrastrukturfehler getrennt zählen. Netzwerk-/Tool-Ausfälle sind keine Skill-Fehler und dürfen eine Verhaltensquote nicht verzerren.
4. Ergebnisse unabhängig nachprüfen. Geeignet sind direkte API-/Datei-/Netzwerkabfragen oder menschliche Kontrolle über einen separaten Zugang.
5. Ein Erfolgsstatus beweist nur Annahme/Ausführung, nicht korrekten Inhalt. HTTP 2xx, Exit-Code 0 oder ein grüner Containerstatus sind keine semantische Abnahme.
6. Bei Dateiübertragungen byte-genau verifizieren. Insbesondere lange Inhalte oder Sonderzeichen können auf Übertragungswegen verändert werden; Prüfsummen sind zuverlässiger als Sichtprüfung.

Skill statt Ad-hoc-Prompt

Wiederkehrendes Aufgabenwissen gehört in versionierte Skills. Ein einzelner Prompt ist zu flüchtig und zu schwer reproduzierbar.

Der bevorzugte Ablauf pro neuer Fähigkeit:

1. Baseline und konkrete Fehlbeispiele sammeln.
2. Skill erstellen statt den generischen Transport anzupassen.
3. Test mit Ground-Truth-Daten durchführen.
4. Bei Fehlern Ursache diagnostizieren.
5. Fix auf der möglichst strukturellen Ebene anwenden.
6. Nach demselben Testmuster erneut verifizieren.
7. Ergebnis und bekannte Grenzen dokumentieren.

Fix-Hierarchie

Bevorzugte Reihenfolge:

1. Konfiguration: unerwünschtes Verhalten strukturell unmöglich machen.
2. Skill-Inhalt: explizite wiederverwendbare Regeln und getesteten Code hinterlegen.
3. Gezielte Task-Anweisung: nur wenn höhere Ebenen nicht ausreichen.
4. Generischer Wrapper-/Transport-Patch: möglichst vermeiden, weil aufgabenspezifisches Verhalten dadurch an einer zu tiefen Ebene verankert wird.

Leitfrage:

Auf welcher Ebene lässt sich das Problem lösen, ohne auf Modell-Compliance angewiesen zu sein?

Verhaltenstest versus Root-Cause-Diagnose

• Verhaltenstests beantworten, ob und wie häufig ein Fehler auftritt.
• Logs und mechanische Diagnose beantworten, warum er auftritt.

Wenn eine korrekt formulierte Regel nicht zuverlässig befolgt wird, sind weitere gleichartige Tests allein kein Root-Cause-Nachweis.

Mechanische Diagnose

Bei unklaren technischen Fehlern möglichst interpretationsfreie Einzelaktionen verwenden. Ein exakt vorgegebener Befehl ist belastbarer als die Aufforderung „zeig, was du tust“.

Mehrere ähnliche Tool-Aufrufe sollten nicht unnötig gebündelt werden. In Hermes-Tests führte Tool-Deduplication dazu, dass ein Aufruf entfernt wurde und anschließend trotzdem ein plausibles Ergebnis berichtet wurde.

Approval- und Sicherheitsgrenze

Genehmigungsentscheidungen werden nie automatisch durch den Agenten getroffen. Der vollständige Inhalt einer Approval-Anfrage muss dem Menschen vorgelegt werden.

Blockierte oder genehmigungspflichtige Aktionen müssen als solche gemeldet werden. Ein Agent darf einen blockierten Aufruf nicht als Erfolg umdeuten.

Terminal-Learnings aus Hermes

Wiederverwendbare Befunde:

• Nach jedem Tool-Aufruf output, Fehler und Exit-Code explizit prüfen.
• Wörtliche Rohausgabe kann trotz Aufforderung paraphrasiert werden; kritische Werte deshalb über unabhängige Kontrolle prüfen.
• Mehrere Terminal-Aufrufe in einem Turn können dedupliziert werden; kritische Schritte einzeln ausführen.
• Wenn eine vermeintliche Ausgabe exakt dem gesendeten Befehl entspricht, kann es sich um Command-Echo statt echte Ausgabe handeln.
• Wiederholte Fehlversuche begrenzen; keine blinden Retry-Schleifen.
• Längere Prozesse explizit in einen geeigneten Hintergrundmodus überführen.
• Persistente lokale Agenten-Backends können Zustand wie exportierte Umgebungsvariablen über Aufgaben hinweg behalten; Secrets daher nicht unnötig in die Prozessumgebung exportieren.

Fertig-Kriterien

Vor Delegation technischer Arbeit sollten vier Punkte feststehen:

• Ziel: Was soll erreicht werden?
• Warum: Welcher Kontext oder welches Risiko ist relevant?
• Fertig-Kriterien: mechanisch prüfbare Ergebnisse.
• Grenzen: Was gehört ausdrücklich nicht zum Auftrag?

Fertig-Kriterien sollten beobachtbare Fakten benennen, nicht Formulierungen wie „sinnvoll“ oder „vollständig“.

AgileKit – Konzept

Idee

AgileKit war als Produktidee für hochwertige Agile-Templates und später kleine Workflow-Automatisierungen für Scrum Master, Agile Coaches und Teams gedacht.

Positionierung

Die zentrale Idee war nicht „KI erzeugt Templates“, sondern fachliche Kuration mit KI-gestütztem Produktionsworkflow. Die Expertise sollte in Methodenauswahl, Qualitätskriterien, Prompting und redaktioneller Auswahl liegen.

Bild aus der Quelle: eher Tischler mit CNC-Fräse als Maschine ohne Handwerk.

Geplanter Ausbau

1. einzelne hochwertige Templates,
2. thematisch gebündelte Template-Sets,
3. kleine Agents und Automatisierungen für wiederkehrende Arbeitsabläufe.

Produktionsprinzip

Der Produktionsworkflow sollte möglichst wenig manuelle Layoutarbeit verursachen und Zeit in Methoden, Inhalte und Qualität verlagern.

Historische Einordnung

Das Projekt ist archiviert. Erste Vertriebsannahmen, Preisideen und Toolfragen waren frühe Hypothesen und werden nicht als aktuelle Entscheidung fortgeschrieben.

Anytype – Evaluation für selbstgehostete Wissensarbeit

Einordnung

Anytype/AnySync wurde als mögliche selbstgehostete Notiz- und Wissensschicht evaluiert. Die Tests waren ein Spike; eine Entscheidung, Anytype als Nomon-Standard aufzunehmen, wurde nicht getroffen.

Die reale Migration persönlicher Inhalte soll erst erfolgen, wenn ein finaler Zielaccount und ein finales AnySync-Betriebsmodell feststehen.

Bestätigte Fähigkeiten

• Selfhost-Sync zwischen Fedora-Desktop und iPhone funktionierte bidirektional.
• Die lokale Desktop-API war erreichbar und konnte Objekte lesen und verändern.
• Ein separater Headless-/Bot-Account konnte in einem selbstgehosteten AnySync-Netz betrieben werden.
• Der Bot sah nur explizit freigegebene Spaces plus seinen eigenen Space.
• Lesen, Schreiben und Archivieren funktionierten über die Headless-HTTP-API.
• Der offizielle Anytype-MCP-Adapter funktionierte technisch gegen die Headless-API.
• Die Space-Isolation blieb über MCP erhalten.
• Rechteentzug entfernte den lesbaren Zugriff im laufenden Betrieb ohne Credential-Rotation.

Wichtige Grenze: eine erneute Freigabe eines zuvor entzogenen Spaces wurde vom laufenden Headless-Prozess nicht zuverlässig ohne Neustart übernommen.

Agentenarchitektur

Für Agentenzugriff ist ein separater Bot-/Agentenaccount die bevorzugte Berechtigungsgrenze. Der persönliche Nutzeraccount soll nicht als Agentenidentität verwendet werden.

Der vollständige technische Pfad wurde nachgewiesen:

MCP-Client → Anytype-MCP → Headless-Bot-API → AnySync → explizit freigegebener Space

Mit einem realen Claude-Code-Client funktionierte dieser Pfad im Debug-Startmodus. Der normale interaktive Claude-Code-Betrieb war wegen eines reproduzierbaren Verbindungsfehlers noch nicht stabil und gilt deshalb nicht als abgeschlossen.

Collectives → Anytype

Der native Markdown-/Obsidian-Import von Anytype übernimmt normale Markdown-Strukturen weitgehend gut. Die zentrale semantische Differenz zu Nextcloud Collectives lautet:

• Collectives: Ordner + Readme.md ist eine Parent-Seite mit eigenem Inhalt.
• Anytype: Ordner und Readme.md werden als getrennte Objekte importiert.

Ein nachträgliches Verschmelzen des Readme-Inhalts über die Markdown-API wurde verworfen, weil dabei native Child-Referenzen zu normalen Textlinks degradiert wurden.

Funktionierender Migrationsansatz

Vor dem nativen Anytype-Import wird deterministisch vorverarbeitet:

1. Collective als Markdown-Verzeichnis inklusive Attachments exportieren.
2. Readme.md in Ordnern als sichtbare Child-Seite, z. B. Start.md mit Titel „Übersicht“, abbilden.
3. Nextcloud-spezifische Syntax portabel normalisieren.
4. Anytypes nativen Markdown-/Obsidian-Importer verwenden.
5. Import automatisiert und stichprobenartig validieren.

Damit bleiben Unterseiten native Anytype-Karten statt durch nachträgliches Markdown-Patching degradiert zu werden.

Formatierungsbefund

Sauber beziehungsweise brauchbar übernommen wurden unter anderem Überschriften, Standardformatierungen, Listen, Aufgabenlisten, Zitate, Tabellen, Codeblöcke, SVG-Bilder, Links, Frontmatter-Tags, Wiki-Links, LaTeX und <details>.

Bekannte Abweichungen:

• Inline-Bilder erscheinen als eigene Bildblöcke.
• Mermaid bleibt Codeblock statt gerendertem Diagramm.
• Nextcloud-Erwähnungen werden Klartext.
• Nextcloud-spezifische Highlights und Callouts brauchen Normalisierung.

Noch offen

Vor einer Standardentscheidung fehlen unter anderem:

• Shared-Space-Test mit zweitem menschlichem Account,
• Ressourcenmessung von Headless/API/MCP,
• Backup-/Restore-Test des AnySync-Stacks,
• Privacy-/Metadatenprüfung,
• dauerhaftes Netzwerk-/Admission-Control-Modell,
• Betriebsmodell für Headless-Service und Secret-Handoff,
• Architektur-/Security-Review.

Ein gemeinsames AnySync-Netz würde verschlüsselte Nutzdaten und Metadaten instanzübergreifend verarbeiten. Das muss vor Nomon-Standardisierung gegen Datenhoheit und Verantwortungsmodell geprüft werden.

Atlus Homeserver – stabiler Systemkontext

Rolle

Atlus ist ein Lenovo ThinkCentre M920q als lokaler, headless betriebener Homeserver. Er dient als langfristige Docker-Plattform im Heimnetz und als reale Test-/Betriebsumgebung für Teile von Nomon.

Stabile Basis

• Debian 13 als Betriebssystem.
• x86-64 Plattform.
• 32 GB RAM-Klasse und lokale SSD als Systemlaufwerk.
• LVM mit großem Root-Dateisystem statt kleiner separater /var-Partition, damit Docker nicht künstlich eingeengt wird.
• Docker aus dem offiziellen Docker-Repository.
• gemeinsames internes Docker-Netz proxy-net für Reverse-Proxy-basierte Dienste.

Administrationsmodell

• normaler Admin-Account statt direktem Root-Login,
• SSH ausschließlich key-basiert,
• direkter Root-Login deaktiviert,
• UFW mit deny-by-default für eingehenden Verkehr,
• Fail2ban für SSH,
• Administration über Heimnetz oder Tailscale,
• Docker administrativ über sudo, nicht über Mitgliedschaft des normalen Accounts in der Docker-Gruppe.

Serverbetrieb

Atlus ist für dauerhaften unbeaufsichtigten Betrieb konfiguriert:

• Sleep/Suspend/Hibernate deaktiviert,
• kurzer Power-Button-Druck ignoriert,
• automatischer Start nach Stromrückkehr aktiviert,
• SMART-Monitoring und regelmäßiges TRIM aktiv,
• automatische Paketupdates ohne automatischen Reboot.

Netzwerkprinzip

Öffentliche Webdienste sollen nach Möglichkeit über Nginx Proxy Manager laufen. Interne Dienste werden nicht unnötig direkt über Host-Ports veröffentlicht.

Administration und normaler Nutzdatenverkehr werden getrennt gedacht. Tailscale dient als privates Overlay für Administration und interne Verbindungen; in Nomon existiert zusätzlich ein separates Wartungsnetz, siehe nomon-m2-7-vollmacht-fernwartung.

NAS-Integration

Atlus ist für NFS, CIFS/SMB, rsync und SSHFS vorbereitet. Konkrete Mounts, Backup-Ziele und produktive Credentials werden nicht als statischer Maschinenzustand in dieser Notiz festgeschrieben.

Dauerhafte Leitplanken

Kein Big-Bang-Cutover

Pro Dienst:

1. bestehenden Stack analysieren,
2. Abhängigkeiten und Datenpfade identifizieren,
3. Secrets identifizieren, ohne sie in Doku zu kopieren,
4. Backup und Restoreweg definieren,
5. parallel testen,
6. Netzwerk und Proxy prüfen,
7. erst danach umschalten und alten Dienst stoppen.

Keine unnötigen offenen Ports

Öffentliche Ports nur für tatsächlich benötigte Dienste. SSH soll nicht öffentlich aus dem Internet erreichbar sein.

Secrets bleiben außerhalb der Dokumentation

Private Keys, Passwörter, API-Tokens, .env-Secrets und Zertifikats-Private-Keys gehören nicht in die Wissensbasis.

Fedora-Geräte-Synchronisation

Ziel

Mehrere Fedora-/GNOME-Geräte sollen sich im Alltag ähnlich anfühlen, ohne vollständige Systemimages zu spiegeln. Synchronisiert werden deshalb ausgewählte Einstellungen und Anwendungslisten, nicht das ganze System.

GNOME/dconf-Sync

Bewährtes Muster:

• Änderungen an ausgewählten dconf-Bereichen werden exportiert.
• Ein NAS-Pfad dient als neutraler Austauschort.
• Andere Geräte importieren nur neuere Stände.
• Erststart eines neuen Geräts importiert zuerst und exportiert erst danach.
• Gerätespezifische Energieeinstellungen bleiben bewusst ausgeschlossen.

Synchronisierbare Bereiche sind unter anderem Shell/Dock, Hintergrund, Tastenkürzel, Extension-Einstellungen und Interface/Themes.

Learning

Nicht jede dconf-Einstellung ist cross-device kompatibel. Hardware- oder pfadspezifische Werte sollten nicht blind synchronisiert werden.

Flatpak-Sync

Statt Flatpak-Zustand komplett zu replizieren, wird die Liste manuell installierter Apps zwischen Geräten verglichen. Fehlende Apps werden interaktiv angeboten; bewusst ignorierte Apps landen lokal auf einer Ignore-Liste.

GNOME-Kernapps werden gefiltert, um nicht jede distributionsnahe Standardkomponente zu spiegeln.

Clipboard-Sync

Ein getestetes Konzept nutzte:

• GNOME Shell Extension als Clipboard-Beobachter und Empfänger,
• D-Bus zum direkten Setzen der Zwischenablage,
• SSH über Tailscale als Transport zwischen Geräten,
• Loop-Schutz über den zuletzt gesehenen Inhalt.

Das direkte Setzen über GNOME/St.Clipboard vermeidet sichtbares Flackern durch externe Clipboard-Tools.

Sicherheits-/Robustheitsgrenzen

• Passwordless SSH-Keys sind bequem für Automatisierung, vergrößern aber bei kompromittiertem Client den Zugriffsradius; der Einsatz sollte auf klar begrenzte Geräte-/Use-Cases beschränkt bleiben.
• StrictHostKeyChecking=no ist für dauerhaften Betrieb keine ideale Vertrauensgrenze und sollte bei einer Neuimplementierung durch sauberes Host-Key-Management ersetzt werden.
• NAS-Mount und Tailscale-Verfügbarkeit müssen als eigene Fehlerdomänen behandelt werden; Sync darf bei Nichterreichbarkeit kontrolliert aussteigen.

NAS- und AppImage-Learning

SMB-Mounts unterstützen nicht in jedem Setup die Unix-Semantik, die Linux-Anwendungen erwarten. Insbesondere AppImages/Wine-Umgebungen können an fehlenden Symlinks oder Locking-Eigenschaften scheitern.

Dauerhafte Regel: Programme, die Unix-Symlinks oder lokale Locking-Semantik benötigen, lokal ausführen und NAS nur als Daten-/Backupziel verwenden.

Fotografie – Kamera-Präferenzen

Ausgangslage

Vorhandene Referenzkamera ist eine Nikon D7000. Hauptgrund für einen möglichen Wechsel ist weniger Bildqualität als Gewicht und Alltagstauglichkeit.

Stabile Kaufkriterien

• möglichst leicht; Gewicht ist wichtiger als maximale Miniaturisierung,
• kompakt, aber mit elektronischem Sucher,
• gutes Handling auch mit größeren Händen,
• klarer Foto-Fokus; Video ist nachrangig,
• sinnvolle Festbrennweiten ungefähr bei 24 mm, 50 mm und 85–100 mm Vollformat-Äquivalent,
• Gebrauchtkauf ist grundsätzlich in Ordnung,
• Kamera vor Kauf in die Hand nehmen.

Bisher engere Kandidaten

Fujifilm X-E5

War in der Recherche Ende 2025 der Favorit. Attraktiv wegen kompakter APS-C-Bauform und kleiner Festbrennweiten.

Passende Brennweiten im damaligen Raster:

• XF 16 mm f/2.8 → ungefähr 24 mm äquivalent,
• XF 35 mm f/2 → ungefähr 52 mm,
• XF 56 mm f/1.2 → ungefähr 84 mm,
• XF 60 mm f/2.4 Macro → ungefähr 90 mm.

Sony a7C II

Interessant als kompakte Vollformatoption. Offener Punkt war vor allem das Handling mit großen Händen; ein Zusatzgriff könnte relevant sein.

Verworfene Richtungen der damaligen Recherche

• Nikon Zf: vorhandenes älteres AF-D-Objektiv wäre über FTZ nicht mit Autofokus nutzbar.
• MFT: der Größenvorteil erschien bei den betrachteten Gehäusen nicht groß genug.
• Sony a7R V: technisch attraktiv, aber deutlich teurer und mit unnötig großen Dateien für den eigentlichen Bedarf.

Status

Die letzte dokumentierte Tendenz war Fuji X-E5 oder Sony a7C II, mit leichter Präferenz zur Fuji. Vor einer späteren Entscheidung muss der Markt neu geprüft werden; Modellpreise und Verfügbarkeit aus der alten Recherche sind kein dauerhafter Wissensstand.

Frühe Produktideen – Archiv

Diese Seite bewahrt drei ältere, nie bis zur Umsetzung ausgearbeitete Ideen in stark verdichteter Form. Marktpreise, Anbieterlinks und alte Kostenschätzungen werden nicht als aktueller Wissensstand fortgeschrieben.

Van Conversion / Tiny Living (2019)

Frühe Idee für einen großen Kastenwagen als Wohn- und Arbeitsraum.

Gedanken damals:

• möglichst großer L4/L5-Kastenwagen,
• Bett platzsparend hochziehbar oder als Murphy-Bett,
• Dusche und Stauraum multifunktional nutzen,
• Solarstrom,
• Standheizung/-klima,
• Anhängerkupplung,
• mögliche Hybrid-/Elektro-Nachrüstung,
• TÜV- und Zulassungsfragen als zentrale Hürde.

Die damaligen Fahrzeug-, Solar- und Preisangaben sind veraltet und müssten bei einer Wiederaufnahme komplett neu recherchiert werden.

Veganer Ayran (2022)

Produktidee für ein pflanzliches herzhaftes Erfrischungsgetränk.

Offene Arbeitsfelder waren:

• Rezeptur und Inhaltsstoffe,
• Haltbarkeit und Lagerung,
• Produktionspartner,
• direkte und indirekte Konkurrenz,
• Marken-/Verpackungsdesign,
• Preisstruktur und Vertrieb,
• Finanzierung.

Es wurde keine belastbare Rezeptur oder Marktentscheidung dokumentiert.

Sofa-/Polsterkissen nach Maß (2022)

E-Commerce-/Produktidee für universell nutzbare Sofa- und Rückenkissen.

Gedanklicher Kern:

• Fremdfertigung statt eigener Produktion,
• möglichst lagerarmer Versandprozess,
• funktionale Differenzierung über Befestigung und universelle Größen,
• Sets aus Sitz- und Rückenteilen,
• zweisprachiger Vertrieb DE/EN denkbar,
• möglichst wenig Startkapital durch Eigenleistung bei Website, Design und Kommunikation.

Auch hier sind historische Wettbewerber und Preise nicht mehr verlässlich.

Einordnung

Alle drei Ideen sind historisch, nicht aktiv. Bei einer Wiederaufnahme gilt: zuerst Bedarf, Markt und heutige technische/rechtliche Rahmenbedingungen neu validieren, statt die alten Detailannahmen weiterzuverwenden.

Johannes Goerner – stabiler Kontext

Beruflicher Hintergrund

• Gastronomie-Hintergrund als Barkeeper und Teamleiter.
• Studium im Bereich Vegan Food Management.
• Wechsel aus der Gastronomie in agile Beratung und IT-Kontexte.
• 2023 bis März 2025 freiberuflich als Agile Coach und Scrum Master tätig.
• Seit 2025 Scrum Master bei uni-assist e. V.

Berufliche Zeitlinie

2023 – Freelance-Phase

• Scrum Master und Agile Coach auf Projektbasis.
• Arbeit unter anderem an Anforderungsmanagement und Scrum-Einführungen.
• Aufbau der eigenen Positionierung und beruflichen Kommunikation.

2024 – Freelance + Übergang

• weitere Scrum-/Agile-Arbeit,
• Beschäftigung mit Testing-Prozessen, Wissensstrukturen und HR-/Organisationsentwicklung,
• zunehmende Bewerbungs- und Neuorientierungsphase.

2025 – Wechsel in Festanstellung

• intensive Bewerbungsphase auf Rollen wie Scrum Master, Agile Coach, Product Owner und Projekt-/Produktmanagement,
• letzte Freelance-Projekte im Frühjahr,
• anschließend Wechsel zu uni-assist e. V. als Scrum Master.

Seit 2025/2026 – Organisationskontext uni-assist

Wiederkehrende Arbeitsfelder:

• Sprint Reviews, Retrospektiven und Dailys,
• PI Planning,
• Stakeholder-Kommunikation,
• Onboarding,
• Rollen- und Auftragsklärung zwischen Scrum Master und Product Owner,
• Obeya und weitere Formen visueller Führung/Koordination,
• Testing- und Prozessverbesserung,
• Facilitation und systemische Perspektiven.

Methoden und Qualifikationen

Dokumentierter Methoden-/Qualifikationskontext umfasst unter anderem:

• Scrum und Kanban,
• OKR,
• Obeya,
• SAFe / PI Planning,
• Liberating Structures,
• Gewaltfreie Kommunikation,
• systemische Beratung,
• Lean / Kaizen,
• TZI,
• Graphic Recording.

Genannte Zertifizierungen sind PSM I, PSK und LWO I sowie dokumentierte SAFe-Erfahrung.

Arbeitsweise

Wiederkehrende Muster aus den Notizen:

• pragmatisch und iterativ statt methodendogmatisch,
• gern mit visuellen Modellen und Metaphern,
• Erkenntnisgewinn durch kleine Experimente und anschließende Reflexion,
• technische und organisatorische Probleme möglichst über überprüfbare Kriterien statt bloße Plausibilität lösen.

Dauerhafte Interessensfelder

• Agilität, Organisationsentwicklung und Facilitation,
• Self-Hosting und digitale Selbstbestimmung,
• Muay Thai,
• Gastronomie und pflanzliche Ernährung,
• Fotografie,
• Natur / Foraging,
• Geschichte und Literatur.

Abgrenzung

Diese Notiz enthält bewusst keine Kontakt- oder Wohnadresse, Identitätsdokumente, Gesundheitsangaben, Finanzinformationen oder andere für die langfristige Wissensbasis unnötige sensible Daten.

MyHub – Produktkonzept

Kernidee

MyHub war als verbindendes Produkt zwischen Desktop-Betriebssystem und eigenem Server gedacht: nicht als weiteres Server-Dashboard oder Plugin, sondern als Brücke, durch die selbstgehostete Dienste auf Desktop und Mobilgerät wie ein zusammenhängendes Ökosystem wirken.

Produktversprechen der damaligen Konzeption:

Du hast dein Betriebssystem. Du hast deinen Server. Durch MyHub wird daraus ein Ökosystem.

Strategisches Modell

Die damalige Präferenz war eine Kombination aus drei Säulen:

1. Offener Standard: Beschreibung, wie ein souveränes digitales Ökosystem auf Linux aussehen und sich einrichten kann.
2. Referenzimplementierung: ein dokumentierter vollständiger Stack für Menschen, die von Null starten.
3. Community: offener Kern ohne Vendor Lock-in; Finanzierung perspektivisch über freiwillige oder ergänzende Leistungen.

Abgrenzung

Server-Oberflächen wie CasaOS oder Umbrel wurden nicht primär als Konkurrenz gesehen. Sie verwalten den Server; MyHub sollte Desktop, Mobilgerät und Server zu einer Nutzererfahrung verbinden.

Historische Einordnung

MyHub ist kein aktueller Nomon-Baustein. Das Konzept bleibt als historischer Referenzpunkt nützlich, weil mehrere spätere Nomon-Ideen – verständliche Oberfläche, Verbindung von Self-Hosting und Alltag, Referenzimplementierung – denselben Problemraum berühren.

Die damalige konkrete Roadmap und offene Taskstände werden nicht fortgeschrieben.

NAS – Dateihygiene und persönliches Offsite-Backup

Datenbereinigung: Ergebnis zuerst schützen

Langlaufende Dateiscans können selbst ein wertvolles Artefakt sein. Bei sehr großen Datenbeständen dauerte ein Duplikat-Scan über Netzwerk mehrere Tage.

Daraus folgt:

• Scan-Ergebnisse nicht ausschließlich in flüchtigen Verzeichnissen wie /tmp aufbewahren.
• Vor jeder Auswertung eine unveränderte, schreibgeschützte Kopie des Rohresultats anlegen.
• Auswertungsskripte ausschließlich gegen die Kopie lesen lassen.
• Vor Kopieren oder Löschen erst Anzahl und Gesamtgröße des Kandidatensatzes prüfen.

Duplikate versus einzigartige Dateien

Für die Bereinigung historischer Backup-Bestände ist die relevante Unterscheidung:

• Datei existiert bereits im Zielbestand → kein Handlungsbedarf.
• Datei ist nur innerhalb des Altbestands mehrfach vorhanden → eine Kopie retten.
• Datei ist ausschließlich im Altbestand vorhanden und kein Duplikat → retten.

Snapshots oder vollständige Spiegel des Zielbestands müssen vor der Auswertung ausgeschlossen werden, sonst verfälschen sie die Duplikatklassen.

Werkzeugspezifische Lernpunkte

AllDup

„Aus Ergebnis entfernen“ und „Datei löschen“ sind unterschiedliche Aktionen. Nach realen Löschvorgängen Speicherbelegung und Dateianzahl unabhängig kontrollieren.

Czkawka

CLI-Optionen und JSON-Struktur sind versionsabhängig. Ein Parser muss gegen die tatsächlich erzeugte Struktur der eingesetzten Version entwickelt werden, nicht gegen Annahmen aus anderer Dokumentation.

Restic-Offsite-Grundsatz

Ein persönliches Offsite-Backup wird erst nach drei Schritten als erfolgreich behandelt:

1. neuer Snapshot vorhanden,
2. Repository lesbar,
3. restic check ohne Fehler.

Vor physischem Trennen eines Datenträgers immer sauber aushängen.

Hardware-Learning: USB ist Teil der Backup-Kette

Bei einem getesteten externen SATA-USB-Gehäuse führten UAS beziehungsweise der Betrieb über einen USB-Hub unter hoher Last zu I/O-Fehlern und Dateisystemproblemen. Stabil war der direkte Anschluss mit erzwungenem usb-storage statt UAS.

Daraus folgt allgemein:

Backup-Zuverlässigkeit hängt nicht nur von Restic oder dem Dateisystem ab, sondern auch von Controller, Treiber, Kabel und USB-Topologie.

Nach Kernel-/Treiberänderungen relevante Quirks beziehungsweise den tatsächlich aktiven Treiber erneut prüfen.

Hintergrundprozesse

Langlaufende Backups oder Scans, die aus einer Shell gestartet werden, müssen bewusst von der Sitzung entkoppelt werden. Andernfalls kann ein Abbruch der beobachtenden Shell auch den eigentlichen Prozess beenden.

Logs und Fortschrittsbeobachtung sollten den Backup-Prozess nicht selbst gefährden.

New Work / Homeoffice – Artikelidee 2020

Historischer Kontext

Aus einer Bachelorarbeits-/Publikationsidee von 2020 entstand ein möglicher Fachartikel zu Chancen und Risiken virtueller Arbeit. Das Projekt wurde nicht als aktuelles Vorhaben weitergeführt, enthält aber einen weiterhin brauchbaren Denkrahmen.

Kernfrage

Wie lässt sich die gewonnene Eigenverantwortung des Homeoffice nutzen, ohne soziale Isolation, Überforderung oder Selbstausbeutung zu verstärken?

Gedanklicher Aufbau

1. Ausgangssituation

• New Work und Homeoffice als zunehmende Arbeitsrealität,
• höhere Eigenverantwortung Einzelner,
• weniger selbstverständlich vorhandene soziale und räumliche Struktur.

2. Spannungsfelder

Aus Sicht von Beschäftigten:

• Motivation und Selbstorganisation,
• Flow als produktiver Zustand,
• Gefahr der Überidentifikation bzw. Selbstausbeutung,
• soziale Kontakte,
• räumliche und technische Infrastruktur.

Aus Sicht von Organisationen:

• Führung ohne permanente physische Präsenz,
• Vertrauen und Kontrolle,
• Unternehmenskultur,
• technische Infrastruktur,
• Zusammenarbeit in virtuellen Teams.

3. Gestaltungsfrage

Gesucht ist nicht „Homeoffice gut oder schlecht“, sondern eine gute Mischung aus virtuellen und physischen Kontaktpunkten.

Mögliche Hebel:

• virtuelle Teampraktiken,
• bewusst gestaltete soziale Kontaktpunkte,
• Coworking,
• Führung und klare Erwartungen,
• passende Kollaborationswerkzeuge,
• Schutz vor dauerhafter Entgrenzung.

4. Coworking als Brücke

Eine damalige Idee war, Coworking nicht nur als Arbeitsplatzvermietung zu betrachten, sondern als Infrastruktur zwischen Unternehmen, Beschäftigten und Kommunen – besonders in ländlichen Regionen.

Kommunen könnten damit physische Arbeitsorte, soziale Begegnung und Unterstützungsangebote bereitstellen, ohne dass jede Person täglich in eine zentrale Firmenzentrale pendeln muss.

Möglicher roter Faden

1. Homeoffice erhöht Eigenverantwortung.
2. Motivation kann Chance und Risiko zugleich sein.
3. Flow und Selbstausbeutung bilden ein relevantes Spannungsfeld.
4. Virtuelle Teams und Coworking können Teile des Problems adressieren.
5. Entscheidend ist die Gestaltung der Schnittstelle zwischen Individuum, Team, Organisation und Ort.

Historische Einordnung

Die ursprünglichen Verlags-/Kontaktlisten und konkrete Publikationsplanung von 2020 werden nicht fortgeschrieben. Falls das Thema erneut aufgegriffen wird, müssen Forschungslage, Arbeitswelt und Publikationsumfeld neu recherchiert werden.

Nextcloud Collectives → Second Brain – Migrationsaudit

Quelle: Nextcloud Collective Persönlich mit 411 Seiten inklusive Struktur-/Readme-Knoten.
Ziel: Gitea habbes/second-brain, Branch chatgpt-import.

Grundsatz

Die Migration ist keine 1:1-Kopie. Ziel ist eine dauerhafte, agentenlesbare Wissensbasis. Chronologische Arbeitsprotokolle, temporäre Zustände und redundante Einzelseiten wurden deshalb zu stabilen Wissensobjekten verdichtet.

Dabei gilt:

• dauerhaftes Wissen vor Momentaufnahmen,
• aktueller Stand vor überholten Zwischenständen,
• Entscheidungen und Begründungen vor Chat-/Session-Chronik,
• keine Secrets oder funktionalen Zugangsdaten im Git-Wiki,
• keine unnötigen sensiblen persönlichen Verwaltungsdaten.

Migrierte / konsolidierte Zielobjekte

AUSGESCHLOSSEN – enthält Zugangsdaten

Die folgenden Quellseiten wurden nicht direkt migriert. Bereinigte allgemeine Learnings durften in andere Wissensobjekte einfließen; Credential-Werte selbst bleiben außerhalb des Repos.

Seiten wie Secrets-Übersicht, Security, Admin-Accounts oder Hermes – Setup & Konfiguration nennen teilweise Orte oder Namen von Secrets, aber keine für die Wissensmigration benötigten Klartextwerte. Ihre Prinzipien wurden nur abstrahiert übernommen; detaillierte Produktionskonfiguration bleibt Betriebsdokumentation.

AUSGESCHLOSSEN – sensible personenbezogene Verwaltungsdaten

Nicht in die allgemeine agentenlesbare Wissensbasis übernommen wurden insbesondere:

• Krankenkassen- und Identitätsdokumentdaten,
• persönliche Gesundheits-/Verletzungsnotizen,
• Finanzen und Steuern,
• Arbeitsamt-/BAföG-Akten,
• konkrete Wohnungs-, Adress- und Kontaktakten,
• personenbezogene Detailprofile aus KI-Extrakten, soweit sie Kontakt-, Wohn-, Finanz-, Gesundheits- oder Beziehungsdaten enthalten.

Aus den KI-Extrakten wurde nur nicht sensibler, langfristig nützlicher beruflicher und fachlicher Kontext nach people/johannes-goerner.md übernommen.

NICHT MIGRIERT – leer, flüchtig, überholt oder zu granular

Konflikte und überholte Quellen

M2.7-Startseite

Die M2.7-Startseite behauptet noch, WP-B1 sei „noch nicht begonnen“. Jüngere Unterseiten dokumentieren dagegen Design-Spike, Security-Review, UGREEN-Spike und das Final-Gate vom 15.09.2026. Für das Second Brain gilt der jüngere Unterseitenstand.

Technische Roadmap

Die Roadmap-Startseite trägt im Kopf noch Stand: 01.09.2026 und nennt M2.6 als aktuellen Meilenstein, obwohl M2.6 am 11.09.2026 geschlossen und M2.7 inzwischen aktiv ist. Der Second-Brain-Stand wurde auf 16.09.2026 konsolidiert.

Scrum-Prüfnotizen

Mehrere Aussagen stammen aus alten Rollen-/Begriffsständen. Sie wurden nicht als aktuelles Scrum-Referenzwissen übernommen; bei Bedarf ist die aktuelle Primärquelle neu heranzuziehen.

Journal-Abgrenzung

Die vorhandenen historischen Protokolle wurden nicht künstlich in journal/ umgebaut. Das Journal ist für neue, fortlaufende Historie nach der aktuellen second-brain-schema-Konvention vorgesehen. Historische Detailchronik verbleibt in Nextcloud, während stabile Erkenntnisse in Areas, Projects, Topics und Decisions liegen.

Was bewusst im Ursprung bleibt

Nextcloud Collectives bleibt die historische Quelle. Ins Git-Wiki wandert die kuratierte Wissensschicht, nicht jedes Zwischenprotokoll. Wird später ein altes Detail dauerhaft relevant, kann die Originalquelle gezielt erneut herangezogen und als neues oder aktualisiertes Wissensobjekt destilliert werden.

Nextcloud MCP – Authentifizierungsmodell und Betriebslearnings

Drei getrennte Vertrauensbeziehungen

Bei der Nextcloud-MCP-Anbindung müssen drei Auth-Ebenen auseinandergehalten werden:

1. MCP-Client ↔ MCP-Server: OAuth 2.1/PKCE beziehungsweise eine lokale Client-Freigabe des MCP-Servers.
2. MCP-Server ↔ Nextcloud OIDC: delegierter Nextcloud-Zugriff über einen statisch registrierten OIDC-Client.
3. MCP-Server ↔ Nextcloud Login Flow / App-Passwort: zusätzlicher Zugriff für WebDAV-nahe Funktionen wie Dateien und Collectives, wenn die OIDC-Ebene dafür nicht ausreicht.

Client-IDs und Konfigurationen dieser Ebenen sind nicht austauschbar. Insbesondere ist eine lokale MCP-Client-Freigabe keine Nextcloud-OIDC-Client-Registrierung.

Dynamische Registrierung nicht voraussetzen

Im getesteten Setup unterstützte die Nextcloud-OIDC-Seite keine Dynamic Client Registration. Der belastbare Weg war ein statisch freigegebener MCP-Client mit manuell passender Redirect-URI.

Dauerhafte Regel: DCR-Unterstützung nicht aus OAuth/OIDC-Unterstützung ableiten; sie muss separat bestätigt werden.

Erfolgsmeldungen unabhängig prüfen

Collectives-Create-Aufrufe konnten Fehler zurückgeben, obwohl die Aktion tatsächlich ausgeführt worden war. Nach mutierenden Aufrufen daher den Zielzustand durch eine separate Leseoperation verifizieren.

Das ist ein konkretes Beispiel für agenten-verifikation-und-skills: Transport-/API-Status und tatsächlicher Systemzustand sind unterschiedliche Dinge.

Collectives-Pfade sind strukturdynamisch

Sobald eine Collectives-Seite Unterseiten erhält, kann aus einer einzelnen Markdown-Datei ein Ordner mit Readme.md werden. Ein zuvor bekannter WebDAV-Pfad ist deshalb nicht dauerhaft stabil.

Vor Schreibzugriffen auf Collectives-Seiten den aktuellen Pfad aus der Collectives-Struktur neu ermitteln.

File Locks respektieren

423 Locked ist ein legitimer Konfliktzustand, wenn eine Seite parallel bearbeitet wird. Nicht durch aggressive Retries oder alternative Schreibpfade umgehen; Bearbeitung beenden beziehungsweise Lock auslaufen lassen und anschließend erneut schreiben.

Token-Lebensdauer als Systemparameter

Access- und Refresh-Token-Laufzeiten sind unterschiedliche Parameter. Wenn beide gleichzeitig kurz ablaufen, kann ein Client nach einer längeren Pause keinen Refresh mehr durchführen und wirkt fälschlich wie dauerhaft kaputt.

Dauerhafte Regel: Refresh-Fähigkeit separat vom Access-Token-Lifetime-Design betrachten.

Reverse-Proxy-Learning

Ein Reverse Proxy in Docker sieht localhost aus Sicht seines eigenen Containers. Soll ein Ziel auf einem Host-Port erreicht werden, muss der tatsächliche Netzwerkpfad beziehungsweise eine erreichbare Bridge-/Host-Adresse verwendet werden; 127.0.0.1 ist nicht automatisch der Docker-Host.

Nomon – Konzeption

Nomon ist keine zentral gehostete Plattform. Es verbindet Software, Marke und Einrichtungsdienst für eigenständig betriebene Instanzen und versteht sich als Föderation dieser Instanzen. Personen oder Gruppen behalten Kontrolle über Hosting-Vertrag, Infrastruktur und Daten. Der technische Betrieb erfolgt selbst oder per Vollmacht.

Aktuelles Arbeitsmotto:

Dateien, Termine und Nachrichten liegen hier – auf deiner eigenen Infrastruktur, gepflegt von jemandem, den du kennst.

Das Motto ist eine kommunikative Orientierung, kein unveränderlicher Leitspruch.

1. Grundidee & Föderation

Leitprinzipien:

• Eigenständigkeit: Jede Instanz ist getrennt betreibbar, kündbar und wiederherstellbar.
• Datenhoheit: Hosting-Vertrag und Kontrolle verbleiben bei den Betreibenden.
• Offenheit: Offene Programme und Protokolle sollen Abhängigkeiten begrenzen.
• Portabilität: Ein Ausstieg muss Datenmitnahme ermöglichen.
• Datensparsamkeit: Nomon zentralisiert keine fremden Inhaltsdaten.
• Transparenz: Grenzen, Wartung und Störungen werden offen benannt.
• Freiwilligkeit: Zugehörigkeit und Freigaben bleiben widerrufbar.

„Föderation“ bezeichnet sowohl das übergeordnete Zusammenspiel unabhängiger Nomon-Instanzen als auch – wo vorhanden – die technische Föderation einzelner Dienste. Nicht jeder Dienst muss technisch auf dieselbe Weise föderieren. Matrix bringt native Föderation mit; andere Verbindungen können über Fernzugriff, Schnittstellen oder Synchronisation entstehen.

Inhalte sind zunächst privat. Dauerhafte Freigaben innerhalb der Nomon-Föderation und zeitlich begrenzte Gastfreigaben sind konzeptionell vorgesehen. Die „digitale Allmende“ dient als soziale Metapher für eigenständige Parzellen mit gemeinsamen Regeln und verbindendem Umfeld.

2. Betriebs- & Instanzmodell

Instanzen können Personen oder Gruppen gehören. Es gibt zwei gleichrangige Betriebswege:

Eigene Verwaltung

Die Betreibenden richten die Instanz selbst ein oder werden dabei begleitet. Gemietete Infrastruktur und eigene Hardware sind möglich. Verantwortung für Betrieb, Strom, Internet, Erreichbarkeit und Wiederherstellung liegt bei den Betreibenden.

Vollmacht-Verwaltung

Die Betreibenden schließen den Hosting-Vertrag selbst ab und bevollmächtigen Johannes mit technischer Einrichtung und Wartung im definierten Umfang. Die Vollmacht ist widerrufbar. Selbst installierte Erweiterungen gehören nicht automatisch zur Wartungsverantwortung.

Der Instanzname und der Nutzername sind getrennte Konzepte. Das sichtbare Domain-Schema lautet grundsätzlich:

dienst.instanzname.nomon.cloud

Neue Matrix-Konten folgen grundsätzlich:

@nutzername:instanzname.nomon.cloud

Bestehende Identitäten können aus technischen Gründen erhalten bleiben.

Eine Instanz muss unabhängig von Nomon weiterbetrieben, übertragen oder beendet werden können. Normaler Nutzdatenverkehr läuft direkt zur Instanz; ein zentraler Nomon-Relay ist nicht als Standard vorgesehen. Administrative Mesh-Netze sind davon getrennt. Siehe nomon-direkter-datenpfad und nomon-m2-7-vollmacht-fernwartung.

3. Rollen, Zugang & Teilen

Stabile Rollen:

• Betreibende: organisatorisch und vertraglich verantwortliche Person oder Gruppe.
• Nutzende: Menschen mit regulärem Konto auf einer Instanz.
• Gäste: Menschen ohne reguläres Konto mit begrenztem Zugriff.
• Nomon-Mitglied: informeller Markenbegriff, derzeit keine Vereinsmitgliedschaft.
• Vereinsmitglied: nur für einen später tatsächlich bestehenden Verein.
• Host: kommunikative Rolle für Ordnung, Onboarding und technische Fürsorge; ersetzt keine formale Verantwortung.

Zugangsarten:

• reguläres Konto,
• dauerhafte Freigabe innerhalb der Föderation,
• temporäre Gastfreigabe,
• Einladung zu einzelnen Funktionen.

Bridges gehören nicht zum normalen Onboarding.

Wiederherstellung:

• Nomon-Passwörter können zurückgesetzt werden.
• 2FA-Wiederherstellungscodes müssen sicher hinterlegt werden.
• Ein verlorenes Tresor-Hauptpasswort ist nicht wiederherstellbar; diese Grenze muss beim Einrichten sichtbar sein.

Für jeden Dienst soll ein ehrlicher Export-/Ausstiegsweg dokumentiert werden. Grenzen, insbesondere bei Matrix-Verläufen, werden ausdrücklich benannt.

4. Dienste & Ressourcenstufen

Beschlossene Dashboard-Grundlogik:

• Zentrale: Kalender, Kontakte, Mail, Aufgaben, Formulare und weitere Nextcloud-Funktionen.
• Dateien: direkter Einstieg in die Dateiverwaltung.
• Dokumente: Nextcloud-Office-/Dokumentenansicht; Collabora ist technisches Backend, keine eigene Ablage.
• Kollective: Wiki und gemeinsam gepflegte Dokumentation.
• Chat: Element auf Matrix.
• Tresor: Vaultwarden.
• Fotos: Zusatzdienst bei geeigneter Ressourcenstufe.
• Design: Zusatzdienst bei geeigneter Ressourcenstufe.

Kanonische sichtbare Adressen:

• start.<instanz>.nomon.cloud
• zentrale.<instanz>.nomon.cloud
• dateien.<instanz>.nomon.cloud
• dokumente.<instanz>.nomon.cloud
• kollective.<instanz>.nomon.cloud
• chat.<instanz>.nomon.cloud
• tresor.<instanz>.nomon.cloud

Technische Endpunkte wie Authentik, MAS oder Collabora müssen nicht als eigene sichtbare Nomon-Funktion erscheinen.

Ressourcenstufen:

• s – schlank: geringerer Ressourcenbedarf, reduzierte schwere Funktionen.
• m – vollständig: aktuell erprobter Basis-Stack.
• l – erweitert: mehr Ressourcen und Zusatzdienste.

Belastbare Personenzahlen und Lastgrenzen sind noch nicht festgelegt. Stufenwechsel soll Ausbau statt Neuinstallation sein.

Nextcloud Talk bleibt das Videosystem. Element bleibt Text-/Matrix-Chat. Speicherziele wie NAS, SMB, WebDAV oder SFTP können eine Instanz erweitern.

5. Marke & Kommunikation

Nomon wird nicht als „privates Google“ positioniert. Die Sprache ist deutsch, konsequent per Du, verständlich und ohne unnötige Fachbegriffe oder unbelegte Sicherheitsversprechen. Drittanbieter bleiben als Drittanbieter erkennbar. Die mobile Nutzung ist die wichtigste Markenfläche.

Farbmodi

Grenzstein – hell

• Hintergrund #EDEAE2
• Karten #FFFFFF
• Primärtext #28271F
• Akzent #3F6355
• CTA #2C4A3D
• Warnung #A85338

Herdfeuer – dunkel

• Hintergrund #232019
• Karten #2C2820
• Primärtext #F2EDE4
• Akzent #CE7A2E
• CTA #E08F42
• Warnung #C96B4E

Typografie:

• Bitter für Wortmarke und Überschriften.
• Atkinson Hyperlegible für UI und Fließtext.
• Fonts werden selbst gehostet; keine externen CDNs.
• Keine Stockfotos.

Nomenklatur:

• „Nomon“ im Fließtext; „nomon“ nur als Wortmarke.
• Sichtbare Dienste heißen möglichst schlicht nach ihrer Funktion.
• Leitregel: „Nomon ist der einzige Eigenname im System. Alles darunter heißt, was es tut.“

Initiale Zielgruppe: ungefähr 25–50 Personen aus persönlichem und gemeinschaftlichem Umfeld.

6. Verantwortung & Rechtliches

Grundsatz:

Nomon speichert keine fremden Inhaltsdaten zentral. Bei bevollmächtigter Wartung beschränkt Johannes seinen Zugriff auf das technisch Notwendige.

Die Aussage „Johannes verarbeitet niemals fremde Daten“ wird ausdrücklich nicht verwendet. Wartung, Protokolle und Fehlerbehebung können bereits Datenverarbeitung darstellen.

Stabile Verantwortungsgrenzen:

• Hosting-Vertrag und Instanzkontrolle liegen bei den Betreibenden.
• Vollmacht-Wartung gibt begrenzte administrative Befugnisse.
• Inhalte werden nur eingesehen, wenn dies für ein konkret gemeldetes Problem erforderlich ist.
• Wartung wird nachvollziehbar dokumentiert.
• Vollmachten sind widerrufbar.
• Selbst installierte Komponenten sind nicht automatisch Teil der Wartungsverantwortung.

Offen und nicht als entschieden zu behandeln sind insbesondere Gruppeninstanzen, rechtliche Rolle bei Vollmacht-Wartung, Datenschutz-/Vertragsmodell, Einzeldienst-Zugänge Dritter, Pflichten aus dem verteilten Mailbetrieb, Betreiberverein und mögliche Wartungsvergütung.

Die frühere Rechtsseite zum Vereins-/Zentralservermodell ist historisch und nicht maßgeblich.

7. Umsetzungsmodell – Claude, Hermes & Johannes

Status der Quelle: erster Arbeitsentwurf, nicht abschließend von Johannes freigegeben. Die folgenden Punkte sind deshalb als belastbare Arbeitsprinzipien dokumentiert, nicht als endgültige Governance.

Rollen:

• Claude: technischer Entwurf, Zerlegung, Review und unabhängige Verifikation; keine eigenständigen konzeptionellen oder rechtlichen Entscheidungen.
• Hermes: begrenzte technische Ausführung über versionierte Skills.
• Johannes: Produkt-/Konzeptentscheidungen, Freigaben und strukturell nicht delegierbare Aktionen.

Verlässlichkeitsprinzipien:

1. Hermes-Selbstauskünfte sind keine unabhängige Verifikation.
2. Ein technischer Erfolgsstatus beweist nicht die inhaltliche Korrektheit.
3. Wiederkehrendes Aufgabenwissen gehört in versionierte Skills statt in Ad-hoc-Prompts.
4. Fix-Hierarchie: Konfiguration vor Skill-Inhalt vor Einzelanweisung; generische Transport-/Wrapper-Patches zuletzt und möglichst vermeiden.
5. Unklare Fehler werden mechanisch und interpretationsarm diagnostiziert.
6. Secrets werden gezielt und minimal verarbeitet, nie vollständig in Chat oder Logs ausgegeben.
7. Genehmigungsentscheidungen werden nie automatisch getroffen.
8. Voraussetzungen einer Aufgabe besitzen ihre eigene Risikoklasse; eine lesende Zielaktion kann produktionsnahe Voraussetzungen haben.

Autonomiestufen des Entwurfs:

• Stufe 1: lesend/diagnostisch – autonom.
• Stufe 2: reversibel und gut verifizierbar – autonom erst nach belastbarem Ground-Truth-/Batch-Nachweis.
• Stufe 3: irreversibel oder produktionsnah – explizite Freigabe je Aktion, bis eine Aufgabenklasse separat freigegeben ist.
• Stufe 4: rechtlich/vertraglich bindend oder echte Secret-/Zugangsrotation – nie autonom.

Die wiederverwendbaren Test- und Skill-Prinzipien stehen verdichtet unter agenten-verifikation-und-skills.

Offene Konzeptentscheidungen

• technische Umsetzung von nutzername@nomon.cloud im verteilten Mailbetrieb,
• belastbare Kapazitätsgrenzen der Ressourcenstufen,
• Verzeichnis, Auffindbarkeit und Präsenz innerhalb der Föderation,
• technisches Modell dauerhafter instanzübergreifender Freigaben,
• Datenschutz-/Vertragsmodell für Gruppeninstanzen und Vollmacht-Wartung,
• mögliche spätere Wartungsvergütung,
• möglicher Betreiberverein,
• finale Freigabe des Umsetzungsmodells,
• Markenregisterprüfung vor kommerzieller Nutzung.

Technische Umsetzung

Abgeschlossene und laufende technische Meilensteine werden nicht Seite für Seite gespiegelt, sondern als verdichtete Projektstände gepflegt:

• nomon-m2-6-instanz-tooling – abgeschlossen am 11.09.2026.
• nomon-m2-7-vollmacht-fernwartung – laufend; Phase A abgeschlossen, Phase B in Arbeit.

Anytype ist bislang nur evaluiert und kein Nomon-Standard: anytype-evaluation.

Nomon – Normaler Datenverkehr läuft direkt zur Instanz

Kontext

Für Heimhardware ohne regulär erreichbare öffentliche IPv4 wurde geprüft, ob ein zentraler öffentlicher Nomon-Reverse-Proxy über Headscale/Tailscale als generelle IPv4-Brücke dienen könnte.

Entscheidung

Normaler öffentlicher Web-, Matrix- und Nextcloud-Verkehr läuft direkt zur jeweiligen Instanz. Headscale/Tailscale dient der administrativen Fernwartung und ist nicht der normale Nutzdatenpfad.

Ein zentraler öffentlicher Nomon-Relay wird nicht als Standardmodell eingesetzt.

Begründung

Auch bei reinem TLS-Passthrough würde ein zentraler VPS Verbindungsmetadaten bündeln. Das widerspricht dem konzeptionellen Ziel, keine unnötige zentrale Stelle für fremden Datenverkehr zu schaffen.

Für unterschiedliche Zielumgebungen werden deshalb getrennte Infrastrukturadapter vorgesehen, etwa für professionelle Mietserver oder Heimanschlüsse mit IPv6/DynDNS.

Verworfene Alternativen

• Zentraler öffentlicher Nomon-Reverse-Proxy über Headscale/Tailscale als generelle IPv4-Brücke.

Nomon – Offsite-Backup mit technisch erzwungenem Append-only

Kontext

M2.6 bewies Backup und Restore lokal auf der Instanz, aber keinen produktiven Offsite-Transfer. Für M2.7 muss das Backup-Ziel vom Instanzhost getrennt sein und zugleich unter Kontrolle der jeweiligen Instanzperson/-gruppe bleiben.

Ein erster UGREEN-Spike über den herstellereigenen System-SSH zeigte, dass ein globaler ForceCommand dort keinen sauber isolierten per-Key Uploadpfad zulässt.

Entscheidung

Das generische Produktmodell für WP-B1 ist Restic + technisch erzwungenes Append-only.

Die normale Upload-Identität darf finalisierte Backup-Daten weder löschen noch überschreiben. Retention und Löschung erfolgen über einen getrennten, stärker privilegierten Owner-/Target-Pfad.

Für die UGREEN NASync DH2300 wird als nächster Adapter ein isolierter nativer rest-server --append-only geprüft.

Begründung

Append-only begrenzt den Schaden eines kompromittierten Instanzhosts: Die Identität, die neue Backups schreiben darf, soll bestehende Sicherungen nicht zerstören können.

Das Backup-Ziel bleibt Eigentum beziehungsweise unter Kontrolle der Instanzbetreibenden; Nomon hält keine zentrale Kopie fremder Inhaltsdaten.

Die Sicherheitsgrenze soll technisch erzwungen und mit Delete-/Overwrite-Negativtests praktisch bewiesen werden, nicht nur aus einer Konfigurationsoption abgeleitet werden.

Verworfene Alternativen

• rclone crypt + SFTP ohne unabhängig nachgewiesenen Löschschutz.
• UGREEN-System-SSH mit globalem Hersteller-ForceCommand als Sicherheitsgrenze für den produktiven Nomon-Uploadpfad.

Nomon – Separates Wartungsnetz als Userspace-Sidecar

Kontext

Bevollmächtigte Instanzen brauchen einen administrativen Fernzugang, ohne bestehende persönliche Tailscale-Identitäten umzuschalten oder als Nomon-Kanal zu verwenden. Gleichzeitig soll der Wartungskanal keine zusätzlichen Host-Routen oder weitreichenden Netzwerkprivilegien erzeugen.

WP0 und WP-A2 prüften den Parallelbetrieb praktisch auf Agent-VPS und Atlus.

Entscheidung

Nomon verwendet für die Vollmacht-Fernwartung ein separates Headscale-Netz mit isolierten Tailscale-Userspace-Sidecars.

Der persönliche Host-Tailscale-Client bleibt unverändert aktiv. Die Nomon-Sidecars verwenden kein TUN, kein NET_ADMIN, kein Host-Networking, keine Subnet-Routes und keinen Exit-Node-Modus.

Zugriffe werden über tag-basierte, deny-by-default Headscale-Grants begrenzt. SSH-Zugang wird zusätzlich serverseitig durch rollenfeste Forced Commands eingeschränkt.

Begründung

Der Parallelbetrieb wurde praktisch nachgewiesen. Damit lässt sich ein eigener, widerrufbarer Nomon-Wartungskanal schaffen, ohne das persönliche Tailnet als Verwaltungsinfrastruktur zu missbrauchen.

Das Userspace-Modell reduziert die Host-Eingriffe und hält die Nomon-Netzidentität von der persönlichen Identität getrennt. Die praktische Isolationsmatrix für TCP, UDP und ICMP wurde vor und nach Host-Reboots bestätigt.

Verworfene Alternativen

• Persönliches Tailscale des Hosts für Nomon-Wartung verwenden.
• Persönlichen Tailscale-Client für Nomon umschalten oder ausloggen.
• Sidecars mit TUN, NET_ADMIN, Host-Networking oder zusätzlichen Host-Routen als Standardarchitektur.

Nomon – Technische Roadmap

Zweck

Die Roadmap beschreibt die technische Entwicklung als Storyline. Konzeptionelle Entscheidungen stehen unter nomon-konzeption; detaillierte Umsetzungsprotokolle bleiben in den jeweiligen Projektquellen und werden nicht komplett in das Second Brain gespiegelt.

Storyline

M0–M2: erster funktionsfähiger Kern

• M0 – Fundament: Domains, TLS und erreichbare Dienste. Abgeschlossen 06.08.2026.
• M1 – Identität: gemeinsame Anmeldung und automatische Konten. Abgeschlossen 07.08.2026.
• M2 – Dashboard-Grundgerüst: eigener Einstieg mit Login und Dienstekacheln. Abgeschlossen 08.08.2026.

Diese Meilensteine entstanden noch unter dem ersten Betriebsmodell.

Architektur-Pivot: eigenständige Instanzen

• M2.5 – Verteiltes Fundament: erste Instanz in das neue Domain- und Verbindungsmodell überführen. Abgeschlossen 13.08.2026.
• M2.6 – Instanz-Tooling: reproduzierbares technisches Fundament für neue Instanzen. Abgeschlossen 11.09.2026; siehe nomon-m2-6-instanz-tooling.
• M2.7 – Vollmacht-Fernwartung: sichere Aufnahme, Wartung, Backup/Restore und Übergabe bevollmächtigter Instanzen. Aktiv; Phase A abgeschlossen, WP-B1 Offsite-Backup in Arbeit. Siehe nomon-m2-7-vollmacht-fernwartung.
• M2.8 – Föderationsfunktionen: Auffindbarkeit, Freigaben und dienstspezifische Interaktion zwischen Instanzen konzipieren und mindestens einen repräsentativen Fall erproben.
• M2.9 – Konsolidierung & Readiness Review: Fundamentlücken, Altlasten und Widersprüche schließen; ausdrückliches Gate vor M3–M6.

M2.8 – Föderationsfunktionen

Ziel ist, die Nomon-Föderation über Matrix hinaus praktisch nutzbar zu machen.

Fachliche Reihenfolge:

1. festlegen, wer was mit wem teilen darf,
2. Sichtbarkeit, Widerruf und Datensparsamkeit definieren,
3. erst danach je Dienst das technische Muster auswählen.

Mögliche technische Muster:

• native Föderation,
• autorisierter Fernzugriff auf die Quellinstanz,
• lokale Einbindung entfernter Inhalte,
• kontrollierte Synchronisation/Replikation.

Erste Kandidaten: Dateien/Kollective, Kalender, Fotos, Audiobookshelf und weitere Bibliotheken.

M2.9 – Readiness Gate

M2.9 ist kein Review-Meeting ohne Folgen. Blockierende Nacharbeiten müssen tatsächlich geschlossen werden.

Geprüft werden insbesondere:

• Instanztrennung und Datenhoheit,
• reproduzierbarer Neuaufbau,
• DNS/TLS/Reverse Proxy/Firewall/Adminzugänge,
• Backup, Restore, Secret-Rotation und Widerruf,
• OIDC, Matrix-ID-Schema und verteiltes Mailmodell,
• Ressourcenstufen und Upgradepfad,
• alte Domains, Testkonten, Secrets und manuelle Konfiguration,
• widerspruchsfreie Dokumentation.

Ergebnis ist ausdrücklich „bereit für M3“ oder „nicht bereit“.

Abhängigkeitsregel: M3 bis M6 beginnen erst nach erfolgreichem M2.9.

Produktvertiefung

M3 – Dashboard-Funktionstiefe

Dashboard vom reinen Dienste-Einstieg zur Arbeits- und Kontofläche ausbauen.

Schwerpunkte:

• übergreifende Suche für geeignete Nextcloud-Bereiche,
• bewusst getrennte Bewertung weiterer Quellen wie Fotos, Chat, Mail und Tresor,
• Kontomenü mit Anzeigename, Authentik-Verweisen, Export/Umzug, Status und Hilfe,
• konsistente mobile Navigation,
• klare Übergänge zwischen Dateien, Dokumenten und Kollective.

Sicherheitsfunktionen werden nicht im Dashboard nachgebaut, wenn Authentik dafür bereits zuständig ist.

M3.5 – Mein Nomon

Selbstverwaltung für Betreibende und Nutzende ohne direkten Serverzugriff.

Geplant:

• Instanzname, Domain, Betriebsweg und Ressourcenstufe,
• aktive Dienste und angemessene Statusinformationen,
• Nutzende, Rollen und Gruppeninstanzen,
• Diensteaktivierung und Ressourcenupgrade,
• Freigaben/Föderation,
• Datenexport, Umzug und Vollmachtswiderruf,
• Verwaltung zusätzlicher Speicherziele wie NAS, SMB, WebDAV oder SFTP.

Zentrale Leitfrage: Wie viel Selbstbedienung ist möglich, ohne Infrastrukturdetails und Secrets unnötig offenzulegen?

M4 – Chat-Feinschliff

• Element innerhalb seiner zulässigen Grenzen in die Nomon-Marke integrieren,
• Rückweg zum Dashboard,
• Synapse für m/l weiterführen,
• leichtere Chat-Servervariante für s erproben,
• Föderation und Ressourcenverbrauch testen,
• bestehende Matrix-Identitäten nicht unnötig zwangsmigrieren.

Klare Produktgrenze:

• Element/Matrix: Text- und Matrix-Chat.
• Nextcloud Talk: Video.
• Bridges: freiwilliger Sonderprozess, nicht Standard-Onboarding.

M5 – Öffentliche Flächen

Neuaufbau der öffentlichen und halböffentlichen Kommunikation:

• öffentliche Nomon-Seite,
• Ordnung,
• Status/Hilfe,
• Einrichtungs- und Gastfreigabeseiten,
• Hardware-/Hosting-Hinweise,
• Impressum und Datenschutz,
• Einstieg in Auffindbarkeit gemäß M2.8.

Alte Branding-Texte sind Materialquellen, aber keine aktuelle Entscheidungsquelle.

M6 – Onboarding

Getrennte Einstiege für:

• Betreibende: Betriebsweg, Instanz, Ressourcenstufe, Backup/Restore, Verantwortung und Widerruf.
• Nutzende: Konto, zentrale Dienste, mobile Apps, Hilfe, Status und Freigabegrundlagen.
• Gäste: wer teilt, was zugänglich ist, wie lange, ob Login nötig ist und wie Zugang endet.

Bridges werden im normalen Onboarding nicht erwähnt.

Paketierung und Betrieb

M7 – Installationspaket

Nach M6 wird der vollständige Stand als versioniertes Terminalpaket für Neuinstallationen bereitgestellt.

Leitsatz:

Ein Installer, zwei Bedienende: Mensch oder Agent.

Ziele:

• ein dokumentierter Startpunkt,
• Preflight des Zielsystems,
• definierte Reihenfolge,
• sichere Wiederholung/Fortsetzung,
• automatische Acceptance- und Healthchecks,
• verständliche Human-Ausgabe plus strukturierte Agentendiagnose,
• nichtinteraktive Ausführung,
• Secret-Management,
• vollständige Testmatrix für s/m/l und realer Weg-2-/Mietserver-Nachweis.

M7 behandelt Neuinstallation, nicht Updates.

M8 – Updates & sichere Rollouts

Updates bestehender Instanzen sind ein eigener Sicherheitsbereich.

Geplant:

1. Ausgangs- und Zielversion prüfen,
2. Backup und Restoreweg vorab verifizieren,
3. Test auf repräsentativen Instanzen,
4. Pilotinstanz aktualisieren,
5. gestaffelt ausrollen,
6. nach jeder Stufe Health-/Funktionstests,
7. bei Fehlern Rollout stoppen und sicher zurückfallen.

Dazu gehören Versionssprünge, Datenbankmigrationen, Digest-Pinning, unveränderliche Artefaktreferenzen und Regeln für Notfall-/Sicherheitsupdates.

Aktueller Stand 16.09.2026

• M0 ✅
• M1 ✅
• M2 ✅
• M2.5 ✅
• M2.6 ✅
• M2.7 🚧 aktiv – Phase A abgeschlossen, Offsite-Backup-Phase in Arbeit
• M2.8 geplant
• M2.9 geplant; Gate für M3–M6
• M3 bis M8 geplant/zu konzipieren

Übergreifende Leitplanken

• Normaler Instanzverkehr läuft direkt zur jeweiligen Instanz; kein zentraler Nomon-Reverse-Proxy als Standard.
• Zentrale Nomon-Komponenten dürfen nicht stillschweigend zu zentraler Inhaltsdatenhaltung werden.
• IPv4/IPv6/DNS-Publishing ist ein austauschbarer Infrastrukturadapter je Installation, keine feste Nomon-Annahme.
• Mail unter nutzername@nomon.cloud bleibt im verteilten Modell ungelöst.
• Kapazitätsgrenzen der Ressourcenstufen s/m/l müssen praktisch gemessen werden.
• Rechtliche Rollen bei Gruppeninstanzen und Vollmacht-Wartung bleiben getrennt von der technischen Roadmap zu klären.

Nomon M2.6 – Instanz-Tooling

Ziel

M2.6 sollte aus einem funktionierenden Einzelprototyp einen reproduzierbaren Aufbauprozess machen: Eine frische Nomon-Instanz muss aus versionierter Konfiguration und Tooling in einer definierten Ressourcenstufe aufgebaut, getestet und übergeben werden können.

Abschluss

M2.6 wurde am 11.09.2026 geschlossen.

Kanonischer Tooling-Stand: 18ded32.

Finale Acceptance: 83 bestanden, 0 fehlgeschlagen, 1 Warnung, Exit-Code 0. Die verbleibende Warnung betraf ausschließlich die bekannte IPv6-only-Erreichbarkeit von Matrix; echte Matrix-Föderation war praktisch bestätigt.

Final bestätigte Funktionalität

Ein kontrollierter Wipe von Atlus und ein Neuaufbau aus einem frischen Checkout des konsolidierten Toolings wurden Ende-zu-Ende erfolgreich durchgeführt. Dabei wurden die im Fresh-Rebuild gefundenen Reparaturen zurück ins Tooling geführt, committed und erneut getestet.

Praktisch nachgewiesen waren im Abschlussstand:

• Dashboard, Authentik und Erstnutzer-Enrollment,
• Nextcloud und Office,
• Vaultwarden,
• Matrix/Synapse mit Matrix Authentication Service,
• echter Login-Pfad chat.<instanz>.nomon.cloud → Element → MAS → Authentik,
• echte Matrix-Föderation zu einem unabhängigen dritten System,
• verteilter Mailbetrieb mit Inbound und Outbound,
• Mail-Edge und öffentlicher Mail-DNS,
• Backup und Restore,
• reproduzierbarer Fresh-Rebuild der Testinstanz.

Dauerhafte Tooling-Prinzipien

Git ist ausführbare Source of Truth

Dashboard und Instanz-Tooling wurden versioniert. Nextcloud dokumentiert Entscheidungen, Tests, Historie und Abschluss; die ausführbaren Artefakte liegen in Git.

Zentrale Identität über Authentik

Authentik ist die zentrale Identitätskomponente. OIDC-Clients und instanzspezifische Credentials werden über das Tooling erzeugt beziehungsweise reconciled.

Für Nextcloud und Matrix/MAS wurde praktisch bestätigt, dass der jeweilige OIDC-/SSO-Pfad aus der Instanzkonfiguration reproduzierbar hergestellt werden kann.

Sichtbare Dienste und technische Backends trennen

Sichtbare Endpunkte und interne Technik dürfen nicht vermischt werden. Insbesondere ist „Dokumente“ eine Nextcloud-Funktion; Collabora bleibt technisches Backend. Matrix API, MAS und Authentik sind technische Endpunkte und keine zusätzlichen sichtbaren Nomon-Funktionen.

Proxy- und Namensauflösung bewusst testen

Docker-interne Namensauflösung muss durch die tatsächlich verwendeten Mechanismen funktionieren. Bei Nextcloud reicht ein bloßer /etc/hosts-/extra_hosts-Eintrag nicht in allen Fällen aus; Netzwerk-Aliase am Reverse Proxy erwiesen sich als robusterer Testweg.

Fehler nicht nur live reparieren, sondern zurückführen

Ein Live-Fix ist noch kein reproduzierbares Tooling. M2.6 wurde erst geschlossen, nachdem Fresh-Rebuild-Funde in Source zurückgeführt und erneut abgenommen waren.

Backups mit Integritätsnachweis

Der Backup-/Restore-Pfad arbeitet mit manifestierten Artefakten und SHA256SUMS. Temporäre beziehungsweise einmalige Enrollment-Artefakte werden bewusst nicht in einen Restore zurückgebracht.

Wichtige technische Entscheidungen

• Gitea wurde als dauerhafter Code-Ort für Dashboard und Instanz-Tooling verwendet.
• Der normale öffentliche Datenverkehr soll direkt zur Instanz laufen; ein zentraler öffentlicher Nomon-Relay wurde als Standard verworfen. Siehe nomon-direkter-datenpfad.
• M2.6 unterscheidet zwei Ersteinrichtungswege vor dem gemeinsamen Kern: Heimhardware/privater Anschluss und professionell gehosteter Mietserver.
• Zentrale Zertifikatsausstellung ist als Verwaltungsfunktion vorgesehen; Atlus ist keine zentrale Nomon-Stelle.
• Die Ressourcenstufe m war die vollständig praktisch abgenommene Referenzstufe von M2.6.

Bleibende Learnings

• Ein Fresh-Rebuild ist aussagekräftiger als viele Teiltests am gewachsenen System.
• Ein HTTP-Erfolg oder grüner Containerstatus beweist keine korrekte Ende-zu-Ende-Funktion.
• SSO muss über die echte Nutzerreise geprüft werden, nicht nur über Discovery-Endpunkte.
• Konfigurationen, die von mehreren Diensten geteilt werden, müssen semantisch konsistent erzeugt und validiert werden; bei MAS etwa echte ULIDs statt Platzhaltern.
• Backup-/Restore-Mechanismen sind erst dann belastbar, wenn der Restore praktisch getestet und anschließend mit Acceptance geprüft wurde.

Verbleibende Grenzen außerhalb M2.6

Nicht als Restarbeit von M2.6 behandelt werden:

• ausreichend beschränkte beziehungsweise delegierte DNS-Zugangsdaten pro produktiver Instanz,
• komfortabler Installer und sofort sichtbarer Mail-Provisionierungsabschluss – M7,
• sichere Update- und Rollout-Prozesse – M8,
• Vollmacht-Fernwartung – nomon-m2-7-vollmacht-fernwartung.

Nomon M2.7 – Vollmacht-Fernwartung

Ziel

Bevollmächtigte Nomon-Instanzen sollen sicher aufgenommen, anlassbezogen gewartet, aus geprüften Backups wiederhergestellt und nach Widerruf ohne verbleibenden Nomon-Zugang übergeben werden können.

Vollmachtsform, Vertragsgestaltung und Geschäftsmodell sind ausdrücklich nicht Teil der technischen Architektur von M2.7.

Architekturziel

Das Wartungsnetz ist technisch und organisatorisch vom normalen Nutzdatenpfad getrennt. Persönliche Tailscale-Identitäten werden nicht als Nomon-Fernwartungskanal zweckentfremdet.

Die produktive Architektur verwendet:

• selbst betriebenen Headscale-Koordinationsserver,
• getrennte Tailscale-Userspace-Sidecars für Nomon-Agent und Instanz,
• keine TUN-Devices,
• kein NET_ADMIN,
• kein Host-Networking,
• keine zusätzlichen Host-Routen,
• deny-by-default Policies,
• rollenfeste SSH-Zugänge über Forced Commands statt freier Shell.

Siehe nomon-wartungsnetz-userspace.

Phase A – Netz & Zugang

Abgeschlossen: 14.09.2026.

Finaler Tooling-Stand Phase A: ac6b1921e905f649b5ab861bcb3383fcf6020356.

Bestätigt wurden:

• Headscale als selbst betriebener Koordinationsserver,
• öffentliche Control-Plane ausschließlich über HTTPS/TCP 443,
• Enrollment über kurzlebige, getaggte Pre-Auth-Keys,
• paralleler Betrieb persönlicher Tailscale-Verbindungen und des Nomon-Wartungskanals,
• tag-basierte Isolation Agent → Instanz,
• vollständige TCP-/UDP-/ICMP-Isolationsmatrix vor und nach Host-Reboots,
• SSH auf separatem Wartungsport mit rollenfesten Schlüsseln,
• Forced-Command-Dispatcher ohne freie Shell,
• keine allgemeine sudo- oder Docker-Berechtigung des Wartungsaccounts,
• lokale root-geschützte Auditierung.

Root-Trust-Path-Gate

Zwischen WP-A1 und WP-A2 wurde ein Sicherheitsfehler gefunden: root-ausgeführte Cron-Skripte lagen unter Parent-Verzeichnissen, die von einem unprivilegierten Nutzer beschreibbar waren. Damit war der tatsächlich ausgeführte Root-Code austauschbar.

Der Trust Path wurde gehärtet, ohne unnötig ganze Verzeichnisbäume umzubauen. Daraus entstand das allgemeine Prinzip root-trust-paths.

Userspace-/UDP-Learning

Der erste WP-A2-Versuch wurde zunächst gestoppt, weil ein belastbarer UDP-Ingress-Test im Userspace-Modell nicht offensichtlich war. Quellcode- und Laufzeitprüfung zeigten anschließend einen tragfähigen Testweg über den Userspace-Netstack und begrenzte temporäre UDP-Grants. Die userspace-only Architektur musste deshalb nicht aufgegeben werden.

Phase B – Offsite-Backup

Stand: 15.09.2026 – WP-B1 Design und Sicherheits-Gates abgeschlossen; produktive Umsetzung noch offen.

Das generische Produktmodell lautet:

Restic + technisch erzwungenes Append-only am Owner-kontrollierten Ziel.

Damit bleibt das Backup-Ziel unter Kontrolle der jeweiligen Instanzperson/-gruppe. Der Nomon-Agent hält keine zentrale Kopie fremder Inhaltsdaten.

Adapter-Rangfolge

1. SSH-Key-gebundener Forced Command, wenn das Zielsystem keine konkurrierende globale Zwangslogik besitzt.
2. Isolierter nativer oder containerisierter rest-server, wenn Variante 1 nicht sauber möglich ist.
3. Unabhängig nachgewiesener Snapshot-/Immutability-Layer des Zielsystems, wenn 1 und 2 ausscheiden.

Ein einfacher SFTP-/rclone-crypt-Pfad ist kein ausreichender Append-only-Schutz, solange ein kompromittierter Client vorhandene Sicherungen löschen oder überschreiben kann.

UGREEN-Befund

Der erste UGREEN-Spike über das System-SSH wurde verworfen: Das UGOS-System-SSH hängt an einem globalen Hersteller-ForceCommand, wodurch eine eigene per-Key-Sicherheitsgrenze nicht belastbar nachweisbar war.

Für die UGREEN NASync DH2300 wurde deshalb als nächster reversibler Spike ein isolierter nativer rest-server --append-only freigegeben.

Geplanter Datenpfad:

Instanz → Restic REST/TLS → rest-server --append-only → dedizierter Owner-Speicherpfad

Verbindliche Grenzen des Spikes:

• offizielles ARM64-Binary aus verifiziertem Release,
• kein Eingriff in bestehende UGOS-Dienste,
• dedizierter unprivilegierter Service-User,
• eigener Datenpfad außerhalb bestehender Freigaben,
• Bind ausschließlich an private Tailscale-IP,
• TLS zwingend; CA/Zertifikat instanzseitig explizit pinnen,
• zusätzliche HTTP-Basic-Authentifizierung,
• kein --no-auth,
• kein öffentlicher Port/FQDN,
• Upload-Hashprüfung nicht deaktivieren.

Append-only muss praktisch bewiesen werden

Nicht das Flag gilt als Nachweis, sondern die Laufzeitwirkung:

• neues Repositoryobjekt schreiben und lesen,
• Löschversuch über Append-only-Endpunkt muss scheitern,
• Überschreibversuch eines bestehenden Objekts muss scheitern,
• ursprünglicher Bestand bleibt anschließend intakt und lesbar.

Zusätzlich wird ein getrennter, privilegierter Retention-/Adminpfad benötigt, über den derselbe Löschvorgang gezielt erfolgreich sein kann. So wird bewiesen, dass die Sicherheitsgrenze am Append-only-Endpunkt liegt und nicht an zufälliger Dateisystem-Unveränderlichkeit.

Siehe nomon-offsite-backup-append-only.

Restore-Leitplanken

Der produktive Restore soll:

1. Eigentümer über Backup-ID, Alter und mögliches Datenverlustfenster informieren,
2. aktuellen Zustand sichern und Writer stoppen,
3. Manifest und Checksummen vor jedem Schreibzugriff prüfen,
4. Daten einspielen und Integrität prüfen,
5. nur zuvor laufende Dienste wieder starten,
6. anschließend Instanz-Acceptance erneut ausführen.

Rollback-Ziel bei Fehlschlag ist immer der unmittelbar vorher gesicherte Zustand – nie ein unbekannter Halb-Restore.

Prozess- und Datenschutzprinzipien

• Monitoring bleibt passiv-minimal: Erreichbarkeit des Wartungskanals statt dauerhafte Sammlung detaillierter Betriebsdaten.
• Wartungsprotokolle bleiben lokal auf der Instanz und werden nicht zentral aggregiert.
• Rohlogs mit möglichen Inhaltsdaten sind ein expliziter Notfallpfad, nicht normale Monitoring-Ausgabe.
• Wartungsankündigungen werden nach Eingriffstiefe gestaffelt.
• Bei Widerruf müssen Headscale- und SSH-Zugang gemeinsam entzogen und der Nichtzugriff anschließend aktiv verifiziert werden.

Noch offen

• nativer UGREEN-rest-server-Spike und erneuter Review,
• produktiver Offsite-Backup-Adapter,
• Retention und kontrollierter Adminpfad,
• produktiver Live-Restore und Rollback,
• Monitoring-/Protokoll-/Ankündigungsphase,
• vollständiger Widerrufs-/Übergabeprozess,
• Gesamt-Acceptance von M2.7.

Abnahmekriterium M2.7 gesamt

Eine bevollmächtigte Instanz kann sicher aufgenommen, gestaffelt gewartet, aus einem geprüften Backup wiederhergestellt und anschließend ohne verbleibenden Nomon-Zugang übergeben werden.

Persönliche IT-Infrastruktur

Zweck

Laufender Verantwortungsbereich für selbst betriebene Server, NAS, Netzwerkzugänge, Backups und Client-Integration.

Grundprinzipien

• Administration erfolgt bevorzugt über private Overlay-Netze und SSH, nicht über unnötig öffentliche Admin-Ports.
• Direkter Root-Login per SSH ist zu vermeiden; Key-basierte Anmeldung über einen normalen Admin-Account mit gezieltem sudo ist der bevorzugte Weg.
• Docker-Container sollen nur dann Host-Ports veröffentlichen, wenn dies wirklich erforderlich ist. Webdienste werden nach Möglichkeit über einen zentralen Reverse Proxy und interne Docker-Netze geführt.
• Mitgliedschaft in der Docker-Gruppe wird als praktisch root-äquivalent behandelt.
• Änderungen an kritischen Diensten erfolgen nicht als Big Bang: erst Backup und Restoreweg, dann paralleler Test, dann Cutover.
• Backup und Restore werden als zusammengehörige Fähigkeit behandelt; siehe self-hosting-backup-recovery.
• Root-ausgeführte Automatisierung folgt der Trust-Path-Regel root-trust-paths.

Aktuelle Rollen

Atlus

Lokaler Homeserver und langfristige Docker-Plattform. Stabiler Hostkontext und Härtungsprinzipien: atlus-homeserver.

UGREEN NASync DH2300

Zentrales lokales Speichersystem mit getrennten Volumes für Primärdaten und Backups. Es dient unter anderem als Ziel für Server-Backups und als Speicher für persönliche Dateien.

Agent-/Root-Server

Externe Systeme übernehmen je nach Zweck öffentlich erreichbare Dienste, Monitoring, Automatisierung und administrative Koordination. Der konkrete Maschinenzustand ändert sich und wird deshalb nicht als statische Second-Brain-Inventarliste gepflegt.

Architektur-Learnings

Monitoring außerhalb des überwachten Systems

Ein Monitor sollte nicht ausschließlich auf dem System laufen, dessen Ausfall er erkennen soll. Externes Monitoring auf einem separaten Knoten bleibt auch dann verfügbar, wenn der Hauptserver ausfällt.

Admin-Interfaces privat binden

Wenn ein Reverse Proxy hinter Docker-NAT keine verlässliche Quell-IP für Access Lists sieht, ist direktes Binding eines Admin-Ports an eine private Tailscale-Adresse eine robuste Alternative zum öffentlichen Proxying.

Storage ist eine gemeinsame Fehlerdomäne

Ein voller Host kann Datenbanken, Auth-Systeme und abhängige Dienste gleichzeitig kippen lassen. Bei mehreren scheinbar unabhängigen Ausfällen deshalb zuerst den Speicherzustand prüfen.

Abgrenzung

Momentane Containerlisten, RAM-Verbrauch, aktuelle IPs oder einzelne Prozesszustände sind Betriebszustand und gehören nicht als dauerhaftes Wissen in diese Area. Nur stabile Rollen, Prinzipien und wiederverwendbare Learnings werden hier gepflegt.

Pilze & Foraging

Samtfußrüblinge

Dokumentierte Art: Flammulina velutipes.

Merkmale aus der alten Notiz:

• wächst an Holz,
• typische Saison im Winter,
• goldgelb bis orangefarbene Hüte,
• in kultivierter Form mit Enoki verwandt.

Die alte Notiz führte die Art als essbar, weist aber ausdrücklich auf Verwechslungsgefahr hin.

Shiitake

Shiitake wurde 2026 zubereitet, nicht wild gesammelt. Eine konkrete Rezeptnotiz wurde damals nicht fertig ergänzt.

Sicherheitsregel

Fotos und Chat-Einschätzungen allein sind keine ausreichende Grundlage für den Verzehr wild gesammelter Pilze. Bei Unsicherheit lokale Pilzberatung nutzen.

Diese Seite ist Wissens-/Erfahrungsnotiz, keine Bestimmungshilfe für konkrete Funde.

Root-Trust-Pfade für automatisierte Skripte

Regel

Code, den root automatisch ausführt, darf nicht über Pfade austauschbar sein, die ein unprivilegierter Nutzer verändern kann.

Nicht nur die Skriptdatei selbst ist Teil der Vertrauensgrenze. Auch alle Parent-Verzeichnisse des ausgeführten Pfads müssen so geschützt sein, dass unprivilegierte Nutzer weder die Datei ersetzen noch den Pfad umbiegen können.

Warum das wichtig ist

Ein root-Cronjob, eine systemd-Unit oder ein exakt freigegebener sudo-Aufruf erbt die Vertrauenswürdigkeit des gesamten Dateipfads. Ist ein Parent-Verzeichnis schreibbar, kann selbst eine root-owned Skriptdatei durch Umbenennen, Austauschen oder Pfadmanipulation effektiv ersetzt werden.

Prüfmodell

Bei root-ausgeführtem Code mindestens prüfen:

• Besitzer und Modus der Skriptdatei,
• Besitzer und Schreibrechte aller Parent-Verzeichnisse,
• Symlinks und andere indirekte Pfadbestandteile,
• referenzierte Helper-Skripte,
• Konfigurationsdateien, die Code oder Befehle beeinflussen,
• ob ein weniger privilegierter Nutzer den Pfad oder das Ziel austauschen kann.

Härtungsprinzip

Die kleinstmögliche Trust-Grenze härten. Keine rekursiven Rechteänderungen über große Verzeichnisbäume, wenn nur ein konkreter aktiver Root-Codepfad betroffen ist.

Funktionale Fehler des Skripts und die Vertrauensgrenze getrennt behandeln: Ein bereits vorhandener Laufzeitfehler ist nicht automatisch durch die Rechtehärtung verursacht.

Second Brain — Architekturentscheidung

Kontext

Die Second-Brain-Frage entstand im Zusammenhang mit Hermes (n8n/Agent-Setup) und der parallelen Überlegung, ob Notiz-Tool (Anytype/Nextcloud Collectives) und Second Brain zwingend derselbe Ort sein müssen.

Entscheidung

Das Second Brain ist ein eigenständiges, Git-versioniertes Markdown-Repo (habbes/second-brain im selbstgehosteten Gitea unter git.tyf.one), unabhängig von einzelnen LLMs, Agenten oder Notiz-Tools. Zugriff erfolgt über austauschbare Adapter (Filesystem-Mount, Git-Clone, MCP), nie ausschließlich über ein einziges Protokoll.

Begründung

• Substrat darf nicht an einen bestimmten Agenten (Hermes) oder ein bestimmtes Protokoll (MCP) gebunden sein, damit es auch nach einem Tool-Wechsel bestehen bleibt
• Notiz-Erfassung (UX-Frage) und Wissensspeicherung fürs Retrieval durch Agenten (Kurations-Frage) sind unterschiedliche Anforderungen und werden bewusst getrennt
• Markdown + Git ermöglicht Versionierung, Inspizierbarkeit und Unabhängigkeit von proprietären Formaten

Verworfene Alternativen

• Second Brain direkt in Hermes' Skills-/Memory-Verzeichnis führen — hätte es an einen Agenten gebunden
• Live-Sync zwischen Notiz-Tool (Anytype/Collectives) und Second Brain über MCP — Rauschen-/Drift-Risiko, keine bewusste Kuration
• Ausschließlich MCP als Zugriffsweg — zu abhängig von einem einzelnen Protokoll/Anbieter

Second Brain — Schema & Konventionen

Ordnerstruktur

• areas/ — laufende Verantwortlichkeiten ohne Enddatum
• projects/ — zeitlich begrenzte Vorhaben mit Zielzustand
• people/ — Kontext zu Personen
• topics/ — Referenzwissen, wiederverwendbare Fakten
• decisions/ — dokumentierte Entscheidungen (ADR-Stil)
• journal/ — datierte, fortlaufende Einträge (siehe eigener Abschnitt unten)

Ordner bleiben flach — kein Verschachteln nach Lebensbereich
(areas/naturfreunde/..., areas/ambrosia/...). Zusammengehörigkeit läuft über
tags und [[Wikilinks]] im Frontmatter, nicht über Verzeichnistiefe. Tiefe
Verschachtelung war die AppFlowy-Falle (268 Views, widersprüchliche
Strukturlogiken) — hier bewusst vermieden.

Frontmatter (alle Dateien außer index.md/CHANGELOG.md/journal/*)

---
title: <Titel>
type: area | project | person | topic | decision
status: active | paused | archived
created: YYYY-MM-DD
updated: YYYY-MM-DD
tags: [tag1, tag2]
aliases: [Alternativname]
links: ["[[anderer-notiz-slug]]"]
---

Decision-Dateien

Zusätzlich zum Standard-Frontmatter feste Body-Struktur:

## Kontext
## Entscheidung
## Begründung
## Verworfene Alternativen

Reserviert für strukturelle Weichenstellungen mit Tragweite (Architektur,
grundlegende Richtungsentscheidungen) — nicht für Alltagsentscheidungen.
Faustregel: nur rein, wenn in einem Jahr noch relevant ist, warum so
entschieden wurde, nicht nur dass.

Journal

Datierte, fortlaufende Einträge — für Anfragen, die sich auf eine Historie
beziehen ("wie hat sich X entwickelt", "wann war Y").

• Eine Datei pro Monat: journal/YYYY-MM.md, darin Einträge als
  Tagesüberschriften (## YYYY-MM-DD)
• Frontmatter minimal: title, type: journal, created, updated
• Einträge verlinken auf betroffene areas//projects//people/-Dateien via
  [[Wikilinks]], statt Kontext zu duplizieren
• Kein endloses Rohlog: älter als ca. 3 Monate wird periodisch zu einer kurzen
  Zusammenfassung verdichtet oder die daraus stabile Erkenntnis wandert in die
  betroffene areas//topics/-Datei; das Journal selbst bleibt schlank

Personen & Sensible Inhalte

people/-Dateien sind Beziehungskontext, kein Dossier — private Details aus
dem Leben der anderen Person gehören nicht hinein, nur was die gemeinsame
Sache betrifft.

Bestimmte Kategorien bleiben grundsätzlich draußen, selbst wenn sie "wahr und
dauerhaft" wären: Gesundheitsdetails, Kontostände/Finanzen, sensible
Familienthemen. Grund: Dieses Repo ist über mehrere AI-Connectors abrufbar
(nicht nur von einer Person gelesen) — das ist eine andere Kategorie als
"nur ich lese das", unabhängig davon, ob das Repo selbst öffentlich ist.

Prinzipien

• Atomare Notizen: eine Datei pro Fakt/Thema
• Explizites „Warum" dokumentieren, nicht nur das „Was"
• [[Wikilinks]] zwischen verwandten Notizen setzen, damit ein Graph entsteht
• Änderungen mit Begründung in CHANGELOG festhalten
• Keine Zugangsdaten/Secrets in diesem Repo

Self-hosted SSO – Authentik, Nextcloud & Matrix

Identitäten stabil matchen

Bei bestehenden Accounts ist ein stabiler, bewusst gewählter Identifier entscheidend. Im getesteten Setup wird der Benutzername als sub verwendet. Nextcloud kann damit bestehende Accounts zuordnen, statt ungewollt neue Nutzer anzulegen.

Allgemeines Prinzip:

Vor einer SSO-Migration festlegen, welche Kennung die dauerhafte Identität repräsentiert – und das Verhalten bei bereits existierenden Accounts explizit testen.

Nextcloud: Provider und Client nicht verwechseln

Nextcloud besitzt mehrere OIDC-bezogene Funktionen mit ähnlich klingenden Namen. Für Login in Nextcloud über einen externen IdP ist Nextcloud der OIDC-Client; eine Funktion, die Nextcloud selbst zum OIDC-Provider macht, ist die falsche Richtung.

Bei Migrationen deshalb zuerst das Vertrauensdreieck aufzeichnen:

Browser → Identity Provider → Anwendung

und pro Komponente festhalten, wer Client und wer Provider ist.

Claims nur dann als integriert betrachten, wenn der Consumer sie tatsächlich abfragt

Ein IdP kann zusätzliche Claims korrekt ausgeben, ohne dass die Zielanwendung sie verwendet. Im getesteten Nextcloud-Setup wurden mehrere benutzerdefinierte Profilfelder vom IdP geliefert, aber von der verwendeten user_oidc-Version nicht angefordert bzw. übernommen.

Daraus folgt:

• Claim im Token vorhanden ≠ Zielanwendung nutzt ihn.
• Mapping muss Ende-zu-Ende getestet werden.
• Produktgrenzen nicht als Konfigurationsfehler missdeuten.

Enrollment muss fremde bestehende Sessions ausschließen

Ein Einladung-/Registrierungsflow kann gefährlich werden, wenn im Browser bereits eine andere Admin- oder Nutzersession aktiv ist. Im getesteten Authentik-Flow führte das zeitweise dazu, dass eine Registrierung den bereits eingeloggten Account veränderte.

Robuste Regel:

Enrollment-Flows für neue Konten sollten eine bestehende Auth-Session explizit ausschließen oder einen bewussten Account-Wechsel erzwingen.

Im getesteten Setup wurde dies über require_unauthenticated gelöst.

Interne und externe Nutzerrollen bewusst wählen

Ein als external deklarierter Nutzer kann in Authentik von internen Oberflächen ausgeschlossen sein. Eine automatische Weiterleitung direkt in eine Anwendung wirkt zunächst bequem, kann aber gewünschte Portal-/Dashboard-Funktionen abschneiden.

Der Nutzer-Typ ist deshalb keine kosmetische Eigenschaft, sondern Teil des Berechtigungsmodells.

Matrix Authentication Service: Migration ist mehr als ein Proxy-Umbau

Bei der Umstellung bestehender Synapse-Konten auf MAS müssen nicht nur Proxy- und OIDC-Einstellungen geändert werden. Bestehende Nutzer, Geräte und Kompatibilitätstoken müssen sauber in MAS überführt werden.

Bewährte Reihenfolge:

1. Datenbank und Konfiguration sichern.
2. MAS-Datenbank und Config vorbereiten.
3. syn2mas check ausführen.
4. Migration im Dry-Run testen.
5. Synapse für die echte Migration stoppen.
6. echte Migration ausführen.
7. erst danach Synapse auf MAS-Delegation umstellen.
8. Login, bestehende Sessions und Bridges getrennt verifizieren.

Ein früher Versuch ohne vollständige syn2mas-Migration führte zu unknown compat access token. Der schnelle Rollback auf die gesicherte Synapse-Konfiguration verhinderte einen längeren Ausfall.

Bestehende Konten: Konfliktstrategie explizit setzen

Bei MAS muss das Verhalten für bereits vorhandene lokale Matrix-Accounts festgelegt werden. Ohne passende Konfliktstrategie kann die Verknüpfung eines Upstream-Accounts mit einem bestehenden lokalen Konto absichtlich verweigert werden.

Allgemeines Learning:

„Username stimmt überein“ ist noch keine Migrationsstrategie. Die Software muss ausdrücklich wissen, ob bestehende Identitäten verknüpft, neu angelegt oder abgelehnt werden sollen.

Redirect-URIs exakt aus der realen Anwendung ableiten

MAS verwendet für Upstream-Callbacks eine interne Provider-ID in der Callback-URL. Eine intuitiv erfundene sprechende Redirect-URI reicht nicht.

Robuste Vorgehensweise:

• Callback-URI aus der tatsächlich erzeugten Konfiguration/Runtime ableiten,
• exakt beim IdP eintragen,
• keine semantisch „schönere“ URL annehmen.

Scopes und Property Mappings gehören zusammen

Ein deklarierter Scope ist nur nützlich, wenn der IdP dazu passende Mappings liefert. Fehlende Standard-Mappings führten im getesteten Matrix-Provider zu Invalid scope format.

Deshalb bei OIDC-Fehlern Scope-Anforderung und tatsächlichen Tokeninhalt gemeinsam prüfen.

Passwortlogin nach erfolgreicher SSO-Migration bewusst behandeln

Nach erfolgreicher Migration kann lokaler Passwortlogin gezielt deaktiviert werden, wenn der IdP alleiniger Loginweg sein soll. Das sollte erst nach verifizierter SSO-Funktion geschehen, nicht davor.

Bridges sind ein eigener Authentifizierungsmechanismus

Matrix-Appservice-Bridges verwenden eigene Appservice-Tokens und sind nicht automatisch von einem User-SSO-Umbau betroffen. Das ist für Migrationen wichtig, weil User-Login und Bridge-Authentifizierung getrennt bewertet werden müssen.

Backup-/Restore-Konsequenz

Mit MAS reichen Synapse-Datenbank und Synapse-Datenverzeichnis allein nicht mehr. Auch MAS-Datenbank, Config und Signing Keys gehören in den Backup- und Restore-Plan.

Restore-Reihenfolge bleibt abhängigkeitsgetrieben:

1. Datenbankdienst,
2. Datenbanken einspielen,
3. Synapse-Daten und Konfiguration,
4. MAS-Daten und Konfiguration,
5. Anwendungen starten,
6. Login/Discovery/Bridges separat testen.

Siehe self-hosting-backup-recovery.

DNS-Discovery: Wildcards decken die Root-Domain nicht ab

Wenn Matrix-server_name auf der nackten Root-Domain liegt, müssen .well-known-Requests auch dort funktionieren. Ein DNS-Wildcard-Eintrag für Subdomains deckt die Root-Domain nicht ab.

Caching kann einen solchen Fehler lange verdecken. Nach Auth-/Client-Migrationen sollte .well-known deshalb aus einem frischen Kontext aktiv geprüft werden.

Self-Hosting – Backup- und Recovery-Prinzipien

Backup ist erst mit Restore belastbar

Ein vorhandenes Backup ist kein ausreichender Recovery-Nachweis. Für kritische Dienste müssen Restore-Prozedur, Reihenfolge, Rechte, Datenbank-/Dateisystemkonsistenz und Erfolgskriterien praktisch getestet sein.

Vor destruktiven Operationen gilt:

1. aktuellen Zustand explizit sichern,
2. geplante Schritte und Fallback dokumentieren,
3. Restore-Quelle verifizieren,
4. Schreibdienste kontrolliert stoppen,
5. Restore durchführen,
6. Integrität prüfen,
7. erst dann Dienste wieder freigeben.

Der sichere Rückfallpunkt ist der unmittelbar vor dem Eingriff gesicherte Zustand, nicht ein halb geschriebener Zwischenstand.

Exit-Cleanup muss Dienste wiederherstellen

Backup- und Wartungsskripte dürfen bei tolerierbaren Teilfehlern nicht in einem gefährlichen Betriebszustand abbrechen. Ein konkretes Beispiel war ein Nextcloud-Backup, bei dem tar Exit-Code 1 wegen veränderter Dateien lieferte und set -e dadurch den späteren maintenance:mode --off-Schritt übersprang.

Daraus folgt:

• Exit-Codes semantisch unterscheiden,
• Cleanup-Logik über trap beziehungsweise garantiert ausgeführte Abschlussfunktionen absichern,
• Schreibdienste und Maintenance Modes auch bei Fehlern definiert zurücksetzen.

Root-Cron muss wirklich unter dem erwarteten Interpreter laufen

Ein fehlerhafter Shebang kann dazu führen, dass Cron ein Bash-Skript über /bin/sh/Dash ausführt. Shell-spezifische Konstrukte wie ERR-Traps können dann sofort scheitern.

Dauerhafte Regel: automatisierte Skripte immer über den tatsächlichen Cron-/systemd-Ausführungsweg testen, nicht nur manuell in einer interaktiven Shell.

Retention muss zur realen Plattengröße passen

Retention allein verhindert keinen Vollstand. Entscheidend ist der maximale gleichzeitige Platzbedarf während eines Backup-Laufs.

Wenn ein neuer vollständiger Stand erzeugt wird, während der letzte fertige Stand bewusst noch bestehen bleibt, muss die Platte beide gleichzeitig tragen können. Ein formal korrektes Retention-Skript kann deshalb trotzdem strukturell zu wenig freien Speicher lassen.

Bei wiederholtem Vollstand sind strukturelle Lösungen zu prüfen:

• Kompression,
• inkrementelle/deduplizierende Backups,
• direktes Streaming zum Ziel,
• größeres lokales Arbeitsvolumen,
• weniger lokale Vollstände.

Disk-full zuerst prüfen

Wenn mehrere abhängige Container gleichzeitig scheinbare DNS-/Netzwerkfehler zeigen, zuerst df -h prüfen. Ein gestoppter Container verliert seine Netzwerkpräsenz; Folgefehler können dann wie DNS-Probleme aussehen, obwohl die Root Cause fehlender Speicherplatz ist.

Merksatz:

Bei gleichzeitig kippenden Diensten: erst Disk, dann Netzwerk.

Backup-Transfer und Monitoring sind getrennte Fehlerdomänen

Ein fehlgeschlagener Offsite-Transfer darf nicht still als vollständiger Backup-Erfolg behandelt werden. Lokal erfolgreich und offsite erfolgreich sind zwei getrennte Zustände und sollten separat überwacht werden.

Auch Monitoring-Schwellen ersetzen keine Kapazitätsrechnung: Ein Alarm bei hoher Belegung schützt nicht automatisch vor einem strukturell zu großen Backup-Fenster.

SQLite/WAL und laufende Datenbanken

Bei SQLite-basierten Diensten müssen WAL-/SHM-Dateien beziehungsweise ein konsistenter Datenbankzustand in der Restore-Strategie berücksichtigt werden. Ein bloßes Kopieren der Hauptdatei kann unvollständig sein.

Bei anderen Datenbanken sind native Dump-/Restore-Mechanismen gegenüber rohen Dateikopien zu bevorzugen, sofern der Dienst dies unterstützt.

Offsite bedeutet getrennte Schadensdomäne

Ein Offsite-Backup sollte nicht im selben physischen und administrativen Ausfallbereich liegen wie die Primärdaten. Für Nomon wird diese Idee zusätzlich um technisch erzwungenes Append-only erweitert: nomon-offsite-backup-append-only.

Vinted AIgent – Automatisiertes Inserieren

Ziel

Der Vinted AIgent automatisierte den Weg von Produktfotos zu einem vorbereiteten Vinted-Inserat mit möglichst wenig manueller Arbeit.

Nachgewiesener früherer Ablauf

Der End-to-End-Flow funktionierte zeitweise unter Windows:

1. Fotos wurden über Matrix übergeben.
2. KI analysierte die Produktdaten.
3. Angaben konnten im Chat bestätigt oder korrigiert werden.
4. Ein lokales Playwright-Skript füllte das Vinted-Formular aus.
5. Das Ergebnis wurde vor dem Veröffentlichen kontrolliert.

Die Automatisierung befüllte unter anderem Kategorie, Marke, Größe, Zustand, Farbe, Material, Preis und Versandgröße.

Architekturprinzipien

• Orchestrierung und Kommunikation waren von der eigentlichen Browserautomation getrennt.
• Das Browser-Skript lief bewusst in einer normalen Desktop-Browserumgebung statt als direkter API-Client.
• Veröffentlichung blieb als menschlicher Kontrollpunkt erhalten; der technische Flow konnte Entwürfe vorbereiten.
• Tokens und Sessiondaten gehören nicht in die Dokumentation, sondern in eine Secret-Ablage.

Warum das Projekt pausiert ist

Die frühere Ausführungsumgebung war an Windows gebunden; nach dem Wechsel zu Fedora fiel dieser Betriebsweg weg.

Der wichtigste ungelöste technische Blocker war die kurze beziehungsweise unzuverlässige Lebensdauer der Vinted-Browser-Session. Regelmäßiger manueller Cookie-Export widersprach dem Ziel einer wartungsarmen Automatisierung.

Offene Architekturfragen bei einer Wiederaufnahme

• Browserautomation lokal auf Fedora oder headless auf einem Server betreiben?
• Session-/Login-Erneuerung als bewussten Wartungsschritt akzeptieren oder technisch neu lösen?
• Browserautomation weiterhin verwenden oder einen anderen Integrationsweg wählen?
• CLI beibehalten oder eine kleine Desktop-Oberfläche ergänzen?

Bleibendes Learning

Eine funktionierende Browserautomation ist noch keine dauerhaft autonome Lösung. Session-Lebensdauer, Login-Erneuerung, menschliche Freigabepunkte und die tatsächliche Betriebsumgebung sind Teil der Architektur und müssen von Anfang an mitbewertet werden.