2027a/auroscope

Watch

Fork 0

[Decision D1] Définir la version minimale compatible de Paru #2

New issue

Closed

opened 2026-08-30 20:42:55 +00:00 by hephaistos · 6 comments

hephaistos commented

2026-08-30 20:42:55 +00:00

Owner

MODE: DECISION

Statut

Proposé — décision de Mathieu requise. Ce ticket doit rester ouvert après ta réponse. Il ne sera fermé et la décision ne sera considérée acquise qu’après ton go explicite.

Question

Quelle version de Paru AURoscope doit-il accepter pour préserver la sélection interactive native sans parser l’interface humaine ?

Pourquoi c’est structurant

AURoscope doit laisser Paru afficher son menu numéroté, tout en récupérant uniquement les noms choisis. Cette séparation devient un contrat de compatibilité de production.

Preuves vérifiées

Paru stable v2.1.0 (70f66dc9) met le menu et le nom sélectionné sur stdout; stderr reste vide; la sélection réussie sort avec le code 1.
Le correctif d1dfbc4 rétablit la séparation attendue.
Au commit postérieur 9ac3578, le menu va sur stderr, le nom seul sur stdout, toujours avec le code 1.
Aucune version stable inspectée ne contient encore ce correctif.
Le numéro de version seul ne distingue pas forcément un build patché.

Options

A — Exiger la première version stable contenant `d1dfbc4`

Pour : contrat clair, pas de parsing fragile, dépendance stable.
Contre : bloque la sélection par recherche en production jusque-là.

B — Supporter un commit `paru-git` épinglé

Pour : développement immédiat.
Contre : dépendance non publiée, dérive possible, support plus coûteux.

Pour : compatibilité immédiate.
Contre : fragile, localisé, confond données et UI, contraire au design.

Recommandation

Option A, avec 9ac3578 uniquement pour les tests de design en attendant. Ajouter des tests de capacité exécutables; ne pas se fier au seul --version.

Risque résiduel

Une future version peut encore modifier les flux ou codes de sortie : matrice de contrats obligatoire par version supportée.

Réponse attendue

Indique A, B, C ou une variante motivée. Je reformulerai la décision dans le ticket. Je n’écris pas l’ADR et je ne ferme pas avant ton go.

Documentation

Proposition complète : https://git.2027a.net/2027a/auroscope/src/branch/design/technical-contracts/docs/architecture/design-proposals.md
Note Paru : https://git.2027a.net/2027a/auroscope/src/branch/design/technical-contracts/docs/dependency-notes/paru-contract.md
PR de design : #1

Protocole automatique de décision

Ce ticket reste en discussion et n’autorise aucune implémentation.
Les commentaires ordinaires poursuivent la discussion avec Hephaistos dans le ticket.
Quand la dernière proposition concrète te convient, publie un commentaire dont le contenu est exactement :

GO DECISION

Ce signal transfère automatiquement le ticket à Hephaistos pour consigner l’ADR, mettre à jour les documents de design, vérifier les changements et fermer le ticket.
GO DECISION n’autorise ni code de production ni plan d’implémentation; ce travail doit avoir son propre ticket MODE: EXECUTION.

MODE: DECISION ## Statut **Proposé — décision de Mathieu requise.** Ce ticket doit rester ouvert après ta réponse. Il ne sera fermé et la décision ne sera considérée acquise qu’après ton **go explicite**. ## Question Quelle version de Paru AURoscope doit-il accepter pour préserver la sélection interactive native sans parser l’interface humaine ? ## Pourquoi c’est structurant AURoscope doit laisser Paru afficher son menu numéroté, tout en récupérant uniquement les noms choisis. Cette séparation devient un contrat de compatibilité de production. ## Preuves vérifiées - Paru stable `v2.1.0` (`70f66dc9`) met le menu **et** le nom sélectionné sur stdout; stderr reste vide; la sélection réussie sort avec le code `1`. - Le correctif `d1dfbc4` rétablit la séparation attendue. - Au commit postérieur `9ac3578`, le menu va sur stderr, le nom seul sur stdout, toujours avec le code `1`. - Aucune version stable inspectée ne contient encore ce correctif. - Le numéro de version seul ne distingue pas forcément un build patché. ## Options ### A — Exiger la première version stable contenant `d1dfbc4` **Pour :** contrat clair, pas de parsing fragile, dépendance stable. **Contre :** bloque la sélection par recherche en production jusque-là. ### B — Supporter un commit `paru-git` épinglé **Pour :** développement immédiat. **Contre :** dépendance non publiée, dérive possible, support plus coûteux. ### C — Parser le menu de Paru 2.1 **Pour :** compatibilité immédiate. **Contre :** fragile, localisé, confond données et UI, contraire au design. ## Recommandation **Option A**, avec `9ac3578` uniquement pour les tests de design en attendant. Ajouter des tests de capacité exécutables; ne pas se fier au seul `--version`. ## Risque résiduel Une future version peut encore modifier les flux ou codes de sortie : matrice de contrats obligatoire par version supportée. ## Réponse attendue Indique `A`, `B`, `C` ou une variante motivée. Je reformulerai la décision dans le ticket. **Je n’écris pas l’ADR et je ne ferme pas avant ton go.** ## Documentation - Proposition complète : https://git.2027a.net/2027a/auroscope/src/branch/design/technical-contracts/docs/architecture/design-proposals.md - Note Paru : https://git.2027a.net/2027a/auroscope/src/branch/design/technical-contracts/docs/dependency-notes/paru-contract.md - PR de design : https://git.2027a.net/2027a/auroscope/pulls/1 ## Protocole automatique de décision - Ce ticket reste en discussion et n’autorise aucune implémentation. - Les commentaires ordinaires poursuivent la discussion avec Hephaistos dans le ticket. - Quand la dernière proposition concrète te convient, publie un commentaire dont le contenu est exactement : ```text GO DECISION ``` - Ce signal transfère automatiquement le ticket à Hephaistos pour consigner l’ADR, mettre à jour les documents de design, vérifier les changements et fermer le ticket. - `GO DECISION` n’autorise ni code de production ni plan d’implémentation; ce travail doit avoir son propre ticket `MODE: EXECUTION`.

hephaistos added the

labels

2026-08-30 20:45:45 +00:00

mathieu commented

2026-08-30 20:48:09 +00:00

Owner

A semble le plus pertinent. Mais fait une recherche web pour t'assurer du contexte autour de ce commit, et de la probabilité raisonnable qu'il soit dans la version stable relativement bientôt. Sinon, probablement Ce en attendant que A soit effectif

hephaistos commented

2026-08-30 23:19:33 +00:00

Author

Owner

Ticket classé comme décision humaine. La discussion continue ici, mais aucune implémentation ni ADR accepté ne sera produit tant que Mathieu n’aura pas publié exactement GO DECISION dans un commentaire distinct.

Ticket classé comme décision humaine. La discussion continue ici, mais aucune implémentation ni ADR accepté ne sera produit tant que Mathieu n’aura pas publié exactement `GO DECISION` dans un commentaire distinct.

hephaistos commented

2026-08-30 23:23:15 +00:00

Author

Owner

J’ai vérifié l’amont. Le contexte renforce A sur le fond, mais pas l’hypothèse d’une publication proche :

d1dfbc4 corrige une régression de redirection stdin/stdout introduite par af078e8b; il ne s’agit pas d’un changement expérimental propre à AURoscope.
Le correctif a fermé l’issue Paru #1413 et a été fusionné dans master le 5 octobre 2025 via la PR #1417, le jour même de son ouverture. Il est toujours dans l’ascendance du master actuel. La probabilité que la prochaine stable le contienne est donc élevée, sauf revert.
En revanche, le calendrier ne permet pas de dire « relativement bientôt » : la dernière stable reste v2.1.0, publiée le 8 juillet 2025; aucun tag stable plus récent n’existe; le dernier commit de master date du 9 janvier 2026. Il n’y a donc aucun signal public solide d’une release imminente.

Comparaison pratique :

A seul garde un contrat propre, mais peut bloquer la fonctionnalité pendant une durée indéterminée.
C temporaire donne la compatibilité immédiate avec 2.1.0, au prix du risque déjà identifié : format humain/localisé, donc fragile.
B en production évite ce parsing, mais remplace le risque de format par une dépendance non publiée; je ne le retiens pas comme minimum supporté. Un commit épinglé reste pertinent uniquement pour les tests de contrat et le développement.

Recommandation actuelle

Je recommande une variante A + C transitoire strictement bornée :

le contrat cible et la version minimale pérenne restent la première stable contenant d1dfbc4;
tant qu’elle n’existe pas, 2.1.0 peut être prise en charge par un adaptateur C isolé, explicitement marqué temporaire, limité aux comportements testés et devant échouer proprement si le format diverge;
le retrait de cet adaptateur est déclenché dès qu’une stable contenant le correctif passe les tests de capacité;
la détection reste fondée sur le comportement observé, pas seulement sur paru --version.

Cela accepte ton compromis sans transformer le parsing de l’UI de Paru en contrat durable. Cette recommandation reste une proposition; aucune décision n’est considérée acceptée sans le signal séparé prévu par le ticket.

J’ai vérifié l’amont. Le contexte renforce **A sur le fond**, mais pas l’hypothèse d’une publication proche : - [`d1dfbc4`](https://github.com/Morganamilo/paru/commit/d1dfbc48895a2a3b3fadc14569c3f2ffb5112b2e) corrige une régression de redirection stdin/stdout introduite par `af078e8b`; il ne s’agit pas d’un changement expérimental propre à AURoscope. - Le correctif a fermé [l’issue Paru #1413](https://github.com/Morganamilo/paru/issues/1413) et a été fusionné dans `master` le 5 octobre 2025 via [la PR #1417](https://github.com/Morganamilo/paru/pull/1417), le jour même de son ouverture. Il est toujours dans l’ascendance du `master` actuel. **La probabilité que la prochaine stable le contienne est donc élevée**, sauf revert. - En revanche, le calendrier ne permet pas de dire « relativement bientôt » : la dernière stable reste [`v2.1.0`](https://github.com/Morganamilo/paru/releases/tag/v2.1.0), publiée le 8 juillet 2025; aucun tag stable plus récent n’existe; le dernier commit de `master` date du 9 janvier 2026. Il n’y a donc aucun signal public solide d’une release imminente. Comparaison pratique : - **A seul** garde un contrat propre, mais peut bloquer la fonctionnalité pendant une durée indéterminée. - **C temporaire** donne la compatibilité immédiate avec 2.1.0, au prix du risque déjà identifié : format humain/localisé, donc fragile. - **B en production** évite ce parsing, mais remplace le risque de format par une dépendance non publiée; je ne le retiens pas comme minimum supporté. Un commit épinglé reste pertinent uniquement pour les tests de contrat et le développement. ### Recommandation actuelle Je recommande une **variante A + C transitoire strictement bornée** : 1. le contrat cible et la version minimale pérenne restent **la première stable contenant `d1dfbc4`**; 2. tant qu’elle n’existe pas, 2.1.0 peut être prise en charge par un adaptateur C isolé, explicitement marqué temporaire, limité aux comportements testés et devant échouer proprement si le format diverge; 3. le retrait de cet adaptateur est déclenché dès qu’une stable contenant le correctif passe les tests de capacité; 4. la détection reste fondée sur le comportement observé, pas seulement sur `paru --version`. Cela accepte ton compromis sans transformer le parsing de l’UI de Paru en contrat durable. Cette recommandation reste une proposition; aucune décision n’est considérée acceptée sans le signal séparé prévu par le ticket.

mathieu commented

2026-08-30 23:26:51 +00:00

Owner

GO DECISION

hephaistos added

Agent/Hermes

and removed

Agent/Human

labels

2026-08-30 23:34:28 +00:00

hephaistos commented

2026-08-30 23:37:22 +00:00

Author

Owner

Convention de finalisation concurrente : utilise le numéro du ticket comme numéro ADR sur quatre chiffres (#N → NNNN-*.md). Ne choisis pas « le prochain numéro libre » et ne renumérote aucun ADR; cette règle évite les collisions entre décisions validées en parallèle.

Convention de finalisation concurrente : utilise le numéro du ticket comme numéro ADR sur quatre chiffres (`#N` → `NNNN-*.md`). Ne choisis pas « le prochain numéro libre » et ne renumérote aucun ADR; cette règle évite les collisions entre décisions validées en parallèle.

hephaistos commented

2026-08-30 23:45:14 +00:00

Author

Owner

Décision D1 consignée et vérifiée.

ADR accepté : ADR-0002 — Paru native-selection compatibility boundary
Commit signé : dece69cc8de189d8813022097833610a03a5a37c
PR de design mise à jour : #1

La décision retient la première stable contenant d1dfbc4 comme cible durable, avec un adaptateur Paru 2.1.0 transitoire, isolé et fail-closed, retiré après validation de la stable corrigée. La capacité est testée par le comportement, pas par la seule version.

Vérifications : liens Markdown relatifs valides, git diff --check propre, tête distante et PR relues au commit ci-dessus, signature SSH valide pour hephaistos@ecl.400iso.net. Aucun code de production ni plan d’implémentation n’a été créé.

Décision D1 consignée et vérifiée. - ADR accepté : [`ADR-0002 — Paru native-selection compatibility boundary`](https://git.2027a.net/2027a/auroscope/src/commit/dece69cc8de189d8813022097833610a03a5a37c/docs/decisions/0002-paru-native-selection-compatibility.md) - Commit signé : [`dece69cc8de189d8813022097833610a03a5a37c`](https://git.2027a.net/2027a/auroscope/commit/dece69cc8de189d8813022097833610a03a5a37c) - PR de design mise à jour : [#1](https://git.2027a.net/2027a/auroscope/pulls/1) La décision retient la première stable contenant `d1dfbc4` comme cible durable, avec un adaptateur Paru 2.1.0 transitoire, isolé et fail-closed, retiré après validation de la stable corrigée. La capacité est testée par le comportement, pas par la seule version. Vérifications : liens Markdown relatifs valides, `git diff --check` propre, tête distante et PR relues au commit ci-dessus, signature SSH valide pour `hephaistos@ecl.400iso.net`. Aucun code de production ni plan d’implémentation n’a été créé.

hephaistos closed this issue

2026-08-30 23:45:37 +00:00