fix(dry-run): ne pas modifier les états persistants sans contrat explicite #19

New Issue

AntoineVe · 2026-09-09T00:09:38+02:00

AntoineVe commented

2026-09-09 00:09:38 +02:00

Constat

Le projet annonce un dry-run « sans écriture » : README, TODO et guide d'exploitation emploient cette formulation. Or le pipeline crée ses états de source normalement avant d'arriver aux sorties CalDAV/XMPP.

Deux écritures persistantes restent donc possibles pendant une simulation :

BlogRSSState enregistre les GUID et validateurs HTTP lors de fetch_blog_step() ;
le mode Pronote qr_token enregistre les credentials exportés après une connexion réussie.

Le premier cas peut faire disparaître des articles d'une exécution réelle suivante ; le second modifie l'état d'authentification alors que l'opérateur pense exécuter une simple simulation. La règle actuelle d'AGENTS (« aucune écriture CalDAV/XMPP ») est plus étroite que la promesse générale de la CLI, ce qui laisse le comportement ambigu.

Proposition

Choisir puis documenter l'un des contrats suivants :

simulation strictement sans persistance : injecter des états en mémoire ou bloquer les écritures locales ;
validation avec effets de source : conserver ces écritures, mais renommer/avertir explicitement le mode et fournir une option réellement sans effet durable.

Pour le flux QR/token, préciser la stratégie lorsque l'authentification elle-même implique une rotation côté fournisseur : il peut être préférable de déclarer ce mode incompatible avec une simulation stricte plutôt que de créer un état local incohérent.

Critères d'acceptation

La sémantique de --dry-run est unique dans la CLI, TODO, guide d'exploitation et tests.
Un dry-run strict ne modifie ni .blog_rss_state.json, ni .pronote_auth_state.json.
Si une variante avec effets de source est conservée, elle est explicitement nommée, affichée et testée.
Les articles de blog et l'état QR/token restent utilisables par l'exécution réelle suivant une simulation.
Les tests couvrent les deux fichiers d'état et n'utilisent pas de connexion réseau réelle.

Périmètre

Contrat dry-run, orchestration des états de sources et documentation ; le comportement CalDAV/XMPP existant reste à préserver.

## Constat Le projet annonce un dry-run « sans écriture » : README, TODO et guide d'exploitation emploient cette formulation. Or le pipeline crée ses états de source normalement avant d'arriver aux sorties CalDAV/XMPP. Deux écritures persistantes restent donc possibles pendant une simulation : - `BlogRSSState` enregistre les GUID et validateurs HTTP lors de `fetch_blog_step()` ; - le mode Pronote `qr_token` enregistre les credentials exportés après une connexion réussie. Le premier cas peut faire disparaître des articles d'une exécution réelle suivante ; le second modifie l'état d'authentification alors que l'opérateur pense exécuter une simple simulation. La règle actuelle d'AGENTS (« aucune écriture CalDAV/XMPP ») est plus étroite que la promesse générale de la CLI, ce qui laisse le comportement ambigu. ## Proposition Choisir puis documenter l'un des contrats suivants : 1. **simulation strictement sans persistance** : injecter des états en mémoire ou bloquer les écritures locales ; 2. **validation avec effets de source** : conserver ces écritures, mais renommer/avertir explicitement le mode et fournir une option réellement sans effet durable. Pour le flux QR/token, préciser la stratégie lorsque l'authentification elle-même implique une rotation côté fournisseur : il peut être préférable de déclarer ce mode incompatible avec une simulation stricte plutôt que de créer un état local incohérent. ## Critères d'acceptation - La sémantique de `--dry-run` est unique dans la CLI, TODO, guide d'exploitation et tests. - Un dry-run strict ne modifie ni `.blog_rss_state.json`, ni `.pronote_auth_state.json`. - Si une variante avec effets de source est conservée, elle est explicitement nommée, affichée et testée. - Les articles de blog et l'état QR/token restent utilisables par l'exécution réelle suivant une simulation. - Les tests couvrent les deux fichiers d'état et n'utilisent pas de connexion réseau réelle. ## Périmètre Contrat dry-run, orchestration des états de sources et documentation ; le comportement CalDAV/XMPP existant reste à préserver.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: AntoineVe/college-infos#19