Dotfiles v0.4: un harness agent-first que sabe qué puede afirmar

19 de septiembre de 2026

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

Tesis:

Un agente debe entender el repositorio, las mutaciones disponibles, los contratos de validación, el ownership de tools y la frescura del contexto antes de cambiar nada.

v0.3 hizo visibles las capacidades. v0.4 hace visible el estado afirmable: qué sabe el harness, qué puede mutar cada transición y qué evidencia falta todavía.

devx agent inventory

devx agent inventory resume, en modo solo lectura (humano o JSON):

lifecycle
validation
tools
skills
context
GitNexus

Incluye visibilidad de mutabilidad: qué mutaría cada transición del lifecycle de slice antes de ejecutarla. Eso convierte el inventory en un rehearsal de orientación, no en un dump cosmético.

Los delimitadores de handoff también se endurecen: aliases deterministas (brackets case-insensitive y headings Markdown de niveles 2–6) con allowlist explícita; duplicados fallan en alto. Menos fuzzy matching, menos ambigüedad agent-first.

Discoverability del slice: prepare → start

La salida de devx agent slice prepare apunta al start explícito. El camino deja de ser «preparé algo y ahora ¿qué?».

El comportamiento remoto-only importa:

origin/<feature-branch> existe
branch local ausente
→ crear tracking branch desde el tip remoto
  (no desde base)

El plan reporta would_create_tracking_branch. Recrear desde base habría silenciado trabajo remoto ya existente; v0.4 lo hace explícito y predecible.

devx project doctor

Doctor valida estáticamente [devx.agent.validation]:

• targets de Make desconocidos → warning sin ejecutarlos;
• targets conocidos → se reportan; los comandos de validación explícitos siguen siendo autoritativos;
• scripts de package.json pueden aparecer como hints cuando el package manager es conocido, pero no autorizan nada.

Separación crítica:

hint ≠ authorization

Diagnóstico de entorno npm

Doctor detecta configuración npm heredada desconocida:

npm_config_*
NPM_CONFIG_*

Sin imprimir valores. Sin mutar el entorno del proceso. El harness señala contaminación posible; no la «arregla» a escondidas.

Ownership de tools: devx tools status

Nuevo comando solo lectura y offline. Distingue ownership explícito:

uv-owned:
  ty
  ruff
  pytest

mise-owned:
  actionlint
  osv-scanner

Reporta versiones declared/locked frente a effective. No usa red. No muta paquetes. No afirma que mise deba poseer todo el toolchain.

GitNexus: cero evidencia ≠ riesgo LOW

La lección semántica central de v0.4:

zero evidence
≠
LOW risk

Y además:

structural coverage
≠
impact-risk classification

Cuando la evidencia estructural es insuficiente, el riesgo se marca como unavailable, no como confianza baja disfrazada de verde. Hay tabla de decisión canónica y guidance de fallback.

El modelo compartido de frescura del índice GitNexus alimenta tanto devx agent inventory como devx gitnexus status. El comando preferido para frescura es:

devx gitnexus status --json

Sin analyze/refresh automático: reportar frescura es estrictamente read-only.

Seguridad operacional

Todas las superficies nuevas son solo lectura por defecto. Los diagnósticos de entorno no mutan el process environment. El status de tools no muta paquetes. Eso alinea el harness con el Rehearsal Pattern: primero observar, después autorizar.

Encadenamiento

Tras v0.3 (qué puede hacer el agente) y v0.4 (qué puede afirmar con evidencia), v0.5 empuja dos fronteras restantes: semántica Serena por proyecto y validación Playwright con localhost natural bajo WSL/Docker.