Skip to content

feat: S5 onboarding scan-progress ring#72

Merged
EyalDelarea merged 3 commits into
mainfrom
feat/s5-onboarding-scan
Jun 12, 2026
Merged

feat: S5 onboarding scan-progress ring#72
EyalDelarea merged 3 commits into
mainfrom
feat/s5-onboarding-scan

Conversation

@EyalDelarea

Copy link
Copy Markdown
Owner

S5 · Onboarding scan-progress ring

The last open roadmap slice (#55, epic #50) — the design's §1 step-2 "scanning your chats" ring shown after the WhatsApp link connects.

What changed (bottom-up)

  • collectorTenantSessionRegistry.wire() now re-emits history-progress with the tenant prepended, the same way it already attributes message/qr/connected. This is the per-tenant progress feed.
  • webGET /api/onboarding/progress: an SSE stream that forwards the tenant's history-sync progress as progress frames and ends with a done frame at 100. Scoped to the requesting tenant only (mirrors the QR stream's isolation); null progress (older syncs) keeps the stream open rather than ending early.
  • ui — after connected, the QR is replaced by a circular progress ring fed by /api/onboarding/progress; the app loads once the sync completes. A 90s safety timeout reloads anyway if the server never reports 100, so onboarding can't get stuck here.

Scope note

This flow is multi-tenant-only — single-user mode has no login/onboarding pane, so the registry-backed onboarding routes aren't mounted. The whole feature only runs under MULTI_TENANT=true.

Verification

  • Backend is unit-tested and CI-green: registry forwards history-progress with tenant attribution + isolation; the progress SSE streams progressdone, ignores other tenants, and stays open on null progress. Full suite 1320 passed.
  • UI ring can not be Playwright-verified in single-user serve mode — it requires a live multi-tenant WhatsApp link + an in-flight history sync, which the serve-only harness (no collector) deliberately can't produce. The ring is driven entirely by the unit-tested SSE contract above; flagging the verification limitation honestly rather than claiming a screenshot I can't produce.

Gate

biome check · tsc --noEmit · build · vitest — all green (1320 passed).

Closes #55.

🤖 Generated with Claude Code

EyalDelarea and others added 3 commits June 12, 2026 03:07
The registry re-emits session events with the tenant prepended (message/qr/
connected/…). Add history-progress to that set so the web onboarding flow can
attribute WhatsApp's history-sync progress (0–100) to the requesting tenant —
the feed for S5's onboarding scan-% ring.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add GET /api/onboarding/progress — an SSE stream that forwards the tenant's
history-sync progress as `progress` frames and ends with a `done` frame at 100.
Scoped to the requesting tenant only (mirrors the QR stream's isolation). Null
progress (older syncs) keeps the stream open rather than ending early.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
After the WhatsApp link connects, WhatsApp streams the chat history. Replace
the QR with a circular progress ring fed by /api/onboarding/progress, then load
the app once the sync completes. A 90s safety timeout reloads anyway if the
server never reports 100, so onboarding can't get stuck on this screen.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@EyalDelarea EyalDelarea merged commit dbbd836 into main Jun 12, 2026
5 checks passed
@EyalDelarea EyalDelarea deleted the feat/s5-onboarding-scan branch June 12, 2026 00:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

S5 · Prefs + onboarding polish

1 participant