Ein Projekt anlegen und sein Repository verbinden

Ein Projekt ist das, worauf ein Agent gerichtet wird. Es lebt im aktiven Workspace und ist der Anker für alles Weitere: die Tasks, die du dagegen startest, und deren Runs, die Issues, die es importiert, und das Backlog, das sie speisen, die Workflows und Automatiken, die darauf wirken, seine eigenen Umgebungsvariablen und sein Container-Image sowie seine Richtlinie – wer daran arbeiten darf, wie weit unbeaufsichtigt, und wie viel es ausgeben darf. Vor allem trägt es die Credentials, die die Agenten benutzen: ein Git-Credential für das Repository und optional ein Tracker-Credential für eine Issue-Quelle.

Ohne Projekt läuft kein Agent. Ein Projekt anlegen darf jedes Mitglied des Workspace; das meiste, was du danach daran konfigurieren kannst, nicht.

Lege das Git-Credential zuerst an

Die Credential-Auswahl im Anlegen-Formular listet nur Credentials, die bereits existieren. Hinterlege eines unter Einstellungen → Git-Zugangsdaten, bevor du hier anfängst, und gib ihm Schreibrechte auf das Repository – ein Agent klont, committet und pusht einen Branch zurück. Die Scopes (persönlich, Workspace, Organisation) und wer gewinnt, stehen in Secrets in der Benutzeroberfläche verwalten.

Das Projekt anlegen

1. Öffne Projekte in der Seitenleiste und drücke Neues Projekt. Auf dem Telefon ist die Anlegen-Aktion der runde Knopf unten in der Liste. Du landest auf /projects/new.

2. Fülle die vier Felder in dieser Reihenfolge aus:

   • Name – so erscheint das Projekt in jeder Liste, und genau dieses Wort tippst du im Befehl run des Web-Terminals. Pflichtfeld.
   • Git Repo URL – Pflichtfeld. Beide URL-Formen werden akzeptiert; der Platzhalter zeigt die SSH-Form ssh://git@git.example.com:2222/org/repo.git.
   • Git Provider – Forgejo (Voreinstellung), Bitbucket, GitHub oder GitLab. Ein Wechsel setzt die Credential-Auswahl darunter zurück – wähle also erst den Provider, dann das Credential.
   • Git Credential – die Auswahl listet nur Credentials, die zum gerade gewählten Provider passen, jeweils mit ihrer Art beschriftet: (SSH Key) oder (Access Token). Passt keines, bietet sie nur Kein Credential und einen Link Credentials in Settings anlegen.

3. Drücke Projekt erstellen. Du landest auf der Seite des neuen Projekts.

Die Credential-Art muss zur URL-Form passen

Ein Git-Credential hat eine Art, und die beiden Arten sind nicht austauschbar – das Formular filtert nach Provider, nicht nach Art, lässt dich also bereitwillig die falsche mit deiner URL kombinieren.

• Ein SSH Key authentifiziert den Git-Transport. Er passt zu einer ssh://- oder git@…-URL und deckt Klonen und Pushen ab.
• Ein Access Token authentifiziert die HTTP-API des Providers. Darüber laufen das Durchsuchen von Issues, das Öffnen von Pull Requests und das Auflisten von Repositories, und es passt zu einer https://-URL.

Ein Projekt bindet genau ein Git-Credential, die Wahl ist also echt: ein Projekt mit reinem SSH-Zugang kann klonen und pushen, erreicht aber die API des Providers nicht. Wenn SupaCloud für dich Issues lesen und Pull Requests öffnen soll, nimm eine HTTPS-URL mit einem Access Token. Wie die daraus folgenden Fehlermeldungen aussehen, steht in Einen hängenden oder fehlgeschlagenen Lauf diagnostizieren.

Ein Branch-Feld gibt es im Anlegen-Formular nicht – den Default Branch setzt du danach im Reiter Konfiguration des Projekts (siehe unten). Setze ihn ausdrücklich, wenn der Standard deines Repositorys nicht main heißt: ein nicht existierender Branch ist eine der drei Ursachen hinter der Meldung „Git clone failed“ und sieht von außen genauso aus wie eine falsche URL oder ein falsches Credential.

Mehrere Repositories auf einmal importieren

Wenn du eine ganze Organisation anbindest statt eines einzelnen Repositorys, liegt in der Projektliste neben Neues Projekt eine Aktion Importieren (auf dem Telefon ein Symbol in der Kopfleiste), die in einem Durchgang je Repository ein Projekt anlegt.

1. Drücke Importieren. Du landest auf /projects/sync mit dem Titel Projekte importieren.

2. 1. Provider auswählen – drücke Forgejo, Bitbucket, GitHub oder GitLab.

3. 2. Git Credential auswählen – wähle ein Credential und drücke dann Repos abrufen. Manche Provider brauchen daneben noch einen Wert: Bitbucket will den Namen des Bitbucket-Workspace, Forgejo und GitLab wollen den Host, zum Beispiel https://git.example.com. GitHub braucht keinen davon.

4. 3. Repositories auswählen – hake an, was du willst. Repositories, zu denen es bereits ein Projekt gibt, sind ausgegraut und mit importiert gekennzeichnet, ein zweiter Import kann sie also nicht doppeln; Alle auswählen nimmt nur den importierbaren Rest. Jede Zeile zeigt den Default-Branch des Repositorys.

5. Drücke Projekte importieren. Aus jedem gewählten Repository wird ein Projekt mit seinem Namen, seiner Klon-URL, seinem Provider und seinem Default-Branch.

Der Import listet nur Access-Token-Credentials

Dieser Assistent spricht mit der API des Providers und bietet deshalb nur Access Token-Credentials an – ein SSH-Schlüssel kann keine Repositories auflisten. Ist keines hinterlegt, erscheint „Keine passenden Access-Token-Credentials vorhanden“ und ein Link In Settings anlegen. Für Klonen und Pushen ist ein SSH-Credential danach trotzdem in Ordnung – tausche es am Projekt aus, sobald es existiert.

Einen Issue-Tracker anbinden

Woher die Issues eines Projekts kommen, ist eine eigene, optionale Bindung, und es gibt sechs mögliche Quellen: die Issues der vier Git-Forges selbst – Forgejo, GitHub, GitLab und Bitbucket – sowie Linear und Notion.

Ein gerade angelegtes Projekt ist bereits an die erste Art angebunden: ohne gesetzten Tracker sind seine Issues die des Repositorys, das du gebunden hast. Einen Tracker zu setzen ersetzt diese Quelle, statt sie zu ergänzen – steht Issue-Tracker-Quelle auf Linear oder Notion, laufen dort jedes Lesen, jeder Kommentar und jeder Statuswechsel hin, und die Issue-Liste der Forge wird nicht mehr befragt. Das Feld auf Keiner stehen zu lassen ist also eine echte Entscheidung und kein unkonfigurierter Zustand.

1. Öffne das Projekt, dann den Reiter Konfiguration, dann die Zeile Repository & Quelle. Der Tracker-Block sitzt direkt unter den Repository-Feldern.

2. Setze Issue-Tracker-Quelle. Keiner (Git-Anbieter verwenden) behält die Issues der Forge; Linear und Notion wechseln die Quelle.

3. Benenne die Sammlung, die gelesen werden soll. Linear verlangt einen Team-Schlüssel – Linears eigene Kennung für die Gruppe, zu der die Issues gehören; Notion verlangt eine Datenbank-ID.

4. Drücke Linear verbinden bzw. Notion verbinden. Das ist eine ganzseitige OAuth-Autorisierung: du bestätigst beim Anbieter und kommst mit einer Bestätigung ins Projekt zurück. Wähle danach die entstandene Verbindung unter Tracker-Credential.

5. Optional überschreibst du unter Status bei Task-Ausgang die Statusnamen, die SupaCloud nach einem Task zurückschreibt – Bei Erfolg, Bei Fehlschlag und In Arbeit. Ein leeres Feld bedeutet den dokumentierten Standardwert; ein leeres Bei Fehlschlag heißt: SupaCloud kommentiert und lässt das Element offen.

6. Drücke Speichern unten im Reiter Konfiguration.

Ein gebundener Tracker macht seine Issues im Reiter Issues des Projekts durchsuchbar und startbar: du kannst einen Task direkt aus einem Issue starten, mit vorbefülltem Titel und Prompt und mit dem Run zurückverlinkt. Siehe Einen Task aus einem Issue starten.

Unter den Statusnamen sitzen Issue-Tracker-Auto-Developer aktivieren und ein Webhook-Secret. Das ist eine andere Frage – nicht woher Issues kommen, sondern ob SupaCloud sie selbstständig abarbeitet. Lass es aus, bis du Den Autodev-Modus wählen gelesen hast.

Tracker-Verbindungen sind nicht persönlich

Anders als API-Schlüssel und Git-Zugangsdaten hat eine Linear- oder Notion-Verbindung keine persönliche Stufe – sie ist ausschließlich Workspace- oder Organisations-weit. Ein Providerwechsel löscht Credential und Status-Überschreibungen, eine Linear-Verbindung kann also nie versehentlich unter Notion gespeichert werden.

Das Projekt konfigurieren

Alles Weitere zu einem Projekt liegt an einer Stelle: im Reiter Konfiguration auf der Projektseite (direkt verlinkbar als ?tab=config und Ziel von Einstellungen sowohl im Zeilenmenü als auch im Fuß). Es ist ein einziges eingebettetes Akkordeon – separate Nur-Lese-Reiter und einen Bearbeiten-Dialog gibt es nicht mehr.

Es beginnt mit einem Satz in Klartext, der die aktuelle Richtlinie des Projekts beschreibt; jeder Teilsatz darin ist ein Link, der die zuständige Zeile öffnet. Darunter setzt die Abkürzung Sichere Backlog-Automatik einrichten mit einem Druck einen bewährten Startpunkt, und jedes Feld, das sie anfasst, bleibt editierbar.

Die sieben Zeilen:

Zeile	Was darin steckt	Wo es dokumentiert ist
Repository & Quelle	Name, Provider, Default Branch, Repo-URL, Git-Credential – und der Issue-Tracker von oben	Diese Seite
Wer & wie weit	Autonomiestufe, Aufwand, welche Agent-Profile die Arbeit übernehmen dürfen	Die Autonomiestufe festlegen
Freigaben & Merge	Die Konzept- und Entwurfs-PR-Gates sowie die Merge-Politik	Den Autodev-Modus wählen
Automatik	Der Autodev-Modus, der Klassifizierer, die PR-Review-Bahn, die Prüfschleife	Den Autodev-Modus wählen, Das Backlog ausführen
Abschluss	Was ein Agent am Ende jedes Tasks tut, und die Memory-Governance	Den Standard-Closeout konfigurieren, Memories verwalten
Schutzplanken	Umgebungs-Geltungsbereich, gesperrte Tools, geforderte Prüfer, Budgets, Parallelität, Worker-Gruppen	Unten und Nutzung und Budget verfolgen
Umgebung & Build	Umgebungsvariablen des Projekts und sein Container-Image	–

Ein Speichern unten sichert das Projekt selbst. Drei Steuerelemente speichern eigenständig über eigene Endpunkte – das Parallelitätslimit, der Image-Build und die Umgebungsvariablen –, sie werden also erst durch ihren jeweils eigenen Knopf übernommen.

Ein Mitglied sieht das nur lesend

Der Reiter Konfiguration ist für Eigentümer und Admins des Workspace editierbar. Ein Mitglied sieht dieselben Zeilen mit dem Hinweis „Du hast nur Lesezugriff auf diese Einstellungen.“, ohne Speichern-Knopf und mit inaktiven Zeilen.

Begrenzen, was das Projekt ausgeben darf

Die Zeile Schutzplanken trägt die Geldgrenzen des Projekts, damit ein einzelnes lautes Repository nicht das Workspace-Budget leert.

• Tagesbudget-Obergrenze ($) und Monatsbudget-Obergrenze ($) sind Projekt-Summen. Sie binden jeden Task-Start gegen das Projekt – von Hand gestartet, aus dem Backlog und aus der PR-Review-Bahn gleichermaßen, nicht nur Backlog-Läufe – und sie greifen unterhalb des Workspace-Budgets: beide müssen die Ausgabe erlauben. Ein leeres Feld heißt: keine Projekt-Obergrenze.
• Daneben liegen die backlog-spezifischen Grenzen: ein Backlog-Tagesbudget, eine Backlog-Parallelität und eine Latte für geforderte Prüfer, die nur für autonom versandte Arbeit gelten.

Beide Obergrenzen sind ein harter Stopp, keine Warnung. Ist die Ausgabe des Tages oder des Monats an einer angekommen, wird der nächste Start rundheraus abgelehnt – mit „Project daily AI budget exhausted“ bzw. „Project monthly AI budget exhausted“ samt Betrag und Obergrenze. Erhöhe die Grenze oder warte, bis das Zeitfenster umspringt. Die beiden Fenster sind unabhängig: schon eines reicht zur Ablehnung.

Setzen dürfen sie nur Eigentümer und Admins des Workspace, und nur an einem bestehenden Projekt – im Anlegen-Formular gibt es die Felder nicht. Das Workspace-Budget darüber und das Ablesen der tatsächlichen Ausgaben behandelt Nutzung und Budget verfolgen.

Ein Repository mit dem Workspace synchron halten

Das ist erwähnenswert, weil die Wörter sich ähneln und die Funktionen nicht: Projekte importieren (oben) liest viele Repositories einmalig, um Projekte anzulegen. Repo Sync bindet ein Repository dauerhaft als beidseitiges Zuhause für das, was du innerhalb von SupaCloud baust. Es gilt für den Workspace, nicht je Projekt, und liegt unter Einstellungen → Daten & Sync → Repo Sync – dort setzt du Repo-URL, Branch und eine Credential-Resource und bekommst die Knöpfe Zum Repo pushen und Vom Repo ziehen sowie eine Liste der letzten Sync-Aktivitäten.

Was mitreist: Workflows, Scripts, Apps, Resources und Memories, jeweils als Datei in einem eigenen Verzeichnis. Secrets von Resources und von Workflow-Triggern werden beim Hinausschreiben entfernt; Memories mit persönlichem Scope werden nie serialisiert, und eine personal-Memory im Repository wird beim Hereinholen abgelehnt.

Drei Dinge solltest du kennen, bevor du einen der beiden Knöpfe drückst:

• Die Sync-Richtung ist eine Einstellung. Bidirektional (Push und Pull), die Voreinstellung, erlaubt beides; Nur Repo (Git ist die Quelle der Wahrheit) deaktiviert Push; Nur UI (die UI ist die Quelle der Wahrheit) deaktiviert Pull. Der deaktivierte Knopf trägt einen Tooltip mit dem Grund.
• Konflikte werden je Element nach Last-write-wins aufgelöst. Vom Repo ziehen öffnet zuerst eine Pull-Preview, listet, was angelegt, aktualisiert oder übersprungen würde, und zeigt jede konfliktbehaftete Datei mit beiden Fassungen und einem Abzeichen, wer gewinnt. Pro Datei kannst du Remote übernehmen (überschreiben) drücken, um die Fassung aus dem Repository zu erzwingen, oder Lokal behalten, was nur den Standardausgang bestätigt und nichts ändert. Pull anwenden übernimmt dann den Rest.
• Löschungen reisen nicht mit — mit einer Ausnahme. Für Workflows, Scripts, Apps, Ressourcen und Memories gilt: Eine im Repository entfernte Datei löscht beim Pull keine Zeile, und ein in der UI gelöschtes Element entfernt beim Push seine Datei nicht; aufräumen musst du auf beiden Seiten selbst. Die Ausnahme ist die gemeinsame Code-Bibliothek (lib/): Ein Pull entfernt dort sehr wohl eine Datei, die du im Repository gelöscht hast — eine gemeinsame Bibliothek, deren Löschungen nie ankommen, wäre ein Zwischenspeicher und keine Quelle. Eine Bibliotheksdatei, die du zuletzt in der Oberfläche bearbeitet hast, überlebt diesen Abgleich. Siehe Code zwischen Code-Nodes teilen.

Der Push authentifiziert sich mit einem Benutzername-/Token-Paar aus einer Workspace-Resource, die du benennst – gib ihm also eine HTTPS-Repo-URL; das Credential leer zu lassen ist nur für ein öffentliches Repository gedacht. Repo Sync einzurichten und auszuführen erfordert Admin-Rechte im Workspace. Änderungen automatisch pushen ist ein optionaler Schalter, der Änderungen an Workflows, Scripts und Apps mit kurzer Verzögerung pusht; Änderungen an Resources und Memories sowie jedes Löschen brauchen weiterhin einen Push von Hand. Wie speziell Memories mitreisen, steht in Memories verwalten.

Ein Projekt archivieren oder löschen

Im Zeilenmenü der Projektliste liegen zwei verschiedene Aktionen, und nur eine davon ist umkehrbar.

Projekt archivieren nimmt es aus der aktiven Liste, ohne irgendetwas zu zerstören. Es taucht im Reiter Archiviert wieder auf, wo Projekt wiederherstellen es zurückholt. Archivieren ist nicht bloß kosmetisch: ein archiviertes Projekt fällt aus dem autonomen Backlog-Scan heraus und nimmt damit von sich aus keine Arbeit mehr auf. Es wird nichts zurückgefragt, weil nichts verloren geht. Genau das willst du für ein Repository, mit dem du vorerst fertig bist.

Löschen fragt „Dieses Projekt wirklich löschen?“ und ist endgültig. Es lohnt sich, genau zu wissen, was geht und was bleibt:

• Mit dem Projekt zerstört – seine Workflows (und die Runs dieser Workflows), seine Backlog-Einträge, seine Automatik-Konfiguration, seine Projekt-Umgebungsvariablen, seine geplanten Berichte und seine Agent-Berechtigungen.
• Erhalten, aber gelöst – seine Tasks und deren Agent-Runs, seine Task-Zeitpläne, seine Kosten- und Ergebnisdaten, seine Audit-Historie und seine projektbezogenen Memories. Sie überleben ohne die Projektverknüpfung, die Aufzeichnung des Geschehenen bleibt also, auch wenn der Rahmen dafür weg ist.
• Unberührt – das Repository und der Issue-Tracker. Kein Commit, kein Branch, kein Issue und kein Pull Request ändert sich; SupaCloud räumt nur seine eigene Seite ab.

Das Löschen ist nicht rollengeschützt – und wartet nicht

Der Bestätigungsdialog ist das Einzige, was vor dem Löschen steht: anders als der Reiter Konfiguration ist es nicht auf Eigentümer und Admins beschränkt – jedes Mitglied des Workspace, das das Projekt sieht, kann es also entfernen. Auch ein laufender Task hält es nicht auf – ein Projekt mit laufender Arbeit zu löschen wird nicht abgelehnt und beendet diese Arbeit nicht. Da Archivieren nichts kostet und umkehrbar ist: archiviere zuerst, wann immer du unsicher bist.

Siehe auch

• Erste Schritte mit SupaCloud – das Tutorial, das auf diese Seite übergibt
• Dein erster Agent-Run – was du mit dem gerade angelegten Projekt tust
• Secrets in der Benutzeroberfläche verwalten
• Einen Task aus einem Issue starten
• Den Autodev-Modus wählen
• Workspaces und Organisationen