Opus High Review: Piano Finale di Implementazione¶
Meta¶
- Reviewer: Claude Opus 4.6 (1M context)
- Data: 27 marzo 2026
- Documento revisionato:
final-token-optimization-implementation-plan.md - Metodo: analisi strutturale del piano, verifica di coerenza interna, confronto con evidenze raccolte nella review precedente
1. Approved As-Is¶
Fase 0: Metriche e Osservabilita'¶
Solido. Lo schema JSONL e' completo, include supporting_files_count e supporting_files_bytes (feedback precedente recepito). La tassonomia di classificazione run e' esaustiva con l'aggiunta di cancelled. L'aggregatore locale con le 6 metriche chiave e' il gate corretto prima di qualsiasi ottimizzazione. La condizione di completamento ("devo poter rispondere con numeri a...") e' ben formulata.
Fase 2: Split di skill-boilerplate.md¶
Solido. La suddivisione in core + stealth + ratelimit + bugbounty + proxy e' corretta. Il refactoring dei riferimenti ("carica core sempre, moduli aggiuntivi in base a condizioni") e' il pattern giusto. Feature flag dedicato. Il posizionamento prima delle decomposizioni skill e' l'ordine corretto — prima si riduce il costo base, poi si attaccano le skill individuali.
Fase 3: Budget max-turns per classe di skill¶
Solido. Le quattro classi (Deterministic 80-120, Medium 150, High 250, Very High 250+) sono ragionevoli. Il punto 3.2 (telemetria prima di impostare le soglie) e' la decisione corretta — budget inferiti dai dati, non indovinati. Questo evita il rischio di tagliare turni a skill che ne avevano bisogno.
Fase 4: Decomposizione POC test-injection¶
Solido. Il cross-type signal forwarding (4.3) e' correttamente integrato come componente obbligatorio, non opzionale. Il router che consuma i segnali (4.4) chiude il loop. La struttura router + sub-skill con supporting-files minimali e' il pattern giusto. Il criterio di successo ("Se questa POC regge, poi applico lo stesso pattern a...") e' la strategia corretta.
Fase 9: Search Hygiene e Ignore Rules¶
Solido. Lista di esclusioni completa. Rischio nullo. Unico problema: il posizionamento (vedi sezione Rollout).
Sezione "Cosa NON farei adesso"¶
Corretta e importante. I 5 vincoli di auto-contenimento dimostrano disciplina operativa. In particolare "non introdurrei troppe ottimizzazioni insieme senza misurarle separatamente" e' il principio giusto per evitare che una regressione venga mascherata da un miglioramento concomitante.
2. Approved With Conditions¶
Fase 5: Novelty Gate per il Proxy Analyzer¶
Fase 6: Differential Rediscovery¶
Condizione: specificare il valore di N per force full rediscovery nel testo, non solo nel flag.
Il flag suggerisce BB_FORCE_FULL_REDISCOVERY_EVERY_N=5, che e' ragionevole come punto di partenza. Ma il testo del piano dice solo "ogni N cicli o ogni M giorni" senza impegnarsi. In un piano implementativo il valore va fissato esplicitamente (anche se configurabile), altrimenti resta ambiguo.
Le specifiche del manifest (6.1) e del delta check (6.2) sono complete e corrette.
Fase 7: Compattazione agent-dispatch.md¶
Condizione: dettagliare la struttura target.
Il piano dice "vanno in JSON/YAML compatti" ma non mostra la struttura. Per un piano implementativo serve almeno uno schema di esempio:
{
"wave_config": {
"max_waves": 12,
"agents_per_wave": 3,
"agents_per_wave_fast": 5
},
"model_routing": {
"test-injection": {"model": "opus-4-6", "thinking_budget": 24000, "max_turns": 250},
"test-auth": {"model": "opus-4-6", "thinking_budget": 16000, "max_turns": 250},
"test-infra": {"model": "haiku-4-5", "thinking_budget": 2000, "max_turns": 100}
}
}
Senza struttura target, chi implementa deve interpretare il markdown narrativo e decidere da solo cosa diventa campo e cosa diventa commento. Questo introduce varianza.
Fase 8: Decomposizione altre skill¶
Condizione: riordinare la coda di priorita'.
L'ordine proposto e': test-auth, test-access, test-llm, test-client, test-logic.
test-llm (204KB) e' piu' grande di test-access (87KB) e viene attivato con flag dedicato (--llm), il che rende la decomposizione piu' semplice e piu' isolata. Farlo prima di test-access ha ROI migliore per byte risparmiato e rischio piu' basso.
Ordine proposto: test-auth, test-llm, test-access, test-client, test-logic.
I guardrail obbligatori (signal forwarding, parity test, feature flag, rollback) sono corretti.
3. Risks / Blind Spots¶
Blind spot 1: Fase 9 posizionata per ultima¶
.rgignore e' a rischio zero, implementabile in 10 minuti, e previene context pollution su tutte le fasi successive. Metterlo allo Step 6 (ultimo) significa che tutte le fasi 0-8 soffrono di un problema risolvibile immediatamente.
Questo e' un errore di sequencing, non di contenuto. La fix e' banale: anticipare a Step 0.
Blind spot 2: 15 feature flags¶
Il piano introduce 15 flag. Questo e' gestibile ma crea complessita' combinatoria in debug. Alcune flag sono naturalmente accoppiate e non hanno motivo di esistere separatamente:
| Flag 1 | Flag 2 | Motivo accoppiamento |
|---|---|---|
SKILL_BOILERPLATE_SPLIT |
SKILL_LAZY_LOAD |
Se splitti il boilerplate, il lazy load e' implicito nello split |
BB_LOOP_SINGLETON_LOCK |
BB_GLOBAL_RATE_LIMIT_GUARD |
Non ha senso avere il lock senza il cooldown — sono co-dipendenti |
TEST_INJECTION_SPLIT |
CROSS_TYPE_SIGNAL_FORWARDING |
Non si splitta mai senza signal forwarding — la review precedente lo ha detto esplicitamente |
Proposta: consolidare in ~10 flag raggruppando i co-dipendenti. Meno flag = meno combinazioni da testare, meno stati invalidi possibili.
Blind spot 3: Nessun acceptance criteria per Fase 2¶
Fasi 0, 3, 4 e 8 hanno criteri di successo o condizioni di completamento espliciti. Fase 2 (boilerplate split) no. Manca: "il prompt size medio per subprocess deve calare di almeno X% senza variazione nei finding."
Dato che la review precedente ha stimato ~30-45K token di risparmio per subprocess, un criterio ragionevole sarebbe: "prompt size medio per subprocess cala di almeno 25% rispetto alla baseline misurata in Fase 0."
Blind spot 4: Piano di validazione troppo generico¶
La sezione "Piano di validazione" a fine documento elenca metriche e dataset minimi, ma non specifica:
- Quanti finding deve avere il baseline per essere statisticamente significativo
- Quale soglia definisce "miglioramento significativo" del costo token (10%? 20%? 40%?)
- Se la validazione e' per singola fase o cumulativa
- Chi decide il go/no-go e con quale processo (automatico su threshold o review manuale)
- Cosa succede se una fase migliora i token ma peggiora una singola metrica non-primaria
Senza queste specifiche, il go/no-go diventa soggettivo. Il rischio non e' alto ma e' evitabile.
Risk 1: Schema JSONL per cross-type signal non definito¶
La Fase 4.3 dice "emit segnale in $EDIR/signals/cross-type-signals.jsonl" e mostra gli esempi qualitativi (SQLi->XSS, XSS->SSTI, ecc.), ma non definisce lo schema del record. Questo e' il meccanismo piu' critico per la no-regression nelle decomposizioni. Senza schema fissato:
- Ogni sub-skill potrebbe implementare un formato diverso
- Il router non puo' parsare in modo affidabile
- Il testing di parity diventa fragile
Schema minimo proposto:
{
"timestamp": "ISO8601",
"source_skill": "sqli",
"target_signal": "ssti",
"endpoint": "/api/search",
"evidence": "Jinja2 {{7*7}} evaluated in error message",
"confidence": "medium",
"request_hash": "sha256_of_request"
}
Risk 2: Assenza di pentest/SKILL.md dalla lista di ottimizzazione¶
pentest/SKILL.md (134.7KB, ~33.7K token) e' l'orchestratore principale e non viene toccato dal piano. Le sue 6 fasi contengono blocchi narrativi lunghi (istruzioni per recon, discovery, scanning) che vengono caricati anche quando il pentest e' in Phase 4 (wave dispatch) e quei blocchi non servono piu'. Non e' il target piu' urgente, ma e' un'assenza degna di nota per un piano che mira a ridurre il prompt tax strutturale.
4. Missing Optimizations¶
Mancante 1: Target di dimensione per boilerplate-core¶
La Fase 2 elenca le sezioni del core ma non fissa un target numerico. La review precedente ha stimato ~15KB. Senza target, il rischio e' che il "core" cresca fino a ridiventare quasi grande quanto l'originale. Aggiungere: "il core non deve superare i 15KB; qualsiasi sezione oltre quella soglia va in un modulo opzionale."
Mancante 2: Safety preamble centralizzato¶
16 skill di test duplicano ciascuna 3-5KB di regole safety. Il framing attorno alle regole domain-specific e' identico in tutte. Centralizzare il frame una volta sola e tenere solo il delta in ogni skill risparmia ~40-50KB totali. Non e' il risparmio piu' grande, ma e' gratuito e pulisce il codebase.
Mancante 3: pentest/SKILL.md phase-specific loading¶
L'orchestratore carica tutto il suo SKILL.md (134.7KB) anche quando e' in Phase 4 (wave dispatch) e le istruzioni di Phase 1-3 (recon, discovery, scanning) non servono piu'. Estrarre le istruzioni per-phase in helper separati ridurrebbe il contesto attivo in ogni momento.
5. Revised Rollout Order¶
Ordine nel piano:¶
Step 1: Fase 0 + Fase 1 (metriche + loop hardening)
Step 2: Fase 2 + Fase 3 (boilerplate split + max-turns)
Step 3: Fase 4 (test-injection POC)
Step 4: Fase 5 + Fase 6 (proxy + rediscovery)
Step 5: Fase 7 + Fase 8 (dispatch compaction + altre decomposizioni)
Step 6: Fase 9 + Fase 10 (search hygiene + lane B)
Ordine rivisto:¶
Step 0 (immediato, 10 min): Fase 9 (search hygiene — .rgignore)
Step 1: Fase 0 + Fase 1
Step 2: Fase 2 + Fase 3
Step 3: Fase 4 + Fase 7
Step 4: Fase 5 + Fase 6
Step 5: Fase 8
Step 6: Fase 10 opzionale
Modifiche e razionale:¶
| Cambio | Razionale |
|---|---|
| Fase 9 anticipata a Step 0 | Rischio zero, 10 minuti, beneficia tutte le fasi successive prevenendo context pollution. Non ha senso lasciarla per ultima. |
| Fase 7 spostata da Step 5 a Step 3 | La compattazione di agent-dispatch.md e' a basso rischio e riduce il costo dell'orchestratore che dispatcha le sub-skill decomposte in Fase 4. Farle insieme crea sinergia: si ottimizza sia il dispatcher che la skill dispatchata. |
| Fase 8 separata da Fase 7 | Le decomposizioni successive dipendono dal successo della POC (Fase 4). Metterle nello stesso step della compattazione dispatch crea un blocco troppo grande. Meglio sequenziale dopo validazione del pattern. |
Il resto dell'ordine (Step 1 = metriche + loop, Step 2 = boilerplate + turns, Step 4 = proxy + rediscovery) e' confermato come corretto.
6. Final Recommendation¶
Il piano e' ben strutturato ed e' implementabile.¶
Rispetto ai due documenti precedenti (diagnosi + piano operativo), questo piano finale ha quattro miglioramenti sostanziali:
- Cross-type signal forwarding integrato come prerequisito della decomposizione — risolve il rischio di regressione piu' serio
- Telemetria prima dei budget max-turns — decisioni data-driven
- Feature flag per ogni fase — rollback granulare
- Sequencing chiaro con dipendenze — ogni step sa cosa presuppone
Tre correzioni da fare prima di procedere:¶
| # | Correzione | Effort | Impatto |
|---|---|---|---|
| 1 | Anticipare Fase 9 a Step 0 | 1 riga nel piano + 10 min di implementazione | Previene context pollution per tutte le fasi |
| 2 | Annotare Fasi 1, 5, 6 come nuova costruzione | 3 righe nel piano | Elimina ambiguita' operativa per chi implementa |
| 3 | Fissare lo schema JSONL per cross-type signal forwarding | 1 blocco di 10 righe nel piano | Protegge il meccanismo piu' critico per la no-regression |
Correzioni minori (nice-to-have, non bloccanti):¶
- Consolidare i 15 flag in ~10 raggruppando i co-dipendenti
- Aggiungere acceptance criteria a Fase 2 (target ~15KB per core, -25% prompt size per subprocess)
- Dettagliare la struttura JSON target per Fase 7
- Spostare test-llm prima di test-access nell'ordine di Fase 8
- Specificare N=5 nel testo di Fase 6, non solo nel flag
- Eliminare il flag
PROXY_AUTO_ANALYZE_DEFAULT_OFF(inutile per codice nuovo)
Verdetto complessivo¶
Piano pronto per l'implementazione. La struttura e' chiara, le fasi sono nell'ordine giusto con una sola eccezione (Fase 9), i vincoli di no-regression sono correttamente presidiati dal cross-type signal forwarding, e la strategia feature-flag consente rollback sicuro per fase.
La stima di riduzione 40-70% sul pentest flow e 70-90% sul BB loop e' plausibile e coerente con le misure fatte sul codebase.
La frase finale del piano — "non prova a rendere il pentest piu' corto; prova a rendere molto piu' efficiente tutto cio' che succede prima, attorno e tra i momenti in cui Opus fa il lavoro veramente ad alto valore" — e' la sintesi corretta dell'intero approccio.