feat: interactive device onboarding tutorial

[aaravgarg]

Summary

• Adds a 4-step interactive device tutorial accessible from Settings → Device Tutorial (when device connected)
• Step 0: Real-time transcription demo — user speaks, sees live transcript, "Good job" after 5+ words
• Step 1: Ask a question — single press to enter voice mode, speak question, get AI response
• Step 2: Power cycle — long press to turn off (detects disconnect), press to turn on (detects reconnect)
• Step 3: Double tap config — choose between End Conversation / Mute-Unmute / Star Conversation, try it live
• Intercepts button presses and transcription in CaptureProvider during onboarding
• Suppresses disconnect notification during power cycle step
• Mixpanel analytics for each step and completion
• Non-skippable: PopScope(canPop: false), no back/skip buttons

Test plan

• Connect Omi device → open Settings → verify "Device Tutorial" appears under Device Settings
• Tap "Device Tutorial" → verify 4-step flow launches full-screen
• Step 0: Speak into device → verify live transcript → verify "Good job" after a few words → tap Continue
• Step 1: Press button → verify "Listening" → speak → press again → verify AI response → tap Continue
• Step 2: Long press → verify "Device is off" → press to turn on → verify "Connected" → tap Continue
• Step 3: Select a double-tap action → double-tap device → verify detection → tap Finish
• Verify you're back in settings after finishing
• Verify double-tap preference was saved (test the action)
• Disconnect device → open Settings → verify "Device Tutorial" is hidden

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR adds a 4-step interactive device onboarding tutorial (transcription demo → ask a question → power cycle → double-tap config) accessible from Settings when a device is connected. The overall architecture is solid — DeviceOnboardingProvider cleanly encapsulates step state, the wrapper correctly caches the CaptureProvider reference per earlier review feedback, and all AnimationControllers are properly disposed.

Key findings:

• Future.delayed inside Consumer build body (transcription_demo_step.dart, power_cycle_step.dart): a new timer is created on every rebuild while the condition holds; move the delay into a provider listener in initState.
• Mutable list alias in onTranscriptSegments (device_onboarding_provider.dart): demoSegments = segments risks silent mutations from _processNewSegmentReceived; use List.from(segments).
• onDeviceDisconnected fires before the _manualDisconnect guard (device_provider.dart): swap the two blocks so an app-initiated disconnect doesn't incorrectly advance the power-cycle step.
• live_transcript_display.dart is unused — dead file from an earlier iteration, should be removed.

Confidence Score: 4/5

Safe to merge after addressing the Future.delayed-in-build timer accumulation and the onDeviceDisconnected ordering issue.

Two P1/P2 logic issues remain that should be fixed before shipping to avoid subtle edge-case bugs, but nothing catastrophic.

transcription_demo_step.dart and power_cycle_step.dart (Future.delayed in build), device_provider.dart (onDeviceDisconnected ordering), device_onboarding_provider.dart (list alias)

Important Files Changed

Filename	Overview
app/lib/providers/device_onboarding_provider.dart	New provider coordinating 4-step onboarding state; stores a mutable alias to transcript segments list (P2), otherwise clean logic.
app/lib/providers/device_provider.dart	Hooks disconnect/reconnect events into onboarding provider; onDeviceDisconnected fires before _manualDisconnect guard (P2 ordering issue).
app/lib/pages/onboarding/interactive_device_onboarding/steps/transcription_demo_step.dart	Step 0 implementation; Future.delayed inside Consumer build body creates repeated timers on each rebuild (P1).
app/lib/pages/onboarding/interactive_device_onboarding/steps/power_cycle_step.dart	Step 2 implementation; same Future.delayed-in-build anti-pattern as transcription step for the reconnected state transition.
app/lib/pages/onboarding/interactive_device_onboarding/interactive_device_onboarding_wrapper.dart	Clean wrapper using ChangeNotifierProvider.value + PageView; caches CaptureProvider reference correctly per prior review feedback.
app/lib/providers/capture_provider.dart	Adds onboarding interception for button events and transcript segments; step-1 single-tap fall-through is correct.

Comments Outside Diff (1)

1. app/lib/pages/onboarding/interactive_device_onboarding/steps/transcription_demo_step.dart, line 748-752 (link)

   Future.delayed inside build creates duplicate timers

   Future.delayed is called directly inside the Consumer builder, which means every time the DeviceOnboardingProvider calls notifyListeners() while transcriptionComplete && !_showContinue is true, a new timer is enqueued. Multiple independent timers pile up. Although each is harmless individually (the mounted && setState call is idempotent), the accumulation is wasteful and fragile.

   The same pattern exists in power_cycle_step.dart (line 313–317) for the reconnected state.

   Move the one-shot delay into a provider listener registered in initState so it fires exactly once.

_{Reviews (2): Last reviewed commit: "feat(onboarding): add Omi image with pul..." | Re-trigger Greptile}

[greptile-apps]

context.read<>() called in dispose()

Calling context.read<CaptureProvider>() inside dispose() is discouraged — by the time dispose() runs the element may be deactivating and Provider can emit warnings or throw in debug mode. Cache the reference in initState instead:

late CaptureProvider _captureProvider;

@override
void initState() {
  super.initState();
  _captureProvider = context.read<CaptureProvider>();
  WidgetsBinding.instance.addPostFrameCallback((_) {
    _captureProvider.deviceOnboardingProvider = _onboardingProvider;
    _onboardingProvider.startOnboarding();
    MixpanelManager().deviceOnboardingStarted();
  });
}

@override
void dispose() {
  _captureProvider.deviceOnboardingProvider = null;
  _onboardingProvider.dispose();
  _pageController.dispose();
  super.dispose();
}

[greptile-apps]

Hardcoded string — l10n required

Every other _buildSettingsItem call in this file uses context.l10n.* (e.g. context.l10n.profile, context.l10n.notifications, context.l10n.developerSettings), but 'Device Tutorial' is a bare string literal. Per the project's localization policy all user-facing strings must go through l10n.

The same applies to all titles, subtitles, button labels, and hint texts in the new onboarding files:

• transcription_demo_step.dart — 'Speak Into Your Omi', 'Say a few words...', 'Good job!'
• single_press_step.dart — 'Ask Omi a Question', 'Listening...', 'Processing...', etc.
• power_cycle_step.dart — 'Turn Off & On', 'Hold the button...', 'Device is off!', etc.
• double_press_config_step.dart — 'Customize Double Tap', option titles and descriptions
• onboarding_step_scaffold.dart — 'Continue', 'Finish'

All of these should be extracted into the app's ARB files and referenced via context.l10n.

Context Used: Flutter localization - all user-facing strings mus... (source)

[aaravgarg]

@greptile-apps review