v0.1.1

[0.1.1] — 2026-07-07

Ciclo perfectivo que corrige los 12 hallazgos Menores y el residuo WARNING-01
identificados durante la revisión final del release 0.1.0, más el ciclo
correctivo de la auditoría de production-readiness: cierra la única grieta
funcional (el release gate del pin de revisiones en la carga del engine) y siete
Menores (gate de daemon serve, identidad del health check, sandbox acotado del
daemon, exactitud documental y procedencia del lockfile). Todos los cambios
de contrato son aditivos: los códigos de salida existentes no cambian y
schema_version permanece en "1".

Añadido

• --json en los cuatro comandos de escritura (R-03): voice add
  ({name, reference, speech}), voice remove ({name, removed}), setup
  ({model, already_cached, downloaded, cache_dir}, con variante para
  --remove-path) y cleanup ({removed, dry_run}). El contrato programático
  queda simétrico: ningún comando obliga a parsear texto. cleanup --json
  exige --yes o --dry-run (exit 4 sin ellos) y envía sus listados
  informativos a stderr.
• Referencia de esquemas --json en USAGE.md (R-04): las claves de los
  nueve payloads (tipo y significado) declaradas por escrito como parte del
  contrato, sin necesidad de ingeniería inversa.
• Revisión fijada del modelo por release (R-15): setup descarga ambos
  repos de HuggingFace con revision= (commit hash auditado, constantes
  MODEL_REVISIONS/BASE_MODEL_REVISION en model_cache.py) y la detección
  de caché valida el snapshot de esa revisión en ambos repos (ciclo posterior
  cerró el residuo WARNING-01 del repo base); el bump del pin es un paso del
  runbook de release (docs/RELEASING.md) y su alcance está descrito en
  SECURITY.md.
• Plantillas de Issue/PR en .github/ (R-12): formularios de bug (versión,
  SO, comando reproducible, salida) y de propuesta, blank_issues_enabled: false con la vía de seguridad señalizada, y checklist de PR alineado a
  CONTRIBUTING.md.

Cambiado

• Documentación del bloqueo SmartScreen/Gatekeeper ampliada: README.md,
  USAGE.md, SECURITY.md y docs/BUILD.md explican por qué el sistema
  bloquea el primer arranque (binario sin firma + sin reputación por ser cada
  release un archivo nuevo), que no indica malware, cómo proceder paso a paso
  (incluido el bloqueo del navegador y la cuarentena de antivirus de terceros,
  siempre tras verificar el SHA-256) y la ruta prevista de firma de código vía
  SignPath Foundation (gratuita para proyectos open source).

• daemon stop honesto durante la ventana de arranque (R-05): detecta el
  daemon en arranque por cmdline (sin PID file), avisa «arrancando; aún no
  acepta conexiones» y termina con exit 5 en vez de reportar un éxito falso;
  no mata el proceso. Documentado en docs/DAEMON-MODE.md.

• CI con imágenes fijadas por digest y pip pineado (R-14): las tres
  referencias cimg/python:3.13 usan @sha256:<digest> (manifest list
  multi-arch) y los siete pip install --upgrade pip pasaron a versión exacta.
  Excepciones documentadas: brew upgrade pyenv (necesario para el parche
  3.13.14; no altera el artefacto) y create-dmg (Homebrew no pinea).
  Implicaciones y procedimiento de bump en docs/BUILD.md §Reproducibilidad.

• Exactitud documental (R-11, R-13): stack de reproducción real
  (winsound/sounddevice/afplay) en docs/DESIGN.md y docs/ARCHITECTURE.md
  (antes describían pycaw-WASAPI/pyalsaaudio/AVFoundation); árboles de
  estructura con voices.py, paths.py y model_cache.py; CI descrito como
  Linux/Windows/macOS en CONTRIBUTING.md; conteo de tests actualizado a
  268 en docs/GOAL.md; inventario de licencias consistente (dependencias
  copyleft-compatibles mencionadas en USAGE.md/CLAUDE.md; los runtimes
  NVIDIA no van en ningún artefacto distribuido — README.md y
  THIRD-PARTY-LICENSES.md).

• El engine honra las revisiones fijadas en la carga y en las descargas de
  respaldo (release gate de la auditoría de production-readiness): la
  resolución de snapshot en tiempo de carga (language pack y snapshot base del
  Voice Encoder) y las dos redes de seguridad de descarga (snapshot_download
  del modelo, hf_hub_download de ve.safetensors) pasan revision=
  (MODEL_REVISIONS/BASE_MODEL_REVISION). Cierra la asimetría por la que la
  detección honraba el pin pero la carga caía al fallback refs/main→mtime: tras
  un bump futuro de revisión ya no puede producirse síntesis silenciosa con el
  modelo viejo. Simétrico con setup y la detección de caché.

• daemon serve exige el modelo en caché antes de arrancar (auditoría de
  production-readiness): mismo gate que daemon start; sin modelo provisionado
  falla rápido remitiendo a setup (exit 2) sin cargar el engine ni disparar la
  descarga de su red de seguridad. Ningún subcomando descarga de forma implícita.

• Sandbox de audio del daemon acotado a un subdirectorio namespaced
  (auditoría de production-readiness): /synthesize acepta audio bajo los
  directorios de voces (fábrica/usuario) y <tempdir>/tts-sidecar/, pero ya no
  bajo el tempdir compartido general (%TEMP%//tmp), reduciendo la superficie
  de temp compartido preservando el staging IPC. docs/DAEMON-MODE.md y
  USAGE.md describen la superficie real.

• Exactitud documental de estados, conteos y doctor (auditoría de
  production-readiness): daemon status documenta los valores reales
  ("healthy"/"initializing", ya no "ready") en prosa y en la tabla del
  esquema JSON de USAGE.md; el ejemplo de doctor incluye el chequeo de RAM y
  el total de chequeos coherente (5); conteo de tests a 268.

• requirements-lock.txt regenerado con el comando canónico (auditoría de
  production-readiness): sin el --constraint a un archivo externo al repo; su
  header ya no referencia ningún override y la procedencia vuelve a ser
  reproducible desde CLAUDE.md/docs/BUILD.md. La resolución de versiones es
  idéntica a la anterior; instala con --require-hashes.

Corregido

• voice list ante un directorio de voces ilegible (R-01): el mensaje
  apunta al directorio de voces de usuario implicado en vez de remitir a
  tts-sidecar setup (que no resuelve un problema de filesystem); conserva
  exit 3.
• speak --daemon --no-daemon (R-02): los flags contradictorios producen
  un error claro en stderr y exit 4 antes de cualquier trabajo, en vez de que
  --daemon gane en silencio.
• Validación de integridad de los tres checkpoints (R-07): is_model_cached
  valida el header safetensors también de s3gen_v3.safetensors y
  ve.safetensors (antes solo del T3): una descarga truncada de cualquiera se
  reporta como «no cacheado» y doctor remite a setup, en vez de reventar
  con un error críptico en el primer speak.
• Fixture mock_daemon_client alineada con el cliente real (R-10): la
  firma de synthesize coincide con DaemonIPCClient.synthesize
  (on_progress en vez de los inexistentes model/compute_backend).
• La detección de vida del daemon valida la identidad del servicio
  (auditoría de production-readiness): DaemonIPCClient.is_running ya no acepta
  cualquier 200 en /health, sino que valida el cuerpo contra HealthResponse;
  si otro servicio local ocupara el puerto 8765 y respondiera 200, ya no se
  confunde con un falso «daemon ya corriendo» (que derivaba en síntesis fallidas
  con exit 5 difícil de atribuir). DaemonManager delega en el mismo chequeo.
• Detección del Voice Encoder honra la revisión fijada del repo base
  (WARNING-01, residuo de R-06): is_ve_cached resuelve el snapshot del
  repo ResembleAI/chatterbox exclusivamente contra BASE_MODEL_REVISION (un
  VE de otra revisión ya no cuenta como caché válida), simétrico con la
  descarga de setup y con la rama del language pack. Cobertura nueva: caso
  positivo bajo BASE_MODEL_REVISION y caso negativo (revisión distinta) en
  tests/test_engine_cache.py. Párrafo de USAGE.md sobre actualización
  anclado al mecanismo real (revisión fijada por release + deduplicación por
  blob de la caché de HF).
• Decisión de validación E2E documentada (criterios 1-3, 9 de
  docs/GOAL.md): la validación end-to-end de los instaladores por SO es
  externa al pipeline por diseño (consume demasiada cuota de runner al cargar
  el modelo y los ~2 GB de pesos en cada build). El pipeline mantiene el smoke
  test automatizado del binario congelado. Fuera del pipeline: Windows la
  realiza el propietario sobre su equipo local; Linux y macOS dependen de
  feedback de usuarios reales. La decisión completa está en docs/GOAL.md
  §"Decisión de validación E2E" y docs/BUILD.md §"Verificación post-build".