pr-simplify

Simplifica el cambio

Una pasada de edición por el autor del cambio: ejecútala en tu propia rama antes de abrir el PR, y de nuevo antes de enviar reparaciones grandes. Precede a la revisión y nunca la reemplaza. Hereda el alcance de la tarea y la autoridad de reparación; una solicitud solo de revisión recibe hallazgos en lugar de ediciones. El flujo de trabajo del mantenedor elegido gestiona la publicación, revisión y fusión.

El diff es una propuesta. Que las pruebas pasen demuestra que funciona, no que su arquitectura o cada prueba añadida sean necesarias.

Reglas: las secciones "Prioridades de diseño", "Un solo dueño, migración completa", "Salvaguardas de tiempo de ejecución y código" y "Producto y validación" del archivo raíz AGENTS.md, más el AGENTS.md con alcance más cercano. Los pasos 2 y 3 aplican cada regla a cada archivo modificado.

1. Re-derivar la corrección completa más pequeña

Lee el resultado del usuario y el alcance más reciente, el diff completo contra la base de fusión objetivo, y la evidencia conservada. Reutiliza el contexto de la sesión ya recopilado. Luego pregunta:

Comenzando desde la base, ¿cuál es la corrección completa más pequeña usando los dueños ya presentes? ¿Seguiría introduciendo esta arquitectura?

Inspecciona primero los módulos, estado, adaptadores y andamios de prueba más grandes añadidos. Lee sus llamadores directos y el historial relevante: un comportamiento aparentemente redundante puede proteger una configuración ya enviada o una regresión anterior. El alcance es el sistema modificado y las rutas que reemplaza.

Rastrea cada fragmento modificado hasta el resultado indicado. Un fragmento que sirve a otro objetivo abandona este cambio: elimínalo o muévelo a su propio PR.

Cuenta las líneas modificadas no mecánicas. Por encima de aproximadamente 800, o aproximadamente 500 para lógica compleja, nombra la etapa coherente más pequeña que pueda llegar primero y reduce el cambio a esa etapa.

Terminado cuando puedas enunciar el defecto, el invariante requerido y la corrección completa más pequeña en una oración cada uno, y cada fragmento restante sirve a esa corrección.

2. Eliminar arquitectura innecesaria

Aplica cada simplificación soportada en el diff:

• Un solo dueño de la decisión. Mueve la política repetitiva del lado del llamador a la operación que posee la decisión. Migra los llamadores afectados y elimina las implementaciones antiguas, las exportaciones y las ramas de reparación. Diferentes transportes pueden compartir una decisión manteniendo sus propios contratos de entrega.
• Estado existente primero. Cuestiona nuevos esquemas, gestores, cachés y representaciones combinadas. Reutiliza un dueño existente cuando su ciclo de vida, autoridad, atomicidad y limpieza encajen. Elimina una migración propuesta solo cuando sea genuinamente innecesaria; conserva la migración que mantiene la configuración y el estado existentes funcionando después de la actualización. El nuevo estado pertenece a un campo que lo significa.
• Elimina la ruta redundante. Elimina renderizadores paralelos, analizadores duplicados, operaciones de ciclo de vida falsas usadas solo para obtener un resultado, estado derivado que los llamadores ya pueden obtener, y envoltorios que solo reenvían o renombran. Prefiere una representación más simple en lugar de modos alternativos alrededor de la antigua.
• Pule al final. En cada fragmento modificado, conserva solo lo que un mantenedor del archivo circundante escribiría:
  • comentarios que expliquen propiedad, ciclo de vida, ordenamiento o restricciones;
  • comprobaciones y bloques try/catch que coincidan con el módulo circundante y protejan estados reales;
  • tipos reales en lugar de conversiones de tipo que desinfectan (as any, as unknown as T, ampliar y luego afirmar);
  • variables y ayudantes que añadan significado de dominio, eliminen duplicación o simplifiquen el flujo de control;
  • shims, alias, reintentos y alternativas respaldados por un contrato con nombre enviado y un plan de eliminación;
  • nombres, flujo de control, importaciones y formato que coincidan con el archivo circundante.

Preserva la corrección solicitada y el comportamiento soportado, no el diseño accidental de la propuesta. Mantén diferencias reales de dominio y compatibilidad pública justificada. Cuando el historial (git log -p -S <símbolo>) deje poco claro el propósito de una ruta, consérvala e infórmalo. Informa nuevas decisiones de producto, contratos rotos, limpieza no relacionada y reemplazo destructivo de ramas como hallazgos para el dueño.

3. Conservar pruebas para fallos

Para cada grupo de pruebas añadido o modificado y sus ayudantes de configuración, nombra el fallo observable distinto que detecta.

Conserva regresiones para el defecto real y límites distintos: ordenamiento, cancelación, autoridad obsoleta, reinicio, rechazo, errores reales y diferencias de consumidores afectados. Conserva guardianes de contrato estáticos que protejan de forma independiente un límite real. Elimina casos duplicados de la misma ruta, ecos de simulaciones, aserciones incidentales de copia de campo o redacción, aserciones sobre valores definidos estáticamente, pruebas que solo prueban que la lógica eliminada se ha ido, pruebas de implementaciones obsoletas, y andamios o enlaces de prueba solo para producción. Consolida casos útiles en un conjunto de pruebas de un dueño existente.

Eliminar pruebas nunca debilita las aserciones, la cobertura de límites reales o las líneas base que permanecen.

Terminado cuando cada grupo de pruebas restante tiene un fallo nombrado.

4. Probar el cambio más pequeño y pasarlo

Agrupa las ediciones, luego vuelve a ejecutar la reproducción y las comprobaciones enfocadas para los contratos modificados y los consumidores afectados. Reutiliza evidencia cuyas entradas no hayan cambiado. Una afirmación conservada de reinicio, actualización o transporte necesita evidencia aplicable. El flujo de trabajo existente selecciona comprobaciones más amplias.

Terminado cuando el diff completo es inspeccionado, cada regla tiene un veredicto para cada archivo modificado, las simplificaciones soportadas se aplican, las rutas reemplazadas son inalcanzables y el comportamiento afectado aún tiene evidencia. Ningún cambio es un resultado válido cuando la forma existente está justificada. Apunta a código neto negativo, no a una cuota de eliminación.

Informa en el cuerpo del PR o en la evidencia de la tarea existente: la responsabilidad o maquinaria que desapareció, el comportamiento aún protegido, y los deltas de producción/prueba contra la base de fusión. Etiqueta una reducción contra una revisión anterior por separado del delta de todo el cambio. Nombra cualquier crecimiento necesario restante o decisión no resuelta.

Luego abre o actualiza el PR. Después de reparaciones posteriores, simplifica solo los nuevos cambios y los dueños que tocan antes de enviarlos.