build-the-gate-before-the-content
Un controllo aggiunto dopo ciò che protegge è un controllo che qualcuno spegne per consegnare. Chiudilo finché non c'è nulla da bloccare.
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
- sto pianificando una migrazione
- sto creando una nuova superficie
- il lint lo aggiungiamo dopo
- sto decidendo l'ordine del lavoro
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 costruire qualcosa su cui dovrà essere applicata una regola — un vincolo di stile, un controllo di freschezza, uno schema, un validatore di link, un budget. L'ordine naturale è costruire la cosa e aggiungere il controllo una volta che c'è qualcosa da controllare.
Non si applica a un controllo che stai aggiungendo a codice già esistente; quello è un lavoro diverso e più difficile, e lì la risposta è un ratchet, non un muro.
Fai
- Aggiungi il controllo nel primo commit, prima che esista contenuto su cui possa fallire. Passa banalmente, ed è proprio questo il punto: nasce verde.
- Dagli un messaggio di fallimento che dica cosa eseguire. Un gate il cui output è
assert Falseviene cancellato dalla prossima persona che ci sbatte contro alle due di notte. - Scrivi il controllo in modo che fallisca alla prima violazione, non alla centesima. I ratchet servono per il codice legacy; un progetto nuovo parte da zero.
- Quando il controllo scatta, correggi il contenuto. Ogni volta che modifichi il controllo invece, annota nel messaggio di commit quale caso lo ha reso necessario.
Evita
"Lo attiveremo una volta scritte le pagine." A quel punto il controllo ha un arretrato, attivarlo
significa una giornata di correzioni non correlate, e la via più economica è una lista skip che
non si riduce mai.
Evita anche di allentare un gate nello stesso commit della funzionalità che lo ha fatto scattare. L'allentamento è invisibile in un diff ampio, ed è esattamente il momento in cui un gate smette di esserlo — quindi merita un commit a sé, con una spiegazione a sé.
Verifica
Introduci una violazione di proposito e conferma che la build diventa rossa — poi rimuovila. Fallo il giorno stesso in cui scrivi il gate, non dopo.
Un gate che nessuno ha mai visto fallire non è un gate; è un file che dichiara di esserlo.
Rischio
Un gate scritto prima del contenuto codifica un'assunzione su un contenuto che ancora non esiste, e alcune di quelle assunzioni si rivelano sbagliate. Aspettati di doverlo restringere una o due volte all'inizio.
Quel restringimento è il momento pericoloso. Ognuno indebolisce la regola, e una regola ristretta tre volte senza che nessuno se ne accorga è una regola che non copre più il caso per cui era stata scritta. Fissa ogni restringimento con l'esempio fallito che lo ha causato.
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/build-the-gate-before-the-content/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.
58c3de3bf7323fb3be38d084394e45ff97e408c20c45db31749cde2b8a13fc81