[arzvaak]

Issue for this PR

Closes #69

Type of change

• New feature
• Bug fix
• Documentation

What does this PR do?

Adds opt-in Mobile devices settings backed by the existing Desktop sidecar and hosted OpenTunnel service. Phones require matching-code approval and separate revocable credentials; public QR links contain no access credentials.

Keeps optional mobile storage failures from blocking Desktop startup, preserves damaged state until explicit reset, cancels pending/queued/restoring pairing before reset, rejects stale Settings responses, and gives the QR its four-module clear border.

How did you verify your code works?

• 52 connector tests, 168 Desktop tests, 55 browser tests, five Settings Playwright cases, Desktop/app/e2e typechecks, and five companion generator/browser-helper checks passed.
• Earlier full app suite: 748 passed and one existing Arabic parity failure, reproduced on the clean base; no suppression or unrelated translation edits.
• Physical Android 17: the user scanned the installed Desktop QR, approved the matching code and confirmed real conversations loaded. This qualifies the Mobile camera fix against the installed Desktop; it is not acceptance of a new all-platform Desktop release.

Details: docs/mobile-access-fixes-2026-10-28.md.

Screenshots / recordings

Before: Reset disabled while synthetic provisioning is pending

After: Reset remains available to cancel the same synthetic provisioning state

Both images are isolated Playwright renderer fixtures using fake IPC; they are not live sidecar, camera, or pairing-flow screenshots.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

Companion Mobile PR: BharatCode-ai/bharatcode-mobile#1

[shrey16]

Reconciliation found a reproducible recovery issue: corrupt admissions.json prevents connector creation; reset reports success but preserves the corrupt file, so the next pair attempt fails again (desktop-api.mjs loading and desktop-access.mjs reset). Recovery must quarantine/report safely while retaining ambiguous-delivery protections, not simply erase the journal and allow duplicate prompts. Keep the generated connector synchronized with bharatcode-mobile. Independent tests passed: connector 52, Desktop 168, app browser-condition 55; typechecks passed. App unit tests have the same pre-existing Arabic parity failure on clean dev. Packaged runtime/physical-device coverage remains unverified here. Holding until recovery is addressed.

[arzvaak]

Fixed the recovery case you found and synced the connector source and tests with Mobile.

Reset now writes a recovery marker before moving the damaged journal into a private backup. It reports storage failures, and healthy journals are left intact.

Losing the journal does not allow uncertain prompts to run again. Existing conversations remain readable, and matching stored messages can be acknowledged without resending. Unknown old prompts are blocked with an explanation. Sending resumes in a new conversation created on the phone, using a fresh identity recorded durably rather than a timestamp check.

With dev f8c7fea merged, all 65 connector tests and 170 Desktop source tests pass. The actual-server regression also passes: two intended prompts produce two submissions and two model calls; retries add none. The packaged Linux Reset check preserved the corrupt bytes and completed without an error.

The app suite still has the locale-parity failure reproduced on clean dev. Standalone release checks are not all green, and physical-phone and Windows/macOS acceptance remain unverified. Full verification notes: docs/admissions-recovery-2026-10-30.md.

[shrey16]

Rechecked a1b14eb against the previous corrupt-journal finding. The recovery fence is persisted before quarantine, uncertain old submissions remain blocked, and only connector-created new identities can resume delivery. Independently ran all 65 connector tests successfully, including the real HTTP recovery/restart case. Confirmed the connector source is byte-identical to Mobile #2. Thank you for the targeted fix. Remaining integration work: update against current dev after #64/#71, preserve their auth/support guards, and rerun the focused Desktop tests/typecheck. Mobile CI is currently blocked by the Expo/React Native patch mismatch tracked in BharatCode-ai/bharatcode-mobile#3, not an observed recovery regression. Please include a concise real-phone pairing/revoke/reconnect result before a packaged release; no production credentials or giant new test matrix needed.

The corrupt-journal blocker is resolved at a1b14eb: 65 connector tests pass and Mobile source parity is verified. Remaining current-base integration and release/device checks are tracked in the follow-up comment.

[shrey16]

Rechecked the exact current head a1b14eb together with current dev 2e01b61 in a clean local merge: 206 Desktop source tests and 65 connector tests pass; Desktop type-checking passes. The corrupt-journal recovery now preserves the uncertainty fence and existing forwarding journal, and the connector source matches the companion Mobile PR. Approving this development merge. This is not a signed Desktop/Mobile release: Mobile #2 still needs the Expo/React Native CI correction tracked in BharatCode-ai/bharatcode-mobile#3, plus native acceptance before publication.