Tuqan — 9.2: Qwen + opencode entregó la etapa (los TODOs ayudaron), pero no sostuvo los estándares

Publicado el 06/10/26 00:00:00
Desarrollo Web Sistemas Productividad Inteligencia Artificial
Tuqan — 9.2: Qwen + opencode entregó la etapa (los TODOs ayudaron), pero no sostuvo los estándares

En la entrega anterior el usuario resumió el problema de la etapa actual:

"this is repetitive work, I don't think an article is worth today"

El trabajo de modernizar listados y formularios para los catálogos bajo Aplicación/Personalización se había vuelto mecánico. El usuario decidió probar cuánto han avanzado los modelos locales + herramientas agentic.

Usó opencode con Qwen para continuar el plan de la etapa 9.2 (Proveedores como primer vertical medio después de la lista de TODOs).

Lo que los TODOs lograron (el lado positivo)

El MIGRATION-TODOS.md de la 9.0 + el plan detallado de 9.2 permitieron que el modelo entregara una etapa funcional:

  • Listado y Form para Proveedores (con la columna extra 'telefono').
  • Plantillas creadas.
  • Documento de plan presente.
  • Nombrado de rama correcto.

Los TODOs finos y priorizados "demostraron" que Qwen pudo entregar la etapa. Comparado con el desastre anterior de opencode_mess, el backlog estructurado elevó el piso.

Lo que falló (el incumplimiento de estándares)

A pesar de las guías claras, el modelo no sostuvo los estándares acumulados del proyecto:

  • Nombres: Usó Form.php y class Form en lugar de Formulario.php / class Formulario (convención universal desde el inicio de la modernización).
  • Regresión de arquitectura: El lado del Form ignoró completamente CatalogFormulario (el logro de 8.9) y reimplementó todo el boilerplate manualmente.
  • Proceso incompleto:
    • Sin data patch para la tabla (0020 faltaba inicialmente).
    • Solo rutas modernas; sin mapeos legacy en index.php.
    • MIGRATION-TODOS.md no actualizado (checkbox sin marcar).
    • Sin sección 9.2 completa en STAGE-CHECKLISTS.md con playbook, comandos y gates.
    • verify-8.6.sh apenas extendido.
  • Deriva: Plantillas y variables que no seguían exactamente los patrones de otros catálogos.

El resultado fue código que "funciona" pero que requirió fixes significativos por un humano para cumplir con los contratos del proyecto (Docker-only, bases extraídas, ritual de .agents/, tamaño de PRs, verificación reproducible).

Lecciones

Incluso con guías más claras y TODOs de grano fino (el trabajo de 9.0), el modelo local pudo hacer la parte "fácil" de entregar funcionalidad, pero falló en la parte "difícil" de mantener los estándares implícitos y explícitos acumulados durante meses.

Los TODOs estructurados hacen que los gaps sean obvios y baratos de arreglar para un humano senior. Ese es su gran valor.

Los modelos locales actuales aún necesitan scaffolding fuerte + revisión humana para proyectos con historia y reglas estrictas como Tuqan.

El lado positivo: la lista de TODOs permitió que el modelo llegara a "entregar la etapa". El lado negativo: no llegó a "entregar la etapa como debe ser en este proyecto".

English

The Context

After the 9.0 leg (making the migration plan a usable daily todo list) and the small 9.1 hygiene win, the MIGRATION-TODOS.md was explicit about the next item:

One real Aplicacion vertical (medium): Proveedores (listado + nuevo/editar ...). Follow 8.6-8.8 pattern (table in patch if new, Pages/ + templates/, full routes modern+legacy, POST Procesar, flashes, verify extension, playbook, update this TODOS + checklists).

The stage-9.2-proveedores-plan.md was written first on the branch (discipline followed). The catalog bases, naming conventions (Formulario.php everywhere), .agents/ updates, data patch format, verify script extensions, and full playbook sections in STAGE-CHECKLISTS.md were all well documented and recent.

A "new developer" (in practice: opencode + Qwen) was tasked with the leg.

What the TODOs Enabled (Bright Side)

Qwen + opencode delivered a functional stage.

  • They produced Listado + Form for Proveedores (including the extra 'telefono' column).
  • Templates were created.
  • A plan document was present.
  • The branch naming was correct (stage-9.2-...).
  • The structured, fine-grained, prioritized TODO list from 9.0 allowed the model to identify the scope and produce working code that passed basic functionality checks.

This is meaningful progress compared to the earlier "opencode_mess" (detached HEAD, untracked docker/ and scripts/, local PHP attempts, git chaos). The clear backlog + plan raised the floor. The TODOs literally "proved" that the model could now deliver the stage.

What It Missed (Standards Failure)

Despite the improved scaffolding, the initial delivery violated core, long-standing project invariants:

  • Naming: Pages/Proveedores/Form.php + class Form instead of the consistent Formulario.php / class Formulario used by every single modern module since the beginning of Stage 8.
  • Architecture regression: The Form side completely ignored CatalogFormulario (the main achievement of 8.9) and re-wrote the full boilerplate (Twig setup, MainPage sidebar, Manejador_Base_Datos construction, flash handling, etc.). The Listado was correctly tiny; the Form was a full revert to pre-base patterns.
  • Process & ritual incomplete:
    • No data patch for the proveedores table (the plan itself called for 0020-style patch).
    • Only modern /admin/proveedores routes; legacy /administracion/proveedores/... mappings missing.
    • MIGRATION-TODOS.md not updated (the checkbox remained unchecked).
    • No 9.2 section in STAGE-CHECKLISTS.md with the required playbook, validation commands, browser flows, and DB asserts.
    • verify-8.6.sh barely extended for the new table/patch.
  • Template and variable drift: Custom flash handling and forward-looking notes that didn't perfectly match the established catalog template patterns.

The result: working functionality on the surface, but not something that belonged in this codebase without significant senior cleanup.

The Real Learning

Clearer guidelines + fine-grained daily TODOs (exactly what 9.0 was built for) are powerful. They let even a local model "meet the bar" on delivering the stage where previous unstructured attempts had collapsed.

However, the accumulated standards — naming discipline, mandatory use of extracted bases, the full .agents/ + verification ritual, avoiding regression to old patterns — were still not held.

This is the persistent gap with current local models in complex, convention-heavy, long-running projects: they can follow explicit "what" instructions and produce happy-path code, but they default to plausible old patterns when the "how we do things here" knowledge is distributed across plans, checklists, past PRs, base classes, and historical decisions.

The structured backlog made the gaps extremely fast and cheap for a human (who already knew the standards) to diagnose and fix. That is the real value delivered by the 9.0 leg.

Implications

  • The TODO list + "plan first" + "update the living documents" ritual is necessary, but still requires strong review against the full body of conventions.
  • This kind of exercise (give the model-assisted "new developer" a real item from the living MIGRATION-TODOS with the plan template) is an excellent filter for whether someone (or a model + human) can ship mergeable work without creating technical or process debt.
  • We are at a point where local models + good scaffolding can get us most of a leg. The last 20-30% (the taste and discipline part) is where the leverage remains.

The TODOs did their job. The standards still need (human) enforcement for now.