MC-4316

# MC-4307: Fix Tessa gate — dead code and infinite loop risk **Priority:** high **Assigned:** luci **Depends on:** MC-4303 (Tessa gate must exist first) ## What to do The QA review found two critical issues with the Tessa gate (mc_tessa_gate.py): **Issue 1 — `act_on_tessa_output` is dead code.** The function exists and is tested but is never called from any production path. When Tessa reports DONE, nothing processes her ISSUES/APPROVED output. **Issue 2 — Potential infinite Tessa dispatch loop.** When Tessa reports DONE: 1. Harvest sets ticket to `done` 2. Shadow reviewer runs → verdict `pass` (reviewing the same code that already passed) 3. `act_on_verdict` → `gate_on_pass` → detects UI → dispatches to Tessa **again** 4. No guard prevents re-dispatching to a ticket that already went through Tessa This could loop until `review_cycles` hits 3, or potentially forever if Tessa's worktree setup produces `sha=None` each time. ## Steps ### Part A: Wire `act_on_tessa_output` into the harvest path 1. Find where Tessa reports DONE in the harvest path (likely `ticket_runtime.py` or `mc_pickup.py`). 2. After the DONE sentinel is detected, check if the ticket has a Tessa verdict in the evidence/comments. 3. If Tessa verdict exists, call `mc_tessa_gate.act_on_tessa_output(ticket_id, tessa_output)`. 4. The function handles ISSUES (bump `review_cycles`, reopen to `todo`) and APPROVED (no-op, ticket stays done). ### Part B: Add a "Tessa already ran" guard 1. In `mc_tessa_gate.gate_on_pass`, before dispatching to Tessa, check if the ticket has already been through Tessa. 2. Detection options (pick one): - Check `tessa_verdict` column (add it if needed — `TEXT`, values: `APPROVED` / `ISSUES` / `UNAVAILABLE`) - Check comments for "Tessa" + "APPROVED" or "ISSUES" markers - Check if `review_cycles > 0` AND the last shadow review was `pass` (implies Tessa already ran and looped back) 3. If Tessa already ran AND verdict was `APPROVED`, do NOT re-dispatch. Proceed to "gate to Elmar" check. 4. If Tessa already ran AND verdict was `ISSUES`, the ticket is already back in `todo` from `act_on_tessa_output`. Do NOT re-dispatch until the worker fixes it and reports done again. ### Part C: Track Tessa verdicts 1. Add a `tessa_verdict` column to the tickets table (or use a separate tracking table if migrations are complex). 2. When `act_on_tessa_output` runs, write the verdict (`APPROVED` / `ISSUES` / `UNAVAILABLE`). 3. Use this for the "already ran" guard in Part B. ### Part D: Test end-to-end 1. Create a dummy UI-touching ticket (tag it `ui` or touch a `.html` file). 2. Let the worker "do" it (dummy commit). 3. Let shadow reviewer pass. 4. Let Tessa gate dispatch. 5. Simulate Tessa APPROVED → verify ticket stays done, no re-dispatch. 6. Simulate Tessa ISSUES → verify ticket reopens, `review_cycles` increments, no infinite loop. 7. Post DB evidence on this ticket. ## Acceptance criteria - `act_on_tessa_output` is called from the harvest path when Tessa reports DONE - "Tessa already ran" guard prevents infinite re-dispatch - `tessa_verdict` is recorded in the ticket evidence - End-to-end test proves: Tessa APPROVED → ticket stays done; Tessa ISSUES → ticket reopens once, not infinitely - No infinite loop when a UI ticket goes through the full cycle ## If blocked - If the harvest path is complex and you can't find where Tessa's DONE is processed, add a comment to the ticket and escalate to Elmar. - If adding `tessa_verdict` column requires a migration and migrations are complex, use a comment-based detection (grep for "Tessa verdict:" in ticket comments). - Test with a real ticket before enabling the flag. If the loop risk is too high, keep `MC_ORCH_TESSA_GATE=0` until the fix is proven. ## What NOT to do - Do not change the shadow reviewer (MC-4301) - Do not change the review loop (MC-4302) - Do not change the operator (MC-4304) - Do not touch the inbox (MC-4305) - Do not enable `MC_ORCH_TESSA_GATE` on live UI tickets until the fix is proven