Anleitung zur Quellcode-Vorschau · 0.1.0

Wiederherstellen und das ursprüngliche Ergebnis erhalten

Finde die betroffene Verbindung, Berechtigung, Quelle, Scanner- oder Jobgrenze und nutze deren Wiederherstellung ohne Austausch der Installationsidentität.

Die API-Referenz ist auf Englisch.

Bewahre die Identität der Arbeit

Beginne mit dem sichtbaren Fehler und der genannten Ressource. Erhalte Installationszustand, Endpunkt, Editorprofil sowie Projekt-, Scan-, Job- und Befehlskennungen. Ein neues Zustandsverzeichnis erzeugt eine andere Installation; es stellt Mitglieder oder Ergebnisse der alten nicht wieder her.

Ein fehlgeschlagener Abruf unterscheidet sich von einem leeren Ergebnis. Findings, Settings und Jobs erhalten zuvor geladene Informationen bei späteren Aktualisierungsfehlern. Diese Ansicht liefert Kontext; für eine aktuelle Entscheidung ist jedoch ein neuer erfolgreicher Abruf nötig.

Stelle die vorgesehene Verbindung her

Prüfe, ob lomoCodeSecurity.apiBaseUrl auf die vorgesehene Installation zeigt. Standard ist http://127.0.0.1:8080; ein anderer Port ist eine andere Origin. Änderungen erfordern erneutes Verbinden mit diesem Ziel. Die Erweiterung sendet die Berechtigung der alten Origin nicht an die neue.

Nutze den unterstützten Quellstart mit demselben Installationszustand. Sobald der Dienst verfügbar ist, versucht Reconnect to Local Service die bestehende Profilverbindung erneut. Wurde die Mitgliedschaft widerrufen oder ist sie inaktiv, verwende Connect / Review IDE Access. Reconnect genehmigt kein Mitglied und erteilt keinen Quellzugriff.

Folge bei nicht verfügbarem Eigentümerbrowser dem Authentifizierungs-Wiederherstellungsablauf. Halte einmalige Werte geheim. Eine fehlende Browsersitzung rechtfertigt weder das Kopieren von Editorzugangsdaten noch das Neuanlegen aller Clients.

Der automatische native Windows-Start hat in der öffentlichen Vorschau einen dokumentierten Timeout bei der Prüfung privaten Speichers. Ein erfolgreicher manueller Refresh beweist keine Reparatur des automatischen Starts. Lies den festgeschriebenen Release-Status zu Plattformgrenzen, bevor du einen Workaround als Abnahme behandelst.

Repariere nur den beschädigten Berechtigungsdatensatz

Die lokale Reparaturaktion bestätigt genaue unveränderte Profildateien mit nachgewiesener Beschädigung. Remove invalid record in Settings betrifft eine ungültige serverseitige Mitgliedschaftszeile. Dies sind separate Operationen; keine führt die andere stillschweigend aus.

Erhalte unbekannte oder geänderte Dateien zur Diagnose. Kopiere keine fremden Profilberechtigungen, lockere keine Verzeichnisrechte und entferne nicht sämtliche Datensätze zur Umgehung des gemeldeten Zustands. Neueinschreibung erzeugt eine neue Generation; klonspezifischer Push-Schutz muss für sie erneut genehmigt und angewandt werden.

Gleiche Quellen und veraltete Editornachweise ab

Repository-Auswahl, Registrierung und Hostautorisierung sind getrennt. Prüfe die genaue enge Wurzel, die das Produkt anbietet, und wende nur die beabsichtigte Quellautorisierung an. Einen Ordner zu VS Code hinzuzufügen oder ein untergeordnetes Repository auszuwählen autorisiert keinen breiteren Elternordner.

Nach Bearbeiten, Umbenennen oder Löschen von Quellen können frühere Diagnosen veraltet markiert oder entfernt werden. Speichere den vorgesehenen Inhalt und scanne genaue Datei, Ordner oder Repository erneut. Refresh Findings lädt bestehende Ergebnisse und scannt keine Änderungen. Ungespeicherte Puffer sind keine Scannereingaben.

Kann ein genauer Dateirescan das kanonische Quellziel nicht bestimmen, kläre den Quellkontext, statt eine ähnlich benannte Datei einzusetzen. Historische Befunde eines festgehaltenen Baums bleiben an diesen gebunden.

Stelle Scannerbereitschaft wieder her

Öffne Tools und prüfe jede benötigte Komponente. Warte während Verifying auf den Abschluss der Inhaltsprüfung. Bereitschaftswarnung und harte Ablaufgrenze sind verschieden: Geprüfte Daten warnen nach sieben Tagen und haben vierzehn Tage harte Gültigkeit. Unveränderliche quellverwaltete Regeln folgen ihrem geprüften Lock statt einer erfundenen Altersgrenze.

Nutze Prepare all scanners für die normale vollständige Vorbereitung. Eine Komponente mit requires_lock_refresh benötigt aktualisierten geprüften Quellcode und Datenlock. Wiederholtes Herunterladen unter derselben abgelaufenen Berechtigung repariert sie nicht.

Wähle die zum Fehler passende Aktion:

• Retry verification wiederholt eine geeignete fehlgeschlagene Beobachtung des unveränderten Cache-Ziels. Es lädt nichts herunter und repariert keine ungültigen Bytes.
• Check cache outcome untersucht eine unklare Veröffentlichung über einen separaten begrenzten schreibgeschützten Job. Die ursprüngliche Vorbereitung bleibt fehlgeschlagen.
• Roll back cache unter Advanced scanner maintenance wählt nur eine geeignete zuvor gute Generation, wenn Inhalt, Berechtigung, Kompatibilität und Aktualität weiterhin bestehen. Es umgeht keinen Ablauf und ändert keine Scanner-Image-Binärdateien.

Normale vollständige Vorbereitung kann eine beschädigte einzige ausgewählte Generation ersetzen, wenn ihr Zeiger gültig bleibt, keine zuvor gute Generation existiert und alle sechs Daten-/Regelkomponenten angefordert werden. Der vollständige Ersatz benötigt Platz neben den alten Daten. Unsichere Strukturen, fehlerhafte Zeiger und Teilreparaturen werden abgelehnt. Bewahre Nachweise, statt Generationszeiger, Eigentum oder Rechte manuell zu ändern.

Die Scananleitung erklärt Vorbereitung und Abdeckung. Ein begrenzter Scan bleibt teilweise und ist keine Wiederherstellungsabkürzung zu einem bestandenen vollständigen Gate.

Kehre zu unklaren Jobs und Speicheraktionen zurück

Öffne Jobs, suche die ursprüngliche Aufgabe und aktualisiere sie. Verwende bei nicht verfügbarer Verarbeitung make up im Produktcheckout, warte auf Worker-Gesundheit und prüfe denselben Job erneut. Wiederhole nur eine geeignete Aufgabe im Endzustand mit angebotener Retry-Aktion.

Stelle für Settings die Verbindung wieder her und nutze Reload Settings. Bearbeitete Abschnitte erhalten Entwürfe, unberührte laden aktuelle Werte. Ein unsicheres Speichern kann das Backend bereits erreicht haben. Vergleiche den gespeicherten Zustand vor erneutem Einreichen. Ein Revisionskonflikt verlangt eine neue Entscheidung anhand aktueller Werte.

Auch Abbruch hat ein zu klärendes Ergebnis. Warte auf abschließende Bereinigung: Schließen einer Seite bricht keine Arbeit ab; Abbruch macht veröffentlichte Scannerdaten nicht rückgängig und holt entfernte Advisor-Inhalte nicht zurück. Die Job-Anleitung behandelt diese Unterschiede und API-Idempotenz.

Interpretiere API-Fehler im Kontext

Control-Validierungsfehler verwenden ein bereinigtes detail-Array mit type, loc und msg, ohne eingereichte Werte. Andere Fehler können einen String oder strukturierte Problemdetails verwenden. Lies den Antwortvertrag der genauen Operation.

Die API-Referenz verknüpft routenspezifische Fehler mit Quellcode. Diese Tabelle hilft bei der Wiederherstellung und behauptet nicht, dass jede Route jeden Status liefert.

Bewahre Nachweise für den Support

Notiere öffentliche Quellrevision, Plattform, betroffene Operation, nicht geheime Ressourcenidentität, erwartetes Verhalten und eine minimale synthetische Reproduktion. Prüfe Diagnoseausgaben vor dem Teilen. Schließe Laufzeitzugangsdaten, Cookies, Kopplungswerte, private Repositories und ungeprüfte Logs aus.

Die Installation hält dauerhaften Datenbankzustand und unterstützte bereinigte Artefakte getrennt von temporärer Scannerausgabe und Wiederherstellungsspool. Lies vor Speicherwiederherstellung die festgeschriebene Persistenzanleitung. Nutze Support für Produktfragen und den Sicherheitsmeldekanal für mögliche Schwachstellen.