TL;DR

tests/run_agent/test_concurrent_interrupt.py::_Stub is missing _apply_pending_steer_to_tool_results, so both concurrent-interrupt tests fail on clean origin/main with AttributeError. This is test-only drift — production code is unaffected.

Fixing this takes two tests off the repo's standing baseline-failure list that's currently blocking every open PR's test check.

Root cause

_execute_tool_calls_concurrent (run_agent.py:7940+) is bound onto a minimal _Stub class for these tests. At run_agent.py:8092 the method unconditionally calls:

self._apply_pending_steer_to_tool_results(messages, num_tools)

That method was added to AIAgent at run_agent.py:3339 but the stub was never updated. Every invocation of the interrupt-path tests raises:

AttributeError: '_Stub' object has no attribute '_apply_pending_steer_to_tool_results'

Reproduces on clean origin/main (6fb69229):

$ python -m pytest tests/run_agent/test_concurrent_interrupt.py -q
2 failed, 2 passed in 3.16s
FAILED test_concurrent_interrupt_cancels_pending
FAILED test_running_concurrent_worker_sees_is_interrupted

Fix

Add a no-op _apply_pending_steer_to_tool_results to _Stub, matching the existing pattern for the other stub methods (_vprint, _safe_print, _should_emit_quiet_tool_messages, _has_stream_consumers, …).

Why a no-op (rather than mirroring the real method's state machine):

• These tests assert only interrupt propagation + worker cancellation — they never set _pending_steer or exercise the /steer injection path.
• The real method would early-return anyway (_drain_pending_steer returns None when _pending_steer is unset), so a no-op is behaviourally equivalent for this test surface.
• Keeping the stub small avoids dragging in _drain_pending_steer + _pending_steer + _pending_steer_lock state that isn't under test.

def _apply_pending_steer_to_tool_results(self, messages, num_tool_msgs):
    # Real AIAgent method (run_agent.py:3339) mutates ``messages`` to
    # append any pending ``/steer`` text to the last tool-result.
    # These interrupt tests never set ``_pending_steer``, so the
    # real implementation would early-exit anyway — we stub it as a
    # no-op to avoid dragging in ``_drain_pending_steer`` +
    # ``_pending_steer`` / ``_pending_steer_lock`` state that isn't
    # under test here.  Required since ``_execute_tool_calls_concurrent``
    # (run_agent.py:8092) unconditionally calls this at the end of
    # each tool batch.
    return None

Validation

source venv/bin/activate
python -m pytest tests/run_agent/test_concurrent_interrupt.py -q
# 4 passed  (was: 2 failed, 2 passed on origin/main)

Broader tests/run_agent/ under -n auto → 783 passed, 7 skipped, 0 failures.

Narrow scope — explicitly not changed

• No production code touched. run_agent.py is unmodified.
• No other stub methods added. Only the one method needed to unblock the 2 failing tests. Other drift (if any) is out of scope for this PR.
• No other baseline failures addressed. Separate follow-ups can take those (schema-version pin drift, tool-rename test drift, etc.); this PR keeps scope surgical.

Pre-empted review questions

Q. Should the stub track _pending_steer state instead, to better mirror production?
The existing stub is deliberately minimal (see its other _vprint/_safe_print/… no-ops). The tests don't exercise the steer path, so carrying that state would be speculative complexity. If a future test does want to exercise /steer injection during concurrent interrupt, that test can extend the stub then — per its actual needs.

Q. Why not fix it in production (make _execute_tool_calls_concurrent tolerant of a missing method)?
Because nothing is wrong in production — AIAgent always has this method. The bug is purely in the test stub that drifted from the class it's shadowing.

_{Co-authored via LLM assistance; I've reviewed every line and am responsible for correctness.}