* Stub the two helpers the sliced harnesses started importing
Backend CI's "Repo tests (CPU)" has been red on main since 588405dce, with 111
failures in two files. Both are the same defect, and neither is about what the
tests claim to be testing.
These harnesses replay real studio source with its import block stripped, so
every name the sliced region calls has to be defined in the harness. Two landed
without one:
refresh-context-usage.ts findLatestUserVideoBase64 (#9056, decline to price
a prompt carrying video)
chat-runtime-store.ts resolvePreserveThinkingOnLoad
Both product changes are right. The first is the more dangerous shape: with no
stub the replayed body throws a ReferenceError, the effect bails, `counts` stays
0, and the assertion reads "the empty New Chat view must be priced exactly once"
-- a pricing bug that does not exist. 41 tests failed that way, and bisecting
main was the only way to see it, because the message points at the wrong thing.
test_chat_autoload_failure_gate.py already guards this and said exactly what was
missing, which is why its 70 failures named resolvePreserveThinkingOnLoad
outright. test_new_chat_context_recount.py had no such guard; it does now, built
the same way -- parse the real import list, assert the harness defines each name.
Mutation-tested: dropping the video stub turns it red with the name in the
message.
The preserve-thinking stub is the real resolver's rule verbatim, since no
scenario here sets a stored preference.
tests/studio: 0 failures, from 111.
* Count nesting when finding install.sh's GPU-detection fallback
With the harness stubs in place, Repo tests (CPU) is down to one failure, and it
is the last of the same kind: correct product code reported as a defect by a
scan that reads the file too loosely.
test_no_torch_backend_auto_outside_fallback allows --torch-backend=auto only
inside install.sh's "GPU detection failed" branch, and located the end of that
branch as the first line equal to `fi` after the comment. #8670 put a `case`
into the branch to choose the desktop install spec, with an `if`/`fi` inside one
of its arms. That `fi` is now the first one, so the block ended four lines early
and the branch's own install call -- line 5280, the one the test exists to
permit -- was reported as a primary path using the flag.
The end is now found by counting nesting. `case` counts too: it closes with
`esac`, so an `if`/`fi` inside a case arm would still throw off a counter that
only tracked `if`.
Added test_the_fallback_range_reaches_the_end_of_the_branch, because the bug
here was in the range and not in what the range was used for, so nothing was
checking the range itself. It pins both ends: the block contains the branch's
first `if` and both of its --torch-backend=auto calls, and does not run past its
closing `fi`.
Mutation-tested both ways. Adding --torch-backend=auto outside the branch still
fails the original assertion; reverting the nesting count to the first-`fi`
behaviour fails the new one.
tests/python/test_cross_platform_parity.py 78 passed.
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
3457a57a33