Files

Jakub Zych a9a7a328e6 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.

2026-10-06 01:47:40 +02:00

5.1 KiB

Raw Permalink Blame History

Como verificar e publicar uma fase

Objetivo: Conduzir o trabalho executado pelo processo de testes de aceitação do usuário, diagnosticar e corrigir eventuais falhas e, em seguida, abrir um pull request com o corpo gerado automaticamente.

Pré-requisitos: A fase deve ter sido executada e possuir arquivos SUMMARY.md. Se a execução ainda não foi concluída, consulte Executar uma fase.

Executar os testes de aceitação do usuário

/msd-verify-work 1

O MSD lê os arquivos SUMMARY.md da fase, extrai as entregas observáveis pelo usuário e guia você por elas uma de cada vez. Para cada ponto de verificação, ele apresenta o que deveria acontecer e pergunta se a realidade corresponde.

yes / y / vazio → aprovado, avança para o próximo teste
Qualquer outra coisa → registrado como um problema; a severidade é inferida a partir da sua descrição

Você nunca precisa categorizar a severidade — o MSD a infere a partir das suas palavras ("trava" → bloqueador, "não funciona" → grave, "está estranho" → cosmético).

O progresso é gravado em .planning/phases/01-<name>/01-UAT.md e sobrevive a um /clear. Se uma sessão for interrompida, execute novamente /msd-verify-work 1 e o MSD oferece a opção de retomar a partir do último ponto de verificação.

Quando falhas são encontradas: diagnóstico automático e planejamento de correção

Se algum teste reportar problemas, o MSD prossegue automaticamente:

Diagnostica as causas raiz — cria agentes de depuração paralelos, um por problema, e atualiza o UAT.md com as causas raiz.
Planeja o fechamento das lacunas — cria um msd-planner no modo de fechamento de lacunas, que lê o UAT.md (com os diagnósticos) e escreve novos arquivos PLAN.md.
Verifica os planos de correção — cria um msd-plan-checker para garantir que os planos são executáveis. Se problemas forem encontrados, o planner e o checker iterarão até três vezes.
Apresenta o próximo passo — quando os planos passam pelo checker:

Plans verified and ready for execution.

`/clear` then `/msd-execute-phase 1 --gaps-only`

Execute o comando sugerido para aplicar as correções e, em seguida, execute novamente /msd-verify-work 1 para confirmar que tudo passa.

Quando todos os testes passam: publicar a fase

Quando todos os testes de aceitação passam (ou se esta é a primeira execução e nenhum problema é encontrado), a fase é marcada como concluída em ROADMAP.md e STATE.md automaticamente.

/msd-ship 1

O MSD executa verificações de pré-voo (status de verificação, árvore de trabalho limpa, branch, remoto, autenticação da CLI gh), envia o branch e cria um PR:

/msd-ship 1          # PR pronto para revisão
/msd-ship 1 --draft  # PR em rascunho — útil quando mais fases virão a seguir

O corpo do PR é montado automaticamente a partir dos artefatos de planejamento:

Objetivo da fase em ROADMAP.md
Resumos por plano dos arquivos SUMMARY.md e seus arquivos principais
Requisitos atendidos (REQ-IDs)
Status de verificação em VERIFICATION.md
Decisões-chave em STATE.md

Não é necessário escrever o corpo manualmente.

Opcional: revisão de código antes ou depois de publicar

/msd-ship não executa uma revisão de código automaticamente, mas você pode incluir uma a qualquer momento:

Antes da verificação (identifica problemas antes dos testes de aceitação):

/msd-code-review 1          # Revisão padrão
/msd-code-review 1 --fix    # Revisão com correção automática de achados Críticos + Avisos

Depois que o PR estiver aberto (para controlar a qualidade antes do merge):

/msd-code-review 1 --depth=deep  # Análise entre arquivos incluindo grafos de importação

Consulte Configurar revisão entre IAs para configurar o Antigravity, Codex ou outros revisores para revisão de planos mais cedo no ciclo.

Opcional: criar um branch de PR limpo

Se o seu branch contiver commits de .planning/ que você não quer que os revisores vejam:

/msd-pr-branch          # Filtrar contra main
/msd-pr-branch develop  # Filtrar contra develop

/msd-pr-branch cria um novo branch apenas com mudanças de código — commits de artefatos de planejamento são excluídos. Execute antes de /msd-ship se a política de revisão da sua equipe exclui ruído de planejamento.

Encerrando um marco

Se esta foi a última fase do marco, execute a auditoria do marco e arquive-o:

/msd-audit-milestone      # Verificar se todos os requisitos foram entregues
/msd-complete-milestone   # Arquivar, criar tag git

/msd-complete-milestone é o próximo passo natural após o merge do PR. Consulte O ciclo de fases para entender como a verificação e a publicação se encaixam no ciclo de vida completo do projeto.

5.1 KiB Raw Permalink Blame History