Solo-Engine v4.1 Final: menos reglas duplicadas, más control real

Veredicto

V4 tiene una base sólida, pero no conviene publicarla sin cambios. Resuelve problemas importantes: evita fingir búsquedas, compilaciones o pruebas; diferencia el código entregado de la validación real; y evita presentar una conversación de roles como si fueran varios agentes autónomos.

La recomendación final es Solo-Engine v4.1 Final. El cambio central no es ampliar la lista de normas, sino hacerla más ejecutable:

• las restricciones irrenunciables viven en la instrucción principal del Gem;
• los SOP, esquemas y plantillas pasan a la base de conocimiento;
• el estado del proyecto se reduce y se reconcilia explícitamente;
• las capacidades se declaran según las herramientas reales de la sesión.

Qué conserva de V4

• Dos entradas claras: /ana-solo para investigación y decisión, y /ana-bmad para planificación, implementación y verificación.
• Separación epistemológica entre FACT, INFERENCE, ASSUMPTION y UNKNOWN.
• Matriz de decisión, revisión adversarial (Deep Recon) y ADR con ciclo de vida.
• Entrega de archivos completos, sin pseudocódigo ni fragmentos que se hagan pasar por un proyecto terminado.
• Pausa en límites de archivo: si la respuesta se alarga, se detiene entre archivos y no en mitad de uno.

El enfoque inspirado en BMAD es razonable, siempre que se describa correctamente. La documentación de BMAD distingue agentes, skills y flujos de trabajo; por ello, un único Gem puede usar perspectivas de producto, arquitectura, desarrollo, QA y operaciones, pero no debe afirmar que ejecutó varios agentes independientes.11014

Los problemas que V4 todavía deja abiertos

1. Demasiadas reglas repetidas

Cuando la instrucción principal, los procedimientos de ingeniería y las plantillas repiten estados, dependencias, ADR y criterios de finalización, aumenta el riesgo de que se aplique una versión parcial o contradictoria de la regla.

Corrección: la instrucción principal debe contener solo el contrato operativo: autenticidad, autorización, límites de herramientas, estados y criterios de cierre. Los detalles se consultan en documentos auxiliares.

2. El «bucle automático» necesita límites reales

Un Gem no obtiene por una instrucción la capacidad de trabajar en segundo plano, mantener una terminal persistente o continuar tras finalizar la sesión.

En V4.1, un bucle automático solo puede existir:

1. dentro de la sesión actual;
2. dentro de la autorización actual del usuario;
3. con herramientas realmente expuestas;
4. con un presupuesto explícito de reintentos;
5. con una salida obligatoria a WAITING_VERIFICATION si no hay ejecutor real.

3. «Cero dependencias» era ambiguo

No puede significar a la vez «sin runtime», «sin paquetes de terceros» y «sin archivos locales no entregados».

La definición operativa propuesta es:

• cero dependencias no declaradas;
• por defecto, cero dependencias nuevas de terceros;
• cero dependencias locales nuevas que no se entreguen completas;
• runtime, compilador, SDK, sistema operativo y plataforma anfitriona son prerrequisitos de entorno, no algo que el código pueda eliminar.

4. Código completo no equivale a proyecto verificado

V4.1 separa tres estados:

Dimensión	Pregunta que responde
DELIVERY_STATUS	¿Se entregaron completos todos los archivos necesarios?
VERIFICATION_STATUS	¿Se compiló, ejecutó o probó realmente?
ENGINEERING_STATUS	¿Hay evidencia suficiente para declarar terminado el trabajo?

Sin evidencia de ejecución, se puede entregar código completo y una revisión estática, pero el trabajo queda en WAITING_VERIFICATION. No se puede afirmar «sin errores de compilación» ni «tests en verde».

5. Proyectos nuevos y existentes requieren contratos distintos

Para un proyecto nuevo, la entrega debe incluir el cierre mínimo: configuración de construcción, entrada, fuentes, pruebas, recursos necesarios y comando de validación.

Para un repositorio existente, deben entregarse completos todos los archivos añadidos o modificados. No hace falta repetir archivos base que el usuario ya proporcionó y no cambiaron; pero si falta una interfaz, tipo o configuración necesaria para compilar, el Gem debe solicitarla en vez de inventarla.

Decisión final

Dimensión	V4	V4.1 Final
Límites de herramientas y autenticidad	4,0/5	4,8/5
Calidad de análisis, matriz y Deep Recon	4,5/5	4,8/5
Salvaguardas de ingeniería	4,6/5	4,8/5
Cierre de dependencias y entrega	4,6/5	4,9/5
Densidad y aplicabilidad de instrucciones	2,8/5	4,5/5
Recuperación y reconciliación de estado	4,2/5	4,7/5
Puntuación de auditoría	84,2/100	95,5/100

Estas puntuaciones son una evaluación de diseño y coherencia de configuración, no un benchmark de ejecución.

Arquitectura recomendada del paquete final

Archivo	Ubicación	Función
00-solo-engine-system.md	Instrucciones del Gem	Rutas, límites, estados y reglas no negociables
10-ana-solo.md	Base de conocimiento	Investigación, extracción de valor, matriz de decisión y Deep Recon
20-ana-bmad.md	Base de conocimiento	Escenarios, preflight, implementación, validación y entrega
30-artifacts.md	Base de conocimiento	Planes, ADR, registros de verificación, informe de verdad y cápsula de reanudación
40-three-pass-reading.md	Base de conocimiento	Método de lectura en tres pasadas

No conviene cargar a la vez archivos antiguos que definan los mismos conceptos: la recuperación de instrucciones podría traer reglas incompatibles.

Reglas no negociables de la versión final

1. No fingir capacidades. No declarar búsquedas, llamadas a Tavily, acceso web, ejecución, compilación, pruebas, escritura de archivos, Git, despliegues ni agentes independientes si no hay evidencia real.
2. No confundir salida con verificación. Un archivo completo puede ser entregado sin que haya sido ejecutado; la afirmación debe reflejarlo.
3. No inventar contratos faltantes. Si un archivo base o una interfaz es necesaria para compilar, se solicita; no se deduce por el nombre.
4. No ampliar el alcance en silencio. Cambios en contratos públicos, dependencias externas, credenciales, producción o datos requieren nueva autorización.
5. No fabricar éxito. No se eliminan pruebas válidas, no se endurecen datos de ejemplo, no se ocultan excepciones y no se convierten logs esperados en logs reales.
6. No cerrar sin reconciliación. El plan, el paquete de archivos, el entorno, la verificación y el ADR deben corresponder a la misma revisión.

Tavily y la investigación: adaptación por capacidad

search_depth=advanced es un parámetro real de Tavily pensado para consultas detalladas y de alta precisión; prioriza relevancia, pero puede aumentar latencia y coste.2411

Por eso, la regla correcta no es «usar Tavily Advanced», sino esta:

• usarlo solo si Tavily está realmente conectado;
• reservarlo para vacíos de evidencia decisivos;
• respetar el esquema real de la herramienta disponible;
• si no existe Tavily, degradar a las fuentes o búsquedas que sí estén disponibles;
• nunca afirmar que se ejecutó una consulta advanced cuando no hubo llamada verificable.

Además, «SEO produce información de valor» debería llamarse por defecto extracción de valor: evidencia → significado → valor para el usuario → acción → verificación. El análisis SEO se activa únicamente si el encargo trata de palabras clave, indexación, rastreo, ranking o rendimiento de contenido.

Pruebas de fallo mínimo para auditar V4.1

La configuración debe considerarse fallida si ocurre cualquiera de estos casos:

1. Sin ejecutor, el Gem dice que el código superó las pruebas.
2. Falta una interfaz local y el Gem la inventa para afirmar que compila.
3. Un arreglo modifica una firma pública y no activa revisión estructural.
4. Se entrega medio archivo y se marca DELIVERY_STATUS=COMPLETE.
5. Tavily no está disponible y el Gem afirma haber usado search_depth=advanced.

Dictamen

Elegida: Solo-Engine v4.1 Final.

V4 queda como una buena base experimental. V4.1 es más adecuada como configuración estable porque reduce la duplicación, delimita el runtime con honestidad y convierte la entrega, la evidencia y el cierre de ingeniería en contratos separados.

Si más adelante se incorpora un agente gestionado por API, MCP, un espacio de trabajo persistente o un sandbox de código, la solución no debe ser añadir descripciones ficticias de herramientas al prompt principal. Debe crearse un Runtime Adapter específico que exponga sus capacidades, permisos, persistencia y registros de ejecución.