aetherius 0.5.2__tar.gz → 0.5.4__tar.gz

{aetherius-0.5.2 → aetherius-0.5.4}/CHANGELOG.md

@@ -5,6 +5,147 @@ Toutes les évolutions notables du projet sont consignées ici. Le format s'insp
 [SemVer](https://semver.org/lang/fr/). Tant que la version reste en `0.x`, l'API publique peut encore
 évoluer entre deux versions mineures.
 
+## [0.5.4] - 2026-08-13
+
+Un second appendice à la Phase 3, ouvert par le même port réel que le premier : l'extraction d'Act I
+ne connaissait que le JSON et le HTML, si bien qu'une réponse **à lignes** — iCalendar, CSV,
+`text/plain` — était hors de portée d'un Blueprint. Elle gagne sa troisième et dernière forme,
+`from: "text"`, dans les deux moteurs. Une valeur d'énumération, et rien d'autre.
+
+### Ajouté
+- **Jalon 3-I — Extraire un corps de réponse en texte**
+  ([docs/acts/vector.md](docs/acts/vector.md#from-text--les-formats-à-lignes),
+  [docs/phase-3/3-i-extraction-texte.md](docs/phase-3/3-i-extraction-texte.md)). Le besoin vient de
+  [UKit](docs-ukit/README.md) : à peu près aucune université française n'expose un serveur de
+  planning interrogeable sans authentification, alors que presque toutes offrent un **export iCal**.
+  C'est la seule voie qui ne demande pas de porter un produit de planning par établissement.
+  - **`extract: { x: { from: "text" } }`** rend le corps décodé, tel quel. Pas de parseur, et pas de
+    `from: "regex"` : une seconde grammaire d'expressions régulières entre Python et JavaScript
+    finirait par diverger, et le filtrage d'un texte reste applicatif.
+  - **Le corps n'est jamais publié tout seul.** `http.request` continue de ne rendre que
+    `status_code` et `headers` : sans extraction nommée, la charge utile ne traîne ni dans les
+    journaux, ni dans les événements, ni dans la mémoire d'un run qui n'en a que faire. C'est
+    l'extraction qui dit **ce qu'on garde**.
+  - **Le décodage suit l'en-tête de réponse**, avec repli UTF-8 et remplacement des octets invalides
+    — un corps binaire ne lève pas : ce n'est pas au moteur de deviner qu'on s'est trompé de source.
+    Un BOM est conservé, comme le fait le codec Python.
+  - **La table d'encodages est bornée et partagée par les deux moteurs** (latin-1 **strict**, cp1252,
+    UTF-8 pour toute autre étiquette) plutôt que déléguée à leurs plateformes. C'est la décision
+    centrale du jalon : `TextDecoder` est absent de React Native et complet sous Node, donc la
+    solution paresseuse aurait mis la CI d'accord et le téléphone en désaccord — sur la première
+    source mal étiquetée, en production. Le moteur embarqué porte donc son décodeur UTF-8
+    (algorithme WHATWG, soit un `U+FFFD` par sous-partie maximale, ce que rend `errors="replace"` de
+    CPython) et sa table mono-octet, **sans dépendance ajoutée**.
+  - **Sur l'appareil, les octets ne sont lus que si un `from: "text"` est déclaré** : le driver
+    scanne le bloc `extract` avant d'envoyer la requête — lecture statique légitime, les specs
+    n'étant jamais rendues — et n'appelle `arrayBuffer()` que dans ce cas. Une requête sans
+    extraction texte emprunte exactement le chemin d'avant et ne paie pas le pont base64 de React
+    Native ; un hôte dont la réponse ne sait pas rendre ses octets obtient une erreur **typée qui le
+    nomme**, jamais un décodage UTF-8 tacite ni une erreur réseau trompeuse.
+  - **`path`, `where`, `fields`, `selector`, `selector_type`, `attr` et `multiple` sont refusés** avec
+    `from: "text"`, **à la validation** et par les deux moteurs : un Blueprint qui croit filtrer est
+    pire qu'un Blueprint qui échoue. La règle vit dans les deux validateurs sémantiques, pas dans la
+    couche de portabilité du moteur embarqué — elle appartient au contrat.
+  - **Corpus de conformance** : `run/18-text-body-and-charset` sert quatre routes (latin-1 bien
+    étiqueté, UTF-8 **mal** étiqueté — les deux moteurs doivent produire le *même* mojibake —,
+    `Content-Type` sans `charset`, corps vide qui rend `""` et non `null`), ce qui a demandé un champ
+    de route **`charset`** aux deux serveurs de fixtures ; `validation/37-text-extract-with-path`
+    fige le refus. Les tests unitaires ajoutent une table d'octets UTF-8 invalides dont les valeurs
+    attendues viennent de CPython et sont recopiées dans le test JavaScript : c'est ce qui garde les
+    deux décodeurs alignés sur les cas dégénérés qu'un serveur ne peut pas facilement servir.
+  - **Exemple exécutable zéro configuration** :
+    [`examples/vector/ical-planning-text`](examples/vector/ical-planning-text.blueprint.json)
+    (export iCal anonyme d'un vrai serveur ADE, entrées figées sur une plage passée dont le contenu
+    reste servi — donc reproductible sans attendre une rentrée), avec sa **contre-épreuve conçue pour
+    échouer**, [`ical-error-page-probe`](examples/mobile/ical-error-page-probe.blueprint.json) : le
+    même export sans paramètres répond 500 avec une page HTML, et la garde de forme doit mordre.
+  - **Vérifié sur iPhone** : `caracteres: 21461` et `80712` **identiques** au moteur Python, accents
+    compris, et la sonde conçue pour échouer échoue au même step avec le même message. C'est la seule
+    vérification qui pouvait couvrir le pont d'octets de React Native (blob → base64 → natif), qui
+    n'existe nulle part ailleurs.
+  - `contracts/blueprint.schema.json` **ne bouge pas** — le bloc `extract` y était déjà ouvert ; seule
+    l'aide du paramètre, dans le contrat **généré** `contracts/actions.json`, nomme désormais les
+    trois formes.
+
+### Corrigé
+- **Un rendez-vous d'approbation pouvait s'annoncer non expiré alors qu'il venait de l'être.** Sans
+  rapport avec le jalon, trouvé parce que la suite du moteur embarqué échouait une fois sur trois :
+  `expired` comparait l'horloge à l'échéance, or un `setTimeout` peut se déclencher une fraction de
+  milliseconde avant que `Date.now()` ne l'atteigne. L'attente rendait donc `null` — la décision
+  n'arrivera plus — pendant que `expired` répondait encore `false`, deux réponses contradictoires sur
+  le même rendez-vous. Le minuteur fait désormais foi en plus de l'horloge. Aucune décision ne
+  pouvait être appliquée à tort (`resolve` était déjà gardé par l'état « résolu »), mais une surface
+  qui lit `expired` pour cesser d'afficher sa demande pouvait la laisser à l'écran.
+
+## [0.5.3] - 2026-08-10
+
+Un correctif, pas un jalon : la Phase 3 reste close (3-A à 3-H). Une promesse du jalon 3-E — « une
+source injoignable dit qu'elle l'est » — ne tenait pas sur un appareil, et le port d'une application
+réelle l'a montré. Elle tient désormais **des deux côtés**, et trois gardes l'empêchent de repartir.
+
+### Corrigé
+- **Une source injoignable atteint `unavailable`, sur le moteur embarqué**
+  ([docs/embedded.md](docs/embedded.md#une-source-injoignable-atteint-unavailable-corrigé-en-053)).
+  Mesuré sur iPhone le 2026-08-09 en portant la session universitaire d'
+  [UKit](docs-ukit/README.md) : un `navigate` vers une adresse injoignable **réussissait**, et c'est
+  l'attente suivante qui échouait — en `blocked` avec le code du Blueprint, ou en `data`. Aucune
+  panne réseau de l'Act II n'ouvrait donc de bouton Réessayer, ce qui vidait de son sens le
+  paragraphe central du modèle d'erreur.
+  - **La cause n'était pas le câblage.** `react-native-webview` tire `onError` **puis** `onLoadEnd`
+    pour la *même* navigation en échec, dans le même tick. Le second effaçait le verdict, avançait
+    la génération et réinjectait l'agent — qui s'annonçait depuis la page d'erreur de la plateforme
+    comme depuis n'importe quel document. Deux erreurs, et il fallait les deux : un événement de fin
+    de chargement pris pour la **preuve** qu'un document s'est chargé, et une boucle d'attente qui
+    testait la génération **avant** le verdict alors que les deux sont vrais au même tour.
+  - **Deux défauts latents du même chemin**, trouvés en écrivant le correctif et qui mordaient
+    précisément sur le bouton Réessayer qu'il rend possible : le verdict n'était effacé que par le
+    signal de la vue, qui arrive après le premier tour de la boucle — une reprise échouait donc
+    instantanément en héritant d'un échec qu'elle n'avait pas rencontré ; et une reprise sur la même
+    URL demandait un `reload()`, que la plateforme ignore sur une vue dont la navigation provisoire
+    a échoué. `PageControl.load` exige désormais de charger **même si la vue affiche déjà cette
+    URL**, et le composant l'honore en recréant la vue.
+  - **Un chargement qui part et ne revient jamais est `unavailable`**, plus `engine` : à l'échéance,
+    un chargement que la vue a annoncé sans le terminer lève un `TimeoutError`. C'est le second
+    symptôme que la campagne d'origine avait observé sans l'élucider — un nom qui ne résout pas.
+  - **Le verdict reste borné à la navigation demandée** : `awaitReady` teste toujours la présence de
+    l'agent d'abord, parce qu'une navigation de fond qui échoue laisse le document courant intact et
+    qu'échouer là ferait régresser des runs qui marchent.
+- **Une source injoignable est une `NetworkError`, sur le moteur Python**
+  ([docs/acts/continuum.md](docs/acts/continuum.md#une-source-injoignable-est-une-networkerror)).
+  Le même angle mort, trouvé en corrigeant l'autre : `page.goto` vers une adresse injoignable levait
+  une `playwright.Error` brute, enveloppée en `RunError` — un bug du moteur, pour qui lit le
+  `Result`. `navigate`, `back`, `forward` et `reload` typent maintenant un échec de transport
+  (`net::ERR_*`, le code de Chromium, seul navigateur que cet Act lance). La détection est étroite
+  par choix : une page qui se ferme, un `frame` qui se détache ou un `TimeoutError` de Playwright
+  gardent leur chemin — une page lente n'est pas une page qu'on n'atteint pas.
+
+### Ajouté
+- **Un cas de conformance partagé** (`conformance/cases/run/17-unreachable-source.json`) : les deux
+  moteurs échouent **au step `navigate`**, et le step suivant ne démarre pas. C'est exactement la
+  séquence qui divergeait, donc c'est la bonne garde anti-dérive.
+- **Le double jsdom émet `onLoadFailed` avant `onDocumentLoaded`**, comme la plateforme. C'est la
+  leçon de méthode du correctif : le corpus jouait ce chemin depuis deux jalons et le déclarait vert
+  parce que le double ne reproduisait que la moitié de la séquence — celle qui ne contient pas le
+  bug. Un double qui n'émet pas les signaux d'une plateforme ne peut rien garder.
+- **Une sonde de banc, `examples/mobile/unreachable-probe.blueprint.json`**, conçue pour échouer :
+  déterministe, hors ligne, elle **remplace le passage en mode avion** du parcours de vérification —
+  rien à changer sur le téléphone.
+
+### Connu
+- **Un échec de chargement que la vue ne rapporte pas reste invisible**, et c'est la première passe
+  sur appareil qui l'a montré : le correctif était en place, gardé, et la sonde rendait quand même
+  `PAGE_ABSENTE`. `react-native-webview` filtre `WebKitErrorDomain` **101** (« cannot show URL »)
+  avant d'appeler `onError`, or c'est ce que WebKit rend pour un **port bloqué** — et la sonde visait
+  le port 1. La vue savait, la bibliothèque a avalé, l'hôte est resté aveugle. Le signe avant-coureur
+  était sous les yeux : côté Python la même adresse donnait `net::ERR_UNSAFE_PORT`, pas
+  `ERR_CONNECTION_REFUSED`.
+  - **Règle de sondage : viser un port qui _refuse_ (4), pas un port _bloqué_ (1, 7, 9 …).** La
+    sonde, le cas de conformance et le test navigateur l'appliquent.
+  - Le périmètre restant n'est pas celui de la production : un portail en panne rend
+    `NSURLErrorDomain` (-1001, -1004, -1009), que la bibliothèque laisse passer. Ce qu'elle avale —
+    port bloqué, schéma non supporté — désigne des Blueprints à corriger, pas des services à
+    réessayer.
+
 ## [0.5.2] - 2026-08-07
 
 Un appendice à la Phase 3, ouvert par un port réel : la livraison distante sait désormais
@@ -965,7 +1106,9 @@ Première release publique. Elle clôt la **Phase 1** : le socle d'Aetherius, ut
 - SemVer `0.x` : l'API peut évoluer pendant le durcissement de la Phase 1.
 - La **Phase 2** ajoutera Act III (Oracle, vision) et Act IV (Phantom, agent autonome).
 
-[Non publié]: https://github.com/kln-mltre/Aetherius/compare/v0.5.2...HEAD
+[Non publié]: https://github.com/kln-mltre/Aetherius/compare/v0.5.3...HEAD
+[0.5.4]: https://github.com/kln-mltre/Aetherius/releases/tag/v0.5.4
+[0.5.3]: https://github.com/kln-mltre/Aetherius/releases/tag/v0.5.3
 [0.5.2]: https://github.com/kln-mltre/Aetherius/releases/tag/v0.5.2
 [0.5.1]: https://github.com/kln-mltre/Aetherius/releases/tag/v0.5.1
 [0.5.0]: https://github.com/kln-mltre/Aetherius/releases/tag/v0.5.0

{aetherius-0.5.2 → aetherius-0.5.4}/PKG-INFO

@@ -1,6 +1,6 @@
-Metadata-Version: 2.4
+Metadata-Version: 2.5
 Name: aetherius
-Version: 0.5.2
+Version: 0.5.4
 Summary: A fixed, robust web-bot engine driven by declarative instruction files (Blueprints).
 Project-URL: Repository, https://github.com/kln-mltre/Aetherius
 Author: Kylian Malartre
@@ -130,8 +130,9 @@ plus les dépendances sont lourdes (installées à la demande via des *extras*).
 ### Act I — Vector
 Client HTTP robuste : requêtes GET/POST, encodage form/JSON, en-têtes, retries avec backoff,
 pagination, stratégies d'authentification (cookie, bearer, basic, form-login type CAS), extraction
-déclarative (JSONPath pour le JSON, CSS/XPath pour le HTML). Remplace les services `axios` écrits à
-la main ; les constantes magiques disséminées deviennent des `inputs` typés et documentés.
+déclarative (JSONPath pour le JSON, CSS/XPath pour le HTML, le corps décodé pour les formats à
+lignes type iCalendar). Remplace les services `axios` écrits à la main ; les constantes magiques
+disséminées deviennent des `inputs` typés et documentés.
 
 ### Act II — Continuum
 Automatisation d'un vrai navigateur (Playwright) qui suit le Blueprint à la lettre : navigation,
@@ -807,7 +808,8 @@ binaire : un **registre** le résout entre un socle embarqué et une surcouche d
 **un site qui change se répare sans republier sur les stores**. Le jalon 3-G clôt la phase en
 **portant un cas d'usage mobile réel** — quatre API tierces et un parcours authentifiant complet —
 et en livrant le guide de migration ; le jalon 3-H, appendice ouvert par ce port, laisse le même
-manifeste **ajouter** un Blueprint sous un préfixe réservé. Référence d'usage :
+manifeste **ajouter** un Blueprint sous un préfixe réservé, et le jalon 3-I, ouvert par le même,
+rend atteignables les réponses qui ne sont ni JSON ni HTML (`from: "text"` — iCalendar, CSV). Référence d'usage :
 [docs/embedded.md](docs/embedded.md).
 
 - [x] **3-A** — Socle TypeScript & parité : le moteur embarqué **charge, valide et refuse** un
@@ -1008,8 +1010,47 @@ manifeste **ajouter** un Blueprint sous un préfixe réservé. Référence d'usa
   [docs/embedded.md](docs/embedded.md#étendre--les-noms-réservés),
   [docs/phase-3/3-h-portails.md](docs/phase-3/3-h-portails.md).
 
-**Phase 3 terminée (A–H).** Le même Blueprint tourne sur une machine et sur un téléphone, se corrige
-et s'ajoute à distance, et un cas d'usage réel le prouve.
+- [x] **3-I** — **Extraire un corps de réponse en texte.** Second appendice, et la même origine que le
+  premier : un port réel a buté sur une limite du contrat. L'extraction d'Act I ne connaissait que
+  `json` et `html`, et `http.request` publie `status_code` et `headers` mais **jamais le corps** — une
+  réponse qui n'est ni l'un ni l'autre était donc hors de portée d'un Blueprint. C'est le cas de tous
+  les formats à lignes, dont **iCalendar**, et le besoin est concret : à peu près aucune université
+  française n'expose un serveur de planning interrogeable sans authentification, alors que presque
+  toutes offrent un lien d'abonnement. Le jalon ajoute **une valeur d'énumération**, `from: "text"`, et
+  rien d'autre — pas de parseur, pas de `regex` (deux moteurs, un contrat : ce qui n'est pas identique
+  par construction finit par diverger), et **aucune sortie de step ne grossit** : c'est l'extraction
+  nommée qui dit ce qu'on garde, un corps ne traîne pas dans les journaux de ceux qui n'en veulent pas.
+  Le point qui décidait de tout était le **décodage**, et il a été tranché à l'inverse de la facilité :
+  plutôt que chaque moteur délègue à sa plateforme, les deux portent la **même table d'encodages
+  bornée** (latin-1 strict, cp1252, UTF-8 pour tout le reste) et le moteur embarqué écrit ses propres
+  décodeurs — `TextDecoder` est absent de React Native et complet sous Node, s'en servir aurait mis la
+  CI d'accord et le téléphone en désaccord, sur la première source mal étiquetée. Sur l'appareil, les
+  octets ne sont lus (`arrayBuffer`, donc le pont base64 de React Native) **que** si un `from: "text"`
+  est déclaré : une requête qui n'en veut pas emprunte exactement le chemin d'avant. Les clés des
+  autres dialectes (`path`, `where`, `fields`, `selector`, …) sont **refusées à la validation** par les
+  deux moteurs — un Blueprint qui croit filtrer est pire qu'un Blueprint qui échoue. Exemple exécutable
+  zéro configuration : [`examples/vector/ical-planning-text`](examples/vector/ical-planning-text.blueprint.json)
+  (export iCal anonyme d'un vrai serveur ADE), avec sa contre-épreuve conçue pour échouer — la page
+  d'erreur du même serveur, qui ne doit **pas** passer pour un calendrier vide.
+  [docs/acts/vector.md](docs/acts/vector.md#from-text--les-formats-à-lignes),
+  [docs/phase-3/3-i-extraction-texte.md](docs/phase-3/3-i-extraction-texte.md).
+
+**Phase 3 terminée (A–I).** Le même Blueprint tourne sur une machine et sur un téléphone, se corrige
+et s'ajoute à distance, et un cas d'usage réel le prouve — et continue de désigner ce qui manque.
+
+> **Correctif 0.5.3 — une source injoignable atteint enfin `unavailable`.** La phase reste close ;
+> ceci n'ouvre pas de jalon. Le port d'UKit a trouvé sur iPhone que le signal d'échec de chargement
+> d'une WebView, câblé depuis le jalon 3-E, n'était **jamais lu** : la plateforme tire un événement
+> de fin de chargement pour une navigation en échec, l'agent s'installait sur sa page d'erreur, et la
+> navigation passait pour réussie. Aucune panne réseau de l'Act II n'ouvrait donc de bouton
+> Réessayer. Le correctif tient en deux règles — un événement de chargement n'efface pas un verdict
+> d'échec, et le verdict se lit **avant** la génération — plus deux défauts latents du même chemin
+> (une reprise condamnée par l'échec précédent, un `reload()` sur une vue sans document). Le moteur
+> **Python** avait le même angle mort et le corrige aussi : `navigate` type un échec de transport en
+> `NetworkError`. Trois gardes, dont un cas de conformance partagé, et un double jsdom qui reproduit
+> désormais la séquence de la plateforme — c'est son silence qui avait laissé passer le défaut deux
+> jalons durant. [docs/embedded.md](docs/embedded.md#une-source-injoignable-atteint-unavailable-corrigé-en-053),
+> [docs/acts/continuum.md](docs/acts/continuum.md#une-source-injoignable-est-une-networkerror).
 
 ## Sources de référence
 

{aetherius-0.5.2 → aetherius-0.5.4}/README.md

@@ -57,8 +57,9 @@ plus les dépendances sont lourdes (installées à la demande via des *extras*).
 ### Act I — Vector
 Client HTTP robuste : requêtes GET/POST, encodage form/JSON, en-têtes, retries avec backoff,
 pagination, stratégies d'authentification (cookie, bearer, basic, form-login type CAS), extraction
-déclarative (JSONPath pour le JSON, CSS/XPath pour le HTML). Remplace les services `axios` écrits à
-la main ; les constantes magiques disséminées deviennent des `inputs` typés et documentés.
+déclarative (JSONPath pour le JSON, CSS/XPath pour le HTML, le corps décodé pour les formats à
+lignes type iCalendar). Remplace les services `axios` écrits à la main ; les constantes magiques
+disséminées deviennent des `inputs` typés et documentés.
 
 ### Act II — Continuum
 Automatisation d'un vrai navigateur (Playwright) qui suit le Blueprint à la lettre : navigation,
@@ -734,7 +735,8 @@ binaire : un **registre** le résout entre un socle embarqué et une surcouche d
 **un site qui change se répare sans republier sur les stores**. Le jalon 3-G clôt la phase en
 **portant un cas d'usage mobile réel** — quatre API tierces et un parcours authentifiant complet —
 et en livrant le guide de migration ; le jalon 3-H, appendice ouvert par ce port, laisse le même
-manifeste **ajouter** un Blueprint sous un préfixe réservé. Référence d'usage :
+manifeste **ajouter** un Blueprint sous un préfixe réservé, et le jalon 3-I, ouvert par le même,
+rend atteignables les réponses qui ne sont ni JSON ni HTML (`from: "text"` — iCalendar, CSV). Référence d'usage :
 [docs/embedded.md](docs/embedded.md).
 
 - [x] **3-A** — Socle TypeScript & parité : le moteur embarqué **charge, valide et refuse** un
@@ -935,8 +937,47 @@ manifeste **ajouter** un Blueprint sous un préfixe réservé. Référence d'usa
   [docs/embedded.md](docs/embedded.md#étendre--les-noms-réservés),
   [docs/phase-3/3-h-portails.md](docs/phase-3/3-h-portails.md).
 
-**Phase 3 terminée (A–H).** Le même Blueprint tourne sur une machine et sur un téléphone, se corrige
-et s'ajoute à distance, et un cas d'usage réel le prouve.
+- [x] **3-I** — **Extraire un corps de réponse en texte.** Second appendice, et la même origine que le
+  premier : un port réel a buté sur une limite du contrat. L'extraction d'Act I ne connaissait que
+  `json` et `html`, et `http.request` publie `status_code` et `headers` mais **jamais le corps** — une
+  réponse qui n'est ni l'un ni l'autre était donc hors de portée d'un Blueprint. C'est le cas de tous
+  les formats à lignes, dont **iCalendar**, et le besoin est concret : à peu près aucune université
+  française n'expose un serveur de planning interrogeable sans authentification, alors que presque
+  toutes offrent un lien d'abonnement. Le jalon ajoute **une valeur d'énumération**, `from: "text"`, et
+  rien d'autre — pas de parseur, pas de `regex` (deux moteurs, un contrat : ce qui n'est pas identique
+  par construction finit par diverger), et **aucune sortie de step ne grossit** : c'est l'extraction
+  nommée qui dit ce qu'on garde, un corps ne traîne pas dans les journaux de ceux qui n'en veulent pas.
+  Le point qui décidait de tout était le **décodage**, et il a été tranché à l'inverse de la facilité :
+  plutôt que chaque moteur délègue à sa plateforme, les deux portent la **même table d'encodages
+  bornée** (latin-1 strict, cp1252, UTF-8 pour tout le reste) et le moteur embarqué écrit ses propres
+  décodeurs — `TextDecoder` est absent de React Native et complet sous Node, s'en servir aurait mis la
+  CI d'accord et le téléphone en désaccord, sur la première source mal étiquetée. Sur l'appareil, les
+  octets ne sont lus (`arrayBuffer`, donc le pont base64 de React Native) **que** si un `from: "text"`
+  est déclaré : une requête qui n'en veut pas emprunte exactement le chemin d'avant. Les clés des
+  autres dialectes (`path`, `where`, `fields`, `selector`, …) sont **refusées à la validation** par les
+  deux moteurs — un Blueprint qui croit filtrer est pire qu'un Blueprint qui échoue. Exemple exécutable
+  zéro configuration : [`examples/vector/ical-planning-text`](examples/vector/ical-planning-text.blueprint.json)
+  (export iCal anonyme d'un vrai serveur ADE), avec sa contre-épreuve conçue pour échouer — la page
+  d'erreur du même serveur, qui ne doit **pas** passer pour un calendrier vide.
+  [docs/acts/vector.md](docs/acts/vector.md#from-text--les-formats-à-lignes),
+  [docs/phase-3/3-i-extraction-texte.md](docs/phase-3/3-i-extraction-texte.md).
+
+**Phase 3 terminée (A–I).** Le même Blueprint tourne sur une machine et sur un téléphone, se corrige
+et s'ajoute à distance, et un cas d'usage réel le prouve — et continue de désigner ce qui manque.
+
+> **Correctif 0.5.3 — une source injoignable atteint enfin `unavailable`.** La phase reste close ;
+> ceci n'ouvre pas de jalon. Le port d'UKit a trouvé sur iPhone que le signal d'échec de chargement
+> d'une WebView, câblé depuis le jalon 3-E, n'était **jamais lu** : la plateforme tire un événement
+> de fin de chargement pour une navigation en échec, l'agent s'installait sur sa page d'erreur, et la
+> navigation passait pour réussie. Aucune panne réseau de l'Act II n'ouvrait donc de bouton
+> Réessayer. Le correctif tient en deux règles — un événement de chargement n'efface pas un verdict
+> d'échec, et le verdict se lit **avant** la génération — plus deux défauts latents du même chemin
+> (une reprise condamnée par l'échec précédent, un `reload()` sur une vue sans document). Le moteur
+> **Python** avait le même angle mort et le corrige aussi : `navigate` type un échec de transport en
+> `NetworkError`. Trois gardes, dont un cas de conformance partagé, et un double jsdom qui reproduit
+> désormais la séquence de la plateforme — c'est son silence qui avait laissé passer le défaut deux
+> jalons durant. [docs/embedded.md](docs/embedded.md#une-source-injoignable-atteint-unavailable-corrigé-en-053),
+> [docs/acts/continuum.md](docs/acts/continuum.md#une-source-injoignable-est-une-networkerror).
 
 ## Sources de référence
 

{aetherius-0.5.2 → aetherius-0.5.4}/conformance/README.md

@@ -148,6 +148,7 @@ le reste.
 | `status` | Code de statut (200 par défaut). |
 | `headers` | En-têtes de réponse (un `Set-Cookie`, un `Location`, …). |
 | `body` | Corps littéral ; `Content-Type: text/plain` par défaut. |
+| `charset` | Encodage des octets de `body` : `utf-8` (défaut) ou `iso-8859-1`. Une étiquette inconnue **fait échouer le harnais** au lieu de retomber sur UTF-8 — un cas qui servirait silencieusement de l'UTF-8 passerait en ne prouvant rien. |
 | `json` | Corps sérialisé en JSON compact ; `Content-Type: application/json` par défaut. |
 | `html` | Corps littéral servi en `text/html` — ce qu'un navigateur exige pour parser un document au lieu d'en montrer la source. |
 | `echo` | Répond par une description JSON de la requête reçue : `method`, `path`, `query`, `body`, `headers`. |
@@ -156,6 +157,11 @@ le reste.
 query ou un en-tête, donc ce sont les deux moteurs qui sont comparés — le harnais n'a aucune idée de
 la façon dont un formulaire devrait être encodé, et c'est bien ainsi.
 
+`charset`, lui, sert la seule question qu'un corpus en JSON ne peut pas poser autrement : le corps
+qui part sur le réseau n'est plus celui qu'on lit dans le fichier de cas. C'est ce qui permet de
+servir une réponse **mal étiquetée** — des octets UTF-8 annoncés en `iso-8859-1` — et d'exiger des
+deux moteurs le **même** mojibake, plutôt que de faire confiance à chacun pour deviner.
+
 La valeur comparée est un **résumé normalisé** du run. Les identifiants de run et les durées en sont
 absents : ils diffèrent par nature, et les comparer rendrait chaque cas instable.
 

aetherius-0.5.4/conformance/cases/run/17-unreachable-source.json

@@ -0,0 +1,56 @@
+{
+  "name": "run-continuum-unreachable-source",
+  "kind": "run",
+  "requires": "browser",
+  "description": "Une source injoignable arrete le run AU step navigate, sur les deux moteurs. Le port 4 est privilegie (rien ne peut s'y lier sans root, et l'OS ne l'attribue jamais en port ephemere) et n'est sur aucune liste de ports bloques : le refus est un VRAI refus de connexion, immediat, sans serveur de fixtures. Un port bloque par politique (1, 7, 9…) donnerait une erreur d'une autre nature — voir docs/embedded.md. Le cas fige la sequence, qui est exactement ce qui divergeait : le moteur embarque declarait la navigation reussie, et l'echec arrivait au step SUIVANT avec le nom que le Blueprint lui avait donne. Une application n'avait alors aucun moyen de distinguer une panne reseau d'une page qui a change.",
+  "server": {},
+  "blueprint": {
+    "aetherius": "1.0",
+    "name": "conformance.continuum.unreachable",
+    "act": "continuum",
+    "options": { "timeout_ms": 8000 },
+    "steps": [
+      { "id": "nav", "action": "navigate", "url": "http://127.0.0.1:4/" },
+      {
+        "id": "jamais",
+        "action": "wait_for",
+        "selector": "#absent",
+        "timeout_ms": 500,
+        "on_timeout": "fail:PAGE_ABSENTE"
+      }
+    ],
+    "outputs": { "url": "{{ steps.nav.url }}" }
+  },
+  "expect": {
+    "python": {
+      "outcome": "rendered",
+      "message_contains": ["the source is unreachable", "127.0.0.1:4"],
+      "value": {
+        "status": "failed",
+        "outputs": {},
+        "steps": [{ "step_id": "nav", "action": "navigate", "status": "failed" }],
+        "events": [
+          { "type": "progress", "step_id": null },
+          { "type": "step_started", "step_id": "nav" },
+          { "type": "error", "step_id": "nav" },
+          { "type": "done", "step_id": null }
+        ]
+      }
+    },
+    "embedded": {
+      "outcome": "rendered",
+      "message_contains": ["could not load", "127.0.0.1:4"],
+      "value": {
+        "status": "failed",
+        "outputs": {},
+        "steps": [{ "step_id": "nav", "action": "navigate", "status": "failed" }],
+        "events": [
+          { "type": "progress", "step_id": null },
+          { "type": "step_started", "step_id": "nav" },
+          { "type": "error", "step_id": "nav" },
+          { "type": "done", "step_id": null }
+        ]
+      }
+    }
+  }
+}

aetherius-0.5.4/conformance/cases/run/18-text-body-and-charset.json

@@ -0,0 +1,140 @@
+{
+  "name": "run-text-body-and-charset",
+  "kind": "run",
+  "description": "L'extraction from: 'text' rend le corps decode, et le decodage suit l'en-tete de reponse. Le cas qui prouve que les deux moteurs decodent pareil : un corps latin-1 bien etiquete, un corps UTF-8 mal etiquete (le mojibake doit etre le meme des deux cotes, pas 'corrige' par l'un d'eux), un Content-Type sans charset (UTF-8 par defaut) et un corps vide (chaine vide, pas null). Cote embarque, la lecture passe par arrayBuffer plutot que par text().",
+  "server": {
+    "GET /latin1": {
+      "headers": { "Content-Type": "text/csv; charset=ISO-8859-1" },
+      "charset": "iso-8859-1",
+      "body": "Prénom;Ville\nZoé;Bègles\n"
+    },
+    "GET /mislabelled": {
+      "headers": { "Content-Type": "text/csv; charset=iso-8859-1" },
+      "body": "Prénom;Zoé"
+    },
+    "GET /no-charset": {
+      "headers": { "Content-Type": "text/calendar" },
+      "body": "BEGIN:VCALENDAR\r\nSUMMARY:Noël\r\nEND:VCALENDAR\r\n"
+    },
+    "GET /empty": {
+      "headers": { "Content-Type": "text/plain" },
+      "body": ""
+    }
+  },
+  "blueprint": {
+    "aetherius": "1.0",
+    "name": "conformance.vector.text",
+    "act": "vector",
+    "inputs": { "base_url": { "type": "string", "required": true } },
+    "steps": [
+      {
+        "id": "latin1",
+        "action": "http.request",
+        "url": "{{ inputs.base_url }}/latin1",
+        "expect": { "status": 200 },
+        "extract": { "raw": { "from": "text" } }
+      },
+      {
+        "id": "mislabelled",
+        "action": "http.request",
+        "url": "{{ inputs.base_url }}/mislabelled",
+        "extract": { "raw": { "from": "text" } }
+      },
+      {
+        "id": "plain",
+        "action": "http.request",
+        "url": "{{ inputs.base_url }}/no-charset",
+        "extract": { "raw": { "from": "text" } }
+      },
+      {
+        "id": "empty",
+        "action": "http.request",
+        "url": "{{ inputs.base_url }}/empty",
+        "extract": { "raw": { "from": "text" } }
+      },
+      {
+        "id": "guard",
+        "action": "assert",
+        "condition": "{{ 'BEGIN:VCALENDAR' in steps.plain.raw }}",
+        "message": "ICAL_SHAPE"
+      }
+    ],
+    "outputs": {
+      "latin1": "{{ steps.latin1.raw }}",
+      "mislabelled": "{{ steps.mislabelled.raw }}",
+      "plain": "{{ steps.plain.raw }}",
+      "empty": "{{ steps.empty.raw }}",
+      "taille": "{{ steps.plain.raw | length }}"
+    }
+  },
+  "expect": {
+    "python": {
+      "outcome": "rendered",
+      "value": {
+        "status": "success",
+        "outputs": {
+          "latin1": "Prénom;Ville\nZoé;Bègles\n",
+          "mislabelled": "Prénom;Zoé",
+          "plain": "BEGIN:VCALENDAR\r\nSUMMARY:Noël\r\nEND:VCALENDAR\r\n",
+          "empty": "",
+          "taille": 46
+        },
+        "steps": [
+          { "step_id": "latin1", "action": "http.request", "status": "success" },
+          { "step_id": "mislabelled", "action": "http.request", "status": "success" },
+          { "step_id": "plain", "action": "http.request", "status": "success" },
+          { "step_id": "empty", "action": "http.request", "status": "success" },
+          { "step_id": "guard", "action": "assert", "status": "success" }
+        ],
+        "events": [
+          { "type": "progress", "step_id": null },
+          { "type": "step_started", "step_id": "latin1" },
+          { "type": "step_finished", "step_id": "latin1" },
+          { "type": "step_started", "step_id": "mislabelled" },
+          { "type": "step_finished", "step_id": "mislabelled" },
+          { "type": "step_started", "step_id": "plain" },
+          { "type": "step_finished", "step_id": "plain" },
+          { "type": "step_started", "step_id": "empty" },
+          { "type": "step_finished", "step_id": "empty" },
+          { "type": "step_started", "step_id": "guard" },
+          { "type": "step_finished", "step_id": "guard" },
+          { "type": "done", "step_id": null }
+        ]
+      }
+    },
+    "embedded": {
+      "outcome": "rendered",
+      "value": {
+        "status": "success",
+        "outputs": {
+          "latin1": "Prénom;Ville\nZoé;Bègles\n",
+          "mislabelled": "Prénom;Zoé",
+          "plain": "BEGIN:VCALENDAR\r\nSUMMARY:Noël\r\nEND:VCALENDAR\r\n",
+          "empty": "",
+          "taille": 46
+        },
+        "steps": [
+          { "step_id": "latin1", "action": "http.request", "status": "success" },
+          { "step_id": "mislabelled", "action": "http.request", "status": "success" },
+          { "step_id": "plain", "action": "http.request", "status": "success" },
+          { "step_id": "empty", "action": "http.request", "status": "success" },
+          { "step_id": "guard", "action": "assert", "status": "success" }
+        ],
+        "events": [
+          { "type": "progress", "step_id": null },
+          { "type": "step_started", "step_id": "latin1" },
+          { "type": "step_finished", "step_id": "latin1" },
+          { "type": "step_started", "step_id": "mislabelled" },
+          { "type": "step_finished", "step_id": "mislabelled" },
+          { "type": "step_started", "step_id": "plain" },
+          { "type": "step_finished", "step_id": "plain" },
+          { "type": "step_started", "step_id": "empty" },
+          { "type": "step_finished", "step_id": "empty" },
+          { "type": "step_started", "step_id": "guard" },
+          { "type": "step_finished", "step_id": "guard" },
+          { "type": "done", "step_id": null }
+        ]
+      }
+    }
+  }
+}

aetherius-0.5.4/conformance/cases/validation/37-text-extract-with-path.json

@@ -0,0 +1,29 @@
+{
+  "name": "text-extract-with-path",
+  "description": "from: 'text' rend le corps entier : un 'path' (comme un 'where', un 'selector' ou un 'fields') n'y selectionne rien. Le refuser evite un Blueprint qui croit filtrer et ne filtre pas. C'est une regle du contrat, pas d'un moteur — les deux refusent, a la validation, avant que la requete ne parte.",
+  "blueprint": {
+    "aetherius": "1.0",
+    "name": "conformance.extract.text.path",
+    "act": "vector",
+    "steps": [
+      {
+        "id": "cal",
+        "action": "http.request",
+        "url": "https://example.test/calendar.ics",
+        "extract": { "ics": { "from": "text", "path": "$" } }
+      }
+    ]
+  },
+  "expect": {
+    "python": {
+      "outcome": "rejected",
+      "error": "BlueprintValidationError",
+      "message_contains": ["'ics'", "from='text'", "'path'", "at steps[0].extract.ics"]
+    },
+    "embedded": {
+      "outcome": "rejected",
+      "error": "BlueprintValidationError",
+      "message_contains": ["'ics'", "from='text'", "'path'", "at steps[0].extract.ics"]
+    }
+  }
+}

{aetherius-0.5.2 → aetherius-0.5.4}/contracts/actions.json

@@ -332,7 +332,7 @@
           "kind": "object",
           "required": false,
           "default": null,
-          "help": "Named JSONPath/CSS extractions from the response.",
+          "help": "Named extractions from the response: from='json' (JSONPath), from='html' (CSS/XPath) or from='text' (the decoded body).",
           "placeholder": "{\"items\": {\"from\": \"json\", \"path\": \"$[*]\"}}"
         }
       ]