Backlog de clústeres de refactorización

Clasificados por probable reducción de LOC, seguridad y amplitud.

1. Scaffolding de configuración y seguridad de plugins de canal

Clúster de mayor valor. Formas repetidas en muchos plugins de canal: config.listAccountIds, config.resolveAccount, config.defaultAccountId, etc.

Ahorro esperado: ~250-450 LOC. Riesgo: Medio.

2. Boilerplate de singleton de runtime de extensiones

Muy seguro. Casi todas las extensiones tienen el mismo holder de runtime. Ahorro esperado: ~180-260 LOC. Riesgo: Bajo.

3. Pasos de prompts y parches de configuración de onboarding

Gran superficie. Ahorro esperado: ~300-600 LOC. Riesgo: Medio.

4. Fragmentos de config-schema multi-cuenta

Fragmentos de esquema repetidos entre extensiones. Ahorro esperado: ~120-220 LOC. Riesgo: Bajo a medio.

5. Arranque del ciclo de vida de webhook y monitor

Buen clúster de valor medio. Ahorro esperado: ~150-300 LOC. Riesgo: Medio a alto.

6. Limpieza pequeña de clones exactos

Bucket de limpieza de bajo riesgo. Ahorro esperado: ~30-60 LOC. Riesgo: Bajo.

Clústeres de test

  • Fixtures de eventos de webhook LINE: ~120-180 LOC
  • Matriz de autenticación de comandos nativos de Telegram: ~80-140 LOC
  • Setup de ciclo de vida de Zalo: ~50-90 LOC
  • Tests de opciones no soportadas de Brave llm-context: ~30-50 LOC

Orden sugerido

  1. Boilerplate de singleton de runtime
  2. Limpieza pequeña de clones exactos
  3. Extracción de builders de configuración y seguridad
  4. Extracción de helpers de test
  5. Extracción de pasos de onboarding
  6. Extracción de helper de ciclo de vida del monitor