Show per-connection memory sync status, controls, and progress #1136

[Feature] Show per-connection memory sync status, controls, and progress

Summary

Add a dedicated memory-sync UI that shows which connections are supported for memory sync, lets the user choose which connections should sync into memory, and exposes live per-connection progress/state so users can monitor what the memory pipeline is doing.

Problem

Today the app has pieces of memory tooling and sync triggers, but not a user-facing per-connection sync control/monitoring flow.

What exists today:

• the Memory UI can inspect memory content and trigger broad sync actions via MemoryWorkspace in app/src/components/intelligence/MemoryWorkspace.tsx
• the settings entrypoint already exists via app/src/components/settings/panels/MemoryDataPanel.tsx
• connection status is already surfaced separately through channel/account status APIs
• the core already has memory ingestion events (MemorySyncRequested, MemoryIngestionStarted, MemoryIngestionCompleted) in src/core/event_bus/events.rs
• provider connections already persist sync state in src/openhuman/composio/providers/sync_state.rs
• background tree work is already gated on host conditions in src/openhuman/scheduler_gate/**

What is missing:

• users cannot clearly see which supported connections can sync into memory
• users cannot explicitly choose which connections should feed memory and which should not
• users cannot see how much data a given connection has already synced
• users cannot see the current phase of memory work for each connection
• users cannot tell whether the system is actively working, waiting on scheduler/battery/CPU constraints, or finished

This is a product and trust problem. Memory sync is long-running, multi-stage, and partially deferred by design. Without a first-class UI, the system feels opaque and users cannot reason about cost, privacy, battery impact, or whether their integrations are working.

Solution (optional)

Build a dedicated per-connection memory sync surface in the app and back it with a structured core-side sync status model.

High-level product shape:

• show a list of supported syncable connections/providers in Memory
• show whether each connection is enabled for memory sync
• let the user enable/disable memory sync per connection
• show per-connection counters such as items/documents synced, pending work, last sync time, and current phase
• show a progress bar and status text for active work
• make the same controls/status visible from the main Memory screen and from Settings

Suggested per-connection phases/states:

• idle
• downloading — fetching provider data / backfill / delta ingest; usually fast
• compressing — summarization / reduction work running according to config
• tree_building — building the memory tree only when host conditions allow it, without wasting battery or clogging the machine
• final_cleanup — final cleanup / polish pass, including the T1 cleanup model step
• paused — gated by scheduler policy, battery, CPU pressure, or user choice
• failed — terminal or retry-needed error state with a user-readable reason

Core scope:

• define a canonical per-connection memory sync status model in Rust instead of leaving progress implicit across multiple subsystems
• expose a controller/RPC surface for:
  • listing supported syncable connections
  • getting per-connection sync settings
  • enabling/disabling memory sync per connection
  • reading live and recent sync status/counters/progress
• extend eventing/state so the frontend can distinguish pipeline phases, not just a generic sync request or ingestion start/end
• connect provider-level sync state (src/openhuman/composio/providers/sync_state.rs), memory ingestion, tree summarization, and scheduler gating into one user-facing status contract
• include explicit reporting for deferred work caused by scheduler_gate so users understand when tree/compression work is intentionally waiting

Frontend scope:

• extend the Memory UI beyond the current broad workspace/debug shape in app/src/components/intelligence/MemoryWorkspace.tsx
• add a dedicated section/card/list for syncable connections
• render phase-specific progress UI, item counts, bytes or document counts where available, and last-sync metadata
• make it obvious which work is immediate download work versus slower background memory processing
• surface errors, paused states, and retry actions cleanly

Implementation note:

• this should not become another frontend-only inference layer. The app should render a core-authored sync status model rather than reconstructing pipeline state from scattered RPC calls or heuristics.

Acceptance criteria

• The Memory UI shows all connections/providers currently supported for syncing into memory.

• Users can enable or disable memory sync per connection.

• Each connection shows a clear current state, including at least idle, downloading, compressing, tree_building, final_cleanup, paused, and failed.

• Each connection shows user-facing progress information, including synced amount and pending/active work where measurable.

• The UI includes a progress bar plus supporting text/counters for active sync work.

• The UI distinguishes immediate ingest/download work from deferred background memory work.

• The core exposes a canonical RPC/controller contract for per-connection memory sync status and settings.

• Scheduler-gated/deferred work is visible to the user instead of appearing as a silent stall.

• Sync status survives app restarts and reflects persisted state where appropriate.

• Errors and retry-needed states are surfaced with enough detail for the user to act.

• The same memory sync controls/status are reachable from the primary Memory flow and Settings.

• Tests cover the core status model, RPC surface, and app rendering/state transitions.

• Diff coverage ≥ 80% — the implementing PR meets the changed-lines coverage gate (Vitest + cargo-llvm-cov, enforced by .github/workflows/coverage.yml).

• The feature is documented so the per-connection memory pipeline and its visible states are understandable to contributors and users.

Related

• app/src/components/intelligence/MemoryWorkspace.tsx
• app/src/components/settings/panels/MemoryDataPanel.tsx
• app/src/store/providerSurfaceSlice.ts
• app/src/services/api/providerSurfacesApi.ts
• src/core/event_bus/events.rs
• src/openhuman/composio/providers/sync_state.rs
• src/openhuman/scheduler_gate/**
• docs/memory-sync-functions.md