Kann Cursor Start from Scratch direkt live gehen? Abnahme-Checkliste 2026

Symptom: Die Browser-Vorschau funktioniert, aber niemand kann belastbar sagen, welcher Code, welche Zugangsdaten und welche Umgebung dahinterstehen.
Schnellste Lösung: Behandeln Sie Cursor Start from Scratch zunächst als Prototyp und geben Sie ihn erst nach Repository-Übergabe, reproduzierbarem Build, automatisierten Tests, isolierten Schlüsseln, manueller Prüfung und verifiziertem Rollback für den produktiven Betrieb frei.

Diese Vorgehensweise gilt für Webanwendungen, interne Werkzeuge und Produktideen, die mit Cursor Cloud Agents ohne vorhandenes Quellcode-Repository entstehen. Wenn Ihr Projekt Xcode, Apple SDKs oder eine andere macOS-spezifische Toolchain benötigt, gehört die tatsächliche Build- und Signaturprüfung in eine getrennte Mac-Umgebung.

Für wen diese Abnahme relevant ist

Sie entwickeln allein und möchten eine Idee ohne bestehende Repository-Struktur schnell demonstrieren? Dann hilft Ihnen die Checkliste, eine funktionierende Oberfläche nicht mit einem wartbaren Projekt zu verwechseln.

Sie arbeiten in einem AI-Startup oder als Plattformverantwortlicher? Dann erhalten Sie klare Übergabepunkte für Repository, Berechtigungen, CI/CD, Geheimnisse und Produktionsfreigabe.

Wichtiger Prüfstand: Für diesen Beitrag wurden die offiziellen Angaben zu Start from Scratch, Origin und Cloud Agents zuletzt am 28.08.2026 gegen Cursor-Änderungsprotokoll, Origin-Dokumentation und Cloud-Agents-Dokumentation abgeglichen. Origin ist dabei weiterhin als „early beta“ einzuordnen. Eine funktionierende Vorschau ist keine Zusicherung für Sicherheit, Tests, Compliance, Verfügbarkeit oder eine bestimmte macOS-Buildfähigkeit.

Abnahmeziel statt bloßer Vorschau

Vor dem ersten Prompt legen Sie fest, welches Ergebnis überhaupt als bestanden gilt. Eine einmalige Präsentation benötigt eine andere Prüfung als ein internes Werkzeug mit echten Unternehmensdaten. Ein öffentlich erreichbarer Dienst braucht zusätzlich belastbare Betriebs-, Datenschutz- und Rückfallregeln.

Dokumentieren Sie vor der Generierung mindestens diese Punkte:

• Zweck: Einmalige Demo, internes Werkzeug, begrenzter Pilot oder öffentlicher Produktionsdienst.
• Technik: Framework, Laufzeit, Paketmanager, Datenbank, Build-Befehl und Zielplattform.
• Daten: Nur Beispieldaten, interne Informationen oder personenbezogene Daten nach DSGVO-Anforderungen.
• Abhängigkeiten: Externe APIs, Authentifizierung, Zahlungsdienste, Dateispeicher und E-Mail-Versand.
• Betrieb: Zielumgebung, DNS, Logging, Backup, Monitoring und verantwortliche Person.
• Apple-Bezug: Abhängigkeit von Xcode, Apple SDKs, Signatur, Simulator oder anderen macOS-Komponenten.

„Die Seite öffnet sich im Browser“ ist nur ein Prototyp-Signal. Als Produktionskriterium zählen dagegen nachvollziehbare Dateien, reproduzierbare Befehle, getestete Fehlerpfade und eine dokumentierte Verantwortungskette.

Eine kurze Abnahme-Checkliste für AI-Coding-Prototypen kann als ergänzende interne Vorlage dienen. Entscheidend ist jedoch, dass Sie die Kriterien an Ihr Datenrisiko und den vorgesehenen Betrieb anpassen.

Generierungsphase: vom Agent-Kontext zur Projektstruktur

Cursor Start from Scratch kann nach der offiziellen Produktbeschreibung einen Cloud Agent starten, ohne dass zunächst ein verbundenes Drittanbieter-Repository vorhanden ist. Dabei kann ein Origin-Projekt entstehen, und die Anwendung lässt sich in einer Browser-Vorschau prüfen. Diese bestätigten Funktionen beantworten aber nur die Frage, wie ein Projekt beginnt — nicht, ob es bereits als Softwareprodukt übergeben werden kann.

Nach der ersten Generierung prüfen Sie deshalb, ob eine andere Person das Ergebnis ohne den ursprünglichen Agent-Kontext übernehmen kann. Öffnen Sie die Dateien nicht nur in der Vorschau, sondern lesen Sie die Projektwurzel und die Einstiegspunkte.

Ihre erste Übergabeprüfung besteht aus fünf konkreten Nachweisen:

1. Verzeichnisstruktur: Sie erkennen Anwendungscode, Konfiguration, Tests, statische Dateien und Dokumentation ohne Rückfrage.
2. Abhängigkeitsliste: Alle Pakete stehen in den vorgesehenen Manifest- und Lock-Dateien; versteckte Installationen oder manuell nachinstallierte Komponenten werden entfernt.
3. Start- und Build-Befehle: Eine README beschreibt Installation, lokale Ausführung, Test, Build und notwendige Umgebungsvariablen.
4. Gespeicherte Geschäftslogik: Entscheidende Regeln liegen in versionierten Dateien und nicht nur in einem Prompt, einer Sitzung oder einem temporären Laufzeitzustand.
5. Änderungsnachweis: Sie können die vom Agent vorgenommenen Dateien einzeln prüfen und erklären, warum jede relevante Änderung erforderlich ist.

Achten Sie besonders auf scheinbar harmlose Platzhalter. Beispielschlüssel, Testkonten, hartcodierte Rollen, unechte Zugriffskontrollen und mitgelieferte Testdaten dürfen nicht versehentlich in ein späteres Repository gelangen. Suchen Sie vor der Übergabe nach typischen Geheimnisnamen wie API_KEY, TOKEN, SECRET, privaten Zertifikaten und Zugangsdaten in Konfigurationsdateien. Entfernen Sie nicht nur den sichtbaren Wert, sondern prüfen Sie auch Verlauf, Build-Artefakte und generierte Logs.

Die Antwort auf die Frage, wie Sie ein Projekt ohne vorhandenes Repository speichern, lautet daher nicht „mit einem Screenshot der Vorschau“. Sie benötigen einen vollständigen Dateiexport, eine lokale oder isolierte Kopie, ein dokumentiertes Installationsverfahren und anschließend ein Repository, das unabhängig vom Agent-Kontext funktioniert.

Browserprüfung: Oberfläche gegen echte Funktion

Die Vorschau ist der erste ausführbare Meilenstein, aber sie kann mehrere Ebenen vermischen. Ein sichtbarer Port oder eine bereitgestellte Oberfläche beweist noch nicht, dass Serverlogik, Persistenz und externe Dienste korrekt zusammenarbeiten.

Prüfen Sie die Anwendung in dieser Reihenfolge:

1. Statische Oberfläche: Navigation, responsive Darstellung, leere Zustände, Ladeanzeigen und Fehlermeldungen.
2. Serverlogik: Authentifizierung, Autorisierung, Validierung, Fehlercodes und Verhalten bei fehlenden Parametern.
3. Persistenz: Erstellen, Lesen, Ändern und Löschen; danach Browser-Refresh, neuer Prozess und erneuter Login.
4. Externe Schnittstellen: Timeout, ungültige Antwort, Rate Limit, abgelaufener Schlüssel und nicht erreichbarer Dienst.
5. Zustandswechsel: Normaler Eingang, absichtlich fehlerhafte Eingabe, parallele Aktionen und Wiederanlauf nach einem Neustart.

Verwenden Sie dafür mindestens drei Testklassen: einen gültigen Standardfall, einen ungültigen oder missbräuchlichen Eingang und einen Neustartfall. Schreiben Sie nicht nur „funktioniert“ in ein Ticket. Speichern Sie Screenshots, Build- und Laufzeitprotokolle, Testausgaben, verwendete Beispieldaten und die genaue Revision des erzeugten Codes.

Die Anwendung geht zurück in die Generierungsphase, wenn ein Neustart Daten verschwinden lässt, die Vorschau nur mit einem offenen Agent-Kontext funktioniert, Fehlermeldungen keine verwertbare Ursache nennen oder externe API-Schlüssel im Frontend landen. Ein Projekt kann für eine Demo ausreichend sein und trotzdem für einen internen Piloten ungeeignet bleiben.

Origin-Übergabe und Verantwortlichkeit

Cursor Origin als Übergabepunkt

Bei einem Cursor-Origin-Projekt müssen Sie vor dem Go-live klären, wer Eigentümer des Projekts ist, wer Änderungen prüfen darf und welche Personen Integrationen verwalten. Die offizielle Origin-Dokumentation beschreibt den Produktkontext und den Beta-Status; sie ersetzt jedoch nicht Ihre interne Verantwortungsmatrix.

Prüfen Sie vor dem ersten Baseline-Commit:

• Repository-Eigentümer und Organisation stimmen mit dem geplanten Betrieb überein.
• Sichtbarkeit ist bewusst auf privat, intern oder öffentlich gesetzt.
• Mitglieder besitzen nur die für ihre Aufgabe erforderlichen Rechte.
• Privacy Mode und Agent-Zugriffe wurden für Quellcode, Logs und verbundene Dienste geprüft.
• Mindestens eine zweite Person kann Pull Requests prüfen und eine fehlerhafte Änderung ablehnen.
• Integrationseinstellungen können nicht unbemerkt von einer einzelnen Person geändert werden.

Die Sicherheitsdokumentation für Cursor Cloud Agents ist die passende Referenz, um Zugriff, Ausführung und Geheimnisbehandlung gegen Ihre eigene Risikobewertung zu halten. Sie sollten dabei zwischen drei Bereichen unterscheiden: dem Agent-Kontext, der Cloud-Ausführungsumgebung und dem Repository. Eine Berechtigung in einem Bereich bedeutet nicht automatisch, dass eine andere Person den Code kontrolliert oder ein Build reproduzieren kann.

Git-Grundtest

Führen Sie die Übergabe mit Standard-Git-Abläufen aus, nicht nur über die ursprüngliche Produktoberfläche. Klonen Sie das Repository in ein leeres Verzeichnis, installieren Sie die Abhängigkeiten und prüfen Sie, ob Branch, Commit-Historie und relevante Dateien vollständig vorhanden sind. Die Syntax und das Verhalten von git clone können Sie in der offiziellen Git-Dokumentation gegenprüfen.

Der Prüfablauf lautet:

1. Repository in ein neues Verzeichnis klonen.
2. Aktuellen Commit und Branch dokumentieren.
3. Abhängigkeiten ausschließlich aus den versionierten Dateien installieren.
4. Eine kleine, nachvollziehbare Änderung vornehmen.
5. Commit erstellen und in einen Test-Branch pushen.
6. Pull Request mit manueller Prüfung öffnen.
7. Änderung zurücksetzen oder über einen definierten Revert wiederherstellen.

Scheitert einer dieser Schritte, bleibt das Projekt ein verwalteter Prototyp und wird nicht in die nächste Stufe überführt. Der erste Baseline-Commit erhält eine menschliche Freigabe mit Datum, geprüften Dateien, bekannten Einschränkungen und der Entscheidung „Demo“, „Pilot“ oder „zurückgestellt“.

Entscheidungsrahmen für die nächste Stufe

Die folgende Gegenüberstellung verhindert, dass ein einzelnes positives Signal die übrigen Risiken überdeckt:

Verwenden Sie die Spalten als Rückfallregeln: Erfüllt das Projekt nur die erste Spalte, bleibt es eine Demo. Sind Codeübernahme, Fehlerprüfung und isolierter Betrieb vorhanden, aber Rollback oder Rechteverwaltung noch unklar, ist ein limitierter Pilot die Obergrenze. Erst die letzte Spalte rechtfertigt eine Produktionsentscheidung.

CI/CD und unabhängiger Wiederaufbau

Cursor Cloud Agents dürfen nicht zur einzigen Umgebung werden, in der das Projekt funktioniert. Ein sauberer Wiederaufbau in einem neuen Verzeichnis zeigt, ob Lock-Dateien, Umgebungsvariablen, Datenbankschema, Build-Skripte und Systemabhängigkeiten wirklich dokumentiert sind.

Gehen Sie für die unabhängige Prüfung so vor:

1. Erstellen Sie eine neue, leere Arbeitsumgebung ohne Agent-Cache und ohne lokale Altdateien.
2. Klonen Sie die Baseline oder den geprüften Branch.
3. Installieren Sie nur die dokumentierten Laufzeit- und Entwicklungsabhängigkeiten.
4. Legen Sie Test-Geheimnisse über die CI/CD-Umgebung an, niemals durch Einchecken in das Repository.
5. Führen Sie Formatprüfung, statische Analyse, Unit-Tests und Build aus.
6. Prüfen Sie Sicherheitsmeldungen, Rechtekonfiguration, Abhängigkeiten und generierte Artefakte.
7. Starten Sie die Anwendung mit einer frischen Testdatenbank oder einem reproduzierbaren Schema.
8. Speichern Sie Logs, Testberichte, Commit-ID und Artefakt-Hash als Abnahmenachweis.

Für eine Veröffentlichung über eine Git-Integration müssen Sie außerdem kontrollieren, welches Repository verbunden ist, wer Deployments auslösen darf und ob ein Pull Request wirklich dieselben Prüfungen durchläuft wie ein manueller Start. Die Dokumentation zur Git-Integration beschreibt die technische Verbindung; die Freigaberegeln, Umgebungsgrenzen und Rückfallprozedur bleiben Ihre Betriebsverantwortung.

Ein wiederholbarer Build ist nicht dasselbe wie ein erfolgreicher lokaler Build. Wenn der erste Durchlauf nur wegen eines versteckten Caches, einer global installierten Bibliothek oder einer Agent-spezifischen Umgebungsvariablen gelingt, muss der Code zurück in die Übernahmephase.

Apple-Toolchain und getrennte Mac-Umgebung

Bei einem Webprojekt ohne Apple-Abhängigkeit können Sie den Produktionsbuild in der vorgesehenen Server- oder CI-Umgebung validieren. Für iOS- und macOS-Anwendungen, native Module oder Signaturprozesse reicht eine Browser-Vorschau dagegen nicht aus.

Planen Sie eine isolierte Mac-Umgebung ein, sobald mindestens eine dieser Bedingungen erfüllt ist:

• Xcode ist Teil des Build- oder Testbefehls.
• Apple SDKs oder Simulatoren werden benötigt.
• Das Projekt erzeugt ein signiertes App-Artefakt.
• Zertifikate, Provisioning-Profile oder Schlüsselbundzugriffe müssen geprüft werden.
• Ein natives Modul verhält sich auf macOS anders als in der Vorschau.

Prüfen Sie dort den vollständigen Ablauf: Repository klonen, Abhängigkeiten installieren, Projekt öffnen oder per Kommandozeile bauen, Tests ausführen, Signatur anwenden, Artefakt exportieren und das Ergebnis in einer sauberen Zielumgebung installieren. Die Apple-Dokumentation zur Erstellung signierter Mac-Code-Artefakte ist für die Signatur- und Exportseite maßgeblich.

Wenn Sie dafür keine geeignete lokale Maschine bereitstellen können, ist ein isolierter Mac-Build für Xcode und CI/CD der sinnvollere nächste Schritt als ein produktiver Start aus der Vorschau heraus. Trennen Sie dabei Quellcode, Build-Geheimnisse, Artefakte und Zugriffsrechte; ein gemeinsam genutzter, unkontrollierter Remote-Desktop ist keine belastbare CI/CD-Umgebung.

Freigabe, Pilot oder Rückgabe

Vor dem Veröffentlichen treffen Sie die Entscheidung anhand gespeicherter Nachweise:

Freigabe: Der Code ist unabhängig übernehmbar, der Build läuft in einer neuen Umgebung, Tests und Sicherheitsprüfungen sind in CI/CD verankert, Geheimnisse sind getrennt, Rechte sind nachvollziehbar und der Rollback wurde tatsächlich durchgeführt.

Limitierter Pilot: Die Kernfunktion ist stabil genug für eine kontrollierte Nutzergruppe, aber einzelne Betriebs- oder Skalierungsfragen sind noch offen. Begrenzen Sie Daten, Berechtigungen und Zugriff, und definieren Sie eine Person, die den Pilot jederzeit beendet.

Rückgabe: Das Projekt hängt am Agent-Kontext, die Abhängigkeiten sind unklar, Daten gehen nach einem Neustart verloren, ein Schlüssel ist im Code enthalten, die Pipeline baut nicht reproduzierbar oder niemand kann eine vorherige Version wiederherstellen.

In der ersten Betriebswoche sammeln Sie nicht nur Nutzungszahlen. Dokumentieren Sie fehlgeschlagene Agent-Aufgaben, manuelle Codekorrekturen, Build-Fehler, Umgebungsabweichungen, Rollback-Versuche und ungeklärte Berechtigungen. Diese Beobachtungen zeigen, ob AI Coding tatsächlich einen tragfähigen Entwicklungsprozess erzeugt oder nur die erste Demo beschleunigt.

Die von Cursor offiziell bestätigten Funktionen von Start from Scratch, Origin und Cloud Agents sollten Sie deshalb bei jeder relevanten Produktänderung erneut gegenprüfen. Besonders wichtig sind Änderungen am Beta-Status, an Repository-Strategien, Integrationen, Berechtigungen und dem Netzwerkmodell. Eine Produktaktualisierung ist kein Ersatz für Ihre eigene Abnahme.

Wenn Sie heute mit einem lokalen Einzelrechner oder einer gemeinsam genutzten Standardumgebung arbeiten, entstehen für diesen Übergang oft drei konkrete Nachteile: Die Build-Umgebung lässt sich nicht sauber von der Entwicklung trennen, Apple-Zertifikate und Schlüssel landen leichter im falschen Zugriffskontext, und ein zweiter reproduzierbarer Lauf fehlt genau dann, wenn der erste Build scheitert. Für kurzlebige Tests, isolierte Xcode-Läufe oder einen kontrollierten Übergang kann das Mieten eines Mac über MacPull deshalb übersichtlicher sein als die sofortige Anschaffung und dauerhafte Wartung eigener Hardware.

Lesen Sie vor der Übergabe die Hilfe zu Mac-Umgebungen und Zugriffsabläufen. Wenn Sie nur vorübergehend eine unabhängige Mac-Ausführungsumgebung für Build, Signatur oder CI/CD benötigen, können Sie damit zunächst den fehlenden Nachweis erbringen, ohne den gesamten Produktionsbetrieb auf eine ungeprüfte Agent-Vorschau zu stützen.