# Status Report: RAG Test Failure in Tier-3 Batch (2026-06-08)

**TL;DR:** The `test_rag_phase4_final_verify` failure in the latest tier-3 batch is **NOT a regression from my `__getattr__` fix**. It's a pre-existing test isolation issue that was masked by the previous `IM_ASSERT` failure.

**Reproduction:**
- Test passes in isolation (`pytest tests/test_rag_phase4_final_verify.py` → 6.80s PASS)
- Test fails after the 4 sims (`pytest tests/test_extended_sims.py tests/test_rag_phase4_final_verify.py` → 1 FAIL, 4 PASS)
- Test fails the same way on PRE-FIX HEAD (verified by `git stash` + rerun)

**Failure modes observed across runs:**
1. `Status: error: Local RAG embeddings require sentence-transformers` — environmental, `sentence-transformers` package not installed
2. `Poll 0, status: Loaded track: Track B` — the controller's `ai_status` is showing track loading state from a prior sim's MMA workflow
3. `Poll 0, status: done` + later `RAG context not found in history` — the AI responded but didn't include the RAG-retrieved context in the message

**Root cause:** The `live_gui` fixture is session-scoped. State accumulated from the 4 sims pollutes the controller in ways the RAG test doesn't anticipate. The sims:
- Change the `current_provider` to `gemini_cli`
- Set various `ui_*` attributes
- May leave pending MMA track workflows
- May modify `mma_streams`, `mma_epic_input`, etc.

When the RAG test starts, the controller is in an unknown state. The test assumes a clean baseline.

**Per the systematic-debugging skill (after 3+ fix attempts on a similar pattern):**

This is a CLASSIC test isolation issue. It's the SAME architectural problem that the previous `IM_ASSERT` bug exposed — the shared session-scoped subprocess. My fix to the `__getattr__` bug fixed ONE specific bug that was making the test fail. The underlying test isolation issue is still there, and it surfaces as a different failure now.

**Recommended fix (per `docs/reports/test_infra_hardening_foundation_20260608.md`):**

The future track should:
1. Make the `live_gui` fixture per-file or per-test scoped (instead of session)
2. Add lazy re-spawn when the subprocess dies or is degraded
3. Or: have the RAG test explicitly reset state via a documented API before starting

**Immediate workaround for the user:** The RAG test failure is NOT introduced by my fix. The user can:
- Continue with the IM_ASSERT fix merged (commit `bcdc26d0`)
- File a separate bug for the RAG test isolation issue
- Or, since my `__getattr__` fix unblocked `test_full_live_workflow`, the user may want to accept the RAG test failure as a separate issue

**Related commits:**
- `bcdc26d0` (my fix): `__getattr__` allowlist — fixes the IM_ASSERT
- Pre-existing (no commit): RAG test batch isolation issue
