# 2026-07-27 · TARS · Universal typeahead commit paths (ITW deep-dive)

## Result: 0 submissions. ITW's source_hearing widget cannot be committed in headless Chromium via any mouse or keyboard path we tried. Universal fixes benefit ALL other tenants.

## New universal fixes deployed (playwright_base.py searchBox handler):

1. **Option-set pre-pick** — after preflight opens popup, scrape real options and check if any candidate is an exact/prefix match. If no candidate matches at all, immediately hand real options to LLM (skips wasteful candidate-loop typing that filters popup to zero).

2. **Direct-click fast path** — when candidate is an exact case-insensitive match against a real option, skip type+filter entirely and click the option directly from the unfiltered popup.

3. **Multi-tier commit fallback chain on direct-click**:
   - Playwright `opt_handle.hover() + opt_handle.click(force=True)` (full driver protocol)
   - `page.mouse.click(x, y, delay=50)` at option centroid via CDP
   - JS `.click()` (weakest, kept as last resort)

4. **Commit verification** — checks chip render, popup close + persistent value + no aria-activedescendant. Falls back to Enter/Tab keyboard commit. Falls back to ArrowDown-until-target keyboard-nav.

5. **promptOption preference** — selector prefers `[data-automation-id='promptOption']` over `[role='option']`. Walks up from menuItem to promptOption ancestor (Workday's real click target).

## ITW-specific pathology confirmed via DOM diagnostic:

DOM structure inside the popup:
```
<div aid=activeListContainer role=listbox aria-activedescendant="menuItem-...d4e90000">
  <div class="ReactVirtualized__Grid__innerScrollContainer">
    <div aid=menuItem cls="css-kbbc15">      ← visible container
      <div aid=promptLeafNode cls="css-1hb284">
        <div aid=promptOption cls="css-7b4z4m">  ← our click target
```

Behavior observed:
- Every commit path (Playwright click, CDP mouse.click, JS click, Enter, Tab, ArrowDown+Enter) fires successfully.
- After 60 ArrowDown presses, aria-activedescendant NEVER changes — sees only 1 unique text ("Direct Source").
- Chip never renders. `input.value` stays empty.
- On next walk pass, widget is fully REMOUNTED with different CSS class (`css-1jafa2r` vs `css-1giiucd`) — React tore down + rebuilt with fresh state.

Conclusion: ITW's Workday tenant is bot-detecting via some signal our stealth plugin doesn't mask. Widget is functional but doesn't respond to programmatic input.

## Untried paths (parked for future):

- **Headed Chromium mode** — Trinity Health typeahead works with same code, suggesting ITW checks a specific headless signal. Switch to headed for source_hearing widgets.
- **navigator.webdriver deeper masking** — beyond current stealth plugin.
- **Simplify-style prefill+handoff mode** — walker fills what it can, marks app `needs_manual_finish` with screenshot, user opens in own browser to finish. This was #2 recommendation from the "what commercial services do" analysis.

## App IDs of interest:

- 722 Capital One — still locked out
- 723-728 — ITW source_hearing loop (all with universal fixes deployed)

## Standing rules confirmed in play this session:

- [[feedback-tars-auto-kill-hung-walkers]] — killed 8+ hung Chrome batches
- [[feedback-tars-autonomous-fix-and-retry]] — iterated ~10 fix-and-retry cycles

## Recommended next session:

1. **Build prefill+handoff mode** — mark stuck apps as `needs_manual_finish`, screenshot the stuck page, add UI button "Open in browser to finish". Unblocks EVERY tenant with a broken widget, not just ITW.
2. **Try headed Chromium for source_hearing** — 1-line config change; might just work on ITW.
3. **Add new non-Workday jobs to the queue** — test universal fixes on Greenhouse/Lever/etc. that aren't blocked by tenant-specific pathologies.