3bb2f8f1c5
* chore: wire docs/agents config into AGENTS.md Agent skills section
Add the `## Agent skills` discovery block pointing the engineering
skills at the existing docs/agents/{issue-tracker,triage-labels,domain}.md
files (issue tracker, triage label mapping, single-context domain docs).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* docs: rebrand to GSD Core and restructure docs with Diataxis
Reorganise the root README and docs/ around the Diataxis framework
(tutorials, how-to guides, reference, explanation), add new how-to
guides and schema references (STATE.md / CONTEXT.md / PLAN.md /
planning artifacts), and cross-link the whole set. Update the lone
legacy gsd-build reference to open-gsd; keep internal get-shit-done/
filesystem paths unchanged (directory rename tracked separately in
open-gsd/gsd-core#604). Regenerate the ja-JP, ko-KR, pt-BR and zh-CN
localised trees to mirror the new structure.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* docs: backfill changeset PR number (#605)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
125 lines
5.1 KiB
Markdown
125 lines
5.1 KiB
Markdown
# 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](execute-a-phase.md).
|
|
|
|
---
|
|
|
|
## Executar os testes de aceitação do usuário
|
|
|
|
```bash
|
|
/gsd-verify-work 1
|
|
```
|
|
|
|
O GSD 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 GSD 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 `/gsd-verify-work 1` e o GSD 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 GSD prossegue automaticamente:
|
|
|
|
1. **Diagnostica as causas raiz** — cria agentes de depuração paralelos, um por problema, e atualiza o `UAT.md` com as causas raiz.
|
|
2. **Planeja o fechamento das lacunas** — cria um `gsd-planner` no modo de fechamento de lacunas, que lê o `UAT.md` (com os diagnósticos) e escreve novos arquivos `PLAN.md`.
|
|
3. **Verifica os planos de correção** — cria um `gsd-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.
|
|
4. **Apresenta o próximo passo** — quando os planos passam pelo checker:
|
|
|
|
```
|
|
Plans verified and ready for execution.
|
|
|
|
`/clear` then `/gsd-execute-phase 1 --gaps-only`
|
|
```
|
|
|
|
Execute o comando sugerido para aplicar as correções e, em seguida, execute novamente `/gsd-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.
|
|
|
|
```bash
|
|
/gsd-ship 1
|
|
```
|
|
|
|
O GSD 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:
|
|
|
|
```bash
|
|
/gsd-ship 1 # PR pronto para revisão
|
|
/gsd-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
|
|
|
|
`/gsd-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):
|
|
|
|
```bash
|
|
/gsd-code-review 1 # Revisão padrão
|
|
/gsd-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):
|
|
|
|
```bash
|
|
/gsd-code-review 1 --depth=deep # Análise entre arquivos incluindo grafos de importação
|
|
```
|
|
|
|
Consulte [Configurar revisão entre IAs](set-up-cross-ai-review.md) para configurar o Gemini, 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:
|
|
|
|
```bash
|
|
/gsd-pr-branch # Filtrar contra main
|
|
/gsd-pr-branch develop # Filtrar contra develop
|
|
```
|
|
|
|
`/gsd-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 `/gsd-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:
|
|
|
|
```bash
|
|
/gsd-audit-milestone # Verificar se todos os requisitos foram entregues
|
|
/gsd-complete-milestone # Arquivar, criar tag git
|
|
```
|
|
|
|
`/gsd-complete-milestone` é o próximo passo natural após o merge do PR. Consulte [O ciclo de fases](../explanation/the-phase-loop.md) para entender como a verificação e a publicação se encaixam no ciclo de vida completo do projeto.
|
|
|
|
---
|
|
|
|
## Relacionados
|
|
|
|
- [Executar uma fase](execute-a-phase.md)
|
|
- [Configurar revisão entre IAs](set-up-cross-ai-review.md)
|
|
- [O ciclo de fases](../explanation/the-phase-loop.md)
|
|
- [Comandos](../COMMANDS.md)
|