Oshun V1 — Dependency Registry

Scope: Dependencies that the Oshun V1 launch relies on — third-party APIs, SDKs, infrastructure services, language runtimes, and internal packages that sit on the V1 critical path. Out-of-scope domains (Yemaya, Maya, Iris coding assistant, Maat, Cybele, Saraswati, Brigid, etc.) are cataloged in the whole-monorepo /DEPENDENCIES.md. Companion docs: V1/features.md, V1/TODOS.md, V1/ARCHITECTURE.md. Date: 2026-05-11

Purpose#

This file is the V1-scoped dependency contract. For each dependency it answers three questions a reviewer needs before launch:

1. What is it — one sentence on the dependency itself.
2. Where does V1 use it — the V1 features or TODOS sections that need it.
3. How is it wired — env vars, package paths, ports, version source.

Pinned versions live in pnpm-workspace.yaml (TypeScript), each service's pyproject.toml (Python), and docker/docker-compose.dev.yml plus the per-domain compose files (containers). This document references those sources of truth rather than duplicating them.

Table of Contents#

1. Internal Packages — Foundations
2. Internal Packages — V1 Domains and Substrates
3. Application Runtimes
4. Backend Frameworks
5. Frontend Stack
6. Mobile Stack
7. Data Stores
8. AI / ML Providers
9. Generation Providers (Isis)
10. Inbound Integrations
11. Outbound Messaging Channels
12. Identity, Auth, and Provisioning
13. Payment and Billing
14. Observability and Telemetry
15. Object Storage and CDN
16. Search and Vector Stores
17. Concept and Knowledge Graph
18. Domain-Specific External APIs
19. Provenance and Synthetic-Content Verification
20. Cloud Providers
21. Containerization and Local Development
22. CI/CD and Build Tooling
23. Testing Tooling
24. Security and Secrets

1. Internal Packages — Foundations#

Foundational packages that every V1 surface depends on.

Not on the V1 critical path but used by Isis post-processing (image/video generation): @oshun/color-science (libs/oshun/color-science/) provides color-science foundations for OSHUN imaging workflows. V1 consumes it transitively through the Isis generation pipelines rather than from any customer/admin surface.

2. Internal Packages — V1 Domains and Substrates#

Customer-facing domains#

Platform substrates#

Cross-domain support#

Shared shell#

3. Application Runtimes#

4. Backend Frameworks#

5. Frontend Stack#

Design system grounding: cream-paper + terracotta canonical, with the Lilith register variants applied at the persona-policy boundary (@oshun/persona-policy-lilith). Routes referenced in V1 features include /, /landing, /tara…/nisaba, /operator/*, /system.

Lighthouse budgets live at apps/oshun/web/lighthouse-budget.json (LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1).

Hosting: all Next.js front-ends (apps/oshun/{web,admin,tenant-admin,telegram-miniapp}, apps/metis/{web,admin}) run as containers on the single Hetzner box (SSR standalone + static, both via docker/Dockerfile.web) behind the Caddy TLS edge, host-routed on <prefix>.<platform_domain> — the same single hosting plane as every backend service. Defined by deploy/v1/hetzner/docker-compose.yml and released by .github/workflows/deploy-hetzner.yml. History: Vercel → Amplify → Fargate (2026-07-04 single-plane consolidation, V1/planning/IAC_CICD_AUDIT_2026-07-04.md) → Hetzner single box (2026-07-09, V1/planning/HETZNER_SINGLE_BOX_2026-07-09.md).

6. Mobile Stack#

Admin mobile (apps/oshun/admin-mobile) shares the same Expo/RN baseline.

Launch-readiness gap: V1 features.md calls for push routing (domain/persona/quiet-hours/sensitivity), audio playback for Tara meditations and Living Scenes narration, offline media caching, and camera/microphone capture. The mobile package.json does not yet pin expo-notifications, expo-av, expo-image, expo-camera, or expo-file-system. Either these must be added before launch or the supporting Expo plugins / native modules must be declared in the prebuild config.

7. Data Stores#

Profiles documented in CLAUDE.md § "Local Development".

8. AI / ML Providers#

All provider calls flow through:

• Isis control plane for generation jobs and provenance bundles.
• Lilith persona policy for tone/crisis/audacity gating.
• Iris memory for consent scoping and admin inspection trails.

9. Generation Providers (Isis)#

V1 generation surfaces fan out behind @oshun/generation-control-isis. Raw provider access is operator-only (TODOS § 24, features.md § Generation Audience Tiers).

Every generation produces a ProvenanceBundle (consent ID, prompt, model, watermark hash, timestamp, invoking user, tenant) recorded against the audit platform and used by takedown cascades.

10. Inbound Integrations#

All inbound integrations are implemented by @oshun/inbound-integrations (libs/shared/inbound-integrations/src/). Each module exposes a connector framework with health probes, circuit breakers, version pinning, and upgrade pathways (TODOS § 1.10).

LMS / Standards#

Calendars#

BYOM (bring-your-own-model)#

Payments and Notifications#

Documented in §13 Payment and §11 Outbound Messaging.

11. Outbound Messaging Channels#

Boundary, residency, retention, consent, and audit are enforced uniformly through @oshun/audit-platform and Iris consent records.

12. Identity, Auth, and Provisioning#

13. Payment and Billing#

V1 settlement is non-custodial crypto-first. The primary rail uses self-hosted nodes, watch-only or view-only wallets on the application server, and an air-gapped signing station for refunds and sweeps. Fiat (Stripe-class) is V1.x optional and slots into the same entitlement, receipt, and dunning machinery.

V1 primary — non-custodial crypto (Aje libs/aje/ + V1 bridge)#

V1 settlement consumes the Aje domain (Yoruba orisha of wealth and commerce) — the monorepo's existing library-only blockchain and Web3 infrastructure. Aje contributes the chain modules, wallet management, merchant payments, stablecoins, oracles, and nodes. V1 adds five new chain modules to Aje (Monero, Litecoin, TON, Ergo, Tron) plus a thin bridge library (libs/oshun/payments-bridge/) that maps Aje's invoice contracts onto the V1 entitlement event bus. The combined rail covers the top-10 payment cryptos by real-world volume plus Cardano and Ergo. Per-chain decentralization tier (A / B / C) and per-asset issuer-trust class are documented in features.md § Crypto Payments — Non-Custodial Entitlement Settlement and enforced at the invoice-disclosure layer.

Aje library packages consumed by V1#

V1 contribution to Aje: five new chain modules#

Each follows Aje's existing @aje/chains/<chain>/ module pattern and preserves the "TypeScript throughout" design principle by isolating non-TS cryptography to upstream node processes (the TypeScript module owns only the JSON-RPC client; the wallet daemon is a separate process; spend keys live on the air-gapped signing station behind @aje/wallets/hardware-wallet).

Tier A — credibly decentralized, self-hosted full node mandatory#

Tier B — decentralized with documented caveats; self-hosted where practical + multi-RPC consensus#

Tier C — centralized trust required; accepted with explicit invoice disclosure#

Stablecoin accept-list (per chain)#

Cross-cutting tooling#

Aje libraries run inside libs/aje/ and the V1 bridge runs inside libs/oshun/payments-bridge/. The bridge emits entitlement-grant and refund events through libs/shared/event-bus topics shared with the fiat adapter, keeping downstream consumers rail-agnostic.

V1.x optional — fiat rails#

Billing-action reversal, entitlement suspension, trial-expiry behavior, payment-method update reminders (fiat), and renewal-invoice reminders (crypto) are all documented in features.md § Support, Entitlements, Billing and § Crypto Payments — Non-Custodial Entitlement Settlement, and tracked in TODOS § 23 and § 23.1. Aje's own feature catalog lives in DOMAINS/aje/features.md and architecture in DOMAINS/aje/architecture.md.

14. Observability and Telemetry#

Per-channel SLA monitor (libs/shared/queue/src/sla-monitor.ts) feeds the launch-readiness dashboards.

15. Object Storage and CDN#

16. Search and Vector Stores#

17. Concept and Knowledge Graph#

18. Domain-Specific External APIs#

Nyx — sky predictions#

All sources are declared in the PredictionSourceRef contract so customers inspecting a sky event see exactly which external authority predicted it. No NYX-specific HTTP base URLs are pinned in .env.example yet; pre-launch work should add NYX_*_URL entries alongside the per-source API keys.

Nisaba — scholarly sources#

Veritas — source quality and counterclaim feeds#

External feeds are operator-curated (peer-reviewed databases, retraction watch sources, fact-check syndications). Veritas requires a SourceKind declaration on every source and a per-source reviewer attestation.

19. Provenance and Synthetic-Content Verification#

20. Cloud Providers#

(Production deployment; dev runs entirely in compose.)

21. Containerization and Local Development#

Per CLAUDE.md § "Local Development":

docker compose -f docker/docker-compose.dev.yml up -d
docker compose -f docker/docker-compose.dev.yml ps
pnpm install

Core services (always on): postgres (pgvector/pgvector:pg16, port 5432), pgbouncer, redis (6379), minio (9000/9001), mailpit (1025/8025). Optional profiles:

Per-domain compose files exist for brigid, cybele, freya, iris, lakshmi, maat, saraswati (out-of-V1 domains; runnable independently).

V1 domain databases pinned in .env.example today: TARA_DATABASE_URL, TARA_REDIS_PREFIX, TARA_CONTENT_BUCKET, TARA_CDN_URL, NISABA_DATABASE_URL, NISABA_REDIS_PREFIX, plus the shared oshun_dev database used by services without a dedicated per-domain database. Gap: ARETE_DATABASE_URL, VERITAS_DATABASE_URL, NYX_DATABASE_URL, and METIS_DATABASE_URL are not yet documented in .env.example. Either: (a) those domains run against the shared oshun_dev database for V1 launch, in which case .env.example should declare that explicitly, or (b) they need per-domain database URLs added before launch. Metis runs inside apps/metis/{web,admin,api-gateway,worker} against its own per-service database URLs.

22. CI/CD and Build Tooling#

23. Testing Tooling#

24. Security and Secrets#

Cross-References#

• Product surface and feature scope — V1/features.md.
• Implementation source of truth — V1/TODOS.md.
• V1 runtime architecture — V1/ARCHITECTURE.md.
• Whole-monorepo dependency registry (out-of-V1 domains) — /DEPENDENCIES.md.
• Whole-monorepo architecture — /ARCHITECTURE.md.
• Domain reference — /DOMAINS.md.
• Project conventions — /CLAUDE.md.