# Checkpoint IA experimental al 70% Estado congelado: 2026-08-10/11. Este es el punto de reanudación del módulo IA. Resume evidencia final conservada; no convierte resultados históricos obsoletos en estado actual. ## Estado operativo Commands está listo para uso experimental con `gpt-oss:20b`, `think=low`, no para órdenes largas de composición completa. La evidencia final end-to-end conserva 23 PASS, 1 FAIL y 1 ambigüedad humana en 25 órdenes (23/24 evaluables, 95,83%), sin fallos demostrados de contrato, scope o ejecución; Undo 12/12 y Redo 12/12. Véase [cierre autónomo](../tests/ia/results/autonomous_closure_final/closure-report.md). La clasificación de capacidades vigente es 42 VERDE, 14 AMARILLO y 2 ROJO. No debe leerse como promesa teórica: procede del [manual práctico](../tests/ia/results/commands_capability_manual/README.md), que enumera la forma de pedir cada capacidad y sus límites. ## Arquitectura Commands El flujo es panel IA → `IA/ollama.php` → contrato/normalización → dry-run secuencial → aplicación transaccional en el diseñador. Las primitives operan sobre APIs públicas de los objetos y no deben construir estructura privada de `TTable`. La validación/aplicación es secuencial sobre el estado actualizado. Un snapshot protege la operación completa: si falla un command se restaura documento, selección e historial. La evidencia determinista de transacción, rollback y Undo/Redo está en [sequential_transaction](../tests/ia/results/sequential_transaction/report.md) y la revalidación A–L en [commands_real_usage_revalidated](../tests/ia/results/commands_real_usage_revalidated/summary.md). ## Capacidades y primitives Hay operaciones de propiedades, mover/redimensionar, borrar, crear, alinear, distribuir, ordenar, duplicar y operaciones de tabla. El catálogo de capacidad recomendado, con verde/amarillo/rojo y límites de formulación, es el [manual Commands](../tests/ia/results/commands_capability_manual/README.md). No ampliar el prompt ni añadir parsers por fallos legacy aislados. El cierre final recomienda no reabrir scope, inventario, transacciones, refs, UTF-8 ni primitives sin una regresión real reproducible. ## TTable y objetos de celda - Crear `TTable` y usar `target.ref` está cubierto por [Factura fase 1](../tests/ia/results/factura_phase1_table_create_ref/report.md): escenarios A–J y 21/21 primitives de tabla sobre una misma ref. - Los objetos visuales dentro de celdas usan `create` con `targetCell`; la tabla crea/vincula el objeto real sin que Commands construya `hSections`, `aLines`, `aCells` ni `hContent` privado. Resultado final: 5/6 GPT-OSS, 10/10 deterministas en [Factura fase 2](../tests/ia/results/20260810_132238_factura2_table_cell/report.md). - Campos/variables compactos: 8/8, sin campos inventados, en [Factura fase 3](../tests/ia/results/20260810_135316_factura3_fields_commands/summary.json). ## Dry-run y reparación El dry-run da diagnóstico antes de aplicar y habilita una reparación acotada. En [Factura fase 4](../tests/ia/results/20260810_142158_factura4_repair_commands/summary.json) se aplicaron 2 de 4 casos; 2 reparaciones tuvieron éxito y 2 no. Es una ayuda, no una garantía de completar una factura compleja. ## Scope e inventario Selection y global son ámbitos distintos. La selección múltiple tiene evidencia real en [scope selection](../tests/ia/results/commands_scope_selection/README.md). El estado final para global es el [inventario plano](../tests/ia/results/commands_scope_inventory/summary.md): objetos raíz y anidados de `TTable` se aplanan, deduplican y se identifican de forma determinista; los controles finales lograron recall global 100% en los cinco casos de negrita, sin objetos extra ni errores contractuales. Se conserva [scope global](../tests/ia/results/commands_scope_global/summary.md) como antecedente de la limitación que el inventario posterior resolvió. ## UTF-8 Los prompts físicos finales están limpios en UTF-8. El cierre separa fallos legacy de los flujos productivos: no atribuir a UTF-8 los fallos aislados de representación histórica. ## Límite práctico de planes largos La zona recomendada es 1–3 operaciones por instrucción; 4–5 solo si son homogéneas y explícitas. A partir de 6–10 aparecen omisiones y debe dividirse. El máximo práctico recomendado es aproximadamente 5 commands. Fuente: [manual Commands](../tests/ia/results/commands_capability_manual/README.md). La factura incremental es el enfoque correcto: construir/validar primero estructura, después celdas, campos, estilo y totales en operaciones cortas. La planificación visual de factura completa sigue siendo una limitación: en el último informe, los planes de factura completa quedaron vacíos y la reparación no los convirtió en aplicables. Véase [Factura fase 5](../tests/ia/results/20260810_150204_factura5_visual_planning_commands/report.md). ## Benchmark y modelo El benchmark controlado conserva la recomendación: GPT-OSS por defecto y Big Pickle como proveedor manual; Big Pickle obtuvo más PASS, pero el router simple no redujo de forma suficiente la incertidumbre de selección. Véase [recomendación controlada](../tests/ia/results/controlled_gptoss_vs_big_pickle/product-recommendation.md). Para repetir una comparación con modelo grande, usar los prompts físicos del [control CORE](../tests/ia/results/core_large_model_control/README.md), sin adaptarlos. ## Punto exacto para retomar 1. Mantener el checkpoint como baseline y ejecutar primero una batería corta sobre cambios reales. 2. No abordar una factura completa monolítica. Elegir un flujo incremental de 1–3 operaciones y medirlo sobre datos reales. 3. Si reaparece un fallo, clasificarlo primero: modelo/prompt, contrato, scope, dry-run, aplicación o renderer; no modificar el producto hasta tener reproducción mínima. 4. Solo reabrir capacidad amarilla/roja con un caso concreto y una prueba de regresión estable.