chimera-thin-vertical-slice
Costruisci un solo percorso stretto che attraversa ogni livello e viene eseguito, prima di costruire per intero qualsiasi livello — un'integrazione che non è mai stata eseguita è una supposizione.
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 iniziando una nuova feature
- serve una CLI, un servizio e uno storage
- costruisco prima l'astrazione
- non gira ancora niente
- creo lo scheletro di un sottosistema
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 iniziando un lavoro che attraversa più livelli — un comando che arriva a un orchestratore che chiama un provider che scrive su uno store — e stai decidendo cosa costruire per primo. La tentazione è costruire completamente il livello più basso, poi il successivo, e cablare il tutto alla fine.
Non si applica a un lavoro che è genuinamente profondo un solo livello: un parser, un formattatore, una funzione pura. Lì non c'è alcuna verticale, e inventarne una è cerimonia. Non si applica nemmeno a una modifica dentro un sistema che già gira da un capo all'altro; quel percorso esiste, e la fetta è già stata pagata.
Fai
- Nomina l'osservabile che la fetta produrrà, come un comando che qualcun altro potrebbe digitare e
un singolo output concreto. Non "la pipeline funziona" —
chimera run "hi"stampa una riga tornata da un provider reale. - Scrivi per prima quell'invocazione, come script o come test, e guardala fallire per il motivo giusto.
- Implementa il percorso più breve attraverso ogni livello, degenere in ciascuno: un solo provider, nessun retry, nessun file di configurazione, nessuna cache, nessuna concorrenza. Dove un giorno vivrà una policy, metti una costante.
- Tieni reale il livello che porta l'incognita vera. Se non sai ancora cosa restituisce il provider, il provider è l'unica cosa della prima fetta che non deve essere uno stub.
- Fai commit nel momento in cui gira, prima di generalizzare. Quel commit è la prova che i livelli combaciano.
- Allarga un asse alla volta — secondo provider, poi la configurazione, poi la cache — e mantieni funzionante il comando del passo 1 dopo ognuno. Se si rompe, l'indiziato è quell'allargamento.
Evita
Progettare un'interfaccia in assenza di chiamanti. L'ordine orizzontale produce una classe base, sei adapter, un registry e una policy di retry il primo giorno, e scopre al momento del cablaggio che la forma è sbagliata — perché nulla le aveva ancora posto una domanda reale.
class BaseProvider(ABC): ...
class ProviderRegistry: ...
class RetryPolicy: ...
# Day 1, vertical: ugly, hardcoded, and it answers the question.
def complete(prompt: str) -> str:
return _post(URL, {"model": MODEL, "prompt": prompt})["choices"][0]["text"]
Evita anche la fetta che è sottile nella dimensione sbagliata: mockare la chiamata esterna e percorrere tutto il resto da un capo all'altro. Questo dimostra che i tuoi livelli sono d'accordo tra loro, che non era mai la parte dubbia. L'integrazione che non hai esercitato è l'integrazione che sarà sbagliata.
Verifica
Poni una domanda binaria: qualcuno che non l'ha scritto, su un checkout pulito, riesce a eseguire un comando e a vedere la funzionalità fare il suo lavoro fino in fondo? Se la risposta richiede un "beh, una volta che stubbi anche X" o un "dopo che incolli un token in quella costante" — annota onestamente il secondo come setup, e considera qualsiasi riserva sul codice come prova che non è ancora una fetta.
Poi controlla git log: esiste un commit in cui il comando funzionava e le astrazioni non esistevano
ancora? Se il primo commit funzionante è anche quello che ha introdotto il registry, la fetta è stata
saltata.
Rischio
Una fetta scrive scelte a codice fisso, e i valori fissati sopravvivono. Il fallimento tipico è che i passi 5 e 6 non avvengono mai perché la prima fetta "funziona", lasciando un sistema il cui unico provider è saldato dentro e le cui giunzioni sono finite in qualunque posto fosse comodo alla seconda ora. Pianifica l'allargamento come lavoro dello stesso lotto, non come un seguito che nessuno finanzia.
L'altro costo è reale: far passare la prima fetta attraverso una dipendenza esterna viva rende quel primo test lento, a pagamento e ogni tanto instabile. Registralo e riproducilo dopo che esiste — registrare una chiamata che non hai mai fatto non è possibile, ed è tutto il motivo per cui l'ordine conta.
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-thin-vertical-slice/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.
cc2b4e8524f6a9a839d70effa69a32287a69eb70dba16321bffb74ae39c302e6