Supported Scope

Requirement A consumer MUST select a size, a shape, one stack per frontend, and one backend stack unless the shape is client-only.

Rationale One size and explicit stacks tell every check which records and pages apply. The size decides which record types and test projects the project needs; each stack decides which technology pages and checks apply. Small needs the core types with Architecture and Integration test projects, while large adds problems, features, journeys, and cases with the Acceptance project. Each frontend declares react, svelte, or blazor.

Example A library catalog with one web frontend selects small with the svelte stack; a clinic booking system with journeys selects large.

The running library example declares large with a server shape and two stacks in litespec.project.json:

{
  "size": "large",
  "shape": "server",
  "stacks": ["dotnet", "svelte"],
  "optionalTypes": ["constraint", "research", "limit", "runbook"]
}

The size switches on the large record rows, the shape names a backend stack, and each stack switches on its technology pages, which satisfies this provision.

The three project choices and what each decides: size, shape, and stacks.

Requirement A consumer MUST keep one business language and deployment boundary.

Rationale Modules organize related language, models, use cases, and code without becoming independent services or bounded contexts.

Example Posts, Authors, and Comments can be modules in one publishing context.

Requirement A consumer MUST select every extension whose activation criteria apply, and no extension whose criteria do not.

Rationale Conditional capabilities stay inactive until a documented product or engineering condition applies. The manifest's extension list is the closed set a project selects from.

Example Caching, durable messaging, and multitenancy are extensions; the extension index lists each with its activation criteria.

Requirement A consumer MUST list every selected extension in selectedExtensions in litespec.project.json, each with its criterion and review date.

Rationale The project record determines which extension boundaries apply to its work.

Example

{ "id": "cache", "criterion": "catalog reads miss the latency target", "reviewBy": "2027-01-15" }

Requirement A consumer MUST state in litespec.project.json whether any outside constraint applies to the project.

Rationale An empty answer is a stated answer: it records that no outside rule binds the project.

Example A clinic booking system records that medical-device regulation does not apply to appointment scheduling.

Requirement A consumer with no server of its own MUST declare the client-only shape and record a decision naming the surfaces left without coverage.

Rationale The shape decides which backend pages still apply. A client-only product keeps a domain model, so it applies the backend architecture, domain, application, and identifier pages, which the manifest lists under shapes. Persistence, the HTTP API, and API testing have no target. Adding a server to obtain conformance contradicts litespec/core/principles#require-current-complexity-activation.

Example litespec/quality/ci#run-applicable-gates-on-every-pull-request already permits skipping a gate whose surface does not exist, so a missing backend gate is a recorded consequence rather than an unexplained absence.

Requirement A consumer MUST record a separate project decision for microservices, multiple contexts, native clients, other platforms, event sourcing, active-active regions, or large pipelines.

Rationale These architectures change the supported scope's assumptions and need their own boundaries.