2026 OpenClaw en pratique : sur un Mac distant, surveiller le dossier d’export Figma, appliquer un filigrane PNG par lot, contrôler les sommes de contrôle et archiver les livraisons

Normes du répertoire d’export et permissions

Fixez dans Figma un chemin d’export unique sur le Mac distant (dossier local synchronisé ou volume dédié), par exemple sous ~/FigmaDelivery/inbox. Évitez les dossiers ouverts simultanément dans plusieurs IDE ou synchroniseurs agressifs sur le même répertoire : ils multiplient les événements partiels et font échouer la détection « fichier terminé ».

Contrat de répertoires (à adapter, noms à garder stables dans vos scripts et skills) :

• inbox — écriture par Figma uniquement ; le worker y lit et déplace vers staging.
• staging — PNG dont la taille est stabilisée, prêts pour filigrane.
• watermarked — sortie finale avant empaquetage ; c’est souvent ce que le DAM ou le client reçoit.
• archive — tarballs ou dossiers datés YYYY-MM-DDTHH-mmZ + manifeste.
• failed — quarantaine avec petit fichier JSON explicatif à côté de chaque PNG rejeté.
• logs — une ligne JSON par job (JSONL), rotation comme dans les autres playbooks MacPng.

Permissions macOS : un seul compte utilisateur exécute launchd, tmux ou le service OpenClaw ; chown cohérent sur toute l’arborescence. Dans les plist, utilisez des chemins absolus et des variables d’environnement explicites (HOME, FIGMA_INBOX). Si Terminal ou votre binaire est bloqué, accordez l’accès disque complet (TCC). Vérifiez que Figma peut toujours écrire dans inbox après vos tests de script (pas de chmod trop restrictif).

Pour aligner transparence, sRGB et conventions d’export avant d’automatiser, croisez avec Figma / Sketch : transparence et export PNG comparés.

Paramètres du filigrane (position, transparence, zone de sécurité)

Le filigrane doit être lisible sans casser la lisibilité du design ni les mentions légales imposées par la marque. Documentez trois nombres versionnés dans un watermark.env : opacité (par ex. 18–35 % selon fonds clairs ou sombres), marge en pixels depuis le bord (safe zone marketing), et échelle du logo par rapport à la largeur du PNG (par ex. 12–18 % pour des bannières web).

Position : SouthEast ou SouthWest sont les plus neutres pour les maquettes UI ; pour des visuels centrés, préférez un bandeau discret en bas avec -gravity South et un geometry qui limite la largeur. Évitez le centre sauf charte explicite : il masque souvent le sujet produit.

Transparence : avec ImageMagick (installable via Homebrew sur le Mac distant), composez le logo PNG sur le master en réglant l’alpha global du calque logo avant fusion. Sur les PNG déjà dotés d’alpha complexe, testez d’abord sur cinq fichiers représentatifs (ombre portée, détourage cheveux, icônes fines).

Gabarit de traitement (extrait reproductible) :

#!/usr/bin/env bash
# watermark_one.sh — à boucler depuis le watcher / OpenClaw
set -euo pipefail
SRC="$1"
OUT="$2"
LOGO="$3"                 # PNG logo filigrane, fond transparent
OPACITY="${OPACITY:-0.28}"
MARGIN="${MARGIN:-24}"

magick "$SRC" \( "$LOGO" -alpha set -channel A \
  -evaluate multiply "$OPACITY" +channel \) -gravity SouthEast \
  -geometry +${MARGIN}+${MARGIN} -compose over -composite "$OUT"

Enchaînez ensuite une passe de validation visuelle automatisable minimale : dimensions inchangées, fichier non vide, pas d’erreur stderr — puis promotion vers watermarked/. Pour une chaîne CLI plus longue (optimisation, QA), réutilisez la logique de chaîne CLI PNG et gabarits de retry sur Mac M distant.

Sommes de contrôle, checklist et archivage des versions

Les clients et équipes internes doivent pouvoir vérifier qu’aucun fichier n’a été altéré après coup. Après filigrane, calculez au minimum un SHA-256 par PNG et agrégez dans un manifeste-<run_id>.csv : chemin relatif, taille octets, sha256, horodatage, version du script (git rev-parse --short HEAD si le dépôt d’outillage est versionné).

Checklist avant clôture d’un run :

1. Tous les fichiers listés dans le manifeste existent sous watermarked/ et sont lisibles par pngcheck ou ouverture ImageMagick sans avertissement critique.
2. Le nombre de lignes du manifeste égale le nombre de PNG attendus pour la campagne ou le lot (comparez au ticket Jira / Notion).
3. Les hashs sont uniques par contenu ; en cas de doublon de hash et noms différents, vérifiez qu’il s’agit bien de fichiers identiques volontaires.
4. Une copie du watermark.env et du script utilisé est jointe dans le même dossier d’archive pour rejeu futur.

Archivage : créez sous archive/ un dossier ou une archive .tar.zst nommée avec l’identifiant de livraison (slug projet + date). Conservez aussi un lien symbolique archive/LATEST pointant vers la livraison courante si vos outils internes le consomment. En parallèle, les métadonnées de droits peuvent compléter le filigrane visuel : voir IPTC / XMP et surveillance d’export sur Mac distant.

Commande indicative de manifeste :

cd "$WATERMARKED_DIR"
find . -name '*.png' -print0 | sort -z | while IFS= read -r -d '' f; do
  printf '%s,' "$f"
  shasum -a 256 "$f" | awk '{print $1}'
done > "../manifeste-${RUN_ID}.csv"

Déclenchement OpenClaw et retour des journaux

En 2026, combinez un watcher (fswatch ou launchd) et, si besoin, une tâche OpenClaw qui appelle le même script via la Gateway en loopback (port et auth : runbook type audit palette OpenClaw).

Intégration skill / gateway (schéma) :

• Le skill expose une action du type process_figma_png_delivery avec paramètres inbox, run_id, opacity, margin.
• La passerelle reçoit le déclenchement (webhook interne, file Redis, ou cron qui « pousse » un job) et exécute le même bash que votre pipeline manuel — la source de vérité reste le script versionné.
• Chaque étape écrit une ligne JSONL : watch, watermark, checksum, archive, avec duration_ms et exit_code.

Retry : sur erreurs manifestement transitoires (I/O disque, fichier encore verrouillé par Figma), appliquez un backoff exponentiel (par ex. 5 s, 20 s, 60 s) avec plafond de trois tentatives par fichier et par jour ; persistance du compteur dans le sidecar JSON sous failed/ ou dans la file OpenClaw. Les erreurs de validation (filigrane hors plage, PNG corrompu) ne doivent pas boucler indéfiniment : classez-les en échec définitif et ouvrez un ticket humain.

FAQ des échecs courants

Q : Le filigrane apparaît flou ou trop petit sur les exports @2x.
A : Calibrez l’échelle du logo en fonction de la largeur en pixels du PNG, pas du nom de l’échelle Figma. Gardez un master logo vectoriel exporté en PNG haute résolution pour les livraisons Retina.

Q : magick: no decode delegate ou erreurs de politique sécurité.
A : Vérifiez l’installation ImageMagick via Homebrew sur le Mac distant et la politique policy.xml si vous traitez des fichiers volumineux ; évitez les binaires obsolètes du système.

Q : Les checksums ne correspondent pas après téléchargement par le client.
A : Assurez-vous que le client vérifie les fichiers après décompression exacte du même tarball ; normalisez les fins de ligne et interdisez les recompression « optimisateurs » côté client avant contrôle.

Q : OpenClaw ne voit pas les nouveaux PNG.
A : Contrôlez que le processus surveille le bon volume, que le debounce n’est pas trop long, et que Figma n’écrit pas dans un sous-dossier non inclus dans le glob du watcher.

Q : Besoin d’optimiser après filigrane sans casser le manifeste.
A : Figez l’ordre des étapes : filigrane d’abord, puis éventuellement oxipng sans perte ; regénérez le manifeste après la dernière transformation. Référence : métadonnées ICC/sRGB et recompression sans perte.

En résumé : arborescence unique, scripts rejouables, OpenClaw pour déclenchements et journaux, archives traçables. Un Mac distant MacPng dédie le worker quand le portable plafonne (thermique, disque) — prêt à louer un nœud et à enchaîner vos livraisons PNG sans friction.