fix(ux+voice): KI-252 — align profile bar with Path B 7-slot ready gate + RULE 4 implicit confirmation + ZCR scaling

Root-cause of "70% DONE despite all data" + "Let me pause for a second":

1. Profile completeness bar mismatch (Q2 from user screenshot 59):
- scorecard.py:profile_completeness checked 9 weighted fields:
age 20% + dependents 15% + budget_band 15% + existing_cover_inr 10%
+ primary_goal 10% + location_tier 10% + health_conditions 10%
+ income_band 5% + parents_age_max 5% = 100%.
- Path B's _REQUIRED_FOR_READY = (name, age, dependents, location_tier,
income_band, primary_goal, health_conditions) — 7 slots.
- So a fully captured Path B profile (Priya) shows only 70%:
age (20) + dependents (15) + primary_goal (10) + location_tier (10)
+ health_conditions (10) + income_band (5) = 70%. The 30% gap is
budget_band/existing_cover_inr/parents_age_max that Path B doesn't
gather (intentionally — budget can be inferred from income).
- FIX: re-weighted scorecard.profile_completeness to the 7 Path B slots:
age 20% + dependents 17% + income_band 16% + primary_goal 15% +
location_tier 14% + health_conditions 13% + name 5% = 100%.
- main.py:profile_completeness_view now includes "name" in profile_dict
(was omitted; new key matches the scorecard).

2. RULE 4 wait-for-confirmation too rigid (Q1 from user screenshot 58):
- "Let me pause for a second — could you tell me a bit more..." was
Gemini's OWN polite-stalling output (not our fallback — grep'd code).
- Welcome-back recap asked "Has anything changed?". When user replied
with NEW slots ("18L income, first family policy, no medical issues")
instead of literal "yes", RULE 4's "WAIT for explicit confirmation"
made Gemini hesitate — it didn't treat data-provision as confirmation.
- FIX: added "IMPLICIT CONFIRMATION" subsection to RULE 4 telling Gemini
that providing new fields counts as both (a) confirming the recap +
(b) supplying data. Once 7 slots captured, immediately retrieve.

3. Carryover fixes from U2 + U3 agents:
- voice_resilience.ts scaleSpeechZcrBand formula was inverted —
at fixed fftSize=2048, lower sample rate = longer buffer = MORE ZC.
Confirmed via Kedem 1986 / WebRTC VAD literature. Inverted formula
to REFERENCE_SAMPLE_RATE / actualSampleRate. 16kHz now gets ~60..750
band (3× 48kHz's 20..250). Practical: barge-in works on older
Android / Bluetooth devices.
- voice_resilience.ts retryPostTranscribe docblock corrected from
"1s/2s/4s, max 7s" to accurate "1s+2s, ~3s pre-attempt waits".
- single_brain.py RULE 1 gained gender no-op note (don't waste
iterations calling save_profile_field for gender).
- admin.py: ADMIN_IP_ALLOWLIST env unset on HF Space; TODO comment
added in _check_admin (no logic change, password-gated remains).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

backend/admin.py

@@ -72,6 +72,12 @@ def _check_admin(request: Request, password: Optional[str]) -> None:
     function no longer inspects the client IP. Earlier dual-gate behavior
     (IP allowlist + 404-to-hide-existence) was removed in KI-097.
     """
+    # TODO: enforce IP allowlist for hardening — verified 2026-05-15 that
+    # ADMIN_IP_ALLOWLIST is not configured on the HF Space (rohitsar567/
+    # InsuranceBot). Gate is password-only, which is acceptable for the
+    # current threat model per KI-097, but a future hardening pass should
+    # re-introduce an IP allowlist as a second factor (with a documented
+    # break-glass procedure so a network change doesn't lock ops out).
     if not _password_ok(password):
         raise HTTPException(status_code=401, detail="Unauthorized")
 

backend/main.py

@@ -1429,6 +1429,7 @@ async def profile_completeness_view(session_id: Optional[str] = None):
     sess = get_session(session_id)
     p = sess.profile
     profile_dict = {
+        "name": p.name,  # KI-252 — Path B 7-slot alignment with completeness bar
         "age": p.age, "dependents": p.dependents, "income_band": p.income_band,
         "existing_cover_inr": p.existing_cover_inr, "primary_goal": p.primary_goal,
         "location_tier": p.location_tier, "parents_to_insure": p.parents_to_insure,

backend/scorecard.py

@@ -597,6 +597,18 @@ def _profile_tuned_weights(profile: Optional[dict]) -> dict[str, float]:
 def profile_completeness(profile: Optional[dict]) -> float:
     """0.0–1.0 measure of how much we know about the buyer.
 
+    KI-252 (2026-05-15): aligned with Path B's `_REQUIRED_FOR_READY` 7-slot
+    list (see brain_tools.py + single_brain.py). Previously this checked 9
+    weighted fields including budget_band / existing_cover_inr /
+    parents_age_max which Path B doesn't gather, causing the UI bar to read
+    70% while Path B already considered the profile "ready to recommend".
+
+    The 7 slots: name, age, dependents, location_tier, income_band,
+    primary_goal, health_conditions. `name` is the identifier; the other 6
+    are decision-critical for retrieval. Existing-cover and budget-band are
+    captured opportunistically (Rajesh provided existing_cover_inr in turn 1)
+    but are NOT required to recommend.
+
     Used by the frontend to GATE the personalized scorecard view — until
     completeness >= 0.6, we show insurer-level metrics (CSR, complaints —
     universal) but suppress the per-user grade since it's meaningless without
@@ -604,18 +616,15 @@ def profile_completeness(profile: Optional[dict]) -> float:
     """
     if not profile:
         return 0.0
-    # Weighted by signal importance: age + dependents + budget are core; goal
-    # + conditions + location are deep-dives that further refine.
+    # Weights align with Path B _REQUIRED_FOR_READY. Sum = 1.0.
     weights = {
         "age": 0.20,
-        "dependents": 0.15,
-        "budget_band": 0.15,
-        "existing_cover_inr": 0.10,
-        "primary_goal": 0.10,
-        "location_tier": 0.10,
-        "health_conditions": 0.10,
-        "income_band": 0.05,
-        "parents_age_max": 0.05,
+        "dependents": 0.17,
+        "income_band": 0.16,
+        "primary_goal": 0.15,
+        "location_tier": 0.14,
+        "health_conditions": 0.13,
+        "name": 0.05,
     }
     total = 0.0
     for field_name, weight in weights.items():

backend/single_brain.py

@@ -124,6 +124,11 @@ of these facts and call save_profile_field ONCE PER FACT:
         ← MANDATORY even though it's a negation. "none" tells the system the slot is captured.
         Without this call the profile stays incomplete forever and the bot loops asking for PED.
 
+NOT-ON-PROFILE FIELDS (do NOT call save_profile_field for these):
+  • gender — the system does NOT track gender. save_profile_field will reject it
+    with field_not_on_profile_dataclass and waste a tool-call iteration. Just
+    remember it for conversational context and continue.
+
 Worked example A. User says: "Hi I'm Priya, 34, Bangalore, with husband and one kid"
   → You MUST call:
        save_profile_field(field="name",            value="Priya")
@@ -175,8 +180,21 @@ reply MUST:
      dependents, primary_goal, health_conditions).
   3. Ask: "Has anything changed since last time, or should we go with this
      profile?"
-  4. WAIT for explicit user confirmation BEFORE calling retrieve_policies.
-Do NOT skip the confirmation step even if all 7 slots look complete.
+
+IMPLICIT CONFIRMATION (KI-252 — DO NOT MISS THIS):
+If the user's NEXT message provides ANY new profile fields (e.g. "Around
+18 lakh income, no medical issues, first family policy"), that counts as
+BOTH (a) implicit confirmation of the recap AND (b) provision of the new
+fields. Your flow on that turn:
+  i.   Call save_profile_field once per new slot the user mentioned.
+  ii.  IF all 7 required slots are now captured: IMMEDIATELY call
+       retrieve_policies and produce recommendations. DO NOT ask "are you
+       sure?" again — the user already confirmed by providing data.
+  iii. IF some slots are still missing: ask for the next missing slot
+       only, do NOT re-confirm what they just provided.
+
+Explicit confirmation is only required when the user's reply is a literal
+"yes/no/that's right" with no new data. Bypass the WAIT in any other case.
 
 ═══════════════════════════════════════════════════════════
 RULE 5 — Comparison view ("compare #1 and #3")

frontend/src/lib/voice_resilience.ts

@@ -53,8 +53,11 @@ export interface RetryOptions {
 
 /**
  * Wraps an async transcribe call with up to `maxAttempts` retries on
- * network errors. Backs off 1s → 2s → 4s. Aborts propagate immediately
- * (we don't retry a user-initiated abort).
+ * network errors. With defaults (maxAttempts=3, baseDelayMs=1000) the
+ * loop performs 3 attempts separated by exponential pre-attempt delays
+ * of 1s then 2s — max ~3s of additional wait across the run. (Delays
+ * sit BETWEEN attempts; no delay follows the final attempt.) Aborts
+ * propagate immediately (we don't retry a user-initiated abort).
  *
  * The caller passes a thunk that performs the actual POST. The thunk MUST
  * accept its own AbortSignal so each attempt can be individually timed
@@ -117,8 +120,14 @@ export async function retryPostTranscribe<T>(
 // ---------------------------------------------------------------------------
 // V1.3 — sample-rate-aware ZCR band.
 // The original VAD assumes fftSize=2048 @ 48 kHz, where speech ZCR sits in
-// ~20..250 zero crossings per buffer. At 16 kHz the same 2048-sample window
-// covers 3x as long in time → ZCR counts scale by sampleRate/48000.
+// ~20..250 zero crossings per 2048-sample buffer. At a fixed fftSize the
+// buffer's TIME duration = fftSize / sampleRate, so a 16 kHz buffer covers
+// 128 ms (vs 48 kHz's 42.7 ms — 3× longer). Speech ZCR per SECOND is roughly
+// constant for a given phoneme class (cf. Kedem 1986 "Spectral analysis and
+// discrimination by zero-crossings"; Bachu et al. "Separation of Voiced and
+// Unvoiced using Zero Crossing Rate"; WebRTC VAD per-rate feature tuning),
+// so a longer-duration window observes MORE crossings, not fewer. Net: the
+// per-buffer count scales INVERSELY with sampleRate (ratio = 48000 / actual).
 //
 // We expose a helper so the hook can compute the band at AudioContext init.
 // ---------------------------------------------------------------------------
@@ -130,12 +139,10 @@ export function scaleSpeechZcrBand(actualSampleRate: number): { min: number; max
   if (!actualSampleRate || actualSampleRate <= 0) {
     return { min: REFERENCE_ZCR_MIN, max: REFERENCE_ZCR_MAX };
   }
-  // ZCR scales linearly with the time-window length per buffer at fixed
-  // fftSize, which scales inversely with sampleRate. So a SHORTER window
-  // (higher rate) sees PROPORTIONALLY fewer crossings — but the per-second
-  // speech crossing rate is roughly constant. Net: the per-buffer count
-  // scales linearly with sampleRate.
-  const ratio = actualSampleRate / REFERENCE_SAMPLE_RATE;
+  // Per-buffer ZCR = ZCR_per_second * (fftSize / sampleRate). With fftSize
+  // fixed, per-buffer count scales as 1/sampleRate. So at 16 kHz we expect
+  // ~3× the crossings seen at 48 kHz for the same speech signal.
+  const ratio = REFERENCE_SAMPLE_RATE / actualSampleRate;
   return {
     min: Math.max(1, Math.round(REFERENCE_ZCR_MIN * ratio)),
     max: Math.max(REFERENCE_ZCR_MIN + 1, Math.round(REFERENCE_ZCR_MAX * ratio)),