# Lilith Dependency Analysis

> A generated dependency-hygiene report for the Lilith domain: it walks every
> Lilith service and shared package and checks the internal import graph for
> **cycles**. A green result ("No circular dependencies found" everywhere) is
> the evidence that Lilith's layering is clean — each service and package can be
> built, tested, and reasoned about in isolation.

## What this report is, and why it matters

Lilith is the contemplative-platform backend: a set of independently deployable
services (`auth`, `bff`, `content`, `conversation`, `media`, `notification`,
`moderation`, `ai`) sitting on top of a layer of shared packages (`cache`,
`config`, `core`, `database`, `errors`, `fastify-core`, `logger`, `metrics`,
`queue`, `testing`, `tracing`, `vectordb`). For that layering to hold, the
dependency edges between these units must form a **directed acyclic graph** —
services may depend on packages, packages may depend on lower packages, but
nothing may depend back on something that (transitively) depends on it.

A circular dependency is more than a style problem. It means two units cannot be
compiled, versioned, or tested separately; a change to one forces a rebuild of
the other; and the "who owns this" boundary the domain model promises has
quietly leaked. The check below exists to catch that the moment it appears,
across the whole Lilith surface at once.

## How to read it

The report is organized in two passes — the deployable **services** first, then
the shared **packages** — and lists each unit with its verdict:

- **`No circular dependencies found`** — the import graph rooted at this unit
  has no back-edges. This is the expected, healthy state and the result
  currently recorded for every Lilith service and package below.
- A reported cycle (none present here) would name the chain of modules that
  close the loop, which is the exact set an author must break — typically by
  lifting the shared type into a lower package, inverting the dependency with an
  interface, or moving the offending code to the layer that legitimately owns
  it.

## How it is produced and kept honest

This is a **generated artifact**, not hand-maintained prose — the timestamp
below records when it was last produced from the live Lilith workspace. It is
the domain-scoped companion to the repo-wide module-boundary lint (the Nx
`scope:`/`layer:` tag rules) and to the sibling
[Yemaya dependency analysis](./yemaya-dependency-analysis.md): the lint blocks a
bad edge at PR time, while these inventories give a flat, auditable snapshot of
the whole graph's health for review. Regenerate it whenever Lilith's service or
package set changes, and the green verdict should hold.

---

## Generated report

Generated: Sat Jan 10 16:09:24 UTC 2026

### Circular Dependency Check

#### Service: auth

No circular dependencies found

#### Service: bff

No circular dependencies found

#### Service: content

No circular dependencies found

#### Service: conversation

No circular dependencies found

#### Service: media

No circular dependencies found

#### Service: notification

No circular dependencies found

#### Service: moderation

No circular dependencies found

#### Service: ai

No circular dependencies found

### Package Dependencies

#### Package: cache

No circular dependencies found

#### Package: config

No circular dependencies found

#### Package: core

No circular dependencies found

#### Package: database

No circular dependencies found

#### Package: errors

No circular dependencies found

#### Package: fastify-core

No circular dependencies found

#### Package: logger

No circular dependencies found

#### Package: metrics

No circular dependencies found

#### Package: queue

No circular dependencies found

#### Package: testing

No circular dependencies found

#### Package: tracing

No circular dependencies found

#### Package: vectordb

No circular dependencies found