Solo-Engine v4.1 Final: meno regole duplicate, più verificabilità

Verdetto: V4 è una buona base, ma V4.1 Final è la scelta più solida

La valutazione è favorevole al lavoro svolto sul V4: ha affrontato problemi cruciali, come l’invenzione di tool, test e risultati di compilazione, oppure la consegna di frammenti spacciati per un progetto completo. Tuttavia, non è consigliabile adottarlo senza modifiche.

Il limite principale non è la mancanza di capacità, bensì l’eccesso di regole ripetute e alcune definizioni ancora ambigue. In particolare, devono essere delimitati meglio:

• cosa può realmente fare un Gem in una sessione;
• cosa significhino «ciclo automatico» e «zero dipendenze»;
• quando una consegna di file completi diventi davvero un completamento ingegneristico;
• come usare ruoli ispirati a BMAD senza fingere l’esecuzione di un runtime multi-agent.

La scelta raccomandata è quindi Solo-Engine v4.1 Final. L’idea è semplice: mantenere il ciclo ricerca → decisione → ingegneria del V4, ma rendere il sistema più corto, autosufficiente e verificabile.

Cosa il V4 ha già fatto bene

Il V4 ha costruito una base metodologica credibile:

• separa /ana-solo per analisi e decisione da /ana-bmad per pianificazione, implementazione e verifica;
• distingue chiaramente FACT, INFERENCE, ASSUMPTION e UNKNOWN;
• vieta di inventare accesso al web, Tavily, esecutori, file system, Git, compilazioni e test;
• separa l’emissione di codice completo dalla prova reale che quel codice compili o superi i test;
• introduce controlli come Algorithm-Fit, Preflight, State Reconcile e una pressione di arresto dopo fallimenti ripetuti;
• tratta gli ADR come decisioni con ciclo di vita, non come documentazione decorativa;
• impone di interrompere le consegne soltanto al confine tra file completi;
• interpreta BMAD come una struttura di responsabilità interne al singolo Gem, non come la prova che più agenti indipendenti siano stati eseguiti davvero.

Questa ultima distinzione è rilevante. La documentazione BMAD descrive agenti, skill, workflow e percorsi di test come meccanismi operativi specifici. Un singolo Gem può adottarne la logica di revisione dei ruoli, ma dovrebbe definirsi «orchestrazione di ruoli ispirata a BMAD», non equivalente a un runtime BMAD multi-agent reale. 11014

I problemi da correggere

1. Troppi vincoli affidati alla knowledge base

Le regole essenziali non dovrebbero vivere solo nei documenti di supporto. Non è prudente dare per certo che ogni file della knowledge base venga richiamato integralmente a ogni risposta.

Per questo V4.1 Final mantiene direttamente nell’istruzione principale del Gem i vincoli su:

• autenticità di tool e risultati;
• confini degli strumenti disponibili;
• codice e file completi;
• condizioni di verifica;
• definizione di completamento.

Procedure operative, checklist e template restano invece nella knowledge base. In questo modo si riduce il rischio che una regola critica venga persa durante una risposta lunga.

2. Densità di istruzioni e duplicazioni

Nel V4, stati, dipendenze, ADR, verifiche e criteri di completamento compaiono in più documenti. Una maggiore quantità di testo non garantisce una maggiore aderenza: regole sovrapposte possono produrre interpretazioni locali incoerenti.

La revisione propone quindi un solo punto di verità per le regole inderogabili e documenti secondari per il dettaglio operativo.

3. Il «ciclo automatico» deve avere confini reali

Un prompt non crea attività in background, un terminale persistente o una capacità di continuare a lavorare tra sessioni diverse. Nella versione finale, un ciclo automatico può esistere soltanto:

• nella risposta o sessione corrente;
• entro l’autorizzazione esplicita dell’utente;
• entro le capacità realmente esposte nell’ambiente;
• con una condizione di arresto e un budget di ritentativi;
• senza esecutore reale, fermandosi a WAITING_VERIFICATION.

Questa modifica evita di trasformare una procedura desiderata in una capacità tecnica fittizia.

4. «Zero dipendenze» non è una sola cosa

L’espressione può confondere almeno tre concetti diversi: assenza di pacchetti terzi, assenza di moduli locali mancanti e assenza di prerequisiti di runtime. V4.1 Final li separa:

• zero dipendenze non dichiarate;
• nessuna nuova dipendenza di terze parti per impostazione predefinita;
• tutte le nuove dipendenze locali consegnate nel bundle;
• runtime, SDK, sistema operativo e piattaforma host dichiarati come prerequisiti ambientali.

In altre parole, il codice sorgente può chiudere il proprio perimetro di consegna, ma non può eliminare magicamente la necessità di un compilatore, di un runtime o di un SDK.

5. «Codice completo» dipende dal contesto del progetto

Per un progetto nuovo, la consegna deve includere tutti i file necessari a formare un minimo progetto eseguibile: configurazione di build, punto di ingresso, sorgenti, test, risorse indispensabili e script di verifica.

Per un progetto esistente, invece, devono essere emessi per intero tutti i file nuovi o modificati. I file di baseline già forniti dall’utente e non modificati non vanno ripetuti inutilmente. Se però manca un’interfaccia esistente che condiziona compilazione o comportamento, il Gem deve chiedere quel file o quella firma: non può inventarla.

6. Consegna e completamento ingegneristico restano distinti

La proposta mantiene tre piani separati:

• DELIVERY_STATUS: i file sono stati consegnati integralmente?
• VERIFICATION_STATUS: esiste una prova reale di build o test?
• ENGINEERING_STATUS: è corretto dichiarare il lavoro concluso?

Una risposta può avere DELIVERY_STATUS=COMPLETE e restare in WAITING_VERIFICATION. Questa è la formulazione corretta quando non esiste un compilatore o un esecutore realmente disponibile.

7. Tavily deve essere un adattatore di capacità, non una promessa

search_depth=advanced è un parametro reale di Tavily, pensato per query dettagliate e ad alta precisione, con un compromesso in termini di latenza o costo. Non può però diventare una capacità acquisita per il solo fatto di citarla in un prompt. 2411

La regola corretta è:

• usare Tavily solo se lo strumento o l’integrazione sono realmente disponibili;
• impiegare advanced per lacune informative decisive e ad alta precisione;
• usare modalità meno costose per ricerca esplorativa;
• dichiarare il downgrade verso fonti caricate o ricerca nativa quando Tavily non è disponibile.

8. Meglio «Value Extraction» che un SEO implicito

L’obiettivo predefinito dovrebbe essere l’estrazione di valore: collegare evidenza, significato, valore per l’utente, azione e verifica. Il SEO va attivato solo quando la richiesta riguarda davvero keyword, indicizzazione, crawling, struttura del sito, ranking o ottimizzazione dei contenuti.

9. Il Truth Report non deve suggerire verità assolute

Il nome può essere conservato, ma con una definizione rigorosa: è una fotografia dei fatti supportati dalle prove disponibili in quel momento. Deve includere anche assunzioni, elementi ignoti, test non eseguiti e prove negative, senza cancellare silenziosamente ciò che contraddice la soluzione.

Matrice decisionale

La scala va da 0 a 5 e viene normalizzata su 100. Questi punteggi sono una valutazione statica della configurazione, non un benchmark di esecuzione del Gem.

Dimensione	Peso	V4	V4.1 Final
Confini operativi del Gem e autenticità degli strumenti	25%	4,0	4,8
Qualità di lettura in tre passaggi, DM e DR	20%	4,5	4,8
Salvaguardie ingegneristiche e gestione dei fallimenti	20%	4,6	4,8
Codice completo e chiusura delle dipendenze	15%	4,6	4,9
Densità delle istruzioni e applicabilità	10%	2,8	4,5
Recupero dello stato e riconciliazione delle prove	10%	4,2	4,7
Totale ponderato	100%	84,2	95,5

La formula utilizzata è:

$$
Score = 20\sum_{i=1}^{n}w_i s_i,
\qquad
\sum_{i=1}^{n}w_i=1
$$

Il risultato non implica che V4.1 sia stato eseguito con successo in un ambiente reale: indica che la sua struttura risponde meglio ai requisiti di autenticità, verificabilità e chiarezza operativa.

Decisione finale

• Scelta consigliata: Solo-Engine v4.1 Final.
• Alternativa: V4, utile per sperimentazione interna ma non consigliato come configurazione stabile a lungo termine.
• Miglioramento decisivo: non aggiungere altre regole, ma eliminare duplicazioni, rendere autosufficiente l’istruzione principale e dichiarare esplicitamente i limiti di runtime.
• Condizione di evoluzione: se in futuro saranno disponibili Gemini API Managed Agent, MCP, una sandbox di codice persistente o tool con permessi reali, andrà introdotto un Runtime Adapter separato. Non è consigliabile accumulare descrizioni di tool nel prompt principale.

I cinque test minimi che possono smentire il progetto

Bastano questi casi per dimostrare che anche V4.1 necessita di ulteriore irrigidimento:

1. Senza esecutore, il Gem dichiara che il codice ha superato i test.
2. In assenza di un’interfaccia locale, il Gem ne inventa una e afferma che il progetto compila.
3. Un bugfix modifica una firma pubblica senza passare a un Preflight strutturale.
4. La consegna si ferma a metà file, ma lo stato viene marcato COMPLETE.
5. Tavily non è disponibile, ma il Gem sostiene di aver eseguito una ricerca con search_depth=advanced.

Se si verifica anche uno solo di questi casi, le istruzioni principali non sono ancora abbastanza chiare o compatte.

Copertura delle evidenze

• Confermato: il V4 possiede già una valida struttura per autenticità delle evidenze e ciclo ingegneristico.
• Confermato: Tavily Advanced è un parametro di ricerca effettivo e non una capacità ottenibile con il prompt. 2411
• Confermato: i ruoli in stile BMAD sono utili per riesaminare responsabilità dentro un singolo Gem, ma non provano l’esecuzione di agenti indipendenti multipli. 11014
• Non verificabile con il materiale disponibile: il Gem dell’utente dispone davvero di Tavily, compilatori per il linguaggio target, MCP o un workspace persistente.

Struttura consigliata del pacchetto V4.1

File	Posizione	Funzione
00-solo-engine-system.md	Istruzioni del Gem	Routing, vincoli inderogabili, limiti di capacità
10-ana-solo.md	Knowledge base	Ricerca, estrazione di valore, Decision Matrix e Deep Recon
20-ana-bmad.md	Knowledge base	Riconoscimento degli scenari, controlli ingegneristici e consegna
30-artifacts.md	Knowledge base	Plan, ADR, record di verifica, Truth Report e Resume Capsule
40-three-pass-reading.md	Knowledge base	Nucleo del metodo di lettura in tre passaggi

I file equivalenti delle versioni precedenti non dovrebbero essere caricati insieme a questo pacchetto: la sovrapposizione aumenterebbe il rischio di recuperare istruzioni in conflitto.

Conclusione

Solo-Engine v4.1 Final non promette capacità che un Gem non possiede. Fa una cosa più utile: rende esplicito il confine tra analisi, generazione di artefatti, consegna di codice e verifica realmente eseguita.

È questa separazione a trasformare un prompt ricco di regole in un workflow più affidabile: meno teatralità multi-agent, meno risultati impliciti, più stato tracciabile e più onestà sulle prove disponibili.