Ir para o conteúdo

O que é um Workspace

Um workspace é como o N45 trata uma aplicação polyrepo — quando um único produto vive em vários repositórios (por exemplo, um frontend e uma api separados) e uma feature precisa atravessar mais de um deles ao mesmo tempo.

No modo Project você trabalha dentro de um repositório. No modo Workspace você coordena vários — cada repositório é um membro, e uma feature pode tocar quantos membros precisar, planejada e executada de uma sessão só.

Project vs Workspace

Project (single-repo) Workspace (polyrepo)
Onde você roda o /n45 dentro do repositório na pasta do workspace
Alcance de uma feature um repositório um ou mais membros
O que coordena — o CONTRACT entre os serviços
Onde ficam os roadmaps no próprio repo em cada membro (um sub-roadmap por membro)

Uma feature pode tocar só um membro

Você não precisa de dois repositórios pra usar o workspace. Se a feature toca só um membro, o N45 segue normalmente no workspace — você pode adicionar mais membros depois.

O modelo mental

  • O workspace coordena; os roadmaps moram nos membros. Cada membro é um repositório git independente com o próprio planejamento (discovery, spec, roadmap, tasks).
  • A costura entre os serviços é o CONTRACT. Ao planejar uma feature cross-repo, o N45 fecha um CONTRACT — os pontos de integração entre os membros (endpoints, eventos, schemas). Cada membro implementa a fatia dele honrando o CONTRACT, em paralelo.
  • Cada membro tem o próprio ritmo. Os membros não andam em lockstep: cada um roda o próprio roadmap, nas próprias fases. O N45 junta tudo no final, na validação unificada, pra conferir que os serviços realmente conversam.
flowchart TD
    WS[Workspace] --> Feat[Uma feature cross-repo]
    Feat --> Contract[CONTRACT
a costura entre os serviços]
    Contract --> A[Membro: frontend
sub-roadmap próprio]
    Contract --> B[Membro: api
sub-roadmap próprio]
    A --> V[Validação unificada]
    B --> V
    V --> Finish[Finalização coordenada]

Quando usar

  • Use um Workspace quando um produto vive em vários repositórios e você quer planejar/executar features que atravessam eles como uma coisa só.
  • Use um Project quando o trabalho vive num repositório só (mesmo que seja um monorepo — um monorepo é um repositório).

Veja também