ROADMAP: pairing a panel through the portal

The component-level side of the M5 item: which three gates close that path
today and which scope branch opens them.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AHpLJHozysQXjsxAyU1WHj
This commit is contained in:
2026-08-20 17:46:14 +02:00
co-authored by Claude Opus 5
parent ce77262f81
commit 2552c92a45
+12
View File
@@ -283,6 +283,18 @@ Shares components with the admin view. See `docs/architecture/structure.canvas`
dashboards overview, and the credential that mints is scoped to that dashboards overview, and the credential that mints is scoped to that
panel's dashboards and the message endpoints its widgets speak. Deleting panel's dashboards and the message endpoints its widgets speak. Deleting
the panel revokes it the panel revokes it
- [ ] Pair a panel through the portal, for a screen hanging somewhere the
installation is not reachable from. Three gates today: the hub's app shell
redirects a browser carrying no portal session, its proxy authorizes before
forwarding so the unauthenticated pairing call never crosses the tunnel,
and the app under a portal takes its bearer from the injected config rather
than from storage. A hub token with a `panel` scope opens all three —
`decode_portal_token` already branches on scope, and `_panel_may` then
applies unchanged, so the installation stays the authority on what the
panel reads. The owner check in the hub's `_authorize` is what a panel
token must not fall through, and the rate-limit key beside it assumes a
user id too. Milestone-level rationale, and the alternative worth weighing
first, are in `docs/private/roadmap.md` § M5
## Phase 5 — Website and docs ## Phase 5 — Website and docs