[WIP] Fix critical flaws in JEEVA project plan v6.0

[Copilot]

• Create docs/JEEVA_V6_MASTER_PLAN.md — Complete v6.0 unified plan addressing all 5 critical problems
• Update docs/JEEVA_FUNDED_PROJECT_PLAN.md — Add superseded-by-v6.0 header
• Update docs/JEEVA_MASTER_AUDIT_REPORT.md — Add superseded-by-v6.0 header

Original prompt

Context

This PR addresses 5 critical flaws identified in the JEEVA project plan v5.2/v5.3, and produces a complete rewrite of JEEVA_FUNDED_PROJECT_PLAN.md and JEEVA_MASTER_AUDIT_REPORT.md as a unified v6.0 document.

The builder is a first-year college student with a part-time job working on a ₹10,00,000 funded project to build 16 beta elder-care companion robots. The current plan has fatal contradictions that must be resolved before any code is written.

---

The 5 Critical Problems to Fix

Problem 1: "100% Offline" Hypocrisy

The plan claims "100% offline" as a key differentiator over Pepper, but then relies on:

• Bhashini TTS (online API) for good Tamil speech quality (9/10 vs offline 7.5/10)
• Bhashini ASR (online) for better WER (8% vs offline Whisper 12%)
• Edge TTS (Microsoft cloud) as primary TTS

Fix Required: The plan must be genuinely 100% offline. All AI models (LLM, ASR, TTS) must run locally on the Jetson Orin Nano Super with NO cloud dependency. Online APIs can exist ONLY as optional enhancements when WiFi happens to be available — the product must be fully functional and sound natural with zero internet. Research and specify exact offline models for Tamil + Hindi + English that fit in 8GB shared RAM.

Problem 2: Language Swapping 3-Second Latency Kill

The plan proposes dynamically swapping between Sarvam-2B (Tamil/Hindi) and Llama 3.2 3B (English) based on detected language, admitting "<3 seconds swap time." For code-switching elderly users (mixing Tamil and English mid-sentence), this creates unacceptable conversation pauses.

Fix Required: Find a SINGLE multilingual model that handles Tamil + Hindi + English simultaneously without swapping. If no single model fits in 8GB RAM alongside Whisper + TTS + OpenCV, specify the exact RAM budget and which combination works. The conversation must have <1.5 second total latency (speech-to-response) with NO model swapping pauses.

Problem 3: WebRTC AEC Inside a Resonant PETG Chamber

Software AEC (WebRTC) running on Jetson alongside heavy AI inference will fail when CPU spikes cause audio buffer timing jitter >10ms. The robot's own voice will leak through and Whisper will transcribe it as user input. A 5W speaker centimeters from dual INMP441 mics inside a resonant plastic body is an acoustic nightmare.

Fix Required: Design a solution that doesn't rely on perfect real-time software AEC timing. Options: half-duplex (mute mic while speaking — simplest, most reliable), hardware AEC codec chip, or physical acoustic isolation design. Specify the exact approach with component changes if needed, and explain why it will work under CPU load.

Problem 4: Ethics Committee Approval Reality

An 18-year-old solo student founder asking a hospital ethics board to deploy internet-connected cameras and microphones in elderly patients' bedrooms will face 6-8+ month delays, not the 2-4 months estimated. Without a partnering doctor or professor, IEC approval may never come.

Fix Required: Redesign the beta deployment strategy to avoid requiring full IEC/CTRI approval for the initial validation phase. Options: deploy at non-medical facilities (community centers, day-care centers for elderly, family homes of willing participants), partner with an academic advisor/doctor from the student's college, or restructure the study as a "technology usability study" rather than "clinical trial."

Problem 5: Timeline Hallucination for a Part-Time Student

The plan assumes 42 hours/week of focused work. The builder is a first-year college student with classes and a part-time job — realistically available 15-20 hours/week for the project. The current 10-month timeline includes: ESP-IDF migration, FastAPI migration, JWT auth, Ed25519 OTA signing, Secure Boot v2, LUKS encryption, WebRTC beamforming tuning, and hand-assembling 16 units (160 hours of manual labor alone).

Fix Required:

• Set a realistic timeline based on 15-20 hours/week availability
• "Write the code correctly from the beginning" — choose the right frameworks UPFRONT so there's no migration cost later. If FastAPI is better than Flask, start with FastAPI. If ESP-IDF is needed for production, evaluate whether to start with it or use Arduino with a clean abstraction layer that won't need rewriting.
• Eliminate all migration/rewrite tasks. Every technology choice must be final from Day 1.
• Calculate honest assembly time for 16 units by a single person

---

Additional Deep Analysis Required

Mismatch Detection

Go through the entire plan and find ALL contradictory statements, component mismatches, and logical inconsistencies. Examples to check:

• BOM items referenced in text but missing from budget tables (or vice versa)
• GPIO pin assignments that conflict between different sections
• Power budget numbers that don't add up across sections
• Runtime claims that contradict the power math
• "Already have" items that may not be compatible with the new ESP32-S3 (cur...

This pull request was created from Copilot chat.

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

[Copilot]

Copilot wasn't able to review any files in this pull request.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.