Gardez votre catalogue à jour

Votre catalogue de capacités décrit votre API au moment où vous avez lancé la découverte. Les API bougent : la fraîcheur est une boucle, pas un événement unique — relancez la découverte au changement, automatisez-la en CI, et laissez la détection de dérive à l’exécution attraper ce qui a échappé.

Relancez la découverte à chaque changement d’API

Relancer init est sûr par conception : l’extraction est déterministe, le fichier du catalogue (.syncanix/catalog.json) est réécrit depuis votre code actuel, et le catalogue rafraîchi est envoyé vers le même espace de travail. Aucune étape de migration : la relance EST la mise à jour.

npx syncanix init

Votre curation survit à la relance : les entrées de .syncanixignore sont exclues à chaque exécution puisque le fichier vit dans votre dépôt, et les ajustements par capacité faits dans le tableau de bord sont liés à la capacité et se réappliquent après un nouveau scan — cette survie est couverte par un test d’intégration, pas par une convention.

Automatisez : la découverte en CI

En CI, lancez init en mode non interactif avec --yes et authentifiez-vous via la variable d’environnement SYNCANIX_API_KEY (créez une clé dans le tableau de bord et stockez-la comme secret CI — la même clé que syncanix login écrirait en local). Un workflow GitHub Actions minimal :

# .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 }}

Exécutez-le sur les push vers votre branche principale (ou seulement quand les chemins de code de l’API changent, via les filtres de votre CI). Le job ré-extrait, renvoie, et votre assistant récupère le catalogue rafraîchi — aucun déploiement de Syncanix n’est impliqué.

Détection de dérive à l’exécution (SDK Node)

Même avec la CI, un endpoint peut partir en production sans que la découverte ne l’ait vu. Le SDK Node surveille le trafic réel exactement pour cela : il s’abonne au canal de diagnostic HTTP intégré de Node — sans monkey-patching, coût nul au repos — et compare chaque requête entrante à l’ensemble des capacités connues.

Les requêtes qui ne correspondent à aucune capacité connue émettent un événement de dérive nouveau-endpoint, dédupliqué, que le SDK envoie à votre espace de travail — le tableau de bord vous montre alors les endpoints qui servent du trafic de production sans figurer au catalogue. Traitez un événement de dérive comme un signal de relancer la découverte.

Monorepos et bases de code polyglottes

Lancez init une fois depuis la racine du dépôt. La découverte détecte chaque stack de framework trouvée — entre workspaces et entre langages —, extrait chacune et fusionne les résultats dans un catalogue unique ; un monorepo avec, par exemple, une API NestJS et un service FastAPI produit un ensemble de capacités combiné. Si une stack est mal détectée, fixez-la avec --framework.

Étapes suivantes