Beta features

Some of what 2.6.0 built ships behind a switch. The switch is one boolean on the instance — Admin → Instance → Beta features — off by default, flipped by an administrator, and read by every signed-in user. It applies immediately; no reload, no restart.

The panel next to the switch lists what it turns on, with a plain sentence for each entry, read from the same registry the application’s own gates check. So the list cannot claim something the build does not do, and a gate that has lost its reason shows up as one.

What is behind the switch in 2.6.0

Feature	Why it is hidden	What brings it out
Places — the domain, its pages, the dashboard tab, the module toggle, place visits on the trip timeline, the web import panel	The CSV and Google Maps import routes exist, but the web surface for the rows that need a decision does not yet	That surface: an import tile, a preview for rows that need input
Tours — the Tours tab on a trip, the section list, the route editor, the Tours dashboard tab	Works end to end; the owner ruled the feature unfinished for this release	The owner accepts tours for release
Companion pairing — the Devices section in settings	Pairing works; the Companion app and the flows behind it are unfinished	The owner accepts the pairing for release
Dawarich connection — the settings card and the admin card	Every consumer of a recorded track (tours) is beta, so the connection that feeds it is too	Tours are released, or another consumer of recorded tracks ships (cruise legs are planned)
The passport page — /passport, its nav entry	Complete, and its numbers agree with the statistics page, but it shipped in the middle of a release candidate	2.6.0 has been in real use for a round, or 2.7.0 opens
Per-domain colours — the appearance section that lets a user repaint the four domain hues	A brand constant would become a default, which reaches into screenshots and documentation	The brand decision is settled
The AI trip summary — the card on the trip page	The generated summaries are buggy and the Trips area is still being finished	The Trips feature is complete

Three of these — tours, pairing and Dawarich — were briefly offered to everyone in a late release candidate, once the conditions their own gates named had come true. On reading the 2.6.0 announcement the owner ruled all three beta and put them back, together, so they move as one. “Beta” here means exactly that: the code works, and the product decision has not been taken.

What the switch does to data

Nothing. The switch is a visibility gate. Turning it off hides the pages, tabs, cards and toggles; it deletes nothing, migrates nothing, and the rows stay where they are. A user who recorded places on an instance with the switch on, and whose administrator then turns it off, still owns those rows; they simply stop being shown, and a place visited on a trip keeps its visit and reappears intact the moment the switch comes back on. The same holds for tour sections and a paired device.

Turning it on shows what was always there. It creates no rows and runs no migration — the tables ship with every build.

What the switch is not

It is not a security boundary. The backend routes behind the gated features — /pairing/*, /stats/passport, the places routes, the trip route sections, the Dawarich settings — stay reachable for any authenticated user whatever the switch says. That is deliberate:

• hiding the Devices UI must not lock the instance owner out of pairing, so the section stays reachable by its address;
• the Companion app reads /stats/passport and must not have to care what an instance’s switch says;
• a script with a Personal Access Token sees the same API on every instance.

Authorisation is done by the session and the token scope, as everywhere else. The switch decides what the web UI offers.

Who should turn it on

An instance whose users want to try places, tours or the passport, and accept that those surfaces may change between releases. A production instance with several users is better left off until each feature comes out on its own — the list in the admin panel will shrink as they do, and the changelog names each one when it happens.

For the curious: how the gate is kept honest

Every gate in the frontend names a key from one registry, and each entry carries why it is hidden and the condition under which it comes out. A test fails when a gate names a key that is not registered, or when an entry lacks either sentence. Un-gating a feature means deleting its entry and every gate that named it — a gate left wired to a key that no longer exists would read like a gate that is still there. The admin panel renders that registry, which is why its list and the application’s behaviour cannot drift apart.