rp-preflight

Exécutez l'helper preflight déterministe avant discovery :

node skills/wix-replatform/scripts/orchestration-preflight.js <projectDir>

Utilisez son résultat structuré comme autorité. Quand il signale une configuration source ou des credentials manquants, routez vers rp-source-inputs ; quand il signale un problème de destination, routez vers rp-destination. Ne commencez pas discovery avec un preflight bloqué.

The recording line

Le résultat comporte également une vérification telemetry_journal signalant si ce projet enregistre : active, absent, finalized_only ou unreadable. Son statut est toujours info, et info n'affecte jamais le verdict global — une exécution sans journal telemetry passe toujours preflight et continue.

La vérification regarde seulement ; le script se rétablit ensuite. Quand la lecture est absent, finalized_only, ou un journal unreadable qui ne rejoue aucun démarrage d'exécution, le script preflight commence lui-même l'enregistrement (un journal endommagé est d'abord mis de côté vers telemetry/events.unreadable-<timestamp>.jsonl, chaque octet conservé). La vérification garde la lecture journal originale et ajoute recovery — not_needed, started, set_aside_and_started ou failed — plus recoveredRunId/recoveredAttempt, setAsideFile ou recoveryError. Vous n'avez pas besoin d'agir sur cette ligne.

recovery: failed ne change jamais le verdict ou le code de sortie, et est une preuve réservée à l'équipe : ne le relayez pas à la personne exécutant la migration (règle rp-telemetry « never mention »). Appelez rp-telemetry start au début de l'exécution comme avant ; preflight est le filet de sécurité.

Output

orchestration/preflight.json — le résultat structuré du script (status: pass | blocked | failed plus détail par vérification). C'est ce qu'une exécution dispatchée doit produire.