kwa/ workflows
Limites et suite

Ce qui reste à faire

Les gardes ne sont pas une frontière de sécurité

Un agent peut en théorie éditer ses propres hooks ; guard-write demande confirmation avant de toucher à .claude/kwa/ et settings.json, rien de plus. Les règles permissions.deny, seules, filtrent un outil : Read(./.env) n'arrête pas python3 -c. Pour une vraie barrière : le bac à sable de Claude Code (/sandbox), qui applique aussi ces règles aux commandes shell ; un conteneur ou une machine isolée ; des identifiants séparés ; la protection de branche GitHub avec CI obligatoire. Le détail : Ce qui est imposé, ce qui est suggéré.

Les gardes analysent du texte

Un script écrit dans un fichier puis exécuté, ou une commande assemblée à l'exécution, échappent à l'analyse. Les cibles calculées ($(…), variables) déclenchent une demande plutôt qu'un passage.

Feuille de route

1. Essai sur un projet pilote, toujours en simulation d'abord. 2. kwa sync : installer sur tous les projets listés dans un fichier de configuration. 3. Évals de skills avec claude plugin eval, à vérifier sur la version en place. 4. Fusion guidée d'un CLAUDE.md existant dans AGENTS.md, avec contrôle de couverture. 5. Profil « projet client » : compte machine, politique de fusion humaine.

Ce que Kwa ne décide pas pour vous

Le contenu de la politique d'un projet (commandes interdites, environnements, pré-vols) vient de vos incidents. Kwa pré-remplit ce qu'il peut déduire et vous laisse le reste. Le module client-handover n'est jamais déduit : il dépend de l'intention.