The old file was a confusing mix of eras: an accurate current
Windows/Rocky/VPS environment section sitting alongside stale leftovers
from before this project's current setup existed -- a wrong port (9090,
staging is actually 9190), old docker-compose v1 syntax, a podman-compose
three-terminal dev loop nobody uses, an nginx config for laikazinas.lsm.lv
(the real current LSM production site, unrelated to and confusable with
this project's actual temporary test domain), Fly.io commands from a
hosting platform no longer in use, and an example command that happens to
run one of the files this session's security review flagged as a
mislabeled test script capable of touching a live database.
Replaced with a short landing page: what the tool does, how it's built,
current status (Rocky-only development now that Windows is retired from
the workflow, laikapstak.li as the temporary test environment ahead of
eventually replacing the live laikazinas.lsm.lv service), and a security
summary -- all pointing to docs/ for actual technical depth rather than
duplicating half-true instructions. Updated docs/README.md's own
description of the root README to match.
Documents release a6b2b84 (the queryLatestTemperatures fix and the user's
CSS polish pass) in the changelog and README status line. Also fixes a real
bug in VPS_RELEASE_RUNBOOK.md's own checksum step, found by actually running
it for this release: it generated the .sha256 file against a full local
path rather than a bare filename, which fails verification on the VPS since
that path doesn't exist there.
VPS_STAGING_PLAN.md describes the release process at a policy level; the
changelog table narrates what happened after each release. Neither is a
step-by-step "how" a person (or Guntis) could actually follow without
already knowing the process from having run it. This is that document --
copy-pasteable commands, in order, parameterized by commit SHA.
Writing it surfaced a real regression: earlier releases (through ef64895)
retained the release tarball under /srv/weathertool/releases/<sha>/ and
backed up .env.staging before every edit; tonight's releases (0be325f,
9bab93d, 001b014) did neither -- I'd been deleting the transfer copy from
/tmp after each deploy and sed-ing .env.staging directly with no backup.
Practical cost: rolling back to any of tonight's releases would have meant
rebuilding from git history and re-transferring, instead of just re-pointing
.env.staging at an already-present image. Closed the gap for the current
live release (001b014) retroactively -- exported it directly on the VPS
(checksum matches the exact bytes shipped tonight, confirming no drift) and
backed up the current .env.staging -- and the runbook restores both habits
going forward.
Six real commits (padding, the Result.css collision fix + dead code
cleanup, Ūdens's card layout, its button styling, the Valmiera substitution,
and click-to-edit) had detailed commit messages but no corresponding
roadmap changelog rows or README status updates -- caught while checking
doc status before a planned VPS push.
LVĢMC's open-data station list has no station in or near Valmiera at all
(confirmed live 2026-08-23 in OpenDataStationService.scala), so that fixed
position has been silently blank. Priekuļi is the closest currently-
reporting station -- measured against the app's own calibrated map
coordinates (~56px away vs. the next-closest candidate, Rūjiena, at ~81px),
not a guess. Same pattern already used for Stende/Talsi and Zīlāni/Jēkabpils.
Implemented client-side in Faktiskā's fetch only: query Priekuļi's reading,
remap it back onto the "Valmiera" key before it reaches the rest of the
component. Valmiera's marker position and on-map label are untouched (both
are tied to Valmiera's real map location, not Priekuļi's) -- only the data
source for that one slot changes. This also fixes a second, previously
unexplained symptom for free: the weather-symbol picker only lists cities
with a value, so Valmiera never appeared there either; it now does.
Provisional pending direct confirmation from LVĢMC -- documented as such in
PRODUCT_WORKFLOWS.md, matching how Stende/Zīlāni are already flagged.
Verified: typecheck clean, production build succeeds, headless-browser
checks confirm Valmiera's field shows Priekuļi's real live value (14.8°C,
fresh timestamp, not flagged manual/stale) and now appears in the
weather-symbol exceptions list (13 cities, was 12).
The changelog claimed ci.yml #1 verified green (it didn't -- that was a
wrong WebFetch summary of the Gitea Actions page, reported as fact without
checking it visually) and CONTINUOUS_INTEGRATION.md described the
HOME/cache permission warning as harmless (it wasn't -- it blocked
resolving actions/checkout entirely). Both corrected with what actually
happened: three real, different bugs, found only by running the workflow
and reading user-provided screenshots of the actual failures.
Pushing to rocky alone doesn't trigger CI (Gitea can't see that private bare
repo), and two separate git push commands are easy to half-remember. 'all'
has two push URLs (rocky, gitea) so one push updates the staging checkout's
source and triggers CI together. Deliberately excludes origin (GitHub)
pending the still-open question about that repo's ownership/involvement.
Adds CONTINUOUS_INTEGRATION.md (mirrors HOP's CI doc structure), links it
from README, and records the CI changelog entry plus the follow-up review's
open findings (scheduler crash-loop, System.gc(), connection pooling, the
PostgresService field-routing invariant, and the mislabeled main-method
"tests") in the roadmap's Phase 2/Phase 5 checklists.
Release 0be325f (image weathertool:0be325fbbbf92b03bc8d574dc6f7b9449ef310ea)
ships the path-traversal/auth-bypass/DoS and SQL-injection fixes to
production; b0b58d2 remains the rollback target.
Records the path-traversal/auth-bypass/DoS fixes (6b9c7cf), the SQL
injection fix (8c45d8d), and the subsequent Postgres password rotation on
Rocky in the roadmap changelog and Phase 4 checklist, and notes current
status in README/DEVELOPMENT_AND_STAGING. VPS deployment of these fixes is
still pending.
The SPA fallback (2c44888/b0b58d2) is deployed to VPS as b0b58d2,
verified via curl and headless-browser on real routes, a missing
asset, and /api, both locally and through the public domain.
Also updated the FTP saga: re-testing this morning found a Rocky-only
failure with the VPS confirmed off, which the two-machine-collision
theory from last night can't explain. Decided to stop self-testing
and wait for a real answer from LVGMC about the account's connection
policy rather than keep guessing through trial and error.
The ltv account fails to authenticate from the VPS specifically
(works fine from Rocky with the same credentials, network path to
ftp.meteo.lv:21 confirmed fine from the VPS too) — narrowed to either
a password transcription error in .env.staging or LVGMC IP-allowlisting
the account, neither confirmable without inspecting the password.
Caught via the overnight watch this was set up for rather than
assumed safe; reverted ENABLE_LVGMC_FTP_JOBS to false on the VPS
immediately once the failure was confirmed real, restoring stable
operation. FTP stays enabled on Rocky, where it works.
Changelog rows for the COALESCE upsert fix, both timezone fixes, the
ENABLE_LVGMC_FTP_JOBS/ENABLE_HARMONIE_JOBS split, and the VPS compose
LVGMC templating fix — none had one yet. Updated the stale "currently
deployed" references (were still e446f1ff) to the actual final
release (3eddf95). Recorded the DMI Harmonie research (no API key
needed, new domain, verified live) and the 5-step verification plan
for actually wiring it up, deferred to a dedicated session. One line
about the VPS's first FTP fetch is marked pending — a background
watch is still confirming it as of this commit; will follow up once
it resolves.
Real LVGMC FTP credentials arrived today; real DMI HARMONIE
credentials haven't. The combined flag would have enabled both the
moment FTP's were ready, crash-looping the app on HARMONIE's still-
placeholder values via parMapN — caught this before it happened
(the Grib job was ~15 min from its first scheduled run). Split into
ENABLE_LVGMC_FTP_JOBS and ENABLE_HARMONIE_JOBS so each provider can
be enabled independently as its own credentials become real.
Deployed everything since 6185dbf (Brīdinājumi draggable symbols, real
open-data station/water-temperature ingestion, synthetic-data removal,
scheduler split, METEO_* deletion, real per-zone water-temperature
ranges), flipped ENABLE_SCHEDULED_JOBS=true on the VPS, and wiped the
VPS weather table's synthetic rows after a PostgreSQL backup.
ARCHITECTURE.md, PRODUCT_WORKFLOWS.md, DEVELOPMENT_AND_STAGING.md, and
README.md still described the removed synthetic-seed staging setup and
Ūdens as pure manual entry. Updates this session (open-data station
ingestion, the scheduler split, water-temperature auto-populate)
weren't reflected outside UPDATE_ROADMAP.md's changelog.
b0txec