TASK-008 — Rendre au garde git un niveau « demande » #14

New issue

Closed

opened 2026-10-11 10:06:43 +02:00 by mathieu · 0 comments

mathieu commented

2026-10-11 10:06:43 +02:00

Owner

Le garde amont (guard-destructive.sh, mattpocock, adopté verbatim le
2026-09-20) ne connaît qu'un verdict : refus sec, sortie 2. Le niveau
« demande » — invite de permission plutôt que blocage — a été perdu avec la
garde précédente. Sa perte est écrite en tête du script ; sa conséquence ne
l'était pas.

Constatée le 2026-09-21. Mathieu a autorisé explicitement la poussée de trois
dépôts, et la session n'a eu aucun moyen de l'exécuter : toute autorisation
explicite est désormais inapplicable, et la seule issue reste que l'humain tape
la commande lui-même. Le garde ne protège plus d'une erreur, il déplace le
travail.

Le même jour, le garde a bloqué la création de cette tâche-ci, parce que sa
description cite la commande interdite. C'est le faux positif que le découpage
par segment et le retrait des heredocs évitaient dans l'ancienne garde — eux
aussi perdus le 2026-09-20, eux aussi listés en tête du script. La liste des
pertes est donc exacte ; ce qui manquait, c'est de mesurer ce qu'elle coûte à
l'usage.

Le refus sec garde sa place pour l'irrattrapable : poussée forcée,
reset --hard, clean -f. La poussée simple, elle, appelle une invite :
réversible, quotidienne, et déjà encadrée par la règle du double push.

Deux contraintes. Ne pas réintroduire une confirmation qui se donne en
conversation — règle déjà posée ailleurs, dans la base de connaissance
personnelle : le consentement passe par l'environnement ou la ligne de
commande, jamais par une phrase. Et ne pas
repartir en fork silencieux de l'amont : tout écart s'écrit en tête du script,
comme le précédent.

Voir git log --follow sur plugins/atelier/hooks/guard-destructive.sh, et
TASK-002, fermée caduque le 2026-09-20.

Critères d'acceptation

Le garde distingue au moins deux verdicts : refus sec et invite de permission
La poussée simple passe en invite ; poussée forcée, reset --hard et clean -f restent en refus sec
Une commande qui ne fait que citer un motif interdit (heredoc, description, commentaire) n'est plus bloquée
L'autorisation ne peut pas être donnée par une phrase dans la conversation
L'écart avec l'amont est écrit en tête du script
Une suite de tests couvre les deux verdicts et échoue si le garde est neutralisé

Migré de Backlog.md (TASK-008, créé le 2026-09-21 20:38, étiquettes : garde-fou).

Importé d'OpenProject (#1111, essai Kaneo, ADR-0008).

Migré de Kaneo le 2026-10-11 : ATE-11 du projet « Atelier », créée le 2026-10-04.

Le garde amont (`guard-destructive.sh`, mattpocock, adopté verbatim le 2026-09-20) ne connaît qu'un verdict : refus sec, sortie 2. Le niveau « demande » — invite de permission plutôt que blocage — a été perdu avec la garde précédente. Sa perte est écrite en tête du script ; sa conséquence ne l'était pas. Constatée le 2026-09-21. Mathieu a autorisé explicitement la poussée de trois dépôts, et la session n'a eu aucun moyen de l'exécuter : toute autorisation explicite est désormais inapplicable, et la seule issue reste que l'humain tape la commande lui-même. Le garde ne protège plus d'une erreur, il déplace le travail. Le même jour, le garde a bloqué la création de cette tâche-ci, parce que sa description cite la commande interdite. C'est le faux positif que le découpage par segment et le retrait des heredocs évitaient dans l'ancienne garde — eux aussi perdus le 2026-09-20, eux aussi listés en tête du script. La liste des pertes est donc exacte ; ce qui manquait, c'est de mesurer ce qu'elle coûte à l'usage. Le refus sec garde sa place pour l'irrattrapable : poussée forcée, `reset --hard`, `clean -f`. La poussée simple, elle, appelle une invite : réversible, quotidienne, et déjà encadrée par la règle du double push. Deux contraintes. Ne pas réintroduire une confirmation qui se donne en conversation — règle déjà posée ailleurs, dans la base de connaissance personnelle : le consentement passe par l'environnement ou la ligne de commande, jamais par une phrase. Et ne pas repartir en fork silencieux de l'amont : tout écart s'écrit en tête du script, comme le précédent. Voir `git log --follow` sur `plugins/atelier/hooks/guard-destructive.sh`, et TASK-002, fermée caduque le 2026-09-20. ## Critères d'acceptation - [x] Le garde distingue au moins deux verdicts : refus sec et invite de permission - [x] La poussée simple passe en invite ; poussée forcée, `reset --hard` et `clean -f` restent en refus sec - [x] Une commande qui ne fait que citer un motif interdit (heredoc, description, commentaire) n'est plus bloquée - [x] L'autorisation ne peut pas être donnée par une phrase dans la conversation - [x] L'écart avec l'amont est écrit en tête du script - [x] Une suite de tests couvre les deux verdicts et échoue si le garde est neutralisé *Migré de Backlog.md (TASK-008, créé le 2026-09-21 20:38, étiquettes : garde-fou).* *Importé d'OpenProject (#1111, essai Kaneo, ADR-0008).* --- *Migré de Kaneo le 2026-10-11 : ATE-11 du projet « Atelier », créée le 2026-10-04.*

mathieu added this to the (deleted) milestone

2026-10-11 10:06:43 +02:00

mathieu

2026-10-11 10:06:43 +02:00

closed this issue
added the
Garde-fous
label

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

mathieu/essai-actions#14

No description provided.

Rows
Columns