docs: state device approval as an API rendezvous in the blueprint

[FSM1]

Records ADR 0009 (FSM1/cipher-box-next#65, merged) in the blueprint. Documentation only, no code surface.

Replaces #1263, which GitHub auto-closed when its base branch was deleted on the merge of #1255. Same content, rebuilt on main.

The framing being corrected

Three files described MFA and device approval as chrome-side Core Kit UX. Device approval cannot be UI-side: the Core Kit has no native cross-device share transfer, so approval is a server-mediated rendezvous — and v1 built an API module with its own table and migration to provide one. The mislabel is why v2 has no endpoint, no UI, and until this week no issue.

What changed

api.md — the rendezvous joins the other API surfaces: request, poll, respond, cancel and a pending list, under a scoped non-refreshable pre-reconstruction token, with the API as a bulletin board that relays ciphertext and never holds plaintext key material. Both halves carry a device-key signature, and a row's life ends at collection or expiry. device_approvals joins the table list.

web-client.md — the Core Kit bullet keeps MFA enrollment and loses device approval. A new bullet states the client's part: mint the ephemeral key, display the comparison value both devices must match, sign both halves with the device identity key, and seal a fresh factor rather than the approver's own. The /settings row distinguishes enrollment and recovery from authorized devices and approval.

desktop.md — records that the recovery phrase always works on this host, with no second device and no rendezvous, and that desktop's participation in approval is a scope decision to make rather than leave open. v1 shipped a requester UI that could never work beside a settings string saying MFA was web-only.

testing.md — the Core Kit staging-dispatch exemption covers interactive login and MFA enrollment, and explicitly does not extend to device approval, which runs over our own API and needs a harness driving two sessions. v1 skipped every cross-device case for want of a second device, which is exactly how a desktop path sending a 33-byte key where 65 were required reached a verified status.

Checks

markdownlint-cli2 and prettier --check clean on all four files.

Note

Document device approval as an API rendezvous flow in the blueprint

• Updates blueprint/api.md to describe device approval as a request/poll/respond/cancel rendezvous under a scoped, non-refreshable pre-reconstruction token, and adds a device_approvals table to the schema list.
• Updates blueprint/web-client.md to move device approval out of Core Kit UI responsibilities, describing it as a server-mediated rendezvous where the client mints an ephemeral key, displays a comparison value, signs with a device identity key, and seals a fresh factor to the requester.
• Updates blueprint/desktop.md to remove device approval from the Tauri webview scope and note that recovery phrase always works on desktop, flagging an open question about desktop participation in device approval.
• Updates blueprint/testing.md to explicitly exclude device approval from the Core Kit staging-dispatch exemption, noting it requires a two-session harness and is absent from v1 cross-device test coverage.

^{Macroscope summarized abeaec3.}

[coderabbitai]

Warning

Review limit reached

@FSM1, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 57 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: ebc13af2-cb44-4506-a90c-7c2e9cdf0fc6

📥 Commits

Reviewing files that changed from the base of the PR and between 6d987de and abeaec3.

📒 Files selected for processing (4)

• blueprint/api.md
• blueprint/desktop.md
• blueprint/testing.md
• blueprint/web-client.md

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}