golem15/msd-core
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

refactor: hard-fork GSD -> MSD (Make Software Done)

Browse Source 
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
2026-10-06 01:47:40 +02:00
parent fe069b2a56
commit a9a7a328e6
2763 changed files with 78465 additions and 78434 deletions
Download Patch File Download Diff File Expand all files Collapse all files

64
docs/pt-BR/tutorials/onboarding-an-existing-codebase.md
View File

@@ -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)

70
docs/pt-BR/tutorials/your-first-project.md
View File

@@ -1,6 +1,6 @@
# Seu primeiro projeto
Neste tutorial você instalará o GSD Core e construirá um pequeno aplicativo de linha de comando para gerenciar tarefas do zero — uma fase, um PR, o ciclo completo. Ao final, você terá executado cada comando do ciclo de fase principal pelo menos uma vez e terá visto os artefatos de planejamento que cada comando produz.
Neste tutorial você instalará o MSD Core e construirá um pequeno aplicativo de linha de comando para gerenciar tarefas do zero — uma fase, um PR, o ciclo completo. Ao final, você terá executado cada comando do ciclo de fase principal pelo menos uma vez e terá visto os artefatos de planejamento que cada comando produz.
---
@@ -16,16 +16,16 @@ Um CLI em Node.js que permite adicionar, listar e concluir itens de tarefas arma
- **Claude Code** — aberto no diretório do projeto que você deseja utilizar.
- Uma conexão com a internet para a instalação inicial.
Nenhuma outra ferramenta é necessária. O próprio GSD Core é instalado no próximo passo.
Nenhuma outra ferramenta é necessária. O próprio MSD Core é instalado no próximo passo.
---
## Passo 1 — Instalar o GSD Core
## Passo 1 — Instalar o MSD Core
Abra um terminal no diretório do seu projeto e execute:
```bash
npx @opengsd/gsd-core@latest
npx @golem15/msd-core@latest
```
O instalador pergunta qual ambiente de execução de IA você está usando e se deseja instalar globalmente ou no projeto atual. Escolha **Claude Code** e **local** (apenas este projeto) por enquanto.
@@ -35,10 +35,10 @@ Você verá uma saída como:
```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
```
Observe que um diretório `.claude/` agora existe no seu projeto. É onde os comandos e agentes do GSD Core residem.
Observe que um diretório `.claude/` agora existe no seu projeto. É onde os comandos e agentes do MSD Core residem.
> Por que local vs global? Uma instalação local mantém a versão das skills fixada neste projeto. Consulte [Instalar no seu ambiente de execução](../how-to/install-on-your-runtime.md) quando quiser instalar globalmente.
@@ -46,7 +46,7 @@ Observe que um diretório `.claude/` agora existe no seu projeto. É onde os com
## Passo 2 — Iniciar o Claude Code com permissões
O GSD Core spawna sub-agentes que leem e escrevem arquivos. Inicie o Claude Code com o sinalizador de permissões para que ele não pause para perguntar sobre cada operação de arquivo:
O MSD Core spawna sub-agentes que leem e escrevem arquivos. Inicie o Claude Code com o sinalizador de permissões para que ele não pause para perguntar sobre cada operação de arquivo:
```bash
claude --dangerously-skip-permissions
@@ -61,10 +61,10 @@ Você chegará ao prompt do Claude Code no diretório do seu projeto.
Digite este comando slash no prompt do Claude Code:
```text
/gsd-new-project
/msd-new-project
```
O GSD Core abrirá uma conversa. Ele faz uma pergunta primeiro:
O MSD Core abrirá uma conversa. Ele faz uma pergunta primeiro:
```text
What do you want to build?
@@ -78,13 +78,13 @@ A Node.js CLI tool for managing to-do items. Users run `todo add "buy milk"`,
No external dependencies — Node built-ins only.
```
O GSD Core faz uma série de perguntas de esclarecimento. Responda naturalmente. Ele está aprendendo o que é importante para você antes de escrever qualquer plano.
O MSD Core faz uma série de perguntas de esclarecimento. Responda naturalmente. Ele está aprendendo o que é importante para você antes de escrever qualquer plano.
Após as perguntas, ele oferece a opção de realizar pesquisa de domínio. Para um projeto deste tamanho você pode pular a pesquisa — escolha **Skip research** quando solicitado.
O GSD Core então pede que você escolha as configurações de fluxo de trabalho (modo, granularidade, agentes de pesquisa). Escolha os padrões recomendados para cada um. Eles são gravados em `.planning/config.json`.
O MSD Core então pede que você escolha as configurações de fluxo de trabalho (modo, granularidade, agentes de pesquisa). Escolha os padrões recomendados para cada um. Eles são gravados em `.planning/config.json`.
Por fim, um sub-agente de roadmap é executado (você verá o aviso "Spawning roadmapper…" — isso é normal e leva cerca de um minuto). Quando ele retornar, o GSD Core apresentará um roadmap proposto. Para um projeto de uma única fase, ele terá uma aparência semelhante a:
Por fim, um sub-agente de roadmap é executado (você verá o aviso "Spawning roadmapper…" — isso é normal e leva cerca de um minuto). Quando ele retornar, o MSD Core apresentará um roadmap proposto. Para um projeto de uma única fase, ele terá uma aparência semelhante a:
```text
Proposed Roadmap
@@ -115,7 +115,7 @@ Abra `.planning/ROADMAP.md` agora e leia. Observe que a Fase 1 tem uma Meta, uma
## Passo 4 — Limpar o contexto e discutir a Fase 1
O GSD Core é projetado em torno de contextos frescos. Limpe a janela de sessão principal antes de cada fase:
O MSD Core é projetado em torno de contextos frescos. Limpe a janela de sessão principal antes de cada fase:
```text
/clear
@@ -124,10 +124,10 @@ O GSD Core é projetado em torno de contextos frescos. Limpe a janela de sessão
Em seguida, inicie a discussão para a Fase 1:
```text
/gsd-discuss-phase 1
/msd-discuss-phase 1
```
O GSD Core lê a meta da fase e pergunta sobre suas preferências de implementação. Estas são as decisões que moldam *como* ele constrói, não apenas *o que* ele constrói. Exemplo de troca:
O MSD Core lê a meta da fase e pergunta sobre suas preferências de implementação. Estas são as decisões que moldam *como* ele constrói, não apenas *o que* ele constrói. Exemplo de troca:
```text
> How should done items be stored — mark them in place or move them?
@@ -140,7 +140,7 @@ O GSD Core lê a meta da fase e pergunta sobre suas preferências de implementa
Create it silently on first add.
```
Quando a discussão encerra, o GSD Core escreve:
Quando a discussão encerra, o MSD Core escreve:
```text
.planning/phases/01-core-cli/CONTEXT.md
@@ -153,7 +153,7 @@ Abra esse arquivo. Você verá uma seção `## Implementation Decisions` captura
## Passo 5 — Planejar a Fase 1
```text
/gsd-plan-phase 1
/msd-plan-phase 1
```
Quatro sub-agentes de pesquisa se expandem em paralelo (você verá o aviso "Spawning 4 researchers…"). Eles levam de 1 a 5 minutos. Não interrompa.
@@ -169,17 +169,17 @@ Quando retornarem, um planejador lê o CONTEXT.md mais os resultados da pesquisa
01-02-PLAN.md ← Tarefa: implementar os comandos add / list / done
```
Abra `01-01-PLAN.md`. Você verá um bloco `<task>` com um nome, os arquivos que toca, as etapas de ação, um comando de verificação e uma condição de conclusão. Observe a tag `<verify>` — o executor do GSD Core executará esse comando após escrever o código.
Abra `01-01-PLAN.md`. Você verá um bloco `<task>` com um nome, os arquivos que toca, as etapas de ação, um comando de verificação e uma condição de conclusão. Observe a tag `<verify>` — o executor do MSD Core executará esse comando após escrever o código.
---
## Passo 6 — Executar a Fase 1
```text
/gsd-execute-phase 1
/msd-execute-phase 1
```
O GSD Core agrupa os planos em ondas (planos independentes são executados em paralelo), spawna um executor fresco com 200k de contexto por plano e confirma cada tarefa atomicamente.
O MSD Core agrupa os planos em ondas (planos independentes são executados em paralelo), spawna um executor fresco com 200k de contexto por plano e confirma cada tarefa atomicamente.
Você verá algo como:
@@ -215,17 +215,17 @@ node todo.js done 1
node todo.js list
```
Você deve ver os itens aparecerem e o item 1 desaparecer da lista padrão após marcá-lo como concluído. Esse é o seu primeiro resultado visível entregue pelo GSD Core.
Você deve ver os itens aparecerem e o item 1 desaparecer da lista padrão após marcá-lo como concluído. Esse é o seu primeiro resultado visível entregue pelo MSD Core.
---
## Passo 7 — Verificar o trabalho
```text
/gsd-verify-work 1
/msd-verify-work 1
```
O GSD Core extrai os critérios de sucesso da fase e os percorre um a um:
O MSD Core extrai os critérios de sucesso da fase e os percorre um a um:
```text
[1/3] Can you run `node todo.js add "buy milk"` without errors?
@@ -240,7 +240,7 @@ O GSD Core extrai os critérios de sucesso da fase e os percorre um a um:
All 3 checks passed. Phase 1 verified.
```
Se alguma verificação falhar, o GSD Core diagnostica a causa raiz e cria um plano de correção. Execute `/gsd-execute-phase 1` novamente para aplicá-lo e depois re-execute `/gsd-verify-work 1`.
Se alguma verificação falhar, o MSD Core diagnostica a causa raiz e cria um plano de correção. Execute `/msd-execute-phase 1` novamente para aplicá-lo e depois re-execute `/msd-verify-work 1`.
**O que é criado:**
@@ -253,10 +253,10 @@ Se alguma verificação falhar, o GSD Core diagnostica a causa raiz e cria um pl
## Passo 8 — Publicar
```text
/gsd-ship 1
/msd-ship 1
```
O GSD Core cria um pull request com um corpo gerado automaticamente. O corpo do PR sempre inclui: Resumo, Alterações, Requisitos Atendidos, Verificação e Decisões Principais.
O MSD Core cria um pull request com um corpo gerado automaticamente. O corpo do PR sempre inclui: Resumo, Alterações, Requisitos Atendidos, Verificação e Decisões Principais.
Você verá:
@@ -272,15 +272,15 @@ Esse é o ciclo completo — da ideia ao PR mesclado — para uma fase.
## O que você aprendeu
- Como instalar o GSD Core com `npx @opengsd/gsd-core@latest`.
- Como `/gsd-new-project` transforma uma conversa em um roadmap respaldado por artefatos em `.planning/`.
- Como `/gsd-discuss-phase` captura decisões de implementação antes de qualquer planejamento acontecer.
- Como `/gsd-plan-phase` spawna pesquisadores em paralelo e produz planos de tarefa atômicos.
- Como `/gsd-execute-phase` executa esses planos em ondas paralelas e confirma cada tarefa.
- Como `/gsd-verify-work` percorre os critérios de sucesso e gera planos de correção quando necessário.
- Como `/gsd-ship` transforma uma fase verificada em um pull request.
- Como instalar o MSD Core com `npx @golem15/msd-core@latest`.
- Como `/msd-new-project` transforma uma conversa em um roadmap respaldado por artefatos em `.planning/`.
- Como `/msd-discuss-phase` captura decisões de implementação antes de qualquer planejamento acontecer.
- Como `/msd-plan-phase` spawna pesquisadores em paralelo e produz planos de tarefa atômicos.
- Como `/msd-execute-phase` executa esses planos em ondas paralelas e confirma cada tarefa.
- Como `/msd-verify-work` percorre os critérios de sucesso e gera planos de correção quando necessário.
- Como `/msd-ship` transforma uma fase verificada em um pull request.
Para um projeto de múltiplas fases, repita os Passos 4–8 para cada fase e depois execute `/gsd-progress --next` para deixar o GSD Core detectar o próximo passo automaticamente.
Para um projeto de múltiplas fases, repita os Passos 4–8 para cada fase e depois execute `/msd-progress --next` para deixar o MSD Core detectar o próximo passo automaticamente.
---
@@ -288,4 +288,4 @@ Para um projeto de múltiplas fases, repita os Passos 4–8 para cada fase e dep
- [O ciclo de fase](../explanation/the-phase-loop.md) — por que o ciclo tem esse formato
- [Guias práticos](../README.md#how-to-guides) — receitas focadas em tarefas para situações específicas
- [Integrando uma base de código existente](onboarding-an-existing-codebase.md) — traga o GSD Core para um repositório já existente
- [Integrando uma base de código existente](onboarding-an-existing-codebase.md) — traga o MSD Core para um repositório já existente