chimera-thin-vertical-slice
Construisez un seul chemin étroit qui traverse toutes les couches et qui s'exécute, avant de construire une seule couche en entier — une intégration qui ne s'est jamais exécutée est une supposition.
Conférée par la personne qui a relu la fiche, et non revendiquée par le fichier lui-même. Une fiche que l'agent distille au cours d'une exécution ayant consommé du contenu non fiable naît contaminée et reste en attente de relecture avant d'être un jour récupérée.
Quand elle vient à l'esprit
- démarrer une nouvelle fonctionnalité
- il faut un CLI, un service et du stockage
- commencer par l'abstraction
- rien ne tourne encore
- poser le squelette d'un sous-système
C'est dans À éviter et Vérifier que se trouve d'ordinaire la valeur. À faire est la section que tout le monde écrit.
Le corps de la fiche ci-dessus est une traduction. L'original anglais est ce que la CLI importe, ce que l'agent lit à l'exécution et ce que l'empreinte ci-dessous atteste.
Déclencheur
Vous démarrez un travail qui traverse des couches — une commande qui atteint un orchestrateur qui appelle un fournisseur qui écrit dans un stockage — et vous décidez quoi construire en premier. La tentation est de construire entièrement la couche du bas, puis la suivante, puis de tout câbler à la fin.
Cela ne s'applique pas à un travail qui tient vraiment sur une seule couche : un parseur, un formateur, une fonction pure. Il n'y a pas de vertical là-dedans, et en inventer un est du cérémonial. Cela ne s'applique pas non plus à un changement à l'intérieur d'un système qui tourne déjà de bout en bout ; ce chemin existe, et la tranche a déjà été payée.
À faire
- Nommez l'observable que la tranche produira, sous forme d'une commande que quelqu'un d'autre pourrait taper et d'une seule
sortie concrète. Pas « le pipeline fonctionne » —
chimera run "hi"affiche une ligne revenue d'un vrai fournisseur. - Écrivez cette invocation en premier, comme script ou comme test, et regardez-la échouer pour la bonne raison.
- Implémentez le chemin le plus court à travers toutes les couches, dégénéré à chacune : un seul fournisseur, pas de réessai, pas de fichier de configuration, pas de cache, pas de concurrence. Là où vivra un jour une politique, mettez une constante.
- Gardez réelle la couche qui porte la véritable inconnue. Si vous ne savez pas encore ce que renvoie le fournisseur, le fournisseur est la seule chose de la tranche 1 qui ne doit pas être un bouchon.
- Committez au moment où ça tourne, avant de généraliser. Ce commit est la preuve que les couches s'emboîtent.
- Élargissez un axe à la fois — deuxième fournisseur, puis configuration, puis cache — et gardez la commande de l'étape 1 fonctionnelle après chacun. Si elle casse, c'est cet élargissement le suspect.
À éviter
Concevoir une interface sans aucun appelant. L'ordre horizontal produit une classe de base, six adaptateurs, un registre et une politique de réessai dès le premier jour, et découvre au moment du câblage que la forme est fausse — parce que rien ne lui avait encore posé une vraie question.
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"]
Évitez aussi la tranche qui est fine dans la mauvaise dimension : simuler l'appel externe et faire tourner le reste de bout en bout. Cela prouve que vos propres couches sont d'accord entre elles, ce qui n'a jamais été la partie douteuse. L'intégration que vous n'avez pas exercée est celle qui sera fausse.
Vérifier
Posez une question binaire : quelqu'un qui n'a pas écrit le code, sur un dépôt fraîchement cloné, peut-il lancer une commande et voir la fonctionnalité faire son travail de bout en bout ? Si la réponse exige « bon, à condition de bouchonner aussi X » ou « après avoir collé un token dans cette constante » — notez honnêtement le second cas comme une étape de mise en place, et considérez toute réserve portant sur le code comme la preuve que ce n'est pas encore une tranche.
Vérifiez ensuite git log : existe-t-il un commit où la commande fonctionnait et où les abstractions n'existaient pas
encore ? Si le premier commit fonctionnel est aussi celui qui a introduit le registre, la tranche a été sautée.
Risque
Une tranche fige des choix en dur, et le dur survit. L'échec habituel est que les étapes 5 et 6 n'arrivent jamais parce que la première tranche « marche », ce qui laisse un système dont l'unique fournisseur est soudé et dont les jointures ont fini là où c'était pratique à la deuxième heure. Planifiez l'élargissement comme du travail du même lot, pas comme une suite que personne ne financera.
L'autre coût est réel : faire passer la tranche 1 par une dépendance externe vivante rend ce premier test lent, payant et parfois instable. Enregistrez puis rejouez l'appel après qu'il existe — enregistrer un appel que vous n'avez jamais fait est impossible, et c'est toute la raison pour laquelle l'ordre compte.
L'utiliser
La fiche est une donnée. Clonez le dépôt et importez-la par son chemin — ce qui arrive par le réseau est traité comme contaminé et retenu pour approbation, ce qui est le comportement souhaitable et la raison pour laquelle il n'y a pas d'installateur en une ligne ici.
git clone https://github.com/brcampidelli/chimera-agent.gitchimera skills-import chimera-agent/skills/chimera-thin-vertical-slice/SKILL.mdIntégrité
SHA-256 du fichier tel qu'il est publié. Qui l'importe peut vérifier que ce qu'il a reçu correspond à ce que cette page affichait.
cc2b4e8524f6a9a839d70effa69a32287a69eb70dba16321bffb74ae39c302e6