curiositech/windags-skills

Refactorización de Tiempo de Ejecución con Autoridad en el Backend

Refactoriza solo después de que puedas decir exactamente dónde vive la verdad de ejecución y cómo la IU la lee.

Cuándo Usarlo

• La IU sintetiza gráficos, fases o elecciones de proveedores que el backend no entiende.
• Reiniciar o reconectar cambia el estado visible de ejecución porque el frontend almacenó en caché la autoridad.
• Esquemas antiguos y nuevos, formatos de inicio o tipos de nodo coexisten en la ruta de autoría activa.
• La aprobación, revisión o ejecución descendente depende de una reconstrucción solo del frontend.

NO para

• Limpieza visual cosmética sin cambios en la propiedad de ejecución.
• Refactorizaciones de componentes aislados donde el contrato del backend ya es autoritario.
• Implementar nuevas funciones de negocio antes de eliminar la costura de autoridad dividida.
• Trabajo puro de rendimiento del backend cuando la arquitectura ya tiene una única fuente de verdad.

Puntos de Decisión

flowchart TD
  A[Solicitud de refactorización de flujo de trabajo] --> B{¿Puede la IU aún inventar la verdad de ejecución?}
  B -->|No| C[Usa un dominio o skill de IU más específicos]
  B -->|Sí| D[Inventariar comandos, consultas y costuras de eventos]
  D --> E{¿Cada acción del usuario puede mapearse a un comando, consulta o evento?}
  E -->|No| F[Congela el contrato antes del trabajo de funcionalidad]
  E -->|Sí| G[Separar el estado de proyección del estado propiedad del backend]
  G --> H{¿Las rutas de compatibilidad heredadas siguen activas?}
  H -->|Sí| I[Muévelas a bordes de migración o elimínalas]
  H -->|No| J[Añade evaluadores, consultas de inicio seguras para reproducción y suscripciones a eventos]
  I --> J
  J --> K[Validar la preparación para reconexión, aprobación y flujo descendente]

Usa este modelo de enrutamiento primero:

• Si la IU no puede describirse como comando -> transición del backend -> consulta o proyección de eventos, la costura sigue siendo incorrecta.
• Si una ruta de "compatibilidad temporal" está en la ruta activa, trátala como deuda de refactorización, no como una funcionalidad.
• Si reiniciar o reconectar no puede reconstruir el estado visible solo a partir de la verdad del backend, la refactorización está incompleta.

Método de Trabajo

1. Inventariar el cerebro dividido

Encuentra todos los lugares donde la IU:

• genera o muta la verdad de ejecución
• inventa fases que el backend desconoce
• simula ejecución en rutas de código activas
• conserva esquemas antiguos y nuevos en la misma ruta de autoría
• mezcla niveles de enrutamiento abstractos con IDs de proveedores exactos

2. Congelar el contrato

Define solo tres clases:

• Comandos: iniciar, detener, aprobar, reanudar, mutar
• Consultas: estado de inicio, carga útil de revisión, instantánea de ejecución, estado del proveedor
• Eventos: transiciones autoritarias, veredictos de evaluadores, estado de compuertas, marcas de reproducción

Si una acción de la IU no puede expresarse como una de estas, la arquitectura sigue siendo turbia.

3. Normalizar la propiedad del estado

Divide los almacenes en:

• estado de entrada del contrato
• estado de proyección de instantánea del backend
• estado de diseño de la IU

No permitas que ningún almacén posea tanto la verdad de ejecución como las preocupaciones de diseño.

4. Eliminar costuras de compatibilidad activas

Prefiere la eliminación sobre "soportar ambos por ahora".

Eliminaciones típicas:

• compatibilidad de esquemas singular y plural en la autoría activa
• simulación en navegador o demo en el tiempo de ejecución de escritorio activo
• tipos de nodo obsoletos en la ruta principal
• resúmenes de revisión duplicados
• múltiples formatos de inicio o importación

5. Añadir evaluadores antes de confiar en la refactorización

Cada nodo de implementación debe tener:

• un evaluador de salida local para corrección
• un evaluador de preparación descendente para seguridad del contrato
• una ruta de reinicio o reconexión que se rehidrate desde la verdad del backend, no desde suposiciones del frontend

Modos de Falla

Proyección disfrazada de autoridad

Síntoma: la IU parece "solo lectura" pero ensambla silenciosamente la verdad de fase, gráfico o proveedor localmente.

Solución: mueve esa lógica a comandos o consultas del backend y trata al frontend como un proyector.

Calcificación de la costura de compatibilidad

Síntoma: "soportar ambos por ahora" permanece en la ruta activa durante semanas y se convierte en la arquitectura real.

Solución: empuja la compatibilidad a bordes de migración unidireccionales con una fecha de eliminación explícita o elimínala ahora.

Aprobación sin inspeccionabilidad

Síntoma: un humano puede aprobar trabajo que no puede inspeccionar porque la carga útil de revisión es parcial o sintetizada por el frontend.

Solución: el backend debe emitir la carga útil exacta de revisión; la IU solo la renderiza.

Inicio hostil a la reproducción

Síntoma: reiniciar la aplicación cambia el estado visible o pierde la posición de la compuerta porque el frontend almacenó en caché la autoridad.

Solución: el inicio debe ser una consulta contra la verdad del backend más la reproducción de eventos, no una reconstrucción del almacén.

Shibboleth

Si reiniciar la aplicación cambia el estado visible de ejecución sin ningún evento nuevo del backend, la autoridad sigue dividida.

Ejemplo Práctico

Editor de flujo de trabajo Tauri con lógica de fase propiedad del frontend

Problema:

• Los stores de React generaban el gráfico, inferían el estado de fase y normalizaban los niveles de proveedor.
• La ejecución del backend usaba un contrato diferente, por lo que los flujos de revisión y reinicio se desviaban.

Ruta de refactorización:

1. Inventariar cada lugar donde la IU inventó la verdad de ejecución.
2. Colapsar las interacciones de ejecución a comandos, consultas y eventos.
3. Mover la normalización de proveedores y las transiciones de fase detrás de los comandos del backend.
4. Eliminar las uniones de formato de inicio de la ruta de autoría activa.
5. Añadir compuertas de evaluadores para que el trabajo descendente solo proceda de salidas validadas por el backend.

Condición de éxito:

• Al reiniciar, la IU reconstruye el mismo estado visible a partir de la instantánea del backend más eventos.
• Las pantallas de aprobación renderizan una carga útil de revisión emitida por el backend, no una recomposición de React.

Guía de Bifurcación

Bifurca cuando el trabajo se separa limpiamente:

• Carril de contrato: inventariar costuras de autoridad dividida y definir comandos, consultas y eventos.
• Carril de eliminación: eliminar capas de compatibilidad, tipos de nodo obsoletos y uniones de formato de inicio.
• Carril de verificación: añadir compuertas de evaluadores, pruebas de reproducción y cobertura de reinicio o reconexión.

Mantén las decisiones finales de propiedad en el carril principal para que un único actor decida qué posee realmente el backend.

Puertas de Calidad

• La IU no puede fabricar verdad de gráfico, fase, proveedor o compuerta localmente.
• Cada acción del usuario se mapea a un comando, consulta o evento.
• El estado de ejecución sobrevive al reinicio y la reconexión solo a partir de la verdad del backend.
• Las cargas útiles de revisión y aprobación son emitidas por el backend y renderizadas por la IU.
• La lógica de compatibilidad vive solo en bordes de migración, no en la ruta activa.
• La ejecución descendente se detiene ante una falla del contrato ascendente.
• Los IDs de proveedores exactos y las elecciones de modelo son visibles en el límite del contrato.
• Las pruebas cubren rutas de reinicio, reconexión, aprobación y falla de evaluadores.

Mapa de Referencia

• references/architecture-patterns.md — patrones de contrato de flujo de trabajo propiedad del backend y divisiones de propiedad de estado.
• references/windags-lessons.md — lecciones concretas de una migración real de tiempo de ejecución con autoridad dividida.