Saltar a contenido

Flujo: Ingenieria Inversa de Codebase a Feature Specs

Pipeline cientifico que analiza un codebase externo (sin documentacion) y produce Feature Specs compatibles con ATL Inteliside. Basado en metodologias academicas (Chikofsky & Cross IEEE 1990, Horseshoe Model, 5 Abstraction Levels) adaptadas para el ecosistema SDD. RE-Wizard trabaja en modo solo lectura sobre el codebase analizado, delega a 5 agentes especializados por fase, y entrega documentacion estructurada lista para reimplementar, extraer modulos o mejorar proyectos open-source.

Resumen

El usuario apunta RE-Wizard a un codebase y selecciona un modo de operacion. El plugin ejecuta 5 fases secuenciales con agentes aislados: reconocimiento (stack, estructura, metricas), analisis estructural (arquitectura, datos, API), analisis funcional (features, flujos, reglas), analisis de dominio (proposito, NFRs, deuda), y sintesis (consolidacion en specs finales + Feature Specs ATL). El output son documentos en ./re-wizard-output/ y, opcionalmente, milestones en GitHub listos para que ATL los implemente.

Modos de operacion

RE-Wizard ofrece 3 modos que determinan el alcance del analisis y el formato de los documentos finales:

Mode 1 — Full RE (Reimplementacion completa)

  • Cuando usarlo: codebase completo sin documentacion que se necesita reimplementar desde cero o refactorizar profundamente.
  • Alcance: analiza todo el codebase.
  • Produce: 08-MASTER-SPEC.md (especificacion completa del sistema) + 09-REIMPLEMENTATION-GUIDE.md (guia paso a paso para reconstruir).
  • Caso tipico: migrar un monolito legacy a microservicios, reescribir en otro stack.

Mode 2 — Module Extraction (Extraccion de modulo)

  • Cuando usarlo: se necesita extraer un modulo o componente especifico de un proyecto grande para adaptarlo a otro contexto.
  • Alcance: focalizado en el modulo objetivo y sus dependencias.
  • Produce: 08-MODULE-SPEC.md (especificacion del modulo aislado) + 09-ADAPTATION-GUIDE.md (guia para adaptar a otro proyecto).
  • Caso tipico: extraer el sistema de pagos de una plataforma, aislar el motor de recomendaciones.

Mode 3 — Fork & Enhance (Mejora de proyecto open-source)

  • Cuando usarlo: proyecto MIT/open-source que se quiere mejorar con atribucion adecuada.
  • Alcance: analiza todo el codebase con enfoque en oportunidades de mejora.
  • Produce: 08-MASTER-SPEC.md (como funciona hoy) + 09-ENHANCEMENT-PLAN.md (mejoras propuestas priorizadas).
  • Caso tipico: fork de un CMS open-source para agregar multi-tenancy, mejorar un framework con features enterprise.

Output comun a todos los modos

Independientemente del modo, Phase 4 siempre genera: - 10-ATL-FEATURE-SPECS/feat-*.md — Feature Specs individuales con formato identico a SDD-Wizards - 11-ATL-MILESTONE-PLAN.md — Plan de implementacion con waves y dependencias entre features

Pipeline de 5 fases

Phase 0 — Reconnaissance (Reconocimiento)

  • Agente: re-wizard-recon
  • Modelo: sonnet
  • Aislamiento: isolation: worktree (sandbox git)
  • maxTurns: 40
  • Que hace: escaneo de directorio, deteccion de stack, inventario de dependencias, localizacion de docs y tests existentes, metricas de LOC.
  • Output: 00-RECONNAISSANCE.md
  • Engram: re-wizard/{id}/recon, project/stack

Phase 1 — Structural Analysis (Analisis estructural)

  • Agente: re-wizard-structure
  • Modelo: sonnet
  • maxTurns: 50
  • Que hace: arquitectura y capas del sistema, dependencias entre modulos, modelo de datos (entidades, relaciones, indices), endpoints API (metodos, params, auth), patrones de diseno, middleware, autenticacion.
  • Output: 01-ARCHITECTURE.md, 02-DATA-MODEL.md, 03-API-SPEC.md
  • Engram: re-wizard/{id}/architecture, re-wizard/{id}/data-model, re-wizard/{id}/api-spec

Phase 2 — Functional Analysis (Analisis funcional)

  • Agente: re-wizard-functional
  • Modelo: sonnet
  • maxTurns: 50
  • Que hace: inventario de features con nivel de complejidad, user flows por rol, reglas de negocio con trazabilidad (archivo:linea), validaciones, permisos, procesos background.
  • Output: 04-FEATURES.md, 05-USER-FLOWS.md, 06-BUSINESS-RULES.md
  • Engram: re-wizard/{id}/features, re-wizard/{id}/user-flows, re-wizard/{id}/business-rules

Phase 3 — Application Analysis (Analisis de dominio)

  • Agente: re-wizard-domain
  • Modelo: sonnet
  • maxTurns: 40
  • Que hace: proposito del sistema y dominio de negocio, stakeholders, NFRs inferidos (performance, seguridad, escalabilidad), decisiones arquitectonicas, deuda tecnica, limitaciones y oportunidades de mejora.
  • Output: 07-SYSTEM-OVERVIEW.md
  • Engram: re-wizard/{id}/system-overview

Phase 4 — Specification Synthesis (Sintesis)

  • Agente: re-wizard-synthesis
  • Modelo: opus
  • maxTurns: 60
  • Memoria: memory: user (aprende patrones de analisis previos)
  • Que hace: consolida toda la documentacion de fases anteriores en documentos finales segun modo (ver seccion de modos). Genera Feature Specs individuales con formato SDD-Wizards. Compila plan de milestones por waves. Opcionalmente crea milestones e issues en GitHub.
  • Output:
  • Segun modo: 08-*.md, 09-*.md
  • Comun: 10-ATL-FEATURE-SPECS/feat-*.md, 11-ATL-MILESTONE-PLAN.md
  • Engram:
  • Propios: re-wizard/{id}/synthesis-status
  • Handoff ATL: project/features/{feature-name}, project/features-index, project/github-context

Transicion a ATL Inteliside

Despues de que RE-Wizard completa el analisis, los Feature Specs son input directo para ATL:

RE-Wizard (analisis)                    ATL Inteliside (implementacion)
 |                                          |
 | Phase 4: Synthesis                       |
 |   -> feat-*.md en 10-ATL-FEATURE-SPECS/ |
 |   -> 11-ATL-MILESTONE-PLAN.md           |
 |   -> GitHub: milestones (opcional)       |
 |   -> Engram: project/features/*          |
 |   ------handoff-------->                 |
 |                             /orchestrador feat-[nombre]
 |                             [milestone -> codigo]
 |                             Ingesta -> Spec -> Tasks
 |                             Tests -> Implementacion
 |                             Verificacion -> Archivo

Pasos para la transicion

  1. Revisar documentacion: examinar los documentos en ./re-wizard-output/, especialmente 08-*.md y 09-*.md para entender el alcance.
  2. Crear milestones en GitHub: si RE-Wizard no los creo automaticamente, seguir el plan en 11-ATL-MILESTONE-PLAN.md para crearlos por waves.
  3. Ejecutar ATL por feature: /atl-inteliside:orchestrador feat-[nombre] para cada feature, en el orden de waves del milestone plan.
  4. Repetir: hasta completar todas las features de cada wave.

Diagrama del flujo

Usuario                     RE-Wizard                        ATL Inteliside
 |                              |                                |
 | /reverse-engineer [path]     |                                |
 | Seleccionar modo (1/2/3)     |                                |
 |   -------->                  |                                |
 |                              |                                |
 |                 Phase 0: Reconnaissance                       |
 |                 [re-wizard-recon]                              |
 |                 -> 00-RECONNAISSANCE.md                       |
 |                 -> Engram: re-wizard/{id}/recon               |
 |                              |                                |
 |                 Phase 1: Structural Analysis                  |
 |                 [re-wizard-structure]                          |
 |                 -> 01-ARCHITECTURE.md                          |
 |                 -> 02-DATA-MODEL.md                            |
 |                 -> 03-API-SPEC.md                              |
 |                              |                                |
 |                 Phase 2: Functional Analysis                   |
 |                 [re-wizard-functional]                         |
 |                 -> 04-FEATURES.md                              |
 |                 -> 05-USER-FLOWS.md                            |
 |                 -> 06-BUSINESS-RULES.md                        |
 |                              |                                |
 |                 Phase 3: Application Analysis                  |
 |                 [re-wizard-domain]                             |
 |                 -> 07-SYSTEM-OVERVIEW.md                       |
 |                              |                                |
 |                 Phase 4: Specification Synthesis               |
 |                 [re-wizard-synthesis]                          |
 |                 -> 08-*.md + 09-*.md (segun modo)             |
 |                 -> 10-ATL-FEATURE-SPECS/feat-*.md             |
 |                 -> 11-ATL-MILESTONE-PLAN.md                   |
 |   <--confirmar GitHub?--     |                                |
 |   ------si-------->          |                                |
 |                 -> GitHub: milestones + issues                 |
 |                 -> Engram: project/features/*                  |
 |                              |                                |
 |                 Step 7: Final Delivery                         |
 |                 [resumen + estadisticas]                       |
 |   <--documentacion lista--   |                                |
 |                              |                                |
 | /orchestrador feat-[wave-1-feat-A]  -------->                 |
 |                              |         Ingesta                |
 |                              |         Exploracion            |
 |                              |         Propuesta              |
 |                              |         Spec + Design          |
 |                              |         Tasks                  |
 |                              |         Tests (TDD)            |
 |                              |         Implementacion         |
 |                              |         Verificacion           |
 |                              |         Archivo                |
 |                              |                                |
 | (repetir por feature/wave)   |                                |

Handoffs

De A Artefacto Medio
Usuario RE-Wizard Path al codebase + modo Invocacion directa
RE-Wizard (Phase 4) Dev (ATL) Feature Specs Filesystem (10-ATL-FEATURE-SPECS/) + GitHub (milestones con labels feature-spec, atl-ready, re-wizard) + Engram (project/features/*)
RE-Wizard (Phase 4) Dev (ATL) Plan de implementacion Filesystem (11-ATL-MILESTONE-PLAN.md)
RE-Wizard (Phase 0) ATL (sdd-init) Stack detectado Engram (project/stack)

Comandos por etapa

Etapa Comando Quien lo ejecuta
Analisis completo /reverse-engineer [path-to-codebase] Usuario
Implementar feature /atl-inteliside:orchestrador feat-[nombre] Dev
Continuar DAG ATL /sdd-continue Dev
Implementar fase /sdd-apply [Foundation\|Core\|Integration\|UI\|Testing] Dev
Verificar /sdd-verify Dev
Archivar /sdd-archive Dev

Notas operativas

  • RE-Wizard es de solo lectura: no modifica el codebase analizado. Solo escribe en ./re-wizard-output/.
  • Soporte de lenguajes: guias especializadas para JavaScript/TypeScript y Python. Guias de framework para Next.js y Django. Otros stacks funcionan sin heuristicas especializadas.
  • Codebases grandes (>500K LOC): se recomienda Mode 2 (Module Extraction) para acotar alcance.
  • GitHub es opcional: RE-Wizard puede generar toda la documentacion sin GitHub. La creacion de milestones/issues requiere confirmacion explicita del usuario.
  • Convivencia con otros plugins: RE-Wizard nunca escribe a prefijos sdd/, team/, legacy/, intake/ en Engram. Si project/features/{name} ya existe (de SDD-Wizards), pide confirmacion antes de sobreescribir.
  • Memoria del agente synthesis: re-wizard-synthesis tiene memory: user, lo que le permite aprender patrones de analisis previos y mejorar la calidad de Feature Specs en usos futuros.

Flujo Ingenieria Inversa — Marketplace Inteliside