feat: Améliorations de data_inclusion & de la génération de code#50
feat: Améliorations de data_inclusion & de la génération de code#50
Conversation
|
|
||
| # Inject condensed tool results from the previous turn so the agent | ||
| # doesn't re-query data it already obtained. | ||
| if not is_first_message: |
There was a problem hiding this comment.
j'ai du mal à comprendre la logique – en quelles circonstances les précédents tool calls ne font pas partie du contexte ?
There was a problem hiding this comment.
très bon point. J'ai tenté une modification un poil cavalière la semaine dernière en séminaire pour débloquer le mode multiprocess - j'ai dû revoir la façon dont on gère le contexte. Super preneur d'une conversation à ce sujet parce que ça me semble touchy et on a eu améliorations comme régressions à la fois :/
There was a problem hiding this comment.
Yep – d'autant plus qu'un des bénéfices de passer par Claude, c'est qu'ils conservent le contexte en cache chez eux (je sais pas combien de temps).
| "PreToolUse": [ | ||
| { | ||
| "matcher": "Edit|Write", | ||
| "command": "python3 .claude/hooks/check_python.py" |
There was a problem hiding this comment.
C'est censé tourner et pour la génération en locale, et pour la génération de petits scripts en prod, j'imagine ?
There was a problem hiding this comment.
L'idée est de permettre que les guidelines de code soient au maximum appliquées dans les PR au moins - pour les scripts en prod ça ne sera pas non plus un luxe. Mais on a un sujet les concernant à terme d'ailleurs.
Comment les apps interactives passent-elles à une version managée et suivie/relue (et donc pérennisée ? qui est mise à jour quand le code d'autometa est mis à jour ? quand on va passer au datalake anonymisé, quid des anciennes apps ? où tournent-elles ce jour là ?)
Comment faire pour que les conversations qui apportent de la connaissance soient en un sens pérennisées ? Font-elles aujourd'hui déjà partie de la base de connaissances de l'agent en prod ? cc pour cet aprem @PierreDeNantes
There was a problem hiding this comment.
(J'imagine qu'on peut garantir certains de ces trucs via ruff, et en cherchant, je découvre l'existence de semgrep qui pourra peut-être aider à généraliser des choses.)
There was a problem hiding this comment.
ruff fait de la validation syntaxique mais n'a pas aujourd'hui d'enforce de guidelines à ce niveau.
Je ne suis pas SUPER fan de ce mécanisme actuellement mais il attrappe quand meme pas mal de choses, en tout cas bien plus que ce qu'on a avant - l'agent ne lance pas de selfcheck systématiquement, il peut ignorer ses propres regles et le fait assez regulièrement... ca pose probleme pour le vibecoding du coup.
7f8e999 to
ca5fe33
Compare
We don't want naive datetimes anywhere. Local region is applied before display. This fixes naive and non-naive comparisons in our templates.
We never should handle those cases : the database refuses to have NULL values in those NULL dates, and mostly everywhere we should not handle this. If it happens we should crash, it's unexpected. Some apps still have no dates though (funnel-search-services & penetration-snapshot), let's handle that and see how we port those later eventually.
06ec0ca to
8154f02
Compare
Pourquoi ?
La génération de code est pas ouf (cf PR de Annaelle) et ne suit pas ses propres guidelines.
Par ailleurs, le skill data_inclusion est complexe et parfois se perd dans le lancement de cinquantaines de commandes.
Check-list : la forme
<type>(<scope optionnel>): <description>feat,fix,chore,docs,refactor,test, etc.web,lib,skills,knowledge,config,scripts,tests,ci<auteur>/<type>/<feature>Check-list : le fond
Comment tester que ça marche ?
Bah faudra essayer en prod tant qu'on a pas de staging :x