Dependencies

Requirement A dependency between layers or modules MUST follow the declared graph and add no other edge.

Rationale An undeclared edge lets a layer reach past its boundary, and review cannot refuse what no graph forbids.

Requirement The Domain layer MUST depend on no external package or framework.

Rationale Persistence, messaging, web, injection, serialization, and logging libraries all stay outside.

Requirement Application MUST depend only on messaging abstractions, required read abstractions, and the one declared read boundary.

Rationale A provider package in Application makes the coordination layer depend on the technology Infrastructure was meant to hide. The Requirement names the one read boundary this allows.

Requirement A database provider, external SDK, resilience, discovery, or serialization adapter MUST live in Infrastructure.

Rationale Infrastructure is the only layer that a provider change may reach, except the read boundary the ownership table assigns to Application.

Requirement Every dependency version MUST resolve through central management or the committed lockfile, at the pin litespec.manifest.json states where it states one.

Rationale An inline version in one module file is invisible to the manifest that is supposed to own it. The manifest pins the baseline stack, which is the set these standards name. A consumer also carries packages for its own product, and it cannot add those to a manifest it does not own. Those versions live in the consumer's own central file or its lockfile, and litespec/workspace/dependencies#approve-new-packages-explicitly is what admits them.

Example A consumer generating invoices pins its PDF library in its central version file with a decision record. The manifest never names it, and the pin is still central.

Requirement A package absent from the manifest MUST have a decision naming its use case, alternatives, owning layer, operating cost, and removal condition.

Rationale A package arrives with a cost nobody revisits, so the decision names the removal condition while the alternatives are still fresh. A baseline package lands in the manifest in the same change as its decision. A consumer-owned package lands in the consumer's central file instead, because the manifest belongs to the LiteSpec release rather than to the consumer.

Requirement A frontend MUST NOT import another application's source or another module's internal feature files.

Rationale A shared package exposes a documented public entry point and depends on no application.

Requirement A React web frontend MUST take its UI packages from the uiBaseline in litespec.manifest.json, and a Svelte web frontend from uiBaselineSvelte.

Rationale Each baseline pins its design system, styling, base components, icons, and the utility packages the installed source imports directly.