knacky/mimic
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

update SPEC.md

Browse Source
This commit is contained in:
Knacky
2026-05-25 20:09:56 +02:00
parent c4ca8712b7
commit 1194414b57
1 changed files with 39 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

46
SPEC.md
View File

@@ -63,20 +63,52 @@ Pour ce projet, j'ai besoin d'une équipe d'agent réparti de la manière suivan
- Met à jour le README.md quand nécessaire
- Met à jour le fichier SPEC.md quand de nouvelles fonctionnalités ou des précisions sont apportées à certains points
- Réfléchit à l'aspect architecturale de l'application
2. Développeur : **modèle Sonnet**
- Code l'application Frontend et Backend
- Rédige et dispatch les technical briefs
2. Backend builder : **modèle Sonnet**
- Développement backend uniquement
- What it builds: → API routes → Services and business logic → Database access and migrations → Background jobs → Unit tests for everything it writes
- What it cannot do: → Touch React components, pages, or client-side hooks (that's Agent 5) → Invent new dependencies without instruction → Modify files outside agreed scope → Stop without running typecheck, lint, and the test suite
- After finishing, it returns a summary: → Every file added or edited → Every existing helper or pattern reused → Any CLAUDE.md rule that would have helped
- Tools: Read, Edit, Write, Bash — scoped to backend folders only.
- Livre un code simple à comprendre sans essayer de prévoir l'avenir (se limiter au scope)
- Ne prend pas de décision ou d'hypothèse. Si des questions subsitent, il les remonte au team lead qui décidera de la position à prendre en fonction des contraintes énnoncés par le développeur.
- Livre un code propre, avec les tests appropriés
3. Spec reviewer : **modèle Sonnet**
- Livre un code propre, avec les tests appropriés (success, failure, edge cases)
3. Front builder : **modèle Sonnet**
- Développement frontend uniquement
- It reads the Backend Builder's summary first.
- It consumes the API exactly as the backend produced it.
- It does not invent new endpoints.
- If the API shape is wrong for the UI, it surfaces the mismatch as feedback — not as a patch.
- Input it receives: → Approved technical brief → Researcher's findings → Backend Builder's summary (the API contract)
- What it builds: → React components and pages → Client-side hooks and state → Loading and error states → Component and unit tests for everything it writes
- What it cannot do: → Touch services, API routes, workers, or migrations (that's Agent 4) → Invent endpoints or response shapes → Add dependencies without instruction → Stop without running typecheck, lint, and the test suite
- Tools: Read, Edit, Write, Bash — scoped to frontend folders only
- Livre un code simple à comprendre sans essayer de prévoir l'avenir (se limiter au scope)
- Ne prend pas de décision ou d'hypothèse. Si des questions subsitent, il les remonte au team lead qui décidera de la position à prendre en fonction des contraintes énnoncés par le développeur.
- Livre un code propre, avec les tests appropriés (success, failure, edge cases)
4. Spec reviewer : **modèle Sonnet**
- Avant chaque début de sprint, lit les plans du team leader et valide les tâches à donner au développeur
- Si le plan s'éloigne des spec énoncés, le dire au team leader afin qu'il mette à jour son plan pour répondre aux besoins énoncés
4. Code reviewer : **modèle Opus**
5. Code reviewer : **modèle Opus**
- A la fin de chaque sprint, avant de réaliser la PR, cet agent relit le code généré par le développeur sur le sprint courant (pas tout le code, juste celui du scope).
- Utilise un maximum les LSP quand c'est possible
- Vérifie si des optimisations ou des factorisations de code sont possibles suite aux nouvelles implémentations du développeur.
- Dans le cas ou des erreurs ou des optimisations ou des factorisations sont possible, les remontés directement au développeur afin qu'il traite les erreurs et en informer le team lead.
- Quand le code review est OK, le remonter au team lead afin qu'il génère la PR.
5. Devil advocate : **modèle Opus**
- Quand le code review est OK, en informer le test verifier pour qu'il réalise ses tests à son tour.
6. Test verifier : **modèle Sonnet**
- The Test Verifier does one thing only: prove that the feature actually does what the user story said it should.
- It writes acceptance tests. Not unit tests.
- These test the feature from the outside — the way a real user would experience it.
- Input it receives: → Approved user story (with all acceptance criteria) → Approved technical brief → Both builders' summaries
- What it produces: → One acceptance test file covering every acceptance criterion → A report: which criteria passed, which failed, which can't be covered cleanly
- What it cannot do: → Modify any backend or frontend code → Invent workarounds for untestable criteria → Mark a criterion as covered if it genuinely isn't
- If a test fails: the feature doesn't satisfy the story.
- It reports exactly which criterion failed.
- It does not patch the code.
- That goes back to the right builder.
- Tools: Read, Edit, Write (test files only), Bash.
- The rule: you don't have a feature until the acceptance tests pass.
- Quand tout est ok pour le test verifier en informer le team lead afin qu'il prépare la PR.
6. Devil advocate : **modèle Opus**
- Dans le cas de questions structurantes sur le projet, faire intervenir cet agent en tant que tierce personne n'ayant pas connaissance de tout le projet mais permettant d'avoir un regarde neuf sur ces questions.