Settings, In One Language
Settings, In One Language
What changed
The general, developer and billing settings pages now read in the same visual language as the dashboard and the organisation page: the banded layout, the mono section labels, one palette where a colour means the same thing everywhere, and the same quiet register the rest of the app uses. Nothing about how these pages behave has changed. Every field, every form, every action does exactly what it did before. The saving behaviour, the two-factor setup, the API key and webhook flows, and the Stripe billing controls are untouched. What changed is how the surface reads, not what it does.
Alongside the settings work, a corporation tax first-year period now shows its own start and end dates, where a first-year split could previously show the company year end in place of each period’s own boundary.
Why it matters
Settings used to read as a different product from the rest of the app: cards and borders and a palette that did not match the dashboard you spend your time on. Now the whole surface speaks once. The same calm band rhythm, the same legible labels, the same colour carrying the same meaning on every screen. A state that needs your attention is the colour of attention; a figure that is settled reads as settled. You stop having to relearn the page each time you cross from the dashboard into settings.
The discipline that makes a reskin safe is that it stays a reskin. The real risk in restyling a working page is that you quietly change what it does. Here, every data path was carried across untouched and then checked to be identical to the page it replaces, so the trust you already had in these screens transfers wholesale. The billing view still resolves to exactly one state per visit, two-factor still enables only against a verified code, and a developer secret is still shown once and never again.
The corporation tax fix is small, and it is the kind that matters: a date you read off your books should be the date that governs you. A company whose first year splits into two corporation tax periods now sees each period’s own start and end, rather than the shared year end repeated, so the period you are reading is the period that is real.
How it is proven
A reskin earns trust by proving it changed nothing it should not. Each settings page was rebuilt with its data layer held constant: every read, every write and every piece of state preserved verbatim from the page it replaces, then diffed to confirm the behaviour is identical and only the presentation moved. Each page was checked in both light and dark themes before it shipped.
The release crossed the sixteen-phase deploy pipeline with the executable anchor suite green and zero violations. Because the settings work adds no behaviour, those anchors are themselves the assurance that nothing beneath the surface moved: they ran unchanged and stayed green. The corporation tax date fix carries its own anchor: a test that pins each period to its own start and end, asserts the two periods in a split read different ends rather than the shared year end repeated, and confirms a straight twelve-month period is unaffected. That anchor fails if the dates are ever bound back to the shared year end, so the correction cannot quietly regress. The underlying payment dates these periods drive were already governed by the end-of-month rule proven over a closed set of thirty-one dates (migration 123) and were not changed by this release; what changed is that each period now reports its own boundary.
Operational impact
The settings surface changes in appearance only. No endpoint, request or response shape changed. Endpoint count: 215, unchanged. There are no breaking changes.
Deferred
Two pieces from 5.89.0 remain the next steps, unchanged by this release. A company whose first period runs a little over twelve months still has its corporation tax deadlines held back until the first-year split lands. This release corrects the dates those periods display, but the two deadlines themselves still wait for the split. And a company that began recording transactions before it set its accounting reference date still cannot set or correct it in settings, and sees its company details read-only until the change path for an established company arrives.