@neetru/cli 2.31.0 → 2.32.1

package/dist/lib/build-targets.d.ts

@@ -0,0 +1,127 @@
+export type PackageManagerName = 'npm' | 'pnpm' | 'yarn' | 'bun';
+export interface PackageManagerInfo {
+    name: PackageManagerName;
+    /**
+     * Diretório onde o `install` deve rodar. Em monorepo é a RAIZ do workspace
+     * (onde mora o lockfile), não o diretório do app — `pnpm install` dentro de
+     * `apps/web` sem o lockfile por perto instala um projeto solto e quebra os
+     * links dos pacotes internos do workspace.
+     */
+    rootDir: string;
+    /** De onde veio a decisão — entra no log pra o dev conseguir auditar. */
+    source: 'campo packageManager' | 'lockfile' | 'default';
+    /** Lockfile encontrado (basename), quando `source === 'lockfile'`. */
+    lockfile?: string;
+}
+/**
+ * `packageManager: "pnpm@9.1.0"` (padrão corepack) → `'pnpm'`.
+ * Qualquer coisa fora do enum conhecido devolve `null` em vez de chutar.
+ */
+export declare function parseCampoPackageManager(valor: unknown): PackageManagerName | null;
+/**
+ * Um diretório só conta como RAIZ DE WORKSPACE se ele se declara como tal.
+ *
+ * Isso é a trava contra o pior modo de falha da subida na árvore: um app em
+ * `~/projetos/meu-app` sem lockfile próprio NÃO pode herdar o
+ * `package-lock.json` que por acaso existe em `~/projetos` — instalar lá
+ * mexeria num projeto que não é o do build.
+ */
+export declare function ehRaizDeWorkspace(dir: string): boolean;
+/**
+ * Descobre QUAL gerenciador de pacote usar e ONDE rodar o `install`, partindo
+ * do diretório do app.
+ *
+ * Ordem de decisão (da mais forte pra mais fraca):
+ *   1. `packageManager` no package.json do próprio app (corepack) — é uma
+ *      declaração explícita do dono do projeto;
+ *   2. lockfile NO PRÓPRIO diretório do app (repo de app único);
+ *   3. subindo a árvore: o primeiro ancestral que tem lockfile **e** se declara
+ *      raiz de workspace (`pnpm-workspace.yaml` ou `workspaces` no package.json).
+ *      O `packageManager` desse ancestral, se houver, vence o lockfile dele;
+ *   4. nada encontrado → `npm` no próprio diretório do app (comportamento
+ *      histórico — não quebra ninguém que já usava o CLI).
+ *
+ * A subida PARA no diretório que contém `.git` (inclusive): fora do repo não
+ * existe workspace que interesse a este build.
+ */
+export declare function detectPackageManager(appDir: string): PackageManagerInfo;
+export interface Comando {
+    cmd: string;
+    args: string[];
+}
+/**
+ * `install` NÃO-DESTRUTIVO por gerenciador.
+ *
+ * bug_93f984a já tinha estabelecido a regra pro npm: nunca `npm ci` (apaga
+ * node_modules e briga com os file locks do `next dev` no Windows). A mesma
+ * regra vale pros outros — nada de `--frozen-lockfile` nem `--immutable`, que
+ * falham de cara quando o dev acabou de mexer num package.json do workspace.
+ */
+export declare function comandoInstall(pm: PackageManagerName): Comando;
+/** Roda um script do package.json (`build`, `start`, …). */
+export declare function comandoRunScript(pm: PackageManagerName, script: string): Comando;
+/**
+ * Executa um binário de `node_modules/.bin` (`next`, `vite`, `tsc`…).
+ *
+ * Usado só no caminho Windows do bug_0cf14fba/bug_893891f, onde o CLI desmonta
+ * o prefixo de env estilo Unix do script e roda o comando real direto. Com pnpm
+ * o `npx` NÃO serve: os binários ficam atrás do store de links do pnpm e o npx
+ * acabaria BAIXANDO o pacote do registry em vez de usar o local.
+ */
+export declare function comandoExecBin(pm: PackageManagerName, bin: string, args: string[]): Comando;
+export interface LayoutStandalone {
+    /** `<appDir>/.next/standalone` — sempre a RAIZ do tar. */
+    standaloneDir: string;
+    /**
+     * Caminho POSIX do app DENTRO do standalone. `''` em repo de app único;
+     * `'apps/web'` num monorepo com `outputFileTracingRoot` na raiz.
+     */
+    appPrefix: string;
+    /** Entrypoint relativo à raiz do tar: `server.js` ou `apps/web/server.js`. */
+    entrypoint: string;
+}
+/**
+ * Acha ONDE o `server.js` do Next.js ficou dentro de `.next/standalone`.
+ *
+ * Em repo de app único ele está na raiz; em monorepo o Next.js aninha o app sob
+ * o caminho dele relativo ao `outputFileTracingRoot` (`apps/web/server.js`).
+ * Não dá pra deduzir esse prefixo do `next.config` (o `outputFileTracingRoot`
+ * pode ser implícito, vindo da detecção de workspace do próprio Next.js), então
+ * a verdade é a árvore PÓS-BUILD — a mesma lógica do `isStandaloneBuildDir`.
+ *
+ * Varredura em largura, pulando `node_modules` (pacote dependente pode ter um
+ * `server.js` qualquer e envenenar a busca). Entre candidatos, ganha o que
+ * TAMBÉM tem um diretório `.next` ao lado — é o par que o Next.js sempre emite
+ * junto (`server.js` + `.next/` com os chunks de servidor). Empate real resolve
+ * pelo mais raso e, em seguida, por ordem alfabética (determinismo: dois builds
+ * da mesma árvore têm que dar o mesmo tarball).
+ *
+ * Devolve `null` quando não há standalone nenhum (build não-standalone) ou
+ * quando há standalone mas nenhum `server.js` — nesse segundo caso quem chama
+ * precisa FALHAR, nunca empacotar um tarball sem entrypoint.
+ */
+export declare function resolveStandaloneLayout(appDir: string): LayoutStandalone | null;
+/**
+ * Resolve o `-C` do `tar` que faz `.next/static` e `public` caírem DENTRO do
+ * prefixo do app no tarball.
+ *
+ * O Next.js não copia nenhum dos dois pro standalone (limitação conhecida), e o
+ * runtime os procura ao lado do `server.js` — ou seja, dentro do prefixo do app,
+ * não na raiz do tar. Era exatamente isso que saía errado em monorepo
+ * (bug_678ddc98): o tar levava `./.next/static` e `./public` na raiz enquanto o
+ * server rodava de `apps/web/`, e o app subia sem CSS/JS e sem os estáticos.
+ *
+ * O truque pra gravar o membro já aninhado SEM `--transform` (GNU) nem `-s`
+ * (bsdtar), que não são portáveis entre os dois tars: o `appPrefix` é, por
+ * construção, `path.relative(outputFileTracingRoot, appDir)` — então o mesmo
+ * caminho EXISTE no disco a partir da raiz de tracing. Basta dar `-C <raiz de
+ * tracing>` e pedir o membro `apps/web/.next/static`, que o tar grava com o
+ * caminho completo.
+ *
+ * Devolve `null` quando o prefixo não casa com o disco (não deveria acontecer —
+ * é a trava contra empacotar caminho inventado).
+ */
+export declare function baseDeInjecaoNoTar(appDir: string, appPrefix: string): {
+    chdir: string;
+    prefixo: string;
+} | null;

package/dist/lib/build-targets.js

@@ -0,0 +1,348 @@
+/**
+ * Detecção de ALVO de build — o diretório do app, o gerenciador de pacote e o
+ * layout do output `standalone` do Next.js.
+ *
+ * bug_678ddc988497475d9160d714a5a10992: o `neetru build` nasceu assumindo
+ * "um repo = um app na raiz = npm". Três premissas, todas cravadas:
+ *
+ *   1. `cwd = process.cwd()` (build.ts:905) — não dava pra apontar pra um app
+ *      dentro de `apps/<app>` sem `cd`;
+ *   2. `npm install` (build.ts:616) e `npm run build` (build.ts:664) literais —
+ *      num repo pnpm/yarn isso resolve o workspace ERRADO (ou nem resolve);
+ *   3. `tarStandalone` assumia `.next/standalone/server.js` no TOPO e injetava
+ *      `.next/static`/`public` na RAIZ do tar (build.ts:412-443), e o
+ *      entrypoint era a string fixa `'server.js'` (build.ts:673).
+ *
+ * Num monorepo (pnpm workspaces + Turborepo) o Next.js, ao tracejar a partir
+ * de `outputFileTracingRoot`, ANINHA o app dentro do standalone:
+ *
+ *   apps/web/.next/standalone/
+ *     node_modules/…            ← fica na RAIZ do standalone (tracejado/hoisted)
+ *     packages/ui/…             ← pacotes do workspace que o app importa
+ *     apps/web/server.js        ← o entrypoint REAL, aninhado
+ *     apps/web/.next/…
+ *
+ * Por isso NÃO dá pra "re-enraizar" o tar em `apps/web`: `server.js` resolve
+ * `node_modules` subindo a árvore, e esses `node_modules` moram ACIMA dele.
+ * O formato correto é preservar a árvore inteira do standalone e apontar o
+ * entrypoint pro caminho aninhado (`apps/web/server.js`), injetando
+ * `.next/static` e `public` DENTRO do prefixo do app.
+ *
+ * Este módulo é propositalmente puro (só `fs` de leitura, zero subprocesso)
+ * pra ser testável sem rodar build nenhum.
+ */
+import * as fs from 'node:fs';
+import * as path from 'node:path';
+/**
+ * Lockfiles conhecidos, em ordem de PRECEDÊNCIA dentro de um mesmo diretório.
+ *
+ * pnpm/yarn/bun vêm antes de npm de propósito: `package-lock.json` é o que mais
+ * aparece por acidente (um `npm install` distraído num repo pnpm gera um), então
+ * ele é o sinal MENOS confiável quando há concorrência. O campo `packageManager`
+ * do package.json (padrão corepack) ganha de todos — ver `detectPackageManager`.
+ */
+const LOCKFILES = [
+    { file: 'pnpm-lock.yaml', name: 'pnpm' },
+    { file: 'yarn.lock', name: 'yarn' },
+    { file: 'bun.lockb', name: 'bun' },
+    { file: 'bun.lock', name: 'bun' },
+    { file: 'package-lock.json', name: 'npm' },
+    { file: 'npm-shrinkwrap.json', name: 'npm' },
+];
+/** Teto de subida na árvore — monorepo nenhum aninha app a 12 níveis da raiz. */
+const MAX_SUBIDA = 12;
+function existe(p) {
+    try {
+        fs.statSync(p);
+        return true;
+    }
+    catch {
+        return false;
+    }
+}
+function lerJson(p) {
+    try {
+        return JSON.parse(fs.readFileSync(p, 'utf8'));
+    }
+    catch {
+        return null;
+    }
+}
+/**
+ * `packageManager: "pnpm@9.1.0"` (padrão corepack) → `'pnpm'`.
+ * Qualquer coisa fora do enum conhecido devolve `null` em vez de chutar.
+ */
+export function parseCampoPackageManager(valor) {
+    if (typeof valor !== 'string')
+        return null;
+    const nome = valor.trim().split('@')[0].toLowerCase();
+    if (nome === 'npm' || nome === 'pnpm' || nome === 'yarn' || nome === 'bun')
+        return nome;
+    return null;
+}
+/**
+ * Um diretório só conta como RAIZ DE WORKSPACE se ele se declara como tal.
+ *
+ * Isso é a trava contra o pior modo de falha da subida na árvore: um app em
+ * `~/projetos/meu-app` sem lockfile próprio NÃO pode herdar o
+ * `package-lock.json` que por acaso existe em `~/projetos` — instalar lá
+ * mexeria num projeto que não é o do build.
+ */
+export function ehRaizDeWorkspace(dir) {
+    if (existe(path.join(dir, 'pnpm-workspace.yaml')))
+        return true;
+    const pkg = lerJson(path.join(dir, 'package.json'));
+    if (!pkg)
+        return false;
+    const ws = pkg.workspaces;
+    // npm/yarn/bun aceitam `workspaces: []` OU `workspaces: { packages: [] }`.
+    if (Array.isArray(ws))
+        return true;
+    if (ws && typeof ws === 'object' && Array.isArray(ws.packages))
+        return true;
+    return false;
+}
+function lockfileDoDir(dir) {
+    for (const lf of LOCKFILES) {
+        if (existe(path.join(dir, lf.file)))
+            return lf;
+    }
+    return null;
+}
+/**
+ * Descobre QUAL gerenciador de pacote usar e ONDE rodar o `install`, partindo
+ * do diretório do app.
+ *
+ * Ordem de decisão (da mais forte pra mais fraca):
+ *   1. `packageManager` no package.json do próprio app (corepack) — é uma
+ *      declaração explícita do dono do projeto;
+ *   2. lockfile NO PRÓPRIO diretório do app (repo de app único);
+ *   3. subindo a árvore: o primeiro ancestral que tem lockfile **e** se declara
+ *      raiz de workspace (`pnpm-workspace.yaml` ou `workspaces` no package.json).
+ *      O `packageManager` desse ancestral, se houver, vence o lockfile dele;
+ *   4. nada encontrado → `npm` no próprio diretório do app (comportamento
+ *      histórico — não quebra ninguém que já usava o CLI).
+ *
+ * A subida PARA no diretório que contém `.git` (inclusive): fora do repo não
+ * existe workspace que interesse a este build.
+ */
+export function detectPackageManager(appDir) {
+    const campoLocal = parseCampoPackageManager(lerJson(path.join(appDir, 'package.json'))?.packageManager);
+    const lockLocal = lockfileDoDir(appDir);
+    // O campo local é a declaração mais explícita que existe — mas o `rootDir`
+    // ainda pode ser um ancestral (app de monorepo que declara `packageManager`
+    // e deixa o lockfile na raiz). Por isso o rootDir é resolvido à parte.
+    if (lockLocal) {
+        return {
+            name: campoLocal ?? lockLocal.name,
+            rootDir: appDir,
+            source: campoLocal ? 'campo packageManager' : 'lockfile',
+            lockfile: campoLocal ? undefined : lockLocal.file,
+        };
+    }
+    let dir = appDir;
+    for (let i = 0; i < MAX_SUBIDA; i++) {
+        const temGit = existe(path.join(dir, '.git'));
+        const pai = path.dirname(dir);
+        if (temGit || pai === dir)
+            break;
+        dir = pai;
+        const lock = lockfileDoDir(dir);
+        if (!lock) {
+            if (existe(path.join(dir, '.git')))
+                break;
+            continue;
+        }
+        // Lockfile de ancestral só vale se o ancestral É raiz de workspace — ver
+        // `ehRaizDeWorkspace` pro porquê (não sequestrar projeto vizinho).
+        if (!ehRaizDeWorkspace(dir))
+            break;
+        const campoRaiz = parseCampoPackageManager(lerJson(path.join(dir, 'package.json'))?.packageManager);
+        return {
+            name: campoLocal ?? campoRaiz ?? lock.name,
+            rootDir: dir,
+            source: campoLocal || campoRaiz ? 'campo packageManager' : 'lockfile',
+            lockfile: campoLocal || campoRaiz ? undefined : lock.file,
+        };
+    }
+    return {
+        name: campoLocal ?? 'npm',
+        rootDir: appDir,
+        source: campoLocal ? 'campo packageManager' : 'default',
+    };
+}
+/**
+ * `install` NÃO-DESTRUTIVO por gerenciador.
+ *
+ * bug_93f984a já tinha estabelecido a regra pro npm: nunca `npm ci` (apaga
+ * node_modules e briga com os file locks do `next dev` no Windows). A mesma
+ * regra vale pros outros — nada de `--frozen-lockfile` nem `--immutable`, que
+ * falham de cara quando o dev acabou de mexer num package.json do workspace.
+ */
+export function comandoInstall(pm) {
+    switch (pm) {
+        case 'pnpm':
+            return { cmd: 'pnpm', args: ['install', '--no-frozen-lockfile'] };
+        case 'yarn':
+            // Serve pro yarn classic (1.x) e pro berry — ambos aceitam `install` puro.
+            return { cmd: 'yarn', args: ['install'] };
+        case 'bun':
+            return { cmd: 'bun', args: ['install'] };
+        case 'npm':
+        default:
+            return { cmd: 'npm', args: ['install', '--no-save', '--no-audit', '--no-fund'] };
+    }
+}
+/** Roda um script do package.json (`build`, `start`, …). */
+export function comandoRunScript(pm, script) {
+    switch (pm) {
+        case 'pnpm':
+            return { cmd: 'pnpm', args: ['run', script] };
+        case 'yarn':
+            return { cmd: 'yarn', args: ['run', script] };
+        case 'bun':
+            return { cmd: 'bun', args: ['run', script] };
+        case 'npm':
+        default:
+            return { cmd: 'npm', args: ['run', script] };
+    }
+}
+/**
+ * Executa um binário de `node_modules/.bin` (`next`, `vite`, `tsc`…).
+ *
+ * Usado só no caminho Windows do bug_0cf14fba/bug_893891f, onde o CLI desmonta
+ * o prefixo de env estilo Unix do script e roda o comando real direto. Com pnpm
+ * o `npx` NÃO serve: os binários ficam atrás do store de links do pnpm e o npx
+ * acabaria BAIXANDO o pacote do registry em vez de usar o local.
+ */
+export function comandoExecBin(pm, bin, args) {
+    switch (pm) {
+        case 'pnpm':
+            return { cmd: 'pnpm', args: ['exec', bin, ...args] };
+        case 'yarn':
+            return { cmd: 'yarn', args: ['exec', bin, ...args] };
+        case 'bun':
+            return { cmd: 'bunx', args: [bin, ...args] };
+        case 'npm':
+        default:
+            return { cmd: 'npx', args: [bin, ...args] };
+    }
+}
+/** Profundidade máxima de varredura dentro do standalone à procura do server.js. */
+const MAX_PROFUNDIDADE_STANDALONE = 6;
+/**
+ * Acha ONDE o `server.js` do Next.js ficou dentro de `.next/standalone`.
+ *
+ * Em repo de app único ele está na raiz; em monorepo o Next.js aninha o app sob
+ * o caminho dele relativo ao `outputFileTracingRoot` (`apps/web/server.js`).
+ * Não dá pra deduzir esse prefixo do `next.config` (o `outputFileTracingRoot`
+ * pode ser implícito, vindo da detecção de workspace do próprio Next.js), então
+ * a verdade é a árvore PÓS-BUILD — a mesma lógica do `isStandaloneBuildDir`.
+ *
+ * Varredura em largura, pulando `node_modules` (pacote dependente pode ter um
+ * `server.js` qualquer e envenenar a busca). Entre candidatos, ganha o que
+ * TAMBÉM tem um diretório `.next` ao lado — é o par que o Next.js sempre emite
+ * junto (`server.js` + `.next/` com os chunks de servidor). Empate real resolve
+ * pelo mais raso e, em seguida, por ordem alfabética (determinismo: dois builds
+ * da mesma árvore têm que dar o mesmo tarball).
+ *
+ * Devolve `null` quando não há standalone nenhum (build não-standalone) ou
+ * quando há standalone mas nenhum `server.js` — nesse segundo caso quem chama
+ * precisa FALHAR, nunca empacotar um tarball sem entrypoint.
+ */
+export function resolveStandaloneLayout(appDir) {
+    const standaloneDir = path.join(appDir, '.next', 'standalone');
+    try {
+        if (!fs.statSync(standaloneDir).isDirectory())
+            return null;
+    }
+    catch {
+        return null;
+    }
+    const candidatos = [];
+    const fila = [
+        { dir: standaloneDir, prefix: '', profundidade: 0 },
+    ];
+    while (fila.length > 0) {
+        const atual = fila.shift();
+        let entradas;
+        try {
+            entradas = fs.readdirSync(atual.dir, { withFileTypes: true });
+        }
+        catch {
+            continue;
+        }
+        const temServer = entradas.some((e) => e.name === 'server.js' && e.isFile());
+        if (temServer) {
+            candidatos.push({
+                prefix: atual.prefix,
+                temNext: entradas.some((e) => e.name === '.next' && e.isDirectory()),
+                profundidade: atual.profundidade,
+            });
+            // Não desce mais por este ramo: achado o app, o que houver abaixo é
+            // output dele, não outro app.
+            continue;
+        }
+        if (atual.profundidade >= MAX_PROFUNDIDADE_STANDALONE)
+            continue;
+        for (const e of entradas) {
+            if (!e.isDirectory())
+                continue;
+            // `node_modules` nunca hospeda o app; `.next` abaixo da raiz é output.
+            if (e.name === 'node_modules' || e.name === '.next')
+                continue;
+            fila.push({
+                dir: path.join(atual.dir, e.name),
+                prefix: atual.prefix ? `${atual.prefix}/${e.name}` : e.name,
+                profundidade: atual.profundidade + 1,
+            });
+        }
+    }
+    if (candidatos.length === 0)
+        return null;
+    candidatos.sort((a, b) => {
+        if (a.temNext !== b.temNext)
+            return a.temNext ? -1 : 1;
+        if (a.profundidade !== b.profundidade)
+            return a.profundidade - b.profundidade;
+        return a.prefix.localeCompare(b.prefix);
+    });
+    const vencedor = candidatos[0];
+    return {
+        standaloneDir,
+        appPrefix: vencedor.prefix,
+        entrypoint: vencedor.prefix ? `${vencedor.prefix}/server.js` : 'server.js',
+    };
+}
+/**
+ * Resolve o `-C` do `tar` que faz `.next/static` e `public` caírem DENTRO do
+ * prefixo do app no tarball.
+ *
+ * O Next.js não copia nenhum dos dois pro standalone (limitação conhecida), e o
+ * runtime os procura ao lado do `server.js` — ou seja, dentro do prefixo do app,
+ * não na raiz do tar. Era exatamente isso que saía errado em monorepo
+ * (bug_678ddc98): o tar levava `./.next/static` e `./public` na raiz enquanto o
+ * server rodava de `apps/web/`, e o app subia sem CSS/JS e sem os estáticos.
+ *
+ * O truque pra gravar o membro já aninhado SEM `--transform` (GNU) nem `-s`
+ * (bsdtar), que não são portáveis entre os dois tars: o `appPrefix` é, por
+ * construção, `path.relative(outputFileTracingRoot, appDir)` — então o mesmo
+ * caminho EXISTE no disco a partir da raiz de tracing. Basta dar `-C <raiz de
+ * tracing>` e pedir o membro `apps/web/.next/static`, que o tar grava com o
+ * caminho completo.
+ *
+ * Devolve `null` quando o prefixo não casa com o disco (não deveria acontecer —
+ * é a trava contra empacotar caminho inventado).
+ */
+export function baseDeInjecaoNoTar(appDir, appPrefix) {
+    if (!appPrefix)
+        return { chdir: appDir, prefixo: '' };
+    const niveis = appPrefix.split('/').filter(Boolean);
+    const chdir = path.resolve(appDir, ...niveis.map(() => '..'));
+    // A igualdade é a prova de que `<chdir>/<appPrefix>` é o MESMO diretório que
+    // `appDir` — sem isso o tar gravaria um caminho que não existe.
+    if (path.resolve(chdir, ...niveis) !== path.resolve(appDir))
+        return null;
+    return { chdir, prefixo: `${appPrefix}/` };
+}
+//# sourceMappingURL=build-targets.js.map

package/dist/lib/cli-error.d.ts

@@ -0,0 +1,13 @@
+/**
+ * Saída do processo a partir de um `NeetruCliError` (bug_89d2497e, etapa 3).
+ *
+ * O cli-kit monta o erro (puro); aqui ele é impresso — JSON no stdout em
+ * `--json`, texto humano no stderr fora dele — e o processo sai com o código
+ * de saída DO ERRO. Ponto único: `handleApiError`, `resolveStepUp`, a validação
+ * de `--env` e o trap global de `index.ts` passam por aqui.
+ */
+import { NeetruCliError } from '../cli-kit/errors.js';
+/** Imprime o erro e devolve o código de saída — sem encerrar. */
+export declare function emitCliError(error: NeetruCliError, json?: boolean): number;
+/** Imprime o erro e encerra com o código de saída dele. Nunca retorna. */
+export declare function exitWithCliError(error: NeetruCliError, json?: boolean): never;

package/dist/lib/cli-error.js

@@ -0,0 +1,24 @@
+/**
+ * Saída do processo a partir de um `NeetruCliError` (bug_89d2497e, etapa 3).
+ *
+ * O cli-kit monta o erro (puro); aqui ele é impresso — JSON no stdout em
+ * `--json`, texto humano no stderr fora dele — e o processo sai com o código
+ * de saída DO ERRO. Ponto único: `handleApiError`, `resolveStepUp`, a validação
+ * de `--env` e o trap global de `index.ts` passam por aqui.
+ */
+import { renderCliError } from '../cli-kit/errors.js';
+import { log } from '../utils/logger.js';
+import { safeExit } from '../utils/safe-exit.js';
+/** Imprime o erro e devolve o código de saída — sem encerrar. */
+export function emitCliError(error, json) {
+    if (json)
+        console.log(JSON.stringify(error.toJSON()));
+    else
+        log.error(renderCliError(error));
+    return error.exit;
+}
+/** Imprime o erro e encerra com o código de saída dele. Nunca retorna. */
+export function exitWithCliError(error, json) {
+    return safeExit(emitCliError(error, json));
+}
+//# sourceMappingURL=cli-error.js.map

package/dist/lib/cli-write.d.ts

@@ -18,6 +18,27 @@ export declare function saveMfaSession(mfaSessionToken: string, expiresAt: strin
  * apagado junto com o Bearer token.
  */
 export declare function clearMfaSession(): Promise<void>;
+/**
+ * uid dono de um token de sessão MFA. O Core emite
+ * `<uid_base64url>.<issuedAt_hex>.<hmac_sha256_hex>` (`createCliMfaSessionToken`
+ * em `src/lib/auth-mfa-session.ts`): o uid é a parte ASSINADA, não segredo — o
+ * servidor só aceita a sessão se ele bater com o uid do Bearer. `null` se o
+ * formato não for reconhecido.
+ */
+export declare function mfaSessionOwnerUid(token: string): string | null;
+/**
+ * Descarta a sessão MFA salva quando ela não é do `uid` que acabou de logar.
+ *
+ * A8 (2026-10-13): `neetru login` com outra conta trocava o Bearer mas deixava
+ * o `mfa-session.json` da conta anterior. O Core recusa sessão de outro uid,
+ * então TODO comando destrutivo tomava 401 `mfa_required` por até 1h (e, antes
+ * do conserto da precedência em `resolveStepUp`, nem `--mfa-token` salvava).
+ * Sessão de dono desconhecido (arquivo corrompido, formato não reconhecido)
+ * também sai — o servidor recusaria do mesmo jeito. Sessão do MESMO uid fica
+ * (re-login na mesma conta não deve exigir TOTP de novo). Retorna `true` se
+ * apagou.
+ */
+export declare function discardMfaSessionOfOtherUid(uid: string): Promise<boolean>;
 export interface ConfirmOptions {
     /** `--yes` / `--force` — pula a confirmação (modo script/CI). */
     yes?: boolean;
@@ -25,6 +46,17 @@ export interface ConfirmOptions {
     /** Saída em JSON — não imprime prompt humano. */
     json?: boolean;
 }
+/**
+ * O que dizer quando a confirmação não pode ser perguntada (P105 /
+ * bug_89d2497e). Cita só as flags de confirmação que o comando EM EXECUÇÃO
+ * declara: o texto fixo "use --yes (ou --force)" chegava a 8 comandos que
+ * declaram `--yes` mas não `--force` (medido na árvore do Commander em
+ * 2026-10-18: `servers pgbouncer sync-userlist`, `products memory set`,
+ * `vm memory set`, `db move start|abort|decommission`, `promote execute`,
+ * `mobile revoke`) — quem seguisse com `--force` tomava "unknown option".
+ * Sem nenhuma das duas (ou fora do Commander, como no menu), não cita flag.
+ */
+export declare function confirmationAdvice(modo: 'json' | 'nao-interativo'): string;
 /**
  * Gate de confirmação pra operações DESTRUTIVAS (suspend, deactivate, delete,
  * rollback, archive, yank). Se `--yes`/`--force` foi passado, retorna sem
@@ -58,19 +90,21 @@ export interface StepUpOptions extends ConfirmOptions {
 }
 /**
  * Resolve o que uma operação destrutiva TOP-TIER precisa mandar pro servidor:
- *  - `headers`: `X-Neetru-MFA-Session` (sessão de 1h) OU `X-Neetru-MFA-Token`
- *    (TOTP fresco) e/ou `X-Neetru-Dry-Run`.
+ *  - `headers`: `X-Neetru-MFA-Token` (TOTP fresco) OU `X-Neetru-MFA-Session`
+ *    (sessão de 1h) e/ou `X-Neetru-Dry-Run`.
  *
  * Ordem de preferência:
  *   1. dry-run: sem MFA, só `X-Neetru-Dry-Run: true`.
- *   2. Sessão de 1h salva localmente (`~/.config/neetru-cli/mfa-session.json`):
- *      usa `X-Neetru-MFA-Session` sem pedir TOTP. Silencioso — o operador
- *      não precisa saber que a sessão está ativa.
- *   3. TOTP fresco: do flag `--mfa-token` ou prompt interativo.
- *      Em terminal não-interativo sem `--mfa-token`, encerra com instrução
- *      clara — o servidor recusaria de qualquer forma (fail-closed).
+ *   2. `--mfa-token` explícito: manda `X-Neetru-MFA-Token` — e também a sessão
+ *      salva, se houver (o Core tenta a sessão antes e não gasta o TOTP à toa).
+ *      O código NUNCA é descartado em favor da sessão (A8).
+ *   3. Sessão de 1h salva localmente: usa `X-Neetru-MFA-Session` sem pedir
+ *      TOTP. Silencioso — o operador não precisa saber que a sessão está ativa.
+ *   4. Prompt interativo do TOTP. Em `--json`/não-interativo sem código nem
+ *      sessão, encerra com instrução clara — o servidor recusaria de qualquer
+ *      forma (fail-closed).
  *
- * feature mfa-session (2026-06-12): o item 2 elimina o re-prompt TOTP a cada
+ * feature mfa-session (2026-06-12): o item 3 elimina o re-prompt TOTP a cada
  * comando destrutivo quando o operador já rodou `neetru auth mfa-session`.
  */
 export declare function resolveStepUp(opts: StepUpOptions): Promise<{