Lokal entwickeln.
Auf connic ausführen.
connic dev lädt dein Projekt in ein isoliertes Dev Environment auf connic und überträgt jede gespeicherte Änderung in Sekunden.
Jede Änderung landet im nächsten Run. Fehlerhafte bleiben draußen.
Die CLI lädt jede gespeicherte Änderung hoch, und connic prüft die Agenten, bevor der Dev Runner sie übernimmt.
- Ein Fehler ist nur eine Warnung
- Das Terminal zeigt den Grund, und der Runner behält die letzte funktionierende Version, bis du erneut speicherst.
- Tasten während der Session
- r lädt sofort hoch, t startet die Tests, und q beendet die Session und räumt auf.
- Neue Abhängigkeiten
- requirements.txt wird beim Start der Session installiert. Nach einer Änderung startest du die Session neu.
Dev-Agenten direkt im Dashboard starten.
Wähl in der Environment-Auswahl ein Dev Environment, und du siehst seine Agenten, Runs, Verbindungen und Variablen.
- Getrennte Daten
- Ein Dev Environment hat eigene Variablen, Verbindungen, Datenbank, Retrieval und Sessions. Testdaten bleiben so aus der Produktivumgebung heraus.
- Die KI-Modelle des Projekts
- Anbieter-Keys gehören zum Projekt. connic/* und BYOK-Modelle laufen deshalb ohne weitere Einrichtung.
- Echte Auslöser
- Starte einen Agenten im Playground oder schick echte Ereignisse an eine Verbindung im Dev Environment.
Einmal kurz testen. Oder das Environment für später behalten.
Starte connic dev ohne Argumente und wähl aus.
- Deine Wahl
- Die Auswahl bietet zuerst das in .connic gespeicherte Environment an, dann ein neues oder einen Quick Test.
- Gelöscht
- Für Experimente und Bug-Repros. Environment, Verbindungen und Variablen werden gelöscht, sobald die Session endet.
- Bleibt
- Verbindungen und Variablen sind noch da, wenn du an dem Feature weiterarbeitest.
Tests mit einer Taste starten.
Drück t, während connic dev läuft. Die Suites aus tests/ laufen gegen deinen aktuellen Stand, und die Ergebnisse erscheinen im selben Terminal.
→ Submitting tests to backend (target: dev session env)... ✓ Test run id: 5d0c7b1e-2f94-4a63-b8d1-0e6a9c3f2b57 PASS lead-qualifier::scores_enterprise_lead 1/1 100% PASS lead-qualifier::rejects_free_mail_domain 1/1 100% PASS lead-qualifier::routes_partner_referral 1/1 100% ✓ 3/3 cases passed. [10:51:12] → Back to watching. Keys: [r] refresh [t] run tests [q] quitEntdecke weitere Features
composer SDKAgenten in YAML, Tools in Python.ToolsDie Funktionen und MCP-Server, an denen du arbeitest.StorageDatenbank und Retrieval, getrennt pro Environment.TestingDie Tests hinter t und das Deploy Gate.EnvironmentsVariablen, Verbindungen und Promotion pro Environment.ObservabilityTraces und Logs für jeden Dev Run.
Häufig gestellte Fragen
Jede gespeicherte Änderung in agents/, tools/, middleware/, hooks/, schemas/, guardrails/ und tests/, auch in Unterordnern. Die CLI sammelt Änderungen eine Sekunde lang, damit eine Umbenennung über mehrere Dateien oder ein Formatter-Lauf als ein Upload ankommt. Mit r lädst du den aktuellen Stand sofort hoch.
Ein Quick Test über connic dev --quick oder die Auswahl legt ein temporäres Environment an und löscht es am Ende der Session. connic dev mit einem Namen legt dieses Environment an oder nutzt es wieder, und es bleibt nach dem Beenden samt Verbindungen und Variablen erhalten. Ohne Argumente fragt connic dev, was du willst.
Ja. Sie läuft in einem eigenen Environment mit eigenen Variablen, Verbindungen, Datenbank, Retrieval und Sessions. So bleibt Test-Traffic aus der Produktivumgebung heraus. Anbieter-Keys gelten für das ganze Projekt, die Session nutzt also dieselben KI-Modelle wie deine anderen Environments.
connic login öffnet das Dashboard, dort erstellst du einen API Key. Danach fragt die CLI nach dem Login-Token und speichert die Zugangsdaten in der Datei .connic im Projektordner. Nimm sie in .gitignore auf. In CI oder einer geteilten Shell setzt du stattdessen CONNIC_API_KEY und CONNIC_PROJECT_ID.
Pakete aus requirements.txt werden beim Start der Session installiert. Ändert sich die Datei während der Session, meldet die CLI, dass die Session neu aufgesetzt werden muss. Beende sie mit q und starte connic dev noch einmal.
Nein. Pro benanntem Environment ist immer nur eine Dev Session aktiv. Ein zweites connic dev mit demselben Namen wird abgelehnt, bis die erste Session endet. Für paralleles Arbeiten nimmt jede Person einen eigenen Namen oder einen Quick Test.