2027a/auroscope

Watch

Fork 0

Plan: executable AURoscope v1 implementation sequence #18

Closed

hephaistos wants to merge 0 commits from execution/issue-17-initial-implementation-plan into main

hephaistos commented

2026-08-31 01:19:34 +00:00

Owner

Summary

define seven dependency-ordered vertical milestones from bootstrap through the disposable-Arch release gate;
give every milestone explicit prerequisites, exact repository paths, RED/GREEN/REFACTOR steps, exact executable verification commands, and observable Definition of Done;
prove the unresolved Paru execution closure in Milestone 0 before SQLite, scanner, LLM, or review architecture grows around it;
deliver one deterministic guarded AUR install path first, then daily Paru workflows, optional LLM assessment, bounded maintenance, and packaging;
force rebuilds in v1 and defer cached package-artifact reuse;
define a durable serial Hermes/Kanban loop with one new implementation umbrella issue, implementation/v1, one draft PR, a stable worktree, and a concise restart status file.

Scope

Documentation only. This PR closes planning issue #17 but does not authorize production implementation. Implementation starts only after this PR is merged and Mathieu explicitly launches the separate implementation loop.

Verification

npx --yes markdownlint-cli2@0.19.0 docs/implementation/initial-plan.md — one real file linted, 0 errors; MD013 is intentionally disabled in-file, all other enabled rules remain active;
git diff --check — clean;
structural review — 7 milestones, each with exactly one Definition of Ready, exact-files block, RED, GREEN, REFACTOR, exact-command block, and Definition of Done;
commit 6c86e714e384aa0fee9d2ff6be21d5495affc558 is signed by Hephaistos;
the required work branch and this PR branch point to the same commit.

Risks and stop gates

Milestone 0 must prove the supported Paru execution closure and hook boundary; failure blocks later milestones and requires a focused decision amendment.
Paru/Pacman/makepkg contracts remain versioned, executable compatibility gates rather than assumptions.
The accepted same-UID post-guard race and trusted-local-host boundary remain explicit residual risks.
Live package-manager and end-to-end tests are restricted to guarded disposable Arch environments and must never target the workstation package state.

Review guidance

Review Milestone 0's fail-closed feasibility gate first, then the exact human-authority/approval invariants in milestones 1–2, the official-upgrade-first sequencing in Milestone 3, and the disposable-host guard in Milestone 6. Also review the one-branch serial Kanban policy for restartability and collision avoidance.

Closes #17

## Summary - define seven dependency-ordered vertical milestones from bootstrap through the disposable-Arch release gate; - give every milestone explicit prerequisites, exact repository paths, RED/GREEN/REFACTOR steps, exact executable verification commands, and observable Definition of Done; - prove the unresolved Paru execution closure in Milestone 0 before SQLite, scanner, LLM, or review architecture grows around it; - deliver one deterministic guarded AUR install path first, then daily Paru workflows, optional LLM assessment, bounded maintenance, and packaging; - force rebuilds in v1 and defer cached package-artifact reuse; - define a durable serial Hermes/Kanban loop with one new implementation umbrella issue, `implementation/v1`, one draft PR, a stable worktree, and a concise restart status file. ## Scope Documentation only. This PR closes planning issue #17 but does not authorize production implementation. Implementation starts only after this PR is merged and Mathieu explicitly launches the separate implementation loop. ## Verification - `npx --yes markdownlint-cli2@0.19.0 docs/implementation/initial-plan.md` — one real file linted, 0 errors; MD013 is intentionally disabled in-file, all other enabled rules remain active; - `git diff --check` — clean; - structural review — 7 milestones, each with exactly one Definition of Ready, exact-files block, RED, GREEN, REFACTOR, exact-command block, and Definition of Done; - commit `6c86e714e384aa0fee9d2ff6be21d5495affc558` is signed by Hephaistos; - the required work branch and this PR branch point to the same commit. ## Risks and stop gates - Milestone 0 must prove the supported Paru execution closure and hook boundary; failure blocks later milestones and requires a focused decision amendment. - Paru/Pacman/makepkg contracts remain versioned, executable compatibility gates rather than assumptions. - The accepted same-UID post-guard race and trusted-local-host boundary remain explicit residual risks. - Live package-manager and end-to-end tests are restricted to guarded disposable Arch environments and must never target the workstation package state. ## Review guidance Review Milestone 0's fail-closed feasibility gate first, then the exact human-authority/approval invariants in milestones 1–2, the official-upgrade-first sequencing in Milestone 3, and the disposable-host guard in Milestone 6. Also review the one-branch serial Kanban policy for restartability and collision avoidance. Closes #17

hephaistos added 1 commit

2026-08-31 01:19:34 +00:00

docs: plan initial AURoscope implementation cea3087706

hephaistos referenced this pull request

2026-08-31 01:20:08 +00:00

Plan initial d’implémentation complet après le design #17

hephaistos commented

2026-08-31 01:26:18 +00:00

Author

Owner

Revue critique — angle simplification

Verdict proposé : modifications avant approbation. Les ADR ont déjà éliminé plusieurs mauvaises directions (framework CLI, PTY systématique, resolver maison, event sourcing). Mon problème principal est maintenant le plan d’exécution : il transforme ces décisions en 19 chantiers horizontaux et reporte trop tard les preuves qui peuvent invalider l’ensemble.

1. [Bloquant] Prouver le contrat d’exécution avant de construire autour

Le plan reconnaît lui-même que la fermeture réellement exécutée par Paru n’est pas encore prouvée (initial-plan.md:21, 349-357, 398-406). Pourtant cette inconnue ne devient un gate qu’aux slices 10/12, après le bootstrap, la configuration, le process runner, les adaptateurs, SQLite, l’acquisition, le scanner, le LLM et la revue.

C’est le mauvais ordre de risque : si le run d’exécution ne peut pas être borné par le plan approuvé avec une surface Paru supportée, une partie importante de l’orchestration doit être redessinée.

Simplification demandée : faire de cette preuve un spike exécutable initial, juste après le bootstrap et le minimum d’adaptateur Paru, dans Arch jetable. Le spike doit prouver sélection/planification, re-résolution, visibilité de la fermeture réellement exécutée et timing du hook. Échec = issue MODE: DECISION avant toute architecture applicative supplémentaire.

2. [Important] Ne pas mettre le LLM sur le chemin critique du premier flux vertical

La slice 08 est un blocage préalable à la présentation, à la décision humaine, à la planification et au guard (286-357, graphe 546-554). Or le backend disabled est déjà un état v1 accepté : la revue et les rapports doivent donc fonctionner sans assessment LLM.

Simplification demandée : livrer d’abord un flux vertical déterministe classification → plan → acquisition → scan → présentation → décision → guard → exécution pour un -S AUR explicite, puis ajouter le LLM comme enrichissement. Cela ne retire pas le LLM de v1; cela évite qu’un adaptateur HTTP/Codex, sa persistance et sa validation bloquent la preuve du cœur produit.

3. [Important] Retirer la réutilisation d’artefacts de v1 tant que sa surface n’est pas prouvée

Le plan dit que la réutilisation reste désactivée sans preuve (22), mais lui réserve quand même une migration, internal/approval/artifact.go, une matrice de mutation/réutilisation, des scénarios d’intégration et un critère global (384-406, 483, 606). C’est une branche spéculative coûteuse autour d’une capacité possiblement indisponible.

Simplification demandée : v1 force toujours le rebuild et ne réutilise aucun paquet préconstruit. Conserver seulement l’enregistrement d’outcome réellement nécessaire à status/explain. Si une surface post-build exacte est prouvée plus tard, l’ajouter dans une feature séparée; si les textes acceptés sont interprétés comme exigeant cette capacité en v1, ouvrir d’abord un petit amendement de décision au lieu d’implémenter un demi-système conditionnel.

4. [Important] Garder les 19 slices comme checklist TDD, pas comme topologie de 19 issues/PR

28-41 impose une issue, une branche et une PR par slice; 473-491 ajoute ensuite une slice d’intégration générale alors que chaque slice annonce déjà ses tests et le baseline cumulatif. Le résultat annoncé est 19 PR sérielles et 91 directives de création de fichiers avant même le premier retour d’usage. C’est beaucoup de coût de coordination et une intégration réelle trop tardive.

Simplification demandée : conserver les petites slices RED/GREEN comme étapes internes, mais les regrouper en 6–8 PR de capacité cohérentes. Chaque PR doit fermer un comportement observable et porter ses scénarios d’intégration. Supprimer la slice 16 comme phase de “rattrapage” : ses scénarios vont dans les PR qui livrent le comportement; la slice 18 reste l’unique gate E2E jetable final.

Un découpage plus maigre serait :

bootstrap + spike Paru bloquant;
fondations minimales + flux déterministe explicite complet;
approbation/guard et état SQLite minimal;
sélection, upgrade officiel-first, held/status;
LLM optionnel;
récupération/rétention;
packaging + gate Arch jetable.

5. [Suggestion] Faire croître config et maintenance avec leurs consommateurs

La slice 02 crée d’un coup [policy], [scanner], [llm], [retention], [compatibility], etc. avant ces features (148-168). La slice 05 ajoute backup/restore, quick_check et locking opérationnel dès la première migration (215-238), puis la slice 15 revient sur récupération et maintenance (450-471).

Simplification demandée :

slice config initiale : uniquement chemins privés + viewer nécessaires au premier flux;
ajouter chaque section TOML dans la slice qui la consomme;
bootstrap SQLite : ouverture, FK, migration initiale, invariants réellement utilisés;
déplacer backup/restore, purge, quick_check de démarrage et maintenance dans la slice récupération/rétention.

Cela applique à la configuration et aux opérations le même principe “instrumental, pas générique” déjà accepté pour le schéma SQLite.

6. [Suggestion] Alléger les preuves de processus et les écritures non autoritatives

Deux exigences ajoutent du bruit sans renforcer le contrat produit :

35, 45-50 demandent de conserver une trace RED/GREEN/REFACTOR par commits ou dans chaque description de PR. Garder le TDD comme méthode, mais exiger surtout des commits verts et les preuves finales; ne conserver un échec RED que lorsqu’il documente une régression ou une découverte de contrat externe.
326-328 demandent fsync, rename et synchronisation du répertoire pour des rapports que la spécification déclare reconstructibles et non autoritatifs. Un fichier temporaire privé, fermé puis renommé atomiquement suffit; la durabilité forte appartient à SQLite et aux migrations/backups.

Même principe pour CI : tests ciblés et race tests pertinents sur chaque PR; suite race complète aux checkpoints et à la release, plutôt que go test -race ./... après chaque micro-slice.

Conclusion

Je ne demande pas de remettre en cause les 14 ADR. Je demande que le plan soit réordonné autour de preuves de faisabilité précoces et de tranches verticales, et qu’il supprime deux coûts non nécessaires au premier v1 : la réutilisation d’artefacts et la correspondance 1 slice = 1 PR. En l’état, le plan est très complet, mais sa complétude augmente le coût avant d’avoir prouvé le chemin critique.

## Revue critique — angle simplification **Verdict proposé : modifications avant approbation.** Les ADR ont déjà éliminé plusieurs mauvaises directions (framework CLI, PTY systématique, resolver maison, event sourcing). Mon problème principal est maintenant le plan d’exécution : il transforme ces décisions en 19 chantiers horizontaux et reporte trop tard les preuves qui peuvent invalider l’ensemble. ### 1. [Bloquant] Prouver le contrat d’exécution avant de construire autour Le plan reconnaît lui-même que la fermeture réellement exécutée par Paru n’est pas encore prouvée (`initial-plan.md:21`, `349-357`, `398-406`). Pourtant cette inconnue ne devient un gate qu’aux slices 10/12, après le bootstrap, la configuration, le process runner, les adaptateurs, SQLite, l’acquisition, le scanner, le LLM et la revue. C’est le mauvais ordre de risque : si le run d’exécution ne peut pas être borné par le plan approuvé avec une surface Paru supportée, une partie importante de l’orchestration doit être redessinée. **Simplification demandée :** faire de cette preuve un spike exécutable initial, juste après le bootstrap et le minimum d’adaptateur Paru, dans Arch jetable. Le spike doit prouver sélection/planification, re-résolution, visibilité de la fermeture réellement exécutée et timing du hook. Échec = issue `MODE: DECISION` avant toute architecture applicative supplémentaire. ### 2. [Important] Ne pas mettre le LLM sur le chemin critique du premier flux vertical La slice 08 est un blocage préalable à la présentation, à la décision humaine, à la planification et au guard (`286-357`, graphe `546-554`). Or le backend `disabled` est déjà un état v1 accepté : la revue et les rapports doivent donc fonctionner sans assessment LLM. **Simplification demandée :** livrer d’abord un flux vertical déterministe `classification → plan → acquisition → scan → présentation → décision → guard → exécution` pour un `-S` AUR explicite, puis ajouter le LLM comme enrichissement. Cela ne retire pas le LLM de v1; cela évite qu’un adaptateur HTTP/Codex, sa persistance et sa validation bloquent la preuve du cœur produit. ### 3. [Important] Retirer la réutilisation d’artefacts de v1 tant que sa surface n’est pas prouvée Le plan dit que la réutilisation reste désactivée sans preuve (`22`), mais lui réserve quand même une migration, `internal/approval/artifact.go`, une matrice de mutation/réutilisation, des scénarios d’intégration et un critère global (`384-406`, `483`, `606`). C’est une branche spéculative coûteuse autour d’une capacité possiblement indisponible. **Simplification demandée :** v1 force toujours le rebuild et ne réutilise aucun paquet préconstruit. Conserver seulement l’enregistrement d’outcome réellement nécessaire à `status/explain`. Si une surface post-build exacte est prouvée plus tard, l’ajouter dans une feature séparée; si les textes acceptés sont interprétés comme exigeant cette capacité en v1, ouvrir d’abord un petit amendement de décision au lieu d’implémenter un demi-système conditionnel. ### 4. [Important] Garder les 19 slices comme checklist TDD, pas comme topologie de 19 issues/PR `28-41` impose une issue, une branche et une PR par slice; `473-491` ajoute ensuite une slice d’intégration générale alors que chaque slice annonce déjà ses tests et le baseline cumulatif. Le résultat annoncé est 19 PR sérielles et 91 directives de création de fichiers avant même le premier retour d’usage. C’est beaucoup de coût de coordination et une intégration réelle trop tardive. **Simplification demandée :** conserver les petites slices RED/GREEN comme étapes internes, mais les regrouper en 6–8 PR de capacité cohérentes. Chaque PR doit fermer un comportement observable et porter ses scénarios d’intégration. Supprimer la slice 16 comme phase de “rattrapage” : ses scénarios vont dans les PR qui livrent le comportement; la slice 18 reste l’unique gate E2E jetable final. Un découpage plus maigre serait : 1. bootstrap + spike Paru bloquant; 2. fondations minimales + flux déterministe explicite complet; 3. approbation/guard et état SQLite minimal; 4. sélection, upgrade officiel-first, held/status; 5. LLM optionnel; 6. récupération/rétention; 7. packaging + gate Arch jetable. ### 5. [Suggestion] Faire croître config et maintenance avec leurs consommateurs La slice 02 crée d’un coup `[policy]`, `[scanner]`, `[llm]`, `[retention]`, `[compatibility]`, etc. avant ces features (`148-168`). La slice 05 ajoute backup/restore, `quick_check` et locking opérationnel dès la première migration (`215-238`), puis la slice 15 revient sur récupération et maintenance (`450-471`). **Simplification demandée :** - slice config initiale : uniquement chemins privés + viewer nécessaires au premier flux; - ajouter chaque section TOML dans la slice qui la consomme; - bootstrap SQLite : ouverture, FK, migration initiale, invariants réellement utilisés; - déplacer backup/restore, purge, `quick_check` de démarrage et maintenance dans la slice récupération/rétention. Cela applique à la configuration et aux opérations le même principe “instrumental, pas générique” déjà accepté pour le schéma SQLite. ### 6. [Suggestion] Alléger les preuves de processus et les écritures non autoritatives Deux exigences ajoutent du bruit sans renforcer le contrat produit : - `35`, `45-50` demandent de conserver une trace RED/GREEN/REFACTOR par commits ou dans chaque description de PR. Garder le TDD comme méthode, mais exiger surtout des commits verts et les preuves finales; ne conserver un échec RED que lorsqu’il documente une régression ou une découverte de contrat externe. - `326-328` demandent `fsync`, rename et synchronisation du répertoire pour des rapports que la spécification déclare reconstructibles et non autoritatifs. Un fichier temporaire privé, fermé puis renommé atomiquement suffit; la durabilité forte appartient à SQLite et aux migrations/backups. Même principe pour CI : tests ciblés et race tests pertinents sur chaque PR; suite race complète aux checkpoints et à la release, plutôt que `go test -race ./...` après chaque micro-slice. ### Conclusion Je ne demande pas de remettre en cause les 14 ADR. Je demande que le plan soit réordonné autour de **preuves de faisabilité précoces et de tranches verticales**, et qu’il supprime deux coûts non nécessaires au premier v1 : la réutilisation d’artefacts et la correspondance 1 slice = 1 PR. En l’état, le plan est très complet, mais sa complétude augmente le coût avant d’avoir prouvé le chemin critique.

hephaistos added 1 commit

2026-08-31 01:38:09 +00:00

docs: refine initial implementation plan 900d9a67a0

hephaistos referenced this pull request

2026-08-31 01:38:49 +00:00

Plan initial d’implémentation complet après le design #17

hephaistos added 1 commit

2026-08-31 01:41:12 +00:00

docs: simplify AURoscope v1 implementation plan 7400e1e996

hephaistos commented

2026-08-31 01:41:31 +00:00

Author

Owner

Plan définitif réécrit dans l’optique allégée demandée.

7 jalons verticaux au lieu de 19 tranches horizontales;
preuve bloquante du contrat d’exécution Paru en jalon 0;
premier flux AUR déterministe et gardé avant le LLM;
reconstruction forcée en v1, sans réutilisation d’artefacts;
une issue d’exécution, une branche implementation/v1, une draft PR et une chaîne Kanban sérielle et reprenable;
prompt /goal compact inclus pour lancer la boucle depuis une nouvelle session.

Commit signé : 7400e1e996b9256501cb1a699f976d3c1e376c78. Les remarques de la revue #1294 sont intégrées.

Plan définitif réécrit dans l’optique allégée demandée. - 7 jalons verticaux au lieu de 19 tranches horizontales; - preuve bloquante du contrat d’exécution Paru en jalon 0; - premier flux AUR déterministe et gardé avant le LLM; - reconstruction forcée en v1, sans réutilisation d’artefacts; - une issue d’exécution, une branche `implementation/v1`, une draft PR et une chaîne Kanban sérielle et reprenable; - prompt `/goal` compact inclus pour lancer la boucle depuis une nouvelle session. Commit signé : `7400e1e996b9256501cb1a699f976d3c1e376c78`. Les remarques de la revue #1294 sont intégrées.

hephaistos added 1 commit

2026-08-31 01:44:54 +00:00

docs: harden autonomous v1 execution plan 1d4bdc7bb6

hephaistos commented

2026-08-31 01:45:11 +00:00

Author

Owner

Audit final intégré après la réécriture allégée. Corrections principales :

seconde résolution et comparaison de drift désormais dans le premier flux exécutable;
plafonds scanner exacts et benchmark restaurés;
invariants SQLite/CGO, configuration Paru, signaux et réinspection explicités;
issue #17 interdite comme issue d’implémentation;
boucle Kanban rendue idempotente avec carte bootstrap, 7 workers sériels, worktree stable et carte finalizer;
reprise intra-jalon, détection des livraisons déjà poussées, autorité PR limitée et pause Kanban explicite.

Commit signé : 1d4bdc7bb631ce2c2d96191219d25678bafe10eb.

Audit final intégré après la réécriture allégée. Corrections principales : - seconde résolution et comparaison de drift désormais dans le premier flux exécutable; - plafonds scanner exacts et benchmark restaurés; - invariants SQLite/CGO, configuration Paru, signaux et réinspection explicités; - issue #17 interdite comme issue d’implémentation; - boucle Kanban rendue idempotente avec carte bootstrap, 7 workers sériels, worktree stable et carte finalizer; - reprise intra-jalon, détection des livraisons déjà poussées, autorité PR limitée et pause Kanban explicite. Commit signé : `1d4bdc7bb631ce2c2d96191219d25678bafe10eb`.

hephaistos added 1 commit

2026-08-31 01:50:13 +00:00

docs: make implementation milestones executable 6c86e714e3

hephaistos changed title from ~~Plan: initial AURoscope v1 implementation sequence~~ to Plan: executable AURoscope v1 implementation sequence

2026-08-31 01:50:48 +00:00

hephaistos referenced this pull request

2026-08-31 01:50:48 +00:00

Plan initial d’implémentation complet après le design #17

hephaistos referenced this pull request

2026-08-31 01:50:56 +00:00

Plan initial d’implémentation complet après le design #17

hephaistos referenced this pull request

2026-08-31 02:40:01 +00:00

Décision — Recentrer v1 sur un wrapper minimal LLM-first #19

hephaistos commented

2026-08-31 02:40:16 +00:00

Author

Owner

PR bloquée par la remise à plat demandée par Mathieu.

Le plan actuel reste trop éloigné du produit : l’audit LLM doit être le cœur, pas une option autour d’un moteur de règles et d’un protocole transactionnel. La nouvelle architecture minimale est proposée dans #19 : #19

Ne pas fusionner cette PR. Après acceptation de #19, la spécification et les ADR seront simplifiés, puis ce plan sera remplacé par une séquence courte centrée sur le spike Paru, l’audit Codex CLI, la décision par paquet et l’exécution finale.

PR bloquée par la remise à plat demandée par Mathieu. Le plan actuel reste trop éloigné du produit : l’audit LLM doit être le cœur, pas une option autour d’un moteur de règles et d’un protocole transactionnel. La nouvelle architecture minimale est proposée dans #19 : https://git.2027a.net/2027a/auroscope/issues/19 Ne pas fusionner cette PR. Après acceptation de #19, la spécification et les ADR seront simplifiés, puis ce plan sera remplacé par une séquence courte centrée sur le spike Paru, l’audit Codex CLI, la décision par paquet et l’exécution finale.

hephaistos referenced this pull request

2026-08-31 03:00:46 +00:00

Plan minimal d’implémentation après spike Paru #21

hephaistos commented

2026-08-31 03:01:42 +00:00

Author

Owner

PR fermée sans fusion. Son plan repose sur l’architecture scanner/LLM optionnel désormais supersédée par la décision #19 et ADR-0015.

La finalisation minimale est dans PR #20; le nouveau spike et plan seront suivis par #21. Cette PR reste comme historique uniquement.

PR fermée sans fusion. Son plan repose sur l’architecture scanner/LLM optionnel désormais supersédée par la décision #19 et ADR-0015. La finalisation minimale est dans PR #20; le nouveau spike et plan seront suivis par #21. Cette PR reste comme historique uniquement.

hephaistos closed this pull request

2026-08-31 03:01:43 +00:00

hephaistos referenced this pull request

2026-08-31 03:01:43 +00:00

Plan initial d’implémentation complet après le design #17

hephaistos referenced this pull request

2026-08-31 03:03:12 +00:00

Decision: adopt the minimal LLM-first architecture #20

~~hephaistos referenced this pull request 2026-08-31 03:06:00 +00:00~~

Plan minimal d’implémentation après spike Paru #21