Status Displays & Cloud

Status Displays & Cloud

Covers the status indicators visible in the app’s UI for embedding, sync, and cloud authentication. Several of these subsystems are unavailable in the QA bridge environment — the app should surface “Unavailable” or “Disabled” states rather than crashing or showing misleading indicators.

This spec is P2. The scenarios here validate that status indicators correctly reflect the app’s degraded or limited state in the bridge environment, and that the UI handles unavailable subsystems gracefully.

Preconditions

• The app is open and a workspace is loaded
• Status indicators are visible in the bottom bar, settings panel, or equivalent location
• For cloud-dependent scenarios (auth session, sign-in flow): the app must have Supabase credentials configured. In a CI environment without credentials, those scenarios should be skipped with a note referencing the missing configuration.
• For sync bridge:skip scenarios: no special setup is required — the unavailable state is unconditional in the bridge environment.

Scenarios

Seed: seed.spec.ts

1. Embedding status indicator — shows Idle in the bridge environment

The embedding pipeline is not running in the bridge environment. The embedding status indicator in the app should reflect this without showing an error.

Steps:

1. Open the app settings panel or observe the bottom status bar.
2. Locate the embedding status indicator.
3. Observe its current state and label.

Expected: The embedding status indicator shows “Idle” (or equivalent text such as “Not running” or “Unavailable in this mode”). No error badge or crash is displayed. The indicator is visible and legible.

2. Rebuild embedding index — action completes silently in bridge mode

The embedding index rebuild is a no-op in the bridge environment. Triggering it should not show an error.

Steps:

1. Open the app settings panel.
2. Locate the embedding / semantic search section.
3. Click “Rebuild Embedding Index” (or equivalent action button).
4. Observe the feedback shown.

Expected: The UI briefly indicates the action was triggered (spinner, “Rebuilding…” text, or similar). The indicator returns to a non-error state (Idle or OK) after the action completes. No error message is displayed.

3. Sync status indicator — shows Unavailable in the bridge environment

bridge:skip — The sync engine is not available in the bridge. The sync status indicator should show “Unavailable” or “Disabled” rather than an active or error state.

Steps:

1. Open the app settings panel or observe the bottom status bar.
2. Locate the sync status indicator.
3. Observe its state and label.

Expected: The sync status indicator clearly shows “Unavailable”, “Disabled”, or “Not supported” (or an equivalent visual treatment such as a greyed-out icon). No false “Syncing” or “Synced” state is shown. The app does not crash or display an error banner.

4. Start sync action — shows Unavailable feedback in the bridge environment

bridge:skip — Triggering sync start from the UI should result in an “Unavailable” or “Not supported” message, not a success indicator.

Steps:

1. Open the sync section in settings or the bottom bar.
2. Click “Start Sync” (or equivalent action).
3. Observe the UI response.

Expected: The UI displays a message such as “Sync is not available in this mode” or shows a disabled state. No spinner that resolves to “Synced” is shown. The app does not crash.

5. Stop sync action — shows Unavailable feedback in the bridge environment

bridge:skip — Stopping sync should surface an unavailable message, not a success state.

Steps:

1. Open the sync section in settings.
2. Click “Stop Sync” (or equivalent action).
3. Observe the UI response.

Expected: Same as scenario 4 — the UI shows an “Unavailable” or “Disabled” message. No false sync state change is indicated.

6. Pull sync action — shows Unavailable feedback in the bridge environment

bridge:skip — Triggering a pull sync should be handled gracefully in the UI.

Steps:

1. Open the sync section in settings or the bottom bar.
2. Click “Sync Now” or “Pull Changes” (or equivalent action).
3. Observe the UI response.

Expected: The UI shows “Unavailable” or “Not supported” feedback. No data appears to sync and no success state is shown. The app remains stable.

7. Force sync action — shows Unavailable feedback in the bridge environment

bridge:skip — Force sync is not available in bridge mode.

Steps:

1. Open the sync section in settings.
2. Trigger any “Force Sync” or “Full Sync” action.
3. Observe the UI response.

Expected: The UI shows “Unavailable” or “Disabled” feedback. No success state is indicated. The app does not crash.

14. Auth panel — no session stored shows logged-out state

When no auth session is stored, the auth section in settings should clearly indicate the user is not signed in.

Steps:

1. Open the app settings panel and navigate to the Account or Cloud section.
2. Ensure no active session by first signing out if currently signed in (see scenario 17).
3. Observe the auth state indicator.

Expected: The auth section shows a “Not signed in” or “Sign in” state. No user name, email, or avatar is displayed. A “Sign in” or “Log in” button is visible and enabled.

15. Store and retrieve auth session — logged-in state is reflected in settings

Sign in with valid credentials and verify the auth section in settings updates to show a logged-in state.

Steps:

1. Open the Account section in settings.
2. Observe the current auth state (should be signed-out from scenario 14).
3. Sign in by entering test credentials (or via the OAuth flow if available in the test environment).
4. After sign-in completes, return to the Account section.
5. Observe the displayed auth state.

Expected: The Account section shows a logged-in state: a user name or email is displayed, and the “Sign in” button is replaced with a “Sign out” option. The session indicator is active (green dot or similar visual cue).

16. Clear auth session — Account section returns to signed-out state

After signing in, sign out and verify the Account section reverts to the signed-out state.

Steps:

1. Ensure a session is active (from scenario 15 or a prior sign-in).
2. Open the Account section in settings.
3. Click “Sign out” (or “Log out”).
4. Confirm sign-out in any confirmation dialog.
5. Observe the Account section state.

Expected: The Account section shows “Not signed in” and the “Sign in” button reappears. No user name, email, or avatar is displayed. The auth state indicator is inactive.

17. Sign out action — clears session and updates auth display

Sign out explicitly via the settings panel and verify the auth indicator in the app updates.

Steps:

1. Ensure a session is active.
2. Open the Account section in settings.
3. Click “Sign out”.
4. After sign-out, observe the Account section and any persistent auth indicator in the bottom bar or header.

Expected: All auth indicators in the UI (settings panel, bottom bar, header) show a signed-out state. The sign-in button is visible and the user name / avatar is gone.

18. Sign up with email — shows Unavailable in the bridge environment

bridge:skip — Email sign-up is not implemented in the bridge. Attempting it should show an unavailable or not-supported message.

Steps:

1. Open the Account section in settings.
2. Click “Sign up” or “Create account”.
3. If a form appears, attempt to submit with an email address.
4. Observe the UI response.

Expected: The UI shows a message such as “Account creation is not available in this mode” or the sign-up form shows an error after submission indicating the feature is unavailable. The app does not crash.

19. Sign in with email — shows Unavailable in the bridge environment

bridge:skip — Email sign-in is not supported in the bridge.

Steps:

1. Open the Account section in settings.
2. Click “Sign in with email” (or equivalent).
3. Enter any email and password.
4. Attempt to submit.
5. Observe the UI response.

Expected: The UI displays “Not available in this mode” or an equivalent message after submission. No session is created. The sign-in form does not proceed to a logged-in state.

20. Sign in with OAuth — shows Unavailable in the bridge environment

bridge:skip — OAuth sign-in (Google, GitHub, etc.) is not available in the bridge.

Steps:

1. Open the Account section in settings.
2. Click an OAuth sign-in option (e.g., “Sign in with Google”).
3. Observe the UI response.

Expected: The OAuth flow either does not launch, or it shows an immediate error: “Not available in this mode.” No browser redirect to an OAuth provider occurs. The app remains stable.

21. Cloud health — app liveness indicator shows OK

The app exposes a basic health status that confirms the backend process is running. This is observable as a status indicator in the app.

bridge:partial — There is no dedicated “cloud health check” in the bridge UI. Use the bridge’s own /health endpoint or the equivalent app-level liveness indicator as a proxy.

Steps:

1. Observe the app’s connection or status indicator in the bottom bar or settings panel.
2. Note whether the bridge process shows as reachable/connected.

Expected: The status indicator shows the app backend is reachable (e.g., a green “Connected” dot, “Online”, or no disconnection warning). The indicator is not blank or in an error state.

22. Cloud workspace list — shows Unavailable or prompts sign-in

bridge:partial — Cloud workspace listing is not implemented in the bridge. The UI should reflect this limitation gracefully.

Steps:

1. Open the settings panel or workspace switcher.
2. Look for a “Cloud Workspaces” or “Sync to Cloud” section.
3. Observe the state if no cloud session is active.

Expected: The cloud workspace section shows “Sign in to view cloud workspaces” or “Not available” (if the feature is not exposed in this environment). The section is not blank and does not display an error. If the feature does not appear in the UI, this scenario passes by absence.

Note: If cloud workspace listing is added to the bridge in a future iteration, update this scenario to assert a successful list response.

23. Refresh session — shows error when no session is stored

Attempt to refresh the auth session when no session is currently stored. The UI should surface an appropriate error state rather than silently failing.

Steps:

1. Ensure no session is active (sign out if needed).
2. Open the Account section in settings.
3. Observe whether a “Refresh” or “Reconnect” action is available.
4. If visible, click it and observe the response.

Expected: The UI displays an error such as “No active session to refresh” or the refresh button is disabled when signed out. The app does not crash. The auth section remains in the signed-out state.

Note: In a CI environment without Supabase credentials, this scenario should be skipped.

24. Sync cursor display — shows zero or initial state for a fresh workspace

A fresh workspace should show a sync cursor at zero or in an initial/never-synced state. This is observable via the sync status panel or a developer-facing sync details view.

Steps:

1. Open a freshly-initialized workspace.
2. Navigate to the sync settings or status panel.
3. Observe the sync cursor or “Last synced” indicator.

Expected: The sync cursor shows 0, “Never synced”, or an equivalent initial state. No error is displayed. The indicator is legible.

25. Sync cursor — updates after manual sync trigger in the full app (informational)

This scenario is informational and applies only to the full Tauri desktop app (not the bridge environment). It documents expected behavior for the sync cursor after a successful sync.

Steps:

1. (Full app only) Sign in and trigger a sync operation.
2. Observe the sync status panel cursor or “Last synced” timestamp.

Expected: After a successful sync, the “Last synced” timestamp updates to the current time and the sync cursor advances from 0 to a positive integer. In the bridge environment, this scenario is skipped as sync is unavailable.

26. Pending sync count — fresh workspace shows zero pending items

A freshly-opened workspace with no pages should show zero pending sync items in the sync status panel.

Steps:

1. Open a fresh workspace (one with no pages or minimal seed pages).
2. Navigate to the sync status panel.
3. Observe the pending sync count indicator.

Expected: The pending sync count shows 0 or “Nothing to sync”. No error is displayed. The indicator is legible.

27. Clear sync queue — pending count returns to zero after clearing

Create a page (which adds a pending sync entry), then use the QA maintenance action to clear the sync queue. Verify the pending count returns to zero.

Steps:

1. Ensure a workspace is open and the sync status panel is visible.
2. Create a new page in the workspace. Observe that the pending sync count increments.
3. Open the sync maintenance or QA tools panel.
4. Click “Clear Sync Queue” (or equivalent action, if exposed in the UI).
5. Observe the pending sync count after clearing.

Expected: The pending sync count returns to 0 after the queue is cleared. The sync status panel updates to reflect the empty queue. No error is displayed.

Note: The clear sync queue action is a QA-only maintenance operation. It should only appear in developer or QA modes, not in the standard user-facing UI.

Test Data

Key	Value	Notes
dummy_access_token	test-access-token-sentinel	Fake token for round-trip auth session tests
dummy_refresh_token	test-refresh-token-sentinel	Fake refresh token
sync_cursor_test_value	42	Arbitrary integer for cursor round-trip tests

Notes

• bridge:skip — The following subsystems ALWAYS show “Unavailable” or “Disabled” in the bridge environment. Tests must assert the unavailable UI state, not a success state:

  • Sync: get status, start, stop, pull, force sync
  • Auth: sign up with email, sign in with email, sign in with OAuth

• bridge:partial — The following have reduced functionality vs. the full Tauri desktop app:

  • Embedding status — always shows “Idle” regardless of actual index state (no embedding manager in bridge)
  • Rebuild embedding index — no-op; the UI should confirm completion without error
  • Cloud health — no dedicated cloud health check command; use the bridge liveness indicator as a proxy
  • Cloud workspace list — no route exists; the UI section shows a sign-in prompt or absence

• Auth session commands (store/get/clear session, sign out) are functional in the bridge and use local storage. refresh_session, register_device, list_devices, and deauthorize_device require a live Supabase instance and valid credentials.

• Tests for register_device, list_devices, and deauthorize_device are intentionally omitted because they require a live Supabase backend. These should be covered by a separate cloud-integration spec (future work).

• P2 priority reflects that users cannot trigger sync via the bridge — these features only function in the full Tauri desktop app. The bridge correctly reports its own limitations, which is what these tests validate.