> ## Documentation Index
> Fetch the complete documentation index at: https://docs.highailabs.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Weekly Feature Regression

> The weekly Tier A/B/C regression run — lanes, how to reproduce it locally, and why its schedule is still off.

## 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`.

| Lane            | What runs                                                          | Wall clock |
| --------------- | ------------------------------------------------------------------ | ---------- |
| `tiers-ab-only` | Tier A + Tier B only. No secrets, no spend                         | \~2 min    |
| `tier-c-fast`   | Tier A/B, then Tier C smoke plus everything **not** tagged `@slow` | \~10 min   |
| `tier-c-full`   | Tier A/B, then Tier C smoke plus the full Tier C suite             | 30–60 min  |
| `all`           | Same as `tier-c-full`                                              | 30–60 min  |

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.

```bash theme={null}
gh workflow run feature-regression.yml -f lanes=tier-c-fast -f paid=false
gh run watch
```

<Note>
  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.
</Note>

## 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.

<Warning>
  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.
</Warning>

## Reproducing a run locally

The same commands the workflow runs, from `apps/mobile`:

```bash theme={null}
# Tier A/B — free, hermetic
pnpm --filter @highiq/mobile test:convex
pnpm --filter @highiq/mobile test:unit
pnpm --filter @highiq/mobile test:ui

# Tier C — billed, hits the shared staging deployment
pnpm --filter @highiq/mobile test:integration:smoke  # gate: is the harness healthy?
pnpm --filter @highiq/mobile test:integration:fast   # everything not @slow
pnpm --filter @highiq/mobile test:integration        # full suite
```

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

<Steps>
  <Step title="Check nothing else is in flight">
    ```bash theme={null}
    gh run list --workflow feature-regression.yml --status in_progress
    ```

    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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Confirm main is green before filing anything">
    ```bash theme={null}
    gh run list --branch main --limit 1
    ```

    A red baseline makes triage meaningless — record findings locally and stop.
  </Step>
</Steps>

## 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](/planning/testing/feature-test-platform#interpreting-results).

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:

```bash theme={null}
gh issue list --label feature-regression --state open --limit 50
```

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.

## Related

<CardGroup cols={2}>
  <Card title="Test Platform Overview" icon="vials" href="/planning/testing/feature-test-platform">
    The three tiers and how to add a test for a new feature.
  </Card>

  <Card title="Tier C — Staging Integration" icon="plug-circle-check" href="/planning/testing/tier-c-staging-integration">
    Guard, identity model, tags, and cost controls.
  </Card>
</CardGroup>