The Cypress commands listed here (npm run cypress:run / npm run cypress:open) don’t exist in package.json scripts. The repo uses npm run test:e2e / npm run test:e2e:ci (and cypress:install/cypress:verify) instead, so this section should be updated to avoid sending contributors/agents to non-existent commands.

The “Only allow” license list is stricter than the repo’s actual license gate. npm run test:licenses currently allows MIT;ISC;0BSD;BSD-2-Clause;BSD-3-Clause;Apache-2.0;Unlicense;CC0-1.0 (package.json), so this guidance should be updated to match (or the script tightened) to avoid conflicting direction during dependency reviews.

The guidance hard-codes a relative module specifier (vi.mock('../../audio/AudioProvider')), but in this repo tests mock AudioProvider using different relative paths depending on the test location (e.g. vi.mock("../../../audio/AudioProvider", ...)). Suggest rephrasing to: mock AudioProvider using the same import path as the code under test (or standardize on the @/audio/* alias if that’s the intended convention).

This example uses a fixed relative path (vi.mock('../../audio/AudioProvider')), but existing tests in the repo mock AudioProvider with varying relative specifiers based on file depth (e.g. "../../../audio/AudioProvider"). To avoid copy/paste failures, recommend wording this as “mock AudioProvider using the same module specifier as the component under test” (or explicitly recommend the @/audio/* alias if you want to standardize).

The “Core Technologies” section lists libraries that are not currently in this repo’s dependencies (e.g. @react-three/rapier, cannon-es, howler, zustand). This can lead to agent output that won’t compile/install. Consider either (a) updating this section to reflect the existing in-repo physics/audio/state systems, or (b) marking these as “future/optional” and linking to the planned adoption work.

The comment block still states we “require high fatigue to be greater than low fatigue”, but the assertion was changed to toBeGreaterThanOrEqual. Update the surrounding comment text to match the actual condition (or revert the assertion) so the test’s intent is unambiguous.

The “Strict TypeScript” bullet implies noUncheckedIndexedAccess and exactOptionalPropertyTypes are enabled, but the repo’s tsconfig doesn’t set noUncheckedIndexedAccess and explicitly sets exactOptionalPropertyTypes: false. Please reword this to reflect the actual configuration (or call out these as recommended flags rather than current settings).

This test still asserts against wall-clock time (performance.now()), which tends to be flaky across CI runners and can fail due to unrelated load/GC. Consider moving this check into a dedicated vitest bench benchmark (like the existing AI performance bench) or gating it behind an explicit performance-test flag so unit tests remain deterministic.

Relaxing this assertion to allow ties reduces flakiness, but the test is still inherently non-deterministic because makeDecision() uses Math.random() internally. To avoid future flakes (and to make failures actionable), consider mocking/overriding randomness with a seeded RNG during this test and asserting on an expected difference or confidence interval instead of a single stochastic comparison.

getStanceTransitionBlend() returns {...} | null, but expect(blend).toBeDefined() will still pass when blend is null. This makes the test too weak (it won’t catch an unexpected null) and contradicts the comment about returning a valid object. Use an assertion that matches the intended contract (e.g., assert non-null during the rapid-query loop, or explicitly allow null only when the transition has completed).

Mocking Math.random is only restored via vi.restoreAllMocks() inside the test body. If the loop throws/fails before reaching that line, the spy can leak into later tests. Prefer restoring in a try/finally or an afterEach, and restore only the Math.random spy (mockRestore) instead of restoreAllMocks() to avoid unintentionally resetting unrelated spies/mocks in this large test suite.

vi.restoreAllMocks() is very broad here and will reset any other spies/mocks that might be active in this test file. Since this test only overrides Math.random, restore that specific spy instead (or restore in afterEach) to keep tests isolated and reduce the chance of unintended side effects.

Same issue here: expect(blend).toBeDefined() will not fail when blend is null, so this doesn’t actually validate that the state machine continues returning blend data (or that null only occurs after completion). Either assert not.toBeNull() for frames where a blend must exist, or explicitly permit null only once the transition is done (and validate the non-null cases more strongly, e.g. blend in [0,1]).