Espacio de investigación independiente de cartridge-builder/ (que es autoría de contenido de
cartuchos) y de src/ (la app en producción). Aquí se estudian preguntas sin respuesta obvia
sobre cómo llevar una vertical del concepto a la realidad — tanto de infraestructura técnica (qué
plataforma/hardware haría viable el transporte del mensaje) como de producto/validación (qué es
lo mínimo que tiene sentido llevar a un experto de dominio para saber si el concepto sirve).
Cada pregunta de investigación es un notebook markdown independiente, con fecha de última actualización, fuentes citadas, y una sección de experimentos/resultados que se va ampliando con el tiempo — no son informes cerrados.
notebook-infraestructura-transporte.md — qué canal
de comunicación entre dispositivos (más allá del acústico actual) haría viable el cartucho de
Situaciones Críticas a escala real. Conclusión inicial: ninguna alternativa "sin instalar nada"
(BLE/NFC/Wi-Fi Direct) es viable en iOS por restricciones de Apple; el acústico sigue siendo la
única vía cross-platform de coste cero — el camino real pasa por rediseñar su patrón de uso a
"baliza", aceptar un wrapper nativo para BLE real, o hardware LoRa dedicado para escala real.
Caso extremo estudiado (víctima bajo escombros/terremoto): "que lo oigan los perros" choca con
el techo real del altavoz de un móvil (~20kHz, los silbatos de rescate necesitan 23-54kHz); el
hallazgo más fuerte fue que la vibración transmitida al material llega 3-6x más lejos que
el sonido por el aire a través de escombros — viable hoy solo en Android (navigator.vibrate()
no es fiable en segundo plano en iOS). Probado en Android real (07-09-2026): el patrón SOS se
reconoce bien, pero el bucle se corta al bloquear/apagar la pantalla — límite "web vs. nativo",
no arreglable ni instalando el PWA. Última vía documentada: un wearable programable dedicado
(PineTime o LILYGO T-Watch, 25-40€) elimina el problema de raíz al no depender de ningún
navegador — compra de hardware pospuesta, queda como candidato principal para cuando se retome.
notebook-mvp-validacion-institucional.md — qué es lo mínimo que tiene sentido enseñarle a un consorcio de bomberos/rescate real (tipo el de Huelva, usado como ejemplo del tipo de institución, sin contacto aún) para validar el concepto con expertos de dominio, no para venderles ni pilotar nada. No requiere construir nada nuevo: el cartucho de Situaciones Críticas + la demo acústica ya existen — el "MVP" es el guion de la sesión de validación y cómo recoger el feedback. Incluye vía de entrada investigada (el departamento de Formación de estos consorcios es el punto de contacto realista, no compras/ contratación) y qué NO prometer todavía (nada de lo aprendido en el notebook de infraestructura de transporte está listo para un despliegue real).
notebook-protocolos-transporte-verticales.md — catálogo de mercado de protocolos de transporte físico (BLE, Zigbee/Thread, UWB, LoRa/Meshtastic/MeshCore, Sigfox/ NB-IoT/LTE-M, Wi-Fi HaLow, TETRA/DMR/APRS, VLF Through-the-Earth minero, acústica submarina profesional y open-source, satelital Iridium/Swarm/Myriota/Astrocast/Starlink D2C/Inmarsat, Link 16/22 militar) con ficha técnica, literatura citada, y a qué vertical (V1 Situaciones Críticas, V2 Minería, V3 Submarinos, V4 Satélite/UAV, V5 Defensa) encaja cada uno — ordenados de menos a más costoso. Distinto del notebook de infraestructura de transporte: aquel acota "qué puede hacer una PWA sin instalar nada"; este cataloga el protocolo de mercado en sí, con o sin wrapper nativo/hardware dedicado. Incluye además un barrido de otras verticales de mercado candidatas (avalancha/SAR alpino, espeleología, ferrocarril, marítimo/EPIRB, aviación general/ELT, energía, construcción) y por qué las verticales de consumo ya retiradas del producto (Hostelería, Esports) no encajan en esta lente de canal degradado.
notebook-vocabulario-catalogo.md — cuánta redundancia real
tiene el catálogo actual de 10.000 códigos (4D) y qué matices podría rellenar el propio
dispositivo en vez del humano. Medido sobre el código real: de 10.000 códigos posibles, solo
3.700 (37%) producen una frase distinta — el resto duplica el texto exacto de otro código,
sobre todo por matices sin contenido propio todavía en cartridgeContent.ts. De los 10 matices,
solo "Recursos Agotados" (nivel de batería) y "En Curso"/"Retraso" (tiempo transcurrido) son
buenos candidatos a auto-rellenar por telemetría del dispositivo; el resto debe seguir siendo
elección humana, y "Situación Resuelta" no debe auto-inferirse nunca por el coste de un falso
positivo en un sistema de emergencias.
informe-piloto-lora-meshtastic.md — plan de ejecución (no notebook
de investigación abierta) para llevar la conclusión del notebook de infraestructura a un piloto real:
fases, pasos concretos, presupuesto (~50-90€ + 1-2 semanas de ingeniería), riesgos y criterios de
éxito/go-no-go para que la PWA de NumChat hable con dos nodos LoRa (Heltec LoRa32 V3 + firmware Meshtastic
oficial) vía Bluetooth, usando la librería oficial @meshtastic/js (soporta Web Bluetooth directamente
desde el navegador, sin wrapper nativo) — y mida el alcance real conseguido.