DeepSeek Superagent-tutorial: CI volgen en een fix autoriseren

Wat is de DeepSeek Superagent?

DeepSeek Superagent bewaakt één GitHub-repository via DeepSeek Harness. Teamregels bepalen of een event werk verdient; geaccepteerd werk gaat naar een aparte sessie. Deze tutorial behandelt het gepubliceerde prototype, niet enkel ontwerpideeën.

Harness levert de runtime; Superagent voegt eventmonitoring en autorisatie toe. Onze uitleg over de agent harness behandelt tools, geheugen en controle.

Hoe werkt de DeepSeek Superagent?

Een nieuw GitHub-event kan vier stadia doorlopen. Deze stadia houden de beslissing en de codewijziging gescheiden:

• Bron en Trigger: GitHub-polling verandert elk event in een Trigger op een Issue, pull request of main.

• Toelating: de poort labelt het als expliciet verzoek, afgeleide kandidaat, of niets.

• Eval en Beslissing:  afgeleide CI wordt beoordeeld aan de hand van de regels. Een expliciet verzoek wordt gerouteerd naar een accept-beslissing, reden explicitRouted.

• Ticket en Executor: geaccepteerd werk krijgt zijn autorisatie, workersessie en directory.

Een latere comment op de eigen Thread van het Ticket gaat naar zijn worker zonder nieuwe Eval. Het diagram toont drie GitHub-paden: default-branch CI, een expliciet verzoek en die review. Binnen het CI-pad liggen observe en auto aan tegenovergestelde uiteinden van een gematchte regel.

CI wordt beoordeeld. Verzoeken starten werk. Afbeelding door de auteur.

Wat is het verschil tussen observe-modus en auto-modus?

De accept-modus geldt alleen voor werk dat Superagent uit een event heeft afgeleid. Kies één van drie instellingen:

• off verwerpt afgeleide kandidaten.

• observe evalueert ze maar registreert een positief resultaat als "zou accepteren".

• auto start werk na een positieve evaluatie.

Een verzoek van een toegestane persoon werkt in elke modus en creëert zijn eigen Ticket. Laat auto uit voor deze tutorial.

Bouw een CI-reparatieworkflow in observe-modus

De pijplijn gebruikt pytest en twee GitHub Actions-jobs om events om te zetten in dagelijkse omzet. Superagent voegt een beslissing in voordat werk start. Onze Claude Code Routines-tutorial behandelt een andere eventgedreven workflow.

Traceer de replay-bug in dagelijkse omzet

De bug telt een opnieuw afgeleverde betaling dubbel. Elke rij heeft een event_id, order_id, tijdstempels en een bedrag. Eén order kan meerdere geldige betalingen bevatten.

Daarom kan dedupliceren op order_id een replay-test doorstaan maar echte betalingen verwijderen; de juiste sleutel is event_id. Bereken verwachte totalen met Pythons csv-module vóórdat je de agent autoriseert, zodat de output van de agent niet de antwoordsleutel is.

Definieer een geslaagde CI-reparatie

Succes hangt af van wat de workflow doet, niet alleen van wat de agent zegt. Stel deze voorwaarden in voordat je de repository wijzigt:

• Negeer een fout die alleen documentatie betreft.

• Match revenue-integrity zonder werk te starten.

• Open pas een pull request na een expliciet verzoek.

• Behoud assertions en slaag voor een vooraf gebouwde holdout-suite.

Bereid de holdout-suite voor voordat Superagent toegang krijgt. Zo blijft het verwachte gedrag buiten de ontwikkelingsinputs van de worker.

DeepSeek Superagent-vereisten en isolatie

Je hebt een DeepSeek API-sleutel, twee GitHub-accounts en een wegwerp-Linuxomgeving nodig. Voor de basis van Harness, zie onze basishandleiding.

Software en accounts die je nodig hebt

Pin de softwareversies zodat een upgrade de workflow niet kan veranderen. De laatste kolom legt de setup vast die is gebruikt voor de resultaten verderop in het artikel:

De agent heeft een eigen GitHub-gebruiker met schrijfrechten nodig omdat Superagent de notificaties van dat account leest. Voeg alleen de menselijke maintainers toe die werk mogen autoriseren aan de toegestane lijst.

Isoleer de agent van persoonlijke bestanden

Beide presets geven de OS-gebruiker volledige toegang en de gh-wrapper isoleert het proces niet. Gebruik een nieuwe WSL-distributie met automount en interop uitgeschakeld:

Als je al een wegwerp-Linux-virtuele machine hebt, sla dan het WSL-blok over en gebruik die machine. Houd niet-gerelateerde credentials en bestanden eraf.

# /etc/wsl.conf inside the disposable distribution
[automount]
enabled = false
mountFsTab = false
[interop]
enabled = false
appendWindowsPath = false
[user]
default = superagentMogelijk gemaakt door

Een dedicated superagent-gebruiker zou alleen de DeepSeek-sleutel en agenttoken moeten hebben. Dit vermindert toevallige toegang maar is geen security boundary; Microsofts WSL-beveiligingsmodel raadt een apart beheerde virtuele machine buiten WSL aan voor onbetrouwbare code.

Bescherm op GitHub main met een vereiste pull request, ten minste één onafhankelijke goedkeuring en beide CI-checks. Geef de agent schrijfrechten zonder administrator-bypass. Niets hiervan voorkomt prompt injection via Issue-tekst.

Stap 1: Bouw de Python-omzetpijplijn en CI-baseline

De gepubliceerde tutorial-repository heeft nu de samengevoegde reparatie op main, dus gebruik de huidige branch niet als starttoestand. Gebruik deze commits om de drie fasen te scheiden:

De pijplijn en tests hieronder zijn vereenvoudigd ten opzichte van de groene baseline (a6d2036), niet genomen uit de huidige main. Maak een wegwerprepository vanuit die commit voordat je de CI-stappen volgt:

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 --pushMogelijk gemaakt door

Gebruik deze nieuwe repository voor de gecontroleerde fouten en de branches van de agent. Laat de gepubliceerde repository ongewijzigd; de incident- en oplossing-commits zijn referenties ter vergelijking.

"""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 reportMogelijk gemaakt door

De baseline-dataset beslaat twee dagen en bevat meerdere echte betalingen voor één order. Pytest controleert bekende totalen en die gedeelde-ordercase, en niets test nog 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]Mogelijk gemaakt door

Geef elke job de naam van het gedrag dat het controleert. Dezelfde namen verschijnen dan in GitHub en in de Trigger-tekst van 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 fileMogelijk gemaakt door

Als kale pytest revenue niet kan importeren, voeg dan een pytest.ini toe met pythonpath = .. Bevestig dat beide jobs slagen op main voordat je Superagent installeert.

De gepubliceerde experiment/holdout-directory documenteert de oorspronkelijke run maar is zichtbaar in de publieke clone. Maak voor een nieuw experiment een frisse suite buiten elke checkout en elk bestandssysteem dat de worker kan lezen.

Hash die suite voordat je het reparatieverzoek verstuurt. Dek deze gevallen af:

• Herhaalde bezorgingen van één event.
• Verschillende events met dezelfde order-ID.
• Een input-DataFrame dat ongewijzigd moet blijven.
• De verwachte outputkolommen en sorteervolgorde.

Houd deze suite verborgen tot de review. Stap 6 draait hem vanuit de aparte menselijke omgeving nadat de worker klaar is.

Het volgende diagram scheidt de ontwikkelingsinputs van de worker van de uiteindelijke controle door de maintainer.

Holdout-data blijft buiten de worker. Afbeelding door de auteur.

Stap 2: Installeer DeepSeek Superagent en koppel GitHub

Installeer de bundel in een dedicated Harness-profiel, apart van het profiel voor dagelijks werk. Laad het token van het agentaccount in AGENT_GH_TOKEN zonder het in de repository te schrijven. Voer daarna deze commando’s uit als de gebruiker 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"Mogelijk gemaakt door

Opmerking: De runs in deze tutorial gebruikten commit 6337fc8, die DeepSeek later samenvatte in 8c32a9d.

Gebruik het profielvoorbeeld in de gekloonde repository om een state-directory te zetten en het paneel te binden aan 127.0.0.1:3082. Start vervolgens de service in tmux:

scripts/dsh-superagent start
scripts/dsh-superagent statusMogelijk gemaakt door

Dit profiel scheidt servicerestarts van persoonlijke Harness-sessies. Het houdt ook de PATH- en Git-instellingen van de plugin buiten het normale profiel.

status kan setup pending of repositoryUnset rapporteren totdat je in Stap 3 de GitHub Source opslaat. Bevestig op dit punt alleen dat de runtime antwoordt en het Superagent-paneel opent; verwacht nog geen Source of CI-baseline.

Open Settings → Models in het dedicated profiel en selecteer deepseek-flash. Bevestig in Superagent → Settings → Eval en Execution dat beide rollen dat profielmodel overerven of noem deepseek-flash expliciet.

Stap 3: Configureer GitHub Actions-monitoring in observe-modus

Laat observatie van default-branch CI uit terwijl je de Source, policy, regel en executor-instellingen opslaat. Zet dit pas aan nadat de nieuwe repository een groene main heeft, zodat de eerste meting een schone baseline vastlegt.

Configureer de GitHub Source

Stel in Settings → Sources de repository in op EXPERIMENT_REPO, wijs het CLI-veld naar de dedicated gh-agent-wrapper, en laat observatie van default-branch CI uit. Sla de Source op en wacht tot een eventuele herstart klaar is voordat je het beleid wijzigt.

Configureer het CI-toelatingsbeleid

Een CI-resultaat heeft geen afzender. De toelatingsrij heeft één cel, die standaard op ignore staat. Als je die instelling niet wijzigt, ziet Eval nooit CI.

Definieer een smalle revenue-integrity-regel

Vervang de voorbeeldregels door één regel die is vernoemd naar de check. Zeg tegen de evaluator dat er niet naar oorzaken gegist mag worden:

{
  "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"}}
  }}
}Mogelijk gemaakt door

Voeg een prepare-commando toe dat voor elk Ticket een Git worktree maakt. Elke worker start dan vanuit een repository-checkout:

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"Mogelijk gemaakt door

Superagent vult deze variabelen in voor elk Ticket. Controleer of de resulterende directory de verwachte checkout bevat voordat je werk autoriseert.

De optionele configuratiehelper schrijft dezelfde Source-, policy-, Eval- en executorblokken. Hij houdt CI-observatie uit tijdens de eerste pass; zet altijd expliciet de experiment-repository en toegestane aanvrager:

export REPO="$EXPERIMENT_REPO"
export ALLOWED="YOUR_GITHUB_LOGIN"
bash /path/to/configure.sh allMogelijk gemaakt door

Houd proactieve uitvoering uitgeschakeld

Laat Eval in observe staan met het standaardmodel van het profiel. Controleer na elk event het tabblad Eval voor de beslissing en het tabblad Execution voor een eventueel Ticket.

Zet CI-observatie aan en leg de baseline vast

Zet observatie van default-branch CI aan nadat beide GitHub Actions-jobs slagen op main. Met het helperscript gebruik je de tweede pass:

OBSERVE_CI=true bash /path/to/configure.sh source
bash /path/to/configure.sh showMogelijk gemaakt door

De eerste meting legt state vast zonder werk te creëren. Verifieer alle vier de voorwaarden:

• Setup toont geen openstaande vereiste.

• De GitHub Source meldt ready.

• De Source registreert een schone CI-baseline.

• De tabs Trigger en Execution tonen geen baseline-Trigger of Ticket.

Als één van deze checks faalt, stop dan voordat je de documentatiefout maakt. De schermbeelden van Source en Eval tonen de uiteindelijke configuratie.

GitHub Source-kaart met CI-observatie. Afbeelding door de auteur.

Eval-instellingen: één regel, observe-modus. Afbeelding door de auteur.

Stap 4: Test een niet-gerelateerde GitHub Actions-fout

Gebruik een kapotte README-link als niet-gerelateerde fout. Omdat de beschermde branch een mislukte check afwijst, gebruik je alleen in deze wegwerprepository een bypass door een menselijke administrator; geef die bypass nooit aan de 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 pushMogelijk gemaakt door

Toen GitHub Actions klaar was, faalde docs-check en slaagde revenue-integrity. Dat kwam overeen met de door mij ingestelde regel: Superagent negeerde de kandidaat omdat de omzetregel niet matchte.

De beslissing gebruikte ignoredFromCard, een snelkoppeling voor kandidaten die geen actieve regel raken. Deze check dekt dus de routering in plaats van de regel zelf.

Draai de README-wijziging terug en wacht tot beide jobs slagen. Superagent zou het herstel moeten negeren en stil blijven.

Stap 5: Trigger een revenue-integrity CI-fout

Gebruik hetzelfde pad dat alleen voor mensen is om de incidentdata uit de tutorial-repository toe te voegen. Deze samenvatting toont de replay en de afzonderlijke betalingen op één order zonder de timestamp-kolommen:

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,firstMogelijk gemaakt door

De repository houdt de volledige timestamp-kolommen; ze zijn hier weggelaten omdat ze de eventidentiteit niet bepalen. De eerder voorbereide onafhankelijke berekening verwacht 15.100 cent, dus stel die waarde in de test in en voeg test_replayed_event_is_counted_once() toe.

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 passedMogelijk gemaakt door

De extra 5.000 cent is één betaling die dubbel is geteld. 15100 aanpassen naar 20100 of de replay-test verwijderen zou CI ook groen maken, en geen van beide is een reparatie.

De mislukte GitHub Actions-workflow toont alleen revenue-integrity die faalt. De Trigger arriveerde na ongeveer één polling-interval.

Eval markeerde de kandidaat als "zou accepteren", terwijl het tabblad Execution leeg bleef. De evaluator zag checknamen en conclusies, niet de pytest-log, dus hij wist welke guard faalde maar niet waarom.

Observe-modus logt alleen "zou accepteren". Afbeelding door de auteur.

Stap 6: Autoriseer de reparatie en verifieer de pull request

Het eerder besproken pad met expliciet verzoek autoriseert nu de uitvoering. GitHub-notificaties kunnen laat zijn.

Ga om met een gemiste GitHub Issue-mention

Bij Superagent 6337fc8 overlapt de GitHub Source polls met vijf seconden en leest een genotificeerde thread vanaf de latere cursor. Mention-notificaties arriveerden 21 tot 23 seconden later, waardoor een poll voorbij het bericht kon schuiven.

Die timing verklaart waarom de nieuwe Issue-body en sommige comments nooit Triggers werden. Een communityrapport beschrijft dezelfde faalmodus.

Autoriseer de reparatie met een GitHub-comment

Plaats het verzoek opnieuw als een frisse comment en bevestig dat de Trigger verschijnt. Superagent zou het als expliciet verzoek moeten accepteren en de worker starten.

Comment-mention creëert het geautoriseerde Ticket. Afbeelding door de auteur.

Controleer de event-deduplicatie-fix van de agent

De resulterende pull request baseerde de fix op event_id. Review de diff in plaats van op de beschrijving te vertrouwen:

 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")Mogelijk gemaakt door

Er werd een replay-test toegevoegd en niets verwijderd. Het eerste testcommando faalde omdat dependencies ontbraken. Nadat de worker een virtual environment had gemaakt, slaagde de zichtbare testsuite.

Test betalingen die een order delen

Vraag wijzigingen aan zonder de agent te noemen: bewijs dat twee betalingen op één order, identiek behalve event_id, allebei meetellen, en een replay van één telt één keer. De review zou hetzelfde Ticket moeten bereiken zonder nieuwe Eval.

De worker reageerde met een commit die alleen een test toevoegde en de pijplijn ongewijzigd liet. Controleer vóór goedkeuring de exacte head-SHA en voer de onafhankelijke suite opnieuw uit tegen die revisie.

Reviewfeedback gaat verder in hetzelfde Ticket. Afbeelding door de auteur.

Controleer de reparatie met onafhankelijke data

Draai de holdout vanuit de aparte menselijke omgeving tegen exact het hoofd van de pull request. Op a43c541 slaagden beide suites voor 5 van 5 tests zonder een assertion te verwijderen; 62bac08 behield dezelfde boom.

Tests die alleen door de agent zijn geschreven, dekken alleen de gevallen die de agent koos.

Stap 7: Merge de fix en meet CI-herstel

Controleer na de merge dat main weer groen wordt en dat herstel geen nieuw werk start. Bekijk daarna de eventtrace, verstreken tijd en providerkosten.

Merge de fix en bevestig CI-herstel

Na handmatige goedkeuring en merge slaagden beide default-branch-checks. Superagent negeerde het herstel, startte geen nieuw werk en sloot het bestaande Ticket met de uitkomst merged.

Evalueer eventintake en beslissingen

Volg elk event van intake tot uitkomst, zoals onze gids voor het evalueren van AI-agents beschrijft. Over drie herhalingen namen events die Eval bereikten de verwachte route; misses traden op tijdens intake, niet bij de modelbeslissing.

Meet correctheid, tijd en kosten van de reparatie

Hetzelfde scenario draaide in drie frisse repositories en WSL-distributies met Superagent 6337fc8, Harness 0.2.1-rc.3, deepseek-flash en één policy. Kosten gebruiken het lagere daluren-tarief van DeepSeek; dit zijn reproducties, geen benchmark.

Alle drie reparaties gebruikten event_id; elke holdout-test slaagde. Intake varieerde meer: de mention in de Issue-body werd elke keer gemist, en de derde reproductie miste ook twee comments voordat er één binnenkwam.

De tweede reproductie herschreef commits, en goedkeuring kwam binnen vóór de holdout opnieuw draaide. De latere check slaagde, maar de veiligere volgorde is head-SHA, holdout, dan goedkeuring.

DeepSeek Superagent-beperkingen en troubleshooting

Verschillende fouten hier lijken op stilte, dus begin met vinden waar een event stopte. Het lastige is dat een gemiste notificatie en een correcte ignore hetzelfde kunnen lijken.

CI-fouten die geen Trigger opleveren

Superagent volgt veranderingen in de set die faalt, dus de baselinereading, een check die blijft falen en checks die nog lopen leveren niets op. Een Trigger zonder beslissing wijst meestal naar de CI-toelatingscel, niet naar het model.

GitHub-verzoeken die nooit aankomen

Verzoeken kunnen falen als de afzender niet is toegestaan, de Source uitstaat, verwerking gepauzeerd is of GitHub laat notificeert. Als die checks slagen, plaats dan een nieuwe comment; het bewerken van de Issue-body creëert geen event.

Grenzen van autonome CI-reparatie

Het prototype biedt geen security boundary. Workers hebben volledige OS-gebruikertoegang, en disclosure-regels zijn prompttekst. Isoleer het agentaccount en beperk het tot de wegwerprepository.

Voordat je naar auto schakelt, verzamel weken aan geobserveerde beslissingen, tel verkeerde accepts én verkeerde ignores, en verplaats de worker van WSL naar een aparte virtuele machine.

Tot slot

Het contrast uit de opening hield stand: twee rode CI-staten leidden niet tot dezelfde actie. Superagent negeerde docs-check en markeerde revenue-integrity als "zou accepteren", terwijl observe-modus de code onaangeroerd liet tot iemand de reparatie vroeg.

De event_id-patch was rechttoe rechtaan. Notificatie-intake was minder betrouwbaar: de vermelding in de Issue-body bereikte Eval nooit, dus een correcte regel kon niet helpen.

Ik zou dit resultaat niet veralgemeniseren naar autonome CI-reparatie. De repository was klein, de regel smal en de merge menselijk gestuurd. Elders: begin groen, inspecteer beslissingen, autoriseer expliciet, houd holdout-data apart en merge na onafhankelijke checks.

Mijn volgende stap zou zijn om het GitHub-notificatiepad te repareren en de workflow te herhalen met meer fouttypes. Totdat dat bewijs er is, houd ik auto-modus uit.