@neetru/cli 2.33.0 → 2.34.0

package/CHANGELOG.md

@@ -4,6 +4,66 @@ Convenção: [Keep a Changelog](https://keepachangelog.com/) + [SemVer](https://
 
 ## [Unreleased]
 
+## [2.34.0] — 2026-10-26 (`neetru environments repoint` e Dockerfile gerado certo para monorepo e pnpm/yarn/bun)
+
+> **Por que MINOR.** Entra um comando novo (`neetru environments repoint`), sem quebrar comportamento existente; o resto são correções. O `repoint` só funciona contra um Core com a rota `POST /api/cli/v1/products/{slug}/environments/{env}/server` no ar (neetru-core ca18fea); antes disso o Core responde 404.
+
+### Adicionado
+
+- **`neetru environments repoint <slug> <staging|prod> --to <serverId> --expect-from <serverId> --reason "<motivo>"`: re-aponta o ambiente de um produto para outra VM sem PATCH manual no Firestore** (bug_7446f7f2; precisa do Core com a rota `POST /api/cli/v1/products/{slug}/environments/{env}/server` no ar). Antes nenhum comando mudava a VM que o ambiente aponta: só o Dev Core, à mão, o que travava o go-live quando ele estava fora. Só o ponteiro muda — o app continua onde está até o próximo `neetru deploy --target vm --env <env> --server <serverId>`, e a promoção de staging para prod passa a usar a VM apontada. `--dry-run` mostra os requisitos sem gravar e sem MFA (VM nova pronta, da frota, aceitando app, com espaço e IP público; nenhum outro ambiente do produto nela; banco do ambiente noutra VM só com a porta de entrada ligada para a VM nova). Fora dele, admin + MFA (`--mfa-token` ou a sessão de `neetru auth mfa-session`). `--expect-from` protege contra mudar um estado que você não viu: se o ambiente já aponta outra VM, nada é gravado. Cada recusa do Core (`REPOINT_*`) sai com a mensagem do Core e o que fazer. O grupo novo se chama `environments` porque `neetru env` já cuida do NEETRU_ENV local e das variáveis do Cloud Run.
+
+### Corrigido
+
+- **`neetru deploy --target cloud-run` sem Dockerfile: o template gerado para `--stack=node|nextjs` passa a usar o gerenciador de pacote certo e o layout aninhado do monorepo** (bug_1dcf8e03, achado na revisão do cli#106). O template supunha sempre app único com npm: `COPY package*.json ./` + `RUN npm ci --omit=dev` e `CMD node server.js`/`.next/standalone` na raiz de `/app`. Num projeto pnpm/yarn/bun sem `package-lock.json` o `npm ci` falhava de cara; em monorepo o contexto era sempre o `cwd` (as dependências `workspace:*` não resolvem sem o workspace inteiro) e o entrypoint do standalone ficava aninhado em `apps/web/server.js`, não na raiz.
+  - `generateDockerfileTemplate` chama `detectPackageManager` (`build-targets.ts`, a mesma detecção do cli#106) a partir do `cwd` de onde `neetru deploy` roda. Com `pm.rootDir !== cwd` (monorepo), o `appPrefix` relativo é o mesmo conceito de `relativeAppDir` do cli#106: o build context vira a raiz do workspace (`pm.rootDir`, onde mora o lockfile — `workspace:*` só resolve com o monorepo inteiro), o Dockerfile instala e builda lá, e o runner copia o standalone aninhado (`<prefixo>/.next/standalone/<prefixo>/server.js`) e aponta `CMD ["node", "<prefixo>/server.js"]`. O caminho de hoje (app na raiz, `cwd === pm.rootDir`) preserva o shape de 3 estágios (deps/builder/runner) de antes — só o gerenciador muda.
+  - O install usa pnpm (`corepack enable` + `pnpm install`), yarn (`corepack enable` + `yarn install`) ou bun (instalado via script oficial, já que a imagem `node:22-slim` só traz npm) conforme o lockfile/`packageManager` detectado; com lockfile presente prefere `npm ci`/`--frozen-lockfile` (reprodutível), sem lockfile cai pro install não travado — nos dois casos sem exigir `package-lock.json` de quem não usa npm.
+  - O Dockerfile gerado (e sua limpeza, no `finally`) agora é escrito no build context resolvido, não sempre em `cwd` — em monorepo isso é a raiz do workspace.
+  - **Fica de fora:** yarn berry (2+) com PnP (o template assume `node-modules` linker); workspaces `npm`/`yarn` nativos (sem lockfile de 3º nível) não foram testados — só pnpm (fixture de monorepo) e npm de app único (fixture de hoje). O README (seção Build de monorepo) ainda recomenda o Dockerfile próprio pra casos fora dessas duas fixtures.
+
+- **`neetru ai`, `neetru auth` e `neetru config` param de oferecer a API da Anthropic e o Gemini, e a CLI passa a ter uma lista só de provedores de IA** (bug_19d312f3, achado no pacote publicado). A 2.33.0 tinha duas listas que discordavam: `neetru ai` e `neetru auth` com anthropic, openai, gemini, groq e nvidia; `neetru code`, `neetru ai models` e a config do AI Gateway com groq, nvidia e openai. A primeira oferecia dois provedores que a casa não usa (IA só de provedor gratuito; a API da Anthropic e o Gemini custam e estão vetados). E o `neetru ai` ainda saía usando ANTHROPIC_API_KEY ou GEMINI_API_KEY achadas na máquina, sem o dev escolher. Agora:
+  - A lista mora num lugar só (`src/lib/ai/provedores.ts`): Groq, NVIDIA NIM e OpenAI. Todo lugar que enumera provedor lê dela. O teste `provedores-ia-lista-unica.test.ts` trava a lista e falha se outro arquivo de `src/` declarar lista própria ou se um texto voltar a citar Anthropic ou Gemini, a chave, a variável de ambiente, o SDK ou o endereço da API deles.
+  - `neetru auth status|setup|pull` mostra Groq, NVIDIA NIM e OpenAI (antes: Claude, Codex e Gemini; Groq e NVIDIA nem apareciam). Para Groq e NVIDIA o assistente pede a chave direto, sem programa para instalar.
+  - O `auth pull` e o `auth setup` não copiam mais para a config a chave que vem do ambiente (GROQ_API_KEY, NVIDIA_API_KEY, OPENAI_API_KEY): a CLI já a lê direto da variável, e a cópia passava a valer mais que ela (a chave da config vem primeiro), então trocar a chave na variável deixava a CLI usando a antiga. A chave do arquivo do Codex continua sendo copiada. O assistente também não pede de novo um provedor que já tem chave na config, e o `auth status` mostra esse provedor pronto e diz que a CLI usa a chave da config.
+  - A descoberta não lê mais ANTHROPIC_API_KEY, GEMINI_API_KEY, GOOGLE_API_KEY nem os arquivos do Claude Code e do Gemini. Chave da Anthropic ou do Gemini, na config ou na máquina, não libera mais o `neetru ai`.
+  - A dependência `@anthropic-ai/sdk` sai do package.json e do package-lock.json, e com ela os pacotes que só ela usava (`json-schema-to-ts`, `ts-algebra`, `@babel/runtime`, `standardwebhooks`, `@stablelib/base64`, `fast-sha256`): o `npm i -g @neetru/cli` não baixa mais o SDK da Anthropic. O teste também confere o package.json e o lock.
+  - O `auto` do `neetru ai` prefere os provedores gratuitos: geração de código vai primeiro para a NVIDIA NIM, pergunta curta para o Groq e, no resto, a ordem é Groq, NVIDIA NIM e só então a OpenAI (antes a OpenAI, que é paga, vinha primeiro na geração de código e no resto, e uma OPENAI_API_KEY na máquina bastava para ela atender sem o dev escolher). A OpenAI só entra no `auto` quando nenhum gratuito tem chave; com `-m openai` ela é usada direto.
+  - `neetru ai -m <nome>` e o `/debug:model` aceitam `groq | nvidia | openai | gateway | auto`. `-m claude`, `-m gemini` ou um nome qualquer saem com exit 1 dizendo o que aceitam (antes caíam calados no `auto`).
+  - Sem `-m`, o `neetru ai` passa a usar o `defaultModel` da config, que começa em `auto`. Antes o `-m` tinha `auto` de padrão e o `defaultModel` nunca era lido pelo `neetru ai`: `neetru config set defaultModel groq` não tinha efeito.
+  - `neetru config set` recusa `anthropicApiKey`, `geminiApiKey`, `claudeModel`, `geminiModel` e `defaultModel` fora da lista. Um config.json antigo com essas chaves, ou com `defaultModel: "claude"`, continua carregando: as chaves só deixam de ser lidas. Com o `defaultModel` antigo, o `neetru ai` sem `-m` sai com exit 1 dizendo para rodar `neetru config set defaultModel auto` (ou abrir com `-m <modelo>`).
+  - O `/agentes` (vários modelos em paralelo) consulta na ordem da lista: Groq, NVIDIA NIM, OpenAI.
+  - `neetru code --provider <nome fora da lista>` (ex.: `gemini`) avisa que o nome não existe e qual a lista. O pedido segue sem provedor forçado, como antes (antes não avisava).
+  - **Quebra:** quem usava o `neetru ai` só com chave da Anthropic ou do Gemini fica sem provedor. Sem sessão do `neetru login`, o `neetru ai` abre o assistente do `neetru auth setup`. Com sessão, o REPL abre, mas o `auto` não usa o AI Gateway por conta própria (isso gasta a cota do gateway): cada pergunta responde que não há provedor com chave e diz como pedir o gateway (`neetru ai -m gateway` ou `neetru config set defaultModel gateway`). O `neetru auth status --json` perde `anthropic` e `gemini` em `configured` e em `providers`. Quem dependia do `auth pull` para gravar a OPENAI_API_KEY do ambiente na config passa a gravá-la com `neetru config set openaiApiKey <chave>`.
+  - **Fica para depois:** a OpenAI segue na lista. É paga, mas não estava no veto do bug e as duas listas já concordavam nela; tirar ou não é decisão do dono. Até lá, o `auto` só a usa quando nenhum gratuito tem chave.
+
+- **`neetru deploy --target vm`: o aviso do `--port` e a ajuda passam a dizer que cada produto tem UM app por ambiente na VM, e como ter dois** (bug_6d92ef71, 2ª metade). O Core reconhece o app pelo par produto + ambiente (`appKeyOf` no `port-registry` do Core): um 2º deploy do mesmo produto no mesmo ambiente reusa a mesma porta e o mesmo endereço e substitui o 1º. O aviso antigo ("a porta é gerenciada pelo Core… --port é ignorado") confirmava a limitação e não dava saída a quem passou `--port` querendo um segundo app (ex.: site e API em endereços diferentes). Agora o aviso — e `neetru deploy --help`, para quem nem passou `--port` — explica o modelo e o caminho: dois apps são dois produtos (`neetru products create`, papel admin ou operator, e o deploy de cada um com o seu `--product`); o deploy do produto novo exige uma chave da CLI que o alcance (a de admin alcança todos; uma chave com escopo de produto recebe `403 forbidden_product` do Core, e o deploy fica com um admin); cada produto tem endereço, banco e segredos próprios, e se os dois precisam do mesmo banco a API fica no próprio app. O texto mora num lugar só (`src/lib/deploy-vm-um-app.ts`). O aviso também passa a sair **antes** da escolha do servidor (num `--json --non-interactive` sem `--server` a CLI morria em `server_required` sem avisar) e com `--port` inválido (`--port abc` virava NaN e calava o aviso). Seção nova no README.
+  - **O caminho ensinado esbarra hoje num defeito do Core, e a CLI passa a explicar a recusa** (bug_fe30f035, no Core). O produto criado pelo `neetru products create` nasce com staging e prod no destino workspace, e o 1º deploy dele na VM volta `400 vm_deploy_failed` com "Ambiente prod tem destino 'workspace', não 'vm'. Migre o destino antes (changeEnvironmentTarget) ou use o destino atual." — um conselho que a CLI não tem como seguir: ela não tem comando que troque o destino de um ambiente. Agora, quando o Core recusa assim (na VM ou no Cloud Run), a CLI mantém o recado do Core e acrescenta o que aconteceu, que a troca de destino não está ao alcance da CLI e o que fazer: no produto novo, é defeito do Core e o caso fica com um admin do Core; com o ambiente em outro destino de app, refazer com `--target <destino atual>`. Código, exit e `message` do erro não mudam; em `--json` entram `ambiente`, `destinoAtual`, `destinoPedido` e `hint`. Outros 400 passam intactos. O texto mora em `src/lib/deploy-recusa-de-destino.ts` e só aparece quando a recusa acontece, então não envelhece quando o Core for consertado: o conserto proposto do Core (core#791, aberto em 24/10) troca esse recado por outro, sem a cauda `changeEnvironmentTarget`, e a CLI então deixa o erro passar como veio. O caminho de dois apps só funciona de ponta a ponta com o conserto do Core no ar.
+- **`neetru secrets set` e `neetru deploy --target vm` param de dizer que o agente da VM "ainda não entrega" segredos do produto ao app** (bug_8b85353b, defeito nomeado na vistoria de 22/10). A frase foi escrita em 2026-10-16, quando o lado do agente (Parte 2) ainda não tinha saído; o agente 1.6.80 a entrega desde 2026-10-20 (`agent_releases/1.6.80`, canal stable; a 1.6.79, onde o CHANGELOG do agente põe o recurso, foi declarada e nunca publicada) e as duas VMs operacionais da frota reportam 1.6.80 desde 2026-10-22. A 2.33.0 a repetia em todo `secrets set` bem-sucedido (na tela e no campo `note` do `--json`, que automação lê) e no `deploy --target vm` que descarta do `--env-file` um segredo como o `NEETRU_WEBHOOK_SECRET` — exatamente o passo do relato. Ela mandava o dev não usar um caminho que funciona. Agora:
+  - `secrets set` diz quando o segredo chega: no próximo deploy do ambiente, pelo agente 1.6.80 ou mais novo, que grava o valor num arquivo que só o root da VM lê; o app no ar só vê a gravação depois desse deploy. O `note` do `--json` traz a mesma frase.
+  - `deploy --target vm`, depois de descartar a chave, diz que o segredo chega pelo registro: a chave já registrada no ambiente entra neste deploy, a que não está só chega no primeiro deploy depois do registro, e `neetru secrets list --env <ambiente>` mostra o que já está registrado. Sai como informação, não mais como aviso.
+  - **Limites declarados (lado Core, fora desta CLI):** a mensagem do próprio Core ao recusar segredo em `envVars` (`assertNoSecretEnvVars`) ainda diz que o agente não foi liberado; e, no deploy, o Core lê as chaves registradas com `resolveProductEnvKeys`, que vira lista vazia num erro de leitura — o agente então apaga o arquivo de segredos e o deploy sai com sucesso. As notas desta CLI descrevem o caminho normal; os dois consertos são do Core e só chegam com deploy dele.
+- **`neetru chat identity <palavra>` não grava mais a palavra como apelido: o default foi invertido** (bug_09574d4b, encerramento derrubado na vistoria de 22/10). Os dois consertos anteriores (#76 e P105) eram lista de permissão — recusavam 18 palavras (`show`/`set`/`clear`, os equivalentes em PT-BR e os sinônimos do `SYNONYMS`) e gravavam todo o resto. Na 2.33.0 publicada, `identity mostrar`, `identity status`, `identity whoami`, `identity atual`, `identity apelido` (o alias do próprio comando) e `identity "Dev Core"` gravavam o argumento como apelido da credencial — que é compartilhada por todas as sessões do mesmo token —, com o mesmo "✓ Apelido definido" do caminho feliz. Agora qualquer primeira palavra fora de `show|ver|get`, `set|definir` e `clear|limpar` é recusada sem nenhuma chamada ao Core (exit 1, `uso_invalido`; no JSON, `value`, `suggestions` e `valid`): a recusa lista os subcomandos e ensina `neetru chat identity set "<o mesmo texto>"`. As únicas formas de gravar são `identity set "Nome"`, `identity clear` e `chat send --as` (que já avisa no stderr).
+  - **Quebra a forma posicional da CH3:** `neetru chat identity "Nome"` deixou de gravar — use `neetru chat identity set "Nome"`. A skill `neetru-chat` ainda ensina a forma posicional como "define"; precisa mudar junto com a publicação.
+
+- **Mensagens que mandavam usar uma flag que o comando em execução não tem** (bug_89d2497e, etapa 1: cli#98 e o PR seguinte). A guarda de testes passou a conferir cada flag citada contra o subcomando que imprime a mensagem, e não só contra a CLI inteira. Os conselhos errados que ela achou foram consertados:
+  - `neetru new` com o diretório `./<nome>` ocupado mandava "Use --here ou --path ou --force", flags que o `new` não tem. Agora cita o comando inteiro: `neetru init <nome> --here`, `--path <outro-diretório>` ou, para sobrescrever, `--path <nome> --force`.
+  - `neetru deploy` (standalone sem `server.js`) mandava "use `--app <dir>`". Agora manda rodar `neetru build --app <dir>` no diretório de onde vai rodar o deploy.
+  - `dev sync`/`dev status --sync` citavam `--prototype <slug>` solto. Agora citam `neetru dev use --prototype <slug>`.
+  - `neetru ui` sem terminal interativo mandava usar "--json", que o `ui` não tem.
+  - O step-up de MFA de `vm provision`/`agent release` falava em "modo --json", flag que esses comandos não declaram. Agora diz "modo não-interativo".
+  - `neetru new "!!!"` (nome que não gera slug) caía no "informe --slug" do `products create`. Agora o `new` recusa antes de autenticar, citando `--product-slug`.
+  - `neetru new` num produto que já tem ambiente ativo no mesmo env imprimia o JSON de `workspaces create` com "Use --force-duplicate para criar mesmo assim", e o `new` não tem essa flag. O `message` desse JSON agora depende do comando em execução: `workspaces create --json` continua citando `--force-duplicate`; o `new` manda rodar `neetru workspaces create --product <id> --env <env>` num terminal interativo, que pergunta se reusa o ambiente existente ou cria outro. O código do erro (`tenant_already_exists`, 409) não mudou.
+  - A guarda passou a ler mais formas de texto (o logger `lg` do `scopedLog`, `console.*`, `process.stderr.write`, `chalk`, mapa de mensagens, `${…}`, retorno de função, `export const` importada, `let msg` atribuída por ramo, as chaves `guidance`/`warning`/`note` do JSON). Na guarda do cli#98, 102 textos com flag que o usuário lê não eram conferidos; agora são 36, e nenhum deles é conselho errado. Os que ela achou:
+    - `neetru deploy` no Windows, sem artefato pronto (o deploy roda o build): "use --no-install pra pular esta etapa", e o `deploy` não tem essa flag. No `deploy` o aviso agora só pede para pausar o dev server; o `neetru build` continua citando `--no-install`.
+    - `neetru secrets archive CHAVE=VALOR`: "mande o valor por --stdin, --from-file ou pelo pedido na tela". O `archive` não recebe valor nem tem essas flags; agora ele só pede o nome. O `secrets set` continua ensinando as três origens.
+    - `neetru admin sdk-credential scopes`: "em --scopes, separe por vírgula". A flag é do `create`, e a dica agora cita `neetru admin sdk-credential create --scopes`.
+    - O aviso de segredo descartado do `neetru deploy --target vm` dizia "use --generate" solto. Agora cita `neetru secrets set <NOME> --env <ambiente> --generate`.
+    - O "o que fazer" de `neetru db frontdoor`, comum ao `enable`, ao `status` (que mostra o último erro da ligação) e ao `disable`: "Confira o id passado em --app-server" (só o `enable` tem) e "repita com --force"/"nem com --force" (só o `disable` tem). Agora cada um cita o comando inteiro.
+    - Dois textos mudaram sem ser conselho errado, para a guarda não cobrar à toa: o rótulo do `neetru chat history --since` passou de "desde o cursor --since" para "desde o cursor informado" (o runner é o mesmo do `neetru chat`, que nunca chega a esse rótulo), e o `--no-cache` do build com yarn/bun diz que eles não têm equivalente ao `npm cache clean --force`.
+
+- **`neetru build` em monorepo: o lugar do app dentro do standalone vem do próprio Next.js** (bug_678ddc98, o que faltava do comportamento esperado do relato). Desde a 2.31.1 o build detecta o gerenciador de pacotes, aceita `--app`/`--cwd` e acha o `server.js` aninhado, mas achava por varredura da árvore: entre dois `server.js` com `.next` ao lado escolhia pela ordem alfabética, e não descia mais de 6 pastas. Agora lê `relativeAppDir` de `.next/required-server-files.json`, que o Next.js grava no mesmo build com a mesma conta que usa para escrever `.next/standalone/<relativeAppDir>/server.js` (um valor gravado no Windows, com `\`, vira `/`). A varredura fica só para Next.js antigo, sem o campo. Se o Next.js registrou um lugar e o `server.js` não está lá, ou registrou um lugar fora do standalone, o build para com exit 1 e diz qual dos dois, em vez de empacotar outro app da árvore. App único segue igual (`relativeAppDir` vazio, `server.js` na raiz).
+  - **README:** seção nova "Build de monorepo". Abre com o aviso de que o deploy de monorepo na VM ainda não funciona (limite abaixo) e traz `--app`, onde sai o pacote, a ordem de escolha do gerenciador (o lockfile da pasta do app vem antes de tudo da raiz, inclusive do `packageManager` da raiz) e o Dockerfile do Cloud Run, que ainda supõe app único com npm.
+  - **Limite (lado do agente, fora desta CLI):** o agente da VM (1.6.80) decide se instala dependências olhando só a raiz do pacote. O pacote de monorepo não tem `server.js` nem `.next/` na raiz, então o agente não o reconhece como standalone e roda `npm rebuild` (e, se falhar, `npm install`) na raiz do pacote em vez de pular a instalação. O conserto é do `neetru-agent-service-vm` (bug_bc72fe7e). O bug fica aberto por isso.
+
 ## [2.33.0] — 2026-10-19 (`neetru db frontdoor` e confirmação da VM na limpeza forçada)
 
 > **Por que MINOR.** Entram um comando novo (`neetru db frontdoor enable|status|disable`) e uma flag nova (`neetru servers force-cleanup --confirm-instance-id`), sem quebrar comportamento existente. Os dois só funcionam contra um Core com o core#727 e o core#732 no ar; antes disso a rota da porta de entrada responde 404, e a limpeza forçada ignora a confirmação.

package/README.md

@@ -56,7 +56,7 @@ Cria produto + workspace + scaffold local Next.js 15 + instala deps + abre cockp
 | `neetru docs new <tipo> "<título>"` | Doc novo a partir do modelo, na pasta e com o nome do protocolo |
 | `neetru docs check [--changed] [--strict]` | Valida os docs do produto offline (códigos FM/TI/NM/LK/PB/LC + PR001–PR004) |
 | `neetru docs sync [--dry-run]` | Publica os docs do produto no Core (só os sem erro; nada é apagado) |
-| `neetru build [--stack ...] [--target-env dev\|workspace\|prod] [--env-file ...] [--no-cache] [--no-install]` | Empacotar produto em tarball pra deploy |
+| `neetru build [--app <pasta>] [--stack ...] [--target-env dev\|workspace\|prod] [--env-file ...] [--no-cache] [--no-install]` | Empacotar produto em tarball pra deploy (monorepo: `--app apps/web`, ou `--cwd`) |
 | `neetru smoke [--base-url ...] [--prod ...] [--health-path ...] [--routes csv] [--json]` | Percorrer as páginas do produto **local** antes do deploy (alcance + login + DB) + smoke de prod opcional |
 | `neetru promote` | Promover dev → staging → prod |
 | `neetru env switch <target>` | Trocar `NEETRU_ENV` no `.env.local` |
@@ -87,7 +87,7 @@ Cria produto + workspace + scaffold local Next.js 15 + instala deps + abre cockp
 | `neetru logs` | Ver logs de produtos |
 | `neetru status` | Visão geral do ecossistema |
 | `neetru open <produto>` | Abrir cockpit do produto no browser |
-| `neetru ai` | REPL IA Neetru-aware (Claude/OpenAI/Gemini) |
+| `neetru ai` | REPL IA Neetru-aware (Groq, NVIDIA NIM, OpenAI ou o AI Gateway da Neetru via `neetru login`) |
 | `neetru ui` | Menu interativo do CLI |
 | `neetru publish` | Publicar produto no catálogo público |
 | `neetru upgrade` | Auto-update do CLI |
@@ -171,6 +171,24 @@ Isso existe porque o Next.js carrega `.env.local` (arquivo do disco do dev, nunc
 
 Se o produto envolver `next.config.mjs` com `withNeetruBuildGuard` (`@neetru/sdk/build-guard`, `@neetru/sdk >= 3.1.15`), `neetru build` confere pós-build que o env realmente compilado bate com o esperado — e **recusa empacotar o tarball** se divergir, em vez de deployar um bundle quebrado silenciosamente.
 
+## Build de monorepo (pnpm, yarn, bun ou npm workspaces)
+
+> **Deploy de monorepo na VM ainda não funciona.** O agente da VM (1.6.80) não reconhece o app que fica dentro de uma pasta do pacote (`apps/web/server.js`): em vez de pular a instalação, ele roda `npm rebuild` na raiz do pacote e, se falhar, `npm install` — o mesmo caminho que já derrubou deploy em VM pequena (exit 137). Para a VM, mantenha o seu empacotador próprio até sair a versão do agente que reconhece o app aninhado (bug_bc72fe7e no agente; origem bug_678ddc98). O `neetru build --app` abaixo já monta o pacote; o que falta é o agente saber instalá-lo.
+
+Rode da raiz do monorepo e aponte o app com `--app` (`--cwd` é o mesmo):
+
+```bash
+neetru build --app apps/web --product meu-produto
+neetru deploy --product meu-produto   # da mesma pasta: usa o pacote que o build gerou (na VM, veja o aviso acima)
+```
+
+- **Onde sai o pacote:** em `.neetru-build/` da pasta onde você rodou o comando — é lá que o `neetru deploy` procura. O `neetru.config.json` pode ficar no app ou na raiz (o do app vale mais). A versão vem do `package.json` do app.
+- **Gerenciador de pacotes, nesta ordem:** (1) o campo `packageManager` do `package.json` do app; (2) o lockfile da pasta do app (`pnpm-lock.yaml`, `yarn.lock`, `bun.lock`/`bun.lockb`, `package-lock.json`), que vem antes de tudo o que está na raiz, inclusive do `packageManager` da raiz; (3) sem lockfile no app, a CLI sobe até a raiz do workspace, e lá o `packageManager` do `package.json` da raiz vale mais que o lockfile da raiz. A raiz só conta se se declara workspace (`pnpm-workspace.yaml` ou `workspaces` no `package.json`), e a busca para na pasta que tem `.git`. Achada a raiz, a instalação roda nela e o script `build` roda na pasta do app. Sem lockfile nenhum, fica o npm, como sempre.
+- **Cuidado com lockfile solto no app:** um `package-lock.json` esquecido em `apps/web` de um monorepo pnpm faz a CLI escolher o npm e instalar só dentro de `apps/web`, onde as dependências `workspace:*` falham. Apague o lockfile solto antes do build.
+- **Next.js com `output: 'standalone'`:** no monorepo o Next.js põe o app dentro do standalone, no mesmo caminho que ele tem no repositório (`.next/standalone/apps/web/server.js`). A CLI lê esse caminho de `.next/required-server-files.json` (campo `relativeAppDir`, gravado pelo próprio Next.js no build). Se o arquivo não traz o campo (Next.js antigo), ela procura o `server.js` pela árvore. O pacote leva o standalone inteiro, `.next/static` e `public` vão para dentro de `apps/web/`, e o `neetru deploy` manda o entrypoint `apps/web/server.js` para o Core.
+- **Quando a CLI recusa:** se o Next.js registrou o app num lugar e o `server.js` não está lá, ou registrou um lugar fora do standalone (o `outputFileTracingRoot` precisa ser uma pasta acima do app), o build para com exit 1 em vez de empacotar um pacote que não sobe.
+- **Cloud Run sem Dockerfile:** o Dockerfile que o `neetru deploy --target cloud-run` gera quando o projeto não tem um reconhece o monorepo (bug_1dcf8e03): detecta o gerenciador do app (mesma regra do `neetru build --app` acima), builda com o contexto na raiz do workspace (onde mora o lockfile — `workspace:*` só resolve assim) e aponta o `CMD`/`COPY` do standalone para o caminho aninhado do app (`apps/web/server.js`). Rode `neetru deploy` de dentro do app (`cd apps/web && neetru deploy …`), como no `neetru build --app`. Testado com pnpm (fixture de monorepo) e npm de app único (caso de sempre); yarn berry com PnP e workspace nativo npm/yarn sem teste próprio — fora desses dois casos, escreva o seu Dockerfile.
+
 ## Segredo no pacote público bloqueia o deploy (2.30.0)
 
 A credencial `nrt_` do produto é **só de servidor**. Antes de enviar o pacote, `neetru deploy` varre o que é servido ao navegador — `.next/static/**`, `public/**`, `out/**`, `dist/**`, `build/**` (na stack `static`, o pacote inteiro; `node_modules` nunca) — procurando:
@@ -191,6 +209,23 @@ neetru deploy --allow-public-secret "chave antiga já revogada, ticket #123"
 
 Limites: `--artifact-url` (pacote remoto) e `--image` (imagem pronta, cloud-run) não passam pelo CLI e **não são varridos** — o deploy avisa. Em `target=cloud-run` sem `--image`, a varredura é nas pastas públicas do disco antes do build da imagem.
 
+## Deploy na VM: um app por produto e ambiente
+
+Na VM (`--target vm`) quem escolhe a porta do app é o Core; `--port` é ignorado (a CLI avisa). O Core reconhece o app pelo **produto + ambiente**: um novo `neetru deploy --product X --env prod` **substitui** o app de `X` em `prod` que está no ar — o endereço de `prod` passa a servir o deploy novo, e não sobe um segundo app ao lado.
+
+Para ter **dois apps** (ex.: site e API em endereços diferentes), cadastre o segundo como produto próprio e faça o deploy de cada um com o seu `--product`:
+
+```bash
+neetru products create --name "Meu SaaS API" --slug meu-saas-api   # exige papel admin ou operator
+neetru deploy --product meu-saas-api --env prod --target vm --server <id>
+```
+
+O deploy do produto novo exige que a **chave da CLI** o alcance: a de admin alcança todos os produtos; uma chave com escopo de produto só alcança os dela, e o deploy do novo volta `403 forbidden_product` — nesse caso o deploy fica com um admin.
+
+**Enquanto o conserto do Core para o bug_fe30f035 não estiver no ar, o 1º deploy do produto novo na VM é recusado pelo Core**: o produto nasce com staging e prod no destino workspace, e o deploy na VM volta `400 vm_deploy_failed` ("Ambiente prod tem destino 'workspace', não 'vm'. Migre o destino antes (changeEnvironmentTarget)…"). A CLI não tem comando para trocar o destino de um ambiente. Quando essa recusa acontece, a CLI a explica, e o caso fica com um admin do Core.
+
+Cada produto tem endereço, banco e segredos próprios. Se os dois precisam do **mesmo banco**, separar não serve (o banco é isolado por produto): sirva a API pelo próprio app (ex.: rotas `/api`), no mesmo endereço. O mesmo texto aparece em `neetru deploy --help`.
+
 ## Smoke local antes do deploy (`neetru smoke`)
 
 Roda contra o servidor **dev local** (`next dev` / `neetru dev up`) e percorre as páginas do produto **antes** de `neetru build` + `neetru deploy` — pega página quebrada, login que não renderiza ou banco fora do ar sem subir nada em produção.
@@ -220,7 +255,7 @@ Token Bearer fica em `~/.config/neetru-cli/auth.json` (chmod 0600 em Unix, NTFS
 | Chave | Valor |
 |---|---|
 | `neetruApiUrl` | URL base do Core (default `https://api.neetru.com`). **Allowlist** desde 2.11.0: `*.neetru.com` + `localhost`; demais hosts exigem `--allow-untrusted-url` |
-| `defaultModel` | `claude` / `openai` / `gemini` / `auto` (REPL `neetru ai`) |
+| `defaultModel` | `groq` / `nvidia` / `openai` / `gateway` / `auto` (default `auto`): o modelo do `neetru ai` aberto sem `-m`. No `auto`, a CLI escolhe entre os provedores com chave, gratuitos primeiro (Groq, NVIDIA NIM; a OpenAI só sem eles) |
 | `telemetry.enabled` | Telemetry opt-in (default `false`) — desde 2.11.0 emite eventos anônimos pra `/api/sdk/v1/telemetry/log` |
 | `neetruApiKey` | **(legado)** Token em Conf — substituído por `auth.json`. Será removido em 2.12.0 |
 

package/dist/commands/admin/sdk-credential.js

@@ -207,7 +207,9 @@ export async function runSdkCredentialScopes(opts) {
         }
         console.log();
     }
-    console.log(chalk.dim('Dica: em --scopes, separe por vírgula. Aliases legados (ex.: "data" → ' +
+    // bug_89d2497e (etapa 1): este é o `admin sdk-credential scopes`, que não
+    // declara --scopes; a flag é do `create`, e o texto diz qual.
+    console.log(chalk.dim('Dica: em `neetru admin sdk-credential create --scopes`, separe por vírgula. Aliases legados (ex.: "data" → ' +
         'datastore.read, "auth" → profile.read) são aceitos e normalizados pelo servidor.'));
 }
 //# sourceMappingURL=sdk-credential.js.map

package/dist/commands/ai-models.d.ts

@@ -1,6 +1,7 @@
+import { type ProvedorIa } from '../lib/ai/provedores.js';
 export interface AiModelCatalogEntry {
     id: string;
-    provider: 'groq' | 'nvidia' | 'openai';
+    provider: ProvedorIa;
     modelId: string;
     label: string;
     notes: string;

package/dist/commands/ai-models.js

@@ -13,14 +13,13 @@
 import chalk from 'chalk';
 import { apiRequest } from '../lib/api-client.js';
 import { handleApiError } from '../lib/api-error.js';
+import { NOME_DO_PROVEDOR } from '../lib/ai/provedores.js';
 import { config } from '../lib/config.js';
 import { log } from '../utils/logger.js';
 import { setSafeExitCode } from '../utils/safe-exit.js';
-const PROVIDER_LABELS = {
-    groq: 'Groq',
-    nvidia: 'NVIDIA NIM',
-    openai: 'OpenAI',
-};
+// Nomes da lista única (`provedores.ts`, bug_19d312f3). Indexado por string
+// porque o provider vem do Core; fora da lista, a tela mostra o id cru.
+const PROVIDER_LABELS = NOME_DO_PROVEDOR;
 async function fetchCatalog() {
     const { entries } = await apiRequest('/api/cli/v1/ai/models');
     return entries;

package/dist/commands/ai.d.ts

@@ -1,4 +1,14 @@
-import { type ModelId } from '../lib/ai/orchestrator.js';
+/**
+ * Checa se o usuário tem pelo menos uma cred (local OU descoberta) de um
+ * provedor da lista única OU uma sessão `neetru login` válida (gateway). Se
+ * zero, roda o setup wizard inline antes de abrir o REPL.
+ *
+ * bug_19d312f3: antes, `anthropicApiKey`/`geminiApiKey` na config ou
+ * ANTHROPIC_API_KEY/GEMINI_API_KEY no ambiente liberavam o REPL, que saía
+ * usando a API da Anthropic ou o Gemini sem o dev escolher. Os dois estão
+ * vetados e não contam mais.
+ */
+export declare function ensureAtLeastOneProvider(): Promise<boolean>;
 export declare function runAiRepl(opts?: {
-    model?: ModelId;
+    model?: string;
 }): Promise<void>;

package/dist/commands/ai.js

@@ -2,6 +2,7 @@ import * as readline from 'readline/promises';
 import chalk from 'chalk';
 import { chat, chatParallel } from '../lib/ai/orchestrator.js';
 import { discoveredKeys } from '../lib/ai/auth-discovery.js';
+import { CHAVE_DO_PROVEDOR, MODELOS_DO_AI_NA_TELA, NOMES_DOS_PROVEDORES, PROVEDORES_IA, ehModeloDoAi, } from '../lib/ai/provedores.js';
 import { config } from '../lib/config.js';
 import { getActiveTokenSync } from '../lib/token-resolver.js';
 import { log } from '../utils/logger.js';
@@ -10,64 +11,72 @@ import { safeExit } from '../utils/safe-exit.js';
 const PROMPT_PREFIX = chalk.hex('#1E90FF').bold('  › ');
 const ASSISTANT_PREFIX = chalk.dim('  ◆ ');
 // Help público — sem /modelo (orchestrator escolhe). /debug:model é o
-// override avançado pra quem quer forçar.
+// override avançado pra quem quer forçar. Provedores e modelos vêm da lista
+// única (`provedores.ts`, bug_19d312f3).
 const HELP_TEXT = `
   Comandos:
     /sair  /exit         encerrar sessão
     /limpar /clear       limpar histórico de contexto
     /agentes <pergunta>  consultar 2+ modelos em paralelo e comparar
-    /auth                rodar wizard de configuração (claude/codex/gemini)
+    /auth                rodar wizard de configuração (${NOMES_DOS_PROVEDORES})
     /help                mostrar este texto
-    /debug:model <nome>  forçar modelo (claude|openai|gemini|groq|nvidia|gateway|auto)
+    /debug:model <nome>  forçar modelo (${MODELOS_DO_AI_NA_TELA})
 `.trim();
-const DEBUG_MODELS = ['claude', 'openai', 'gemini', 'groq', 'nvidia', 'gateway', 'auto'];
+/** Algum provedor da lista única tem chave na config local? */
+function temChaveLocal() {
+    return PROVEDORES_IA.some((p) => !!config.get(CHAVE_DO_PROVEDOR[p]));
+}
+/** Algum provedor da lista única tem chave achada na máquina (ambiente, Codex)? */
+function temChaveDescoberta() {
+    const descobertas = discoveredKeys();
+    return PROVEDORES_IA.some((p) => !!descobertas[p]);
+}
 /**
- * Checa se o usuário tem pelo menos uma cred (local OU descoberta) OU uma
- * sessão `neetru login` válida (gateway). Se zero, roda o setup wizard
- * inline antes de abrir o REPL.
+ * Checa se o usuário tem pelo menos uma cred (local OU descoberta) de um
+ * provedor da lista única OU uma sessão `neetru login` válida (gateway). Se
+ * zero, roda o setup wizard inline antes de abrir o REPL.
+ *
+ * bug_19d312f3: antes, `anthropicApiKey`/`geminiApiKey` na config ou
+ * ANTHROPIC_API_KEY/GEMINI_API_KEY no ambiente liberavam o REPL, que saía
+ * usando a API da Anthropic ou o Gemini sem o dev escolher. Os dois estão
+ * vetados e não contam mais.
  */
-async function ensureAtLeastOneProvider() {
-    const local = {
-        anthropic: !!config.get('anthropicApiKey'),
-        openai: !!config.get('openaiApiKey'),
-        gemini: !!config.get('geminiApiKey'),
-        groq: !!config.get('groqApiKey'),
-        nvidia: !!config.get('nvidiaApiKey'),
-    };
-    if (local.anthropic || local.openai || local.gemini || local.groq || local.nvidia)
+export async function ensureAtLeastOneProvider() {
+    if (temChaveLocal())
         return true;
     // Gateway (não-BYOK): sessão de `neetru login` já basta.
     if (getActiveTokenSync())
         return true;
-    const discovered = discoveredKeys();
-    if (discovered.anthropic ||
-        discovered.openai ||
-        discovered.gemini ||
-        discovered.groq ||
-        discovered.nvidia) {
+    if (temChaveDescoberta())
         return true;
-    }
     // Zero — força setup interativo.
     log.warn('Nenhum provedor de IA configurado.');
     log.info('Abrindo wizard de configuração...');
     await runAuthSetup();
     // Re-checa.
-    const disc = discoveredKeys();
-    const after = !!config.get('anthropicApiKey') ||
-        !!config.get('openaiApiKey') ||
-        !!config.get('geminiApiKey') ||
-        !!config.get('groqApiKey') ||
-        !!config.get('nvidiaApiKey') ||
-        !!disc.anthropic ||
-        !!disc.openai ||
-        !!disc.gemini ||
-        !!disc.groq ||
-        !!disc.nvidia;
-    return after;
+    return temChaveLocal() || temChaveDescoberta();
 }
 export async function runAiRepl(opts = {}) {
     log.banner();
     log.info('Assistente Neetru — contexto da plataforma carregado.');
+    // bug_19d312f3: `-m claude` / `-m gemini` (ou qualquer nome fora da lista)
+    // caía calado no `auto`. Agora é recusado antes de abrir a sessão.
+    //
+    // Revisão do #104: sem `-m`, vale o `defaultModel` da config (`neetru config
+    // set defaultModel <modelo>`), que começa em `auto`. Antes o `-m` tinha
+    // `auto` de padrão no index.ts e o `defaultModel` nunca chegava aqui — nem o
+    // válido (`groq`) tinha efeito, nem o antigo (`claude`) era avisado.
+    const doConfig = opts.model === undefined;
+    const pedido = opts.model ?? config.get('defaultModel') ?? 'auto';
+    if (!ehModeloDoAi(pedido)) {
+        log.error(doConfig
+            ? `O defaultModel gravado na config ("${String(pedido)}") não existe no neetru ai. ` +
+                `Use: ${MODELOS_DO_AI_NA_TELA}. Rode \`neetru config set defaultModel auto\` ` +
+                '(ou abra com `neetru ai -m <modelo>`).'
+            : `O modelo "${String(pedido)}" não existe no neetru ai. Use: ${MODELOS_DO_AI_NA_TELA}.`);
+        safeExit(1);
+        return;
+    }
     // Bloqueia antes do REPL se não tem cred nenhuma.
     const ready = await ensureAtLeastOneProvider();
     if (!ready) {
@@ -86,7 +95,7 @@ export async function runAiRepl(opts = {}) {
     // bug: histórico crescia ilimitado → context_window_exceeded em sessões longas.
     // Janela deslizante: mantém as últimas HISTORY_WINDOW mensagens (par user+assistant).
     const HISTORY_WINDOW = 40;
-    let currentModel = opts.model ?? 'auto';
+    let currentModel = pedido;
     let running = true;
     rl.on('close', () => {
         running = false;
@@ -121,12 +130,12 @@ export async function runAiRepl(opts = {}) {
         }
         if (input.startsWith('/debug:model ')) {
             const m = input.split(' ')[1];
-            if (DEBUG_MODELS.includes(m)) {
+            if (ehModeloDoAi(m)) {
                 currentModel = m;
                 log.success(`Modelo forçado: ${m}`);
             }
             else {
-                log.warn('Use: claude | openai | gemini | groq | nvidia | gateway | auto');
+                log.warn(`Use: ${MODELOS_DO_AI_NA_TELA}`);
             }
             continue;
         }

package/dist/commands/auth.d.ts

@@ -6,8 +6,9 @@ interface CommonOpts {
  */
 export declare function runAuthStatus(opts?: CommonOpts): Promise<void>;
 /**
- * `neetru auth pull` — sem perguntar, copia toda apiKey extraída dos CLIs
- * concorrentes pra config do Neetru. Útil pra CI/script.
+ * `neetru auth pull` — sem perguntar, copia pra config do Neetru a chave achada
+ * no arquivo do Codex. A do ambiente não é copiada: a CLI já a lê direto da
+ * variável (ver `chaveCopiavel`). Não sobrescreve chave já configurada.
  */
 export declare function runAuthPull(opts?: CommonOpts): Promise<void>;
 /**