Found during #1555's post-merge evidence round (artifacts /private/tmp/ad-p5-evidence-FINAL/retry2/). Two independent sightings of the same shape on DIFFERENT platforms in one session, distinct from #1569's scroll-specific mechanism:
- iOS: replay failed at step 2 (
react-native dismiss-overlay) with "accessibility tree is unreadable" on a lightly-loaded host (~4.0), immediately after a fast session-reused open (postOpenSettleDurationMs:300). Artifacts: retry2/leg1-ios-run1-retry.
- Android: the FIRST replay of a freshly-recorded script diverged at its first click with a fully empty snapshot (
refs:[]) immediately after a cold open --relaunch; an immediate retry went green. Artifacts: retry2/leg3-extended (item b, first attempt).
Both look like the app not yet mounted/AX-registered when the first post-open capture lands — the open-settle window is closing before the app's tree is actually readable. Suggested investigation: what does post-open settle currently wait on per platform, and should the first capture after open carry a readable/non-empty-tree precondition with a bounded retry (attempt-bound per the #1569 lesson, not wall-clock)?
Related: #1569 (distinct mechanism, same corpus), the #1105 capture-wedge lineage (iOS), #1254/#1259 (Android a11y-cache freshness — the helper clears cache per capture, so the Android sighting is likely mount-timing, not cache).
Generated by Claude Code
Found during #1555's post-merge evidence round (artifacts /private/tmp/ad-p5-evidence-FINAL/retry2/). Two independent sightings of the same shape on DIFFERENT platforms in one session, distinct from #1569's scroll-specific mechanism:
react-native dismiss-overlay) with "accessibility tree is unreadable" on a lightly-loaded host (~4.0), immediately after a fast session-reusedopen(postOpenSettleDurationMs:300). Artifacts: retry2/leg1-ios-run1-retry.refs:[]) immediately after a coldopen --relaunch; an immediate retry went green. Artifacts: retry2/leg3-extended (item b, first attempt).Both look like the app not yet mounted/AX-registered when the first post-open capture lands — the open-settle window is closing before the app's tree is actually readable. Suggested investigation: what does post-open settle currently wait on per platform, and should the first capture after open carry a readable/non-empty-tree precondition with a bounded retry (attempt-bound per the #1569 lesson, not wall-clock)?
Related: #1569 (distinct mechanism, same corpus), the #1105 capture-wedge lineage (iOS), #1254/#1259 (Android a11y-cache freshness — the helper clears cache per capture, so the Android sighting is likely mount-timing, not cache).
Generated by Claude Code