Updates, versions & the rhythm
Sonderr updates on one principle: when an update runs, it is the update you saw, verified, and nothing else. This guide covers the mechanics — the fail-closed update gate, required updates, what changes on disk — and the rhythm behind them. DXN1-STUDIOS is a one-person studio, and the cadence says so out loud: roughly monthly at best, sometimes slower, giant when it lands.
Two things are true about Sonderr updates at the same time. Mechanically, they are conservative: a fail-closed gate decides what runs, and required updates are required for good reasons. Rhythmically, they are slow on purpose: a one-person studio ships when the work passes the bar, not when a calendar page turns. This guide covers both halves, because trusting an update means knowing both what it does and why it took the time it took.
1 · The fail-closed update gate
The launcher wraps every update in a gate that fails closed: if the source cannot be verified, the update does not run — the old version keeps working instead. There is no fallback to "run it anyway," no override flag to regret. The gate is the same idea as the rest of the security model, applied to supply chain: what runs on your machine is what you verified, or nothing. The launcher internals, including how the gate sits in the boot sequence, are in CLI & launcher reference.
2 · Required updates — the honest kind
Most releases are optional: skip them and everything keeps working. Some are marked required — typically when a change is load-bearing for safety or compatibility, and running an old version would be quietly worse for you. A required update is announced in the release notes and on the announcements feed before the gate enforces it, so it never arrives as a surprise mid-work. That is the whole trick: required is a category you were told about, not a behavior you discover.
3 · What an update touches — and what it never does
| Area | An update may… | An update never… |
|---|---|---|
| Runtime & workspace | Replace engine and interface code | Touch your sessions or settings without consent |
| Skills library | Refresh the 65-playbook set | Delete your own notes or exports |
Data (~/.sonderr/) | Read its own config | Leave your machine |
| Source | Verify before it runs | Run unverified code "as a fallback" |
Your data map — sessions, uploads, task notes, everything under ~/.sonderr/ — is documented completely in Your data, your machine, including the one-copy backup and the full wipe. Updates are guests there: they replace the software, not the record of your work.
4 · The rhythm — slow by design
Here is the part most products hide and this one won't: DXN1-STUDIOS is a one-person company, for now. The cadence follows from that honestly — roughly monthly at best, sometimes slower, and giant updates preferred over frequent drips. When the studio grows — the co-ownership seat is publicly open — the cadence is the first thing that speeds up. Until then, slow is not a scandal; it is the price of every release passing the bar, written down where you can read it. The full policy, including what would make it faster and what DXN1 will not do, lives on Release cadence — slow by design.
5 · Reading releases
Every release lands in two places, in this order: the changelog, which records what changed, and the announcements feed, which explains why and what it means. The feed is the source of truth — if a change is not announced there, treat any claim about it as rumor, including rumors in this documentation. Version notes follow a fixed shape: what changed, what it touches, whether the update is required, and anything you should do besides update.
6 · Staying put safely
It is fine to not update. Skipping an optional release is a supported state, not an error: the old version keeps working, and the gate does not nag. Two courtesies are asked in return — read the required-update notices when they come (they are rare and short), and keep one copy of your data backed up so any update, rollback or fresh install is a non-event. The backup is one command, in Your data, your machine; the configuration knobs around versions and checkouts are in Configuration & environment.