🗂 NutriSync Sprint Planning · by Nutri-Engineering

Cómo se entrega cada cosa — no se elige aparte: lo dice el número de la release. Antes había un desplegable para esto y podía contradecir a la release; ahora hay una sola verdad.
🔄 OTA — 0.N.x con x>0 (0.21.1, 0.21.2…): JavaScript puro. Llega a las usuarias el mismo día, sin tiendas ni revisión.
📦 Nativa — 0.N.0 (0.22.0): toca dependencias nativas, permisos, iconos o config de tiendas. Build el miércoles, usuarias el viernes.
🌐 Web · continua — WEB: el carril del deploy web. Nunca «se publica» porque no para; lo que se termina son los items.
· Sin release — —: aún no comprometido a nada. No es que falte analizarlo: es que todavía no se ha decidido cuándo entra.

¿Y cómo se sabe en el triaje? Tres preguntas, en este orden — y si la tercera no está clara, se queda en «sin decidir», que es una respuesta legítima:
1️⃣ ¿El cambio vive en la web o en el hub? → WEB. Esto no es criterio, es ubicación: se sabe siempre.
2️⃣ ¿Pide una capacidad del teléfono que la app todavía no pide (cámara, galería, notificaciones, salud, biometría, ubicación), añade un módulo nativo, o toca icono, nombre, permisos o config de tiendas? → Nativa.
3️⃣ Si no, es JavaScript puro → OTA.
La trampa del paso 2 (10-ago, me costó un día): la pregunta NO es «¿está la librería en package.json?» sino «¿estaba en el último build nativo?». Una dependencia añadida después del build no existe en el móvil de la usuaria — el código la llama y no pasa nada. Se comprueba con git log -S"<paquete>" -- package.json contra la fecha del último build.