# LiteSpec selection: Client-only with react

> A client-only project using the react frontend stack.

This index lists the pages the client-only.react selection applies, grouped by layer. Each entry links the page's raw Markdown.

## [Core, workspace and quality](https://litespec.dev/2.0.0/layers/core.md)

- [Agent Operating Protocol](https://litespec.dev/2.0.0/core/agent.md): This protocol controls how agents select context, resolve standards, preserve user work, and report completion. Agents query the project model for the records a task needs and read the generated agent context first.
- [Authoring Standard](https://litespec.dev/2.0.0/core/authoring.md): This page states how LiteSpec pages and consumer specification pages are written: the page styles, the provision contracts, the identifiers, the verification table, and the prose style. Prose follows the [Google developer documentation style guide](https://developers.google.com/style), with the few additions this page states. The structure rules are what `litespec validate` and `litespec consumer` check.
- [Maintaining the Standards](https://litespec.dev/2.0.0/core/maintaining.md): This page is the maintainer's manual for the LiteSpec repository itself. It states how a provision moves through its lifecycle. It states how an identifier rename is handled. It states how citations are written. It states how a LiteSpec release is published.
- [The Project Model](https://litespec.dev/2.0.0/core/model.md): Every project describes itself with records of fixed types joined by fixed links. People and agents write the intent records. The builder reads the code, screens, tests, and test runs, and computes the links between the two.
- [Engineering Principles](https://litespec.dev/2.0.0/core/principles.md): These principles resolve choices no narrower rule covers. They favor explicit intent, proven behavior, and evidence over speculative abstractions.
- [Product Intent](https://litespec.dev/2.0.0/core/product.md): This page governs where a consumer states its business intent and in what form. Business intent is what the product commits to as a business. It covers what the product sells, to whom, at what price, and in which markets. It also covers how the company runs and what comes next.
- [Release Standard](https://litespec.dev/2.0.0/core/release.md): A release joins deployed product behavior with evidence that a maintainer can operate it. One completed layer or passing test category does not meet this outcome.
- [Supported Scope](https://litespec.dev/2.0.0/core/scope.md): Every project selects one size, one shape, and its stacks, so agents can make concrete decisions without inventing architecture for every task. A stack applies the pages in its own folder and in every folder above it; a preset only fills in a common selection.
- [Stacks](https://litespec.dev/2.0.0/core/stacks.md): A stack is one technology's binding of the specification, held in one folder: a backend stack under `backend/`, a frontend stack under `frontend/`. Selecting a stack applies its folder and every folder above it, so a stack never restates an inherited principle ([Supported scope](scope.md)). Each stack folder holds a `stack.md` that states what the stack adds: its rules, its version pins, and its checks. These rules govern every stack selection.
- [LiteSpec](https://litespec.dev/2.0.0/core/system.md): LiteSpec coordinates software work with agents as active engineering participants. It combines records, architecture standards, agent protocols, implementation conventions, tests, operating controls, and release records.
- [Configuration](https://litespec.dev/2.0.0/workspace/config.md): Repository configuration should make builds repeatable and fail before a deployment starts with missing or invalid values. Version pins, compiler rules, environment access, and secret handling have one defined owner.
- [Dependencies](https://litespec.dev/2.0.0/workspace/dependencies.md): Layer dependencies and package ownership make the application boundary visible to review. Each layer accepts only the dependencies its owning provisions allow, and each project rejects packages introduced without a current requirement.
- [Naming and Code Style](https://litespec.dev/2.0.0/workspace/naming.md): Names should expose business intent and architectural role without requiring a reader to open the file. Fixed suffixes and file conventions reduce variation across agent sessions.
- [Workspace Structure](https://litespec.dev/2.0.0/workspace/structure.md): One canonical monorepo tree lets agents locate applications, shared packages, documentation, and tests without searching for a project-specific interpretation. The structure supports an API-only application, one frontend, or multiple frontends while retaining one bounded context.
- [Continuous Integration](https://litespec.dev/2.0.0/quality/ci.md): Continuous integration proves that a pull request preserves the selected standards, generated contracts, dependencies, and release artifacts. The workflow keeps slow deployment checks separate from fast local feedback while retaining one required merge gate.
- [Operations](https://litespec.dev/2.0.0/quality/operations.md): A released application is observable, deployable, recoverable, and supportable by one maintainer. Operating behavior is part of the use-case slice when code changes schema, external dependencies, background work, or failure recovery.
- [Security](https://litespec.dev/2.0.0/quality/security.md): Security boundaries follow identity, resource ownership, data classification, and trust transitions across API, persistence, frontend, external services, and operations. Authentication establishes identity. Each use case declares the permissions it needs, and the application guard authorizes from them.

## [Backend principles](https://litespec.dev/2.0.0/layers/backend.md)

- [Application Layer](https://litespec.dev/2.0.0/backend/application.md): Application coordinates use cases. It translates a command or query into Domain and persistence work, applies structural input validation, and returns a transport-neutral result. It does not contain HTTP behavior or provider implementations.
- [Backend Architecture](https://litespec.dev/2.0.0/backend/architecture.md): The backend is a five-part modular monolith. Part boundaries separate business rules, the contracts every layer names, use-case coordination, technical adapters, and HTTP hosting. They do not split each concern into a deployable unit.
- [Domain Layer](https://litespec.dev/2.0.0/backend/domain.md): Domain holds the business model and protects aggregate invariants. It references no persistence, HTTP, messaging, logging, configuration, injection, serialization, or provider concept. Its names match the Terms that its records use.
- [Record Identifiers](https://litespec.dev/2.0.0/backend/identifiers.md): Every record carries one identifier naming its type, home, and name. One form per type lets a reader find the record from the identifier alone, by reading or by searching.

## [Frontend principles](https://litespec.dev/2.0.0/layers/frontend.md)

- [Frontend Components](https://litespec.dev/2.0.0/frontend/components.md): One shared UI package holds everything a page draws with. It holds the shared primitives and the composites those primitives are assembled into.
- [Frontend Data and State](https://litespec.dev/2.0.0/frontend/data.md): The frontend holds no contract of its own. It calls the API through one generated client, reads every answer through its cache, and sends each write as a command.
- [UI Pattern Decisions](https://litespec.dev/2.0.0/frontend/patterns.md): Every recurring interface question is decided once and recorded in one catalog. Each entry holds the options considered, the option chosen, the compact-screen behavior, and the implementation per platform. Implementers build from the chosen option and extend the catalog rather than redrawing the pattern.
- [Frontend Rendering and Routes](https://litespec.dev/2.0.0/frontend/rendering.md): A route answers three questions: what address is this, what data does it need, and which floorplan draws it. Everything else belongs in a module.
- [Frontend Structure](https://litespec.dev/2.0.0/frontend/structure.md): A frontend holds three parts: a frame, routes, and use-case modules. The frame holds everything cross-cutting. The routes hold the addresses the frontend serves. The modules hold one folder per backend use case the frontend calls. Each frontend is one entry-point record.
- [Frontend Testing](https://litespec.dev/2.0.0/frontend/testing.md): Frontend tests prove behavior at the cheapest boundary that represents the risk. Each kind in the table below runs against a frontend, and each one answers one question.
- [Controlled UI Governance](https://litespec.dev/2.0.0/frontend/ui.md): The shared UI package is a constrained construction language. It provides the primitive source, the interaction behavior, the layout, and the tokens. A route names one floorplan and fills its slots from the domain. A route suite proves every route.

## [Web shared pages](https://litespec.dev/2.0.0/layers/frontend/web.md)

- [TypeScript Web Components](https://litespec.dev/2.0.0/frontend/web/components.md): This page states how the TypeScript web stacks realize the frontend component principles ([Frontend components](../components.md)). It states the registry source, the closed element list, and the visual file patterns. It also states the raw HTML sinks and the route suite checks the React and Svelte stacks share.
- [Web Data and State](https://litespec.dev/2.0.0/frontend/web/data.md): This page states how the TypeScript web frontends realize the Frontend data rules ([Frontend data](../data.md)). It states the generated client, the query cache behavior, and the tooling the React and Svelte stacks share. A provision here cites the neutral rule it realizes.
- [Web UI Pattern Decisions](https://litespec.dev/2.0.0/frontend/web/patterns.md): This page states how the TypeScript web group realizes the frontend pattern rules ([UI Pattern Decisions](../patterns.md)). It states the React and Svelte bindings and the widths one web implementation requires. A provision here cites the neutral rule it realizes.
- [Web Rendering and Routes](https://litespec.dev/2.0.0/frontend/web/rendering.md): This page states how the TypeScript web stacks realize the frontend rendering rules ([Frontend rendering](../rendering.md)). It states the loaders, queries, router files, and tooling the React and Svelte stacks share. Each realization cites the neutral rule it follows.
- [Web Structure](https://litespec.dev/2.0.0/frontend/web/structure.md): This page states how the TypeScript web stacks realize the Frontend structure rules ([Frontend structure](../structure.md)). It states the toolchain, folders, and commands the React and Svelte stacks share. A provision here cites the neutral rule it realizes, where one exists.
- [Web Testing](https://litespec.dev/2.0.0/frontend/web/testing.md): This page states how the TypeScript web stacks realize the frontend testing principles ([Frontend testing](../testing.md)). It states the runners, libraries, and commands one web frontend requires. A provision here cites the neutral rule it realizes.
- [Web UI](https://litespec.dev/2.0.0/frontend/web/ui.md): This page states how the TypeScript web stacks realize the frontend UI rules ([Frontend UI](../ui.md)). It states the toolchain, registry, tokens, and suites one web frontend requires. A provision here cites the neutral rule it realizes.

## [React stack](https://litespec.dev/2.0.0/layers/frontend/web/react.md)

- [React Components](https://litespec.dev/2.0.0/frontend/web/react/components.md): Components in a React frontend are function components with typed boundaries. The shared provisions live on the stack-neutral page ([Frontend components](../../components.md)). This page states what React alone requires.
- [React Stack](https://litespec.dev/2.0.0/frontend/web/react/stack.md): This stack serves a React frontend beside the product's backend stack. A React frontend takes one of three rendering modes, chosen by who reads it. An authenticated console is a static single-page application. A public surface whose pages are shared as links and read by a search engine renders on the server. A device client that asks one question repeatedly is a static page with no router. The shared stack rules on the [Stacks](../../../core/stacks.md) page apply to every stack.

## Extensions this selection may add

- [API Compatibility](https://litespec.dev/2.0.0/layers/ext/compat.md): OpenAPI freshness proves that committed artifacts match source code. It does not prove that independently deployed consumers can continue using the API.
- [Caching](https://litespec.dev/2.0.0/layers/ext/cache.md): Caching trades freshness and invalidation work for lower latency or source load. This extension requires measurement, a named staleness contract, and a recovery path.
- [Concurrency and Idempotency](https://litespec.dev/2.0.0/layers/ext/concurrency.md): Concurrency control protects invariants when accepted writes overlap. Idempotency protects an operation from duplicate execution after a retry or uncertain network response.
- [Data Lifecycle](https://litespec.dev/2.0.0/layers/ext/lifecycle.md): Retention, deletion, archival, and restore behavior follows the business and legal lifetime of data. This extension makes lifecycle work explicit without imposing soft delete.
- [Container Deployment](https://litespec.dev/2.0.0/layers/ext/containers.md): This extension defines image and rollout requirements for hosted environments that deploy immutable images. It supplements baseline release and operations standards.
- [External Integrations](https://litespec.dev/2.0.0/layers/ext/integrations.md): External systems are unreliable and outside application change control. This extension keeps provider details in Infrastructure, maps failures to project-owned outcomes, and tests network boundaries.
- [Audit Trail](https://litespec.dev/2.0.0/layers/ext/audit.md): An audit trail is evidence that one actor attempted one action against one target, and what the attempt produced. It answers who is accountable.
- [Localization](https://litespec.dev/2.0.0/layers/ext/locale.md): Localization makes routes, messages, formatting, metadata, and tests locale-aware while stored Domain values remain locale-neutral.
- [Model Context Protocol](https://litespec.dev/2.0.0/layers/ext/mcp.md): An MCP server presents the product's API to an LLM client running outside the product. The API provisions own the behavior the server calls. This page states how the server presents itself, describes its tools, and words its refusals.
- [Multitenancy](https://litespec.dev/2.0.0/layers/ext/tenancy.md): Multitenancy makes tenant identity part of authorization, persistence, caches, jobs, exports, diagnostics, and recovery. A tenant ID column alone does not provide isolation.
- [Outbox Worker](https://litespec.dev/2.0.0/layers/ext/outbox.md): The outbox makes a business commit and its required outgoing message durable in one database transaction. A Worker dispatches pending records with retry, idempotency, visibility, and safe replay.
- [Realtime Updates](https://litespec.dev/2.0.0/layers/ext/realtime.md): Realtime transport reduces visible update delay when polling cannot meet an accepted user requirement. Messages remain refresh hints unless a use case defines durable ordered delivery.
- [Reporting and Exports](https://litespec.dev/2.0.0/layers/ext/report.md): Reporting separates complex joins, aggregate analysis, and large exports from normal request projections when cost or duration exceeds the baseline read path.
- [Scheduled Jobs](https://litespec.dev/2.0.0/layers/ext/jobs.md): Scheduled work runs independently of HTTP requests and remains safe when replicas restart, overlap, or lose connectivity. This extension covers recurring and delayed jobs, not durable event dispatch.
- [Release Stage](https://litespec.dev/2.0.0/layers/ext/stage.md): A consumer passes through two release stages. Before the first deployment holds customer data, several provisions assume a service that does not exist yet. This extension declares the stage, bounds what the early stage defers, and records the promotion that ends it.
- [Agent Delegation](https://litespec.dev/2.0.0/layers/ext/delegation.md): One agent can hold a whole change in view. A fleet cannot hold it. Delegation needs written boundaries where one agent needs none. This extension states the brief, the containment, and the acceptance check.
- [Static Marketing Site](https://litespec.dev/2.0.0/layers/ext/site.md): A static marketing site presents the product to the public as pages that need no server. It serves people, search engines, and language models from one build.

## UI pattern groups

- [Admin Screen Patterns](https://litespec.dev/2.0.0/layers/patterns/admin-screens.md): Admin screens configure the back office itself. They cover the team and its roles, API keys and webhooks, data imports, the payment account, supplier invoices, and discount codes. These patterns answer how each screen is laid out. Each pattern offers drawn options and names a default.
- [Create, Edit and Remove Patterns](https://litespec.dev/2.0.0/layers/patterns/create-edit-remove.md): These patterns answer how a reader creates a record, changes one that exists, removes one or several, and changes something that has already happened. Each pattern offers drawn options and names a default.
- [Dialog and Overlay Patterns](https://litespec.dev/2.0.0/layers/patterns/dialogs-and-overlays.md): An overlay sits above the page: a dialog, a drawer, a popover, a menu, a toast, or a bar that stays in view. These patterns answer when each one fits and how it opens, holds focus, and closes. Each pattern shows its options as wireframes and names a default.
- [Feedback and State Patterns](https://litespec.dev/2.0.0/layers/patterns/feedback-and-states.md): A screen spends part of its life empty, loading, refused, offline, or failed. These patterns answer what shows in each of those states and how a command reports that it worked. Each pattern offers drawn options and names a default.
- [Form and Field Patterns](https://litespec.dev/2.0.0/layers/patterns/forms-and-fields.md): A form collects values you enter to create or change a record. These patterns answer how each kind of field takes its value and how a form reports a refused submit or unsaved work. Each pattern offers drawn options and names a default.
- [List and Table Patterns](https://litespec.dev/2.0.0/layers/patterns/lists-and-tables.md): A list or a table shows many records of one kind, so a reader can find, compare, and act on them. These patterns answer how columns, sorting, filters, selection, paging, and the states of a table behave. Each pattern offers drawn options and names a default.
- [Money, Time and Density Patterns](https://litespec.dev/2.0.0/layers/patterns/money-time-density.md): These patterns answer how a back office writes amounts, statements, moments, and periods. They also answer how many rows fit before a page breaks and how figures and charts read. Each pattern offers drawn options and names a default.
- [Navigation Patterns](https://litespec.dev/2.0.0/layers/patterns/navigation.md): Navigation is the frame around every page: the sidebar, the header, the breadcrumb, tabs, the command palette, and the account menu. These patterns answer how a reader moves through the back office and knows where they are. Each pattern offers drawn options and names a default.
- [Page Frame Patterns](https://litespec.dev/2.0.0/layers/patterns/page-frames.md): A page frame is the layout of one kind of page. It covers a home page, a list, a queue, a record, a form, a report, a settings page, or an outcome. These patterns answer how each kind of page is laid out. Each pattern offers drawn options and names a default.
- [Record Detail Patterns](https://litespec.dev/2.0.0/layers/patterns/record-detail.md): A record detail page shows one business record, such as an order, a customer, or a product. It shows its state, its facts, its history, and the commands a reader may run on it. These patterns answer the recurring questions of that page. Each pattern offers drawn options and names a default.

## How to read this

Fetch the pages a task touches, not all of them. Start with the page that owns the decision, then follow its links. When a task spans a whole layer, each section heading links the layer bundle that carries the same text in fewer requests.