Narrow workflow selector: implementation and live tests

The selector chooses a destination in front of the existing workflows. It does not classify consent, validate generated answers or replace qualification/send handlers. Implemented locally and opt-in; not deployed.

Results

Same 23 case definitions and live model/source services. Candidate confirmation run used concurrency 3; baseline used 2. The initial candidate run was exploratory and included in-development changes; this report uses the later frozen confirmation run only. Baseline selector-off behavior was unaffected by the selector adjustments. Raw judge verdicts are preserved. Single-run generative results are not statistically conclusive, and this is a targeted subset rather than a new 228-case full UAT.

What is verified

• Entry routing: tickets, SPEX, agenda, and generic information; ambiguous decisions fall back to existing behavior.
• Active-flow short replies (yes, email, quantity) bypass Jev entirely. Other turns use the narrower continue/switch/side-question decision.
• Explicit workflow switching and information side questions preserve the right session state.
• Live ticket → venue question → resume tickets → cancel sequence passed. Disabled baseline instead asked for contact details when asked the venue.
• The original LATEST-SPEX-LOOP and LATEST-SPEX-CANCEL both passed; loop failed in this disabled-baseline sample.
• Durable session checks verified separate chat IDs, event isolation, and clearing one session without affecting another. Checks ran in separate processes using the configured session store.
• Post-handoff state inspection: W04 cancellation and W07/W08/W10 accepted handoffs cleared active workflow; FEEDBACK-F13 rejected HTTP 503 delivery retained tickets for retry.
• Streaming remains enabled and the latest streaming control passes. No response validation or buffering was added by Jev.
• 150 owning web tests pass; Biome passes; zero new TypeScript diagnostics against the existing baseline. Unrelated Inwink sync changes were left untouched.

Remaining failures are not repaired by destination routing

• W02: natural sponsorship confirmation follows a correct summary but does not dispatch; both variants fail. The existing confirmation/handler path still needs work.
• W03: candidate sends exactly one correct Spex UNW lead but skips the required pre-send summary. Baseline exhibits the same omission, judged partial rather than fail. Selecting SPEX does not repair its internal confirmation behavior.
• W06: the existing agenda-email guard asks for an email already in the profile, then fails to submit. Baseline also captures no agenda email, with a partial verdict. The loose email-follow-up check and profile reuse are existing workflow defects.
• REGRESSION-R06: both variants return the map link instead of the test’s prescribed unpublished-floorplan fallback. Review this expectation against maintained content. Candidate also showed a duplicate-message warning on the sign-off: a pre-classifier abuse/harness interaction requiring separate review.
• W01 partial: correct single sponsorship handoff, but the pre-send summary remains insufficient.

These findings justify keeping the selector behind its flag. The new stateful routing improved the targeted pass count, but did not eliminate end-to-end workflow failures.

Per-case comparison

Transport timings (descriptive, not a speedup claim)

candidate LATEST-STREAM transport chunks: 658. candidate webhook attempts: Counter({200: 8, 503: 1}). HTTP 503 is a rejected attempt, not a delivered enquiry.

baseline LATEST-STREAM transport chunks: 372. baseline webhook attempts: Counter({200: 7, 503: 1}). HTTP 503 is a rejected attempt, not a delivered enquiry.

No real inbox/CRM delivery was attempted. Local API tests do not establish browser paint timing or widget lifecycle correctness. Live content and model/judge variation affect comparisons.

Candidate transcripts · Baseline transcripts · Routing probes · Session evidence · Configuration and storage