# Responsibility Split Recommendation (Nx Monorepo)

This document defines a clean separation of concerns for the projects in this
repo (`lilith`, `yemaya`, `aphrodite` (formerly `eve`), `nyx`, plus `bellona`,
`isis`, `sophia`, `hathor`) and how to express that separation as multiple
apps + shared libs in a single Nx workspace.

> **Note**: The Eve → Aphrodite migration was completed in January 2026. The
> domain was renamed to align with the mythological naming convention (Greek
> goddess of love and beauty).

## 1) Current State (Observed)

### Lilith

- **Shape**: Large TS monorepo with multiple clients + many backend services.
- **Clients**: `lilith/web` (Next.js PWA), `lilith/mobile` (React Native),
  `lilith/desktop` (Tauri).
- **Backend**: `lilith/services/*` (~76–83 Fastify microservices; repo docs
  mention both counts) with a `bff` aggregator and many domain services.
- **Shared packages**: `lilith/packages/*`
  (core/config/db/errors/logger/metrics/queue/testing/tracing/vectordb, etc).
- **Gen tooling**: `lilith/comfyui-nodes` and `lilith/comfyui-workflows` plus a
  `lilith/services/comfyui` service.
- **Repo/PM reality**: contains `package-lock.json` and `yarn.lock` and a large
  `node_modules/` (migration to a single workspace toolchain will require
  deliberate lockfile/package-manager consolidation).

### Yemaya

- **Shape**: pnpm+turbo TS monorepo; “capability packages” and a few primary
  apps.
- **Apps**: `yemaya/apps/api` (Hono + OpenAPI + gRPC), `yemaya/apps/web`
  (React/Vite), `yemaya/apps/desktop` (Electron), `yemaya/apps/cli`,
  `yemaya/apps/workers` (BullMQ).
- **Packages**: `yemaya/packages/*` contains many feature/capability modules
  (engine bridges, AI/agents, assets/video/audio, collaboration, cultural
  research, theory, types, ui, etc).
- **Repo/PM reality**: pnpm workspace + `pnpm-lock.yaml` and `turbo.json`.

### Eve → Aphrodite (MIGRATED)

> **Migration Status**: ✅ COMPLETE (January 2026)
>
> The original `eve/` directory has been fully migrated to the Aphrodite domain
> within the Nx monorepo structure. The `eve/` directory has been removed.

- **Current Location**: `apps/aphrodite/*` and `libs/aphrodite/*`
- **Apps**: 22 Nx applications under `apps/aphrodite/` including:
  - `apps/aphrodite/admin-web` (admin dashboard)
  - `apps/aphrodite/analytics-service` (ClickHouse analytics)
  - `apps/aphrodite/chat-service` (real-time chat with moderation)
  - `apps/aphrodite/stream-service` (live streaming with WebRTC/mediasoup)
  - `apps/aphrodite/user-service`, `apps/aphrodite/payment-service`, etc.
- **Libraries**: 73+ Nx libraries under `libs/aphrodite/` including:
  - `libs/aphrodite/common`, `libs/aphrodite/database`, `libs/aphrodite/proto`
  - `libs/aphrodite/device-*` (Lovense, OhMiBod, Buttplug, Handy, Kiiroo, TCode)
  - `libs/aphrodite/stream-*`, `libs/aphrodite/chat-*`,
    `libs/aphrodite/payment-*`
- **Key Capabilities** (unchanged):
  - Live streaming infrastructure (private shows, group shows, ticket shows,
    public shows, VR streaming)
  - Interactive adult device integrations (Lovense, OhMiBod, Buttplug, Handy,
    Kiiroo, TCode/Funscript)
  - Fan clubs and subscription tiers with perks
  - Content store (photos, videos, photo sets with licensing)
  - Token-based economy (tipping, purchases, subscriptions)
  - Adult content moderation (NSFW detection, chat filtering)
  - 18 U.S.C. 2257 compliance (age verification, record-keeping)
- **Package Manager**: pnpm (unified with Nx workspace)

### Bellona / Isis / Sophia / Hathor

- Present as active platform domains in the Nx workspace, with first-class apps
  and libraries now implemented under `apps/*` and `libs/*`.

### Repo-level constraints that affect the migration

- **Nested git repos**: both `lilith/.git` and `yemaya/.git` exist. A true Nx
  monorepo typically means **one git root**, so you’ll need to decide whether to
  absorb them into a single repo (recommended for Nx) or keep them as
  submodules/subtrees (higher friction).
- **Multi-runtime build matrix**: Next.js, Vite, Electron, Tauri, React Native,
  many Node services, and Solidity (Foundry/Hardhat). Nx can orchestrate all of
  this, but you’ll want to be explicit about what becomes a first-class Nx
  project vs a thin `run-commands` wrapper.

## 2) Guiding Principles (So the split stays clean)

1. **Products vs. Capabilities**
   - **Products** are end-user experiences (UI/UX, opinionated flows).
   - **Capabilities** are reusable systems (APIs/workers/tooling) that multiple
     products consume.
2. **Share via Contracts, not Internals**
   - Prefer **schemas + generated clients** (OpenAPI/Proto/GraphQL) over
     importing service code across domains.
3. **Stable "platform capabilities"**
   - `isis`, `sophia`, `hathor`, `bellona` should be treated as stable platform
     capability domains used by `lilith`, `yemaya`, and `aphrodite`.
4. **Composition over entanglement**
   - `lilith`, `yemaya`, and `aphrodite` should not import each other directly;
     they integrate through shared platform libs and/or capability service APIs.
5. **Domain-specific compliance**
   - `aphrodite` has unique compliance requirements (2257, adult content
     regulations) that should be isolated from other domains.

## 3) Keep the 8 Names; Clarify What Each Owns

Below is a recommended responsibility model that keeps your project names and
captures the
"movie/game/research/consciousness/generation/worldbuilding/adult-entertainment/motion"
intent with strong separation of concerns.

**Domain Summary**:

- **Yemaya** - Creative Studio (Movie/Game Production)
- **Lilith** - Consciousness Experience Platform
- **Aphrodite** (Eve) - Adult Entertainment & Live Streaming
- **Nyx** - Astronomy & Night Sky Exploration
- **Isis** - Generative Factory (AI & Asset Generation)
- **Sophia** - Research & Knowledge Substrate
- **Hathor** - Worldbuilding & Narrative Systems
- **Bellona** - Engine & Build/Bridge Capability
- **Aja** - Motion Intelligence & Animation

### Yemaya — Creative Studio (Movie/Game Production)

**Owns**: The creator-facing “studio” product experience and orchestration for
end-to-end production workflows.

In addition, Yemaya should own the **project/workspace-level asset library**:

- project organization (folders/tags/versions)
- review/approval state
- “what ships” packaging/bundling
- distribution/export tracking

Suggested Yemaya apps:

- **Studio Web**: project dashboard, timeline, editors, collaboration UI
- **Desktop Studio** (optional): local integrations, heavy workflows, file
  system access
- **API Gateway**: project/workspace APIs, auth/session, orchestration
  endpoints, plugin routing
- **Workers**: background job orchestration (rendering, exports, batch
  processing, pipelines)
- **CLI**: headless automation, CI usage, pipeline triggers

Yemaya should _consume_:

- `bellona` for engine/build integrations
- `isis` for generation workflows + asset creation
- `sophia` for research/knowledge grounding
- `hathor` for narrative/world simulation artifacts

### Bellona — Engine + Build/Bridge Capability (Game Engines + “Game Building”)

**Owns**: Integration with external engines/tools + build/export runtime
packaging.

Key boundary: separate **authoring-time design models** from **runtime
integration**.

- Authoring-time narrative/world rules and validation belong in **Hathor**.
- Runtime engine glue (adapters, import/export, packaging) belongs in
  **Bellona**.

Suggested Bellona apps/services:

- **Bridge services** (optional): websocket/IPC services that external tools
  connect to (Blender/Godot/Unreal/Unity)
- **Build worker(s)**: packaging, asset baking, validation, engine project
  generation

Suggested Bellona libs:

- Engine adapters (Godot/Unreal/Unity)
- Import/export pipelines (GLTF/USD), asset transforms, validation
- Scene/animation/material interchange models and converters

Bellona should _not_ own:

- Generative model management (Isis)
- Research ingestion/RAG (Sophia)
- Product UX (Lilith/Yemaya)

### Isis — Generative Factory (ComfyUI + AI Tools + Asset Generation)

**Owns**: Asset generation pipelines (image/video/audio/3D), workflow registry,
GPU execution, reproducibility, and provenance.

Important scope clarification:

- Isis should own **generation outputs** (immutable artifacts +
  lineage/provenance) and **workflow execution**.
- Yemaya should own the **project asset library** (the curated, editable, “this
  is in the project” view).
- Avoid making Isis “the entire asset system for everything”, or it will become
  a coupled bottleneck.

Suggested Isis apps/services:

- **Generation API**: job submission, status, outputs, metadata
- **GPU Workers**: ComfyUI execution, model runners, conversion pipelines
- **Workflow Registry**: publish/version workflows (ComfyUI graphs, templates)
- **Output Registry** (optional but recommended): canonical registry for
  “generated outputs” + provenance/lineage (not the full project asset library)

Suggested Isis libs:

- Workflow definitions + schema validation
- Prompt/template DSL, seed management
- Output manifests (files + metadata), provenance + license fields
- Connectors to local/remote model backends (ComfyUI, other tools)

Isis should integrate with:

- Yemaya asset pipeline (creator-side)
- Lilith content/media (end-user experiences)
- Sophia citations/provenance where needed (sources used for generation, if any)

### Sophia — Research + Knowledge Substrate (History/Psych/Neuro/Philo + “Exploration Tools”)

**Owns**: Ingestion, structured knowledge objects, citations, RAG/graph/vector
search, and research tooling primitives.

Important convergence decision:

- Today, Lilith already has knowledge/RAG/ingestion/vector-db shaped services.
- For the split to actually reduce complexity long-term, **Sophia should become
  the shared “knowledge plane”** and Lilith/Yemaya should consume it, rather
  than maintaining parallel stacks indefinitely.

Suggested Sophia apps/services:

- **Ingestion Service(s)**: connectors, OCR, chunking, enrichment
- **Search/RAG API**: retrieval, citations, knowledge packs
- **Knowledge Graph API** (optional): entities/relations and queries
- **Research Workbench UI** (optional): internal tooling for curation/review

Suggested Sophia libs:

- Canonical document/citation schemas
- Indexing pipelines, chunking strategies, embedding interfaces
- Evaluation harnesses for retrieval quality and citation integrity

Sophia should _not_ own:

- Story/world simulation logic (Hathor)
- Generative workflow execution (Isis)

### Hathor — Worldbuilding + Narrative Systems (Cross-cuts Movies and Games)

**Owns**: Storylines, world state models, culture/politics/economics frameworks,
quest/dialogue structures, and simulation.

Scope guardrails:

- Hathor should be **engine-agnostic** (pure domain models + rules +
  simulation), and emit artifacts that Bellona can translate into
  engine-specific formats.
- Avoid leaking engine SDK types into Hathor; keep interchange formats in
  contracts.

Suggested Hathor apps/services:

- **World Model API**: canonical world state + versioning
- **Narrative API**: story graphs, quests, dialogue trees, constraints
- **Simulation Worker(s)**: economics/politics/culture simulations, scenario
  generation
- **Worldbuilding Workbench UI** (optional): tools for designers/writers

Suggested Hathor libs:

- Domain models: factions, economies, laws, cultures, geography, timelines
- “Lore compiler”: generate engine-ready and film-ready artifacts (quests,
  script beats, scene cards)
- Validation: consistency checks (timeline, causality, taxonomy)

Hathor should integrate with:

- Sophia for grounded research facts/citations
- Isis for generating concept art, maps, portraits, audio motifs
- Bellona for emitting engine-ready world/quest content

### Lilith — Consciousness Experience Product (“Vast & Fun Exploration Platform”)

**Owns**: The end-user consciousness exploration product: metaverse,
teachers/mentors, meditation experiences, community, safety, personalization.

Potential boundary conflict to decide explicitly:

- Lilith includes rights/licensing/creator-economy adjacent services today.
- Yemaya also has marketplace-oriented packages (asset/plugin marketplace).
- Recommendation: treat **creator economy/licensing/marketplace** as a
  creator-platform concern (Yemaya-leaning) and have Lilith integrate, rather
  than duplicating marketplace logic in both products.

Suggested Lilith apps:

- **Lilith Web** (PWA) + **Mobile** + **Desktop** (as needed)
- **Lilith BFF** (or API gateway) for client-specific aggregation
- **Core experience services** (existing): auth, content, conversation, media,
  moderation, notification, rag/knowledge, realtime/voice, etc.

Lilith should _consume_:

- Sophia for knowledge/research content and citation pipelines
- Isis for generation pipelines (art assets, audio, video, etc.)
- Hathor for story/world systems used inside "consciousness worlds"
- Bellona if/when Lilith experiences are embedded in engines or exported worlds

### Eve → Aphrodite — Adult Entertainment & Creator Economy Platform (Live Streaming + Fan Engagement)

**Domain Rename**: Eve will be integrated into Oshun as the **Aphrodite**
domain. Library prefix: `@aphrodite/*`. This aligns with the mythological naming
convention used across Oshun domains.

**Owns**: The end-user adult entertainment product: live streaming
infrastructure, interactive device integrations, fan clubs, content stores, age
verification/compliance, and adult-specific moderation.

Eve/Aphrodite represents a distinct product domain focused on adult content
creators and their audiences, with specialized compliance and safety
requirements.

#### Metaverse & SOTA Enhancement Opportunities

Eve/Aphrodite can leverage other Oshun domains to achieve industry-leading
features:

- **Aja Integration (Motion & Animation)**:
  - Real-time motion capture for VTuber/avatar streaming via webcam
  - Pre-made animation libraries for broadcaster avatars
  - Motion-to-haptic translation for device synchronization
  - 3D avatar rendering with VRM and Ready Player Me support

- **Isis Integration (AI & Generation)**:
  - AI-powered chat moderation and content analysis
  - Automated thumbnail generation and content tagging
  - AI chatbot assistants for broadcasters (AFK engagement)
  - Real-time stream upscaling and enhancement

- **Sophia Integration (Knowledge & Recommendations)**:
  - Personalized viewer recommendations
  - Predictive analytics for optimal streaming times
  - Content discovery and similar broadcaster suggestions

- **Metaverse Virtual Environment Features**:
  - 3D virtual room system with WebGL rendering
  - Spatial audio with HRTF support
  - Interactive objects with tip-triggered effects
  - Viewer presence and avatar system in virtual spaces

Suggested Aphrodite apps:

- **aphrodite-viewer** (React SPA): viewer experience, content browsing, virtual
  room viewing
- **aphrodite-broadcaster** (React SPA): creator dashboards, stream controls,
  avatar customization
- **aphrodite-admin**: moderation queue, 2257 compliance management, content
  review
- **aphrodite-streaming**: WebRTC/mediasoup live streaming, private/group/ticket
  shows, VR streaming
- **aphrodite-chat**: real-time chat with moderation, DMs, room management
- **aphrodite-analytics**: ClickHouse-backed creator dashboards, revenue
  tracking, viewer analytics
- **aphrodite-notifications**: push notifications, email alerts, stream
  reminders
- **aphrodite-payment**: token economy, tipping, subscriptions, creator payouts
- **aphrodite-devices**: interactive toy integrations, haptic pattern management
- **aphrodite-vr**: VR streaming, head tracking, spatial experiences

Suggested Aphrodite-specific capabilities:

- **Live streaming infrastructure**:
  - Private shows (1:1 creator-viewer)
  - Group shows (cost-sharing among viewers)
  - Ticket shows (scheduled events with advance sales)
  - Public shows (free/tipped streams)
  - VR capture and playback (180°/360°)
  - Low-latency HLS/WebRTC delivery
  - Adaptive bitrate streaming
  - Multi-camera support with dynamic switching
- **Interactive device integrations**:
  - Lovense, OhMiBod, Buttplug, Handy, Kiiroo adapters
  - TCode/Funscript pattern support
  - Tip-triggered vibration patterns
  - Real-time device synchronization
  - Audio-reactive haptics
  - Motion-linked haptics (via Aja integration)
  - Bidirectional haptic interaction
- **Fan engagement systems**:
  - Fan clubs with subscription tiers and perks
  - Content store (photos, videos, bundles)
  - Tipping with custom amounts and messages
  - Gamification (achievements, leaderboards, loyalty programs)
  - Virtual gifts with 3D animations
- **Metaverse features** (SOTA enhancements):
  - 3D virtual rooms with customizable environments
  - Broadcaster 3D avatars with motion capture
  - Viewer presence and avatars in virtual spaces
  - Spatial audio with distance attenuation
  - Interactive objects with tip-triggered effects
  - VIP areas and exclusive virtual spaces
- **AI-powered features** (via Isis integration):
  - AI chat moderation and content analysis
  - Smart thumbnail generation
  - Broadcaster AI assistant for AFK engagement
  - Personalized recommendations
  - Real-time stream enhancement/upscaling
- **Compliance & safety**:
  - 18 U.S.C. 2257 compliance (age verification, record-keeping, custodian
    designation)
  - NSFW content classification (ML-based image/video analysis)
  - Real-time chat moderation (profanity, harassment, spam detection)
  - Age gate and geo-blocking
  - GDPR/CCPA data rights handling
  - DRM and content protection (Widevine, FairPlay, PlayReady)
  - Forensic watermarking

Key Aphrodite entities owned:

- Users (creators and viewers), Creator profiles, Verification records
- Streams, Shows (private/group/ticket), Recordings
- Content items, Photo sets, Licenses
- Subscriptions, Subscription tiers, Perks
- Transactions, Tips, Token balances, Payouts
- Chat rooms, Messages, Moderation logs
- Device connections, Vibration patterns, Haptic presets
- Virtual rooms, Room templates, Room props
- Avatars, Avatar customizations, Animations
- Virtual gifts, Gift animations

Suggested Aphrodite libraries:

- `@aphrodite/streaming-core`: WebRTC utilities, media pipeline, bitrate
  adaptation
- `@aphrodite/device-protocols`: Lovense, Buttplug, Handy, Kiiroo integrations
- `@aphrodite/payments`: CCBill, Epoch, SegPay, crypto payment integrations
- `@aphrodite/chat-core`: Real-time messaging, room management, tipping
- `@aphrodite/vr-core`: VR streaming protocols, head tracking, spatial
  experiences
- `@aphrodite/gamification`: Achievements, leaderboards, loyalty programs
- `@aphrodite/avatar-motion`: Motion capture integration, avatar animation (uses
  Aja)
- `@aphrodite/avatar-renderer`: 3D avatar rendering, VRM support, customization
- `@aphrodite/virtual-rooms`: 3D room rendering, interactive objects, spatial
  audio
- `@aphrodite/haptics`: Haptic pattern designer, audio-reactive, motion-linked
- `@aphrodite/analytics`: Viewer analytics, revenue reporting, performance
  metrics

Aphrodite should _consume_:

- Shared foundation libs (`@oshun/*`) for logging, metrics, tracing, config,
  etc.
- **Aja** for motion capture, avatar animation, and motion-to-haptic translation
- **Isis** for AI-powered content moderation, thumbnail generation, chat
  assistance
- **Sophia** for recommendation engine, knowledge-based features, predictive
  analytics

Aphrodite should _not_ directly import from:

- Lilith, Yemaya (these are separate product domains)
- Hathor (not directly relevant to Aphrodite's use cases)
- Bellona (not directly relevant to Aphrodite's use cases)

### Aphrodite Data Ownership

Aphrodite is the authoritative source for all adult entertainment platform data:

#### User & Identity Data

| Entity                  | Owner     | Description                                |
| ----------------------- | --------- | ------------------------------------------ |
| User accounts           | Aphrodite | Creator and viewer accounts                |
| Creator profiles        | Aphrodite | Public profiles, bios, avatars, banners    |
| Verification records    | Aphrodite | 2257 compliance, age verification, ID docs |
| Social graph            | Aphrodite | Follows, subscribers, blocked users        |
| Fan clubs               | Aphrodite | Subscription tiers, perks, member lists    |
| User preferences        | Aphrodite | Notification settings, privacy settings    |
| Authentication sessions | Aphrodite | JWT tokens, refresh tokens, 2FA state      |

#### Streaming & Media Data

| Entity              | Owner     | Description                                |
| ------------------- | --------- | ------------------------------------------ |
| Live streams        | Aphrodite | Stream sessions, metadata, status          |
| Stream recordings   | Aphrodite | VOD files, chapters, thumbnails            |
| Private shows       | Aphrodite | 1-on-1 session records, pricing            |
| Group shows         | Aphrodite | Multi-viewer session records, ticket lists |
| Ticket shows        | Aphrodite | Scheduled shows, ticket sales, attendees   |
| Media files         | Aphrodite | Photos, videos, audio (stored in S3)       |
| Photo sets          | Aphrodite | Bundled media collections                  |
| Content store items | Aphrodite | PPV content, pricing, access records       |
| Stream quality      | Aphrodite | Bitrate settings, transcoding profiles     |

#### Financial Data

| Entity            | Owner     | Description                                 |
| ----------------- | --------- | ------------------------------------------- |
| Token balances    | Aphrodite | User token holdings                         |
| Token purchases   | Aphrodite | Token package transactions                  |
| Tips              | Aphrodite | Tip transactions, messages, device triggers |
| Subscriptions     | Aphrodite | Active subscriptions, renewal history       |
| Content purchases | Aphrodite | PPV access grants, purchase records         |
| Creator earnings  | Aphrodite | Accumulated earnings, pending balance       |
| Payouts           | Aphrodite | Payout requests, bank details, history      |
| Tax documents     | Aphrodite | W-9/W-8BEN forms, 1099-K records            |

#### Interactive & Engagement Data

| Entity             | Owner     | Description                                 |
| ------------------ | --------- | ------------------------------------------- |
| Chat messages      | Aphrodite | Room messages, DMs, moderation flags        |
| Chat rooms         | Aphrodite | Room state, participant lists               |
| Device connections | Aphrodite | Connected devices, patterns, activation log |
| Tip goals          | Aphrodite | Goal definitions, progress, contributors    |
| Polls              | Aphrodite | Poll questions, votes, results              |
| Tip menus          | Aphrodite | Menu items, device actions, pricing         |
| Tip leaderboards   | Aphrodite | Rankings, aggregate tip totals              |
| Achievements       | Aphrodite | Unlocked achievements, progress             |

#### Analytics Data

| Entity              | Owner     | Description                           |
| ------------------- | --------- | ------------------------------------- |
| Stream analytics    | Aphrodite | Viewer counts, peaks, watch time      |
| Creator dashboards  | Aphrodite | Earnings reports, viewer demographics |
| Viewer analytics    | Aphrodite | Watch history, preferences, activity  |
| Content performance | Aphrodite | Views, purchases, conversion rates    |
| Real-time metrics   | Aphrodite | Live stream stats, chat activity      |

#### Moderation Data

| Entity             | Owner     | Description                       |
| ------------------ | --------- | --------------------------------- |
| Moderation queue   | Aphrodite | Flagged content pending review    |
| Moderation actions | Aphrodite | Bans, timeouts, warnings, appeals |
| Content reports    | Aphrodite | User-submitted reports            |
| AI moderation logs | Aphrodite | Automated detection results       |
| Chat filter rules  | Aphrodite | Blocked words, spam patterns      |
| Moderator roles    | Aphrodite | Channel moderator assignments     |

### Aphrodite API Contracts

Aphrodite exposes the following API contracts for internal and external
consumption:

#### REST APIs (Internal)

| Service                | Port | Purpose                               |
| ---------------------- | ---- | ------------------------------------- |
| User Service           | 3000 | Auth, profiles, social, subscriptions |
| Payment Service        | 4000 | Tokens, tips, earnings, payouts       |
| Chat Service           | 5000 | Room management, DMs (HTTP endpoints) |
| Analytics Service      | 7000 | Event ingestion, creator dashboard    |
| Content Service        | 7001 | Media upload, content store, VOD      |
| Moderation Service     | 7002 | Content moderation, reports, appeals  |
| Notification Service   | 7003 | Notification delivery, preferences    |
| Recommendation Service | 7004 | Personalized feeds, discovery, search |

#### WebSocket APIs (Real-time)

| Namespace        | Purpose                                 |
| ---------------- | --------------------------------------- |
| `/chat`          | Real-time messaging, typing, reactions  |
| `/stream`        | Stream events, goals, device activation |
| `/notifications` | Push notifications, unread counts       |

#### gRPC APIs (Service-to-Service)

| Service        | Port  | Purpose                                    |
| -------------- | ----- | ------------------------------------------ |
| Stream Service | 50051 | Stream lifecycle, signaling, media routing |

#### Event Contracts (Kafka/Redis)

Aphrodite publishes the following domain events:

| Event                         | Description                    |
| ----------------------------- | ------------------------------ |
| `aphrodite.user.registered`   | New user registration          |
| `aphrodite.user.verified`     | Creator verification completed |
| `aphrodite.stream.started`    | Live stream began              |
| `aphrodite.stream.ended`      | Live stream concluded          |
| `aphrodite.tip.received`      | Tip transaction completed      |
| `aphrodite.subscription.new`  | New subscription created       |
| `aphrodite.content.published` | New content published          |
| `aphrodite.content.purchased` | Content purchase completed     |
| `aphrodite.goal.completed`    | Tip goal reached               |
| `aphrodite.device.activated`  | Interactive device triggered   |
| `aphrodite.moderation.action` | Moderation action taken        |
| `aphrodite.payout.completed`  | Payout transferred             |

### Aphrodite Integration Points

#### Aja Integration (Motion & Animation)

| Feature             | Aja Provides                | Aphrodite Consumes              |
| ------------------- | --------------------------- | ------------------------------- |
| Motion capture      | Webcam-to-skeleton pipeline | Real-time avatar animation      |
| Avatar animation    | Animation blending, IK      | VTuber-style streaming          |
| Motion-to-haptic    | Motion intensity extraction | Device activation from movement |
| Pre-made animations | Animation library           | Emotes, reactions, gestures     |

**Integration Pattern**: Aphrodite calls Aja's motion capture API for real-time
webcam processing and receives skeleton data for avatar animation.

#### Isis Integration (AI & Generation)

| Feature              | Isis Provides              | Aphrodite Consumes               |
| -------------------- | -------------------------- | -------------------------------- |
| Content moderation   | NSFW classification models | Real-time content scanning       |
| Thumbnail generation | Image processing pipeline  | Auto-generated stream thumbnails |
| AI chat assistant    | LLM-based conversation     | Broadcaster AFK engagement bot   |
| Stream enhancement   | Real-time upscaling        | Improved stream quality          |
| Content tagging      | Multi-label classification | Automatic content categorization |

**Integration Pattern**: Aphrodite sends content/streams to Isis moderation APIs
and receives classification results. AI assistants are deployed as
Aphrodite-specific Isis workflows.

#### Sophia Integration (Knowledge & Recommendations)

| Feature              | Sophia Provides            | Aphrodite Consumes                 |
| -------------------- | -------------------------- | ---------------------------------- |
| Recommendations      | Collaborative filtering    | Personalized creator suggestions   |
| Trending analysis    | Trend detection algorithms | Trending creators/content feeds    |
| Viewer clustering    | User segmentation          | Targeted promotions                |
| Predictive analytics | Time series forecasting    | Optimal streaming time suggestions |

**Integration Pattern**: Aphrodite sends user interaction events to Sophia and
queries recommendation APIs for personalized feeds.

#### Shared Foundation (Oshun)

| Feature            | Oshun Provides                 | Aphrodite Consumes        |
| ------------------ | ------------------------------ | ------------------------- |
| Logging            | Structured logging             | Service logging           |
| Metrics            | Metrics collection             | Performance monitoring    |
| Tracing            | Distributed tracing            | Request tracing           |
| Configuration      | Config management              | Environment configuration |
| Database utilities | Connection pooling, migrations | Database access           |
| Cache utilities    | Redis abstractions             | Session caching           |
| Queue utilities    | Job queue interfaces           | Background job processing |

### Aphrodite Library Inventory

Based on the implemented domain, these are the Aphrodite-specific libraries:

#### Core Libraries

| Library                      | Purpose                                    |
| ---------------------------- | ------------------------------------------ |
| `@aphrodite/core`            | Types, validation, utilities, constants    |
| `@aphrodite/database`        | Database schemas, migrations, repositories |
| `@aphrodite/cache`           | Redis caching layer                        |
| `@aphrodite/storage`         | S3-compatible file storage                 |
| `@aphrodite/event-publisher` | Kafka/Redis event publishing               |

#### Streaming Libraries

| Library                      | Purpose                             |
| ---------------------------- | ----------------------------------- |
| `@aphrodite/streaming-core`  | WebRTC, MediaSoup, HLS streaming    |
| `@aphrodite/vr-core`         | VR streaming, stereoscopic formats  |
| `@aphrodite/cloud-recording` | Stream recording and VOD generation |
| `@aphrodite/video-effects`   | Real-time video filters and effects |

#### Device Libraries

| Library                       | Purpose                            |
| ----------------------------- | ---------------------------------- |
| `@aphrodite/device-protocols` | Device protocol abstractions       |
| `@aphrodite/buttplug`         | Buttplug.io integration            |
| `@aphrodite/haptics`          | Haptic pattern design and playback |

#### Payment Libraries

| Library                      | Purpose                              |
| ---------------------------- | ------------------------------------ |
| `@aphrodite/payments`        | Payment processing, token management |
| `@aphrodite/crypto-payments` | Cryptocurrency payment support       |

#### Chat & Social Libraries

| Library                      | Purpose                            |
| ---------------------------- | ---------------------------------- |
| `@aphrodite/chat-core`       | Real-time messaging infrastructure |
| `@aphrodite/chat-moderation` | Chat filtering and moderation      |

#### Compliance Libraries

| Library                       | Purpose                       |
| ----------------------------- | ----------------------------- |
| `@aphrodite/age-verification` | Age verification workflows    |
| `@aphrodite/compliance-2257`  | 18 U.S.C. 2257 record-keeping |
| `@aphrodite/gdpr-compliance`  | GDPR data rights handling     |

#### Analytics Libraries

| Library                      | Purpose                               |
| ---------------------------- | ------------------------------------- |
| `@aphrodite/analytics`       | Event tracking, dashboards, reporting |
| `@aphrodite/recommendations` | Recommendation engine (uses Sophia)   |
| `@aphrodite/gamification`    | Achievements, leaderboards, loyalty   |

### Boundary clarification: Product Domains

| Concern             | Aphrodite                              | Lilith                           | Yemaya                         | Nyx                             |
| ------------------- | -------------------------------------- | -------------------------------- | ------------------------------ | ------------------------------- |
| Primary audience    | Adult content consumers/creators       | Consciousness/meditation seekers | Creative professionals         | Astronomy enthusiasts/educators |
| Content type        | Adult live streams, photos, videos, VR | Meditations, spiritual content   | Movies, games, creative assets | Star maps, ephemeris, catalogs  |
| Compliance focus    | 2257, adult content regulations        | General safety, wellness         | Copyright, licensing           | Scientific accuracy, citations  |
| Monetization        | Tips, subscriptions, pay-per-view      | Subscriptions, courses           | Asset sales, project fees      | Subscriptions, API access tiers |
| Device integrations | Adult toys (Lovense, etc.), haptics    | Biometrics, wearables            | Game engines, DAWs             | Telescopes, planetarium domes   |
| Metaverse features  | Virtual rooms, 3D avatars, spatial     | Consciousness worlds             | Creative environments          | VR planetarium, AR starfinding  |

### Nyx — Astronomy & Night Sky Exploration Platform

**Owns**: The astronomy and night sky exploration product experience:
planetarium, star map, satellite tracking, astronomical event predictions,
telescope control, and educational astronomy content.

Nyx is an educational and observational astronomy platform providing accurate
ephemeris calculations, real-time satellite tracking, and immersive night sky
visualization across web, mobile, VR, and planetarium dome displays.

#### Implementation Status

> **Status**: ✅ PHASE 21 COMPLETE AND VERIFIED (May 2026)
>
> Nyx has been implemented with 73 library projects and 22 application/tool
> projects under the `@nyx/*` namespace in the Nx monorepo.

**Current Structure:**

- **Applications and tools** (`apps/nyx/`):
  - `apps/nyx/star-map` - Interactive WebGL star map (React/Three.js)
  - `apps/nyx/api` - REST/WebSocket API (Hono framework)
  - `apps/nyx/ar-sky` - AR sky-identification application
  - `apps/nyx/mobile` - Offline-capable mobile PWA
  - `apps/nyx/vr-planetarium` - WebXR planetarium experience
  - `apps/nyx/pipelines` - Data pipeline workers
  - `apps/nyx/education/*` - Courses, demonstrations, and challenge apps
  - `apps/nyx/tools/*` - Observation, astrophotography, light-curve, and orbit
    determination tools

- **Libraries** (`libs/nyx/`): 73 libraries organized into domains:
  - **Core**: `@nyx/constants`, `@nyx/types`, `@nyx/utils`
  - **Time & Coordinates**: `@nyx/time`, `@nyx/time-travel`, `@nyx/coordinates`,
    `@nyx/positional`
  - **Celestial Mechanics**: `@nyx/orbital`, `@nyx/ephemeris`, `@nyx/events`
  - **Catalogs**: `@nyx/catalogs/*` for Gaia, Hipparcos, Tycho, SIMBAD, NGC/IC,
    NASA exoplanets, solar-system bodies, deep-sky objects, exotic objects,
    spacecraft, supernovae, and unified star queries
  - **Real-time**: `@nyx/realtime/*` for satellites, solar activity, NEOs, and
    event alerts
  - **Visualization**: `@nyx/renderer/*`, `@nyx/visualization/*`,
    `@nyx/analysis/*`, and embeddable widgets
  - **Education and experience**: `@nyx/education/*`, `@nyx/mythology`,
    `@nyx/constellations`, `@nyx/lilith-integration`, `@nyx/audio/*`
  - **Integrations**: Stellarium, telescope control, and planetarium bridges
  - **Database**: `@nyx/database` (PostgreSQL schemas and repositories)

#### Core Capabilities

- **Astronomical Calculations**:
  - High-precision ephemeris generation (VSOP87, ELP2000/82 theory)
  - Coordinate transformations (ICRS, GCRS, ITRS, topocentric, horizontal)
  - Time systems (UTC, TT, TAI, UT1, TDB, Julian dates)
  - Precession, nutation, aberration, light-time corrections
  - Rise/set/transit time calculations with atmospheric refraction

- **Satellite Tracking**:
  - TLE parsing and validation (NORAD two-line elements)
  - SGP4/SDP4 orbit propagation
  - Real-time position updates via WebSocket
  - Celestrak and Space-Track data integration
  - Satellite pass prediction with visibility windows

- **Celestial Catalogs**:
  - Messier (110 deep-sky objects)
  - NGC/IC (13,000+ objects)
  - Hipparcos (118,000 stars)
  - Gaia DR3 (subset for magnitude-limited queries)
  - NASA Exoplanet Archive integration
  - Minor Planet Center integration (asteroids, comets)

- **Event Predictions**:
  - Solar and lunar eclipses (Besselian elements)
  - Planetary conjunctions and oppositions
  - Meteor showers with radiant/ZHR data
  - Satellite visible passes
  - Occultations and transits

- **Visualization**:
  - WebGL star rendering with magnitude-based sizing
  - Constellation lines and boundaries
  - Milky Way rendering
  - Atmospheric effects (twilight, light pollution)
  - Multiple projection modes (stereographic, orthographic, Hammer-Aitoff)

- **Hardware Integration**:
  - ASCOM/Alpaca telescope control
  - INDI server support
  - Planetarium dome projection
  - GoTo mount control
  - Camera control for astrophotography

#### Deployment Infrastructure

- **Kubernetes Deployment** (`infra/nyx/`):
  - Base manifests with Kustomize overlays (dev/staging/prod)
  - API deployment with HPA scaling
  - Star map static serving via nginx
  - WebSocket support for real-time updates

- **CDN Configuration** (`infra/nyx/cdn/`):
  - AWS CloudFront distribution
  - Tiered caching (immutable textures: 1 year, catalogs: 7 days, dynamic: 1
    hour)
  - S3 bucket for static astronomical assets

- **Data Pipelines** (`infra/nyx/pipelines/`):
  - TLE updater (hourly from Celestrak/Space-Track)
  - Catalog syncer (weekly from VizieR/SIMBAD/NASA)
  - Ephemeris generator (daily precomputation)
  - Event calculator (weekly predictions)

Implemented Nyx apps and tools:

- **nyx-star-map** (React/WebGL): Interactive star map with search, time
  control, educational overlays, satellite tracking, and astronomy tools.
- **nyx-api**: REST and WebSocket API for ephemeris, events, satellites, and
  object search.
- **nyx-ar-sky**: AR sky map with camera, orientation, labels, grids, and
  observation assistance.
- **nyx-mobile**: Offline-capable mobile PWA for stargazing, event widgets, and
  sky-pointing workflows.
- **nyx-vr-planetarium**: WebXR planetarium with immersive tours and VR
  interaction.
- **nyx-pipelines**: Data pipeline workers for TLE, catalog, ephemeris, and
  event refreshes.
- **nyx-education** and **nyx-tools**: Course, demonstration, challenge,
  observation-planning, astrophotography, light-curve, and orbit-determination
  projects.

Suggested Nyx libraries:

- `@nyx/ephemeris`: Ephemeris generation with configurable precision
- `@nyx/coordinates`: Coordinate system transformations (ICRS, GCRS, horizontal)
- `@nyx/time`: Time systems (UTC, TT, TDB, Julian dates)
- `@nyx/celestial-mechanics`: Orbital mechanics and perturbation theory
- `@nyx/realtime`: Real-time satellite tracking (TLE, SGP4)
- `@nyx/catalogs`: Star and deep-sky object catalogs
- `@nyx/events`: Astronomical event prediction (eclipses, conjunctions)
- `@nyx/star-renderer`: WebGL star field rendering
- `@nyx/telescope-control`: ASCOM/INDI telescope integration
- `@nyx/database`: PostgreSQL schemas for astronomical data

Nyx should _consume_:

- **Shared foundation** (`@oshun/*`) for logging, metrics, tracing, config
- **Sophia** for educational content citations and research grounding
- **Isis** for AI-powered object identification and image enhancement

Nyx should _not_ directly import from:

- Lilith, Yemaya, Aphrodite (separate product domains)
- Hathor, Bellona (not directly relevant to astronomy)

### Nyx Data Ownership

Nyx is the authoritative source for all astronomy platform data:

#### Astronomical Data

| Entity             | Owner | Description                                 |
| ------------------ | ----- | ------------------------------------------- |
| Star catalogs      | Nyx   | Hipparcos, Gaia, Tycho, Bright Star Catalog |
| Deep-sky objects   | Nyx   | Messier, NGC, IC, PGC catalogs              |
| Satellite TLEs     | Nyx   | NORAD two-line elements, orbital parameters |
| Ephemeris data     | Nyx   | Precomputed planetary positions             |
| Event predictions  | Nyx   | Eclipses, conjunctions, meteor showers      |
| Exoplanet data     | Nyx   | NASA Exoplanet Archive integration          |
| Minor bodies       | Nyx   | Asteroids, comets from Minor Planet Center  |
| Constellation data | Nyx   | Boundaries, lines, mythology, star names    |

#### User Data

| Entity             | Owner | Description                              |
| ------------------ | ----- | ---------------------------------------- |
| Saved observations | Nyx   | User-logged observations with timestamps |
| Custom objects     | Nyx   | User-defined celestial objects           |
| Observation lists  | Nyx   | User-curated target lists                |
| Equipment profiles | Nyx   | Telescope/camera configurations          |
| Location presets   | Nyx   | Observer location bookmarks              |

### Nyx API Contracts

#### REST APIs

| Endpoint          | Method | Purpose                                         |
| ----------------- | ------ | ----------------------------------------------- |
| `/api/objects`    | GET    | Query celestial objects by type, position, name |
| `/api/ephemeris`  | GET    | Generate ephemeris tables for objects           |
| `/api/satellites` | GET    | List satellites, predict passes                 |
| `/api/events`     | GET    | Upcoming astronomical events                    |
| `/api/search`     | GET    | Cross-catalog search by name or designation     |

#### WebSocket Channels

| Channel          | Purpose                              |
| ---------------- | ------------------------------------ |
| `/ws/satellites` | Real-time satellite position updates |
| `/ws/time`       | Synchronized time broadcast          |
| `/ws/events`     | Live event notifications             |

#### Event Contracts

Nyx publishes the following domain events:

| Event                         | Description                        |
| ----------------------------- | ---------------------------------- |
| `nyx.satellite.pass.upcoming` | Satellite pass alert for observer  |
| `nyx.event.eclipse.upcoming`  | Eclipse event reminder             |
| `nyx.event.conjunction`       | Planetary conjunction notification |
| `nyx.catalog.updated`         | Catalog data refresh completed     |
| `nyx.tle.updated`             | TLE data refresh completed         |

### Autonomous AAA Creation Architecture (How "Yemaya builds AAA games/movies" survives the split)

The key idea is: **one autonomy control plane** (Yemaya) orchestrates multiple
**execution planes** (Bellona/Isis/Sophia/Hathor). This preserves “one vast
autonomous system” without turning any single codebase into an unmaintainable
god-object.

**Yemaya = autonomy + project control plane**

- **Director/Planner**: decomposes a high-level goal (“make a AAA RPG +
  trailer”) into a task graph and artifact graph.
- **Policy/Budget**: cost/latency constraints, model/tool routing policy, safety
  constraints, “needs human approval” rules.
- **Project truth**: the canonical project/workspace state and the curated
  project asset library (what exists, versions, review state, what ships).
- **Orchestration**: dispatches jobs to execution planes, listens to completion
  events, retries/fallbacks, and assembles deliverables.
- **Review UX**: human-in-the-loop checkpoints (approve a script, lock a style
  pack, sign off on an export).

**Execution planes (capability domains)**

- **Sophia (research)**: ingestion + retrieval + citations + knowledge packs;
  returns grounded briefs, citations, and structured research artifacts.
- **Hathor (world/story)**: story graphs, quests/dialogue, world state +
  simulation; outputs engine-agnostic narrative/world artifacts (with
  validation).
- **Isis (generation)**: workflow registry + GPU execution; outputs immutable
  generated artifacts (images/video/audio/3D) with provenance/lineage.
- **Bellona (engine/build)**: converts Hathor/Isis artifacts into engine-native
  projects/assets, runs builds/tests, packages exports, and reports results.

**How this is implemented cleanly**

- **Contracts-first**: the handoffs are schema-defined
  (Project/Asset/Workflow/WorldModel/Research/Citation + event contracts).
- **Clients + events, not imports**: Yemaya calls capability APIs via generated
  clients and reacts to completion events; it does not import their internals.
- **Clear data ownership**:
  - Yemaya owns project state + “asset library” (curated/project-facing).
  - Isis owns generation outputs + provenance (factory-facing).
  - Sophia owns research indices + citation truth.
  - Hathor owns world/story truth + simulation state.
  - Bellona owns build outputs + build metadata.

### Integration placement examples (ElevenLabs, Civitai, Ardour)

Use these concrete integrations as “boundary tests” to keep the split
consistent:

- **ElevenLabs integration**: belongs in **Isis** as a provider adapter
  (voice/TTS generation execution). Lilith/Yemaya call it via an Isis
  API/client; any product-specific UX orchestration (e.g., realtime voice UX)
  stays in the product, but the vendor adapter stays in Isis.
- **Civitai integration**: belongs in **Isis** as a model registry/marketplace
  connector (model discovery/metadata, versioning, license capture,
  download/cache, safety gates). Yemaya can present a “model marketplace” UI by
  calling Isis; Lilith generally consumes “installed model/workflow IDs” and
  generated outputs rather than talking to Civitai directly.
- **Ardour integration**: belongs in **Bellona** as deep external tool/DAW
  integration (session control, routing, templates, export, and automation
  scripts). Yemaya orchestrates “mix/export” tasks; Isis can generate inputs
  (music/SFX/voice); Bellona drives Ardour to assemble/process/export
  deliverables.

## 4) Nx Workspace Model (Apps vs Libs)

### High-level Nx layout

Recommended top-level structure:

- `apps/` = deployables (UIs, APIs, workers, CLIs, microservices)
- `libs/` = reusable code (types/contracts/clients/ui primitives/infra helpers)
- `tools/` = generators, code mods, repo tooling

### What counts as an “app”

- Any independently deployable runtime:
  - Web apps, desktop apps, mobile apps
  - API servers/BFFs
  - Workers/job processors
  - CLIs
  - Lilith microservices (each service can be an Nx project)

Operational note:

- With dozens of services, you’ll want generators and conventions so “add a
  service” isn’t a copy/paste config exercise.
- For unusual runtimes (React Native, Tauri, Foundry), consider treating them as
  **thin Nx projects** that run existing scripts (Nx orchestrates; native
  toolchains still do the heavy lifting).

### What counts as a “lib”

- Anything reused across multiple apps without owning runtime deployment:
  - `types`, schema contracts, shared SDKs/clients
  - common infra helpers (logging/tracing/config/auth primitives)
  - domain models (world model schemas, asset manifests)
  - UI component libraries

## 5) Recommended Nx Project/Module Naming

Keep the deity names as _scopes_ (domains), and use consistent prefixes:

- Apps: `lilith-web`, `lilith-bff`, `lilith-svc-auth`, `yemaya-api`,
  `aphrodite-streaming`, `aphrodite-chat`, `nyx-star-map`, `nyx-api`,
  `nyx-planetarium`, `isis-worker-gpu`, `hathor-svc-world`, etc.
- Libs: prefer minimal renames early. Keep existing product scopes (`@lilith/*`,
  `@yemaya/*`, `@aphrodite/*`, `@nyx/*`) for product-internal code and introduce
  `@oshun/*` primarily for shared foundation + cross-domain contracts/clients:
  - `@oshun/contracts`, `@oshun/foundation-logging`, `@oshun/isis-workflows`,
    `@oshun/sophia-citations`, `@oshun/hathor-world-model`, etc.
  - `@aphrodite/streaming-core`, `@aphrodite/chat-core`,
    `@aphrodite/gamification`, `@aphrodite/device-protocols` for
    Aphrodite-specific libraries.
  - `@nyx/ephemeris`, `@nyx/coordinates`, `@nyx/catalogs`, `@nyx/realtime` for
    Nyx-specific libraries.

## 6) Dependency Boundaries (Enforced by Nx Tags)

Use Nx tags to prevent accidental coupling.

Suggested tags:

- `scope:lilith | scope:yemaya | scope:aphrodite | scope:nyx | scope:bellona | scope:isis | scope:sophia | scope:hathor | scope:aja | scope:shared`
- `type:app | type:lib`
- `layer:ui | layer:domain | layer:data | layer:infra | layer:contracts`

Simple boundary rules:

- `layer:ui` can depend on `layer:domain`, `layer:contracts`, `layer:infra` (not
  the other way around).
- `scope:lilith`, `scope:yemaya`, `scope:aphrodite`, and `scope:nyx` may depend
  on `scope:isis|sophia|hathor|bellona|aja|shared` but **not on each other**.
- `scope:aphrodite` is a product domain like `scope:lilith`, `scope:yemaya`, and
  `scope:nyx`; it should not be imported by other product scopes.
- `scope:nyx` is a product domain focused on astronomy; it may depend on
  `scope:sophia` (research/citations) and `scope:isis` (AI image processing).
- `scope:aphrodite` may additionally depend on `scope:aja` for motion/animation
  features.
- `scope:hathor` may depend on `scope:sophia` (grounding), and optionally
  `scope:isis` (generation helpers), but avoid depending on product scopes.
- `scope:isis` should not depend on `scope:lilith`, `scope:yemaya`,
  `scope:aphrodite`, or `scope:nyx` (keep it capability-grade).

Hardening rules (to prevent slow “monorepo coupling creep”):

- `scope:shared` must stay **small** and **infra-only** (no product logic, no
  capability-specific domain logic).
- Cross-scope _code_ reuse should be limited to:
  - `layer:contracts` (schemas, event envelopes, interchange models)
  - `layer:clients` (generated clients/SDKs)
  - `scope:shared` + `layer:infra` (logging/tracing/config/http helpers)
- Everything else across scopes should integrate via **HTTP/gRPC/events**, not
  imports.

Data ownership rule:

- A scope that owns data stores the data and serves it through APIs/events;
  other scopes do **not** read its database directly.

## 7) Shared Code Strategy (What Goes Where)

### A) Shared “Foundation” (low-level, safe to share)

Create a small set of shared libs that standardize runtime behavior:

- logging, tracing, metrics
- config/env validation
- auth primitives (JWT verification helpers, session interfaces)
- http/grpc client helpers, retries, circuit breaking
- queue interfaces + job envelope types
- storage interfaces (S3/MinIO abstraction), file manifests

### B) Shared “Contracts” (the most important shared layer)

Make contracts the canonical cross-domain handshake:

- `Asset` + provenance + licensing
- `Workflow` + inputs/outputs + versioning
- `ResearchDocument` + `Citation` + `Claim` structures
- `WorldModel` + story/quest/dialogue graph schemas
- `Project`/`Workspace` models (Yemaya-centric)

Prefer:

- OpenAPI/Proto/Zod schemas in `libs/*/contracts`
- generated clients in `libs/*/clients`

Avoid:

- importing service internals across domains

### C) Shared “Capability SDKs”

Where it helps developer experience, publish SDKs:

- `@oshun/isis-client` (submit generation jobs, fetch outputs)
- `@oshun/sophia-client` (search, retrieve citations, ingest docs)
- `@oshun/hathor-client` (get world state, generate quests, validate lore)
- `@oshun/bellona-client` (trigger builds, exports, engine sync)

### D) Shared “Event Contracts” (recommended)

Define canonical events as part of `layer:contracts`, e.g.:

- `isis.assetGenerated` / `isis.jobFailed`
- `sophia.documentIngested` / `sophia.indexUpdated`
- `hathor.worldPublished` / `hathor.simulationCompleted`
- `bellona.buildCompleted` / `bellona.exportReady`

This gives you clean async integration between studio (Yemaya) and experience
(Lilith) without direct coupling.

### E) Versioning and releases (must be decided up front)

- Your workspace currently uses different release conventions (Yemaya uses
  changesets; Lilith does not).
- Pick one approach for the unified Nx workspace and enforce it:
  - one “contracts first” release flow so consumers can pin/upgrade safely
  - consistent codegen (OpenAPI/Proto) and CI checks that prevent breaking
    contract changes

## 8) How Existing Lilith and Yemaya Map into This

### Lilith mapping

- `lilith/web`, `lilith/mobile`, `lilith/desktop` become Nx apps.
- Each `lilith/services/<name>` becomes an Nx app (or grouped apps where it
  makes sense operationally).
- `lilith/packages/*` mostly becomes Nx libs under `shared/foundation` (or stays
  as-is initially, but registered as Nx projects).
- `lilith/comfyui-*` content should move under `isis` ownership over time
  (workflows/nodes are Isis assets; Lilith consumes them).
- Knowledge/RAG ingestion: converge toward Sophia as the shared knowledge plane
  (avoid maintaining parallel knowledge stacks long-term).

### Yemaya mapping

- `yemaya/apps/*` become Nx apps.
- `yemaya/packages/*` become Nx libs, reorganized by scope (some stay
  `scope:yemaya`, some are better as `scope:bellona` / `scope:isis` /
  `scope:sophia` / `scope:hathor` if they are capability-grade).
- Specifically, packages like `quest-dialogue`, `theory`, `cultural-research`
  often belong in the Sophia/Hathor orbit (depending on whether they are
  "research substrate" vs "narrative/world systems").

### Eve → Aphrodite mapping (COMPLETED)

> **Migration Status**: ✅ COMPLETE (January 2026)
>
> The Eve to Aphrodite migration has been completed. The domain was renamed from
> "Eve" to "Aphrodite" during migration to better align with the mythological
> naming convention (Greek goddess of love and beauty).

**Final Structure (as implemented):**

- `eve/apps/*` migrated to `apps/aphrodite/*`:
  - `eve/apps/admin` → `apps/aphrodite/admin-web`
  - `eve/apps/analytics-service` → `apps/aphrodite/analytics-service`
  - `eve/apps/chat-service` → `apps/aphrodite/chat-service`
  - `eve/apps/stream-service` → `apps/aphrodite/stream-service`
  - Additional services → `apps/aphrodite/*` (22 total applications)
- `eve/packages/*` migrated to `libs/aphrodite/*`:
  - `eve/packages/common` → `libs/aphrodite/common`
  - `eve/packages/database` → `libs/aphrodite/database`
  - `eve/packages/gamification` → `libs/aphrodite/gamification`
  - `eve/packages/api-middleware` → `libs/aphrodite/api-middleware`
  - `eve/packages/proto` → `libs/aphrodite/proto`
  - 73+ total libraries under `libs/aphrodite/*`
- `eve/services/shared` utilities migrated to:
  - `libs/aphrodite/service-lib` (Aphrodite-specific)
  - `libs/shared/*` (reusable utilities promoted to shared)
- Aphrodite-specific compliance code (2257, adult content moderation) remains
  isolated under `scope:aphrodite`.
- Package manager: Unified to pnpm with the Nx workspace.
- Original `eve/` directory: **Deleted** after migration completion.

### Nyx mapping (IMPLEMENTED)

> **Status**: ✅ PHASE 21 COMPLETE AND VERIFIED (May 2026)
>
> Nyx has been implemented directly in the Nx monorepo structure with 73 library
> projects and 22 application/tool projects.

**Current Structure (as implemented):**

- `apps/nyx/*` (22 application/tool projects):
  - `apps/nyx/star-map` - Interactive WebGL star map (React/Three.js)
  - `apps/nyx/api` - REST/WebSocket API (Hono framework)
  - `apps/nyx/ar-sky` - AR sky-identification app
  - `apps/nyx/mobile` - Offline-capable mobile PWA
  - `apps/nyx/vr-planetarium` - WebXR planetarium experience
  - `apps/nyx/pipelines` - Data pipeline workers
  - `apps/nyx/education/*` - Course, demonstration, and challenge apps
  - `apps/nyx/tools/*` - Scientific planning and analysis tools

- `libs/nyx/*` (73 libraries across domains):
  - Core: `@nyx/constants`, `@nyx/types`, `@nyx/utils`
  - Time and coordinates: `@nyx/time`, `@nyx/time-travel`, `@nyx/coordinates`,
    `@nyx/positional`
  - Mechanics and ephemeris: `@nyx/orbital`, `@nyx/ephemeris`, `@nyx/events`
  - Catalogs: `@nyx/catalogs/*` (messier, ngc, hipparcos, gaia, exoplanets,
    etc.)
  - Real-time: `@nyx/realtime/*` (satellites, solar activity, NEOs, alerts)
  - Visualization: `@nyx/renderer/*`, `@nyx/visualization/*`, `@nyx/widgets/*`
  - Education and lore: `@nyx/education/*`, `@nyx/mythology`,
    `@nyx/constellations`
  - Integrations: `@nyx/integrations/*`, `@nyx/client`, `@nyx/client-python`
  - Database: `@nyx/database` (PostgreSQL schemas)

- Deployment infrastructure:
  - `infra/nyx/base/` - Kubernetes base manifests
  - `infra/nyx/overlays/` - Environment-specific overlays (dev/staging/prod)
  - `infra/nyx/cdn/` - AWS CloudFront CDN configuration
  - `infra/nyx/pipelines/` - Data pipeline CronJob manifests

- Package manager: Unified to pnpm with the Nx workspace.
- Nyx-specific astronomical data and algorithms isolated under `scope:nyx`.

## 9) "Things You Haven't Considered" (Usually the Real Coupling Sources)

1. **Identity & Permissions**
   - Decide whether you want a single identity provider across all 8 domains
     (recommended) or per-product auth.
   - Aphrodite has unique requirements: age verification, creator verification
     (2257), and adult content access controls.
2. **Asset provenance + licensing**
   - If Isis generates assets, the provenance record becomes a cross-cutting
     "truth" used by Yemaya, Lilith, and potentially Aphrodite.
3. **Versioned artifacts**
   - World models (Hathor), workflows (Isis), and research packs (Sophia) need
     strict versioning and reproducible builds.
4. **Runtime environments**
   - GPU workers (Isis) and engine build workers (Bellona) have very different
     infra requirements than web APIs.
   - Aphrodite has specialized infra needs: media servers (mediasoup/WebRTC),
     low-latency streaming, VR capture/playback.
5. **Evaluation and safety**
   - Lilith has heavy safety/moderation needs; Sophia also needs citation
     integrity and "groundedness" evaluation.
   - Aphrodite has the most stringent content moderation requirements: NSFW
     classification, real-time chat filtering, 2257 compliance.
6. **Plugin architecture**
   - Yemaya will likely need a plugin system; keep plugin contracts in shared
     libs and plugin implementations in scoped packages.
7. **Data ownership and eventing**
   - Without clear "who owns what data" and an event contract, teams tend to
     read each other's DBs or share internal libs, which collapses boundaries.
8. **Naming and scope drift**
   - Decide early whether you will introduce `@oshun/*` only for
     shared/capabilities and keep `@lilith/*` / `@yemaya/*` / `@aphrodite/*` /
     `@nyx/*` for product code to avoid mass renames.
9. **Regulatory isolation**
   - Aphrodite operates in a heavily regulated space (adult content); its
     compliance code, record-keeping, and moderation systems should be isolated
     to prevent coupling with other domains.
   - Consider whether Aphrodite shares auth with other domains or has a
     completely separate identity system due to compliance requirements.
10. **Device integration abstraction**
    - Aphrodite has extensive interactive device integrations (Lovense, OhMiBod,
      etc.); these should be abstracted behind a clean interface in case other
      domains (e.g., Lilith biometrics) want similar patterns.
11. **Streaming infrastructure reuse**
    - Aphrodite's streaming infrastructure (WebRTC, mediasoup, HLS) may be
      reusable for Lilith (real-time meditation sessions) or Yemaya (live
      collaboration). Consider whether to make this a shared capability or keep
      it Aphrodite-specific.
12. **Astronomical data accuracy and citations**
    - Nyx requires high scientific accuracy with proper citations to
      authoritative sources (JPL DE440/441, IAU SOFA, IERS standards).
    - Consider how Sophia's citation infrastructure can support Nyx's need for
      research-grade references.
13. **External data pipeline dependencies**
    - Nyx depends on external data sources (Celestrak, Space-Track, NASA
      Exoplanet Archive, SIMBAD) that have rate limits and update schedules.
    - Implement robust caching and fallback mechanisms for external API
      failures.
14. **Hardware integration patterns**
    - Nyx's telescope/dome control patterns (ASCOM/INDI) may inform patterns for
      other domains' hardware integrations (Lilith biometrics, Aphrodite
      devices).
    - Consider whether hardware abstraction layers should be shared.

## 10) Migration Options (Practical Path)

### Option B: "Full restructure into apps/libs" (clean end state, more work)

> **Eve → Aphrodite Migration Status**: ✅ COMPLETE (January 2026)
>
> The Eve migration has been completed following this path. Eve was renamed to
> Aphrodite during the migration. The steps below reflect the completed state.

1. ✅ **Single-repo strategy decided**:
   - Nested repos absorbed into one git root (Nx monorepo).
   - Eve (now Aphrodite) was a top-level directory; integrated directly.
2. ✅ **Package manager consolidated**:
   - Unified on pnpm at the workspace root.
   - Eve's npm + turbo migrated to pnpm + Nx.
3. ✅ **Nx project boundaries established**:
   - All projects tagged (`scope:*`, `layer:*`, `type:*`).
   - Aphrodite uses `scope:aphrodite` tag; isolation enforced.
4. ✅ **Deployables moved to `apps/`**:
   - Grouped by scope: `apps/aphrodite/*` (22 applications).
   - Includes: `apps/aphrodite/admin-web`, `apps/aphrodite/stream-service`,
     `apps/aphrodite/chat-service`, `apps/aphrodite/analytics-service`, etc.
5. ✅ **Reusable code moved to `libs/`**:
   - Foundation in `libs/shared/*`.
   - Aphrodite libraries in `libs/aphrodite/*` (73+ libraries).
   - Includes: `libs/aphrodite/database`, `libs/aphrodite/gamification`,
     `libs/aphrodite/common`, `libs/aphrodite/streaming`,
     `libs/aphrodite/compliance`.
6. **Replace cross-imports with contracts + clients** (ongoing):
   - define contract packages first (schemas, events)
   - generate clients (OpenAPI/Proto) and migrate callers to the clients
7. **Converge overlapping stacks** (ongoing):
   - pick a target "knowledge plane" (Sophia) and migrate Lilith/Yemaya toward
     it
   - move ComfyUI workflows/nodes under Isis ownership; consume from products
     via APIs/clients
   - evaluate whether Aphrodite's streaming infrastructure should become a
     shared capability or remain Aphrodite-specific
8. **Standardize release/versioning** (ongoing):
   - choose a unified release mechanism (Nx release and/or changesets) and apply
     it consistently to shared contracts + capability SDKs
9. ✅ **Aphrodite-specific concerns handled**:
   - 2257 compliance code isolated in `libs/aphrodite/compliance`
   - Adult content moderation models in `scope:aphrodite`
   - Aphrodite's unique data retention requirements documented (7-year 2257
     records)

## 11) Concrete Next Decisions (Checklist)

> **Note**: Several items below have been completed as part of the Eve →
> Aphrodite migration (January 2026).

- ✅ Choose git/repo strategy: absorbed nested repos into one git root.
- ✅ Choose package manager: pnpm unified across the Nx workspace.
- Decide if auth/identity is shared across all domains (recommended, but
  Aphrodite may need isolated age/identity verification).
- Decide "source of truth" for:
  - assets/provenance (Isis)
  - project asset library and review state (Yemaya)
  - research/citations (Sophia)
  - world model/story graphs (Hathor)
  - ✅ live streams, content store, subscriptions (Aphrodite)
  - ✅ 2257 compliance records (Aphrodite)
- Decide eventing strategy (which events are first-class contracts).
- Define API boundaries + codegen approach (OpenAPI/Proto first).
- Decide Aphrodite's relationship to shared infrastructure:
  - Does Aphrodite share auth with Lilith/Yemaya, or maintain separate identity
    for compliance reasons?
  - Is Aphrodite's streaming infrastructure shared as a capability, or kept
    Aphrodite-specific?
  - How do Aphrodite's gamification/loyalty systems relate to potential Lilith
    gamification?
- ✅ Compliance isolation strategy decided:
  - All 2257-related code in `scope:aphrodite`.
  - Adult content moderation ML models isolated from other domains.
  - Data retention requirements documented (7-year 2257 records).