Tutorial DeepSeek Superagent: urmărește CI și autorizează o corecție

Ce este DeepSeek Superagent?

DeepSeek Superagent urmărește un singur depozit GitHub prin DeepSeek Harness. Regulile echipei decid dacă un eveniment merită muncă; munca acceptată merge într-o sesiune separată. Acest tutorial acoperă prototipul publicat, nu idei doar de design.

Harness oferă runtime-ul; Superagent adaugă monitorizarea evenimentelor și autorizarea. Explicatorul nostru despre agent harness acoperă uneltele, memoria și controlul.

Cum funcționează DeepSeek Superagent?

Un nou eveniment GitHub poate trece prin patru etape. Aceste etape păstrează separat decizia și schimbarea de cod:

• Sursă și Trigger: interogarea GitHub transformă fiecare eveniment într-un Trigger pe un Issue, un pull request sau pe main.

• Admisie: poarta îl etichetează drept cerere explicită, candidat dedus sau nimic.

• Eval și Decizie:  CI dedus este judecat după reguli. O cerere explicită este direcționată spre o Decizie de acceptare, motiv explicitRouted.

• Ticket și Executor: munca acceptată primește autorizația, sesiunea worker și directorul ei.

Un comentariu ulterior pe Thread-ul propriu al Ticket-ului ajunge la worker-ul său fără un nou Eval. Diagrama arată trei căi GitHub: CI pe ramura implicită, o cerere explicită și acea revizuire. În interiorul căii CI, observe și auto lasă o regulă potrivită la capete diferite.

CI este judecat. Cererile pornesc munca. Imagine de autor.

Care este diferența dintre modul observe și modul auto?

Modul de acceptare se aplică doar muncii pe care Superagent a dedus-o dintr-un eveniment. Alege unul dintre trei setări:

• off aruncă la gunoi candidații deduși.

• observe îi evaluează, dar înregistrează un rezultat pozitiv ca „ar accepta”.

• auto pornește munca după o evaluare pozitivă.

O cerere de la o persoană permisă funcționează în orice mod și creează propriul Ticket. Ține auto oprit pentru acest tutorial.

Construiește un flux de reparare CI în modul Observe

Pipeline-ul folosește pytest și două joburi GitHub Actions pentru a transforma evenimentele în venituri zilnice. Superagent inserează o decizie înainte ca munca să înceapă. Tutorialul nostru despre Claude Code Routines acoperă un alt flux de lucru bazat pe evenimente.

Urmărește bugul de replay în veniturile zilnice

Bugul numără de două ori o plată redifuzată. Fiecare rând are un event_id, order_id, marcaje de timp și o sumă. O comandă poate conține mai multe plăți valide.

De aceea deduplicarea pe order_id poate trece un test de replay, dar șterge plăți reale; cheia corectă este event_id. Calculează totalurile așteptate cu modulul csv din Python înainte de a autoriza agentul, astfel încât ieșirea agentului să nu fie cheia de răspuns.

Definește o reparare CI reușită

Succesul depinde de ceea ce face fluxul de lucru, nu doar de ce spune agentul. Stabilește aceste condiții înainte de a schimba depozitul:

• Ignoră un eșec doar de documentație.

• Potrivește revenue-integrity fără a începe munca.

• Deschide un pull request doar după o cerere explicită.

• Păstrează aserțiunile și treci o suită de holdout preconstruită.

Pregătește suita de holdout înainte ca Superagent să primească acces. Asta păstrează comportamentul așteptat în afara intrărilor de dezvoltare ale worker-ului.

Cerințe prealabile și izolare pentru DeepSeek Superagent

Ai nevoie de o cheie API DeepSeek, două conturi GitHub și un mediu Linux de unică folosință. Pentru elementele de bază ale Harness, vezi ghidul nostru de configurare de bază.

Software și conturi necesare

Blochează versiunile software-ului pentru ca un upgrade să nu poată schimba fluxul de lucru. Ultima coloană înregistrează configurarea folosită pentru rezultatele de mai târziu din articol:

Agentul are nevoie de propriul utilizator GitHub cu acces de scriere deoarece Superagent citește notificările acelui cont. Adaugă pe lista de permise doar menținătorii umani care pot autoriza munca.

Izolează agentul de fișierele personale

Ambele presetări dau utilizatorului din sistemul de operare (OS) acces complet, iar wrapperul gh nu izolează procesul. Folosește o distribuție WSL proaspătă cu automount și interop dezactivate:

Dacă ai deja o mașină virtuală Linux de unică folosință, sari peste blocul WSL și folosește-o în schimb. Ține credențialele și fișierele fără legătură departe de ea.

# /etc/wsl.conf inside the disposable distribution
[automount]
enabled = false
mountFsTab = false
[interop]
enabled = false
appendWindowsPath = false
[user]
default = superagentFuncționează cu

Un utilizator dedicat superagent ar trebui să dețină doar cheia DeepSeek și tokenul agentului. Asta reduce accesul accidental, dar nu este o barieră de securitate; modelul de securitate WSL de la Microsoft recomandă o mașină virtuală administrată separat în afara WSL pentru cod neîncredințat.

Pe GitHub, protejează main cu un pull request obligatoriu, cel puțin o aprobare independentă și ambele verificări CI. Dă agentului acces de scriere fără bypass de administrator. Nimic din asta nu oprește injectarea de prompt prin textul Issue-ului.

Pasul 1: Construiește pipeline-ul de venituri în Python și baza CI

Depozitul de tutorial publicat are acum repararea îmbinată pe main, așa că nu folosi ramura curentă drept stare inițială. Folosește aceste commit-uri pentru a separa cele trei etape:

Pipeline-ul și testele de mai jos sunt simplificate din baza verde (a6d2036), nu preluate din main-ul curent. Creează un depozit de unică folosință din acel commit înainte de a urma pașii 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 --pushFuncționează cu

Folosește acest nou depozit pentru eșecurile controlate și ramurile agentului. Lasă depozitul publicat neschimbat; commit-urile de incident și soluție sunt referințe pentru comparație.

"""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 reportFuncționează cu

Setul de date de bază acoperă două zile și include mai multe plăți reale pentru o comandă. Pytest verifică totaluri cunoscute și acel caz cu comandă comună, iar nimic nu testează încă replays:

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]Funcționează cu

Denumește fiecare job după comportamentul pe care îl verifică. Aceleași denumiri vor apărea apoi în GitHub și în textul Trigger-ului din 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 fileFuncționează cu

Dacă pytest simplu nu poate importa revenue, adaugă un pytest.ini cu pythonpath = .. Confirmă că ambele joburi trec pe main înainte de a instala Superagent.

Directorul publicat experiment/holdout documentează rularea originală, dar este vizibil în clonarea publică. Pentru un experiment nou, creează o suită proaspătă în afara oricărui checkout și sistem de fișiere pe care worker-ul îl poate citi.

Calculează hash-ul acelei suite înainte de a trimite cererea de reparare. Acoperă aceste cazuri:

• Livrări repetate ale aceluiași eveniment.
• Evenimente diferite cu același ID de comandă.
• Un DataFrame de intrare care trebuie să rămână neschimbat.
• Coloanele de ieșire așteptate și ordinea de sortare.

Ține această suită ascunsă până la revizuire. Pasul 6 o rulează din mediul uman separat după ce worker-ul termină.

Diagrama următoare separă intrările de dezvoltare ale worker-ului de verificarea finală a menținătorului.

Datele de holdout rămân în afara worker-ului. Imagine de autor.

Pasul 2: Instalează DeepSeek Superagent și conectează GitHub

Instalează pachetul într-un profil Harness dedicat, separat de profilul folosit pentru munca zilnică. Încarcă tokenul contului agentului în AGENT_GH_TOKEN fără a-l scrie în depozit. Apoi rulează aceste comenzi ca utilizator 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"Funcționează cu

Notă: Rulările din acest tutorial au folosit commitul 6337fc8, pe care DeepSeek l-a comasat ulterior în 8c32a9d.

Folosește exemplul de profil din depozitul clonat pentru a seta un director de stare și a lega panoul la 127.0.0.1:3082. Apoi pornește serviciul în tmux:

scripts/dsh-superagent start
scripts/dsh-superagent statusFuncționează cu

Acest profil separă repornirile serviciului de sesiunile tale personale Harness. De asemenea, păstrează PATH-ul pluginului și setările Git în afara profilului normal.

status poate raporta configurare în așteptare sau repositoryUnset până salvezi Sursa GitHub la Pasul 3. În acest punct, confirmă doar că runtime-ul răspunde și că se deschide panoul Superagent; nu te aștepta încă la o Sursă sau la baza CI.

Deschide Settings → Models în profilul dedicat și selectează deepseek-flash. În Superagent → Settings → Eval și Execution, confirmă că ambele roluri moștenesc modelul acelui profil sau denumește explicit deepseek-flash.

Pasul 3: Configurează monitorizarea GitHub Actions în modul Observe

Lasă observarea CI pe ramura implicită oprită cât timp salvezi setările pentru Sursă, politică, regulă și executor. Pornește-o doar după ce noul depozit are un main verde, astfel încât prima citire să înregistreze o bază curată.

Configurează Sursa GitHub

În Settings → Sources, setează depozitul la EXPERIMENT_REPO, indică în câmpul CLI wrapperul dedicat gh-agent și păstrează observarea CI pe ramura implicită oprită. Salvează Sursa și așteaptă finalizarea oricărei reporniri înainte de a schimba politica.

Configurează politica de admitere pentru CI

Un rezultat CI nu are expeditor. Rândul de admitere are o singură celulă, care implicit este ignore. Dacă lași setarea neschimbată, Eval nu vede niciodată CI.

Definește o regulă îngustă pentru revenue-integrity

Înlocuiește regulile de exemplu cu o singură regulă numită după verificare. Spune evaluatorului să nu ghicească motive:

{
  "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"}}
  }}
}Funcționează cu

Adaugă o comandă de pregătire care creează un worktree Git pentru fiecare Ticket. Fiecare worker pornește apoi de la un checkout al depozitului:

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"Funcționează cu

Superagent completează aceste variabile pentru fiecare Ticket. Verifică faptul că directorul rezultat conține checkout-ul așteptat înainte de a autoriza munca.

Helperul opțional de configurare scrie aceeași Sursă, politică, blocuri Eval și executor. Păstrează observarea CI oprită în prima trecere; setează întotdeauna explicit depozitul de experiment și solicitantul permis:

export REPO="$EXPERIMENT_REPO"
export ALLOWED="YOUR_GITHUB_LOGIN"
bash /path/to/configure.sh allFuncționează cu

Păstrează execuția proactivă dezactivată

Ține Eval în observe cu modelul implicit al profilului. După fiecare eveniment, verifică fila Eval pentru Decizie și fila Execution pentru orice Ticket.

Pornește observarea CI și înregistrează baza

După ce ambele joburi GitHub Actions trec pe main, pornește observarea CI pe ramura implicită. Cu scriptul helper, folosește a doua trecere:

OBSERVE_CI=true bash /path/to/configure.sh source
bash /path/to/configure.sh showFuncționează cu

Prima citire înregistrează starea fără a crea muncă. Verifică toate cele patru condiții:

• Configurarea nu arată nicio cerință în așteptare.

• Sursa GitHub raportează ready.

• Sursa înregistrează o bază CI curată.

• Filele Trigger și Execution nu arată niciun Trigger sau Ticket de bază.

Dacă vreuna dintre aceste verificări eșuează, oprește-te înainte de a crea eșecul de documentație. Capturile de ecran ale Sursei și Eval arată configurația finală.

Cardul GitHub Source cu observarea CI. Imagine de autor.

Setări Eval: o singură regulă, modul observe. Imagine de autor.

Pasul 4: Testează un eșec GitHub Actions fără legătură

Folosește un link README stricat ca eșec fără legătură. Deoarece ramura protejată respinge o verificare eșuată, folosește bypass-ul unui administrator uman doar în acest depozit de unică folosință; nu oferi niciodată acel bypass agentului.

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 pushFuncționează cu

Când GitHub Actions a terminat, docs-check a eșuat și revenue-integrity a trecut. Asta s-a potrivit cu regula setată: Superagent a ignorat candidatul pentru că regula de venituri nu s-a potrivit.

Decizia a folosit ignoredFromCard, un shortcut pentru candidații care nu ating o regulă activă. Așadar, această verificare acoperă rutarea, nu regula în sine.

Revino la schimbarea din README și așteaptă ca ambele joburi să treacă. Superagent ar trebui să ignore revenirea și să rămână inactiv.

Pasul 5: Declanșează un eșec CI de integritate a veniturilor

Folosește același traseu doar-uman pentru a adăuga datele de incident din depozitul tutorial. Acest rezumat arată replay-ul și plățile separate pe o comandă, fără coloanele cu marcaje de timp:

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,firstFuncționează cu

Depozitul păstrează coloanele complete de timp; sunt omise aici pentru că nu decid identitatea evenimentului. Calculul independent pregătit anterior așteaptă 15.100 de cenți, așa că setează acea valoare în test și adaugă 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 passedFuncționează cu

Cei 5.000 de cenți în plus reprezintă o plată numărată de două ori. Editarea lui 15100 la 20100 sau ștergerea testului de replay ar întoarce și ele CI pe verde, dar niciuna nu e o reparare.

Fluxul GitHub Actions eșuat arată doar revenue-integrity în eșec. Trigger-ul lui a sosit după cam un interval de interogare.

Eval a marcat candidatul „ar accepta”, în timp ce fila Execution a rămas goală. Evaluatorul a văzut nume de verificări și concluzii, nu logul pytest, așa că a știut ce gard a eșuat, dar nu și de ce.

Modul observe înregistrează doar „ar accepta”. Imagine de autor.

Pasul 6: Autorizează repararea și verifică pull request-ul

Traseul cu cerere explicită acoperit mai devreme autorizează acum execuția. Notificările GitHub pot întârzia.

Gestionează o mențiune GitHub Issue ratată

La Superagent 6337fc8, Sursa GitHub suprapune interogările cu cinci secunde și citește un thread notificat de la cursorul ulterior. Notificările de mențiune au sosit cu 21–23 secunde mai târziu, astfel încât o interogare putea trece peste mesaj.

Acea temporizare explică de ce noul corp de Issue și unele comentarii nu au devenit Trigger-e. Un raport din comunitate descrie același mod de eșec.

Autorizează repararea cu un comentariu pe GitHub

Publică din nou cererea ca un comentariu nou și confirmă că apare Trigger-ul lui. Superagent ar trebui să o accepte ca cerere explicită și să pornească worker-ul.

Mențiunea din comentariu creează Ticket-ul autorizat. Imagine de autor.

Verifică corecția de deduplicare a evenimentelor făcută de agent

Pull request-ul rezultat a bazat corecția pe event_id. Revizuiește diff-ul, nu te baza pe descriere:

 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")Funcționează cu

A adăugat un test pentru replay și nu a șters nimic. Prima comandă de test a eșuat din cauza dependențelor lipsă. După ce worker-ul a creat un mediu virtual, suita de teste vizibilă a trecut.

Testează plăți care împart o comandă

Cere schimbări fără a menționa agentul: demonstrează că două plăți pe aceeași comandă, identice în afară de event_id, se numără ambele, iar un replay al uneia este numărat o singură dată. Revizuirea ar trebui să ajungă la același Ticket fără un nou Eval.

Worker-ul a răspuns cu un commit care a adăugat doar un test și a lăsat pipeline-ul neschimbat. Înainte de aprobare, verifică exact SHA-ul head și rulează din nou suita independentă împotriva acelei revizii.

Feedback-ul de revizuire continuă același Ticket. Imagine de autor.

Verifică repararea cu date independente

Rulează holdout-ul din mediul uman separat împotriva exactului head al pull request-ului. Pe a43c541, ambele suite au trecut 5 din 5 teste fără a elimina vreo aserțiune; 62bac08 a păstrat același arbore.

Testele scrise doar de agent acoperă doar cazurile alese de agent.

Pasul 7: Îmbină corecția și măsoară revenirea CI

După îmbinare, verifică faptul că main revine pe verde și că revenirea nu pornește muncă nouă. Apoi analizează urma evenimentelor, timpul scurs și costul furnizorului.

Îmbină corecția și confirmă revenirea CI

După aprobare manuală și îmbinare, ambele verificări pe ramura implicită au trecut. Superagent a ignorat revenirea, nu a pornit muncă nouă și a închis Ticket-ul existent cu rezultatul merged.

Evaluează preluarea evenimentelor și deciziile

Urmărește fiecare eveniment de la preluare până la rezultat, așa cum descrie ghidul nostru pentru evaluarea agenților AI. Pe parcursul a trei repetiții, evenimentele care au ajuns la Eval au urmat traseul așteptat; ratările au apărut la preluare, nu la Decizia modelului.

Măsoară corectitudinea, timpul și costul reparării

Același scenariu a rulat în trei depozite și distribuții WSL proaspete cu Superagent 6337fc8, Harness 0.2.1-rc.3, deepseek-flash și o singură politică. Costurile folosesc tariful DeepSeek redus în afara vârfului; acestea sunt reproduceri, nu un rezultat de referință.

Toate cele trei reparări au folosit event_id; fiecare test de holdout a trecut. Preluarea a variat mai mult: mențiunea din corpul Issue-ului a fost ratată de fiecare dată, iar a treia reproducere a mai ratat două comentarii înainte să sosească unul.

A doua reproducere a rescris commit-uri, iar aprobarea a sosit înainte ca holdout-ul să ruleze din nou. Verificarea ulterioară a trecut, dar ordinea mai sigură este SHA-ul head, holdout, apoi aprobarea.

Limitări și depanare pentru DeepSeek Superagent

Câteva eșecuri de aici par tăcere, așa că începe prin a găsi unde s-a oprit un eveniment. Partea frustrantă este că o notificare ratată și un ignore corect pot arăta la fel.

Eșecuri CI care nu produc Trigger

Superagent urmărește schimbările în setul de eșecuri, astfel încât citirea de bază, o verificare care continuă să pice și verificările încă în curs nu produc nimic. Un Trigger fără Decizie indică de obicei spre celula de admitere CI, nu spre model.

Cererile GitHub care nu ajung niciodată

Cererile pot eșua când expeditorul nu este permis, Sursa e oprită, procesarea e pusă pe pauză sau GitHub notifică târziu. Dacă acele verificări trec, postează un comentariu nou; editarea corpului Issue-ului nu creează eveniment.

Limitele reparării CI autonome

Prototipul nu oferă o barieră de securitate. Worker-ii au acces complet al utilizatorului OS, iar regulile de divulgare sunt text de prompt. Izolează contul agentului și limitează-l la depozitul de unică folosință.

Înainte de a trece pe auto, adună săptămâni de Decizii observate, numără acceptările greșite precum și ignorările greșite și mută worker-ul din WSL într-o mașină virtuală separată.

Gânduri finale

Contrastul de la început s-a menținut: două stări CI roșii nu au dus la aceeași acțiune. Superagent a ignorat docs-check și a marcat revenue-integrity drept „ar accepta”, în timp ce modul observe a ținut codul neatins până când o persoană a solicitat repararea.

Patch-ul pe event_id a fost direct. Preluarea notificărilor a fost mai puțin fiabilă: mențiunea din corpul Issue-ului nu a ajuns niciodată la Eval, așa că o regulă corectă nu a putut ajuta.

Nu aș generaliza acest rezultat la repararea CI autonomă. Depozitul a fost mic, regula îngustă, iar îmbinarea controlată de om. În alte părți, pornește pe verde, inspectează Deciziile, autorizează explicit, ține datele de holdout separate și îmbină după verificări independente.

Următorul meu pas ar fi să repar traseul notificărilor GitHub și să repet fluxul de lucru cu mai multe tipuri de eșecuri. Până există acele dovezi, aș ține modul auto oprit.