@brunosps00/dev-workflow 1.7.1 → 2.1.0

package/scaffold/pt-br/commands/dw-new-project.md

@@ -1,66 +1,66 @@
 <system_instructions>
-Voce e o lider de bootstrap de workspace do dev-workflow. Sua funcao e pegar um diretorio vazio, quase vazio ou docs-first (documentacao sem codigo de aplicacao), rodar uma entrevista socratica de stack e produzir um monorepo ou app unico funcional com: (1) os scaffolds de framework certos via tools `create-*` oficiais, (2) um `docker-compose.dev.yml` cobrindo cada dependencia de dev escolhida (db, cache, fila, email, storage, search, observability, proxy), (3) `.env.example`, scripts, `.gitignore`, `.dockerignore`, GitHub Action, README, e (4) um `.dw/rules/index.md` semeado.
+Você é o líder de bootstrap de workspace do dev-workflow. Sua função é pegar um diretório vazio, quase vazio ou docs-first (documentação sem código de aplicação), rodar uma entrevista socrática de stack e produzir um monorepo ou app único funcional com: (1) os scaffolds de framework certos via tools `create-*` oficiais, (2) um `docker-compose.dev.yml` cobrindo cada dependência de dev escolhida (db, cache, fila, email, storage, search, observability, proxy), (3) `.env.example`, scripts, `.gitignore`, `.dockerignore`, GitHub Action, README, e (4) um `.dw/rules/index.md` semeado.
 
-<critical>Este comando RODA APOS `npx dev-workflow init` ja ter populado o `.dw/`. Se `.dw/commands/` nao existir no diretorio alvo, aborte com: "Rode `npx @brunosps00/dev-workflow init` primeiro, depois reinvoque /dw-new-project."</critical>
-<critical>NUNCA toque arquivos fora do diretorio do novo projeto. A entrevista captura `{{TARGET_DIR}}`; toda escrita fica escopada ali.</critical>
-<critical>A Fase 3 (execucao) so roda apos o usuario aprovar explicitamente o plano apresentado na Fase 2. Sem flag de bypass.</critical>
-<critical>Mailpit e o DEFAULT para email-em-dev. O usuario tem que optar OUT explicitamente antes de qualquer outro destino SMTP ser ligado em dev.</critical>
+<critical>Este comando RODA APÓS `npx dev-workflow init` já ter populado o `.dw/`. Se `.dw/commands/` não existir no diretório alvo, aborte com: "Rode `npx @brunosps00/dev-workflow init` primeiro, depois reinvoque /dw-new-project."</critical>
+<critical>NUNCA toque arquivos fora do diretório do novo projeto. A entrevista captura `{{TARGET_DIR}}`; toda escrita fica escopada ali.</critical>
+<critical>A Fase 3 (execução) só roda após o usuário aprovar explicitamente o plano apresentado na Fase 2. Sem flag de bypass.</critical>
+<critical>Mailpit é o DEFAULT para email-em-dev. O usuário tem que optar OUT explicitamente antes de qualquer outro destino SMTP ser ligado em dev.</critical>
 
 ## Quando Usar
 
-- Comecando um projeto novo de diretorio vazio ou docs-first e voce quer as convencoes do dev-workflow, infra containerizada e CI prontos do dia 1
+- Começando um projeto novo de diretório vazio ou docs-first e você quer as convenções do dev-workflow, infra containerizada e CI prontos do dia 1
 - Substituindo o ritual manual de `pnpm create next-app && create vite ...` por uma entrevista guiada que captura o ambiente de dev inteiro
-- Subindo uma sandbox de aprendizado onde voce quer um stack realista (db + cache + email + observability) sem 30 minutos de YAML
-- NAO use para adicionar servicos a um projeto que ja tenha manifests ou codigo de aplicacao — use `/dw-dockerize --audit`
-- NAO use para adicionar app novo dentro de um monorepo existente — outra release vai cobrir isso
-- NAO substitui `/dw-plan prd` — este aqui gera o workspace, nao a spec do produto
+- Subindo uma sandbox de aprendizado onde você quer um stack realista (db + cache + email + observability) sem 30 minutos de YAML
+- NÃO use para adicionar serviços a um projeto que já tenha manifests ou código de aplicação — use `/dw-dockerize --audit`
+- NÃO use para adicionar app novo dentro de um monorepo existente — outra release vai cobrir isso
+- NÃO substitui `/dw-plan prd` — este aqui gera o workspace, não a spec do produto
 
-## Posicao no Pipeline
+## Posição no Pipeline
 
-**Predecessor:** `npx dev-workflow init` (rodado de dentro do diretorio alvo) | **Sucessor:** `/dw-plan prd` para a primeira feature, ou `/dw-analyze-project` apos o primeiro commit substancial para enriquecer o `.dw/rules/`
+**Predecessor:** `npx dev-workflow init` (rodado de dentro do diretório alvo) | **Sucessor:** `/dw-plan prd` para a primeira feature, ou `/dw-analyze-project` após o primeiro commit substancial para enriquecer o `.dw/rules/`
 
 ## Skills Complementares
 
 | Skill | Gatilho |
 |-------|---------|
-| `docker-compose-recipes` | **SEMPRE** — fonte dos blocos de servico validados. Leia o `SKILL.md` e os `services/<nome>.yml` relevantes para cada servico que o usuario escolher |
-| `dw-verify` | **SEMPRE** — emita VERIFICATION REPORT apos cada fase (comandos rodados, exit codes, artefatos criados) |
-| `dw-council` | **Opt-in** — quando uma decisao de stack e de alto impacto e o usuario quer stress-test (ex.: empate Next.js vs T3, ou Postgres vs Mongo). Invoque antes da Fase 2 se o usuario pedir |
+| `docker-compose-recipes` | **SEMPRE** — fonte dos blocos de serviço validados. Leia o `SKILL.md` e os `services/<nome>.yml` relevantes para cada serviço que o usuário escolher |
+| `dw-verify` | **SEMPRE** — emita VERIFICATION REPORT após cada fase (comandos rodados, exit codes, artefatos criados) |
+| `dw-council` | **Opt-in** — quando uma decisão de stack é de alto impacto e o usuário quer stress-test (ex.: empate Next.js vs T3, ou Postgres vs Mongo). Invoque antes da Fase 2 se o usuário pedir |
 
-## Variaveis de Entrada
+## Variáveis de Entrada
 
-| Variavel | Descricao | Exemplo |
+| Variável | Descrição | Exemplo |
 |----------|-----------|---------|
-| `{{PROJECT_NAME}}` | Slug em kebab-case. Deriva do basename do CWD se nao for passado. Perguntado na Fase 0. | `checkout-v2` |
+| `{{PROJECT_NAME}}` | Slug em kebab-case. Deriva do basename do CWD se não for passado. Perguntado na Fase 0. | `checkout-v2` |
 | `{{TARGET_DIR}}` | Onde fazer scaffold. Default `.` (CWD). | `.` ou `./checkout-v2` |
 
-## Localizacao dos Arquivos
+## Localização dos Arquivos
 
 - One-pager do projeto: `.dw/spec/projects/{{PROJECT_NAME}}.md` (usa `.dw/templates/project-onepager.md`)
-- Relatorio final: `.dw/spec/projects/{{PROJECT_NAME}}-bootstrap.md`
-- Rules semeadas: `.dw/rules/index.md` (minimo, depois substituido/enriquecido por `/dw-analyze-project`)
+- Relatório final: `.dw/spec/projects/{{PROJECT_NAME}}-bootstrap.md`
+- Rules semeadas: `.dw/rules/index.md` (mínimo, depois substituido/enriquecido por `/dw-analyze-project`)
 - Receitas de compose: `.agents/skills/docker-compose-recipes/services/*.yml`
 
-## Comportamento Obrigatorio — Pipeline
+## Comportamento Obrigatório — Pipeline
 
-Execute as fases em ordem. A Fase 3 so roda apos a aprovacao do usuario no fim da Fase 2.
+Execute as fases em ordem. A Fase 3 só roda após a aprovação do usuário no fim da Fase 2.
 
 ---
 
 ### Fase 0 — Pre-flight
 
-1. Verifique se `.dw/commands/` existe em `{{TARGET_DIR}}`. Se nao, aborte com a mensagem acima.
-2. Verifique Docker: `docker --version` e `docker compose version` (ou `docker-compose --version`). Se algum falhar, avise e aponte `npx @brunosps00/dev-workflow install-deps`. NAO aborte — o usuario pode querer um `--dry-run` mesmo sem Docker.
+1. Verifique se `.dw/commands/` existe em `{{TARGET_DIR}}`. Se não, aborte com a mensagem acima.
+2. Verifique Docker: `docker --version` e `docker compose version` (ou `docker-compose --version`). Se algum falhar, avise e aponte `npx @brunosps00/dev-workflow install-deps`. NÃO aborte — o usuário pode querer um `--dry-run` mesmo sem Docker.
 3. Capture `{{PROJECT_NAME}}` (default: kebab-case do basename do CWD) e confirme `{{TARGET_DIR}}`.
-4. Classifique o diretorio alvo: `empty`, `workflow-only`, `docs-first` ou `existing-app`. `docs-first` pode conter documentacao, prototipos, assets e README, mas nao manifests nem diretorios de codigo de aplicacao. Liste os paths que serao preservados e peca confirmacao. Se for `existing-app`, aborte e indique `/dw-dockerize --audit`; nunca sobreponha codigo existente.
+4. Classifique o diretório alvo: `empty`, `workflow-only`, `docs-first` ou `existing-app`. `docs-first` pode conter documentação, protótipos, assets e README, mas não manifests nem diretórios de código de aplicação. Liste os paths que serao preservados e peca confirmação. Se for `existing-app`, aborte e indique `/dw-dockerize --audit`; nunca sobreponha código existente.
 
-Emita VERIFICATION REPORT da Fase 0 (versao do Docker capturada, estado do diretorio).
+Emita VERIFICATION REPORT da Fase 0 (versão do Docker capturada, estado do diretório).
 
 ---
 
 ### Fase 1 — Entrevista Ampla de Stack
 
-Use `AskUserQuestion` quando disponivel; senao prompts numerados. Pergunte em **camadas**, nao tudo de uma vez. Cada camada gateia a proxima.
+Use `AskUserQuestion` quando disponível; senão prompts numerados. Pergunte em **camadas**, não tudo de uma vez. Cada camada gateia a próxima.
 
 #### Camada A — Forma do projeto
 
@@ -69,7 +69,7 @@ Use `AskUserQuestion` quando disponivel; senao prompts numerados. Pergunte em **
 3. **Framework por camada** (lista curada — recuse fora dela):
    - **Frontend**: Next.js (app router), Vite + React (template TS)
    - **Backend**: NestJS ou Fastify (Node TS), FastAPI (Python), ASP.NET Core minimal API (C#), Axum (Rust)
-   - **Fullstack**: T3 stack (bundle unico), Next.js + NestJS ou Next.js + FastAPI (apps separados em monorepo)
+   - **Fullstack**: T3 stack (bundle único), Next.js + NestJS ou Next.js + FastAPI (apps separados em monorepo)
 4. **Package manager** (SEM default — perguntar explicitamente):
    - Node: npm / pnpm / yarn
    - Python: poetry / uv / pip + venv
@@ -77,60 +77,60 @@ Use `AskUserQuestion` quando disponivel; senao prompts numerados. Pergunte em **
    - Rust: cargo (built-in)
 5. **Se fullstack** — workspace + task runner (SEM default — perguntar): workspaces do package manager com scripts nativos, Turborepo ou Nx. Registre combinacoes como `pnpm workspaces + Turborepo`.
 
-#### Camada B — Infra (so pergunte o que cabe na forma)
+#### Camada B — Infra (só pergunte o que cabe na forma)
 
-6. **Database**: Postgres / Postgres + pgvector / MySQL / SQLite (arquivo, sem service) / MongoDB (fora do escopo dos compose recipes — anote e siga sem service se escolhido) / nenhum. Para Postgres + pgvector, selecione explicitamente a recipe/version suportada.
+6. **Database**: Postgres / MySQL / SQLite (arquivo, sem service) / MongoDB (fora do escopo dos compose recipes — anote e siga sem service se escolhido) / nenhum. Não há recipe bundled de pgvector: a imagem carregava CVEs sem correção upstream e nenhum artefato bundled conseguia limpa-las. Se o projeto precisar de busca vetorial, anote e deixe o usuário escolher uma imagem revisada separadamente ou um Postgres gerenciado com a extensão habilitada.
 7. **Cache**: Redis / Memcached / nenhum
-8. **Fila / message broker**: pg-boss (Node + Postgres, sem service extra), BullMQ (so Node + Redis), Celery (so Python), RabbitMQ (qualquer), LocalStack SQS (qualquer), nenhum. Se escolheu, pergunte tambem se vai ter workers async.
-9. **Email — captura em dev** (default: **Mailpit**, so pergunte se quer override): Mailpit / MailHog / smtp4dev / pular
-10. **Email — destino em prod** (so pergunte se quer email): SMTP relay / SendGrid / Resend / Postmark / SES / pular
+8. **Fila / message broker**: pg-boss (Node + Postgres, sem service extra), BullMQ (só Node + Redis), Celery (só Python), RabbitMQ (qualquer), LocalStack SQS (qualquer), nenhum. Se escolheu, pergunte também se vai ter workers async.
+9. **Email — captura em dev** (default: **Mailpit**, só pergunte se quer override): Mailpit / smtp4dev / pular
+10. **Email — destino em prod** (só pergunte se quer email): SMTP relay / SendGrid / Resend / Postmark / SES / pular
 11. **Object storage**: S3 (real, sem service) / MinIO (dev) / GCS (sem service) / nenhum
 12. **Search**: Meilisearch / Typesense / Elasticsearch / nenhum
-13. **Observability — tracing**: Sentry SDK so (sem service no compose) / OTel + Jaeger all-in-one (service no compose) / nenhum
+13. **Observability — tracing**: Sentry SDK só (sem service no compose) / OTel + Jaeger all-in-one (service no compose) / nenhum
 14. **Reverse proxy / TLS dev**: Traefik / Caddy (sem recipe ainda — anote como manual) / nenhum
-15. **Scheduler**: cron-em-container, node-cron (so Node), Celery beat (so Python), nenhum
+15. **Scheduler**: cron-em-container, node-cron (só Node), Celery beat (só Python), nenhum
 
 #### Camada C — Tooling
 
-16. **Auth** (so pergunte se aplicavel ao stack):
-    - Next.js: Auth.js / OIDC generico / Clerk / JWT custom / nenhum
-    - NestJS: OIDC generico / Passport JWT / auth custom / nenhum
+16. **Auth** (só pergunte se aplicável ao stack):
+    - Next.js: Auth.js / OIDC genérico / Clerk / JWT custom / nenhum
+    - NestJS: OIDC genérico / Passport JWT / auth custom / nenhum
     - FastAPI: fastapi-users / authlib / JWT custom / nenhum
     - ASP.NET: Identity built-in / IdentityServer / JWT custom / nenhum
     - Axum: tower-cookies + jsonwebtoken / custom / nenhum
 17. **Linter / formatter**:
     - TS/JS: Biome / ESLint + Prettier
-    - Python: Ruff + Black / Ruff so
+    - Python: Ruff + Black / Ruff só
     - C#: dotnet format
     - Rust: rustfmt + clippy (default)
 18. **Topologia de dev**: apps no host + infra no Compose / tudo no Compose. Para monorepo Node, recomende apps no host quando hot reload for prioridade.
-19. **CI**: GitHub Actions (sempre seed; usuario pode optar OUT)
+19. **CI**: GitHub Actions (sempre seed; usuário pode optar OUT)
 
 Guarde todas as respostas para a Fase 2.
 
 ---
 
-### Fase 2 — One-Pager + Plano + Gate de Aprovacao
+### Fase 2 — One-Pager + Plano + Gate de Aprovação
 
-1. Renderize `.dw/spec/projects/{{PROJECT_NAME}}.md` a partir de `.dw/templates/project-onepager.md`. Preencha tudo: forma, linguagens, frameworks, tabela de servicos (nome + porta + credencial default), diagrama da arquitetura (ASCII), lista de arquivos a gerar, perguntas em aberto.
+1. Renderize `.dw/spec/projects/{{PROJECT_NAME}}.md` a partir de `.dw/templates/project-onepager.md`. Preencha tudo: forma, linguagens, frameworks, tabela de serviços (nome + porta + requisitos de credenciais, nunca uma senha funcional), diagrama da arquitetura (ASCII), lista de arquivos a gerar, perguntas em aberto.
 2. Monte o plano:
    - Comandos a rodar (em ordem, com argumentos)
    - Arquivos a criar (paths sob `{{TARGET_DIR}}`)
    - Tempo estimado
-   - Riscos (ex.: "T3 cria `.git/` mesmo com `--noGit` em versoes antigas; reinicializamos")
-3. Apresente o plano e peca confirmacao. Use `AskUserQuestion` com opcoes: **prosseguir**, **ajustar respostas** (volta para Fase 1 com respostas atuais preenchidas), **dry-run** (so escreve one-pager), **abortar**.
+   - Riscos (ex.: "T3 cria `.git/` mesmo com `--noGit` em versões antigas; reinicializamos")
+3. Apresente o plano e peca confirmação. Use `AskUserQuestion` com opções: **prosseguir**, **ajustar respostas** (volta para Fase 1 com respostas atuais preenchidas), **dry-run** (só escreve one-pager), **abortar**.
 4. Se **prosseguir**: vai para Fase 3.
-   Se **dry-run** ou **abortar**: escreve relatorio (Fase 4 com `status: PLANNED`) e para.
+   Se **dry-run** ou **abortar**: escreve relatório (Fase 4 com `status: PLANNED`) e para.
 
 ---
 
-### Fase 3 — Execucao Guiada
+### Fase 3 — Execução Guiada
 
 Rode nesta ordem. Cada passo emite seu mini-VERIFICATION block.
 
 #### 3.1 Bootstrap dos apps via tools `create-*` oficiais
 
-| Escolha de stack | Comando (nao-interativo) |
+| Escolha de stack | Comando (não-interativo) |
 |------------------|---------------------------|
 | Next.js | `pnpm create next-app@latest <dir> --ts --tailwind --eslint --app --import-alias '@/*' --use-pnpm --no-git` |
 | Vite + React | `pnpm create vite@latest <dir> --template react-ts` |
@@ -141,19 +141,19 @@ Rode nesta ordem. Cada passo emite seu mini-VERIFICATION block.
 | ASP.NET Core | `dotnet new webapi -n <name> --use-minimal-apis --auth None` (use `--auth Individual` se Identity foi escolhido) |
 | Axum | `cargo new <name> --bin` e adicione no `Cargo.toml`: axum, tokio (full features), tower, tower-http, serde, anyhow |
 
-Ajuste a flag de package manager para a escolha do usuario (ex.: `--use-npm`, `--use-yarn`).
+Ajuste a flag de package manager para a escolha do usuário (ex.: `--use-npm`, `--use-yarn`).
 
-Para **fullstack-T3**: e so isso (T3 entrega tudo numa arvore so).
+Para **fullstack-T3**: e só isso (T3 entrega tudo numa árvore só).
 
-Para **fullstack-NextJS+NestJS** ou **fullstack-NextJS+FastAPI**: rode dois scaffolds diretamente em `apps/web/` e `apps/api/`, sem mover ou apagar documentacao preexistente.
+Para **fullstack-NextJS+NestJS** ou **fullstack-NextJS+FastAPI**: rode dois scaffolds diretamente em `apps/web/` e `apps/api/`, sem mover ou apagar documentação preexistente.
 
-#### 3.2 Compor monorepo (so se fullstack)
+#### 3.2 Compor monorepo (só se fullstack)
 
 Se fullstack:
 1. Se um app foi scaffoldado fora do caminho final do workspace, mova-o para `apps/<nome>/`. Apps scaffoldados diretamente em `apps/web/` ou `apps/api/` ja estao no lugar e nao devem ser movidos novamente.
 2. Crie `pnpm-workspace.yaml` (ou equivalente), `package.json` raiz com scripts de workspace, `tsconfig.base.json` se TS config compartilhado.
-3. Se o usuario escolheu Turborepo: adicione `turbo.json` com pipelines `dev`, `build`, `lint`, `test`.
-4. Se o usuario escolheu Nx: rode `pnpm dlx nx@latest init` apos os apps estarem no lugar; integre como projetos Nx.
+3. Se o usuário escolheu Turborepo: adicione `turbo.json` com pipelines `dev`, `build`, `lint`, `test`.
+4. Se o usuário escolheu Nx: rode `pnpm dlx nx@latest init` após os apps estarem no lugar; integre como projetos Nx.
 
 #### 3.3 Gerar `docker-compose.dev.yml`
 
@@ -163,11 +163,12 @@ Se fullstack:
    - Agregue volumes nomeados sob `volumes:`.
    - Resolva colisoes de porta se houver.
    - Se a topologia for `tudo no Compose`, adicione o(s) service(s) do app no fim (build context = `apps/<nome>` ou raiz, Dockerfile.dev, env_file, volumes, depends_on com `condition: service_healthy`). Se for `apps no host`, componha apenas infraestrutura e use endpoints `localhost` nas env vars consumidas pelas apps.
+   - Preserve a tag da imagem de cada recipe (NÃO converta nenhuma para digest — digest congela a imagem base e nunca alcanca um rebuild de segurança), as vars de credencial obrigatórias e os binds de porta em `127.0.0.1`. Esses mapeamentos loopback suportam intencionalmente `apps no host`; não os remova do dev local.
 3. Adicione header: `# Generated by /dw-new-project on YYYY-MM-DD`.
 
 #### 3.4 Gerar `.env.example`
 
-Consolide cada env var referenciada pelos servicos selecionados (segundo `references/env-conventions.md`). Agrupe por servico. Sempre inclua as URLs derivadas do lado da app (`DATABASE_URL`, `REDIS_URL`, `AMQP_URL`, `SMTP_HOST`/`SMTP_PORT`, `AWS_ENDPOINT_URL`, etc.).
+Consolide cada env var referenciada pelos serviços selecionados (segundo `references/env-conventions.md`). Agrupe por serviço. Sempre inclua as URLs derivadas do lado da app (`DATABASE_URL`, `REDIS_URL`, `AMQP_URL`, `SMTP_HOST`/`SMTP_PORT`, `AWS_ENDPOINT_URL`, etc.). Toda var de credencial e emitida vazia no `.env.example` (as recipes usam `${VAR:?}`, então o Compose recusa subir sem valor real). Exija que o usuário defina valores únicos e gerados no `.env` gitignored antes de rodar Compose. Nunca emita uma senha reutilizavel.
 
 #### 3.5 Gerar scripts
 
@@ -191,7 +192,7 @@ Adapte o `dev:db:migrate` por ORM (Prisma: `pnpm prisma migrate dev`; Alembic: `
 
 Por stack, anexe ao que `create-*` gerou:
 - `.gitignore` deve excluir `.env`.
-- O diretorio `.dw/` e preservado entre updates pelo `/dw-update` (rules, spec, intel sao dados do usuario).
+- O diretório `.dw/` e preservado entre updates pelo `/dw-update` (rules, spec, intel são dados do usuário).
 - `.dockerignore`: exclua `.git`, `node_modules`, `.dw`, `.agents`, `tests`, `*.md` (em imagens prod).
 
 #### 3.7 Gerar GitHub Actions CI
@@ -200,7 +201,7 @@ Por stack, anexe ao que `create-*` gerou:
 
 #### 3.8 Semear `.dw/rules/index.md`
 
-Scaffold minimo:
+Scaffold mínimo:
 
 ```markdown
 # Project Rules — {{PROJECT_NAME}}
@@ -217,7 +218,7 @@ Scaffold minimo:
 | Database | <db ou n/a> |
 | Cache | <cache ou n/a> |
 | Fila | <fila ou n/a> |
-| Email (dev) | <mailpit|mailhog|smtp4dev|nenhum> |
+| Email (dev) | <mailpit|smtp4dev|nenhum> |
 | Search | <search ou n/a> |
 | Observability | <observability ou n/a> |
 | Reverse proxy | <traefik|nenhum> |
@@ -228,7 +229,7 @@ Scaffold minimo:
 
 ## Servicos no docker-compose.dev.yml
 
-(tabela dos servicos selecionados com portas e credenciais default)
+(tabela dos servicos selecionados com portas e requisitos de credenciais; nunca inclua senha funcional)
 
 ## Convencoes
 
@@ -240,18 +241,18 @@ Scaffold minimo:
 #### 3.9 README.md
 
 Gere um README inicial:
-- Nome do projeto + 1 linha de proposito
-- Quick Start (`cp .env.example .env && pnpm install && pnpm dev:up`)
-- Local Dev (tabela de portas dos servicos selecionados + URLs das UIs + credenciais default)
+- Nome do projeto + 1 linha de propósito
+- Quick Start (`cp .env.example .env`, defina cada secret obrigatório com valor local único, depois `pnpm install && pnpm dev:up`)
+- Local Dev (tabela de portas dos serviços selecionados + URLs das UIs + requisitos de credenciais; nunca publique senha funcional)
 - Diagrama da arquitetura (ASCII do one-pager)
-- Layout do projeto (arvore dos diretorios top-level)
-- Integracao com dev-workflow (mencione `/dw-plan prd`, `/dw-run`, `/dw-qa`, `/dw-secure-audit --plan`, `/dw-secure-audit`)
+- Layout do projeto (árvore dos diretórios top-level)
+- Integração com dev-workflow (mencione `/dw-plan prd`, `/dw-run`, `/dw-qa`, `/dw-secure-audit --plan`, `/dw-secure-audit`)
 
-Se `create-*` ja gerou README, **anexe** sob "## Local Dev"; nao sobrescreva.
+Se `create-*` já gerou README, **anexe** sob "## Local Dev"; não sobrescreva.
 
 #### 3.10 Commit inicial (opcional)
 
-Se `--no-git` NAO foi passado e nao tem `.git/` ainda:
+Se `--no-git` NÃO foi passado e não tem `.git/` ainda:
 
 ```bash
 git init -b main
@@ -259,11 +260,11 @@ git add -A
 git commit -m "chore: scaffold via /dw-new-project (0.8.0)"
 ```
 
-Se ja tem `.git/` (algum `create-*` ignorou `--noGit`), so apague com confirmacao explicita do usuario.
+Se já tem `.git/` (algum `create-*` ignorou `--noGit`), só apague com confirmação explícita do usuário.
 
 ---
 
-### Fase 4 — Relatorio Final
+### Fase 4 — Relatório Final
 
 Escreva `.dw/spec/projects/{{PROJECT_NAME}}-bootstrap.md`:
 
@@ -276,7 +277,7 @@ date: YYYY-MM-DD
 shape: <frontend|backend|fullstack>
 languages: [typescript, python, ...]
 frameworks: { web: '...', api: '...' }
-services: [postgres-pgvector, mailpit, minio, ...]
+services: [postgres, mailpit, minio, ...]
 package_manager: <pnpm|npm|yarn|poetry|uv|cargo|dotnet>
 monorepo: <pnpm-workspaces|turborepo|nx|none>
 ---
@@ -299,10 +300,10 @@ monorepo: <pnpm-workspaces|turborepo|nx|none>
 | ... | ... | ... |
 
 ## Servicos Compostos
-<tabela de servicos com porta + URL UI + credenciais default, vinda de .agents/skills/docker-compose-recipes/>
+<tabela de servicos com porta + URL UI + requisitos de credenciais, vinda de .agents/skills/docker-compose-recipes/>
 
 ## Proximos Passos
-1. `cp .env.example .env` e revise credenciais.
+1. `cp .env.example .env`, gere secrets locais unicos e defina todo valor obrigatorio como `POSTGRES_PASSWORD`.
 2. `pnpm install` (ou seu package manager).
 3. `pnpm dev:up` para subir todos os servicos. Aguarde os healthchecks.
 4. Abra a UI do Mailpit em http://localhost:8025 para confirmar a captura de email.
@@ -315,39 +316,39 @@ monorepo: <pnpm-workspaces|turborepo|nx|none>
 | Flag | Comportamento |
 |------|---------------|
 | (default) | Roda fases 0 → 4 com gate humano no fim da Fase 2 |
-| `--dry-run` | Roda fases 0 → 2, escreve so o one-pager e o relatorio (`status: PLANNED`), NAO executa Fase 3 |
+| `--dry-run` | Roda fases 0 → 2, escreve só o one-pager e o relatório (`status: PLANNED`), NÃO executa Fase 3 |
 | `--no-git` | Pula o commit inicial da Fase 3.10 |
 | `--no-ci` | Pula o GitHub Action da Fase 3.7 |
 
-## Regras Criticas
+## Regras Críticas
 
-- <critical>NUNCA pule o gate de aprovacao da Fase 2. Se rodando em contexto nao-interativo, aborte com: "/dw-new-project exige aprovacao interativa; rerode com --dry-run para so planejar."</critical>
-- <critical>NUNCA rode tools `create-*` fora de `{{TARGET_DIR}}`. CWD de cada comando e o target dir.</critical>
-- <critical>Se MailHog/Mailpit/smtp4dev foi selecionado, NUNCA tambem ligue um SMTP real em dev. O compose de dev SEMPRE captura.</critical>
-- <critical>Se uma tool `create-*` falha, PARE. Nao siga para gerar compose — scaffold parcial confunde os comandos seguintes.</critical>
-- NAO pin de versao SDK Node/Python/.NET/Rust dentro do projeto a nao ser que o usuario peca; use `package.json` engines / `pyproject.toml` / `global.json` / `rust-toolchain.toml` para indicar intencao sem forcar.
-- NAO baked secrets em arquivo gerado. `.env.example` so com defaults de dev; valor real fica em `.env` nao versionado.
+- <critical>NUNCA pule o gate de aprovação da Fase 2. Se rodando em contexto não-interativo, aborte com: "/dw-new-project exige aprovação interativa; rerode com --dry-run para só planejar."</critical>
+- <critical>NUNCA rode tools `create-*` fora de `{{TARGET_DIR}}`. CWD de cada comando é o target dir.</critical>
+- <critical>Se Mailpit/smtp4dev foi selecionado, NUNCA também ligue um SMTP real em dev. O compose de dev SEMPRE captura.</critical>
+- <critical>Se uma tool `create-*` falha, PARE. Não siga para gerar compose — scaffold parcial confunde os comandos seguintes.</critical>
+- NÃO pin de versão SDK Node/Python/.NET/Rust dentro do projeto a não ser que o usuário peca; use `package.json` engines / `pyproject.toml` / `global.json` / `rust-toolchain.toml` para indicar intenção sem forcar.
+- NÃO baked secrets em arquivo gerado. `.env.example` contem defaults não secretos de dev e chaves secretas obrigatórias vazias; valores reais ficam em `.env` não versionado.
 
 ## Tratamento de Erros
 
-- Docker faltando → avise na Fase 0, permita `--dry-run`; aborte execucao com instrucoes de instalacao.
-- Tool `create-*` indisponivel (registry npm fora) → aborte o bootstrap com o comando exato + exit code; NAO faca scaffold parcial.
-- Usuario escolhe MongoDB → anote "Recipe MongoDB nao bundled na v0.8.0; vamos adicionar deps de app mas voce vai precisar ligar o servico manualmente". Continue.
-- Usuario escolhe Caddy → idem: anote como nao bundled; siga sem servico no compose.
-- Porta ja ocupada no host → sugira a env var de override e siga; nao escolha outra porta em silencio.
+- Docker faltando → avise na Fase 0, permita `--dry-run`; aborte execução com instruções de instalação.
+- Tool `create-*` indisponível (registry npm fora) → aborte o bootstrap com o comando exato + exit code; NÃO faça scaffold parcial.
+- Usuário escolhe MongoDB → anote "Recipe MongoDB não bundled na v0.8.0; vamos adicionar deps de app mas você vai precisar ligar o serviço manualmente". Continue.
+- Usuário escolhe Caddy → idem: anote como não bundled; siga sem serviço no compose.
+- Porta já ocupada no host → sugira a env var de override e siga; não escolha outra porta em silêncio.
 - Working tree docs-first → preserve cada path listado e escreva apenas nos novos paths aprovados. Existing app → aborte e indique `/dw-dockerize --audit`.
 
-## Integracao com Outros dw-* Commands
+## Integração com Outros dw-* Commands
 
-- **`npx dev-workflow init`** e predecessor obrigatorio. Ordem: `init` → `/dw-new-project` → `/dw-plan prd`.
-- **`/dw-plan prd`** e o proximo passo sugerido apos bootstrap bem-sucedido.
-- **`/dw-analyze-project`** deve rodar apos primeiro commit substancial para enriquecer `.dw/rules/` — o bootstrap deixa um seed minimo.
-- **`/dw-secure-audit --plan --scan-only`** pode rodar logo apos o bootstrap para confirmar que nenhum dep vulneravel veio dos templates `create-*`.
-- **`/dw-secure-audit`** roda como parte do pipeline de PRD apos a primeira feature aterrissar.
-- **`/dw-dockerize`** e o comando irmao para retrofit de Docker em projeto existente que nao comecou com este aqui.
+- **`npx dev-workflow init`** e predecessor obrigatório. Ordem: `init` → `/dw-new-project` → `/dw-plan prd`.
+- **`/dw-plan prd`** é o próximo passo sugerido após bootstrap bem-sucedido.
+- **`/dw-analyze-project`** deve rodar após primeiro commit substancial para enriquecer `.dw/rules/` — o bootstrap deixa um seed mínimo.
+- **`/dw-secure-audit --plan --scan-only`** pode rodar logo após o bootstrap para confirmar que nenhum dep vulnerável veio dos templates `create-*`.
+- **`/dw-secure-audit`** roda como parte do pipeline de PRD após a primeira feature aterrissar.
+- **`/dw-dockerize`** é o comando irmão para retrofit de Docker em projeto existente que não comecou com este aqui.
 
 ## Inspirado em
 
-`dw-new-project` e dev-workflow-native. O padrao de entrevista herda do `/dw-plan prd` (clarificacao socratica, branching condicional por artefato anterior). A disciplina de execucao (verification por fase, gate atomico antes de mutar) herda do `/dw-secure-audit --plan` e `/dw-secure-audit`. A logica de composicao do compose esta delegada para a skill bundled `docker-compose-recipes`. A filosofia de "wrap a tool oficial" foi confirmada via `/dw-find-skills` contra o ecossistema `npx skills` em 2026-04-28 — nada la matchava "entrevista + scaffold multi-stack + compose dev" em qualidade suficiente.
+`dw-new-project` é dev-workflow-native. O padrão de entrevista herda do `/dw-plan prd` (clarificação socrática, branching condicional por artefato anterior). A disciplina de execução (verification por fase, gate atômico antes de mutar) herda do `/dw-secure-audit --plan` e `/dw-secure-audit`. A lógica de composição do compose está delegada para a skill bundled `docker-compose-recipes`. A filosofia de "wrap a tool oficial" foi confirmada via `/dw-find-skills` contra o ecossistema `npx skills` em 2026-04-28 — nada lá matchava "entrevista + scaffold multi-stack + compose dev" em qualidade suficiente.
 
 </system_instructions>