chimera-reproduce-before-diagnosing
Una diagnosi è un'affermazione su una macchina che non hai eseguito. Riproduci prima il fallimento con un solo comando breve — soprattutto quando la diagnosi è arrivata da qualcun altro.
Conferita da chi ha letto la scheda, non rivendicata dal file su se stesso. Una scheda che l'agente distilla durante un'esecuzione che ha consumato contenuti non affidabili nasce contaminata e resta in attesa di revisione prima di essere mai recuperata.
Quando viene in mente
- è arrivata una segnalazione di bug
- un altro agente ha spiegato la causa
- il traceback punta a un file
- correggo qualcosa che non ho visto fallire
Il valore di solito sta in Evita e Verifica. Fai è la sezione che scrivono tutti.
Il corpo della scheda qui sopra è una traduzione. L'originale inglese è ciò che la CLI importa, ciò che l'agente legge in esecuzione e ciò che l'hash qui sotto attesta.
Trigger
Stai per modificare del codice a causa di un fallimento che non hai visto accadere di persona: un job di CI rosso, un estratto di log in una issue, la descrizione di un utente, oppure — il caso di cui questa card parla davvero — una diagnosi sicura di sé consegnata da un revisore, da un sub-agente o da uno strumento di analisi statica, completa di file e numero di riga.
Non si applica quando il fallimento è già un solo comando. Un test che fallisce localmente quando lo esegui è una riproduzione; non costruirne una seconda. Non si applica nemmeno a lavoro che non contiene alcun fallimento — una funzionalità nuova, un refactor, una domanda di design. Lì non c'è nulla da riprodurre.
Fai
- Scrivi la cosa più corta che fallisce e che può essere eseguita da sola: uno script, un node id di pytest, un'invocazione della CLI. "Esegui la suite e guarda il terzo errore" non lo è — leggerai oltre l'errore ogni volta.
- Eseguila. Copia l'output reale nei tuoi appunti: il tipo di eccezione, il valore sbagliato accanto a quello atteso, l'exit code. Non il tuo riassunto.
- Ora enuncia la diagnosi, e prova subito ad ucciderla. Metti un
raise RuntimeError("here")in cima alla funzione che la diagnosi accusa e riesegui la riproduzione. Se il fallimento originale compare ancora immutato, quella funzione non è sul percorso che fallisce e la diagnosi è sbagliata a prescindere da quanto fosse ben argomentata. - Correggi, riesegui lo stesso comando, e conserva la riproduzione come test nella stessa modifica. Una riproduzione cancellata dopo la correzione non può dirti quando la correzione viene annullata.
Evita
Modificare il frame del traceback che riconosci. Il frame che riconosci è quello che hai già letto, non quello che è sbagliato, e una modifica plausibile lì spesso sposta il sintomo altrove — cosa che poi si legge come un progresso.
Evita di ereditare una diagnosi come se fosse un fatto. Una spiegazione consegnata da altri è testo, e il processo che produce una spiegazione scorrevole e sbagliata è lo stesso che ne produce una scorrevole e giusta, quindi la scorrevolezza non porta alcuna informazione su quale delle due ti sia capitata. Trattala come un'ipotesi con un nome attaccato: utile per ordinare cosa provare, priva di valore come prova.
# reviewer says the cache key is missing the tenant id
key = f"{tenant.id}:{user.id}"
# yes — first make the failure appear on demand
# repro.py: two tenants, same user id, assert the second read misses
Ed evita il riflesso di rieseguire finché non è verde su un fallimento intermittente. Rieseguire non diagnostica una race condition, la nasconde, e converte un bug riproducibile una volta in un bug che nessuno riesce più a riprodurre.
Verifica
Prima di scrivere la correzione, rispondi sì o no: riesco a far accadere di nuovo questo fallimento, adesso, con un solo comando? Se no, non stai facendo debug, stai speculando con un editor aperto.
Dopo la correzione: lo stesso comando ora passa, e prima lo avevi visto fallire con i tuoi occhi? Una correzione validata solo dal fatto che la suite è diventata verde dimostra che la suite è verde — cosa che poteva esserlo per il motivo sbagliato, se il caso che falliva non è mai stato nella suite.
Rischio
Alcuni fallimenti sono genuinamente costosi da riprodurre: una race che si manifesta una volta al giorno, uno stato che esiste solo in produzione, un crash sei ore dentro un job lungo. Insistere lì su una riproduzione a basso costo brucia più di quanto costi il bug. Dagli un tempo massimo, e se quel tempo scade, di' chiaramente che la correzione non è verificata invece di descriverla come confermata.
La trappola più sottile è la minimizzazione eccessiva. Uno script ridotto all'osso può iniziare a fallire per un motivo diverso dall'originale, e a quel punto correggi il giocattolo. Difenditi applicando la correzione anche al percorso originale che falliva, e confermando che lì il sintomo originale sparisce — il caso minimizzato è uno strumento per trovare la causa, mai la prova che fosse la causa.
Come usarla
La scheda è un dato. Clona il repository e importala per percorso — ciò che arriva dalla rete è trattato come contaminato e trattenuto in attesa di approvazione, che è il comportamento desiderabile e il motivo per cui qui non c'è un installatore in una riga.
git clone https://github.com/brcampidelli/chimera-agent.gitchimera skills-import chimera-agent/skills/chimera-reproduce-before-diagnosing/SKILL.mdIntegrità
SHA-256 del file così com'è pubblicato. Chi lo importa può verificare che ciò che ha ricevuto sia ciò che questa pagina mostrava.
9d70fa5a61992e3b79a2d0ab2afb592c41a7b63274efbdca0afec1724a5b8338