@neetru/cli 2.29.0 → 2.32.0

package/dist/commands/deploy.d.ts

@@ -1,3 +1,6 @@
+import { type RuntimeEnvironmentId } from '../lib/envs.js';
+import { type BuildManifest } from './build.js';
+import { type PublicSecretOverrideRecord } from '../lib/public-secret-scan.js';
 /**
  * bug_a5786e03 (2026-05-31): o Core/agente só conhecem os stacks canônicos
  * `node|docker|php-apache|static` (PRODUCT_STACKS). `nextjs` é um alias de
@@ -88,29 +91,136 @@ export interface DeployOptions {
      * pra prod (auditoria cli/v1 2026-09-29, M7). Ignorado em dev/staging.
      */
     mfaToken?: string;
+    /**
+     * 2.30.0 — `--allow-public-secret "<motivo>"`: override de EMERGÊNCIA da
+     * varredura de segredo no pacote público. Motivo obrigatório (≥10 chars);
+     * fica registrado no deploy (`publicSecretOverride` no corpo enviado ao Core
+     * e na saída --json) — só caminho + tipo de padrão, nunca o valor.
+     */
+    allowPublicSecret?: string;
+    /**
+     * Protocolo de docs de produto v1: pula a checagem dos docs (que só avisa)
+     * e a publicação automática no fim do deploy de produção (`docs.publishOnDeploy`).
+     */
+    semDocs?: boolean;
 }
+/** Resultado da varredura de segredo, anexado ao deploy. */
+export interface PublicSecretGateResult {
+    /** `false` quando não deu pra varrer (artefato remoto / imagem pronta). */
+    scanned: boolean;
+    scannedFiles?: number;
+    reason?: string;
+    override?: PublicSecretOverrideRecord;
+}
+/**
+ * Valida o motivo do `--allow-public-secret` ANTES de qualquer build/upload.
+ * `undefined` = flag não passada.
+ */
+export declare function validateAllowPublicSecretReason(raw: string | undefined, json?: boolean): string | undefined;
+/**
+ * 2.30.0 — gate de segredo no pacote PÚBLICO (decisão do dono 2026-10-03: a
+ * credencial nrt_ é SÓ DE SERVIDOR). Roda ANTES do upload. Achou → falha
+ * FECHADO (exit 1, `public_secret_in_bundle`), a não ser que haja override com
+ * motivo — aí segue com aviso alto e devolve o registro pro corpo do deploy.
+ */
+export declare function runPublicSecretGate(source: {
+    kind: 'tar';
+    path: string;
+} | {
+    kind: 'dir';
+    root: string;
+}, ctx: {
+    cwd: string;
+    envFile?: string;
+    stack?: string;
+    allowReason?: string;
+    json?: boolean;
+}): Promise<PublicSecretGateResult>;
+/**
+ * bug_678ddc98 (elo que faltava): decide se este deploy precisa DIZER ao Core
+ * qual é o entrypoint, em vez de deixar o agente adivinhar.
+ *
+ * O #68 ensinou o `neetru build` a empacotar monorepo e a calcular o entrypoint
+ * aninhado (`apps/web/server.js`), mas a cadeia parava no `manifest.json`:
+ * `manifest.entrypoint` nunca foi lido por ninguém — era campo write-only.
+ * Num monorepo o tarball fica assim:
+ *
+ *   <versionDir>/node_modules/…        ← tracejado, na RAIZ
+ *   <versionDir>/packages/ui/…         ← pacotes internos do workspace
+ *   <versionDir>/apps/web/server.js    ← entrypoint REAL
+ *   <versionDir>/apps/web/package.json ← o package.json DO APP mora aqui
+ *
+ * O agente (`neetru-agent-service-vm/src/lib/deploy-plan.ts:117-124`) infere o
+ * comando de start olhando SÓ a raiz do versionDir: `server.js` na raiz,
+ * `.next/` na raiz, `.next/standalone/server.js`, e `scripts.start` do
+ * `package.json` da raiz. Em monorepo os três primeiros não existem, e o
+ * quarto não ajuda: o Next.js escreve o package.json do app em
+ * `<appPrefix>/package.json` (`next/dist/build/utils.js:1197`), então o que
+ * houver na raiz é o package.json do WORKSPACE — que ou não tem `start`, ou
+ * tem um `start` de ferramenta de monorepo (`turbo start`), nunca
+ * `node apps/web/server.js`. Nos dois casos o agente erra: cai no fallback
+ * `'npm start'` (deploy-plan.ts:124) e o systemd entra em crash-loop.
+ *
+ * REGRA: só mandamos o entrypoint quando o agente NÃO consegue acertar sozinho,
+ * isto é quando o standalone está aninhado (`appPrefix` preenchido). Para app
+ * único o agente já resolve certo — e mandar `pkg.main`/`index.js` ali
+ * ATROPELARIA o `npm start` de produtos como o gestovendas, que dependem de
+ * `scripts.start`. Conserto que quebra o caso que funcionava não é conserto.
+ *
+ * Também não mandamos para stack não-node: ali `entrypoint` é `index.html` /
+ * `index.php` / referência de imagem, que não é "arquivo para o `node` rodar".
+ *
+ * ATENÇÃO — a cadeia ainda NÃO fecha só com isto: o Core descarta o campo hoje
+ * (`deployRequestSchema` não o declara, e objeto zod sem `.passthrough()` remove
+ * chave desconhecida em silêncio). Ver "o que falta no Core" na descrição do PR.
+ */
+export declare function entrypointParaDeploy(manifest: Pick<BuildManifest, 'entrypoint' | 'appPrefix' | 'stack'> | null | undefined): string | undefined;
 /** `true` pra `prod`/`production` (o Core normaliza `production`→`prod`). */
 export declare function isProdEnv(envName: string | undefined): boolean;
 /**
  * M7 (auditoria cli/v1 2026-09-29): `POST /api/cli/v1/deploy` com
  * `environmentId` prod exige step-up MFA no Core (mesmo gate de `promote`).
- * Resolve os headers (sessão 1h → --mfa-token → prompt TOTP; fail-closed em
+ * Resolve os headers (--mfa-token → sessão 1h → prompt TOTP; fail-closed em
  * --json/--non-interactive/sem TTY) só quando o alvo é prod. Chamado logo
  * antes do POST — depois do build/upload — pra o TOTP não vencer no meio.
  */
 export declare function resolveDeployStepUpHeaders(opts: Pick<DeployOptions, 'mfaToken' | 'json'>, envName: string, nonInteractive: boolean): Promise<Record<string, string>>;
+/**
+ * Mostra os `warnings[]` que o Core devolve no deploy.
+ *
+ * Medido em 2026-10-12: o Core devolve `warnings` nos TRES alvos e o comentario
+ * dele diz, literalmente, "`warnings[]` na resposta JSON (o CLI exibe pro
+ * operador)" (`cli/v1/deploy/route.ts:309`). `grep warnings` em `deploy.ts`
+ * devolvia ZERO — a promessa nunca foi cumprida.
+ *
+ * O caso que mais doia: a CLI manda o ambiente default e o Core normaliza, e o
+ * aviso de que `environmentId` foi ASSUMIDO disparava em todo deploy sem
+ * `--env` — e sumia 100% das vezes. O operador achava que tinha escolhido.
+ *
+ * Vai pro STDERR de proposito: em `--json` o stdout e contrato de maquina (uma
+ * linha JSON) e nao pode ser poluido. Quem le JSON ja recebe `warnings` no
+ * proprio corpo.
+ */
+export declare function mostrarAvisosDoCore(warnings: unknown, json?: boolean): void;
+/**
+ * `--env` do deploy workspace/cloud-run: fora do vocabulário, encerra com exit
+ * 1 e os valores válidos da MESMA lista que validou (`invalid_env`, com `flag`,
+ * `value` e `valid` no JSON). Exportada para teste.
+ */
+export declare function validarAmbienteDoDeploy(envName: string, json: boolean | undefined): void;
 /**
  * Mapeia o `envName` do deploy ('dev' | 'staging' | 'prod' — vocabulário do
  * `--env` deste comando) pro `targetEnv` que `neetru build` entende
  * ('dev' | 'workspace' | 'prod' — vocabulário de `BuildOptions`/SDK).
  * 'staging' vira 'workspace' (mesmo conceito de ambiente não-dev/não-prod).
  * Valor desconhecido cai em 'prod' (mesmo default conservador de `runBuild`).
+ * P105: a correspondência sai de `VOCABULARIOS_DE_AMBIENTE`, não de `if`s.
  *
  * Fix (2026-07-22, achado da revisão adversarial): sem isso, todo build
  * implícito de `neetru deploy --env dev`/`--env staging` (quando não há
  * artifact em cache) forçava NEXT_PUBLIC_NEETRU_ENV=prod incondicionalmente.
  */
-export declare function deployEnvToBuildTargetEnv(envName: string): 'dev' | 'workspace' | 'prod';
+export declare function deployEnvToBuildTargetEnv(envName: string): RuntimeEnvironmentId;
 /**
  * bug_5b6bb0d7 — segredos NÃO podem viajar por env no deploy.
  *
@@ -133,6 +243,30 @@ export declare function deployEnvToBuildTargetEnv(envName: string): 'dev' | 'wor
  * saírem de sincronia, mas exige atualização manual dos dois lados.
  */
 export declare const SECRET_ENVVAR_PATTERNS: RegExp[];
+/**
+ * Aviso do segredo descartado no `--env-file` de um deploy VM.
+ *
+ * bug_8b85353b (Parte 3): até aqui a mensagem mandava "usar o Secret Manager e
+ * referenciar por nome na VM" — mecanismo que NÃO existia para segredo do
+ * próprio produto (era a 4ª cópia do padrão que o core#632 corrigiu nas outras
+ * três). O caminho real é `neetru secrets set`, que grava no registro
+ * `product_secrets` do Core com o valor direto no Secret Manager. `env` é o
+ * `--env` do deploy, para o comando sugerido já sair com o ambiente certo.
+ *
+ * Revisão do #81 (M1): o comando só é sugerido quando o Core o aceitaria.
+ * Chave reservada (o Core já a entrega ao app: credencial SDK/OIDC/CLI,
+ * módulo, unit) é recusada em `assertValidProductSecretKey`, e nome fora de
+ * CAIXA_ALTA é recusado pela própria CLI (`problemaNaChave`) — sugerir
+ * `neetru secrets set` nesses casos mandava o dev para um caminho que falha.
+ */
+export declare function avisoSegredoDescartadoNaVm(chave: string, env: string | undefined): string;
+/**
+ * O aviso desta chave manda para `neetru secrets set`? Não manda quando o
+ * Core reserva a chave — aí o aviso de que o agente ainda não entrega
+ * segredos do produto também não cabe.
+ */
+export declare function segredoDescartadoApontaSecretsSet(chave: string): boolean;
+export declare function pickTarget(opts: DeployOptions, nonInteractive: boolean, runtime?: string): Promise<'cloud-run' | 'vm' | 'workspace'>;
 /** Verdicts de uma tentativa de probe. Só `healthy` é terminal-sucesso. */
 export type HealthProbeVerdict = 'healthy' | 'degraded' | 'warming' | 'unreachable' | 'unverifiable';
 export interface HealthProbeAttempt {