[httpsphl]

What

The phone (spec section 28): a PWA that approves requests and answers questions from the owner's bots, from anywhere. It is a remote control only: no chat, no files, no messages to bots. The bots keep running on the computer and the daemon still listens only on 127.0.0.1.

How it works:

• Sealed end to end. ECDH P-256 + HKDF + AES-256-GCM (all WebCrypto-native, so the page carries no crypto library). The relay carries bytes it cannot open. docs/test-vectors/mobile.json is written by the daemon's tests and read by the page's tests, and was also checked against Node's WebCrypto.
• Connecting by QR. The QR holds #p=<id>&s=<secret>&d=<computer key> after the #, which the browser never sends. The phone proves it read the secret, both screens show the same six digits, the owner accepts at the computer, and the phone collects its token once.
• A phone token reaches only the relay, push, /v1/me and logout. Never the backups.
• What the phone may allow is limited to plain tools (Bash, PowerShell, WebFetch, WebSearch, file tools, the plan), shown whole (<= 8 KiB), once only. Everything else, and anything cut, can only be denied there. The daemon checks again when the answer arrives.
• Notices are empty, VAPID-signed Web Pushes (nothing for a push service to read). The page's service worker writes the text. The server calls only the browsers' push hosts.

Slices, one commit each (spec CE1–CE7):

CE1	spec section 28
CE2	botloft-cloud: pairings, WebSocket relay, queue, restricted phone token
CE3	botloftd: relay client, sealing, pairing, approval/question bridge, mobile.* methods
CE4	app: "Phone" block in Settings (QR drawn in the app, code comparison, disconnect)
CE5	the phone's page (app/src/phone), served by the account server at /m; Docker stage builds it
CE6	Web Push ([push], botloft-cloud vapid-key)
CE7	rehearsal results and the real-device runbook (spec 28.10, 19)

How it was checked

• cargo fmt, cargo clippy -D warnings, cargo test --workspace: pass. pnpm check (types, lint, 510 tests): passes.
• A real browser as the phone against the real server and daemon (in process): connect with the code, receive the list, allow a command, deny the rest, answer a question, see the "disconnected" notice. Run it with cargo test -p botloftd --test mobile_live -- --ignored --nocapture.
• The full Docker image builds and runs read-only and non-root; /m is served under its policy, ..%2f stays inside the folder.
• Rust and the page's WebCrypto agree byte for byte on keys, proofs, the code and sealed messages.

Not checked yet (needs the VPS updated and two phones)

The runbook is in spec 28.10 and the results table in section 19 says "em parte":

• the service worker and the notice arriving on a locked phone (Android Chrome, iPhone Safari with the page on the Home Screen). The app's own browser pane cannot register service workers at all, so this cannot be seen there;
• the system camera keeping the # of the QR on iOS and Android;
• WebCrypto on Safari; wss and the 25 s ping behind Cloudflare for hours.

For whoever deploys

The deployed server (botloft.comitium.com.br) is the old version. It needs this image, phone_dir = "/srv/phone" and, for notices, [push] with a key from botloft-cloud vapid-key (docs/cloud-deploy.md). Without [push] everything else works and the phone shows only what is there when it is opened.

Known: the page's JavaScript is 711 KB (223 KB gzipped) because it carries the app's strings; it can be slimmed later.