Arbox Bridge verification

Automated checks

Run from the repository root:

pnpm -C apps/api exec vitest run --config vitest.unit.config.ts src/arbox-bridge src/bookings src/class-sessions src/import ../../libs/shared/src/lib/schemas/arbox.schema.unit.spec.ts
NEXT_PUBLIC_E2E_TEST_MODE=true pnpm -C apps/web exec vitest run --config vitest.integration.config.ts src/components/settings/arbox-connect.int.spec.tsx
pnpm exec tsc -p apps/api/tsconfig.app.json --noEmit
pnpm exec tsc -p apps/web/tsconfig.json --noEmit

The database tests require the local docker-compose.test.yml PostgreSQL service (and Redis for the shared rate-limiter test). They refuse non-local hosts and database names without _test, create/drop only isolated fixture schemas, and never apply application migrations or call Arbox:

DATABASE_URL=postgresql://postgres:postgres@localhost:55432/taikan_test TEST_DB_WORKERS=1 \
  pnpm -C apps/api exec vitest run --config vitest.integration.config.ts src/arbox-bridge src/bookings src/class-sessions

The fixture schemas model runtime columns, defaults and the unique keys used by upserts. They do not replace validating migrations 0144 and 0152 against a real migration chain.

Coverage includes: route allowlist and redirect refusal, no transport retry of writes, non-production write refusal, the shared rate cap, error-to-HTTP mapping, owner-only routes, post-commit nudge, dedicated-queue dispatch, unmapped members skipped when members are off, member chain when on, stale-session supersede, cancel with an absent class, conflict parking with a single owner alert, audited retry/dismiss/unlink, user search 0/1/many/aggregator-only, create-then-re-search, no double create after an uncertain create, bridge membership assign/verify/cancel, Arbox-priced memberships untouched, schedule import all-or-nothing, candidates (exact, ambiguous, confirm, reject), series ownership (no overwrite, no cancel, Arbox-only listing), coach push verification, managed-field guard, disconnect purge, DST gap. Web tests cover setup dependencies, bridge type and cancel reason, issues retry/dismiss, error codes through the dictionary, aggregator filtering, member unlink, candidates, series ownership and staff mapping.

Required live acceptance (not yet executed)

Use a disposable Arbox box with owner-authorized public v3 credentials and explicit permission to create test users, memberships and bookings. Never use session login, management routes or browser automation as an alternative. Outside production, ARBOX_SANDBOX_ALLOW must list the box.

1. Schedule: pagination terminates; native and Move/FreeFit identities, capacity, checked-in rows, overnight classes and a DST date import correctly; a class deleted in Arbox cancels only Arbox-owned sessions.
2. Members: a Taikan-only member is created once (repeat the op and simulate a lost response); an existing Arbox member with the same email or phone is linked, not duplicated; an identity with two Arbox records parks as a conflict. Record whether Arbox sends any email/SMS/push on user creation with send_welcome_email: false.
3. Bridge membership: assign creates exactly one ₪0 non-recurring membership; bookSession against it does not charge or decrement a priced membership; cancel with the selected reason ends only that membership. Record notifications and any Arbox-side counters.
4. Bookings: book, repeat the intent, simulate a lost response; confirm exactly one Arbox seat and the expected Move capacity change. Cancel after the ordinary cutoff with late_cancellation: false; check seat restoration, credits and penalties.
5. Conflict: fill a class externally between the Taikan booking and the mirror. The Taikan booking remains, the issue appears once, owners receive exactly one email and push.
6. Classes: coach push to a mapped staff member is visible in Arbox; a Taikan-created class retyped in Arbox becomes a candidate, confirm links it without a duplicate; a series switched to Taikan stops being overwritten and its Arbox-only occurrences are listed.
7. Operations: revoked key, disconnect, reconnect (returns to dry run), delayed retries, owner dismiss/retry. Confirm no phone numbers remain in stored rosters.
8. Record expected/actual results and box scope in TKN-259; obtain approval for the pilot and the pending migrations. Only then record the approved reference in settings and go live for that org.