rp-execution-policy

Utilisez cette ressource pour la gate d'approbation d'exécution et la finalisation agrégée.

Pour awaiting_execution_approval, présentez le plan d'exécution généré, attendez l'acceptation utilisateur requise en mode normal, et conservez-le dans orchestration/approvals.json. En mode 1-click explicitement demandé par l'utilisateur (automationMode=one_click, source=user), utilisez l'assistant d'approbation agent déterministe uniquement après que le plan et tout examen de sécurité du code requis soient validés. Puis routez à nouveau. Une valeur one_click non rédigée par l'utilisateur est un mode interactif normal et doit attendre l'acceptation utilisateur.

Divulguer ce qui a été lu depuis une source portant des credentials

Si l'exécution a lu la configuration de la payment gateway depuis la source, le plan présenté à la gate d'approbation doit l'indiquer : la configuration de cette gateway a été lue, quelles gateways ont été trouvées, combien sont activées, combien de champs de credentials sont configurés, et que aucune valeur de credential n'a été conservée. L'adaptateur source produit cette ligne — pour WordPress, describeGatewaySummary() dans rp-source-wordpress/lib/gateway-summary.mjs.

Une exécution qui signale « N gateways, M activées, K champs de credentials présents, 0 valeurs conservées » est auditable. Une qui a lu la même chose silencieusement ne l'est pas, et l'utilisateur approuvant le plan n'a aucun moyen de les distinguer. Ne mettez jamais une valeur de credential, un préfixe, une longueur ou un hash dans le rapport du plan lui-même.

Signaler la section paiements du plan

Si l'exécution importe des enregistrements de paiement, des remboursements ou des documents de facture, construisez cette section du plan avec lib/payments-report.js plutôt que manuellement. Cela applique trois éléments qu'un résumé rédigé à la main a déjà mal gérés, et cela BLOQUE la gate d'approbation plutôt que d'imprimer une mise en garde :

• Les résultats de paiement doivent correspondre à la population de commandes source découverte. Un rapport dont les chiffres ne s'additionnent pas cache des commandes. Le builder retourne approvable: false avec le manque nommé.
• Zéro est un résultat. Chaque résultat et chaque décompte sont émis même à zéro, donc « 0 remboursements trouvés » est vérifiable d'un coup d'œil. Un chiffre invraisemblable est moins cher à attraper ici.
• La couverture candidate n'est pas la couverture inscrite. Les commandes portant une valeur de forme-référence et les commandes dont la référence peut être défendablement attribuées sont des lignes distinctes. Les fusionner surestime la fidélité.

Le dénominateur doit provenir des lectures réconciliées de l'exécution elle-même (from: 'run-reconciled-read'), pas d'une enquête antérieure. Quand une enquête a compté différemment, les deux chiffres sont affichés et la discordance doit être réconciliée avant le pilot.

L'inventaire des fournisseurs porte l'identifiant, le nom d'affichage et l'état d'activation uniquement — un champ de forme-credential sur un fournisseur bloque la gate. La phrase « vous perdrez votre historique » est interdite : elle est fausse pour les enregistrements de paiement, qui sont indépendants du fournisseur.

Exécutez :

node skills/wix-replatform/scripts/migration-completion.js <projectDir>

Cette commande valide la comptabilité d'achèvement du backend et, pour la livraison du site web, le reçu d'achèvement du frontend. Elle écrit completion/migration-completion.json de façon atomique.

Elle refuse également, sur les deux modes de livraison, sauf si l'exécution a produit sa transmission post-exécution et son journal d'exécution. Une exécution management ne produit pas de site web et n'avait auparavant besoin d'aucune transmission du tout, ce qui permettait à une migration backend uniquement de finaliser sans aucun compte d'elle-même n'importe où dans le projet. Les raisons de refus typées sont :

Les deux dernières comparent par rapport au timestamp de dernière écriture enregistré du rapport d'achèvement lui-même, jamais un mtime de fichier : un mtime est rafraîchi par une copie et ne prouve rien. Si la validation échoue, ne fabriquez pas d'achèvement ; routez à nouveau vers le module qui possède l'artefact manquant ou obsolète.

Gate d'attestation Entity-QA

Le même finaliseur refuse également sans un execution/qa/entity-qa-attestation.json frais et complet qui correspond au digest actuel de execution/completion-report.json et couvre chaque entité/sous-type mappée avec des décomptes correspondants (section « Entity-by-entity QA » de rp-execute-import/SKILL.md). Le refus porte entityQa: { qaStatus, entities, recheck } :

Une attestation valide ne prouve que la fraîcheur et la couverture des lignes d'import (scope: 'import-entity-coverage' dans migration-completion.json) — jamais la configuration métier ou la préparation au lancement, et jamais la preuve que la passe QA elle-même s'est produite plutôt qu'une copie des propres décomptes du rapport.

Signaler les coupons, la devise et les définitions de plan

lib/coupon-currency-plan-report.js buildCouponCurrencyPlanReport rend la section et décide l'approvabilité de la même manière que payments-report.js : chaque ligne avec son décompte y compris zéro ; par zone written + excluded + skipped = discovered ; exactement un résultat de devise, et une discordance ou un historique multi-devise BLOQUE comme arrêt ; la surface de coupon-usage doit être nommée. Deux phrases sont refusées partout où elles apparaissent — « imported N coupons » (le titre honnête est la répartition de la rédemption) et « not supported » (zéro lignes de plan est « none found », un fait mesuré).

Statut d'ensemble découvert et re-finalisation sûre

Pour chaque finalisation en mode standard, construisez execution/discovered-set-status.json avec node scripts/discovered-set-status.js build <projectDir> après le rapport d'achèvement, puis régénérez la transmission post-exécution, conservez l'attestation entity-QA actuelle, et exécutez node scripts/migration-completion.js <projectDir>. L'approbation, la réconciliation ou le statut du census manquant ou obsolète est une retenue ; reconstruisez l'artefact possédant et obtenez un examen de mapping frais où requis. Le reçu final est la version 2. Les lignes de ensemble découvert ouvert conservent un backend complet à complete_with_warnings, et la transmission et le reçu doivent être d'accord.

Sur reviewOnly: true, la re-finalisation utilise les résultats d'import existants. Ne faites aucun client Wix, setup, codegen, import ou dispatch de site web. Reconstruisez uniquement le statut d'ensemble découvert et la transmission post-exécution, puis l'achèvement agrégé ; le writer archive le reçu version-1 d'origine une fois. Toute autre route est tenue pour l'Opérateur d'Import. Le travail manuel peut être enregistré uniquement pour une ligne manual-open, par le marchand ou l'Opérateur Cutover via node scripts/discovered-set-status.js resolve <projectDir> --census-id <id> --by merchant|cutover-operator --evidence <short non-record evidence>. Tous les autres résultats ouverts nécessitent leur chemin de récupération d'import/mapping existant. Le mode rapide ne nécessite aucun statut d'ensemble découvert.