Dotfiles v0.3: capacidades explícitas, Serena y releases gobernadas

19 de septiembre de 2026

Fuente primaria: notas de release v0.3.0 del repositorio Dotfiles (jesuserro/dotfiles/releases/v0.3.0.md, 2026-09-19).

Tesis:

El harness empieza a exponer qué puede hacer un agente y dónde vive la autoridad, mientras la publicación de releases se convierte en una operación guardada.

Hasta v0.3, un agente podía tener herramientas potentes y aun así operar a ciegas: sin un contrato legible de capacidades, sin política clara de routing y sin un camino de release que no dependiera de un workflow opaco. Esta minor release no inventa el entorno reproducible; hace inspeccionable la autoridad.

Capacidades de agente

devx agent capabilities publica una superficie de discovery:

• salida humana legible;
• salida JSON;
• JSON Schema v1 para el contrato machine-readable;
• inventario MCP construido desde el MANIFEST.yaml canónico;
• discovery de skills;
• catálogo CLI soportado.

El punto no es enumerar tools por estética. Es que un implementer —humano o agente— pueda responder antes de mutar:

¿qué capacidades existen?
¿de dónde salen?
¿qué contrato las describe?

El manifiesto MCP permanece como fuente de verdad. Las skills y el catálogo CLI se reutilizan; no se inventan inventarios paralelos por cliente.

Routing: autoridad, no preferencia de tool

v0.3 fija una política de enrutado que separa dónde vive la autoridad de qué cliente conviene:

Necesidad	Autoridad / ruta
Documentación actual de librerías y frameworks upstream	Context7
Issues, PRs, búsqueda y contenido hospedado en GitHub	GitHub MCP
Operaciones Git locales	Git local
Tags y publicación de GitHub Release	git + gh vía el workflow gobernado de devx release

GitHub MCP no publica tags ni Releases. Esa frontera evita que «tengo acceso a GitHub» se confunda con «puedo publicar una versión».

Serena y GitNexus son complementarios

Se añade serena-agent==1.7.0 a través del runtime gobernado uvx para Cursor, Codex y OpenCode.

Los roles no compiten:

GitNexus
→ análisis de grafo
→ impacto estructural
→ flujos cross-file

Serena
→ símbolos
→ referencias
→ rename
→ overview semántico

GitNexus responde «qué se rompe si cambio esto en el grafo». Serena responde «dónde está este símbolo y cómo se renombra con inteligencia semántica». Sustituir uno por el otro borra una dimensión distinta de evidencia.

Releases gobernadas

Antes, un publisher disparado por tag en GitHub Actions podía convertir un push de tag en una publicación casi automática. v0.3 lo retira y sustituye por un flujo explícito:

devx release plan
→ lectura / dry-run

devx release create
→ requiere --yes
→ tag anotado
→ push solo de ese tag
→ gh release create

--dry-run planifica sin publicar. --yes es la confirmación explícita. El resume seguro permite retomar un release a medias sin reinventar el estado a mano.

La arquitectura queda clara:

ai/assets/mcps/MANIFEST.yaml  → verdad MCP
devx release                  → publicación gobernada sobre git + gh
GitHub MCP                    → no publica tags ni Releases

Qué cambia para el operador

Un agente que llega a Dotfiles después de v0.3 ya no tiene que adivinar el perímetro. Puede listar capacidades, respetar el routing de autoridad y tratar la publicación de una versión como una mutación guardada — no como un efecto colateral de empujar un tag.

La siguiente entrega, v0.4, convierte esa claridad de capacidades en orientación previa a cualquier cambio: inventory, doctor, ownership de tools y semántica de riesgo de GitNexus.