@neetru/cli 2.33.0 → 2.34.0

package/dist/commands/db.js

@@ -1370,7 +1370,9 @@ function restoreFail(json, error, message) {
  *   1. Lista backups disponíveis via GET /api/cli/v1/db/[id]/backups
  *   2. Operador escolhe qual backup restaurar
  *   3. Exige confirmação textual "RESTAURAR" (operação destrutiva)
- *   4. POST /api/cli/v1/db/[id]/restore com MFA step-up
+ *   4. POST /api/cli/v1/db/[id]/restore com MFA step-up (`resolveStepUp`:
+ *      `--mfa-token` → sessão de 1h → pergunta do TOTP; sem nenhum dos três em
+ *      `--json`/sem terminal, falha fechada com `mfa_required`)
  *
  * Automação / --json (auditoria UX 2026-09): o restore precisa ser scriptável.
  *   - `--backup-id <id>` pula o prompt de seleção (validado contra a lista).
@@ -1388,10 +1390,6 @@ export async function runDbRestore(dbId, opts) {
         restoreFail(opts.json, 'invalid_input', '<dbId> é obrigatório.');
         return;
     }
-    if (!opts.mfa) {
-        restoreFail(opts.json, 'mfa_required', '--mfa-token <token> é obrigatório para restaurar banco (operação destrutiva).');
-        return;
-    }
     // Fail-CLOSED em --json: sem TTY pra escolher backup ou digitar a confirmação,
     // então exige --backup-id e --yes explícitos (pula o inquirer, nunca trava).
     if (opts.json && !opts.backupId) {
@@ -1471,6 +1469,15 @@ export async function runDbRestore(dbId, opts) {
         }
     }
     // 4. POST restore com MFA step-up.
+    //
+    // bug_757b9746: o restore exigia `--mfa-token` logo na entrada e montava
+    // `X-Neetru-MFA-Token` à mão — com a sessão de 1h de `neetru auth mfa-session`
+    // ativa, recusava do mesmo jeito, embora a rota do Core
+    // (`requireCliStepUpMfa`) aceite `X-Neetru-MFA-Session`. Era o último comando
+    // destrutivo fora do `resolveStepUp`. Resolvido AQUI, depois da escolha e da
+    // confirmação e antes do spinner: o TOTP perguntado não vence no meio, quem
+    // cancela não gasta código e a pergunta não disputa a linha com o spinner.
+    const { headers: mfaHeaders } = await resolveStepUp({ mfaToken: opts.mfa, json: opts.json });
     const spinnerRestore = opts.json
         ? null
         : ora({ text: 'Disparando restore…', color: 'yellow' }).start();
@@ -1478,7 +1485,7 @@ export async function runDbRestore(dbId, opts) {
     try {
         resp = await apiRequest(`/api/cli/v1/db/${encodeURIComponent(dbId)}/restore`, {
             method: 'POST',
-            headers: { 'X-Neetru-MFA-Token': opts.mfa },
+            headers: mfaHeaders,
             body: { backupId, dbId },
         });
         spinnerRestore?.succeed(`Restore iniciado — job ${chalk.bold(resp.jobId ?? '—')} · status: ${resp.status}`);

package/dist/commands/deploy.d.ts

@@ -84,6 +84,8 @@ export interface DeployOptions {
      * HTTP de saúde pós-deploy (`GET https://<domain>/api/health?deep=1`). Default
      * SEMPRE false — o probe roda por padrão. Use apenas em casos legítimos sem
      * superfície HTTP (ex.: deploy de um serviço/worker sem endpoint web).
+     * Pula também a conferência da página inicial (bug_0d2e0087), que só roda
+     * depois de a saúde passar.
      */
     skipHealthProbe?: boolean;
     /**
@@ -170,9 +172,16 @@ export declare function runPublicSecretGate(source: {
  * 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.
+ * Do lado do Core o campo chega: desde o d6cfda64 (2026-10-11) o
+ * `deployRequestSchema` declara `entrypoint` e o `entrypointToStartCommand` o
+ * traduz para o `startCommand` do agente (`node apps/web/server.js`).
+ *
+ * O que ainda NÃO fecha é do agente (medido na main dele, 1.6.80): a decisão de
+ * instalar dependências (`resolveNodeInstallPlan` em `deploy-plan.ts`) também
+ * olha só a raiz do pacote. Sem `server.js` nem `.next/` na raiz, o pacote de
+ * monorepo não é reconhecido como standalone e o agente roda `npm rebuild` (e,
+ * se falhar, `npm install`) na raiz do pacote, em vez de pular a instalação.
+ * O conserto é no `neetru-agent-service-vm` (bug_bc72fe7e).
  */
 export declare function entrypointParaDeploy(manifest: Pick<BuildManifest, 'entrypoint' | 'appPrefix' | 'stack'> | null | undefined): string | undefined;
 /** `true` pra `prod`/`production` (o Core normaliza `production`→`prod`). */
@@ -262,8 +271,8 @@ export declare const SECRET_ENVVAR_PATTERNS: RegExp[];
 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.
+ * Core reserva a chave — aí a nota de como o segredo registrado chega ao app
+ * (`notaSegredoDescartadoNoDeploy`) 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'>;