Browse pages
Provisions
Use this generated page to resolve a provision ID to its heading, owning page, and verification mark.
Intent#
Use this generated page to resolve a provision ID to its heading, owning page, and verification mark.
Run litespec provisions after any provision change. The repository validator fails when this page and the active standards disagree.
The active release states 1249 provisions across 6 areas.
backend#
| ID | Provision | Kind | Mark | Evidence |
|---|---|---|---|---|
| litespec/backend/api#apply-only-coarse-policies-at-the-endpoint | Apply only coarse policies at the endpoint | rule | guidance | Does any endpoint decide target authorization instead of enforcing coarse policies? |
| litespec/backend/api#apply-patch-to-a-partial-update | Apply PATCH to a partial update | rule | guidance | Does each partial update use PATCH with merge-patch media? |
| litespec/backend/api#avoid-noise-words-in-field-names | Avoid noise words in field names | convention | guidance | Does any field name carry a type prefix or noise word? |
| litespec/backend/api#bound-collection-queries | Bound collection queries | rule | guidance | Do collection endpoints order deterministically within default and maximum limits? |
| litespec/backend/api#commit-the-generated-contract-its-consumers-read | Commit the generated contract its consumers read | rule | guidance | Is the generated artifact committed and current for each consumer? |
| litespec/backend/api#declare-a-smaller-collection-maximum | Declare a smaller collection maximum | convention | guidance | Does each lowered maximum name its value and reason? |
| litespec/backend/api#declare-stable-operation-metadata-in-the-contract | Declare stable operation metadata in the contract | rule | guidance | Does each operation declare its operationId, metadata, and summary? |
| litespec/backend/api#defer-error-mapping-to-the-global-handler | Defer error mapping to the global handler | rule | guidance | Does any endpoint catch an Application or Domain exception? |
| litespec/backend/api#expose-development-tooling-in-development-only | Expose development tooling in Development only | rule | guidance | Do Scalar and development tooling map in Development only? |
| litespec/backend/api#generate-the-contract-without-hosted-dependencies | Generate the contract without hosted dependencies | convention | guidance | Does generation avoid hosted dependencies with its answer recorded? |
| litespec/backend/api#keep-endpoint-dependencies-transport-focused | Keep endpoint dependencies transport-focused | rule | guidance | Does any endpoint take a Domain repository, session, context, provider, or service? |
| litespec/backend/api#keep-numeric-transport-types-precise | Keep numeric transport types precise | convention | guidance | Does each numeric field publish a plain schema except large int64 unions? |
| litespec/backend/api#keep-routes-resource-oriented | Keep routes resource-oriented | rule | guidance | Do routes use plural segments, kebab subresources, and body command data? |
| litespec/backend/api#map-one-operation-per-endpoint | Map one operation per endpoint | rule | guidance | Does each mapped route resolve to one endpoint type and one mediator dispatch? |
| litespec/backend/api#mark-polymorphic-models-with-discriminators | Mark polymorphic models with discriminators | rule | guidance | Does each data-bearing set publish oneOf with a string discriminator? |
| litespec/backend/api#mirror-a-domain-closed-set-as-a-transport-model-of-the-same-shape | Mirror a Domain closed set as a transport model of the same shape | rule | guidance | Does each transport model preserve its Domain set shape? |
| litespec/backend/api#model-a-monetary-value-as-one-object | Model a monetary value as one object | convention | guidance | Does each monetary value travel as one Money object? |
| litespec/backend/api#name-boolean-fields-as-conditions | Name boolean fields as conditions | convention | guidance | Does each boolean field use the camel-case condition name? |
| litespec/backend/api#name-failure-pairs-code-and-reason | Name failure pairs code and reason | convention | guidance | Does each request failure name code for the class and reason? |
| litespec/backend/api#name-path-parameters-per-resource | Name path parameters per resource | convention | guidance | Does each path parameter name its own resource identity? |
| litespec/backend/api#name-routes-from-resources | Name routes from resources | convention | guidance | Does each route derive from its resource with action segments justified? |
| litespec/backend/api#name-time-fields-with-at | Name time fields with At | convention | guidance | Does each time field end in At? |
| litespec/backend/api#name-transport-types-by-their-boundary-role | Name transport types by their boundary role | convention | guidance | Does each transport type carry the suffix its role assigns? |
| litespec/backend/api#publish-label-only-sets-as-string-enums | Publish label-only sets as string enums | rule | guidance | Does each label-only set publish a string enum? |
| litespec/backend/api#publish-precise-complete-schemas | Publish precise, complete schemas | rule | guidance | Does each schema declare its value set, bounds, format, and control headers? |
| litespec/backend/api#record-each-results-http-status | Record each result's HTTP status | rule | checkable | litespec model check reports result-status. |
| litespec/backend/api#reflect-enforced-authentication-in-the-contract | Reflect enforced authentication in the contract | rule | guidance | Does each authenticated operation declare its security scheme and requirement? |
| litespec/backend/api#reject-a-collapsed-or-borrowed-wire-contract | Reject a collapsed or borrowed wire contract | rule | guidance | Does any transport model collapse a set or reuse an inner type? |
| litespec/backend/api#require-the-marker-header-on-cookie-authenticated-writes | Require the marker header on cookie-authenticated writes | rule | guidance | Does a cookie-authenticated write without the marker header answer 401? |
| litespec/backend/api#return-stable-problem-details | Return stable Problem Details | rule | guidance | Does each error response carry code, traceId, and field errors? |
| litespec/backend/api#state-an-unexpressible-transition-as-a-custom-method | State an unexpressible transition as a custom method | rule | guidance | Does each unexpressible transition use POST with a colon-suffixed verb? |
| litespec/backend/api#treat-openapi-as-a-generated-contract | Treat OpenAPI as a generated contract | rule | guidance | Does the release build regenerate the OpenAPI artifact, with the gate failing on a changed tree? |
| litespec/backend/api#use-consistent-status-codes | Use consistent status codes | rule | guidance | Does each operation return its outcome-table status code? |
| litespec/backend/api#use-offsets-for-proven-bounded-datasets | Use offsets for proven bounded datasets | convention | guidance | Does each offset page cite the bound making it safe? |
| litespec/backend/api#use-opaque-cursors-for-collection-paging | Use opaque cursors for collection paging | rule | guidance | Does a malformed cursor answer 400 with code invalid_cursor? |
| litespec/backend/api#use-put-for-a-whole-replacement | Use PUT for a whole replacement | rule | guidance | Does each PUT replace the whole resource its path names? |
| litespec/backend/api#use-standard-field-vocabulary | Use standard field vocabulary | convention | guidance | Does each field use the standard vocabulary over its rejected synonym? |
| litespec/backend/api#use-this-endpoint-layout | Use this endpoint layout | convention | guidance | Does each endpoint folder match its module, aggregate, and use case? |
| litespec/backend/api#version-cursors-with-stable-sort-values | Version cursors with stable sort values | rule | guidance | Does each cursor carry a version, stable sort values, and no readable secret? |
| litespec/backend/application#declare-a-port-where-its-consumers-meet | Declare a port where its consumers meet | rule | guidance | Does each port sit at the lowest folder holding its consumers? |
| litespec/backend/application#declare-every-pipeline-position-beside-the-message | Declare every pipeline position beside the message | rule | guidance | Does each message declare a value or exemption for every required position? |
| litespec/backend/application#define-narrow-external-ports | Define narrow external ports | rule | guidance | Does each port name its business action with project-owned types? |
| litespec/backend/application#dispatch-commands-and-queries-through-separate-entry-points | Dispatch commands and queries through separate entry points | rule | guidance | Does each dispatch site call its own command or query entry point? |
| litespec/backend/application#enforce-target-authorization-in-the-pipeline | Enforce target authorization in the pipeline | rule | guidance | Does the pipeline suite assert that every target has a guard and no handler authorizes itself? |
| litespec/backend/application#keep-command-handlers-narrow | Keep command handlers narrow | rule | guidance | Does the pipeline stage suite assert that no handler commits, audits, or authorizes? |
| litespec/backend/application#keep-event-reaction-implementations-explicit | Keep event reaction implementations explicit | rule | guidance | Does each reaction declare exactly one classification it honors? |
| litespec/backend/application#keep-mappings-at-the-owning-boundary | Keep mappings at the owning boundary | convention | guidance | Does each conversion live in the layer owning its output shape? |
| litespec/backend/application#keep-messages-immutable | Keep messages immutable | convention | guidance | Is each message, result, and validation error a record? |
| litespec/backend/application#keep-one-state-changing-use-case-in-one-pipeline | Keep one state-changing use case in one pipeline | rule | guidance | Does any command handler dispatch another command through the command pipeline? |
| litespec/backend/application#mirror-a-domain-closed-set-in-the-result | Mirror a Domain closed set in the result | rule | guidance | Does each result union carry one record per Domain case? |
| litespec/backend/application#model-expected-use-case-failures-explicitly | Model expected use-case failures explicitly | rule | guidance | Does each expected failure throw its typed exception with its Result code? |
| litespec/backend/application#organize-application-by-operation | Organize Application by operation | rule | guidance | Does each operation folder hold its message, result, validator, handler, and definition? |
| litespec/backend/application#project-queries-directly | Project queries directly | rule | guidance | Does each query handler project to its result without loading an aggregate? |
| litespec/backend/application#record-a-decision-for-closed-set-narrowing | Record a decision for closed-set narrowing | rule | guidance | Does each narrowed set name its decision and updated specification? |
| litespec/backend/application#report-input-problems-as-validity-findings | Report input problems as validity findings | rule | guidance | Does each validator report validity findings with member, code, and message failures? |
| litespec/backend/application#return-use-case-results | Return use-case results | convention | guidance | Does each result return only values the caller needs? |
| litespec/backend/application#separate-input-validation-from-invariants | Separate input validation from invariants | rule | guidance | Does each validator check only structural input and defer state decisions? |
| litespec/backend/application#use-this-operation-layout | Use this operation layout | convention | guidance | Does each operation path match its module, aggregate, and use case? |
| litespec/backend/architecture#compose-each-process-explicitly | Compose each process explicitly | rule | guidance | Does each host register its own services without building a second provider? |
| litespec/backend/architecture#create-a-worker-project-when-background-work-needs-its-own-process | Create a Worker project when background work needs its own process | rule | guidance | Does background work needing its own process run in a Worker project? |
| litespec/backend/architecture#declare-the-execution-host-for-work-that-outlives-a-request | Declare the execution host for work that outlives a request | rule | guidance | Which Decision names the execution host for dispatch, queue consumption, and scheduled work? |
| litespec/backend/architecture#keep-business-invariants-in-domain | Keep business invariants in Domain | rule | guidance | Does every state transition run inside its aggregate or value object? |
| litespec/backend/architecture#keep-implementation-types-hidden | Keep implementation types hidden | rule | guidance | Is every handler, validator, definition, and endpoint implementation hidden and closed? |
| litespec/backend/architecture#keep-one-application-part | Keep one Application part | rule | guidance | Does one Application part hold every message, handler, and module-owned port? |
| litespec/backend/architecture#keep-service-registration-in-hosts | Keep service registration in hosts | convention | guidance | Does all service registration live in hosts and host modules? |
| litespec/backend/architecture#organize-every-layer-by-module-and-use-case | Organize every layer by module and use case | rule | guidance | Does each layer folder path resolve to a declared module and aggregate? |
| litespec/backend/architecture#own-each-layers-contract-types | Own each layer's contract types | rule | guidance | Does each layer define its own contracts apart from kernel values and typed IDs? |
| litespec/backend/architecture#place-a-type-at-the-lowest-folder-that-holds-its-consumers | Place a type at the lowest folder that holds its consumers | rule | guidance | Does each type sit at the lowest folder holding its consumers, with no banned folder name? |
| litespec/backend/architecture#point-dependencies-inward | Point dependencies inward | rule | guidance | Does every project reference point toward Domain without an outward edge? |
| litespec/backend/architecture#separate-command-and-query-behavior | Separate command and query behavior | rule | guidance | Do commands mutate through repositories while queries project without aggregates? |
| litespec/backend/architecture#test-structural-boundaries | Test structural boundaries | rule | guidance | Do the architecture tests prove references, packages, visibility, folders, and inheritance? |
| litespec/backend/architecture#use-five-application-parts | Use five application parts | rule | guidance | Does the solution hold exactly the five baseline parts? |
| litespec/backend/domain#align-id-representations-at-every-boundary | Align ID representations at every boundary | convention | guidance | Is each identifier represented the same way at every boundary in the table? |
| litespec/backend/domain#create-valid-aggregates-through-named-factories | Create valid aggregates through named factories | rule | guidance | Does each aggregate root create instances only through a named static factory that checks identity and records events? |
| litespec/backend/domain#define-collection-value-semantics-explicitly | Define collection value semantics explicitly | rule | guidance | Does each collection value implement content equality and a matching hash under its ordering rule? |
| litespec/backend/domain#describe-every-public-domain-contract-in-documentation | Describe every public Domain contract in documentation | rule | guidance | Does every public Domain type and member document its constraint, result, or failure? |
| litespec/backend/domain#expose-repositories-for-one-aggregate-only | Expose repositories for one aggregate only | rule | guidance | Does each repository serve one aggregate with Domain-only types and no queryable, session, or generic surface? |
| litespec/backend/domain#express-transitions-through-business-methods | Express transitions through business methods | rule | guidance | Does each mutation check state, and does each lifecycle move also replace state and record its event? |
| litespec/backend/domain#identify-aggregates-with-strongly-typed-version-7-values | Identify aggregates with strongly typed version 7 values | rule | guidance | Is each identity a dedicated type over a version 7 UUID with no conversion, alias, or parameterless creation? |
| litespec/backend/domain#keep-binary-floating-point-out-of-exact-quantities | Keep binary floating point out of exact quantities | rule | guidance | Does no Domain member use double or float for money, a rate applied to money, or an exactly compared quantity? |
| litespec/backend/domain#keep-child-entities-inside-the-aggregate-boundary | Keep child entities inside the aggregate boundary | rule | guidance | Do children expose no mutable state outside their root, with collections surfaced as read-only views? |
| litespec/backend/domain#keep-domain-independent-of-outer-layers | Keep Domain independent of outer layers | rule | guidance | Does Domain code reference only the standard library and project-owned Domain types? |
| litespec/backend/domain#model-every-aggregate-lifecycle-with-state-types | Model every aggregate lifecycle with state types | rule | guidance | Does each aggregate expose one state property over a closed hierarchy of state types? |
| litespec/backend/domain#model-every-closed-set-of-domain-values-as-a-closed-type-hierarchy | Model every closed set of domain values as a closed type hierarchy | rule | guidance | Is each closed set a type hierarchy with stable codes and a named label lookup? |
| litespec/backend/domain#model-money-with-exact-decimal-values | Model money with exact decimal values | rule | guidance | Is each monetary amount an exact decimal in the shared Money object with the stated JSON shape? |
| litespec/backend/domain#organize-a-module-by-aggregate-and-concept | Organize a module by aggregate and concept | convention | guidance | Does each Domain module give each aggregate its plural folder with its own states, events, and concepts? |
| litespec/backend/domain#pass-nondeterministic-values-into-domain | Pass nondeterministic values into Domain | rule | guidance | Does Domain receive time, randomness, and identifiers as arguments and read no clock? |
| litespec/backend/domain#raise-immutable-facts-as-domain-events | Raise immutable facts as domain events | rule | guidance | Is each domain event an immutable event named for its aggregate and fact, carrying business data only? |
| litespec/backend/domain#reference-other-aggregates-by-id | Reference other aggregates by ID | rule | guidance | Does each aggregate store other aggregates as typed identifiers rather than object references? |
| litespec/backend/domain#reject-business-violations-with-dedicated-errors | Reject business violations with dedicated errors | rule | guidance | Does each rejected rule fail with its own error type carrying a stable code and no transport status? |
| litespec/backend/domain#reuse-the-shared-domain-contracts-across-modules | Reuse the shared Domain contracts across modules | convention | guidance | Is each shared Domain contract declared once and reused across modules? |
| litespec/backend/domain#take-identity-and-events-from-the-project-root-contract | Take identity and events from the project root contract | rule | guidance | Does each aggregate root inherit the one base type that supplies its identifier and its pending events? |
| litespec/backend/domain#treat-aggregates-as-consistency-boundaries | Treat aggregates as consistency boundaries | rule | guidance | Is each aggregate root the only public mutation path for the invariants its transaction protects? |
| litespec/backend/domain#use-immutable-value-objects-for-domain-concepts | Use immutable value objects for domain concepts | rule | guidance | Is each value object immutable, compared by complete value, and created through a static method? |
| litespec/backend/domain#use-one-ubiquitous-language | Use one ubiquitous language | rule | guidance | Does each Domain name match a Term record in the project language record? |
| litespec/backend/domain#use-stateless-domain-services-for-ownerless-rules | Use stateless domain services for ownerless rules | rule | guidance | Is each domain service stateless, confined to Domain values, and free of the banned calls? |
| litespec/backend/domain#use-these-domain-names | Use these Domain names | convention | guidance | Does each Domain name follow the cited workspace naming provisions and the chosen state-case form? |
| litespec/backend/dotnet/api#declare-operation-metadata-in-the-contract | Declare operation metadata in the contract | rule | guidance | Does each operation declare its operationId, metadata, typed results, and summary? |
| litespec/backend/dotnet/api#exclude-mvc-controllers-from-the-stack | Exclude MVC controllers from the stack | rule | checkable | dotnet build of the WebApi project reports no LiteSpec.Analyzers LS2003 diagnostic. |
| litespec/backend/dotnet/api#keep-programcs-as-composition | Keep Program.cs as composition | convention | guidance | Does Program.cs hold only composition in the recorded order? |
| litespec/backend/dotnet/api#mark-polymorphic-transport-models-with-discriminators | Mark polymorphic transport models with discriminators | rule | guidance | Does each data-bearing set map to sealed records published as oneOf with a string discriminator? |
| litespec/backend/dotnet/api#use-one-endpoint-per-operation | Use one endpoint per operation | rule | guidance | Does each mapped route resolve to one IEndpoint type and one mediator dispatch? |
| litespec/backend/dotnet/application#keep-one-state-changing-use-case-in-one-command-pipeline | Keep one state-changing Use case in one Command pipeline | rule | checkable | dotnet build of the Application project reports no LiteSpec.Analyzers LS2002 diagnostic. |
| litespec/backend/dotnet/application#report-input-problems-as-validity | Report input problems as Validity | rule | guidance | Does each validator report Validity with member, code, and message failures? |
| litespec/backend/dotnet/application#use-the-pinned-mediator-entry-points | Use the pinned mediator entry points | convention | guidance | Does each dispatch site call the pinned mediator entry points? |
| litespec/backend/dotnet/architecture#keep-composition-in-hosts | Keep composition in hosts | convention | guidance | Does all service registration live in hosts and host modules? |
| litespec/backend/dotnet/architecture#keep-implementation-types-internal | Keep implementation types internal | rule | guidance | Is every handler, validator, definition, and endpoint implementation internal and sealed? |
| litespec/backend/dotnet/architecture#keep-one-application-assembly | Keep one Application assembly | rule | guidance | Does one Application project hold every message, handler, and module-owned port? |
| litespec/backend/dotnet/architecture#use-five-application-projects | Use five application projects | rule | guidance | Does the solution hold exactly the five baseline projects? |
| litespec/backend/dotnet/architecture#use-one-public-assembly-marker-per-scanned-project | Use one public assembly marker per scanned project | convention | guidance | Does each scanned project expose exactly one public assembly marker? |
| litespec/backend/dotnet/config#centralize-net-build-settings | Centralize .NET build settings | rule | guidance | Does Directory.Build.props set the manifest target framework, nullable types, implicit usings, and warnings as errors? |
| litespec/backend/dotnet/config#centralize-nuget-versions | Centralize NuGet versions | rule | guidance | Does Directory.Packages.props enable central management with the manifest pins, and do projects omit versions? |
| litespec/backend/dotnet/config#commit-the-tool-manifest | Commit the tool manifest | rule | guidance | Does .config/dotnet-tools.json pin each local tool a documented command invokes? |
| litespec/backend/dotnet/config#set-the-sdk-floor-at-the-workspace-root | Set the SDK floor at the workspace root | rule | guidance | Does the root global.json set the manifest major release's first feature band, such as 10.0.100, with latestMajor roll-forward? |
| litespec/backend/dotnet/config#validate-backend-options-at-startup | Validate backend options at startup | rule | guidance | Does each configuration section bind a validated options class that fails startup on bad values? |
| litespec/backend/dotnet/domain#define-the-shared-domain-contracts-once | Define the shared Domain contracts once | convention | guidance | Is each shared Domain contract declared once, with DomainException declaring its abstract Code? |
| litespec/backend/dotnet/domain#document-every-public-domain-contract | Document every public Domain contract | rule | checkable | dotnet build of the Domain project reports no LiteSpec.Analyzers LS1011 diagnostic. |
| litespec/backend/dotnet/domain#keep-domain-free-of-outer-layer-concerns | Keep Domain free of outer-layer concerns | rule | guidance | Does the Domain assembly reference only the base class library and project-owned Domain types? |
| litespec/backend/dotnet/domain#keep-id-representations-aligned-at-every-boundary | Keep ID representations aligned at every boundary | convention | guidance | Is each identifier represented the same way at every boundary in the table? |
| litespec/backend/dotnet/domain#keep-repository-interfaces-in-domain | Keep repository interfaces in Domain | rule | guidance | Does each repository serve one aggregate with Domain-only types and no IQueryable, session, or generic surface? |
| litespec/backend/dotnet/domain#make-money-and-decimal-rules-explicit | Make money and decimal rules explicit | rule | guidance | Is each monetary amount a decimal in the shared Money object with the stated JSON shape? |
| litespec/backend/dotnet/domain#model-every-aggregate-lifecycle-with-state-records | Model every Aggregate lifecycle with state records | rule | guidance | Does each aggregate expose one State property over an abstract base with sealed cases, read only through that property? |
| litespec/backend/dotnet/domain#model-every-closed-set-of-domain-values-without-enums | Model every closed set of domain values without enums | rule | guidance | Is each closed set a record hierarchy with stable codes and FromCode for data-less sets, with no enum in Domain? |
| litespec/backend/dotnet/domain#raise-immutable-domain-facts | Raise immutable domain facts | rule | guidance | Is each domain event an immutable record named for its aggregate and fact, carrying business data only? |
| litespec/backend/dotnet/domain#reject-business-violations-with-domain-exceptions | Reject business violations with Domain exceptions | rule | guidance | Does each rejected rule throw its own DomainException type with a stable code and no transport status? |
| litespec/backend/dotnet/domain#use-strongly-typed-version-7-identifiers | Use strongly typed version 7 identifiers | rule | guidance | Is each identity a readonly record struct over a version 7 Guid with no conversion, alias, or parameterless creation? |
| litespec/backend/dotnet/domain#use-the-project-aggregate-root-contract | Use the project aggregate root contract | rule | guidance | Does every aggregate root derive from the one project base and use its identity and event mechanics? |
| litespec/backend/dotnet/ext/bdd#assert-observable-outcomes | Assert observable outcomes | rule | guidance | Does each scenario assert a response, read, event, record, or other observable outcome? |
| litespec/backend/dotnet/ext/bdd#avoid-routine-scenario-duplication | Avoid routine scenario duplication | rule | guidance | Does the suite leave unit and validation cases to their narrower tests? |
| litespec/backend/dotnet/ext/bdd#drive-public-behavior | Drive public behavior | rule | guidance | Do all steps call the HTTP API or another declared public boundary? |
| litespec/backend/dotnet/ext/bdd#exclude-production-internals | Exclude production internals | rule | guidance | Is the suite free of Domain repository, handler, session, and provider resolution? |
| litespec/backend/dotnet/ext/bdd#group-feature-files-by-module | Group feature files by module | convention | guidance | Do feature files follow the module folders or a recorded Exception? |
| litespec/backend/dotnet/ext/bdd#isolate-scenario-execution | Isolate scenario execution | rule | guidance | Does the suite reset state between scenarios and avoid order dependence? |
| litespec/backend/dotnet/ext/bdd#keep-steps-vocabulary-scoped | Keep steps vocabulary-scoped | convention | guidance | Does each reusable step set serve one business vocabulary or a recorded Exception? |
| litespec/backend/dotnet/ext/bdd#limit-database-assertions | Limit database assertions | rule | guidance | Does each direct database assertion name its documented durable boundary? |
| litespec/backend/dotnet/ext/bdd#limit-scenario-context | Limit scenario context | convention | guidance | Does the scenario context hold state only, or is there a recorded Exception? |
| litespec/backend/dotnet/ext/bdd#mark-pull-request-scenarios | Mark pull-request scenarios | convention | guidance | Does the pull-request subset stay small, owned, and separate from Case proof? |
| litespec/backend/dotnet/ext/bdd#own-scenario-data | Own scenario data | rule | guidance | Does each scenario own its identifiers, actor context, requests, responses, and expected state? |
| litespec/backend/dotnet/ext/bdd#preserve-scenario-failures | Preserve scenario failures | rule | guidance | Do hooks await setup and cleanup without replacing the scenario failure? |
| litespec/backend/dotnet/ext/bdd#prove-a-case-from-every-scenario | Prove a Case from every scenario | rule | guidance | Does every scenario carry one proves claim for a Case its steps prove? |
| litespec/backend/dotnet/ext/bdd#select-shared-critical-examples | Select shared critical examples | rule | guidance | Does the scenario give shared discussions one executable cross-layer example? |
| litespec/backend/dotnet/ext/bdd#translate-business-phrases | Translate business phrases | rule | guidance | Do step definitions delegate business phrases to typed driver calls? |
| litespec/backend/dotnet/ext/efcore#apply-migrations-as-release-work | Apply migrations as release work | rule | checkable | EfCoreMigrationsTests place migration application before replica startup in the release record. |
| litespec/backend/dotnet/ext/efcore#avoid-per-aggregate-read-stores | Avoid per-aggregate read stores | rule | checkable | EfCoreReadTests assert no per-aggregate read-store interface pattern exists. |
| litespec/backend/dotnet/ext/efcore#commit-ef-core-command-work-once | Commit EF Core Command work once | rule | checkable | EfCoreCommitTests observe one post-handler SaveChangesAsync call per owned Command. |
| litespec/backend/dotnet/ext/efcore#configure-ef-core-mappings-in-infrastructure | Configure EF Core mappings in Infrastructure | rule | checkable | EfCoreMappingTests assert EF Core mappings use Infrastructure-owned configuration classes. |
| litespec/backend/dotnet/ext/efcore#configure-optimistic-tokens | Configure optimistic tokens | rule | checkable | EfCoreConcurrencyTests carry expected version and use the configured EF Core token. |
| litespec/backend/dotnet/ext/efcore#configure-relational-details-explicitly | Configure relational details explicitly | rule | guidance | Does the mapping review record every declared relational configuration category? |
| litespec/backend/dotnet/ext/efcore#define-ef-core-query-roots | Define EF Core query roots | rule | checkable | EfCoreReadTests assert one owned IApplicationDbContext and no wider EF surface. |
| litespec/backend/dotnet/ext/efcore#exclude-direct-handler-commits | Exclude direct handler commits | rule | checkable | EfCoreWriteTests assert handlers inject no DbContext and call no SaveChangesAsync. |
| litespec/backend/dotnet/ext/efcore#generate-migrations-for-schema-changes | Generate migrations for schema changes | rule | checkable | EfCoreMigrationsTests assert EF Core schema diffs include a generated migration. |
| litespec/backend/dotnet/ext/efcore#implement-query-roots-in-infrastructure | Implement query roots in Infrastructure | rule | checkable | EfCoreReadTests assert the Infrastructure DbContext implements the owned query interface. |
| litespec/backend/dotnet/ext/efcore#keep-migration-files-together | Keep migration files together | rule | checkable | EfCoreMigrationsTests assert each migration commit holds migration, snapshot, and reviewed SQL. |
| litespec/backend/dotnet/ext/efcore#map-ef-core-concurrency-conflict | Map EF Core concurrency conflict | rule | checkable | EfCoreConcurrencyTests map the provider exception to the Application contract. |
| litespec/backend/dotnet/ext/efcore#map-stable-relational-state-shape | Map stable relational state shape | rule | checkable | EfCoreStateTests assert no relational lifecycle flags or duplicate nullable state values. |
| litespec/backend/dotnet/ext/efcore#map-unsupported-state-shapes-in-infrastructure | Map unsupported state shapes in Infrastructure | rule | checkable | EfCoreStateTests map valid discriminator values to Domain states. |
| litespec/backend/dotnet/ext/efcore#process-changed-aggregate-events | Process changed aggregate events | rule | checkable | EfCoreCommitTests classify and stage Domain events correctly. |
| litespec/backend/dotnet/ext/efcore#project-ef-core-queries-directly | Project EF Core queries directly | rule | checkable | EfCoreReadTests assert no tracking, authorized filters, deterministic limits, projections, and no invariant from a projection. |
| litespec/backend/dotnet/ext/efcore#record-ef-core-replacement-scope | Record EF Core replacement scope | rule | guidance | Does the decision name aggregates, evolution, transactions, queries, packages, and rollback? |
| litespec/backend/dotnet/ext/efcore#record-provider-selection | Record provider selection | rule | guidance | Does the decision name each Command path's provider and its test evidence? |
| litespec/backend/dotnet/ext/efcore#register-one-command-post-handler | Register one Command post-handler | rule | checkable | EfCoreTransactionTests assert each command resolves only its selected provider post-handler. |
| litespec/backend/dotnet/ext/efcore#reject-automatic-command-retry | Reject automatic command retry | rule | checkable | EfCoreConcurrencyTests prove no complete Command automatic retry. |
| litespec/backend/dotnet/ext/efcore#reject-cross-provider-outbox-storage | Reject cross-provider outbox storage | rule | checkable | EfCoreOutboxTests assert EF Core Commands write no outbox record through Marten. |
| litespec/backend/dotnet/ext/efcore#reject-mixed-provider-writes | Reject mixed provider writes | rule | checkable | EfCoreTransactionTests assert no mixed Marten and EF Core aggregate repository writes. |
| litespec/backend/dotnet/ext/efcore#reject-startup-schema-mutation | Reject startup schema mutation | rule | checkable | EfCoreMigrationsTests assert startup calls none of the prohibited schema APIs. |
| litespec/backend/dotnet/ext/efcore#resolve-cross-provider-invariants | Resolve cross-provider invariants | rule | guidance | Does each cross-provider invariant use one provider or a reviewed shared transaction? |
| litespec/backend/dotnet/ext/efcore#resolve-the-tenant-at-context-creation | Resolve the tenant at context creation | rule | checkable | EfCoreReadTests assert tenant resolution at creation and tenant filters on owned sets. |
| litespec/backend/dotnet/ext/efcore#retain-domain-state-values | Retain Domain state values | rule | checkable | EfCoreStateTests retain the aggregate's one Domain state value. |
| litespec/backend/dotnet/ext/efcore#retain-marten-query-boundary | Retain Marten query boundary | rule | checkable | EfCoreReadTests assert Marten query handlers retain IQuerySession. |
| litespec/backend/dotnet/ext/efcore#retain-unaffected-baseline-persistence | Retain unaffected baseline persistence | rule | guidance | Does every unaffected aggregate path retain its baseline persistence behavior? |
| litespec/backend/dotnet/ext/efcore#review-migration-effects | Review migration effects | rule | guidance | Does the migration review cover every declared storage and rollback effect? |
| litespec/backend/dotnet/ext/efcore#review-new-persisted-states | Review new persisted states | rule | guidance | Does the new state review cover migration, mixed versions, rollback, and a fixture? |
| litespec/backend/dotnet/ext/efcore#stage-aggregate-writes-in-repositories | Stage aggregate writes in repositories | rule | checkable | EfCoreWriteTests stage changes through the scoped DbContext. |
| litespec/backend/dotnet/ext/efcore#stage-ef-core-outbox-records-together | Stage EF Core outbox records together | rule | checkable | EfCoreOutboxTests stage message and business work through one DbContext. |
| litespec/backend/dotnet/ext/efcore#test-migration-starting-states | Test migration starting states | rule | checkable | EfCoreMigrationsTests run from empty and previous-release databases. |
| litespec/backend/dotnet/ext/efcore#use-direct-state-mapping-only-when-supported | Use direct state mapping only when supported | rule | checkable | EfCoreStateTests materialize, track, and round-trip every state case. |
| litespec/backend/dotnet/ext/efcore#use-durable-outbox-delivery | Use durable outbox delivery | rule | checkable | EfCoreCommitTests assert EF Core durable Commands commit no Marten session. |
| litespec/backend/dotnet/ext/efcore#use-one-write-provider | Use one write provider | rule | checkable | EfCoreTransactionTests stage aggregate work through one selected provider. |
| litespec/backend/dotnet/ext/efcore#use-snake-case-relational-names | Use snake-case relational names | convention | checkable | EfCoreTests assert generated migrations contain verified snake-case database names. |
| litespec/backend/dotnet/ext/efcore#use-the-ef-core-infrastructure-layout | Use the EF Core Infrastructure layout | convention | guidance | Does each EF Core Infrastructure path use the default layout or record an Exception? |
| litespec/backend/dotnet/naming#keep-implementation-style-consistent | Keep implementation style consistent | rule | guidance | Does production C# use file-scoped namespaces, braces, explicit modifiers, and sealed classes? |
| litespec/backend/dotnet/naming#match-c-files-and-primary-types | Match C# files and primary types | rule | checkable | dotnet build reports no LiteSpec.Analyzers LS3003 diagnostic. |
| litespec/backend/dotnet/naming#name-asynchronous-methods-completely | Name asynchronous methods completely | rule | checkable | dotnet build reports no LiteSpec.Analyzers LS3001 or LS3002 diagnostic. |
| litespec/backend/dotnet/packages#keep-application-dependencies-narrow | Keep Application dependencies narrow | rule | guidance | Does Application reference only permitted abstractions and the one read boundary? |
| litespec/backend/dotnet/packages#keep-domain-package-free | Keep Domain package-free | rule | guidance | Does the Domain project reference no package beyond the base class library? |
| litespec/backend/dotnet/packages#pin-every-dependency-centrally | Pin every dependency centrally | rule | guidance | Does every version resolve through central management or the lockfile at the manifest or consumer pin? |
| litespec/backend/dotnet/packages#reference-only-the-litebus-module-required | Reference only the LiteBus module required | convention | guidance | Does each project reference only the LiteBus modules its code dispatches? |
| litespec/backend/dotnet/packages#run-litespecanalyzers-in-every-application-project | Run LiteSpec.Analyzers in every application project | convention | guidance | Does each of the five application projects reference LiteSpec.Analyzers at the manifest pin? |
| litespec/backend/dotnet/packages#use-the-project-reference-graph | Use the project reference graph | rule | guidance | Does each project reference follow the declared graph with no added edge? |
| litespec/backend/dotnet/packages#use-this-baseline-package-ownership | Use this baseline package ownership | convention | guidance | Does each baseline package sit in the layer the ownership table assigns? |
| litespec/backend/dotnet/persistence#commit-once-in-the-command-pipeline | Commit once in the command pipeline | rule | guidance | Does exactly one command post-handler call SaveChangesAsync for each pipeline, with no other caller committing? |
| litespec/backend/dotnet/persistence#query-through-iquerysession | Query through IQuerySession | rule | guidance | Does each query handler project through IQuerySession, with filter, scope, ordering, and limit applied first? |
| litespec/backend/dotnet/persistence#register-one-scoped-session | Register one scoped session | convention | guidance | Do the Domain repositories and the commit handler in one command resolve one IDocumentSession? |
| litespec/backend/dotnet/persistence#stage-aggregate-writes-through-repositories | Stage aggregate writes through repositories | rule | guidance | Does each command handler reach persistence only through a Domain repository, never through IDocumentSession? |
| litespec/backend/dotnet/persistence#use-this-infrastructure-layout | Use this Infrastructure layout | convention | guidance | Do Marten configuration, repositories, and commit behavior sit under the one persistence folder? |
| litespec/backend/dotnet/stack#declare-dotnet-as-the-backend-stack | Declare dotnet as the backend stack | rule | guidance | Does litespec.project.json name dotnet when the backend runs on .NET? |
| litespec/backend/dotnet/stack#write-test-results-the-model-builder-reads | Write test results the model builder reads | rule | checkable | litespec model check reports no case as verified when no result file exists. |
| litespec/backend/dotnet/testing#enforce-architecture-rules | Enforce architecture rules | rule | guidance | Do architecture tests assert the named structural boundaries and run in the Release pass? |
| litespec/backend/dotnet/testing#keep-the-test-projects-the-size-requires | Keep the test projects the size requires | rule | guidance | Does the solution hold the test projects its size requires and no other baseline project? |
| litespec/backend/dotnet/testing#prove-each-case-with-a-test-that-calls-its-use-case | Prove each Case with a test that calls its use case | rule | guidance | Is each Case proved by a test carrying its XML doc proves tag and calling its use case? |
| litespec/backend/dotnet/testing#test-http-integration-through-the-real-host | Test HTTP integration through the real host | rule | guidance | Does each HTTP integration test run through WebApplicationFactory, covering Problem Details, authentication, and authorization? |
| litespec/backend/dotnet/testing#use-one-production-faithful-integration-harness | Use one production-faithful integration harness | rule | guidance | Does the integration project own one container fixture, ApiFactory, and isolation helper? |
| litespec/backend/dotnet/workspace#declare-size-and-stacks-in-project-config | Declare size and stacks in project config | rule | guidance | Does litespec.project.json declare size and one stack per frontend beside the .NET backend? |
| litespec/backend/dotnet/workspace#keep-net-production-and-test-projects-separate | Keep .NET production and test projects separate | rule | guidance | Do production projects sit under src/ and test projects under tests/? |
| litespec/backend/dotnet/workspace#keep-one-workspace-solution-beside-the-api-solution | Keep one workspace solution beside the API solution | rule | guidance | Does any root solution list more than one deployable while builds name the API solution? |
| litespec/backend/dotnet/workspace#place-a-workspace-apphost-beside-the-applications-it-runs | Place a workspace AppHost beside the applications it runs | rule | guidance | Does an AppHost running a frontend sit at apps/apphost/ and an API-only one under apps/api/src/? |
| litespec/backend/identifiers#cite-shared-provisions-in-their-published-form | Cite shared provisions in their published form | rule | checkable | litespec validate emits no ID_UNKNOWN_REFERENCE diagnostic. |
| litespec/backend/identifiers#follow-the-identifier-form-of-each-record-type | Follow the identifier form of each record type | rule | checkable | litespec model check reports identifier-form. |
| litespec/backend/identifiers#keep-business-record-names-unique-across-the-project | Keep business record names unique across the project | rule | checkable | litespec model check reports business-record-name-clash. |
| litespec/backend/identifiers#keep-negation-in-rule-names | Keep negation in rule names | rule | checkable | litespec model check reports rule-name-negation. |
| litespec/backend/identifiers#keep-use-case-names-unique-across-the-project | Keep use case names unique across the project | rule | checkable | litespec model check reports use-case-name-clash. |
| litespec/backend/identifiers#keep-wire-codes-stable | Keep wire codes stable | rule | guidance | Do clients read the same code values as before? |
| litespec/backend/identifiers#name-records-with-one-to-six-words | Name records with one to six words | rule | checkable | litespec model check reports identifier-form. |
| litespec/backend/identifiers#resolve-every-identifier-citation | Resolve every identifier citation | rule | checkable | litespec model check reports reference-unresolved. |
| litespec/backend/persistence#add-read-documents-for-query-shaped-data | Add read documents for query-shaped data | convention | guidance | Does each read document record its consistency and rebuild behavior beside its owning use case? |
| litespec/backend/persistence#bound-aggregate-document-growth | Bound aggregate document growth | rule | guidance | Does each embedded collection in an aggregate document have an accepted business bound? |
| litespec/backend/persistence#collect-events-without-a-public-unit-of-work | Collect events without a public unit of work | rule | guidance | Does each repository register touched aggregates with the internal buffer the post-handler drains? |
| litespec/backend/persistence#commit-each-command-pipeline-once | Commit each command pipeline once | rule | guidance | Does exactly one command post-handler commit each pipeline, with no other caller committing? |
| litespec/backend/persistence#control-production-schema-changes | Control production schema changes | rule | guidance | Does each hosted schema change run as a reviewed step before traffic shifts? |
| litespec/backend/persistence#evolve-stored-document-contracts-explicitly | Evolve stored document contracts explicitly | rule | guidance | Does each stored-contract change carry a reviewed transformation or an expand-and-contract rollout? |
| litespec/backend/persistence#keep-mappings-and-aliases-explicit | Keep mappings and aliases explicit | rule | guidance | Does each stored aggregate declare a stable alias, identifier mapping, and the indexes its queries need? |
| litespec/backend/persistence#keep-serialization-behavior-out-of-domain | Keep serialization behavior out of Domain | rule | guidance | Does Infrastructure own the stored JSON contract with every persisted subtype registered? |
| litespec/backend/persistence#persist-one-explicit-state-object | Persist one explicit state object | convention | guidance | Does each aggregate persist its state object with every state round-tripping through the serializer? |
| litespec/backend/persistence#query-through-the-read-session | Query through the read session | rule | guidance | Does each query handler project through the read session, with filter, scope, ordering, and limit applied first? |
| litespec/backend/persistence#review-query-plans-for-new-indexes | Review query plans for new indexes | convention | guidance | Does each new index record its accepted query and the plan that justified it? |
| litespec/backend/persistence#stage-aggregate-writes-through-domain-repositories | Stage aggregate writes through domain repositories | rule | guidance | Does each command handler reach persistence only through a Domain repository? |
| litespec/backend/persistence#test-persistence-against-postgresql | Test persistence against PostgreSQL | rule | guidance | Does each persistence behavior run against the pinned PostgreSQL through Testcontainers? |
| litespec/backend/persistence#use-database-naming-conventions | Use database naming conventions | rule | guidance | Is each generated database identifier snake_case? |
| litespec/backend/persistence#use-one-persistence-folder | Use one persistence folder | convention | guidance | Do store configuration, repositories, and commit behavior sit under the one persistence folder? |
| litespec/backend/persistence#use-one-session-per-command | Use one session per command | convention | guidance | Do the repositories and the commit handler in one command resolve one session? |
| litespec/backend/testing#assert-architecture-boundaries-with-tests | Assert architecture boundaries with tests | rule | guidance | Do architecture tests assert the named structural boundaries? |
| litespec/backend/testing#isolate-integration-state | Isolate integration state | rule | guidance | Does each integration test reset state through the documented strategy with no order dependence? |
| litespec/backend/testing#keep-assertions-focused | Keep assertions focused | convention | guidance | Does each test assert only its named outcome rather than a whole-object snapshot? |
| litespec/backend/testing#keep-the-test-suites-the-size-requires | Keep the test suites the size requires | rule | guidance | Does the codebase hold the test suites its size requires and no other baseline suite? |
| litespec/backend/testing#mirror-production-module-names | Mirror production module names | convention | guidance | Does each test project tree list the same module folders as production, apart from the exempt harness files? |
| litespec/backend/testing#name-tests-by-observable-behavior | Name tests by observable behavior | convention | guidance | Does each test name state operation, condition, and expected result on its production type class? |
| litespec/backend/testing#prove-each-rule-at-its-enforcement-point | Prove each Rule at its enforcement point | rule | guidance | Does a test at the enforcement point prove each Rule, with store refusals provoked through integration? |
| litespec/backend/testing#share-one-production-faithful-integration-harness | Share one production-faithful integration harness | rule | guidance | Does the integration suite own one container fixture, host factory, and isolation helper? |
| litespec/backend/testing#tag-the-test-that-proves-each-case | Tag the test that proves each Case | rule | guidance | Does a test carrying its proves tag, calling the use case and asserting its result, prove each Case? |
| litespec/backend/testing#test-application-coordination | Test Application coordination | rule | guidance | Does each Application test substitute its ports and assert the handler coordination? |
| litespec/backend/testing#test-domain-in-isolation | Test Domain in isolation | rule | guidance | Does each Domain test use explicit inputs with no database, host, container, clock, or mock? |
| litespec/backend/testing#test-http-integration-through-the-real-application-host | Test HTTP integration through the real application host | rule | guidance | Does each HTTP integration test run through the real host covering Problem Details, authentication, and authorization? |
| litespec/backend/testing#use-builders-for-valid-defaults | Use builders for valid defaults | convention | guidance | Does each test data builder produce valid state by default through its Domain factory? |
| litespec/backend/testing#use-evidence-rather-than-one-coverage-target | Use evidence rather than one coverage target | rule | guidance | Do you collect coverage for review with no percentage treated as sufficient testing? |
core#
| ID | Provision | Kind | Mark | Evidence |
|---|---|---|---|---|
| litespec/core/agent#apply-guidance-precedence | Apply guidance precedence | rule | guidance | In which order did the design apply the project exception, the extension, the deeper page, and the shallower page? |
| litespec/core/agent#follow-the-local-pattern-before-the-model-query | Follow the local pattern before the model query | rule | guidance | Which local pattern did the change follow, and which surface did it avoid adding? |
| litespec/core/agent#inspect-existing-work-before-editing | Inspect existing work before editing | rule | guidance | What did git status show, and which unrelated work stayed untouched? |
| litespec/core/agent#inspect-local-examples-after-standards | Inspect local examples after standards | convention | guidance | Which neighboring files shaped the change after the standards? |
| litespec/core/agent#keep-agent-working-files-under-agents | Keep agent working files under agents | convention | guidance | Which working files sit outside .agents/ or the declared replacement? |
| litespec/core/agent#load-applicable-extensions | Load applicable extensions | rule | guidance | Which extensions did the agent load before editing inside their boundaries? |
| litespec/core/agent#make-coherent-scoped-changes | Make coherent scoped changes | rule | guidance | Which changed artifact does the authorized request fail to explain? |
| litespec/core/agent#read-the-full-record-before-changing-a-boundary | Read the full record before changing a boundary | convention | guidance | Which full record did the file generation or boundary change cite? |
| litespec/core/agent#replace-only-declared-conventions | Replace only declared conventions | rule | guidance | Which approved exception record declares each convention replacement? |
| litespec/core/agent#restrict-unapproved-side-effects | Restrict unapproved side effects | rule | guidance | Which approval covers each listed side effect the change makes? |
| litespec/core/agent#select-task-context | Select task context | rule | guidance | Which model query selected the records the change cites? |
| litespec/core/agent#stop-on-unresolved-conflict | Stop on unresolved conflict | rule | guidance | Which quoted conflict stopped the work, with both provision identifiers? |
| litespec/core/authoring#attach-examples-to-their-provisions | Attach examples to their provisions | rule | checkable | litespec validate emits no STANDARD_EXAMPLE_LABEL or PAGE_UNKNOWN_SECTION diagnostic. |
| litespec/core/authoring#check-the-vocabulary-on-every-surface-a-reader-meets | Check the vocabulary on every surface a reader meets | rule | checkable | litespec consumer scans every languageScan pattern and fails a pattern that matches no file. |
| litespec/core/authoring#classify-every-specification-file | Classify every specification file | rule | checkable | litespec consumer fails a Markdown file with no declared type outside a declared unstructured path. |
| litespec/core/authoring#declare-structured-specification-metadata | Declare structured specification metadata | rule | checkable | litespec consumer validates each opening specification metadata block against the record schema. |
| litespec/core/authoring#derive-a-computed-fact-instead-of-restating-it | Derive a computed fact instead of restating it | rule | guidance | Does each count, census, and membership list name its source or its command? |
| litespec/core/authoring#exclude-a-sequence-number-from-the-identifier | Exclude a sequence number from the identifier | rule | guidance | Do changed identifiers name their obligation in words alone? |
| litespec/core/authoring#exclude-cross-release-compatibility-work | Exclude cross-release compatibility work | rule | guidance | Would a consumer find any promise of migration, mapping, or alias here? |
| litespec/core/authoring#exclude-declared-content-paths-from-the-ascii-check | Exclude declared content paths from the ASCII check | rule | guidance | Does the project record name every path outside the ASCII check, with documents about that content still checked? |
| litespec/core/authoring#exclude-generated-regions-from-prose-checks | Exclude generated regions from prose checks | rule | guidance | Does every authoring check skip the text between generated-region fences? |
| litespec/core/authoring#exclude-historical-transition-material | Exclude historical transition material | rule | guidance | Does any active file carry history-specific material between releases? |
| litespec/core/authoring#exclude-the-compound-that-names-another-concept | Exclude the compound that names another concept | rule | checkable | litespec consumer reports no LANGUAGE_REJECTED_SYNONYM diagnostic inside an exempt compound. |
| litespec/core/authoring#follow-the-google-developer-documentation-style-guide | Follow the Google developer documentation style guide | rule | guidance | Would a reviewer who knows developers.google.com/style accept the changed prose, apart from the additions this page states? |
| litespec/core/authoring#identify-actionable-conventions | Identify actionable conventions | rule | checkable | litespec validate emits no CONVENTION_MISSING_DEFAULT or CONVENTION_MISSING_REPLACEMENT diagnostic. |
| litespec/core/authoring#keep-a-pinned-release-for-as-long-as-it-serves | Keep a pinned release for as long as it serves | rule | guidance | Does any active provision oblige a consumer to adopt a later release? |
| litespec/core/authoring#keep-authored-prose-ascii-safe | Keep authored prose ASCII-safe | rule | checkable | litespec validate emits no PROSE_NON_ASCII diagnostic. |
| litespec/core/authoring#keep-identifiers-out-of-provision-headings | Keep identifiers out of provision headings | rule | checkable | litespec validate emits no ID_IN_HEADING diagnostic. |
| litespec/core/authoring#map-provisions-to-evidence | Map provisions to evidence | rule | checkable | litespec validate emits no VERIFY_MISSING_ID or VERIFY_UNKNOWN_ID diagnostic. |
| litespec/core/authoring#mark-every-provision-checkable-or-guidance | Mark every provision checkable or guidance | rule | checkable | litespec validate emits no VERIFY_MARK diagnostic. |
| litespec/core/authoring#name-the-escape-from-every-abstraction | Name the escape from every abstraction | rule | checkable | litespec validate emits no PAGE_MISSING_SECTION diagnostic for a command page. |
| litespec/core/authoring#name-the-owning-page-in-the-identifier | Name the owning page in the identifier | rule | checkable | litespec validate emits no ID_PAGE_FILENAME or ID_DUPLICATE diagnostic. |
| litespec/core/authoring#name-the-tool-rather-than-the-mechanism | Name the tool rather than the mechanism | rule | guidance | Does each procedure step name the shipped command that performs it? |
| litespec/core/authoring#prefer-direct-action-headings | Prefer direct action headings | convention | guidance | Does every changed Standard or Convention heading start with a concrete action verb? |
| litespec/core/authoring#publish-each-release-as-a-complete-contract | Publish each release as a complete contract | rule | checkable | litespec validate emits no ID_UNKNOWN_REFERENCE diagnostic. |
| litespec/core/authoring#record-a-setting-as-reference | Record a setting as reference | rule | guidance | Does every setting named in a procedure resolve to a configuration page row? |
| litespec/core/authoring#record-the-project-vocabulary-as-data | Record the project vocabulary as data | rule | checkable | litespec consumer validates the language record against the language schema. |
| litespec/core/authoring#record-the-reviewed-litespec-release | Record the reviewed LiteSpec release | rule | checkable | litespec consumer fails when reviewedLiteSpecVersion differs from the pinned release. |
| litespec/core/authoring#regenerate-the-provision-index | Regenerate the provision index | rule | checkable | litespec provisions --check exits zero. |
| litespec/core/authoring#reject-a-recorded-synonym-inside-its-scope | Reject a recorded synonym inside its scope | rule | checkable | litespec consumer emits no LANGUAGE_REJECTED_SYNONYM diagnostic. |
| litespec/core/authoring#route-the-reader-before-listing-pages | Route the reader before listing pages | rule | checkable | litespec validate emits no INDEX_MISSING_ROUTING diagnostic. |
| litespec/core/authoring#run-repeatable-authoring-checks | Run repeatable authoring checks | rule | checkable | litespec validate, dotnet test --solution LiteSpec.slnx and git diff --check exit zero. |
| litespec/core/authoring#state-one-layer-per-page | State one layer per page | rule | guidance | Does mechanism detail appear only under an Underneath section? |
| litespec/core/authoring#use-controlled-capitalization | Use controlled capitalization | rule | checkable | litespec validate emits no PAGE_TITLE_CASE diagnostic. |
| litespec/core/authoring#use-one-metadata-carrier | Use one metadata carrier | rule | guidance | Is the opening specification metadata block the only metadata on each page? |
| litespec/core/authoring#use-one-normative-vocabulary | Use one normative vocabulary | rule | checkable | litespec validate emits no STANDARD_MODAL_COUNT or STANDARD_MODAL_VOCABULARY diagnostic. |
| litespec/core/authoring#use-one-term-for-one-concept | Use one term for one concept | rule | guidance | Would a reader meet each concept under one name only? |
| litespec/core/authoring#use-the-declared-identifier-grammar | Use the declared identifier grammar | rule | checkable | litespec validate emits no ID_UNKNOWN_REFERENCE diagnostic. |
| litespec/core/authoring#use-the-declared-page-contract | Use the declared page contract | rule | checkable | litespec validate emits no PAGE_MISSING_SECTION, PAGE_SECTION_ORDER or PAGE_UNKNOWN_SECTION diagnostic. |
| litespec/core/authoring#validate-current-standards-material | Validate current standards material | rule | guidance | Does the validator read the working tree and no earlier release? |
| litespec/core/authoring#write-atomic-standards-provisions | Write atomic Standards provisions | rule | checkable | litespec validate emits no STANDARD_REQUIREMENT_COUNT, STANDARD_SENTENCE_COUNT or STANDARD_LABEL_INVALID diagnostic. |
| litespec/core/maintaining#publish-a-litespec-release-from-a-tag | Publish a LiteSpec release from a tag | rule | guidance | Does one new tag carry the current version across the manifest, the changelog, and the template? |
| litespec/core/maintaining#replace-every-citation-on-a-rename | Replace every citation on a rename | rule | checkable | litespec validate emits no ID_UNKNOWN_REFERENCE diagnostic. |
| litespec/core/maintaining#state-the-provision-lifecycle | State the provision lifecycle | rule | guidance | Is every provision in exactly one lifecycle state, with retired identifiers cited nowhere? |
| litespec/core/model#apply-guidance-precedence | Apply guidance precedence | rule | guidance | Does intent override a standard anywhere without an exception? |
| litespec/core/model#authorize-access-through-the-permission-chain | Authorize access through the permission chain | rule | checkable | litespec model check reports record-shape and reference-unresolved. |
| litespec/core/model#cover-every-public-use-case-from-a-journey | Cover every public use case from a journey | rule | checkable | litespec model check reports journey-reach. |
| litespec/core/model#declare-size-stacks-and-optional-types | Declare size stacks and optional types | rule | checkable | litespec model check reports size-type-missing and record-shape. |
| litespec/core/model#express-module-order-as-depends-on | Express module order as depends on | rule | guidance | Does any record rank modules instead of linking them? |
| litespec/core/model#follow-the-authority-order | Follow the authority order | rule | guidance | Does each conflict resolve toward the higher authority? |
| litespec/core/model#give-every-use-case-its-results | Give every use case its results | rule | checkable | litespec model check reports use-case-without-success and case-result-unresolved. |
| litespec/core/model#hold-approval-behind-draft-decisions | Hold approval behind draft decisions | rule | checkable | litespec model check reports draft-gate. |
| litespec/core/model#keep-one-owner-and-status-on-every-record | Keep one owner and status on every record | rule | checkable | litespec model check reports owner-unknown and draft-without-decider. |
| litespec/core/model#name-what-every-decision-decides | Name what every decision decides | rule | checkable | litespec model check reports decision-decides-nothing. |
| litespec/core/model#read-truth-from-code-screens-and-test-runs | Read truth from code screens and test runs | rule | checkable | litespec model check reports use-case-unimplemented, proves-unconfirmed, and refusal-not-thrown. |
| litespec/core/model#record-accepted-gaps-as-known-gaps | Record accepted gaps as known gaps | rule | checkable | litespec model check reports record-shape and known-gap-expired. |
| litespec/core/model#render-generated-regions-from-the-model | Render generated regions from the model | convention | guidance | Are generated regions current, or is a replacement recorded? |
| litespec/core/model#resolve-every-page-link | Resolve every page link | rule | checkable | litespec model check reports link-unresolved. |
| litespec/core/model#resolve-ties-by-the-later-decision | Resolve ties by the later decision | rule | guidance | Does the later approved decision settle each tie? |
| litespec/core/model#retire-records-with-replaces | Retire records with replaces | rule | checkable | litespec model check reports invalid-field for replaces outside a decision and reference-unresolved for an unknown target. |
| litespec/core/model#state-the-common-fields-on-every-record | State the common fields on every record | rule | checkable | litespec model check reports record-shape. |
| litespec/core/model#write-every-record-in-its-home | Write every record in its home | rule | checkable | litespec model check reports record-shape. |
| litespec/core/model#write-links-on-the-record-that-points | Write links on the record that points | rule | checkable | litespec model check reports reference-unresolved. |
| litespec/core/principles#avoid-generic-boundary-names | Avoid generic boundary names | rule | guidance | Does every changed boundary name carry the narrowest accurate business name? |
| litespec/core/principles#classify-record-authority | Classify record authority | rule | checkable | litespec consumer fails a record with a missing or unknown status, or a draft without decider and decideBy date. |
| litespec/core/principles#keep-one-authored-source | Keep one authored source | rule | guidance | Does every fact on the changed pages trace to one authored record? |
| litespec/core/principles#locate-package-versions-in-the-manifest | Locate package versions in the manifest | rule | checkable | litespec consumer fails a project whose stack versions do not resolve from the manifest. |
| litespec/core/principles#locate-record-status-in-frontmatter | Locate record status in frontmatter | rule | checkable | litespec consumer fails a record whose frontmatter is missing a required common field. |
| litespec/core/principles#name-boundary-intent | Name boundary intent | rule | guidance | Does every changed boundary name state its business action and owner? |
| litespec/core/principles#prefer-direct-owned-dependencies | Prefer direct owned dependencies | convention | guidance | Is each new abstraction justified by a boundary, or recorded as an exception? |
| litespec/core/principles#prefer-local-code-until-reuse-is-real | Prefer local code until reuse is real | convention | guidance | Does each new shared unit serve two real consumers under one accurate name? |
| litespec/core/principles#prove-cases-with-tests | Prove cases with tests | rule | guidance | Does every case have a passing test that calls its use case and asserts its result? |
| litespec/core/principles#prove-enforceable-boundaries-mechanically | Prove enforceable boundaries mechanically | rule | guidance | Does a reference, test, or lint rule prove each changed enforceable boundary? |
| litespec/core/principles#refuse-approval-behind-a-draft-decision | Refuse approval behind a draft decision | rule | guidance | Is every decision behind an approved record approved itself? |
| litespec/core/principles#require-current-complexity-activation | Require current complexity activation | rule | guidance | Does a current use case, decision, or requirement name the added complexity? |
| litespec/core/principles#retire-public-behavior-deliberately | Retire public behavior deliberately | rule | checkable | litespec consumer fails a retired use case that still names an entry point. |
| litespec/core/principles#separate-authority-from-implementation | Separate authority from implementation | rule | checkable | litespec consumer fails a record that writes its own implementation status. |
| litespec/core/product#answer-every-constraint | Answer every constraint | rule | checkable | litespec consumer fails a constraint without source and applicability, or a project with unanswered constraints. |
| litespec/core/product#build-intent-before-specification-before-code | Build intent before specification before code | rule | guidance | Did intent, research, decision, requirement, records, code, and tests land in order? |
| litespec/core/product#build-on-a-draft-decision-before-approval | Build on a draft decision before approval | rule | guidance | Does the release hold approval for every decision the code builds on? |
| litespec/core/product#cite-requirements-from-records | Cite requirements from records | rule | guidance | Does every record that carries a requirement name it in fulfills? |
| litespec/core/product#cite-sources-for-chapter-claims | Cite sources for chapter claims | rule | guidance | Does each claim in the chapter cite its source? |
| litespec/core/product#derive-history-from-decisions | Derive history from decisions | rule | guidance | Does History list exactly the decisions that decide the page, as generated? |
| litespec/core/product#derive-requirement-coverage-from-the-model | Derive requirement coverage from the model | rule | guidance | Does the coverage list come from the model rather than hand-kept notes? |
| litespec/core/product#group-product-topics-by-area | Group product topics by area | convention | guidance | Does docs/product/ follow the example layout, or does an Exception record the replacement? |
| litespec/core/product#identify-every-requirement | Identify every requirement | rule | checkable | litespec consumer fails a Requirement entry without identifier, kind, or statement, or a promise without effective-dated values. |
| litespec/core/product#keep-behavior-out-of-product-pages | Keep behavior out of product pages | rule | guidance | Does any product page name a state, entry point, failure code, or handler? |
| litespec/core/product#keep-business-intent-under-product | Keep business intent under product | rule | checkable | litespec consumer fails a why-layer record outside its home folder. |
| litespec/core/product#load-product-intent-before-commercial-work | Load product intent before commercial work | rule | guidance | Does the change report list the product pages read before the change? |
| litespec/core/product#name-product-decisions-in-one-numbered-sequence | Name product decisions in one numbered sequence | convention | checkable | litespec consumer fails a decision file whose name does not match its identifier. |
| litespec/core/product#name-the-person-who-approved-a-decision | Name the person who approved a decision | rule | guidance | Did the named decider approve the decision, and does the record carry the date? |
| litespec/core/product#place-the-story-before-the-commitments | Place the story before the commitments | rule | checkable | litespec consumer fails a topic whose chapter follows its commitments. |
| litespec/core/product#record-each-product-choice-as-a-decision | Record each product choice as a decision | rule | checkable | litespec consumer fails a decision missing a required section or decides target. |
| litespec/core/product#record-research-with-read-sources | Record research with read sources | rule | checkable | litespec consumer fails a Research record without question or source read date. |
| litespec/core/product#reject-an-unfulfilled-requirement | Reject an unfulfilled requirement | rule | checkable | litespec model check reports no requirement-unfulfilled finding outside an open Known gap. |
| litespec/core/product#replace-a-decision-with-a-new-record | Replace a decision with a new record | rule | guidance | Does the new decision name the old one in replaces, with the old one retired? |
| litespec/core/product#review-a-topic-by-its-date | Review a topic by its date | rule | checkable | litespec consumer fails a topic page whose reviewBy date has passed. |
| litespec/core/product#state-each-problem-and-feature | State each problem and feature | rule | checkable | litespec consumer fails a problem or feature missing its required fields. |
| litespec/core/product#state-each-topic-in-one-page-shape | State each topic in one page shape | rule | checkable | litespec consumer fails a topic page missing a required section or reviewBy. |
| litespec/core/product#state-one-product | State one product | rule | checkable | litespec consumer fails a brief without one product, boundary, and audience. |
| litespec/core/product#trace-every-choice-to-a-decision | Trace every choice to a decision | rule | guidance | Does every Position and Refusals entry link an unretired decision, approved when the page is approved? |
| litespec/core/product#treat-generated-research-as-source-material | Treat generated research as source material | rule | guidance | Does every new position trace to a Research record or an approved decision? |
| litespec/core/release#apply-release-access-controls | Apply release access controls | rule | guidance | Do authentication and authorization guard every restricted release path? |
| litespec/core/release#identify-immutable-release-artifacts | Identify immutable release artifacts | rule | guidance | Does the release record name the source commit and artifact reference? |
| litespec/core/release#keep-a-first-release-readiness-record | Keep a first-release readiness record | rule | guidance | Does one record hold dated rehearsals, green gates, and a rehearsal owner? |
| litespec/core/release#keep-generated-contracts-stable | Keep generated contracts stable | rule | guidance | Is the contract diff free of timestamps, machine paths, and unstable order? |
| litespec/core/release#keep-release-records-non-authoritative | Keep release records non-authoritative | rule | guidance | Does the record link outward instead of restating behavior? |
| litespec/core/release#keep-unfinished-behavior-in-draft | Keep unfinished behavior in draft | rule | guidance | Is every use case with unfinished behavior still in draft? |
| litespec/core/release#list-included-release-behavior | List included release behavior | rule | guidance | Does the record list every included journey, use case, and extension? |
| litespec/core/release#meet-release-readiness-gates | Meet release readiness gates | rule | guidance | Is every included use case verified, with passing journey evidence for each journey? |
| litespec/core/release#provide-release-data-recovery | Provide release data recovery | rule | guidance | Do schema setup, backup instructions, and a tested restore all exist? |
| litespec/core/release#provide-release-delivery-controls | Provide release delivery controls | rule | guidance | Are CI, deployment, rollback, limits, and runbooks all current? |
| litespec/core/release#provide-release-operating-visibility | Provide release operating visibility | rule | guidance | Do health signals and trace diagnostics ship without secrets in source control? |
| litespec/core/release#record-accepted-debt-as-a-known-gap | Record accepted debt as a known gap | rule | guidance | Does every accepted debt live as a Known gap with owner and end date? |
| litespec/core/release#record-operating-readiness | Record operating readiness | rule | guidance | Does the record state limits, alerts, runbooks, conditions, and omissions? |
| litespec/core/release#record-release-evidence | Record release evidence | rule | guidance | Does the record hold a result for every listed evidence kind? |
| litespec/core/release#record-the-release-artifact | Record the release artifact | rule | guidance | Does one release record name the immutable artifact? |
| litespec/core/release#regenerate-application-contracts | Regenerate application contracts | rule | guidance | Do committed contracts match a fresh generation from their source? |
| litespec/core/release#report-verification-exactly | Report verification exactly | rule | guidance | Would a reviewer learn the commands, outcomes, scope, omissions, and limits from the report? |
| litespec/core/release#resolve-release-blockers | Resolve release blockers | rule | guidance | Is every open decision and external claim settled or excluded in every owning record? |
| litespec/core/release#run-backend-release-checks | Run backend release checks | rule | guidance | Did the release build and every required backend suite pass? |
| litespec/core/release#run-boundary-selected-checks | Run boundary-selected checks | rule | guidance | Did the change run every check its changed boundaries select? |
| litespec/core/release#run-consistency-checks | Run consistency checks | rule | checkable | litespec consumer exits zero. |
| litespec/core/release#run-extension-checks | Run extension checks | rule | guidance | Did each affected extension report its stated verification evidence? |
| litespec/core/release#run-frontend-release-checks | Run frontend release checks | rule | guidance | Did install, lint, type checks, tests, and the production build all pass? |
| litespec/core/release#run-journey-checks | Run journey checks | rule | guidance | Did the journey tests pass against the deployed boundary? |
| litespec/core/release#state-each-release-as-a-complete-record | State each release as a complete record | rule | guidance | Would a reader judge the release from this record alone? |
| litespec/core/release#store-release-records-together | Store release records together | convention | guidance | Does the record path follow the default or a recorded Exception? |
| litespec/core/release#treat-check-warnings-as-failures | Treat check warnings as failures | convention | guidance | Does the build fail on warnings except for recorded narrow suppressions? |
| litespec/core/release#verify-connected-journeys | Verify connected journeys | rule | guidance | Does each completed journey reach one observable outcome through a deployed public boundary? |
| litespec/core/scope#answer-the-constraints-question | Answer the constraints question | rule | guidance | Where does the project state which outside constraints apply? |
| litespec/core/scope#declare-a-consumer-that-has-no-backend | Declare a consumer that has no backend | rule | checkable | litespec consumer refuses a client-only project that names a backend stack. |
| litespec/core/scope#keep-one-bounded-context | Keep one bounded context | rule | guidance | Which second language or deployment boundary does the design introduce? |
| litespec/core/scope#measure-capacity-before-expansion | Measure capacity before expansion | convention | guidance | Which load, target, and observed constraint justify the added capacity? |
| litespec/core/scope#record-selected-extensions | Record selected extensions | rule | checkable | litespec consumer rejects a selection without a criterion or review date. |
| litespec/core/scope#record-unsupported-scope-decisions | Record unsupported scope decisions | rule | guidance | Which decision records each architecture outside the supported boundary? |
| litespec/core/scope#select-a-size-a-shape-and-stacks | Select a size, a shape and stacks | rule | checkable | litespec consumer refuses a shape whose backend stack count is wrong and a platform that names no frontend stack. |
| litespec/core/scope#select-conditional-extensions-explicitly | Select conditional extensions explicitly | rule | guidance | Which criterion justifies each selection, and which applicable extension stays unselected? |
| litespec/core/scope#start-with-one-api-and-database | Start with one API and database | convention | guidance | Which second deployable or database does the topology add, and why? |
| litespec/core/stacks#apply-the-complete-stack | Apply the complete stack | rule | guidance | Does the consumer apply every page in its stack folders and the folders above them? |
| litespec/core/stacks#declare-replacements | Declare replacements | rule | guidance | Does each replacement name every provision ID it replaces? |
| litespec/core/stacks#keep-the-stack-visible | Keep the stack visible | convention | guidance | Do litespec.project.json and the root AGENTS.md name the selection? |
| litespec/core/stacks#use-manifest-version-pins | Use manifest version pins | rule | guidance | Does each resolved version match its manifest pin? |
| litespec/core/system#bound-a-scenario-to-120-words | Bound a scenario to 120 words | convention | checkable | litespec consumer fails a Scenario section longer than scenarioWordLimit, defaulting to 120 words. |
| litespec/core/system#compute-use-case-status-from-evidence | Compute use-case status from evidence | rule | guidance | Which use-case status did a person write by hand instead of the evidence? |
| litespec/core/system#connect-one-product-outcome-through-a-journey | Connect one product outcome through a journey | rule | guidance | Which journey links the use case, or which background caller replaces it? |
| litespec/core/system#declare-each-link-on-its-source | Declare each link on its source | rule | guidance | Which link sits off its source, and which citation resolves nowhere? |
| litespec/core/system#declare-event-reaction-delivery | Declare event reaction delivery | rule | guidance | Which reaction lacks exactly one classification that the implementation honors? |
| litespec/core/system#deliver-one-complete-use-case | Deliver one complete use case | rule | guidance | Which layer or evidence does the incomplete use case still lack? |
| litespec/core/system#derive-every-scenario-from-one-reference-cast | Derive every scenario from one reference cast | rule | guidance | Does one scenario-cast page exist, and does each scenario draw from it? |
| litespec/core/system#drive-work-from-approved-records | Drive work from approved records | rule | guidance | Which approved records authorized each behavior change? |
| litespec/core/system#grant-access-through-roles-and-permissions | Grant access through roles and permissions | rule | guidance | Which access lacks its actor, role, permission, and use-case path? |
| litespec/core/system#group-language-and-use-cases-by-module | Group language and use cases by module | rule | checkable | litespec consumer resolves each module reference to one declared module directory. |
| litespec/core/system#group-module-use-case-files-by-business-record | Group module use-case files by business record | convention | guidance | Does each use case sit under its module or one business-record subdirectory? |
| litespec/core/system#keep-a-scenario-informative | Keep a scenario informative | rule | guidance | Does any Scenario section contain a record identifier? |
| litespec/core/system#keep-decision-authority-with-accountable-people | Keep decision authority with accountable people | rule | guidance | Which draft decision records each question that stopped the work? |
| litespec/core/system#keep-operational-and-security-references-under-operations | Keep operational and security references under operations | convention | guidance | Which operating or security prose sits outside docs/operations/? |
| litespec/core/system#keep-records-readable-without-tooling | Keep records readable without tooling | convention | guidance | Which JSON sits outside the frontmatter block? |
| litespec/core/system#keep-use-cases-and-handlers-in-one-to-one-correspondence | Keep use cases and handlers in one-to-one correspondence | rule | guidance | Which handler lacks its use case, or which use case lacks its handler? |
| litespec/core/system#make-business-record-ownership-explicit | Make business-record ownership explicit | rule | guidance | Which business record lacks its state, rules, or commands on the module page? |
| litespec/core/system#model-every-business-record-lifecycle-with-state-records | Model every business-record lifecycle with state records | rule | guidance | Which business state lacks its sealed state record in page and code? |
| litespec/core/system#name-what-calls-a-use-case | Name what calls a use case | rule | guidance | Which entry points reach the use case, or which background caller does? |
| litespec/core/system#resolve-authority-by-ladder | Resolve authority by ladder | rule | guidance | Which ladder settles the conflict, and which record lacks an owner? |
| litespec/core/system#state-each-rule-with-its-kind | State each rule with its kind | rule | guidance | Which rule lacks its kind, governor, enforcement, or kept negation? |
| litespec/core/system#state-one-occasion-for-every-behavior-record | State one occasion for every behavior record | rule | guidance | Which behavior page lacks a Scenario section stating its concrete occasion? |
| litespec/core/system#update-records-with-behavior | Update records with behavior | rule | guidance | Which affected record did the behavior change leave behind? |
| litespec/core/system#use-established-technical-terms | Use established technical terms | convention | guidance | Which term replaces an established technical meaning with a softer synonym? |
| litespec/core/system#use-ordinary-capitalization-in-prose | Use ordinary capitalization in prose | convention | guidance | Which ordinary noun carries capitalization outside names and identifiers? |
| litespec/core/system#use-this-consumer-documentation-layout | Use this consumer documentation layout | convention | guidance | Which directory breaks the layout without a declared exception? |
| litespec/core/system#write-each-record-in-its-catalog-shape | Write each record in its catalog shape | rule | guidance | Which record breaks its catalog type, home, owner, or status? |
ext#
| ID | Provision | Kind | Mark | Evidence |
|---|---|---|---|---|
| litespec/ext/audit#add-a-correcting-record | Add a correcting record | rule | guidance | Is each correction a new record referencing the earlier one? |
| litespec/ext/audit#anchor-the-audit-chain-outside-its-own-store | Anchor the audit chain outside its own store | rule | guidance | Does a checkpoint the operators cannot rewrite anchor the chain head? |
| litespec/ext/audit#audit-reads-of-the-trail | Audit reads of the trail | rule | guidance | Does a completed trail read produce one audit record? |
| litespec/ext/audit#commit-a-success-record-with-its-business-change | Commit a success record with its business change | rule | guidance | Does a succeeded record commit in the same transaction as its change? |
| litespec/ext/audit#cover-the-required-audit-categories | Cover the required audit categories | rule | guidance | Does the declared selection contain one entry for each required category? |
| litespec/ext/audit#declare-audit-selection-beside-the-command | Declare audit selection beside the Command | convention | guidance | Does each Command carry the declaration attribute or a recorded Exception? |
| litespec/ext/audit#declare-audit-selection-on-every-command | Declare audit selection on every Command | rule | guidance | Does every Command declare audited status or excluded status with a reason? |
| litespec/ext/audit#emit-audit-records-at-the-mediation-boundary | Emit audit records at the mediation boundary | rule | guidance | Does the producer run in the mediation pipeline rather than inside handlers? |
| litespec/ext/audit#enforce-append-only-through-storage-privilege | Enforce append-only through storage privilege | rule | guidance | Does the writing account lack update and delete privileges on the store? |
| litespec/ext/audit#exclude-derived-audit-trails | Exclude derived audit trails | rule | guidance | Is the trail produced directly rather than derived from events, triggers, or capture? |
| litespec/ext/audit#exclude-indiscriminate-auditing | Exclude indiscriminate auditing | rule | guidance | Does the selection justify each audited category rather than auditing every Command? |
| litespec/ext/audit#exclude-personal-data-beyond-actor-identity | Exclude personal data beyond actor identity | rule | guidance | Does each record hold only pseudonymous actor and target identifiers? |
| litespec/ext/audit#exclude-secrets-and-payment-data | Exclude secrets and payment data | rule | guidance | Is every record free of credentials, tokens, session identifiers, keys, and payment values? |
| litespec/ext/audit#exclude-state-snapshots | Exclude state snapshots | rule | guidance | Is every record free of before and after state copies? |
| litespec/ext/audit#give-the-trail-a-read-path | Give the trail a read path | rule | guidance | Does a permission-gated read filter the trail by every declared filter? |
| litespec/ext/audit#keep-audit-infrastructure-in-one-location | Keep audit infrastructure in one location | convention | guidance | Does the audit code use the documented path or a recorded Exception? |
| litespec/ext/audit#provide-tamper-evidence | Provide tamper evidence | rule | guidance | Does each record chain to its predecessor with the stated hash? |
| litespec/ext/audit#publish-a-copy-to-the-security-platform | Publish a copy to the security platform | convention | guidance | Does a published copy leave the local store authoritative, or is there a recorded Exception? |
| litespec/ext/audit#publish-unsuccessful-write-failures | Publish unsuccessful write failures | rule | guidance | Does the deployment publish the write failure count of the unsuccessful path? |
| litespec/ext/audit#record-a-bulk-read-inside-its-own-boundary | Record a bulk read inside its own boundary | rule | guidance | Does a query above the threshold produce a record carrying the subject count? |
| litespec/ext/audit#record-bulk-export | Record bulk export | rule | guidance | Does each export produce a record naming the requested scope? |
| litespec/ext/audit#record-delegated-administrative-access | Record delegated administrative access | rule | guidance | Does an action under a support grant record that the grant was used? |
| litespec/ext/audit#record-every-attempt-outcome | Record every attempt outcome | rule | guidance | Does every record carry one of the three declared outcomes? |
| litespec/ext/audit#record-failed-audited-attempts | Record failed audited attempts | rule | guidance | Does a permitted attempt that throws produce a failed record? |
| litespec/ext/audit#record-personal-data-reads | Record personal-data reads | rule | guidance | Does a cross-boundary personal-data query produce a record? |
| litespec/ext/audit#record-refused-authorization | Record refused authorization | rule | guidance | Does a refused authorization produce a denied record? |
| litespec/ext/audit#record-the-audit-adoption-decision | Record the audit adoption decision | rule | guidance | Does the adoption decision record the required fields? Is no record approved behind its draft? |
| litespec/ext/audit#record-the-failure-code-on-an-unsuccessful-attempt | Record the failure code on an unsuccessful attempt | rule | guidance | Does each denied or failed record carry its stable failure code? |
| litespec/ext/audit#record-the-operation-trace-identity | Record the operation trace identity | rule | guidance | Does each record carry the trace identifier of its operation? |
| litespec/ext/audit#record-the-request-origin | Record the request origin | rule | guidance | Does each request-produced record carry origin, client, and request identifier? |
| litespec/ext/audit#record-the-required-audit-fields | Record the required audit fields | rule | guidance | Does every record carry each required field, including the tenant value? |
| litespec/ext/audit#reject-an-undeclared-command | Reject an undeclared Command | rule | guidance | Does the build or startup fail for a Command with no declaration? |
| litespec/ext/audit#remove-the-identity-mapping-on-erasure | Remove the identity mapping on erasure | rule | guidance | Does erasure remove the identity mapping while retaining the records? |
| litespec/ext/audit#restrict-handler-contribution-to-determined-values | Restrict handler contribution to determined values | rule | guidance | Does each handler contribute only the audit values it alone determines? |
| litespec/ext/audit#retain-each-category-for-its-declared-period | Retain each category for its declared period | rule | guidance | Are records deleted after the declared retention of their category? |
| litespec/ext/audit#scope-every-record-to-its-tenant | Scope every record to its tenant | rule | guidance | Does each record carry the tenant of the acted-on resource? |
| litespec/ext/audit#stage-the-audit-write-before-the-business-commit | Stage the audit write before the business commit | rule | guidance | Does the audit stage run before the business commit stage? |
| litespec/ext/audit#state-the-action-as-use-case-identity | State the action as use-case identity | rule | guidance | Does each action value name the invoked use case? |
| litespec/ext/audit#store-the-trail-beside-the-business-data | Store the trail beside the business data | convention | guidance | Is the trail in the business database under separated privileges or a recorded Exception? |
| litespec/ext/audit#use-a-closed-actor-set | Use a closed actor set | rule | guidance | Is every actor one of the five Actor kinds, with devices and processes mapped? |
| litespec/ext/audit#use-a-fixed-category-vocabulary | Use a fixed category vocabulary | convention | guidance | Does each category value belong to the eight-value vocabulary? |
| litespec/ext/audit#verify-the-integrity-chain-on-a-schedule | Verify the integrity chain on a schedule | rule | guidance | Does a scheduled job verify the chain and alert on a break? |
| litespec/ext/audit#version-the-audit-record-shape | Version the audit record shape | rule | guidance | Does every record carry an explicit schema version? |
| litespec/ext/audit#write-an-unsuccessful-record-outside-the-failed-transaction | Write an unsuccessful record outside the failed transaction | rule | guidance | Does a denied or failed record survive the rollback of its transaction? |
| litespec/ext/cache#avoid-unbounded-key-locks | Avoid unbounded key locks | rule | guidance | Does lock state stay bounded under high-cardinality keys? |
| litespec/ext/cache#bound-cache-refresh-work | Bound cache refresh work | rule | guidance | Does concurrent-miss refresh stay bounded and protect the source? |
| litespec/ext/cache#compose-cache-keys-from-result-inputs | Compose cache keys from result inputs | rule | guidance | Does each key separate version, result inputs, and tenant or actor partition? |
| litespec/ext/cache#define-cache-invalidation | Define cache invalidation | rule | guidance | Does each cached value define expiry, events, an owner, and failure behavior? |
| litespec/ext/cache#define-cache-outage-behavior | Define cache outage behavior | rule | guidance | Does an outage use the source or return the documented degraded response? |
| litespec/ext/cache#emit-a-signal-for-each-degraded-cache-path | Emit a signal for each degraded cache path | rule | guidance | Do a miss, an error, and a degraded response each increment their own metric? |
| litespec/ext/cache#exclude-unsafe-cache-key-material | Exclude unsafe cache key material | rule | guidance | Is every key free of secrets, unbounded input, and unhashed personal data? |
| litespec/ext/cache#keep-source-data-authoritative | Keep source data authoritative | rule | guidance | Is the required business data authoritative in its source of record? |
| litespec/ext/cache#place-cache-access-at-an-outer-boundary | Place cache access at an outer boundary | convention | guidance | Is cache access outside Domain, or is there a recorded Exception? |
| litespec/ext/cache#prefer-bounded-staleness | Prefer bounded staleness | rule | guidance | Does the expiry stay short unless a measured decision permits longer? |
| litespec/ext/cache#record-a-manual-cache-invalidation | Record a manual cache invalidation | rule | guidance | Does a manual clear write a record naming the actor, the scope, and the reason? |
| litespec/ext/cache#record-measured-cache-need | Record measured cache need | rule | guidance | Does the proposal record the query, load, latency, cost, target, staleness, and ownership? |
| litespec/ext/cache#remove-unjustified-caches | Remove unjustified caches | rule | guidance | Does a cache leave when measurements do not justify its cost? |
| litespec/ext/compat#assign-operation-ids | Assign operation IDs | rule | guidance | Does each independent-consumer operation carry a deliberate operationId? |
| litespec/ext/compat#assign-versioned-operation-ids | Assign versioned operation IDs | rule | guidance | Does a new version assign a new operation ID for each changed contract? |
| litespec/ext/compat#classify-breaking-contract-changes | Classify breaking contract changes | rule | guidance | Does the reviewer mark each removed, renamed, narrowed, retyped, or authentication change as breaking? |
| litespec/ext/compat#classify-compatible-additions | Classify compatible additions | rule | guidance | Does the reviewer record why each optional addition preserves existing behavior? |
| litespec/ext/compat#classify-independent-consumer-changes | Classify independent-consumer changes | rule | guidance | Does the reviewer classify each independent-consumer contract change? |
| litespec/ext/compat#diff-release-contracts | Diff release contracts | rule | guidance | Do the local run and continuous integration compare against the selected baseline? |
| litespec/ext/compat#exercise-generated-consumers | Exercise generated consumers | rule | guidance | Does each first-party client compile and exercise the changed contract? |
| litespec/ext/compat#gate-new-error-outcomes | Gate new error outcomes | rule | guidance | Do existing consumers safely handle each added unknown code? |
| litespec/ext/compat#keep-baseline-references-immutable | Keep baseline references immutable | convention | guidance | Are baseline references immutable, or is there a recorded Exception? |
| litespec/ext/compat#keep-problem-details-codes-stable | Keep Problem Details codes stable | convention | guidance | Do Problem Details codes stay stable across compatible versions? |
| litespec/ext/compat#preserve-stable-error-codes | Preserve stable error codes | rule | guidance | Does the reviewer classify each removed or reassigned stable code as breaking? |
| litespec/ext/compat#publish-deprecation-context | Publish deprecation context | rule | guidance | Does the consumer CHANGELOG.md name each operation scheduled for removal? |
| litespec/ext/compat#record-deprecation-conditions | Record deprecation conditions | rule | guidance | Does the deprecation decision record the sunset date, replacement, and ownership? |
| litespec/ext/compat#record-version-retirement | Record version retirement | rule | guidance | Does the versioning decision name its consumer owners, deadline, removal condition, and ownership? |
| litespec/ext/compat#reject-unapproved-breaking-diffs | Reject unapproved breaking diffs | rule | guidance | Does a breaking diff fail without a new version or an approved decision? |
| litespec/ext/compat#resolve-uncertain-classifications-safely | Resolve uncertain classifications safely | rule | guidance | Does the reviewer treat each unclear change as breaking with consumer review? |
| litespec/ext/compat#retain-compatible-operation-ids | Retain compatible operation IDs | rule | guidance | Does each compatible change retain the existing operationId? |
| litespec/ext/compat#retain-release-baselines | Retain release baselines | rule | guidance | Does each release retain its OpenAPI document as an immutable baseline? |
| litespec/ext/compat#retain-supported-versions | Retain supported versions | rule | guidance | Does the previous version stay available through its support window? |
| litespec/ext/compat#review-exhaustive-consumer-changes | Review exhaustive consumer changes | rule | guidance | Do added enum values and discriminator cases receive consumer review? |
| litespec/ext/compat#signal-planned-public-removal | Signal planned public removal | rule | guidance | Does each operation scheduled for removal expose its deprecation signal? |
| litespec/ext/compat#store-current-openapi-source | Store current OpenAPI source | convention | guidance | Is the generated OpenAPI at the documented path or a recorded Exception? |
| litespec/ext/compat#treat-errors-as-contracts | Treat errors as contracts | rule | guidance | Does the owner treat type, code, field codes, and statuses as versioned contract elements? |
| litespec/ext/compat#use-one-diff-tool | Use one diff tool | convention | guidance | Do the local run and continuous integration invoke the same diff tool? |
| litespec/ext/compat#version-breaking-contracts | Version breaking contracts | rule | guidance | Does each breaking contract use a new route or media-type version? |
| litespec/ext/concurrency#apply-http-version-preconditions | Apply HTTP version preconditions | rule | checkable | ConcurrencyVersionTests require and validate a strong persistence-derived ETag. |
| litespec/ext/concurrency#bound-expired-record-cleanup | Bound expired-record cleanup | rule | checkable | IdempotencyRetentionTests show bounded deletion of expired idempotency records. |
| litespec/ext/concurrency#canonicalize-request-fingerprints | Canonicalize request fingerprints | rule | checkable | IdempotencyKeyTests assert equivalent mapped requests produce one fingerprint without credentials or client key. |
| litespec/ext/concurrency#compare-expected-aggregate-versions | Compare expected aggregate versions | rule | checkable | ConcurrencyVersionTests race conflicting aggregate writes with expected versions. |
| litespec/ext/concurrency#declare-applicable-headers | Declare applicable headers | convention | checkable | ConcurrencyTests asserts generated OpenAPI declares the header for every applicable operation. |
| litespec/ext/concurrency#declare-replayed-transport-outcomes | Declare replayed transport outcomes | rule | checkable | IdempotencyOutcomeTests match replayed statuses and headers against the declared list. |
| litespec/ext/concurrency#define-concurrent-retry-behavior | Define concurrent retry behavior | rule | checkable | IdempotencyReplayTests prove the documented wait, in-progress, or conflict behavior. |
| litespec/ext/concurrency#delay-irreversible-provider-calls | Delay irreversible provider calls | rule | guidance | Does every irreversible provider call run only after its business transaction commits? |
| litespec/ext/concurrency#discard-failed-replay-state | Discard failed replay state | rule | checkable | IdempotencyReplayTests leave no business change or completed replay state. |
| litespec/ext/concurrency#document-write-conflict-behavior | Document write conflict behavior | rule | guidance | Does the use case name conflicts, invalid state, winner behavior, and caller response? |
| litespec/ext/concurrency#enforce-key-uniqueness | Enforce key uniqueness | rule | checkable | IdempotencyKeyTests assert concurrent inserts prove the tenant-actor-operation-key uniqueness constraint. |
| litespec/ext/concurrency#exclude-unsafe-replay-outcomes | Exclude unsafe replay outcomes | rule | checkable | IdempotencyOutcomeTests exclude authentication, transient failures, cookies, hop-by-hop headers, tokens, and secrets. |
| litespec/ext/concurrency#hide-provider-version-values | Hide provider version values | rule | checkable | ConcurrencyVersionTests assert public transport models expose no provider-specific version field. |
| litespec/ext/concurrency#keep-idempotency-persistence-in-infrastructure | Keep idempotency persistence in Infrastructure | convention | checkable | ConcurrencyTests assert idempotency persistence and transaction handling live in Infrastructure. |
| litespec/ext/concurrency#limit-version-checks | Limit version checks | rule | checkable | ConcurrencyVersionTests link every version check to a documented conflicting-write case. |
| litespec/ext/concurrency#map-failed-expected-versions | Map failed expected versions | rule | checkable | ConcurrencyVersionTests assert a failed expected version returns 409 Problem Details with its stable code. |
| litespec/ext/concurrency#map-replay-responses-at-the-api-boundary | Map replay responses at the API boundary | convention | checkable | ConcurrencyTests assert replay response mapping lives at the API boundary. |
| litespec/ext/concurrency#protect-fingerprint-source-data | Protect fingerprint source data | rule | guidance | Is sensitive fingerprint source data hashed wherever support needs no original content? |
| litespec/ext/concurrency#reject-conflicting-key-reuse | Reject conflicting key reuse | rule | checkable | IdempotencyKeyTests assert reused keys with changed input return the documented rejection. |
| litespec/ext/concurrency#reject-silent-overwrites | Reject silent overwrites | rule | checkable | ConcurrencyVersionTests assert conflicting accepted writes preserve the winner without silent replacement. |
| litespec/ext/concurrency#reload-concurrent-winners | Reload concurrent winners | rule | checkable | IdempotencyReplayTests reload and replay the matching winner record. |
| litespec/ext/concurrency#replay-completed-results | Replay completed results | rule | checkable | IdempotencyReplayTests return the original accepted status and body. |
| litespec/ext/concurrency#restrict-replay-data | Restrict replay data | rule | guidance | Does each stored replay field serve the accepted result callers reproduce? |
| litespec/ext/concurrency#retain-safe-retry-keys | Retain safe retry keys | rule | checkable | IdempotencyRetentionTests reject expiration before the documented safe retry time. |
| litespec/ext/concurrency#return-precondition-outcomes | Return precondition outcomes | rule | checkable | ConcurrencyVersionTests return 428 for a missing If-Match and 409 for a stale version. |
| litespec/ext/concurrency#route-required-external-effects-durably | Route required external effects durably | rule | guidance | Does each required effect use the outbox or a documented provider idempotency contract? |
| litespec/ext/concurrency#scope-client-keys | Scope client keys | rule | checkable | IdempotencyKeyTests assert keys from different tenants, actors, or operations do not replay each other. |
| litespec/ext/concurrency#set-key-retention | Set key retention | rule | guidance | Does the Limit record cover the caller retry window and the business risk? |
| litespec/ext/concurrency#store-idempotency-state-atomically | Store idempotency state atomically | rule | checkable | IdempotencyKeyTests commit fingerprint, state, response, and expiry with the accepted business change. |
| litespec/ext/concurrency#use-the-standard-idempotency-header | Use the standard idempotency header | convention | checkable | ConcurrencyTests assert applicable operations accept Idempotency-Key or record an Exception. |
| litespec/ext/containers#apply-oci-release-labels | Apply OCI release labels | rule | checkable | ContainersMetadataTests assert the four required OCI labels on built images. |
| litespec/ext/containers#apply-schema-work-before-traffic | Apply schema work before traffic | rule | checkable | ContainersSchemaTests place the reviewed schema job before the traffic shift. |
| litespec/ext/containers#build-from-the-workspace-root | Build from the workspace root | convention | checkable | ContainersTests assert image builds access declared shared inputs from repository-root context. |
| litespec/ext/containers#build-release-images-in-stages | Build release images in stages | rule | checkable | ContainersImageTests assert multi-stage builds and digest-pinned release bases. |
| litespec/ext/containers#copy-only-runtime-files | Copy only runtime files | rule | checkable | ContainersImageTests match the image file listing against the declared runtime manifest. |
| litespec/ext/containers#declare-writable-paths-and-limits | Declare writable paths and limits | rule | checkable | ContainersSecurityTests match the manifest against declared writable paths and Limit records. |
| litespec/ext/containers#exclude-build-material-from-runtime-images | Exclude build material from runtime images | rule | checkable | ContainersImageTests find no build-only files or local configuration in runtime images. |
| litespec/ext/containers#exclude-build-timestamps-from-contracts | Exclude build timestamps from contracts | rule | checkable | ContainersMetadataTests assert the generated-contract diff contains no build timestamp. |
| litespec/ext/containers#exclude-environment-configuration-from-images | Exclude environment configuration from images | rule | checkable | ContainersConfigTests find no environment-specific configuration in release images. |
| litespec/ext/containers#exclude-insecure-frontend-secret-carriers | Exclude insecure frontend secret carriers | rule | checkable | ContainersConfigTests reject ARG, copied environment files, and secret-bearing layers. |
| litespec/ext/containers#keep-mutable-data-external | Keep mutable data external | rule | guidance | Does the design keep every piece of mutable data outside the container filesystem? |
| litespec/ext/containers#keep-schema-work-out-of-startup | Keep schema work out of startup | rule | checkable | ContainersSchemaTests observe no production schema mutation from replica startup. |
| litespec/ext/containers#limit-container-privileges | Limit container privileges | rule | checkable | ContainersSecurityTests assert read-only filesystem and dropped capabilities in the deployment manifest. |
| litespec/ext/containers#place-dockerfiles-beside-deployables | Place Dockerfiles beside deployables | convention | checkable | ContainersTests assert a colocated Dockerfile per deployable or a recorded Exception. |
| litespec/ext/containers#record-image-digests | Record image digests | rule | checkable | ContainersMetadataTests identify the deployed artifact by immutable digest in the release record. |
| litespec/ext/containers#retain-rollback-material | Retain rollback material | rule | checkable | ContainersRollbackTests resolve the Runbook record and its previous image digest. |
| litespec/ext/containers#run-images-as-non-root | Run images as non-root | rule | checkable | ContainersImageTests assert the declared non-root runtime user. |
| litespec/ext/containers#run-the-application-as-pid-1 | Run the application as PID 1 | rule | checkable | ContainersProcessTests confirm the application receives the container stop signal. |
| litespec/ext/containers#separate-frontend-configuration-classes | Separate frontend configuration classes | rule | guidance | Does the frontend build keep public configuration apart from server-only secrets? |
| litespec/ext/containers#set-sufficient-shutdown-time | Set sufficient shutdown time | rule | checkable | ContainersProcessTests assert in-flight work stops within the declared grace period. |
| litespec/ext/containers#supply-runtime-configuration-externally | Supply runtime configuration externally | rule | checkable | ContainersConfigTests match deployment manifests against runtime values declared outside the image. |
| litespec/ext/containers#test-released-traffic | Test released traffic | rule | checkable | ContainersTrafficTests pass after new-version traffic shift. |
| litespec/ext/containers#use-protected-frontend-secret-delivery | Use protected frontend secret delivery | rule | guidance | Does the frontend build deliver every secret through mounts or runtime injection? |
| litespec/ext/containers#wait-for-replica-readiness | Wait for replica readiness | rule | checkable | ContainersTrafficTests assert new replicas reach readiness before traffic shifts. |
| litespec/ext/containers#write-runtime-logs-to-streams | Write runtime logs to streams | rule | checkable | ContainersProcessTests assert container logs appear on standard output or standard error. |
| litespec/ext/delegation#ask-only-unanswered-questions | Ask only unanswered questions | rule | guidance | Does the worker ask only questions its brief leaves unanswered? |
| litespec/ext/delegation#restrict-a-worker-to-its-paths | Restrict a worker to its paths | rule | checkable | git diff --name-only lists only the brief's named paths. The worker commits nothing. |
| litespec/ext/delegation#verify-before-accepting-worker-output | Verify before accepting worker output | rule | guidance | Which verification run does the delegating agent watch pass before accepting the output? |
| litespec/ext/delegation#write-a-brief-before-delegating | Write a brief before delegating | rule | guidance | Does each brief state goal, context, sources, and output? |
| litespec/ext/integrations#bind-client-configuration | Bind client configuration | rule | checkable | ExternalClientTests reject missing or invalid external client configuration. |
| litespec/ext/integrations#bound-transient-retries | Bound transient retries | rule | checkable | ExternalRetryTests verify bounded jittered retry for transient failures. |
| litespec/ext/integrations#cover-provider-failure-modes | Cover provider failure modes | rule | checkable | ExternalTestTests suite covers every declared failure mode. |
| litespec/ext/integrations#define-business-action-ports | Define business-action ports | rule | guidance | Does each Application port name a business action without naming its provider? |
| litespec/ext/integrations#exclude-provider-internals | Exclude provider internals | rule | checkable | ExternalFailureTests expose no provider body, credential, header, type, or account identifier. |
| litespec/ext/integrations#group-provider-code | Group provider code | convention | guidance | Does each provider folder hold its code or record an Exception? |
| litespec/ext/integrations#isolate-provider-implementations | Isolate provider implementations | rule | checkable | ExternalPortTests assert the Application assembly references no provider SDK or transport type. |
| litespec/ext/integrations#keep-ports-near-use-cases | Keep ports near use cases | convention | guidance | Does each business-action port stay with its owning Application use case? |
| litespec/ext/integrations#keep-provider-components-together | Keep provider components together | convention | guidance | Does each provider folder hold its options, client, models, mappings, and registration? |
| litespec/ext/integrations#process-duplicate-messages-safely | Process duplicate messages safely | rule | checkable | ExternalInboundTests leave one accepted external effect. |
| litespec/ext/integrations#protect-non-idempotent-calls | Protect non-idempotent calls | rule | checkable | ExternalRetryTests show no retry without documented provider protection. |
| litespec/ext/integrations#reject-formula-leading-import-values | Reject formula-leading import values | rule | checkable | ExternalInboundTests reject or neutralize formula-leading import values. |
| litespec/ext/integrations#reject-per-request-http-clients | Reject per-request HTTP clients | rule | checkable | ExternalClientTests report no per-request HTTP client construction. |
| litespec/ext/integrations#simulate-integration-boundaries | Simulate integration boundaries | rule | checkable | ExternalTestTests run each provider contract against a controllable local endpoint. |
| litespec/ext/integrations#translate-provider-failure-outcomes | Translate provider failure outcomes | rule | checkable | ExternalFailureTests assert provider failures map to project-owned outcomes and stable diagnostics. |
| litespec/ext/integrations#use-managed-http-clients | Use managed HTTP clients | rule | checkable | ExternalClientTests assert HTTP registration uses the owned factory and declared discovery path. |
| litespec/ext/integrations#verify-inbound-provider-messages | Verify inbound provider messages | rule | checkable | ExternalInboundTests reject invalid signatures, timestamps, content, size, schema, and identities. |
| litespec/ext/jobs#audit-manual-replay | Audit manual replay | rule | guidance | Does manual replay create a new audited attempt under the same identity? |
| litespec/ext/jobs#bound-job-execution | Bound job execution | rule | guidance | Does each job honor cancellation and duration bounds and stop during shutdown? |
| litespec/ext/jobs#bound-job-retries | Bound job retries | rule | guidance | Are attempts bounded with cancellation-aware backoff and a poison state? |
| litespec/ext/jobs#define-business-local-clock-behavior | Define business-local clock behavior | rule | guidance | Does each local schedule name its zone and transition behavior? |
| litespec/ext/jobs#define-misfire-recovery | Define misfire recovery | rule | guidance | Does the specification define skip or replay behavior for missed occurrences? |
| litespec/ext/jobs#derive-stable-occurrence-identity | Derive stable occurrence identity | rule | guidance | Are occurrence identities stable per schedule and instant, with declared retention? |
| litespec/ext/jobs#dispatch-application-behavior | Dispatch Application behavior | rule | guidance | Does each job dispatch an Application Command or approved port? |
| litespec/ext/jobs#exclude-direct-storage-and-http-execution | Exclude direct storage and HTTP execution | rule | guidance | Is job source free of direct storage mutation and WebApi calls? |
| litespec/ext/jobs#exclude-machine-local-time | Exclude machine-local time | rule | guidance | Is production job code free of machine-local time reads? |
| litespec/ext/jobs#generate-monotonic-fencing-values | Generate monotonic fencing values | rule | guidance | Are fencing values monotonic per occurrence and checked on completion? |
| litespec/ext/jobs#persist-occurrence-recovery-points | Persist occurrence recovery points | rule | guidance | Does the store persist last scheduled, started, and completed times? |
| litespec/ext/jobs#persist-occurrence-state | Persist occurrence state | rule | guidance | Does the store persist scheduled, processing, completed, and dead-letter state? |
| litespec/ext/jobs#place-handlers-with-owned-behavior | Place handlers with owned behavior | convention | guidance | Does each handler sit with its behavior's module or record an Exception? |
| litespec/ext/jobs#prefer-utc-schedules | Prefer UTC schedules | rule | guidance | Is each schedule UTC or a documented business-local deviation? |
| litespec/ext/jobs#prevent-duplicate-completion | Prevent duplicate completion | rule | guidance | Does the lease prevent two replicas from completing one occurrence? |
| litespec/ext/jobs#provide-operational-recovery-procedures | Provide operational recovery procedures | rule | guidance | Do Runbook records cover inspection, manual replay, and disable? |
| litespec/ext/jobs#record-schedule-behavior | Record schedule behavior | rule | guidance | Does each schedule record name every required field, its owner, and its status? |
| litespec/ext/jobs#renew-only-owned-leases | Renew only owned leases | rule | guidance | Does a replica stop when its lease renewal fails? |
| litespec/ext/jobs#restrict-completion-by-fencing-value | Restrict completion by fencing value | rule | guidance | Is completion refused once the fencing value is stale? |
| litespec/ext/jobs#run-jobs-in-worker | Run jobs in Worker | rule | guidance | Does every scheduled job run in Worker, outside WebApi request handling? |
| litespec/ext/jobs#scope-command-idempotency-by-occurrence | Scope command idempotency by occurrence | rule | guidance | Do retries of one occurrence share its idempotency scope? |
| litespec/ext/jobs#scope-occurrences-and-leases-by-tenant | Scope occurrences and leases by tenant | rule | guidance | Do occurrences and leases carry tenant scope where tenants are isolated? |
| litespec/ext/jobs#separate-schedule-definitions | Separate schedule definitions | convention | guidance | Are schedule definitions separate from Command behavior or is an Exception recorded? |
| litespec/ext/jobs#store-execution-leases | Store execution leases | rule | guidance | Does the store record lease owner, expiry, and fencing value per occurrence? |
| litespec/ext/jobs#test-time-transitions | Test time transitions | rule | guidance | Do tests inject the clock and cover representative transitions? |
| litespec/ext/jobs#tolerate-duplicate-execution | Tolerate duplicate execution | rule | guidance | Do the job Command and side effect stay correct when a lease or process failure replays them? |
| litespec/ext/jobs#treat-unavailable-schedule-stores-as-outages | Treat unavailable schedule stores as outages | rule | guidance | Does an unavailable store get backed-off, rate-limited logging? |
| litespec/ext/jobs#use-execution-scopes | Use execution scopes | convention | guidance | Does each occurrence resolve scoped dependencies in one disposed scope? |
| litespec/ext/lifecycle#align-backup-deletion-behavior | Align backup deletion behavior | rule | guidance | Do backups and replicas follow the documented deletion guarantee? |
| litespec/ext/lifecycle#authorize-and-audit-lifecycle-changes | Authorize and audit lifecycle changes | rule | guidance | Does each operation apply its authorization and record its audit? |
| litespec/ext/lifecycle#authorize-lifecycle-access-paths | Authorize lifecycle access paths | rule | guidance | Do administrative and restore queries use named authorized paths? |
| litespec/ext/lifecycle#bound-purge-and-archive-work | Bound purge and archive work | rule | guidance | Is purge and archive work resumable, bounded, and observable? |
| litespec/ext/lifecycle#default-to-hard-delete | Default to hard delete | rule | guidance | Is deletion hard wherever no retention or restore requirement applies? |
| litespec/ext/lifecycle#define-post-deletion-references | Define post-deletion references | rule | guidance | Does the specification state which post-deletion references, exports, and uniqueness rules remain? |
| litespec/ext/lifecycle#define-relational-lifecycle-behavior | Define relational lifecycle behavior | rule | guidance | Does the relational implementation define columns, filters, indexes, and migrations? |
| litespec/ext/lifecycle#define-storage-lifecycle-behavior | Define storage lifecycle behavior | rule | guidance | Does the document implementation define state, queries, indexes, and purge behavior? |
| litespec/ext/lifecycle#exclude-inactive-records-from-normal-reads | Exclude inactive records from normal reads | rule | guidance | Do normal queries exclude deleted and archived records? |
| litespec/ext/lifecycle#exclude-persistence-only-lifecycle-behavior | Exclude persistence-only lifecycle behavior | rule | guidance | Does storage behavior alone implement any lifecycle rule? |
| litespec/ext/lifecycle#keep-archive-records-module-owned | Keep archive records module-owned | convention | guidance | Do archive records stay in the owning module or record an Exception? |
| litespec/ext/lifecycle#model-lifecycle-operations-in-domain | Model lifecycle operations in Domain | rule | guidance | Does the aggregate expose each applicable lifecycle operation? |
| litespec/ext/lifecycle#model-retained-lifecycle-states | Model retained lifecycle states | rule | guidance | Does each retained record have a business reason and explicit transition? |
| litespec/ext/lifecycle#name-soft-delete-timestamps | Name soft-delete timestamps | convention | guidance | Do soft-delete timestamps use the default or record an Exception? |
| litespec/ext/lifecycle#preserve-legal-hold-data | Preserve legal-hold data | rule | guidance | Does retention work record progress and preserve held data? |
| litespec/ext/lifecycle#record-lifecycle-scope | Record lifecycle scope | rule | guidance | Does each lifecycle record name every required field, its owner, and its status? |
| litespec/ext/lifecycle#record-the-release-of-a-legal-hold | Record the release of a legal hold | rule | guidance | Does each legal-hold release record actor, data, reason, and resumed retention? |
| litespec/ext/lifecycle#reject-hidden-lifecycle-flags | Reject hidden lifecycle flags | rule | guidance | Is lifecycle behavior more than a hidden boolean? |
| litespec/ext/lifecycle#separate-query-shaped-history | Separate query-shaped history | convention | guidance | Is query-shaped history a read model or is an Exception recorded? |
| litespec/ext/lifecycle#test-provider-lifecycle-paths | Test provider lifecycle paths | rule | guidance | Do tests cover normal and lifecycle query paths? |
| litespec/ext/locale#avoid-catalog-only-locale-claims | Avoid catalog-only locale claims | rule | guidance | Is supported-locale evidence the decision rather than catalog files? |
| litespec/ext/locale#avoid-duplicate-localized-urls | Avoid duplicate localized URLs | rule | guidance | Is there one indexable URL per localized content item? |
| litespec/ext/locale#complete-or-fall-back-catalog-values | Complete or fall back catalog values | rule | guidance | Does each locale resolve required keys or use its declared fallback? |
| litespec/ext/locale#define-one-locale-route-shape | Define one locale route shape | rule | guidance | Does the application define and use one locale route shape? |
| litespec/ext/locale#follow-the-validation-message-grammar | Follow the validation message grammar | rule | guidance | Does each validation message state label, fault, and accepted input? |
| litespec/ext/locale#format-values-with-active-locale | Format values with active locale | rule | guidance | Are dates, numbers, currency, plurals, lists, and relative time localized? |
| litespec/ext/locale#handle-unavailable-locale-segments | Handle unavailable locale segments | rule | guidance | Do unsupported or missing locale segments follow product policy? |
| litespec/ext/locale#keep-locale-selection-explicit | Keep locale selection explicit | convention | guidance | Is selection in the URL or a documented session preference? |
| litespec/ext/locale#keep-stable-error-codes-locale-neutral | Keep stable error codes locale-neutral | rule | guidance | Is each stable error code identical across locales? |
| litespec/ext/locale#localize-public-presentation-content | Localize public presentation content | rule | guidance | Do metadata, labels, validation, and safe errors follow the active locale? |
| litespec/ext/locale#name-messages-by-meaning | Name messages by meaning | rule | guidance | Do catalog keys cite Term records instead of source sentences? |
| litespec/ext/locale#preserve-locale-neutral-business-data | Preserve locale-neutral business data | rule | guidance | Do Domain values and API contracts stay locale-neutral? |
| litespec/ext/locale#record-supported-locale-behavior | Record supported locale behavior | rule | guidance | Does the decision list locales, default, fallback, selection, owner, and status? |
| litespec/ext/locale#resolve-every-shown-identifier | Resolve every shown identifier | rule | guidance | Does each shown code render its Term label rather than the raw code? |
| litespec/ext/locale#split-catalogs-by-module-when-needed | Split catalogs by module when needed | convention | guidance | Is each module split justified by size or is an Exception recorded? |
| litespec/ext/locale#store-user-facing-copy-in-catalogs | Store user-facing copy in catalogs | rule | guidance | Is user-facing copy stored in locale catalogs? |
| litespec/ext/locale#use-bcp-47-identifiers | Use BCP 47 identifiers | convention | guidance | Are locale identifiers BCP 47 or is an Exception recorded? |
| litespec/ext/locale#use-one-catalog-root | Use one catalog root | convention | guidance | Do catalogs sit under one owned root or record an Exception? |
| litespec/ext/mcp#confirm-every-writing-tool | Confirm every writing tool | rule | guidance | Does every writing tool refuse until the person confirms? |
| litespec/ext/mcp#exclude-secrets-and-personal-data | Exclude secrets and personal data | rule | guidance | Are descriptions and logs free of secrets and personal data? |
| litespec/ext/mcp#pass-server-instructions-at-initialize | Pass server instructions at initialize | rule | guidance | Does the server pass a non-empty instructions value at initialize? |
| litespec/ext/mcp#scope-each-tool-to-named-use-cases | Scope each tool to named use cases | rule | guidance | Does each tool name the use cases and permissions it reaches? |
| litespec/ext/mcp#state-the-distribution-and-update-path | State the distribution and update path | rule | guidance | Does the documentation state install and update steps? |
| litespec/ext/mcp#state-the-refusing-side-on-each-refusal | State the refusing side on each refusal | convention | guidance | Do refusals carry the three prefixes or record an Exception? |
| litespec/ext/mcp#write-one-tool-description-for-one-decision | Write one tool description for one decision | rule | guidance | Does {path}, the declared tools directory, show imperative titles and stated side effects? |
| litespec/ext/outbox#accept-repeated-delivery | Accept repeated delivery | rule | guidance | Does each consumer handle the same message twice? |
| litespec/ext/outbox#audit-outbox-replay | Audit outbox replay | rule | guidance | Does each replay record actor, reason, time, and prior failure? |
| litespec/ext/outbox#avoid-automatic-durable-bus-adoption | Avoid automatic durable-bus adoption | convention | guidance | Is any durable package pinned with transaction evidence or avoided? |
| litespec/ext/outbox#await-target-acceptance | Await target acceptance | rule | guidance | Does the Worker withhold completion until the target accepts? |
| litespec/ext/outbox#back-off-unavailable-store-polling | Back off unavailable-store polling | rule | guidance | Does polling back off with rate-limited logging during outages? |
| litespec/ext/outbox#bound-delivery-retries | Bound delivery retries | rule | guidance | Are retries bounded with exponential backoff and jitter? |
| litespec/ext/outbox#classify-message-kinds | Classify message kinds | rule | guidance | Does each record name its kind and cite its Event record? |
| litespec/ext/outbox#classify-permanent-delivery-failure | Classify permanent delivery failure | rule | guidance | Do permanent failures dead-letter with safe replay evidence? |
| litespec/ext/outbox#define-claim-ownership | Define claim ownership | rule | guidance | Does each claim use the jobs lease definition in a short transaction? |
| litespec/ext/outbox#deploy-readers-before-writers | Deploy readers before writers | rule | guidance | Do releases deploy compatible readers before additive writers? |
| litespec/ext/outbox#dispatch-claimed-records-in-worker | Dispatch claimed records in Worker | rule | guidance | Does the Worker claim bounded batches and record outcomes? |
| litespec/ext/outbox#dispatch-journey-step-commands-in-a-new-scope | Dispatch journey-step commands in a new scope | convention | guidance | Are journey-step commands dispatched in a fresh Worker scope? |
| litespec/ext/outbox#distinguish-dependency-outage | Distinguish dependency outage | rule | guidance | Is store outage distinct from claimed-message failure? |
| litespec/ext/outbox#exclude-manually-repeatable-reactions | Exclude manually repeatable reactions | rule | guidance | Is the outbox free of manually repeatable best-effort reactions? |
| litespec/ext/outbox#exclude-request-transaction-dispatch | Exclude request-transaction dispatch | rule | guidance | Are request paths free of durable message dispatch? |
| litespec/ext/outbox#gate-dispatch-on-readiness | Gate dispatch on readiness | rule | guidance | Does readiness gate dispatch and stop dead-store polling? |
| litespec/ext/outbox#group-outbox-infrastructure | Group outbox infrastructure | convention | guidance | Is outbox infrastructure grouped or is an Exception recorded? |
| litespec/ext/outbox#identify-repeated-delivery | Identify repeated delivery | rule | guidance | Does each consumer suppress repeats by message ID or business key? |
| litespec/ext/outbox#isolate-the-worker-host | Isolate the Worker host | convention | guidance | Is the Worker host separate or is an Exception recorded? |
| litespec/ext/outbox#keep-provider-mapping-with-integration | Keep provider mapping with integration | convention | guidance | Does provider mapping stay with its integration or record an Exception? |
| litespec/ext/outbox#model-outbox-lifecycle-states | Model outbox lifecycle states | rule | guidance | Are lifecycle states sealed records with documented transitions? |
| litespec/ext/outbox#plan-undispatched-rollback-records | Plan undispatched rollback records | rule | guidance | Does the rollback Runbook cover undispatched new-writer records? |
| litespec/ext/outbox#preserve-message-identity-during-retry | Preserve message identity during retry | rule | guidance | Is message ID stable across retry and replay? |
| litespec/ext/outbox#protect-active-worker-compatibility | Protect active Worker compatibility | rule | guidance | Can every active Worker read new message shapes? |
| litespec/ext/outbox#publish-backlog-indicators | Publish backlog indicators | rule | guidance | Does the deployment publish pending, failed, age, attempts, duration, and rate? |
| litespec/ext/outbox#publish-best-effort-reactions-after-commit | Publish best-effort reactions after commit | rule | guidance | Do excluded reactions publish after commit without staging records? |
| litespec/ext/outbox#record-durable-delivery-behavior | Record durable delivery behavior | rule | guidance | Does each delivery specification record guarantee, boundary, retry, owner, and status? |
| litespec/ext/outbox#reject-independent-outbox-commits | Reject independent outbox commits | rule | guidance | Is writer source free of independent connections and commits? |
| litespec/ext/outbox#release-claim-transactions-before-calls | Release claim transactions before calls | rule | guidance | Are claim transactions released before network calls? |
| litespec/ext/outbox#requeue-expired-claims | Requeue expired claims | rule | guidance | Do expired claims return to eligible work? |
| litespec/ext/outbox#restrict-completion-to-current-lease-owners | Restrict completion to current lease owners | rule | guidance | Does only the current lease owner update records? |
| litespec/ext/outbox#restrict-message-retry-to-claimed-records | Restrict message retry to claimed records | rule | guidance | Does the Worker limit retries to claimed records? |
| litespec/ext/outbox#serialize-durable-messages | Serialize durable messages | rule | guidance | Is each pending message serialized into an outbox record? |
| litespec/ext/outbox#set-delivery-alerts | Set delivery alerts | rule | guidance | Are alert thresholds Limit records derived from the delivery target? |
| litespec/ext/outbox#stage-messages-with-business-work | Stage messages with business work | rule | guidance | Are messages staged in the same session as business changes? |
| litespec/ext/outbox#store-failure-and-completion-evidence | Store failure and completion evidence | rule | guidance | Does each record retain its error summary and completion time? |
| litespec/ext/outbox#store-required-message-fields | Store required message fields | rule | guidance | Does each record hold identity, kind, type, version, time, payload, and state? |
| litespec/ext/outbox#support-coexisting-message-producers | Support coexisting message producers | rule | guidance | Does the dispatcher read every coexisting producer shape? |
| litespec/ext/outbox#version-message-types | Version message types | rule | guidance | Does each message carry a stable type name and schema version? |
| litespec/ext/realtime#authenticate-and-authorize-subscriptions | Authenticate and authorize subscriptions | rule | guidance | Do anonymous, unrelated, owner, and tenant-scoped connections meet the authorization rule? |
| litespec/ext/realtime#bound-realtime-resources | Bound realtime resources | rule | guidance | Does each of the four bounds live as a Limit record with its value? |
| litespec/ext/realtime#place-realtime-code-at-outer-boundaries | Place realtime code at outer boundaries | convention | guidance | Does realtime transport code sit at the documented boundaries or a recorded Exception? |
| litespec/ext/realtime#reconnect-and-refresh-authoritative-state | Reconnect and refresh authoritative state | rule | guidance | Does the client reconnect with bounded backoff and refresh authoritative state? |
| litespec/ext/realtime#record-realtime-need | Record realtime need | rule | guidance | Does the use-case page record polling, cost, target latency, connections, and recovery? |
| litespec/ext/realtime#record-transport-support | Record transport support | rule | guidance | Does the use-case page record the transport and hosting support? |
| litespec/ext/realtime#reject-cosmetic-realtime-adoption | Reject cosmetic realtime adoption | rule | guidance | Does the realtime decision cite a measurable update requirement? |
| litespec/ext/realtime#reject-unbounded-slow-client-buffering | Reject unbounded slow-client buffering | rule | guidance | Is slow-client buffering bounded with controlled backpressure? |
| litespec/ext/realtime#revalidate-long-lived-access | Revalidate long-lived access | rule | guidance | Does an expired session or token lose access? |
| litespec/ext/realtime#subscribe-through-narrow-functions | Subscribe through narrow functions | convention | guidance | Do features subscribe through operation-specific functions or a recorded Exception? |
| litespec/ext/realtime#tolerate-notification-ordering-differences | Tolerate notification ordering differences | rule | guidance | Do duplicate and reordered notifications leave client state correct? |
| litespec/ext/realtime#use-server-sent-events-for-notifications | Use server-sent events for notifications | rule | guidance | Does each one-way notification use the server-sent events boundary? |
| litespec/ext/realtime#use-signalr-for-interactive-messaging | Use SignalR for interactive messaging | rule | guidance | Does each bidirectional use case use SignalR capabilities? |
| litespec/ext/report#apply-item-read-authorization | Apply item-read authorization | rule | guidance | Does each report and export enforce the item-read rules? |
| litespec/ext/report#avoid-speculative-reporting-systems | Avoid speculative reporting systems | rule | guidance | Does reporting serve an accepted current query or export? |
| litespec/ext/report#define-export-encoding-and-columns | Define export encoding and columns | rule | guidance | Does each export state its encoding and stable columns? |
| litespec/ext/report#define-report-limits | Define report limits | rule | guidance | Does each report bound live as a Limit record? |
| litespec/ext/report#escape-formula-leading-export-values | Escape formula-leading export values | rule | guidance | Are formula-leading export values escaped except for reviewed formula fields? |
| litespec/ext/report#keep-raw-sql-in-infrastructure | Keep raw SQL in Infrastructure | rule | guidance | Do raw report SQL and connection handling live in Infrastructure? |
| litespec/ext/report#keep-report-definitions-in-application | Keep report definitions in Application | convention | guidance | Do report definitions live in their module or a recorded Exception? |
| litespec/ext/report#keep-report-providers-in-infrastructure | Keep report providers in Infrastructure | convention | guidance | Do SQL and storage code live in Infrastructure or a recorded Exception? |
| litespec/ext/report#parameterize-report-sql | Parameterize report SQL | rule | guidance | Does every report query bind actor, tenant, filter, range, sort, and pagination values? |
| litespec/ext/report#protect-export-output | Protect export output | rule | guidance | Does export output carry an owner and expiry with short-lived authorized download? |
| litespec/ext/report#record-reporting-need | Record reporting need | rule | guidance | Does the use-case page record the report, volume, plan, target, maximum, and owner? |
| litespec/ext/report#review-report-plans | Review report plans | rule | guidance | Did the owner review plans and indexes on representative data? |
| litespec/ext/report#run-budget-exceeding-exports-in-worker | Run budget-exceeding exports in Worker | rule | guidance | Does each export past its request budget run through Worker? |
| litespec/ext/report#scope-export-output-to-the-tenant | Scope export output to the tenant | rule | guidance | Does each export store its output under a tenant-scoped path? |
| litespec/ext/report#separate-worker-orchestration | Separate Worker orchestration | convention | guidance | Is Worker orchestration separate from report business rules or a recorded Exception? |
| litespec/ext/report#support-report-cancellation | Support report cancellation | rule | guidance | Does report work cancel, and does expired output clear? |
| litespec/ext/site#avoid-client-scripts-without-a-named-interactive-need | Avoid client scripts without a named interactive need | rule | guidance | Does each shipped script serve a recorded interactive need? |
| litespec/ext/site#declare-each-static-site-in-the-project-record | Declare each static site in the project record | rule | checkable | litespec consumer refuses a selected site extension whose paths.sites entry is missing. |
| litespec/ext/site#default-to-a-light-scheme-with-a-reader-chosen-dark-scheme | Default to a light scheme with a reader-chosen dark scheme | convention | guidance | Is light the initial scheme with a reader-chosen dark scheme or a recorded Exception? |
| litespec/ext/site#generate-a-sitemap-covering-every-page | Generate a sitemap covering every page | rule | guidance | Does the sitemap list every page with its alternates? |
| litespec/ext/site#generate-the-site-with-astro | Generate the site with Astro | convention | guidance | Does Astro generate the site or does an Exception record a replacement? |
| litespec/ext/site#give-every-page-one-main-heading-and-landmark-elements | Give every page one main heading and landmark elements | rule | guidance | Does every page carry one top-level heading and landmarks? |
| litespec/ext/site#keep-each-repeated-fact-in-one-data-source | Keep each repeated fact in one data source | rule | guidance | Does each repeated fact live in one source, with each product word as a Term record? |
| litespec/ext/site#list-every-page-for-language-models | List every page for language models | rule | guidance | Does the page list match the built pages? |
| litespec/ext/site#load-every-script-from-the-site-origin | Load every script from the site origin | rule | guidance | Does every client script load from the site origin? |
| litespec/ext/site#load-nothing-from-a-third-party-origin | Load nothing from a third-party origin | rule | guidance | Does any page load from a third-party origin? |
| litespec/ext/site#mark-pages-with-json-ld-structured-data | Mark pages with JSON-LD structured data | rule | guidance | Does every page carry its JSON-LD graph? |
| litespec/ext/site#mark-unfinished-facts-with-visible-placeholders | Mark unfinished facts with visible placeholders | rule | guidance | Does each missing fact show a visible placeholder naming it? |
| litespec/ext/site#name-every-page-with-a-title-and-a-description | Name every page with a title and a description | rule | guidance | Does every page state its title and description? |
| litespec/ext/site#point-crawler-rules-at-the-sitemap | Point crawler rules at the sitemap | rule | guidance | Do the crawler rules point at the sitemap? |
| litespec/ext/site#point-every-page-at-its-absolute-canonical-address | Point every page at its absolute canonical address | rule | guidance | Does every page link its absolute canonical address? |
| litespec/ext/site#publish-a-markdown-copy-beside-every-page | Publish a Markdown copy beside every page | rule | guidance | Does every page link its Markdown copy? |
| litespec/ext/site#publish-full-page-text-for-language-models | Publish full page text for language models | rule | guidance | Does the full-text file match the default-language pages? |
| litespec/ext/site#read-prices-and-claims-from-product-and-pricing-records | Read prices and claims from product and pricing records | convention | guidance | Do prices and claims read the brief and pricing record or a recorded Exception? |
| litespec/ext/site#read-site-prices-and-claims-from-consumer-records | Read site prices and claims from consumer records | rule | guidance | Does each site price and claim trace to its named record? |
| litespec/ext/site#reference-language-alternates-from-every-translated-page | Reference language alternates from every translated page | rule | guidance | Does each translated page link its alternates and fallback? |
| litespec/ext/site#reject-a-release-build-carrying-a-placeholder | Reject a release build carrying a placeholder | rule | guidance | Does a release build fail while a placeholder remains? |
| litespec/ext/site#render-components-on-the-server-with-astro-or-svelte | Render components on the server with Astro or Svelte | convention | guidance | Do Astro or Svelte sources render server-side or does an Exception record a replacement? |
| litespec/ext/site#render-every-language-from-one-page-structure | Render every language from one page structure | rule | guidance | Does one structure render every language, with each language supplying only text? |
| litespec/ext/site#render-every-page-to-static-files | Render every page to static files | rule | guidance | Does the build write every page as a static file needing no server? |
| litespec/ext/site#state-allowed-sources-in-a-content-security-policy | State allowed sources in a content security policy | rule | guidance | Does the policy name every source the pages load? |
| litespec/ext/site#use-tailwind-for-site-styles | Use Tailwind for site styles | convention | guidance | Do Tailwind styles build the site or does an Exception record a replacement? |
| litespec/ext/stage#declare-the-release-stage | Declare the release stage | rule | checkable | litespec consumer refuses a stage selection with a missing or unknown releaseStage. |
| litespec/ext/stage#defer-named-provisions-until-promotion | Defer named provisions until promotion | rule | checkable | litespec consumer refuses a deferral naming an unknown provision or past its until date, and any deferral in production. |
| litespec/ext/stage#promote-through-a-recorded-decision | Promote through a recorded decision | rule | guidance | Does an approved promotion Decision predate the first deployment holding customer data? |
| litespec/ext/tenancy#apply-cross-tenant-disclosure-policy | Apply cross-tenant disclosure policy | rule | guidance | Does each cross-tenant response use the documented policy? |
| litespec/ext/tenancy#avoid-unplanned-isolation-models | Avoid unplanned isolation models | rule | guidance | Does each mixed model record its decision and evolution plan? |
| litespec/ext/tenancy#define-tenant-isolation | Define tenant isolation | rule | guidance | Does the decision define the isolation model, guarantee, and trade-off? |
| litespec/ext/tenancy#isolate-administrative-cross-tenant-access | Isolate administrative cross-tenant access | rule | guidance | Does administrative access need its platform-scope Permission and write its audit record? |
| litespec/ext/tenancy#pass-tenant-scope-explicitly | Pass tenant scope explicitly | convention | guidance | Does domain code read no ambient tenant state, or does an Exception record it? |
| litespec/ext/tenancy#protect-tenant-diagnostics | Protect tenant diagnostics | rule | guidance | Do diagnostics exclude foreign tenant identifiers and data? |
| litespec/ext/tenancy#record-an-all-tenant-operation | Record an all-tenant operation | rule | guidance | Does each all-tenant run write its record with count and bounded list? |
| litespec/ext/tenancy#record-the-tenant-adoption-decision | Record the tenant adoption decision | rule | guidance | Does an owned Decision record the tenant source, model, guarantee, access, path, and bound? |
| litespec/ext/tenancy#reject-unrestricted-tenant-input | Reject unrestricted tenant input | rule | guidance | Can request tampering with a tenant ID select another boundary? |
| litespec/ext/tenancy#resolve-tenant-identity-from-trusted-context | Resolve tenant identity from trusted context | rule | guidance | Does each trusted source resolve the tenant? |
| litespec/ext/tenancy#scope-tenant-operations | Scope tenant operations | rule | guidance | Does each procedure declare one-tenant or all-tenant scope? |
| litespec/ext/tenancy#scope-tenant-owned-records | Scope tenant-owned records | rule | guidance | Does every listed boundary include tenant scope? |
| litespec/ext/tenancy#use-one-tenant-accessor | Use one tenant accessor | convention | guidance | Does the host boundary hold one current-tenant accessor or a recorded Exception? |
| litespec/ext/tenancy#use-selected-tenant-storage-support | Use selected tenant storage support | rule | guidance | Does each provider resolve the tenant at session creation? |
| litespec/ext/tenancy#use-typed-tenant-identities | Use typed tenant identities | convention | guidance | Do tenant references use TenantId or a recorded Exception? |
| litespec/ext/tenancy#verify-actor-and-target-tenancy | Verify actor and target tenancy | rule | guidance | Do mismatched actor and target tenants fail? |
frontend#
| ID | Provision | Kind | Mark | Evidence |
|---|---|---|---|---|
| litespec/frontend/blazor/browser#bound-what-is-stored | Bound what is stored | rule | guidance | Does each persisting specification state its collection bound and eviction rule? |
| litespec/frontend/blazor/browser#keep-a-stable-serialization-contract | Keep a stable serialization contract | convention | guidance | Does a record with an unknown property still read? |
| litespec/frontend/blazor/browser#own-storage-in-infrastructure | Own storage in Infrastructure | rule | guidance | Does every storage call resolve the Application interface? |
| litespec/frontend/blazor/browser#provide-a-migration-for-every-changed-shape | Provide a migration for every changed shape | rule | guidance | Does each changed shape ship a migration reading every released version? |
| litespec/frontend/blazor/browser#provide-export-and-import | Provide export and import | rule | guidance | Does an export reimport to identical durable state, refusing a newer version? |
| litespec/frontend/blazor/browser#record-the-classification | Record the classification | convention | guidance | Do durable and device-local keys use separate prefixes? |
| litespec/frontend/blazor/browser#select-the-storage-mechanism-per-shape | Select the storage mechanism per shape | convention | guidance | Does each persisted shape use its declared mechanism? |
| litespec/frontend/blazor/browser#treat-reads-as-fallible | Treat reads as fallible | rule | guidance | Does the adapter return unavailable, absent, corrupt, and present as typed outcomes? |
| litespec/frontend/blazor/browser#version-and-scope-every-storage-key | Version and scope every storage key | rule | guidance | Is each key a declared constant carrying product, area, and version? |
| litespec/frontend/blazor/components#apply-one-styling-system | Apply one styling system | convention | guidance | Is each color, spacing, and font value a defined token? |
| litespec/frontend/blazor/components#declare-every-parameter-type | Declare every parameter type | rule | guidance | Does each parameter declare a feature-owned concrete type? |
| litespec/frontend/blazor/components#keep-accessibility-in-the-component | Keep accessibility in the component | rule | guidance | Do keyboard paths and announcements work in each interactive component? |
| litespec/frontend/blazor/components#keep-components-presentational | Keep components presentational | rule | guidance | Does any component resolve storage, interop, or a Domain service? |
| litespec/frontend/blazor/components#name-for-the-boundary-role | Name for the boundary role | convention | guidance | Does each feature component name match its rendered role? |
| litespec/frontend/blazor/components#own-the-layer-contract | Own the layer contract | rule | guidance | Does any view model expose a Domain or Application type? |
| litespec/frontend/blazor/components#place-one-component-per-file | Place one component per file | rule | guidance | Does each component file declare one primary component? |
| litespec/frontend/blazor/components#raise-events-rather-than-mutating | Raise events rather than mutating | rule | guidance | Does each child report upward through a callback parameter? |
| litespec/frontend/blazor/components#resolve-browser-behavior-through-an-interface | Resolve browser behavior through an interface | rule | guidance | Does any component inject the interop runtime directly? |
| litespec/frontend/blazor/data#classify-state | Classify state | rule | guidance | Does each specification introducing state name one classification? |
| litespec/frontend/blazor/data#keep-derived-values-single-sourced | Keep derived values single-sourced | rule | guidance | Does each derived value have one computation site? |
| litespec/frontend/blazor/data#keep-forms-typed | Keep forms typed | convention | guidance | Does each form bind a feature-owned model and map to a command? |
| litespec/frontend/blazor/data#load-persisted-state-once | Load persisted state once | rule | guidance | Does persisted state load before the first render? |
| litespec/frontend/blazor/data#make-failure-explicit | Make failure explicit | rule | guidance | Does each handler union cover success and every named failure? |
| litespec/frontend/blazor/data#prefer-explicit-refresh | Prefer explicit refresh | convention | guidance | Does the store update from each result without a follow-up query? |
| litespec/frontend/blazor/data#route-use-cases-through-application | Route use cases through Application | rule | guidance | Does any component resolve a Domain service or storage adapter? |
| litespec/frontend/blazor/data#validate-at-the-boundary | Validate at the boundary | rule | guidance | Does each form failure originate from its Application validator? |
| litespec/frontend/blazor/rendering#declare-routes-on-pages | Declare routes on pages | rule | guidance | Does each routable component declare one template with typed parameters? |
| litespec/frontend/blazor/rendering#give-every-route-explicit-states | Give every route explicit states | rule | guidance | Does each route render its six states, with not-found for bad parameters? |
| litespec/frontend/blazor/rendering#keep-navigation-state-in-the-url | Keep navigation state in the URL | convention | guidance | Does refresh-surviving state appear in the route or query string? |
| litespec/frontend/blazor/rendering#keep-the-acquisition-surface-static | Keep the acquisition surface static | rule | guidance | Does each landing page load without fetching the framework payload? |
| litespec/frontend/blazor/rendering#name-routes-for-the-reader | Name routes for the reader | convention | guidance | Does each template match its documented use-case name? |
| litespec/frontend/blazor/rendering#operate-offline-after-first-load | Operate offline after first load | rule | guidance | Does the application start offline after first load, with stated limits? |
| litespec/frontend/blazor/rendering#render-on-the-client-only | Render on the client only | rule | guidance | Does the published output declare no server render mode? |
| litespec/frontend/blazor/stack#keep-blazor-outside-the-ui-contract | Keep Blazor outside the UI contract | rule | guidance | Does the consumer apply any UI contract page or route check? |
| litespec/frontend/blazor/stack#publish-static-webassembly-output | Publish static WebAssembly output | rule | guidance | Does the published output hold no server assembly or server render mode? |
| litespec/frontend/blazor/stack#record-a-first-load-budget | Record a first-load budget | convention | guidance | Does Operating Limits record the budget the publish job enforces? |
| litespec/frontend/blazor/stack#verify-with-the-net-toolchain | Verify with the .NET toolchain | convention | guidance | Does the CI client job run dotnet build and dotnet test? |
| litespec/frontend/blazor/structure#isolate-module-internals | Isolate module internals | rule | guidance | Does any cross-module reference resolve an internal feature type? |
| litespec/frontend/blazor/structure#keep-domain-free-of-browser-concerns | Keep Domain free of browser concerns | rule | guidance | Do Domain and Application reference any browser or interop type? |
| litespec/frontend/blazor/structure#keep-imports-directional | Keep imports directional | rule | guidance | Does the reference graph match the declared direction? |
| litespec/frontend/blazor/structure#keep-static-content-out-of-the-assembly | Keep static content out of the assembly | convention | guidance | Does published output serve runtime content from wwwroot/ rather than embedded resources? |
| litespec/frontend/blazor/structure#organize-features-by-module-and-use-case | Organize features by module and use case | rule | guidance | Does each feature path resolve to a declared module and use case? |
| litespec/frontend/blazor/structure#place-interop-adapters-together | Place interop adapters together | convention | guidance | Does each adapter sit beside its matching script, or record a replacement? |
| litespec/frontend/blazor/structure#use-the-client-solution-tree | Use the client solution tree | rule | guidance | Do four production projects exist, with no server project? |
| litespec/frontend/blazor/testing#enforce-the-first-load-budget | Enforce the first-load budget | rule | guidance | Does the CI publish job fail when transfer size exceeds the recorded budget? |
| litespec/frontend/blazor/testing#keep-browser-capability-tests-honest | Keep browser-capability tests honest | convention | guidance | Does each capability-dependent feature test both its paths? |
| litespec/frontend/blazor/testing#keep-end-to-end-tests-few | Keep end-to-end tests few | convention | guidance | Does each browser case map to a required flow or named interaction? |
| litespec/frontend/blazor/testing#prove-each-case-with-a-test | Prove each case with a test | rule | guidance | Does each Case have a test whose steps call the use case and assert the Result? |
| litespec/frontend/blazor/testing#replace-interop-in-component-tests | Replace interop in component tests | rule | guidance | Does each render substitute every Application interface? |
| litespec/frontend/blazor/testing#test-the-core-without-a-browser | Test the core without a browser | rule | guidance | Does any core test project reference a browser or interop type? |
| litespec/frontend/blazor/testing#use-the-four-client-test-projects | Use the four client test projects | rule | guidance | Do the four test projects exist and run in CI? |
| litespec/frontend/blazor/testing#verify-real-browser-behavior-end-to-end | Verify real browser behavior end to end | rule | guidance | Does the browser suite cover the primary flow, storage loss, offline startup, and portability? |
| litespec/frontend/components#add-a-missing-composite-to-the-shared-package | Add a missing composite to the shared package | rule | guidance | Is every layout, control, or surface a second page needs exported from the shared package? |
| litespec/frontend/components#compose-composites-in-page-code | Compose composites in page code | rule | checkable | litespec ui refuses a primitive library import reached from an application. |
| litespec/frontend/components#expose-card-and-section-titles-as-headings | Expose card and section titles as headings | convention | guidance | Does every visible card, panel, or section title render as a heading at its correct level? |
| litespec/frontend/components#keep-component-inputs-narrow | Keep component inputs narrow | rule | guidance | Does any composite input type name a client, a store, or a business record? |
| litespec/frontend/components#keep-domain-values-typed-until-display | Keep domain values typed until display | convention | guidance | Does conversion to display strings happen only at the presentation boundary? |
| litespec/frontend/components#keep-error-boundaries-scoped | Keep error boundaries scoped | convention | guidance | Does each error boundary have a recovery path that keeps its surroundings usable? |
| litespec/frontend/components#keep-shared-ui-in-one-package | Keep shared UI in one package | rule | guidance | Does one shared package hold the shared primitives and the composites, with no copy in an application? |
| litespec/frontend/components#name-components-for-their-role | Name components for their role | convention | guidance | Does every component name describe the role it plays? |
| litespec/frontend/components#place-a-drawing-no-composite-makes-in-an-exception-file | Place a drawing no composite makes in an exception file | rule | guidance | Does every exception file use semantic tokens only, with no custom styling elsewhere? |
| litespec/frontend/components#prefer-a-composite-over-a-primitive | Prefer a composite over a primitive | rule | guidance | Does page code import a primitive where the shared package provides a composite? |
| litespec/frontend/components#render-complete-states | Render complete states | rule | guidance | Does every data component render each named state and every control render its own, with each name a recorded term? |
| litespec/frontend/components#sanitize-untrusted-rich-content | Sanitize untrusted rich content | rule | guidance | Does any component render untrusted content without its recorded sanitization decision? |
| litespec/frontend/components#support-keyboard-focus-labels-and-announcements | Support keyboard, focus, labels, and announcements | rule | guidance | Does interactive UI support keyboard operation, visible focus, semantic elements, programmatic labels, and status announcements? |
| litespec/frontend/components#use-a-composite-for-a-content-image | Use a composite for a content image | rule | guidance | Does every content image render through the shared image component with its owned text? |
| litespec/frontend/components#use-composites-for-layout-and-interaction-in-page-code | Use composites for layout and interaction in page code | rule | guidance | Does page code declare a refused element, and does each refusal name its composite? |
| litespec/frontend/components#use-declared-visual-variants | Use declared visual variants | rule | guidance | Does every repeated variant use theme tokens through the variant helper? |
| litespec/frontend/components#write-no-class-name-in-page-code | Write no class name in page code | rule | guidance | Does any component under a route or module folder declare a class or style binding? |
| litespec/frontend/data#announce-the-outcome-of-an-optimistic-update | Announce the outcome of an optimistic update | rule | guidance | Does a differing server result announce through a live region? |
| litespec/frontend/data#assign-state-to-the-narrowest-owner | Assign state to the narrowest owner | rule | guidance | Does each value live with the narrowest owner the order allows? |
| litespec/frontend/data#build-a-form-on-the-shared-form-library | Build a form on the shared form library | convention | guidance | Is each form built on the shared package's form entry point and field components? |
| litespec/frontend/data#generate-the-client-from-the-published-contract | Generate the client from the published contract | rule | guidance | Is every client, type, schema, and operation option generated from the published contract? |
| litespec/frontend/data#keep-schemas-operation-specific | Keep schemas operation specific | convention | guidance | Does each shared schema serve two real readers? |
| litespec/frontend/data#keep-secrets-out-of-browser-storage | Keep secrets out of browser storage | rule | guidance | Is any secret or privileged credential kept out of browser storage and public variables? |
| litespec/frontend/data#keep-the-client-boundary-in-the-frame | Keep the client boundary in the frame | convention | guidance | Do the client configuration, problem mapping, and download helpers sit only in the frame root? |
| litespec/frontend/data#keep-the-session-in-an-api-owned-cookie | Keep the session in an API owned cookie | rule | guidance | Does the API hold the session in an HTTP-only cookie with no token in frontend code? |
| litespec/frontend/data#localize-copy-through-locale-dictionaries | Localize copy through locale dictionaries | rule | guidance | Does all copy resolve through locale dictionaries with fill, plurals, and a declared fallback? |
| litespec/frontend/data#make-optimistic-behavior-recoverable | Make optimistic behavior recoverable | rule | guidance | Does each optimistic update declare identity, conflict behavior, rollback, and reconciliation? |
| litespec/frontend/data#map-every-failure-to-one-problem-type | Map every failure to one problem type | rule | guidance | Does every failure become one problem, with the trace identifier shown in the error detail? |
| litespec/frontend/data#name-the-zone-for-every-timestamp | Name the zone for every timestamp | rule | guidance | Does each timestamp formatter receive an explicit IANA zone from its caller? |
| litespec/frontend/data#place-a-field-refusal-on-its-field | Place a field refusal on its field | rule | guidance | Does each field problem reach its field through the frame's helper, with the form left open? |
| litespec/frontend/data#place-a-refusal-beside-what-was-refused | Place a refusal beside what was refused | rule | guidance | Does each refusal render beside what was refused, in the application's sentence for its code? |
| litespec/frontend/data#read-a-permission-from-the-session | Read a permission from the session | rule | guidance | Does each offered command follow the Actor's held Permissions, with the API deciding? |
| litespec/frontend/data#regenerate-the-client-rather-than-editing-it | Regenerate the client rather than editing it | convention | guidance | Is the committed client regenerated from the document with no hand edit under it? |
| litespec/frontend/data#route-a-personal-value-in-a-header | Route a personal value in a header | rule | guidance | Does each person-naming value travel in its contract-declared header? |
| litespec/frontend/data#set-the-write-marker-on-every-request | Set the write marker on every request | rule | guidance | Does the client send the configured marker header on every write? |
| litespec/frontend/data#update-the-cache-a-command-changed | Update the cache a command changed | rule | guidance | Does each successful command invalidate the queries it changed and no others? |
| litespec/frontend/data#use-one-configured-client-per-application | Use one configured client per application | rule | guidance | Does every read and write pass through the one configured client? |
| litespec/frontend/data#validate-a-form-with-the-generated-schema | Validate a form with the generated schema | rule | guidance | Does a spec submit contract-invalid input and assert a client-side refusal? |
| litespec/frontend/patterns#declare-the-compact-behavior | Declare the compact behavior | rule | checkable | litespec ui reports a compact option naming no recorded option. |
| litespec/frontend/patterns#implement-a-chosen-pattern-once | Implement a chosen pattern once | rule | checkable | litespec ui reports a named component path that does not exist. |
| litespec/frontend/patterns#keep-a-visual-registry | Keep a visual registry | convention | guidance | Does the registry render every product-added option in each theme at compact and full widths? |
| litespec/frontend/patterns#keep-one-pattern-catalog | Keep one pattern catalog | rule | checkable | litespec ui reports a missing catalog or a schema failure. |
| litespec/frontend/patterns#keep-the-catalog-platform-neutral | Keep the catalog platform neutral | rule | guidance | Does any pattern name a component library outside implementations? |
| litespec/frontend/patterns#promote-pattern-improvements | Promote pattern improvements | convention | guidance | Did each accepted generic proposal reach the LiteSpec pattern page as a new or refined option? |
| litespec/frontend/patterns#record-every-option-considered | Record every option considered | rule | checkable | litespec ui reports fewer than two options or a choice naming no option. |
| litespec/frontend/patterns#record-who-chose | Record who chose | rule | guidance | Does each decision record owner or recommended, with no agent-marked owner choice? |
| litespec/frontend/patterns#report-pattern-feedback-after-the-work | Report pattern feedback after the work | convention | guidance | Does each completion report carry proposals with pattern id, change, reason, and option? |
| litespec/frontend/patterns#start-from-a-litespec-pattern | Start from a LiteSpec pattern | convention | guidance | Does each entry set library or record its own reason, keeping the pattern's option IDs? |
| litespec/frontend/patterns#state-the-implementation-status | State the implementation status | rule | checkable | litespec ui reports a partial or pending entry without a gap. |
| litespec/frontend/patterns#update-the-catalog-with-the-code | Update the catalog with the code | rule | guidance | Did the catalog entry change with its implementation or name a record? |
| litespec/frontend/patterns/admin-screens#api-keys-and-webhooks | API keys and webhooks | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/admin-screens#bringing-data-from-spreadsheets | Bringing data from spreadsheets | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/admin-screens#connecting-the-payment-account | Connecting the payment account | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/admin-screens#discount-and-promotion-codes | Discount and promotion codes | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/admin-screens#show-a-new-secret-once | Show a new secret once | rule | guidance | Does every built screen of this kind keep this rule, including in its compact layout? |
| litespec/frontend/patterns/admin-screens#show-what-a-role-allows-before-granting-it | Show what a role allows before granting it | rule | guidance | Does every built screen of this kind keep this rule, including in its compact layout? |
| litespec/frontend/patterns/admin-screens#supplier-invoice | Supplier invoice | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/admin-screens#team-members-and-their-roles | Team members and their roles | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/create-edit-remove#changing-a-record-that-already-exists | Changing a record that already exists | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/create-edit-remove#changing-something-that-has-already-happened | Changing something that has already happened | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/create-edit-remove#confirm-or-undo-every-removal | Confirm or undo every removal | rule | guidance | Does every built screen of this kind keep this rule, including in its compact layout? |
| litespec/frontend/patterns/create-edit-remove#creating-a-record-and-then-filling-it-in | Creating a record and then filling it in | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/create-edit-remove#creating-one-record | Creating one record | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/create-edit-remove#duplicating-a-record | Duplicating a record | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/create-edit-remove#inviting-a-team-member | Inviting a team member | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/create-edit-remove#publishing-and-unpublishing-a-listing | Publishing and unpublishing a listing | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/create-edit-remove#putting-a-list-in-order-by-hand | Putting a list in order by hand | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/create-edit-remove#removing-several-at-once | Removing several at once | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/create-edit-remove#removing-something | Removing something | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/create-edit-remove#restoring-an-archived-record | Restoring an archived record | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/create-edit-remove#scheduling-a-change-for-later | Scheduling a change for later | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/create-edit-remove#show-the-created-record | Show the created record | rule | guidance | Does every built screen of this kind keep this rule, including in its compact layout? |
| litespec/frontend/patterns/dialogs-and-overlays#bar-that-stays-while-the-reader-works | Bar that stays while the reader works | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/dialogs-and-overlays#bottom-sheet-on-a-phone | Bottom sheet on a phone | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/dialogs-and-overlays#confirming-a-command-that-cannot-be-taken-back | Confirming a command that cannot be taken back | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/dialogs-and-overlays#context-menu-where-the-pointer-is | Context menu where the pointer is | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/dialogs-and-overlays#dialog-with-a-long-body-and-a-sticky-footer | Dialog with a long body and a sticky footer | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/dialogs-and-overlays#drawer-beside-the-list | Drawer beside the list | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/dialogs-and-overlays#keyboard-shortcut-help-overlay | Keyboard shortcut help overlay | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/dialogs-and-overlays#menu-of-a-rows-commands | Menu of a row's commands | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/dialogs-and-overlays#name-the-command-on-a-confirm-action | Name the command on a confirm action | rule | guidance | Does every built page of this kind keep this rule, including in its compact layout? |
| litespec/frontend/patterns/dialogs-and-overlays#return-focus-when-an-overlay-closes | Return focus when an overlay closes | rule | guidance | Does every built page of this kind keep this rule, including in its compact layout? |
| litespec/frontend/patterns/dialogs-and-overlays#short-panel-that-opens-beside-a-control | Short panel that opens beside a control | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/dialogs-and-overlays#short-task-in-a-dialog | Short task in a dialog | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/dialogs-and-overlays#toast-at-the-edge-of-the-screen | Toast at the edge of the screen | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/feedback-and-states#back-office-is-down-for-a-short-while | Back office is down for a short while | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/feedback-and-states#command-that-worked | Command that worked | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/feedback-and-states#command-the-api-refused | Command the API refused | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/feedback-and-states#connection-is-gone | Connection is gone | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/feedback-and-states#fact-somebody-has-to-read-before-acting | Fact somebody has to read before acting | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/feedback-and-states#keep-the-readers-input-through-a-failure | Keep the reader's input through a failure | rule | guidance | Does every built screen of this kind keep this rule, including in its compact layout? |
| litespec/frontend/patterns/feedback-and-states#loading | Loading | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/feedback-and-states#nothing-has-ever-existed | Nothing has ever existed | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/feedback-and-states#nothing-matches-what-was-asked-for | Nothing matches what was asked for | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/feedback-and-states#reader-may-not-do-this | Reader may not do this | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/feedback-and-states#sign-in-ran-out | Sign-in ran out | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/feedback-and-states#somebody-else-saved-first | Somebody else saved first | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/feedback-and-states#something-went-wrong-on-our-side | Something went wrong on our side | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/feedback-and-states#state-what-failed-and-the-next-step | State what failed and the next step | rule | guidance | Does every built screen of this kind keep this rule, including in its compact layout? |
| litespec/frontend/patterns/feedback-and-states#this-record-does-not-exist | This record does not exist | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/feedback-and-states#too-many-tries | Too many tries | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/feedback-and-states#work-that-runs-without-you | Work that runs without you | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/forms-and-fields#address-field | Address field | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/forms-and-fields#capacity-field | Capacity field | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/forms-and-fields#choosing-a-record | Choosing a record | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/forms-and-fields#choosing-one-of-a-few-options | Choosing one of a few options | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/forms-and-fields#color-field-for-the-storefront-accent | Color field for the storefront accent | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/forms-and-fields#date-and-time-field | Date and time field | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/forms-and-fields#email-body-editor | Email body editor | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/forms-and-fields#keep-entered-values-after-a-refused-submit | Keep entered values after a refused submit | rule | guidance | Does every built screen of this kind keep this rule, including in its compact layout? |
| litespec/frontend/patterns/forms-and-fields#money-field | Money field | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/forms-and-fields#name-every-field-with-a-visible-label | Name every field with a visible label | rule | guidance | Does every built screen of this kind keep this rule, including in its compact layout? |
| litespec/frontend/patterns/forms-and-fields#picking-a-period | Picking a period | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/forms-and-fields#repeatable-group-for-price-tiers | Repeatable group for price tiers | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/forms-and-fields#reporting-a-refused-submit | Reporting a refused submit | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/forms-and-fields#slug-or-url-field-with-a-preview | Slug or URL field with a preview | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/forms-and-fields#switch-or-a-checkbox | Switch or a checkbox | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/forms-and-fields#tag-input | Tag input | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/forms-and-fields#text-field-and-its-states | Text field and its states | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/forms-and-fields#upload-field | Upload field | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/forms-and-fields#work-that-is-not-saved | Work that is not saved | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/lists-and-tables#align-money-to-the-right-with-its-currency | Align money to the right with its currency | rule | guidance | Does every built screen of this kind keep this rule, including in its compact layout? |
| litespec/frontend/patterns/lists-and-tables#bulk-action-bar | Bulk action bar | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/lists-and-tables#choosing-the-columns | Choosing the columns | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/lists-and-tables#deliveries-as-a-grid | Deliveries as a grid | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/lists-and-tables#exporting-the-list | Exporting the list | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/lists-and-tables#filters | Filters | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/lists-and-tables#grouped-rows | Grouped rows | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/lists-and-tables#inline-row-expansion | Inline row expansion | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/lists-and-tables#keep-a-lists-view-in-its-address | Keep a list's view in its address | rule | guidance | Does every built screen of this kind keep this rule, including in its compact layout? |
| litespec/frontend/patterns/lists-and-tables#list-on-a-phone | List on a phone | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/lists-and-tables#money-column | Money column | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/lists-and-tables#pagination | Pagination | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/lists-and-tables#pinned-and-resizing-columns | Pinned and resizing columns | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/lists-and-tables#row-actions | Row actions | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/lists-and-tables#row-density | Row density | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/lists-and-tables#searching-with-highlighted-matches | Searching with highlighted matches | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/lists-and-tables#sorting | Sorting | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/lists-and-tables#status-in-a-column | Status in a column | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/lists-and-tables#tables-own-states | Table's own states | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/money-time-density#choosing-a-period | Choosing a period | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/money-time-density#counting-things | Counting things | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/money-time-density#figure-against-an-earlier-period | Figure against an earlier period | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/money-time-density#how-much-fits-before-it-breaks | How much fits before it breaks | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/money-time-density#numbers-at-phone-width | Numbers at phone width | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/money-time-density#sales-by-product-variant | Sales by product variant | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/money-time-density#sales-over-time | Sales over time | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/money-time-density#sell-through-against-capacity | Sell-through against capacity | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/money-time-density#show-the-currency-of-every-amount | Show the currency of every amount | rule | guidance | Does every built screen of this kind keep this rule, including in its compact layout? |
| litespec/frontend/patterns/money-time-density#showing-an-identifier | Showing an identifier | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/money-time-density#state-the-time-zone-of-a-shared-moment | State the time zone of a shared moment | rule | guidance | Does every built screen of this kind keep this rule, including in its compact layout? |
| litespec/frontend/patterns/money-time-density#statement-that-adds-up | Statement that adds up | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/money-time-density#two-vat-rates-on-one-page | Two VAT rates on one page | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/money-time-density#vendors-invoice-to-the-company | Vendor's invoice to the company | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/money-time-density#when-the-money-arrives | When the money arrives | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/money-time-density#writing-a-moment | Writing a moment | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/money-time-density#writing-an-amount | Writing an amount | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/navigation#account-menu | Account menu | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/navigation#breadcrumb | Breadcrumb | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/navigation#command-palette | Command palette | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/navigation#give-every-page-its-own-address | Give every page its own address | rule | guidance | Does every built screen of this kind keep this rule, including in its compact layout? |
| litespec/frontend/patterns/navigation#header-bar | Header bar | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/navigation#help-and-support | Help and support | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/navigation#icons-in-the-frame | Icons in the frame | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/navigation#language-and-theme | Language and theme | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/navigation#mark-the-current-section | Mark the current section | rule | guidance | Does every built screen of this kind keep this rule, including in its compact layout? |
| litespec/frontend/patterns/navigation#notification-inbox | Notification inbox | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/navigation#phone-navigation | Phone navigation | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/navigation#sidebar | Sidebar | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/navigation#tabs-within-a-page | Tabs within a page | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/navigation#workspace-switcher | Workspace switcher | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/page-frames#calendar-or-schedule-page | Calendar or schedule page | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/page-frames#editor-page | Editor page | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/page-frames#error-or-not-found-page | Error or not-found page | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/page-frames#form-page | Form page | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/page-frames#home-page | Home page | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/page-frames#list-page | List page | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/page-frames#live-operations-page | Live operations page | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/page-frames#name-the-page-in-one-heading | Name the page in one heading | rule | guidance | Does every built screen of this kind keep this rule, including in its compact layout? |
| litespec/frontend/patterns/page-frames#onboarding-or-setup-page | Onboarding or setup page | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/page-frames#outcome-page | Outcome page | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/page-frames#queue | Queue | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/page-frames#record-drawer | Record drawer | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/page-frames#record-page | Record page | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/page-frames#report-page | Report page | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/page-frames#settings-home | Settings home | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/page-frames#show-one-primary-action-in-a-page-frame | Show one primary action in a page frame | rule | guidance | Does every built screen of this kind keep this rule, including in its compact layout? |
| litespec/frontend/patterns/record-detail#keep-destructive-commands-out-of-the-primary-place | Keep destructive commands out of the primary place | rule | guidance | Does every destructive command on a record page sit outside the primary place, in its own tone? |
| litespec/frontend/patterns/record-detail#order-record | Order record | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/record-detail#previous-and-next-record | Previous and next record | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/record-detail#property-list-with-copy | Property list with copy | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/record-detail#record-aside | Record aside | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/record-detail#record-attachments | Record attachments | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/record-detail#record-change-history | Record change history | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/record-detail#record-header | Record header | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/record-detail#record-header-on-a-phone | Record header on a phone | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/record-detail#record-notes | Record notes | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/record-detail#record-summary | Record summary | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/record-detail#record-tabs | Record tabs | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/record-detail#record-the-reader-may-not-change | Record the reader may not change | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/record-detail#record-timeline | Record timeline | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/record-detail#related-records | Related records | pattern | guidance | Does the built page follow the default option, or the option the project catalog records with its reason? |
| litespec/frontend/patterns/record-detail#show-one-primary-action-in-a-record-header | Show one primary action in a record header | rule | checkable | litespec patterns check refuses a wireframe header holding two primary actions; a reviewer confirms each built record header holds at most one. |
| litespec/frontend/rendering#build-the-server-data-cache-per-request | Build the server data cache per request | rule | guidance | Does each server request construct its own data cache? |
| litespec/frontend/rendering#keep-address-parameters-validated-by-a-schema | Keep address parameters validated by a schema | rule | guidance | Does each route declare its address parameters in a schema, with no direct reads? |
| litespec/frontend/rendering#keep-authenticated-caching-explicit | Keep authenticated caching explicit | rule | guidance | Does each cached actor-specific read declare its key, boundary, owner, and review? |
| litespec/frontend/rendering#keep-layouts-stable | Keep layouts stable | convention | guidance | Is each provider required by every child route? |
| litespec/frontend/rendering#keep-proxy-behavior-at-the-edge | Keep proxy behavior at the edge | rule | guidance | Does any proxy rule decide the actor or what the actor may read? |
| litespec/frontend/rendering#keep-server-only-code-identifiable | Keep server-only code identifiable | convention | guidance | Does each server-owned module sit in a file named for the server? |
| litespec/frontend/rendering#load-each-route-and-each-language-separately | Load each route and each language separately | rule | guidance | Does each route and each language load as its own download? |
| litespec/frontend/rendering#load-route-data-before-rendering | Load route data before rendering | rule | guidance | Does each route that reads load it through one shared cache before its view renders? |
| litespec/frontend/rendering#prefetch-a-route-on-intent | Prefetch a route on intent | rule | guidance | Does the router prefetch the route the reader signals intent toward, with no second cache? |
| litespec/frontend/rendering#read-route-data-from-the-route-cache | Read route data from the route cache | rule | guidance | Does each read name the entry its route filled? |
| litespec/frontend/rendering#represent-route-states | Represent route states | rule | guidance | Does an absent address render the shared outcome page? |
| litespec/frontend/rendering#use-a-shared-layout-for-a-shell | Use a shared layout for a shell | convention | guidance | Does each shell sit in a shared layout? |
| litespec/frontend/structure#cover-public-use-cases-in-journeys | Cover public use cases in journeys | rule | guidance | Does every public use case appear in a journey or name its background caller? |
| litespec/frontend/structure#keep-a-route-entry-thin | Keep a route entry thin | rule | guidance | Does each route entry hold only its input, its load, and its component? |
| litespec/frontend/structure#keep-a-use-case-folder-flat | Keep a use case folder flat | rule | guidance | Does each use-case folder hold files and no subfolder? |
| litespec/frontend/structure#keep-applications-independent | Keep applications independent | rule | guidance | Does any frontend import source from another frontend? |
| litespec/frontend/structure#keep-shared-packages-non-application-specific | Keep shared packages non application specific | rule | guidance | Does any shared package name a use case or a screen? |
| litespec/frontend/structure#locate-cross-route-values-in-the-frame | Locate cross-route values in the frame | rule | guidance | Does the frame hold every cross-route value and browser use? |
| litespec/frontend/structure#mirror-the-backend-use-case-path-in-kebab-case | Mirror the backend use case path in kebab case | rule | guidance | Does each use-case folder resolve to its backend folder? |
| litespec/frontend/structure#order-imports-from-routes-to-shared-packages | Order imports from routes to shared packages | rule | guidance | Does every import follow the route to module to frame to package direction? |
| litespec/frontend/structure#organize-a-frontend-into-frame-routes-and-modules | Organize a frontend into frame, routes, and modules | rule | guidance | Does each frontend use a frame, routes, and use-case modules? |
| litespec/frontend/structure#place-a-shared-file-in-the-folder-that-owns-it | Place a shared file in the folder that owns it | rule | guidance | Does each shared file sit in the narrowest folder holding every reader? |
| litespec/frontend/structure#place-tests-at-their-ownership-boundary | Place tests at their ownership boundary | convention | guidance | Do logic tests sit beside their module and browser suites share one root? |
| litespec/frontend/structure#reject-a-folder-name-that-owns-nothing | Reject a folder name that owns nothing | rule | guidance | Does any folder carry a refused name? |
| litespec/frontend/structure#use-explicit-public-entry-points-for-shared-packages | Use explicit public entry points for shared packages | convention | guidance | Does any application import a path its package does not export? |
| litespec/frontend/testing#assert-each-declared-refusal-by-its-code | Assert each declared refusal by its code | rule | guidance | Does the specification reach each declared refusal and assert it by its Result's code? |
| litespec/frontend/testing#isolate-browser-tests | Isolate browser tests | rule | guidance | Does each browser test create its own data, context, and expected state? |
| litespec/frontend/testing#keep-mocks-at-owned-boundaries | Keep mocks at owned boundaries | rule | guidance | Is every mock at an owned boundary, replacing no library internal or private function? |
| litespec/frontend/testing#keep-test-support-narrow | Keep test support narrow | convention | guidance | Do the helpers stay limited to providers, one API helper, and locators? |
| litespec/frontend/testing#match-test-level-to-risk | Match test level to risk | rule | guidance | Does each new test sit at the level its risk requires? |
| litespec/frontend/testing#prove-a-case-by-calling-its-use-case | Prove a case by calling its use case | rule | guidance | Do the test's steps call the use case and assert the Result, submitting where money moves? |
| litespec/frontend/testing#prove-the-module-mirror-in-a-structure-test | Prove the module mirror in a structure test | rule | guidance | Does the structure test resolve every module folder to a backend use-case folder? |
| litespec/frontend/testing#query-by-accessible-behavior | Query by accessible behavior | convention | guidance | Does each identifier query lack a stable user-facing alternative? |
| litespec/frontend/testing#reach-every-public-use-case-from-a-journey | Reach every public use case from a journey | rule | guidance | Does every public use case sit in a Journey or name its background caller? |
| litespec/frontend/testing#read-the-deployment-for-its-identifiers | Read the deployment for its identifiers | convention | guidance | Is each record identifier read from the deployment rather than written in a specification? |
| litespec/frontend/testing#run-browser-checks-through-the-command-line | Run browser checks through the command line | rule | guidance | Does each browser check run through the command line per route and per file? |
| litespec/frontend/testing#test-observable-states | Test observable states | rule | guidance | Does each test assert observable output in the states its situation reaches? |
| litespec/frontend/testing#use-network-mocks-for-component-tests | Use network mocks for component tests | rule | guidance | Does each component test needing HTTP run through contract-generated network mocks? |
| litespec/frontend/ui#check-every-route | Check every route | rule | guidance | Does every route pass each route suite check? |
| litespec/frontend/ui#compose-each-route-from-one-floorplan | Compose each route from one floorplan | rule | guidance | Does every route render exactly one floorplan from the declared set or record its freestyle decision? |
| litespec/frontend/ui#declare-a-closed-floorplan-set | Declare a closed floorplan set | rule | guidance | Does the Patterns section list every floorplan with a when-to-use rule? |
| litespec/frontend/ui#derive-each-page-type-from-a-named-reference | Derive each page type from a named reference | rule | guidance | Does every route name its page type reference, with each freestyle route naming its decision record? |
| litespec/frontend/ui#govern-behavior-packages | Govern behavior packages | rule | guidance | Does every behavior package name its approving decision and render through baseline components and tokens? |
| litespec/frontend/ui#hold-the-declared-base-color | Hold the declared base color | rule | guidance | Does the token definition carry only declared baseline values, with each departure recorded? |
| litespec/frontend/ui#keep-a-blocked-command-visible-with-its-reason | Keep a blocked command visible with its reason | convention | guidance | Does each disabled command stay visible with its reason? |
| litespec/frontend/ui#keep-layout-inside-floorplans | Keep layout inside floorplans | rule | guidance | Does any route file declare layout outside its floorplan and display composites? |
| litespec/frontend/ui#keep-separators-at-the-subtle-step | Keep separators at the subtle step | rule | guidance | Is every structural separator and input border at the published border step or lighter? |
| litespec/frontend/ui#keep-tokens-in-one-definition | Keep tokens in one definition | rule | guidance | Does each application use the shared token definition with no declared value and no literal color? |
| litespec/frontend/ui#pin-the-baseline-in-the-shared-package | Pin the baseline in the shared package | rule | checkable | litespec ui reports a workspace with no pinned baseline installed once in its shared package. |
| litespec/frontend/ui#prove-every-result-a-route-calls | Prove every result a route calls | rule | guidance | Is every result the route calls proved by a passing test or named by a known-gap record? |
| litespec/frontend/ui#prove-ui-behavior-and-appearance | Prove UI behavior and appearance | rule | guidance | Does each change name the evidence the matrix assigns to its class? |
| litespec/frontend/ui#publish-a-design-contract | Publish a design contract | rule | checkable | litespec ui reports a missing contract, a schema failure, or a missing section. |
| litespec/frontend/ui#record-a-freestyle-route | Record a freestyle route | rule | guidance | Does every freestyle route name the decision record that justifies its layout? |
| litespec/frontend/ui#record-a-frontend-outside-the-controlled-contract | Record a frontend outside the controlled contract | rule | guidance | Does every frontend outside the controlled platforms declare its platform and name its replacement boundaries? |
| litespec/frontend/ui#restrict-styling-to-semantic-tokens | Restrict styling to semantic tokens | rule | guidance | Does every style use a semantic token rather than a raw value? |
| litespec/frontend/ui#select-a-command-surface-by-size | Select a command surface by size | rule | guidance | Does each command use the surface the Concepts table assigns to its input? |
| litespec/frontend/ui#select-a-tone-from-the-closed-set | Select a tone from the closed set | rule | guidance | Does each application declare its state-to-tone mapping once as an exhaustive table of terms? |
| litespec/frontend/ui#select-one-visual-authority | Select one visual authority | rule | checkable | litespec consumer refuses a frontend with no declared platform and a workspace with a controlled frontend but no shared package. |
| litespec/frontend/ui#show-the-trace-id-in-error-detail | Show the trace ID in error detail | rule | guidance | Does every visible error show its trace identifier copyably in its detail rather than its headline? |
| litespec/frontend/ui#use-the-product-profiles | Use the product profiles | convention | checkable | litespec ui refuses a controlled frontend with no density profile. |
| litespec/frontend/web/components#compose-class-names-in-the-shared-package | Compose class names in the shared package | convention | guidance | Does every class merge go through the shared package helper? |
| litespec/frontend/web/components#give-card-and-section-titles-heading-semantics | Give card and section titles heading semantics | convention | checkable | tests/routes/every-route.spec.ts asserts each visible section title resolves as a heading. |
| litespec/frontend/web/components#keep-primitives-and-composites-in-one-shared-package | Keep primitives and composites in one shared package | rule | guidance | Does one shared package hold the registry source and the composites, with no copy in an application? |
| litespec/frontend/web/components#meet-accessibility-requirements | Meet accessibility requirements | rule | checkable | tests/routes/every-route.spec.ts presses Tab and asserts every focused element shows an indicator. |
| litespec/frontend/web/components#place-a-drawing-no-composite-makes-in-a-visual-file | Place a drawing no composite makes in a visual file | rule | guidance | Does every visual file use semantic tokens only, and does any other file write class names? |
| litespec/frontend/web/components#protect-rich-content-boundaries | Protect rich content boundaries | rule | guidance | Does any component pass untrusted content to a raw HTML sink without its recorded decision? |
| litespec/frontend/web/components#use-no-raw-element-in-page-code | Use no raw element in page code | rule | guidance | Does page code declare a refused element, and does each refusal name its composite? |
| litespec/frontend/web/data#assign-state-to-the-narrowest-owner | Assign state to the narrowest owner | rule | guidance | Does each value live with the narrowest owner, using the stack's own component state? |
| litespec/frontend/web/data#build-a-form-on-the-shared-form-library | Build a form on the shared form library | convention | guidance | Is each form built on the shared package's form entry point and field components? |
| litespec/frontend/web/data#generate-the-client-from-the-published-contract | Generate the client from the published contract | rule | checkable | pnpm api:types regenerates the client, and the contract check fails when the committed output differs. |
| litespec/frontend/web/data#keep-the-client-boundary-in-the-frame | Keep the client boundary in the frame | convention | guidance | Do the client configuration, problem mapping, and download helpers sit only in the frame root? |
| litespec/frontend/web/data#localize-copy-through-locale-dictionaries | Localize copy through locale dictionaries | rule | guidance | Does all copy resolve through the stack's dictionary library with fill, plurals, and a declared fallback? |
| litespec/frontend/web/data#map-every-failure-to-one-problem-type | Map every failure to one problem type | rule | guidance | Does every failure become one problem, with the traceId shown in the error detail? |
| litespec/frontend/web/data#place-a-refusal-beside-what-was-refused | Place a refusal beside what was refused | rule | guidance | Does each refusal render beside what was refused through the shared alert? |
| litespec/frontend/web/data#regenerate-the-client-rather-than-editing-it | Regenerate the client rather than editing it | convention | checkable | pnpm api:types regenerates the client; committed output that differs from generated output fails the contract check. |
| litespec/frontend/web/data#update-the-cache-a-command-changed | Update the cache a command changed | rule | guidance | Does each successful command invalidate the TanStack Query entries it changed and no others? |
| litespec/frontend/web/data#validate-a-form-with-the-generated-schema | Validate a form with the generated schema | rule | guidance | Does a spec submit contract-invalid input and assert a client-side refusal? |
| litespec/frontend/web/patterns#implement-a-chosen-pattern-once | Implement a chosen pattern once | rule | checkable | litespec ui reports a named React or Svelte component path that does not exist. |
| litespec/frontend/web/patterns#keep-a-visual-registry | Keep a visual registry | convention | guidance | Does the registry render every product-added option at 390 and 1280 pixels? |
| litespec/frontend/web/react/components#keep-component-boundaries-typed | Keep component boundaries typed | rule | checkable | pnpm type-check runs under strict mode and fails on an untyped prop or event. |
| litespec/frontend/web/react/components#write-components-as-functions | Write components as functions | rule | guidance | Is every component a function component using hooks? |
| litespec/frontend/web/react/stack#build-a-device-client-as-one-static-page | Build a device client as one static page | rule | guidance | Is each device client one static page with no router? |
| litespec/frontend/web/react/stack#select-a-rendering-mode-by-audience | Select a rendering mode by audience | rule | guidance | Does each frontend render in the mode its audience requires? |
| litespec/frontend/web/rendering#build-the-server-query-cache-per-request | Build the server query cache per request | rule | checkable | grep -c createQueryClient (React) or grep -c 'new QueryClient' (Svelte) counts one construction in the request factory. |
| litespec/frontend/web/rendering#define-route-metadata-deliberately | Define route metadata deliberately | rule | guidance | Does each public route state four values, and each private route refuse indexing? |
| litespec/frontend/web/rendering#keep-authenticated-caching-explicit | Keep authenticated caching explicit | rule | guidance | Does each cached actor-specific read declare its key, boundary, owner, and review? |
| litespec/frontend/web/rendering#keep-proxy-behavior-at-the-edge | Keep proxy behavior at the edge | rule | guidance | Does any proxy rule decide the actor or what the actor may read? |
| litespec/frontend/web/rendering#keep-search-parameters-validated-by-a-schema | Keep search parameters validated by a schema | rule | guidance | Does each route declare its search in a schema, with no direct reads? |
| litespec/frontend/web/rendering#load-a-route-on-intent | Load a route on intent | rule | guidance | Does the router preload the route a pointer is over, with no second cache? |
| litespec/frontend/web/rendering#load-route-data-in-the-loader | Load route data in the loader | rule | guidance | Does each route that reads declare a loader that prefetches it? |
| litespec/frontend/web/rendering#read-route-data-with-a-suspense-query | Read route data with a suspense query | rule | guidance | Does each read name the key its loader filled? |
| litespec/frontend/web/rendering#split-one-chunk-per-route-and-per-language | Split one chunk per route and per language | rule | checkable | pnpm build reports one output chunk per route and one per language. |
| litespec/frontend/web/rendering#use-a-pathless-layout-route-for-a-shell | Use a pathless layout route for a shell | convention | guidance | Does each shell sit in a shared layout? |
| litespec/frontend/web/structure#keep-a-route-file-thin | Keep a route file thin | rule | guidance | Does each route file hold only its input, its load, and its component? |
| litespec/frontend/web/structure#keep-imports-directional | Keep imports directional | rule | guidance | Does every import follow the route to module to frame to package direction? |
| litespec/frontend/web/structure#keep-tests-near-their-ownership-boundary | Keep tests near their ownership boundary | convention | guidance | Do logic tests sit beside their module and browser suites share one root? |
| litespec/frontend/web/structure#locate-the-frame-in-the-app-folder | Locate the frame in the app folder | rule | guidance | Does the frame hold every cross-route value and browser use? |
| litespec/frontend/web/structure#refuse-stack-specific-folder-names | Refuse stack-specific folder names | rule | guidance | Does any React folder take the name lib, or any Svelte folder under src/lib the name stores? |
| litespec/frontend/web/structure#use-explicit-public-entry-points-for-workspace-packages | Use explicit public entry points for workspace packages | convention | guidance | Does any application import a path its package manifest does not export? |
| litespec/frontend/web/structure#use-the-frontend-application-tree | Use the frontend application tree | rule | guidance | Does each frontend tree match the layout its stack section states? |
| litespec/frontend/web/structure#use-the-generated-route-tree | Use the generated route tree | convention | guidance | Do the build and type-check scripts each run the router's generate command? |
| litespec/frontend/web/svelte/components#keep-component-boundaries-typed | Keep component boundaries typed | rule | checkable | svelte-check runs under strict mode and fails on an untyped prop, event, or snippet. |
| litespec/frontend/web/svelte/components#write-components-in-runes-mode | Write components in runes mode | rule | checkable | svelte-check fails on a legacy reactive statement or an untyped $props call. |
| litespec/frontend/web/svelte/stack#build-a-device-client-as-one-static-page | Build a device client as one static page | rule | guidance | Is each device client one static page with no router? |
| litespec/frontend/web/svelte/stack#select-a-rendering-mode-by-audience | Select a rendering mode by audience | rule | guidance | Does each frontend render in the mode its audience requires? |
| litespec/frontend/web/testing#assert-each-declared-refusal-by-its-code | Assert each declared refusal by its code | rule | guidance | Does each web refusal assertion name its Result code in the page? |
| litespec/frontend/web/testing#keep-mocks-at-owned-boundaries | Keep mocks at owned boundaries | rule | guidance | Does each web mock avoid the libraries its stack section names? |
| litespec/frontend/web/testing#match-test-level-to-risk | Match test level to risk | rule | guidance | Does each web test use Vitest for logic and Playwright for browser behavior? |
| litespec/frontend/web/testing#prove-the-module-mirror-in-a-structure-test | Prove the module mirror in a structure test | rule | guidance | Does the Vitest structure test resolve modules and name no refused folder? |
| litespec/frontend/web/testing#query-by-accessible-behavior | Query by accessible behavior | convention | guidance | Does each web query scope by data-floorplan and accessible names? |
| litespec/frontend/web/testing#run-browser-checks-through-the-playwright-cli | Run browser checks through the Playwright CLI | rule | guidance | Does each browser check run through the Playwright CLI per route and per file? |
| litespec/frontend/web/testing#use-network-mocks-for-component-tests | Use network mocks for component tests | rule | guidance | Does each web HTTP test run through msw handlers from the contract? |
| litespec/frontend/web/ui#check-every-route-in-a-browser | Check every route in a browser | rule | checkable | tests/routes/every-route.spec.ts runs axe and the Concepts checks on each discovered route. |
| litespec/frontend/web/ui#compose-each-route-from-one-floorplan | Compose each route from one floorplan | rule | checkable | tests/routes/every-route.spec.ts asserts page.locator("[data-floorplan]") has count 1. |
| litespec/frontend/web/ui#derive-each-page-type-from-a-named-reference | Derive each page type from a named reference | rule | checkable | tests/routes/every-route.spec.ts asserts data-registry-item resolves to a published registry item on every non-freestyle route. |
| litespec/frontend/web/ui#hold-the-declared-base-color | Hold the declared base color | rule | guidance | Does the token stylesheet carry only values from the declared base color ramp, with each departure recorded? |
| litespec/frontend/web/ui#keep-layout-inside-floorplans | Keep layout inside floorplans | rule | guidance | Does any route file carry a layout utility outside its floorplan and display composites? |
| litespec/frontend/web/ui#keep-tokens-in-one-stylesheet | Keep tokens in one stylesheet | rule | checkable | litespec ui reports an application stylesheet declaring a rule and a shared stylesheet declaring a literal color. |
| litespec/frontend/web/ui#pin-the-baseline-in-the-shared-package | Pin the baseline in the shared package | rule | checkable | litespec ui compares the committed configuration against the manifest baseline fields. |
| litespec/frontend/web/ui#prove-every-result-a-route-calls | Prove every result a route calls | rule | guidance | Is every result the route calls proved by a passing test or named by a known-gap record? |
| litespec/frontend/web/ui#prove-ui-behavior-and-appearance | Prove UI behavior and appearance | rule | checkable | tests/routes/every-route.spec.ts runs on the changed route, and review confirms the change named the matrix evidence. |
| litespec/frontend/web/ui#publish-one-registry-item-per-floorplan | Publish one registry item per floorplan | rule | checkable | shadcn build (React) or shadcn-svelte build (Svelte) exits zero, and review confirms registry.json lists one item per declared floorplan. |
| litespec/frontend/web/ui#restrict-css-decisions | Restrict CSS decisions | rule | checkable | litespec ui rejects an arbitrary value, a raw palette value, or an important modifier. |
| litespec/frontend/web/ui#select-a-tone-from-the-closed-set | Select a tone from the closed set | rule | checkable | pnpm type-check fails on a state with no tone; review confirms each tone is a term. |
| litespec/frontend/web/ui#track-source-changes | Track source changes | rule | checkable | litespec ui recomputes each digest and reports changed primitive source. |
| litespec/frontend/web/ui#use-the-source-update-procedure | Use the source update procedure | convention | guidance | Does the update branch record the pinned CLI, the dry-run output, and separate review of both file sets? |
quality#
| ID | Provision | Kind | Mark | Evidence |
|---|---|---|---|---|
| litespec/quality/ci#apply-the-documented-defaults | Apply the documented defaults | convention | guidance | Does each workflow match one job, or does an Exception record the replacement? |
| litespec/quality/ci#check-documentation-on-every-pull-request | Check documentation on every pull request | rule | checkable | litespec consumer fails on a page that breaks the page contract, configuration, language, or prose rules. |
| litespec/quality/ci#enforce-the-supply-chain-gate | Enforce the supply-chain gate | rule | guidance | Does the supply-chain job scan, pin, inventory, and block a release with a high-severity advisory and no Exception? |
| litespec/quality/ci#keep-a-canonical-job-graph | Keep a canonical job graph | rule | guidance | Does consumer CI use the job names and responsibilities the jobs table states? |
| litespec/quality/ci#keep-generated-contracts-fresh | Keep generated contracts fresh | rule | guidance | Does CI regenerate the contracts from source and fail on any difference? |
| litespec/quality/ci#promote-verified-artifacts | Promote verified artifacts | rule | guidance | Does the same immutable artifact move through staging and production? |
| litespec/quality/ci#protect-the-default-branch | Protect the default branch | rule | guidance | Does the default branch require its jobs, a review, and a clean merge? |
| litespec/quality/ci#record-every-branch-protection-bypass | Record every branch protection bypass | rule | guidance | Does every bypass name its actor, reason, and admitted change? |
| litespec/quality/ci#review-schema-artifacts | Review schema artifacts | rule | guidance | Does every persistence change publish a reviewed schema artifact with its destructive operations listed? |
| litespec/quality/ci#run-applicable-gates-on-every-pull-request | Run applicable gates on every pull request | rule | guidance | Does every pull request run the jobs the jobs table selects for its changed areas? |
| litespec/quality/operations#apply-schema-changes-outside-request-startup | Apply schema changes outside request startup | rule | guidance | Does the schema step run before traffic shifts, and never at replica startup? |
| litespec/quality/operations#bound-external-calls | Bound external calls | rule | guidance | Does every network call declare a timeout, a cancellation path, and bounded idempotent retries? |
| litespec/quality/operations#cover-the-baseline-alert-set | Cover the baseline alert set | rule | guidance | Does baseline coverage include sustained readiness failures, unexpected HTTP errors, release-flow latency, PostgreSQL outages, and failed deployments? |
| litespec/quality/operations#define-actionable-baseline-alerts | Define actionable baseline alerts | rule | guidance | Does every baseline alert declare owner, threshold, window, severity, and runbook? |
| litespec/quality/operations#define-backup-and-restore-behavior | Define backup and restore behavior | rule | guidance | Does the release document owner, schedule, retention, encryption, location, command, and objectives? |
| litespec/quality/operations#emit-correlated-diagnostics | Emit correlated diagnostics | rule | guidance | Do logs and traces carry correlation identifiers, and metrics service labels? |
| litespec/quality/operations#exercise-a-restore-before-the-first-production-data | Exercise a restore before the first production data | rule | guidance | Did the project rehearse a restore on representative data before production data? |
| litespec/quality/operations#exercise-every-runbook-before-release | Exercise every runbook before release | rule | guidance | Does every required runbook carry a dated rehearsal in the operations log? |
| litespec/quality/operations#keep-deployment-descriptors-together | Keep deployment descriptors together | convention | guidance | Are the deployment descriptors under one deploy/ tree, or is an Exception recorded? |
| litespec/quality/operations#keep-production-secrets-out-of-the-repository | Keep production secrets out of the repository | rule | guidance | Are production values on the host, with only placeholders in the repository? |
| litespec/quality/operations#keep-rollback-executable | Keep rollback executable | rule | guidance | Does the rollback runbook state its reference, command, compatibility, and data condition? |
| litespec/quality/operations#keep-runbooks-near-project-documentation | Keep runbooks near project documentation | convention | guidance | Is every runbook under docs/runbooks/ with its sections, or is an Exception recorded? |
| litespec/quality/operations#list-every-sub-processor | List every sub-processor | rule | guidance | Does every provider the code calls appear as a provider Actor? |
| litespec/quality/operations#name-a-runbook-on-every-alert | Name a runbook on every alert | rule | guidance | Does every alert name the runbook that answers it? |
| litespec/quality/operations#operate-background-work-independently | Operate background work independently | rule | guidance | Does the Worker publish its own health, rates, counts, age, and shutdown behavior? |
| litespec/quality/operations#pass-trace-context-in-the-w3c-format | Pass trace context in the W3C format | rule | guidance | Does one propagator read and write W3C trace context on every host? |
| litespec/quality/operations#report-liveness-from-every-recurring-job | Report liveness from every recurring job | rule | guidance | Does every recurring job report liveness that pages a person on silence? |
| litespec/quality/operations#route-each-severity-to-a-declared-destination | Route each severity to a declared destination | rule | guidance | Does every severity state its destination and expected response time? |
| litespec/quality/operations#separate-liveness-and-readiness | Separate liveness and readiness | rule | guidance | Does liveness ignore dependencies while readiness checks the critical ones? |
| litespec/quality/operations#start-the-stack-with-one-local-command | Start the stack with one local command | rule | guidance | Does one command named in AGENTS.md start every local resource? |
| litespec/quality/operations#use-a-repeatable-deployment | Use a repeatable deployment | rule | guidance | Does every deployment use versioned artifacts, declared configuration, and a passing release job? |
| litespec/quality/operations#use-stable-service-names | Use stable service names | convention | guidance | Are service, resource, meter, and trace names identical across environments, or is an Exception recorded? |
| litespec/quality/security#apply-erasure-and-export-to-every-store | Apply erasure and export to every store | rule | guidance | Do erasure and export reach every store, with backups expiring inside their bound? |
| litespec/quality/security#authorize-each-target-resource | Authorize each target resource | rule | guidance | Does the guard authorize every protected operation from its declared permissions? |
| litespec/quality/security#bound-abuse-at-exposed-endpoints | Bound abuse at exposed endpoints | rule | guidance | Does every exposed endpoint declare its limit, and answer 429 above it? |
| litespec/quality/security#derive-the-actor-from-claims | Derive the actor from claims | rule | guidance | Does actor resolution follow the WebApi boundary rules this rule cites? |
| litespec/quality/security#keep-a-personal-data-inventory-per-store | Keep a personal-data inventory per store | rule | guidance | Does the inventory name the fields, purposes, and retention of each store? |
| litespec/quality/security#keep-backend-authentication-provider-neutral | Keep backend authentication provider-neutral | rule | guidance | Does the backend validate issuer, audience, signature, lifetime, and claims, and refuse identity headers? |
| litespec/quality/security#keep-one-limit-store-across-replicas | Keep one limit store across replicas | rule | guidance | Do all replicas read rate and concurrency counters from one store? |
| litespec/quality/security#keep-personal-data-out-of-logs | Keep personal data out of logs | rule | guidance | Is personal data absent in clear from every log, trace, and diagnostic record? |
| litespec/quality/security#keep-secrets-out-of-tracked-and-observable-data | Keep secrets out of tracked and observable data | rule | guidance | Is every secret absent from source, logs, traces, messages, files, URLs, snapshots, layers, and browser storage? |
| litespec/quality/security#keep-secure-headers-in-host-configuration | Keep secure headers in host configuration | convention | guidance | Are the secure headers defined in one host location, or is an Exception recorded? |
| litespec/quality/security#limit-public-error-detail | Limit public error detail | rule | guidance | Does every public error use the HTTP API error contract? |
| litespec/quality/security#minimize-sensitive-data | Minimize sensitive data | rule | guidance | Does every use case handle only the fields its input and results declare? |
| litespec/quality/security#parameterize-database-input | Parameterize database input | rule | guidance | Does every external value reach the database through a query API or parameter? |
| litespec/quality/security#protect-browser-boundaries | Protect browser boundaries | rule | guidance | Does every frontend apply escaping, policy, headers, redirect validation, and forgery protection? |
| litespec/quality/security#protect-live-data-at-rest | Protect live data at rest | rule | guidance | Is every live store encrypted, or covered by an Exception naming this rule? |
| litespec/quality/security#record-security-audit-events | Record security audit events | rule | guidance | Does every security audit event record actor, action, target, outcome, timestamp, trace, and reason? |
| litespec/quality/security#report-a-breach-within-its-deadline | Report a breach within its deadline | rule | guidance | Does the breach procedure name an owner, a backup person, and meet its deadline? |
| litespec/quality/security#restrict-a-protected-collection-in-the-database | Restrict a protected collection in the database | rule | guidance | Does every protected collection query apply its scope as a database predicate before paging? |
| litespec/quality/security#restrict-cross-origin-access | Restrict cross-origin access | rule | guidance | Does the cross-origin policy list origins, methods, headers, and credential mode without a wildcard origin? |
| litespec/quality/security#rotate-production-secrets | Rotate production secrets | rule | guidance | Does every production secret have a secret-inventory entry and a revocation runbook? |
| litespec/quality/security#test-the-resource-authorization-matrix | Test the resource authorization matrix | convention | guidance | Does every protected operation pass each caller case the convention lists, or is an Exception recorded? |
| litespec/quality/security#treat-an-unsalted-digest-as-personal-data | Treat an unsalted digest as personal data | rule | guidance | Does every unsalted digest of personal data receive personal-data handling? |
| litespec/quality/security#use-deny-by-default-policies | Use deny-by-default policies | convention | guidance | Is every new endpoint protected by default, or is an Exception recorded? |
| litespec/quality/security#use-one-current-actor-abstraction | Use one current actor abstraction | convention | guidance | Does WebApi expose one current-actor accessor, or does an Exception record the replacement? |
| litespec/quality/security#validate-at-trust-boundaries | Validate at trust boundaries | rule | guidance | Does every trust boundary validate its shape and metadata before use? |
workspace#
| ID | Provision | Kind | Mark | Evidence |
|---|---|---|---|---|
| litespec/workspace/config#keep-documentation-directories-out-of-build-artifact-ignore-rules | Keep documentation directories out of build-artifact ignore rules | convention | guidance | Does git check-ignore report no match for each documentation directory? |
| litespec/workspace/config#keep-environment-examples-beside-applications | Keep environment examples beside applications | convention | guidance | Does each frontend and host directory hold an environment example with safe values? |
| litespec/workspace/config#keep-local-overrides-untracked | Keep local overrides untracked | convention | guidance | Are local overrides ignored with no second tracked environment-specific source? |
| litespec/workspace/config#keep-logging-configuration-provider-neutral | Keep logging configuration provider-neutral | convention | guidance | Does application source use only logging abstractions with exporters in hosts? |
| litespec/workspace/config#keep-secrets-outside-source-control | Keep secrets outside source control | rule | guidance | Does each tracked configuration file carry only safe defaults and placeholders? |
| litespec/workspace/config#pin-the-javascript-toolchain | Pin the JavaScript toolchain | rule | guidance | Does root package.json declare the manifest pnpm release and a matching Node engine? |
| litespec/workspace/config#pin-the-react-version-in-the-eslint-flat-config | Pin the React version in the ESLint flat config | rule | guidance | Does each React flat config set a concrete settings.react.version? |
| litespec/workspace/config#use-one-frontend-dependency-graph | Use one frontend dependency graph | rule | guidance | Does the workspace use one root manifest and lockfile with no nested lockfile tracked? |
| litespec/workspace/config#validate-backend-configuration-at-startup | Validate backend configuration at startup | rule | guidance | Does each backend section bind a validated settings type that fails startup on bad values? |
| litespec/workspace/config#validate-frontend-environment-access | Validate frontend environment access | rule | guidance | Does each frontend read environment values only through its validated module with server values separated? |
| litespec/workspace/dependencies#approve-new-packages-explicitly | Approve new packages explicitly | rule | guidance | Does each package outside the manifest carry a decision with use case, alternatives, layer, cost, and removal condition? |
| litespec/workspace/dependencies#assign-each-baseline-package-to-its-owning-layer | Assign each baseline package to its owning layer | convention | guidance | Does each baseline package sit in the layer the ownership table assigns? |
| litespec/workspace/dependencies#follow-the-declared-dependency-graph | Follow the declared dependency graph | rule | guidance | Does each layer or module dependency follow the declared graph with no added edge? |
| litespec/workspace/dependencies#keep-application-free-of-provider-packages | Keep Application free of provider packages | rule | guidance | Does Application depend only on abstractions and the declared read boundary? |
| litespec/workspace/dependencies#keep-domain-dependency-free | Keep Domain dependency-free | rule | guidance | Does Domain depend on no external package or framework? |
| litespec/workspace/dependencies#keep-frontend-applications-isolated | Keep frontend applications isolated | rule | guidance | Is each frontend free of imports from another application's source or internal feature files? |
| litespec/workspace/dependencies#keep-generated-packages-dependency-light | Keep generated packages dependency-light | convention | guidance | Does the generated types package stay dependency-free with a thin client? |
| litespec/workspace/dependencies#keep-providers-in-infrastructure | Keep providers in Infrastructure | rule | guidance | Does each provider adapter live in Infrastructure apart from the read boundary? |
| litespec/workspace/dependencies#keep-test-dependencies-in-test-projects | Keep test dependencies in test projects | convention | guidance | Do production projects reference no test package? |
| litespec/workspace/dependencies#keep-the-approved-web-ui-dependency-boundary | Keep the approved web UI dependency boundary | rule | guidance | Does each React frontend take UI packages from uiBaseline and each Svelte one from uiBaselineSvelte? |
| litespec/workspace/dependencies#pin-every-dependency-version-centrally | Pin every dependency version centrally | rule | guidance | Does every version resolve through central management or the lockfile at the manifest or consumer pin? |
| litespec/workspace/naming#align-business-names-across-layers | Align business names across layers | convention | guidance | Does one business name span each module across layers and documentation? |
| litespec/workspace/naming#anchor-aggregate-owned-types-on-the-aggregate-root | Anchor aggregate-owned types on the aggregate root | rule | guidance | Does each aggregate-owned type name begin with its aggregate root name? |
| litespec/workspace/naming#avoid-generic-type-names | Avoid generic type names | convention | guidance | Does each type name avoid the generic names this rule lists when a narrower name exists? |
| litespec/workspace/naming#derive-boundary-names-from-the-ubiquitous-term | Derive boundary names from the ubiquitous term | convention | guidance | Does each route segment and field name derive from its current ubiquitous term? |
| litespec/workspace/naming#keep-namespaces-aligned-with-folders | Keep namespaces aligned with folders | convention | guidance | Does each namespace match its folder path beneath the project root? |
| litespec/workspace/naming#name-asynchronous-operations-completely | Name asynchronous operations completely | rule | guidance | Does each asynchronous operation reveal its asynchrony in its name and accept cancellation explicitly when cancelable? |
| litespec/workspace/naming#name-exceptions-by-failed-rule | Name exceptions by failed rule | rule | guidance | Does each Domain exception name lead with its root and name its reason? |
| litespec/workspace/naming#use-architectural-suffixes | Use architectural suffixes | rule | guidance | Does each architectural type carry the suffix its role requires? |
| litespec/workspace/naming#use-current-language-features | Use current language features | rule | guidance | Does production code target the pinned language version with current constructs? |
| litespec/workspace/naming#use-intent-revealing-boolean-names | Use intent-revealing boolean names | rule | guidance | Does each boolean member use an intent-revealing prefix or verb? |
| litespec/workspace/naming#use-predictable-frontend-names | Use predictable frontend names | rule | guidance | Does each frontend follow the folder, component, and hook naming form? |
| litespec/workspace/structure#declare-size-and-application-stacks-in-project-config | Declare size and application stacks in project config | rule | guidance | Does litespec.project.json declare size and one stack for the backend and each frontend? |
| litespec/workspace/structure#keep-consumer-documentation-at-the-root | Keep consumer documentation at the root | rule | guidance | Do all project records live under the root docs/ directory? |
| litespec/workspace/structure#keep-generated-api-contracts-in-packages | Keep generated API contracts in packages | convention | guidance | Do generated types and the typed client sit under packages/ with two frontends? |
| litespec/workspace/structure#keep-orientation-documents-separate-from-canonical-records | Keep orientation documents separate from canonical records | rule | guidance | Does each README under docs/ link to its record rather than restate it? |
| litespec/workspace/structure#keep-production-and-test-code-separate | Keep production and test code separate | rule | guidance | Does production code sit under src/ and test code under tests/? |
| litespec/workspace/structure#keep-runnable-applications-under-apps | Keep runnable applications under apps | rule | guidance | Does each runnable application sit under apps/ and each library under packages/? |
| litespec/workspace/structure#keep-scripts-at-the-root | Keep scripts at the root | convention | guidance | Do bootstrap, release, and CI helper scripts sit under root scripts/? |
| litespec/workspace/structure#keep-the-generated-model-out-of-source-control | Keep the generated model out of source control | rule | guidance | Is the generated .model/ folder untracked? |
| litespec/workspace/structure#limit-shared-typescript-packages | Limit shared TypeScript packages | rule | guidance | Does each shared package have two consumers or carry generated output? |
| litespec/workspace/structure#name-frontends-by-audience | Name frontends by audience | convention | guidance | Does each directory under apps/ carry an audience name? |
| litespec/workspace/structure#use-the-canonical-root-tree | Use the canonical root tree | rule | guidance | Does the workspace match the canonical tree with records at their homes? |