Auton 1.2.0 — historique de validation et de livraison¶

Candidat revu le 30 septembre 2026 ; état de livraison réconcilié le 2 novembre 2026. Ce document conserve les preuves d’implémentation et de validation de la PR #36. La version 1.2.0 a été publiée ; les deux paquets et le site sont depuis passés à la série 1.3. Les nombres ci-dessous décrivent ce candidat historique, pas une nouvelle exécution des tests sur les sources actuelles.

Périmètre implémenté¶

[x] Réconciliation en lecture seule des rapports JSON avec les cibles actuelles explicitement sélectionnées : origines/identités fixées, sans rejeu POST ni reprise d’étape ignorée.
[x] Schémas publiés de paramètres positionnels et saisie guidée Web/TUI, avec validation faisant autorité à l’admission et à l’exécution.
[x] Visibilité des origines de remplacement avec lectures bornées et détails liés à leur source.
[x] Annulation explicite de sous-processus autorisée par propriétaire/portée, courses au lancement en file, nettoyage des enfants et distinction demande/confirmation compris.
[x] Workers Unix détachés sur l’hôte de contrôle : le départ du client n’arrête pas le scénario ; les observations privées durables conservent les identités sans rejeu.
[x] continue_on_error explicite, historique Redis optionnel via DWho, mTLS natif et SSO navigateur OIDC code-flow/PKCE avec permissions des comptes locaux.
[x] Compatibilité Python 3.13, contrôle des wheels reproductibles et expiration périodique des résultats pendant l’inactivité ; validation des paquets installés, interfaces et documentation.

Preuves¶

Le candidat complet 41d7cb51186272b2e771e87f2742188a60fc77ab a réussi les tests 36750744617 et la construction Docker/paquets 36750744423. Les contrôles du dernier commit de la PR restent requis après les dernières finitions documentaires et visuelles ; un ancien commit vert ne valide pas les modifications suivantes.

unittest : 227 déclarations et 227 cas collectés. L’exécution locale en a réussi 225 et ignoré volontairement deux intégrations faute de serveur Redis. Le job Redis dédié de la CI les exécute contre un vrai Redis.
Python 3.10, 3.11, 3.12 et 3.13 : suite et contrôles d’isolation du client installé.
Construction Docker, tests sans privilèges, démarrage rapide Compose authentifié et volumes durables ; aucune publication d’image depuis cette PR.
Deux constructions indépendantes de wheels aux octets identiques dans le même environnement.
Wheels installés hors dépôt, points d’entrée, ressources et refus d’authentification ; compatibilité client ↔ daemon candidat avec la version historique 0.3.2.
Sélection réelle au terminal, arguments guidés, progression, export privé et réconciliation en lecture seule ; exports originaux et inventaire des tâches inchangés.
Chromium bureau/mobile, rendu littéral des sorties, soumission guidée, confirmation, maintenance, absence de rejeu, lecture seule et déconnexion.
Navigation OIDC Chromium entre sites sur HTTPS avec certificat client, compte existant en lecture seule, cookie de session, CSRF et déconnexion locale réussie.
Les tests HTTPS stricts rejettent certificat client absent, chaîne serveur non fiable et identité applicative absente. Les tests OIDC signés rejettent émetteur, audience, nonce, clé ou algorithme incorrects, flux expirés, rejeu et comptes désactivés.
Documentation construite avec avertissements traités comme erreurs. Les captures Web/TUI générées ont été examinées visuellement, retour de soumission bleu et état explicite compris.
Tests des outils CI : 14 collectés, 13 réussis localement ; un test générique de compatibilité du lanceur pytest ignoré car pytest est absent. Auton utilise unittest.

Architecture et constats de revue¶

Les services applicatifs consomment entrées, identités et adaptateurs explicites. CLI, TUI et Web traduisent l’interaction ; aucune interface n’en exécute une autre comme API métier. La politique OIDC de flux/session/compte est séparée de l’adaptateur HTTP borné d’échange de jetons. Avec un faux échange injecté, son service fonctionne avec imports CLI, gestionnaires HTTP et adaptateur sortant bloqués. Les contrôles existants d’isolation du service de tâches et du client installé restent actifs.

La composition du daemon possède authentification, configuration TLS, historique optionnel et cycle de conservation. La conservation s’arrête avant fermeture de l’historique. Les négociations TLS utilisent des workers bornés sans bloquer l’écoute. Les extensions optionnelles ne changent pas le stockage par défaut, n’imposent pas une connexion CLI interactive et n’ouvrent pas ncurses depuis cron.

Problèmes trouvés et corrigés pendant la validation :

Le job de reproductibilité installait setuptools 84 alors que le backend exige <81 ; il installe désormais des outils compatibles.
La réconciliation refusait un motif de basculement null légitime. Elle valide désormais le contrat réel des exports et rejette les enregistrements mal formés sans accès réseau.
La validation TLS stricte de Python 3.13 rejetait des extensions incomplètes de l’autorité de test. Les certificats incluent désormais usages et identifiants de clés ; la vérification reste active.
La première visite masquait le bouton SSO derrière un contrôle CSRF enregistré. La découverte précède désormais cette condition et le callback établit un document de même origine sans affaiblir les protections intersites.
Un lanceur détaché avec stdin fermé pouvait perdre le descripteur du répertoire d’observation pendant la redirection des flux standard. Ce descripteur reste désormais au-dessus de stderr, avec un vrai test de scénario détaché.
Le texte de l’état vide en lecture seule et les libellés des durées réconciliées ont été corrigés pendant la revue visuelle.

Réutilisation de Redis¶

Les connexions utilisent dwho.adapters.redis.DWhoAdapterRedis, inspecté au commit amont 861c61ac4038bb58308a2c87f3c73fcedffaf366. Auton fournit uniquement instantanés, conservation, propriété de l’espace et récupération. Il ne duplique pas l’adaptateur Redis et n’exige aucun changement de DWho. Délais de connexion/lecture, absence de rejeu, écritures protégées, propriétaire unique et perte de bail sont couverts. L’authentification reste sur SQLite, configurée indépendamment.

Migration et limites explicites¶

Toutes les nouveautés sont à activer explicitement sauf l’expiration pendant l’inactivité selon le TTL existant. Les jetons n’obtiennent pas cancel : émettez les bonnes portées. Ajouter un schéma restreint volontairement les arguments. Redis n’importe pas automatiquement l’historique SQLite. Séparez les deux stockages et gardez des sauvegardes lors d’un changement.

OIDC utilise des clés publiques RSA gérées par l’opérateur, une correspondance explicite sujet/compte local et des sessions mémoire bornées. Un redémarrage déconnecte les sessions SSO ; aucun refresh token, flux device/CLI, création automatique ou déconnexion globale du fournisseur n’est sous-entendu. La rotation des certificats/clés exige un redémarrage contrôlé. Le faux fournisseur local prouve le flux de protocole pris en charge, pas la compatibilité avec tous les fournisseurs d’identité.

Les scénarios détachés exigent un hôte de contrôle actif, sans reprise automatique après sa perte. Le bail Redis protège l’historique mais ne prouve pas l’arrêt d’une commande externe. Ces tests ne revendiquent ni résistance à la saturation ni absence de fuite sur longue durée.

Publication et livraison effectuées¶

La version 1.2.0 a livré ces fonctions rétrocompatibles et optionnelles.

[x] Choisir et incrémenter la version 1.2.0 ; les captures sont régénérées depuis la révision finale fixée par le site.
[x] Fusionner et publier les paquets et images via les contrôles de publication existants.
[x] Actualiser la révision source du site privé et vérifier après déploiement sa version générée, sa documentation et le manifeste partagé des captures.

Les métadonnées vérifiées du site indiquaient la version publiée 1.3.2 lors de cette réconciliation. Les métadonnées de publication et le manifeste partagé des captures constituent la preuve de livraison ; les captures candidates seules ne prouvent pas une publication. Aucun PNG figé n’est commité. Consultez la feuille de route actuelle et les notes de version pour les évolutions ultérieures. Le formulaire de contact reste hors périmètre ; le lien de courriel existant ne nécessite aucun service d’envoi de formulaire.

Version candidate des règles client (6 novembre 2026)¶

Implémenté pour revue : argpolicy dans Sonicprobe, permissions par catégorie d’entrée client, expressions régulières et choix, répétitions et nombre de valeurs, instantanés des envfiles validés, avertissements au démarrage et diagnostic hors ligne, ainsi que refus par défaut en 2.0. Voir le guide de migration utilisateur.

Ordre de livraison : publier Sonicprobe 0.3.64, utiliser cette dépendance du registre dans Auton 1.4.0 et 2.0.0rc2, puis vérifier les deux paquets, les images Docker et les notes de version immuables. Le site stable doit utiliser les sources de la 1.4.0 et présenter la 2.0.0rc2 comme une préversion distincte. La 2.0 stable exige encore une nouvelle validation de migration. Les métadonnées des registres et des déploiements attestent la publication ; une fusion seule ne suffit pas. Ce travail ne modifie pas le design de l’interface.