Catalogue des façades du harness

0. Périmètre, méthode et couverture

Ce chapitre catalogue le harness Synedre : les points d'entrée exécutables (scripts Python, scripts shell, hooks) qui orchestrent le travail des agents, centralisés autour d'une base unique. Il ne décrit pas le produit CodeMyShop, qui est multi-tenant : Synedre orchestre CodeMyShop, il n'en fait pas partie. La frontière est stricte : tout ce qui est générique vit dans le cœur de CodeMyShop, tout ce qui est spécifique à un client vit dans une surcouche dédiée, et le harness ne contient jamais de contenu métier en statique.

Chaque point d'entrée est recensé avec sa famille, son rôle en une ligne et son mode d'invocation type (cron, ligne de commande, skill, hook, bibliothèque, worker), afin qu'un ingénieur qui reprend le dépôt retrouve quel script fait quoi sans relire plusieurs centaines de fichiers. Les façades d'envoi d'email, de scan de pièces jointes et de déploiement sont déclarées « façade unique obligatoire » : aucun appel direct au transport sous-jacent.

Dernière régénération du miroir : le catalogue couvre désormais 948 scripts Python de premier niveau et 148 entrées d'outillage en ligne de commande. Les écarts détectés par le miroir de dérive documentaire sont de deux sortes : du code cité plus récent que la doc, et une soixantaine de références mortes déjà documentées comme telles (fichiers supprimés ou déplacés, annotés dans le chapitre et exclus du calcul de dérive).

• Courrier interne et copies : un canal unique Atlas → fondateur (boîte canonique, adresse de réponse dirigée vers Atlas, identifiant de message réel relu après envoi) et un module pur qui garantit une seule copie « à valider » par brouillon.
• Reprise PrestaShop 9 : quatre façades neuves (charte, audit de reprise, pose de module, rejeu des redirections), toutes limitées à la préproduction.
• DNS et hébergement : appel unique à l'API d'un hébergement mutualisé par session navigateur sans identifiant, comparaison de deux zones DNS avant bascule, provisionnement d'un espace privé sans secret affiché.
• Vigies : lecture paginée du blog pour la vigie du dictionnaire, ouverture mensuelle de l'audit SEO de chaque tenant, surveillance du reset nocturne de la démo.
• Diffusion : publieur navigateur pour un réseau d'articles longs (2 par mois au plus, après validation humaine) et correction d'un faux positif de l'anti-fuite.
• Hook : une garde bloquante qui impose de dire en clair au fondateur toute écriture sur la production d'un client avant qu'elle ait lieu.

Méthode d'extraction

Le recensement recoupe chaque fichier de premier niveau du dépôt d'outillage avec le texte du chapitre ; un fichier absent est lu (docstring et arguments) avant d'être catalogué. Les commits postérieurs à la dernière régénération sont relus pour réaligner les lignes existantes. Chaque référence à un fichier est vérifiée sur le disque ; une référence qui n'existe plus est annotée, jamais silencieusement supprimée.

Décompte couvert vs réel

Périmètre	Réel	Couverture
Scripts Python de premier niveau	948	tous catalogués ou classés « sans effet sur le catalogue »
Entrées d'outillage en ligne de commande	148	toutes cataloguées
Hooks recensés	deux jeux de réglages	un seul manque signalé, intégré dans cette passe

Légende « invocation »

Code	Signification
cron	lancé par le planificateur, souvent via un enrobage qui journalise et coupe les échecs répétés
CLI	appelé à la main en ligne de commande
skill	façade derrière un skill d'agent
hook	hook de l'outil d'agent (démarrage de session, soumission de prompt, avant/après outil, arrêt) ; deux jeux de hooks coexistent (§17)
lib	module importé, pas un point d'entrée autonome
worker	daemon ou boucle qui vide une file en base

1. Familles et flux d'ensemble

Les points d'entrée se répartissent en familles qui se répondent. Un email entrant est classé puis confié à l'orchestration ; celle-ci ouvre des chantiers ou lance un brainstorm ; l'exécution des agents alimente à son tour les audits, le blog et le SEO, la finance, les agents navigateur et le déploiement.

   email entrant ──► inbox / email  (relève, classement d'intention)
                         │
   hub, CLI      ──► atlas / orchestration (spawn, réaction, QA)
                         │                │
                  chantiers            brainstorm
                         │                │
                         ▼                ▼
              exécution des agents (appel multi-LLM, tâche réactive)
                         │
      ┌──────────┬───────┴────┬──────────┬──────────┐
      ▼          ▼            ▼          ▼          ▼
    audits   blog / SEO   finance   navigateur   déploiement

Un second plan, transversal, porte la mémoire et l'apprentissage (cicatrices, doctrine, rappel sémantique), la maintenance nocturne et les hooks qui encadrent chaque geste d'un agent.

2. Socle commun (bibliothèques et façades transverses)

Le socle regroupe les modules réutilisés par toutes les familles : accès à la base unique, façades d'envoi, résolution du tenant, journalisation des échecs, enrobage de cron, gardes de coût. Une trentaine de lignes les décrivent, chacune avec son contrat et son mode d'appel.

Registre des credentials

Le registre des accès tiers ne stocke jamais une valeur lisible dans un fichier suivi : un mot de passe est généré, chiffré et saisi dans le même processus, sous des invariants vérifiables (niveau « coffre seul »). Un empreintier à signature sert à un hook qui bloque toute saisie en clair ; une vigie contrôle les invariants avec un seuil d'écart de zéro ; un outil de migration déplace des métadonnées vers le registre avec sauvegarde et retour arrière. Un collecteur remonte, à intervalle régulier, les secrets que la fiche de flotte d'un serveur déclare.

Pont MCP

Un pont expose les outils SEO en lot, émet un jeton d'accès par tenant et sert un serveur d'outils partagé entre plusieurs harnais d'agent. Chaque émission de jeton est tracée et limitée au tenant demandeur.

Résolution du tenant, portée de session et cible d'écriture

Un résolveur unique lit la flotte pour trouver le tenant visé et échoue en mode fermé s'il est ambigu ; la préproduction d'un tenant se lit dans la flotte avant toute convention de nommage. Une garde de portée limite ce que peut écrire une tentacule : elle peut écrire au fondateur sans ouvrir la boîte entrante ni une copie tierce, et une session lancée sans tenant ne voit que l'équipe de son client.

3. Famille atlas / orchestration

Atlas est le point d'entrée qui reçoit une demande, la qualifie et la distribue. Une cinquantaine de façades gèrent le lancement de sessions, la réaction aux tâches, le dispatch des réponses et les arrêts propres. Les envois internes vers le fondateur passent tous par un canal unique : ils partent de la boîte canonique, avec une adresse de réponse qui ramène la réponse au poll d'Atlas, et rendent l'identifiant de message réel.

Pont ligne de commande → cockpit

Huit façades relient une session en ligne de commande au cockpit : synchronisation d'état, remontée d'événements, pose d'une commande que l'agent demande au fondateur de lancer. Depuis cette passe, une session peut poser une commande pour une autre ventouse (cible profil:#id ou profil:nom), l'écarter ou la reposer, et le cockpit cible le bouton sur la bonne session.

AgentRunner (multi-LLM)

Un exécuteur unique appelle les modèles de plusieurs fournisseurs sous un contrat commun (profil de harnais, coût, quota). Il joue ses tours sur le serveur du harnais natif quand il existe et rafraîchit le quota au passage.

Pool de tentacules

Le fan-out du cockpit lance, suit et ferme des sessions parallèles (une « ventouse » par bras de travail). Seize façades gèrent l'ouverture, le plafond, la reprise, la lecture des transcripts, la compaction et la relance automatique d'une session qui s'arrête.

Harnais Codex et meta-harnais portable

Un adaptateur pilote le serveur d'application de Codex avec un brief et une garde de contexte. Un générateur de meta-harnais produit, à partir d'une source unique en base, les configurations de trois harnais (hooks, agents, skills) et mesure la parité des gardes entre eux.

Cinquième harnais natif

Un cinquième harnais s'appuie sur une sortie résidentielle par la box navigateur, un relais HTTP CONNECT local et un client de quota. Un lanceur borné pose toujours la confiance de l'espace de travail et refuse le profil contributeur.

Liaison ventouse du cockpit In-Situ

Une liaison sortante en flux d'évènements et en requêtes signées relie une ventouse à un cockpit de démonstration, derrière un coupe-circuit payant. Le compte de démonstration pilote la démo par son profil ; la production lui reste fermée.

4. Famille chantiers (procédure en sept étapes)

Un chantier est l'unité de travail non testable ou irréversible. La procédure en sept étapes est imposée mécaniquement : lecture de la demande, audit des agents, lettre de mission, recrutement explicite, création atomique avec squelette, mise à jour post-squelette, garde de préparation. Une cinquantaine de façades l'outillent : création, tableau de bord, passage d'étape, clôture, rapport.

Orbite QA — auto-clôture

Trois façades vérifient la preuve de recette d'un chantier et le ferment automatiquement quand elle est suffisante ; faute de preuve, il reste ouvert.

Auto-optimisation post-chantier

Deux façades relisent un chantier terminé et en tirent des leçons proposées, jamais appliquées sans validation.

5. Famille brainstorm

Huit façades organisent la réflexion collective : ouverture d'un sujet, tour de table d'agents, synthèse et décision consignée. Le brainstorm produit une recommandation, pas une exécution ; le passage à l'acte repasse par la procédure de chantier ou par un run léger.

6. Famille audits / qualité / sécurité

La plus grosse famille (une centaine de lignes) : vigies en lecture seule qui mesurent la dérive entre le code, la base et la documentation. On y trouve les audits de schéma, de sécurité des routes, de conformité des skills, de couverture des tests, de sauvegardes et de l'arbre éditorial.

Compte système QA par tenant

Un registre associe à chaque tenant un compte de recette dédié. Une garde d'entrée et une vigie contrôlent son état, un outil pose le mot de passe sans boîte mail, et une preuve live vérifie qu'une ressource protégée répond bien par un refus. Le navigateur de recette dispose d'un profil par tenant et d'une liste d'autorisation par hôte exact.

Mesure iso-maquette

Dix façades comparent une maquette de design et son rendu, route par route : inventaire du fichier de maquette, capture, calcul des écarts de gouttière verticale, jugement et fiabilité du juge.

7. Famille mémoire / cicatrices / apprentissage

Soixante façades gèrent la mémoire de l'équipe : cicatrices qualifiées (incident, cause, règle, garde), doctrine, rappel sémantique par vecteurs et par index plein texte, compaction des transcripts, notes déposées en zone de transit. La règle du dépôt est que le « comment » vit dans la documentation et le « pourquoi » dans la mémoire.

Auto-réparation de la documentation

Une boucle nocturne de maintenance compare la documentation au code, signale les références mortes et les contenus plus anciens que le code qu'ils citent, puis propose une régénération gatée : le texte régénéré ne remplace l'ancien qu'après vérification des références. Dix-neuf façades portent les mesures, la file de réparation, le cadran de maintenance et les alertes.

Immunité adaptative

Quatre façades transforment un incident récurrent en garde mécanique : détection de la signature, proposition d'un hook ou d'un test, suivi de son efficacité.

Organe de délibération

Une façade structure une décision délicate en options pesées et trace l'arbitrage retenu.

8. Famille personas / agents (entretien)

Dix façades entretiennent le référentiel des agents : fiches, périmètre d'outils, rattachement aux skills, indicateurs d'usure et revue périodique. Le référentiel vit en base ; les fichiers d'agents des harnais en sont dérivés.

9. Famille inbox / email (client)

La relève des boîtes, le classement d'intention, la rédaction de brouillons et l'envoi passent par une façade unique : brouillon, montré avant envoi, validation explicite, envoi. Rien ne part à un client de la seule initiative d'un agent.

Deux modules neufs complètent la chaîne : un canal unique pour les messages d'Atlas vers le fondateur, et un module pur qui remplace les brouillons réécrits par une seule copie « à valider » (sans jamais toucher un brouillon déjà parti, programmé ou à jeton consommé). Un dossier client peut être produit en Markdown lisible par un humain comme par un modèle, par liste blanche et assainissement mécanique.

Prospection et note de mesure

Douze façades qualifient un prospect, datent chaque observation, rédigent un premier contact adossé à un fait vérifié et programment l'envoi sous sceau dans une fenêtre horaire. Une note de mesure multi-volets (vitesse, PHP, SEO, hygiène, rendez-vous) accompagne le contact.

Délégations bornées

Deux délégations écrites, activables seulement par le fondateur, autorisent des envois plafonnés par jour dans un périmètre strict, après un récapitulatif que le fondateur peut vetoer, avec un interrupteur de coupure.

Traitement par ventouse

Une veille lance un traitement par client, démarre sur validation à jeton, applique des règles de rédaction et des promesses du fil, rejoue à blanc avec deux juges et mesure le taux de brouillons validés tels quels. Chaque traitement est audité par une vue dédiée.

Messagerie pro et communauté

Une famille WhatsApp pro gère l'API officielle ; la communauté PrestaShop est lue et répondue sous gardes (charte, politesse, forme, anti-fuite), avec publication automatique sur les forums et validation humaine pour le reste.

Protection d'un majeur et permanence vocale

Une boîte dédiée classe le courrier d'un dossier de protection, extrait les faits et prépare un récapitulatif ; la permanence vocale pilote un frontal téléphonique et la téléphonie du fournisseur.

Emails système auto-adressés

Trois façades traitent les messages que le système s'adresse à lui-même, sous un modèle de confiance en mode fermé : un message non authentifié est journalisé, jamais déclenchant. Un récapitulatif de 7 h 30 regroupe les vigies au lieu de les envoyer une à une.

10. Famille blog / SEO / contenu

Quatre-vingt-cinq lignes plus une quinzaine de sous-familles : rédaction, relais, files, couvertures, maillage interne, indexation, Search Console, glossaire, traductions, netlinking, diffusion.

Mesh des sites

Trois pôles (SEO, performance, sécurité) mesurent chaque site de la flotte et alimentent une vue de synthèse.

Google Search Console

Dix-sept façades importent l'historique, rejouent les inspections, classent les écarts par cause, vérifient la propriété d'un site et raccordent les nouveaux domaines à l'import quotidien.

Traductions i18n

La règle est « on adapte au marché, on ne traduit pas » : un hook l'impose, la rédaction des fiches non francophones part d'un brief de marché en base, et des invariants de langue contrôlent les termes attestés du glossaire.

Autoblog

La rédaction, le relais, le semis et le réassort des files sont pilotés par vigies : jours de sujets restants, parution effective, visuels manquants. Le plafond de parution est fixé par semaine.

Autres sous-familles éditoriales

• FAQ des articles : rattrapage, régénération et purge des doublons.
• Couvertures : de catégorie (image par catégorie, texte alternatif par marché) et de blog (miniatures publiées).
• Forum de dialogues d'agents : fils publiés sur le site de la maison.
• Indexation par vagues, maillage interne réversible, glossaire i18n, netlinking supervisé par fraîcheur.
• Tenant pièces auto : treize façades de vigie technique et de catalogue.

Vigies de contenu

La vigie du dictionnaire relit les articles publiés par pages (lecture seule, curseur et budget de caractères). L'audit SEO mensuel ouvre, le premier du mois, une tâche par tenant enrôlé : le cron ne fait qu'ouvrir le travail, la rédaction est un travail de session et la dépense de données reste gatée.

Diffusion sociale automatique

Les posts viennent de sources fermées (article, astuce, livraison, réponse de forum déjà publiée) et passent des gardes mécaniques (fuites, marqueurs d'IA, longueur d'accroche, plafond par réseau et par jour, interrupteur). Un publieur navigateur gère un réseau d'articles longs, à deux par mois au plus, après validation humaine ; il refuse de tronquer silencieusement des étiquettes et relit l'adresse publiée. L'anti-fuite distingue désormais un identifiant d'URL d'un hash de commit.

11. Famille browser / agents navigateur

Quarante-quatre façades pilotent de vrais navigateurs depuis la mothership : navigation, saisie, capture, sessions persistantes, profils par usage. Des gardes limitent la fréquence des appels vers des sites tiers : on demande moins et plus lentement plutôt que de contourner un contrôle d'accès.

Box navigateur — provisioning et montages

Dix-sept façades gèrent l'installation de la box, un jukebox, une cinémathèque de sous-titres et le montage vidéo. Les profils hors box (poste personnel, PC Windows rattaché) disposent d'une vérification honnête : l'état n'est plus sondé sur un navigateur local qui n'existe pas.

Maquettes iso

Huit façades rapatrient des maquettes (DOM, capture, présentation, API, fills, commentaires) avec leur manifeste.

Hébergement mutualisé sans identifiant

Une façade passe un appel d'API de panneau d'hébergement par appel, dans la session déjà ouverte du navigateur ; aucun identifiant n'est vu. Les lectures sont libres ; toute écriture exige un drapeau explicite.

12. Famille bank / invoicing / finance

Vingt-trois façades gèrent le rapprochement bancaire, la facturation (émetteur toujours l'entité du fondateur, avec présentation avant envoi) et le suivi des coûts.

FinOps — poches, plafonds et appels

Trois façades suivent des poches budgétaires par usage, leurs plafonds et les appels qui les consomment. Les appels payants sont gatés par un coupe-circuit.

Dépenses fournisseurs

Quatre façades collectent les factures fournisseur par API, les archivent hors dépôt et les rattachent à une dépense ; une CLI les liste et les complète.

Foyer

La base du foyer est séparée de la base professionnelle : le personnel ne se mélange pas au pro.

Budget et débit d'un fournisseur de modèles

Trois façades calculent le budget restant d'un fournisseur de modèles, le débit autorisé et un battement de vie de l'autonomie.

13. Famille brand-watch / veille

Vingt-six façades de veille : concurrence, marché, opportunités et menaces.

Recherche de marque et de logo

Sept façades vérifient l'antériorité (offices de marques), la disponibilité des domaines et leur prix, les coûts de dépôt, puis produisent un livrable. Elles proposent, elles ne déposent ni n'achètent.

Vectorisation de logo

Une façade vectorise un logo bitmap en gardant la fidélité des courbes.

14. Famille deploy / ship / infra / backups

Soixante lignes pour la mise en ligne, l'infrastructure et les sauvegardes. Règle dure : la flotte décide si un site peut être expédié en production ; une cible interne passe par le déploiement dédié, jamais par l'expédition. De nuit, une preuve de recette est exigée, avec retour arrière automatique par un contrôle de santé et un interrupteur d'arrêt.

• Four de build : le build lourd est déporté sur un serveur tampon, avec un sémaphore à plusieurs emplacements (deux builds simultanés) et une isolation par tenant.
• Garde des secrets : un scan de sortie bloque par défaut un build qui embarque un secret ; un tenant dont les secrets ne vivaient que dans le build est refusé.
• Journal des livraisons : appelé en fin de chaque mise en ligne, il date la livraison sans dépendre d'un bouton.
• Médecin système : une liste fermée de soins, un journal des actes, et un code de sortie qui distingue un constat critique d'un plantage.

Sauvegardes et restauration

Douze façades sauvegardent les bases vers un stockage objet avec rétention (90 jours puis archive à un an), testent la restauration et surveillent la fraîcheur. Le site hébergé d'un client est sauvegardé chaque nuit hors de son serveur et surveillé comme les autres. Le coffre humain a ses propres sauvegarde et restauration d'essai, et une garde l'empêche d'être joignable depuis Internet.

Bascule de la mothership

Trois façades encadrent le déménagement de la mothership vers son nouveau serveur : préparation, bascule, vérification de parité.

Tenant historique

Six façades regroupent les opérations propres à un tenant d'import de pièces (mises à jour, contrôles, rapprochements).

Registrar, alias, comptes et droits

Neuf façades s'appuient sur un client d'API unique du registrar : DNS idempotent, alias, commande de noms de domaine en trois gestes (devis, bon de commande payé par un humain), ouverture de compte au nom du client sans mot de passe, demande d'élargissement des droits. S'y ajoutent la comparaison de deux zones DNS nom par nom avant une bascule (les adresses proxifiées sont remplacées par l'origine réelle ; code de sortie non nul en cas d'écart) et le provisionnement d'un espace privé sans secret affiché (rôle de base dédié, sauvegarde avant écriture, migrations rejouables).

15. Famille OSS sync / refactor / migrations

Trente-deux lignes plus une dizaine de sous-familles. La synchronisation du cœur open source est unidirectionnelle depuis le dépôt privé et refuse toute fuite de nom de client.

Connecteurs fournisseur

Huit façades importent le catalogue de deux grossistes (normalisation, images, prix) ; deux autres couvrent un connecteur de gestion de magasin.

Scraping et ETL client

Quatorze façades extraient, nettoient et chargent des données de clients dans le cadre de reprises autorisées.

Comparateur de prix concurrents

Quatre façades relèvent les prix publics de concurrents d'un tenant pour alimenter des décisions tarifaires.

Seeds de démonstration

Quatorze façades et scripts créent et remettent à zéro le jeu de démonstration. Une vigie surveille le reset nocturne : trois verdicts (ok, non armé, alerte) ; seul le premier est silencieux, et le cas « tâche posée mais jamais exécutée » est détecté.

Redirections 301 « fidèles »

Trois façades posent un lot de redirections permanentes qui préservent le produit exact visé.

Tenant catalogue pièces auto

Trente-sept façades : fiches par référence, compatibilités, contrôles qualité itératifs, import et rapprochement.

Variantes, fournisseurs et déclinaisons couleur

Cinq façades regroupent des variantes en déclinaisons ; deux gèrent un connecteur fournisseur ; trois créent des déclinaisons de couleur pour un rayon d'un tenant.

Reprise PrestaShop 9

Quatre façades neuves, toutes limitées à la préproduction :

Façade	Rôle	Invocation
Charte PS9	Dérive des couleurs du logo et les écrit, entre deux marqueurs, dans la feuille du thème enfant sous forme de variables Bootstrap ; la zone manuelle n'est jamais touchée.	skill
Audit de reprise	Inventaire des défauts que la recette des données ne cherche pas : case CGV vers une page supprimée, pied de page vers des pages disparues, consentement vers une politique inexistante, modules marketing jamais configurés. Lecture seule.	skill
Pose de module	Cherche d'abord les pièges connus de PrestaShop 9 (code retour non nul si bloquant), puis installe sur la préproduction seulement, avec cache vidé et preuve en base.	skill
Rejeu des redirections	Rejoue sur la nouvelle boutique les adresses que la Search Console a vues, trie les pertes. Lecture seule, n'écrit que son rapport.	skill

16. Famille monitoring obsolescence / tests harness

Trente-cinq lignes plus cinq sous-familles : surveillance d'obsolescence des dépendances, tests du harness, sondes de parité.

Atelier 3D et configurateur sur mesure

Quarante façades pilotent la chaîne 3D (modèle, rig, rendu, vérification de ressemblance) et un configurateur sur mesure.

Protection d'un majeur

Cinq façades complètent le traitement du courrier du dossier (recevabilité, démarches).

Gouvernance des automates

Quatre façades rapprochent la table du planificateur de la base et signalent les écarts (crons orphelins, documentation périmée).

Jukebox / karaoké

Quatre façades pilotent le lecteur de la télévision du foyer.

Vigies de supervision

Six vigies de supervision des automates, et une bascule vers une supervision SRE dédiée.

17. Hooks Claude Code recensés (deux fichiers de réglages)

Les hooks vivent dans deux fichiers distincts qui portent chacun un jeu différent ; il ne faut pas les confondre.

17.a — Hooks de façades Python et d'outillage

Ce jeu déclare les hooks de démarrage de session (remise à zéro du compteur de contexte, brief de session, injection de cicatrices), de soumission de prompt, d'avant-outil (garde d'écriture en production, garde de la façade email, injection de cicatrices avant Bash, édition, écriture et agent) et d'après-outil.

17.b — Hooks-wrappers shell

Ce second jeu, de plus de deux cents entrées, porte les gardes en shell et en Python : refus d'un vhost client sur la mothership, secrets en clair, contenu non adapté au marché, parité des harnais, synchronisation des fichiers d'agents, précommit. Une garde neuve, bloquante, intercepte toute écriture de fichier vers un serveur distant portant la production d'un client (ou un hôte inconnu de la flotte) : transfert FTP/SFTP avec écriture, copie vers un hôte, envoi par requête HTTP. Le geste doit être dit en clair au fondateur avant, avec sauvegarde et retour arrière annoncés ; une soupape explicite le consigne après son accord.

17.c — Gardes présentes mais non câblées

Vingt-sept gardes existent sur disque sans être câblées dans l'un des deux jeux (précommit, vérifications ponctuelles, contrôle du coffre humain). Elles sont recensées avec leur point de déclenchement réel.

18. Notes de fiabilité

Ce chapitre est régénéré à intervalle régulier à partir du code ; chaque régénération consigne ce qui a été vérifié et ce qui ne l'a pas été.

• Dernière régénération : douze façades Python et un hook cataloguées, douze lignes réalignées, une sous-famille ajoutée (reprise PrestaShop 9).
• Limites assumées : la cadence de deux nouvelles vigies (reset de démo, audit SEO mensuel) n'est pas vérifiée contre la planification réelle ; la ligne du four de build n'a pas été relue après l'ajout de ses emplacements multiples ; les références ligne à ligne des anciennes entrées ne sont pas toutes recalées.
• Anomalies relevées sans correction ici : docstrings ou commentaires de planification périmés, façades conçues pour tourner en cron mais sans ligne active, quelques scripts orphelins ou cassés. Elles sont listées dans le chapitre interne pour traitement par chantier.
• Références mortes : une soixantaine de chemins cités n'existent plus ; toutes sont annotées (supprimées, corbeille, historique) et aucune n'a été introduite dans cette passe.