2026 OpenClaw, front-end terrain :
agréger Vite/Webpack sur Mac distant et renvoyer un résumé PR de régression performance — chaîne reproductible

1. Sans parité de runner, une PR « verte » peut masquer une régression murale sur Apple Silicon. 2. Les logs CI mélangent installation, lint et build : peu exploitables pour une revue humaine. 3. Un bot sur-dimensionné expose l’organisation si le jeton dépasse le dépôt visé.

L’objectif est un artefact unique par commit, relu par OpenClaw et renvoyé là où la discussion a lieu. « Mesurer avant d’argumenter : millisecondes par phase, pas opinions. » Réservez .openclaw/reports/<git-sha>/ pour les sorties machine et gardez les builds production alignés sur la CI.

Idée de script : un node scripts/collect-build-metrics.mjs enveloppe npm run build, lit BUILD_METRICS_PATH, fusionne les mesures émises par plugins et écrit build_metrics.json atomiquement (writeFileSync vers un fichier temporaire puis rename). Sur le Mac loué, fixez CI=1 et la même version Node que le workflow.

En monorepo, ajoutez workspace ou packageName pour éviter d’additionner des builds parallèles sans le savoir.

Versionnez un schéma build_metrics/v1. Champs recommandés : gitSha, toolchain (node, vite, webpack), totalMs, phases (tableau { "name", "durationMs" }), cacheHit booléen ou ratio si votre orchestrateur le fournit, coldWarm pour distinguer CI à froid du cache chaud. Parsez avec jq : jq -e '.phases | map(.durationMs) | add' vérifie la cohérence interne.

Chargez une baseline (dernier build vert de main ou parent de merge). Calculez des deltas par phase et par totalMs. Écrivez build_gate.json avec level : ok, warn (ex. dépassement cinq pour cent sur une phase non critique), fail (budget global ou phase critique). Les alertes Slack ou e-mail peuvent lire le même fichier ; le commentaire PR reste court grâce au Markdown synthétique. Documentez les seuils dans le dépôt pour éviter qu’un ajustement de runner ne soit confondu avec une régression réelle.

OpenClaw consomme build_metrics.json + build_gate.json et produit pr_build_perf_summary.md avec sections fixes : empreinte, tableau phases, delta baseline, verdict. Le token passerelle authentifie uniquement votre worker (en-tête Authorization: Bearer ou signature HMAC) : il ne remplace pas GITHUB_TOKEN. Attribuez-lui le moindre privilège : création de tâche d’analyse, pas d’accès lecture aux secrets du dépôt. Séparez les environnements (préprod / prod) et faites tourner les secrets lors des départs.

Après synthèse, postez vers un webhook interne qui valide la charge (sha, text Markdown) puis appelle gh pr comment ou l’API Checks. Utilisez un marqueur HTML <!-- openclaw-build-perf:SHA --> pour éviter les doublons ; en cas de 429, backoff exponentiel. Enfermez le build et le parse dans timeout (souvent vingt à quarante minutes pour les grosses SPA).

curl -sS -X POST "$BUILD_PERF_WEBHOOK_URL" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENCLAW_GATEWAY_TOKEN" \
  -d "$(jq -n --rawfile body pr_build_perf_summary.md --arg sha "${GITHUB_SHA:-local}" \
    --slurpfile gate build_gate.json '{text: $body, sha: $sha, gate: $gate[0]}')"