Skip to content

Opus High Final Handoff Plan

Mission

Eseguire un ultimo controllo tecnico sul piano di ottimizzazione token e, se lo ritieni corretto, implementarlo in modo graduale senza degradare:

  • coverage della superficie di attacco
  • numero di finding trovati
  • qualità del reasoning
  • qualità della verification
  • qualità del chaining
  • qualità delle evidenze

Fonte di verità

Questo documento è il riferimento operativo principale.

Documenti di supporto:

Decisione architetturale già presa

L’ordine corretto del lavoro è questo:

  1. Misurazione
  2. Hardening del bug bounty loop
  3. Split di skill-boilerplate.md
  4. Budget max-turns per skill
  5. Decomposizione POC di test-injection con cross-type signal forwarding
  6. Novelty gate sul proxy analyzer
  7. Differential rediscovery con safety net di full rediscovery periodico
  8. Compattazione dispatch/preamble
  9. Decomposizione delle altre skill pesanti
  10. Solo infine lane shadow per task deterministici

Cosa è già approvato concettualmente

Approved as-is

  • Misurazione prima di cambiare
  • Workspace/search hygiene
  • Loop hardening

Approved with conditions

  • Context slimming
  • partire da skill-boilerplate.md, non da CLAUDE.md
  • rispettare il meccanismo supporting-files:

  • introdurre cross-type signal forwarding prima di decomporre le skill

  • Skinny context

  • non trattarlo come problema di contesto conversazionale

  • ottimizzare invece file caricati e supporting files

  • Differential rediscovery

  • obbligatorio il fallback force full rediscovery every N cycles

  • Proxy analyzer

  • novelty gate sì

  • auto_analyze=False come default solo dopo parity o dietro feature flag

  • Model routing

  • solo lane A subito
  • lane B solo in shadow

Non-obiettivi

Non devi:

  • semplificare la metodologia di test
  • ridurre il numero di skill eseguite senza prova di equivalenza
  • abbassare il modello nelle fasi critiche
  • ottimizzare “a sentimento” senza metrica
  • introdurre regressioni pur di risparmiare token

Regole di implementazione

Regola 1

Ogni macro-fase deve essere:

  • implementata in modo isolabile
  • protetta da feature flag
  • verificabile con metriche locali
  • rollbackabile senza effetti collaterali

Regola 2

Dopo ogni fase devi fermarti, verificare e decidere se procedere alla successiva.

Regola 3

Se una modifica rischia anche moderatamente di ridurre findings o coverage, deve restare in shadow mode fino a parity dimostrata.

Piano implementativo che devi seguire

Phase A: Instrumentation

Obiettivo

Misurare dove vanno i token.

Da implementare

  1. Record JSONL per ogni claude -p
  2. Classificazione run:
  3. useful
  4. rate_limited_immediate
  5. rate_limited_midrun
  6. dead_run_short
  7. error
  8. cancelled
  9. Metriche aggiuntive:
  10. supporting_files_count
  11. supporting_files_bytes
  12. Aggregazione locale:
  13. spawn/hour
  14. rate-limit ratio
  15. dead-run ratio
  16. estimated prompt tax by family
  17. token per confirmed finding

File target principali

Feature flag

  • CLAUDE_METRICS=1

Stop gate

Non proseguire se non riesci a produrre un baseline numerico leggibile.

Phase B: Bug Bounty Loop Hardening

Obiettivo

Eliminare spawn storm, run morte e retry inutili in quota esaurita.

Da implementare

  1. Single-instance lock
  2. Control plane unico
  3. Cooldown globale su rate limit
  4. Dead-run classifier
  5. Quota-aware scheduler
  6. Runtime separation per prompt dump e log

File target principali

Feature flags

  • BB_LOOP_SINGLETON_LOCK=1
  • BB_GLOBAL_RATE_LIMIT_GUARD=1
  • BB_DEAD_RUN_CLASSIFIER=1
  • BB_RUNTIME_LOG_SEPARATION=1

Stop gate

Non proseguire se:

  • vedi ancora più orchestratori contemporanei
  • partono nuovi claude -p durante cooldown
  • i run morti continuano ad avanzare il loop come run normali

Phase C: Split di skill-boilerplate.md

Obiettivo

Ridurre il costo statico condiviso da quasi tutte le skill.

Da implementare

Dividere skill-boilerplate.md in:

  • skill-boilerplate-core.md
  • skill-boilerplate-stealth.md
  • skill-boilerplate-ratelimit.md
  • eventuali moduli opzionali:
  • skill-boilerplate-bugbounty.md
  • skill-boilerplate-proxy.md

Regola

  • il core è always-on
  • il resto è lazy-load o conditional-load

Feature flags

  • SKILL_BOILERPLATE_SPLIT=1
  • SKILL_LAZY_LOAD=1

Stop gate

Non proseguire se il refactor rompe il contratto operativo delle skill /test-*.

Phase D: max-turns Budget per Skill

Obiettivo

Evitare budget eccessivi dove non servono.

Da implementare

Budget per classe:

  • deterministic: 80-120
  • medium: ~150
  • high: 250
  • very high: 250+

Regola

Non fissare i budget a intuito. Usa i dati raccolti in Phase A.

File target principali

Feature flag

  • SKILL_MAX_TURNS_BUDGETING=1

Stop gate

Non proseguire se una skill complessa va spesso in exhaustion del nuovo budget e cala la qualità.

Phase E: Decomposizione POC di test-injection

Obiettivo

Validare il pattern di decomposizione sulla skill più costosa.

Da implementare

  1. Router leggero
  2. Sub-skill per scope/type
  3. Supporting files minimali per sub-skill
  4. Cross-type signal forwarding
  5. Router che consuma i segnali

Vincolo obbligatorio

Il cross-type signal forwarding è necessario prima del rollout, altrimenti c’è rischio di perdita di finding.

File target principali

Feature flags

  • TEST_INJECTION_SPLIT=1
  • CROSS_TYPE_SIGNAL_FORWARDING=1

Stop gate

Non proseguire alle altre decomposizioni se questa POC non dimostra parity.

Phase F: Proxy Analyzer Novelty Gate

Obiettivo

Ridurre il background AI burn del proxy analyzer.

Da implementare

  1. Semantic fingerprint
  2. Novelty gate
  3. Keep-list di request sempre interessanti
  4. Realtime manual analysis sempre disponibile
  5. Eventuale auto_analyze=False solo dietro flag o dopo parity

File target principali

Feature flags

  • PROXY_AI_NOVELTY_GATE=1
  • PROXY_AUTO_ANALYZE_DEFAULT_OFF=0

Phase G: Differential Rediscovery

Obiettivo

Non rifare discovery completa su programmi invariati, ma senza introdurre false negative.

Da implementare

  1. Freshness manifest
  2. Lightweight delta check
  3. Reuse baseline se delta basso
  4. Full rediscovery se delta alto
  5. Force full rediscovery every N cycles

Vincolo obbligatorio

Il fallback periodico di full rediscovery è mandatory.

File target principali

Feature flags

  • BB_DIFFERENTIAL_REDISCOVERY=1
  • BB_FORCE_FULL_REDISCOVERY_EVERY_N=5

Phase H: Dispatch/Preamble Compaction

Obiettivo

Ridurre altro costo statico ripetuto.

Da implementare

  1. Compattare tabelle di dispatch in config più sintetica
  2. Centralizzare framing duplicato dei preamble
  3. Ridurre markdown narrativo dove una config basta

File target principali

Feature flag

  • DISPATCH_CONFIG_COMPACTION=1

Phase I: Decomposizione Altre Skill Pesanti

Ordine

  1. test-auth
  2. test-access
  3. test-llm
  4. test-client
  5. test-logic

Regola

Ogni skill si decompone solo se il pattern POC di test-injection ha passato parity.

Phase J: Lane Shadow per Task Deterministici

Obiettivo

Fare l’ultimo miglio solo dove il rischio è basso e misurabile.

Da considerare solo in shadow

  • route normalization
  • hashing
  • diff manifest
  • parsing sitemap/robots
  • clustering

Non toccare

  • exploit reasoning
  • verification
  • chain discovery
  • final acceptance
  • stuck resolution

Feature flags globali

  • CLAUDE_METRICS=1
  • BB_LOOP_SINGLETON_LOCK=1
  • BB_GLOBAL_RATE_LIMIT_GUARD=1
  • BB_DEAD_RUN_CLASSIFIER=1
  • BB_RUNTIME_LOG_SEPARATION=1
  • SKILL_BOILERPLATE_SPLIT=1
  • SKILL_LAZY_LOAD=1
  • SKILL_MAX_TURNS_BUDGETING=1
  • TEST_INJECTION_SPLIT=1
  • CROSS_TYPE_SIGNAL_FORWARDING=1
  • PROXY_AI_NOVELTY_GATE=1
  • PROXY_AUTO_ANALYZE_DEFAULT_OFF=0
  • BB_DIFFERENTIAL_REDISCOVERY=1
  • BB_FORCE_FULL_REDISCOVERY_EVERY_N=5
  • DISPATCH_CONFIG_COMPACTION=1

Validation Gates

Per ogni phase devi misurare:

  • token total
  • token per family
  • dead-run ratio
  • rate-limit ratio
  • endpoint coverage
  • crown jewel coverage
  • findings confirmed
  • verification quality
  • chain quality

Hard Stop Rules

Se anche una sola di queste peggiora in modo reale, ti fermi e non vai avanti:

  • findings parity
  • endpoint coverage parity
  • crown jewel coverage parity
  • verification parity
  • chain parity

Deliverable attesi da te

Deliverable 1

Review finale breve:

  • approved as-is
  • approved with conditions
  • risks
  • final rollout order

Deliverable 2

Implementazione reale solo di:

  • Phase A
  • Phase B
  • Phase C
  • Phase D

Deliverable 3

Report di verifica post-implementazione con:

  • cosa è cambiato
  • metriche prima/dopo
  • rischi residui
  • raccomandazione se procedere a Phase E

Decisione operativa

Se ritieni che una fase successiva richieda shadow mode o più guardrail di quanto previsto qui, fermati e proponi l’aggiustamento prima di implementarla.

L’obiettivo non è finire tutto in una volta. L’obiettivo è implementare il massimo risparmio possibile senza intaccare il valore offensivo del progetto.