refactor: hard-fork GSD -> MSD (Make Software Done)
Mechanical rename produced by scripts/msd-rename.cjs: gsd/Gsd/GSD -> msd/Msd/MSD across contents and paths, upstream package/repo coordinates -> @golem15/msd-core and golem15com/msd-core. Deep links into upstream history, sibling upstream packages, the GSD-2 import feature, CHANGELOG.md and .changeset/ are kept as-is. Hand edits on top: MSD block-letter banner and logos, LICENSE copyright line, package/plugin identity, regenerated lockfile, install-tree fixtures, derived registries and benchmark baseline; migration checksum baseline re-locked (MSD keeps its own install state, so no install had applied the old sums); sort-order and regex-escaped expectations in tests adjusted.
This commit is contained in:
Jakub Zych
@@ -1,12 +1,12 @@
|
||||
# Integrando uma base de código existente
|
||||
|
||||
Neste tutorial você integrará o GSD Core a um repositório que já possui código. Você mapeará a base de código, criará um projeto que descreve o que está *adicionando* e executará seu primeiro ciclo de discussão e planejamento para uma mudança pequena e focada. Ao final, o pipeline de planejamento do GSD Core conhecerá sua stack, suas convenções e suas preocupações — e usará esse conhecimento toda vez que planejar.
|
||||
Neste tutorial você integrará o MSD Core a um repositório que já possui código. Você mapeará a base de código, criará um projeto que descreve o que está *adicionando* e executará seu primeiro ciclo de discussão e planejamento para uma mudança pequena e focada. Ao final, o pipeline de planejamento do MSD Core conhecerá sua stack, suas convenções e suas preocupações — e usará esse conhecimento toda vez que planejar.
|
||||
|
||||
---
|
||||
|
||||
## O que você vai construir
|
||||
|
||||
Adicionaremos um único endpoint `GET /health` a uma aplicação Express existente. A mudança é pequena o suficiente para nunca desviar do objetivo real da lição: como o GSD Core aprende sua base de código antes de planejar qualquer coisa.
|
||||
Adicionaremos um único endpoint `GET /health` a uma aplicação Express existente. A mudança é pequena o suficiente para nunca desviar do objetivo real da lição: como o MSD Core aprende sua base de código antes de planejar qualquer coisa.
|
||||
|
||||
---
|
||||
|
||||
@@ -18,12 +18,12 @@ Adicionaremos um único endpoint `GET /health` a uma aplicação Express existen
|
||||
|
||||
---
|
||||
|
||||
## Passo 1 — Instalar o GSD Core
|
||||
## Passo 1 — Instalar o MSD Core
|
||||
|
||||
Na raiz do seu repositório:
|
||||
|
||||
```bash
|
||||
npx @opengsd/gsd-core@latest
|
||||
npx @golem15/msd-core@latest
|
||||
```
|
||||
|
||||
Escolha **Claude Code** e **local** quando solicitado. Você verá:
|
||||
@@ -31,7 +31,7 @@ Escolha **Claude Code** e **local** quando solicitado. Você verá:
|
||||
```text
|
||||
✓ Installed 86 skills to .claude/commands/
|
||||
✓ Installed agents to .claude/agents/
|
||||
✓ GSD Core ready — run /gsd-new-project to start
|
||||
✓ MSD Core ready — run /msd-new-project to start
|
||||
```
|
||||
|
||||
---
|
||||
@@ -44,7 +44,7 @@ claude --dangerously-skip-permissions
|
||||
|
||||
> [!CAUTION]
|
||||
> **The permissions flag is optional.** It skips per-file confirmation while
|
||||
> GSD's sub-agents read and write files. Use it only in low-stakes or
|
||||
> MSD's sub-agents read and write files. Use it only in low-stakes or
|
||||
> throwaway contexts. To keep confirmations enabled, start with `claude` instead.
|
||||
> For real work, read the [security model](../explanation/security-model.md) first.
|
||||
|
||||
@@ -53,13 +53,13 @@ claude --dangerously-skip-permissions
|
||||
|
||||
## Passo 3 — Iniciar o onboarding brownfield
|
||||
|
||||
Antes de criar um projeto, deixe o GSD Core inspecionar o estado do repositório e indicar o próximo comando de nível superior seguro. Este passo evita pular contexto de código ou sobrescrever arquivos de planning existentes.
|
||||
Antes de criar um projeto, deixe o MSD Core inspecionar o estado do repositório e indicar o próximo comando de nível superior seguro. Este passo evita pular contexto de código ou sobrescrever arquivos de planning existentes.
|
||||
|
||||
```text
|
||||
/gsd-onboard
|
||||
/msd-onboard
|
||||
```
|
||||
|
||||
Se o onboarding informar que o mapa da base de código está ausente, escolha a opção recomendada e execute o handoff `/gsd-map-codebase` impresso antes de rodar `/gsd-onboard` novamente. `/gsd-onboard --fast` serve para uma primeira passada leve, mas um mapa completo ainda é necessário antes de `/gsd-new-project`. O `/gsd-map-codebase` cria quatro sub-agentes mapeadores paralelos (você verá "Spawning 4 parallel codebase mapper agents…" — isso leva de 1 a 5 minutos; não interrompa). Cada agente foca em uma preocupação diferente:
|
||||
Se o onboarding informar que o mapa da base de código está ausente, escolha a opção recomendada e execute o handoff `/msd-map-codebase` impresso antes de rodar `/msd-onboard` novamente. `/msd-onboard --fast` serve para uma primeira passada leve, mas um mapa completo ainda é necessário antes de `/msd-new-project`. O `/msd-map-codebase` cria quatro sub-agentes mapeadores paralelos (você verá "Spawning 4 parallel codebase mapper agents…" — isso leva de 1 a 5 minutos; não interrompa). Cada agente foca em uma preocupação diferente:
|
||||
|
||||
| Agente | Foco |
|
||||
|--------|------|
|
||||
@@ -83,9 +83,9 @@ Created .planning/codebase/:
|
||||
- CONCERNS.md (33 lines) - Technical debt and issues
|
||||
```
|
||||
|
||||
Abra `.planning/codebase/STACK.md`. Você verá a linguagem, o runtime, as versões do framework e as dependências principais que o GSD Core detectou — fundamentadas nos arquivos reais que leu, não em suposições.
|
||||
Abra `.planning/codebase/STACK.md`. Você verá a linguagem, o runtime, as versões do framework e as dependências principais que o MSD Core detectou — fundamentadas nos arquivos reais que leu, não em suposições.
|
||||
|
||||
Abra `.planning/codebase/CONVENTIONS.md`. Você verá as convenções de nomenclatura, os padrões de tratamento de erros e as regras de estilo de código que ele observou no seu código-fonte. Todos os planos que o GSD Core produzir para este repositório seguirão essas convenções automaticamente.
|
||||
Abra `.planning/codebase/CONVENTIONS.md`. Você verá as convenções de nomenclatura, os padrões de tratamento de erros e as regras de estilo de código que ele observou no seu código-fonte. Todos os planos que o MSD Core produzir para este repositório seguirão essas convenções automaticamente.
|
||||
|
||||
Abra `.planning/codebase/CONCERNS.md`. Este é o arquivo mais útil para ler antes de qualquer trabalho em novo recurso — ele expõe dívidas técnicas e áreas frágeis que podem afetar seus planos.
|
||||
|
||||
@@ -99,15 +99,15 @@ Limpe a janela de sessão:
|
||||
/clear
|
||||
```
|
||||
|
||||
Agora execute `/gsd-onboard` novamente. Se o GSD Core detectar ADRs, PRDs, specs, RFCs ou requisitos de nível raiz, aceite o handoff recomendado para `/gsd-ingest-docs` primeiro e depois rode `/gsd-onboard` de novo. Quando o contexto estiver pronto, o onboarding imprimirá o handoff de inicialização:
|
||||
Agora execute `/msd-onboard` novamente. Se o MSD Core detectar ADRs, PRDs, specs, RFCs ou requisitos de nível raiz, aceite o handoff recomendado para `/msd-ingest-docs` primeiro e depois rode `/msd-onboard` de novo. Quando o contexto estiver pronto, o onboarding imprimirá o handoff de inicialização:
|
||||
|
||||
```text
|
||||
/gsd-new-project
|
||||
/msd-new-project
|
||||
```
|
||||
|
||||
Como o GSD Core encontrou código existente no passo anterior, `/gsd-new-project` sabe que é um projeto brownfield. As perguntas focam no que você está *adicionando*, não em reconstruir o que já existe:
|
||||
Como o MSD Core encontrou código existente no passo anterior, `/msd-new-project` sabe que é um projeto brownfield. As perguntas focam no que você está *adicionando*, não em reconstruir o que já existe:
|
||||
|
||||
O GSD Core pergunta o que você quer construir. Responda com o recurso que está adicionando, e não com uma descrição de toda a base de código:
|
||||
O MSD Core pergunta o que você quer construir. Responda com o recurso que está adicionando, e não com uma descrição de toda a base de código:
|
||||
|
||||
```text
|
||||
Add a GET /health endpoint to the Express app. It should return
|
||||
@@ -115,7 +115,7 @@ Add a GET /health endpoint to the Express app. It should return
|
||||
health checks.
|
||||
```
|
||||
|
||||
O GSD Core faz um pequeno número de perguntas de esclarecimento e depois prossegue para a criação de requisitos e roteiro. Como já leu `ARCHITECTURE.md` e `STACK.md`, mapeará as capacidades existentes para a seção **Validated** de `PROJECT.md` automaticamente — você não precisa descrever a superfície de API existente.
|
||||
O MSD Core faz um pequeno número de perguntas de esclarecimento e depois prossegue para a criação de requisitos e roteiro. Como já leu `ARCHITECTURE.md` e `STACK.md`, mapeará as capacidades existentes para a seção **Validated** de `PROJECT.md` automaticamente — você não precisa descrever a superfície de API existente.
|
||||
|
||||
Escolha os padrões recomendados para todas as configurações do fluxo de trabalho.
|
||||
|
||||
@@ -133,7 +133,7 @@ Proposed Roadmap
|
||||
|
||||
Aprove o roteiro.
|
||||
|
||||
Execute `/gsd-onboard` mais uma vez depois que a configuração do projeto terminar. Agora que `PROJECT.md`, `REQUIREMENTS.md`, `ROADMAP.md` e `STATE.md` existem, o onboarding cria ou confirma `.planning/onboarding/SUMMARY.md`.
|
||||
Execute `/msd-onboard` mais uma vez depois que a configuração do projeto terminar. Agora que `PROJECT.md`, `REQUIREMENTS.md`, `ROADMAP.md` e `STATE.md` existem, o onboarding cria ou confirma `.planning/onboarding/SUMMARY.md`.
|
||||
|
||||
**O que é criado em `.planning/`:**
|
||||
|
||||
@@ -148,7 +148,7 @@ Execute `/gsd-onboard` mais uma vez depois que a configuração do projeto termi
|
||||
codebase/ ← os sete arquivos de mapa do Passo 3
|
||||
```
|
||||
|
||||
Observe que `.planning/codebase/` já está lá desde o Passo 3. O GSD Core leu esses arquivos ao escrever `PROJECT.md`, por isso conseguiu preencher os requisitos Validated sem que você os descrevesse.
|
||||
Observe que `.planning/codebase/` já está lá desde o Passo 3. O MSD Core leu esses arquivos ao escrever `PROJECT.md`, por isso conseguiu preencher os requisitos Validated sem que você os descrevesse.
|
||||
|
||||
---
|
||||
|
||||
@@ -159,10 +159,10 @@ Observe que `.planning/codebase/` já está lá desde o Passo 3. O GSD Core leu
|
||||
```
|
||||
|
||||
```text
|
||||
/gsd-discuss-phase 1
|
||||
/msd-discuss-phase 1
|
||||
```
|
||||
|
||||
Como o GSD Core leu seu `CONVENTIONS.md` e `ARCHITECTURE.md`, suas perguntas são fundamentadas na sua base de código real — não em conselhos genéricos. Você pode ver:
|
||||
Como o MSD Core leu seu `CONVENTIONS.md` e `ARCHITECTURE.md`, suas perguntas são fundamentadas na sua base de código real — não em conselhos genéricos. Você pode ver:
|
||||
|
||||
```text
|
||||
> Your routes are registered in src/routes/index.js. Should the health
|
||||
@@ -177,7 +177,7 @@ Como o GSD Core leu seu `CONVENTIONS.md` e `ARCHITECTURE.md`, suas perguntas sã
|
||||
process.uptime() is fine.
|
||||
```
|
||||
|
||||
Quando a discussão encerrar, o GSD Core escreverá:
|
||||
Quando a discussão encerrar, o MSD Core escreverá:
|
||||
|
||||
```text
|
||||
.planning/phases/01-health-endpoint/CONTEXT.md
|
||||
@@ -190,7 +190,7 @@ Abra esse arquivo. A seção `## Implementation Decisions` captura suas resposta
|
||||
## Passo 6 — Planejar a Fase 1
|
||||
|
||||
```text
|
||||
/gsd-plan-phase 1
|
||||
/msd-plan-phase 1
|
||||
```
|
||||
|
||||
Quatro sub-agentes de pesquisa rodam em paralelo (1–5 minutos). Quando retornarem, o planejador lê `CONTEXT.md`, os resultados da pesquisa e o mapa da sua base de código para criar planos de tarefas que correspondem às suas convenções.
|
||||
@@ -204,7 +204,7 @@ Quatro sub-agentes de pesquisa rodam em paralelo (1–5 minutos). Quando retorna
|
||||
01-02-PLAN.md ← Tarefa: registrar rota health em src/routes/index.js
|
||||
```
|
||||
|
||||
Abra `01-01-PLAN.md`. Observe que a tag `<files>` referencia `src/routes/health.js` — exatamente o caminho que você especificou na discussão, consistente com o padrão de roteamento que o GSD Core observou no mapa da sua base de código. Isso é o mapa da base de código em ação.
|
||||
Abra `01-01-PLAN.md`. Observe que a tag `<files>` referencia `src/routes/health.js` — exatamente o caminho que você especificou na discussão, consistente com o padrão de roteamento que o MSD Core observou no mapa da sua base de código. Isso é o mapa da base de código em ação.
|
||||
|
||||
---
|
||||
|
||||
@@ -213,21 +213,21 @@ Abra `01-01-PLAN.md`. Observe que a tag `<files>` referencia `src/routes/health.
|
||||
Você agora tem um projeto com um mapa da base de código, um registro de decisões de discussão e planos de tarefas verificados — tudo fundamentado no seu código real. A partir daqui, o fluxo de trabalho é idêntico ao de um projeto greenfield:
|
||||
|
||||
```text
|
||||
/gsd-execute-phase 1
|
||||
/gsd-verify-work 1
|
||||
/gsd-ship 1
|
||||
/msd-execute-phase 1
|
||||
/msd-verify-work 1
|
||||
/msd-ship 1
|
||||
```
|
||||
|
||||
Para cada recurso futuro, execute `/gsd-map-codebase` novamente sempre que a estrutura mudar significativamente, para manter o mapa da base de código atualizado.
|
||||
Para cada recurso futuro, execute `/msd-map-codebase` novamente sempre que a estrutura mudar significativamente, para manter o mapa da base de código atualizado.
|
||||
|
||||
---
|
||||
|
||||
## O que você aprendeu
|
||||
|
||||
- Como `/gsd-onboard` sequencia com segurança o setup brownfield sem aninhar comandos interativos ou sobrescrever planning existente.
|
||||
- Como `/gsd-map-codebase` executa quatro agentes paralelos para produzir `STACK.md`, `ARCHITECTURE.md`, `CONVENTIONS.md`, `CONCERNS.md`, `STRUCTURE.md`, `TESTING.md` e `INTEGRATIONS.md` em `.planning/codebase/`.
|
||||
- Como `/gsd-new-project` em um repositório brownfield concentra as perguntas no que você está *adicionando* e preenche os requisitos Validated a partir do código existente.
|
||||
- Como o mapa da base de código orienta cada pergunta em `/gsd-discuss-phase` — caminhos de arquivos, padrões e convenções vêm do seu código real.
|
||||
- Como `/msd-onboard` sequencia com segurança o setup brownfield sem aninhar comandos interativos ou sobrescrever planning existente.
|
||||
- Como `/msd-map-codebase` executa quatro agentes paralelos para produzir `STACK.md`, `ARCHITECTURE.md`, `CONVENTIONS.md`, `CONCERNS.md`, `STRUCTURE.md`, `TESTING.md` e `INTEGRATIONS.md` em `.planning/codebase/`.
|
||||
- Como `/msd-new-project` em um repositório brownfield concentra as perguntas no que você está *adicionando* e preenche os requisitos Validated a partir do código existente.
|
||||
- Como o mapa da base de código orienta cada pergunta em `/msd-discuss-phase` — caminhos de arquivos, padrões e convenções vêm do seu código real.
|
||||
- Como o planejador lê `CONTEXT.md` e `CONVENTIONS.md` para produzir planos que correspondem ao estilo do seu repositório.
|
||||
|
||||
---
|
||||
@@ -235,5 +235,5 @@ Para cada recurso futuro, execute `/gsd-map-codebase` novamente sempre que a est
|
||||
## Relacionados
|
||||
|
||||
- [Seu primeiro projeto](your-first-project.md) — o ciclo greenfield completo, da instalação ao PR
|
||||
- [Mapear base de código via Comandos](../COMMANDS.md) — todos os flags e subcomandos de `/gsd-map-codebase`
|
||||
- [Mapear base de código via Comandos](../COMMANDS.md) — todos os flags e subcomandos de `/msd-map-codebase`
|
||||
- [Índice de documentação](../README.md)
|
||||
|
||||
Reference in New Issue
Block a user