Notes de maintenance sur la parité GPT-5.5 / Codex

Documentation Index

Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

Cette note explique comment examiner le programme de parité GPT-5.5 / Codex sous forme de quatre unités de fusion sans perdre l’architecture d’origine à six contrats.

​

Unités de fusion

​

PR A : exécution agentique stricte

Possède :

• executionContract
• suivi au même tour, axé d’abord sur GPT-5
• update_plan comme suivi de progression non terminal
• états bloqués explicites au lieu d’arrêts silencieux limités au plan

Ne possède pas :

• classification des échecs d’authentification/d’exécution
• véracité des permissions
• refonte de la relecture/continuation
• évaluation comparative de la parité

​

PR B : véracité de l’exécution

Possède :

• exactitude des portées OAuth de Codex
• classification typée des échecs fournisseur/exécution
• disponibilité véridique de /elevated full et raisons de blocage

Ne possède pas :

• normalisation du schéma d’outil
• état de relecture/vivacité
• verrouillage par évaluation comparative

​

PR C : exactitude de l’exécution

Possède :

• compatibilité des outils OpenAI/Codex gérée par le fournisseur
• gestion stricte des schémas sans paramètres
• exposition des relectures invalides
• visibilité des états de longue tâche en pause, bloquée et abandonnée

Ne possède pas :

• continuation auto-sélectionnée
• comportement générique du dialecte Codex en dehors des hooks fournisseur
• verrouillage par évaluation comparative

​

PR D : harnais de parité

Possède :

• premier pack de scénarios GPT-5.5 vs Opus 4.6
• documentation de parité
• rapport de parité et mécanismes de verrouillage de release

Ne possède pas :

• changements de comportement d’exécution hors QA-lab
• simulation auth/proxy/DNS dans le harnais

​

Correspondance avec les six contrats d’origine

​

Ordre de revue

1. PR A
2. PR B
3. PR C
4. PR D

PR D est la couche de preuve. Elle ne doit pas retarder les PR d’exactitude de l’exécution.

​

Points à vérifier

​

PR A

• Les exécutions GPT-5 agissent ou échouent de manière fermée au lieu de s’arrêter aux commentaires
• update_plan ne ressemble plus à une progression à lui seul
• le comportement reste axé d’abord sur GPT-5 et limité au Pi embarqué

​

PR B

• les échecs auth/proxy/exécution cessent d’être rabattus sur une gestion générique de type « modèle en échec »
• /elevated full est décrit comme disponible uniquement lorsqu’il est réellement disponible
• les raisons de blocage sont visibles à la fois pour le modèle et pour l’exécution côté utilisateur

​

PR C

• l’enregistrement strict des outils OpenAI/Codex se comporte de façon prévisible
• les outils sans paramètres n’échouent pas aux vérifications strictes de schéma
• les résultats de relecture et de compaction préservent un état de vivacité véridique

​

PR D

• le pack de scénarios est compréhensible et reproductible
• le pack inclut une voie de sécurité de relecture mutante, pas seulement des flux en lecture seule
• les rapports sont lisibles par les humains et l’automatisation
• les affirmations de parité sont étayées par des preuves, pas anecdotiques

Artefacts attendus de PR D :

• qa-suite-report.md / qa-suite-summary.json pour chaque exécution de modèle
• qa-agentic-parity-report.md avec comparaison agrégée et par scénario
• qa-agentic-parity-summary.json avec un verdict lisible par machine

​

Verrou de release

Ne revendiquez pas la parité ou la supériorité de GPT-5.5 par rapport à Opus 4.6 tant que :

• PR A, PR B et PR C ne sont pas fusionnées
• PR D n’exécute pas proprement le premier pack de parité
• les suites de régression de véracité de l’exécution restent vertes
• le rapport de parité ne montre aucun cas de faux succès et aucune régression du comportement d’arrêt

Le harnais de parité n’est pas la seule source de preuves. Gardez cette séparation explicite pendant la revue :

• PR D possède la comparaison GPT-5.5 vs Opus 4.6 basée sur des scénarios
• les suites déterministes de PR B possèdent toujours les preuves auth/proxy/DNS et de véracité de l’accès complet

​

Flux de fusion rapide pour mainteneur

Utilisez ceci lorsque vous êtes prêt à intégrer une PR de parité et souhaitez une séquence répétable à faible risque.

1. Confirmer que le niveau de preuve requis est atteint avant la fusion :
   • symptôme reproductible ou test en échec
   • cause racine vérifiée dans le code touché
   • correctif dans le chemin impliqué
   • test de régression ou note explicite de vérification manuelle
2. Trier/étiqueter avant la fusion :
   • appliquer toute étiquette de fermeture automatique r:* lorsque la PR ne doit pas être intégrée
   • garder les candidates à la fusion exemptes de fils bloquants non résolus
3. Valider localement sur la surface touchée :
   • pnpm check:changed
   • pnpm test:changed lorsque des tests ont changé ou que la confiance dans le correctif dépend de la couverture de tests
4. Intégrer avec le flux mainteneur standard (processus /landpr), puis vérifier :
   • comportement de fermeture automatique des issues liées
   • CI et état post-fusion sur main
5. Après l’intégration, lancer une recherche de doublons pour les PR/issues ouvertes liées et ne fermer qu’avec une référence canonique.

S’il manque un seul élément du niveau de preuve requis, demandez des changements au lieu de fusionner.

​

Carte objectif-preuve

​

Raccourci de revue : avant vs après

​

Associé

• Parité agentique GPT-5.5 / Codex