feat: a public live demo, a read-only viewer role, and links out of the login footer

[fclairamb]

Three specs, each implemented in isolation and cleared by an independent completeness audit before being archived to specs/done/2026/09/. Two needed a fix round; both re-audited clean.

1. viewer is finally read-only — a real privilege fix

This is a behaviour change. viewer is offered in the members UI as the read-only tier, and nothing enforced it. A viewer could create and delete checks, resolve incidents, publish to public status pages, edit notification plumbing, and send test reports. Anyone relying on that — knowingly or not — will now get a 403.

• New RequireOrgWrite floor, applied structurally in the orgGroup helper, so a new org route cannot ship without it.
• The role is read from the membership row, not the token: a demotion bites on the next request, and a PAT minted while the user was a user stops writing the moment they are demoted.
• Exactly two self-scoped exemptions: your own notification settings (/users/me/*) and your own PAT (POST /tokens).
• MCP gets the same floor. Scope was the only gate there, so a viewer holding a full-mcp token could create_check straight past REST middleware.
• Incident ack/snooze/resolve are deliberately denied — they change what the whole team is paged about. A team that wants that gives the person user.

The deliverable is the proof, not the middleware: a route walk asserts every non-GET org route refuses a viewer on the gate's own message (so an unrelated 403 can't mask a regression), with a positive control walking the same table as a user — a floor that also locks out ordinary users would be worse than the hole it closes.

Implementation found four write surfaces the spec's own inventory missed, all previously open to viewers: the Slack and Discord install-url endpoints, MS Teams link-code, and job cancellation.

Out of scope by design: dash0 still renders write buttons for viewers. The honest 403 is the intended interim; hiding them is a follow-up spec.

2. A public live demo account — off by default

Evaluators had to sign up before seeing anything work. This adds a real demo org and user reachable through the standard login, on the production server so the multi-region fleet and real history are the demo.

Safety is a positive allowlist, not a denylist: a demo session may create a check and edit or delete its own, and nothing else. Everything else answers DEMO_READ_ONLY. Seeded catalogue checks are created_by = NULL and therefore untouchable by construction, with no "protected" flag to forget.

• Guard sits inside RequireAuth/RequireMCPAuth — the one chokepoint every authenticated route passes — and matches on the router pattern, never the raw path.
• Load is bounded by entitlements that already existed (maxChecks, maxChecksPerMinute), not new machinery.
• Only side-effect-free credential-free probe types; only SolidPing-owned targets — the demo never probes a third party. Notifications go to our own /api/v1/fake sink.
• A 30-minute cleanup job deletes expired visitor checks through the real delete path and reconciles the shared identity, so anything that slips is undone within half an hour.

SP_DEMO_ENABLED defaults to false — merging this exposes nothing until it is switched on.

3. The login footer says what it is and links somewhere

v0.24.0 as bare text becomes SolidPing v0.24.0, two links: the brand to the marketing site with UTM parameters distinguishing SaaS from self-hosted, the version to the changelog. This also exposes deploymentMode on /api/mgmt/version — dash0 previously had no way to tell which flavour it was running on, and the alternative was sniffing the hostname.

Notes for review and deploy

• New migration 019_v0_25_0 on both backends: users.demo and checks.created_by.
• created_by is now recorded for every check creator, not just demo sessions — useful audit data in its own right, and exposed as createdBy.
• The billing service was verified — not assumed — to never write entitlements for an org with no Polar customer, so the pinned demo row cannot be overwritten. ../solidping-billing is untouched.
• An integration test proves a correctly-signed billing entitlements push still returns 2xx through the full chain, with a viewer-session negative control proving the new floor really is in the chain that push travels through.

QA

Backend build, lint and full test suite green; dash0 build, lint and 1372 unit tests green; docs build green. dash0 ESLint holds at its 42-error pre-existing baseline with zero new errors in touched files.

🤖 Generated with Claude Code