release: v0.3.3 — region scoping page (#187), devcontainer, E2E fresh-server #205

Filed after the fact, like #202 before it. Tagged and deployed by ITblacksheep; this record was written later by a different session, so the details below are reconstructed from the box and the git history rather than from the releaser. Anything only he knows is marked as such.

Tag v0.3.3 (annotated, bare message v0.3.3) at commit 09ba8c6a.
Tagger: ITBlacksheep <rockywilson117@gmail.com>, 2026-10-16 20:19:52 UTC [verified: git cat-file -p v0.3.3].

Contents

[verified: git log v0.3.2..v0.3.3]

#198 and #199 were already on master and had no release of their own, so they rode along.

What #187 shipped

[verified: git show --stat 09ba8c6a] +3,647 / −5 across 26 files:

• public/region-def.js (543), public/region-def-core.js (452), public/region-def.css
• docs/region-def.md (288)
• scripts/check-region-data.js, scripts/simplify-region-layers.js
• E2E + unit tests, and fixtures under tests/fixtures/region-layers/
• public/region-layers/layers.json.example and known-points.json.example

Note the .example suffix. The repo ships templates, not real region data. The actual layers.json and geojson live only on the box, which is why a bind mount is required at all.

#187 touched no compose file [verified: git show 09ba8c6a --name-only | grep compose → nothing].

Timeline, reconstructed

The 17:08 edit is dated by file mtime plus the fact that no compose backup prior to today contains region-layers — the most recent earlier backup is 2026-08-26 and the line is absent [verified: grep across all .bak files].

So the region-def page existed on prod only from 20:37, and was broken from the moment it existed until #204 landed — roughly three hours, not since the 12th. An earlier read of mine said "broken since Oct 12"; that was wrong and is corrected here.

Deploy result

Release Fast-Path and the dispatched CI/CD Pipeline both concluded success [verified: gh run list]. Prod came up and has been serving since.

Current prod state [box: /api/stats on deadbeef, 2026-10-16] — measured after the #204 fix, so it reflects a later container than the release itself:

What this release did not carry, and should have

A mount the feature depends on. #187 added the page but nothing in the release configured where its data comes from. That was done by hand on the box three hours before the tag, with a defect (${DATA_DIR} reused for both mounts) that no CI could see, because /opt/corescope/docker-compose.yml is not in version control and no repo compose mentions region-layers. See #204 for the fix and the version-control gap.

A feature whose deployment requirement lives only in one person's head and only on one box is a release that cannot be reproduced.

Open questions only ITblacksheep can answer

• The tag annotation is bare (v0.3.3 and nothing else). v0.3.0–v0.3.2 all carry contents and verification notes. Deliberate or rushed?
• Adding a region scoping page for region rollouts #187 was merged by its author while carrying CHANGES_REQUESTED. Whether those requested changes were addressed before merge is not something this record establishes, and is not asserted either way.
• Was the mount intended to ship in the repo? The .example files suggest the real data was always meant to be box-local, but the mount itself arguably belongs in a tracked compose.

Closing as done — this exists for the record, not as open work.

Refs #187, #198, #199, #204, #202