Note per i manutentori sulla parità GPT-5.5 / Codex

Documentation Index

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

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

Questa nota spiega come rivedere il programma di parità GPT-5.5 / Codex come quattro unità di merge senza perdere l’architettura originale a sei contratti.

​

Unità di merge

​

PR A: esecuzione agentica rigorosa

Possiede:

• executionContract
• proseguimento nello stesso turno con priorità a GPT-5
• update_plan come tracciamento di avanzamento non terminale
• stati bloccati espliciti invece di arresti silenziosi con solo piano

Non possiede:

• classificazione degli errori di auth/runtime
• veridicità dei permessi
• riprogettazione di replay/continuazione
• benchmarking di parità

​

PR B: veridicità del runtime

Possiede:

• correttezza degli scope OAuth di Codex
• classificazione tipizzata degli errori di provider/runtime
• disponibilità veritiera di /elevated full e motivi di blocco

Non possiede:

• normalizzazione dello schema degli strumenti
• stato di replay/liveness
• gate di benchmark

​

PR C: correttezza dell’esecuzione

Possiede:

• compatibilità degli strumenti OpenAI/Codex di proprietà del provider
• gestione dello schema rigoroso senza parametri
• emersione dei replay non validi
• visibilità dello stato di task lunghi in pausa, bloccati e abbandonati

Non possiede:

• continuazione scelta autonomamente
• comportamento generico del dialetto Codex fuori dagli hook del provider
• gate di benchmark

​

PR D: harness di parità

Possiede:

• primo pacchetto di scenari GPT-5.5 vs Opus 4.6
• documentazione di parità
• report di parità e meccaniche del gate di release

Non possiede:

• modifiche al comportamento del runtime fuori da QA-lab
• simulazione auth/proxy/DNS dentro l’harness

​

Mappatura sui sei contratti originali

​

Ordine di revisione

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

PR D è il livello di prova. Non dovrebbe essere il motivo per cui le PR di correttezza del runtime vengono ritardate.

​

Cosa cercare

​

PR A

• le esecuzioni GPT-5 agiscono o falliscono in modo chiuso invece di fermarsi al commento
• update_plan non appare più come avanzamento di per sé
• il comportamento resta con priorità a GPT-5 e limitato al Pi integrato

​

PR B

• gli errori di auth/proxy/runtime smettono di collassare in una gestione generica “modello non riuscito”
• /elevated full viene descritto come disponibile solo quando è effettivamente disponibile
• i motivi di blocco sono visibili sia al modello sia al runtime rivolto all’utente

​

PR C

• la registrazione rigorosa degli strumenti OpenAI/Codex si comporta in modo prevedibile
• gli strumenti senza parametri non falliscono i controlli dello schema rigoroso
• gli esiti di replay e Compaction preservano uno stato di liveness veritiero

​

PR D

• il pacchetto di scenari è comprensibile e riproducibile
• il pacchetto include una lane di sicurezza replay mutante, non solo flussi di sola lettura
• i report sono leggibili da esseri umani e automazione
• le affermazioni di parità sono supportate da evidenze, non aneddotiche

Artefatti attesi da PR D:

• qa-suite-report.md / qa-suite-summary.json per ogni esecuzione del modello
• qa-agentic-parity-report.md con confronto aggregato e a livello di scenario
• qa-agentic-parity-summary.json con un verdetto leggibile dalla macchina

​

Gate di release

Non affermare parità o superiorità di GPT-5.5 rispetto a Opus 4.6 finché:

• PR A, PR B e PR C non sono state unite
• PR D esegue pulitamente il primo pacchetto di parità
• le suite di regressione della veridicità del runtime restano verdi
• il report di parità non mostra casi di falso successo né regressioni nel comportamento di arresto

L’harness di parità non è l’unica fonte di evidenze. Mantieni esplicita questa separazione nella revisione:

• PR D possiede il confronto basato su scenari GPT-5.5 vs Opus 4.6
• le suite deterministiche di PR B possiedono ancora le evidenze di veridicità su auth/proxy/DNS e accesso completo

​

Workflow rapido di merge per maintainer

Usalo quando sei pronto a integrare una PR di parità e vuoi una sequenza ripetibile e a basso rischio.

1. Conferma che la soglia di evidenza sia soddisfatta prima del merge:
   • sintomo riproducibile o test fallito
   • causa radice verificata nel codice toccato
   • correzione nel percorso implicato
   • test di regressione o nota esplicita di verifica manuale
2. Fai triage/applica label prima del merge:
   • applica eventuali label di chiusura automatica r:* quando la PR non dovrebbe essere integrata
   • mantieni i candidati al merge privi di thread bloccanti non risolti
3. Valida localmente sulla superficie toccata:
   • pnpm check:changed
   • pnpm test:changed quando i test sono cambiati o la fiducia nel bug fix dipende dalla copertura dei test
4. Integra con il flusso standard dei maintainer (processo /landpr), poi verifica:
   • comportamento di chiusura automatica delle issue collegate
   • CI e stato post-merge su main
5. Dopo il merge, esegui la ricerca di duplicati per PR/issue aperte correlate e chiudi solo con un riferimento canonico.

Se manca anche solo uno degli elementi della soglia di evidenza, richiedi modifiche invece di fare merge.

​

Mappa obiettivo-evidenza

​

Sintesi per reviewer: prima vs dopo

​

Correlato

• Parità agentica GPT-5.5 / Codex