個人 GitHub 帳號下公開儲存庫的擁有者可以登入並驗證所有權,自行管理介紹,無需管理員核准。
登入並產生驗證檔案,在 30 分鐘內將其提交至此儲存庫的預設分支。其他分支或分叉儲存庫中的檔案無效。然後在下方檢查檔案,即可無需管理員核准直接管理專案。請保留檔案以維持管理權限。
如需登入,將前往登入頁面。登入後請回到此處,再次點擊所選的驗證按鈕。
在專案資料夾中執行 /nomorevibe verify,即可驗證所有權並自行管理介紹。
一分鐘完成驗證Qué sembrar y cuándo en el Gran Buenos Aires. PWA offline-first con el calendario de 55 especies afinado a períodos de 10 días y a tu zona del AMBA.
翻譯準備中
取自儲存庫 README
正在載入完整 README。 以下為已儲存的摘錄。
Una app para planificar y mantener una huerta casera en el Gran Buenos Aires. Se instala en el celular, funciona sin internet y no tiene cuentas, servidor ni nube: todo lo que cargás vive en tu aparato. Responde tres preguntas, que son las que uno se hace con tierra en las manos:檢視完整 README ↗
Una app para planificar y mantener una huerta casera en el Gran Buenos Aires. Se instala en el celular, funciona sin internet y no tiene cuentas, servidor ni nube: todo lo que cargás vive en tu aparato.
Responde tres preguntas, que son las que uno se hace con tierra en las manos:
No está en Play Store ni en App Store: es una PWA, se instala desde el navegador. Entrá a facundo-p.github.io/huertapp y seguí los pasos según el teléfono. (Los mismos pasos están dentro de la app, en Ajustes → Instalar en el celu.)
También puede aparecer un botón Instalar la app en Ajustes: es el mismo diálogo, más a mano.
En iOS hay que usar Safari — Chrome o Firefox en iPhone no pueden instalar PWAs, es una restricción del sistema.
Abre sin la barra de direcciones del navegador, y en Ajustes dice "Ya está instalada".
Todo se guarda en IndexedDB, en el navegador de ese aparato. No hay copia en ningún otro lado, y eso tiene una contra concreta:
Por eso el backup no es un extra. En Ajustes hay un botón que baja un único
archivo .json con todo adentro —plantas, diario y fotos en base64— y otro que
lo restaura. Guardátelo cada tanto donde uses: mail, Drive, lo que sea. El
archivo sirve solo, no necesita nada más para restaurarse.
Restaurar reemplaza todo lo que haya, y nunca lo hace sin confirmación: primero valida el archivo, después te muestra qué trae (cuántas plantas, cuántas entradas, cuántas fotos, de qué fecha) y recién ahí aparece el botón.
La app también le pide al navegador que no borre estos datos —la primera vez que cargás una planta, que es cuando hay algo que perder—, pero eso es una mejora de probabilidad, no una garantía. El backup sigue siendo la red de seguridad.
Se pueden prender en Ajustes, y son opcionales por diseño: la app no depende de ellos. Al abrirla, la pantalla Hoy siempre muestra lo pendiente.
| Dónde | Qué pasa |
|---|---|
| Android + Chrome, instalada | Anda. Un aviso por día como mucho, y solo los días en que aparece algo nuevo. La hora la decide el navegador. |
| Android, en una pestaña común | No. El navegador no despierta una pestaña. |
| iPhone / iPad | No. iOS no implementa Periodic Background Sync: una PWA instalada no puede despertarse sola. No hay forma de darle la vuelta sin un servidor de push. |
| Escritorio (Chrome/Edge) | Igual que Android instalada. |
Las 55 especies salen de una base de conocimiento investigada aparte
(data/huerta_gba.json): cada campo tiene su valor, sus fuentes con URL
y un índice de confianza del 1 al 10, todo accesible desde la ficha. INTA,
ProHuerta, UNLu, UNLP, FAUBA, universidades y extensiones agrícolas.
Sobre esa base, la app agrega dos capas —y la diferencia entre ellas está a la vista en todas partes:
1. Lo que dijeron las fuentes. Los meses de siembra y trasplante, tal cual se derivaron de los textos. Es la capa citable y no se toca nunca.
2. El afinado a décadas. Las fuentes hablan en meses, pero no es lo mismo sembrar a principios que a fines de septiembre. Un modelo climático del GBA —construido sobre las normales 1991–2020 del SMN y la estadística de heladas de FAUBA (umbral agrometeorológico de 3 °C, series de 50 a 63 años)— recorta esos meses a períodos de 10 días, que es la unidad decádica que usa INTA.
La regla de oro que hace todo esto defendible: el modelo solo puede recortar lo
que dijeron las fuentes, nunca agregar. Está verificada por un test sobre las
66 entradas del catálogo × 3 zonas, y el build falla si alguna década se sale de los meses de
origen, variedades incluidas. Cada recorte queda registrado con su regla y su motivo en
data/REVISION_CALENDARIO.md.
Precisión honesta del afinado: ±10 días. Va declarado en el glosario y al pie de cada ficha, y nunca se presenta como dato de fuente.
Las tres zonas importan. Dentro del AMBA la última helada cambia 71 días entre el centro porteño y La Plata. Sin elegir zona, la precisión sub-mensual le erraría a media ciudad. Se elige en Ajustes; por defecto, Conurbano.
npm install
npm run dev # servidor de desarrollo (sin service worker, a propósito)
npm run build # dist/ listo para cualquier hosting estático
npm run preview # sirve dist/ en :4173; los e2e lo levantan solos, no lo dejes corriendo
| Comando | Qué hace |
|---|---|
npm test | Más de mil tests de lógica pura con vitest: modelo climático, afinado del calendario, motor de tareas, agenda de avisos, estimaciones. |
npm run e2e | Playwright: backup de ida y vuelta, offline real, flujo de actualización, y accesibilidad en todas las pantallas. |
npm run shots | Screenshots en 390×844 para revisión visual (e2e/shots/). |
npm run data:build | Regenera data/huerta_gba_enriquecido.json desde el JSON base + el enriquecimiento + el modelo climático. |
npm run data:tabla | Regenera data/REVISION_CALENDARIO.md para revisar el calendario a mano. |
npm run iconos | Regenera los PNG del ícono desde scripts/icono-app.mjs. |
HashRouter y base: './' → anda en
cualquier hosting estático, en cualquier subcarpeta, sin configurar rutas.scripts/sw.js + scripts/plugins-build.mjs), sin
Workbox: la app es estática y con nombres hasheados, así que la estrategia son
tres decisiones que caben en 100 líneas legibles. Precache total en install,
cache primero, y la versión nueva nunca se activa sola —espera a que la
persona la acepte.idb. Las fotos van como Blobs, redimensionadas a 1280 px y
convertidas a webp al guardar.src/theme.css. Sin librerías de
componentes.currentColor). El Glosario los explica todos.Números del build: 1516 KB precacheados (el catálogo es la mayor parte), 1,6 s hasta contenido útil en la primera visita simulando un teléfono medio (CPU 4× más lenta, 1,6 Mbps), 0,15 s de ahí en adelante.
Cada push a main dispara .github/workflows/publicar.yml, que en una máquina
limpia corre npm ci, más de mil tests unitarios + el chequeo de que el
JSON generado esté al día, los e2e (offline y actualización incluidos), y
recién ahí buildea y publica en GitHub Pages.
Los e2e antes del deploy no son ceremonia: un service worker roto le deja una pantalla en blanco a quien ya tiene la app instalada, y esa persona no lo puede arreglar desde su lado. Dos minutos de Playwright son el seguro.
dist/ nunca se commitea. El repo guarda código fuente y GitHub arma el resto.
Para republicar sin cambios, "Run workflow" en la pestaña Actions.
Notas del hosting:
…github.io/**huertapp**/ porque en una Page de proyecto la ruta
es el nombre del repo. Cambiar el nombre cambia la URL, y eso rompe las
instalaciones existentes: para el navegador, otro origen es otra app, con
otro service worker y otra base de datos. Los datos se mudan con el backup.github.io y se
configura en Pages con dos clicks — pero conviene decidirlo antes de que
la URL circule, por lo mismo del punto anterior.No es una pasada final: e2e/accesibilidad.spec.ts recorre todas las
pantallas y falla si algo baja. El contraste lo mide en los dos temas y con
datos cargados; el foco, en los dos temas y sin datos, con un Tab por ruta de
partida. Lo que se abre tocando, como Planta o Compostera, queda sin medir el
foco.
Dicho de frente, porque son decisiones y no pendientes: