@neetru/cli 2.11.3 → 2.11.4

package/CHANGELOG.md

@@ -1,547 +1,561 @@
-# Changelog @neetru/cli
-
-Convenção: [Keep a Changelog](https://keepachangelog.com/) + [SemVer](https://semver.org/).
-
-## [2.11.0] — 2026-05-27 (hardening: token unificado · URL allowlist · telemetry real)
-
-> Minor de hardening pós-2.10.2. Fecha 3 itens HIGH levantados na review do chefe-de-CLI (`docs/_review/CHEFE_CLI_REVIEW_2026-05-27.md` no Core) + Codex sweep (HIGH-10). Nenhuma breaking change — comandos e flags antigas seguem funcionando; warnings apontam para a deprecação prevista pra 2.12.0.
-
-### Adicionado
-
-- **`--allow-untrusted-url` em `neetru config set`** (MASTER-HIGH-049) — flag opt-in pra setar `neetruApiUrl` fora da allowlist canônica. Sem essa flag (ou `NEETRU_ALLOW_UNTRUSTED_URL=1`) o `config set` rejeita com exit(1) + banner vermelho. Allowlist: `api.neetru.com`, `core.neetru.com`, `neetru.com` (apex), `*.neetru.com` (subdomínios), `localhost`/`127.0.0.1`/`::1` (dev — HTTP ok); demais hosts exigem HTTPS.
-- **Telemetry real** (MASTER-HIGH-052) — `telemetry.enabled` deixou de ser flag fantasma. Quando opt-in, `neetru <comando>` agora emite evento anônimo (`{command, durationMs, ok, exitCode, ts}`) para `POST /api/sdk/v1/telemetry/log`. Identificação por `installId` UUID em `~/.config/neetru-cli/install-id` (chmod 0600). Nunca envia token, path absoluto, email, ou env. Buffer in-memory cap 50 + flush em `beforeExit` com timeout 1.5s (fire-and-forget — erro de rede não bloqueia o comando). Override: `NEETRU_TELEMETRY_DISABLED=1`.
-
-### Mudado (compat-friendly)
-
-- **Token resolver unificado** (MASTER-HIGH-048) — `api-client.ts` (`apiRequest` + `apiStream`) agora lê o Bearer token via `getActiveTokenSync()` (`src/lib/token-resolver.ts`), que prefere `~/.config/neetru-cli/auth.json` (canônico desde Sprint 1) sobre o Conf storage (legacy). Quando o token vem do Conf, emite warning one-shot stderr alertando deprecação pra 2.12.0. 8 comandos que liam `config.get('neetruApiKey')` direto (`status`, `validate`, `deploy`, `vm`, `logs`, `doctor`, `publish`, `whoami`) migrados pra `getActiveTokenSync()`. Comportamento anterior — "logado pra `whoami` mas não pra `status`" quando o token só existia em `auth.json` — desaparece.
-- **`neetru config set neetruApiKey` emite deprecation warning** — o setter manual continua funcionando, mas avisa que `neetru login` é o caminho canônico (que grava em `auth.json` chmod 0600). Storage Conf de `neetruApiKey` será removido em 2.12.0.
-- **`apiRequest` emite warning one-shot quando host customizado fora da allowlist** — defesa em profundidade pra casos em que o owner já tem URL untrusted em Conf (não pegou o `config set` 2.11).
-
-### Infraestrutura de testes (+34 tests)
-
-- **Novo `src/__tests__/url-allowlist.test.ts`** (15 cases): hosts trusted + edge cases (domain confusion `neetru.com.evil.com`, HTTP em prod, protocolos não suportados).
-- **Novo `src/__tests__/config-set-allowlist.test.ts`** (7 cases): rejeita default, aceita com `--allow-untrusted-url`, aceita com env override.
-- **Novo `src/__tests__/token-resolver.test.ts`** (4 cases): precedência `auth.json > Conf > null` + warning one-shot stderr.
-- **Novo `src/__tests__/telemetry.test.ts`** (8 cases): opt-in default off + env override, happy path POST com payload validado, idempotência do flush, falha de rede engolida, cap de buffer, privacy (zero token/path/email no payload).
-- 7 tests existentes ganharam `readAuthJsonSync: vi.fn(() => null)` no mock de `auth.js` (control-plane, workspaces, products-create, sdk-credential, new-browser-optin, doctor, publish) — preserva semântica antiga de "token via config.set" caindo no fallback Conf.
-- `vitest.config.ts` seta `NEETRU_SUPPRESS_LEGACY_WARNINGS=1` em test setup pra não poluir CI com banner de deprecation.
-
-### Deprecation timeline
-
-- **2.11.0 (esta release):** Conf `neetruApiKey` ainda funciona (com warning); login grava em ambos os storages.
-- **2.12.0 (planejado):** `login` para de gravar em Conf; `config set neetruApiKey` continua aceito mas vira no-op com warning; `Conf neetruApiKey` removido do schema. Owner que copia binário pra outra máquina precisa garantir migração `~/.config/neetru-cli/auth.json`.
-
-### Sem breaking change
-
-- Todos os comandos e flags da 2.10.x seguem funcionando.
-- Endpoints API canônicos inalterados.
-- Path padrão `~/.config/neetru-cli/auth.json` continua canônico.
-
----
-
-## [2.10.2] — 2026-05-27 (patch: paths broken em produção + autocomplete drift)
-
-> Patch urgente — chefe-de-CLI review do dia (`docs/_review/CHEFE_CLI_REVIEW_2026-05-27.md` no Core) + `MASTER_PLAN_2026-05-27.md` §4 Bloco G. Quatro endpoints quebrados em produção (404 silencioso ou rota inexistente) + cobertura de autocomplete em ~45% silenciosamente. Sem nada novo de UI ou behavior — só fix de quem já estava 404'eando.
-
-### Corrigido (CRITICAL)
-
-- **MASTER-CRIT-035 — `neetru promote` apontava pra endpoint inexistente.** `src/commands/promote.ts:104` chamava `/cli/v1/promotion/request` (sem prefixo `/api`) → 404 sempre. Pior: o handler de 404 ainda mascarava o erro com "Endpoint ainda não disponível, entra em build no Sprint 11" — a rota existe há sprints sob `/api/cli/v1/promotion/request`. Fixado. Handler de 404 agora reporta erro real (exit 5). Test cúmplice `promote.test.ts:110` atualizado (pinava `/cli/v1/...` como correto).
-- **MASTER-CRIT-036 — `neetru agent release` apontava pra endpoint inexistente.** `src/commands/agent-release.ts:215` chamava `/cli/v1/agent/release`. Trocado pra canônico `/api/cli/v1/agent/release`.
-- **MASTER-CRIT-037 — `neetru fn deploy` removido (rota nunca existiu).** `src/commands/fn.ts` apontava pra `/cli/v1/fn/deploy` — não há rota em `/api/**/fn/**` no Core. Comando deletado por inteiro (arquivo + import em `src/index.ts` + entry em autocomplete + test cúmplice `src/__tests__/fn.test.ts` que pinava o path errado). Reintroduzir quando/se a feature for de fato implementada server-side.
-
-### Corrigido (HIGH)
-
-- **MASTER-HIGH-050 — `neetru logs` apontava pra alias legacy.** `src/commands/logs.ts:106` usava `/api/v1/cli/logs` (inversão dos prefixos). O alias legacy ainda existe no Core mas tem deprecation prevista para 2026-07-01 — depois disso `neetru logs` morre sem aviso. Trocado pra canônico `/api/cli/v1/logs`.
-- **MASTER-HIGH-051 — autocomplete cobria só ~45% dos comandos.** `TOP_LEVEL_COMMANDS` em `src/commands/autocomplete.ts` listava 22 entries de um total de ~50 comandos top-level expostos em `src/index.ts`. Bash/zsh/pwsh completion silenciosamente broken para a maioria das operações (auth, admin, customers, tenants, audit, billing, servers, workspaces, deployments, cloud-run, api-catalog, products, vm, support, bug, dns, hosting, builds, dr, docs, …). Reescrito para incluir TODOS os ≈50 comandos, em ordem alfabética. Aliases incluídos (`menu` → `ui`, `ar` → `artifact-registry`).
-
-### Infraestrutura de testes (regression guards)
-
-- **Novo: `src/__tests__/endpoint-paths.regression.test.ts`** — varre `src/commands/**/*.ts` extraindo o primeiro argumento de toda chamada `apiRequest(...)` / `apiStream(...)` e valida que começa com prefixo canônico: `/api/cli/v1/`, `/api/sdk/v1/`, `/api/v1/`, ou `/api/internal/`. Allowlist explícita só pra `/api/health` (Cloud Run healthcheck). Três testes: prefixo canônico, zero `/cli/v1/*` cru (vetor dos CRIT-035..037), zero `/api/v1/cli/*` invertido (vetor do HIGH-050).
-- **Novo: `src/__tests__/top-level-commands-coverage.regression.test.ts`** — parse simples de `src/index.ts` extraindo `program.command('X')`; exige cobertura ≥95% em `TOP_LEVEL_COMMANDS` + zero entries fantasma + ordem alfabética. Detecta drift do autocomplete quando alguém adicionar/remover comando no `index.ts` no futuro.
-
-### Sem mudança
-
-- Comportamento do CLI fora dos 4 fixes — idêntico ao 2.10.1.
-
----
-
-## [2.10.0] — 2026-05-27 (rename: `neetru marketplace` → `neetru archive` · fonte agora pública)
-
-### BREAKING
-
-- **`neetru marketplace` foi renomeado para `neetru archive`.** Subcomandos preservados (`skills install/update/list/uninstall`, `sdk init/templates/add`, `browse`). NÃO há alias de retrocompat — o comando antigo deixa de existir nesta versão. Quem rodava `neetru marketplace skills install` em scripts CI precisa trocar para `neetru archive skills install`.
-- **Cache local mudou de `~/.neetru/marketplace-cache/` para `~/.neetru/archive-cache/`.** Caches antigos podem ser apagados manualmente (não há migração automática — `archive skills install` cria o novo limpo). A função `getSkillsSourceDir` mantém retrocompat detectando o nível `claude-skills/` caso o cache de uma versão anterior do `archive-cache` ainda tenha esse layout.
-- **Variável de ambiente `NEETRU_MARKETPLACE_SYMLINK` virou `NEETRU_ARCHIVE_SYMLINK`** (Windows). Quem usava precisa renomear.
-
-### Mudado
-
-- **Fonte de skills migrou de `github.com/Neetru/neetru-libs` (privado) para `github.com/Neetru/neetru-libs-public` (público).** O `neetru-libs` privado mantém `packages/` (`@neetru/db-classifier`, `sql-guard`, `pii-mask`, `neetru-glossario`) — só `claude-skills/` foi exposto, via `git subtree push --prefix=claude-skills`. Resultado: `neetru archive skills install` deixa de exigir `gh auth setup-git` ou `GITHUB_TOKEN` — clone anônimo funciona.
-- **Layout do clone público é mais flat:** `plugins/<plugin>/skills/<skill>/SKILL.md` no topo (em vez de `claude-skills/plugins/...`). O resolver detecta o layout legado automaticamente — caches antigos continuam resolvendo até o próximo `archive skills update`.
-
-### Por quê
-
-- O 2.9.13 quebrava em `git clone` quando `neetru-libs` virou privado (HTTP 401 sem credencial git configurada). O fix arquitetural certo era separar o catálogo público de skills do código proprietário em `packages/` — `neetru-libs-public` é esse catálogo. A renomeação `marketplace → archive` aproveitou o break pra alinhar o nome do comando ao conceito real (catálogo/arquivo de artefatos, não um marketplace transacional).
-
-## [2.9.13] — 2026-05-26 (feat: force-cleanup recovery + mfa-status observability)
-
-### Adicionado
-
-- **`neetru servers force-cleanup <serverId> --reason "..." [--yes] [--json]`** — recovery quando VM stuck (status=timeout_agent_register/falha_provisionamento/provisionando >30min) e flow normal (`deactivate`/`delete` com MFA) não funciona. NÃO exige MFA (bypass intencional pra desbloquear deadlock — bug_c42fa12b CRITICAL quando MFA broken via bug_84e4dacb). Double-confirm interativo: usuário digita o serverId. Audit pesado + notification all staff garantem accountability. Bate em POST `/api/cli/v1/servers/[id]/force-cleanup`.
-- **`neetru auth mfa-status [--json]`** — observability MFA do usuário atual: enrolled, enrolledAt, lastUsedAt, hasEncryptedSecret, recoveryCodesCount, hint acionável (clock skew vs nunca usado vs zero recovery codes vs MFA não enrolled). Bate em GET `/api/cli/v1/auth/mfa/status`. Útil quando `servers deactivate` rejeita TOTP e owner precisa debugar antes de tentar novamente.
-
-### Corrige (HIGH/CRITICAL)
-
-- **bug_c42fa12b1e194a0794f14ea74994e2a3 (CRITICAL) — Deadlock VM stuck + MFA broken.** force-cleanup destrava recovery sem precisar MFA. Pré-condições rígidas + audit pesado mitigam risco de uso indevido.
-- **bug_84e4dacbcaf14ea09ae9825ff2e2b9f3 (HIGH) — MFA TOTP rejeita opaco.** mfa-status mostra `lastUsedAt=null` indicando "MFA enrolled mas nunca usou com sucesso" + sugere causas comuns (clock skew, secret desync).
-
-## [2.9.12] — 2026-05-26 (fix: libuv crash MFA error path + lint guard process.exit)
-
-### Corrigido (MEDIUM — regressão libuv em MFA)
-
-- **bug_6362578edfd7498dbcfe59853181be20 (MEDIUM) — `Assertion failed: !(handle->flags & UV_HANDLE_CLOSING)` voltou em CLI 2.9.9 em error path do MFA.**
-  Reprodução: `neetru servers deactivate <id> --yes --mfa-token=<code> --json` quando o servidor retorna 403 (código MFA inválido ou expirado).
-  Causa raiz: o fix anterior (bug_818cf6d, 2.9.9) cobriu apenas `build.ts`. Os outros error paths — `handleApiError` em `cli-read.ts`, `resolveStepUp` em `cli-write.ts`, `failLookup`/`failInput` em `pickers.ts`, e todos os ~200 pontos de `process.exit()` em 46 arquivos de comando — continuavam chamando `process.exit()` direto após I/O async (fetch 403, inquirer prompts, readline MFA). Em Windows o libuv assertion é fatal.
-  Fix: sweep completo — 46 arquivos de comando + 4 arquivos de lib (`cli-read`, `cli-write`, `pickers`, `iam-preflight`) convertidos para `safeExit(N)`.
-
-### Infraestrutura de testes (guard antirregressão)
-
-- **Novo teste `src/__tests__/regressions/no-direct-process-exit.regression.test.ts`** — varre `src/commands/**/*.ts` e `src/lib/**/*.ts` e FALHA se encontrar qualquer `process.exit(` direto. Detecta regressões desta classe automaticamente em CI. Arquivos isentos: `utils/safe-exit.ts` (a implementação em si). Adição de `// safe-exit-exempt: <razão>` numa linha permite marcar exits síncronos intencionais sem quebrar o guard.
-
-## [2.9.9] — 2026-05-25 (fix: libuv crash Windows + npm ci file lock)
-
-### Corrigido (2 MEDIUM Windows compat)
-
-- **bug_818cf6d507b94c81a23b205eb9d18d71 (MEDIUM) — CLI crashava com `Assertion failed: !(handle->flags & UV_HANDLE_CLOSING)` em Windows.**
-  Causa raiz: handles libuv (http keep-alive, stdin/stdout, ora spinner setInterval) ficavam em `UV_HANDLE_CLOSING` quando `process.exit(1)` matava o loop bruscamente. Em Linux/Mac libuv só warna; em Windows é assertion fatal.
-  Fix: novo `src/utils/safe-exit.ts` com `safeExit(code): never` que faz cleanup explícito antes do exit (stopAllSpinners + destroy stdin + destroy http/https globalAgent). Build agora usa `safeExit(1)` em vez de `process.exit(1)` no catch. Spinners registrados via `registerSpinner()` (novo `src/utils/spinner-registry.ts`) pra cleanup centralizado.
-
-- **bug_93f984a16ad64656af2230583b7e554f (MEDIUM) — `neetru build` quebrava com EPERM unlink quando `next dev` rodando em paralelo.**
-  Causa raiz: `npm ci` deletava `node_modules/@next/swc-*` que o dev server tinha aberto em file lock no Windows.
-  Fix: trocado `npm ci` por `npm install --no-save --no-audit --no-fund` (respeita locks parciais). Nova flag `--no-install` permite skip total quando o dev sabe que `node_modules` está pronto. Warn explícito em Windows orientando pausar dev server.
-
-### Novidades técnicas
-
-- **`src/utils/safe-exit.ts`** — `safeExit(code): never` + `setSafeExitCode(code): void` com cleanup robusto de handles libuv.
-- **`src/utils/spinner-registry.ts`** — registry global de spinners ora pra cleanup centralizado em error paths.
-- **`neetru build --no-install`** — pula `npm install` (assume `node_modules` pronto).
-
-### Testes
-
-- `src/__tests__/safe-exit.test.ts` — 9 testes novos (spinner-registry: 6, safeExit: 3).
-
-## [2.9.7] — 2026-05-25 (fix: URI Artifact Registry completa + Cloud Build remoto + Dockerfile template — 3 CRITICAL/HIGH bugs deploy cloud-run)
-
-### Corrigido (CRITICAL/HIGH — deploy cloud-run bloqueado para gestovendas)
-
-- **bug_467db337ea9749a4b85d270d4e10576f (CRITICAL) — `neetru deploy` gerava URI Artifact Registry malformada.**
-  URI original: `us-central1-docker.pkg.dev/gestovendas:tag` (só 2 segmentos — inválida).
-  URI correta: `us-central1-docker.pkg.dev/{project}/{repo}/{image}:{tag}` (4 segmentos obrigatórios do AR).
-  Fix: `buildArtifactRegistryUri` resolve o project via `gcloud config get-value project` quando o
-  `--registry` passado contém apenas o host. O repo é inferido como `{slug}-{env}` ou explicitado via
-  `--registry-repo`. Quando `--registry` já contém `host/project/repo` (3 segmentos), é usado diretamente.
-  Suporta 3 formatos de `--registry`:
-  - Host apenas: `us-central1-docker.pkg.dev` → descobre project via gcloud config.
-  - Host + project: `us-central1-docker.pkg.dev/neetru` → infere repo.
-  - Host + project + repo: `us-central1-docker.pkg.dev/neetru/gestovendas-staging` → usa direto.
-
-- **bug_0a551e02295b42b9894f6eb6b13887b3 (CRITICAL) — `neetru deploy --target=cloud-run` exigia docker local.**
-  Docker Desktop não é viável em Windows dev machine (5+ GB, requer WSL2, reboot) nem em CI headless.
-  Fix: pipeline substituído por `gcloud builds submit --tag=<uri> [--project=<id>] <cwd>` (Cloud Build
-  remoto). Não exige Docker instalado — apenas `gcloud` autenticado (já feito via `neetru bootstrap`).
-  `--build-local` força o comportamento anterior (docker build + push) para devs que preferem build local.
-
-- **bug_1904ba55feeb480690eb8a7f00b4a7b7 (HIGH) — `--stack=node` sem Dockerfile terminava com erro pouco acionável.**
-  Fix: quando `--stack=node` ou `--stack=nextjs` e não há `Dockerfile` no projeto, o CLI gera
-  automaticamente um template adequado no `cwd` antes de chamar o Cloud Build, e apaga ao terminar.
-  Templates:
-  - `node`: `FROM node:22-slim` + `npm ci --omit=dev` + `CMD ["node", "server.js"]` + porta 8080.
-  - `nextjs`: multi-stage com standalone output + `COPY .next/standalone` + porta 8080.
-  - `docker`: continua exigindo Dockerfile manual (com mensagem de erro clara).
-  Aviso `log.warn` antes de gerar o template para o dev saber o que aconteceu.
-
-### Adicionado
-
-- **`--registry-repo <name>`** — flag opcional para especificar o nome do repositório AR explicitamente.
-  Se omitido, inferido como `{productSlug}-{env}` (ex: `gestovendas-staging`).
-- **`--build-local`** — força `docker build` local em vez do Cloud Build remoto.
-- **`--stack=nextjs`** — novo valor suportado em `neetru deploy`, gera Dockerfile Next.js standalone.
-- **`DeployOptions.json?: boolean`** — campo para propagação de modo JSON em preflight IAM checks.
-
-### Testes
-
-- `src/__tests__/deploy-image-uri.test.ts` — 10 casos cobrindo `buildArtifactRegistryUri` (segmentos, tag sanitização, REGRESSÃO original).
-- `src/__tests__/deploy-cloud-build.test.ts` — 5 casos cobrindo Cloud Build remoto vs docker local.
-- `src/__tests__/deploy-dockerfile-template.test.ts` — 7 casos cobrindo geração/limpeza de template, node/nextjs/docker, warning, existente não sobrescrito.
-
-## [2.9.6] — 2026-05-25 (fix: 3 HIGH Windows compat — bug_ec17af + 0cf14fba + 6001c5e)
-
-### Corrigido
-
-- **bug_ec17af083d7045a1a00f24255efb716c — `neetru deploy --target=cloud-run --artifact=<file>` rejeita silenciosamente.**
-  `--artifact` (tarball source) é incompatível com `target=cloud-run` que exige imagem de container OCI.
-  Adicionada verificação explícita em `runCloudRunDeploy`: quando `--artifact` ou `--artifact-url` é passado
-  com `target=cloud-run`, o CLI sai com `exit 1` e exibe mensagem orientadora com as 3 alternativas corretas:
-  `--image <uri>`, `--registry <host>` (build automático) e `--target=vm` (que aceita tarball).
-  Anteriormente a flag era silenciosamente ignorada, levando ao erro críptico "Sem imagem pra deployar".
-
-- **bug_0cf14fba40ec4352b75f3af2467e24b0 — `neetru build` quebra em Windows com scripts npm unix-only.**
-  Scripts como `NODE_ENV=production next build` usam sintaxe de variável de ambiente Unix incompatível
-  com `cmd.exe`. Adicionada função `detectsUnixEnvPrefix` em `buildNode`: quando `process.platform === 'win32'`
-  e o script `build` do `package.json` contém prefixo de env Unix (padrão `VAR=val ...`), o CLI emite
-  warning orientador antes de tentar rodar. O warning lista as 2 soluções: adicionar `cross-env` ao script,
-  ou remover o prefixo (Next.js já usa `production` por padrão em `next build`).
-  O build prossegue mesmo com o warning (shell=true no spawn já torna compatível em muitos casos).
-
-- **bug_6001c5e83c764428ae39a5d6a1f8be82 — `neetru build` falha com tar em paths com drive-letter Windows.**
-  GNU tar (MSYS2/Git Bash) interpreta `S:` como host SSH, causando "Cannot connect to S: resolve failed".
-  Correção dupla em `tarDirectory` (e `buildDocker`):
-  1. `--force-local` adicionado automaticamente quando `process.platform === 'win32'` — instrui o GNU tar
-     a não interpretar nomes de arquivo como endereços remotos (ignorado pelo bsdtar nativo do Windows 10+).
-  2. `normalizePathForTar()`: converte `S:\Documents\...` → `/S/Documents/...` antes de passar pro tar,
-     compatível com ambos os tars (GNU e BSD).
-  Workaround manual do usuário (`tar --force-local -czf ...`) agora está embutido automaticamente no CLI.
-
-## [2.9.3] — 2026-05-25 (fix HIGH: branch NoSQL no db apply — Bug 11 Fase 1)
-
-### Corrigido
-
-- **Bug 11 Fase 1 — `neetru db apply` era SQL-only; branch NoSQL nunca era alcançada.**
-  Adicionada detecção de engine em `runDbApply`: quando `engine ∈ {nosql-vm, firestore-instance}`,
-  o pipeline SQL (drizzle-kit + Postgres efêmero + classify) é completamente ignorado.
-  A nova função `runNoSqlApply` calcula o fingerprint SHA-256 do `schema.ts` local e envia
-  `POST /api/cli/v1/db/apply` com `schemaDefinition: null` (Fase 1 — sem JSON Schema export).
-  O Core registra o snapshot em `product_db_schema_snapshots/{id}` (implementado em commit `116f0d60`).
-  Saída interativa: spinner `"Aplicando schema NoSQL (sem rehearse — engine schemaless)…"`.
-  Saída `--json`: `{ ok, status, engine, snapshotId, fingerprint, dryRun }`.
-  `--dry-run` calcula fingerprint mas não envia ao Core (status `dry_run`).
-  O pipeline SQL para `cloud-sql-*` e `vm-*` permanece intacto — sem regressão.
-
-## [2.9.2] — 2026-05-25 (ux: cliente padrão Neetru automático)
-
-### Melhorado
-
-- **`neetru workspaces create` — `--customer` agora opcional para produtos Neetru-owned.**
-  Quando o produto selecionado pertence à Neetru (`ownedBy='neetru'`, `ownerTeam='Neetru Core'`
-  ou slug na lista conhecida), o CLI detecta via API e pula o prompt de cliente automaticamente.
-  Em modo interativo exibe `"Cliente omitido — produto Neetru detectado. Usando cliente interno automaticamente."`.
-  Em modo `--json`, envia `customerId` ausente; o Core injeta o customer interno (`isNeetruInternal=true`).
-  Para produtos de terceiros, `--customer` continua obrigatório (erro acionável com instruções de criação).
-
-- **`neetru tenants create` — mesma lógica de auto-default.**
-  Prompt de `customerId` pulado automaticamente quando produto é Neetru-owned.
-
-- **`neetru workspaces create` — mensagem de confirmação no output.**
-  Quando `--customer` não é fornecido, exibe `"Cliente: Neetru Tecnologia (interno) — auto-detectado pelo produto Neetru."`.
-
-## [2.9.1] — 2026-05-25 (security: 5 HIGH fixes)
-
-### Corrigido (segurança)
-
-- **HIGH-1 — `db apply --json` selecionava o primeiro banco silenciosamente com múltiplos bancos.**
-  Em modo não-interativo (`--json` ou `--yes` sem TTY), se `.neetru/db.json` tiver N > 1 bancos
-  e `--db` não for passado, o CLI agora emite erro estruturado em vez de aplicar no primeiro banco.
-  Saída JSON: `{ ok: false, error: "db_required", message: "...", available: [...] }`.
-  Em CI isso evitava migração silenciosa no banco errado.
-
-- **HIGH-2 — Abertura de URL no Windows usava `cmd /c start` sem validação de protocolo.**
-  URLs derivadas de config podiam conter caracteres de injeção de shell (`& malicious.exe`).
-  Nova função `safeOpenUrl` valida `^https?://` antes de qualquer chamada de sistema e usa
-  `rundll32 url.dll,FileProtocolHandler` (sem shell) no Windows. Aplica em `open.ts` e
-  `workspaces.ts` (que agora delega para `safeOpenUrl`).
-
-- **HIGH-3 — `db init` gravava stub local em `.neetru/db.json` antes de registrar no Core.**
-  Falha de rede/400 do Core deixava entrada órfã e re-rodar `db init` adicionava banco duplicado.
-  Agora o registro no Core acontece primeiro; `.neetru/db.json` só é escrito após sucesso.
-
-- **HIGH-4 — `marketplace sdk add <template>` aceitava path traversal.**
-  `path.join(templatesDir, templateName)` aceitava `../../etc/passwd` como nome.
-  Adicionada whitelist `ALLOWED_SDK_TEMPLATES` e verificação `startsWith(resolve(templatesDir) + sep)`
-  como defesa em profundidade.
-
-- **HIGH-5 — `docs publish` usava path absoluto Windows como slug.**
-  Path como `C:/Users/dev/projeto/docs/intro.md` virava slug `C:/Users/dev/projeto/docs/intro`,
-  expondo estrutura de filesystem. `deriveSlugFromPath` agora converte para relativo via
-  `path.relative(cwd, file)` e rejeita slugs com `:`, `..` ou `/` inicial.
-
-## [2.8.2] — 2026-05-25 (fix UX slug conflict + docs open)
-
-### Corrigido
-
-- **Bug #31 — `neetru new` não falha seco em conflito de slug.**
-  Quando o Core retorna 400 com "Já existe um produto com o slug X", o CLI
-  agora exibe o produto existente (nome, ID, status) e oferece um prompt
-  interativo com três opções:
-  1. Vincular este projeto local ao produto existente (escreve `.neetru/config.json`
-     apontando para o `productId`).
-  2. Criar com slug diferente — lista sugestões (`gestovendas-v2`, `-2`, etc.)
-     ou permite digitar um slug livre.
-  3. Cancelar.
-  Removida a mensagem "Tente manualmente: neetru products create --slug <mesmo-slug>"
-  que sugeria repetir exatamente o comando que vai falhar de novo.
-  O fallback genérico cobre qualquer 400 cujo `message` contenha "Já existe",
-  "slug", "already exists" ou "duplicate".
-
-- **Bug #26 — `neetru docs` não abria documentação ao vivo.**
-  O comando `neetru docs` era exclusivamente um registry CRUD (publish/list/get/delete)
-  e não tinha forma de acessar a documentação pública. Adicionado:
-  - `neetru docs open [topic]` — abre `https://core.neetru.com/docs` (ou seção
-    específica) no browser padrão. Tópicos: `sdk`, `cli`, `db`, `webhooks`, `auth`,
-    `billing`, `observability`, `infra`, `dns`, `deploy`, `architecture`.
-  - `neetru docs open` sem argumento — abre o índice geral.
-  - Argumentos desconhecidos abrem busca: `core.neetru.com/docs?q=<query>`.
-  - No menu interativo (`neetru ui`), "Docs live" agora exibe "Abrir documentação
-    no navegador" como primeira opção antes das opções de registry.
-
-### Notas de uso
-
-```
-neetru docs open          # abre core.neetru.com/docs
-neetru docs open sdk      # vai direto pra referência do SDK
-neetru docs open webhooks # manual de runtime/webhooks
-```
-
-## [2.8.1] — 2026-05-25 (marketplace)
-
-### Adicionado
-
-- **`neetru marketplace`** — central de artefatos do ecossistema Neetru.
-  - `neetru marketplace skills install` — clona `Neetru/neetru-libs` em
-    `~/.neetru/marketplace-cache/` e instala skills em `~/.claude/skills/`.
-    Linux/macOS: symlink (atualizações automáticas via git pull).
-    Windows: cópia recursiva (sem exigir Developer Mode).
-  - `neetru marketplace skills update` — git pull no cache + re-copia skills
-    instaladas como cópia (symlinks já são atualizados pelo pull).
-  - `neetru marketplace skills list` — tabela com nome, versão, status e
-    descrição de cada skill disponível no cache local.
-  - `neetru marketplace skills uninstall` — remove skills de `~/.claude/skills/`
-    com confirmação interativa (bypass via `--yes`).
-  - `neetru marketplace sdk init` — adiciona `@neetru/sdk@^2.1.0` ao
-    `package.json` do projeto atual e cria `src/neetru.ts` com boilerplate
-    de `createNeetruClient`. Idempotente — não sobrescreve arquivo existente.
-  - `neetru marketplace sdk templates` — lista templates disponíveis em
-    `templates/` da instalação do CLI.
-  - `neetru marketplace sdk add <template>` — copia template de feature
-    (auth/billing/usage/support/users) pra `src/` do projeto atual.
-  - `neetru marketplace browse` — abre `https://github.com/Neetru/neetru-libs`
-    no browser (start/open/xdg-open por plataforma).
-- **Menu interativo** — item **"Marketplace"** adicionado ao menu principal
-  (entre Suporte e Docs live) com sub-menu completo: skills (instalar /
-  atualizar / listar / remover) + SDK (init / add template / listar / docs)
-  + abrir no GitHub.
-
-## [2.7.5] — 2026-05-20 (fix do crash no upgrade)
-
-### Corrigido
-
-- `neetru upgrade` não crasha mais ao terminar. O comando chamava
-  `process.exit(0)` logo após o `fetch` ao npm — no Windows isso
-  derrubava o libuv com `Assertion failed: !(handle->flags &
-  UV_HANDLE_CLOSING)` (`async.c`), porque o socket do undici (fetch
-  nativo) ainda estava em teardown. Agora o comando só retorna; o event
-  loop drena sozinho (o undici dá unref nos sockets idle) e o processo
-  encerra limpo na hora.
-
-## [2.7.4] — 2026-05-20 (submenus redesenhados)
-
-### Adicionado
-
-- Submenu **"Começar um projeto"** no menu principal — reúne o scaffold
-  local (`neetru init`), a criação completa (`neetru new`) e uma tela de
-  info sobre o `@neetru/sdk` (o que é, como instalar e consumir).
-- Os 10 submenus ganharam o **mesmo visual do menu principal**: moldura
-  azul-marinho, marcador `> <` no item ativo e navegação por setas — em
-  coluna única, alinhada à esquerda.
-
-### Corrigido
-
-- Submenu não engole mais a primeira seta. O menu principal entregava o
-  stdin pausado / fora de raw mode pro submenu, e o inquirer perdia a
-  1ª tecla — só respondia depois de um toque inicial. Agora o stdin fica
-  "quente" na entrega; a seta funciona de cara.
-
-## [2.7.3] — 2026-05-20 (polish do cabeçalho)
-
-### Mudado
-
-- Cabeçalho do `neetru` interativo: logo renderizado **ao lado** do texto
-  (antes era acima), com a sessão e a versão alinhadas à direita do logo.
-- Paleta de contorno do menu e do logo ajustada para um azul mais suave.
-
-## [2.7.2] — 2026-05-20 (aviso de versão + menu em 2 colunas)
-
-### Adicionado
-
-- O cabeçalho do `neetru` interativo mostra a **versão instalada** (`v2.7.2`)
-  ao lado do usuário logado. Quando há uma versão mais nova publicada no
-  npm, aparece uma linha **amarela** avisando pra rodar `neetru upgrade`.
-  A checagem tem timeout curto e é à prova de falha — offline não trava o
-  CLI.
-- Menu principal redesenhado em **duas colunas**, com navegação por setas
-  (↑/↓/←/→) e contorno azul-marinho; o item ativo é marcado com `> <`.
-
-## [2.7.1] — 2026-05-20 (UI do CLI interativo)
-
-### Adicionado
-
-- Logo Neetru em ANSI truecolor no cabeçalho do `neetru` interativo.
-- Cabeçalho mostra o usuário logado (email), lido localmente do
-  `auth.json` — sem chamada de rede.
-- Menu principal com o nome do recurso + uma descrição curta abaixo,
-  quando útil.
-
-### Corrigido
-
-- O CLI interativo não encerra mais sozinho: comandos que chamavam
-  `process.exit()` em erro (ex.: "Nenhum server encontrado") matavam o
-  menu inteiro. Agora o erro é capturado e o CLI volta ao menu — só
-  "Sair" (ou Ctrl+C) encerra.
-
-## [2.7.0] — 2026-05-20 (Fluxo de Ambientes Fase 3 — destino cloud-run)
-
-### Adicionado
-
-- `neetru deploy --target=cloud-run` — caminho de deploy pro destino Cloud Run
-  dedicado. Aceita `--image <uri>` (imagem de container já buildada e pushada)
-  ou faz `docker build` + `docker push` automático via `--registry <host>`
-  (Artifact Registry). O destino `cloud-run` agora aparece no menu interativo.
-
-### Mudado
-
-- `neetru promote` — vocabulário de estágios migrado para `dev | staging | prod`
-  (antes `dev/workspace/beta/prod`). Gates: 24h em `dev→staging`,
-  168h + canary em `staging→prod`.
-- `neetru deploy --target` — sem valor default; omitir abre o menu interativo
-  (workspace / cloud-run / vm). Modo não-interativo continua assumindo `vm`.
-
-## [2.0.0] — 2026-05-06 (Sprint 12 — CLI estabilizada)
-
-### Adicionado
-
-- `neetru doctor` — diagnóstico completo do ambiente: token CLI, Core acessível,
-  schema do `neetru.config.json`, valor de `NEETRU_ENV`, e versão do CLI
-  comparada com a `latest` no npm. Saída em tabela colorida (default) ou
-  JSON (`--json`). Diferença pra `validate`: doctor inclui environment +
-  version mismatch (warning, não fail).
-- `neetru upgrade` — verifica `dist-tags.latest` em
-  `https://registry.npmjs.org/@neetru/cli` e exibe instrução de upgrade
-  (`npm install -g @neetru/cli@latest`). Sem auto-install — não quebra
-  pipelines pinados.
-- `neetru autocomplete <bash|zsh|pwsh>` — gera script de shell completion
-  pra os 22 subcomandos top-level. Usuário cola na config do shell:
-  `neetru autocomplete bash >> ~/.bashrc`.
-- `neetru config set telemetry.enabled <true|false>` — opt-in explícito de
-  telemetria. Default desligado. Quando ligado, CLI envia eventos
-  anonimizados pra `POST /sdk/v1/telemetry/log` (placeholder na v2.0).
-  Nunca envia tokens, paths absolutos ou conteúdo de arquivos.
-
-### Bumped
-
-- `1.4.0 → 2.0.0` (major bump por convenção de estabilidade — sem breaking
-  changes funcionais).
-
-### Não publicado no npm ainda
-
-Bump local. Publish manual pra npm fica deferido — owner aprovará. Build
-local (`npm run build` em `cli/`) gera o `dist/` pronto pra publicação.
-
-## [1.3.0] — 2026-05-06
-
-### Adicionado
-
-- `neetru add <feature>` — copia template em `cli/templates/{feature}/*` para
-  `src/lib/neetru/{feature}/*` no projeto atual. Features: `auth`, `billing`,
-  `usage`, `users`, `support`. Suporta `--force` pra sobrescrever.
-- `neetru mocks reset` — reseta `.neetru/dev-fixtures.json` para `{}` (útil
-  com `NEETRU_ENV=dev`).
-- `neetru env switch <dev|workspace|production>` — atualiza/insere
-  `NEETRU_ENV=<value>` em `.env.local` preservando as outras chaves.
-- `neetru logs` ganhou flags:
-  - `--product <productId>` — filtra logs por produto.
-  - `--channel <channel>` — filtra por channel (stdout/stderr/app/...).
-  - `--correlation-id <uuid>` — filtra por correlation ID.
-
-### Templates novos (`cli/templates/`)
-
-- `auth/sign-in.tsx`, `auth/callback.ts`
-- `billing/page.tsx`, `billing/checkout.ts`
-- `usage/track.ts`
-- `users/profile.tsx`
-- `support/ticket-form.tsx`
-
-### Não publicado no npm ainda
-
-Bump local `1.2.0 → 1.3.0`. Publish pra npm fica deferido — owner aprovará
-manualmente quando quiser. Build local (`npm run build` em `cli/`) já compila.
-
-## [1.2.0] — 2026-05-06
-
-**Consolidação das duas linhas paralelas.** Esta versão unifica os comandos das duas linhas de CLI que estavam coexistindo:
-
-- **`@neetru/cli@1.0.x` (publicada no npm)**: linha *workspace-centric* com `init`, `add`, `validate`, `generate-types`, `whoami`, `login`, `status`, `logs`, `deploy`, `open`. APIs: `/api/v1/cli/workspace/*`.
-- **`@neetru/cli@0.1.0` (monorepo, não publicada)**: linha *server-centric* com `ai`, `init`, `config`, `login`, `logout`, `whoami`, `build`, `deploy`, `publish`. APIs: `/api/v1/cli/{catalog,deploy,servers}`.
-
-As duas falam **APIs distintas e complementares** do mesmo Neetru Core, refletindo a topologia real do produto:
-
-```
-Workspace (prototipação) ──build/promote──► Server VM ou Cloud Run (produção)
-```
-
-A `1.2.0` traz ambos os conjuntos de comandos numa única CLI. O monorepo passa a ser a fonte canônica.
-
-### Adicionado em relação a `1.0.1`
-
-Comandos da linha *server-centric* (deploy via VM agent ou Cloud Run):
-
-- `neetru ai` — REPL multi-model (Claude/OpenAI/Gemini) com contexto Neetru-aware
-- `neetru build` — empacota produto local em tarball + manifest com sha256, detecção automática de stack (node/docker/php-apache/static)
-- `neetru deploy` — pipeline E2E interativo (escolha de produto/server/domain/port + polling status até estado terminal). Suporta `--non-interactive` para CI.
-- `neetru publish` — registra produto no catálogo público (`public_products`), com `--draft` e `--unpublish`
-- `neetru config {set|get|path}` — gerenciamento de chaves de API e config local
-- `neetru logout` — limpa credenciais
-- `neetru login --token nrt_<keyId>_<secret>` — modo CI/legacy paralelo ao Device Code OAuth
-- `neetru login --json` — saída machine-readable para scripts
-
-### Mantido de `1.0.1` (re-implementado em TypeScript com convenções do monorepo)
-
-- `neetru status --client-id <id>` — status de workspace (build/deploy último, domínio, tier, expira em N dias)
-- `neetru logs --client-id <id>` — visualiza logs do workspace; suporta `-f` follow + `-n N` lines + `--since 30m` + `--level error`
-- `neetru validate` — health-check da config local + ping `/api/health` + whoami
-- `neetru open [target]` — abre dashboard, builds, logs, workspaces, products, servers, incidents no browser
-- `neetru init <name>` — agora gera projeto Next.js 15 OU Node API (Fastify) com schema canônico v2
-
-### Backlog 1.3.x
-
-Comandos que ainda dependem de design/templates novos:
-
-- `neetru add <feature>` — scaffolds OAuth/billing/usage/users
-- `neetru generate-types` — codegen TypeScript de planos/features/entitlements
-
-### Alterado
-
-- Package agora é ESM nativo (`"type": "module"`). Imports usam `.js` extension.
-- `neetru login` agora usa Device Code OAuth (RFC 8628) por default; `--token` permanece para CI.
-
-### Migração de `1.0.x`
-
-Não há caminho 100% automático porque a config local muda:
-
-- `1.0.x` lia `neetru.json` workspace-local com `{clientId, coreUrl}` + var de ambiente `NEETRU_CLIENT_SECRET`
-- `1.2.0` lê `~/.config/neetru-cli/auth.json` (Bearer token salvo por `neetru login`) + `neetru.config.json` por projeto com `{slug, runtime, publish}`
-
-Recomendação:
-
-1. `npm uninstall -g @neetru/cli && npm install -g @neetru/cli@1.2.0`
-2. `neetru login` (Device Code) — gera credencial Bearer no novo formato
-3. Para comandos workspace (`status`, `logs`, `open`), passe `--client-id <oauthClientId>` explicitamente — o `clientId` continua sendo o `oauthClientId` do seu workspace, achável em UI Core `/workspaces/{id}`
-
-## [1.0.1] — anterior
-
-Linha workspace publicada no npm. Comandos: `init`, `add`, `validate`, `generate-types`, `whoami`, `login`, `status`, `logs`, `deploy`, `open`. APIs: `/api/v1/cli/workspace/*`.
-
-## [1.0.0] — anterior
-
-Primeira versão pública.
-
-## [0.1.0] — interno (não publicado)
-
-Snapshot interno do monorepo durante desenvolvimento da Sprint 1+. Substituído por `1.2.0`.
+# Changelog @neetru/cli
+
+Convenção: [Keep a Changelog](https://keepachangelog.com/) + [SemVer](https://semver.org/).
+
+## [2.11.4] — 2026-06-05 (db init serverId p/ engines vm-* · README/help fixes)
+
+> Patch consolidando a branch `feat/cli-2.10.2-2.11` com `main` (que já havia avançado pra 2.11.3 com `deployments get|status` + `--stack=nextjs→node`). Sem breaking change.
+
+### Corrigido
+
+- **`neetru db init` coleta `serverId` p/ engines vm-\*** (`bug_062f7fea`, pdv-agiliza) — o Core exige `serverId` p/ engines vm-* (e `nosql-vm`), mas o fluxo dev-facing `db init` não enviava nem expunha a flag → `register_failed`. Agora aceita `--server-id <id>`; sem ele em modo interativo abre prompt listando VM hosts (`GET /api/cli/v1/servers?capacity=true&db=true`, filtra status mortos) com fallback de input livre; em modo `--yes`/`--json` falha com erro `server_id_required` claro. `serverId` vai no top-level do payload de `POST /api/cli/v1/db/register`.
+
+### Documentação / ajuda
+
+- **README — comandos `db` deprecados corrigidos** (CLI-QW-7a) — a tabela ensinava `neetru db create`/`neetru db engines` (inexistentes na árvore `db`). O canônico é `neetru admin database create/engines`; nomes de engine reais (`cloud-sql-postgres`, `vm-postgres-single`, `nosql-vm`, …) em vez de `postgres`/`mysql`.
+- **`ops heartbeat` / `ops smoke observability` — defaults mágicos surfados** (CLI-QW-8) — `--server-id=srv-test-01` (placeholder de teste) e `--base-url=https://core.neetru.com` agora aparecem na descrição do comando + no help da option, evitando sondar silenciosamente um server inexistente.
+- **README drift de stack corrigido** (CLI-QW-7b) — alinhado ao `package.json` real: Node `>=20` (era `>=22`), Commander 12 (era 11), Inquirer 10 (era 12). Nenhuma dep nem `engines` foi tocado — só doc.
+
+## [2.11.0] — 2026-05-27 (hardening: token unificado · URL allowlist · telemetry real)
+
+> Minor de hardening pós-2.10.2. Fecha 3 itens HIGH levantados na review do chefe-de-CLI (`docs/_review/CHEFE_CLI_REVIEW_2026-05-27.md` no Core) + Codex sweep (HIGH-10). Nenhuma breaking change — comandos e flags antigas seguem funcionando; warnings apontam para a deprecação prevista pra 2.12.0.
+
+### Adicionado
+
+- **`--allow-untrusted-url` em `neetru config set`** (MASTER-HIGH-049) — flag opt-in pra setar `neetruApiUrl` fora da allowlist canônica. Sem essa flag (ou `NEETRU_ALLOW_UNTRUSTED_URL=1`) o `config set` rejeita com exit(1) + banner vermelho. Allowlist: `api.neetru.com`, `core.neetru.com`, `neetru.com` (apex), `*.neetru.com` (subdomínios), `localhost`/`127.0.0.1`/`::1` (dev — HTTP ok); demais hosts exigem HTTPS.
+- **Telemetry real** (MASTER-HIGH-052) — `telemetry.enabled` deixou de ser flag fantasma. Quando opt-in, `neetru <comando>` agora emite evento anônimo (`{command, durationMs, ok, exitCode, ts}`) para `POST /api/sdk/v1/telemetry/log`. Identificação por `installId` UUID em `~/.config/neetru-cli/install-id` (chmod 0600). Nunca envia token, path absoluto, email, ou env. Buffer in-memory cap 50 + flush em `beforeExit` com timeout 1.5s (fire-and-forget — erro de rede não bloqueia o comando). Override: `NEETRU_TELEMETRY_DISABLED=1`.
+
+### Mudado (compat-friendly)
+
+- **Token resolver unificado** (MASTER-HIGH-048) — `api-client.ts` (`apiRequest` + `apiStream`) agora lê o Bearer token via `getActiveTokenSync()` (`src/lib/token-resolver.ts`), que prefere `~/.config/neetru-cli/auth.json` (canônico desde Sprint 1) sobre o Conf storage (legacy). Quando o token vem do Conf, emite warning one-shot stderr alertando deprecação pra 2.12.0. 8 comandos que liam `config.get('neetruApiKey')` direto (`status`, `validate`, `deploy`, `vm`, `logs`, `doctor`, `publish`, `whoami`) migrados pra `getActiveTokenSync()`. Comportamento anterior — "logado pra `whoami` mas não pra `status`" quando o token só existia em `auth.json` — desaparece.
+- **`neetru config set neetruApiKey` emite deprecation warning** — o setter manual continua funcionando, mas avisa que `neetru login` é o caminho canônico (que grava em `auth.json` chmod 0600). Storage Conf de `neetruApiKey` será removido em 2.12.0.
+- **`apiRequest` emite warning one-shot quando host customizado fora da allowlist** — defesa em profundidade pra casos em que o owner já tem URL untrusted em Conf (não pegou o `config set` 2.11).
+
+### Infraestrutura de testes (+34 tests)
+
+- **Novo `src/__tests__/url-allowlist.test.ts`** (15 cases): hosts trusted + edge cases (domain confusion `neetru.com.evil.com`, HTTP em prod, protocolos não suportados).
+- **Novo `src/__tests__/config-set-allowlist.test.ts`** (7 cases): rejeita default, aceita com `--allow-untrusted-url`, aceita com env override.
+- **Novo `src/__tests__/token-resolver.test.ts`** (4 cases): precedência `auth.json > Conf > null` + warning one-shot stderr.
+- **Novo `src/__tests__/telemetry.test.ts`** (8 cases): opt-in default off + env override, happy path POST com payload validado, idempotência do flush, falha de rede engolida, cap de buffer, privacy (zero token/path/email no payload).
+- 7 tests existentes ganharam `readAuthJsonSync: vi.fn(() => null)` no mock de `auth.js` (control-plane, workspaces, products-create, sdk-credential, new-browser-optin, doctor, publish) — preserva semântica antiga de "token via config.set" caindo no fallback Conf.
+- `vitest.config.ts` seta `NEETRU_SUPPRESS_LEGACY_WARNINGS=1` em test setup pra não poluir CI com banner de deprecation.
+
+### Deprecation timeline
+
+- **2.11.0 (esta release):** Conf `neetruApiKey` ainda funciona (com warning); login grava em ambos os storages.
+- **2.12.0 (planejado):** `login` para de gravar em Conf; `config set neetruApiKey` continua aceito mas vira no-op com warning; `Conf neetruApiKey` removido do schema. Owner que copia binário pra outra máquina precisa garantir migração `~/.config/neetru-cli/auth.json`.
+
+### Sem breaking change
+
+- Todos os comandos e flags da 2.10.x seguem funcionando.
+- Endpoints API canônicos inalterados.
+- Path padrão `~/.config/neetru-cli/auth.json` continua canônico.
+
+---
+
+## [2.10.2] — 2026-05-27 (patch: paths broken em produção + autocomplete drift)
+
+> Patch urgente — chefe-de-CLI review do dia (`docs/_review/CHEFE_CLI_REVIEW_2026-05-27.md` no Core) + `MASTER_PLAN_2026-05-27.md` §4 Bloco G. Quatro endpoints quebrados em produção (404 silencioso ou rota inexistente) + cobertura de autocomplete em ~45% silenciosamente. Sem nada novo de UI ou behavior — só fix de quem já estava 404'eando.
+
+### Corrigido (CRITICAL)
+
+- **MASTER-CRIT-035 — `neetru promote` apontava pra endpoint inexistente.** `src/commands/promote.ts:104` chamava `/cli/v1/promotion/request` (sem prefixo `/api`) → 404 sempre. Pior: o handler de 404 ainda mascarava o erro com "Endpoint ainda não disponível, entra em build no Sprint 11" — a rota existe há sprints sob `/api/cli/v1/promotion/request`. Fixado. Handler de 404 agora reporta erro real (exit 5). Test cúmplice `promote.test.ts:110` atualizado (pinava `/cli/v1/...` como correto).
+- **MASTER-CRIT-036 — `neetru agent release` apontava pra endpoint inexistente.** `src/commands/agent-release.ts:215` chamava `/cli/v1/agent/release`. Trocado pra canônico `/api/cli/v1/agent/release`.
+- **MASTER-CRIT-037 — `neetru fn deploy` removido (rota nunca existiu).** `src/commands/fn.ts` apontava pra `/cli/v1/fn/deploy` — não há rota em `/api/**/fn/**` no Core. Comando deletado por inteiro (arquivo + import em `src/index.ts` + entry em autocomplete + test cúmplice `src/__tests__/fn.test.ts` que pinava o path errado). Reintroduzir quando/se a feature for de fato implementada server-side.
+
+### Corrigido (HIGH)
+
+- **MASTER-HIGH-050 — `neetru logs` apontava pra alias legacy.** `src/commands/logs.ts:106` usava `/api/v1/cli/logs` (inversão dos prefixos). O alias legacy ainda existe no Core mas tem deprecation prevista para 2026-07-01 — depois disso `neetru logs` morre sem aviso. Trocado pra canônico `/api/cli/v1/logs`.
+- **MASTER-HIGH-051 — autocomplete cobria só ~45% dos comandos.** `TOP_LEVEL_COMMANDS` em `src/commands/autocomplete.ts` listava 22 entries de um total de ~50 comandos top-level expostos em `src/index.ts`. Bash/zsh/pwsh completion silenciosamente broken para a maioria das operações (auth, admin, customers, tenants, audit, billing, servers, workspaces, deployments, cloud-run, api-catalog, products, vm, support, bug, dns, hosting, builds, dr, docs, …). Reescrito para incluir TODOS os ≈50 comandos, em ordem alfabética. Aliases incluídos (`menu` → `ui`, `ar` → `artifact-registry`).
+
+### Infraestrutura de testes (regression guards)
+
+- **Novo: `src/__tests__/endpoint-paths.regression.test.ts`** — varre `src/commands/**/*.ts` extraindo o primeiro argumento de toda chamada `apiRequest(...)` / `apiStream(...)` e valida que começa com prefixo canônico: `/api/cli/v1/`, `/api/sdk/v1/`, `/api/v1/`, ou `/api/internal/`. Allowlist explícita só pra `/api/health` (Cloud Run healthcheck). Três testes: prefixo canônico, zero `/cli/v1/*` cru (vetor dos CRIT-035..037), zero `/api/v1/cli/*` invertido (vetor do HIGH-050).
+- **Novo: `src/__tests__/top-level-commands-coverage.regression.test.ts`** — parse simples de `src/index.ts` extraindo `program.command('X')`; exige cobertura ≥95% em `TOP_LEVEL_COMMANDS` + zero entries fantasma + ordem alfabética. Detecta drift do autocomplete quando alguém adicionar/remover comando no `index.ts` no futuro.
+
+### Sem mudança
+
+- Comportamento do CLI fora dos 4 fixes — idêntico ao 2.10.1.
+
+---
+
+## [2.10.0] — 2026-05-27 (rename: `neetru marketplace` → `neetru archive` · fonte agora pública)
+
+### BREAKING
+
+- **`neetru marketplace` foi renomeado para `neetru archive`.** Subcomandos preservados (`skills install/update/list/uninstall`, `sdk init/templates/add`, `browse`). NÃO há alias de retrocompat — o comando antigo deixa de existir nesta versão. Quem rodava `neetru marketplace skills install` em scripts CI precisa trocar para `neetru archive skills install`.
+- **Cache local mudou de `~/.neetru/marketplace-cache/` para `~/.neetru/archive-cache/`.** Caches antigos podem ser apagados manualmente (não há migração automática — `archive skills install` cria o novo limpo). A função `getSkillsSourceDir` mantém retrocompat detectando o nível `claude-skills/` caso o cache de uma versão anterior do `archive-cache` ainda tenha esse layout.
+- **Variável de ambiente `NEETRU_MARKETPLACE_SYMLINK` virou `NEETRU_ARCHIVE_SYMLINK`** (Windows). Quem usava precisa renomear.
+
+### Mudado
+
+- **Fonte de skills migrou de `github.com/Neetru/neetru-libs` (privado) para `github.com/Neetru/neetru-libs-public` (público).** O `neetru-libs` privado mantém `packages/` (`@neetru/db-classifier`, `sql-guard`, `pii-mask`, `neetru-glossario`) — só `claude-skills/` foi exposto, via `git subtree push --prefix=claude-skills`. Resultado: `neetru archive skills install` deixa de exigir `gh auth setup-git` ou `GITHUB_TOKEN` — clone anônimo funciona.
+- **Layout do clone público é mais flat:** `plugins/<plugin>/skills/<skill>/SKILL.md` no topo (em vez de `claude-skills/plugins/...`). O resolver detecta o layout legado automaticamente — caches antigos continuam resolvendo até o próximo `archive skills update`.
+
+### Por quê
+
+- O 2.9.13 quebrava em `git clone` quando `neetru-libs` virou privado (HTTP 401 sem credencial git configurada). O fix arquitetural certo era separar o catálogo público de skills do código proprietário em `packages/` — `neetru-libs-public` é esse catálogo. A renomeação `marketplace → archive` aproveitou o break pra alinhar o nome do comando ao conceito real (catálogo/arquivo de artefatos, não um marketplace transacional).
+
+## [2.9.13] — 2026-05-26 (feat: force-cleanup recovery + mfa-status observability)
+
+### Adicionado
+
+- **`neetru servers force-cleanup <serverId> --reason "..." [--yes] [--json]`** — recovery quando VM stuck (status=timeout_agent_register/falha_provisionamento/provisionando >30min) e flow normal (`deactivate`/`delete` com MFA) não funciona. NÃO exige MFA (bypass intencional pra desbloquear deadlock — bug_c42fa12b CRITICAL quando MFA broken via bug_84e4dacb). Double-confirm interativo: usuário digita o serverId. Audit pesado + notification all staff garantem accountability. Bate em POST `/api/cli/v1/servers/[id]/force-cleanup`.
+- **`neetru auth mfa-status [--json]`** — observability MFA do usuário atual: enrolled, enrolledAt, lastUsedAt, hasEncryptedSecret, recoveryCodesCount, hint acionável (clock skew vs nunca usado vs zero recovery codes vs MFA não enrolled). Bate em GET `/api/cli/v1/auth/mfa/status`. Útil quando `servers deactivate` rejeita TOTP e owner precisa debugar antes de tentar novamente.
+
+### Corrige (HIGH/CRITICAL)
+
+- **bug_c42fa12b1e194a0794f14ea74994e2a3 (CRITICAL) — Deadlock VM stuck + MFA broken.** force-cleanup destrava recovery sem precisar MFA. Pré-condições rígidas + audit pesado mitigam risco de uso indevido.
+- **bug_84e4dacbcaf14ea09ae9825ff2e2b9f3 (HIGH) — MFA TOTP rejeita opaco.** mfa-status mostra `lastUsedAt=null` indicando "MFA enrolled mas nunca usou com sucesso" + sugere causas comuns (clock skew, secret desync).
+
+## [2.9.12] — 2026-05-26 (fix: libuv crash MFA error path + lint guard process.exit)
+
+### Corrigido (MEDIUM — regressão libuv em MFA)
+
+- **bug_6362578edfd7498dbcfe59853181be20 (MEDIUM) — `Assertion failed: !(handle->flags & UV_HANDLE_CLOSING)` voltou em CLI 2.9.9 em error path do MFA.**
+  Reprodução: `neetru servers deactivate <id> --yes --mfa-token=<code> --json` quando o servidor retorna 403 (código MFA inválido ou expirado).
+  Causa raiz: o fix anterior (bug_818cf6d, 2.9.9) cobriu apenas `build.ts`. Os outros error paths — `handleApiError` em `cli-read.ts`, `resolveStepUp` em `cli-write.ts`, `failLookup`/`failInput` em `pickers.ts`, e todos os ~200 pontos de `process.exit()` em 46 arquivos de comando — continuavam chamando `process.exit()` direto após I/O async (fetch 403, inquirer prompts, readline MFA). Em Windows o libuv assertion é fatal.
+  Fix: sweep completo — 46 arquivos de comando + 4 arquivos de lib (`cli-read`, `cli-write`, `pickers`, `iam-preflight`) convertidos para `safeExit(N)`.
+
+### Infraestrutura de testes (guard antirregressão)
+
+- **Novo teste `src/__tests__/regressions/no-direct-process-exit.regression.test.ts`** — varre `src/commands/**/*.ts` e `src/lib/**/*.ts` e FALHA se encontrar qualquer `process.exit(` direto. Detecta regressões desta classe automaticamente em CI. Arquivos isentos: `utils/safe-exit.ts` (a implementação em si). Adição de `// safe-exit-exempt: <razão>` numa linha permite marcar exits síncronos intencionais sem quebrar o guard.
+
+## [2.9.9] — 2026-05-25 (fix: libuv crash Windows + npm ci file lock)
+
+### Corrigido (2 MEDIUM Windows compat)
+
+- **bug_818cf6d507b94c81a23b205eb9d18d71 (MEDIUM) — CLI crashava com `Assertion failed: !(handle->flags & UV_HANDLE_CLOSING)` em Windows.**
+  Causa raiz: handles libuv (http keep-alive, stdin/stdout, ora spinner setInterval) ficavam em `UV_HANDLE_CLOSING` quando `process.exit(1)` matava o loop bruscamente. Em Linux/Mac libuv só warna; em Windows é assertion fatal.
+  Fix: novo `src/utils/safe-exit.ts` com `safeExit(code): never` que faz cleanup explícito antes do exit (stopAllSpinners + destroy stdin + destroy http/https globalAgent). Build agora usa `safeExit(1)` em vez de `process.exit(1)` no catch. Spinners registrados via `registerSpinner()` (novo `src/utils/spinner-registry.ts`) pra cleanup centralizado.
+
+- **bug_93f984a16ad64656af2230583b7e554f (MEDIUM) — `neetru build` quebrava com EPERM unlink quando `next dev` rodando em paralelo.**
+  Causa raiz: `npm ci` deletava `node_modules/@next/swc-*` que o dev server tinha aberto em file lock no Windows.
+  Fix: trocado `npm ci` por `npm install --no-save --no-audit --no-fund` (respeita locks parciais). Nova flag `--no-install` permite skip total quando o dev sabe que `node_modules` está pronto. Warn explícito em Windows orientando pausar dev server.
+
+### Novidades técnicas
+
+- **`src/utils/safe-exit.ts`** — `safeExit(code): never` + `setSafeExitCode(code): void` com cleanup robusto de handles libuv.
+- **`src/utils/spinner-registry.ts`** — registry global de spinners ora pra cleanup centralizado em error paths.
+- **`neetru build --no-install`** — pula `npm install` (assume `node_modules` pronto).
+
+### Testes
+
+- `src/__tests__/safe-exit.test.ts` — 9 testes novos (spinner-registry: 6, safeExit: 3).
+
+## [2.9.7] — 2026-05-25 (fix: URI Artifact Registry completa + Cloud Build remoto + Dockerfile template — 3 CRITICAL/HIGH bugs deploy cloud-run)
+
+### Corrigido (CRITICAL/HIGH — deploy cloud-run bloqueado para gestovendas)
+
+- **bug_467db337ea9749a4b85d270d4e10576f (CRITICAL) — `neetru deploy` gerava URI Artifact Registry malformada.**
+  URI original: `us-central1-docker.pkg.dev/gestovendas:tag` (só 2 segmentos — inválida).
+  URI correta: `us-central1-docker.pkg.dev/{project}/{repo}/{image}:{tag}` (4 segmentos obrigatórios do AR).
+  Fix: `buildArtifactRegistryUri` resolve o project via `gcloud config get-value project` quando o
+  `--registry` passado contém apenas o host. O repo é inferido como `{slug}-{env}` ou explicitado via
+  `--registry-repo`. Quando `--registry` já contém `host/project/repo` (3 segmentos), é usado diretamente.
+  Suporta 3 formatos de `--registry`:
+  - Host apenas: `us-central1-docker.pkg.dev` → descobre project via gcloud config.
+  - Host + project: `us-central1-docker.pkg.dev/neetru` → infere repo.
+  - Host + project + repo: `us-central1-docker.pkg.dev/neetru/gestovendas-staging` → usa direto.
+
+- **bug_0a551e02295b42b9894f6eb6b13887b3 (CRITICAL) — `neetru deploy --target=cloud-run` exigia docker local.**
+  Docker Desktop não é viável em Windows dev machine (5+ GB, requer WSL2, reboot) nem em CI headless.
+  Fix: pipeline substituído por `gcloud builds submit --tag=<uri> [--project=<id>] <cwd>` (Cloud Build
+  remoto). Não exige Docker instalado — apenas `gcloud` autenticado (já feito via `neetru bootstrap`).
+  `--build-local` força o comportamento anterior (docker build + push) para devs que preferem build local.
+
+- **bug_1904ba55feeb480690eb8a7f00b4a7b7 (HIGH) — `--stack=node` sem Dockerfile terminava com erro pouco acionável.**
+  Fix: quando `--stack=node` ou `--stack=nextjs` e não há `Dockerfile` no projeto, o CLI gera
+  automaticamente um template adequado no `cwd` antes de chamar o Cloud Build, e apaga ao terminar.
+  Templates:
+  - `node`: `FROM node:22-slim` + `npm ci --omit=dev` + `CMD ["node", "server.js"]` + porta 8080.
+  - `nextjs`: multi-stage com standalone output + `COPY .next/standalone` + porta 8080.
+  - `docker`: continua exigindo Dockerfile manual (com mensagem de erro clara).
+  Aviso `log.warn` antes de gerar o template para o dev saber o que aconteceu.
+
+### Adicionado
+
+- **`--registry-repo <name>`** — flag opcional para especificar o nome do repositório AR explicitamente.
+  Se omitido, inferido como `{productSlug}-{env}` (ex: `gestovendas-staging`).
+- **`--build-local`** — força `docker build` local em vez do Cloud Build remoto.
+- **`--stack=nextjs`** — novo valor suportado em `neetru deploy`, gera Dockerfile Next.js standalone.
+- **`DeployOptions.json?: boolean`** — campo para propagação de modo JSON em preflight IAM checks.
+
+### Testes
+
+- `src/__tests__/deploy-image-uri.test.ts` — 10 casos cobrindo `buildArtifactRegistryUri` (segmentos, tag sanitização, REGRESSÃO original).
+- `src/__tests__/deploy-cloud-build.test.ts` — 5 casos cobrindo Cloud Build remoto vs docker local.
+- `src/__tests__/deploy-dockerfile-template.test.ts` — 7 casos cobrindo geração/limpeza de template, node/nextjs/docker, warning, existente não sobrescrito.
+
+## [2.9.6] — 2026-05-25 (fix: 3 HIGH Windows compat — bug_ec17af + 0cf14fba + 6001c5e)
+
+### Corrigido
+
+- **bug_ec17af083d7045a1a00f24255efb716c — `neetru deploy --target=cloud-run --artifact=<file>` rejeita silenciosamente.**
+  `--artifact` (tarball source) é incompatível com `target=cloud-run` que exige imagem de container OCI.
+  Adicionada verificação explícita em `runCloudRunDeploy`: quando `--artifact` ou `--artifact-url` é passado
+  com `target=cloud-run`, o CLI sai com `exit 1` e exibe mensagem orientadora com as 3 alternativas corretas:
+  `--image <uri>`, `--registry <host>` (build automático) e `--target=vm` (que aceita tarball).
+  Anteriormente a flag era silenciosamente ignorada, levando ao erro críptico "Sem imagem pra deployar".
+
+- **bug_0cf14fba40ec4352b75f3af2467e24b0 — `neetru build` quebra em Windows com scripts npm unix-only.**
+  Scripts como `NODE_ENV=production next build` usam sintaxe de variável de ambiente Unix incompatível
+  com `cmd.exe`. Adicionada função `detectsUnixEnvPrefix` em `buildNode`: quando `process.platform === 'win32'`
+  e o script `build` do `package.json` contém prefixo de env Unix (padrão `VAR=val ...`), o CLI emite
+  warning orientador antes de tentar rodar. O warning lista as 2 soluções: adicionar `cross-env` ao script,
+  ou remover o prefixo (Next.js já usa `production` por padrão em `next build`).
+  O build prossegue mesmo com o warning (shell=true no spawn já torna compatível em muitos casos).
+
+- **bug_6001c5e83c764428ae39a5d6a1f8be82 — `neetru build` falha com tar em paths com drive-letter Windows.**
+  GNU tar (MSYS2/Git Bash) interpreta `S:` como host SSH, causando "Cannot connect to S: resolve failed".
+  Correção dupla em `tarDirectory` (e `buildDocker`):
+  1. `--force-local` adicionado automaticamente quando `process.platform === 'win32'` — instrui o GNU tar
+     a não interpretar nomes de arquivo como endereços remotos (ignorado pelo bsdtar nativo do Windows 10+).
+  2. `normalizePathForTar()`: converte `S:\Documents\...` → `/S/Documents/...` antes de passar pro tar,
+     compatível com ambos os tars (GNU e BSD).
+  Workaround manual do usuário (`tar --force-local -czf ...`) agora está embutido automaticamente no CLI.
+
+## [2.9.3] — 2026-05-25 (fix HIGH: branch NoSQL no db apply — Bug 11 Fase 1)
+
+### Corrigido
+
+- **Bug 11 Fase 1 — `neetru db apply` era SQL-only; branch NoSQL nunca era alcançada.**
+  Adicionada detecção de engine em `runDbApply`: quando `engine ∈ {nosql-vm, firestore-instance}`,
+  o pipeline SQL (drizzle-kit + Postgres efêmero + classify) é completamente ignorado.
+  A nova função `runNoSqlApply` calcula o fingerprint SHA-256 do `schema.ts` local e envia
+  `POST /api/cli/v1/db/apply` com `schemaDefinition: null` (Fase 1 — sem JSON Schema export).
+  O Core registra o snapshot em `product_db_schema_snapshots/{id}` (implementado em commit `116f0d60`).
+  Saída interativa: spinner `"Aplicando schema NoSQL (sem rehearse — engine schemaless)…"`.
+  Saída `--json`: `{ ok, status, engine, snapshotId, fingerprint, dryRun }`.
+  `--dry-run` calcula fingerprint mas não envia ao Core (status `dry_run`).
+  O pipeline SQL para `cloud-sql-*` e `vm-*` permanece intacto — sem regressão.
+
+## [2.9.2] — 2026-05-25 (ux: cliente padrão Neetru automático)
+
+### Melhorado
+
+- **`neetru workspaces create` — `--customer` agora opcional para produtos Neetru-owned.**
+  Quando o produto selecionado pertence à Neetru (`ownedBy='neetru'`, `ownerTeam='Neetru Core'`
+  ou slug na lista conhecida), o CLI detecta via API e pula o prompt de cliente automaticamente.
+  Em modo interativo exibe `"Cliente omitido — produto Neetru detectado. Usando cliente interno automaticamente."`.
+  Em modo `--json`, envia `customerId` ausente; o Core injeta o customer interno (`isNeetruInternal=true`).
+  Para produtos de terceiros, `--customer` continua obrigatório (erro acionável com instruções de criação).
+
+- **`neetru tenants create` — mesma lógica de auto-default.**
+  Prompt de `customerId` pulado automaticamente quando produto é Neetru-owned.
+
+- **`neetru workspaces create` — mensagem de confirmação no output.**
+  Quando `--customer` não é fornecido, exibe `"Cliente: Neetru Tecnologia (interno) — auto-detectado pelo produto Neetru."`.
+
+## [2.9.1] — 2026-05-25 (security: 5 HIGH fixes)
+
+### Corrigido (segurança)
+
+- **HIGH-1 — `db apply --json` selecionava o primeiro banco silenciosamente com múltiplos bancos.**
+  Em modo não-interativo (`--json` ou `--yes` sem TTY), se `.neetru/db.json` tiver N > 1 bancos
+  e `--db` não for passado, o CLI agora emite erro estruturado em vez de aplicar no primeiro banco.
+  Saída JSON: `{ ok: false, error: "db_required", message: "...", available: [...] }`.
+  Em CI isso evitava migração silenciosa no banco errado.
+
+- **HIGH-2 — Abertura de URL no Windows usava `cmd /c start` sem validação de protocolo.**
+  URLs derivadas de config podiam conter caracteres de injeção de shell (`& malicious.exe`).
+  Nova função `safeOpenUrl` valida `^https?://` antes de qualquer chamada de sistema e usa
+  `rundll32 url.dll,FileProtocolHandler` (sem shell) no Windows. Aplica em `open.ts` e
+  `workspaces.ts` (que agora delega para `safeOpenUrl`).
+
+- **HIGH-3 — `db init` gravava stub local em `.neetru/db.json` antes de registrar no Core.**
+  Falha de rede/400 do Core deixava entrada órfã e re-rodar `db init` adicionava banco duplicado.
+  Agora o registro no Core acontece primeiro; `.neetru/db.json` só é escrito após sucesso.
+
+- **HIGH-4 — `marketplace sdk add <template>` aceitava path traversal.**
+  `path.join(templatesDir, templateName)` aceitava `../../etc/passwd` como nome.
+  Adicionada whitelist `ALLOWED_SDK_TEMPLATES` e verificação `startsWith(resolve(templatesDir) + sep)`
+  como defesa em profundidade.
+
+- **HIGH-5 — `docs publish` usava path absoluto Windows como slug.**
+  Path como `C:/Users/dev/projeto/docs/intro.md` virava slug `C:/Users/dev/projeto/docs/intro`,
+  expondo estrutura de filesystem. `deriveSlugFromPath` agora converte para relativo via
+  `path.relative(cwd, file)` e rejeita slugs com `:`, `..` ou `/` inicial.
+
+## [2.8.2] — 2026-05-25 (fix UX slug conflict + docs open)
+
+### Corrigido
+
+- **Bug #31 — `neetru new` não falha seco em conflito de slug.**
+  Quando o Core retorna 400 com "Já existe um produto com o slug X", o CLI
+  agora exibe o produto existente (nome, ID, status) e oferece um prompt
+  interativo com três opções:
+  1. Vincular este projeto local ao produto existente (escreve `.neetru/config.json`
+     apontando para o `productId`).
+  2. Criar com slug diferente — lista sugestões (`gestovendas-v2`, `-2`, etc.)
+     ou permite digitar um slug livre.
+  3. Cancelar.
+  Removida a mensagem "Tente manualmente: neetru products create --slug <mesmo-slug>"
+  que sugeria repetir exatamente o comando que vai falhar de novo.
+  O fallback genérico cobre qualquer 400 cujo `message` contenha "Já existe",
+  "slug", "already exists" ou "duplicate".
+
+- **Bug #26 — `neetru docs` não abria documentação ao vivo.**
+  O comando `neetru docs` era exclusivamente um registry CRUD (publish/list/get/delete)
+  e não tinha forma de acessar a documentação pública. Adicionado:
+  - `neetru docs open [topic]` — abre `https://core.neetru.com/docs` (ou seção
+    específica) no browser padrão. Tópicos: `sdk`, `cli`, `db`, `webhooks`, `auth`,
+    `billing`, `observability`, `infra`, `dns`, `deploy`, `architecture`.
+  - `neetru docs open` sem argumento — abre o índice geral.
+  - Argumentos desconhecidos abrem busca: `core.neetru.com/docs?q=<query>`.
+  - No menu interativo (`neetru ui`), "Docs live" agora exibe "Abrir documentação
+    no navegador" como primeira opção antes das opções de registry.
+
+### Notas de uso
+
+```
+neetru docs open          # abre core.neetru.com/docs
+neetru docs open sdk      # vai direto pra referência do SDK
+neetru docs open webhooks # manual de runtime/webhooks
+```
+
+## [2.8.1] — 2026-05-25 (marketplace)
+
+### Adicionado
+
+- **`neetru marketplace`** — central de artefatos do ecossistema Neetru.
+  - `neetru marketplace skills install` — clona `Neetru/neetru-libs` em
+    `~/.neetru/marketplace-cache/` e instala skills em `~/.claude/skills/`.
+    Linux/macOS: symlink (atualizações automáticas via git pull).
+    Windows: cópia recursiva (sem exigir Developer Mode).
+  - `neetru marketplace skills update` — git pull no cache + re-copia skills
+    instaladas como cópia (symlinks já são atualizados pelo pull).
+  - `neetru marketplace skills list` — tabela com nome, versão, status e
+    descrição de cada skill disponível no cache local.
+  - `neetru marketplace skills uninstall` — remove skills de `~/.claude/skills/`
+    com confirmação interativa (bypass via `--yes`).
+  - `neetru marketplace sdk init` — adiciona `@neetru/sdk@^2.1.0` ao
+    `package.json` do projeto atual e cria `src/neetru.ts` com boilerplate
+    de `createNeetruClient`. Idempotente — não sobrescreve arquivo existente.
+  - `neetru marketplace sdk templates` — lista templates disponíveis em
+    `templates/` da instalação do CLI.
+  - `neetru marketplace sdk add <template>` — copia template de feature
+    (auth/billing/usage/support/users) pra `src/` do projeto atual.
+  - `neetru marketplace browse` — abre `https://github.com/Neetru/neetru-libs`
+    no browser (start/open/xdg-open por plataforma).
+- **Menu interativo** — item **"Marketplace"** adicionado ao menu principal
+  (entre Suporte e Docs live) com sub-menu completo: skills (instalar /
+  atualizar / listar / remover) + SDK (init / add template / listar / docs)
+  + abrir no GitHub.
+
+## [2.7.5] — 2026-05-20 (fix do crash no upgrade)
+
+### Corrigido
+
+- `neetru upgrade` não crasha mais ao terminar. O comando chamava
+  `process.exit(0)` logo após o `fetch` ao npm — no Windows isso
+  derrubava o libuv com `Assertion failed: !(handle->flags &
+  UV_HANDLE_CLOSING)` (`async.c`), porque o socket do undici (fetch
+  nativo) ainda estava em teardown. Agora o comando só retorna; o event
+  loop drena sozinho (o undici dá unref nos sockets idle) e o processo
+  encerra limpo na hora.
+
+## [2.7.4] — 2026-05-20 (submenus redesenhados)
+
+### Adicionado
+
+- Submenu **"Começar um projeto"** no menu principal — reúne o scaffold
+  local (`neetru init`), a criação completa (`neetru new`) e uma tela de
+  info sobre o `@neetru/sdk` (o que é, como instalar e consumir).
+- Os 10 submenus ganharam o **mesmo visual do menu principal**: moldura
+  azul-marinho, marcador `> <` no item ativo e navegação por setas — em
+  coluna única, alinhada à esquerda.
+
+### Corrigido
+
+- Submenu não engole mais a primeira seta. O menu principal entregava o
+  stdin pausado / fora de raw mode pro submenu, e o inquirer perdia a
+  1ª tecla — só respondia depois de um toque inicial. Agora o stdin fica
+  "quente" na entrega; a seta funciona de cara.
+
+## [2.7.3] — 2026-05-20 (polish do cabeçalho)
+
+### Mudado
+
+- Cabeçalho do `neetru` interativo: logo renderizado **ao lado** do texto
+  (antes era acima), com a sessão e a versão alinhadas à direita do logo.
+- Paleta de contorno do menu e do logo ajustada para um azul mais suave.
+
+## [2.7.2] — 2026-05-20 (aviso de versão + menu em 2 colunas)
+
+### Adicionado
+
+- O cabeçalho do `neetru` interativo mostra a **versão instalada** (`v2.7.2`)
+  ao lado do usuário logado. Quando há uma versão mais nova publicada no
+  npm, aparece uma linha **amarela** avisando pra rodar `neetru upgrade`.
+  A checagem tem timeout curto e é à prova de falha — offline não trava o
+  CLI.
+- Menu principal redesenhado em **duas colunas**, com navegação por setas
+  (↑/↓/←/→) e contorno azul-marinho; o item ativo é marcado com `> <`.
+
+## [2.7.1] — 2026-05-20 (UI do CLI interativo)
+
+### Adicionado
+
+- Logo Neetru em ANSI truecolor no cabeçalho do `neetru` interativo.
+- Cabeçalho mostra o usuário logado (email), lido localmente do
+  `auth.json` — sem chamada de rede.
+- Menu principal com o nome do recurso + uma descrição curta abaixo,
+  quando útil.
+
+### Corrigido
+
+- O CLI interativo não encerra mais sozinho: comandos que chamavam
+  `process.exit()` em erro (ex.: "Nenhum server encontrado") matavam o
+  menu inteiro. Agora o erro é capturado e o CLI volta ao menu — só
+  "Sair" (ou Ctrl+C) encerra.
+
+## [2.7.0] — 2026-05-20 (Fluxo de Ambientes Fase 3 — destino cloud-run)
+
+### Adicionado
+
+- `neetru deploy --target=cloud-run` — caminho de deploy pro destino Cloud Run
+  dedicado. Aceita `--image <uri>` (imagem de container já buildada e pushada)
+  ou faz `docker build` + `docker push` automático via `--registry <host>`
+  (Artifact Registry). O destino `cloud-run` agora aparece no menu interativo.
+
+### Mudado
+
+- `neetru promote` — vocabulário de estágios migrado para `dev | staging | prod`
+  (antes `dev/workspace/beta/prod`). Gates: 24h em `dev→staging`,
+  168h + canary em `staging→prod`.
+- `neetru deploy --target` — sem valor default; omitir abre o menu interativo
+  (workspace / cloud-run / vm). Modo não-interativo continua assumindo `vm`.
+
+## [2.0.0] — 2026-05-06 (Sprint 12 — CLI estabilizada)
+
+### Adicionado
+
+- `neetru doctor` — diagnóstico completo do ambiente: token CLI, Core acessível,
+  schema do `neetru.config.json`, valor de `NEETRU_ENV`, e versão do CLI
+  comparada com a `latest` no npm. Saída em tabela colorida (default) ou
+  JSON (`--json`). Diferença pra `validate`: doctor inclui environment +
+  version mismatch (warning, não fail).
+- `neetru upgrade` — verifica `dist-tags.latest` em
+  `https://registry.npmjs.org/@neetru/cli` e exibe instrução de upgrade
+  (`npm install -g @neetru/cli@latest`). Sem auto-install — não quebra
+  pipelines pinados.
+- `neetru autocomplete <bash|zsh|pwsh>` — gera script de shell completion
+  pra os 22 subcomandos top-level. Usuário cola na config do shell:
+  `neetru autocomplete bash >> ~/.bashrc`.
+- `neetru config set telemetry.enabled <true|false>` — opt-in explícito de
+  telemetria. Default desligado. Quando ligado, CLI envia eventos
+  anonimizados pra `POST /sdk/v1/telemetry/log` (placeholder na v2.0).
+  Nunca envia tokens, paths absolutos ou conteúdo de arquivos.
+
+### Bumped
+
+- `1.4.0 → 2.0.0` (major bump por convenção de estabilidade — sem breaking
+  changes funcionais).
+
+### Não publicado no npm ainda
+
+Bump local. Publish manual pra npm fica deferido — owner aprovará. Build
+local (`npm run build` em `cli/`) gera o `dist/` pronto pra publicação.
+
+## [1.3.0] — 2026-05-06
+
+### Adicionado
+
+- `neetru add <feature>` — copia template em `cli/templates/{feature}/*` para
+  `src/lib/neetru/{feature}/*` no projeto atual. Features: `auth`, `billing`,
+  `usage`, `users`, `support`. Suporta `--force` pra sobrescrever.
+- `neetru mocks reset` — reseta `.neetru/dev-fixtures.json` para `{}` (útil
+  com `NEETRU_ENV=dev`).
+- `neetru env switch <dev|workspace|production>` — atualiza/insere
+  `NEETRU_ENV=<value>` em `.env.local` preservando as outras chaves.
+- `neetru logs` ganhou flags:
+  - `--product <productId>` — filtra logs por produto.
+  - `--channel <channel>` — filtra por channel (stdout/stderr/app/...).
+  - `--correlation-id <uuid>` — filtra por correlation ID.
+
+### Templates novos (`cli/templates/`)
+
+- `auth/sign-in.tsx`, `auth/callback.ts`
+- `billing/page.tsx`, `billing/checkout.ts`
+- `usage/track.ts`
+- `users/profile.tsx`
+- `support/ticket-form.tsx`
+
+### Não publicado no npm ainda
+
+Bump local `1.2.0 → 1.3.0`. Publish pra npm fica deferido — owner aprovará
+manualmente quando quiser. Build local (`npm run build` em `cli/`) já compila.
+
+## [1.2.0] — 2026-05-06
+
+**Consolidação das duas linhas paralelas.** Esta versão unifica os comandos das duas linhas de CLI que estavam coexistindo:
+
+- **`@neetru/cli@1.0.x` (publicada no npm)**: linha *workspace-centric* com `init`, `add`, `validate`, `generate-types`, `whoami`, `login`, `status`, `logs`, `deploy`, `open`. APIs: `/api/v1/cli/workspace/*`.
+- **`@neetru/cli@0.1.0` (monorepo, não publicada)**: linha *server-centric* com `ai`, `init`, `config`, `login`, `logout`, `whoami`, `build`, `deploy`, `publish`. APIs: `/api/v1/cli/{catalog,deploy,servers}`.
+
+As duas falam **APIs distintas e complementares** do mesmo Neetru Core, refletindo a topologia real do produto:
+
+```
+Workspace (prototipação) ──build/promote──► Server VM ou Cloud Run (produção)
+```
+
+A `1.2.0` traz ambos os conjuntos de comandos numa única CLI. O monorepo passa a ser a fonte canônica.
+
+### Adicionado em relação a `1.0.1`
+
+Comandos da linha *server-centric* (deploy via VM agent ou Cloud Run):
+
+- `neetru ai` — REPL multi-model (Claude/OpenAI/Gemini) com contexto Neetru-aware
+- `neetru build` — empacota produto local em tarball + manifest com sha256, detecção automática de stack (node/docker/php-apache/static)
+- `neetru deploy` — pipeline E2E interativo (escolha de produto/server/domain/port + polling status até estado terminal). Suporta `--non-interactive` para CI.
+- `neetru publish` — registra produto no catálogo público (`public_products`), com `--draft` e `--unpublish`
+- `neetru config {set|get|path}` — gerenciamento de chaves de API e config local
+- `neetru logout` — limpa credenciais
+- `neetru login --token nrt_<keyId>_<secret>` — modo CI/legacy paralelo ao Device Code OAuth
+- `neetru login --json` — saída machine-readable para scripts
+
+### Mantido de `1.0.1` (re-implementado em TypeScript com convenções do monorepo)
+
+- `neetru status --client-id <id>` — status de workspace (build/deploy último, domínio, tier, expira em N dias)
+- `neetru logs --client-id <id>` — visualiza logs do workspace; suporta `-f` follow + `-n N` lines + `--since 30m` + `--level error`
+- `neetru validate` — health-check da config local + ping `/api/health` + whoami
+- `neetru open [target]` — abre dashboard, builds, logs, workspaces, products, servers, incidents no browser
+- `neetru init <name>` — agora gera projeto Next.js 15 OU Node API (Fastify) com schema canônico v2
+
+### Backlog 1.3.x
+
+Comandos que ainda dependem de design/templates novos:
+
+- `neetru add <feature>` — scaffolds OAuth/billing/usage/users
+- `neetru generate-types` — codegen TypeScript de planos/features/entitlements
+
+### Alterado
+
+- Package agora é ESM nativo (`"type": "module"`). Imports usam `.js` extension.
+- `neetru login` agora usa Device Code OAuth (RFC 8628) por default; `--token` permanece para CI.
+
+### Migração de `1.0.x`
+
+Não há caminho 100% automático porque a config local muda:
+
+- `1.0.x` lia `neetru.json` workspace-local com `{clientId, coreUrl}` + var de ambiente `NEETRU_CLIENT_SECRET`
+- `1.2.0` lê `~/.config/neetru-cli/auth.json` (Bearer token salvo por `neetru login`) + `neetru.config.json` por projeto com `{slug, runtime, publish}`
+
+Recomendação:
+
+1. `npm uninstall -g @neetru/cli && npm install -g @neetru/cli@1.2.0`
+2. `neetru login` (Device Code) — gera credencial Bearer no novo formato
+3. Para comandos workspace (`status`, `logs`, `open`), passe `--client-id <oauthClientId>` explicitamente — o `clientId` continua sendo o `oauthClientId` do seu workspace, achável em UI Core `/workspaces/{id}`
+
+## [1.0.1] — anterior
+
+Linha workspace publicada no npm. Comandos: `init`, `add`, `validate`, `generate-types`, `whoami`, `login`, `status`, `logs`, `deploy`, `open`. APIs: `/api/v1/cli/workspace/*`.
+
+## [1.0.0] — anterior
+
+Primeira versão pública.
+
+## [0.1.0] — interno (não publicado)
+
+Snapshot interno do monorepo durante desenvolvimento da Sprint 1+. Substituído por `1.2.0`.