Planejar uma feature cross-repo¶

Da pasta do workspace, rode:

/n45-feat

Comandos no Codex

No Codex, troque o prefixo por $ — ex.: /n45-feat → $n45-feat.

O planejamento de uma feature de workspace é sempre estruturado (uma feature cross-repo tem um CONTRACT) e acontece em etapas, cada uma com um ponto de confirmação seu.

flowchart TD
    Start([/n45-feat]) --> Intent[Intenção + entrevista
+ mapeamento de telas por membro]
    Intent --> Disc[Discovery cross-repo]
    Disc --> Spec[SPEC + CONTRACT]
    Spec --> Review{Revisar o CONTRACT}
    Review -->|Aprovar| Fanout[Fan-out
um sub-roadmap por membro]
    Review -->|Ajustar| Spec
    Fanout --> Exec([Execução])

1. Intenção e entrevista¶

O N45 primeiro conhece cada membro (a stack e os padrões de cada serviço) e então conversa com você pra fechar o que a feature faz através dos serviços. A profundidade é a mesma do modo Project:

Entrevista progressiva — a intenção, e (quando um membro é novo/sem base) a fundação daquele serviço: stack, arquitetura, constraints.
Mapeamento de telas e contratos, atribuído por membro — pra cada membro com interface, o N45 propõe as telas (com estados, componentes e ações); pra cada membro de API, os contratos (entrada → saída). Você valida tudo antes de seguir.

É esse mapeamento que faz o resultado sair rico e concreto, não genérico.

2. Discovery + SPEC + CONTRACT¶

Com a intenção fechada, o N45 gera os artefatos de coordenação e apresenta cada um com link + conteúdo:

DISCOVERY — a superfície de integração entre os serviços e as telas/contratos por membro.
SPEC — a intenção da feature através dos serviços, com as telas por membro.
CONTRACT — o artefato mais importante: os pontos de integração entre os membros.

O CONTRACT¶

O CONTRACT é a costura entre os serviços — a "fonte da verdade" que cada membro segue pra convergir. Cada ponto de integração declara:

o transporte (REST, fila, evento, gRPC, banco compartilhado, webhook…);
produtor e consumidor(es);
o schema tipado + um exemplo concreto;
os erros e as obrigações de cada lado ("Produtor DEVE…", "Consumidor DEVE…").

Você revisa e aprova o CONTRACT antes do fan-out:

Revisar CONTRACT

Os pontos de integração entre os serviços estão corretos?

Por que revisar o CONTRACT com atenção

É por ele que os membros convergem. Se um ponto de integração sair errado, todos os membros que dependem dele divergem. Vale revisar com calma antes de aprovar.

3. Fan-out¶

Ao aprovar, o N45 faz o fan-out: pra cada membro afetado, gera um roadmap autocontido (discovery, spec e roadmap do próprio membro), honrando a fatia dele do CONTRACT e transcrevendo as telas/contratos que você validou. A feature cria uma branch própria em cada repositório (e no workspace).

A partir daqui, cada membro tem o próprio sub-roadmap, com fases próprias — pronto pra execução.