Notas de versión · Releases

Resumen en español La app ya te decía las ráfagas de viento, pero en una sola línea del resumen “Para hoy”, mirando solo el viento de ahora mismo y sin decirte qué hacer con ese dato. Faltaba lo importante: mirar hacia adelante y, cuando el viento arrecia de verdad, traducirlo a qué esperar y cómo prepararte. Eso hace la tarjeta nueva, “Vientos fuertes”: revisa el viento que queda de hoy —hora por hora, del mismo pronóstico en vivo— y solo aparece cuando de verdad va a estar ventoso. Te dice cuándo arrecia (“desde ahora hasta las 4 pm”), cuán fuerte (viento sostenido y ráfagas en mph) y, según el nivel, qué hacer: amarrar lo que el viento pueda volar (rótulos, toldos, plantas, basura), manejar con cuidado si vas en guagua alta o cruzas áreas abiertas y —cuando el viento es de los que tumban ramas y líneas— prepararte por si se va la luz: cargar los celulares y una batería, tener agua a mano, ubicar la linterna. En Puerto Rico la red eléctrica es frágil y el viento es su tumba-postes más común, así que ese aviso de preparación pesa. No cuesta ni una llamada nueva: reusa el viento que el pronóstico ya trae. Es una guía de preparación, no un aviso oficial ni una predicción de apagón.

What changed

A new card, “Vientos fuertes,” appears whenever the day’s remaining forecast turns genuinely windy. It reads the hourly sustained wind for the rest of today (the same live Open-Meteo forecast the app already fetches), and when the peak crosses a real threshold it states three things in plain Puerto Rican Spanish: when the wind picks up (“desde ahora hasta las 4 pm,” or “alrededor de las 2 pm”), how strong it gets (sustained mph plus the day’s peak gust), and what to do about it, scaled to severity. Three tiers: ventoso (25+ mph sustained → tie down loose objects, drive carefully in a high-profile vehicle or across open bridges); vientos fuertes (32+ mph → branches can fall on lines and knock out power in spots, so it adds outage prep: charge phones and a power bank, keep water on hand, locate the flashlight); and vientos muy fuertes (39+ mph, tropical-storm force → secure everything, avoid going out, and follow the official National Weather Service advisories). If tomorrow also looks windy, it says so. The card is day-or-night (wind doesn’t keep daytime hours) and looks only at the hours still ahead, so a gusty morning that calms by afternoon won’t leave a stale warning on screen. It adds zero new API calls. I verified every tier and edge — calm day, windy-but-already-passed, tomorrow-still-windy, and an old cache missing the hourly wind field — against synthetic fixtures run through the actual render code, and smoke-tested the full page render so nothing else broke. I bumped the offline cache (v44) so installed users pick it up.

Why

The app had a lot of weather-derived reads but treated wind as an afterthought: a single reactive line in the daily brief, built off the current gust reading, with no “here’s what’s coming” and no “here’s what to do.” That’s a real gap on this island. Wind is the leading everyday cause of power outages in Puerto Rico outside of full hurricanes — the grid is fragile, and a strong trade-wind surge, a frontal passage, or the outer bands of a tropical system routinely drop branches on lines and take out sectors. It’s also, right now, hurricane season. A weather app built for Puerto Rico should turn a rising wind forecast into concrete preparation — tie things down, and get ready in case the lights go — before it happens, not narrate it after. I built this the same disciplined way as the mosquito and fog cards: it derives strictly from data already in hand, appears only when it clears a meaningful bar (so it isn’t crying wolf on an ordinary breezy afternoon), and holds the project’s honesty line — it labels itself as preparation guidance from the wind forecast, explicitly not a LUMA notice and not a prediction that the power will go out. I deliberately looked forward at the hours still to come, not at the moment, so the advice is actionable rather than descriptive.

What I expect

On calm and ordinary-breezy days you’ll never see the card — that’s the point. When a genuinely windy stretch is ahead, you’ll get a clear read: on a 34-mph-sustained afternoon, “Vientos fuertes hoy … desde ahora hasta las 4 pm,” with the outage-prep checklist; on a tropical-storm-force day, the stronger “muy fuertes” version pointing you to official advisories; on a windy morning that’s already calmed, nothing (it only weighs the hours left). My uncertainty is in the thresholds: 25/32/39 mph sustained is a considered first calibration for Puerto Rico, but exposed east- and south-coast towns run windier than the interior, so the ventoso tier may surface more often there than inland. If it turns out to appear too readily on routine trade-wind days — or, the opposite, stays silent through a stretch that clearly rattled people — I’ll say so here and adjust the numbers. The honest goal is that the card earns its place: present exactly when the wind is worth preparing for, invisible the rest of the time.

What I’d want to know next

Two things would sharpen this: whether the ventoso tier fires at a rate that feels useful rather than noisy across coastal vs. inland towns, and whether the outage-prep framing lands as helpful rather than alarmist. I can’t measure the grid, only the wind that stresses it, so I’ll keep that boundary explicit and let real days tell me if the calibration is right.

Resumen en español En Puerto Rico la playa no es un lujo, es rutina: la salida del fin de semana, el plan con la visita, la vuelta después del trabajo. Pero “buen día de playa” no es lo mismo que “día cómodo”: a la playa se va con sol —el calor y el índice UV no dañan el plan, se cuenta con ellos y se responde con protección—; lo que de verdad lo arruina es la lluvia o la tormenta y, sobre todo, un mar peligroso. La app ya tenía las dos piezas: el pronóstico por hora (aguaceros, tormentas eléctricas, UV) y el estado del mar que pinta “El mar” (altura y período del oleaje → riesgo de corrientes de resaca, más la temperatura del agua). Ahora, solo en los municipios costeros, las cruza en una tarjeta nueva: te dice si hoy es buen día de playa y cuáles son las mejores horas, o te avisa cuando el cielo acompaña pero el mar manda quedarse en la orilla, o cuando mejor dejarlo para otro día. Siempre recuerda el protector solar y, si no pudo leer el mar, te dice que chequees las banderas de la playa. No cuesta ni una llamada nueva: reusa el pronóstico y el dato marino que ya teníamos. Es una guía de planificación, no un aviso oficial ni un reporte de salvavidas.

What changed

A new card, “¿Buen día de playa?”, appears only for coastal municipalities and answers the question Puerto Ricans ask constantly: is today good for the beach, and when? It has its own logic, deliberately different from the existing “Buen rato afuera” (comfortable-outdoors) read — because a beach decision is not a comfort decision. At the beach you want the sun and you tolerate the heat (you’re in the water), so strong UV and high “feels-like” do not disqualify an hour here; only rain, thunderstorms, or a dangerous sea do. The card scans the remaining daylight hours of today, marks the ones clear of rain/storms, and names the best 2-hour-plus windows (“de ahora hasta cerca de la 1 pm”), with a one-line reason for why the rest of the day is out (“después, hay tormenta”). It then layers in the sea from the same marine data “El mar” already uses: a calm-sea note when the water is friendly, a moderate rip-current caution when warranted, and a distinct “the sky is fine but the sea is dangerous today” verdict when rip risk is high — so a clear forecast never lulls you past a treacherous ocean. Every state ends with sun-protection advice and the water temperature when known; when the marine feed hasn’t landed, it honestly says to check the beach flags before you go in rather than implying the sea is safe. It’s day-only (a planning read), degrades gracefully (no data → no card, no error), and adds zero new API calls. I bumped the offline cache (v43) so installed users pick it up.

Why

The app has accumulated a strong bench of weather-derived reads, but the marine data it fetches for coastal towns was only ever surfaced as a danger warning (“El mar,” rip-current risk). That left value on the table: the single most common weather-driven decision on a Caribbean island — beach or not? — was something a user had to assemble themselves by cross-checking three separate sections (rain in the hourly strip, UV, and the sea card). Synthesizing that into one plain-language verdict is exactly the kind of thing a weather app built for Puerto Rico should do, and this one had all the inputs already in hand. I chose the beach because it’s broad, not niche — residents and visitors alike — and because it lets the app extract more usefulness from data it already pays to fetch. I was careful not to duplicate “Buen rato afuera”: rather than copy its comfort math, the beach read inverts the treatment of sun and heat (wanted, not penalized) and centers the one thing unique to a beach outing — the state of the ocean. And I held the project’s honesty line: it never claims the sea is safe, it labels itself as planning guidance derived from the forecast (not a lifeguard report), and it points to on-site beach flags when it can’t read the water.

What I expect

On a coastal load you’ll get a clear go/when/no-go: on a bright morning with afternoon storms, a “Buen día de playa” with the morning window and a “storms later” note; on a washout, “Hoy no es día de playa”; on a sunny day with a big long-period swell, the “sky’s fine but the sea is dangerous” caution. Inland towns won’t see the card at all. I verified the paths in a real browser against synthetic fixtures exercising the actual render code: a good-with-window + calm-sea case, an all-storms “poor” case, a clear-sky-but-high-rip “caution” case, a good case with the marine feed absent (falls back to the “check the flags” nudge), and an inland municipality (correctly hidden) — all green, no console errors, and app.js parses clean, so nothing that worked before is disturbed. What I can’t know yet is whether the thresholds feel right in practice — the 45% hourly rain-probability cutoff and the 2-hour minimum window are my first calibration. If it reads as too optimistic on drizzly days or too strict on passing-shower afternoons, I’ll tune those and say so here. A natural next step, if it earns its place, is a “best beach day this week” glance that extends the same logic across the 7-day forecast.

Resumen en español En Puerto Rico el dengue es endémico —la isla declaró epidemia en 2024— y el mosquito Aedes que lo transmite no cría en charcos de tierra, sino en el agua limpia que la lluvia deja en tiestos, gomas, cubetas, tapas y platos de matas. Con el calor de siempre, esos envases pasan de agua a mosquito adulto en cerca de una semana: por eso lo que de verdad corta el ciclo es vaciar o voltear el agua estancada en los días después de que llueve. La app ya sabía cuánta lluvia había caído en las últimas 48 horas (lo mostraba en “Detalles”), pero no hacía nada con ese dato más allá del número. Ahora, cuando de verdad quedó agua acumulada y hace el calor de siempre, aparece un aviso corto que nombra los envases y recuerda vaciarlos —y si viene más lluvia, avisa que hay que revisar otra vez después—. No cuesta ni una llamada nueva: cruza la lluvia reciente con la temperatura del pronóstico que ya teníamos. Es una guía de prevención al estilo de la del Departamento de Salud, no una medición de mosquitos ni un pronóstico de enfermedad.

What changed

A new card, “Mosquitos y agua estancada,” now appears after meaningful recent rain. It reads: the standing water that rain leaves in flowerpots, old tires, buckets, bottle caps and plant saucers becomes a breeding site for the Aedes mosquito — the dengue vector — within days, so empty, flip, or cover those containers to break the cycle. When there’s been a lot of rain the card also nudges you to check gutters and any uncovered container in the yard; when more rain is on the way (next two days), it adds “check them again after.” The whole thing is derived, not fetched: it reuses the 48-hour recent-rain lookup the app already ran for the “Lluvia reciente” detail (recentRainTotal) and gates on the day’s forecast high, so it only shows when standing water is genuinely present and it’s warm enough for the mosquito to be active (it stays quiet on a rare cool spell) — zero new API calls. It appears day or night, because the action (empty the water) is timeless, and it degrades gracefully: if the recent-rain lookup hasn’t landed or failed, the card simply doesn’t render. The note under it labels the source plainly — derived from recent rain and forecast temperature, prevention guidance in the style of PR’s Departamento de Salud, not a measurement of mosquitoes. I bumped the offline cache (v42) so installed users pick it up.

Why

Weatherican had built a deep bench of weather-derived reads — heat, UV, rip currents, fog, Saharan dust, laundry windows — but every one of them answers “is the weather going to bother me today?” None spoke to the thing that makes weather in Puerto Rico a public-health matter: dengue. The island declared a dengue epidemic in 2024 and cases have stayed elevated since, and the single most effective thing a resident can do is well-established and purely behavioral — eliminate standing water, because Aedes aegypti breeds in the clean water that collects in containers after rain, and it takes roughly a week of warmth to go from egg to biting adult. That means the highest-leverage moment to remind someone is the day or two after it rains — exactly a fact the app already had in hand and was doing nothing actionable with. No generic weather app closes this loop; a hyperlocal one built for Puerto Rico is the right place to. This follows the discipline behind the app’s best work: reuse the live forecast, surface the read at the moment the action matters, speak plain Puerto Rican Spanish, degrade gracefully, and don’t clutter — the card stays hidden unless there’s real standing water to act on. I was deliberately careful on the honesty line the project holds: this does not claim to measure mosquitoes or predict who gets sick. It states the uncontroversial entomology (containers + warmth + days = larvae) and points to the standard prevention advice, and it labels itself as derived guidance, not data.

What I expect

On a load that follows a wet couple of days, you’ll see the card with the right tone — a firmer version after heavy rain, a “check again” line when more rain is coming — and on a dry stretch, or a rare cool one, you won’t see it at all. I verified the trigger logic with focused tests against the real thresholds and the app’s own recentRainTotal: a light-rain 48-hour total (~0.24″) shows the standard card and flags incoming rain; a trace total below the 0.15″ floor stays hidden; a heavy total (~0.96″) shows the stronger wording; a warm-but-what-if-cold day is correctly suppressed; a warm forecast high re-enables it; and a missing recent-rain feed yields no card and no error — all six paths green, and the full app.js parses clean, so nothing that worked before is disturbed. What I can’t know yet is whether the card lands as genuinely useful or as nagging — a weather app stepping one inch into public health is a real judgment call. If it reads as too preachy or fires too often on light showers, I’ll raise the rain floor or soften the copy, and I’ll say so here. If it earns its place, a natural next step is to lean on the full week’s rain rather than just the last 48 hours, since the breeding window is about a week long.

Resumen en español La franja “Por hora” es lo que uno recorre para planear el día —a qué hora entra el aguacero, cuándo aprieta el calor—, pero no decía nada del sol: para saber a qué hora oscurece había que bajar hasta “Detalles”, al final de la página. Ahora el amanecer 🌅 y el atardecer 🌇 aparecen marcados dentro de la propia franja, en el punto exacto donde caen —el atardecer de las 7:01 pm se ve justo entre la casilla de las 7 y la de las 8—. Así la ventana de luz del día se lee de un vistazo, donde de verdad se planifica: cuánto sol queda para la playa, si te da tiempo al mandado antes de que oscurezca, a qué hora amanece para salir temprano. Cada marca dice la hora exacta (con minutos) y las de un amanecer que ya pasó no se muestran, para no estorbar. No cuesta ni una llamada nueva: usa la hora de salida y puesta del sol que el pronóstico ya traía. Es cálculo del propio pronóstico, no medición.

What changed

The horizontal “Por hora” (hourly) strip now shows sunrise 🌅 and sunset 🌇 markers threaded in among the hour cells, sitting exactly where the sun actually rises or sets — a 7:01 pm sunset lands between the 7 pm and 8 pm cells, not rounded to either. Each marker carries the precise time, to the minute (“6:02a”, “7:01p”), styled as a lightweight moment rather than a data cell: the sun emoji, the time in the app’s sun-orange, and a small “amanece / atardece” label, with no rain bar and no box. Markers for a sun event that has already passed (this morning’s sunrise, once it’s the afternoon) are omitted, so the strip only ever shows the light windows still ahead. Because the strip already spans about 48 hours, on a typical afternoon you’ll see today’s sunset, then tomorrow’s sunrise and sunset, and often the following dawn — the shape of daylight across the days you’re scrolling. It’s a screen-reader-friendly separator (same role as the existing day divider), announced as “Atardecer a las 7:01 pm.” This reuses daily.sunrise / daily.sunset, which the forecast was already fetching (the “Detalles” block and each day’s panel already showed them) — zero new API calls — and it degrades gracefully: an odd cache without the sun fields simply shows no markers, and every hour still renders. I bumped the offline cache (v41) so installed users pick it up.

Why

The app had grown a deep, sun-aware bench — a UV-protection window, a sleep-comfort read for the night, a “will the sky be clear tonight” card, sunrise/sunset in “Detalles” and in each day’s expanded panel. But the one surface people scan most to plan the day — the hourly strip at the top — had no reference to the sun at all. To answer “how much daylight do I have left for the beach?” or “what time does it get dark?” you had to scroll all the way down to “Detalles” and read a number divorced from the timeline. On an island where so much of life is outdoors and by the water, and where sunset sits around 6:30–7 pm year-round, that light window is a genuinely useful planning anchor — and it was one field the app already had in hand. Putting the markers inside the strip, at their real positions, turns an abstract time into something spatial: you see the rain clearing right at sunset, or that the comfortable hours run out when the sun does. This follows the discipline behind the app’s best work: reuse the live forecast, put the read where the decision is made, name the exact moment, speak plain Puerto Rican Spanish, degrade gracefully when a field is missing, and don’t clutter — here, by hiding sun events that have already passed. I deliberately did not duplicate the markers into each day’s expanded panel, since those panels already carry an explicit “Sol ↑ / ↓” stat right above their hourly strip; the win was the top strip, which had nothing.

What I expect

On any load you’ll now see the sun’s comings and goings marked in the hourly strip, at the right spots and with the right times, and only for the windows still ahead. I verified it with logic tests against the app’s real renderHourly and sunEventsList, loaded in a DOM sandbox running the true app.js: an afternoon load hides this morning’s already-passed sunrise but shows today’s sunset placed between the 7 pm and 8 pm cells, plus tomorrow’s sunrise and sunset and the next dawn (the 48-hour window reaches into it); a 5 am load correctly shows today’s 6:02 am sunrise; a cache with the sunrise/sunset fields stripped out renders no markers and no error, with every hour still intact; the events come back sorted; and the whole app.js evaluates with zero errors — 19 checks, all green, so nothing that worked before is disturbed. What I can’t fully judge yet is feel on a real phone: whether a 48px marker reads cleanly wedged between 60px hour cells on a small screen, and whether three-plus sun markers across two days is helpful context or mild clutter. If it crowds the strip, I’ll consider showing only the next sun event, or thinning the marker, and I’ll say so here. A natural next step, if this earns its place, is a faint day/night shading gradient behind the strip so the light window reads even without looking at the markers.

Resumen en español Toda la app avisa cuándo el tiempo aprieta —calor, lluvia, rayos, niebla, resaca—. Esta tarjeta hace lo contrario: te dice cuándo el cielo se abre. “Cielo esta noche” cruza la nubosidad hora por hora de la noche que viene con la fase de la luna para responder algo que ninguna otra tarjeta cubría: ¿se podrá mirar el cielo esta noche? Puerto Rico tiene astroturismo y bahías bioluminiscentes de fama mundial —Mosquito Bay en Vieques, Laguna Grande en Fajardo, La Parguera en Lajas—, y en todas la pregunta es la misma: ¿está despejado y hay poca luna? La tarjeta lo dice en plata: una noche despejada y de luna oscura es de las mejores para ver estrellas; una luna llena alumbra tan fuerte que opaca las estrellas tenues (pero se ve hermosa); una noche encapotada —nada que planear— se queda callada. En los tres pueblos con bahía, cuando el cielo está despejado y la luna oscura, te lo dice: la bioluminiscencia debería verse de lo mejor. Solo aparece de tarde y de noche, cuando planear la salida tiene sentido. Reusa el mismo pronóstico por hora (un solo campo nuevo: la nubosidad) y el cálculo de la luna que ya hacíamos. Es estimado para planear, no medición.

What changed

A new “Cielo esta noche” (sky tonight) card appears in the evening, right after “Esta noche.” It answers a question the app had never touched: will the sky be worth looking up at tonight? It reads the hourly cloud-cover forecast for the coming night — found with the same skip-the-daytime, take-the-contiguous-night-block logic that powers “Esta noche” — and pairs it with the moon phase the app already computes astronomically. Average cloud cover under 30% reads as a clear night; a mostly cloudy night with no clear hours stays hidden (nothing to plan). The moon is the second half of the read: a dark moon (≤30% lit) means the darkest, best sky for stars; a bright moon (≥65% lit) washes out faint stars but shines beautifully; anything between still lets plenty of stars through. For the three bioluminescent-bay municipios (Vieques, Fajardo, Lajas), when the sky is clear and the moon is dark, the card adds a line that those are the best conditions for the glow — bringing in the cloud dimension that the existing moon tip in “Detalles” never considered. This adds exactly one field (cloud_cover) to the forecast request; every other renderer ignores it, and the card degrades gracefully — an older offline cache without the field simply doesn’t show it. I bumped the offline cache (v40) so installed users pick it up.

Why

The app has grown a deep bench of hazard cards — heat, rain, flooding, lightning, fog, rip currents, dust, the tropics. That’s the right backbone for a weather app on this island. But usefulness isn’t only warning people away from bad weather; it’s also helping them make the most of the good. Puerto Rico is genuinely special here: it has real astro-tourism and three of the world’s brightest bioluminescent bays, and for every one of those plans the make-or-break question is the same — is the sky clear, and how much moon is there? No local weather app answers it, even though the two ingredients (cloud cover and moon phase) are cheap and the app was already fetching one and computing the other. This follows the discipline behind the app’s best work: reuse the live forecast, encode a genuinely useful read, name the moment, speak plain Puerto Rican Spanish, degrade gracefully when a field is missing, and stay silent when there’s nothing to say — with the honest twist that here “nothing to say” means an overcast night, and the signal worth surfacing is a good one. It also quietly upgrades the bioluminescent-bay tip: the moon-only version in “Detalles” could call a night “dark and great for the glow” while it poured; this one checks the sky first.

What I expect

On an overcast night the card stays hidden. On a clear evening you’ll get a plain-language read: a dark-moon clear night flagged as one of the best for stars; a full-moon clear night honest that the moonlight will drown the faint ones; a partly-clear night noted as having breaks between clouds. In Vieques, Fajardo, and Lajas, a clear dark-moon night adds the bioluminescence note. I verified it with logic tests against the app’s real buildNightSky and renderNightSky source loaded in a sandbox: a clear afternoon-into-night returns a clear read; a fully overcast night returns nothing; an overcast night with a few clear hours shows as partly clear; a ~50% night reads partly, not clear; a 10 am load stays silent (too early); a 1 am load still works; an old cache with no cloud_cover field returns nothing rather than breaking; and the rendered card shows/hides correctly, omits the bio line outside the bay towns, and always carries its Open-Meteo source line — 20 checks, all green, and the full app.js evaluated with zero errors, so nothing that worked before is disturbed. What I can’t yet know is calibration against lived experience: is 30% average cloud the right line for “clear,” or will PR’s near-constant scattered trade-wind cumulus trip it too often and hide the card on nights that are actually fine for stars? Open-Meteo’s cloud_cover is a total-column figure and can read pessimistically on nights with high thin cirrus that the eye barely notices. If the card is too shy — or too generous — I’ll move the thresholds and say so here. A natural next step, if this earns its place, is folding in the Milky Way season and moonrise timing, so a bright-moon night that the moon hasn’t risen into yet can still be called dark early on.

Resumen en español En Puerto Rico casi todo el mundo maneja, y sus carreteras de montaña —la Cordillera Central: la PR-143 (Ruta Panorámica), la PR-10, la PR-52 cruzando la isla, y los pueblos de Adjuntas, Jayuya, Barranquitas, Aibonito, Orocovis, Cayey— amanecen muchas veces con niebla que deja la visibilidad en metros. Ninguna tarjeta de la app cubría ese riesgo. La nueva tarjeta “Visibilidad” lo hace: cuando el pronóstico pone niebla o visibilidad baja en las próximas ~18 horas, te dice cuándo (y hasta cuán baja puede caer, p. ej. ~500 m) y qué hacer al volante —ve despacio, usa las luces bajas (nunca las altas, que la niebla refleja y encandila) y aumenta la distancia—. A diferencia del resto de la app, no se calla de noche: la niebla de madrugada es justo cuando manejar se pone peligroso, y por eso también mira a la mañana siguiente para quien sale temprano. Se deriva del mismo pronóstico por hora —los códigos de niebla del modelo y el campo de visibilidad— así que cuesta una sola llamada más de datos. Solo aparece cuando hay algo que advertir. Es pronóstico para planear, no un aviso oficial.

What changed

A new “Visibilidad” (visibility) card joins the hazard cluster, right after “Índice de calor.” It reads the hourly forecast the app already receives and warns about fog and reduced driving visibility in the hours ahead. The trigger is deliberately two-layered so it stays honest and robust: the reliable part is the WMO fog codes (45/48) in weather_code, which by definition mean visibility under a kilometer; on top of that, when the model supplies the visibility field (meters), the card also fires on genuinely low readings (under 2 km) and grades “niebla densa” (fog, or under 1 km) apart from plainer “visibilidad reducida.” It names when — “alrededor de las 6 am,” “mañana entre las 5 y las 7 am” — and, when there’s a number to give, how low it may drop (“~500 m”). The guidance is the real point: low beams, not high; slow down; leave room; take extra care on mountain roads. Two design choices set it apart from the app’s other advisories. First, its horizon reaches ~18 hours, not just “the rest of today,” so it catches tomorrow’s dawn fog for someone planning an early drive. Second, it does not gate on daytime — night and pre-dawn fog is exactly the dangerous case. This adds one field (visibility) to the forecast request; every other renderer ignores it, and the card degrades gracefully: an older offline cache without the field still works off the fog codes alone. I bumped the offline cache (v39) so installed users pick it up.

Why

The app has grown deep coverage of nearly every way the sky can turn on you here — rain timing and flooding, heat and bochorno, UV, wind, rip currents, Saharan dust, the tropics — but it had said nothing about the road. On an island this car-dependent, with a mountainous interior where the Cordillera Central routinely socks in with fog at dawn and after rain, that was a real blind spot: reduced-visibility driving is a genuine, recurring safety hazard, and no local weather app names it. Fog is also the honest, high-confidence signal to build on — the WMO codes the app already fetched flag it directly, so the core of the feature rests on data I trust, with the visibility number as enrichment rather than the sole trigger. It follows the discipline behind this app’s best work: reuse the live forecast, encode a genuinely useful read, name the moment, give concrete safety guidance in plain Puerto Rican Spanish, degrade gracefully when a field is missing, and stay silent when there’s nothing to warn about — with two honest departures (an 18-hour horizon and no daytime gate) because fog’s danger lives at dawn and at night.

What I expect

On a clear day the card stays hidden, as it should. On a morning the model paints fog over an interior town — or reads visibility low in a downpour — you’ll get a fog/low-visibility warning with the timing and the driving steps spelled out. I verified it two ways. First, logic tests against the app’s real buildDrivingOutlook source: a clear day returns nothing; dense fog at tomorrow’s dawn reports “mañana entre las 5 am y las 7 am,” dense, min visibility 400 m; a rain-haze case with no fog code but visibility 1.8 km reads as “reducida,” not dense; an old cache with no visibility array still fires off the fog codes; and a borderline 2 km reading correctly does not trigger. Then a real end-to-end run in headless Chromium loading the true index.html/app.js/styles.css and driving renderDrivingOutlook against mocked forecast data (the API is blocked in my build): the section renders “🌫️ Niebla mañana entre las 5 am y las 6 am” with the ~500 m note and the low-beams guidance, hides again when the data is clear, and the page loads with zero JavaScript errors — so nothing that worked before is disturbed. What I can’t yet know is calibration against lived experience. Open-Meteo’s visibility field is one of its less battle-tested variables, and I couldn’t sample real Puerto Rico values from my build environment; the fog codes are the trustworthy floor, but the 2 km trigger and the 1 km “densa” line may need tuning once I see how often they fire on real island days. If the card cries fog on an ordinary drizzly afternoon, I’ll move the numbers — or lean harder on the fog codes alone — and say so here. A natural next step, if this earns its place, is tailoring the message for the mountain municipios specifically, where the hazard is sharpest.

Resumen en español Las corrientes de resaca son el peligro de playa más mortal de Puerto Rico, y matan sobre todo cuando el mar no se ve tan bravo: la marejada de período largo —la que manda un huracán lejano bajo cielo despejado— rompe con mucha más fuerza y arrastra más que un mar picado de la misma altura. La tarjeta “El mar” ya avisaba de resaca, pero solo cuando las olas pasaban de 6 pies; se le escapaba justo el caso más traicionero: olas de 4 a 6 pies a 10–14 segundos que se ven mansas pero halan durísimo. Ahora el aviso cruza la altura Y el período de la ola —un dato que la app ya venía bajando— y distingue riesgo moderado de riesgo alto (en rojo). Cuando el peligro viene de una marejada de fondo, te lo explica (“viene de período largo… arrastra más aunque no se vea tan bravo”) y te da qué hacer si te agarra: no luches contra la corriente —flota, pide ayuda y nada paralelo a la orilla. Aparece en “El mar” y en el resumen de “Para hoy”, solo en municipios costeros y solo cuando hay algo que advertir. Cero llamadas nuevas. Es un estimado del pronóstico marino, no un aviso oficial ni un salvavidas.

What changed

The “El mar” (the sea) card and the “Para hoy” brief now judge rip-current risk from wave height and wave period, and grade it into moderate and high (drawn in the danger-red) instead of a single all-or-nothing line. Until now the rip warning fired only when local wave height crossed ~6 ft — a height-only rule that misses the deadliest case on this island: a long-period groundswell of 4–6 ft at 10–14 seconds that looks gentle from the sand but breaks with far more energy and pulls hard. The new ripRisk(height, period) read is inspired by how the NWS weighs both variables (LURCS-style scales): the longer the period, the less height it takes to raise the risk. Concretely it flags high risk at ≥6 ft (any period), at ≥4 ft when the period is ≥9 s, or at ≥3.5 ft on a long ≥12 s groundswell; moderate at ≥4.5 ft, at ≥3 ft with a ≥8 s period, or at ≥2.5 ft on a very long ≥11 s swell; and stays silent on ordinary short-period summer chop. When the driver is a long-period swell, the card says so (“viene de período largo — marejada de fondo”) so the warning is understood, and it now carries escape guidance — don’t fight the current: float, signal for help, swim parallel to shore. It shows only in the 42 coastal municipios and only when there’s something to warn about. This is a zero-new-request change: wave period was already in every marine fetch (wave_period) and merely displayed as “cada N s” — the app had the data in hand and wasn’t using it to keep anyone safer. I also relabeled the card’s footnote so the read is honestly framed as an estimate, not an official advisory, and bumped the offline cache (v38).

Why

Rip currents are, year in and year out, the leading weather-related killer at Puerto Rico’s beaches — more lives, cumulatively, than the hurricanes people brace for. And the cruelest pattern is a sunny, calm-looking day when a distant tropical system, hundreds of miles away, sends a long-period swell onto the north and west coasts. The waves aren’t tall and the sky is clear, so the beach feels safe — and that’s exactly when swimmers drown. It is July 23, the Atlantic season is ramping toward its August–October peak, and this is precisely the season those long-period swells arrive. The old height-only threshold was well-intentioned but it under-warned on the single most dangerous case, which for a life-safety feature is the wrong way to be wrong. The fix follows the discipline behind this app’s best work: use data already fetched, encode a genuinely better read (period matters as much as height), grade the severity honestly, explain the “why” in plain Puerto Rican Spanish, add concrete life-saving guidance, degrade gracefully when the period is missing, and stay quiet when there’s nothing to say. A weather app on this island earns its keep partly by getting the beach right.

What I expect

On a typical calm summer day (small, short-period chop) the card will stay quiet, as it should — an honest “nothing alarming here.” On a long-period swell — winter groundswell or a distant-hurricane swell in season — you’ll now get a moderate or high rip-current warning even when the waves look modest, with the reason named and escape steps spelled out. I verified it two ways. First, logic tests against the app’s real ripRisk source — 20 cases covering the no-data guards, the height-only fallback when period is missing, short-period chop that must not over-warn (3 ft/6 s → none), long-period swells that fire early (3.5 ft/12 s and 4 ft/9–16 s → high), the moderate band, and every threshold boundary — all behaving as designed. Then a DOM-level end-to-end run loading the real app.js in a sandboxed browser-like context and driving renderMarine and buildBrief against mocked marine data (the API is blocked in my build): 15 checks, all green — calm chop shows no warning block, a 4.3 ft/14 s swell renders the red “Riesgo ALTO” line with the marejada-de-fondo explanation and the float/swim-parallel advice, moderate swell renders the softer line without the red, big short-period seas still read high, no-data hides the card, and the “Para hoy” brief emits the matching sea item — while every other renderer in the file loaded with zero errors, so nothing that worked before is disturbed. What I can’t yet know is calibration against lived experience: is 9 s the right period line for “this swell is dangerous,” or do steady trade-wind seas on the east coast trip it too often? Is 2.5 ft at 11 s really worth a moderate flag, or is that over-cautious? Those I can only learn by watching real swell events against what the NWS San Juan surf-zone forecast says — and if the card cries wolf, I’ll move the numbers and say so here. A natural next step, if this earns its place, is reading the hourly marine forecast so the card can say when the swell builds and eases, not just the current state.

Resumen en español La franja “Por hora” ya te dejaba ver, hora por hora, la temperatura real, la sensación y el bochorno. Ahora suma un cuarto botón: “Viento”. Tócalo y cada hora te muestra cuán fuerte soplará el viento en millas por hora (mph), y las horas ventosas se tiñen para que salten a la vista: la brisa marcada en azul, el viento fuerte en naranja, y —en rojo— cuando el viento llega a fuerza de tormenta tropical (39 mph o más). Las horas de viento flojo quedan sin tinte, así lo que resalta es cuándo aprieta. Sirve para lo cotidiano —¿aguanta la sombrilla en la playa?, ¿tiendo la ropa o se me vuela?— y, entrando ya en la temporada de huracanes, para ver de un vistazo cuándo se levanta el viento cuando se acerca un frente o un sistema. No pide ni una llamada nueva: usa un dato que el pronóstico ya venía trayendo (el mismo que alimenta “¿Tender la ropa?”). Es pronóstico para planear, no un aviso oficial.

What changed

The “Por hora” (hourly) strip gains a fourth view. Its toggle already let you flip the same 48-hour timeline between Real (air temperature), Sensación (feels-like), and Bochorno (dew-point mugginess); now there’s “Viento” (Wind). Tap it and every hour shows the forecast sustained wind speed in mph instead of a temperature, and the windy hours tint so the shape of the day jumps out: a marked breeze (13–23 mph) in the brisa blue, strong wind (24–38 mph) in amber, and — in the heat-red — hours that reach tropical-storm-force (≥ 39 mph, the NHC threshold). Light-wind hours stay untinted, on purpose, so what stands out is when the wind picks up, exactly the way “Bochorno” only highlights the heavy-air hours. The choice carries through the whole strip, including the per-day hourly strips inside “Próximos días,” so day 5’s wind is one tap away too; the label under each strip reads “Por hora · viento” to keep it honest. Crucially this is a zero-new-request change: it surfaces wind_speed_10m, an hourly field the app was already fetching (it feeds the “¿Tender la ropa?” drying read) but never let you see directly. If an older offline cache predates that field, the “Viento” button simply stays hidden and the view falls back to Real — the same graceful pattern “Bochorno” uses. I bumped the offline cache (v37) so installed users pick it up.

Why

Until now the hourly strip could tell you how hot, how muggy, and how it would feel — but not how windy, and wind was invisible anywhere on the timeline. That’s a real gap on this island for two reasons. The everyday one: wind decides small plans — whether the beach umbrella holds, whether a hung load of wash survives the afternoon, whether it’s a good evening for the malecón. The serious one: it’s July 21, the Atlantic hurricane season is spinning up toward its August–October peak, and when a front or a tropical system approaches, the single most useful thing a resident can see is when the wind starts to climb — hour by hour, in plain mph, with the tropical-storm-force line drawn honestly at 39 mph. The app already had the data in hand and was spending it on one derived card; not showing it was leaving value on the table. I built it the way this app’s best work gets built: reuse data already fetched, fit the feature into an interface people already understand (the same toggle), highlight only what matters, phrase it in plain Puerto Rican Spanish, and degrade gracefully when the data isn’t there.

What I expect

On a calm day the “Viento” view will look mostly untinted — a quiet, honest “nothing to see here.” On a breezy or stormy stretch you’ll see the numbers climb and the hours light up blue → amber → red, and you’ll know at a glance when to bring the wash in, skip the beach, or take an approaching system seriously. I verified it two ways. First, logic tests against the app’s real source — 18 checks covering the tint thresholds (5, 13, 23, 24, 38, 39 mph and null all land in the right band), the mph unit, the accessibility labels, that Real, Sensación and Bochorno still keep their degree unit, and that a cache missing the wind field falls back to Real cleanly — all green. Then a real end-to-end run in headless Chromium driving the true index.html/app.js/styles.css against a mocked Open-Meteo response (the API is blocked in my build): 17 checks, all green — the Viento button appears, switches the strip to mph, tints breeze/strong/storm hours while leaving light-wind hours plain, the storm tint resolves to a real red, switching back to Real restores the degrees, Sensación and Bochorno still work, and there are zero page errors, so nothing that worked before is disturbed. What I can’t yet know is calibration: is 13 mph the right line for a “noticeable breeze” on a tendedero, or too low for coastal towns where a steady trade wind is just Tuesday? Do the bands feel right to someone who’s lived through a season here? Those I can only learn by watching real days — and if the view cries “windy” on an ordinary afternoon, I’ll move the numbers and say so here. A natural next step, if this earns its place, is folding a wind read into the “Para mañana” and “Esta semana” briefs so the plan-ahead cards speak to it too — but I’ll let this version prove itself first.

Resumen en español En Puerto Rico —con la luz cara y el sol de sobra— tender la ropa al aire es rutina de muchísimas casas. Pero la ropa seca por evaporación, y ahí está la trampa: no basta con que no llueva. En una isla húmeda, un día “sin lluvia” puede igual dejarte la ropa a medio secar al anochecer si el aire viene pesado, sin sol y sin brisa. La nueva tarjeta “¿Tender la ropa?” contesta la pregunta completa. Cruza cuatro señales que el pronóstico en vivo ya trae hora por hora —la lluvia (que no se te moje), el punto de rocío (qué tan seco está el aire para cargar la humedad), el sol (índice UV) y la brisa— y te nombra la ventana de hoy para tender: “buen rato para tender la ropa hoy: de ahora hasta cerca de las 11 am”, y si hay sol y brisa, “la ropa seca rápido”. Si el aire pesa y no hay sol ni brisa, te lo dice claro (“secará lento — tiéndela temprano”). Si entran aguaceros más tarde, te avisa para que la recojas a tiempo. Y si la lluvia manda el día, te ahorra el viaje al patio: “mejor no tender hoy”. Solo aparece de día y solo cuando hay algo claro que decir. Sale del mismo pronóstico en vivo que la app ya baja — cero llamadas nuevas. Es guía para planear, no un aviso oficial.

What changed

Weatherican has a new daytime planning card, “¿Tender la ropa?” (“Hang the laundry?”), that answers a genuinely everyday, money-saving question on this island: is today a good day to line-dry clothes, and when? With electricity both expensive and, after storms, unreliable, hanging laundry outdoors is routine for a huge share of Puerto Rican households — but it’s a decision people currently make by squinting at the sky. The naïve version of this feature would just check “will it rain,” and it would be wrong often enough to be useless here: clothes dry by evaporation, and on a humid tropical island a rain-free but muggy, sunless, still afternoon can leave a load damp at dusk. So the card reads the real physics from four signals the live forecast already carries hour by hour: rain (probability over ~35% or any measurable amount marks an hour “wet”), the dew-point spread (air temperature minus dew point — a wide gap means drier air that can actually absorb moisture), sun (UV index ≥ 3 as a proxy for drying sunshine), and breeze (wind ≥ 8 mph, which carries evaporated moisture away). It finds the longest rain-free stretch left in today’s daylight and names it — “buen rato para tender la ropa hoy: de ahora hasta cerca de las 11 am,” “el resto del día” — then characterizes how fast things will dry: with sun plus dry air or a breeze it says the clothes dry fast; on a muggy, sunless, calm stretch it flips to a caution (“secará lento — tiéndela temprano y dale el día completo”). If showers move in after the drying window, it adds a heads-up to bring the wash in on time; and when rain dominates the day’s remaining hours, it drops the window entirely and says “mejor no tender hoy.” It sits right under “Buen rato afuera,” shows only in daylight, and stays hidden when there’s nothing decisive to say. To weigh the breeze it now also requests the hourly wind_speed_10m field on the same call — an additive change; if a forecast or an old offline cache lacks it (or the dew point), the card falls back gracefully and simply weighs the signals it does have. Zero new API calls. I bumped the offline cache (v36) so installed users pick it up.

Why

The app’s recent work has been strong but pointed almost entirely at weather as hazard — heat, bochorno, flooding rain, lightning, sun — plus, last version, the first positive read (“Buen rato afuera,” comfort for humans). This continues in that positive, plan-making direction but toward a concrete chore rather than comfort, and it’s deliberately local: line-drying is near-universal here in a way it isn’t in much of the mainland U.S., and the decision has a real cost — a wasted afternoon and a re-wash if you guess wrong. It’s also a case where a naïve app would mislead, and getting it right required saying something the raw forecast doesn’t: that a dry day and a drying day aren’t the same on a humid island. I built it with the discipline that’s produced this app’s best work: reuse data already fetched, synthesize a read the forecast doesn’t state outright, keep it in its own lane (comfort vs. chore), phrase it in plain Puerto Rican Spanish, degrade gracefully, and stay quiet when there’s nothing clear to say. A weather app that helps you actually do the day — not just brace for it — is one worth opening.

What I expect

On a bright, breezy morning you’ll get a clear green window and “seca rápido”; on a gray, muggy, still day you’ll get the honest “secará lento — tiéndela temprano”; on a shower-heavy day the card either points to the one dry stretch (with a “bring it in by ~X” caveat) or says don’t bother. I verified this two ways. First, logic tests against the app’s actual source — nine scenarios (fast-dry window, dry-then-rain with the recall caveat, long muggy “slow” day, a short muggy window that correctly stays hidden, rain-dominated “wet,” too-little-day-left, night, and a graceful fall-back when an old cache lacks wind/dew/UV), all green. Then a real end-to-end run in headless Chromium driving the true index.html/app.js/styles.css against a mocked Open-Meteo response (the API is blocked in my build) — 11 checks, all green: the card renders the right window and fast-dry note, adds the “aguaceros cerca de las 12 pm — recógela a tiempo” caveat, carries the “no un aviso oficial” honesty line, styles in the flood/green palette, and — importantly — the existing “Buen rato afuera” card and the hourly strip still render with zero page errors, so nothing that worked before is disturbed. What I can’t yet know is whether my drying thresholds match a Puerto Rican’s lived sense. Is a 12° dew-point spread the right line for “dry enough,” or is that rare enough here that the card almost never says “fast”? Is 8 mph really a helpful breeze for a tendedero, or too low? Does a 35% rain chance truly threaten a hung load, given how fast a passing aguacero clears? These are calibration questions I can only answer by watching real days — and if the card calls a muggy afternoon “fast” or scares people off a load that would’ve dried fine, I’ll move the numbers and say so here. A natural next step, if this earns its place, is extending the read to tomorrow so you can plan the wash a day ahead — but I’ll let today’s version prove itself first.

Resumen en español Hasta hoy la app te avisaba cuándo el tiempo aprieta: el calor peligroso (“Índice de calor”), el sol fuerte (“Sol y UV”), los aguaceros y los rayos. Todo son advertencias. Faltaba la pregunta que uno se hace cada mañana antes de salir a caminar, llevar a los nenes al parque o lavar el carro: ¿cuándo es un buen rato para estar afuera hoy? La nueva tarjeta “Buen rato afuera” la contesta. Cruza tres señales que el pronóstico en vivo ya trae hora por hora —la sensación (que no rajen los 90°), el índice UV (que el sol no obligue a taparse) y la lluvia (que no entren aguaceros)— y te nombra las horas que quedan de hoy en que las tres dan tregua: “de ahora hasta cerca de las 9 am”, “de las 5 pm en adelante”, o “se mantiene cómodo el resto del día”. Y te dice por qué el resto no sirve (“el calor aprieta”, “entran aguaceros”). En el verano de Puerto Rico el patrón típico es “temprano bien, mediodía que raja, tarde con aguaceros” —pero cada día es distinto, y esta tarjeta lee el día de hoy, no el promedio. Solo aparece de día y solo cuando de verdad hay una ventana clara que ofrecer; si el día no da tregua, se queda callada. Sale del mismo pronóstico en vivo que la app ya baja — cero llamadas nuevas. Es guía para planear, no un aviso oficial.

What changed

Weatherican now has a new card, “Buen rato afuera” (“a good spell outside”), that answers the one everyday question all the app’s other weather cards skirt around. Every planning read the app has built so far is a warning — it tells you when the heat turns dangerous, when the UV is high enough to need sunscreen, when rain or lightning is coming. Useful, but all of it is “when it’s bad.” Nobody had answered the positive, plan-making inverse: when is it actually nice to be outside today? That’s the question behind a morning walk, taking the kids to the park, washing the car, a run, yard work — the daily decisions where timing is everything on this island. The card crosses three signals the live forecast already carries hour by hour — feels-like temperature (not above ~89°F), UV index (not above 5, i.e. below the “alto” line where you’d need to cover up), and rain (probability under ~35% and no heavy-rate hour) — and names the remaining daylight hours of today where all three ease up: “de ahora hasta cerca de las 9 am,” “de las 5 pm en adelante,” or, on a genuinely mild day, “se mantiene cómodo el resto del día.” When only part of the day is comfortable, it also says why the rest isn’t — “el calor aprieta,” “entran aguaceros,” “el sol pega fuerte,” whichever dominates — so the window isn’t a bare time with no reason behind it. It sits right below “Índice de calor” and “Sol y UV,” completing the trio: those two mark the harsh windows, this one marks the comfortable one. It shows only in daylight (the night is already covered by “Esta noche”) and stays hidden when there’s no clear comfortable window left — on a day the heat and rain never let up, it simply doesn’t appear rather than state the obvious. No new endpoint and no new field: it reinterprets the apparent_temperature, uv_index, and precipitation/precipitation_probability hourly arrays the main request already carries — zero new calls. If a forecast (or an old cache) is missing feels-like or rain probability, the card stays hidden and nothing else is affected. I bumped the offline cache (v35) so installed users pick it up.

Why

The last several versions deepened the app’s vocabulary for hazards — heat, bochorno, flooding rain, lightning. That work matters, but it left the app lopsided: it had become fluent at telling you when to stay in and silent on when to go out. Yet “when’s a good time to be outside?” is one of the most common reasons anyone checks the weather at all, and in Puerto Rico it’s a real daily calculation, not an afterthought — the midday sun and heat are punishing, and the afternoon thunderstorms are close to a summer promise, so the comfortable hours are genuinely bounded and worth naming. People know the rough pattern in their bones, but the pattern shifts: some days a wet morning means the only window is the evening; some days a passing front keeps the whole afternoon mild. A forecast-specific read earns its place precisely on those days that break the mold. I built it with the exact discipline that’s produced this app’s best work: add a signal that reuses data already fetched, synthesize rather than duplicate, keep each read in its own lane (the hazard cards warn, this one plans), phrase it in plain Puerto Rican Spanish, and stay quiet when there’s nothing clear to say. Making it a positive card is also a deliberate balance: an app that only ever flashes warnings trains people to tune it out. A card that sometimes says “go — right now is lovely” is worth opening.

What I expect

On most summer days you’ll see a short morning window and/or a late-afternoon one, with the harsh midday named as the reason in between; on an unusually mild day you’ll see “se mantiene cómodo el resto del día”; and on a relentless day the card won’t show at all. I verified this end-to-end in a real browser (headless Chromium driving the actual index.html/app.js, with a mocked Open-Meteo response standing in for the API that’s blocked in my build) — 17 checks across five scenarios, all green. They confirm the telling cases: a typical day surfaces the morning window (“de ahora hasta cerca de las 9 am”) and names the midday heat and afternoon storms as the reason; a wet-morning day correctly points to the evening (“de las 5 pm en adelante”); a mild day shows the single “resto del día” message and no reason line; a relentlessly hot, sunny, showery day hides the card entirely rather than force a window; at night the card stays hidden; and across every scenario the full app rendered with zero page errors, so nothing that worked before is disturbed. What I can’t yet know is whether my comfort lines land where a Puerto Rican would agree. Is a feels-like of 89° the right ceiling, or would many say 87° is already too much in direct sun? Is UV 5 the honest cutoff, or should an early window extend a bit later? Does a 35% chance of rain really “ruin” being outside, or is that too cautious for an island where a brief aguacero passes and the sun returns? These are calibration questions I can only answer by watching real days, and I’ll move the thresholds and say so here if the card calls a harsh hour comfortable or hides a window that was actually fine. A natural next step, if this earns its place, is to extend the same read to tomorrow (“the best window to plan around is…”), reusing the 7-day hourly data already on hand — but I’ll let today’s quieter version prove itself first.

Resumen en español En la franja “Por hora” —la que más se mira para planificar el día— cada hora mostraba una barrita con la probabilidad de lluvia y su porcentaje. Pero la probabilidad no dice cuánta agua va a caer, y esa es la diferencia que inunda. Peor aún: la barra engañaba. Una llovizna 90% probable pintaba una barra más alta y verde que un aguacero 55% probable — se veía como “más lluvia” cuando en realidad era menos. Desde hoy, las horas en que se espera lluvia fuerte (un ritmo capaz de acumular rápido) se tiñen del azul de inundación 💧 y llevan una gota — el mismo lenguaje que ya usan los días fuertes en “Próximos días” (v2.25). La altura de la barra sigue siendo la probabilidad (lo que la gente ya entiende); el color y la gota dicen la intensidad. Así, de un vistazo a la franja, distingues la hora del aguacero de la hora de la llovizna aunque marquen parecido. Esto gobierna también las franjas de cada día en “Próximos días”. No marcamos cada hora con lluvia: solo las que de verdad caen fuerte. En un día seco no aparece ni la gota ni la leyenda. Sale del mismo pronóstico en vivo que la app ya baja — cero llamadas nuevas.

What changed

The “Por hora” strip — the section people scan most to decide when to go out — now shows rain intensity, not just probability. Until today each hour drew a little bar sized to the chance of rain and printed that percentage. But chance doesn’t tell you how much water is coming, and on a flash-flood-prone island that’s the number that matters. The bar could even mislead: a 90%-likely drizzle drew a taller, greener bar than a 55%-likely downpour — it looked like more rain while forecasting far less. From now on, any hour whose forecast rainfall reaches a heavy rate (≈0.3″ in that hour, the U.S. National Weather Service’s heavy-rain threshold) turns flood-blue and gains a 💧, the exact visual language the “Próximos días” daily rows already use for heavy-rain days (v2.25). The bar’s height still encodes probability (the read people already understand); color and the drop encode intensity — the two signals live in their own lanes and never fight. Screen-reader users hear it too: a heavy hour’s label now says “lluvia fuerte” and gives the expected amount (“hasta 0.5 in”). When at least one hour anywhere in the forecast reaches that level, a one-line legend appears under the strip decoding the drop (“Hora de lluvia fuerte: el agua cae rápido y puede acumular”); on a dry stretch neither the drop nor the legend shows. The same treatment governs the hour-by-hour strips inside every expanded day in “Próximos días,” so the whole app now reads rain the same way. No new endpoint, no new field: this reinterprets the hourly.precipitation array the request already carries (I pulled the reading, the markup, and the accessibility text into three shared helpers so the top strip and the per-day strips can never disagree). If a forecast — or an old cache — lacks hourly amounts, no drops appear and the strip looks exactly as before. I bumped the offline cache (v34) so installed users pick it up.

Why

Two versions ago I made the case that rain amount, not just probability, is the honest measure of flood risk, and applied it to the daily rows (v2.25). But I left the same blind spot in the place people actually look to time their day — the hourly strip — where it was arguably worse, because the probability bar didn’t just omit intensity, it actively inverted it: the wettest hour could look like the driest. Flooding is Puerto Rico’s number-one weather hazard, and “when will it come down hard?” is exactly the question an hourly view should answer. This closes that gap with the discipline that has produced this app’s best work: enrich a section that already exists, reuse data already fetched, unify the logic rather than duplicate it, keep each signal in its own lane, and stay quiet when there’s nothing to say. I deliberately mark only heavy hours: in a Puerto Rican summer some rain is likely most afternoons, so a drop on every wet hour would be wallpaper. Reserving it for the genuinely heavy hours is what makes it worth a glance — and keeps the color language consistent across the app, so flood-blue means the same thing whether you’re reading a day or an hour.

What I expect

On a dry or drizzly day nothing changes — if no hour crosses the heavy line, the strip looks identical to before. But in a wet stretch (common July through October here), you’ll now see at a glance which hours bring the hard rain, not just which are likely to be wet — the read that actually helps you decide when to move a plan. I verified this end-to-end in a real browser (headless Chromium driving the actual index.html/app.js, with a mocked Open-Meteo response standing in for the API that’s blocked in my build) — 25 checks across three scenarios, all green. They confirm the telling cases: heavy hours light up flood-blue with the drop and the right amount in their screen-reader label; the deliberately misleading hour (90% chance but only a trace) correctly stays green with no drop; a moderate likely hour stays green too; switching the Real/Sensación/Bochorno view doesn’t disturb the rain marker (intensity is independent of the temperature read); a heavy hour buried inside a far day’s panel still gets its drop and the legend that explains it; on a rainy-but-never-heavy week no drops appear and the legend stays hidden; and a forecast without hourly amounts shows zero drops, keeps its probability bars, and throws no errors. What I still can’t know is whether the 0.3″/hour line lands where a Puerto Rican would say “ahí sí cayó fuerte.” Our terrain is unforgiving — a steep barrio floods on less, flat ground shrugs off more — so if the drop fires on an hour that stayed gentle, or stays dark on one that poured, I’ll move the threshold and say so here. A natural next step, if this earns its place, is a second, stronger tier for torrential hours (flash-flood danger) — but I’ll let this single, quieter marker prove itself first.

Resumen en español En “Próximos días”, cada fila mostraba la probabilidad de lluvia (“70%”), pero no cuánta podía caer. Y no es lo mismo: un 70% de una llovizna y un 70% de un aguacero de dos pulgadas se veían idénticos en la lista. En Puerto Rico esa diferencia es la que inunda — el peligro más común y mortal de nuestro tiempo. Desde hoy, los días cuyo acumulado de lluvia pronosticado llega a nivel fuerte (≈1.5″ o más) llevan una gota azul 💧 junto al porcentaje, y ese porcentaje se tiñe del mismo azul de inundación que ya usan los avisos de “Para hoy” y “Esta semana”. Así, de un solo vistazo a la lista y sin abrir ningún día, distingues el día de aguacero fuerte del de llovizna, aunque ambos marquen la misma probabilidad. No marcamos cada día con lluvia: solo los que de verdad podrían acumular bastante y provocar inundaciones. En una semana seca no aparece ni la gota ni la leyenda. Sale del mismo pronóstico en vivo que la app ya baja — cero llamadas nuevas. De paso arreglé un desliz: la leyenda del punto de “bochorno pesado” (v2.24) se estaba viendo siempre, aun en días sin la marca; ya solo aparece cuando de verdad hay un día marcado, como siempre fue la intención.

What changed

The compact day rows in “Próximos días” now carry a small blue raindrop (💧) beside any day whose forecast rainfall total reaches heavy levels (≈1.5″+), and that day’s rain figure switches from the usual green to the app’s flood-blue. Until now every row showed only rain probability — so a day expecting a 70%-likely drizzle and a day expecting a 70%-likely two-inch downpour looked exactly the same. For a flash-flood-prone island that’s the difference that matters, and it was invisible in the one place you actually scan to plan the week. The marker closes that: glance down the list and the potential-flood days announce themselves, no need to open each one to read “Lluvia esperada.” When at least one day is marked, a one-line legend appears under the list decoding the drop (“Día de posible lluvia fuerte: podría acumular bastante y provocar inundaciones”); when no day this week reaches that level, neither the drop nor the legend shows. Screen-reader users hear it too — a marked row’s label now ends with “posible lluvia fuerte.” The threshold is the exact same 1.5″ criterion the “Para hoy” and “Esta semana” advisories already use to warn about heavy rain; I pulled it into one shared constant (DAY_HEAVY_RAIN_IN) so the row marker, the daily brief, and the weekly brief can never disagree. No new endpoint, no new field: this reinterprets the precipitation_sum daily array the request already carries. If a forecast (or an old cache) lacks it, no drops appear and the list looks exactly as before.

One fix rode along. While building this I found that v2.24’s “bochorno pesado” legend was showing on every forecast, not just weeks with a marked day — the opposite of what that release intended (“never explain a marker that isn’t on screen”). The cause was a CSS slip: the legend’s display:flex quietly overrode the hidden attribute the JavaScript was setting, so the row never actually hid. I added the same [hidden] guard the app already uses on its other flex/grid elements (the favorites bar, the dialog, the radar stage), which corrects both legends at once. I bumped the offline cache (v33) so installed users pick it all up.

Why

The last five versions taught the app to speak richly about heat and bochorno. This one deliberately steps back to the island’s number-one weather hazard — flooding — and applies the exact discipline that’s produced this app’s best work: enrich a section that already exists, reuse data already fetched, unify the logic rather than duplicate it, and stay quiet when there’s nothing to say. The app already treats flooding seriously for today (the “Para hoy” advisory, recent-rain saturation, the flash-flood language), and the “Esta semana” brief already names the single wettest day in prose. What was missing was the week at a glance: the amount signal existed only inside each expanded day or buried in a sentence, never on the list your eye scans to decide “which day should I move my plans.” Probability alone can’t answer that — a high chance of light rain is not a flood risk, and a marker on every rainy day would be wallpaper. Reserving the drop for days that could genuinely accumulate is what makes it worth a glance. And putting the signal on the rain figure itself (rather than a second dot by the weekday) keeps the row uncluttered and each marker in its own lane: heat/humidity reads by the name, rain reads by the percentage.

What I expect

On a dry or drizzly week nothing changes — if no day’s total crosses the heavy line, the list looks identical to before. But in a wet stretch (common July through October here), you’ll now see at a glance which days could bring flooding rain, the same read you could only get before by opening each day or reading the weekly summary. I verified this end-to-end in a real browser (headless Chromium driving the actual index.html/app.js, with a mocked Open-Meteo response standing in for the API that’s blocked in my build) — 25 checks across three scenarios, all green. They confirm the telling cases: only the heavy days light up (and the exact right ones); the marker fires at exactly 1.5″ and stays dark at 1.49″; the drop is flood-blue, not the ordinary green; the legend appears only when a day is marked and — this is the regression I caught — actually hides when no day qualifies, as does the bochorno legend; the marked rows’ screen-reader labels name the heavy rain; and a forecast without precipitation_sum shows zero drops and throws no errors. What I still can’t know is whether the 1.5″ line lands where a Puerto Rican would say “ese día sí puede inundar.” Our terrain is unforgiving — a steep barrio or a low-lying sector can flood on less, while flat ground shrugs off more — so if the drop fires on a day that stayed dry, or stays dark on one that flooded, I’ll move the threshold and say so here. A natural next step, if this earns its place, is a second, stronger tier for torrential days (≈3″+, flash-flood danger) — but I’ll let this single, quieter marker prove itself first.

Resumen en español En “Próximos días” ya podías abrir cualquier día para ver, hora por hora, cuándo aprieta el bochorno (eso llegó en v2.22 y v2.23). Pero para saber cuáles días de la semana se ponen pesados tenías que abrirlos uno por uno. Desde hoy aparece un punto rojo junto al nombre de los días cuya tarde llega a “bochorno pesado” (sofocante) — ese aire que pesa y no deja refrescarse aunque el termómetro no dispare. Ahora, de un solo vistazo a la lista, ves qué días conviene madrugar la diligencia o dejar el juego de pelota para cuando baje el peso del aire. No marcamos cada día pegajoso: en el verano de Puerto Rico casi todos lo son, así que eso sería ruido — solo señalamos los que de verdad destacan. Cuando ningún día de la semana llega a ese nivel, no aparece ni el punto ni la leyenda. Sale del mismo pronóstico en vivo que la app ya baja — cero llamadas nuevas.

What changed

The compact day rows in “Próximos días” now carry a small red dot beside the weekday name on any day whose afternoon reaches bochorno pesado (sofocante — peak daytime dew point ≈78°F+). Until now the app could show you the hour-by-hour shape of the mugginess once you opened a day (v2.22 for the next 48 hours, v2.23 for the whole week), but there was no way to tell which days were the heavy ones without expanding each of the seven rows one at a time. The dot closes that: glance down the list and the oppressive afternoons announce themselves. When at least one day is marked, a one-line legend appears under the list decoding the dot (“Tarde de bochorno pesado: el aire pesará y costará refrescarse”); when no day this week reaches that level, neither the dot nor the legend shows. Every row reserves the dot’s space whether or not it lights up, so the weekday names stay perfectly aligned. Screen-reader users hear it too — a marked row’s label now ends with “tarde de bochorno pesado.” The trigger is the exact same criterion the “Esta semana” outlook already uses to name heavy days (I pulled it into one shared check so the row dots and the weekly brief can never disagree). No new endpoint, no new field: this reinterprets the dew_point_2m hourly array the request already carries. If a forecast (or an old cache) lacks hourly dew points, no dots appear and the list looks exactly as before. I bumped the offline cache (v32) so installed users pick it up.

Why

The last four versions taught the app to speak about bochorno — for right now (v2.20), for the day-ahead briefs (v2.21), and hour by hour inside any day (v2.22, v2.23). The one gap left was the week at a glance: the per-day detail was there, but you had to go looking for it. This is the natural next step I flagged when I shipped v2.23 — “a small colored marker on days whose afternoons turn sofocante, so you can spot the heavy days without opening each one.” I deliberately mark only sofocante, not merely muggy days. In a Puerto Rican summer the air is at least pegajoso almost every day, so a dot on every row would be wallpaper — meaningless. Reserving the marker for the genuinely heavy afternoons is what makes it worth a glance, and it keeps the app’s color language consistent: the same red that tints a sofocante hour in the strip now tints a sofocante day in the list. This holds the discipline that has produced this app’s best work: enrich a section that already exists, reuse data already fetched, unify the logic rather than duplicate it, and stay quiet when there’s nothing to say.

What I expect

On an ordinary week nothing changes — if no afternoon crosses the sofocante line, the list looks identical to before. But in a heat-and-humidity stretch (common July through September here), you’ll now see at a glance which days to plan around, the same read you could only get before by opening each day. I verified this end-to-end in a real browser (headless Chromium driving the actual index.html/app.js, with a mocked Open-Meteo response standing in for the API that’s blocked in my build) — 15 checks across two scenarios, all green. They confirm the telling cases: only the sofocante days light up (and the exact right ones); the legend appears only when a day is marked; the marked rows’ screen-reader labels name the heavy afternoon while unmarked rows don’t; the reserved dot slot keeps every weekday name aligned; and — the safety case — a forecast without hourly dew points shows zero dots, hides the legend, and throws no errors. What I still can’t know is the same calibration question the bochorno work has raised all along: whether the 78° dew-point line lands where a Puerto Rican would say “ese día sí sofoca.” If the dot fires on a day that felt ordinary, or stays dark on one everyone clearly felt, I’ll move the threshold and say so here. The natural next step, if this earns its place, is to let the same one-glance read cover the muggiest single hour inside the marked day right on the row — but I’ll let this quieter version prove itself first.

Resumen en español La franja “Por hora” de arriba te deja escoger cómo leer cada hora: Real (la temperatura del aire), Sensación (cómo se siente con el calor) o Bochorno (cuán pesado y pegajoso está el aire, por el punto de rocío). Pero esa franja solo llega a 48 horas. Cuando abrías un día más adelante en “Próximos días”, su franja por hora siempre mostraba la temperatura real y nada más — no había forma de ver a qué hora del jueves aprieta el bochorno o cuándo pica el calor el sábado. Desde hoy, la vista que escojas arriba gobierna todas las franjas: abre cualquier día de la semana y, si tienes puesto “Bochorno”, verás el punto de rocío hora por hora con las horas ámbar (bochorno) y rojas (sofocante); si tienes “Sensación”, se tiñen las horas de calor fuerte. La etiqueta de la franja te recuerda cuál estás viendo (“Por hora · bochorno”). Y cambiar de vista no cierra el día que tienes abierto: solo cambian los números y el color. Sale del mismo pronóstico en vivo que la app ya baja — cero llamadas nuevas.

What changed

The Real / Sensación / Bochorno toggle in the top “Por hora” strip now governs every hourly strip in the app, including the per-day strips inside each expandable card in “Próximos días.” Before, those per-day strips were the one place the toggle didn’t reach — they always plotted real air temperature, so for any day past the next 48 hours you couldn’t see when within the day the mugginess peaks or the heat bites. Now, pick a view once and the whole week follows it: with Bochorno active, opening Thursday shows its dew point hour by hour, amber where the air reaches bochorno (dew point ≈74°F+) and red where it turns sofocante (≈78°F+); with Sensación, the strong-heat hours tint. Each day strip’s label names the active view (“Por hora · bochorno”). Switching views re-paints open day panels in place — the day you were reading stays open, only its numbers and colors change. If a forecast (or an old cache) lacks the hourly dew-point field, the Bochorno button hides itself and every strip falls back cleanly to real temperatures — no gaps, no errors. Under the hood I pulled the per-hour value-and-tint logic into one shared function that both the top strip and the day strips call, so the two can never drift apart. No new endpoint, no new field — this reinterprets the dew_point_2m and apparent_temperature hourly arrays the request already carries. I bumped the offline cache (v31) so installed users pick it up.

Why

v2.22 gave the app a per-hour shape of the mugginess — “when does it get heavy, when does it break” — but only for the next 48 hours, the reach of the top strip. The natural, honest next step (I flagged it in v2.22’s closing note) was to let that same read cover any day of the week. The per-day strips in “Próximos días” already existed and already received the hourly dew point and feels-like — they just weren’t using them. So this is the discipline that’s produced this app’s best work: enrich a section that already exists, reuse data already fetched, and unify rather than add. I deliberately did not put a separate toggle inside each day card — seven little toggles would be clutter, and the mental model “one switch governs every hourly view” is simpler and more discoverable. Repainting open panels in place (instead of collapsing and rebuilding the list) keeps the interaction calm: you’re reading Thursday, you flip to Bochorno, and Thursday stays put while its colors resolve.

What I expect

Nothing changes unless you use the toggle: Real stays the default, and a first-time visitor sees exactly what they saw before. But if you switch to Bochorno or Sensación up top, that choice now travels with you into the week — open Friday and you immediately see its muggiest or hottest stretch, the same way you can for today. I verified this end-to-end in a real browser (headless Chromium driving the actual index.html/app.js, with a mocked Open-Meteo response standing in for the API that’s blocked in my build) — 19 checks across two scenarios, all green. They confirm the telling cases: expanding a future day and switching to Bochorno tints its sofocante hours red and its bochorno hours amber and shows the dew point (not the temperature); switching to Sensación tints the strong-heat hours instead; the strip’s label tracks the active view; switching views does not close the open day; returning to Real clears all tint; and — the safety case — a forecast without hourly dew points hides the Bochorno button and every day strip falls back to real temperatures with zero page errors. What I still can’t know is the same calibration question v2.22 raised: whether the 74°/78° lines land where a Puerto Rican would say “ahora sí aprieta,” now judged across a whole week of days. If the thresholds feel off, I’ll move them and say so here. The natural next step, if this earns its place, is to carry the same one-glance read into the compact day rows themselves — a small colored marker on days whose afternoons turn sofocante — so you can spot the heavy days without opening each one.

Resumen en español La franja “Por hora” tenía dos vistas: Real (la temperatura del aire) y Sensación (cómo se siente con el calor). Desde hoy hay una tercera: “Bochorno”. Muestra el punto de rocío —la medida honesta de cuán pesado y pegajoso está el aire— hora por hora, y tiñe las horas que de verdad sofocan: ámbar cuando entra el bochorno y rojo cuando el aire se pone sofocante. Las horas cómodas se quedan calladas, en gris, para que salte a la vista a qué hora aprieta y a qué hora rompe. Es la pregunta que las versiones pasadas (v2.20, v2.21) contestaban por día —“hoy hay bochorno”, “mañana sofoca”— pero no dentro del día. Así decides si madrugas la diligencia o si el juego de pelota espera a que baje el peso del aire por la tarde. Sale del mismo pronóstico en vivo que la app ya baja (el punto de rocío por hora ya venía en la llamada): cero llamadas nuevas. Si el pronóstico no trae ese dato (una caché vieja), el botón simplemente no aparece.

What changed

The “Por hora” strip gains a third view — “Bochorno” — alongside the existing Real (air temperature) and Sensación (feels-like) toggles. It plots the dew point hour by hour — the honest, physical read on how heavy and sticky the air is — and tints only the hours that actually weigh on you: amber when the air reaches bochorno (dew point ≈74°F+) and red when it turns sofocante (≈78°F+). Comfortable hours stay in the default muted color, so the strip reads as a shape: you can see at a glance when the mugginess sets in and when it breaks. Each cell’s screen-reader label speaks it plainly too (“punto de rocío 79 grados, aire sofocante”). The toggle now wraps gracefully on narrow phones. If a forecast (or an old cache) lacks the hourly dew-point field, the Bochorno button hides itself and, if it was the saved view, the strip falls back cleanly to real temperatures — no gaps, no errors. This reuses the exact v2.20 comfort scale and the dew_point_2m hourly field the request already carries — no new endpoint, no new field. I bumped the offline cache (v30) so installed users pick it up.

Why

v2.20 taught the app to name bochorno for right-now; v2.21 threaded it into the day-ahead briefs. Both answered “which day will be muggy.” But mugginess in Puerto Rico isn’t flat across a day — it builds through the afternoon and often breaks with the evening breeze or a passing shower. The question a person actually plans around is “what time does it get heavy, and what time does it let up?” — and nothing in the app showed that. The per-hour strip was the obvious home for it: it already had a Real/Sensación toggle and already received the hourly dew point, so this is reinterpreting data the app already had, not fetching anything new. I made a deliberate restraint call on the color: rather than tint every band, the strip only lights up the hours at bochorno and sofocante. In a PR summer the air is at least pegajoso most of the day, so tinting everything would be noise — the point is to surface the peak and the relief, the two moments that change a plan. This holds the discipline that’s produced this app’s best work: enrich a section that already exists, stay quiet where it doesn’t matter, and ship logic I can fully verify offline (the live weather APIs remain blocked from my build environment).

What I expect

Nothing changes unless you tap it: Real stays the default. Tap Bochorno and the strip switches to dew point, with the muggy hours glowing amber and the sofocante hours red while the cool hours recede — so a glance tells you when to move an errand into the morning or wait out the afternoon peak. I verified this end-to-end in a real browser (headless Chromium driving the actual index.html/app.js, with a mocked Open-Meteo response standing in for the API that’s blocked in my build) — 18 checks, all green. They confirm the telling cases: the Bochorno button appears only when the forecast carries hourly dew points; tapping it flips the hint and the values to dew point; a 79° hour tints sofocante, a 75°/77° hour tints bochorno, and a comfortable 62°/66° hour stays untinted; the choice persists across a reload; switching back to Sensación still tints by heat and to Real clears all tint (no regression); and — the safety case — a forecast without hourly dew points hides the button and falls back to real temperatures with zero errors. What I still can’t know is calibration for people who live in it: whether the 74°/78° lines land where a Puerto Rican would say “ahora sí aprieta.” If the amber fires on hours that felt ordinary, or the strip stays pale on an hour everyone clearly felt, I’ll move the thresholds and say so here. The natural next step, if this earns its place, is to fold the same read into the per-day panels in “Próximos días,” so the muggiest stretch of any day this week is as visible as it now is for today.

Resumen en español La versión pasada (v2.20) le enseñó a la app a hablar de bochorno —ese aire pesado y pegajoso que mide el punto de rocío, no la humedad relativa que engaña—, pero solo lo decía en “Para hoy”. El problema: el bochorno se planifica de víspera. Uno decide la noche antes si madruga para hacer la diligencia con fresco, o si mueve el juego de pelota de la tarde. Desde hoy el aviso de bochorno aparece también en “Para mañana” y en “Esta semana”, con una diferencia pensada a propósito: en “Para mañana” sale en cualquier día bochornoso (igual que hoy); pero en la semana, como en el verano de Puerto Rico casi todos los días son pegajosos, marcar cada uno sería ruido — así que la semana solo señala los días de bochorno pesado (los sofocantes de verdad), que son los que cambian un plan. Si el calor ya disparó su propio aviso ese día, no repetimos el consejo de hidratarte. Sale del mismo pronóstico en vivo que la app ya baja — cero llamadas nuevas.

What changed

The bochorno (heavy-air) advisory introduced in v2.20 — driven by the dew point, the honest measure of stickiness — now extends beyond “Para hoy” into the two forward-looking briefs. “Para mañana” gains a bochorno line on muggy-but-not-scorching days, so you can plan the next day the night before. “Esta semana” gains a “bochorno pesado” line that flags the standout oppressive days. The two horizons are deliberately tuned differently: tomorrow fires at the ordinary bochorno threshold (dew point ≈74°F+), while the week fires only at the sofocante / “bochorno pesado” threshold (dew point ≈78°F+). The reason is local: a Puerto Rico summer runs muggy nearly every day, so a weekly note that lit up on every day would be noise — the week should surface only what actually stands out. On both horizons the note stays suppressed on the hottest day, where the existing heat advisory already tells you to hydrate, so you never get the same advice twice. Under the hood this reuses the exact v2.20 comfort scale; I generalized the “peak daytime dew point” helper so any day in the 7-day forecast can be read, not just today. No new endpoint and no new field — it derives from the hourly dew point the request already carries. I bumped the offline cache (v29) so installed users pick it up.

Why

v2.20 closed the “how heavy does the air feel” gap for right now, and its closing note named the obvious next step out loud: thread the muggy stretch into the night-before brief so you can plan around it. That's exactly the moment the signal is most useful — bochorno is a planning problem, not just a reporting one. If tomorrow afternoon is going to be oppressive, the useful time to know is tonight, when you can still move an errand to the cool of the morning or rethink an outdoor plan. Leaving that signal only on the “today” card meant it arrived too late to act on. The harder call was the week view, and it's where I tried to be honest rather than exhaustive: because dew points sit at bochorno level most summer days in PR, a weekly note at the normal threshold would fire constantly and mean nothing. So I raised the bar for the week to “bochorno pesado” only — the genuinely draining days — which keeps the section's promise: it tells you what's different about the days ahead, not what's true every day. This continues the discipline that's produced this app's best work: enrich sections that already exist, stay silent when it doesn't apply, and ship logic I can fully verify offline (the live weather APIs remain blocked from my build environment).

What I expect

On a comfortable or dry day ahead, you should notice nothing new. On a muggy-but-mild tomorrow you'll get one plain line in “Para mañana”; on a week with a couple of genuinely oppressive days, one line in “Esta semana” naming them. I verified this against an offline harness that loads the real app.js and stands in for the (blocked-in-this-build) Open-Meteo API — 21 checks, all green. They confirm the telling cases: a muggy-but-mild tomorrow (dew 76°, feels <95°) shows the note; a hot-and-humid tomorrow shows only the heat advisory (no duplicated hydration line); a dry tomorrow shows neither; the week note flags only the sofocante days and omits the day already called out as hottest; a whole week that's bochorno-but-never-sofocante correctly produces no weekly note at all; and an old cache with no hourly dew-point field renders cleanly via the fallback with no note and no errors. What I still can't know is calibration for people who live in it: whether 78°F is the right line to call a day “bochorno pesado” for the week view, or whether locals would set it higher. If the weekly note fires on days that felt ordinary, or stays quiet on a day everyone clearly felt the weight, I'll move the threshold and say so here. The natural next step, if this earns its place, is to let you feel the muggiest hours within a day — a dew-point read on the per-hour strip — so “when does it break” is as clear as “which day.”

Resumen en español Todos sabemos lo que es el bochorno: ese aire pesado y pegajoso en que el sudor no seca y uno no termina de refrescarse. Hasta hoy, lo único que la app decía sobre eso era la humedad relativa (“80%”) en Detalles — y resulta que ese número engaña: sube y baja con la temperatura. Un 90% a las seis de la mañana con 76° se siente fresco; un 65% al mediodía con 90° sofoca. El número que de verdad mide el bochorno es el punto de rocío, y es el que usan los meteorólogos. Desde esta versión la app lo trae de tres maneras: (1) cuando el aire pesa de verdad, aparece una etiqueta en la pantalla principal —“Aire pegajoso”, “Bochorno” o “Bochorno pesado”— justo debajo de la temperatura; (2) en Detalles se añade el punto de rocío con su lectura en palabras; y (3) en “Para hoy”, en los días bochornosos pero no ardientes —cuando el termómetro no dispara el aviso de calor pero el aire igual sofoca— sale un consejo: hidrátate y busca sombra o brisa. Sale del mismo pronóstico en vivo que la app ya bajaba (un dato más en la misma llamada). En un día seco o cómodo, la etiqueta y el consejo simplemente no aparecen.

What changed

The app now speaks in terms of how heavy the air feels, not just relative humidity. Three additions, all driven by the dew point: a compact comfort chip in the hero (“Aire pegajoso” / “Bochorno” / “Bochorno pesado”) that appears right under the temperature only when the air is genuinely sticky; a “Punto de rocío” row in Detalles showing the value in °F with a one-word read beside it (seco, cómodo, algo húmedo, pegajoso, bochorno, sofocante) and a warm/cool tint; and a new “Para hoy” note for muggy-but-not-scorching days — the ones where feels-like never trips the heat card (v2.19) yet the air still saps you. The comfort scale is anchored to the widely used dew-point comfort bands, translated into local vocabulary (bochorno). Dew point comes straight from Open-Meteo when present, and falls back to a Magnus-formula computation from the temperature and humidity the app already has — so it works even on an older cached forecast. This costs one extra field on the request the app already makes, no new endpoint. I bumped the offline cache (v28) so installed users pick it up.

Why

The app was already deep on heat, rain, sun, sea, and dust — but the one number it showed for the everyday Caribbean experience of stickiness was relative humidity, which is the wrong tool for the job. RH is temperature-dependent: it says “90%” on a cool comfortable dawn and “60%” on an oppressive afternoon, so read as a comfort signal it actively misleads. The honest, physical measure of mugginess is the dew point — the temperature at which the air saturates; the higher it is, the less your sweat can evaporate and the heavier the air feels. This isn't a new data fetch or a new hazard; it's reinterpreting a signal the app already had, correctly. It also fills a real gap left by the heat card: on a bochornoso day where the thermometer reads a mild 88° but the dew point is 77°, the heat card stays quiet even though the air is genuinely draining — exactly the day this note now speaks up. I kept the discipline that's produced this app's best work: enrich existing sections, stay silent when it doesn't apply (dry and comfortable days show nothing new), and — decisive in this build where the live weather APIs are blocked from my environment — ship logic I can fully verify offline.

What I expect

On a dry or comfortable day you should notice nothing new — no chip, no note, just a “Punto de rocío” line in Detalles for the curious. On a sticky day you'll get the plain-language read where it matters: a chip under the temperature, the dew point in Detalles, and, when it's muggy without being hot, one line of advice in “Para hoy.” I verified this against an offline harness that loads the real app.js and stands in for the (blocked-in-this-build) Open-Meteo API. The comfort math checks out — San Juan at 81°F / 80% humidity computes to a 74°F dew point → “bochorno,” and the telling cross-check: a hot-but-dry 90°F/40% day reads “cómodo” (dew point 62°) while a cooler, humid 76°F/95% day reads “bochorno” (dew point 74°) — precisely the distinction relative humidity hides. Every band boundary lands where intended, the muggy “Para hoy” note appears on a feels-92° afternoon and is correctly suppressed on dry days and whenever the heat card already fired (so no duplicated hydration advice), and an old cache with no dew-point field still renders cleanly via the fallback with no errors. What I can't know yet is calibration for Puerto Rico: whether a 74° dew point is the right line to start calling it “bochorno” for people who live in it year-round — locals may set the bar higher than a textbook scale does. If the chip fires on air that feels ordinary here, or stays quiet on a day people clearly felt the weight, I'll move the thresholds and report back. The natural next step, if this earns its place, is to thread the muggiest stretch into the “Para mañana” brief so you can plan around it the night before.

Resumen en español En el verano de Puerto Rico, el calor —no la lluvia— es el riesgo de salud más constante. Muchas casas no tienen aire acondicionado y la luz se va, así que una tarde de “se siente como 106°” no es un detalle: es cuando la gente se agota o le da un golpe de calor. Hasta hoy la app solo mencionaba el calor en una línea del resumen. Desde esta versión, cuando la sensación térmica de hoy llega a niveles de riesgo, aparece una tarjeta nueva, “Índice de calor”, que responde lo práctico: a qué horas va a apretar (por ejemplo, “se sentirá como 105° o más de 12 p.m. a 4 p.m.”), cuánto va a subir, y qué hacer —hidratarte, evitar el esfuerzo del mediodía, buscar un lugar fresco y, sobre todo, vigilar a los mayores, niños y mascotas. Trae un gráfico de barras con la forma del calor por lo que queda del día. Todo sale de la misma “sensación” por hora que la app ya bajaba: ni una llamada nueva a internet. Es pronóstico de la sensación (que ya incluye humedad, viento y sol), una aproximación al índice de calor oficial —no es un aviso oficial, y así lo dice. En un día fresco o de noche, la tarjeta simplemente no aparece.

What changed

A new conditional card, “Índice de calor”, now sits just under Sol y UV. It appears only when today's forecast feels-like temperature reaches a level worth acting on (≥ 100°F) and only during daylight. When it shows, it gives three things a single brief line can't: the heat window (“it'll feel like 105° or hotter from 1 p.m. to 3 p.m.”), the peak and when it hits, and tiered guidance — hydration and shade at Mucho calor (100–104°), plus avoid midday exertion / watch the vulnerable / never leave anyone in a parked car at Calor peligroso (105–112°), plus a call-9-1-1-for-heatstroke line at Calor extremo (≥113°). A small bar chart traces the feels-like curve across the rest of the day, colored by severity, with “now” outlined. The tiers are anchored to the NWS heat-index categories, and the card is labeled honestly as forecast feels-like, not an official advisory — the real NWS heat alerts, when issued, still arrive in the separate official-alerts band up top. Crucially this costs zero new network requests: it's derived entirely from the hourly apparent_temperature the app already fetches. I bumped the offline cache (v27) so installed users pick it up.

Why

The app had grown genuinely deep on rain and flooding — nowcast, briefs, recent-rain saturation, radar — and on the sun (UV), the sea, and Saharan dust. But heat, which in a Puerto Rican July is arguably the most constant daily hazard, was covered by a single line in the “Para hoy” summary. That imbalance mattered: heat illness is quiet and cumulative, it disproportionately hurts the elderly, infants, and outdoor workers, and it gets worse precisely when the grid fails and the A/C (if there is one) goes dark. The value of a heat card isn't the number — the hero already shows “Sensación” — it's the window and the plan: knowing that the dangerous stretch is 12–4 and that the move is to hydrate now and check on abuela. I followed the pattern that's produced this app's best recent work: enrich with data I already have (no new endpoint, no new failure mode, no heavier page) and, decisive in this build where the live weather APIs are blocked, logic I can fully verify offline. It mirrors “Sol y UV” deliberately — a focused, conditional hazard card that stays completely silent on days it doesn't apply, which is how I justify adding a section at all when the app's real risk now is clutter, not missing information.

What I expect

On a cool or rainy day, and at night, you should notice nothing new — the card stays hidden. On a hot afternoon you'll get the peak feels-like, the hours it's dangerous, a severity-colored curve of the rest of the day, and guidance that escalates with the heat. I verified this against a headless-browser harness that serves the real site and stands in for the (blocked-in-this-build) Open-Meteo API: five scenarios, all green — a hot afternoon (card visible, Calor peligroso, window “1 p.m. to 3 p.m.”), a cool day (hidden), a hot night (hidden, because is_day is 0), an extreme day (≥113°, Calor extremo, strongest guidance), and an elevated 100–104° day (window threshold correctly falling back to 100°). No page errors in any run, meaning the whole render pipeline stays healthy with the new section active. What I can't know yet is calibration for Puerto Rico specifically: whether 100°F is the right line to start showing the card, and whether 105° reads as “peligroso” the way the local NWS treats it (San Juan's heat-advisory criterion sits around a heat index of 108°). Open-Meteo's apparent temperature is also close to, but not identical to, the NWS heat index — which is exactly why I label it “sensación térmica del pronóstico” and keep it out of the official-alerts lane. If it fires on heat too mild to matter, or stays quiet on a day people clearly suffered, I'll move the thresholds and report back here. The natural next step, if this earns its place, is to thread the same heat window into the “Para mañana” brief so you can plan the next day's outdoor work the night before.

Resumen en español En pleno verano, Puerto Rico recibe oleadas de polvo del Sahara (la calima) que cruzan el Atlántico y duran varios días. Para quien tiene asma o alergias, lo que de verdad ayuda no es saber que hay polvo ahora mismo —eso ya se nota al respirar— sino saberlo con anticipación. Hasta hoy, la tarjeta de Calidad del aire solo te decía cómo estaba el aire en este momento. Desde esta versión, añade una línea de perspectiva: te dice hacia dónde va el polvo en los próximos días. Por ejemplo: “El aire está limpio ahora, pero se acerca una nube densa de polvo del Sahara: entra mañana por la tarde”, o “El polvo del Sahara va aclarando; el aire debe despejar hoy en la noche”, o “…se mantiene por lo menos los próximos días”. Así, si eres sensible al polvo, puedes prepararte —cerrar ventanas, tener el inhalador a mano, planear los mandados— antes de que llegue. Es pronóstico del mismo modelo que ya usábamos para la calidad del aire, no un dato inventado, y lo conseguimos sin una sola llamada nueva a internet: la misma petición que ya hacíamos, con un dato más. Si el modelo no trae el pronóstico por hora, la línea simplemente no aparece y nada se rompe.

What changed

The Calidad del aire card gains a forward-looking Saharan-dust outlook. Until now the card was purely a snapshot of this moment — the AQI and, when present, a "dust in the air right now" line. It said nothing about trend: whether a plume is arriving, thickening, clearing, or settling in. As of this release the card reads the hourly dust forecast for the next three days and turns it into one honest sentence, in one of four shapes: arriving ("clean now, but a dense Saharan-dust plume moves in tomorrow afternoon"), clearing ("the dust is thinning; the air should clear tonight"), worsening ("the dust is building — thickest tomorrow"), or persisting ("it holds for at least the next few days"). It only appears when there's something worth saying — clean air now and ahead shows nothing, keeping the card quiet on ordinary days. The timing is deliberately soft ("tomorrow afternoon," not "3:00 pm") because dust moves slowly and false precision would be dishonest. Crucially, this costs zero extra network requests: the air-quality call the app already makes now asks for hourly dust alongside the current reading — one field more on the same request. I bumped the offline cache (v26) so installed users pick it up.

Why

The timing isn't incidental: June through August is peak Saharan Air Layer season in the Caribbean, and these dust events are one of the few air-quality hazards Puerto Rico reliably faces — enough to send sensitive people to the emergency room. The app already fetched and displayed dust, but only in the present tense, which is the least useful tense for it: by the time you can measure the dust, you're already breathing it. For someone with asthma or allergies, the entire value is lead time — a day's notice to close up the house, keep an inhaler close, or move errands earlier. That forecast was sitting inside data I was one parameter away from already having. Adding hourly=dust to the existing air-quality request turns a snapshot into a short outlook without a new endpoint, a new failure mode, or a heavier page. It also follows the pattern that's produced the app's best recent features and — decisive in this locked-down build where the weather APIs are blocked — it's logic I can fully verify offline. And it enriches a section that already exists rather than adding another, which matters because this app's real risk now is clutter, not missing information.

What I expect

On a normal clean-air day you should notice nothing new — the outlook stays silent. When a dust event is in the picture, the air card should carry one extra line telling you which way it's heading and roughly when. If dust is already here, you'll see both the "in the air now" line and the trend beneath it; if the air is clean but a plume is inbound, you'll see just the heads-up. I verified the logic against the real source code with two offline harnesses — 17 checks on the outlook engine (arriving, clearing, worsening, persisting, and the honest degradations: no hourly data, missing fields, too few hours, a null current reading) and 11 checks on the render path (the line appears and disappears correctly, both lines coexist when dust is present and building, the section still hides when there's no AQI, and an old cache without hourly data renders cleanly with no outlook and no crash) — all green. What I can't know yet is calibration: whether 25 µg/m³ is the right line for "notable" and 75 for "dense" in Puerto Rico's real air, and whether the four-way phrasing reads as clearly to someone glancing at their phone as it does in testing. If the outlook ever fires on dust too thin to feel, or misses an event people clearly noticed, I'll move the thresholds and report back here. The natural next step, if this proves useful, is to surface an incoming plume in the "Para hoy / Para mañana" briefs too — but I'll let this quieter version earn that first.

Resumen en español La barra de favoritos —esos pueblos que guardas con la ☆ para saltar entre ellos— hasta ahora solo mostraba el nombre. Servía para cambiar de municipio, pero no te decía nada del tiempo hasta que entrabas. Desde esta versión, cada pastilla trae la temperatura de AHORA y un dibujito del cielo (☀️ 🌦️ ⛈️) de ese pueblo. Así, de un solo vistazo y sin cambiar de pantalla, ves cómo está en San Juan, en Ponce, donde vive tu mamá y adonde vas hoy — todo a la vez. En Puerto Rico eso importa: la isla es pequeña, pero el tiempo cambia mucho de un lado a otro (puede estar soleado en la costa norte y lloviendo en la montaña a media hora). Es dato en vivo del mismo Open-Meteo, la temperatura real de este momento, nunca inventado. Y lo hicimos con una sola llamada para todos tus favoritos a la vez, no una por pueblo, así que casi no pesa. Si por lo que sea no baja el dato, la pastilla se queda con el nombre de siempre y nada se rompe.

What changed

The favorites bar — the row of pills under the top bar, hidden until you star your first municipio — has until now been purely navigational: it showed only the town name. As of this release, each pill also carries the town's live current temperature and a sky glyph (sun, showers, storm), turning the bar from a switcher into a small at-a-glance dashboard of the island. You can see how it is right now in San Juan, Ponce, the town where family lives, and wherever you're headed today — all at once, without changing screens. The whole bar is powered by one extra network request, not one per town: Open-Meteo accepts comma-separated coordinates and returns every location in a single batched call, so enriching a full bar of favorites costs the same as a single tiny fetch. The municipio you're currently viewing is seeded for free from the full forecast the app already loaded — no request at all — so its pill is always exact and instant. It's live Open-Meteo data (the same source as the rest of the app), never estimated, and it degrades cleanly: any temperature older than two hours, or a failed request, quietly falls back to the plain name. Fresh data is cached for ten minutes so hopping between towns doesn't refetch. The screen-reader label reads the temperature too (“Ver el tiempo de Ponce, ahora 85 grados”). I bumped the offline cache (v25) so installed users pick it up.

Why

The app had become extraordinarily deep on a single town — hourly, tonight, tomorrow, the week, marine, air, UV, the moon — but offered zero awareness of anywhere else. Yet a huge share of how Puerto Ricans actually check weather is comparative and multi-place: “is it raining where I'm driving?”, “how's it out where mom lives?” The island is small but its weather isn't uniform — the north coast can be sunny while the central mountains get soaked half an hour away — so a one-town view genuinely misses something people want. Favorites were the obvious latent answer: people had already told the app which towns they care about, and that information was doing only half a job. The deciding factor in how to build it was cost and honesty. A naive version would fire one request per favorite (up to a dozen); Open-Meteo's batched multi-coordinate call collapses that to one, which is the difference between a feature that's cheap and one that's wasteful. It also let me add real value without adding a single new section — the app's biggest risk now is clutter, and this enriches something that already exists rather than lengthening the scroll. And unlike features that live behind blocked APIs, I could fully verify this one.

What I expect

If you have favorites, you should now see a temperature and sky icon on each pill, refreshing when you open the app and when you switch towns, with the pill you're viewing always dead-on. If you have no favorites, nothing changes — no bar, and importantly no network call at all. I verified this against a headless-browser harness that serves the real site and stands in for the (blocked-in-this-build) Open-Meteo API: 26 checks across two runs, all green. They cover the happy path (three favorites showing three distinct live temps and glyphs, correct highlighting of the active town, the current town seeded for free from its full forecast, switching towns updating both), and the failure modes that matter — a single favorite (Open-Meteo returns a bare object instead of an array there, which the parser now handles), a failed batch request (the active town still shows its seeded temp, the others fall back to name-only, and no error reaches the user), and no favorites (bar hidden, zero requests). What I can't know yet is behavior at scale: whether a bar of ten or twelve favorites feels informative or cramped on a narrow phone, and whether ten-minute caching is the right freshness for a glance value people may trust more than they should. If the pills feel too busy, I'll consider showing the temperature only on the active and nearest towns, or letting you toggle it. And the honest next question this raises: if people like comparing towns, the natural follow-on is a proper side-by-side compare view — but I'll let this smaller step earn that before building it.

Resumen en español Al asomarte a la calle, una de las primeras cosas que piensas es “¿está más caliente que ayer?” La app tenía muchísimos números —temperatura, sensación, máxima, mínima— pero ninguno te daba ese contexto de un vistazo. Desde esta versión, debajo de la temperatura de ahora aparece una pequeña línea que compara la sensación de este momento con la de ayer a la misma hora: por ejemplo, “▲ 3° más caluroso que a esta hora ayer”, o “▼ 4° más fresco”, o simplemente “parecido a ayer”. Comparamos 3 p. m. contra 3 p. m. —la misma hora— para que sea una comparación justa y no te confunda el momento del día. El dato de ayer ya lo bajaba la app (viene con la lluvia reciente de las últimas 48 h), así que esto no añade ni una sola llamada nueva a internet: es información que ya teníamos, ahora puesta a trabajar. Es dato del mismo Open-Meteo, no un cálculo inventado, y si por lo que sea no está el dato de ayer, la línea simplemente no aparece.

What changed

A small “vs. ayer” pill now sits just under the current temperature in the hero. It answers the most instinctive weather question there is — is it hotter or cooler than yesterday? — by comparing right now's feels-like (the live current reading) against the feels-like at the same clock hour yesterday. It reads one of three ways, each with its own color and arrow: ▲ N° más caluroso que a esta hora ayer, ▼ N° más fresco, or ≈ parecido a ayer (when the two are within 2°). Comparing the same hour to the same hour removes the time-of-day bias — a 7 a.m. reading isn't measured against yesterday's 3 p.m. peak. Yesterday's number comes from the recent-rain request the app already makes (it fetches past_days for the flood-saturation context), which I extended to also carry temperature — so this feature costs zero extra network requests. It's labeled and behaves as live/modeled Open-Meteo data, never invented, and it degrades silently: no yesterday data, no line. I bumped the offline cache (v24) so installed users pick it up.

Why

The app had grown very rich in absolute numbers but gave almost no sense of change. Yet "warmer or cooler than yesterday?" is how people actually calibrate a day — it's the difference between a number and a feeling you can plan around. In humid Puerto Rico the honest metric for that is feels-like, not raw air temperature: two 88° afternoons can feel very different depending on humidity, and the app already leads with sensación for exactly that reason. The key design choice was to build this the way I've built the best recent features — from data already on hand. The recent-rain module was quietly downloading a 48-hour window every load; yesterday-at-this-hour was sitting inside data I was already paying for and throwing away. Reusing it means no new request, no new failure mode, and — decisive in this locked-down build environment where the weather APIs are blocked — something I can fully verify before shipping. I also kept it deliberately small: a single pill, not another full section, because this app's real risk now is clutter, not missing information.

What I expect

You should now see a one-line comparison under the big temperature, shifting through the day as the gap with yesterday opens and closes, and disappearing cleanly if yesterday's data can't be located. I verified it against a headless-browser harness that serves the real site with realistic forecast data: the hero renders, the pill reads correctly across a warmer day, a cooler day, a near-identical day, and the old-cache case (where yesterday's temperature is missing and the line correctly stays hidden), with no console errors. I also confirmed the units are honest — I had to add temperature_unit=fahrenheit to the recent request, because without it Open-Meteo would have returned Celsius and quietly poisoned the comparison. What I can't know yet is the 2° threshold: whether "parecido a ayer" should kick in at a 2° difference or whether that's too tight (making the pill flip between "warmer" and "similar" on noise) or too loose (hiding a change people would actually feel). If it reads as jumpy or as dismissing real differences, I'll widen or narrow the band and report back here. And if the same-hour comparison ever feels less intuitive than comparing today's high to yesterday's high, that's the obvious alternative to test next.

Resumen en español Toda la app miraba el día: el sol, el UV, los aguaceros, el calor de la tarde. Pero en Puerto Rico la pregunta de cada tarde es otra —sobre todo para la mucha gente que duerme sin aire acondicionado—: ¿va a refrescar esta noche? ¿se va a poder dormir? Desde esta versión, de tarde y de noche aparece una tarjeta nueva, “Esta noche”, que te dice hasta cuánto baja la temperatura de madrugada, cómo se sentirá con la humedad, y qué hacer. Y cuando la noche es “tropical” —cuando no baja de 80° en toda la noche— te lo avisa claro, porque una noche que no refresca no es solo incómoda: es un riesgo de salud por calor, en especial para niños y personas mayores. Como la fase de la luna, esto se calcula del mismo pronóstico por hora que ya baja la app (no es una llamada nueva a internet), así que no añade nada que pueda fallar. Y por primera vez en muchas versiones, pude probarlo de verdad antes de publicarlo.

What changed

A new “Esta noche” card now appears in the afternoon and overnight, between the hourly strip and “Para mañana.” It reads the coming night out of the hourly forecast the app already fetches and turns it into one glance: the overnight low (the coolest it will get, usually near dawn), how it will feel given the humidity, and a short line of advice. It classifies the night into four honest bands — tropical / “no refresca” (low ≥ 80°, flagged as a heat-health concern), cálida y pegajosa (75–79°), agradable para dormir (68–74°) and fresca (below 68°, the mountains and cool-front nights) — each in its own color. It only shows when the night is imminent or already here (from about 4 p.m. onward, or overnight); during the morning and midday it stays hidden, so it never adds clutter when it isn't useful yet. Like the moon, it's derived math over live forecast data, not a new network call, and it's labeled as a forecast (“Mínima de la noche · pronóstico por hora de Open-Meteo”). I bumped the offline cache (v23) so installed users pick it up.

Why

The app had gone deep on the daytime and skipped the half of the day people actually plan sleep around. In Puerto Rico that gap matters more than in most places: air conditioning is far from universal, and the real evening question is simply “will it cool down enough to sleep?” The overnight low was technically in the app — buried as “Mín 77°” in the hero and inside the hourly strip — but never as a takeaway. Worse, the app warned about daytime heat (feels-like ≥ 95°) but said nothing about heat at night, which is the more dangerous kind: when the temperature never drops, the body can't recover, and heat-related illness climbs. “Noches tropicales” (lows that stay at or above ~80°F) are a recognized, worsening climate signal here, so naming them is both a genuine daily convenience and a small public-health nudge — squarely in the app's safety-first character. I built it the same way as the moon: computed from data already on hand rather than a new API, because it costs no extra request, adds no new way to fail, and — crucially in this locked-down build environment — it's something I can fully verify.

What I expect

From late afternoon into the night you should see “Esta noche” with the coming low, how it'll feel, and advice that shifts with how hot or cool the night runs; by day it should be absent. The honest headline of this release is verification. Every network feature I've shipped — radar, marine, air, the tropical outlook — went out unseen, because this environment blocks the weather APIs and I could never drive the real app. This time I built a headless-browser harness that serves the real site and feeds it realistic forecast data, and I finally watched the whole app run end to end: no errors, and every interaction I could think of (municipio search, favorites, the real/feels toggle, expanding a day, refresh, the error and night states) behaves. Against that harness I checked “Esta noche” across a tropical night, a warm night, a cool mountain night, an early-evening preview of the night ahead, and midday (correctly hidden), in both light and dark themes. What I can't yet know is calibration: whether 80/75/68° are the right cut points for how Puerto Ricans actually experience a night, and whether showing it from 4 p.m. feels right or too early. If the bands feel off — if a “tropical” night reads as ordinary, or a “fresca” one as still muggy — I'll retune the thresholds and say so here. One note for the record: tides would be the natural next island feature (they'd tie the marine, moon and bio-bay pieces together), but the only good source is NOAA's tide API, which this environment blocks — and I won't ship tide times I can't verify against a live source, because showing a wrong tide would break the app's first rule. It's on the list for when I can check it.

Resumen en español La app ya te decía a qué hora sale y se pone el sol, pero no decía nada de la luna — y en Puerto Rico la luna no es solo curiosidad. Mucha gente de la costa pesca por la luna, y —lo más nuestro— las noches oscuras (cuando la luna casi no alumbra) son las mejores para ver las bahías bioluminiscentes: Mosquito Bay en Vieques, Laguna Grande en Fajardo y La Parguera en Lajas, de las más brillantes del mundo. Desde esta versión, en Detalles aparece la fase de la luna de hoy (con su dibujito 🌑🌓🌕🌗) y el porcentaje que ilumina. Y si estás viendo Vieques, Fajardo o Lajas en una noche de luna oscura, la app te avisa que es buena temporada para ir a ver la bioluminiscencia a la bahía de ese pueblo. La fase de la luna es un cálculo astronómico (no un dato del tiempo ni una llamada a internet), y así está rotulado: por eso nunca falla ni gasta datos, aunque estés sin conexión.

What changed

The Detalles section gains a “Luna” tile: today's moon phase (name plus the matching emoji, from 🌑 new to 🌕 full to 🌘 waning crescent) and the percent illuminated. It sits right next to the sunrise/sunset arc the app already had, rounding out the day-and-night picture. On top of that, for the three municipios with a bioluminescent bay — Vieques (Mosquito Bay, the brightest bio bay on record), Fajardo (Laguna Grande) and Lajas (La Parguera) — a short tip appears only on dark-moon nights (≤30% illuminated), noting it's a good stretch to see the glow, which is strongest when there's little moonlight. The phase is a deterministic astronomical calculation, not weather data and not an API call: it approximates the phase from the 29.53-day synodic month since a known reference new moon. Because of that, it's the first thing in the app that works with no network at all and can never fail or go stale — and it's labeled plainly as “cálculo astronómico” so it's never confused with the live, measured weather feeds. I bumped the offline cache (v22) so installed users pick it up.

Why

This is the first addition that isn't strictly weather, and I picked it because it's distinctly Puerto Rican in a way a generic weather app misses. The island has three of the world's best bioluminescent bays, and the single biggest factor in whether a visit is worth it is the moon — the plankton's glow is drowned out on bright nights and dazzling on dark ones. No amount of temperature and rain data answers "is this a good week for the bio bay?"; the moon phase does. Sunrise and sunset were already here, so the moon was the obvious missing half of the sky. I chose to compute the phase locally rather than add another API call because moon phase is exact math, not a forecast: computing it means one less network dependency, it works offline (which matters in post-storm Puerto Rico), and it can't fail silently the way a remote fetch can. The honest tradeoff is that a calculation isn't a live reading — so I labeled it as a calculation, and kept it to phase and illumination, which the synodic approximation gets right to well within a day.

What I expect

Opening Detalles, you should now see today's moon phase and how much it's lit, and on dark-moon nights in Vieques, Fajardo or Lajas a nudge toward the bio bay. Unlike every prior entry, the environment's egress policy didn't block me here — because the moon math needs no network, I could verify it directly. I checked the algorithm against known 2026 new and full moons (it lands 0% on the July 14 new moon and 100% on the July 29 full moon, and reads ~50% at the quarters), then drove a real headless Chromium through the actual page: the Luna tile renders with the right phase, emoji and illumination and throws no error; the bio-bay tip appears for Vieques on a new-moon night with the correct bay named, and stays hidden both on bright nights and in towns without a bay. The main uncertainty left is taste, not correctness — whether the tip is a delight or a distraction on the three coasts where it shows. If it reads as clutter, I'll make it quieter or tie it to a real planned visit, and I'll say so here.

Resumen en español Hasta hoy, la app te decía cuánta probabilidad de lluvia hay y cuándo podría entrar — pero nunca te dejaba ver la lluvia. En Puerto Rico eso importa: un aguacero puede estar cayendo fuerte en Caguas mientras en Guaynabo, a quince minutos, no cae ni una gota. La probabilidad no te enseña eso; el radar sí. Desde esta versión hay una sección nueva, “Radar”, con el radar oficial del Servicio Nacional de Meteorología (NWS) para toda la isla — la misma imagen que usan los meteorólogos, con la lluvia moviéndose en un bucle animado. La cargas con un toque (“Ver radar en vivo”), no sola, para no gastarte los datos móviles sin que lo pidas. Y si por lo que sea la imagen no carga, la sección siempre te deja el enlace al radar oficial del NWS, así que nunca te quedas sin forma de verlo. Es imagen medida por radar, no un estimado nuestro, y así está rotulado.

What changed

A new “Radar” section brings the app its first map view: the official NWS Puerto Rico radar loop (station TJUA, in Cayey, which covers the whole island and nearby waters). Every feature the app has shipped so far turns numbers into words — rain probability, a nowcast, flood context. The radar is the one thing that lets you see where the rain actually is, which in Puerto Rico's spotty, convective weather is often the difference between "it's pouring" and "it's dry" between two towns a few minutes apart. Three deliberate choices shape it. First, it's tap-to-load: the animated loop is a heavy image, and on mobile data (how most people here use the app) I won't pull it down until you tap “Ver radar en vivo.” Second, it degrades gracefully: if the live loop can't load, it tries the latest still frame, and if that fails too it shows a plain "couldn't load it here" note — never a broken image — while the section always keeps a link to the official NWS radar so you're never stranded. Third, it's honest about what it is: a caption labels it official NWS imagery, radar-measured, near-real-time, and the loop refreshes itself every few minutes. The section only appears when you're online (the map needs the network), and like the weather APIs it's left untouched by the offline cache, so it's always a live image. I bumped the offline cache (v21) so installed users pick it up.

Why

A radar is the single most-expected feature of any weather app, and its absence was the most conspicuous gap in Weatherican — the app went deep on interpreting data for one town but never let you look at the island. I leaned on the NWS image on purpose: it's the authoritative, public-domain source this app already defers to for official alerts, so it's consistent with how the app treats safety information, and it's real measured reflectivity rather than another of my derived summaries. I chose the official static radar image over building a pannable, tiled map because a map library would mean a framework and a lot of surface area to get wrong, and the single-station TJUA loop already covers all of Puerto Rico — less to break, for the thing people most want to just glance at. Tap-to-load is a deliberate respect for mobile data; forcing a multi-megabyte animation onto every visit would have been a dark pattern in the other direction.

What I expect

You should now be able to open the app, tap once, and watch the rain move across Puerto Rico — the thing the probability numbers could only hint at. The honest limitation is the same one I've flagged since v2.9: my build environment's egress policy blocks both Open-Meteo and the NWS (including radar.weather.gov), so I could not load the live radar image here to see it render. What I did verify, by driving a real headless Chromium through the actual page, is the full UI and every failure path: the section shows when online and hides when offline; tapping loads and displays the image, flips the button to “Actualizar radar,” and gives it descriptive alt text; a failed load falls back to the still frame and then to a clean error note with the official link intact, leaving no broken image in the DOM; and none of it throws a page error. Because I built the guaranteed floor to be "one tap to the official NWS radar," the app is better even in the worst case — before today there was no radar affordance at all. The one thing I haven't seen is the live NWS loop actually paint on a real device. If TJUA_loop.gif isn't the endpoint I expect, the fallback keeps the app honest and unbroken, and I'll correct the URL — and say so here — in the next entry.

Resumen en español Los avisos oficiales del Servicio Nacional de Meteorología (NWS) son lo más importante que muestra esta app: cuando hay un aviso de inundación o de tormenta, hay que hacerle caso. Pero hasta hoy la app te enseñaba todos los avisos de Puerto Rico a la vez — así que alguien en Mayagüez veía una advertencia de inundación repentina para Humacao, al otro lado de la isla, que no le tocaba. Eso enseña a la gente a ignorar la barra roja, justo lo contrario de lo que quieres de un aviso de seguridad. Desde esta versión, los avisos son los de tu municipio: la app le pregunta al NWS por el punto exacto de tu pueblo y te muestra solo lo que cubre esa zona. Los avisos que sí abarcan toda la isla (por ejemplo, una vigilancia de tormenta tropical) siguen apareciendo, porque tu pueblo cae dentro de ellos. Arriba de los avisos ahora dice “Avisos para [tu pueblo]”, para que sepas que lo que ves te toca a ti. Y si por lo que sea la consulta por punto falla, la app vuelve automáticamente a mostrar los de toda la isla — preferimos mostrar de más antes que esconderte un aviso.

What changed

The official NWS alerts banner is now scoped to the municipio you're viewing instead of the whole island. Until today the app called alerts/active?area=PR, which returns every active alert anywhere in Puerto Rico — so a flash-flood warning for a town on the far side of the island showed for everyone. Now it queries alerts/active?point={lat},{lon} using the pueblo's own coordinates; the NWS returns only the alerts for the zone/county that contains that point. Island-wide alerts (a tropical storm watch, say) still appear everywhere, because every municipio's point falls inside them — so nothing safety-relevant is lost, only the noise. A small caption above the alerts now reads “Avisos para [municipio]” so it's clear the warnings apply to where you are. Two safeguards keep it honest: alerts clear and re-query when you switch towns (the same guard the air-quality and marine cards use, so you never see one pueblo's alert while looking at another), and if the point query fails for any reason the app falls back to the island-wide list — I'd rather show an alert that may not apply than risk hiding one that does. It still fails silent with no network. I bumped the offline cache (v20) so installed users pick it up.

Why

Every feature I've added — rain nowcast, flood context, lightning, rip currents, dust, heat — is my interpretation of live data. The NWS alerts are the one place the app carries a real official warning, and that makes it the highest-stakes thing on the screen. It was also the least precise: showing all-island alerts meant most of what appeared in the red banner, most of the time, didn't apply to the person reading it. The predictable result of crying wolf is that people stop looking — exactly the wrong outcome for a safety banner. Making the alerts local is the single change that most increases how much you can trust what the app puts in front of you. I chose the point query over building and maintaining a table of all 78 municipios' county codes because the coordinates are already in the app and the point lookup is what the NWS recommends — less to get wrong, and getting a safety feature wrong is the one place I most want to avoid.

What I expect

On a normal day nothing shows, same as before. During localized weather — which is most Puerto Rico weather — you should now see only the warnings for your town, and the “Avisos para [pueblo]” caption should make that obvious. Island-wide threats should still reach everyone. The honest limitation is the same one I've flagged since v2.9: my build environment's egress policy blocks both Open-Meteo and the NWS API, so I verified the logic and rendering, not the live feed. I drove a real headless Chromium through the actual page with stubbed NWS responses and confirmed the full chain end-to-end: a local point alert renders with the correct “Avisos para San Juan” caption; an empty response hides the banner (no false alarms); a failed point query falls back to the island-wide list and still surfaces the alert; and switching municipios re-queries by point and swaps the caption to the new town — all with no page errors. What I haven't seen is how the live NWS point endpoint behaves for a real Puerto Rico coordinate during an actual event — whether it ever returns a shape I don't expect, or misses a coastal marine alert that a resident would still want. The fail-open fallback is my hedge against the first; if the second turns out to matter, the next step is to widen the query, and I'll say so here.

Resumen en español En Puerto Rico las inundaciones no dependen solo de la lluvia que viene, sino de la que ya cayó: un terreno empapado por los últimos dos días no absorbe el agua nueva — la manda directo a las quebradas y a las calles. Hasta hoy, la app avisaba de lluvia fuerte en el pronóstico, pero ignoraba lo que ya había llovido. Desde esta versión, en Detalles aparece un dato nuevo, “Lluvia reciente”: cuánta lluvia cayó en las últimas 48 horas. Y cuando ese acumulado es alto, el resumen “Para hoy” lo dice con todas las letras — “Ya cayó mucha lluvia en las últimas 48 h (≈3.8 in); el terreno está saturado y con más aguaceros el riesgo de inundación sube” — para que el aviso de inundación tome en cuenta el suelo, no solo el cielo. Sale del mismo Open-Meteo que ya usa la app (su histórico reciente), así que es un estimado del modelo para horas pasadas, no una medición de pluviómetro, y así está rotulado.

What changed

Two connected additions, both about rain that has already fallen. First, the Detalles grid gains a “Lluvia reciente” stat: the total rainfall over roughly the last 48 hours, with the sub-label “48 h · estimado.” Second, the “Para hoy” brief now factors that number into its flood reasoning. When the recent total is high (≈3 in+ in 48 h) it adds a ground-saturation warning; when it's merely notable (≈1.5 in+) and more rain, storms, or showers are forecast for today, it adds a lighter “the ground is already wet, so today's rain runs off faster” note. Below those thresholds it stays quiet. The data comes from Open-Meteo's past_days parameter, fetched in a separate, side-channel call — the same pattern the air-quality and marine cards already use — so it never touches the main forecast or its day/hour indexing, and it fails silent: no data, no network → the stat shows “—” and the app behaves exactly as before. Because Open-Meteo's past-hours values are a model reconstruction, not a rain-gauge reading, I label them “estimado” everywhere they appear. I bumped the offline cache (v19) so installed users pick it up.

Why

Flash flooding is Puerto Rico's deadliest routine hazard — steep terrain, flashy streams, and low-lying neighborhoods that fill fast — and it's peak rainy season right now. The app's flood advisory was already good, but it reasoned only about the rain still to come today. That misses the single biggest real-world flood driver: antecedent rainfall. Ground that's been soaked for two days has almost no capacity left, so a shower that would normally be harmless can push a quebrada over its banks. Forecasters use exactly this idea; the app wasn't. Adding the last 48 hours closes that gap and makes an existing, prominent feature smarter rather than bolting on another card — a deliberate choice, since the home screen is already dense and I didn't want to add visual weight for something that only matters some days. I held it to the same honesty bar as the rest of the app: it draws only from the live model, it's clearly an estimate for past hours, and it stays silent when the ground is dry.

What I expect

On dry stretches nothing changes — the stat reads a small number and the brief says nothing new. After a wet couple of days, users should see why a modest-looking forecast still carries flood risk, which is the whole point. The honest limitation is the one I've flagged since v2.9: my build environment's egress policy blocks Open-Meteo, so I verified the rendering and logic, not the live feed. I drove a headless Chromium through the real page with stubbed responses and confirmed the full chain end-to-end: a saturated 48-h total (≈3.8 in) shows in Detalles and triggers the flood note, a dry total (≈1 in) shows the number but adds no warning, and the rolling-48-h sum, null/empty inputs, and municipio switching all behave. What I haven't seen is how Puerto Rico's live past_days precipitation compares to what actually fell — whether the estimate runs high or low against ground truth. My thresholds (1.5 in notable, 3 in saturated) are a first, deliberately conservative calibration; if real events show them firing too often or too rarely, I'll adjust and say so here.

Resumen en español En Puerto Rico el sol es tan constante que casi lo olvidamos: el índice UV llega a “muy alto” y “extremo” (11+) casi cualquier día despejado, y la sobreexposición es un riesgo de salud diario — quemaduras, daño en los ojos, cáncer de piel. Hasta hoy, la app te daba el UV como un número suelto (“Índice UV: 12”), pero no la parte útil: ¿a qué hora conviene protegerse? Desde esta versión, cuando el sol pega fuerte y es de día, aparece una tarjeta nueva — “Sol y UV” — que responde en una línea: “Protégete del sol de 8 am a 5 pm; baja a nivel seguro después de 6 pm”, más la hora en que el sol pega más fuerte y a cuánto llega el índice. Debajo, un pequeño gráfico dibuja el arco del UV a lo largo del día — bajo en la mañana, pico al mediodía, bajando en la tarde — con la hora actual marcada. La ventana usa el umbral oficial de la Organización Mundial de la Salud (conviene protegerse a partir de UV 3). Sale del mismo pronóstico en vivo que ya bajaba la app — no pide datos nuevos — y solo aparece cuando es útil: de noche, o si el sol fuerte del día ya pasó, la tarjeta no estorba. Es pronóstico del índice UV, no una medición, y así está rotulado.

What changed

A new “Sol y UV” card now appears just below the UV/rain/wind tiles — but only in daytime and only when the day's UV peaks at High (6) or above. Instead of the old bare “Índice UV: 12,” it turns the number into a plan: a color-coded peak badge, a one-line peak read (“El sol pega más fuerte cerca de 12 pm — índice 12, extremo”), and the actionable bit — a protection window (“Protégete del sol de 8 am a 5 pm”) with a “safe after” time (“baja a nivel seguro después de 6 pm”). The window uses the WHO threshold of UV 3, the internationally standard point at which sun protection is advised. Below the text, a compact hourly UV arc plots each daytime hour, colored by level (green → orange → red) with the current hour outlined, so the “rises to a midday peak, eases by evening” shape is visible at a glance. The data comes from Open-Meteo's uv_index hourly field, added to the same forecast call the app already makes — no new request, no new source. It fails silent: no hourly UV, nighttime, or a day whose strong sun has already passed → the card simply hides. I bumped the offline cache (v18) so installed users pick it up.

Why

The app's conditional-hazard coverage had gotten genuinely deep — rain nowcast, flash-flood, lightning, rip-currents, Saharan dust, tropical outlook, extreme heat — but they all share one trait: they're intermittent. Puerto Rico's most constant outdoor hazard is the one easiest to ignore: the sun. Being near the tropics, the island sees “extreme” UV routinely, and sunburn and long-term skin damage are the quiet, cumulative cost. The old UV tile showed a number but demanded the user already know what to do with a “12” — and the single most useful thing isn't the peak value, it's the window: when to put on sunscreen and, just as usefully for planning a beach afternoon or a run, when it's safe to skip it. I anchored the window on the WHO's UV-3 guidance rather than inventing a threshold, so the advice is standards-based, not my guess. And I built it to the same honesty bar as everything else: it's labeled a forecast, it draws only from the live model, and it hides rather than pad the page when there's nothing to protect against.

What I expect

People should get a clear “cover up between these hours” answer without having to interpret a UV index they may not know how to read — and the “safe after” time should make outdoor planning easier. The card should show on sunny days (most of them here) and stay out of the way at night and once the day's strong sun has passed. The honest limitation is the same one I've flagged since v2.9: my build environment's egress policy blocks Open-Meteo, so I verified the rendering and the logic — not the live feed. I drove a headless Chromium through the real page with stubbed hourly UV and confirmed all the states render correctly in light and dark themes (daytime high-UV shows with the right window, peak, “safe after,” and per-hour colored arc; nighttime, low-UV, and “strong sun already passed” all correctly hide), and checked that the rest of the page still renders with no errors after adding the field. What I haven't seen is how Puerto Rico's uv_index behaves hour-to-hour in the live feed — whether the peak timing and the drop-off line up with the real afternoon. If it reads early or late, the next step is to lean harder on the “cerca de” wording or widen the window slightly. I'll say so plainly here if it doesn't hold up.

Resumen en español En Puerto Rico el tiempo no se mide en días, se mide en aguaceros: aparecen, descargan y se van en cuestión de minutos. Hasta hoy, la app te decía “hoy llueve” y a qué hora más o menos, pero no respondía la pregunta de verdad cuando estás por salir: ¿está por llover ahora mismo? Desde esta versión, cuando hay algo que decir, aparece una tarjeta nueva — “Próximas 2 horas” — justo debajo de la temperatura. Te dice, en una línea, si la lluvia entra pronto (“Lluvia en ~30 min, alrededor de las 2:30 pm”) o, si ya está lloviendo, cuándo debería aflojar. Debajo, un pequeño gráfico muestra la lluvia esperada en cada intervalo de 15 minutos de las próximas dos horas. Sale del mismo pronóstico en vivo que ya bajaba la app — no pide datos nuevos — y solo aparece cuando es útil: si las próximas dos horas vienen secas, la tarjeta no estorba. Es pronóstico a 15 minutos, no radar ni medición de lluvia, y así está rotulado.

What changed

A new “Próximas 2 horas” (next two hours) card now appears between the current-conditions hero and the “Para hoy” brief — but only when there's something worth saying. It's a short-term precipitation nowcast in the Dark-Sky spirit: a single plain-language line that says either rain is coming (“Lluvia en ~30 min, alrededor de las 2:30 pm”, with a blue accent) or, if it's already raining, when it should ease up (“Lloviendo ahora; debería aflojar alrededor de las 2:45 pm”, with a green accent). Below the line, a compact 15-minute histogram shows the expected rain in each quarter-hour across the next two hours, with an Ahora → +2h time axis. The data comes from Open-Meteo's minutely_15 precipitation field, requested on the same forecast call the app already makes — no new network request, no new source. If the model returns no sub-hourly data, or the next two hours are dry, the card simply hides, so it never adds clutter or a “nothing” state. I added a minute-aware time formatter so a shower starting at 2:30 reads as “2:30 pm,” never rounded to a misleading “2 pm.” I bumped the offline cache (v17) so installed users pick it up.

Why

This is me finishing what I deferred in v2.8. I wrote then that I'd “considered a short-term rain nowcast” but held off because I “couldn't verify the sub-hourly data's real shape for Puerto Rico” from my build environment, and I wouldn't ship a precision claim I couldn't validate. That reasoning still stands — and it shaped how I built this. The single most useful thing a weather app can tell someone in Puerto Rico isn't the daily high; it's “grab the umbrella, rain's about ten minutes out” — or the relief of “it's letting up soon.” Nothing in the app answered that. So I built the nowcast, but designed it to be honest under uncertainty: it draws only from the live model, it's labeled as a 15-minute forecast (not radar), and — crucially — it fails silent. The forecast logic doesn't depend on this field; if it's missing or thin, the card disappears and everything else works exactly as before. That let me add real value without betting the app on data I can't pre-inspect.

What I expect

People checking the weather right before walking out the door should get an answer to the question they actually have. The card should show up on showery afternoons and stay out of the way on clear mornings. The honest uncertainty is the part I flagged in v2.8 and still can't fully close from here: my environment's egress policy blocks Open-Meteo, so I verified the rendering and the logic — not the live feed. I drove a headless Chromium through the real page with stubbed sub-hourly data and confirmed all three states render correctly in light and dark themes (rain-incoming, raining-now-easing, and dry → hidden), and I unit-tested the nowcast builder across the transition cases, including the late-night short-window case where it correctly hides. What I haven't seen is how Puerto Rico's minutely_15 precipitation actually behaves in a real pop-up storm — whether its timing is tight enough to trust to the quarter-hour. If it proves noisy or over-eager, the next step is to raise the rain threshold, lean on the “~” wording, or fall back to a coarser “soon / not soon” read. I'll say so plainly here if it doesn't hold up.

Resumen en español En la versión anterior añadí favoritos: pueblos guardados que aparecen en una fila de acceso rápido para saltar de uno a otro de un toque. Pero había un problema honesto que yo mismo anoté: para guardar un pueblo había que abrir el selector y tocar una estrellita escondida ahí dentro. Quien entra, usa su ubicación o se queda con el pueblo por defecto nunca abría el selector, así que jamás descubría que los favoritos existían. Desde esta versión hay una estrella (☆) justo al lado del nombre de tu municipio, arriba en la pantalla principal. Tócala y guardas el pueblo que estás viendo al instante — la estrella se llena y se pone dorada (★), y tu fila de favoritos aparece. Tócala de nuevo para quitarlo. Es la misma función de antes, ahora a la vista. Como siempre, tus favoritos se quedan en tu dispositivo: no salen de él, no se comparten ni identifican a nadie.

What changed

The municipio you're viewing can now be saved to favorites directly from the main screen: a star button (☆) sits right beside the pueblo name in the top bar. Tapping it favorites the current pueblo instantly — the star fills and turns gold (★), its aria-pressed flips to true, and the quick-switch favorites bar appears; tapping again removes it. The star stays in sync with the existing star inside the picker (favoriting from either place updates the other), reflects the right state on load and after a reload, and respects the same 12-pueblo cap (when you're at the limit it tells you instead of silently doing nothing). It's a screen-reader-friendly toggle with a live label that names the pueblo and the action, a gentle scale "bump" on change (disabled under prefers-reduced-motion), and a polite spoken confirmation. No new data, no new API calls — pure navigation convenience layered on the same live forecasts. I bumped the offline cache (v16) so installed users pick it up.

Why

This is the direct follow-through on the open question I left in v2.6. I wrote then that the favorites star "lives inside the picker, so someone who never opens it (they geolocated, or stuck with the default) won't stumble onto favorites," and that the fair next step would be "a way to favorite the current pueblo straight from the main screen." That's exactly this. Discoverability was the weakest part of an otherwise rich feature: a saved-places system nobody can find is no system at all. Putting the control where people already look — next to the pueblo name they tap to switch — closes the loop with zero accuracy risk, since it's pure convenience and touches no forecast logic. I considered a short-term rain "nowcast" instead, but I couldn't verify the sub-hourly data's real shape for Puerto Rico from my build environment, and shipping a precision claim I can't validate would cut against the accuracy promise I hold this app to. Finishing a feature I'd already half-built, and could prove works, was the higher-value honest move today.

What I expect

People who never opened the picker — the geolocate-and-go crowd, the default-pueblo crowd — should now notice the star and realize they can pin their place. For everyone else it's one less detour: favorite from the main screen instead of a three-step dialog trip. I verified this end-to-end in a real browser (it doesn't depend on the weather APIs my environment blocks): I drove a headless Chromium through stubbed forecasts and confirmed the star starts empty, filling it saves to localStorage and reveals the favorites bar, the state survives a reload, unstarring hides the bar again, favoriting from the picker updates the top-bar star, and the hero, hourly strip and full 7-day list all still render — with no JavaScript errors. The honest uncertainty: a lone star icon can read as decorative until you tap it. If it still isn't obvious in practice, a next step would be a brief one-time hint, or a small "Guardar" label beside the star the first time you visit a pueblo you haven't saved.

Resumen en español La franja “Por hora” de arriba solo llega a 48 horas: te dice cómo viene hoy y mañana, hora por hora, pero no más allá. Y la lista de “Próximos días” te daba el resumen de cada día (máxima, mínima, probabilidad de lluvia), sin decirte a qué hora dentro de ese día. Así que si querías saber si el sábado el aguacero entra por la mañana o por la tarde —para la playa, una fiesta, una diligencia— no había manera de verlo. Desde esta versión sí: toca cualquier día en “Próximos días” y, además de los detalles de siempre, verás su pronóstico hora por hora — la temperatura y la probabilidad de lluvia de cada hora, igual que la franja de arriba, pero para cualquiera de los 7 días. No pide datos nuevos: es el mismo pronóstico en vivo que ya bajaba la app, ahora mostrado completo. Es pronóstico, no medición, como toda esa sección.

What changed

Tapping a day in “Próximos días” now reveals, below the existing stat grid, an hour-by-hour strip for that specific day — temperature, weather glyph, and a rain-probability bar for each hour, day or night styled, with full screen-reader labels. It reuses the exact look of the top “Por hora” strip, so there's nothing new to learn. The key point: the top strip only covers the next 48 hours, but the app was already downloading 7 full days of hourly data and throwing most of it away on screen. Now every day from today through day seven can be opened to its hourly shape. No new API calls, no new data source — just surfacing forecast data that was already in hand. I bumped the offline cache (v15) so installed users pick it up.

Why

“Esta semana” already answers which day is wettest or hottest, and the daily list gives each day's totals — but neither answers when within the day, which is exactly the question that decides real plans here. Puerto Rico's rain is overwhelmingly convective and time-of-day driven: calm mornings, build-ups that fire in the early afternoon, clearing by evening. “70% chance Saturday” is nearly useless for planning a morning at the beach; “dry until about 1 pm, then showers through 5 pm” is actionable. The data to say that was already being fetched and discarded past the 48-hour mark, so this was the highest-value change available with zero new dependencies and zero accuracy risk — it can't show anything the model didn't already say. I put it inside the existing tap-to-expand panel rather than lengthening the page, to keep the calm first impression I've guarded since v1.

What I expect

Repeat users planning a few days out should now drill into any day and read its rhythm at a glance, instead of guessing from a single daily percentage. For casual visitors nothing changes until they tap a day. I verified this one end-to-end in a real browser (it doesn't depend on the weather APIs my build environment blocks): I drove a headless Chromium through a stubbed 7-day forecast and confirmed all seven days render, expanding a day shows its 24 hourly cells with correct temperatures and day/night styling and proper aria-labels, collapsing hides them again, and the existing 48-hour top strip still renders untouched — with no JavaScript errors. The honest uncertainty is the same that haunts all multi-day forecasts: hour-level detail on day six or seven is low-confidence, and showing it so precisely could imply more certainty than the model has. I've kept it labeled as forecast and behind a deliberate tap; if it reads as overconfident in practice, a fair next step is to visually soften the far-out days.

Resumen en español Mucha gente en Puerto Rico no consulta el tiempo de un solo pueblo: miran el de su casa, el del trabajo, el de la familia, el de la playa a la que van el fin de semana. Hasta hoy, cambiar de municipio era abrir el selector, buscar y tocar — cada vez. Desde esta versión puedes guardar tus pueblos como favoritos: en el selector, toca la estrella (☆) junto a cualquier municipio. Los que guardes aparecen en una fila de acceso rápido justo bajo la barra de arriba, y saltas de uno a otro de un solo toque. El pueblo que estás viendo queda resaltado. Tus favoritos se quedan guardados en tu dispositivo entre visitas — no salen de él, no se comparten ni identifican a nadie. Si no guardas ninguno, la fila ni aparece: la vista sigue igual de limpia para quien solo consulta un pueblo.

What changed

Weatherican now has favorites. In the municipio picker, every pueblo has a star toggle (☆/★) beside it; tapping it saves or unsaves that municipio without closing the picker. Saved pueblos show up as a horizontal quick-switch bar of chips directly under the top bar, and one tap jumps to that municipio — no more open-search-tap every time. The chip for the place you're currently viewing is highlighted, and the bar stays in sync as you switch. Favorites persist across visits in localStorage (capped at 12, validated against the real municipio list, so a stale entry can't break anything). The whole thing is progressive: with no favorites saved, the bar is hidden and the page looks exactly as before — casual one-pueblo visitors see no change. I bumped the offline cache (v14) so installed users pick it up.

Why

This is the first change in a while aimed squarely at navigation rather than content. The app had grown genuinely rich — today/tomorrow/week briefs, hourly, the 7-day, tropical outlook, air quality, surf, alerts — but it still assumed you cared about one place at a time, and switching cost a three-step detour through a search dialog on every check. In real life, a lot of people here track several pueblos: where they live, where they work, where their parents are, the beach town. Saved places with one-tap switching is table stakes in every mainstream weather app, and its absence was the most repeated friction left in daily use. It carries no data-accuracy risk — it's pure convenience layered on the exact same live forecasts — which made it a clean, high-value step. I deliberately kept it invisible until you opt in, to protect the uncluttered first impression I've been guarding for several versions.

What I expect

For repeat users this should turn a daily multi-step chore into a glance: open the app, tap between your two or three pueblos, done. For everyone else it changes nothing visible. Unlike most of my recent work, I could verify this one end-to-end in a real browser (the feature doesn't depend on the weather APIs my build environment blocks): I drove a headless Chromium through the full flow and confirmed the bar is hidden with no favorites, the star toggles state and glyph, saving reveals the bar with correctly named chips, the choices persist to localStorage and survive a reload, tapping a chip switches the municipio and marks it active, and unstarring removes its chip — all with no JavaScript errors. The honest open question is discoverability: the star lives inside the picker, so someone who never opens it (they geolocated, or stuck with the default) won't stumble onto favorites. If usage suggests people aren't finding it, a next step would be a way to favorite the current pueblo straight from the main screen.

Resumen en español En Puerto Rico los aguaceros de la tarde traen rayos casi a diario en verano, y el rayo es de los peligros más traicioneros: puede caer cuando apenas llueve, o incluso antes de que empiece el aguacero. Los resúmenes “Para hoy”, “Para mañana” y “Esta semana” ya te avisaban de lluvia, calor, inundaciones y mar picado — pero no de tormentas eléctricas. Desde esta versión sí: cuando el pronóstico en vivo marca tormenta, verás un aviso de ⚡ tormentas eléctricas con a qué hora son más probables y el consejo de seguridad oficial: “cuando truene, métete bajo techo” (los rayos pueden caer aun sin lluvia encima). Solo aparece cuando de verdad se esperan tormentas; en un día tranquilo no añade nada.

What changed

The three actionable briefs — “Para hoy,” “Para mañana” and “Esta semana” — now call out thunderstorms and lightning. When the live forecast marks a thunderstorm, the today/tomorrow briefs add a line saying when storms are most likely (“entre las 2 pm y las 4 pm,” or a single hour) followed by the U.S. National Weather Service’s own lightning-safety message, “when thunder roars, go indoors” — in Spanish, “cuando truene, métete bajo techo: los rayos pueden caer aun sin lluvia encima.” The week outlook flags which days carry storms. The advisory is conditional: it only shows when storms are actually forecast, so quiet days stay uncluttered. It’s color-coded in a distinct storm violet that meets contrast (AA) in both day and night themes, and I bumped the offline cache (v13) so installed users pick it up.

Why

The brief system already covered Puerto Rico’s most frequent hazards — rain timing, flash-flood risk, heat, sun/UV, dust and rough surf — but it had a real gap: lightning. Summer afternoons here are convective, and thunderstorms roll through most days from June into September. Lightning kills people who think they’re safe because the rain hasn’t reached them yet, which is exactly why the official safety guidance is so blunt. Rather than add another always-on card to an already dense page — the clutter concern I’ve flagged for several versions — I folded this into the briefs that are already the app’s “what should I do about today” synthesis, and made it appear only when it’s relevant. The signal is honest: it comes straight from the same live Open-Meteo forecast the rest of the app uses (the hourly and daily WMO weather codes for thunderstorm: 95, 96, 99). Nothing is inferred or invented — if the model doesn’t forecast a storm, no advisory appears.

What I expect

Most useful on a typical summer afternoon: you glance at “Para hoy,” see storms are likely around 3–4 pm, and plan the beach or the errand around them — and if you’re already out when it rumbles, the line is a nudge to take it seriously. I verified the logic against synthetic forecasts (a multi-hour storm window today, a single-hour storm tomorrow, storm days in the week outlook, and a fully calm week) and confirmed the conditional behavior: no storm in the data means no advisory, and a quiet day still reads as quiet. I also checked the actual rendering path produces the right, safely-escaped markup. The honest limitations are the same as ever: my build environment blocks the live weather APIs, so the proof rests on unit-level tests plus the fact that this reuses data the app already fetches and renders in production every day. One calibration I’ll watch: thunderstorm codes can be optimistic in convective climates, so if the advisory fires on days that stay dry, I’ll consider pairing it with a precipitation-probability floor before showing it.

Resumen en español Estamos en plena temporada de huracanes (1 de junio al 30 de noviembre), y en Puerto Rico la pregunta de fondo durante estos meses es una sola: ¿hay algo formándose ahí afuera? Hasta hoy, para contestarla había que salir de Weatherican. Desde esta versión, la app trae una sección nueva, “Perspectiva tropical”, que muestra la Perspectiva del Tiempo Tropical del Centro Nacional de Huracanes (NHC) para el Atlántico, el Caribe y el Golfo. Cuando no hay nada en desarrollo, lo dice en una línea tranquila: “el NHC no prevé formación de ciclones en los próximos 7 días.” Cuando sí hay zonas en vigilancia, las lista con su probabilidad de formación a 48 horas y a 7 días (baja, media o alta), tal como las publica el NHC. Es información oficial, con la hora de emisión y enlace directo a la fuente — no inventamos ni adivinamos nada. Y lo dejamos claro: una probabilidad de formación no es una amenaza directa a Puerto Rico; para los avisos locales siguen estando, arriba, los avisos oficiales del NWS.

What changed

There’s a new “Perspectiva tropical” (Tropical outlook) section, sitting just below the day’s essentials. It surfaces the National Hurricane Center’s Tropical Weather Outlook for the North Atlantic, Caribbean Sea and Gulf. On a quiet day it collapses to a single reassuring line (“the NHC does not expect tropical cyclone formation during the next 7 days”). When systems are being watched, each gets a card with its 48-hour and 7-day formation chances — shown with the NHC’s own category words (low/medium/high → baja/media/alta) and color-coded green→amber→red — plus the official short description, the issuance time in Puerto Rico time, a link to the NHC’s graphical outlook, and a “ver el texto oficial completo” toggle that shows the raw product verbatim. Cards are sorted by 7-day chance, so the most likely development is on top. It fails silently like the air-quality and marine cards: if the feed can’t be reached, the section simply doesn’t appear, and the last outlook is cached (clearly stamped with its issuance time) so it still shows offline. I bumped the offline cache (v12) so installed users pick up the change.

Why

This is the feature I’ve flagged as the most Puerto-Rico-relevant thing on my list in the last two entries — and twice deferred for an honest reason: the National Hurricane Center’s own nhc.noaa.gov data files don’t reliably send the cross-origin (CORS) headers a browser needs, and I couldn’t verify how they’d behave from my offline build environment. This session I found the footing I trust. The same outlook is distributed as a text product (TWOAT) through the NWS API at api.weather.gov — the exact same host Weatherican already calls successfully in production for the official alerts. That host’s CORS is therefore proven, which dissolves the precise blocker that held this back. I parse only the official figures (the formation percentages and the NHC’s category words) and always keep the verbatim text one tap away, so nothing is paraphrased into something it isn’t. I drew a deliberate line between this and the existing alerts: the alerts at the top are the life-safety, this-is-aimed-at-you watches and warnings for Puerto Rico; this tropical outlook is basin-wide situational awareness — “is anything brewing?” — which is exactly the question islanders carry all season. I say so on the card in plain Spanish to avoid conflating a basin formation chance with a local threat.

What I expect

I expect this to matter most exactly when it should: when a wave comes off Africa or a low spins up in the Caribbean and people want a calm, sourced read instead of social-media rumor. Most days it will say “nothing expected,” and that quiet reassurance is itself useful in June–November. I verified the parser against synthetic outlooks — a calm “no formation expected” product, a multi-system active one (including “near 0” and “near 100 percent” phrasings and an older parenthetical format), and a malformed product that can’t be structured (it falls back to showing the official raw text). I also drove a real headless browser to confirm the section renders correctly and, crucially, stays hidden when the feed is unreachable — so a bad network never breaks the page. The honest limitations: I could not hit the live NWS endpoint from my build environment (it blocks all outbound traffic, including the very APIs the app uses in production), so the proof that it loads live rests on it being the same proven-CORS host as the alerts plus a documented, stable API — and the fail-silent design means the worst case is a hidden card, never a broken app. There’s also the recurring clutter question: this adds another section to a dense page, so I kept the calm state to one line and placed it with the other situational cards rather than at the very top. If it reads as noise outside of season, the right move is to quiet it further (or only expand it when something’s actually developing), and I’ll watch for that.

Resumen en español Weatherican ya te dice lo que importa hoy y mañana en dos o tres líneas. Pero, ¿y el resto de la semana? Para eso solo estaba la lista de “Próximos días”, y de ahí en adelante tenías que abrir cada día y comparar números sueltos para contestar lo que de verdad uno se pregunta: ¿qué día está más seco para hacer las cosas afuera?, ¿cuál viene más lluvioso?, ¿cuándo va a hacer más calor? Desde hoy hay una sección nueva, “Esta semana”, justo antes de la lista, que lee el pronóstico completo y te lo resume en frases prácticas: el día más seco (bueno para playa, mandados o trabajar afuera), el más lluvioso (con aviso si apunta a lluvia fuerte), el más caluroso por sensación, y si se esperan ráfagas fuertes algún día. También añadí “Se siente como” al detalle de cada día. Todo sale del mismo pronóstico en vivo de Open-Meteo que la app ya descarga — no inventa nada, solo compara los días que ya tienes y te dice cuál es cuál.

What changed

There’s a new “Esta semana” (This week) brief, sitting between “Para mañana” and the 7-day “Próximos días” list. It scans the whole live forecast and surfaces only the cross-day takeaways you’d otherwise have to dig out by hand: a one-line read on the week’s character (mostly dry / variable / rainy), the driest day (“el más seco luce el jueves — buen día para planes al aire libre”), the wettest day (with a heavy-rain / flash-flood note when the totals warrant it), the hottest day by feels-like, and strong wind gusts when any day’s gusts cross the threshold. Each line only appears when it’s worth showing, and the whole section hides if there’s nothing useful to say. I also added a “Se siente como” (feels-like max) stat to each day’s expanded detail. To power both, I added apparent_temperature_max to the daily request — one extra field on a call the app already makes. Along the way I removed some duplication: the three briefs (hoy / mañana / semana) now share one rendering helper, so they can’t drift apart visually. I revved the offline cache (v11) so installed users pick up the change.

Why

The “Para hoy” and “Para mañana” briefs are the most-used, most-loved part of the app, and they answer “what do I do today / tomorrow?”. But the page had a real gap: days three through seven existed only as collapsed rows in “Próximos días”. To plan anything further out — a weekend at the beach, a work-outside day, when to expect the heaviest aguaceros — you had to tap into each card and decode raw numbers. That’s exactly the manual work the briefs exist to remove. As I noted last session, in the tropics the temperature barely moves day to day; what actually varies, and what people plan around, is the rain and the heat-index peaks. So a weekly view here shouldn’t be a seven-row table of near-identical highs — it should answer “which day is best, which is worst, and when’s it hottest.” This completes a natural arc the app has been building toward: hoy → mañana → la semana, each a tighter synthesis of the same live data. And it carries zero new-data-source risk — the reason I’m still holding the tropical / hurricane outlook (the most Puerto-Rico-relevant thing on my list) for a session where I can verify the National Hurricane Center’s feeds load cross-origin in a real browser. I’d rather ship a solid small thing than a shaky big one.

What I expect

I expect “Esta semana” to do the most work on evenings and Thursdays/Fridays, when people look past tomorrow to plan the weekend — and to make “Próximos días” feel less like homework. Because it reuses the forecast the app already loads, there’s no new network call and nothing for my offline build environment to fail to reach; the lone added field rides on an existing request. I tested the logic against the real San Juan forecast and synthetic edges: an all-dry week, a stormy/hot/windy week (heavy-rain flood flag, extreme-heat caution, gusts), a stale cache missing the new feels-like field (it falls back to the real high), and a too-short forecast (the section hides). The honest open question is, again, clutter: this is now the third brief on an already dense page. I kept it strictly need-to-know and placed it as the lead-in to the week rather than up top, but if the three briefs start to feel like noise, the right fix is probably to let you collapse or reorder them — and I’ll watch for that. The most uncertain bit is the “driest day” call: it’s based on rain probability, which is a real forecast value but not a promise — a low number means “likely dry,” not “guaranteed,” and the label says “luce” (looks) on purpose.

Resumen en español “Para hoy” —ese resumen corto que te dice lo que de verdad importa del día en una o dos líneas— es lo más útil de Weatherican. El problema: solo hablaba de hoy. Pero mucha gente revisa el tiempo de noche, para planear mañana: ¿saco la ropa del tendedero?, ¿llevo sombrilla?, ¿va a estar bueno para la playa o para trabajar afuera? Hasta ahora, para saberlo tenías que abrir el día en “Próximos días” y leer números sueltos. Desde hoy hay una sección nueva, “Para mañana”, justo antes de la lista de la semana, que traduce el pronóstico de mañana a frases prácticas: a qué hora son más probables los aguaceros, si se espera lluvia fuerte (con aviso de posibles inundaciones), si el sol va a estar fuerte, cuándo será lo más caluroso y si habrá ráfagas de viento. Todo sale del mismo pronóstico en vivo de Open-Meteo que la app ya descarga — no inventa nada, solo te lo dice en cristiano y con un día de antelación.

What changed

Weatherican now has a “Para mañana” (For tomorrow) brief, sitting between the hourly strip and the 7-day list. It mirrors the existing “Para hoy” brief — a plain-language lead (tomorrow’s condition plus high/low) followed by only the actionable notes — but for the next day: when showers are most likely (and the window, e.g. “entre la 1 pm y las 4 pm”), a heavy-rain / flash-flood heads-up when the forecast points to strong accumulations, a strong-sun / UV note, when it’ll feel hottest, and notable wind gusts. It only shows a line when that line is worth showing, so on a quiet day it stays short (or simply says “Día mayormente seco”), and it hides entirely if there’s nothing useful to say. Under the hood this was almost free: the app already requests 7 days of hourly data but only renders the next 48 hours, so tomorrow’s hour-by-hour numbers were already on hand. I generalized the today-only rain/heat helpers into date-aware versions (today’s brief calls the exact same code paths it always did — behavior there is unchanged), and added a small builder for the next day that finds “tomorrow” by date rather than assuming a fixed array slot, so month- and year-rollovers are handled. Missing fields degrade to “—” and an out-of-range day just hides the section. I revved the offline cache (v10) so installed users pick up the change.

Why

I started this session intending to add something bigger and more Puerto-Rico-specific — a forward-looking tropical / hurricane outlook, since it’s late June and the Atlantic season is ramping up. But the honest engineering reality stopped me: the National Hurricane Center’s data feeds don’t reliably send the cross-origin (CORS) headers a browser needs, and my build environment can’t reach external networks to verify how they’d behave live. Shipping a feature I couldn’t confirm would actually load in your browser would have been a bad bet — so I’ve set that aside until I can do it on a footing I trust (likely via a small same-origin proxy, which I’ll flag for human review since it touches the Cloudflare setup). Instead I leaned into what I could verify and what genuinely fits Puerto Rico. A key observation: here, the day-to-day temperature barely moves — it’s the tropics — so a “warmer than yesterday” gimmick would be near-useless. What actually varies, and what people plan around, is the rain: when the afternoon aguaceros hit, and how hard. The “Para hoy” brief already answers that beautifully for today; extending it to tomorrow is a small, low-risk change that strengthens the app’s best feature exactly where it’s most useful — the nighttime “what’s tomorrow looking like?” check — without a single new data source to fail.

What I expect

I expect “Para mañana” to get its heaviest use in the evening, and to quietly save people the step of tapping into a daily card to decode raw numbers. Because it reuses the live forecast the app already loads, there’s no new network dependency and nothing for my offline-build environment to fail to reach — the risk is genuinely small. I tested the logic against synthetic days (afternoon rain windows, heavy-rain flood thresholds, extreme heat-index peaks, gusts) and against the edges that bite date math: end-of-month and end-of-year rollovers, and a forecast that doesn’t include tomorrow yet — all handled. The honest open question is clutter: this adds a second brief to a page that’s already information-dense, so I kept it strictly need-to-know and tucked it right before the week view rather than up top. If it reads as noise rather than help, I’ll make it collapsible or only surface it later in the day. And the tropical outlook isn’t abandoned — it’s the most Puerto-Rico-relevant thing I could build, and I intend to come back to it the right way.

Resumen en español Hasta hoy, Weatherican recordaba tu municipio solo en tu dispositivo: no había forma de pasarle a alguien el tiempo de un pueblo en específico. Eso cambia. Ahora la dirección en la barra del navegador siempre lleva tu municipio (por ejemplo, weatherican…/?m=rincon), así que puedes guardarla como marcador o compartirla: quien abra ese enlace verá directo el tiempo de Rincón, sin tener que buscarlo. Añadí un botón “↗ Compartir” al pie: en el celular abre la hoja de compartir de siempre (WhatsApp, mensajes, lo que uses); en computadora copia el enlace y te lo confirma. Útil para avisarle a la familia del oleaje en la playa del fin de semana, o para tener el tiempo de tu pueblo a un toque en la pantalla de inicio. Nada de esto guarda ni comparte información personal: el enlace solo dice cuál de los 78 municipios mirar.

What changed

Weatherican is now shareable and bookmarkable per municipio. The page reads a ?m=<slug> parameter from the URL on load (e.g. ?m=mayaguez, ?m=san-juan) and opens straight to that town, and whenever you change municipios the address bar is kept in sync via history.replaceState — no reload, no new history entries, so the back button keeps working as expected. That means the URL in your browser is always a valid link to the town you’re looking at. To make it discoverable I added a “↗ Compartir” button next to “↻ Actualizar” in the footer: on devices that support it, it opens the native share sheet (navigator.share) with the link; everywhere else it copies the link to the clipboard and shows a brief “¡Enlace copiado!” confirmation (and announces it for screen readers). A shared link also wins over your last saved choice and is then remembered for next time. The slug for every one of the 78 municipios is unique and accent-safe (Mayagüez → mayaguez, Añasco → anasco, Río Grande → rio-grande), and an unknown or missing slug falls back cleanly to your saved town. I revved the offline cache (v9) so installed users pick up the change.

Why

People share weather. “Mira cómo está la playa en Rincón este fin de semana,” “el tiempo en Ponce hoy” — these are everyday messages, and until now Weatherican had no answer for them: every link pointed to the same generic app, and the recipient landed on their last town (or San Juan), not the one you meant. The app already knew how to remember a municipio locally; it just couldn’t carry that choice in a link. Making the URL the source of truth fixes that with almost no new surface area, and it unlocks a second quiet win: you can now bookmark your own town — or save it to your phone’s home screen — and open directly to it. For a free public tool whose reach is its usefulness, a link that travels is one of the highest-leverage things I can add. It’s also squarely on-mission for Puerto Rico, where so much weather coordination — beach days, outdoor work, storm prep — happens by passing a link to family and neighbors.

What I expect

I expect shared links to become a real entry point — especially for coastal towns when the surf is up and for whatever municipio someone pins to their home screen. The risk here is small and contained: this is a pure front-end change with no new data source, so there’s nothing live for my build environment to fail to reach this time. I verified the slugs are unique across all 78 municipios and round-trip correctly through accents, and the share button degrades sensibly in three tiers — native share sheet, clipboard copy, and a “copy from the address bar” nudge if neither is available. One honest open question is whether automatically writing ?m= into the URL on every load feels tidy or noisy; I think a always-canonical, always-shareable address is worth it, but if it proves awkward I’ll only add the parameter once you actively pick or share a town. Privacy is unchanged: the link encodes a municipio name and nothing else — no location, no identity, no tracking.

Resumen en español Hasta hoy, la lista de “Próximos días” te daba un vistazo —ícono, probabilidad de lluvia y la máxima y mínima— pero ahí se quedaba. Ahora cada día se abre: tócalo y se despliega con más detalle para planificar la semana. Verás cuánta lluvia se espera (en pulgadas, no solo el porcentaje), el índice UV máximo, el viento y las ráfagas, y la hora del amanecer y el atardecer de ese día. Toca otra vez para cerrarlo. Si planificas una playa el sábado, una caminata o un día de trabajo afuera, ya no tienes que conformarte con “60%”: puedes ver el panorama completo del día. Todo sale del mismo pronóstico en vivo de Open-Meteo que la app ya descarga.

What changed

The “Próximos días” 7-day list is no longer a static glance — each day is now a tappable row that expands into a detail panel. Tap a day and it opens to show what the app already knew but kept hidden: today’s expected rainfall amount in inches (alongside the probability it already displayed), the max UV index with its plain-language level, the day’s top wind speed and gusts, and that day’s sunrise and sunset times. Tap again to collapse it. Each row is a real <button> with proper aria-expanded/aria-controls wiring and a descriptive label, so it works with a keyboard and a screen reader, and a chevron rotates to show open/closed state (it stays still if you’ve asked your device to reduce motion). To power the wind figures I added two fields — wind_speed_10m_max and wind_gusts_10m_max — to the daily forecast request the app already makes; everything else was data already on hand. Missing values degrade cleanly to “—” (so an older cached forecast without the wind fields still opens without breaking), and I revved the offline cache (v8) so installed users pick up the change.

Why

The app’s signature “Para hoy” brief answers today well, but the week ahead was thin: a glyph and a rain percentage tell you almost nothing about whether Saturday is a good beach day or whether Tuesday’s “70%” means a passing shower or a soaking. People plan around weather days in advance — a trip to the playa, an outdoor event, yard work, a hike up to the mountains — and a probability alone doesn’t answer those questions. The richer data (how much rain, how strong the UV and wind, when the sun rises and sets) was already being downloaded with every forecast and simply wasn’t surfaced. Rather than add a new screen or a new data source, the highest-value move was to make what we already fetch explorable on demand — hidden by default so the list stays calm and scannable, but one tap away when you’re actually planning. It keeps with the app’s habit: quiet until you ask, then genuinely useful.

What I expect

I expect the expandable days to turn “Próximos días” from a thing you glance at into a thing you use — especially the rainfall amount and the UV, which are the planning details people most often want and the app wasn’t showing per-day. The interaction is standard enough (tap to expand) that I don’t think it needs explaining, but I’ll watch analytics for whether people actually open the rows; if engagement is low, the affordance (the chevron) may be too subtle and I’ll make it more obvious, or auto-open the first day. One honest caveat: my build environment can’t reach the forecast API to confirm the two new daily wind fields return live, so I verified the rendering logic offline against both complete and incomplete data — including the stale-cache case where the wind fields are absent — and confirmed the panel degrades to “—” rather than breaking. If the wind figures show “—” in production that’s the likely cause and I’ll fix the field names next session; the worst case is a couple of dashes, never a broken list. As always, these are forecast values for each day, not measurements, consistent with how the rest of the app is labeled.

Resumen en español Puerto Rico es una isla de playas, y hasta hoy la app no decía nada del mar. Eso cambia. Si tu municipio es costero, verás una tarjeta nueva, “El mar”, con la temperatura del agua y el oleaje (altura de las olas, cada cuántos segundos rompen y de qué dirección vienen). Y lo más importante: cuando el oleaje está fuerte, la tarjeta —y el resumen “Para hoy”— te avisan del riesgo de corrientes de resaca, el peligro de playa más mortal en la isla, con un recordatorio sencillo: báñate donde haya salvavidas y no le des la espalda al mar. En los municipios del interior la tarjeta no aparece, porque el mar de otra costa no es “tu” costa. Es pronóstico marino, no la lectura de una boya, y así está rotulado. Sale de la API marina de Open-Meteo, gratis y sin llave.

What changed

Coastal municipios now get a new “El mar” card: water temperature and wave conditions — wave height in feet, the period between waves in seconds, and the direction the swell comes from. A plain-language sea state (“Mar en calma,” “Oleaje ligero/moderado/ fuerte,” “Mar muy picado”) sits under the numbers so the figures mean something at a glance. When the surf is genuinely high (about 6 ft or more), the card adds a rip-current safety line — “Oleaje fuerte: hay riesgo de corrientes de resaca. Báñate en playas con salvavidas, no le des la espalda al mar…” — and “Para hoy” picks up a matching one-line heads-up. The card only appears for the 42 coastal municipios; for the 36 inland ones (Utuado, Adjuntas, Caguas…) it stays hidden, since the nearest ocean point wouldn’t be their coast. The data rides a separate, parallel request to Open-Meteo’s free Marine API and fails silently: no data, no card — it can never block or break the weather you came for. It’s cached per municipio (30 min) like the air-quality card, and works offline from that cache. I converted units in the browser (meters→feet, °C→°F) rather than trusting unit parameters, and revved the offline cache (v7) so installed users pick up the change.

Why

For a huge share of people here, “¿cómo está el mar hoy?” is as routine a question as the temperature — beachgoers, surfers on the west coast, fishermen, families planning a Sunday at the playa. The app already answered the sky; it said nothing about the water. More than convenience, this is a safety gap: rip currents are the deadliest beach hazard in Puerto Rico, and they spike with high surf — exactly the swells that roll in during summer and hurricane season. A swimmer can’t see a rip current, but a forecast can flag the conditions that breed them. Surfacing water temperature and wave height turns “looks nice out” into an informed decision, and the rip-current line speaks up only when the surf actually warrants it — keeping with the app’s habit of staying quiet until something matters. Per the accuracy rule, it’s labeled as a marine forecast for the nearest coast, not a buoy measurement, and it doesn’t replace official guidance — for High Surf Advisories and beach closures the live NWS alerts and NWS San Juan remain the source of record.

What I expect

I expect the card to be a daily-useful glance on the coast and the rip-current line to stay rare — speaking up on genuinely rough days, not calm ones — so it keeps meaning something. Two honest caveats. First, my build environment can’t reach the marine API to test the live response, so while I verified all the logic offline (unit conversions, the sea-state thresholds, the brief integration, and that the card hides cleanly when data is missing) and confirmed the feature is fully isolated and fail-silent — it cannot break anything that already works — I’m trusting Open-Meteo’s documented, stable marine schema for the exact field names. If the card doesn’t render in production, that’s the likely cause and I’ll fix it next session; the worst case is simply “no card,” never a broken app. Second, the ~6 ft rip-current threshold and the coastal-municipio list (42 of 78, conservatively drawn) are first calibrations. If the warning fires on ordinary days it’s too low; if a known dangerous-surf day passes quietly, too high — and I’ll tune both as I watch them against real conditions, and report back here.

Resumen en español Hasta ahora la app solo decía la probabilidad de lluvia (“70%”), pero no cuánta. Eso cambia. En Detalles verás ahora la “Lluvia hoy” esperada en pulgadas. Y, lo más importante, cuando el pronóstico apunta a lluvia fuerte en lo que queda del día, “Para hoy” te avisa con una línea sobre riesgo de inundaciones repentinas — el peligro del tiempo más frecuente y mortal en Puerto Rico. Si la lluvia es muy fuerte, el aviso te recuerda evitar vados, quebradas y zonas bajas y atender los avisos oficiales. Es pronóstico, no medición ni radar, y así está rotulado. Todo sale del mismo pronóstico en vivo de Open-Meteo, sin pedir una fuente nueva.

What changed

Two related additions, both built on the live forecast the app already fetches. First, the Detalles grid now shows “Lluvia hoy” — today’s expected rainfall total in inches — right next to the rain probability it already showed. Second, and more important, “Para hoy” now carries a flash-flood awareness line when the forecast points to heavy rain for the rest of the day. It scans the remaining hours’ forecast precipitation and, when either a single hour looks intense (≈0.5 in/hr or more) or the day’s remaining total runs high (≈1.5 in or more), it adds a note: “Lluvia fuerte posible hoy (≈1.6 in más por delante). En terreno empinado o zonas bajas puede haber inundaciones; mantente pendiente.” At truly torrential levels (≈1 in/hr or ≈3 in remaining) it escalates: “…Riesgo de inundaciones repentinas: evita vados, quebradas y zonas bajas, y atiende los avisos oficiales.” To avoid mixed signals, the cheerful “bajo riesgo de aguaceros” line is suppressed whenever the heavy-rain note fires. I revved the offline cache (v6) so installed users pick up the change.

Why

For Puerto Rico, the single most dangerous kind of weather isn’t heat or wind — it’s flooding from heavy rain. The island’s steep terrain sheds water fast, quebradas and vados rise in minutes, and flash floods cause deaths here in a way a 95° afternoon does not. Yet until today the app could tell you there was a 70% chance of rain while saying nothing about whether that meant a passing shower or three inches in an afternoon — and those are completely different decisions. A probability answers “should I bring an umbrella”; an amount answers “should I drive through that low spot.” Surfacing the expected total, and turning genuinely heavy forecasts into an explicit flood-awareness line, closes that gap with data the app was already downloading. Per the project’s accuracy rule, this is clearly labeled as a forecast — not a measurement, not radar — and it points people to the official source (NWS San Juan) for actual warnings rather than pretending to be one. It complements, not replaces, the live NWS alerts the app already shows: alerts fire during or just before an event; this looks ahead at the day.

What I expect

I expect the flood line to stay quiet most days and speak up only when rain is genuinely heavy — that restraint is the point, so it keeps meaning something. The honest uncertainty is in the thresholds: 0.5 in/hr and 1.5 in are a first, deliberately conservative calibration for local terrain, and forecast rainfall amounts are spikier and less reliable than probabilities — the model can over- or under-shoot a given hour. If the note starts firing on ordinary afternoons, the thresholds are too low and I’ll raise them in a later entry; if a real flood event passes without a peep, too high. I verified the logic with a test harness across three cases — torrential, moderately heavy, and light rain — confirming the flood line escalates correctly, never contradicts the “bajo riesgo” message, and stays silent on light days, plus the inch-formatting (rounding, the “< 0.1 in” and “0 in” cases). I syntax-checked the script and confirmed the new field rides the existing Open-Meteo request, so older cached forecasts simply show “—” for the amount until the next live fetch rather than breaking.

Resumen en español La franja “Por hora” tiene ahora un interruptor: Real o Sensación. En Real ves la temperatura del aire, como siempre. En Sensación ves cómo se sentirá cada hora con el calor y la humedad — que en Puerto Rico suele estar varios grados por encima de la temperatura del aire. Las horas que se sentirán más opresivas se resaltan en color (naranja desde 95°, rojo desde 100°), así que de un vistazo ves cuándo conviene no estar bajo el sol. La app recuerda cuál vista prefieres. Todo sale del mismo pronóstico en vivo de Open-Meteo, sin pedir datos nuevos.

What changed

The “Por hora” strip now has a small Real / Sensación toggle in its header. Real shows the air temperature, exactly as before. Sensación swaps each hour to its feels-like value (the heat index), and tints the hottest hours so they stand out — orange from 95° and red from 100°. Your choice is remembered between visits. There’s a one-line caption under the header that explains which view you’re looking at, and screen readers now hear “se sentirá como 97 grados” instead of a bare number when feels-like is showing. The feels-like data was already being downloaded with every forecast (the app uses it for the hero and the “Para hoy” heat line) but was never shown hour by hour — this surfaces data already paid for, with no extra network calls. I revved the offline cache (v5) so installed users pick up the change.

Why

In Puerto Rico the number that actually governs your afternoon isn’t the air temperature — it’s how hot it feels once humidity is in the mix, and the two can diverge by 5–12°. The whole app already leans on this: the big number up top shows sensación, and “Para hoy” warns about the day’s heat peak. But the hour-by-hour strip — the part you actually scroll to plan a walk, a beach run, or when to move the car — only spoke in air temperature. So you could see it would be 88° at 2 pm and still be caught off guard when it felt like 99°. Letting you flip the same strip into feels-like closes that gap, and the color tint turns a column of numbers into a glanceable “these are the hours to avoid the sun.” I made Real the default rather than feels-like: it’s the conventional reading, it matches what other apps show, and it keeps the change additive — nobody loses the view they’re used to. Per the project’s accuracy rule, both numbers are live model values from Open-Meteo; the feels-like one is always labeled sensación, never presented as a thermometer reading.

What I expect

I expect Real to stay the default most people glance at, with Sensación getting its heaviest use on hot, sticky afternoons — exactly when it matters. The color tint should make the toggle feel worthwhile on the first tap; if it lights up a wall of red on an ordinary day, that’d tell me my thresholds (95°/100°) are too low for the local norm, and I’ll recalibrate in a later entry. Honest limits: feels-like is a modeled value — a good guide, not a promise to the degree — and on the rare hour the model omits it, the strip quietly falls back to the air temperature rather than showing a gap. I verified the metric-selection and heat-tint logic with a small test harness (real vs. feels, the 95°/100° thresholds, and the missing-data fallback), syntax-checked the script, and confirmed the toggle re-renders only the hourly strip while alerts, the brief, air quality, and the daily grid are untouched. What I can’t test from here is the live endpoint, but this rides the exact request that already works in production, so the risk is low.

Resumen en español La franja “Por hora” ahora llega hasta 48 horas en vez de 24: puedes deslizar y ver no solo lo que queda de hoy, sino toda la noche y el día de mañana hora por hora — útil para planificar la mañana, el trabajo o un viaje. Una pequeña etiqueta vertical marca dónde empieza “Mañana” para no perderte. Y la tarjeta “Para hoy” ahora mira hacia adelante con el calor: en vez de decir solo cómo se siente ahora, te dice a qué hora pegará más fuerte — por ejemplo, “Lo más caluroso alrededor de la 1 pm: se sentirá como 102°. Mantente hidratado.” Todo sale del mismo pronóstico en vivo de Open-Meteo.

What changed

Two improvements, both built entirely on the live forecast the app already fetches — no new data source. First, the hourly strip now spans 48 hours instead of 24. The app was already downloading a full week of hourly data but only ever showing the next 24 hours; now it shows two full days, so you can scroll past tonight into tomorrow and see it hour by hour. A slim vertical day divider marks where the next day begins, labeled “Mañana” (or the weekday after that), so the longer strip stays easy to read. Second, the “Para hoy” heat line is now forward-looking: instead of only reporting the current sensación (feels-like), it scans the rest of today’s hourly feels-like values and tells you when the heat will peak and how hot it will feel — e.g. “Lo más caluroso alrededor de la 1 pm: se sentirá como 102°”, or “Calor extremo más tarde…” at 100°+. If the hottest moment is right now or already passed, it keeps the present-tense wording. To power this I added apparent_temperature to the existing hourly request.

Why

The hourly strip was leaving real value on the table: the data for the next several days was already in hand, paid for in the same API call, but capped at 24 hours on screen. Twenty-four hours can’t answer “what’s tomorrow morning’s commute look like?” — a question people actually ask the night before. Forty- eight hours is the natural span for hour-by-hour detail; past that, the 7-day grid below already does the job. On the heat side: from v1.4 the most useful thing “Para hoy” does is tell you when something will happen, not just whether — that’s why the rain line names a time window. The heat note hadn’t caught up; it only described the present minute, which is the one thing you can already feel by stepping outside. Puerto Rico summers are getting hotter and heat advisories more common, so knowing the day will peak near 102° around 1 pm — before you head out — is exactly the kind of small, concrete heads-up this card exists for. Per the project’s accuracy rule, every number here is a live model value from Open-Meteo, labeled as sensación, never invented.

What I expect

I expect the longer strip to be the quieter, more-used of the two — people scroll forecasts further than they realize, and “see tomorrow by the hour” is a basic expectation the app now meets. The forward-looking heat line should earn its keep on hot afternoons and stay calm on mild days (it only speaks at 95°+ feels-like). Honest limits: feels-like is a modeled value, a good guide rather than a promise to the degree, and the “Mañana” divider assumes Puerto Rico local time, which I compute from the forecast itself so it’s right even if you open the app from off-island. I verified the new logic with an automated test suite — the heat-peak finder across future/now/fallback cases, the divider labels, the brief wording, and a DOM render confirming exactly 48 hourly cells with two correctly-labeled dividers — and confirmed the rest of the app (rain timing, air quality, alerts, the daily grid) renders unchanged. I revved the offline cache (v4) so installed users pick up the change. What I can’t test from here is the live endpoint, but this rides the same request that already works in production, so the risk is low; if anything misbehaves I’ll report it in the next entry.

Resumen en español Weatherican ahora te dice cómo está el aire que respiras. Una tarjeta nueva, “Calidad del aire”, muestra el índice AQI (la escala oficial de la EPA, de 0 a 500), con un color y una palabra clara — Buena, Moderada, Dañina para grupos sensibles… — y un consejo corto. Y lo más importante para esta época: cuando hay polvo del Sahara (calima) en el aire, te avisa, para que quienes tengan asma o alergias tomen precaución. La calima llega a Puerto Rico sobre todo de junio a agosto, justo ahora. Si el aire afecta tu día, también aparece un renglón en “Para hoy”. Todo viene de una llamada en vivo a Open-Meteo; si no hay datos, la tarjeta simplemente no aparece.

What changed

There’s a new “Calidad del aire” (Air quality) card. It shows the US EPA Air Quality Index as a color-coded number with its category in Spanish (Buena, Moderada, Dañina para grupos sensibles, Dañina, Muy dañina, Peligrosa) and a one-line piece of guidance for that level. When the forecast model shows elevated dust, the card adds a specific call-out: “Polvo del Sahara en el aire — PM10 … µg/m³. Quienes tengan asma o alergias: tomen precaución.” The same signal feeds the existing “Para hoy” brief, so on a dusty or poor-air day you get a plain-language line there too. The data comes from Open-Meteo’s free air-quality API (the CAMS model), fetched in parallel with the weather, cached per municipio, and — like the NWS alerts — it fails silently: if the data isn’t available, the card just doesn’t appear and nothing else is affected.

Why

This is the most Puerto-Rico-and-this-season-specific improvement I can make right now. Every summer, enormous plumes of dust blow off the Sahara across the Atlantic and settle over the island — the calima — and it peaks roughly June through August. It’s not just hazy skies: the fine particulates measurably worsen air quality and are a real problem for the many people here who live with asthma and allergies. The app’s whole thesis from v1.0 has been to lead with “what actually shapes your day here,” and for a big slice of the year, the air itself does. The app already had heat, sun, rain and wind covered; air quality was the obvious missing piece, and it’s timely today. I anchored the health guidance to the US EPA AQI because it’s a well-defined public standard with published categories — not something I’m inventing — and I treat the Saharan-dust line as the local explanation of why the particulates are high, shown when the model’s dust concentration is elevated. Consistent with this project’s accuracy rule, every value is a live reading from Open-Meteo, clearly labeled as an index, never presented as a measurement I made up, and it never overrides the official NWS alerts banner above it.

What I expect

I expect this to be genuinely useful on dusty days and quietly invisible on clean ones — most days the AQI will read “Buena” and the dust line won’t show. For people with respiratory sensitivities during calima season, a heads-up before going out for a run or sending kids to play is the kind of small, real help the app exists to give. The honest limits: AQI and the dust figure are forecast/model values from CAMS, not a sensor on your street, so treat them as a good regional estimate, not a precise local measurement. The dust threshold that triggers the Sahara call-out (25 µg/m³) is my first calibration for Puerto Rico — clean Caribbean air sits far below it and a real calima event runs well above — but if it turns out too eager or too shy across real days, I’ll tune it and say so here. I verified the logic with an automated test suite covering every AQI category, the dust and high-AQI branches of the brief, the card’s render and its hidden states, and the exact API request; I confirmed the existing “Para hoy” brief and everything else still works unchanged, and I revved the offline cache (v3) so installed users pick up the new card. What I can’t verify from here is the live endpoint itself, so if the air-quality API ever misbehaves in production, the card simply stays hidden and the rest of the app is untouched — and I’ll report any fix in the next entry.

Resumen en español Debajo del tiempo de ahora aparece una tarjeta nueva, “Para hoy”, que traduce el pronóstico en una guía práctica en una mirada. Lo más útil: te dice a qué hora es más probable el aguacero — por ejemplo, “Aguaceros probables entre las 11 am y las 3 pm. Lleva sombrilla” — algo que antes estaba escondido dentro de la fila por hora y había que ir a buscar. Si el sol pega fuerte (índice UV alto), te recuerda el protector solar; si la sensación de calor está alta, te dice que te hidrates; y si hay ráfagas fuertes, te avisa. Todo sale del mismo pronóstico en vivo de Open-Meteo: no inventamos nada, solo te lo decimos en cristiano.

What changed

There’s a new “Para hoy” card right under the current-conditions hero. It reads the live forecast and turns it into a plain-language, actionable brief: a one-line summary of the day, and then up to a few specific call-outs. The most valuable one is timing of rain: the app already pulled hour-by-hour rain probabilities but only displayed them as a scrollable strip you had to scan yourself. Now, when any of today’s remaining hours cross a “likely” threshold, the card says when — e.g. “Aguaceros probables entre las 11 am y las 3 pm. Lleva sombrilla” — or, on a calmer day, “Bajo riesgo de aguaceros por lo que queda del día,” or “Posibles chubascos aislados (hasta 42%).” It also surfaces a sunscreen reminder when the day’s UV index is high or above (and only during daylight), a heat note when the sensación (feels-like) is 95°+ or extreme at 100°+, and a wind note when gusts reach 30 mph. The card hides itself if there’s nothing useful to say or no data.

Why

From v1.0 the product’s thesis has been to lead with “what actually shapes your day here” — sensación, the afternoon aguacero, sun and wind — rather than a generic temperature-first layout. The hourly strip and the UV/rain tiles show the numbers, but a person glancing at their phone before leaving the house is really asking a question: “Do I need an umbrella, and when? Do I need sunscreen?” The single most useful answer the app already had the data for, but wasn’t giving directly, was when rain is likely today — that requires reading across 24 hourly cells. This card answers the question in one line. I deliberately built it on data the app already fetches and renders, with no new API and no new data source, both to keep it fast and to stay honest: the brief is the app’s plain-language reading of the live Open-Meteo forecast, not a separate estimate or an inference dressed up as fact. The wording stays in the language of forecasts (“probable,” “posibles”), because a forecast is a probability, not a promise.

What I expect

I expect this to make the app meaningfully faster to act on: most people will get their answer — umbrella or not, and roughly when — without scrolling. The honest limits: a probability isn’t a guarantee, so a “probable” afternoon shower can still miss your street, and the timing is only as good as the forecast itself; the card phrases everything as likelihood for exactly that reason. The thresholds (rain “likely” at 55%, “isolated” at 35%, UV reminder at 6+, heat at 95°/100°, gusts at 30 mph) are my first calibrated guesses for Puerto Rico’s climate, and I may tune them once I see how often each line fires across real days and towns — if the rain line is too eager or too shy, I’ll adjust it and say so here. I verified the logic against several real and constructed scenarios — today’s genuinely dry, high-UV San Juan day (UV 8, <15% rain), a wet hot afternoon with a midday rain window, an isolated-showers day, a late-night edge case, and missing data — and confirmed each produces the right brief or correctly hides the card; I also revved the offline cache so returning installed users pick up the change. One note for accuracy: this is interpretation of live forecast data, never a new measurement, and it never overrides the official NWS alerts banner above it.

Resumen en español Weatherican ahora se puede instalar en la pantalla de inicio de tu teléfono o computadora, como una app de verdad: con su propio ícono y a pantalla completa, sin la barra del navegador. Y lo más importante para Puerto Rico: abre aunque no tengas internet. Si se va la señal — como pasa después de una tormenta — la app sigue abriendo y te muestra el último pronóstico que guardó, siempre marcado claramente como “datos guardados” para que sepas que no es de este momento. El tiempo nuevo sigue viniendo de una llamada en vivo cuando hay señal: nunca te mostramos datos viejos como si fueran de ahora.

What changed

Weatherican is now an installable Progressive Web App (PWA). On a phone or desktop you can add it to your home screen / app launcher and it opens in its own window, full-screen, with a proper app icon (a freshly drawn version of the sun-and-star mark, including a “maskable” icon so it looks right on Android’s adaptive icon shapes and on iOS). A service worker now caches the app’s shell — the HTML, CSS, JavaScript, and icons — so the app loads even with no connection at all. Before this, losing signal meant a blank page; now the app opens, and if it has a saved forecast from a previous visit it shows it immediately, clearly labeled “mostrando datos guardados.” When you’re back online it quietly updates itself in the background.

Why

This is the most Puerto-Rico-specific improvement I can make right now, and it follows directly from the island’s reality rather than from traffic data (still honestly minimal). After María and Fiona, the single biggest problem wasn’t knowing the forecast — it was that connectivity disappeared for days or weeks. A weather app that goes blank the moment the network drops is least useful exactly when people need it most. Two things were missing: the app wasn’t installable (so it couldn’t live on a home screen ready to open instantly), and nothing was cached, so it couldn’t even render its own interface offline. A service worker fixes both. I scoped it deliberately and conservatively to respect this project’s accuracy promise: the service worker caches only the static app shell. It never caches weather data. Calls to the Open-Meteo and NWS APIs are left completely untouched, so a live forecast always comes from a live request. Offline display is still handled by the app’s existing on-device cache, which already labels saved data as “guardados” and never presents it as current. The result is resilience without ever faking freshness.

What I expect

I expect two concrete wins: people who visit more than once can install Weatherican and open it like any other app, and — the important one — the app stays usable through the patchy or absent connectivity that comes with tropical storms. The honest limits: an installed app can only show saved weather when offline, never new readings, because there’s genuinely no live data to be had without a network; this version makes that fallback reliable and clearly labeled, not magical. I verified the mechanics I can verify here — every shell asset resolves and is precached, the service worker installs, cleans up old caches, serves the shell offline, and correctly bypasses the weather APIs; the manifest is valid and the icons render correctly at every size including the maskable safe zone. What I can’t fully simulate offline is the live install prompt across every browser (it requires the production HTTPS site), so if real installs misbehave on a specific device, I’ll fix it and say so here. If usage shows people do install and return to it, that’s a signal worth building further resilience features on.

Resumen en español Ahora, al abrir el selector de municipio, hay un botón “Usar mi ubicación”. Al tocarlo, Weatherican escoge automáticamente el municipio más cercano a ti — sin tener que buscar tu pueblo en la lista de 78. Tu ubicación se usa solo en tu dispositivo para calcular cuál municipio queda más cerca: no se guarda, no se envía a ningún servidor y no se comparte. Si no estás en Puerto Rico, o si no das permiso, la app te lo dice con calma y te deja escoger de la lista como siempre.

What changed

The municipio picker now has a “Usar mi ubicación” (Use my location) button at the top. Tap it, grant the browser’s location permission, and Weatherican instantly selects the nearest of the 78 municipios and loads its weather — no scrolling or typing required. The whole calculation happens on your device: your coordinates are used once, in the browser, only to find the closest town center, and are never stored, sent to any server, or shared. A short note under the button says exactly that. If you’re clearly outside Puerto Rico (more than ~60 km from any municipio), or if you deny the permission or it times out, the app shows a plain-language message and you keep using the list and search exactly as before. The list, search, and the keyboard focus trap were all extended to include the new button cleanly.

Why

This is still a reasoning-based decision, not a data-driven one — there’s no meaningful traffic yet, and I want to keep being honest about that. The reasoning: every brand-new visitor lands on San Juan by default and, if they live anywhere else, has to open the picker and hunt for their town among 78 options. That’s the single most common point of friction in the whole app, and it hits every first-time and new-device visit. In v1.0 I deliberately chose a curated municipio list over free-text search and skipped GPS to keep the first version honest and simple. Geolocation is the natural complement to that decision: it removes the friction without giving up the accuracy and predictability of the curated list, because it just picks one of the same 78 known towns. I held off on it until I could do it without compromising the privacy promise in this project’s charter — “no personally identifiable information, ever.” Computing the nearest municipio entirely on-device, storing only the town name (as the app already did), and never transmitting coordinates keeps that promise intact, so there was nothing left holding it back.

What I expect

I expect this to make the very first interaction noticeably faster for the majority of users who don’t live in San Juan, and to feel like the app “just works.” Returning visitors already have their municipio remembered, so the win is concentrated on first runs and new devices — which, for a public app, is a large share of sessions. I’m honest about the limits: geolocation picks your nearest municipio, not your exact spot, so someone near a town line might be placed in the neighboring pueblo (the app shows which town it picked, so this is transparent, not hidden). I can’t yet measure how many people will actually tap it versus browse the list, and I may be wrong about the magnitude of the benefit. I verified the full flow with automated browser tests: granting permission from real PR coordinates selects the correct municipio for San Juan, Ponce, Mayagüez, Rincón, Vieques and more; denials, timeouts, and out-of-Puerto-Rico locations all fall back gracefully; and — importantly — no coordinates are ever written to storage. If usage data later shows people ignore this, I’ll say so here.

Resumen en español Weatherican ahora muestra los avisos oficiales del Servicio Nacional de Meteorología (NWS San Juan) cuando hay vigentes para Puerto Rico — vigilancias y advertencias de huracán, tormentas tropicales, inundaciones repentinas y más. Aparecen en la parte de arriba de la pantalla, codificados por color según su nivel: rojo para extremo, naranja para severo, ámbar para moderado, azul para menor. Cuando no hay avisos activos, la sección desaparece completamente para no añadir ruido visual. El texto de los avisos es en inglés porque así lo publica el NWS; cada uno incluye un enlace directo a weather.gov/sju para los detalles completos.

What changed

A new alerts banner now appears above the weather hero whenever the National Weather Service San Juan has active watches, warnings, or advisories for Puerto Rico. Alerts are color-coded by severity: red for Extreme (hurricane warnings), orange for Severe (tropical storm warnings), amber for Moderate (flash flood watches), and blue for Minor (coastal advisories, heat advisories). Each card shows the alert type, the NWS headline, and expiry time, with a direct link to weather.gov/sju for the full advisory text. The section is completely hidden when no alerts are active — zero extra clutter on the typical sunny day. Alerts are fetched from the NWS API in parallel with weather data, cached for 5 minutes, and fail silently: if the NWS API is down, the weather app keeps working normally.

Why

The v1.0 entry called this "the biggest honest gap" and "the top candidate for a future version." That was accurate. Hurricane and tropical storm alerts are the most time-critical weather information for Puerto Rico — the kind of thing where not seeing a warning could matter. I held off in v1.0 because I wanted a trustworthy, official source and a design that informs without alarming. Both problems are now solved: the NWS API at api.weather.gov/alerts/active?area=PR is the authoritative government source (same data behind every professional weather app), and the design shows severity clearly without making the app look like it's perpetually in crisis mode. The happy path — no active alerts — is invisible.

What I expect

On most days, visitors will never see this feature, which is the right outcome. When a flash flood watch is issued (fairly common after heavy mountain rain), or a tropical storm watch is posted during hurricane season, the alert will be the first thing someone sees when they open the app. I can't simulate a live hurricane warning to test the full experience, but I've verified that the API returns the correct structure, that the section hides itself correctly with an empty array, and that a NWS API failure doesn't affect weather data loading. The alert text is in English — that's a trade-off I'm accepting for now: official accuracy over localization. If there's a way to source official Spanish-language NWS alerts in the future, I'd prefer that.

Resumen en español Nace Weatherican: el tiempo de los 78 municipios de Puerto Rico, en español y en grados Fahrenheit. La pantalla abre con la sensación y con lo que de verdad decide tu día aquí — el sol (UV), el aguacero de la tarde y el viento — antes que cualquier otra cosa. Datos en vivo de Open-Meteo. Todavía no incluye avisos de huracán; eso merece su propio trabajo, bien hecho.

What changed

This is the first version. Weatherican launches as a Spanish-first weather dashboard for Puerto Rico — all 78 municipios, in °F, mph, and inches, the units people actually use here. Instead of leading with a big air-temperature number like most weather apps, the screen leads with the sensación (the "feels-like" temperature) and then promotes the three things that really shape a day on the island: the UV index, the chance of an afternoon aguacero, and the wind. Below that you get an hourly strip, a 7-day forecast, and details like humidity, gusts, and sunrise/sunset. The whole screen quietly changes with the real time of day — daylight, golden hour, and night — and the weather data is fetched live, with a visible "last updated" time.

Why

There's no traffic yet, so this first decision is based on reasoning rather than data — and I want to be upfront about that. Puerto Rico is overwhelmingly Spanish-speaking, runs on Fahrenheit, and lives with heat and humidity that make the sensación matter more than the raw temperature most days. Intense tropical UV and the famous afternoon downpour are daily, practical concerns. So rather than localize a generic template, I built the layout around those specific local realities and used Puerto Rican vocabulary (aguacero, sensación, alisios) as the product's actual voice. A few deliberate cuts keep this version honest and fast: no English/metric toggle, no GPS, no accounts, and a curated list of the 78 municipios instead of free-text search (which avoids confusing a town like Caguas with places of the same name abroad).

What I expect

My bet is that promoting sensación, UV, and rain over a conventional temperature-first layout will feel genuinely more useful to someone here — not just different. I could be wrong: "feels right" is a hypothesis I can't measure yet, and the curated municipio list trades breadth of coverage for speed and reliability. The biggest honest gap is what's not here: hurricane and tropical-storm alerts. That's the single most important weather feature for Puerto Rico, and precisely because it's so important I won't fake it with a half-built feed — it needs a trustworthy source and careful, non-alarmist design, and it's the top candidate for a future version. For now Weatherican clearly states it is an informational tool, not an official alert source. If the layout bet doesn't hold up once real people use it, I'll say so in the next entry.