Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@composer.json`:
- Around line 39-49: Add a new npm script "test:tracking-rest-controller" that
runs the new PHP test (tests/tracking-rest-controller-test.php) and update the
existing "test:all" array to include "@test:tracking-rest-controller" so the new
REST controller regression test (and the tz sanitizer fix) runs with the full
suite; edit the composer.json scripts section to add the
"test:tracking-rest-controller" entry and insert its reference into the
"test:all" list alongside the other "@test:..." entries.

In `@README.md`:
- Line 11: Update the README bullet that currently claims "fully compliant with
GDPR" to a softened, non-guarantee statement (e.g., "Provides features to help
support GDPR compliance; actual compliance depends on your site's consent flow,
retention settings, and deployment"). Keep the rest of the sentence about
integrating with WP Consent API and translatable consent banners (WPML/Polylang)
intact, and add a short note that site owners must configure consent/retention
settings to achieve compliance; replace the exact phrase in the existing GDPR
bullet line.

In `@src/Tracker/Processor.php`:
- Around line 237-238: The geo-IP gate is re-checking Consent::piiAllowed()
instead of using the explicit-consent / consent-upgrade-aware boolean computed
earlier in this Processor (the result computed above that indicates
upgrade-aware PII allowance); replace the Consent::piiAllowed() call in the geo
location block where resolve_geolocation_provider() is used with that earlier
variable (use the exact variable name declared above — e.g. $consentUpgradeAware
or $explicitConsent depending on the diff) so both GeoIP passes use the same
consent-upgrade-aware flag and prevent IP/PII from being upgraded for
country/city only in the same request.

In `@tests/e2e/geoip-ajax-loop.spec.ts`:
- Around line 107-110: The test allows up to 3 concurrent GeoIP dispatches
because the current guard in admin/index.php and src/Services/GeoService.php is
a check-then-set around slimstat_last_geoip_dl; change the dispatch protection
to acquire an atomic lock (e.g., use a single DB row lock, mutex, or
get_lock()/SET ... WHERE ... to atomically test-and-set slimstat_last_geoip_dl)
inside the GeoService dispatch path before enqueuing the AJAX job so only one
process can dispatch at a time, then tighten the test assertion in
tests/e2e/geoip-ajax-loop.spec.ts from expect(log.length).toBeLessThanOrEqual(3)
to expect(log.length).toBe(1).

In `@tests/e2e/geolocation-provider.spec.ts`:
- Around line 55-59: The test currently conditionally checks the value of the
select and can silently pass if the control is missing; change it to first
assert the select exists and is visible, then assert its value. Locate the
selector referenced as providerSelect (created via
page.locator('select[name="geolocation_provider"]')) used after
page.goto('/wp-admin/admin.php?page=slimconfig&tab=5') and replace the if (...)
guard with an explicit expect(providerSelect).toHaveCount(1) or
expect(providerSelect).toBeVisible() (or both) followed by
expect(providerSelect).toHaveValue('dbip') so the test fails if the control
disappears.
- Around line 81-159: The tests currently use fixed waits
(page.waitForTimeout(3000/4000)) before calling getLatestStat(marker) which
leads to flakiness; replace those sleeps in the tests that call
simulateLegacyUpgrade(...) and then call getLatestStat(marker) (test "legacy
upgrade with enable_maxmind=disable"), in the Cloudflare test that
setsSlimstatOption(...) and then reads getLatestStat(marker), and in the
"disabled provider" test with a polling helper (e.g., waitForStat(marker,
timeoutMs, intervalMs)) that repeatedly calls getLatestStat(marker) until a
non-null/expected stat is returned or timeout is reached; remove the fixed
page.waitForTimeout(...) calls and use the new polling helper in place so tests
wait deterministically for persistence instead of sleeping.

In `@tests/e2e/helpers/ajax-logger-mu-plugin.php`:
- Around line 8-16: The AJAX logger callback registered with
add_action('wp_ajax_slimstat_update_geoip_database', ...) must be gated and must
stop persisting raw identifiers: inside that callback first verify the request
with wp_verify_nonce(…) and check current_user_can('manage_options') (or the
appropriate slimstat capability), then change its priority so it runs after
SlimStat's handler (e.g. replace priority 1 with a higher value like 20) and
stop storing raw referer/user/ip; instead either increment/write a simple
invocation counter or write only a timestamp plus an irreversible IP fingerprint
(e.g. a hash or truncated digest of $_SERVER['REMOTE_ADDR']) before calling
file_put_contents(WP_CONTENT_DIR . '/geoip-ajax-calls.log', …) to append safe
telemetry.

In `@tests/e2e/helpers/option-mutator-mu-plugin.php`:
- Around line 12-34: The AJAX handler registered in
add_action('wp_ajax_test_set_slimstat_option') must verify a nonce and return
proper HTTP failure codes; call wp_unslash($_POST) first, verify a nonce via
wp_verify_nonce($_POST['nonce'], 'your_action') before
current_user_can('manage_options'), then extract and sanitize inputs using
sanitize_text_field() on the unslashed values; when rejecting requests use
wp_send_json_error($message, 403) for forbidden and wp_send_json_error($message,
400) for missing/invalid input; keep update_option('slimstat_options', $opts)
and wp_send_json_success(...) unchanged otherwise.

In `@tests/e2e/helpers/setup.ts`:
- Around line 15-24: Replace hardcoded developer-specific path constants by
reading them from environment variables with sensible defaults: update WP_ROOT,
MYSQL_SOCKET and any derived paths (WP_CONFIG, WP_CONTENT, MU_PLUGINS, AJAX_LOG,
LOGGER_DEST) to use process.env variables (e.g., process.env.WP_ROOT,
process.env.MYSQL_SOCKET) and compute dependent paths with path.join; keep
LOGGER_SRC as a repo-relative path via __dirname but allow overriding with
process.env.LOGGER_SRC if needed; ensure CRON_LINE remains unchanged. Validate
or throw a clear error when required env vars (like WP_ROOT or MYSQL_SOCKET) are
missing to prevent silent failures.

In `@tests/e2e/upgrade-data-integrity.spec.ts`:
- Around line 122-129: The afterEach only deletes seededIds and calls
restoreSlimstatOptions but doesn't restore the original stats table state
(page.goto inserts extra rows and there's a truncation elsewhere), so make the
teardown hermetic by taking a snapshot of the stats table at test start and
restoring it in afterEach: add a test.beforeEach that calls a helper (e.g.,
getStatsSnapshot) to fetch and store all current stats rows, and modify
test.afterEach to call a restoreStatsRows(originalSnapshot) helper that removes
anything not in the snapshot (or truncates and reinserts the snapshot) and also
still deletes seededIds via deleteStatsRows and resets seededIds = []; remove
any global/truncation-only cleanup and ensure restoreSlimstatOptions remains
called. Reference helpers/getters: getStatsSnapshot, restoreStatsRows,
deleteStatsRows, seededIds, and restoreSlimstatOptions when implementing this
change.
- Around line 25-40: The test hard-codes a user-specific MySQL socket path via
MYSQL_SOCKET and the getPool()/pool logic, causing the spec to fail on other
machines; update the code to read the socket/host config from environment or the
shared E2E helper (e.g., process.env.MYSQL_SOCKET or a central test config) and
fall back to a sensible default, then use that value when creating the pool in
getPool() so the test is portable across environments.

In `@tests/lazy-migration-test.php`:
- Around line 93-97: The test asserts that a fresh install migrates
geolocation_provider to 'disable', but product defaults now set
geolocation_provider to 'dbip'; update the test to match real behavior by
changing the expected value from 'disable' to 'dbip' in the assertion using
wp_slimstat::$settings and lazy_migrate(), or if the intent was only to exercise
the helper (not the product default) rename the test description from "Fresh
install (no settings) → migrates to 'disable'" to something like "Bare helper
invocation sets provider to default" to avoid asserting the wrong product
default.
- Around line 28-72: The test currently reimplements sanitize_text_field,
wp_slimstat::resolve_geolocation_provider, and lazy_migrate which masks
regressions; convert this into a WP_UnitTestCase that boots the real plugin and
invokes the real lazy-migration path instead of the inline clones. Replace the
inline functions/classes with a test class extending WP_UnitTestCase that loads
the plugin (so wp-slimstat.php and admin/config/index.php are used), set up
relevant settings (e.g. enable_maxmind and/or geolocation_provider), trigger the
code path that runs the lazy migration, and assert that
wp_slimstat::$settings['geolocation_provider'] is populated to the expected
values; remove the local sanitize_text_field(),
wp_slimstat::resolve_geolocation_provider(), and lazy_migrate() stubs from the
test file.

In `@tests/perf/geoip-load.js`:
- Around line 119-135: The teardown() function currently only logs a warning
when lines.length > 10, so replace that non-failing path (the if branch that
logs console.warn) with a hard failure: call k6's fail() (or throw a clear
Error) including the lines.length value in the message so the run is marked
failed; alternatively emit a threshold-backed metric instead of
console.warn—update the lines.length > 10 branch in teardown to fail the test
rather than just warn.
- Around line 71-100: The setup() function performs the login but doesn't return
or propagate the login cookies, so VUs in default() aren't authenticated;
extract the cookies from loginRes (e.g., loginRes.cookies or the Set-Cookie
headers) and return them along with loginOk, then update default() to accept the
setup data, install those cookies into the VU before the admin request (either
by setting a Cookie header or using k6's cookie jar API) and only proceed if
loginOk is true so the VU requests hit the authenticated /wp-admin/ paths (refer
to setup(), loginRes, loginOk, default(), and ADMIN_PAGES).

In `@tests/run-qa.sh`:
- Around line 12-16: The script hardcodes machine-specific paths (WP_ROOT,
WP_CONFIG, MU_PLUGINS, AJAX_LOG, MYSQL_SOCKET); change these to read from
environment variables (e.g. ${WP_ROOT:-/default/path}) or parse CLI flags and
fall back to sensible defaults so contributors can override them without editing
the file; update the variable assignments for WP_ROOT, WP_CONFIG, MU_PLUGINS,
AJAX_LOG, and MYSQL_SOCKET to use the env/flag values and ensure downstream uses
of those variables continue to work.
- Around line 97-100: The in-place sed invocation using "sed -i ''" in the block
that checks for DISABLE_WP_CRON and edits "$WP_CONFIG" is BSD-only and will fail
on GNU sed; update the call to use a portable form (e.g., "sed -i.bak ...
\"$WP_CONFIG\"" to create a .bak backup) or add a small detection branch that
tests sed flavor and uses "sed -i''" for BSD and "sed -i" or "sed -i.bak" for
GNU, ensuring the define('DISABLE_WP_CRON', true); insertion into "$WP_CONFIG"
still occurs when the grep for DISABLE_WP_CRON is false.

In `@wp-slimstat.php`:
- Around line 814-818: The get_fresh_defaults() function currently forces new
installs to opt into DB-IP by setting $defaults['geolocation_provider'] =
'dbip'; remove that line (or set the key to null/''/'none') so fresh defaults do
not enable any third‑party geolocation provider; keep the rest of init_options()
behavior unchanged and ensure get_fresh_defaults() returns defaults without
initiating DB-IP or any external download/update flow.

---

Outside diff comments:
In `@admin/config/index.php`:
- Around line 847-865: The posted geolocation provider is only sanitized but not
validated, so arbitrary values can be persisted into
wp_slimstat::$settings['geolocation_provider'] and break later logic; update the
handling around resolve_geolocation_provider()/geolocation_provider to enforce
an allowlist of valid keys (e.g., 'maxmind','dbip','cloudflare','disable'),
validate the sanitized $provider against that list and if it is not in the
allowlist fall back to $prevProvider (the result from
wp_slimstat::resolve_geolocation_provider()), then save the validated value to
wp_slimstat::$settings['geolocation_provider'] and proceed with the existing
enable_maxmind sync logic to ensure legacy flags remain consistent.
- Around line 867-883: The one-shot GeoIP update never runs because
wp_next_scheduled('wp_slimstat_update_geoip_database') is already true from the
recurring weekly job registered elsewhere, and the recurring hook is left
enabled even when selecting the 'cloudflare' or 'disable' provider; fix by
ensuring the recurring weekly scheduler in admin/index.php uses the same
provider gate (skip scheduling when $provider is 'cloudflare' or 'disable') and
by clearing any existing scheduled recurring event when switching to a provider
that shouldn't have recurring updates (call wp_clear_scheduled_hook or
unschedule wp_slimstat_update_geoip_database when $provider changes to
'cloudflare'/'disable' or when $provider !== $prevProvider), and when you still
need an immediate one-shot after a provider change ensure you unschedule the
recurring hook first so wp_next_scheduled(...) returns false before calling
wp_schedule_single_event(...).

In `@assets/css/gdpr-banner.css`:
- Around line 477-479: The reduced-motion override selector
`#slimstat-gdpr-banner` is less specific than the existing
`#slimstat-gdpr-banner.show` rule so the banner can still animate; update the
stylesheet to target the animated state as well (e.g. add a rule for
`#slimstat-gdpr-banner.show` { animation: none; } or `#slimstat-gdpr-banner.show` {
animation: none !important; }) and wrap these in a prefers-reduced-motion:
reduce media query so the override applies only for users who request reduced
motion; reference the `#slimstat-gdpr-banner` ID and the .show class in the new
rule.

In `@src/Tracker/Processor.php`:
- Around line 528-539: The branch that sets $stat['visit_id'] from
VisitIdGenerator::generateNextVisitId() can mint a different visit_id after
Session::ensureVisitId() has already run, but it never rewrites the browser
cookie; update the code path in Processor.php (the block that assigns
$stat['visit_id'] and sets $update_data['visit_id'] when $stat['visit_id'] !=
$existing_record->visit_id) to call Session::setTrackingCookie() with the new
visit id (or otherwise rewrite the tracking cookie) so the browser receives the
upgraded session id; ensure this same fix is applied to the similar block at the
other occurrence (lines ~576-579) to keep cookie and DB visit_id in sync.

---

Minor comments:
In `@docs/TESTING.md`:
- Around line 27-30: Replace the contributor-specific entries in TESTING.md:
remove the personal URL/username in the Local by Flywheel note and swap
hard-coded credentials and the full MySQL socket path (the strings 'parhumm',
'dordane', 'testpass123' and the long '/Users/.../mysqld.sock') for generic
placeholders or environment-variable references (e.g. <LOCAL_URL>,
<WP_ADMIN_USER>, <WP_AUTHOR_USER>, <WP_PASSWORD>, and <MYSQL_SOCKET_PATH> or
${MYSQL_SOCKET}). Update the examples to show how to set the env vars or
substitute example values and keep the "Local by Flywheel" note generic so no
user-specific filesystem paths or passwords are leaked.
- Around line 87-96: The fenced code blocks in docs/TESTING.md (the block
showing the tests/e2e tree and the other block at lines 274-297) are missing a
language tag and trigger markdownlint MD040; update each triple-backtick fence
to include a language token such as ```text or ```bash so the blocks become
```text (or ```bash) and render/lint correctly—locate the blocks by the snippet
content (the tests/e2e file tree and the second identical block) and add the
language after the opening backticks.
- Around line 51-58: Update the provider coverage table row for
resolve-geolocation-provider-test.php to reflect the current resolver/provider
set (include "cloudflare" alongside maxmind, dbip, ip2location and disable) so
the table matches the 5.4.2 behavior; edit the table entry in docs/TESTING.md
where the File column lists `resolve-geolocation-provider-test.php` to mention
the full provider list (maxmind, dbip, ip2location, cloudflare, disable).

---

Nitpick comments:
In `@tests/e2e/global-setup.ts`:
- Around line 43-63: The globalSetup currently hardcodes fixture users when
calling loginAndSave inside globalSetup; modify it so it does not assume
pre-seeded users by either (A) creating the test accounts programmatically
before logging in (call the app's user creation endpoint or invoke a helper like
createUserForTests for usernames 'parhumm' and 'dordane' with desired passwords,
ensuring idempotency) or (B) loading usernames/passwords from environment/config
(process.env.TEST_ADMIN_USER, TEST_ADMIN_PASS, TEST_AUTHOR_USER,
TEST_AUTHOR_PASS) and using those values when calling loginAndSave; update
globalSetup to check for missing creds and fail fast or create accounts
accordingly, and keep references to AUTH_DIR and loginAndSave unchanged so the
rest of the flow still writes tokens to path.join(AUTH_DIR, ...).

In `@tests/e2e/helpers/setup.ts`:
- Around line 83-95: Replace hardcoded DB credentials in getPool() by reading
them from environment variables (e.g., MYSQL_USER, MYSQL_PASSWORD,
MYSQL_DATABASE, MYSQL_SOCKET) and fall back to the existing defaults only if env
vars are not present; update the mysql.createPool call in getPool to include a
connectTimeout (e.g., 5000 ms) and keep existing options (waitForConnections,
connectionLimit). Ensure you reference the same pool variable and MYSQL_SOCKET
usage so behavior is unchanged except for configurable credentials and the added
connectTimeout.
- Around line 262-268: The query in getLatestStat uses LIKE with surrounding %
which can return unintended matches; change the SQL to use an exact equality
comparison (resource = ?) or a stricter pattern (e.g., resource LIKE
CONCAT('%:', ?, ':%' ) if you adopt a delimiter) when calling getPool().execute
in getLatestStat so the parameterized testMarker only matches the intended
resource; update the parameter array accordingly and keep the same return
handling.
- Line 198: The BASE_URL constant is hardcoded which breaks portability; change
the const BASE_URL in tests/e2e/helpers/setup.ts to read from an environment
variable (e.g., process.env.TEST_BASE_URL || process.env.BASE_URL) with the
current 'http://localhost:10003' as a fallback, and ensure any code
importing/using BASE_URL still references this updated constant so tests can run
against different environments by setting the env var.
- Around line 171-179: The teardownTest function should guard the await
setSlimstatSetting('geolocation_provider', savedProviderValue) call so a failure
there doesn't mask test failures or abort remaining cleanup: wrap the
conditional block that calls setSlimstatSetting in a try/catch, log the caught
error (using the existing test logger or console.error), and ensure
savedProviderValue is cleared (set to null) and other cleanup (restoreWpConfig,
uninstallMuPlugin, clearAjaxLog) always run; adjust teardownTest accordingly so
restoreWpConfig, uninstallMuPlugin, and clearAjaxLog are not skipped if
setSlimstatSetting throws.
- Line 28: The module-level variables wpConfigBackup, pool, savedProviderValue,
and savedOptionsSnapshot cause shared state across workers; change them to
test-scoped state by converting these module-level variables into Playwright
fixtures or functions that initialize and return per-test instances (e.g.,
create a setupFixture that captures and restores wpConfigBackup, creates a pool
per test, and stores provider/options snapshots per test) or store them on
test.info(). Instead of top-level let declarations, implement test.extend or a
setup/teardown helper that returns and restores values for each test, or mark
the tests using these helpers as serial if per-test isolation cannot be added.
- Around line 127-158: The setSlimstatSetting function is fragile and exposes a
ReDoS risk by building a regex from the key; replace usages with the safer
setSlimstatOption function (which uses WordPress option APIs) wherever possible.
If direct DB mutation via getPool() is absolutely required, stop constructing an
unescaped regex from key: sanitize/escape all regex metacharacters from the key
(escape characters like . * + ? ^ $ { } ( ) | [ ] \ ) before building the
RegExp, remove reliance on global test()/lastIndex semantics, and perform a
single non-global replace that targets the exact serialized key/value pair;
additionally keep the early-warning/logging behavior when the key is not found.
Update callers to prefer setSlimstatOption and mark setSlimstatSetting as
deprecated with a short comment.

In `@tests/e2e/playwright.config.ts`:
- Around line 16-21: The Playwright config currently hardcodes use.baseURL to
'http://localhost:10003'; change it to read a shared env var (e.g.,
process.env.E2E_BASE_URL or PLAYWRIGHT_BASE_URL) with the existing URL as the
default so CI/dev boxes can override without editing the repo, and update
tests/e2e/global-setup.ts to consume the same env var (use the same env var name
and default) so both playright.config.ts (use.baseURL) and global-setup.ts share
one source of truth.

In `@tests/resolve-geolocation-provider-test.php`:
- Around line 27-65: The test currently reimplements sanitize_text_field() and
wp_slimstat::resolve_geolocation_provider(), so update the test to exercise the
real implementation instead: remove the local copies of sanitize_text_field and
the wp_slimstat class, require/include the plugin/module that defines
wp_slimstat::resolve_geolocation_provider() and let the test call that real
method, and keep only minimal stubs for external WordPress helpers (e.g., mock
sanitize_text_field or any other WP functions used by the real code) so the
assertions validate the shipped resolver rather than a duplicate.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@tests/e2e/upgrade-safety.spec.ts`:
- Around line 21-39: The test file currently hardcodes machine-specific values
(MYSQL_SOCKET, BASE_URL, WP_ROOT) and DB credentials inside getPool/pool which
breaks portability; replace those literal constants with environment-driven
values (e.g., read process.env.MYSQL_SOCKET, process.env.BASE_URL,
process.env.WP_ROOT, process.env.DB_USER, process.env.DB_PASS,
process.env.DB_NAME) and use sensible safe defaults or fail fast if required
vars are missing, and update the mysql.createPool call in getPool to use those
env variables; also add a .env.example documenting required variables for
local/CI usage.
- Around line 196-224: The test "slimstat_visit_id_counter is >= MAX(visit_id)
in stats table" currently allows a missing slimstat_visit_id_counter to pass
silently; change the assertion to require that the option exists after plugin
load and that its numeric value (parsed from the row returned by
getPool().execute for "SELECT option_value FROM wp_options WHERE option_name =
'slimstat_visit_id_counter'") is >= the computed maxId (from the MAX(visit_id)
query) — if the implementation legitimately allows absence, add an explicit
comment or an alternate test path documenting that behavior, but do not let the
test silently succeed; also replace page.waitForTimeout(4000) with await
page.waitForLoadState('networkidle') after page.goto('/') to wait
deterministically for plugin initialization.

In `@tests/e2e/visit-id-performance.spec.ts`:
- Around line 124-149: The test currently allows the counter to remain null
because it may reuse the existing session; instead, before triggering tracking
you must start a fresh session (e.g., open a new browser context or clear
cookies/localStorage) and navigate to a route that will call
VisitIdGenerator::generateNextVisitId() so the counter is created; then require
getVisitIdCounter() to be non-null and assert counter >= maxBefore. Update the
test around seedVisitIds/deleteVisitIdCounter/page.goto so it explicitly forces
a new session (new context or clear session state) and then checks the counter
value rather than treating a null counter as acceptable.
- Around line 192-220: The test "no visit_id collisions under rapid page loads"
currently only asserts visit_id > 0 and uses one browser context; change it to
open each page in its own browser context (use context.browser().newContext() or
create multiple contexts instead of reusing the single `context`), generate
unique `marker` values as before and navigate each context/page to
`${BASE_URL}/?p=${marker}`, then query the DB with `getPool().execute` filtering
for the specific `rapid-*` markers (use the `markers` array to limit the WHERE
clause) and collect the returned `visit_id`s for those markers; finally assert
that the set of returned `visit_id`s has the same size as `markers.length` (i.e.
all `visit_id`s are unique) and that each visit_id is a positive integer.
- Around line 154-187: The current test "visit_ids are monotonically increasing
across sequential visits" uses the same Playwright page/session for all
navigations so visit_id can remain equal; update the loop that generates
pageviews (the section that builds markers and calls page.goto) to create a
fresh browser session each iteration: use page.context().browser().newContext()
then context.newPage(), navigate to `/?p=${marker}`, wait, then close the
context to ensure a new visit/session per iteration; keep collecting markers and
then change the assertion over visitIds (the array produced from rows) to
require strict increases (use > between visitIds[i] and visitIds[i-1]) instead
of >= to verify the counter advances.
- Around line 18-19: The test currently hardcodes MYSQL_SOCKET and BASE_URL
(constants MYSQL_SOCKET and BASE_URL) which pins the suite to one developer's
environment and mixes absolute and relative page.goto() calls; change
MYSQL_SOCKET to be read from shared test configuration or environment (e.g.,
process.env.MYSQL_SOCKET or a testConfig value) and remove the BASE_URL
constant, instead rely on Playwright's configured baseURL and use only relative
page.goto() paths throughout the spec (replace page.goto(`${BASE_URL}/...`) with
page.goto('/...') and ensure any DB/socket usage reads from the centralized
config key you introduced).

---

Nitpick comments:
In `@tests/e2e/upgrade-safety.spec.ts`:
- Around line 284-306: The variable bodyTransition is unused dead code; either
remove the page.evaluate block that computes bodyTransition (the const
bodyTransition = await page.evaluate(...) and its return) if the CSS file check
via cssPath/cssResponse is sufficient, or add an explicit runtime assertion
after that call (for example, assert that bodyTransition.transition and/or
bodyTransition.animation do not equal or contain 'none') so the value is
actually tested; locate the bodyTransition declaration inside the test near
page.evaluate and update accordingly.
- Around line 174-178: The two fixed sleep calls after page.goto (the await
page.waitForTimeout(2000) after page.goto('/wp-admin/admin.php?page=slimstat')
and await page.waitForTimeout(1000) after
page.goto('/wp-admin/admin.php?page=slimconfig')) are flaky; replace them with
deterministic waits such as waiting for network idle or a specific element that
shows the page finished loading (e.g., use page.waitForLoadState('networkidle')
or page.waitForSelector for a known DOM element/button/header unique to the
SlimStat and SlimConfig admin pages) so the test proceeds only when the page is
ready rather than on a fixed timeout.

In `@tests/e2e/visit-id-performance.spec.ts`:
- Line 136: Replace fixed sleeps (await page.waitForTimeout(...)) with
condition-based waits that poll for the specific DOM evidence the test expects
(e.g., the marker row or counter row becoming present/updated). Locate the
occurrences of waitForTimeout in tests/e2e/visit-id-performance.spec.ts (the
instances about marker/counter rows) and change them to use page.waitForSelector
or page.waitForFunction that waits for the marker row selector or the counter
cell/text to reach the expected value; keep existing selectors/expectations
(marker row / counter row) and timeouts but remove static delays so tests only
proceed once the UI state is observed. Ensure each replaced wait targets the
exact element/state the subsequent assertions rely on (for all listed
occurrences).