📖About

Carols request classifier (5-min cron) re-asks the model about the same conversation forever: a parse failure writes NOTHING to the row, and an unsure verdict keeps the row in the pick list, so unchanged conversations are re-classified every 5 minutes indefinitely. Fix: every attempt is recorded on the row (count, outcome, error, time, content hash); after 3 attempts on unchanged content the row leaves the pick list in a visible terminal state (unclassifiable / no-content); NEW conversation content re-admits it; the run summary reports failed and skipped counts, not just classified.

⚖️Decisions

• Elrond's bypass methodology checklist (a reminder, not a gate -- you've got this): 0. File it requested_mode='bypass' (planner-vs-bypass is a deliberate choice). bypass_start REFUSES a non-bypass initiative (CAROL-INI-1846), and the dispatcher only skips the bypass lane when the mode says bypass -- a 'planner' mistag lets Merlin's pipeline grab the placeholder step and block your finished work. 1. Filed as planned status -- let the bypass claim/activate it; never file active. 2. Open the bypass (bypass_start) with your droid id + the remediation answer (remediates_initiative_id=NNN, or remediates_nothing=True). 3. Work the blocks for your work-type: template -> design -> code -> test -> review. Do the real work; record decisions on the initiative as you make them. 4. Reality is recorded for you at close -- code (files changed), each decision, and the twin-review verdict become real activities tied to this initiative and show in the Activity Tracker like a planner run (CAROL-INI-1840). No dummy rows. 5. Keep the initiative status moving; it parks in 'reviewing' and is tagged uat-pending for you at close (CAROL-INI-1836), so the stuck-watchdog leaves it alone until UAT. 6. Close runs the gates (design/architecture compliance + caller-audit). If a gate flags something pre-existing or unrelated to your change, waive it with a clear written rationale -- audit, don't skip. 7. Bypass skips the planner's auto-orchestration, NOT the standards. Same template checklist, same review, same observability as a planner run. (elrond)
• [status-router] planned -> executing | event=bypass_executing | bypass transition (or-bx-01)
• An unsure verdict stands until the conversation changes; only failures earn retries — Re-asking the model the identical question yields the identical answer at full price - the Aug-5 leak shape. A well-formed unsure IS an answer; a parse failure or exception is not, so those retry up to 3 times before the row ends visibly as unclassifiable. No row is deleted - terminal states stay auditable in the inbox. (orion)
• [status-router] executing -> reviewing | event=bypass_reviewing | bypass transition (or-bx-01)
• [status-router] reviewing -> closed | event=operator_signoff | Auto-accepted (CAROL-INI-1859): Orion-initiated, >2 days in reviewing with no objection. (el-srac-01)

✅Success criteria

• Every classification attempt is recorded on the request row - count, outcome, error, time and content hash; a silent parse failure no longer exists (must_have)
• A row that failed 3 attempts on unchanged content leaves the 5-minute pick list in a visible terminal state, and new conversation content re-admits it (must_have)
• A row with no conversation text is closed as no-content after 3 dry passes and is never billed a model call (must_have)
• The run summary reports classified, unsure, failed and skipped counts - results, not just execution (must_have)
• A regression test proves the cap, the re-admit on new content, and that the nine stranded Aug-2 test rows leave the queue, with the model call replaced (must_have)