Notas del mantenedor sobre la paridad de GPT-5.5 / Codex

​

Unidades de fusión

​

PR A: ejecución estrictamente agéntica

• executionContract
• continuidad en el mismo turno con GPT-5 como prioridad
• update_plan como seguimiento de progreso no terminal
• estados bloqueados explícitos en lugar de detenciones silenciosas basadas solo en el plan

• clasificación de fallos de autenticación/tiempo de ejecución
• veracidad de permisos
• rediseño de repetición/continuación
• evaluación comparativa de paridad

​

PR B: veracidad del tiempo de ejecución

• corrección de los alcances OAuth de Codex
• clasificación tipada de fallos de proveedor/tiempo de ejecución
• disponibilidad veraz de /elevated full y motivos de bloqueo

• normalización del esquema de herramientas
• estado de repetición/actividad
• puertas de evaluación comparativa

​

PR C: corrección de la ejecución

• compatibilidad de herramientas OpenAI/Codex gestionada por el proveedor
• manejo estricto de esquemas sin parámetros
• exposición de repetición no válida
• visibilidad del estado de tareas largas pausadas, bloqueadas y abandonadas

• continuación autoelegida
• comportamiento genérico del dialecto Codex fuera de los hooks del proveedor
• puertas de evaluación comparativa

​

PR D: arnés de paridad

• primer paquete de escenarios GPT-5.5 vs Opus 4.6
• documentación de paridad
• informe de paridad y mecanismos de puerta de lanzamiento

• cambios de comportamiento en tiempo de ejecución fuera de qa-lab
• simulación de autenticación/proxy/DNS dentro del arnés

​

Correspondencia con los seis contratos originales

​

Orden de revisión

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

​

Qué revisar

​

PR A

• las ejecuciones de GPT-5 actúan o fallan de forma cerrada en lugar de detenerse en comentarios
• update_plan ya no parece progreso por sí solo
• el comportamiento sigue priorizando GPT-5 y limitado a Pi integrado

​

PR B

• los fallos de autenticación/proxy/tiempo de ejecución dejan de colapsar en un manejo genérico de “el modelo falló”
• /elevated full solo se describe como disponible cuando realmente está disponible
• los motivos de bloqueo son visibles tanto para el modelo como para el tiempo de ejecución orientado al usuario

​

PR C

• el registro estricto de herramientas OpenAI/Codex se comporta de forma predecible
• las herramientas sin parámetros no fallan las comprobaciones estrictas de esquema
• los resultados de repetición y Compaction conservan un estado de actividad veraz

​

PR D

• el paquete de escenarios es comprensible y reproducible
• el paquete incluye una vía mutante de seguridad de repetición, no solo flujos de solo lectura
• los informes son legibles para humanos y automatización
• las afirmaciones de paridad están respaldadas por evidencia, no por anécdotas

• qa-suite-report.md / qa-suite-summary.json para cada ejecución de modelo
• qa-agentic-parity-report.md con comparación agregada y por escenario
• qa-agentic-parity-summary.json con un veredicto legible por máquina

​

Puerta de lanzamiento

• PR A, PR B y PR C estén fusionados
• PR D ejecute limpiamente el primer paquete de paridad
• las suites de regresión de veracidad del tiempo de ejecución sigan en verde
• el informe de paridad no muestre casos de éxito falso ni regresión en el comportamiento de detención

• PR D es responsable de la comparación basada en escenarios entre GPT-5.5 y Opus 4.6
• las suites deterministas de PR B siguen siendo responsables de la evidencia sobre autenticación/proxy/DNS y veracidad de acceso completo

​

Flujo rápido de fusión para mantenedores

1. Confirma que se cumple el umbral de evidencia antes de fusionar:
   • síntoma reproducible o prueba fallida
   • causa raíz verificada en el código afectado
   • corrección en la ruta implicada
   • prueba de regresión o nota explícita de verificación manual
2. Haz triaje/aplica etiquetas antes de fusionar:
   • aplica cualquier etiqueta r:* de cierre automático cuando el PR no deba integrarse
   • mantén los candidatos a fusión sin hilos de bloqueo sin resolver
3. Valida localmente la superficie afectada:
   • pnpm check:changed
   • pnpm test:changed cuando hayan cambiado pruebas o la confianza en la corrección del error dependa de la cobertura de pruebas
4. Integra con el flujo estándar de mantenedor (proceso /landpr) y luego verifica:
   • comportamiento de cierre automático de issues enlazados
   • CI y estado posterior a la fusión en main
5. Después de integrar, busca PR/issues abiertos relacionados duplicados y ciérralos solo con una referencia canónica.

​

Correspondencia entre objetivo y evidencia

​

Taquigrafía para revisores: antes vs después

​

Relacionado

• Paridad agéntica de GPT-5.5 / Codex