Revue d’architecture — 27 septembre 2026¶
Commit examiné : 502a0dc6ac9e8b8d550685c2ab9b66ec1d893130 sur master. État initial : revue et exigences d’ingénierie uniquement. L’implémentation ultérieure décrite ci-dessous traite les constats d’exécution.
Périmètre : séparation logique applicative/interfaces/adaptateurs, propriété des callbacks et de l’initialisation, contrats fixes de validation. Les sources ont été récupérées au commit fixé. Cette PR ne change pas le code d’exécution et ne prétend pas imposer les nouvelles exigences en CI. Sources examinées.
Les dépendances des 11 fichiers Python du paquet et des deux exécutables ont été inspectées et les parcours tâche/requête/exécution retracés. Il s’agit d’une revue de sources ; les suites d’intégration d’exécution et de sous-processus n’ont pas été relancées pour cette modification documentaire.
Constats confirmés¶
A1 — Élevé : tâches et plugins workers dépendent de requêtes HTTP actives¶
auton/modules/job.py gère admission, éviction de capacité, expiration, propriété, insertion en file et résultats dans les gestionnaires HTTP DWho. Ces politiques lèvent directement HttpReqErrJson. _push_epts_sync\ ``stocke une copie de requête dansAutonEPTObject; son constructeur litHTTP_AUTH_USERdepuis les variables serveur.AutonPlugBase.runrelit la requête pour l’autorisation etAutonSubProcPlugin.do_runappellepayload_params()`` pour les entrées d’exécution.
Ce couplage transport/application existe même sans import de bin/auton par le serveur. Extraire un JobService avec identité explicite, JobInput validé, erreurs neutres et file/horloge/stockage injectés. Le module HTTP décode et convertit les résultats ; les plugins consomment les valeurs des tâches. Préserver autorisation à l’admission et à l’exécution, propriété, verrous, capacité, expiration et bornes de sortie.
Validation : admettre, exécuter via un faux plugin, interroger puis expirer une tâche avec imports HTTP/CLI bloqués ; un utilisateur non autorisé ne peut ni soumettre ni inspecter la tâche d’un autre. Aucun objet requête ne survit au décodage du transport.
A2 — Moyen : le client distant réutilisable est implémenté dans l’exécutable¶
bin/auton.AutonClient combine construction d’URL, POST/GET, basculement, validation des réponses, décalages de sortie, préparation environnement/fichiers et affichage terminal. do_autorun mélange interrogation, _show_results\ ``et politique des codes de sortie. Extraire un module client avec options/session explicites et flux de résultats ; garder stdin/stdout, analyse des arguments et codes de sortie dansbin/auton``. Préserver l’interdiction de rejouer un POST accepté ambigu.
A3 — Faible : contrats de validation/style dispersés¶
L’enregistrement des noms d’environnement et la regex de décalage de sortie dans modules/job.py utilisent des motifs intégrés et match avec $. Le motif de décalage peut accepter une correspondance avant un saut de ligne final lors d’un appel direct. Centraliser les motifs fixes et utiliser une correspondance complète ; ne pas confondre ce constat avec l’acceptation par l’analyseur HTTP. Les schémas existants utilisent déjà des constantes de classe en majuscules.
Éléments positifs et limites¶
L’analyse AST ne trouve aucun import CLI/TUI dans le paquet. bin/autond est un point d’entrée légitime de composition/cycle de vie. Le plugin subproc exécute des cibles configurées, ce qui est le but du produit ; ce n’est pas une API lançant sa propre CLI. Limites d’exécution/sortie, règles de reprise sûres et autorisations doivent rester intactes. Aucune tâche réelle n’a été soumise pendant cette revue.
Implémentation ultérieure¶
L’extraction applicative consécutive traite A1 à A3 :
classes/job.py,classes/jobs.pyetclasses/job_schema.pycontiennent valeurs de tâche, validation et politique de service. La traduction des états HTTP reste dansmodules/job.py.Les plugins consomment des valeurs détachées de charge utile/identité et revérifient les ACL d’exécution. L’ancien constructeur est une façade d’instantané documentée.
auton_client.RemoteClientgère le transport distant et l’itération des résultats ; entrées/sorties terminal et politique de sortie restent dans la CLI.Les motifs fixes utilisent la correspondance complète. Les modules HTTP initialisés possèdent leurs verrous ; les registres de points d’entrée/files du daemon restent des entrées de composition.
Des tests comportementaux bloquent les imports HTTP, DWho et CLI pendant admission, fausse exécution, contrôle du propriétaire, interrogation et expiration. D’autres vérifient entrées historiques détachées, vrais sous-processus et ACL, concurrence/capacité, panne de file, décalages clients et intégration daemon/CLI réelle existante. Voir le README pour la compatibilité exacte et les limites restantes.