Les installations OpenClaw fraîches sur Mac mini M4 semblent « vertes » car launchd n’a pas imprimé d’erreurs—puis les webhooks clignotent dès que les jetons tournent. Cette matrice 2026 transforme la validation post-installation en deux tableaux : des contrôles de fumée déterministes avec lignes de réussite explicites, et un routage des symptômes indiquant aux opérateurs s’il faut faire confiance à openclaw doctor, relire les docs d’installation, ou escalader vers les travaux SLO readiness.
Ancrez le rituel avec le déploiement et installation macOS complets, alignez les diagnostics sur les correctifs santé pilotés par doctor, séparez les sondes via le guide santé versus readiness SLO, et terminez l’acceptation avec l’onboarding headless et acceptation du démon.
Pourquoi « pas de journaux de crash » n’est pas un test de fumée
Les passerelles sur Apple Silicon partagent la mémoire unifiée avec indexeurs en arrière-plan et restes de CI. Une défaillance partielle silencieuse—mauvais utilisateur, fichier de jeton obsolète, ou socket admin lié à une interface inattendue—peut ne pas apparaître avant le premier webhook signé. Les tests de fumée doivent donc affirmer identité, version et posture réseau ensemble, pas seulement la vivacité des processus.
- Dérive de version :
openclaw --versiondoit correspondre au semver ticketé avant reload launchd. - Faux verts doctor : checks verts alors que
openclaw gateway statusmontre des écouteurs inattendus signifie que la politique—pas les binaires—est fausse. - Trous headless : une acceptation sans plan break-glass GUI échoue à la première régression TCC—documentez le VNC sans honte.
Règle opérateur : si vous ne pouvez pas coller trois lignes—version, résumé doctor, statut passerelle—dans l’enregistrement de changement, l’hôte n’est pas promu en prod.
Matrice A — Contrôle de fumée, critère de réussite, artefact de preuve
| Contrôle | Critère de réussite | Artefact |
|---|---|---|
| Épinglage semver CLI | openclaw --version correspond à la release épinglée |
Pièce jointe ticket ou extrait de log CI |
| Baseline doctor | openclaw doctor sort zéro ; pas de nouveaux avertissements vs hôte doré |
stdout masqué dans l’object store |
| Posture passerelle | openclaw gateway status n’affiche que les écouteurs attendus |
Capture d’écran ou JSON structuré |
| Marge disque | Espace libre du volume workspace ≥ 2× plus grande rafale d’artefacts | Extrait df dans le ticket |
Matrice B — Symptôme, interprétation, prochain pas
| Symptôme | Interprétation probable | Prochain pas |
|---|---|---|
| Doctor propre, webhooks 401 | Fichier de jeton lisible mais pas celui utilisé par launchd | Comparer les contextes utilisateur ; relancer la checklist d’acceptation headless. |
| Statut montre un écouteur supplémentaire | Dérive de config ou override manuel | Comparer env plist au dépôt ; rollback des flags de bind avant trafic. |
| Readiness fluctue après appels modèle | Sonde readiness trop stricte pour le warm-up GPU | Séparer liveness et readiness modèle selon l’article SLO readiness. |
Garde-fous numériques pour fenêtres de changement
- SLA de preuve : joindre les sorties de fumée dans les 30 minutes suivant le reload launchd ou rollback auto.
- Delta doctor : au plus deux nouveaux avertissements par rapport au doré ; au-delà, bloqueur de merge.
- Répétition webhook : au moins cinq rejouages signés en staging avant d’activer l’ingress prod.
Huit étapes HowTo (miroir JSON-LD)
- Épingler la CLI en enregistrant
openclaw --versiondans le ticket. - Lancer doctor et stocker stdout pour comparaisons avant/après édition plist ou env.
- Inspecter le statut passerelle pour confirmer la politique loopback-first.
- Mesurer le disque sur les racines workspace ; agrandir le volume avant chaînes lourdes.
- Valider l’identité LaunchAgent pour aligner partitions trousseau et portées de secrets.
- Appliquer la séparation readiness : liveness rapide d’abord, contrôles dépendants du modèle ensuite.
- Dry-run webhook avec tailles réalistes et bords de dérive d’horloge.
- Répéter le rollback de plist et jetons sans supprimer les journaux d’audit.
FAQ
La CI doit-elle exécuter la même suite de fumée ?
Oui, mais uniquement des contrôles non interactifs ; les étapes dépendantes du GUI vont dans un pool staging étiqueté avec break-glass VNC documenté.
À quelle fréquence relancer la fumée sur hôtes longue durée ?
Au moins quotidiennement via cron launchd-friendly plus à chaque rotation de secret ; traitez l’absence d’artefacts comme une exécution échouée, pas « ignorée ».
Où sont les clés SSH et bases d’accès distant ?
Commencez au centre d’aide ; utilisez les tarifs lorsqu’un autre hôte dédié est nécessaire à Hong Kong, Japon, Corée, Singapour ou États-Unis.
Des opérations OpenClaw honnêtes sur macOS natif exigent une automatisation SSH d’abord avec VNC réservé aux bords de consentement. Une matrice post-installation disciplinée évite « tableau de bord vert, clients rouges » en liant openclaw --version, openclaw doctor et openclaw gateway status à des preuves rejouables par vos auditeurs. Louer des Mac mini M4 dédiés à travers Hong Kong, Japon, Corée, Singapour et États-Unis donne des hôtes isolés pour que la fumée staging et prod ne partagent jamais accidentellement l’espace de noms du trousseau. Lorsque les matrices montrent une dérive récurrente, ajoutez des hôtes via les tarifs au lieu d’étirer une passerelle unique sur des rôles incompatibles.