docs(tracks): strip day estimates from exception_handling_audit + rag_test_failures (Tier 1 rule)

conductor/tracks/rag_test_failures_20260615/spec.md

@@ -5,7 +5,7 @@
 **Priority:** A (foundational; precedes `data_structure_strengthening_20260606` and the user's planned `send_result` → `send` mass rename)
 **Owner:** Tier 2 Tech Lead
 **Type:** bugfix + test_fix
-**Estimated effort:** 0.5-1 day Tier 2 work (4-8 hours)
+**Scope:** 3 test failures (tier-3 live_gui RAG tests) + 1 production bug in 2 lines + 3 new unit tests
 **Parent tracks:** `data_oriented_error_handling_20260606` (shipped 2026-06-12), `ai_loop_regressions_20260614` (shipped 2026-06-15), `doeh_test_thinking_cleanup_20260615` (shipped 2026-06-15), `public_api_migration_and_ui_polish_20260615` (shipped 2026-06-15)
 
 ---
@@ -263,11 +263,11 @@ If the implementer can't find the bug from the error message alone:
 
 This is a small bug-fix track. The phases are simple:
 
-1. **Phase 1: Investigation + reproducing test (1-2 hours)**
-2. **Phase 2: Fix (1-3 hours)**
-3. **Phase 3: Full test suite + batched verification (30 min)**
-4. **Phase 4: Docs update (15 min)**
-5. **Phase 5: Metadata + tracks.md (15 min)**
+1. **Phase 1: Investigation + reproducing test**
+2. **Phase 2: Fix**
+3. **Phase 3: Full test suite + batched verification**
+4. **Phase 4: Docs update**
+5. **Phase 5: Metadata + tracks.md**
 
 The order doesn't matter much (it's all one fix); the implementer can iterate between Phase 1 and 2 as needed.
 
@@ -302,7 +302,7 @@ The order doesn't matter much (it's all one fix); the implementer can iterate be
 | **R2** | The bug is in a hard-to-reach code path (deep in IO pool worker) | Medium | Medium | Add diagnostic traceback in the except clause; capture the actual error site; document in the commit message. |
 | **R3** | The fix is in the test (subprocess state pollution) not the production code | Low | Low | If the fix is in the test, document this in the commit message. Consider adding a teardown reset in the test. |
 | **R4** | The fix introduces a regression in `test_rag_engine_ready_status_bug.py` | Low | Medium | Run the full RAG test suite after the fix. |
-| **R5** | The implementation takes longer than estimated (1 day) | Low | Low | This is a 0.5-1 day track; even 2 days is acceptable. The user's overall plan is to do 2 more tracks (this + a `send_result` → `send` rename) before the data structure track. |
+| **R5** | The implementation is larger than the 2-line fix suggested by the spec | Low | Low | The spec is a guide, not a contract. If the fix is larger (e.g., a larger refactor is needed), the Tier 2 reports and the user decides whether to expand scope. The user's overall plan is 2 more tracks (this + a `send_result` → `send` rename) before the data structure track. |
 
 ---
 
@@ -331,13 +331,13 @@ The track is DONE when **ALL** of the following are true:
 **No external blockers.** This track can start immediately after the Tier 1 review approves the spec.
 
 **Execution order (the plan):**
-1. Phase 1: Investigation + reproducing test (1-2 hours)
-2. Phase 2: Fix (1-3 hours)
-3. Phase 3: Full test suite + batched verification (30 min)
-4. Phase 4: Docs update (15 min)
-5. Phase 5: Metadata + tracks.md (15 min)
+1. Phase 1: Investigation + reproducing test
+2. Phase 2: Fix
+3. Phase 3: Full test suite + batched verification
+4. Phase 4: Docs update
+5. Phase 5: Metadata + tracks.md
 
-**Total:** 0.5-1 day Tier 2 work (4-8 hours)
+**Total:** 5 phases, ~10 tasks, 4 atomic commits (1 fix + 1 docs + 1 metadata + 1 final-state); all with git notes.
 
 **Followed by:** the user can do the `send_result` → `send` mass rename themselves, then start `data_structure_strengthening_20260606` track.