Fuel & range tracking, voice enrollment (d-vector), EAS build profiles, API contracts.
Date: 2026-06-10 Commits: 164cb21, d47f8be, f091fe6, c4af095, d3a15c5, ac7b763, e51d7bc, 795730c, 0522300, d2e2b3a, 8a5ffb5, 2a313ff, f730fd4, b07a60f, 3af5f92, 66523e3, 04d8573, cd00662, plus the meeting-report commits (bb6cf3d, 97dab61, 4b53d26, 6c543f4) Theme: Add the first genuinely *car* features - fuel/range and per-driver voice enrollment - wire the launcher to real services, and stand up the build pipeline to ship to TestFlight.
Reports 01–04 built a general voice assistant with an app. This session made it a *car* product: it knows your range, it learns your voice, and it can be built and submitted to the App Store.
164cb21, d47f8be)What. EAS Build profiles (development / preview / production) in eas.json, the EAS project link, and the iOS URL schemes / Info.plist entries the app needs (calendar, contacts, music, audiobook, maps).
Why. Up to now the app only ran in Expo Go / dev. To reach real devices and TestFlight it needs signed native builds and declared capabilities (deep-link schemes, permission strings).
How. Three EAS profiles for the dev→preview→production ladder; the EAS project registered as @selimfedakar/excar (ID 77ebd1b1-4d0a-4c3d-88c5-f40bc8d14495); URL schemes added so the launcher can open external apps and the OS knows EXCAR's intents.
Purpose / goal. Turn the project into something installable and submittable - the prerequisite for TestFlight (the goal of Session 7).
f091fe6)What. Replaced the single "Spotify sphere" with multi-platform Music and Audiobook sheets (Spotify / Apple Music / YT Music; Audible / Storytel / Libby).
Why. Hard-coding one provider alienates everyone who uses a different one. The launcher should respect what the driver already has installed.
How. Tapping a sphere opens a sheet; Linking.canOpenURL(scheme) checks if each app is installed and opens it, otherwise redirects to its App Store page. Calendar and Contacts spheres request expo-calendar / expo-contacts permission on tap and deep-link to Settings if denied.
Purpose / goal. A launcher that adapts to the driver's ecosystem instead of dictating it.
c4af095, e51d7bc, 0522300, d2e2b3a,8a5ffb5, 2a313ff)
What. End-to-end fuel/range: a device endpoint computing range, a mobile FuelWidget with a level bar and range display, profile fields for tank capacity and average consumption, and a fuel API client.
Why. Range anxiety is a real driving concern and a natural thing to *ask* a co-pilot ("how far can I go?"). It's also the first feature that reaches toward the vehicle itself (OBD-II).
How. The /fuel endpoint (api/routes/fuel.py) returns range via one of three sources, in preference order:
tank_capacity_l and avg_consumption_l_per_100km on the user profile (0522300).
The mobile FuelWidget (8a5ffb5) shows the level bar and computed range, with a modal to enter tank capacity; the Profile screen gained a Fuel & Range section (2a313ff). api/fuel.ts (e51d7bc) does fetchFuel / patchFuel.
Purpose / goal. The first car-aware capability, designed to degrade gracefully: full accuracy with OBD, useful estimates without it.
d3a15c5, 795730c, f730fd4,b07a60f, 3af5f92, 66523e3)
What. A voice-enrollment flow: the app records 3 voice samples from the phone mic during onboarding; the device extracts a speaker embedding (d-vector) and stores it as the owner's voice profile.
Why. EXCAR needs to know *whose* voice is the driver's - both to personalise and (critically) to ignore passengers. This is the data that powers the diarization gate added in Report 06.
How. The enrollment endpoint (api/routes/enrollment.py, d3a15c5) uses resemblyzer to extract a d-vector (a fixed-length speaker embedding) from the samples and saves it as the voice profile (data/voice_profile.npy). The mobile EnrollmentScreen (f730fd4) records 3 samples via the phone mic and walks the start → record → complete → status API (api/enrollment.ts, 795730c). It was slotted into onboarding after the usage step as step 3/4 (b07a60f, 3af5f92, 66523e3).
Purpose / goal. Establish the owner's voiceprint - the enabling step for "only respond to the driver" (Report 06's diarization).
04d8573, cd00662)What. mobile/docs/ARCHITECTURE.md (full mobile architecture) and mobile/docs/API_CONTRACTS.md (enrollment + fuel contracts).
Why. With two car features and a build pipeline added in one day, the device↔app contract and the app's internal structure needed to be written down so the team stays in sync.
Purpose / goal. Keep the growing surface legible - the same motivation behind this sessions/ journal.
bb6cf3d, 97dab61, 4b53d26, 6c543f4)A Session-4 meeting report (TR/EN) and an Atilla sync message (covering diarization, intent gating, wake word, OBD) were added, then removed once the points were absorbed into the plan. Recorded here so the history reads cleanly: these were transient coordination notes, not deleted features.
EXCAR now tracks fuel/range, knows the owner's voiceprint, opens the driver's own service apps, and has a working EAS build pipeline. Report 06 spends those foundations - using the voiceprint for diarization, adding GPS, Spotify control, barge-in and ducking, and the Pi production config.