@dforce2055/dai 0.7.0 → 0.8.0

package/cli/lib/http.mjs

@@ -0,0 +1,61 @@
+// dai · fetch con diagnóstico de TLS (cero dependencias).
+//
+// En una red corporativa el proxy suele interceptar TLS con una CA propia. Node NO usa
+// el trust store del sistema (trae su propia lista de CAs), así que falla justo donde el
+// navegador anda — y el error crudo de undici no dice nada de eso.
+//
+// El fix es DECLARAR la CA (NODE_EXTRA_CA_CERTS), nunca apagar la verificación:
+// NODE_TLS_REJECT_UNAUTHORIZED=0 hace que la conexión acepte CUALQUIER certificado, y
+// por acá viajan los tokens del tracker. Este módulo existe para que el que se topa con
+// el muro encuentre el camino correcto antes que el atajo peligroso.
+
+const TLS_CODES = new Set([
+  "UNABLE_TO_VERIFY_LEAF_SIGNATURE",
+  "UNABLE_TO_GET_ISSUER_CERT_LOCALLY",
+  "SELF_SIGNED_CERT_IN_CHAIN",
+  "DEPTH_ZERO_SELF_SIGNED_CERT",
+  "CERT_HAS_EXPIRED",
+  "ERR_TLS_CERT_ALTNAME_INVALID",
+]);
+
+// Extrae el código de error TLS de un fallo de fetch, o null si no es de TLS.
+// undici anida el error real en `cause` (a veces dos niveles).
+export function tlsErrorCode(e) {
+  for (let cur = e, depth = 0; cur && depth < 4; cur = cur.cause, depth++) {
+    const code = cur.code;
+    if (code && TLS_CODES.has(code)) return code;
+  }
+  return null;
+}
+
+export function tlsHint(host, code) {
+  return [
+    `no pude verificar el certificado TLS de ${host} (${code}).`,
+    "",
+    "  Casi siempre es un proxy corporativo que intercepta TLS con su propia CA. Node no",
+    "  usa el trust store de Windows/macOS, por eso el navegador anda y dai no.",
+    "",
+    "  Solución: exportá la CA raíz de tu empresa a un .pem y declarásela a Node:",
+    "    Windows (PowerShell):  $env:NODE_EXTRA_CA_CERTS=\"C:\\ruta\\ca-empresa.pem\"",
+    "    macOS / Linux:         export NODE_EXTRA_CA_CERTS=/ruta/ca-empresa.pem",
+    "",
+    "  NO uses NODE_TLS_REJECT_UNAUTHORIZED=0. Eso no arregla nada: apaga la verificación",
+    "  entera, y tu token del tracker viajaría aceptando cualquier certificado — incluido",
+    "  el de alguien haciéndose pasar por el tracker.",
+  ].join("\n");
+}
+
+// fetch, pero traduciendo el fallo de TLS a un error accionable.
+export async function daiFetch(url, init) {
+  try {
+    return await fetch(url, init);
+  } catch (e) {
+    const code = tlsErrorCode(e);
+    if (!code) throw e;
+    let host = String(url);
+    try { host = new URL(url).host; } catch { /* url rara: mostramos lo que vino */ }
+    const err = new Error(tlsHint(host, code));
+    err.cause = e;
+    throw err;
+  }
+}

package/cli/lib/jira-fields.mjs

@@ -0,0 +1,143 @@
+// dai · campos obligatorios propios de Jira, declarados por issuetype (cero dependencias).
+//
+// El Jira de una empresa casi siempre exige campos propios (customfield_NNNNN) que el
+// alta de un issue rechaza si faltan. Y su valor no es config fija: "Clasificación" es
+// Mejora o Corrección SEGÚN LA US. Un default fijo publicaría todas iguales — un dato
+// incorrecto en Jira, en silencio, que es peor que fallar.
+//
+// Así que se declaran acá, con nombre humano, forma y opciones válidas, y dai valida
+// ANTES de llamar a la API: un typo da un error local con la lista, no un 400 críptico.
+//
+// .dai/jira-fields.json:
+//   {
+//     "Story": {
+//       "clasificacion": {
+//         "field":   "customfield_10042",   // el id de Jira (requerido)
+//         "shape":   "select",              // opcional — ver SHAPES
+//         "default": "Mejora",           // opcional — si falta, --field es obligatorio
+//         "options": ["Mejora", "Corrección"]   // opcional — si está, dai valida contra ella
+//       }
+//     },
+//     "Epic": { … }
+//   }
+//
+// Un campo DECLARADO tiene que resolver a un valor (default o --field): se declara porque
+// Jira lo exige. Si es opcional, no lo declares.
+
+// Cómo se envuelve el valor para la API de Jira:
+//   select → { "value": X }        el caso típico de un desplegable
+//   text   → X                     texto plano
+//   multi  → [{ "value": X }, …]   lista (el valor se parte por comas)
+//   raw    → JSON.parse(X)         escape hatch: cualquier forma que Jira pida
+const SHAPES = new Set(["select", "text", "multi", "raw"]);
+
+// JSON no admite comentarios, y este archivo lo edita gente que no escribe código. Las
+// claves que empiezan con "_" son notas y se ignoran — así el molde se explica solo.
+const isNote = (k) => k.startsWith("_");
+
+// Si no se declara `shape`: con options es un desplegable; sin options, texto.
+const shapeOf = (def) => def.shape || (Array.isArray(def.options) ? "select" : "text");
+
+const optionsHint = (def) => (Array.isArray(def.options) && def.options.length ? `\n  válidas: ${def.options.join(" | ")}` : "");
+
+// Valida la estructura del archivo y lo devuelve. Los errores nombran la ruta exacta
+// (`Story.clasificacion`) para que se arregle sin adivinar.
+export function parseFieldsFile(text, path = ".dai/jira-fields.json") {
+  let json;
+  try { json = JSON.parse(text); }
+  catch (e) { throw new Error(`${path} no es JSON válido: ${e.message}`); }
+  if (json === null || typeof json !== "object" || Array.isArray(json)) {
+    throw new Error(`${path}: se espera un objeto { "<issuetype>": { "<alias>": {…} } }`);
+  }
+  for (const [type, entry] of Object.entries(json)) {
+    if (isNote(type)) continue;    // JSON no tiene comentarios: las claves _x son notas
+    if (entry === null || typeof entry !== "object" || Array.isArray(entry)) {
+      throw new Error(`${path}: '${type}' tiene que ser un objeto de campos`);
+    }
+    for (const [alias, def] of Object.entries(entry)) {
+      if (isNote(alias)) continue;
+      const at = `${path}: ${type}.${alias}`;
+      if (def === null || typeof def !== "object" || Array.isArray(def)) throw new Error(`${at} tiene que ser un objeto`);
+      if (typeof def.field !== "string" || !def.field.trim()) {
+        throw new Error(`${at}: falta 'field' (el id de Jira, p. ej. "customfield_10042")`);
+      }
+      if (def.shape !== undefined && !SHAPES.has(def.shape)) {
+        throw new Error(`${at}: shape '${def.shape}' desconocido (${[...SHAPES].join(" | ")})`);
+      }
+      if (def.options !== undefined && !Array.isArray(def.options)) {
+        throw new Error(`${at}: 'options' tiene que ser una lista`);
+      }
+    }
+  }
+  return json;
+}
+
+// `--field alias=valor` (repetible) → { alias: "valor" }.
+export function parseFieldOverrides(input) {
+  const list = input === undefined ? [] : Array.isArray(input) ? input : [input];
+  const out = {};
+  for (const raw of list) {
+    if (typeof raw !== "string") throw new Error("--field espera 'alias=valor'");
+    const i = raw.indexOf("=");
+    if (i <= 0) throw new Error(`--field espera 'alias=valor' (recibí: '${raw}')`);
+    out[raw.slice(0, i).trim()] = raw.slice(i + 1);
+  }
+  return out;
+}
+
+// Los campos declarados para un issuetype. Exacto primero, después sin distinguir
+// mayúsculas ("story" encuentra "Story"), y {} si no hay nada declarado.
+function specFor(spec, issuetype) {
+  if (!spec || typeof spec !== "object") return {};
+  const lower = String(issuetype).toLowerCase();
+  const hit = Object.keys(spec).find((k) => !isNote(k) && (k === issuetype || k.toLowerCase() === lower));
+  if (!hit) return {};
+  return Object.fromEntries(Object.entries(spec[hit]).filter(([alias]) => !isNote(alias)));
+}
+
+function checkOptions(def, alias, value) {
+  if (!Array.isArray(def.options) || def.options.length === 0) return;
+  const values = shapeOf(def) === "multi" ? value.split(",").map((s) => s.trim()).filter(Boolean) : [value];
+  for (const v of values) {
+    if (!def.options.includes(v)) throw new Error(`'${v}' no es opción de '${alias}'.${optionsHint(def)}`);
+  }
+}
+
+function castValue(def, alias, value) {
+  switch (shapeOf(def)) {
+    case "select": return { value };
+    case "text":   return value;
+    case "multi":  return value.split(",").map((s) => s.trim()).filter(Boolean).map((v) => ({ value: v }));
+    case "raw":
+      try { return JSON.parse(value); }
+      catch (e) { throw new Error(`--field ${alias}: shape 'raw' espera JSON válido — ${e.message}`); }
+    default: throw new Error(`shape '${def.shape}' desconocido en '${alias}'`);
+  }
+}
+
+// Resuelve los campos declarados para este issuetype al payload que espera la API.
+// Lanza (sin tocar la red) si un override no existe, si falta un valor obligatorio,
+// o si el valor no está entre las opciones válidas.
+export function resolveJiraFields({ spec, issuetype, overrides = {} }) {
+  const entry = specFor(spec, issuetype);
+  const aliases = Object.keys(entry);
+
+  for (const a of Object.keys(overrides)) {
+    if (Object.prototype.hasOwnProperty.call(entry, a)) continue;
+    throw new Error(aliases.length
+      ? `--field '${a}' no está declarado para el issuetype '${issuetype}'.\n  declarados: ${aliases.join(" | ")}`
+      : `--field '${a}': no hay campos declarados para el issuetype '${issuetype}' (revisá el archivo de campos).`);
+  }
+
+  const out = {};
+  for (const [alias, def] of Object.entries(entry)) {
+    const raw = Object.prototype.hasOwnProperty.call(overrides, alias) ? overrides[alias] : def.default;
+    if (raw === undefined) {
+      throw new Error(`falta el valor de '${alias}' (lo exige el issuetype '${issuetype}').\n  pasalo con:  --field ${alias}=<valor>${optionsHint(def)}`);
+    }
+    const value = String(raw);
+    checkOptions(def, alias, value);
+    out[def.field] = castValue(def, alias, value);
+  }
+  return out;
+}

package/cli/lib/pm-jira.mjs

@@ -7,9 +7,30 @@
 // hasher encuentre "## Criterios de aceptación"); al ESCRIBIR el stamp, componemos ADF.
 
 import { parseUS } from "./us.mjs";
+import { daiFetch } from "./http.mjs";
 
 const trim = (b) => String(b || "").replace(/\/+$/, "");
 
+// La clave del PROYECTO (PROJ), no la de un ticket (PROJ-42). Confundirlas es el
+// error de config más común: `dai init` deja DAI_JIRA_PROJECT vacío y quien lo completa
+// suele pegar la épica que tiene a mano. Jira responde un 400 que no lo explica.
+export function assertProjectKey(key) {
+  if (!key) throw new Error("falta DAI_JIRA_PROJECT en el .env (la clave del proyecto donde crear el issue).");
+  const k = String(key).trim();
+  const m = k.match(/^([A-Za-z][A-Za-z0-9_]*)-\d+$/);
+  if (m) {
+    throw new Error(
+      `DAI_JIRA_PROJECT='${k}' es la clave de un ticket, no la del proyecto.\n` +
+      `  Usá solo la parte de adelante:  DAI_JIRA_PROJECT=${m[1]}\n` +
+      `  Si lo que querías era colgar la US de esa épica:  dai publish <us.md> --parent ${k}`,
+    );
+  }
+  if (!/^[A-Za-z][A-Za-z0-9_]*$/.test(k)) {
+    throw new Error(`DAI_JIRA_PROJECT='${k}' no parece una clave de proyecto (letras y números, empezando por letra — p. ej. PROJ).`);
+  }
+  return k;
+}
+
 export function jiraIssueUrl(base, id) {
   return `${trim(base)}/rest/api/3/issue/${encodeURIComponent(id)}?fields=summary,description`;
 }
@@ -85,37 +106,56 @@ export function renderCoverageAdf(id, r) {
   return { type: "doc", version: 1, content };
 }
 
+// Un 400 al crear casi siempre es un campo obligatorio del proyecto que no mandamos.
+// El cuerpo de Jira nombra el customfield_NNNNN pero no dice qué hacer: lo decimos acá.
+function createHint(status) {
+  if (status !== 400) return "";
+  return "\n\n  Si el error nombra un 'customfield_NNNNN', tu proyecto exige un campo propio.\n" +
+         "  Declaralo en .dai/jira-fields.json y volvé a publicar — no hace falta improvisar\n" +
+         "  una llamada a mano:\n" +
+         '    { "Story": { "clasificacion": { "field": "customfield_NNNNN",\n' +
+         '                                    "options": ["Mejora", "Corrección"] } } }\n' +
+         "    dai publish <us.md> --field clasificacion=Corrección";
+}
+
 export function jiraAdapter(env) {
   const base = env.DAI_JIRA_BASE_URL;
   if (!base) throw new Error("falta DAI_JIRA_BASE_URL en el .env (backend jira).");
   return {
     kind: "jira",
     async fetchUS(id) {
-      const res = await fetch(jiraIssueUrl(base, id), { headers: jiraAuthHeaders(env) });
+      const res = await daiFetch(jiraIssueUrl(base, id), { headers: jiraAuthHeaders(env) });
       if (res.status === 404) return null;
       if (!res.ok) throw new Error(`jira ${res.status}: ${await res.text()}`);
       return { id, ...parseUS(jiraIssueToText(await res.json())) };
     },
     async stamp(id, record) {
-      const res = await fetch(jiraCommentUrl(base, id), {
+      const res = await daiFetch(jiraCommentUrl(base, id), {
         method: "POST", headers: jiraAuthHeaders(env),
         body: JSON.stringify({ body: renderCoverageAdf(id, record) }),
       });
       if (!res.ok) throw new Error(`jira ${res.status}: ${await res.text()}`);
       return `${trim(base)}/browse/${id}`;
     },
-    async createUS({ title, descriptionMarkdown }) {
-      const project = env.DAI_JIRA_PROJECT;
-      const issuetype = env.DAI_JIRA_ISSUETYPE || "Story";
-      if (!project) throw new Error("falta DAI_JIRA_PROJECT en el .env (la clave del proyecto donde crear el issue).");
-      const res = await fetch(`${trim(base)}/rest/api/3/issue`, {
+    // `fields` son los campos propios del proyecto ya resueltos (ver jira-fields.mjs);
+    // `parent` cuelga la US de su épica. Ambos son opcionales: un Jira sin campos
+    // obligatorios sigue publicando igual que antes.
+    async createUS({ title, descriptionMarkdown, parent, issuetype, project, fields }) {
+      const key = assertProjectKey(project || env.DAI_JIRA_PROJECT);
+      const type = issuetype || env.DAI_JIRA_ISSUETYPE || "Story";
+      const payload = {
+        project: { key },
+        issuetype: { name: type },
+        summary: title,
+        description: markdownToAdf(descriptionMarkdown),
+        ...(fields || {}),
+      };
+      if (parent) payload.parent = { key: String(parent).trim() };
+      const res = await daiFetch(`${trim(base)}/rest/api/3/issue`, {
         method: "POST", headers: jiraAuthHeaders(env),
-        body: JSON.stringify({ fields: {
-          project: { key: project }, issuetype: { name: issuetype },
-          summary: title, description: markdownToAdf(descriptionMarkdown),
-        } }),
+        body: JSON.stringify({ fields: payload }),
       });
-      if (!res.ok) throw new Error(`jira ${res.status}: ${await res.text()}`);
+      if (!res.ok) throw new Error(`jira ${res.status}: ${await res.text()}${createHint(res.status)}`);
       const j = await res.json();
       return { id: j.key, url: `${trim(base)}/browse/${j.key}` };
     },

package/docs/adr/0014-copilot-agent-skills.md

@@ -0,0 +1,99 @@
+# ADR-0014 — Copilot lee SKILL.md nativo (Agent Skills)
+
+- **Estado:** aceptado
+- **Fecha:** 2026-07-15
+- **Decide:** lead / arquitecto de la metodología
+- **Modifica:** [ADR-0002](0002-agnostico-del-asistente.md) (la capa 3 del adaptador de Copilot)
+
+## Contexto
+
+La ADR-0002 definió tres capas: contenido portable (los `SKILL.md`), un CLI determinista
+y **adaptadores generados** por asistente. Para Copilot ese adaptador era
+`skillToPrompt()` → `.github/prompts/<nombre>.prompt.md`, porque los prompt files eran
+el único mecanismo que Copilot tenía. De ahí salía su consecuencia registrada: *"el
+analista sin IDE cierra con Claude Desktop"*, ya que los prompt files son solo-IDE.
+
+**Eso dejó de ser cierto.** En diciembre de 2025 GitHub adoptó **Agent Skills**, el
+estándar abierto de `SKILL.md` — el mismo formato que dai ya usa como fuente. Hoy la
+[documentación oficial](https://docs.github.com/en/copilot/concepts/agents/about-agent-skills)
+dice, literal:
+
+> "Agent skills work with Copilot cloud agent, Copilot code review, the GitHub Copilot
+> CLI, the GitHub Copilot app, and agent mode in Visual Studio Code and JetBrains IDEs."
+
+Con rutas estándar: **`.github/skills`**, `.claude/skills` o `.agents/skills` por repo;
+**`~/.copilot/skills`** o `~/.agents/skills` personales. El frontmatter requerido es
+`name` + `description` — exactamente lo que `validateSkill()` ya exige.
+
+Lo descubrimos con un analista funcional real que no lograba que Copilot viera sus
+skills. Tres fallas encadenadas, todas nuestras:
+
+1. **`dai skills install` las dejaba en `~/.claude/skills`.** Esa ruta es válida como
+   skill personal *en VS Code*, pero **no** en el Copilot CLI ni en la app, que solo
+   miran `~/.copilot/skills`. El CLI encima warneaba *"Copilot no tiene skills
+   instalables"* — falso desde diciembre.
+2. **`skillToPrompt()` perdía los `templates/`.** Solo leía el `SKILL.md`, así que
+   `grill-user-story/templates/user-story.md` nunca viajaba y el prompt quedaba con un
+   link roto. Copilot, en cambio, *"automatically discovers all of the files in the
+   skill's directory"*.
+3. **La conversión borraba el `name:`** (había un test afirmándolo como correcto), que
+   en Agent Skills es **requerido** y es lo que define el `/comando`.
+
+## Decisión
+
+**El adaptador de Copilot se elimina: dai le entrega el `SKILL.md` tal cual.**
+
+- **`dai init --for copilot`** → `.github/skills/<nombre>/` como **copia cruda** (igual
+  que Claude), con sus `templates/` adentro. Ya no genera `.github/prompts/`.
+- **`dai skills install --for copilot`** → `~/.copilot/skills/` (global) o
+  `.github/skills/` (local). Copilot **sí** tiene skills instalables.
+- **`skillToPrompt()` se borra.** Queda `stalePromptFiles()`: `dai init` **elimina los
+  `.prompt.md` que generó dai** en versiones previas — si no, cada `/comando` aparecería
+  duplicado, con una copia vieja y sin templates. Solo borra los suyos; los prompt files
+  propios del equipo no se tocan.
+- **`dai doctor` chequea Copilot** y, sobre todo, **solo reporta los asistentes que el
+  repo realmente usa**. Antes listaba los tres siempre: quien configuraba uno veía 14
+  warnings de los otros dos y leía "está todo roto" cuando estaba todo bien.
+- **Cada asistente conserva SU directorio** (`.claude/skills`, `.github/skills`,
+  `.cursor/skills`), aunque Copilot sepa leer los tres. La simetría es predecible y
+  mantiene la capa 3 de la ADR-0002 donde sigue haciendo falta (Cursor).
+
+## Consecuencias
+
+- **La conclusión de la ADR-0002 sobre el analista sin IDE queda revocada.** Un
+  funcional puede cerrar el ciclo con **Copilot CLI o la app de Copilot**, sin VS Code.
+  La tabla del README se corrige: la única superficie sin skills es el chat de
+  github.com.
+- **Los `templates/` de las skills llegan a Copilot por primera vez.**
+- **El frontmatter pasó a tener un lector estricto, y eso destapó un defecto viejo.**
+  Nuestro `parseFrontmatter` es un regex, no YAML: se tragaba cualquier cosa. Y la
+  conversión que borramos hacía `JSON.stringify(description)`, que citaba el valor —
+  o sea que **estaba tapando el bug sin querer**. Al entregar el `SKILL.md` crudo, lo
+  lee un parser YAML real, y `doc-to-backlog` y `grill-epic` **fallaron al cargar**: sus
+  descripciones tenían un `: ` suelto (*"…épicas finales: extrae…"*, *"…nivel
+  funcional/alcance: define…"*) que YAML interpreta como el arranque de un mapa. Las dos
+  skills que más necesita un analista funcional, invisibles.
+  Se citan las descripciones de las 7, y **`validateSkill` ahora valida que `name` y
+  `description` sean escalares YAML válidos** — el molde de `templates/skill.md` también
+  cita por defecto. La lección general: **un adaptador que "arregla" el input esconde el
+  defecto en la fuente**. Mientras convertíamos, el `SKILL.md` inválido era nuestro
+  secreto; entregándolo crudo, el contrato es real y hay que cumplirlo.
+- **Menos código, no más:** se borra una transformación y su test. La capa 3 de la
+  ADR-0002 sigue siendo la decisión correcta — lo que cambió es que Copilot dejó de
+  necesitarla, no que la idea estuviera mal. Cuando el formato de una skill es un
+  estándar abierto, el mejor adaptador es ninguno.
+- **Riesgo asumido:** un repo con `--for all` tendrá el mismo skill en `.claude/skills`
+  y `.github/skills`, y Copilot mira ambos. El estándar exige `name` único, así que
+  esperamos deduplicación por nombre; si en la práctica duplica, se resuelve entonces.
+- **Migración:** `dai init` es idempotente y limpia solo. Un repo viejo se pone al día
+  con `dai init --for copilot` (o `dai sync`).
+
+## Alternativas descartadas
+
+- **Mantener los `.prompt.md` "por compatibilidad".** Duplicaría cada `/comando` con una
+  copia peor. Copilot soporta skills en todas sus superficies desde enero; sostener el
+  camino viejo es sostener el bug.
+- **Escribir solo `.claude/skills` y que Copilot lo levante** (lo hace: *"if you've
+  already set up skills for Claude Code in the `.claude/skills` directory, Copilot will
+  pick them up automatically"*). Rompe la simetría del adaptador y sorprende: pedir
+  `--for copilot` y no tener nada de Copilot en el repo es un mal contrato.

package/docs/adr/0015-jira-corporativo.md

@@ -0,0 +1,104 @@
+# ADR-0015 — `dai publish` en un Jira corporativo (campos propios, épicas, TLS)
+
+- **Estado:** aceptado
+- **Fecha:** 2026-07-15
+- **Decide:** lead / arquitecto de la metodología
+
+## Contexto
+
+`dai publish` funcionaba contra un Jira limpio y fallaba contra uno real. Lo vimos en
+vivo: un analista funcional intentó publicar su primera US en el Jira de su empresa y
+`createUS` mandaba solo `project`, `issuetype`, `summary` y `description`. El proyecto
+exigía un campo propio (`Tipo de trabajo`, `customfield_10042`) → **400 en todos
+los intentos**. Además el proxy corporativo intercepta TLS con su propia CA, y Node no
+usa el trust store del sistema → `fetch` reventaba antes de llegar.
+
+**Lo que pasó después es el verdadero motivo de esta ADR.** El asistente, bloqueado por
+el CLI, improvisó: leyó el schema del campo por su cuenta, armó la llamada a la API de
+Jira con `node -e`, y para pasar el proxy corrió `NODE_TLS_REJECT_UNAUTHORIZED=0` —
+apagando la verificación de certificado **mientras mandaba el token de Jira**. Lo
+reportó como *"nota técnica resuelta en el camino"*. Su propio razonamiento fue:
+*"bypassing dai's limitation entirely"*.
+
+Publicó bien, de casualidad. Pero eso es exactamente lo que la capa 2 de la
+[ADR-0002](0002-agnostico-del-asistente.md) existe para evitar: *"el output es idéntico
+con Claude, con Copilot, o sin ningún asistente"*. **Cuando el CLI no llega, el agente
+inventa** — y el improviso siguiente puede no respetar el contrato del `ac_hash`, y ahí
+la trazabilidad se rompe en silencio.
+
+La lección: **un CLI que no cubre el caso real no es neutral, es una invitación a
+puentearlo.** Cada hueco de la capa 2 se llena con inteligencia no determinista.
+
+## Decisión
+
+**1. Los campos propios se declaran, con nombre humano y opciones válidas.**
+`.dai/jira-fields.json` (o `DAI_JIRA_FIELDS_FILE`), por issuetype:
+
+```json
+{
+  "Story": {
+    "clasificacion": {
+      "field": "customfield_10042",
+      "shape": "select",
+      "default": "Mejora",
+      "options": ["Mejora", "Corrección"]
+    }
+  }
+}
+```
+
+- **Por issuetype**, porque en Jira corporativo los campos obligatorios de una Epic y de
+  una Story casi nunca son los mismos.
+- **`default` + `--field alias=valor`**, porque el valor **no es config fija**: la
+  clasificación es Mejora o Corrección *según la US*. Un default fijo publicaría todas
+  iguales — un dato incorrecto en Jira, en silencio, que es peor que fallar.
+- **`options` valida ANTES de la red.** Un typo da `'Mejraa' no es opción de
+  'clasificacion' — válidas: Mejora | Corrección`, no un 400 críptico.
+- **Un campo declarado tiene que resolver** (default u override): se declara porque Jira
+  lo exige. Si es opcional, no se declara.
+- **`shape`** cubre las formas de Jira (`select` `{value:X}` · `text` X · `multi`
+  `[{value:X}]`), con **`raw`** como escape hatch para cualquier cosa rara: dai no
+  necesita entender todo Jira para no estorbar.
+- **Sin archivo → `{}`.** Un Jira sin campos obligatorios publica igual que siempre.
+
+**2. `--parent` y `--issuetype`.** `--parent` cuelga la US de su épica (`createUS` nunca
+mandaba `parent`); `--issuetype Epic` permite que **`grill-epic` publique épicas por
+CLI**, que hasta hoy no tenían fallback y quedaban como un `.md` para pegar a mano.
+
+**3. Un fallo de TLS enseña el camino correcto, y desaconseja el peligroso.** `daiFetch`
+traduce los códigos de certificado a un error que manda a **`NODE_EXTRA_CA_CERTS`** y
+dice explícitamente por qué `NODE_TLS_REJECT_UNAUTHORIZED=0` no es una alternativa. dai
+**nunca** baja la verificación por su cuenta.
+
+**4. `DAI_JIRA_PROJECT` se valida.** `PROJ-42` es un ticket, no un proyecto — el
+error de config más común. El mensaje da los dos caminos: `DAI_JIRA_PROJECT=PROJ`, o
+`--parent PROJ-42` si lo que querías era colgarla de esa épica.
+
+**5. La constitución prohíbe las dos maniobras**, para todos los asistentes:
+
+> - **No bajes la seguridad para avanzar:** si una llamada falla por el certificado,
+>   declara la CA. Nunca `NODE_TLS_REJECT_UNAUTHORIZED=0`, `verify=False`, `-k`.
+> - **Si el CLI no llega, para y dilo:** no improvises una llamada a la API por fuera.
+
+## Consecuencias
+
+- **`dai publish` sirve en un Jira corporativo**, que es donde vive el usuario real.
+- **`grill-epic` gana un fallback CLI**: MCP → `dai publish --issuetype Epic` → `.md`.
+- **El caso que motivó el bypass ahora está cubierto**, que es la única forma honesta de
+  pedirle a un agente que no improvise: no dejarle el hueco.
+- **`dai doctor`** valida la clave de proyecto y que el archivo de campos parsee. Sigue
+  **sin** verificar que el token sirva — eso es red, y lo dice `dai publish`. El chequeo
+  ahora lo admite en voz alta en vez de dar un ✓ engañoso.
+- **ClickUp queda con el mismo hueco de TLS.** `daiFetch` está listo para adoptarse allá
+  con un import; no lo hicimos ahora por alcance.
+
+## Alternativas descartadas
+
+- **Una sola variable `DAI_JIRA_FIELDS={"customfield_10042":{"value":"Mejora"}}`.**
+  Una línea ilegible, sin distinguir Story de Epic, sin validación, y con el valor fijo
+  — el problema original.
+- **Resolver los nombres de campo contra `createmeta` de Jira.** Menos config, pero pide
+  red para armar el payload, y falla distinto según permisos. Un archivo explícito se lee
+  y se versiona.
+- **Que dai reintente sin verificar TLS si el certificado falla.** Es exactamente lo que
+  hizo el agente. Automatizarlo sería institucionalizar el bug.

package/docs/adr/README.md

@@ -17,6 +17,10 @@ decisión cambia, se escribe un ADR nuevo que supersede al viejo. Molde en
 | [0009](0009-adaptador-cursor.md) | Adaptador nativo para Cursor (skills + rules) con `dai init`/`install`/`doctor` | propuesto |
 | [0010](0010-versionado-y-upgrade.md) | Versionado y upgrade: compatibilidad por semver, `doctor` version-drift, `dai sync` aditivo | propuesto |
 | [0011](0011-archive-gate-de-aprobacion.md) | `archive` es un gate de aprobación: `dai archive` (comando) lo corre el aprobador; `check`/`ls` saltean `archive/` | aceptado |
+| [0012](0012-upgrade-self-update-del-cli.md) | `dai upgrade`: self-update del CLI + `dai sync` del scaffold | aceptado |
+| [0013](0013-skills-externas-install-from.md) | `dai skills install --from`: skills externas por-stack, sin registro ni gatekeeping | aceptado |
+| [0014](0014-copilot-agent-skills.md) | Copilot lee `SKILL.md` nativo (Agent Skills): se elimina el adaptador `.prompt.md` — modifica la 0002 | aceptado |
+| [0015](0015-jira-corporativo.md) | `dai publish` en Jira corporativo: campos propios declarados, `--parent`/`--issuetype`, TLS con CA (nunca apagar la verificación) | aceptado |
 
 > Estas son las decisiones que cierran las "Decisiones abiertas" de
 > [`METODOLOGIA.md §7`](../METODOLOGIA.md) y las enmiendas al

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dforce2055/dai",
-  "version": "0.7.0",
+  "version": "0.8.0",
   "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/",

package/skills/dai-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: dai-review
-description: Revisa una Pull/Merge Request de un repo remoto (GitHub o GitLab) de forma consciente de la metodología dai, y deja un comentario estándar en español con errores y mejoras. Corre `dai check` (¿la US está atrasada?), valida el Definition of Done, hace el review de código (correctitud + calidad), compone el comentario estándar y lo postea — vía el MCP del forge si está disponible, o vía `dai forge comment` (token) si no. Invocar como /dai-review <URL-de-la-PR o número>. Usar en el paso 6 de SCRUM-CON-IA (code review), antes de que un partner humano firme.
+description: "Revisa una Pull/Merge Request de un repo remoto (GitHub o GitLab) de forma consciente de la metodología dai, y deja un comentario estándar en español con errores y mejoras. Corre `dai check` (¿la US está atrasada?), valida el Definition of Done, hace el review de código (correctitud + calidad), compone el comentario estándar y lo postea — vía el MCP del forge si está disponible, o vía `dai forge comment` (token) si no. Invocar como /dai-review <URL-de-la-PR o número>. Usar en el paso 6 de SCRUM-CON-IA (code review), antes de que un partner humano firme."
 ---
 
 # dai-review — review de PR consciente de la metodología

package/skills/doc-to-backlog/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: doc-to-backlog
-description: Toma un documento de análisis (PDF, Word, o un archivo en Drive/SharePoint/ClickUp vía MCP) y produce un BACKLOG CANDIDATO — un mapa de épicas y User Stories propuestas — para que el funcional lo priorice y lo valide. NO emite US ni épicas finales: extrae candidatos marcados "sin validar" y hace handoff de cada sobreviviente a grill-epic / grill-user-story (modo refinar). Es la puerta de entrada del caso "llegué con un documento y quiero sacar el backlog". Invocar como /doc-to-backlog con el path o el link del documento. Usar antes de grill-epic / grill-user-story cuando el input es un doc grande.
+description: "Toma un documento de análisis (PDF, Word, o un archivo en Drive/SharePoint/ClickUp vía MCP) y produce un BACKLOG CANDIDATO — un mapa de épicas y User Stories propuestas — para que el funcional lo priorice y lo valide. NO emite US ni épicas finales: extrae candidatos marcados \"sin validar\" y hace handoff de cada sobreviviente a grill-epic / grill-user-story (modo refinar). Es la puerta de entrada del caso \"llegué con un documento y quiero sacar el backlog\". Invocar como /doc-to-backlog con el path o el link del documento. Usar antes de grill-epic / grill-user-story cuando el input es un doc grande."
 ---
 
 # doc-to-backlog

package/skills/grill-epic/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: grill-epic
-description: Interroga a un PO o analista funcional para producir una ÉPICA bien formada — un bloque grande de valor de negocio que se parte en varias User Stories — siguiendo el template del método. O toma una US que resultó demasiado grande y la promueve a épica. Se queda a nivel funcional/alcance: define el objetivo de negocio y la partición en US, NUNCA criterios de aceptación (esos viven en cada US) ni diseño técnico. Al terminar, publica la épica en Jira/ClickUp (o deja un .md) y hace handoff de cada US hija a grill-user-story. Invocar como /grill-epic, opcionalmente con un título, un ID/URL del tracker, o una US grande a promover. Usar cuando algo es demasiado grande para una sola US.
+description: "Interroga a un PO o analista funcional para producir una ÉPICA bien formada — un bloque grande de valor de negocio que se parte en varias User Stories — siguiendo el template del método. O toma una US que resultó demasiado grande y la promueve a épica. Se queda a nivel funcional/alcance: define el objetivo de negocio y la partición en US, NUNCA criterios de aceptación (esos viven en cada US) ni diseño técnico. Al terminar, publica la épica en Jira/ClickUp (o deja un .md) y hace handoff de cada US hija a grill-user-story. Invocar como /grill-epic, opcionalmente con un título, un ID/URL del tracker, o una US grande a promover. Usar cuando algo es demasiado grande para una sola US."
 ---
 
 # grill-epic
@@ -60,10 +60,18 @@ la forma. Nunca reescribas el formato inline.
 1. **Armar la épica** con el formato de `templates/epica.md`: metadata (`ID`, autor,
    estado, US que la componen) + objetivo + alcance (in/out) + lista de US + métricas +
    dependencias.
-2. **Publicar en el tracker** (según `DAI_PM` del `.env`: `jira` → MCP de Atlassian ·
-   `clickup` → MCP de ClickUp · `md`/sin token → `.md` para pegar a mano). **No asumas
-   el tracker: lee `DAI_PM` primero.** Crear el ticket de épica; las US hijas se crean
-   como tickets vinculados (o quedan listadas para crearse).
+2. **Publicar en el tracker.** **No asumas el tracker: lee `DAI_PM` del `.env` primero.**
+   Tres caminos, mismo contenido:
+   - **Con MCP** (`jira` → MCP de Atlassian · `clickup` → MCP de ClickUp): crea el ticket
+     de épica; las US hijas se crean como tickets vinculados (o quedan listadas).
+   - **Sin MCP, con token** (`DAI_PM=jira` + token en `.env`): escribe la épica como `.md`
+     y publícala con **`dai publish <epica.md> --issuetype Epic`**. Devuelve el key. Si el
+     proyecto exige campos propios, van con `--field alias=valor` (los declarados en
+     `.dai/jira-fields.json`; `dai doctor` te los lista). Después, cada US hija se cuelga
+     con `dai publish <us.md> --parent <KEY-de-la-épica>`.
+   - **Sin token** (o `DAI_PM=md`): deja el `.md` para pegar a mano, y avisa el motivo.
+   - Si `dai` falla, **para y reporta el error tal cual**. No improvises una llamada a la
+     API del tracker por fuera: publicaría igual pero rompería el link en silencio.
 3. **Handoff.** Ofrecer pasar **cada US hija** por `/grill-user-story` para convertirla
    de "título en la lista" a US testeable con criterios. Ese es el paso que las hace
    linkeables (`dai link-us`).

package/skills/grill-intent/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: grill-intent
-description: Gate 0 of the SDD workflow — challenge the *problem* behind a clean user story before any spec is generated. Interrogates whether this is the right problem, for the right user, within constraints, and whether the story's implied solution is a premature jump. Produces intent.md and a verdict that can be "go to spec", "reframe", or "don't build". In the spirit of grill-me, specialized for problem-challenge. Invoke as /grill-intent on a user story (the output of grill-user-story). Use after grill-user-story and before openspec propose.
+description: "Gate 0 of the SDD workflow — challenge the *problem* behind a clean user story before any spec is generated. Interrogates whether this is the right problem, for the right user, within constraints, and whether the story's implied solution is a premature jump. Produces intent.md and a verdict that can be \"go to spec\", \"reframe\", or \"don't build\". In the spirit of grill-me, specialized for problem-challenge. Invoke as /grill-intent on a user story (the output of grill-user-story). Use after grill-user-story and before openspec propose."
 ---
 
 # grill-intent — Gate 0, challenge the problem

package/skills/grill-user-story/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: grill-user-story
-description: Interroga a un PO o analista funcional para producir una User Story funcional y testeable siguiendo el formato del modelo de trazabilidad — o pule una US vaga existente. Se queda a nivel funcional/usuario y se niega a derivar en diseño técnico o a emitir una US con criterios no testeables. Al terminar, PUBLICA la US en el tracker configurado del repo (Jira o ClickUp, según DAI_PM del .env) usando su MCP; si no hay MCP/token, deja un .md con el mismo formato para copiar y pegar. Invocar como /grill-user-story, opcionalmente con un título, un ID/URL del tracker, y/o una US rústica existente. Usar antes de opsx:propose, o cuando alguien dice "necesito una US", "convierte esto en una US como corresponde", o "esta historia está muy vaga".
+description: "Interroga a un PO o analista funcional para producir una User Story funcional y testeable siguiendo el formato del modelo de trazabilidad — o pule una US vaga existente. Se queda a nivel funcional/usuario y se niega a derivar en diseño técnico o a emitir una US con criterios no testeables. Al terminar, PUBLICA la US en el tracker configurado del repo (Jira o ClickUp, según DAI_PM del .env) usando su MCP; si no hay MCP/token, deja un .md con el mismo formato para copiar y pegar. Invocar como /grill-user-story, opcionalmente con un título, un ID/URL del tracker, y/o una US rústica existente. Usar antes de opsx:propose, o cuando alguien dice \"necesito una US\", \"convierte esto en una US como corresponde\", o \"esta historia está muy vaga\"."
 ---
 
 # grill-user-story
@@ -65,11 +65,24 @@ La US se produce UNA vez con el formato de `../../templates/formato-us.md`. Lo q
    - Si NO hay MCP del tracker conectado (pero sí `DAI_PM=jira|clickup` + token en `.env`):
      escribe la US como `.md` (formato `formato-us.md`) y publícala con el comando:
      **`dai publish <ruta-del-md>`** → crea el issue/tarea vía REST y devuelve el key.
-     (Jira necesita además `DAI_JIRA_PROJECT` en el `.env`.)
+     (Jira necesita además `DAI_JIRA_PROJECT` en el `.env` — la clave del **proyecto**,
+     `PROJ`, no la de un ticket.)
+   - **Si la US pertenece a una épica:** `dai publish <us.md> --parent <KEY-de-la-épica>`.
+   - **Si el proyecto exige campos propios** (típico en Jira corporativo): van con
+     `--field alias=valor`, repetible. Los alias son los de `.dai/jira-fields.json`, y
+     `dai doctor` te dice cuáles hay. Si el valor cambia según la US (p. ej. una
+     clasificación Mejora/Corrección), **pregúntaselo a la persona** durante el
+     interrogatorio — no lo elijas tú, es una decisión de negocio.
+     Ej.: `dai publish us.md --parent PROJ-42 --field clasificacion=Corrección`
    - Si tampoco hay token (o `DAI_PM=md`): deja solo el `.md` para que la persona lo
      pegue a mano en el tracker. Avisa el motivo.
    - El contenido es **idéntico** en los tres caminos (MCP / `dai publish` / manual).
-4. **Estado.** Dejar la US en `pulida`. Ofrecer que el dev siga con `dai link-us <ID>` → `opsx:propose` (lado técnico).
+4. **Si `dai publish` falla, para y reporta el error tal cual.** No improvises una llamada
+   a la API del tracker por fuera, ni bajes la verificación TLS para pasar un proxy: el
+   atajo publica igual, pero el `## Criterios de aceptación` puede quedar mal formado y
+   **el link QUÉ↔CÓMO se rompe en silencio**. Si el error nombra un campo obligatorio que
+   falta, decláralo en `.dai/jira-fields.json` (molde en `.dai/templates/`) y reintenta.
+5. **Estado.** Dejar la US en `pulida`. Ofrecer que el dev siga con `dai link-us <ID>` → `opsx:propose` (lado técnico).
 
 ## Hand-off
 

package/skills/link-us/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: link-us
-description: Del lado del dev — crea la branch desde el link de la User Story en Jira SIN margen de error y genera el archivo implements.yaml con el link a la US (id + version + ac_hash). Es la que hace que el link QUÉ↔CÓMO sea correcto por construcción, sin que el dev tipee el key a mano. Invocar como /link-us ABC-### (o con la URL del ticket de Jira). Usar al arrancar la implementación de una US, antes o junto con opsx:explore / opsx:propose.
+description: "Del lado del dev — crea la branch desde el link de la User Story en Jira SIN margen de error y genera el archivo implements.yaml con el link a la US (id + version + ac_hash). Es la que hace que el link QUÉ↔CÓMO sea correcto por construcción, sin que el dev tipee el key a mano. Invocar como /link-us ABC-### (o con la URL del ticket de Jira). Usar al arrancar la implementación de una US, antes o junto con opsx:explore / opsx:propose."
 ---
 
 # link-us