Un prompt peut-il remplacer Airmail ?

Construis un client email desktop dont la fonctionnalité déterminante est que chaque action est scriptable par l’utilisateur.

Compte : un seul compte IMAP et SMTP, identifiants dans le trousseau du système, authentification par mot de passe et par OAuth toutes deux prises en charge.

Synchro : IMAP incrémental avec suivi d’UIDVALIDITY et d’UIDNEXT, résumable après une connexion coupée, en-têtes et corps indexés dans SQLite avec recherche plein texte. Un statut de synchro visible par dossier.

Lecture : threading basé sur les standards via References et In-Reply-To, dossiers et étiquettes, archivage, brouillons sauvegardés côté serveur, pièces jointes. HTML rendu dans un bac à sable avec images distantes et CSS distant bloqués par défaut, et une autorisation explicite par expéditeur.

Le système d’actions, qui est le cœur de cette construction. Les actions vivent dans un dossier sous forme de petits scripts exécutables plus un manifeste décrivant le nom, le raccourci clavier, et si l’action s’applique à un message, un fil ou une sélection. Quand elle est invoquée, le runner passe le message au script en JSON sur stdin : expéditeur, destinataires, objet, date, corps en texte brut, corps HTML, noms des pièces jointes et leurs chemins temporaires, dossier, indicateurs, et identifiant du message. Le code de sortie du script décide ce qui se passe ensuite, avec un petit ensemble documenté : succès et ne rien faire, succès et archiver, succès et marquer comme lu, échec et afficher cette erreur.

Livre cinq actions d’exemple, chacune dans un langage ou une forme différente pour que le modèle soit évident : ajouter le message à un fichier Markdown ; le POSTer vers un webhook ; créer une tâche dans un fichier de tâches local ; sauvegarder toutes les pièces jointes dans un dossier daté ; ouvrir l’adresse de l’expéditeur dans une recherche d’une archive locale existante.

Sécurité autour des actions : les scripts tournent avec un timeout, leur stderr est capturé et affiché, et une première exécution de toute action nouvelle ou modifiée exige une confirmation explicite montrant le chemin du script et un hash. Un client email qui exécute silencieusement des scripts modifiés, c’est un problème de sécurité, pas une fonctionnalité.

Construis aussi : un éditeur de raccourcis clavier, des actions par défaut par dossier, et un export de toute la boîte mail en mbox.

Hors périmètre : applications mobiles et push, faire tourner un serveur mail, boîtes partagées ou en équipe, et intégrations de services packagées. Le principe, c’est que l’utilisateur écrit l’intégration en dix lignes, pas que le client en livre cinquante.