# FAQ

## Why does this starter use custom frontend lint/format scripts instead of heavy npm dependencies?

The kickoff scaffold is intentionally lightweight and keeps only strictly relevant tooling:

- API client generation from the OpenAPI contract
- TypeScript compilation for frontend source files
- basic frontend contract checks
- deterministic formatting checks used by `scripts/ci-local.ps1`

This keeps the first commit small while preserving CI discipline. Additional tooling can be introduced when the frontend stack is finalized.

## Is frontend JavaScript handwritten?

No. Frontend source code lives in `RpgRoller/frontend/*.ts` and is compiled to `RpgRoller/wwwroot/*.js` for browser delivery.

## Where is backend state stored locally?

Backend state is persisted via EF Core + SQLite.

- Development default: `RpgRoller/App_Data/rpgroller.development.db`
- Non-development default: `RpgRoller/App_Data/rpgroller.db`

To start with a clean backend state, stop the app and remove the corresponding SQLite file.

## Does the backend read SQLite on every API call?

No. The backend loads state from SQLite once during startup into in-memory state and serves requests from memory. Successful state mutations are then written back to SQLite.

## What does test coverage include?

Coverage now includes the entire backend project (`RpgRoller`), including API/hosting/bootstrap code and services. It is no longer restricted to `RpgRoller.Services.*`.

## Why do backend services use `*Command` types instead of API request DTOs?

Service workflows now consume service-layer command models (for example, `CreateCampaignCommand`) so endpoint transport contracts stay isolated in the API layer. This reduces coupling and keeps service code reusable when input shapes evolve at the HTTP boundary.