Halten Sie Ihren Katalog aktuell

Ihr Fähigkeitskatalog beschreibt Ihre API zum Zeitpunkt der Erkennung. APIs bewegen sich — Aktualität ist eine Schleife, kein Einmalereignis: Erkennung bei Änderungen erneut ausführen, in CI automatisieren, und die Laufzeit-Drift-Erkennung fängt, was durchgerutscht ist.

Erkennung bei jeder API-Änderung erneut ausführen

Ein erneutes init ist konstruktionsbedingt sicher: Die Extraktion ist deterministisch, die Katalogdatei (.syncanix/catalog.json) wird aus Ihrem aktuellen Code neu geschrieben, und der aufgefrischte Katalog lädt in denselben Workspace hoch. Es gibt keinen Migrationsschritt — der erneute Lauf IST das Update.

npx syncanix init

Ihre Kuration überlebt den erneuten Lauf: Einträge in .syncanixignore werden bei jedem Lauf ausgeschlossen, weil die Datei in Ihrem Repository liegt, und Ihre im Dashboard vorgenommenen Anpassungen pro Fähigkeit sind an die Fähigkeit gebunden und greifen nach einem Rescan wieder — dieses Überleben ist durch einen Integrationstest abgedeckt, nicht durch Konvention.

Automatisieren: Erkennung in CI

In CI führen Sie init nicht-interaktiv mit --yes aus und authentifizieren sich über die Umgebungsvariable SYNCANIX_API_KEY (Schlüssel im Dashboard erzeugen und als CI-Secret speichern — derselbe Schlüssel, den syncanix login lokal schreiben würde). Ein minimaler GitHub-Actions-Workflow:

# .github/workflows/syncanix-catalog.yml
name: Refresh Syncanix catalog
on:
  push:
    branches: [main]
jobs:
  refresh:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - run: npx syncanix init --yes
        env:
          SYNCANIX_API_KEY: ${{ secrets.SYNCANIX_API_KEY }}

Lassen Sie ihn bei Pushes auf Ihren Hauptzweig laufen (oder nur bei Änderungen an API-Codepfaden, über die Pfadfilter Ihrer CI). Der Job re-extrahiert, lädt erneut hoch, und Ihr Assistent übernimmt den aufgefrischten Katalog — ohne jeglichen Syncanix-Deploy.

Laufzeit-Drift-Erkennung (Node-SDK)

Auch mit CI kann ein Endpunkt ausgeliefert werden, den die Erkennung nie gesehen hat. Genau dafür beobachtet das Node-SDK den echten Verkehr: Es abonniert Nodes eingebauten HTTP-Diagnosekanal — kein Monkey-Patching, null Overhead im Leerlauf — und vergleicht jede eingehende Anfrage mit der bekannten Fähigkeitsmenge.

Anfragen ohne passende bekannte Fähigkeit erzeugen ein dedupliziertes Neuer-Endpunkt-Drift-Ereignis, das das SDK in Ihren Workspace hochlädt — das Dashboard zeigt Ihnen damit Endpunkte, die Produktionsverkehr bedienen, ohne im Katalog zu stehen. Behandeln Sie ein Drift-Ereignis als Anlass, die Erkennung erneut auszuführen.

Monorepos und polyglotte Codebasen

Führen Sie init einmal von der Repository-Wurzel aus. Die Erkennung findet jeden Framework-Stack — über Workspaces und Sprachen hinweg —, extrahiert jeden und führt die Ergebnisse in einem einzigen Katalog zusammen; ein Monorepo mit etwa einer NestJS-API und einem FastAPI-Dienst ergibt eine kombinierte Fähigkeitsmenge. Wird ein Stack falsch erkannt, pinnen Sie ihn mit --framework.

Nächste Schritte