LogBrew pour les agents

Cette page explique comment les agents doivent lire LogBrew sans dépendre de l’état du navigateur, d’un contexte caché ou d’un accès privé au tableau de bord.

Lire le Markdown
Première lecture sûre
logbrew status --json

Commencez par l’état local, puis lisez logs, problèmes, actions, traces, versions et projets seulement quand l’authentification et l’accessibilité de l’API sont confirmées.

Feuille de route de l’agent

Suivez cet ordre quand un assistant aide un développeur à configurer LogBrew ou à lire des signaux privés.

  1. Étape 1

    Lire la carte publique

    Chargez l’index public des routes avant de modifier le code de l’application, pour que l’assistant parte du contexte LogBrew actuel.

    curl -L https://logbrew.co/llms.txt
    Utilisez les miroirs Markdown liés pour un contexte public plus détaillé.
  2. Étape 2

    Choisir la fiche SDK

    Lisez le sélecteur de SDK avant toute installation, puis utilisez Copier le prompt d’installation dans Ajouter un projet pour que l’assistant suive la plateforme choisie.

    curl -L https://logbrew.co/en/docs.md
    Demandez à l’utilisateur connecté d’ouvrir Ajouter un projet, de copier le prompt d’installation et de ne jamais mettre d’identifiants d’ingestion dans la conversation.
  3. Étape 3

    Vérifier l’état local

    Confirmez l’accessibilité de l’API et la source d’authentification avant de lire des projets, logs, problèmes, actions, traces ou versions privés.

    logbrew status --json
    Suivez le champ next, sans risque pour le jeton, au lieu de deviner.
  4. Étape 4

    Vérifier le premier signal

    Une fois qu’un signal SDK sûr a été envoyé pendant la configuration, lisez un résultat ciblé et gardez jetons, cookies et données de projet hors des prompts.

    logbrew logs info --json
    Ne lisez problèmes, actions, traces, versions et projets qu’une fois l’authentification prête.

Donnez à l’agent la carte publique de LogBrew avant qu’il modifie votre application ou votre commande de configuration.

curl -L https://logbrew.co/llms.txt
Lisez https://logbrew.co/llms.txt, puis choisissez la fiche SDK correspondante sur https://logbrew.co/en/docs#docs-sdk-choice-title. Utilisez npm install @logbrew/sdk @logbrew/node uniquement pour un service Node.js côté serveur ; pour Next.js, React, iOS, Android ou React Native, utilisez la fiche choisie et le prompt d’Ajouter un projet. Demandez à l’utilisateur connecté d’ouvrir Ajouter un projet et de placer les identifiants uniquement dans l’environnement de l’application concernée. Pour Node.js côté serveur, la variable d’environnement est LOGBREW_SERVER_API_KEY. Lancez node node_modules/@logbrew/node/examples/first-useful-telemetry.mjs uniquement pour les services Node, puis vérifiez avec logbrew logs info --json. Ne demandez jamais d’identifiants dans la conversation ni dans les commits.

Les agents doivent trouver le contexte public de LogBrew via des pages localisées stables, des miroirs Markdown, llms.txt, robots.txt et sitemap.xml.

  • Utilisez /en/agents.md quand le texte brut est l’entrée la plus sûre.
  • Utilisez /en/docs.md pour le contexte des commandes et des routes d’API.
  • Utilisez /llms.txt pour découvrir les ressources publiques lisibles par les agents.

La CLI doit indiquer aux agents si l’authentification locale, l’accessibilité de l’API et les étapes de reprise sont prêtes, sans exposer le jeton.

  • Lancez logbrew status --json avant de lire des projets.
  • Suivez les prochaines étapes indiquées dans le JSON et dans la sortie lisible, au lieu de deviner.
  • Gardez le jeton hors des prompts, des logs, des captures d’écran et des pages publiques.

Les agents doivent lire logs, problèmes, actions, traces, versions et projets avec le même vocabulaire de ressources que les humains.

  • Utilisez les filtres de version, d’environnement, de projet, de trace, de gravité, de statut, de nom et d’utilisateur.
  • Utilisez les routes de détail des problèmes et des traces quand un identifiant est connu.
  • Utilisez les miroirs Markdown pour le contexte public et l’API authentifiée pour les données privées des projets.

Utilisez la documentation publique pour l’aide sur le produit. Utilisez les lectures authentifiées pour les données privées des projets.

  • N’extrayez pas les données du tableau de bord sans session utilisateur valide.
  • Ne publiez pas de noms de projets privés, de jetons, de traces ou de détails de déploiement.
  • Utilisez les pages publiques pour l’apprentissage général et les routes authentifiées pour les données utilisateur ciblées.