Dependencies

The declared graph is the list of crossings review checks. An undeclared edge lets a layer reach past its boundary, and review finds no graph that forbids it. Each new edge then needs an explicit decision instead of arriving silently with an import.

Reviewed forEach layer and module dependency follows the declared graph; read the references between layer folders under apps/api/src and the imports in apps/.

Marked guidance: a reviewer answers this question.

Domain holds business rules, and business rules outlive frameworks. Depending on no external package or framework keeps the rules testable and portable on their own. Persistence, messaging, web, injection, serialization, and logging libraries all stay outside.

Reviewed forNo Domain layer folder needs an external package or framework; read the Domain layer folders and the manifests that serve them.

Marked guidance: a reviewer answers this question.

Application coordinates use cases through abstractions; Infrastructure hides the technology behind them. A provider package in Application makes the coordination layer depend on the technology Infrastructure was meant to hide, so a provider change reaches two layers. Only messaging abstractions, required read abstractions, and the one declared read boundary stay.

Reviewed forThe Application layer folders reference only messaging abstractions, read abstractions, and the declared read boundary; read those folders and the manifests that serve them.

Marked guidance: a reviewer answers this question.

A database provider, an external SDK, and resilience, discovery, and serialization adapters all change with their technology. Keeping them in Infrastructure keeps each provider change inside one layer, apart from the read boundary the ownership table assigns to Application.

Reviewed forDatabase providers, external SDKs, and resilience, discovery, and serialization adapters appear only in the Infrastructure layer folders; read those folders and the manifests that serve them.

Marked guidance: a reviewer answers this question.

An inline version in one module file is invisible to the manifest that is supposed to own it, so two modules drift to two versions of the same package. Central management or the committed lockfile resolves every version in one owned place: the manifest pins the baseline stack the standards name, and the consumer's own central file or lockfile pins the product's own packages. The manifest belongs to the LiteSpec release rather than to the consumer, so a consumer's pins live beside its code, admitted by litespec/workspace/dependencies#approve-new-packages-explicitly.

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

Reviewed forEvery version resolves through central management or the committed lockfile at the manifest pin where one exists; no version sits inline in a module file.

Marked guidance: a reviewer answers this question.

A package arrives with a cost nobody revisits: updates, advisories, license review, and migration work, and a hosted one adds a place personal data may travel and an account someone must own. The decision answers those while the alternatives are still fresh: its options and choice give the use case and the alternatives, its reopenedWhen gives the removal condition, and its admits entry gives the facts a dependency gate asks per package. 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.

Claimwick's decision/0005-render-receipts-as-pdf chooses a PDF library over an HTML-to-PDF browser and admits nuget:PdfSharp with layer Infrastructure, license MIT, location in-process, account owner none, failure behavior "the receipt download fails and the expense stays readable", and operating cost none.

Checked bylitespec model check reports dependency-undeclared (level S) for a direct package in the bill of materials that the manifest does not pin and no decision admits, and admission-invalid (level G) for an admits entry missing any of its six facts.

Marked checkable: the tool named here checks it.

When one frontend imports another's source, neither can change its internals without checking the other, so the two release as one. A frontend also stays out of another module's internal feature files for the same reason. Sharing goes through a shared package with a documented public entry point that depends on no application.

Reviewed forNo import in one frontend names another application's source or another module's internal feature files.

Marked guidance: a reviewer answers this question.

A fixed UI baseline keeps every screen drawing from the same design system, styling, base components, icons, and utilities. Taking UI packages only from uiBaseline for React and uiBaselineSvelte for Svelte keeps that set reviewed and versioned in one place. Each baseline pins the design system, styling, base components, icons, and the utility packages the installed source imports directly.

Reviewed forEach React frontend manifest takes UI packages only from uiBaseline, and each Svelte one only from uiBaselineSvelte, in litespec.manifest.json.

Marked guidance: a reviewer answers this question.