GBP joins the currencies the app comes with: £, two decimals, and a
committed fallback rate of 8.704735 DKK to the pound. build.ts now
fetches it too, so a build with a network bakes a live GBP rate and one
without still covers it — the coverage check derives from the seed table,
so it demanded GBP as soon as the table listed it.
The seed table alone would not have delivered this. Baked currencies and
rates seed a NEW dataset and nothing else, so an existing dataset would
have been left typing the code, name, symbol and decimals by hand. A
4 -> 5 migration adds sterling to a dataset that lacks it, with its rate.
Supplying a rate is the one thing the "rates never backstop a cleared
rate" rule permits here: it forbids re-supplying a number the owner
deleted, not introducing one for a currency they have never had. A GBP
the owner already defined, or a GBP rate they already hold, is left
exactly as it is — asserted, including the case where their definition is
"wrong" (zero decimals), because it is theirs.
This exposed a real latent bug. The 2 -> 3 step seeded the live
seed-currency table BY REFERENCE, so adding sterling there would have
retroactively changed what an old dataset received from a step it had
already been through — silently, and only for whoever had not migrated
yet. Every step now carries its own frozen copy, and a source-level guard
fails the build if a live default is imported again. Scoping that guard
took two goes: matching the whole file flagged the comment explaining the
rule, and then flagged the frozen local copy that is the fix.
Two test fixtures used GBP as their example of an UNSUPPORTED currency
and now use CHF, which no seed table lists.
Verified in a browser by writing a schemaVersion 4 dataset into IndexedDB
and reloading: the currency table gains "British pound / £ / 2" with
"manual · 2026-09-02", the post currency selector offers GBP, and the
income and post survive untouched. Note for the next person — a migration
applies in memory on load and is written back on the next mutation, so
reading IndexedDB straight after a reload still shows the OLD version.
That is recorded in docs/TODO.md, because it made this verification look
like a failure at first.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
"Fetch rates now" failed on the deployed site with nothing but a CORS
error. api.frankfurter.app now answers every request with a 301 to
api.frankfurter.dev/v1, and a redirect response must itself carry
Access-Control-Allow-Origin for a browser to follow it cross-origin. That
301 carries no CORS headers at all, so the request died before the
redirect could be taken.
Measured rather than guessed, with an Origin header set:
api.frankfurter.app -> 301, no access-control-* headers
api.frankfurter.dev -> 200, access-control-allow-origin: *
The response shape is unchanged, so parseFxResponse needed no edit.
Nothing was wrong at build time, which is why this went unnoticed: a
server-side fetch follows the 301 freely, so the baked rates were always
correct. Only the browser path was broken.
Two changes, because a new default alone fixes only some datasets:
- DEFAULT_FX_API_URL points at .dev/v1, with a test that fails if the
redirecting host ever comes back.
- A 3 -> 4 migration drops settings.fxApiUrl when it holds exactly the
dead default, which is the case for anyone who edited that field. It is
DROPPED rather than rewritten, so the dataset follows whatever the
current default is and the next move of the service needs no second
migration for the same user; a URL the owner chose is left strictly
alone. No stored figure changes, so it cannot alter a number in the
budget.
Verified by clicking the button in a real browser: "Updated 2 rate(s)",
USD 6.456195 and EUR 7.474959 both stored with source "api" — and the USD
figure differs from the baked constant, so it is a genuine live fetch.
Two migration tests asserted the chain ends at 3; they now assert
SCHEMA_VERSION, since what they mean is "all the way through".
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
"Why is this the way it is" was answered by pointing at a directory of
five specs, which means reading five specs to find out whether the
question is even addressed. DECISIONS.md answers it in one line per
decision, grouped by area, each entry naming what the choice was made
*over* and linking into the spec that argues it.
Around forty entries. Where no spec exists — the currency model, the
baked rates, the reset — the commit message is cited as the record
instead of inventing one.
Written by reading the specs rather than from memory, which surfaced
history worth having in one place: dates were widened to accept "YYYY-MM"
rather than restructured into month plus optional day, specifically to
avoid running a migration in the browser against the user's only copy of
their financial data for an identical visible outcome.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
