# Manual práctico de Commands

Estado auditado: 10 de agosto de 2026. Este manual describe qué se puede pedir hoy a `gpt-oss:20b` con `think=low` en el diseñador LL-Dominus. No es un catálogo teórico de la fachada.

## Criterio

- **VERDE (42):** existe evidencia determinista y evidencia real GPT-OSS/Chromium suficiente, sin un fallo actual relevante para la forma recomendada.
- **AMARILLO (14):** la operación existe, pero la evidencia real es insuficiente o conserva una ambigüedad, omisión o caso fallido conocido.
- **ROJO (2):** las pruebas reales muestran que no es una forma de trabajo fiable actualmente.

Total auditado: **58 capacidades**. Las clasificaciones están en [green.md](green.md), [yellow.md](yellow.md) y [red.md](red.md).

## Evidencia principal utilizada

- `commands_real_usage`: 12 órdenes reales compuestas; 10 se aplicaron inicialmente y los dos fallos eran de validación secuencial ya corregida. Mediana de 2,08 comandos y 1,66 s.
- `commands_real_usage_revalidated`: los 12 planes guardados pasan, con Undo/Redo 12/12 y rollback atómico.
- `commands_scope_selection`: siete controles plurales reales correctos para mover, redimensionar, alinear, distribuir, duplicar, borrar y cambiar propiedad.
- `commands_scope_global` y `commands_scope_inventory`: el inventario final resolvió 5/5 órdenes globales sobre todos los textos, incluido el texto anidado en TTable; los fallos anteriores explican por qué hay que formular el tipo de forma explícita.
- `autonomous_closure_final`: 23 PASS, 1 FAIL y 1 ambigüedad humana en 25 órdenes end-to-end; sin fallos actuales de contrato, scope o ejecución. El único fallo evaluable omitió el ancho posterior a una inserción.
- `factura_phase1_table_create_ref` y `factura_phase1b_table_sequence`: creación y estructura de TTable; 5/6 tras corregir la precondición de línea. El fallo restante era la semántica del número de columnas, posteriormente comprobada en las fases de factura.
- `20260810_132238_factura2_table_cell`: 5/6 casos GPT-OSS reales y 10/10 deterministas para contenido de celda.
- `20260810_135316_factura3_fields_commands`: 8/8; HEADER, DETAIL, texto combinado, fecha con `Transform` y rechazo seguro de un campo inexistente.
- `20260810_142158_factura4_repair_commands`: dos reparaciones válidas de cuatro; una factura estructural se aplicó, pero quedó visualmente parcial.
- `20260810_150204_factura5_visual_planning_commands`: la factura completa final devolvió planes vacíos; una ejecución exploratoria produjo planes inválidos de 33/43 comandos.
- Informes específicos `commands_table*`: pruebas reales de columnas, líneas, borde, padding, radio, lados, separadores, fórmulas y zebra.

No se ejecutó ninguna inferencia ni prueba nueva para elaborar este manual.

## Tamaño práctico de una orden

La recomendación operativa es **un máximo de 5 comandos por instrucción**:

- **1–3 operaciones:** zona mejor demostrada y preferida.
- **4–5 operaciones:** uso práctico razonable cuando son homogéneas y explícitas.
- **6–10 operaciones:** hay casos correctos, pero ya aparecen omisiones; dividir si es posible.
- **20–30 operaciones:** riesgo alto. Las pruebas complejas produjeron planes incompletos, inválidos o una factura solo parcial.

No se asigna un porcentaje inventado por tramo. El límite recomendado de cinco procede de los planes cortos repetidamente correctos frente a los fallos observados en planes largos.

## Protección actual

- **Dry-run:** simula secuencialmente el mismo plan y detecta referencias, índices, celdas, propiedades o comandos inválidos antes de aplicarlo.
- **Reparación única:** ante un dry-run inválido, GPT-OSS recibe el diagnóstico y puede devolver un plan corregido una sola vez.
- **Rollback:** si el plan no es válido o falla, restaura el documento y evita una aplicación parcial.
- **Undo/Redo:** un plan aplicado forma una única transacción reversible; los controles registrados pasaron 12/12.

Estas protecciones **no detectan una intención incompleta pero contractualmente válida**: pueden aceptar una factura sin total, una columna sin el ancho pedido, estilos omitidos, geometría solapada o el objeto equivocado ante una frase ambigua. Tampoco convierten una macro grande en un buen diseño visual.

## Borrar todo el diseño

`borra todo el diseño` es **AMARILLO** como orden independiente. La infraestructura puede enumerar IDs globales y Undo puede recuperar un plan aplicado, pero no existe una repetición real específica suficiente del borrado global. Además, un borrado semánticamente correcto deja el lienzo vacío: dry-run no debe impedirlo, y guardar/cerrar después puede hacer que la recuperación práctica dependa del usuario.

Forma recomendada: guardar una copia, seleccionar manualmente solo los objetos que se quieren retirar y pedir `borra los objetos seleccionados`.

## Uso recomendado hoy

Trabajar de forma conversacional e incremental: seleccionar el ámbito, pedir una operación pequeña, comprobar visualmente, y continuar. Para tablas: crear tabla, crear una línea, alcanzar sus columnas finales, añadir contenido, aplicar estilos y ajustar anchos en órdenes separadas. El flujo completo propuesto está en [invoice-step-by-step.md](invoice-step-by-step.md).