Clarity Deep Links — Unterstützte Ziele und Grenzen

Öffentlicher Vertrag

Unterstützte Einstiege.

Die Liste beschreibt nur Wege, die als externe Navigation begründbar sind. Interne Tab-, Help-, Support-, Staff-, Marketplace- und Einladungsrouten werden nicht automatisch zu einer stabilen Partner-API.

clarity://assistant

Ariadne öffnen

Öffnet den vorhandenen Assistant-Tab. Der Link übergibt weder Prompt noch Kontodaten.

Unterstützt

clarity://assistant/voice

Spracheingabe anstoßen

Öffnet Ariadne und setzt den vorhandenen Voice-Start im App-Router. Die Berechtigungsentscheidung bleibt in der App.

Unterstützt

clarity://voice-notes

Voice Notes öffnen

Öffnet die vorhandene Voice-Notes-Oberfläche. Es wird keine Aufnahme durch die URL übertragen.

Unterstützt

clarity://session/{catalogue-id}

Guided Session öffnen

Öffnet ausschließlich eine ID, die der App-Katalog kennt. Unbekannte IDs werden nicht fuzzy aufgelöst.

Allowlist

https://{entitled-domain}/clarity/session/{catalogue-id}

Web-Fallback einer Session

Die noindex-Fallbackseite akzeptiert nur die öffentliche ID-Allowlist und lädt keine Konto-, Fortschritts- oder Sitzungsdaten.

Release-gebunden

Auflösung

Prüfen, dann öffnen.

Die App trennt benutzerdefinierte Scheme-Routen von HTTP(S). Für Guided Sessions wird die ID gegen den vorhandenen Katalog geprüft. Bevor eine neue Session erscheint, wird bestehender root-eigener Präsentationszustand zurückgesetzt; eine unbekannte ID öffnet nichts.

route-resolution.txt

1  Scheme oder HTTPS erkennen
2  Host und Pfadform prüfen
3  catalogue-id gegen freigegebenen Katalog prüfen
4  konkurrierende Präsentation schließen
5  exakt angefragte Session öffnen

unknown host → ignore
unknown catalogue-id → no route

Keine Nutzdaten in der URL

Die Route trägt die Navigation. Konto, Prompt, Fortschritt, Sessioninhalt, Berechtigung und Entitlement werden nicht in Query oder Pfad eingebettet.

Universal Links

Drei Teile, eine Freigabe.

App-Router: Der aktuelle iOS-Router kennt den Pfad /clarity/session/{catalogue-id} nur auf explizit unterstützten Hosts.
AASA: Die Website liefert die Association-Datei unter /apple-app-site-association und /.well-known/apple-app-site-association als JSON ohne Redirect aus.
Signiertes Entitlement: Die Domain muss im ausgelieferten App-Build als Associated Domain enthalten sein. Eine Website- oder Build-Variable allein aktiviert keinen Universal Link.
Web-Fallback: Wenn die App nicht übernimmt, zeigt die Webroute nur die allowlist-validierte Sessionübergabe und einen sicheren Downloadweg.

Öffentliche App-ID, kein Credential

RR24DD5K64.com.moritzzinecker.clarity ist die derzeit in AASA ausgewiesene Team-/Bundle-Kombination. Vor Produktion muss sie gegen den tatsächlich signierten Release-Build geprüft werden.

Sicherheitsgrenzen

Was ein Link nicht darf.

Kein fremder HTTP(S)-Host darf einen Clarity-Kontext öffnen.
Eine freie oder neu konfigurierte Domain ist nicht automatisch Teil des App-Entitlements.
Der Fallback akzeptiert keine beliebige Session-ID und macht keine Netzwerk- oder Datenbanksuche daraus.
Der Link überträgt keine Anmeldung, Rolle, Berechtigung oder Planfreigabe.
Interne Support- und Staff-Routen sind kein dokumentierter Partnerweg und bleiben an App-Status, UUID und Rolle gebunden.
Neue HTTPS-Pfade werden erst öffentlich dokumentiert, wenn App-Router, AASA, Fallback und Release-Build denselben Vertrag abbilden.

Release-Prüfung

Vor jeder neuen Domain oder Route.

1 · Router: Die signierte App erkennt genau den dokumentierten Host, Pfad und Fallback.
2 · Katalog: Jede öffentliche Session-ID existiert explizit in Web-Allowlist und App-Katalog.
3 · AASA: Beide standardisierten Pfade antworten direkt mit korrektem JSON und ohne Redirect.
4 · Entitlement: Der ausgelieferte Build enthält die beabsichtigte Associated Domain.
5 · Negativtests: Fremdhost, unbekannte ID, fehlende App und fehlende Berechtigung scheitern sicher.