Project areas

What this controls#

Project areas group repository paths into dashboard-level concepts such as Web, Checkout, API, or Engagement.

Areas affect summary metrics, charts, testing levels, churn, timeline changes, tests, files, and contributors. The global area filter is independent from the framework filter.

Project areas do not change test discovery.

Automatic behaviour#

Test Chronicle detects direct children beneath these common monorepo roots:

• apps/*
• packages/*
• services/*
• libs/*

Automatic areas are shown only when at least two meaningful areas exist. Ordinary single-project repositories therefore keep an uncluttered dashboard.

Examples:

apps/web/**        → Web
apps/admin/**      → Admin
packages/cart/**   → Cart
services/api/**    → API

Area precedence#

Paths are classified in this order:

1. Saved area rules, from top to bottom.
2. Automatically detected monorepo areas.
3. Other, when areas exist but a path matches none of them.

The first matching saved rule wins. Put narrower patterns before broader patterns.

When to add an override#

Save a custom area rule when you need to:

• Rename an automatically detected package.
• Combine several applications or packages into one product area.
• Group paths outside the automatic monorepo roots.
• Create an explicit E2E area for a top-level Playwright directory.
• Control precedence where repository paths overlap.

Configure project areas#

Open Project Settings → Project areas.

1. Review saved rules first.
2. Search the detected suggestions.
3. Select Configure to prefill an editable rule from a suggestion.
4. Change its label or add comma-separated path patterns.
5. Reorder or merge rules where needed.
6. Save project areas.

The dashboard reclassifies current specs and stored historical changes after saving. Another sync is not required.

Matching and historical paths#

Area patterns are repository-relative and case-insensitive.

• * matches one path segment.
• ** matches recursively.
• ? matches one non-separator character.

Deleted files can still be classified from the repository path stored with their historical test change. This means an area-filtered timeline can retain deleted-file activity even when the current spec no longer exists.

Renaming and merging areas#

Renaming changes the display label while the area's stable ID remains attached to its saved rule.

Merging combines the selected rule's patterns into the previous rule. Because rules are first-match, review their order after combining broad patterns.

apps/storefront/**
packages/catalog/**
packages/cart/**

These paths can be saved as one Commerce area.

Cross-area commits#

A commit may contain changes from several areas. The timeline keeps the original commit context while filtered totals count only changes matching the active area.

Commit headers show deterministic area pills and an overflow count when several areas were touched. Expanded changes show their own area label.

Framework filter interaction#

Area and framework filters are combined. Selecting Vitest and Cart shows only Vitest specs and changes classified as Cart.

Some frameworks do not naturally follow product-area paths. A top-level Playwright suite such as e2e/** may:

• Appear as Other when package areas already exist.
• Produce no area filter when it is the only meaningful path group.
• Be assigned to a saved E2E area with e2e/**.
• Be combined with product areas when its paths contain product context, such as e2e/cart/**.

Area options with no files for the selected framework are hidden.

Reset and troubleshoot#

Select Reset to automatic, then save, to remove all saved area rules.

If an area is missing or empty:

1. Confirm there are at least two meaningful areas.
2. Check rule order and broad patterns.
3. Inspect the current framework filter.
4. Verify paths are relative to the repository root.
5. Look for unmatched files under Other.

SyncConfig fragment#

{
  "projectAreaMappings": [
    {
      "id": "commerce",
      "label": "Commerce",
      "patterns": [
        "apps/storefront/**",
        "packages/catalog/**",
        "packages/cart/**"
      ]
    },
    {
      "id": "e2e",
      "label": "E2E",
      "patterns": ["e2e/**"]
    }
  ]
}

IDs are stable internal identifiers. Labels must be unique and every saved area needs at least one path pattern.