Summary

Context progress indicators in the app (onboarding / profile / “how complete is my context” UIs) do not advance reliably after every chat or agent turn, so the user sees a bar that lags the real system state. We should re-fetch the latest user / onboarding / context state from the backend (via core) after each relevant turn (or on a clear cadence) and bind the progress UI to that source of truth.

Problem

• Stale UI: Progress is driven by local assumptions or a one-time load, so when the user (or the welcome agent) completes a step, the bars and percentages do not update until a full remount or manual navigation.
• Duplicated mental model: Users already see outcomes in Conversations; the progress strip should stay in sync with what the server knows (same state the agent uses via tools like check_onboarding_status in the core: src/openhuman/tools/impl/agent/check_onboarding_status.rs).

Observed in product checklist: “Context progress bars don’t update after every turn.”

Constraints

• Single source of truth: Avoid inferring “done” only from the client; prefer authoritative fields from the backend (or the same core snapshot the agent uses).
• No excessive churn: Batching, debounce, or “refetch on turn complete” (not on every token) is fine if called out in implementation notes.

Solution (proposed)

1. Define the payload the UI needs: e.g. onboarding / profile / “context” completion fields (or a compact progress DTO) returned by the backend, exposed to the app through existing openhuman.* / auth paths or a new narrow RPC.
2. On turn boundary: After a user message is sent and the agent reply completes (or when the turn is finalized in ChatRuntimeProvider / chatService), call userApi.getMe() (today: openhuman.auth_get_me → app/src/services/api/userApi.ts) and/or a dedicated “context progress” endpoint if User is insufficient.
3. Wire progress components to that refreshed state. Example area with a client-side bar: app/src/pages/onboarding/steps/ContextGatheringStep.tsx (stage progress is local today — this issue may extend to rehydrate from server or align with a global snapshot).
4. Core alignment: Reuse or mirror the same data as check_onboarding_status / compute_state in onboarding_status.rs so the UI and the agent do not disagree.

Acceptance criteria

• After an agent turn that can change “context” completion, the progress UI updates to match server state without a full app reload.
• Authoritative — The bar reflects data from a server update (HTTP/core RPC), not only client heuristics.
• No regression to chat latency — refetch is async and does not block message rendering; failures degrade gracefully (optional toast / retry).
• Tests — At least one unit or integration test: e.g. mock getMe (or the chosen endpoint) and assert the progress component updates when the handoff event fires.
• Docs — If a new RPC or new User fields are added, note in agent/onboarding docs so backend and app stay aligned.

Related (code map)

• app/src/services/api/userApi.ts — getMe / onboardingComplete today; likely extension point.
• app/src/providers/CoreStateProvider.tsx — snapshot / onboarding task shape (merge strategy when server returns fresh data).
• app/src/pages/onboarding/steps/ContextGatheringStep.tsx — progress bar from local stageStatuses.
• Core: src/openhuman/tools/impl/agent/check_onboarding_status.rs + onboarding_status.rs — canonical state computation for the agent.