Skip to main content

​
What the routine does

Once a week the whole mobile feature test platform is run end to end: Tier A (convex-test), Tier B (vitest jsdom + jest-expo), and Tier C (staging integration). It is report-only. The run itself never opens a pull request. Failures become one GitHub issue per distinct failure, and a fully green run files nothing and commits nothing.

​
Lanes

CI is the Feature Regression (mobile, Tier A/B/C) workflow at .github/workflows/feature-regression.yml. A separate paid boolean input admits the opt-in paid cases (cold dispensary menu scans and the large order-archive seeds). It defaults to off — leave it off unless the run is specifically about those cases.
Tier C skips cleanly in CI when its Clerk secret is absent — a notice and a step summary, not a failure. The preflight gate keys on that one secret; the remaining secrets each gate a narrower set of cases (Trigger.dev polling, the admin runner, the Gmail lane) and their absence produces tracked skips.

​
The schedule is intentionally off

The workflow is workflow_dispatch only. The schedule: block exists in the file but is commented out, part of the automation stand-down that paused every recurring routine.
Do not enable the cron until three consecutive green manual runs have proven the lane. A scheduled job that files issues from an unstable harness trains everyone to ignore it — and a Tier C run costs real money every time it fires.

​
Reproducing a run locally

The same commands the workflow runs, from apps/mobile:
Set the paid opt-in only when you specifically want those cases. Selecting by tag works anywhere Vitest’s -t does, because tags live in test titles: @smoke, @slow, @ai, @trigger, @shared-account, @P0–@P3.

​
Before you start a Tier C run

1

Check nothing else is in flight

Staging is shared and the suite asserts on rows it owns. CI serializes itself with a non-cancelling concurrency group, but that does not protect against a developer running Tier C locally at the same time — ask first.
2

Check the Revyl order-import workflow is idle

The Gmail lane and that workflow drive the same mailbox and the same per-user queue. Overlapping runs produce failures indistinguishable from product bugs.
3

Run the smoke suite first

Under 30 seconds, no spend. A lane failure after a green smoke is a product signal; a lane failure after a red smoke is a harness or configuration signal.
4

Confirm main is green before filing anything

A red baseline makes triage meaningless — record findings locally and stop.

​
Reading and reporting a run

Report four separate counts per tier: pass, fail, skipped-blocked, and skipped-paid. Collapsing skips into “not failing” is how a run with a dead pipeline still looks green. Status meanings are listed in the Test Platform Overview. The weekly summary records:
  • the lane and inputs used, plus the workflow run URL;
  • the four counts per tier;
  • every issue filed and every existing issue re-confirmed;
  • cost attribution — Trigger.dev runs created and total AI spend.

​
Filing failures

One issue per distinct failure. Search for an existing open issue before filing and comment on it rather than opening a second:
Each issue names the case ID and tier, the suite file, the exact command, the run URL, and the failing assertion verbatim. If a fix is obvious and small, that is a separate, normal pull request referencing the issue — never a PR from the routine run itself.

Test Platform Overview

The three tiers and how to add a test for a new feature.

Tier C — Staging Integration

Guard, identity model, tags, and cost controls.