fix(vapi): bisect round 3 — baseline minimum assistant config

[ByteStreams-AI]

Refs #32

Greptile Summary

This is round-3 of an ongoing bisect (Issue #32) to isolate why Vapi keeps returning "Couldn't get assistant." It strips handleAssistantRequest down to the documented minimum — a fixed firstMessage, a generic GPT-4o-mini system prompt, and a hardcoded Rachel voice — while keeping the voice_calls upsert and restaurant lookup intact so dependent integration tests retain their expected DB state.

• vapi_call_start/index.ts: removes all dynamic prompt/tool/customer-lookup logic from the assistant-request handler and returns a hardcoded stub; voiceForRestaurant and TRANSCRIBER_CONFIG are kept but suppressed with eslint-disable no-unused-vars for the revert.
• voice.test.ts: the Sui's-Sushi-specific assistant-request test is skipped with a clear comment; all other tests (tool-calls, end-of-call-report, get_menu, etc.) remain active.

Confidence Score: 4/5

Safe to merge as a temporary debug stub — the change is intentionally narrow and well-documented, and the revert path is explicit in the code and PR description.

The void vapiShape discard is the only non-obvious change: legacy internal-format callers now receive a Vapi-shaped response instead of the internal { status, first_message, prompt, tools } shape. No integration tests exercise that path directly, so the breakage is invisible to CI.

supabase/functions/vapi_call_start/index.ts — specifically the void vapiShape line and the silent collapse of both code paths into the same stub response

Important Files Changed

Filename	Overview
supabase/functions/vapi_call_start/index.ts	Replaces the full dynamic assistant config with a hardcoded bare-minimum stub (fixed firstMessage, generic system prompt, hardcoded Rachel voice, no tools, no transcriber) while preserving the voice_calls upsert; vapiShape parameter is silently discarded, making both legacy and Vapi callers receive the Vapi-shaped response
packages/shared/test/db/voice.test.ts	Skips the Sui's-Sushi-specific assistant-request test with a clear comment explaining the stub mismatch; all other integration tests remain active and should still pass against the stub because startCall() checks only for assistant.firstMessage presence

_{Reviews (1): Last reviewed commit: "fix(vapi): bisect round 3 — minimum base..." | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.

[greptile-apps]

vapiShape=false path silently returns Vapi shape

void vapiShape discards the parameter and the function now always returns the Vapi-shaped stub regardless of whether the caller used the legacy internal format (top-level call_id/caller_phone/destination_phone). Any caller that previously received { status: 'ok', first_message, prompt, tools, context } will now receive { assistant: { firstMessage: ... } }. None of the current integration tests exercise the legacy path directly (they all go through startCall() which uses the Vapi envelope), so the breakage is invisible to CI — but any curl probe or script relying on the internal format will silently get the wrong shape back.