Saltar a contenido

Log — Smart Home 2026

Historial append-only de ingests y lints. Formato: ## YYYY-MM-DD HH:MM — tipo.

2026-05-20 — init

Proyecto creado desde plantillas vía scripts/new-project.sh "Smart Home 2026" (layout=nested, hot=no).

2026-05-20 — scope definido

  • CLAUDE.md completado: scope, 10 preguntas guía, notas locales del usuario.
  • Contexto anclado: HA Yellow + Zigbee/BLE/WiFi + ESPHome custom; k8s descartado; frustración con upgrades HA.
  • Tracks serios: HA hardeneado y custom from-scratch.
  • Out of scope: openHAB/Hubitat/Apple Home como tracks (sólo referencia), voice LLMs locales, reviews de productos.
  • AI angle en scope: dev tooling (Claude Code, agentes IaC) + runtime automation reasoning.
  • gaps.md sembrado: 4 alta prioridad (essentials/experimental arch, HA upgrade reliability, custom reference arch, trade-off matrix), 10 media, 4 baja.
  • Sources candidatos vacíos — pendiente correr /discover smart-home-2026.

2026-05-20 — discover (pasada exhaustiva)

  • Heurísticas: H1 (0 — no hay raw/), H2 (0 — no hay entities/), H3 (0 — no hay concepts/), H4 (10 preguntas guía cubiertas), H5 (related work del dominio).
  • Búsquedas web: ~22 queries paralelas cubriendo upgrade reliability, hardening, IaC, testing, observability, custom orchestrators Python, LLM agents runtime, Matter 2026, HA Yellow migration, Claude Code workflows, anomaly detection, VLAN.
  • Candidatos únicos tras dedup: 78 distribuidos como 29 alta / 38 media / 11 baja.
  • Sources canónicos clave identificados: HA dev docs (testing, LLM API), HA blog oficial (deprecating supervised, AI in HA, SOTOH 2026), Open Home Foundation newsletter, repos Python alternativos (smarthomeconnect, smarthomeNG), repos AI-on-HA (madebynathan, Dan Malone series, philippb/dcb claude kits), papers ICSE26/ICLR26/MDPI sobre runtime safety y edge anomaly detection.
  • Postmortems del dolor del usuario: 2 community threads sobre upgrades rotos (2026.2.3 y stuck-from-aug-2025).
  • Descartados como duplicados: ~12 (varias búsquedas devolvieron las mismas URLs canónicas).
  • Sugerencia: /deepen smart-home-2026 empezará por candidatos alta prioridad. Top picks recomendados para arrancar: (a) HA blog "Deprecating Supervised" + 2 postmortems community (Q2 base), (b) madebynathan self-healing + Dan Malone AI patterns (Q10 reference architecture), (c) smarthomeconnect + smarthomeNG (Q6 custom track).

2026-05-20 — deepen #1: SOTOH 2026 recap

  • Candidato resuelto: openhomefoundation.org/blog/building-whats-next-state-of-the-open-home-2026/ (alta).
  • Source guardado: raw/state-of-the-open-home-2026.md (verbatim, fetched via WebFetch).
  • Páginas creadas (8): sources/state-of-the-open-home-2026, entities/open-home-foundation, entities/paulus-schoutsen, entities/nabu-casa, entities/apollo-automation, entities/home-assistant-labs (stub), concepts/state-of-the-open-home, concepts/building-in-the-open.
  • Index actualizado con las 8 entradas.
  • Gaps cerrados: 1 (movido a "Resueltos").
  • Gaps nuevos detectados (todos media o baja): entities/home-assistant.md por crear; entities/esphome.md por crear; ingerir SOTOH 2025 recap; aclarar qué es "Sendspin"; conseguir URL canónica de la public GitHub roadmap; ingerir anuncio detallado del ESPHome Starter Kit (Apollo).
  • Caveat: lint con obsidian CLI no disponible en container remoto; verificación manual de wikilinks completada.
  • Iteraciones hasta próximo lint completo: 4 (lint cada 5).

2026-05-20 — deepen #2: HA Deprecating Core/Supervised 2025-05

  • Candidato resuelto: home-assistant.io/blog/2025/05/22/deprecating-core-and-supervised-installation-methods-and-32-bit-systems/ (alta).
  • Source guardado: raw/ha-deprecating-core-supervised-2025-05.md (verbatim).
  • Páginas creadas (8):
  • sources/ha-deprecating-core-supervised-2025-05
  • entities/home-assistant (stub central, resuelve un gap previo)
  • entities/home-assistant-os
  • entities/home-assistant-container
  • entities/home-assistant-supervised (marcada deprecated)
  • entities/home-assistant-core (marcada deprecated)
  • comparisons/ha-install-methods-2026 (matriz comparativa)
  • analysis/install-method-decision-2026 (recomendación condicional para el setup del usuario)
  • Index actualizado: 5 entities nuevas, 1 comparison, 1 analysis.
  • Decisión de arquitectura propuesta (primera del wiki): essentials en HAOS sobre el Yellow + experimental en HA Container en otro nodo.
  • Gaps cerrados: 2 (candidato + entities/home-assistant stub).
  • Gaps nuevos detectados: validar que el Yellow sigue recibiendo updates HAOS, encontrar ejemplo público "2 HA instances via MQTT bridge", cuantificar costo de migración Container, source canónico de "release notes del OS" separado.
  • Iteraciones hasta próximo lint completo: 3.

2026-05-20 — deepen #3: Mastering HA Updates and Rollbacks

  • Candidato resuelto: newerest.space/mastering-ha-updates-rollbacks/ (alta).
  • Source guardado: raw/mastering-ha-updates-rollbacks.md (verbatim).
  • Páginas creadas (7):
  • sources/mastering-ha-updates-rollbacks
  • concepts/ha-update-channels (stable/beta/dev)
  • techniques/ha-pre-update-checklist (5 pasos)
  • techniques/ha-rollback-procedure (full restore vs core-only)
  • techniques/ha-update-best-practices (4 reglas)
  • tools/ha-cli (ha core/supervisor/os update)
  • analysis/ha-upgrade-reliability-strategy (síntesis 4 capas para el setup del usuario, con métricas)
  • Subdirs nuevos: wiki/techniques/, wiki/tools/.
  • Index actualizado: 1 source, 1 concept, 3 techniques, 1 tool, 1 analysis.
  • Esta iteración cruzó el umbral conceptual de la pregunta guía Q2 (upgrade reliability) — primera estrategia operativa en wiki.
  • Gaps nuevos: rollback de DB externa, equivalente Container del ha CLI, auto-rollback en boot fallido (¿existe?), tracking metric "% upgrades con pre-checklist".
  • Iteraciones hasta próximo lint completo: 2.

2026-05-20 — deepen #4: postmortem "Stuck HAOS 10.5 April 2026"

  • Candidato resuelto: community.home-assistant.io/.../stuck-at-versions-from-august-2025-its-now-april-2026/1003086 (alta).
  • Skip aplicado: bajé tecnoyfoto.com/.../how-to-safely-update-home-assistant-2026 de alta a media (cubre los mismos pasos que mastering-ha-updates-rollbacks ya ingerido).
  • Source guardado: raw/community-stuck-haos-april-2026.md (verbatim del thread).
  • Páginas creadas (2):
  • sources/community-stuck-haos-april-2026
  • analysis/failure-mode-stuck-haos-update-mechanism (primera entrada del catálogo de failure modes)
  • Páginas actualizadas (3):
  • tools/ha-cli: añadido bloque "Recovery: forzar HAOS desestancado" con ha os update --version 17.2.
  • analysis/ha-upgrade-reliability-strategy: añadidas 2 métricas (días desde último upgrade, gap de versión vs latest); failure modes catalog ya tiene primera entrada.
  • Index: 1 source, 1 analysis.
  • Primera evidencia real del dolor del usuario documentada en wiki (no opinión, postmortem concreto).
  • Gaps nuevos: buscar GitHub issue trackeando el failure mode UI-no-ofrece-upgrade-path; buscar otros postmortems del mismo tipo para frecuencia; definir healthcheck script.
  • Iteraciones hasta próximo lint completo: 1.

2026-05-20 — deepen #5: postmortem "2026.2.3 upgrade failure"

  • Candidato resuelto: community.home-assistant.io/.../home-assistant-stops-working-completely-after-upgrade-from-2026-2-3/1003189 (alta).
  • Source guardado: raw/community-2026-2-3-upgrade-failure.md (calidad delgada — OP cerró sin confirmar fix).
  • Páginas creadas (2):
  • sources/community-2026-2-3-upgrade-failure (marcado quality: thin)
  • analysis/failure-mode-hardware-support-cutoff (segunda entrada del catálogo)
  • Index actualizado.
  • Datapoint nuevo (a confirmar): cutoff de hardware support para generic-x86-64 sería 2026.4.1.
  • Catálogo de failure modes ahora con 2 entradas — patrones distintos (UI-no-ofrece-path vs hardware-cutoff). Comparativa explícita en la página nueva.
  • Iteraciones hasta próximo lint completo: 0 → corre lint ahora.

2026-05-20 — lint completo (post-deepen #5)

Hecho manualmente por falta de obsidian CLI en este container.

  • Páginas totales: 27 (5 sources, 3 concepts, 11 entities, 1 comparison, 4 analysis, 3 techniques, 1 tool — más index y log).
  • Wikilinks unresolved detectados: 2 → ambos reparados:
  • [[ha-update-order]] (referenciado desde ha-update-best-practices.md): aplanado a referencia textual de [ha-pre-update-checklist](<concepts/ha-pre-update-checklist.md>) (la página fue subsumida).
  • [hacs](<entities/hacs.md>) (referenciado desde ha-pre-update-checklist.md): creada entities/hacs.md como stub. Agregada al index.
  • Orphans (páginas sin backlinks): 0. Mínimo: entities/hacs.md con 1 backlink antes del index, 2 después.
  • "Página por crear" residuales limpiados:
  • entities/paulus-schoutsen.md: removido "(página por crear)" detrás de [home-assistant](<entities/home-assistant.md>) ahora que la página existe; también removido el gap interno "Crear entities/home-assistant.md".
  • techniques/ha-pre-update-checklist.md: [hacs](<entities/hacs.md>) ya resuelve, removido el annotation.
  • Gaps formalizados como entradas en gaps.md durante la limpieza:
  • entities/esphome.md por crear (referenciado en 3 páginas como "página por crear").
  • Contradicciones: ninguna detectada entre páginas existentes. Los dos failure modes catalogados son complementarios, no contradictorios (página failure-mode-hardware-support-cutoff tiene tabla explícita de diferenciación).
  • Web search durante lint: no aplicado (ninguna entrada de gaps pidió explícitamente "buscar web para resolver esto ahora").
  • Estado del proyecto tras lint:
  • Q2 (HA upgrade reliability): cobertura operativa. Estrategia en ../analysis/ha-upgrade-reliability-strategy con 2 entradas de failure modes catalogadas. Falta integrar HACS-specific.
  • Q1, Q3-Q10: pendientes — sólo Q1 tiene el esqueleto vía ../analysis/install-method-decision-2026.
  • Próximos pasos sugeridos: continuar /deepen con candidatos alta restantes — HA dev docs testing, HA Prometheus exporter, repos Claude-on-HA (Beguelin / Dan Malone), repos Python alternativos (smarthomeconnect / smarthomeNG).

2026-05-20 — deepen #6: madebynathan self-healing 2026-02 (PARCIAL)

  • Candidato resuelto parcial: madebynathan.com/.../self-healing-infrastructure-how-an-ai-agent-manages-my-home-server-2/ (alta).
  • Source guardado: raw/madebynathan-self-healing-2026-02.md.
  • Páginas creadas (5):
  • sources/madebynathan-self-healing-2026-02
  • entities/openclaw, entities/gatus
  • concepts/self-healing-infrastructure (loop de 6 pasos, 5 capas reusables, adopción incremental)
  • concepts/ai-as-operator (perímetro autónomo / approval / prohibido)
  • concepts/everything-is-code (audit trail, rollback, reproducibilidad)
  • Index actualizado.
  • Páginas pendientes (NO escritas en esta iteración):
  • analysis/self-healing-adapted-to-user-setup
  • analysis/q10-ai-tooling-strategy-v1
  • Motivo del corte: usuario mensaje 2026-05-20 — "I could build another k8s cluster if it makes sense". La adaptación de la reference architecture depende directamente de si k8s vuelve o no a la mesa. Páginas de análisis bloqueadas hasta decisión.
  • Gaps nuevos: ingerir repo openclaw/openclaw, HN thread crítico de madebynathan, repo público ndbroadbent/homeserver-terraform-ansible-public.

2026-05-20 — decisión usuario + cierre deepen #6

  • Decisión del usuario (2026-05-20): k8s queda OUT definitivamente. Meta operativa explicitada: "smart home invisible, no tinkering, agent-managed".
  • CLAUDE.md del proyecto actualizado: nueva sección "Meta operativa explícita" + "Anti-goal" + "k8s finalizado: OUT" en Notas locales. Énfasis: subir prioridad de Q10 (agent ops) sobre Q7 (LLM en runtime).
  • Páginas previamente pendientes — escritas:
  • analysis/self-healing-adapted-to-user-setup: arquitectura sin k8s (HA Yellow essentials + mini-PC experimental con Docker Compose + observability + agente). 5 capas traducidas, adopción incremental 7 pasos, métricas alineadas a "invisible".
  • analysis/q10-ai-tooling-strategy-v1: rol del agente, 3 opciones de stack (Claude Code+cron / SDK custom / OpenClaw), trayectoria mes 1 → mes 12 de perímetro autónomo, lista negra explícita.
  • Index actualizado con los 2 analysis nuevos.
  • Iteración #6 ahora cerrada completa (7/7 páginas).
  • Iteraciones hasta próximo lint completo: 4 (lint cada 5).

2026-05-20 — fix: layout no-conformante (techniques/ y tools/ → concepts/ y entities/)

  • Problema detectado (feedback del usuario 2026-05-20): se habían creado dos subcarpetas no-conformes con el template del root CLAUDE.md (wiki/techniques/ y wiki/tools/). El layout nested estándar usa sólo concepts/ entities/ analysis/ sources/ comparisons/.
  • Reparación:
  • wiki/techniques/ha-pre-update-checklist.md → wiki/concepts/ha-pre-update-checklist.md
  • wiki/techniques/ha-rollback-procedure.md → wiki/concepts/ha-rollback-procedure.md
  • wiki/techniques/ha-update-best-practices.md → wiki/concepts/ha-update-best-practices.md
  • wiki/tools/ha-cli.md → wiki/entities/ha-cli.md
  • Subcarpetas techniques/ y tools/ eliminadas (vacías).
  • Wikilinks actualizados en todas las páginas con sed.
  • Index actualizado: las secciones "Herramientas" y "Técnicas" se mantienen como categorización lógica en el index, pero los wikilinks ahora apuntan a entities/ y concepts/ respectivamente.
  • Notas residuales en gaps.md también actualizadas.
  • Estado post-fix: 27 páginas distribuidas en los 5 subdirs canónicos (sources/, concepts/, entities/, comparisons/, analysis/).
  • Causa raíz del error (nota para futuras sesiones / lints): el template templates/wiki-page.md lista tool y technique como types válidos del frontmatter. Extrapolé (mal) que merecían subdirs propios. El root CLAUDE.md sólo prescribe concepts/ entities/ analysis/ (+ sources/, comparisons/ por convención). Los type: tool van en entities/; los type: technique van en concepts/. No crear subdirs nuevos sin autorización explícita.
  • Descartada otra hipótesis: el usuario sugirió que Obsidian podría haber movido archivos. Verificación: no hay community plugins instalados (projects/.obsidian/community-plugins.json ausente), y git history muestra que los 4 commits que tocaron techniques/ y tools/ son todos del agente, sin sync mobile intermedio.

2026-05-20 — fix: ghost files de Obsidian Mobile en projects/ raíz

  • Problema detectado (segundo feedback del usuario con screenshot de filesystem móvil 2026-05-20 15:08): existían 3 archivos vacíos (0 bytes) en rutas equivocadas a nivel de projects/:
  • projects/analysis/install-method-decision-2026.md
  • projects/concepts/building-in-the-open.md
  • projects/sources/state-of-the-open-home-2026.md
  • Origen confirmado: commit daaa7ba "Last Sync: 2026-05-20 11:01 (Mobile)" — los introdujo el sync de Obsidian Mobile. git show --stat daaa7ba lo confirma: 3 archivos, 0 insertions, 0 deletions.
  • Causa probable: Obsidian Mobile encontró wikilinks bare (sin path completo) como [install-method-decision-2026](<analysis/install-method-decision-2026.md>), [building-in-the-open](<concepts/building-in-the-open.md>), [state-of-the-open-home-2026](<sources/state-of-the-open-home-2026.md>) en alguna página y, al no resolverlos correctamente o al ser tocados accidentalmente en el teléfono, los creó como stubs vacíos en su "default location for new notes" que en el vault es la raíz projects/.
  • Fix: git rm de los 3 archivos + rmdir de las 3 carpetas vacías huérfanas (projects/analysis/, projects/concepts/, projects/sources/).
  • Corrección a la entrada anterior: la hipótesis "Obsidian no fue" era incorrecta — fue Obsidian Mobile específicamente, vía sync. Mi find previo no las mostró porque corrí el comando antes de que estos archivos existieran localmente en este container (el sync mobile committeó tarde).
  • Recomendación al usuario: cambiar en Obsidian Mobile la setting Files & Links → Default location for new notes de "Vault root" a "Same folder as current file" o "Specified folder" apuntando a un staging area, para evitar que clicks accidentales en wikilinks no resueltos creen stubs en la raíz del vault. También revisar Files & Links → New link format — preferir "Absolute path in vault" para que los wikilinks resuelvan correctamente desde mobile.

2026-05-20 — deepens #7-10 + lint (Matter/Zigbee, observability)

  • #7 — Matter status review 2026 (matter-smarthome.de): 4 páginas (raw + source + entities/matter + entities/thread). Conclusión: Matter no maduro suficiente para reemplazar Zigbee; Zigbee gana en battery y maduración.
  • #8 — Zigbee vs Matter decisión: 1 source thin (arxiv) + comparison page de decisión por categoría de device. Estrategia: no migrar Zigbee actual; Matter selectivamente para devices nuevos vía twin.
  • #9 — ZHA vs Z2M 2026 (ordoh.com): 6 páginas (source + 3 entities + comparison + cierre del gap entities/zigbee). Decisión: quedarse en Z2M.
  • #10 — Observabilidad (newerest.space Loki+Grafana): 3 páginas (source + concepts/centralized-logging-stack + analysis/q5-observability-stack-v1).
  • LINT completo post #10:
  • Wikilinks unresolved detectados: [../analysis/self-healing-without-k8s](<../../analysis/self-healing-without-k8s>) (link stale, página fue renombrada). 2 referencias fixed → self-healing-adapted-to-user-setup.
  • [dan-malone](<entities/dan-malone.md>) sin destino — creada página stub entities/dan-malone.md.
  • [../analysis/q5-observability-stack-v1](<../../analysis/q5-observability-stack-v1>) referenciado pero no escrito — escrito acá.
  • 2 falsos positivos del script: [../../CLAUDE.md](<../../../CLAUDE.md>) (resuelve correctamente) y mention de [[ha-update-order]] en log (documentación histórica, no link real).
  • 0 orphans. 0 unresolved reales post-fix.
  • Páginas totales: 42 (sources 9, concepts 8, entities 16, comparisons 3, analysis 6).
  • Estado de cobertura por pregunta guía:
  • Q1 (essentials/experimental): cubierto en install-method-decision + self-healing-adapted.
  • Q2 (HA upgrade reliability): cubierto operativamente.
  • Q3 (IaC): pendiente — próximo iter Ansible role.
  • Q4 (testing/twin): gap registrado, no iniciado.
  • Q5 (observability): cubierto v1 — falta HA Prometheus exporter source.
  • Q6 (custom from-scratch): pendiente.
  • Q7 (LLM runtime): pendiente — los principios de Q10 lo prefiguran.
  • Q8 (Matter/Thread): cubierto operativamente.
  • Q9 (Zigbee migration path): cubierto vía ZHA vs Z2M.
  • Q10 (AI tooling): cubierto v1 — falta ingest de Beguelin y Dan Malone series.
  • Iteraciones hasta próximo lint completo: 5.

2026-05-20 — deepens #11-16 + lint final

  • #11 — HA Prometheus integration docs (Q5 cierre métricas).
  • #12 — Beguelin Claude Code para HA (Q10 workflow real con MCP + scp + skills files).
  • #13 — Dan Malone AI patterns para HA (Q10 multi-agent quarterly + dead code detection).
  • #14 — HA developer testing docs + analysis/q4-testing-strategy-v1 (5 capas: static → unit → twin → smoke → multi-agent).
  • #15 — Ansible role oficial HA + analysis/q3-iac-strategy-v1 (plan IaC sin k8s, repo layout, adopción incremental).
  • #16 — Sin nuevo source: analysis/sensor-recommendations-2026 (pragmáticas por categoría) + analysis/recommendations-master (síntesis ejecutiva con plan 90 días).
  • Lint post-#15:
  • 4 unresolved reales fixed: [../entities/pytest-ha](<../../entities/pytest-ha>) → plain text, [...](<../../wiki>) → plain text, [[home-assistant-mcp]] → plain text. ([../analysis/self-healing-without-k8s](<../../analysis/self-healing-without-k8s>) solo aparece como historical text dentro de backticks en log, OK.)
  • 2 falsos positivos del script: [../../CLAUDE.md](<../../../CLAUDE.md>) (resuelve correctamente al CLAUDE.md del proyecto), ha-update-order (historical mention en log).
  • 0 unresolved reales post-fix.
  • Páginas totales: 59 (12 sources, 9 concepts, 16 entities, 3 comparisons, 9 analysis, log, index).
  • Cobertura final de preguntas guía:
  • Q1 essentials/experimental: cerrada en recommendations-master + self-healing-adapted.
  • Q2 HA upgrade reliability: cerrada operativamente + 2 failure modes en catálogo.
  • Q3 IaC: cerrada v1.
  • Q4 testing: cerrada v1 con 5 capas.
  • Q5 observability: cerrada v1.
  • Q6 custom from-scratch: postergada (solo se ataca si Q2 falla en producción real).
  • Q7 LLM en runtime: postergada (después de Q10 maduro).
  • Q8 Matter/Zigbee: cerrada operativamente.
  • Q9 migration path: cerrada (Zigbee se queda, Z2M se queda).
  • Q10 AI tooling: cerrada v1 + 2 referencias reales (Beguelin, Dan Malone).
  • Estado: el wiki responde el 80% del scope original con recomendaciones accionables. Pendientes ordenados en gaps.md.

2026-05-20 — gap BLE detectado + cubierto

  • Usuario preguntó "¿y Bluetooth? SwitchBot opera en BLE" — gap real, BLE no estaba documentado.
  • Creadas entities/bluetooth-le y entities/switchbot.
  • Updates a sensor-recommendations-2026 (categoría Retrofit BLE) y recommendations-master.

2026-05-20 — iteraciones 17-23: expansión hasta cerrar gaps materiales

Tras el resumen detallado, el usuario pidió "continúa iterando hasta cerrar todos los gaps". 7 deepens más + lint final:

  • #17 — Failure modes catalog +4 (Z2M coordinator lost, HACS broken, recorder DB bloat, sensor stale). Cada uno con manifestación, detección proactiva, recovery, prevención, perímetro del agente.
  • #18 — HA AI 2025-09 + Q7 strategy v1. AI Task entity, MCP bidireccional, patrón "AI propone + determinista valida", plan de adopción gradual con cost-budget.
  • #19 — Q6 evaluado y descartado. SHC + smarthomeNG + otros — no hay alternativa viable a HA en 2026. Criterios objetivos para reabrir documentados.
  • #20 — ESPHome bluetooth_proxy docs + pattern. Cierra el gap "patrón concreto" mencionado en entities/bluetooth-le.
  • #21 — bellack Ansible role. Reemplaza el rol oficial deprecated. Bidireccional vía HA API. Q3 strategy actualizada.
  • #22 — 3 técnicas operativas + entities/ai-task. coordinator-backup-automated, drift-detection, agent-system-prompt-template (skills file ready-to-copy).
  • #23 — Failure mode #7 automation loop + update de recommendations-master.
  • Lint final post-#22: 1 unresolved fixed (entities/ai-task creada). 79 páginas totales, 0 wikilinks unresolved reales.
  • Cobertura final:
  • Q1-Q10: TODAS las 10 preguntas guía con análisis v1 escrito.
  • Failure modes: 7 entradas catalogadas (vs 2 al final del primer batch).
  • Técnicas operativas: backup, drift, agent prompt, BLE proxy pattern — ejecutables.
  • Recommendations master: actualizado con todos los pendientes resueltos.
  • Gaps remaining (intencionalmente):
  • Inventario real del usuario (lo provee él).
  • Templates específicos agent/playbooks/*.md y docs/critical-sensors.yaml (se llenan al deploy).
  • Sendspin (mención vaga en SOTOH 2026).
  • Linter para automation loops pre-deploy (gap conocido).
  • Re-evaluar Q6 en 12 meses si HA falla.
  • Sin más gaps materiales que cerrar sin info adicional del usuario o sin un setup real corriendo.