AnalyseDeCircuit/oxideterm

OxideTerm-Knotensitzungsbesitz

Verwenden Sie diesen Skill immer dann, wenn eine Änderung die Komponente verändern kann, die eine entfernte Sitzung oder einen Hintergrundjob erstellt, teilt, schließt, neu verbindet oder beobachtet.

Kerninvariante

Ein verbundener SSH-Knoten ist unabhängig von jedem Terminalfenster, das ihn nutzt. Die UI-Lebensdauer darf nicht stillschweigend zur Backend-Lebensdauer werden.

flowchart TD
    W["Workspace- oder Anwendungslebensdauer"] --> R["NodeRouter und Verbindungsregister"]
    R --> N["Physische SSH-Knotenverbindung"]
    N --> T["Terminalverbraucher"]
    N --> S["SFTP-Verbraucher"]
    N --> F["Weiterleitungsverbraucher"]
    R --> H["Gesundheits- und Wiederverbindungsjobs"]

Verbindliche Regeln

• Die Knotenlebendigkeit gehört dem Verbindungsregister, NodeRouter oder einer expliziten Knotentrennoperation.
• Das Schließen eines Terminalfensters entfernt diesen Terminalverbraucher. Es darf einen gemeinsamen Knoten nicht trennen.
• SFTP muss eine echte knotengestützte SFTP-Sitzung erwerben. Ein Shell-Befehl, der eine Dateiübertragung imitiert, ist nur ein dokumentierter Kompatibilitätsfallback.
• Die Portweiterleitung besitzt ihre Listener- und Bridge-Tasks. Diese Tasks müssen ohne geöffnetes Terminalfenster lebendig bleiben und stoppen, wenn die Weiterleitungsregel oder der besitzende Knoten stoppt.
• Wiederverbindung, Gesundheitschecks, Gnadenfristen und Child-Process-Bridges benötigen einen expliziten Besitzer und einen Abbruchpfad, der an die Lebensdauer des Knotens, Workspace oder der Anwendung gebunden ist.
• Langlebige Arbeit darf nicht auf einer einmaligen Laufzeit ausgeführt werden, die verworfen wird, wenn ein Befehlshandler zurückkehrt.
• Ein untergeordneter Knoten, der über einen Sprunghost verbunden ist, muss die übergeordnete Verbindung so lange behalten, wie der untergeordnete Transport sie benötigt.
• UI-Komponenten beobachten den Laufzeitzustand über Router- oder Registerereignisse. Sie dürfen die Knotenlebendigkeit nicht aus der Existenz eines Terminals ableiten.
• Fügen Sie prägnante englische Kommentare bei Besitzübertragungen hinzu: Erstellung, Freigabe, Ungültigmachung, Wiederbeschaffung, Abbruch und bewusstes Überleben nach UI-Abbau.

Verbotene Umgehungen

• Öffnen Sie keinen zweiten, nicht verwalteten SSH-Transport, nur weil eine knotengestützte API unpraktisch ist.
• Finden Sie keine Verbindung durch Auswahl des ersten Terminalfensters, das einem Host zugeordnet ist.
• Speichern Sie einen langlebigen Task nur in einem temporären Dialog, Befehlshandler oder Terminal-View.
• Markieren Sie einen Knoten nicht als getrennt, nur weil ein Kanal, Fenster, eine SFTP-Anforderung oder ein Weiterleitungsverbraucher geschlossen wird.
• Lassen Sie erzeugte Child-Prozesse oder Tokio-Tasks nicht ohne ein Herunterfahrsignal und einen begrenzten Abschlusspfad losgelöst zurück.

Empfohlene Praktiken

• Drücken Sie jede Backend-Abhängigkeit als Verbraucher oder Besitzer im Register aus, anstatt sich auf zufällige Arc-Beibehaltung zu verlassen.
• Halten Sie den physischen Transportzustand im Verbindungseintrag und die logische Topologie im NodeRouter.
• Lassen Sie Trennkaskaden aufgezeichneten Eltern-Kind-Verbindungsidentitäten folgen, nicht passenden Host-Strings.
• Halten Sie Task-Handles oder Abbruchsender auf dem Objekt, dessen Lebensdauer den Job definiert.
• Bevorzugen Sie ereignisgesteuerte UI-Updates gegenüber dem Abfragen des Terminalzustands.

Kompatibilitätspfade

Kompatibilitätsfallbacks sind nur erlaubt, wenn sie explizit, begrenzt und genau gemeldet werden. Sie dürfen nicht als native SFTP-, Weiterleitungs- oder Knotensitzungsimplementierung beschrieben werden. Zeichnen Sie den Besitzer und den Bereinigungspfad auch für temporäre Fallbacks auf.

Beispiele

Falsch:

// Durch Schließen des Fensters wird versehentlich der einzige Besitzer des gemeinsamen Knotens zerstört.
struct TerminalPane {
    ssh_transport: SshTransport,
}

Richtige Form:

// Das Fenster besitzt nur seine Verbraucherregistrierung; das Register besitzt die Transportlebendigkeit.
struct TerminalPane {
    connection_id: String,
    terminal_consumer: ConnectionConsumer,
}

Falsch:

tokio::runtime::Runtime::new()?.spawn(run_forward_listener());
// Die Laufzeit wird verworfen, wenn der Befehl zurückkehrt.

Richtige Form:

// Der Weiterleitungsbesitzer behält sowohl Abbruch- als auch Abschluss-Handles.
struct ForwardingJob {
    shutdown_tx: Option<oneshot::Sender<()>>,
    worker: JoinHandle<()>,
}

Überprüfungscheckliste

1. Identifizieren Sie den physischen Verbindungsbesitzer.
2. Listen Sie jeden Terminal-, SFTP-, Weiterleitungs-, Wiederverbindungs-, Gesundheits- und Child-Node-Verbraucher auf.
3. Stellen Sie sicher, dass das Schließen eines Verbrauchers nicht nicht verwandte Verbraucher schließt.
4. Stellen Sie sicher, dass das explizite Trennen des Knotens abhängige Jobs und Child-Transports stoppt.
5. Überprüfen Sie jeden erzeugten Task oder Prozess auf einen beibehaltenen Besitzer, ein Abbruchsignal und einen Bereinigungspfad.
6. Überprüfen Sie, dass der UI-Zustand Knotenereignisse konsumiert und nicht von der Terminalabgeleiteten Lebensdauer abhängt.
7. Geben Sie alle verbleibenden Kompatibilitätsfallbacks präzise an.

Verifikation

• Schließen Sie das letzte Terminal und beweisen Sie, dass der Knoten für einen anderen registrierten Verbraucher nutzbar bleibt.
• Öffnen Sie SFTP, ohne ein Terminalfenster zu benötigen.
• Starten Sie lokale, entfernte und dynamische Weiterleitungen und überprüfen Sie, ob Listener das Schließen des Fensters überleben.
• Trennen Sie einen übergeordneten Knoten und überprüfen Sie, ob abhängige Child-Knoten und Jobs konsistent übergehen.
• Verbinden Sie sich innerhalb der Gnadenfrist erneut, ohne nicht verwandte UI-Zustände zu verlieren.
• Bestätigen Sie, dass die Task-/Prozessbereinigung nach explizitem Trennen und Anwendungsherunterfahren abgeschlossen wird.