Test platform changes with disposable data

Set up a controlled test

1. Work in the Google Cloud development checkout. Use the pinned database migrations from the candidate and a throwaway PostgreSQL fixture. The test runner expects QINTORAVA_TEST_DATABASE_URL and DISPOSABLE_TEST_DATABASE=true. Obtain the connection string from the fixture setup. Keep it out of shell history and Git.
2. Use synthetic MFA identities for the roles involved. Create a disposable record in the desired starting state. Record its UUID and version so assertions can reload it after actions.
3. Choose browser coverage for dynamic controls and navigation. Choose API and database checks for policy gates, concurrency and persisted side effects. Use simulated provider responses when the external service is unavailable.

corepack pnpm install --frozen-lockfile
corepack pnpm run check
corepack pnpm run build
node scripts/test-isolated.mjs --unified --file=service-operations.test.mjs
node scripts/test-isolated.mjs --e2e --project=desktop-chromium \
  --grep 'workplace services manage recurring inspections'

Trace an unexpected failure

1. If the app fails before cases run, check PostgreSQL readiness, the migrations and checksum error, and the actual browser entry files in the candidate image. Separate setup failures from failing workflow assertions in the verification receipt.
2. If the browser waits for a missing control, inspect the first failed API request. Check the session, the role, the selected workspace, the current view, and whether a busy state or API rate limit blocked the prerequisite request.
3. If an action failed after submission, reload the record by UUID and check its history and any dependent record or provider receipt before retrying. Use a fresh approved version for actions that take expectedVersion.
4. Record the expected and actual status and state. Retest with an entitled role and a nearby role or out-of-scope account, then keep evidence of the denied attempt and unchanged record.