Zum Hauptinhalt springen
Connic

Lokal bearbeiten.
In der Cloud ausführen.

connic dev stellt einen isolierten Cloud Runner bereit, lädt das Projekt hoch und beobachtet das lokale Dateisystem. Änderungen erreichen den Runner in 2–5 Sekunden; beim nächsten Aufruf lädt der Agent Loader die neue Version.

Dev-Server-Dokumentation lesen
zsh — connic dev
~/invoice-bot ❯ connic dev
watching agents/ and tools/
connected to dev runner · session a1b2c3d4
✓ ready in 412ms
↻ tools/documents.py changed
✓ reloaded invoice-processor in 2.4s
→ invoice-processor #a1b2c3d4
parsed 3 entities, stored to db
✓ run completed in 2.3s
❯

Speichern. Synchronisieren. Ausführen.

connic dev beobachtet die Projektverzeichnisse agents/, tools/, middleware/, hooks/ und weitere. Der nächste Agent-Aufruf verwendet die aktuellen Änderungen.

agents/triage.yaml
im Editor speichern
etwa 1 s gebündelt
die CLI lädt geänderte Dateien zum Runner hoch
beim nächsten Aufruf
der Agent Loader führt die neue Version aus

Änderungen erreichen den Runner in 2–5 Sekunden. Dateispeicherungen werden etwa eine Sekunde lang gesammelt und gemeinsam hochgeladen, etwa wenn mehrere Dateien umbenannt werden. Ein vollständiger Neustart ist nicht nötig.

Wenige Befehle, keine Liste von Flags

Die CLI benötigt dafür zwei Befehle: connic dev für eine kurzlebige Session, connic dev <name> für eine persistente.

terminal
connic login

Einmal authentifizieren. Die CLI öffnet das Dashboard für einen API Key und schreibt die Zugangsdaten anschließend in eine .connic-Datei im Projektstammverzeichnis.

terminal
connic dev

Eine kurzlebige Dev Session mit Cloud Runner, Projekt-Upload und Überwachung des lokalen Dateisystems. Wird bei Ctrl+C automatisch gelöscht.

terminal
connic dev my-feature

Mit einem benannten Environment erneut verbinden oder es erstellen. Das benannte Environment bleibt zwischen Sessions mit eigenen Verbindungen und Umgebungsvariablen bestehen.

terminal
connic deploy

Die Auslieferung für den Produktivbetrieb nutzt dasselbe Projekt und dieselben Verbindungen in einem anderen Environment.

Live im Dashboard tracen. Im Terminal testen.

Dev Sessions erscheinen im Dashboard neben den Standard-Environments. Agenten lassen sich über eine Verbindung oder das Dashboard auslösen, der vollständige Trace Stream bleibt in Echtzeit sichtbar und die Test Suite läuft vor dem Ausliefern gegen die aktive Session.

Die Agenten-Ansicht markiert die Dev Session mit dem Badge Dev Session. Dadurch ist sie sofort erkennbar. Run Traces werden live in derselben Struktur wie produktive Runs in der Observability angezeigt.

Dev Sessions sind von anderen Environments isoliert. Ein an die Dev Session gesendeter Webhook kann daher nicht versehentlich die Produktivumgebung auslösen.

Während die Session aktiv ist, führt connic test die Suite gegen denselben Code aus, den der Runner gerade lädt. Nach jedem Speichern ist kein erneutes Deployment nötig.

zsh — connic test
❯ connic test

  Running 12 cases against dev session...

  ✓ extracts_invoice_total           (5/5 · 312ms avg)
  ✓ handles_missing_vendor_field     (5/5 · 247ms avg)
  ✓ rejects_unsupported_currency     (5/5 · 218ms avg)
  ✗ handles_corrupt_pdf              (3/5 · 894ms avg)
      expected_result failed:
        output.status == "rejected"
      got: "completed"


  11 passed, 1 failed in 8.4s

Häufig gestellte Fragen

Dateiänderungen in den Standardverzeichnissen agents/, tools/, middleware/, hooks/, schemas/, guardrails/ und tests/. Die CLI sammelt Änderungen etwa eine Sekunde lang und lädt sie gemeinsam hoch. Das bündelt zum Beispiel die Umbenennung mehrerer Dateien oder Änderungen durch einen Formatter.

Beides. connic dev erstellt eine kurzlebige Session, die bei Ctrl+C automatisch gelöscht wird. connic dev <name> erstellt ein benanntes Environment oder verbindet sich erneut damit. Das benannte Environment bleibt zwischen Sessions mit eigenen Verbindungen und Umgebungsvariablen bestehen.

Die Authentifizierung beginnt mit connic login. Die CLI öffnet das Dashboard für einen API Key und schreibt die Zugangsdaten anschließend in eine .connic-Datei im Projektstammverzeichnis. Für CI oder gemeinsam genutzte Shells lassen sich auch CONNIC_API_KEY und CONNIC_PROJECT_ID als Umgebungsvariablen übergeben.

Python-Abhängigkeiten werden beim Start der Dev Session installiert. Nach einer Änderung an requirements.txt muss die Session neu erstellt werden.

Ja. Dev läuft in einem eigenen Environment mit eigenen API Keys, Umgebungsvariablen und Verbindungen. Dev Environments werden im Environment Switcher des Dashboards separat gruppiert, damit ein Webhook nicht versehentlich auf die Produktivumgebung verweist.

Nein. Pro benanntem Environment kann nur eine Dev Session aktiv sein. Unterschiedliche Namen oder kurzlebige Sessions ermöglichen paralleles Arbeiten.