Technische Übersicht des Portable Bridge Workspace

1. Systemzweck

Das Projekt schafft eine portable Bridge zwischen lokaler Entwicklung, privater Versionsverwaltung und ausgewählter öffentlicher Publikation. Das entfernbare Laufwerk enthält Arbeitskopien, das Repo-Hub-Menü, Hilfsskripte und Übergabenotizen. Der VPS hostet die private Git-Forge und dient als dauerhafte Heimatbasis. Für Arbeit, die als Open Source oder öffentlich vorgesehen ist, bleibt ein öffentlicher Code-Host verfügbar.

Vertrauenswürdige Workstation
  -> entfernbarer Bridge-Arbeitsbereich
  -> SSH-Helfer
  -> privater VPS
  -> private Git-Forge

Ausgewählte öffentliche Repositories
  -> private Forge
  -> öffentlicher Code-Host bei bewusster Freigabe

2. Speicherrollen

• Das entfernbare Laufwerk ist die portable Werkbank und Übergabestelle.
• Der VPS ist die private Quelle der Wahrheit für Projektgeschichte und gehostete Dienste.
• Der öffentliche Code-Host wird nur für bewusst öffentliche Repositories verwendet.
• Grosse generierte Artefakte bleiben ausserhalb des Bridge-Arbeitsbereichs, sofern sie nicht für aktive Arbeit gebraucht werden.

3. Vertrauensmodell

Das entfernbare Laufwerk führt absichtlich SSH-Identitätsmaterial für diesen Workflow mit. Diese Entscheidung tauscht Komfort und Portabilität gegen das physische Risiko des Laufwerks. Das Design setzt voraus, dass das Laufwerk als sensibler Gegenstand behandelt wird und ausserhalb davon ein separater Wiederherstellungsweg existiert.

• Private Schlüssel, Tokens, Passwörter oder Wiederherstellungsmaterial nie ausgeben.
• Einen getrennten administrativen Wiederherstellungsweg ausserhalb des entfernbaren Laufwerks aufbewahren.
• Bei Verlust des Laufwerks dessen autorisierten öffentlichen Schlüssel widerrufen und die Identität ersetzen.
• Provider-API-Zugangsdaten rotieren, wenn das Laufwerk verloren geht oder in eine nicht vertrauenswürdige Umgebung kopiert wurde.
• Öffentliche Dokumentation frei von Provider-, Konto- und Adressierungsdetails halten.

4. Repository-Modell

Jedes aktive Projekt ist ein gewöhnliches Git-Repository. Das Remote der privaten Forge dient der VPS-gestützten Versionsgeschichte. Repositories, die zusätzlich öffentlich sein sollen, können ein öffentliches Remote behalten und Dual-Push bewusst einsetzen.

Projekt-Arbeitskopie
  Remotes:
    private -> private VPS-Forge
    public  -> öffentlicher Code-Host, falls zutreffend

Push-Richtlinie:
  private Arbeit      -> privates Remote
  öffentliche Arbeit -> öffentliches Remote mit bewusst konfiguriertem Dual-Push

Die entscheidende Regel lautet, dass Publikation ausdrücklich erfolgt. Private Arbeit kann auf den VPS gelangen, ohne öffentlich zu werden.

5. Repo-Hub

Repo-Hub ist die zentrale Bedienoberfläche dieses Workflows. Bevor eine vertrauenswürdige Maschine oder ein Coding-Agent die Projektgeschichte verändert, soll dies die erste Anlaufstelle sein.

Das Terminal-Menü entdeckt Repositories im Arbeitsbereich und zeigt Branch, Upstream, unsauberen Zustand, Remote-Konfiguration und Push-Bereitschaft. Es kann auch Pull-, Push- und Commit-Push-Workflows ausführen.

• Statusbefehle sind sicher und verändern nichts.
• Bulk-Push überspringt unsaubere Repositories.
• Commit-Push verlangt eine ausdrückliche Commit-Nachricht und Bestätigung.
• Unsaubere Arbeitsbäume sind sichtbar, bevor verändernde Aktionen beginnen.
• Das Menü hält Übergabeentscheidungen aus dem Gedächtnis heraus und im Arbeitsbereich fest.

6. Provider-API-Schicht

Die Bridge kann Provider-API-Zugriff für eng begrenzte Aufgaben der Steuerungsebene mitführen. Der wichtigste Anwendungsfall ist DNS: Records aktualisieren, veraltete Hosting-Ziele entfernen und bestätigen, dass die öffentliche Domain auf den VPS zeigt. Eine getrennte Server-Control-API kann später für Snapshots, Ein- und Ausschaltvorgänge, Inventar oder Notfallwiederherstellung ergänzt werden.

Diese Schicht ersetzt weder SSH noch Git. Sie wird verwendet, wenn ein Vorgang zum Provider-Konto und nicht zum Linux-Server gehört.

• DNS-Änderungen gehören in die Provider-API-Schicht.
• Serverdateien, Dienste und Deployments gehören zu SSH.
• Projektgeschichte gehört zu Git.
• Öffentliche Dokumentation muss das Modell beschreiben, ohne Tokenmaterial offenzulegen.

7. Rolle der Website

Die Website ist ein Projekt innerhalb desselben Workflows. Sie kann lokal gebaut, zur privaten Forge gepusht und später über den VPS oder ein anderes gewähltes Publikationsziel ausgeliefert werden. Eine Live-Vorschau kann bestehen, ist für lokale Bearbeitung aber nicht erforderlich.

8. Betriebliche Grenzen

• Der Chatverlauf ist nicht die Quelle der Wahrheit.
• Die Dokumentation des Bridge-Arbeitsbereichs ist das lokale Betriebsgedächtnis.
• Die private Forge ist die dauerhafte Projektgeschichte.
• Die Provider-API-Schicht dient DNS und Steuerung auf Kontoebene, nicht der normalen Projektbearbeitung.
• Öffentliche Dokumentation darf keine privaten Infrastrukturdetails offenlegen.
• Destruktive Git- oder Serveroperationen brauchen eine ausdrückliche Absicht.

9. Fehlermodi

• Wenn das entfernbare Laufwerk nicht verfügbar ist, Projekte aus der privaten Forge klonen.
• Wenn der VPS nicht verfügbar ist, lokal weiterarbeiten und nach seiner Rückkehr pushen.
• Wenn der öffentliche Host ausfällt, kann private Arbeit weiterhin über die VPS-Forge übertragen werden.
• Wenn das entfernbare Laufwerk verloren geht, seinen SSH-Zugriff vor der Fortsetzung widerrufen.
• Wenn Provider-API-Zugangsdaten offengelegt worden sein könnten, diese vor weiterer Automatisierung auf Provider-Ebene rotieren.