Domains

Domains partition work by technology surface (api, web, mobile, db, cloud, game).

A domain is a slice of a run scoped to one technology surface. Splitting work by domain is what lets Pipemason make progress on several surfaces at once — the architect, TDD, and implement phases each run in parallel by domain — while keeping the boundaries between them explicit.

App and service domains

These cover the building blocks of a typical application or service:

Domain	Surface
`api`	Backend services and HTTP / RPC endpoints
`web`	Web front-end UI
`db`	Schema, migrations, and data access
`mobile`	Native or cross-platform mobile apps
`cloud`	Infrastructure and deployment surface

Game domains

Game work has its own domains for the platforms a title can ship to:

game-mobile — native mobile games
game-rn — cross-platform (React Native) games
game-windows, game-mac — desktop targets
game-xr — visionOS / Quest XR targets
game-console — console targets

How domains shape a run

The set of active domains determines which phases a run executes. Domains with a user interface — web, mobile, and the game and XR domains — add the end-to-end, UI, and screenshot-diff phases to a run. A run with no UI domain (for example, an api-only change) skips those phases and goes straight from implement to verify.

Note

Contracts between domains are frozen before parallel work begins, so independent domain agents cannot drift into incompatible assumptions about each other's boundaries.

Parallelism by domain

Because each active domain works on its own slice, the architect, TDD, and implement phases fan out across domains and run concurrently. The run only advances to the next phase once every active domain has met that phase's gate, keeping the surfaces in step with one another.

Choosing domains

Active domains come from your project's configuration in .pipeline/config.yml. Pipemason only runs work for the domains your project actually uses, so an api-and-web project never spends effort on mobile or game surfaces.