[rominf]

engine-shell-01 (@id:engine-shell-marks-the-prompt) fails intermittently on the hosted mock lane with "the marker never reached a prompt line". It failed on #544 and #630, neither of which touches the engine shell.

Why. The step waited for the bare (rocm:vllm) marker, then checked once that the marker sat on a prompt line. The banner rocm engines shell prints before it starts bash names the same marker: "your prompt is now prefixed (rocm:vllm)". So the wait returned as soon as the banner appeared, before bash had drawn a prompt. When bash started slowly, the one-shot check failed. The failing captures show exactly that: the banner is on screen and no prompt line follows it. A loaded runner (see #661) makes the window wider.

Fix. Wait with wait_for_screen_where until a line has both the marker and $ or #. The scenario still fails, after SCREEN_TIMEOUT, if the prompt never carries the marker.

Tests. This is a fix to the scenario itself. There is no deterministic local reproduction, because the failure depends on bash starting after the step's single check. Locally, cargo xtask e2e -- -n engine-shell passes; fmt, feature_naming, cargo check --test e2e, and clippy for -p e2e-cucumber --test e2e with -D warnings (Linux and Windows targets) are clean.

User-observable behaviour: none. This changes only the test harness.

[jussielo-amd]

Review — no blocking findings

Full review of the whole change.
No ticket named in the PR body; the description references GitHub issues #544, #630, #661 as evidentiary context, not as a tracked goal.

Blocking

None

Non-blocking

None

Decisions for the author

None

Positive signals

• Root-cause diagnosis verified against live evidence, not asserted. The claim that engine-shell-01 failed on #544 and #630 with "the marker never reached a prompt line" is confirmed by the actual CI job logs of both cited runs, and the claimed cause — the pre-shell banner in apps/rocm/src/engines_cmd.rs:637 printing the literal (rocm:vllm) marker before bash starts — is confirmed in the production source.
• Reuses the existing wait_for_screen_where polling helper (already used in dash_steps.rs/tui_driver.rs) instead of hand-rolling a new retry loop, and gets its existing fail-fast diagnostics (reader-thread panic, child-exit detection, framed screen dump) for free.

Deployment notes

None (test-harness-only change; no production code, no user-observable behavior).

What this covered

Single-pass review (appropriate for scale — one file, one function, a ~30-line diff) of the full diff, plus the surrounding step module, wait_for_screen/wait_for_screen_where's full implementations in tui_driver.rs, the production banner source the root-cause claim depends on, file history, and live CI status/logs (including the two cited prior failures) to verify the bug report's evidence directly. A leak scan across the diff was clean.

Did not run: no prior review comments on this file to reconcile; cargo test/clippy/cargo xtask e2e were not re-executed locally — CI's own green run was taken as authoritative (all required checks SUCCESS; "E2E tests (MI300X)," a self-hosted GPU lane, is QUEUED and not required for this class of change).

Not reconciled against any discussion on the PR — no review threads existed at the time of this pass.