docs(#2420): clean stale get-shit-done/ path refs in translated docs (#2421)

After the package/repo rename in #604, the English docs were updated to use gsd-core/... paths, but the four translated doc trees (ja-JP, zh-CN, ko-KR, pt-BR) and .changeset/README.md were never updated and still referenced the pre-rename get-shit-done/ runtime directory, which no longer exists. This commit brings the translations in line with the English docs: - docs/{ja-JP,zh-CN,ko-KR,pt-BR}/**/*.md (57 files): get-shit-done/ -> gsd-core/ (path references) #references-get-shit-donereferencesmd -> #references-gsd-corereferencesmd (anchor in INVENTORY -> ARCHITECTURE links) - .changeset/README.md:9 issue URL: open-gsd/get-shit-done-redux -> open-gsd/gsd-core Legacy references intentionally preserved (historical record): - CHANGELOG.md, .changeset/archived/*, docs/RELEASE-NOTES-LEGACY.md - docs/cleanup-get-shit-done-cc.md, docs/adr/*, docs/research/* - docs/{ja-JP,ko-KR}/superpowers/plans/2026-03-18-* (developer's local paths) - docs/{INVENTORY,README,FEATURES,installer-migrations}.md (rename-history descriptions, some tagged ) - Code/tests implementing or testing legacy-cleanup logic (bin/install.js, gsd-core/bin/lib/legacy-cleanup.cjs, scripts/lint-legacy-dir-name.cjs, migration sources/tests) No source code changes — documentation only. Fixes #2420
2026-07-18 23:11:15 -04:00
parent 873bdf51e5
commit b2f4aa9435
58 changed files with 176 additions and 176 deletions
--- a/docs/pt-BR/ARCHITECTURE.md
+++ b/docs/pt-BR/ARCHITECTURE.md
@@ -43,7 +43,7 @@ O GSD Core é um **framework de meta-prompting** que fica entre o usuário e os
                      │
 ┌─────────────────────▼────────────────────────────────┐
 │              CAMADA DE WORKFLOWS                      │
-│   get-shit-done/workflows/*.md — Lógica de            │
+│   gsd-core/workflows/*.md — Lógica de            │
 │   orquestração                                        │
 │   (Lê referências, cria agentes, gerencia estado)     │
 └──────┬──────────────┬─────────────────┬──────────────┘
@@ -77,7 +77,7 @@ Cada agente criado por um orquestrador recebe uma janela de contexto limpa (até

 ### 2. Orquestradores Leves

-Os arquivos de workflow (`get-shit-done/workflows/*.md`) nunca fazem trabalho pesado. Eles:
+Os arquivos de workflow (`gsd-core/workflows/*.md`) nunca fazem trabalho pesado. Eles:

 - Carregam contexto via `gsd-tools.cjs init <workflow>`
 - Criam agentes especializados com prompts focados
@@ -132,7 +132,7 @@ As descrições dos roteadores usam tags de palavras-chave separadas por pipe (

 A listagem de skills antecipada é um dos dois custos recorrentes de tokens por turno. O outro é o schema de ferramenta MCP injetado por cada servidor MCP habilitado em `.claude/settings.json`. Servidores MCP pesados (browser/playwright, Mac-tools, Windows-tools) podem custar mais de 20 mil tokens por turno cada — muitas vezes eclipsando o que o ajuste do `model_profile` economiza. O controle fica no harness do Claude Code (`enabledMcpjsonServers` / `disabledMcpjsonServers` em `.claude/settings.json`) e **não** é uma preocupação do GSD. Juntos, a camada de roteamento em dois estágios (#2792) e o controle criterioso do MCP são as maiores alavancas de custo por turno. Consulte [`docs/USER-GUIDE.md`](USER-GUIDE.md) e `references/context-budget.md` para o checklist de auditoria.

-### Workflows (`get-shit-done/workflows/*.md`)
+### Workflows (`gsd-core/workflows/*.md`)

 Lógica de orquestração que os comandos referenciam. Contém o processo passo a passo, incluindo:

@@ -161,7 +161,7 @@ espelha a convenção de orçamento de tamanho de agentes:
 o orçamento de bytes do discuss-phase (#717; a divisão discuss-phase/modes mantém ≈32000 bytes). Quando um workflow cresce além de seu tier, extraia os corpos por modo
 em `workflows/<workflow>/modes/<mode>.md`, templates em
 `workflows/<workflow>/templates/`, e conhecimento compartilhado em
-`get-shit-done/references/`. O arquivo pai se torna um despachante leve que
+`gsd-core/references/`. O arquivo pai se torna um despachante leve que
 lê apenas os arquivos de modo e template necessários para a invocação atual.

 `workflows/discuss-phase/` é o exemplo canônico deste padrão —
@@ -182,7 +182,7 @@ Definições de agentes especializados com frontmatter especificando:

 **Total de agentes:** 33

-### Referências (`get-shit-done/references/*.md`)
+### Referências (`gsd-core/references/*.md`)

 Documentos de conhecimento compartilhado que workflows e agentes `@-referenciam` (consulte [`docs/INVENTORY.md`](INVENTORY.md#references-41-shipped) para a contagem oficial e o roster completo):

@@ -236,7 +236,7 @@ O agente planner (`agents/gsd-planner.md`) foi decomposto de um único arquivo m
 - `planner-reviews.md` — Integração de revisão entre IAs (lê REVIEWS.md do `/gsd-review`)
 - `planner-revision.md` — Padrões de revisão de plano para refinamento iterativo

-### Templates (`get-shit-done/templates/`)
+### Templates (`gsd-core/templates/`)

 Templates Markdown para todos os artefatos de planejamento. Usados por `gsd-tools.cjs template fill` / `phase.scaffold` (e `scaffold` de nível superior) para criar arquivos pré-estruturados:
 - `project.md`, `requirements.md`, `roadmap.md`, `state.md` — Arquivos principais do projeto
@@ -268,13 +268,13 @@ Hooks de runtime que se integram ao agente de IA anfitrião:

 Consulte [`docs/INVENTORY.md`](INVENTORY.md#hooks-11-shipped) para o roster oficial de 11 hooks.

-### Hub de Roteamento de Comandos (`get-shit-done/bin/lib/command-routing-hub.cjs`)
+### Hub de Roteamento de Comandos (`gsd-core/bin/lib/command-routing-hub.cjs`)

 Os roteadores de família de comandos CJS despacham através do `CommandRoutingHub`. O hub possui o contrato de resultado puro sem lançamento de exceções (`hub.dispatch()` captura exceções internas e retorna `{ ok: false, kind, ...typedPayload }`) e a taxonomia fechada de erros de runtime (`UnknownCommand`, `InvalidArgs`, `HandlerRefusal`, `HandlerFailure`). Os adaptadores de roteador permanecem como tradutores CLI leves — eles constroem o hub, chamam `dispatch` e depois mapeiam o Result para chamadas `output()`/`error()`. O runtime é de caminho único (sem seleção de modo de runtime duplo). Consulte `docs/adr/0174-retire-gsd-sdk-package-boundary.md`.

-### Ferramentas CLI (`get-shit-done/bin/`)
+### Ferramentas CLI (`gsd-core/bin/`)

-Utilitário CLI Node.js (`gsd-tools.cjs`) com módulos de domínio distribuídos em `get-shit-done/bin/lib/` (consulte [`docs/INVENTORY.md`](INVENTORY.md#cli-modules-33-shipped) para o roster oficial):
+Utilitário CLI Node.js (`gsd-tools.cjs`) com módulos de domínio distribuídos em `gsd-core/bin/lib/` (consulte [`docs/INVENTORY.md`](INVENTORY.md#cli-modules-33-shipped) para o roster oficial):


 | Módulo                 | Responsabilidade                                                                                      |
@@ -481,7 +481,7 @@ UI-SPEC.md (por fase) ───────────────────
 ~/.claude/                          # Claude Code (instalação global)
 ├── skills/gsd-*/SKILL.md           # Skills globais (roster oficial: docs/INVENTORY.md)
 ├── commands/gsd/*.md               # Instalações locais do Claude usam slash commands em vez de skills globais
-├── get-shit-done/
+├── gsd-core/
 │   ├── bin/gsd-tools.cjs           # Utilitário CLI
 │   ├── bin/lib/*.cjs               # Módulos de domínio (roster oficial: docs/INVENTORY.md)
 │   ├── workflows/*.md              # Definições de workflow (roster oficial: docs/INVENTORY.md)
--- a/docs/pt-BR/CLI-TOOLS.md
+++ b/docs/pt-BR/CLI-TOOLS.md
@@ -1,6 +1,6 @@
 # Referência de Ferramentas CLI do GSD

-> Referência para o CLI `gsd-tools` (`get-shit-done/bin/gsd-tools.cjs`). Para comandos slash e fluxos de usuário, consulte a [Referência de Comandos](COMMANDS.md). Voltar ao [índice de documentação](README.md).
+> Referência para o CLI `gsd-tools` (`gsd-core/bin/gsd-tools.cjs`). Para comandos slash e fluxos de usuário, consulte a [Referência de Comandos](COMMANDS.md). Voltar ao [índice de documentação](README.md).

 ---

@@ -11,8 +11,8 @@

 |                    |                                                                                                                                                                                                        |
 | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| **Caminho instalado**   | `get-shit-done/bin/gsd-tools.cjs`                                                                                                                                                                      |
-| **Implementação** | 20 módulos de domínio em `get-shit-done/bin/lib/` (o diretório é autoritativo)                                                                                                                        |
+| **Caminho instalado**   | `gsd-core/bin/gsd-tools.cjs`                                                                                                                                                                      |
+| **Implementação** | 20 módulos de domínio em `gsd-core/bin/lib/` (o diretório é autoritativo)                                                                                                                        |
 | **Status**         | Principal superfície de comandos em tempo de execução para orquestração, fluxos de trabalho e automação. |


@@ -491,7 +491,7 @@ Os slugs são validados contra `[a-zA-Z0-9_-]+`; slugs vazios ou contendo caminh

 ## Tratamento de Segredos

-As chaves de API configuradas via `/gsd-settings` (`brave_search`, `firecrawl`, `exa_search`) são gravadas em texto simples em `.planning/config.json`, mas são mascaradas (`****<last-4>`) em toda saída de `config-set` / `config-get`, tabela de confirmação e prompt interativo. Consulte `get-shit-done/bin/lib/secrets.cjs` para a implementação do mascaramento. O próprio arquivo `config.json` é o limite de segurança — proteja-o com permissões do sistema de arquivos e mantenha-o fora do git (`.planning/` está no gitignore por padrão).
+As chaves de API configuradas via `/gsd-settings` (`brave_search`, `firecrawl`, `exa_search`) são gravadas em texto simples em `.planning/config.json`, mas são mascaradas (`****<last-4>`) em toda saída de `config-set` / `config-get`, tabela de confirmação e prompt interativo. Consulte `gsd-core/bin/lib/secrets.cjs` para a implementação do mascaramento. O próprio arquivo `config.json` é o limite de segurança — proteja-o com permissões do sistema de arquivos e mantenha-o fora do git (`.planning/` está no gitignore por padrão).

 ---

--- a/docs/pt-BR/COMMANDS.md
+++ b/docs/pt-BR/COMMANDS.md
@@ -610,7 +610,7 @@ Exibe os comandos GSD no nível solicitado. O padrão cabe em uma tela; `--full`
 /gsd-help --brief <topic>           # Consulta resumida com escopo — assinatura + resumo em uma linha
 ```

-Consulte `get-shit-done/workflows/help/modes/topic.md` para a tabela completa de aliases. Tópicos desconhecidos exibem a lista reconhecida.
+Consulte `gsd-core/workflows/help/modes/topic.md` para a tabela completa de aliases. Tópicos desconhecidos exibem a lista reconhecida.

 ---

--- a/docs/pt-BR/CONFIGURATION.md
+++ b/docs/pt-BR/CONFIGURATION.md
@@ -184,7 +184,7 @@ Os campos de chave de API aceitam um valor string (a própria chave). Também po
 | `firecrawl` | string \| boolean \| null | `null` | Chave de API Firecrawl para raspagem profunda. Mascarada na exibição |
 | `exa_search` | string \| boolean \| null | `null` | Chave de API Exa Search para busca semântica. Mascarada na exibição |

-**Convenção de mascaramento (`get-shit-done/bin/lib/secrets.cjs`):** chaves com 8 ou mais caracteres são renderizadas como `****<últimos-4>`; chaves menores são renderizadas como `****`; `null`/vazio é renderizado como `(unset)`. O texto simples é escrito como está em `.planning/config.json` — esse arquivo é o limite de segurança — mas a CLI, tabelas de confirmação, logs e descrições de `AskUserQuestion` nunca exibem o texto simples. Isso se aplica à própria saída do comando `config-set`: `config-set brave_search <chave>` retorna um payload JSON com o valor mascarado.
+**Convenção de mascaramento (`gsd-core/bin/lib/secrets.cjs`):** chaves com 8 ou mais caracteres são renderizadas como `****<últimos-4>`; chaves menores são renderizadas como `****`; `null`/vazio é renderizado como `(unset)`. O texto simples é escrito como está em `.planning/config.json` — esse arquivo é o limite de segurança — mas a CLI, tabelas de confirmação, logs e descrições de `AskUserQuestion` nunca exibem o texto simples. Isso se aplica à própria saída do comando `config-set`: `config-set brave_search <chave>` retorna um payload JSON com o valor mascarado.

 ### Roteamento de CLI para Revisão de Código

@@ -256,7 +256,7 @@ Todos os controles de fluxo de trabalho seguem o padrão **ausente = habilitado*
 | `workflow.plan_chunked` | boolean | `false` | Habilita o modo de planejamento em chunks. Quando `true` (ou quando a flag `--chunked` é passada para `/gsd-plan-phase`), o orquestrador divide a única Task de planejamento de longa duração em uma Task curta de esboço seguida de N Tasks curtas por plano (~3-5 min cada). Cada plano é commitado individualmente para resiliência a falhas. Se uma Task travar e o terminal for forçado a fechar, reexecutar com `--chunked` retoma a partir do último plano concluído. Particularmente útil no Windows onde Tasks de longa duração podem travar em stdio. Adicionado na v1.38 |
 | `workflow.code_review_command` | string | (nenhum) | Comando shell para integração de revisão de código externa em `/gsd-ship`. Recebe caminhos de arquivos alterados via stdin. Saída diferente de zero bloqueia o fluxo de trabalho de ship. Adicionado na v1.36 |
 | `workflow.tdd_mode` | boolean | `false` | Habilita o pipeline TDD como modo de execução de primeira classe. Quando `true`, o planejador aplica agressivamente `type: tdd` a tarefas elegíveis (lógica de negócios, APIs, validações, algoritmos) e o executor impõe a sequência de gate RED/GREEN/REFACTOR. Um ponto de revisão colaborativa ao final da fase verifica a conformidade com o gate. Adicionado na v1.36 |
-| `workflow.human_verify_mode` | string | `'end-of-phase'` | Controla os pontos de verificação humana. `'end-of-phase'` (padrão desde #3309) suprime as tasks `checkpoint:human-verify` e incorpora verificações nos blocos `<verify><human-check>` para revisão ao final da fase. `'mid-flight'` restaura as tasks de checkpoint bloqueantes. `checkpoint:decision` e `checkpoint:human-action` não são afetados. Consulte [Referência de Checkpoints](../../get-shit-done/references/checkpoints.md#checkpoint_types). |
+| `workflow.human_verify_mode` | string | `'end-of-phase'` | Controla os pontos de verificação humana. `'end-of-phase'` (padrão desde #3309) suprime as tasks `checkpoint:human-verify` e incorpora verificações nos blocos `<verify><human-check>` para revisão ao final da fase. `'mid-flight'` restaura as tasks de checkpoint bloqueantes. `checkpoint:decision` e `checkpoint:human-action` não são afetados. Consulte [Referência de Checkpoints](../../gsd-core/references/checkpoints.md#checkpoint_types). |
 | `workflow.cross_ai_execution` | boolean | `false` | Delega a execução de fase para uma CLI de IA externa em vez de gerar agentes executores locais. Útil para aproveitar os pontos fortes de um modelo diferente para fases específicas. Adicionado na v1.36 |
 | `workflow.cross_ai_command` | string | (nenhum) | Template de comando shell para execução cross-AI. Recebe o prompt de fase via stdin. Deve produzir saída compatível com SUMMARY.md. Obrigatório quando `cross_ai_execution` é `true`. Adicionado na v1.36 |
 | `workflow.cross_ai_timeout` | number | `300` | Timeout em segundos para comandos de execução cross-AI. Previne processos externos que não terminam. Adicionado na v1.36 |
@@ -285,7 +285,7 @@ O namespace `code_quality.*` controla ferramentas opcionais de análise estrutur

 ## Configurações de Ship

-`ship.pr_body_sections` adiciona seções adicionais ao corpo do PR para conteúdo de PRD/corpo do PR específico do projeto em `/gsd-ship` sem editar `get-shit-done/workflows/ship.md`.
+`ship.pr_body_sections` adiciona seções adicionais ao corpo do PR para conteúdo de PRD/corpo do PR específico do projeto em `/gsd-ship` sem editar `gsd-core/workflows/ship.md`.

 Para um guia do usuário com exemplos de integração e solução de problemas, consulte [Seções Personalizadas do Corpo do PR](../ship-pr-body-sections.md).

@@ -779,7 +779,7 @@ Tokens de flag inválidos são sanitizados e registrados como avisos. Apenas fla
 | gsd-doc-writer | Opus | Sonnet | Haiku | Sonnet | Inherit |
 | gsd-doc-verifier | Sonnet | Sonnet | Haiku | Haiku | Inherit |

-> **Todos os 33 agentes incluídos possuem atribuições explícitas de nível por perfil** no catálogo (`sdk/shared/model-catalog.json`). A tabela acima mostra um subconjunto representativo dos agentes mais usados. Para agentes não listados aqui, `model_overrides` aceita qualquer nome de agente incluído. Os dados autoritativos de perfil são derivados de `sdk/shared/model-catalog.json` via `get-shit-done/bin/lib/model-catalog.cjs` e `sdk/src/model-catalog.ts`.
+> **Todos os 33 agentes incluídos possuem atribuições explícitas de nível por perfil** no catálogo (`sdk/shared/model-catalog.json`). A tabela acima mostra um subconjunto representativo dos agentes mais usados. Para agentes não listados aqui, `model_overrides` aceita qualquer nome de agente incluído. Os dados autoritativos de perfil são derivados de `sdk/shared/model-catalog.json` via `gsd-core/bin/lib/model-catalog.cjs` e `sdk/src/model-catalog.ts`.

 ### Substituições por Agente

--- a/docs/pt-BR/INVENTORY.md
+++ b/docs/pt-BR/INVENTORY.md
@@ -169,7 +169,7 @@ Esses seis roteadores são entradas apenas descritivas que o modelo seleciona pr

 ## Workflows (88 entregues)

-Registro completo em `get-shit-done/workflows/*.md`. Workflows são orquestradores enxutos que os comandos referenciam internamente; a maioria não é lida diretamente pelos usuários finais. As linhas abaixo mapeiam cada arquivo de workflow para sua função (derivada do bloco `<purpose>`) e, quando aplicável, para o comando que o invoca.
+Registro completo em `gsd-core/workflows/*.md`. Workflows são orquestradores enxutos que os comandos referenciam internamente; a maioria não é lida diretamente pelos usuários finais. As linhas abaixo mapeiam cada arquivo de workflow para sua função (derivada do bloco `<purpose>`) e, quando aplicável, para o comando que o invoca.

 | Workflow | Função | Invocado por |
 |----------|--------|--------------|
@@ -268,7 +268,7 @@ Registro completo em `get-shit-done/workflows/*.md`. Workflows são orquestrador

 ## Referências (62 entregues)

-Registro completo em `get-shit-done/references/*.md`. Referências são documentos de conhecimento compartilhado que workflows e agentes `@-reference`. Os agrupamentos abaixo correspondem a [`docs/ARCHITECTURE.md`](ARCHITECTURE.md#references-get-shit-donereferencesmd) — clusters principais, de workflow, de modelo de raciocínio e a decomposição modular do planejador.
+Registro completo em `gsd-core/references/*.md`. Referências são documentos de conhecimento compartilhado que workflows e agentes `@-reference`. Os agrupamentos abaixo correspondem a [`docs/ARCHITECTURE.md`](ARCHITECTURE.md#references-gsd-corereferencesmd) — clusters principais, de workflow, de modelo de raciocínio e a decomposição modular do planejador.

 ### Referências Principais

@@ -363,13 +363,13 @@ O agente `gsd-planner` é decomposto em um agente principal mais módulos de ref
 | `user-story-template.md` | Formato de história de usuário para planejamento MVP — campos estruturados "Como / Quero / Para que". |
 | `spidr-splitting.md` | Regras de decomposição de divisão SPIDR para lidar com histórias de usuário grandes no modo MVP. |

-> **Subdiretório:** `get-shit-done/references/few-shot-examples/` contém exemplos adicionais de few-shot (`plan-checker.md`, `verifier.md`) que são referenciados por agentes específicos. Estes não são contados nas 62 referências de nível superior.
+> **Subdiretório:** `gsd-core/references/few-shot-examples/` contém exemplos adicionais de few-shot (`plan-checker.md`, `verifier.md`) que são referenciados por agentes específicos. Estes não são contados nas 62 referências de nível superior.

 ---

 ## Módulos de CLI (81 entregues)

-Listagem completa: `get-shit-done/bin/lib/*.cjs`.
+Listagem completa: `gsd-core/bin/lib/*.cjs`.

 | Módulo | Responsabilidade |
 |--------|-----------------|
@@ -443,7 +443,7 @@ Listagem completa: `get-shit-done/bin/lib/*.cjs`.
 | `task-command-router.cjs` | Adaptador de roteador de subcomando CJS fino para `gsd-tools task` |
 | `template.cjs` | Seleção e preenchimento de template com substituição de variáveis |
 | `uat.cjs` | Análise de arquivo UAT, rastreamento de dívida de verificação, suporte audit-uat |
-| `ui-safety-gate.cjs` | Detector de token de UI de limite de palavra sem shell (#3706, #3718); lê texto de seção de fase do stdin, sai com 0 (UI encontrada) ou 1 (sem UI); também implantado em `get-shit-done/bin/lib/` para que o instalador GSD o entregue em `$RUNTIME_DIR` (#448) |
+| `ui-safety-gate.cjs` | Detector de token de UI de limite de palavra sem shell (#3706, #3718); lê texto de seção de fase do stdin, sai com 0 (UI encontrada) ou 1 (sem UI); também implantado em `gsd-core/bin/lib/` para que o instalador GSD o entregue em `$RUNTIME_DIR` (#448) |
 | `update-context.cjs` | Resolvedor de contexto de instalação puro para `/gsd:update` — detecção de runtime/escopo/config-dir/versão (LOCAL/GLOBAL/UNKNOWN) portada do bash de update.md; sustenta `gsd-tools update-context` (#498) |
 | `validate-command-router.cjs` | Adaptador de roteador de subcomando CJS fino para `gsd-tools validate` |
 | `validate.cjs` | Auxiliares de normalização de variante de fase puros (`phaseVariants`, `buildRoadmapPhaseVariants`, `buildNotStartedPhaseVariants`) usados por `verify.cjs` para verificações W006/W007; sem I/O, sem async |
--- a/docs/pt-BR/USER-GUIDE.md
+++ b/docs/pt-BR/USER-GUIDE.md
@@ -562,14 +562,14 @@ Para um guia abrangente de solução de problemas, consulte [Recuperar e solucio

 ### CLI programática (`gsd-tools query` vs `gsd-tools.cjs`)

-Para automação, prefira **`gsd-tools query`** com um subcomando registrado (consulte [CLI-TOOLS.md — SDK e acesso programático](CLI-TOOLS.md#sdk-and-programmatic-access) e QUERY-HANDLERS.md). O CLI legado `node $HOME/.claude/get-shit-done/bin/gsd-tools.cjs` continua sendo suportado.
+Para automação, prefira **`gsd-tools query`** com um subcomando registrado (consulte [CLI-TOOLS.md — SDK e acesso programático](CLI-TOOLS.md#sdk-and-programmatic-access) e QUERY-HANDLERS.md). O CLI legado `node $HOME/.claude/gsd-core/bin/gsd-tools.cjs` continua sendo suportado.

 ### STATE.md fora de sincronia

 ```bash
-node "$HOME/.claude/get-shit-done/bin/gsd-tools.cjs" state validate          # Detect drift
-node "$HOME/.claude/get-shit-done/bin/gsd-tools.cjs" state sync --verify     # Preview changes
-node "$HOME/.claude/get-shit-done/bin/gsd-tools.cjs" state sync              # Reconstruct STATE.md
+node "$HOME/.claude/gsd-core/bin/gsd-tools.cjs" state validate          # Detect drift
+node "$HOME/.claude/gsd-core/bin/gsd-tools.cjs" state sync --verify     # Preview changes
+node "$HOME/.claude/gsd-core/bin/gsd-tools.cjs" state sync              # Reconstruct STATE.md
 ```

 ### Um comando parece congelado após "Spawning..."
@@ -667,7 +667,7 @@ Auditoria rápida antes de uma fase longa:

 Cada servidor desabilitado remove seu esquema de cada turno subsequente. Reduzir MCPs **compõe** com o ajuste de `model_profile` — ambas as alavancas são aditivas, e as economias de MCP aparecem imediatamente em cada subagente que o orquestrador gera.

-Para a auditoria completa, referência do harness e a nota de composição com `model_profile`, consulte [Custo de esquema de ferramentas MCP](../../get-shit-done/references/context-budget.md#mcp-tool-schema-cost-harness-concern) na referência `context-budget.md` incluída.
+Para a auditoria completa, referência do harness e a nota de composição com `model_profile`, consulte [Custo de esquema de ferramentas MCP](../../gsd-core/references/context-budget.md#mcp-tool-schema-cost-harness-concern) na referência `context-budget.md` incluída.

 ### Usando runtimes não-Claude (Codex, OpenCode, Gemini CLI, Kilo)

--- a/docs/pt-BR/explanation/context-engineering.md
+++ b/docs/pt-BR/explanation/context-engineering.md
@@ -48,7 +48,7 @@ A engenharia de contexto por si só não é suficiente. Se um agente começa do

 **Desenvolvimento orientado a especificações** significa que toda fase produz artefatos estruturados antes de a execução começar. Um `CONTEXT.md` captura as decisões de implementação da etapa Discuss. Um `RESEARCH.md` registra o que o pesquisador encontrou. Um `PLAN.md` divide o trabalho em tarefas discretas, ordenadas por dependência, com critérios de aceite explícitos. Quando um agente executor toca um arquivo, ele tem uma especificação precisa para seguir — não uma reinterpretação de uma conversa longa.

-**Meta-prompting** significa que as próprias definições de agentes são prompts cuidadosamente engenheirados, não instruções ad-hoc. Os arquivos em `get-shit-done/workflows/` e `agents/` codificam conhecimento conquistado a duras penas sobre como delimitar tarefas, o que verificar e quando escalar para um checkpoint humano. O usuário não precisa reexplicar esse conhecimento a cada sessão; ele está integrado aos próprios prompts do sistema.
+**Meta-prompting** significa que as próprias definições de agentes são prompts cuidadosamente engenheirados, não instruções ad-hoc. Os arquivos em `gsd-core/workflows/` e `agents/` codificam conhecimento conquistado a duras penas sobre como delimitar tarefas, o que verificar e quando escalar para um checkpoint humano. O usuário não precisa reexplicar esse conhecimento a cada sessão; ele está integrado aos próprios prompts do sistema.

 A combinação é deliberada. O contexto limpo garante que cada agente raciocine com clareza. Os artefatos orientados a especificações garantem que cada agente raciocine sobre a *coisa certa*. O meta-prompting garante que cada agente saiba *como* raciocinar bem sobre ela.

--- a/docs/pt-BR/explanation/multi-agent-orchestration.md
+++ b/docs/pt-BR/explanation/multi-agent-orchestration.md
@@ -29,7 +29,7 @@ adequado, coleta o resultado e atualiza o estado compartilhado em `.planning/`.

 ## O padrão orquestrador → agente

-Todos os workflows em `get-shit-done/workflows/` seguem a mesma estrutura:
+Todos os workflows em `gsd-core/workflows/` seguem a mesma estrutura:

 ```text
 Orquestrador (arquivo .md de workflow)
--- a/docs/pt-BR/explanation/security-model.md
+++ b/docs/pt-BR/explanation/security-model.md
@@ -136,7 +136,7 @@ substituir as instruções do agente ou exfiltrar informações.
 O GSD Core trata a injeção de prompt em três níveis.

 **Validação de entrada (`security.cjs`).** O módulo
-`get-shit-done/bin/lib/security.cjs` é o utilitário central de segurança.
+`gsd-core/bin/lib/security.cjs` é o utilitário central de segurança.
 Ele fornece:

 - Prevenção de path traversal: caminhos de arquivo fornecidos pelo usuário
--- a/docs/pt-BR/how-to/recover-and-troubleshoot.md
+++ b/docs/pt-BR/how-to/recover-and-troubleshoot.md
@@ -89,19 +89,19 @@ Isso recria o `STATE.md` ausente, redefine um `config.json` corrompido para os p
 Isso gera o aviso `W002`. Use a CLI de estado para diagnosticar e reparar:

 ```bash
-node "$HOME/.claude/get-shit-done/bin/gsd-tools.cjs" state validate
+node "$HOME/.claude/gsd-core/bin/gsd-tools.cjs" state validate
 ```

 Visualize o que uma sincronização mudaria sem gravar:

 ```bash
-node "$HOME/.claude/get-shit-done/bin/gsd-tools.cjs" state sync --verify
+node "$HOME/.claude/gsd-core/bin/gsd-tools.cjs" state sync --verify
 ```

 Aplique a sincronização:

 ```bash
-node "$HOME/.claude/get-shit-done/bin/gsd-tools.cjs" state sync
+node "$HOME/.claude/gsd-core/bin/gsd-tools.cjs" state sync
 ```

 Esses comandos reconstroem o `STATE.md` a partir do estado real do projeto em disco. Substituem a edição manual do `STATE.md`.
--- a/docs/pt-BR/reference/context-md.md
+++ b/docs/pt-BR/reference/context-md.md
@@ -14,7 +14,7 @@ Toda fase que passou pelo fluxo de trabalho de discussão produz um `CONTEXT.md`

 Por exemplo: `.planning/phases/03-post-feed/03-CONTEXT.md`.

-O arquivo é produzido por `write_context` em `get-shit-done/workflows/discuss-phase.md` (ou seus caminhos expressos de ingestão de PRD / ADR). Ele nunca é editado manualmente durante a operação normal — o fluxo de trabalho discuss-phase o escreve e os agentes downstream o leem como uma fonte de verdade selada.
+O arquivo é produzido por `write_context` em `gsd-core/workflows/discuss-phase.md` (ou seus caminhos expressos de ingestão de PRD / ADR). Ele nunca é editado manualmente durante a operação normal — o fluxo de trabalho discuss-phase o escreve e os agentes downstream o leem como uma fonte de verdade selada.

 ---

--- a/docs/pt-BR/reference/plan-md.md
+++ b/docs/pt-BR/reference/plan-md.md
@@ -122,8 +122,8 @@ Lista os arquivos de workflow que o executor lê antes de começar. Sempre inclu

 ```xml
 <execution_context>
-@~/.claude/get-shit-done/workflows/execute-plan.md
-@~/.claude/get-shit-done/templates/summary.md
+@~/.claude/gsd-core/workflows/execute-plan.md
+@~/.claude/gsd-core/templates/summary.md
 </execution_context>
 ```

--- a/docs/pt-BR/reference/state-md.md
+++ b/docs/pt-BR/reference/state-md.md
@@ -77,7 +77,7 @@ paused_at: null

 ### Valores de status

-`normalizeStateStatus()` em `get-shit-done/bin/lib/state-document.cjs` mapeia o texto bruto do corpo para estes valores canônicos:
+`normalizeStateStatus()` em `gsd-core/bin/lib/state-document.cjs` mapeia o texto bruto do corpo para estes valores canônicos:

 | Valor canônico | Texto correspondente (sem diferenciação de maiúsculas/minúsculas) |
 |---|---|
@@ -133,7 +133,7 @@ Se uma mudança futura substituir o analisador de regex por uma biblioteca YAML

 ## Seções do corpo Markdown

-O corpo (tudo após o `---` de fechamento) segue o template em `get-shit-done/templates/state.md`. As seções padrão são:
+O corpo (tudo após o `---` de fechamento) segue o template em `gsd-core/templates/state.md`. As seções padrão são:

 ### Referência do Projeto

@@ -153,7 +153,7 @@ Onde o projeto está agora:
 | `Last activity:` | Data ISO (`YYYY-MM-DD`) quando escrito por handler; prosa narrativa quando elaborado pelo executor |
 | `Progress:` | Barra visual, ex.: `[████░░░░░░] 40%` |

-Os campos `Status:` e `Last activity:` nesta seção são atualizados pelos handlers do GSD quando o valor existente é um padrão de template conhecido (invariante de Knuth: valores elaborados pelo executor são preservados). A lista completa de padrões de handler conhecidos está em `KNOWN_TEMPLATE_DEFAULTS` dentro de `get-shit-done/bin/lib/state-document.cjs`.
+Os campos `Status:` e `Last activity:` nesta seção são atualizados pelos handlers do GSD quando o valor existente é um padrão de template conhecido (invariante de Knuth: valores elaborados pelo executor são preservados). A lista completa de padrões de handler conhecidos está em `KNOWN_TEMPLATE_DEFAULTS` dentro de `gsd-core/bin/lib/state-document.cjs`.

 ### Métricas de Desempenho