Saltar a contenido

Planificar una feature cross-repo

Desde la carpeta del workspace, corré:

/n45-feat

Comandos en Codex

En Codex, cambiá el prefijo por $ — ej.: /n45-feat → $n45-feat.

Planificar una feature de workspace es siempre estructurado (una feature cross-repo tiene un CONTRACT) y sucede en etapas, cada una con un punto de confirmación tuyo.

flowchart TD
    Start([/n45-feat]) --> Intent[Intención + entrevista
+ mapeo de pantallas por miembro]
    Intent --> Disc[Discovery cross-repo]
    Disc --> Spec[SPEC + CONTRACT]
    Spec --> Review{Revisar el CONTRACT}
    Review -->|Aprobar| Fanout[Fan-out
un sub-roadmap por miembro]
    Review -->|Ajustar| Spec
    Fanout --> Exec([Ejecución])

1. Intención y entrevista

N45 primero conoce cada miembro (el stack y los patrones de cada servicio) y luego conversa con vos para fijar qué hace la feature a través de los servicios. La profundidad es la misma que en modo Project:

  • Entrevista progresiva — la intención, y (cuando un miembro es nuevo/sin base) la fundación de ese servicio: stack, arquitectura, constraints.
  • Mapeo de pantallas y contratos, atribuido por miembro — para cada miembro con interfaz, N45 propone las pantallas (con estados, componentes y acciones); para cada miembro de API, los contratos (entrada → salida). Validás todo antes de seguir.

Ese mapeo es lo que hace que el resultado salga rico y concreto, no genérico.

2. Discovery + SPEC + CONTRACT

Con la intención fijada, N45 genera los artefactos de coordinación y presenta cada uno con enlace + contenido:

  • DISCOVERY — la superficie de integración entre los servicios y las pantallas/contratos por miembro.
  • SPEC — la intención de la feature a través de los servicios, con las pantallas por miembro.
  • CONTRACT — el más importante: los puntos de integración entre los miembros.

El CONTRACT

El CONTRACT es la costura entre los servicios — la "fuente de la verdad" que cada miembro sigue para converger. Cada punto de integración declara:

  • el transporte (REST, cola, evento, gRPC, base compartida, webhook…);
  • productor y consumidor(es);
  • el schema tipado + un ejemplo concreto;
  • los errores y las obligaciones de cada lado ("El productor DEBE…", "El consumidor DEBE…").

Revisás y aprobás el CONTRACT antes del fan-out:

Revisar CONTRACT
¿Los puntos de integración entre los servicios están correctos?

Por qué revisar el CONTRACT con atención

Es aquello sobre lo que los miembros convergen. Si un punto de integración sale mal, todos los miembros que dependen de él divergen. Vale la pena revisarlo con calma antes de aprobar.

3. Fan-out

Al aprobar, N45 hace el fan-out: para cada miembro afectado genera un roadmap autocontenido (el discovery, spec y roadmap del propio miembro), honrando su parte del CONTRACT y transcribiendo las pantallas/contratos que validaste. La feature crea una rama propia en cada repositorio (y en el workspace).

Desde acá, cada miembro tiene su propio sub-roadmap, con fases propias — listo para la ejecución.

Ver también