@dforce2055/dai 0.9.0 → 0.11.0

package/{.env.example → .env.dai.example}

@@ -1,6 +1,6 @@
-# dai · configuración del adaptador de PM (copiar a .env y completar).
-# El .env está gitignoreado para no filtrar secretos. Este .example SÍ se versiona.
-# Las variables ya exportadas en la shell/CI ganan sobre el .env.
+# dai · configuración del adaptador de PM (copiar a .env.dai y completar).
+# El .env.dai NO se versiona (evita filtrar secretos) y el .env del equipo no se toca
+# (ADR-0017). Este .example SÍ se versiona. Precedencia: shell/CI > .env.dai > .env.
 
 # ── Backend del tracker ──────────────────────────────────────────────────────
 # md | jira | clickup

package/CHANGELOG.md

@@ -3,6 +3,152 @@
 Formato basado en [Keep a Changelog](https://keepachangelog.com/). Versionado semver
 (ver `VERSION`).
 
+## [0.11.0] — 2026-07-22
+
+**Ronda de fixes reportados usándola, más el eslabón que faltaba: editar el QUÉ. `dai stamp`
+deja de estampar de más, el gate de governance pasa de regla escrita a comando ejecutable,
+`dai edit-us` trae la US del tracker y valida el formato antes de devolverla, y los mensajes
+de error dejan de mandar el diagnóstico para el lado equivocado.**
+
+### Agregado
+- **`dai check --ci`** — el gate de [`governance/ci-rules.md`](governance/ci-rules.md),
+  ejecutable ([ADR-0018](docs/adr/0018-alcance-de-stamp-y-gate-de-ci.md), issue #26). El
+  documento prometía "sin `implements.yaml` el CI bloquea" y no existía el comando que lo
+  hiciera: era una regla escrita que nadie aplicaba. Ahora lee el nombre de la rama y
+  aplica `branch-naming.md` — `feature/` siempre exige US, `chore/`/`docs/`/`ci/`/`release/`
+  y compañía quedan **exentas**, `fix/` exige solo si el nombre trae un ID. Salidas:
+  `0` pasa · `1` falta el link · `2` el QUÉ cambió. Detecta sola la rama en CI
+  (`GITHUB_HEAD_REF` y equivalentes: en una PR, `HEAD` es un merge commit detached).
+  Con `--no-network` valida el link sin pegarle al tracker.
+- **`templates/ci-dai-gate.yml`** — workflow listo para copiar a `.github/workflows/`.
+  Fuera de GitHub Actions el contrato es el mismo: un comando y su código de salida.
+- **`dai edit-us <ID>` y `dai update-us <ID>`** — editar el QUÉ deja de ser copiar y pegar
+  (issue #23, [ADR-0018](docs/adr/0018-alcance-de-stamp-y-gate-de-ci.md)). Dos puertas a un
+  solo camino: `edit-us` **baja la US del tracker**, te la abre en tu `$EDITOR` y la sube
+  (para el PO); `update-us` empuja un `.md` que ya escribiste (para el dev que refinó la US
+  implementándola). Las dos dan el mismo preview y la misma confirmación, porque comparten
+  el mismo tramo de escritura.
+  - **Valida el formato antes de guardar** contra el molde canónico
+    (`templates/formato-us.md`): frenan las tres cosas sin las cuales no hay `ac_hash`
+    —sin título, sin sección de criterios, sección vacía— y **avisan** las demás (un
+    criterio que no es Gherkin completo, uno que se mete en el CÓMO, un título
+    kilométrico). `--strict` sube los avisos a errores.
+  - **Un formato inválido no tira lo escrito**: te devuelve al editor con los errores a la
+    vista, las veces que haga falta.
+  - **Propone subir el `spec_version`** cuando el `ac_hash` se movió, y espera un sí o un
+    no: `s` = cambio material (los repos con la versión vieja se marcan **atrasados**),
+    `n` = cambio editorial (no se marca nadie). dai sabe *que* cambió, no *si importa* —
+    eso lo sabe el PO. `--bump` / `--no-bump` para el modo no interactivo.
+  - **Re-estampa el `ac_hash`** del `implements.yaml`, que si no `dai check` te marcaría
+    atrasado por tu propia edición. `--dry-run` muestra todo el preview sin escribir.
+
+### Arreglado
+- **`dai stamp` estampaba TODAS las US del repo, archivadas incluidas** (issue #22). Cerrar
+  una historia dejaba un comentario de cobertura en los tickets de las otras tres del
+  sprint — y un comentario en un tracker no se deshace. Ahora el alcance sale de la rama
+  ([ADR-0018](docs/adr/0018-alcance-de-stamp-y-gate-de-ci.md)): si la rama nombra la US,
+  esa; si hay una sola viva, esa; si hay varias y no puede saber cuál, **pregunta** en vez
+  de estampar de más (y sin TTY falla pidiendo el ID, en vez de decidir por vos). Los
+  changes archivados salen del default. `dai stamp <ID>` es explícito y `dai stamp --all`
+  recupera el comportamiento anterior.
+- **El error del forge decía `¿token? ¿ref correcta?` para todo** (issue #24). Sin token,
+  token vencido, token sin scope y PR inexistente caían en la misma frase, y eso costó una
+  sesión entera de diagnóstico equivocado. Ahora se nombran por separado: **no hay
+  `GITHUB_TOKEN`/`GITLAB_TOKEN`** (se detecta antes de salir a la red, y no se afirma que
+  esté vencido algo que no existe) · **401** el token existe pero no sirve, con el `curl`
+  para verificarlo · **403** válido pero sin permiso, o rate limit · **404** nombra las
+  **dos** causas, porque en un repo privado GitHub devuelve 404 y no 403 a propósito. El
+  diagnóstico ahora cubre `forge pr`, `forge comment` y `forge review`, que antes se
+  tragaban el error real.
+- **`.dai/reviews/` en el `.gitignore` de los repos ya inicializados** (issue #25). La
+  regla estaba desde 0.10.0, pero solo la aplicaban `dai init`/`dai sync`, y el
+  `review.json` lo escribe la skill: un repo scaffoldeado con una dai vieja se comía
+  borradores a medio editar en un commit. Ahora `dai forge review` lo agrega al consumir
+  un borrador que está bajo `.dai/reviews/`. Además la reconciliación compara **normalizado**
+  (`.dai/reviews`, `/.dai/reviews/` y `.dai/reviews/` son la misma regla), así no duplica
+  la línea a quien ya la había puesto a mano.
+- Un `Ctrl+D` en un prompt de confirmación se trata como **cancelar** en vez de crashear
+  con `Aborted with Ctrl+D`.
+
+### Interno
+- **`cli/test/package-hygiene.test.mjs`** — chequea lo que hasta ahora era un `git grep` a
+  mano antes de pushear: que ningún fuente versionado tenga bytes NUL (uno se coló y git
+  pasó a tratar el archivo como binario, con el diff dejando de ser revisable), que todo
+  sea UTF-8 válido, que no viajen identificadores de repos de terceros —la convención de
+  los ejemplos es ACME— y que `files[]` no publique el sitio.
+
+### Versionado
+
+**Minor → 0.11.0.** `dai stamp` sin argumentos **cambia de comportamiento**: antes estampaba
+todas las US del repo, ahora una. En el papel es incompatible; en la práctica el
+comportamiento viejo era el bug que reporta el issue #22, y quien lo quiera tiene `--all`.
+El contrato del modelo (`ac_hash`, schema de `implements.yaml`) queda intacto, y todo lo
+demás es aditivo.
+
+### Cambiado
+- `governance/ci-rules.md` describe lo que la máquina realmente hace: el comando que
+  ejecuta cada regla, la tabla de ramas exentas, y por qué el gate no bloquea sin
+  credenciales del tracker.
+- **Los adaptadores de PM devuelven `raw`** (el markdown completo de la US) además del
+  parseo. Es lo que `edit-us` abre; antes solo salían título + hash, que alcanza para
+  detectar drift pero no para editar.
+- **`/grill-user-story` distingue crear de refinar.** Si la US es nueva la crea como
+  siempre (MCP o `dai publish`); si **ya tiene key**, ahora la actualiza con
+  `dai edit-us <ID> --us <md> --no-editor` en vez de pisar el ticket por MCP. Así el
+  camino de la skill pasa por los mismos controles que el manual: validación de formato
+  antes de escribir, preview, y la pregunta del `spec_version` — que la skill tiene
+  instrucción explícita de trasladarle al PO, no de responder con `--yes`.
+- **Las skills dicen bien dónde está la config: `.env.dai` *o* `.env`.** Varias mandaban a
+  leer solo uno de los dos, y quien tenía todo en el `.env` del equipo veía a la skill
+  concluir que no había tracker configurado. dai **carga los dos** —`.env.dai` gana si una
+  clave está en ambos, y un repo que nunca creó `.env.dai` sigue funcionando igual
+  (ADR-0017)—; ahora las skills lo dicen así. Sin cambios de comportamiento en el CLI:
+  el loader ya hacía esto.
+- Documentación al día con los comandos nuevos: la [guía del PO](docs/guias/po.md) estrena
+  una sección "Cuando el QUÉ cambia", más `docs/guias/dev.md`, `docs/PROBAR.md`,
+  `docs/EJEMPLO-END-TO-END.md`, `docs/SCRUM-CON-IA.md`, `docs/METODOLOGIA.md`,
+  `docs/glosario.md`, `docs/detalle/01-refinamiento.md` y `docs/detalle/07-merge-trazabilidad.md`.
+
+## [0.10.0] — 2026-07-18
+
+**La config de dai deja de vivir en el `.env` del equipo y pasa a un `.env.dai` propio (no
+versionado). Resuelve el caso de las empresas que versionan el `.env` como política: dai no
+toca ese archivo y guarda sus secretos donde git realmente los ignora. Y `dai init` estrena
+una bienvenida con el Sol de Mayo en bloques.**
+
+### Agregado
+- **Banner de bienvenida en `dai init`**: el Sol de Mayo de dai en bloques (cuerpo y rayos
+  rectos en oro, rayos ondulados en celeste) junto al título, más un preview de lo que se va
+  a configurar. Cero dependencias (solo ANSI); degrada a ASCII sin color en no-TTY o con
+  `NO_COLOR`.
+- **`dai skills install --from npm:@scope/pkg`** — nueva fuente para skills externas
+  ([ADR-0013](docs/adr/0013-skills-externas-install-from.md)): además de git URL y path
+  local, ahora un **paquete npm**. dai hace `npm install` a un temp (respetando el `.npmrc`
+  del repo, así resuelve **registries privados con scope**; `npm pack` no sirve con los
+  registries de grupo de GitLab). Es común distribuir skills como paquete npm; antes había
+  que materializarlo a mano.
+- **Descripciones en bloque YAML (`|` / `>`) en el frontmatter de las skills.** El parser
+  de frontmatter ahora lee bloques literales/plegados multilínea (antes tomaba solo la
+  primera línea `|` y el validador lo rechazaba). Es como se escriben las skills reales:
+  descripciones ricas con "USAR CUANDO / NO USAR CUANDO" que el agente usa para elegirlas.
+
+### Cambiado
+- **`dai init` escribe en `.env.dai` + `.env.dai.example`, no en `.env`/`.env.example`**
+  ([ADR-0017](docs/adr/0017-env-dai.md)). El `.env` del equipo queda intacto (dai solo lo
+  lee). `.env.dai` (secretos) se gitignorea; `.env.dai.example` (plantilla) se versiona.
+  En un repo sin `.env`, dai ya no crea uno: es del equipo, no de dai.
+- **El loader lee `.env.dai` y `.env`** con precedencia **shell/CI > `.env.dai` > `.env`**.
+  Seguir leyendo `.env` mantiene la compatibilidad: los repos que ya tenían los `DAI_*` ahí
+  no se rompen.
+- **`.gitignore`**: dai ignora `.env.dai` (su archivo), no `.env`. Ya no fuerza un ignore
+  sobre un archivo que muchas orgs versionan a propósito.
+- Se renombró el `.env.example` del paquete a `.env.dai.example`, y se actualizaron doctor,
+  mensajes de init/sync, tutoriales, constitución y README a la nueva convención.
+
+### Interno
+- **228 tests** (+4 desde 0.9.0): precedencia de `loadDaiEnv` (shell > `.env.dai` > `.env`),
+  compat con `.env`, y sin-archivos. Smokes de `dai init` con y sin `.env` preexistente.
+
 ## [0.9.0] — 2026-07-17
 
 **El review de dai deja de ser un comentario al final del hilo y pasa a ser un review
@@ -405,6 +551,8 @@ 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.11.0]: https://github.com/dforce2055/dai/releases/tag/v0.11.0
+[0.10.0]: https://github.com/dforce2055/dai/releases/tag/v0.10.0
 [0.9.0]: https://github.com/dforce2055/dai/releases/tag/v0.9.0
 [0.8.2]: https://github.com/dforce2055/dai/releases/tag/v0.8.2
 [0.8.1]: https://github.com/dforce2055/dai/releases/tag/v0.8.1

package/README.md

@@ -63,10 +63,10 @@ Y después, en el chat del asistente, según lo que tengas:
 
 > Las skills **te interrogan** hasta que la historia es testeable (nunca inventan
 > requerimientos: los sacan a preguntas), y la **publican en el tracker** que configuraste
-> (`DAI_PM` en el `.env`): por el **MCP** de Jira/ClickUp si está conectado, o con
+> (`DAI_PM` en el `.env.dai`): por el **MCP** de Jira/ClickUp si está conectado, o con
 > **`dai publish <us.md>`** si no (crea el issue vía token). Tú respondes y decides.
 
-¿Sin MCP, o querés publicar a mano? `dai publish` sube el `.md` al tracker y te devuelve el key:
+¿Sin MCP, o quieres publicar a mano? `dai publish` sube el `.md` al tracker y te devuelve el key:
 
 ```bash
 dai publish historia.md                                # crea la US → devuelve el key
@@ -87,7 +87,7 @@ Una vez, preparas el repo:
 ```bash
 npm i -g @dforce2055/dai
 cd mi-repo && dai init          # bootstrap: skills + tracker + OpenSpec + PR template
-# completa el token del tracker en .env  (o DAI_PM=md para probar sin credenciales)
+# completa el token del tracker en .env.dai  (o DAI_PM=md para probar sin credenciales)
 dai doctor                      # verifica que todo quedó en su lugar
 ```
 
@@ -112,12 +112,20 @@ dai pr --assignee <compañero>   # crea la PR precargada y se la asigna a un com
 dai stamp                       # al mergear: estampa la cobertura en el tracker
 ```
 
-> **Para que `dai pr` cree la PR/MR** necesitás el CLI del forge instalado y autenticado, una
+> ¿Cambió el QUÉ? `dai edit-us <ID>` baja la US del tracker, te la abre en tu editor, valida
+> el formato y te pregunta si el cambio es material (sube `spec_version`) o editorial. Si
+> ya tenés el `.md` escrito —lo refinaste implementando— `dai update-us <ID>` lo empuja y
+> re-estampa tu `ac_hash`, que si no `dai check` te marca atrasado por tu propia edición.
+> Y si quieres que el link deje de depender de la memoria del equipo, `dai check --ci` es
+> el gate ejecutable de [`governance/ci-rules.md`](governance/ci-rules.md): copia
+> [`templates/ci-dai-gate.yml`](templates/ci-dai-gate.yml) a `.github/workflows/`.
+
+> **Para que `dai pr` cree la PR/MR** necesitas el CLI del forge instalado y autenticado, una
 > sola vez por máquina:
 > - **GitHub** → [`gh`](https://cli.github.com) · `gh auth login`
 > - **GitLab** → [`glab`](https://gitlab.com/gitlab-org/cli) · `glab auth login --hostname <tu-gitlab>`
 >   — en un GitLab self-hosted/corporativo el `--hostname` es **obligatorio**, y el token va con
->   scope `api`. (En Windows, tras instalar `glab` con `winget`, abrí una terminal nueva para que
+>   scope `api`. (En Windows, tras instalar `glab` con `winget`, abre una terminal nueva para que
 >   tome el PATH.)
 >
 > Sin el CLI del forge, `dai pr` **igual pushea tu branch** y te dice qué instalar — después
@@ -159,20 +167,22 @@ flowchart TD
 | 4 | **Linkear la US** | `dai link-us <ID>` → branch + `openspec/changes/<id>/implements.yaml` | dev |
 | 5 | **Verificar / listar** | `dai check` (¿al día?) · `dai ls` (qué implementa el repo) | dev |
 | 6 | **Resincronizar** *(si el PO editó la US)* | `dai link-us <ID> --resync` | dev |
+| 6b | **Editar la US** | `dai edit-us <ID>` la baja del tracker, la abrís en tu editor, valida el formato y la devuelve · `dai update-us <ID>` empuja un `.md` que ya escribiste. Las dos preguntan si subir el `spec_version` | PO / dev |
 | 7 | **Diseñar el CÓMO** | en el asistente: `/opsx:explore` → `/opsx:propose` → design + tasks | dev + IA |
 | 8 | **Implementar** | `/opsx:apply` → implementa la US con TDD y genera los commits | dev + IA |
 | 9 | **Code review propio** | revisas tu implementación (correctitud + calidad) antes de la PR | dev |
 | 10 | **Smoke test** | pides al agente un smoke local del flujo | dev + IA |
 | 11 | **Crear la PR** | `dai pr` → pregunta la branch base, arma el texto, lo muestra, confirma, pushea y crea la PR/MR | dev |
 | 12 | **Review de un partner** | skill `/dai-review <PR>` deja un **review inline** (resumen + un comentario por línea, low/medium/high); te muestra el preview y **espera tu OK** antes de postear; un humano aprueba | partner |
-| 13 | **Merge + estampar** | al mergear: `dai stamp` → cobertura inversa en el tracker | dev / CI |
+| 13 | **Merge + estampar** | al mergear: `dai stamp` → cobertura inversa en el tracker (deduce la US de la rama; en CI pasa el ID) | dev / CI |
+| 13b | **Gate de trazabilidad** *(opcional)* | `dai check --ci` en el CI → bloquea una rama de producto sin link; `chore/`/`docs/` quedan exentas ([template](templates/ci-dai-gate.yml)) | CI |
 | 14 | **Cerrar la US** | `dai done` → vuelve a la base, actualiza y borra la branch local (si está mergeada) | dev |
 
 > **Paso 3b (publicar):** el MCP crea el issue interactivamente; `dai publish` necesita el
-> token del tracker en `.env` (Jira además `DAI_JIRA_PROJECT`, ClickUp `DAI_CLICKUP_LIST_ID`).
+> token del tracker en `.env.dai` (Jira además `DAI_JIRA_PROJECT`, ClickUp `DAI_CLICKUP_LIST_ID`).
 >
 > **Paso 7 (OpenSpec):** `dai init` te ofrece instalarlo **e inicializarlo** solo. Si los
-> comandos `/opsx:*` no aparecen en el asistente, reinicia el IDE (se cargan al arrancar).
+> comandos `/opsx:*` no aparecen en el asistente, reinicia el IDE (se cargan al iniciar).
 >
 > **Paso 11 (PR):** necesita un remoto git (`origin`) y `gh`/`glab` autenticado. Sin remoto,
 > dai no crea la PR (te deja el texto listo igual).
@@ -183,8 +193,8 @@ flowchart TD
 |---|---|
 | `dai init [<repo>]` | scaffolder interactivo del repo. Flags: `--for claude\|copilot\|both\|cursor\|all` (asistente, default `all`) · `--pm md\|jira\|clickup` (tracker) · `--openspec` |
 | `dai skills install [--global \| --local <repo>] [--force] [--dry-run] [--for claude\|copilot\|cursor\|all]` | instala/actualiza las skills de dai en Claude, Copilot y/o Cursor (`--for all` por defecto; Copilot global → `~/.copilot/skills`, local → `.github/skills/`). `--force` re-copia. Alias: **`dai install`**. Ej: `dai skills install --local . --for cursor --force` |
-| `dai skills install --from <git-url\|path>[#ref] [--for …]` | instala **skills externas** (por-stack: .NET, Java, …) desde un repo/dir, **convertidas para los 3 asistentes**. Self-service, one-off, sin registro; `dai sync` no las toca. Colisión con una skill de dai → salta ([ADR-0013](docs/adr/0013-skills-externas-install-from.md)). Ej: `dai skills install --from github.com/mi-org/net-skills` |
-| `dai sync [--dry-run] [--for <asistentes>]` | **refresca** skills, constitución, templates y PR template a la versión del CLI — **aditivo** (no pisa tu `CLAUDE.md`), no toca el `.env` ni OpenSpec. Detecta los asistentes del repo o pasás `--for`. `--dry-run` muestra qué cambiaría ([ADR-0010](docs/adr/0010-versionado-y-upgrade.md)) |
+| `dai skills install --from <git-url\|npm:pkg\|path>[#ref] [--for …]` | instala **skills externas** (por-stack: .NET, Java, …) desde un repo/dir/**paquete npm**, **convertidas para los 3 asistentes**. Self-service, one-off, sin registro; `dai sync` no las toca. Colisión con una skill de dai → salta ([ADR-0013](docs/adr/0013-skills-externas-install-from.md)). Ej: `dai skills install --from github.com/mi-org/net-skills` · `dai skills install --from npm:@mi-org/ui-skills` (usa el `.npmrc` del repo → registries privados OK) |
+| `dai sync [--dry-run] [--for <asistentes>]` | **refresca** skills, constitución, templates y PR template a la versión del CLI — **aditivo** (no pisa tu `CLAUDE.md`), no toca el `.env.dai` ni OpenSpec. Detecta los asistentes del repo o pasás `--for`. `--dry-run` muestra qué cambiaría ([ADR-0010](docs/adr/0010-versionado-y-upgrade.md)) |
 | `dai upgrade [--check] [--dry-run]` · alias `dai update` | **actualiza el CLI global** a la última publicada (`npm i -g …@latest`) — self-update. **No toca el repo**: reporta el drift del scaffold pero deja el `dai sync` al mantenedor. `--check` solo informa · `--dry-run` muestra el comando ([ADR-0012](docs/adr/0012-upgrade-self-update-del-cli.md)) |
 | `dai publish <us.md> [--parent KEY] [--issuetype T] [--field alias=valor]` | crea la US en el tracker (Jira/ClickUp/md) desde un `.md` y devuelve el key — el fallback del MCP para publicar sin el asistente. `--parent PROJ-42` la cuelga de su épica · `--issuetype Epic` publica una épica (fallback CLI de `grill-epic`) · `--field clasificacion=Mejora` (repetible) manda los campos propios que exige tu Jira, declarados en `.dai/jira-fields.json` ([ADR-0015](docs/adr/0015-jira-corporativo.md)) |
 | `dai link-us <ID> [--us <md>]` | crea branch + `implements.yaml`; sin `--us` trae la US del tracker |
@@ -203,20 +213,22 @@ flowchart TD
 > **🆕 Mantené tu repo al día — `dai sync`.** Las skills, la constitución y los templates son un
 > *caché derivable* del CLI. Cuando actualizás `dai` (`dai upgrade`), **`dai doctor` y
 > `dai version` te avisan solos** si tu scaffold quedó atrás — con color y un `⬆️` —, y **`dai sync`**
-> lo refresca: **aditivo** (conserva tu `CLAUDE.md` propio), sin tocar el `.env` ni OpenSpec. Probá sin
+> lo refresca: **aditivo** (conserva tu `CLAUDE.md` propio), sin tocar el `.env.dai` ni OpenSpec. Prueba sin
 > riesgo con `dai sync --dry-run`. El versionado es semver: patch/minor no rompen nada; solo un major
 > pediría migración. ([ADR-0010](docs/adr/0010-versionado-y-upgrade.md))
 
 > **🧩 Skills de cualquier stack — `dai skills install --from`.** Además de las skills de
-> dai, cada equipo suma las suyas (por-stack: .NET, Java, Rust…) desde su propio repo:
-> `dai skills install --from github.com/tu-org/net-skills`. dai las **convierte para los 3
-> asistentes** (Claude/Cursor/Copilot) e instala. **dai es el distribuidor de skills de
-> cualquier stack, sin opinar sobre su contenido** — self-service, sin registro; `dai sync`
-> sigue siendo solo de dai. ([ADR-0013](docs/adr/0013-skills-externas-install-from.md))
+> dai, cada equipo suma las suyas (por-stack: .NET, Java, Rust…) desde su propio repo o
+> **paquete npm**: `dai skills install --from github.com/tu-org/net-skills` · `dai skills
+> install --from npm:@tu-org/ui-skills` (el paquete npm usa el `.npmrc` del repo, así
+> resuelve registries privados con scope). dai las **convierte para los 3 asistentes**
+> (Claude/Cursor/Copilot) e instala. **dai es el distribuidor de skills de cualquier stack,
+> sin opinar sobre su contenido** — self-service, sin registro; `dai sync` sigue siendo solo
+> de dai. ([ADR-0013](docs/adr/0013-skills-externas-install-from.md))
 >
 > La fuente puede ser **pública, privada (por SSH) o un path local**: dai no hace auth
-> propia, delega en git — **si podés `git clone` el repo, dai instala desde ahí**. Para
-> privados usá la forma SSH (`git@github.com:tu-org/net-skills.git`), consistente con el
+> propia, delega en git — **si puedes `git clone` el repo, dai instala desde ahí**. Para
+> privados usa la forma SSH (`git@github.com:tu-org/net-skills.git`), consistente con el
 > modelo de auth de dai ([ADR-0007](docs/adr/0007-modelo-de-autenticacion.md)). Público =
 > cero fricción entre equipos/máquinas.
 >
@@ -229,8 +241,9 @@ flowchart TD
 > en [`skills/`](skills/).
 
 Skills (se invocan en el asistente): `/doc-to-backlog` · `/grill-intent` · `/grill-epic` · `/grill-user-story` · `/link-us` ·
-`/tdd` · `/dai-review`. Config del tracker (`md`\|`jira`\|`clickup`) y tokens: en `.env` —
-ver [`.env.example`](.env.example). Auth (SSH + tokens): [ADR-0007](docs/adr/0007-modelo-de-autenticacion.md).
+`/tdd` · `/dai-review`. Config del tracker (`md`\|`jira`\|`clickup`) y tokens: en `.env.dai`
+(no versionado; el `.env` del equipo no se toca — [ADR-0017](docs/adr/0017-env-dai.md)) —
+ver [`.env.dai.example`](.env.dai.example). Auth (SSH + tokens): [ADR-0007](docs/adr/0007-modelo-de-autenticacion.md).
 
 ## El flag `--for` — ¿para qué asistente preparo el repo?
 
@@ -262,7 +275,7 @@ Después de `dai init` (con `--for all`):
 ```
 mi-repo/
 ├── CLAUDE.md                       · Constitución del proyecto (auto-cargada por Claude)
-├── .env                            · configurado con tu tracker (gitignored, completa el token)
+├── .env.dai                        · tu tracker (NO versionado, completa el token) + .env.dai.example (plantilla, sí versionada)
 ├── .claude/skills/                 · Las skills, locales al repo (el equipo las hereda)
 │   └── doc-to-backlog · grill-intent · grill-epic · grill-user-story · link-us · tdd · dai-review
 ├── .github/
@@ -334,7 +347,7 @@ dai/
 ├── skills/         🤖  doc-to-backlog · grill-intent · grill-epic · grill-user-story · link-us · tdd · dai-review
 ├── governance/     🛡️  branch-naming · ci-rules · commit-convention
 ├── index.html      📊  landing autocontenido (la historia); publicable por GitHub Pages
-└── manifest.yaml · VERSION · install.sh (shim) · .env.example
+└── manifest.yaml · VERSION · install.sh (shim) · .env.dai.example
 ```
 
 ## Licencia
@@ -351,9 +364,17 @@ Detalle en [ADR-0006](docs/adr/0006-distribucion-y-licencia.md).
 
 ## Agradecimientos
 
-dai se apoya en ideas y aprendizajes de la comunidad. En particular, gracias a
-**[Matt Pocock](https://github.com/mattpocock)** por su aporte con las *skills* y por su
-[canal de YouTube](https://www.youtube.com/@mattpocockuk) explicándolas — su trabajo nos ayudó
-a construir esta herramienta.
+dai se apoya en ideas y herramientas de la comunidad.
+
+Un agradecimiento especial a **[OpenSpec](https://github.com/Fission-AI/OpenSpec)** (de
+[Fission AI](https://github.com/Fission-AI), `@fission-ai/openspec`): es la herramienta
+sobre la que se construye todo el **CÓMO** de dai — explorar la solución, proponer el diseño
+y las tareas, e implementar el change (`opsx:explore → propose → apply → archive`). dai no
+la bundlea ni la reemplaza; se apoya en ella para convertir el QUÉ en un plan técnico
+trazable. Sin OpenSpec, la mitad del método no existiría.
+
+Y gracias a **[Matt Pocock](https://github.com/mattpocock)** por su aporte con las *skills*
+y por su [canal de YouTube](https://www.youtube.com/@mattpocockuk) explicándolas — su
+trabajo nos ayudó a construir esta herramienta.
 
 Seguridad: [`SECURITY.md`](SECURITY.md) · Conducta: [`CODE_OF_CONDUCT.md`](CODE_OF_CONDUCT.md)

package/VERSION

@@ -1 +1 @@
-0.9.0
+0.11.0