2027a/auroscope

Watch

Fork 0

[Decision D2] Choisir l’orchestration Paru sans remplacer son résolveur #3

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. Réponse ≠ clôture; fermeture seulement après ton go explicite.

Question

AURoscope doit-il orchestrer Paru en étapes distinctes (sélection/plan, revue, exécution), ou s’appuyer uniquement sur un hook pendant une invocation unique ?

Enjeu

Il faut conserver Paru comme sélecteur, résolveur et builder tout en obtenant un point où les recettes exactes sont inspectées et approuvées avant exécution.

Options

A — Une seule invocation Paru, audit dans `PreBuildCommand`

Pour : comportement très proche de Paru, peu d’orchestration.
Contre : revue tardive, mauvais endroit pour préparer tout l’état, timing du hook imparfait, cache binaire ambigu.

B — Orchestration multiétape

Paru sélectionne et produit son plan;
AURoscope clone/inspecte et recueille la décision;
Paru réexécute; un garde transactionnel refuse toute dérive.

Pour : décision humaine avant exécution, état SQLite propre, garde étroite.
Contre : deux résolutions; il faut détecter et refuser toute différence.

C — Réimplémenter/lier libalpm ou les internes de Paru

Pour : plan typé riche.
Contre : AURoscope devient un second Paru, forte complexité et couplage Rust/libalpm.

Recommandation

Option B. Parser seulement les sorties machine dont le contrat est prouvé; jamais le menu humain. Toute différence entre plan et exécution retourne à la revue.

Risques

Paru n’a pas d’API JSON stable de transaction.
Son format --order a déjà divergé entre documentation et code (INSTALL vs REPO).
Les adaptateurs doivent être versionnés et fail-closed.

Réponse attendue

Choisis A/B/C ou propose une variante. Après reformulation, j’attends ton go avant ADR/clôture.

Documentation

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.** Réponse ≠ clôture; fermeture seulement après ton **go explicite**. ## Question AURoscope doit-il orchestrer Paru en étapes distinctes (sélection/plan, revue, exécution), ou s’appuyer uniquement sur un hook pendant une invocation unique ? ## Enjeu Il faut conserver Paru comme sélecteur, résolveur et builder tout en obtenant un point où les recettes exactes sont inspectées et approuvées avant exécution. ## Options ### A — Une seule invocation Paru, audit dans `PreBuildCommand` **Pour :** comportement très proche de Paru, peu d’orchestration. **Contre :** revue tardive, mauvais endroit pour préparer tout l’état, timing du hook imparfait, cache binaire ambigu. ### B — Orchestration multiétape 1. Paru sélectionne et produit son plan; 2. AURoscope clone/inspecte et recueille la décision; 3. Paru réexécute; un garde transactionnel refuse toute dérive. **Pour :** décision humaine avant exécution, état SQLite propre, garde étroite. **Contre :** deux résolutions; il faut détecter et refuser toute différence. ### C — Réimplémenter/lier libalpm ou les internes de Paru **Pour :** plan typé riche. **Contre :** AURoscope devient un second Paru, forte complexité et couplage Rust/libalpm. ## Recommandation **Option B.** Parser seulement les sorties machine dont le contrat est prouvé; jamais le menu humain. Toute différence entre plan et exécution retourne à la revue. ## Risques - Paru n’a pas d’API JSON stable de transaction. - Son format `--order` a déjà divergé entre documentation et code (`INSTALL` vs `REPO`). - Les adaptateurs doivent être versionnés et fail-closed. ## Réponse attendue Choisis A/B/C ou propose une variante. Après reformulation, j’attends ton **go** avant ADR/clôture. ## Documentation - https://git.2027a.net/2027a/auroscope/src/branch/design/technical-contracts/docs/architecture/design-proposals.md - 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:50:42 +00:00

Owner

B, go

hephaistos commented

2026-08-30 23:19:34 +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:22:00 +00:00

Author

Owner

Compris : ton choix est B, l’orchestration multiétape, tout en gardant Paru comme sélecteur, résolveur et builder.

Ma recommandation concrète reste B, avec ce contrat :

Paru produit le plan exploitable par un adaptateur dont le contrat et la version sont connus.
AURoscope fige l’empreinte du plan, prépare les sources et présente les recettes exactes à la revue avant toute exécution.
Après approbation, Paru résout de nouveau et exécute.
Un garde transactionnel compare le plan courant au plan approuvé; toute dérive — versions, sources, dépendances ou recettes — bloque l’exécution et renvoie à la revue.
Les adaptateurs restent versionnés et fail-closed; le menu humain de Paru n’est jamais parsé.

C’est préférable à A, où PreBuildCommand arrive trop tard pour offrir une vraie frontière d’approbation et laisse des ambiguïtés de cache, et à C, qui ferait d’AURoscope un second Paru fortement couplé à libalpm et aux internes de Paru. Le coût assumé de B est la double résolution; le garde de dérive sert précisément à la rendre sûre.

Ton commentaire B, go exprime bien le choix, mais il ne correspond pas au signal déterministe exact. Je ne considère donc pas encore la décision comme acceptée. Si cette reformulation te convient, publie un commentaire distinct contenant exactement :

GO DECISION

Compris : ton choix est **B**, l’orchestration multiétape, tout en gardant Paru comme sélecteur, résolveur et builder. Ma recommandation concrète reste **B**, avec ce contrat : 1. Paru produit le plan exploitable par un adaptateur dont le contrat et la version sont connus. 2. AURoscope fige l’empreinte du plan, prépare les sources et présente les recettes exactes à la revue avant toute exécution. 3. Après approbation, Paru résout de nouveau et exécute. 4. Un garde transactionnel compare le plan courant au plan approuvé; toute dérive — versions, sources, dépendances ou recettes — bloque l’exécution et renvoie à la revue. 5. Les adaptateurs restent versionnés et **fail-closed**; le menu humain de Paru n’est jamais parsé. C’est préférable à **A**, où `PreBuildCommand` arrive trop tard pour offrir une vraie frontière d’approbation et laisse des ambiguïtés de cache, et à **C**, qui ferait d’AURoscope un second Paru fortement couplé à libalpm et aux internes de Paru. Le coût assumé de B est la double résolution; le garde de dérive sert précisément à la rendre sûre. Ton commentaire `B, go` exprime bien le choix, mais il ne correspond pas au signal déterministe exact. Je ne considère donc pas encore la décision comme acceptée. Si cette reformulation te convient, publie un commentaire distinct contenant exactement : ```text GO DECISION ```

mathieu commented

2026-08-30 23:24:35 +00:00

Owner

GO DECISION

hephaistos added

Agent/Hermes

and removed

Agent/Human

labels

2026-08-30 23:34:29 +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:42:09 +00:00

Author

Owner

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

ADR accepté : ADR-0003 — Multi-stage Paru orchestration without resolver replacement
Commit signé : 9f9e3aa575cc2b554fc420c3d17891b2b475acea
PR de design mise à jour : #1, tête vérifiée sur ce commit et mergeable: true
Validation documentaire : git diff --check réussi; liens internes de l’ADR présents.

La décision acceptée garde Paru comme sélecteur, résolveur, builder et frontend Pacman, avec des résolutions séparées avant/après revue et retour à la revue sur toute dérive du plan. Aucun code de production ni plan d’implémentation n’a été créé.

Décision D2 consignée et vérifiée. - ADR accepté : [`ADR-0003 — Multi-stage Paru orchestration without resolver replacement`](https://git.2027a.net/2027a/auroscope/src/commit/9f9e3aa575cc2b554fc420c3d17891b2b475acea/docs/decisions/0003-multi-stage-paru-orchestration.md) - Commit signé : [`9f9e3aa575cc2b554fc420c3d17891b2b475acea`](https://git.2027a.net/2027a/auroscope/commit/9f9e3aa575cc2b554fc420c3d17891b2b475acea) - PR de design mise à jour : [#1](https://git.2027a.net/2027a/auroscope/pulls/1), tête vérifiée sur ce commit et `mergeable: true` - Validation documentaire : `git diff --check` réussi; liens internes de l’ADR présents. La décision acceptée garde Paru comme sélecteur, résolveur, builder et frontend Pacman, avec des résolutions séparées avant/après revue et retour à la revue sur toute dérive du plan. Aucun code de production ni plan d’implémentation n’a été créé.

hephaistos closed this issue

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