@dforce2055/dai 0.13.0 → 0.13.1

package/CHANGELOG.md

@@ -3,6 +3,47 @@
 Formato basado en [Keep a Changelog](https://keepachangelog.com/). Versionado semver
 (ver `VERSION`).
 
+## [0.13.1] — 2026-08-24
+
+**Un dev en Windows no podía pushear contra el GitLab de su empresa. `ssh -T` le autenticaba
+perfecto, `git push` moría con `Permission denied (publickey…)`. Dos días buscando el problema
+en la clave, en el token y en los permisos del server: no estaba en ninguno de los tres, y dai
+tapaba la única línea que lo decía.**
+
+Su clave tenía passphrase. En Windows conviven dos `ssh.exe` — el de OpenSSH for Windows, que
+habla con el servicio `ssh-agent`, y el que trae Git for Windows, que no lo ve. `ssh -T` usaba
+el primero (la firma la hacía el agente, passphrase nunca), `git push` usaba el segundo y pedía
+la passphrase por stderr. Ese prompt caía en un pipe de dai: el dev veía un cuelgue sin
+explicación, ssh se rendía, caía a autenticación por password y lo único legible al final era
+un error que acusa a la clave. Todo lo que hacía falta para resolverlo estaba en pantalla, y no
+llegaba.
+
+### Arreglado
+- **`dai pr` se tragaba lo que git y ssh preguntan.** El push corría con `stderr` en `pipe`
+  para no ensuciar la salida, pero git y ssh **preguntan por stderr**: la passphrase de una
+  clave, la confirmación de un host nuevo, el aviso del credential manager. Con el prompt
+  invisible el comando no se cuelga por un bug, se cuelga esperando una respuesta que nadie
+  sabe que tiene que dar. Ahora `stderr` va heredado y el push pregunta a la vista. El error de
+  git se lee en vivo, cuando todavía sirve, en vez de aparecer resumido después del fracaso.
+- **La pista al fallar el push asumía que el remoto era HTTPS.** Decía siempre *"si es la
+  primera vez contra este remoto, autenticá pusheando a mano una vez"*. Eso arregla HTTPS,
+  donde el credential manager pide la credencial la primera vez. Contra un remoto **SSH** el
+  push a mano falla exactamente igual — así que la pista mandaba a repetir un comando condenado
+  y a seguir buscando en el lugar equivocado. Ahora el consejo depende del transporte: en SSH
+  aclara que el token de `gh`/`glab` no interviene en el push, que lo que hay que mirar es la
+  clave, y deriva a `dai doctor`.
+
+### Agregado
+- **`dai doctor` — sección `forge`.** Reporta el remoto `origin` con su forge detectado y, en
+  Windows con remoto SSH, **qué `ssh.exe` va a usar git**: si es el suyo (el de Git for
+  Windows, que no llega al `ssh-agent`), lo advierte, explica el modo de falla y da el fix
+  (`git config --global core.sshCommand "C:/Windows/System32/OpenSSH/ssh.exe"`). Respeta la
+  precedencia real de git —`GIT_SSH_COMMAND` > `GIT_SSH` > `core.sshCommand`— y avisa cuando
+  una variable de entorno está pisando un `core.sshCommand` que ya estaba bien: ese caso es
+  particularmente cruel, porque el dev arregla el config, no funciona, y mirando el
+  `.gitconfig` no hay nada que ver. Fuera de Windows, o con un remoto HTTPS, no opina.
+  Núcleo puro y testeado en `cli/lib/git-ssh.mjs` (14 tests); en `dai.mjs` queda solo el I/O.
+
 ## [0.13.0] — 2026-08-21
 
 **Un dev de backend en Windows siguió el tutorial al pie de la letra y el agente se puso a
@@ -696,6 +737,7 @@ ClickUp y Jira Cloud.
 - Tests de las rutas de red (jira/clickup/forge) con `fetch` mockeado. Sin links rotos;
   `files` de npm sin tests ni secretos.
 
+[0.13.1]: https://github.com/dforce2055/dai/releases/tag/v0.13.1
 [0.13.0]: https://github.com/dforce2055/dai/releases/tag/v0.13.0
 [0.12.0]: https://github.com/dforce2055/dai/releases/tag/v0.12.0
 [0.11.0]: https://github.com/dforce2055/dai/releases/tag/v0.11.0

package/VERSION

@@ -1 +1 @@
-0.13.0
+0.13.1

package/cli/dai.mjs

@@ -28,6 +28,7 @@ import { parsePrRef, getPR, postComment, postReview } from "./lib/forge-api.mjs"
 import { trackerUrl } from "./lib/tracker-url.mjs";
 import { parseFindings, diffPositions, validateFindings, filterFindings, renderFindingBody, renderReviewSummary } from "./lib/review-findings.mjs";
 import { composePrBody, prTitle, forgeTool } from "./lib/pr.mjs";
+import { diagnoseGitSsh, pushFailureHint, WINDOWS_OPENSSH } from "./lib/git-ssh.mjs";
 import { dirsEqual } from "./lib/fsutil.mjs";
 import { parseFlags, parseAssistants, isAssistantToken, asList } from "./lib/args.mjs";
 import { versionDrift, planUpgrade, compareVersions } from "./lib/semver.mjs";
@@ -990,11 +991,21 @@ async function cmdPr(opts) {
     // stdin heredado + GIT_TERMINAL_PROMPT=1: la PRIMERA vez contra un remoto HTTPS
     // corporativo, git/credential-manager necesita poder pedir la credencial. Con stdin
     // ignorado (el default de git()) el login no completaba y el push fallaba en seco.
-    git(["push", "-u", "origin", branch], { stdio: ["inherit", "pipe", "pipe"], env: { ...process.env, GIT_TERMINAL_PROMPT: "1" } });
+    //
+    // stderr heredado, y esto no es cosmético: git y ssh PREGUNTAN por stderr. Con
+    // stderr en 'pipe' el prompt de una clave con passphrase ("Enter passphrase for
+    // key …") caía en el pipe, invisible: el dev veía un cuelgue sin explicación, ssh
+    // se rendía y terminaba cayendo a autenticación por password, y lo único que se
+    // llegaba a leer era un "Permission denied (publickey…)" que acusa a la clave
+    // cuando la clave estaba bien. Que pregunte a la vista.
+    git(["push", "-u", "origin", branch], { stdio: ["inherit", "pipe", "inherit"], env: { ...process.env, GIT_TERMINAL_PROMPT: "1" } });
   } catch (e) {
-    const err = String(e.stderr || e.message || "").trim();
+    // git ya imprimió su error en vivo (stderr heredado); acá solo va la pista, y esa
+    // pista depende del transporte: "pushea a mano una vez" arregla HTTPS y no arregla
+    // nada en SSH, donde el push a mano falla igual (lib/git-ssh.mjs).
+    const err = String(e.stderr || "").trim();
     if (err) process.stderr.write("  " + err.split("\n").join("\n  ") + "\n");
-    process.stdout.write(`  Si es la primera vez contra este remoto, autenticá pusheando a mano una vez:\n    git push -u origin ${branch}\n  y volvé a correr:  dai pr\n`);
+    for (const l of pushFailureHint(remote, branch)) process.stdout.write(`  ${l}\n`);
     fail(`no pude pushear la branch '${branch}'.`, 1);
   }
 
@@ -1728,6 +1739,44 @@ function cmdDoctor() {
       : warn("DAI_CLICKUP_LIST_ID vacío — solo hace falta para `dai publish` (crear tareas)");
   }
 
+  // ── forge: el CÓMO sale del repo por acá ─────────────────────────────────────
+  // Si el push no sale, no hay PR; sin PR no hay link QUÉ↔CÓMO. El chequeo del cliente
+  // ssh existe porque su modo de fallar miente: ver lib/git-ssh.mjs.
+  const remote = gitRemote();
+  info("forge:");
+  if (!remote) warn("no hay remoto 'origin' — `dai pr` no tiene dónde publicar la branch");
+  else {
+    const p = parseRemote(remote);
+    ok(`remoto origin: ${remote}${p ? `  (${detectForge(p.host)})` : ""}`);
+    let sshConfig = null;
+    try { sshConfig = git(["config", "--get", "core.sshCommand"]) || null; } catch { /* sin valor: git sale 1 */ }
+    const d = diagnoseGitSsh({
+      platform: process.platform,
+      remote,
+      config: sshConfig,
+      env: { GIT_SSH_COMMAND: process.env.GIT_SSH_COMMAND, GIT_SSH: process.env.GIT_SSH },
+      hasWindowsOpenSsh: existsSync(WINDOWS_OPENSSH),
+    });
+    if (d.status === "ok") ok(`git usa el OpenSSH de Windows (ve al ssh-agent)`);
+    if (d.status === "ok-por-env") {
+      ok(`git usa el OpenSSH de Windows (ve al ssh-agent)`);
+      warn(`pero viene de ${d.source}, no del config: se pierde al cerrar la terminal.`);
+      process.stdout.write(`    Para que quede:  git config --global core.sshCommand "${WINDOWS_OPENSSH}"\n`);
+    }
+    if (d.status === "bundled" || d.status === "otro-ssh") {
+      warn(d.status === "bundled"
+        ? "git usa su propio ssh (Git for Windows), que NO ve al ssh-agent de Windows."
+        : `git usa ${d.bin} (por ${d.source}), que probablemente no vea al ssh-agent de Windows.`);
+      process.stdout.write(`    Si tu clave tiene passphrase, cada push te la va a pedir — y si el prompt no llega,\n`);
+      process.stdout.write(`    ssh cae a password y falla con "Permission denied (publickey…)", que acusa a la clave.\n`);
+      if (d.fix) process.stdout.write(`    → git config --global core.sshCommand "${d.fix}"\n`);
+      if (d.shadowed) process.stdout.write(`    Ojo: ${d.source} está seteada y pisa tu core.sshCommand. Límpiala primero.\n`);
+    }
+    if (d.status === "bundled-sin-openssh") {
+      warn("git usa su propio ssh y no encontré el OpenSSH de Windows: si el push pide passphrase, instálalo (Configuración → Características opcionales → Cliente OpenSSH).");
+    }
+  }
+
   // ── version-drift del scaffold vs el CLI (ADR-0010) ──────────────────────────
   if (existsSync(join(process.cwd(), ".dai", "VERSION"))) { info("versión del scaffold:"); reportDrift(); }
 }

package/cli/lib/git-ssh.mjs

@@ -0,0 +1,107 @@
+// dai · qué cliente SSH usa git, y si ese cliente llega al agente (Windows).
+//
+// En Windows conviven dos ssh.exe: el de OpenSSH for Windows (C:\Windows\System32\
+// OpenSSH), que habla con el servicio `ssh-agent`, y el que trae Git for Windows
+// (MSYS), que NO lo ve. Con una clave con passphrase el síntoma es desconcertante:
+// `ssh -T` autentica (la firma la hace el agente) y `git push` pide la passphrase o,
+// si nadie la contesta, cae a autenticación por password y muere con
+// "Permission denied (publickey…)" — un error que apunta al lugar equivocado y se
+// come una mañana buscando el problema en la clave, en el token o en el server.
+//
+// Núcleo puro: el I/O (git config, existsSync) vive en dai.mjs.
+
+export const WINDOWS_OPENSSH = "C:/Windows/System32/OpenSSH/ssh.exe";
+
+// ¿Por dónde habla el remoto? Decide qué consejo tiene sentido cuando el push falla.
+export function remoteTransport(remote) {
+  const r = String(remote ?? "").trim();
+  if (!r) return null;
+  if (/^ssh:\/\//i.test(r)) return "ssh";
+  if (/^https?:\/\//i.test(r)) return "https";
+  if (/^[\w.-]+@[^:]+:/.test(r)) return "ssh";   // scp-like: git@host:org/repo.git
+  return null;                                    // git://, file://, ruta local…
+}
+
+// El binario de un core.sshCommand / GIT_SSH_COMMAND, que puede traer argumentos y
+// comillas:  `"C:/Program Files/Git/usr/bin/ssh.exe" -v`  →  la ruta sola.
+export function sshBinaryOf(cmd) {
+  const s = String(cmd ?? "").trim();
+  if (!s) return null;
+  if (s[0] === '"' || s[0] === "'") {
+    const end = s.indexOf(s[0], 1);
+    return end === -1 ? s.slice(1) : s.slice(1, end);
+  }
+  const sp = s.search(/\s/);
+  return sp === -1 ? s : s.slice(0, sp);
+}
+
+// ¿Esa ruta es el OpenSSH de Windows? Normalizado: mayúsculas y `\` vs `/` varían
+// según quién haya escrito el config (git acepta las dos formas).
+export function isWindowsOpenSsh(bin) {
+  const p = String(bin ?? "").replace(/\\/g, "/").toLowerCase();
+  return /(^|\/)system32\/openssh\/ssh(\.exe)?$/.test(p);
+}
+
+// Diagnóstico del cliente ssh que va a usar git. Entradas ya resueltas por el
+// llamador; acá no se toca el disco ni se lanza un proceso.
+//   platform          — process.platform
+//   remote            — url de origin (o null)
+//   config            — `git config --get core.sshCommand` (o null si no está)
+//   env               — { GIT_SSH_COMMAND, GIT_SSH }
+//   hasWindowsOpenSsh — existsSync(WINDOWS_OPENSSH)
+//
+// status:
+//   n/a               → no aplica (no es Windows, o el remoto no habla SSH)
+//   ok                → apunta al OpenSSH de Windows por core.sshCommand
+//   ok-por-env        → apunta bien, pero desde una env var: se pierde al cerrar la terminal
+//   otro-ssh          → apunta a otro ssh (el de MSYS, plink…)
+//   bundled           → nadie lo configuró: git usa el suyo, que no ve el agente
+//   bundled-sin-openssh → igual, pero no hay OpenSSH de Windows que recomendar
+export function diagnoseGitSsh({ platform, remote, config, env = {}, hasWindowsOpenSsh = false } = {}) {
+  if (platform !== "win32") return { status: "n/a", reason: "no-windows" };
+  const transport = remoteTransport(remote);
+  if (transport !== "ssh") return { status: "n/a", reason: transport ? "remoto-https" : "sin-remoto" };
+
+  // Precedencia real de git: GIT_SSH_COMMAND > GIT_SSH > core.sshCommand.
+  const [source, raw] =
+    env.GIT_SSH_COMMAND ? ["GIT_SSH_COMMAND", env.GIT_SSH_COMMAND]
+    : env.GIT_SSH ? ["GIT_SSH", env.GIT_SSH]
+    : config ? ["core.sshCommand", config]
+    : ["default", null];
+
+  // Una env var pisando un core.sshCommand que ya estaba bien: el dev "arregló" el
+  // config, no funciona, y no hay forma de verlo mirando el .gitconfig.
+  const shadowed = source !== "default" && source !== "core.sshCommand" && Boolean(config);
+
+  if (source === "default") {
+    return hasWindowsOpenSsh
+      ? { status: "bundled", source, bin: null, fix: WINDOWS_OPENSSH, shadowed }
+      : { status: "bundled-sin-openssh", source, bin: null, fix: null, shadowed };
+  }
+
+  const bin = sshBinaryOf(raw);
+  if (isWindowsOpenSsh(bin)) {
+    return { status: source === "core.sshCommand" ? "ok" : "ok-por-env", source, bin, fix: null, shadowed };
+  }
+  return { status: "otro-ssh", source, bin, fix: hasWindowsOpenSsh ? WINDOWS_OPENSSH : null, shadowed };
+}
+
+// Qué decirle al dev cuando `git push` falla. El consejo de "pusheá a mano una vez"
+// solo aplica a HTTPS, donde el credential manager pide la credencial la primera vez;
+// contra un remoto SSH el push a mano falla EXACTAMENTE igual, así que mandarlo por ahí
+// es hacerle perder el tiempo mientras el problema real (la clave, el agente) sigue ahí.
+export function pushFailureHint(remote, branch) {
+  if (remoteTransport(remote) === "ssh") {
+    return [
+      `El remoto habla SSH: en el push no interviene el token de gh/glab, solo tu clave.`,
+      `Prueba a mano — así ves lo que ssh pregunta (p. ej. la passphrase de tu clave):`,
+      `  git push -u origin ${branch}`,
+      `Si te la pide en cada push, tu clave está en un agente que git no ve:  dai doctor`,
+    ];
+  }
+  return [
+    `Si es la primera vez contra este remoto, autentica pusheando a mano una vez:`,
+    `  git push -u origin ${branch}`,
+    `y vuelve a ejecutar:  dai pr`,
+  ];
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dforce2055/dai",
-  "version": "0.13.0",
+  "version": "0.13.1",
   "description": "Metodología de desarrollo asistido por IA — CLI de acciones deterministas (trazabilidad QUÉ↔CÓMO).",
   "repository": { "type": "git", "url": "git+https://github.com/dforce2055/dai.git" },
   "homepage": "https://dforce2055.github.io/dai/",