data: add 38 postal codes from missing-code monitor#93
Conversation
Adds postal codes discovered by the PostalCode2NUTS monitor that are either absent from TERCET data (404) or only have approximate matches. NUTS estimates are derived from neighboring postal code lookups. New entries: 38
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4eb9066b04
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| LT,71179,LT024,LT02,LT0,high | ||
| LT,71184,LT024,LT02,LT0,high | ||
| LT,71199,LT024,LT02,LT0,high | ||
| LT,71205,LT026,LT02,LT0,medium |
There was a problem hiding this comment.
For inputs where users look up Lithuanian postcode 71205, this new estimate returns LT026 (Šiauliai County), but 71205 is in Šakiai district / Marijampolė County, whose NUTS3 code is LT024; the neighboring 71199 and 71224 rows in this same file also map this postcode block to LT024. This will make /lookup return the wrong NUTS3 region whenever the estimate is used.
Useful? React with 👍 / 👎.
Codex review on #93 flagged LT,71205 as the only postcode in the entire 71xxx range mapped to a non-LT024 region. 71xxx is the Marijampolė County (LT024) range — Šakiai district specifically — and the neighbouring 71199 / 71224 / 71225 / 71227 / 71271 rows all map to LT024. LT026 is Telšiai County in northwest Lithuania and is not adjacent to this range. Confidence on the row was already `medium`, consistent with the monitor being uncertain. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Good catch — verified and fixed in 288da6b. The bot is right that LT,71205 was the only 71xxx row not mapping to LT024 (Marijampolė County / Šakiai district); the neighbours at 71199, 71224, 71225, 71227, 71271 all map to LT024. The proposed LT026 is Telšiai County in northwest Lithuania, not adjacent to the 71xxx postcode range, so it was a clear monitor anomaly — consistent with the (Minor nit on the bot's reply: LT026 is Telšiai County, not Šiauliai — Šiauliai is LT027 — but the substantive point about the wrong region stands.) |
…dispatch The publish job uses a path filter to skip on docs-only changes, but the filter was excluding two files that ARE bundled into the container image via the Dockerfile: - tercet_missing_codes.csv (estimates fallback table) - docker-entrypoint.sh (the actual ENTRYPOINT) Consequence: PR #93 (CSV-only data update) was merged but `publish` skipped, so `ghcr.io/.../:latest` still pointed at the previous image without the 38 new postcodes and the LT 71205 fix. Same risk applies to any future entrypoint-only change. Adds both files to the `code:` filter so a fresh image is published on merge. Also adds `workflow_dispatch` so the publish flow can be re-triggered manually from the Actions UI (or `gh workflow run`) without needing an empty commit dance; updates the `publish` job's `if` to allow that event type as well. Side effect of this PR landing: triggers a fresh image build that picks up #93's CSV update, so the next redeploy from `:latest` will ship both the v0.19.3 deps and the data update. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1 participant
Summary
Adds 38 rows to
tercet_missing_codes.csvsurfaced by the production missing-code monitor since the last data refresh. Pure data update — no app code, no API surface, no dependency changes.Spans CH, CY, HR, and several other Member States (full diff visible in the PR). Confidence levels (
low/medium/high) reflect the monitor's classification.Test plan
🤖 Generated with Claude Code