Tutoriel DeepSeek Superagent : observer le CI et autoriser une correction

Qu’est-ce que DeepSeek Superagent ?

DeepSeek Superagent surveille un dépôt GitHub via DeepSeek Harness. Les règles d’équipe décident si un événement mérite un traitement ; les travaux acceptés partent dans une session séparée. Ce tutoriel couvre le prototype publié, pas des idées de conception non implémentées.

Harness fournit l’exécution ; Superagent ajoute la surveillance d’événements et l’autorisation. Notre guide sur l’agent harness présente les outils, la mémoire et le contrôle.

Comment fonctionne DeepSeek Superagent ?

Un nouvel événement GitHub peut traverser quatre étapes. Ces étapes séparent la décision du changement de code :

• Source et déclencheur : l’interrogation GitHub transforme chaque événement en Trigger sur une Issue, une pull request ou main.

• Admission : le filtre l’étiquette comme demande explicite, candidat inféré, ou rien.

• Évaluation et décision : le CI inféré est jugé au regard des règles. Une demande explicite est routée vers une décision d’acceptation, raison explicitRouted.

• Ticket et exécuteur : les travaux acceptés reçoivent leur autorisation, leur session de travail et leur répertoire.

Un commentaire ultérieur sur le fil du Ticket part vers son worker sans nouvelle évaluation. Le schéma montre trois parcours GitHub : CI de la branche par défaut, une demande explicite, puis cette revue. Dans le parcours CI, observe et auto quittent une règle correspondante à des niveaux différents.

Le CI est jugé. Les demandes démarrent le travail. Image de l’auteur.

Quelle est la différence entre le mode observe et le mode auto ?

Le mode d’acceptation s’applique seulement aux travaux que Superagent a inférés à partir d’un événement. Choisissez l’un de ces trois réglages :

• off écarte les candidats inférés.

• observe les évalue mais enregistre un résultat positif comme « accepterait ».

• auto démarre le travail après une évaluation positive.

Une demande émise par une personne autorisée fonctionne dans tous les modes et crée son propre Ticket. Laissez auto désactivé pour ce tutoriel.

Construire un workflow de réparation CI en mode observe

Le pipeline utilise pytest et deux jobs GitHub Actions pour transformer des événements en chiffre d’affaires quotidien. Superagent insère une décision avant de démarrer le travail. Notre tutoriel Claude Code Routines présente un autre workflow piloté par événements.

Traquer le bug de relecture dans le chiffre d’affaires quotidien

Le bug compte deux fois un paiement rejoué. Chaque ligne possède un event_id, un order_id, des horodatages et un montant. Une commande peut contenir plusieurs paiements valides.

C’est pourquoi la déduplication sur order_id peut réussir un test de relecture mais supprimer des paiements réels ; la bonne clé est event_id. Calculez les totaux attendus avec le module csv de Python avant d’autoriser l’agent, pour éviter que la sortie de l’agent ne serve de solution attendue.

Définir une réparation CI réussie

Le succès dépend de ce que fait le workflow, pas seulement de ce que dit l’agent. Fixez ces conditions avant de modifier le dépôt :

• Ignorer un échec ne concernant que la documentation.

• Identifier revenue-integrity sans démarrer le travail.

• Ouvrir une pull request uniquement après une demande explicite.

• Préserver les assertions et réussir une suite de contrôle préassemblée.

Préparez la suite de contrôle avant de donner l’accès à Superagent. Cela garde le comportement attendu en dehors des données d’entraînement du worker.

Prérequis et isolement pour DeepSeek Superagent

Vous avez besoin d’une clé API DeepSeek, de deux comptes GitHub et d’un environnement Linux jetable. Pour les bases de Harness, consultez notre guide d’installation.

Logiciels et comptes nécessaires

Figez les versions logicielles pour éviter qu’une mise à jour ne modifie le workflow. La dernière colonne consigne la configuration utilisée pour les résultats présentés plus loin dans l’article :

L’agent a besoin de son propre utilisateur GitHub avec des droits d’écriture, car Superagent lit les notifications de ce compte. Ajoutez uniquement les mainteneurs humains autorisés à donner leur aval à la liste des personnes autorisées.

Isoler l’agent des fichiers personnels

Les deux préréglages donnent à l’utilisateur du système d’exploitation un accès complet, et l’enveloppe gh n’isole pas le processus. Utilisez une distribution WSL neuve avec l’automount et l’interop désactivés :

Si vous disposez déjà d’une machine virtuelle Linux jetable, ignorez le bloc WSL et utilisez-la à la place. Évitez d’y stocker des identifiants ou fichiers sans lien.

# /etc/wsl.conf inside the disposable distribution
[automount]
enabled = false
mountFsTab = false
[interop]
enabled = false
appendWindowsPath = false
[user]
default = superagentPropulsé par

Un utilisateur dédié superagent ne devrait contenir que la clé DeepSeek et le jeton de l’agent. Cela réduit les accès accidentels sans constituer une frontière de sécurité ; le modèle de sécurité WSL de Microsoft recommande une machine virtuelle gérée séparément hors WSL pour du code non approuvé.

Sur GitHub, protégez main avec une pull request obligatoire, au moins une approbation indépendante et les deux vérifications CI. Donnez à l’agent des droits d’écriture sans contournement administrateur. Rien de tout cela n’empêche une injection de consignes via le texte d’une Issue.

Étape 1 : construire le pipeline Python et la base CI

Le dépôt de tutoriel publié contient désormais la correction fusionnée sur main, n’utilisez donc pas sa branche actuelle comme état de départ. Utilisez ces commits pour séparer les trois étapes :

Le pipeline et les tests ci‑dessous sont simplifiés à partir de la base verte (a6d2036), et non issus de l’actuel main. Créez un dépôt jetable à partir de ce commit avant de suivre les étapes CI :

git clone https://github.com/KhalidAbdelaty/superagent-revenue-lab.git revenue-lab
cd revenue-lab
git switch -C main a6d2036
git remote remove origin

export EXPERIMENT_REPO="YOUR_LOGIN/superagent-revenue-lab"
gh repo create "$EXPERIMENT_REPO" --private --source=. --remote=origin --pushPropulsé par

Utilisez ce nouveau dépôt pour les échecs contrôlés et les branches de l’agent. Laissez le dépôt publié inchangé ; ses commits d’incident et de solution servent de références.

"""Daily revenue report built from payment events."""
import pandas as pd


def load_events(path):
    """Read payment events; amounts are integer cents."""
    return pd.read_csv(path, parse_dates=["occurred_at", "received_at"])


def daily_revenue(events):
    """Return one row per UTC day with total revenue in cents."""
    days = events["occurred_at"].dt.strftime("%Y-%m-%d")
    report = (
        events.assign(day=days)
        .groupby("day", as_index=False)["amount_cents"]
        .sum()
        .rename(columns={"amount_cents": "revenue_cents"})
    )
    return reportPropulsé par

Le jeu de données de base couvre deux jours et inclut plusieurs paiements réels pour une même commande. Pytest vérifie des totaux connus et ce cas de commande partagée, sans tester encore les relectures :

import pandas as pd


def test_daily_totals_match_known_values():
    report = daily_revenue(load_events(DATA))
    assert report["revenue_cents"].tolist() == [20398, 27550]


def test_events_on_the_same_order_are_all_counted():
    t = pd.Timestamp(0, unit="s", tz="UTC")
    events = pd.DataFrame({
        "event_id": ["evt_a", "evt_b"],
        "order_id": ["ord_1", "ord_1"],
        "occurred_at": [t, t],
        "received_at": [t, t + pd.Timedelta(seconds=1)],
        "amount_cents": [1000, 250],
    })
    assert daily_revenue(events)["revenue_cents"].tolist() == [1250]Propulsé par

Nommez chaque job d’après le comportement vérifié. Les mêmes noms apparaîtront ensuite dans GitHub et dans le texte Trigger de Superagent :

name: ci
on:
  push:
    branches: [main]
  pull_request:

jobs:
  revenue-integrity:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt   # pandas==2.3.3, pytest==8.4.2
      - run: pytest -v

  docs-check:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: python scripts/check_docs.py      # fails if README links a missing filePropulsé par

Si un simple pytest n’arrive pas à importer revenue, ajoutez un pytest.ini avec pythonpath = .. Vérifiez que les deux jobs passent sur main avant d’installer Superagent.

Le répertoire publié experiment/holdout documente l’exécution d’origine mais est visible dans le clone public. Pour une nouvelle expérience, créez une suite de contrôle neuve en dehors de tout checkout et système de fichiers lisible par le worker.

Créez l’empreinte de cette suite avant d’envoyer la demande de réparation. Couvrez ces cas :

• Livraisons répétées d’un même événement.
• Événements différents avec le même ID de commande.
• Un DataFrame d’entrée qui doit rester inchangé.
• Les colonnes de sortie attendues et l’ordre de tri.

Gardez cette suite cachée jusqu’à la revue. L’étape 6 l’exécute depuis l’environnement humain séparé, une fois le travail du worker terminé.

Le schéma suivant sépare les entrées de développement du worker du contrôle final du mainteneur.

Les données de contrôle restent hors de portée du worker. Image de l’auteur.

Étape 2 : installer DeepSeek Superagent et connecter GitHub

Installez le bundle dans un profil Harness dédié, distinct de celui utilisé au quotidien. Chargez le jeton du compte agent dans AGENT_GH_TOKEN sans l’écrire dans le dépôt. Exécutez ensuite ces commandes avec l’utilisateur superagent :

npm install -g @deepseek-ai/[email protected] [email protected]

git clone https://github.com/deepseek-ai/dsh-superagent-prototype.git ~/dsh-superagent
cd ~/dsh-superagent
git checkout --detach 8c32a9dc5d72c033816c6a8110b37f40cf94fba4
pnpm install && pnpm build

# A gh wrapper that only ever sees the agent account
mkdir -p "$HOME/.local/bin"
export PATH="$HOME/.local/bin:$PATH"
cat > ~/.local/bin/gh-agent <<'W'
#!/bin/sh
GH_CONFIG_DIR="$HOME/.config/gh-agent" exec gh "$@"
W
chmod +x ~/.local/bin/gh-agent
printf '%s' "$AGENT_GH_TOKEN" | gh-agent auth login --hostname github.com --with-token
gh-agent api user --jq .login            # your dedicated agent account

# Dedicated profile, then the bundle
dsh superagent --from-default-profile web --dump-config > /dev/null
dsh plugin --profile superagent add "link:$PWD"Propulsé par

Remarque : les exécutions de ce tutoriel utilisaient le commit 6337fc8, que DeepSeek a ensuite compressé dans 8c32a9d.

Utilisez l’exemple de profil du dépôt cloné pour définir un répertoire d’état et lier le panneau à 127.0.0.1:3082. Démarrez ensuite le service dans tmux :

scripts/dsh-superagent start
scripts/dsh-superagent statusPropulsé par

Ce profil sépare les redémarrages du service des sessions Harness personnelles. Il garde aussi le PATH du plugin et la configuration Git hors du profil normal.

status peut indiquer une configuration en attente ou repositoryUnset jusqu’à l’enregistrement de la Source GitHub à l’étape 3. À ce stade, confirmez seulement que le runtime répond et que le panneau Superagent s’ouvre ; n’attendez pas encore de Source ni de base CI.

Ouvrez Settings → Models dans le profil dédié et sélectionnez deepseek-flash. Dans Superagent → Settings → Eval et Execution, vérifiez que les deux rôles héritent du modèle du profil ou mentionnent explicitement deepseek-flash.

Étape 3 : configurer la surveillance GitHub Actions en mode observe

Laissez la surveillance du CI de la branche par défaut désactivée pendant que vous enregistrez la Source, la politique, la règle et les paramètres d’exécution. Activez‑la seulement après que le nouveau dépôt est au vert sur main, afin que la première lecture consigne une base propre.

Configurer la Source GitHub

Dans Settings → Sources, définissez le dépôt sur EXPERIMENT_REPO, pointez le champ CLI vers l’enveloppe dédiée gh-agent et laissez la surveillance du CI de la branche par défaut désactivée. Enregistrez la Source et attendez la fin d’un éventuel redémarrage avant de modifier la politique.

Configurer la politique d’admission du CI

Un résultat CI n’a pas d’expéditeur. Sa ligne d’admission n’a qu’une cellule, qui est par défaut sur ignore. Si vous laissez ce réglage, l’évaluation ne verra jamais le CI.

Définir une règle précise revenue-integrity

Remplacez les exemples par une règle nommée d’après le contrôle. Indiquez à l’évaluateur de ne pas supposer les causes :

{
  "rules": [{
    "id": "revenue-integrity",
    "name": "Revenue integrity CI failures",
    "enabled": true,
    "instruction": "A default-branch CI result in which the check named revenue-integrity newly fails. That check executes the pytest suite guarding the daily revenue totals. Judge only from the check names and results you can read for that commit; do not guess a root cause. Failures limited to other checks, such as docs-check (README links), do not match. A recovery where every check passes does not match. Work, if accepted: investigate the failing revenue-integrity tests, fix the pipeline without weakening or deleting any assertion, add a regression test, and open a pull request for human review. Never merge."
  }],
  "sources": {"github": {
    "allowed": [{"id": "<human-login>"}],
    "bots": [],
    "admission": {"ci": {"unlistedUnaddressed": "inferred"}}
  }}
}Propulsé par

Ajoutez une commande de préparation qui crée un worktree Git pour chaque Ticket. Chaque worker démarre alors depuis un checkout du dépôt :

C=/home/superagent/src/superagent-revenue-lab
git -C $C fetch --no-tags "https://github.com/$DSH_SUPERAGENT_GITHUB_REPOSITORY.git" \
  "${DSH_SUPERAGENT_GITHUB_PR_HEAD:-HEAD}:refs/dsh-superagent/$DSH_SUPERAGENT_TICKET" &&
git -C $C worktree add -b "agent/$DSH_SUPERAGENT_NAME" "$DSH_SUPERAGENT_DIR" "refs/dsh-superagent/$DSH_SUPERAGENT_TICKET"Propulsé par

Superagent renseigne ces variables pour chaque Ticket. Vérifiez que le répertoire obtenu contient bien le checkout attendu avant d’autoriser le travail.

L’assistant de configuration optionnel écrit la même Source, la politique, l’Eval et les blocs d’exécution. Il garde la surveillance CI désactivée au premier passage ; définissez toujours explicitement le dépôt d’expérience et l’auteur autorisé :

export REPO="$EXPERIMENT_REPO"
export ALLOWED="YOUR_GITHUB_LOGIN"
bash /path/to/configure.sh allPropulsé par

Garder l’exécution proactive désactivée

Laissez Eval en observe avec le modèle par défaut du profil. Après chaque événement, consultez l’onglet Eval pour la décision et l’onglet Execution pour tout Ticket.

Activer l’observation du CI et enregistrer la base

Après que les deux jobs GitHub Actions sont passés sur main, activez l’observation du CI de la branche par défaut. Avec le script d’assistance, utilisez son second passage :

OBSERVE_CI=true bash /path/to/configure.sh source
bash /path/to/configure.sh showPropulsé par

La première lecture enregistre l’état sans créer de travail. Vérifiez ces quatre conditions :

• La configuration ne présente aucune exigence en attente.

• La Source GitHub indique ready.

• La Source enregistre une base CI propre.

• Les onglets Trigger et Execution ne montrent ni Trigger ni Ticket pour la base.

Si l’un de ces contrôles échoue, arrêtez‑vous avant de créer l’échec de documentation. Les captures d’écran de la Source et d’Eval montrent la configuration finale.

Carte Source GitHub avec observation du CI. Image de l’auteur.

Paramètres Eval : une règle, mode observe. Image de l’auteur.

Étape 4 : tester un échec GitHub Actions sans lien

Utilisez un lien cassé dans le README comme échec sans lien. Comme la branche protégée rejette un contrôle en échec, utilisez un contournement d’administrateur humain seulement dans ce dépôt jetable ; ne donnez jamais ce contournement à l’agent.

sed -i 's|^- Tests: .*|&\n- Data dictionary: [docs/data-dictionary.md](docs/data-dictionary.md)|' README.md
git commit -am "docs: link the data dictionary from the README" && git pushPropulsé par

Une fois GitHub Actions terminé, docs-check a échoué et revenue-integrity est passé. Cela correspondait à la règle définie : Superagent a ignoré le candidat, car la règle chiffre d’affaires ne correspondait pas.

La décision a utilisé ignoredFromCard, un raccourci pour les candidats qui ne touchent aucune règle active. Ce contrôle valide donc l’aiguillage, plutôt que la règle elle‑même.

Rétablissez le README et attendez que les deux jobs passent. Superagent doit ignorer le retour au vert et rester inactif.

Étape 5 : déclencher un échec CI de revenue integrity

Suivez le même chemin réservé aux humains pour ajouter les données d’incident du dépôt tutoriel. Ce résumé montre la relecture et des paiements distincts sur une même commande, sans les colonnes d’horodatage :

event_id,order_id,amount_cents,delivery
evt_1009,ord_507,5000,first
evt_1010,ord_508,6400,first
evt_1011,ord_508,1600,first
evt_1009,ord_507,5000,replay
evt_1012,ord_509,2100,firstPropulsé par

Le dépôt conserve les colonnes d’horodatage complètes ; elles sont omises ici car elles ne définissent pas l’identité d’un événement. Le calcul indépendant préparé plus tôt attend 15 100 centimes, fixez donc cette valeur dans le test et ajoutez test_replayed_event_is_counted_once().

E       actual daily total: 20100
E       expected daily total: 15100
E       replay total: 8000 != 4000
FAILED tests/test_revenue.py::test_daily_totals_match_known_values
FAILED tests/test_revenue.py::test_replayed_event_is_counted_once
2 failed, 1 passedPropulsé par

Les 5 000 centimes supplémentaires proviennent d’un paiement compté deux fois. Modifier 15100 en 20100 ou supprimer le test de relecture ferait aussi passer le CI, mais ce ne serait pas une réparation.

Le workflow GitHub Actions en échec montre seulement revenue-integrity en échec. Son Trigger est arrivé après environ un intervalle d’interrogation.

Eval a marqué le candidat « accepterait », tandis que l’onglet Execution est resté vide. L’évaluateur a vu les noms de contrôles et leurs conclusions, pas le log pytest ; il savait donc quel garde‑fou avait échoué, mais pas pourquoi.

Le mode observe consigne uniquement « accepterait ». Image de l’auteur.

Étape 6 : autoriser la réparation et vérifier la pull request

La voie de demande explicite vue plus tôt autorise maintenant l’exécution. Les notifications GitHub peuvent arriver en retard.

Gérer une mention d’Issue manquée

Avec Superagent 6337fc8, la Source GitHub recouvre ses interrogations de cinq secondes et lit un fil notifié depuis le curseur ultérieur. Les notifications de mention sont arrivées 21 à 23 secondes plus tard, de sorte qu’une interrogation pouvait avancer au‑delà du message.

Ce minutage explique pourquoi le nouveau corps de l’Issue et certains commentaires ne sont jamais devenus des Triggers. Un retour de la communauté décrit le même mode d’échec.

Autoriser la réparation avec un commentaire GitHub

Publiez la demande à nouveau comme un commentaire frais et confirmez l’apparition de son Trigger. Superagent doit l’accepter comme demande explicite et démarrer le worker.

La mention en commentaire crée le Ticket autorisé. Image de l’auteur.

Contrôler la correction de déduplication des événements

La pull request résultante a indexé la correction sur event_id. Passez en revue le diff sans vous fier à sa description :

 def daily_revenue(events):
     """Return one row per UTC day with total revenue in cents."""
+    # The payment webhook may deliver the same event more than once, with a
+    # different received_at but the same event_id. One event_id is one payment
+    # event, so keep only its first delivery before aggregating.
+    events = events.drop_duplicates(subset="event_id", keep="first")
     days = events["occurred_at"].dt.strftime("%Y-%m-%d")Propulsé par

Elle a ajouté un test de relecture et n’a rien supprimé. La première commande de test a échoué faute de dépendances. Après création d’un environnement virtuel, la suite de tests visible est passée.

Tester des paiements partageant une commande

Demandez des changements sans mentionner l’agent : prouvez que deux paiements sur une même commande, identiques à event_id près, comptent tous deux, et qu’une relecture ne compte qu’une fois. La revue doit revenir sur le même Ticket sans nouvelle évaluation.

Le worker a répondu par un commit n’ajoutant qu’un test et laissant le pipeline inchangé. Avant l’approbation, vérifiez le SHA de tête exact et relancez la suite indépendante contre cette révision.

Les retours de revue alimentent le même Ticket. Image de l’auteur.

Vérifier la réparation avec des données indépendantes

Exécutez la suite de contrôle depuis l’environnement humain séparé contre la tête exacte de la pull request. Sur a43c541, les deux suites ont réussi 5 tests sur 5 sans supprimer d’assertion ; 62bac08 a conservé le même arbre.

Des tests rédigés par l’agent seul ne couvrent que les cas qu’il a choisis.

Étape 7 : fusionner le correctif et mesurer le retour au vert du CI

Après la fusion, vérifiez que main repasse au vert et que le retour au vert ne déclenche aucun nouveau travail. Passez ensuite en revue la trace des événements, le temps écoulé et la facturation du fournisseur.

Fusionner le correctif et confirmer le retour au vert

Après approbation manuelle et fusion, les deux contrôles de la branche par défaut sont passés. Superagent a ignoré le retour au vert, n’a pas démarré de nouveau travail et a clos le Ticket existant avec l’issue merged.

Évaluer la collecte des événements et les décisions

Suivez chaque événement de l’ingestion au résultat, comme l’explique notre guide d’évaluation des agents IA. Sur trois répétitions, les événements parvenus à Eval ont suivi le trajet attendu ; les manqués ont eu lieu lors de l’ingestion, pas à la décision du modèle.

Mesurer la justesse, le temps et le coût de la réparation

Le même scénario a tourné dans trois dépôts et distributions WSL neufs avec Superagent 6337fc8, Harness 0.2.1-rc.3, deepseek-flash et une seule politique. Les coûts utilisent le tarif DeepSeek hors pointe inférieur ; ce sont des reproductions, pas un benchmark.

Les trois réparations ont utilisé event_id ; chaque test de la suite de contrôle a réussi. L’ingestion a davantage varié : la mention dans le corps de l’Issue a été manquée à chaque fois, et la troisième reproduction a aussi manqué deux commentaires avant d’en recevoir un.

La deuxième reproduction a réécrit des commits, et l’approbation est arrivée avant le nouveau passage de la suite de contrôle. Le contrôle ultérieur est passé, mais l’ordre le plus sûr est : SHA de tête, suite de contrôle, puis approbation.

Limites et dépannage de DeepSeek Superagent

Plusieurs pannes ici ressemblent à du silence ; commencez donc par trouver où un événement s’est arrêté. Le plus frustrant est qu’une notification manquée et une ignorance correcte peuvent paraître identiques.

Échecs CI qui ne produisent aucun Trigger

Superagent suit les changements dans l’ensemble des échecs, de sorte que la lecture de base, un contrôle qui échoue encore, et des contrôles toujours en cours ne produisent rien. Un Trigger sans décision pointe généralement la cellule d’admission du CI, pas le modèle.

Demandes GitHub qui n’arrivent jamais

Les demandes peuvent échouer si l’expéditeur n’est pas autorisé, si la Source est désactivée, si le traitement est en pause, ou si GitHub notifie tard. Si ces points sont vérifiés, publiez un nouveau commentaire ; éditer le corps de l’Issue ne crée aucun événement.

Limites d’une réparation CI autonome

Le prototype ne fournit aucune frontière de sécurité. Les workers ont un accès complet en tant qu’utilisateur du système, et les règles de divulgation ne sont que du texte d’invite. Isolez le compte agent et limitez‑le au dépôt jetable.

Avant de passer à auto, collectez des semaines de décisions observées, comptez aussi bien les acceptations erronées que les ignorances erronées, et déplacez le worker de WSL vers une machine virtuelle séparée.

Conclusion

Le contraste initial s’est confirmé : deux états CI au rouge n’ont pas mené à la même action. Superagent a ignoré docs-check et a marqué revenue-integrity « accepterait », tandis que le mode observe a laissé le code intact jusqu’à la demande d’une personne.

Le correctif event_id était direct. L’ingestion des notifications a été moins fiable : la mention dans le corps de l’Issue n’a jamais atteint Eval, de sorte qu’une règle correcte ne pouvait rien y faire.

Je ne généraliserais pas ce résultat à la réparation CI autonome. Le dépôt était petit, la règle étroite, et la fusion contrôlée par l’humain. Ailleurs, partez d’un état vert, inspectez les décisions, autorisez explicitement, gardez des données de contrôle séparées et ne fusionnez qu’après des vérifications indépendantes.

Ma prochaine étape serait de corriger le chemin de notification GitHub et de répéter le workflow avec plus de types d’échecs. D’ici là, je laisserais le mode auto désactivé.