CovD831/flujo-de-trabajo-de-rearquitectura

Flujo de trabajo de rearquitectura

Utilice esta habilidad para convertir un rediseño de arquitectura en un paquete listo para desarrollo. El resultado no es meramente un diagrama: es un contrato acotado de lo que se construirá, cómo migrará, cómo se probará y qué queda sin soporte. Trate la rearquitectura como un programa de migración continua. Cada paquete es un incremento de entrega revisable, no una promesa de especificar o implementar todo el sistema futuro.

Principios operativos

1. Separe autoridad de intención. Lea primero el código actual, las pruebas, la autoridad de arquitectura y las instrucciones del repositorio. Marque los documentos de rediseño como objetivo, plan o evidencia; nunca los presente como comportamiento actual.
2. Nombre las cosas existentes. Asigne cada módulo propuesto a clases, contratos, registros, almacenes o puntos de entrada actuales. No oculte contenido existente detrás de sustantivos inventados.
3. Haga explícita la propiedad. Indique qué posee y qué no debe poseer cada límite, quién escribe hechos duraderos, quién autoriza mutaciones y quién posee la recuperación.
4. Gane abstracciones de consumidores reales. Admita una nueva abstracción solo cuando un consumidor real elimine una dependencia nombrada, unifique un registro real o haga aplicable un invariante. Una abstracción genérica normalmente necesita dos consumidores; un límite de seguridad estrecho puede admitirse para uno solo.
5. Comience con un segmento vertical real. Conserve un fixture heredado y agregue un fixture del límite objetivo para el mismo escenario. Un grafo sintético puede probar mecánicas pero no puede probar la arquitectura.
6. Congele los contratos antes del reemplazo. Defina entradas, salidas, autorización, identidad, idempotencia, fallos, persistencia, recuperación y compatibilidad antes de eliminar una dependencia concreta.
7. Trate el rendimiento como evidencia, no como justificación. Preserve la autoridad, la compatibilidad duradera y la recuperación primero; luego mida cargas de trabajo equivalentes contra la ruta actual.
8. Mantenga los documentos mantenibles. Asigne a cada afirmación un propietario canónico, mantenga visible el estado actual/objetivo/historial y enlace a la política en lugar de copiarla entre documentos.
9. Planifique para la entrega sucesiva. Cada incremento declara entregables, aplazamientos, su siguiente desencadenante de avance y la evidencia de promoción requerida.

Flujo de trabajo y carga de módulos

Nivel 1 (L1) significa límites del sistema, Nivel 2 (L2) significa contratos estables de módulo/límite y Nivel 3 (L3) significa detalle de implementación específico de tarea. Asigne las etiquetas existentes de un proyecto a estos significados en lugar de introducir una segunda taxonomía.

Dimensione correctamente primero. Lea references/deliverable-matrix.md y seleccione el paquete más pequeño que haga revisable la siguiente decisión. Las fases siguientes son la ruta completa, no una lista de verificación obligatoria para cada solicitud. Cargue las otras referencias solo cuando su fase o preocupación correspondiente esté activa.

Cada paquete o incremento de migración debe declarar un horizonte de entrega. La matriz de entregables posee el esquema, la reducción solo de diseño, los aplazamientos y las condiciones de avance.

Fase 0 — Resolver autoridad y línea base

• Lea las instrucciones del repositorio, README, guía de desarrollo y autoridad de arquitectura si existen.
• Busque registros de orientación, documentación, lanzamiento, migración, tarea y traspaso antes de concluir que no existe un programa de rearquitectura anterior.
• Para cada programa activo relevante para la solicitud, lea su último registro de incremento, decisiones de revisión, aplazamientos no resueltos, afirmaciones L1/L2 abiertas, ADR y la siguiente tarea registrada antes de definir nuevo alcance.
• Verifique el desencadenante de avance anterior y la evidencia de promoción. Si alguno no se cumple, o si queda un hallazgo bloqueante abierto, presente el estado y las opciones al usuario antes de continuar. Si el usuario autoriza una excepción, registre la razón, el aprobador y el alcance afectado en el registro de incremento actual.
• Identifique la jerarquía fuente y la revisión exacta de la línea base. Inspeccione los puntos de entrada, propietarios de estado/datos, persistencia, pruebas, ejemplos y registros de extensión actuales cuando estén presentes.
• Registre lo que está implementado, lo que es intención objetivo y lo que es desconocido.
• Antes de afirmar un acoplamiento reducido, cree un inventario de dependencias o registros reproducible: un comando/script reejecutable, una salida o informe verificado en el repositorio, y el mismo método reutilizado para la comparación antes/después.

Siga el libro de tareas, sistema de incidencias y formato de traspaso existentes del repositorio. No requiera una herramienta de colaboración particular y no use el historial de conversación como autoridad de arquitectura.

Fase 1 — Posicionamiento y alcance

Registre:

• qué es el sistema y quién construye sobre él;
• el problema causado por el acoplamiento o crecimiento actual;
• el límite de despliegue de primera etapa;
• no objetivos y capacidades aplazadas;
• ventajas acotadas y la línea base de comparación para cada afirmación.

Al mismo tiempo, establezca un presupuesto de complejidad. Cargue references/document-and-complexity-gates.md para el presupuesto, las reglas de propiedad de documentos y las condiciones de parada. Prefiera afirmaciones acotadas sobre palabras como "más modular" o "más escalable."

Puertas de decisión del usuario

No infiera la intención del producto a partir del código o diagramas. Cuando la evidencia del repositorio no pueda responder una pregunta material sobre alcance, propiedad, implementación, compatibilidad, seguridad, criterios de éxito u orden de migración, haga una pausa y pregunte al usuario. Agrupe las opciones relacionadas, muestre los hechos observados y las compensaciones, y recomiende un valor predeterminado conservador cuando esté justificado.

Use references/user-decision-gates.md para las preguntas específicas de etapa y las ubicaciones de registro duraderas. Si el usuario delegue explícitamente una elección material, seleccione la opción reversible recomendada o mejor respaldada, registre la delegación y las suposiciones, y continúe. Haga explícitas las suposiciones reversibles no materiales en lugar de bloquear el progreso.

Fase 2 — Arquitectura objetivo de nivel 1

Defina los principales subsistemas o planos de coordinación, autoridades de estado/datos y escritores únicos, propiedad de identidad, dirección de dependencias, punto de entrada de la aplicación, límite de proceso/despliegue y formas de comunicación controladas.

L1 es obligatorio y explícito para el objetivo dentro del alcance antes de la dirección de implementación. No necesita describir cada módulo futuro, pero no puede dejar ambigua la propiedad, dirección de dependencias o alcance de despliegue. Nombre las preguntas L1 no resueltas con un propietario y una puerta de decisión.

Cargue references/architecture-contracts.md para las reglas de diagramas L1 y los esquemas L2/L3/interfaz utilizados en fases posteriores.

Fase 3 — Mapeo actual a objetivo

Para cada punto caliente actual, clasifique la primera acción como retener, exponer, adaptar, dividir, consolidar, deprecar o eliminar. Registre el propietario actual, el propietario destino, la ruta de comunicación/persistencia preservada y la puerta de eliminación. Mantenga el horizonte de entrega como el propietario canónico de los aplazamientos detallados.

No cree un documento solo porque un tema sea interesante. Encuentre el propietario canónico primero; cree un nuevo documento solo cuando la propiedad, el estado, el público o el ciclo de vida sea materialmente diferente.

Fase 4 — Contratos de módulo de nivel 2

Cree un contrato L2 por módulo estable o límite entre módulos. Cubra responsabilidad y no responsabilidad, componentes actuales, servicios proporcionados/requeridos, autoridad de escritura, llamadas/visibilidad de datos permitidas, ciclo de vida/fallo, compatibilidad y decisiones aplazadas a la implementación.

L2 puede permanecer incompleto en el primer paquete. Marque las afirmaciones significativas como establecidas, condicionales o abiertas. Cada opción abierta necesita un experimento acotado, umbral de evidencia o puerta de implementación que pueda resolverla; no invente precisión por apariencia.

Use las reglas L2 y de forma de interacción en references/architecture-contracts.md. Use las comprobaciones de navegación y propietario canónico en references/document-and-complexity-gates.md cuando el paquete contenga múltiples documentos.

Fase 5 — MVP y contrato local de tarea

Elija el bucle cerrado real más pequeño que ejercite el límite previsto. Un segmento de lectura/cierre de ciclo de vida puede preceder a un segmento de límite de primera escritura. Preserve las etiquetas locales de MVP solo cuando estén emparejadas con un nombre descriptivo, y establezca exactamente qué demuestra el segmento y qué no demuestra.

Antes de codificar una tarea de implementación acotada, congele solo el contrato L3 consumido por esa tarea. Sigue siendo candidato hasta que la tarea de implementación adopte registre revisiones sobre él. No cree documentos L3 para módulos no seleccionados. Use la lista de verificación L3 e interfaz en references/architecture-contracts.md.

Fase 6 — Revisión adversarial y steelman bidireccional

Realice una pasada adversarial que intente romper las afirmaciones de propiedad, recuperación, compatibilidad, migración y evidencia, seguida de un steelman que establezca el valor más fuerte y los límites deliberadamente conservadores. Prefiera un revisor independiente que no haya escrito el paquete; de lo contrario, use un contexto nuevo y divulgue la limitación.

Use references/adversarial-review.md para el momento de la revisión, las preguntas y el libro de conciliación único. Consuma cada hallazgo inmediatamente. Un hallazgo bloqueante mantiene la puerta cerrada hasta que el riesgo se resuelva o se degrade/acepte explícitamente como una excepción por parte del usuario o un revisor independiente; rechazarlo o aplazarlo por sí solo no abre la puerta.

Fase 7 — Migración, verificación y promoción

Defina una migración por etapas con capas de compatibilidad, condiciones de aborto, puertas de eliminación, límites de reversión/reinicio, fixtures heredados/objetivo y evidencia equivalente. Promueva el texto objetivo a la arquitectura actual solo después de que la implementación, la evidencia de compatibilidad y las actualizaciones de la autoridad del repositorio se fusionen juntas.

Al final de cada incremento, elija un resultado: continuar, ejecutar un experimento con nombre, revisar el objetivo/contrato o detenerse y preservar la ruta actual. El siguiente incremento comienza solo cuando su desencadenante y evidencia de promoción están satisfechos. Cargue references/migration-and-promotion.md para obtener evidencia detallada, experimentos y reglas de ADR.

Fase 8 — Traspaso y publicación

Antes de la publicación:

• valide metadatos, enlaces, catálogos y comprobaciones de conformidad/regresión relevantes;
• inspeccione el diff completo en busca de archivos no relacionados o afirmaciones de implementación no soportadas;
• actualice el registro de cambio/traspaso existente del proyecto;
• haga que el registro de incremento sea descubrible desde una entrada de orientación o catálogo;
• establezca la siguiente tarea exacta y el propietario.

No cree un PR ni empuje una rama a menos que el usuario autorice esa mutación externa. Cuando esté autorizado, describa el paquete como diseño/documentación objetivo a menos que el comportamiento en tiempo de ejecución haya cambiado realmente.

Preocupaciones opcionales

Los plugins, la coexistencia de versiones, el aislamiento de procesos, el reemplazo en caliente y la descarga dinámica no son requisitos de arquitectura predeterminados. Cargue references/optional-concerns.md solo cuando el diseño solicitado active realmente una de esas preocupaciones.

Enrutamiento de módulos

Necesidad	Cargar
Seleccionar el conjunto de artefactos más pequeño y el horizonte de entrega	deliverable-matrix.md
Preguntar o registrar una decisión material del usuario	user-decision-gates.md
Definir L1/L2/L3 o una interfaz orientada a implementación	architecture-contracts.md
Controlar el crecimiento de documentos, la complejidad o el sobrediseño	document-and-complexity-gates.md
Ejecutar revisión adversarial y steelman	adversarial-review.md
Planificar migración, experimentos, ADR o promoción	migration-and-promotion.md
Diseñar plugins, aislamiento o coexistencia de versiones	optional-concerns.md

No cargue todos los módulos por defecto. La fase activa y el entregable solicitado determinan qué referencias son necesarias.

Lo que no se debe hacer

• No reescriba toda la base de código antes de probar un segmento real.
• No convierta cada archivo/clase en un plugin.
• No cree propietarios de estado duplicados, planificadores, almacenes, buses o autoridades de ciclo de vida sin una decisión objetivo explícita y un modelo de fallo.
• No oculte responsabilidades mixtas detrás de un envoltorio de paso directo renombrado.
• No afirme desacoplamiento solo por un recuento menor de dependencias.
• No use una demo sintética como condición de salida principal del MVP.
• No permita que la limpieza de extensiones implique finalización o destrucción del dominio.
• No trate notas de tarea, puntuaciones de benchmark o prosa generada como autoridad de arquitectura actual.