Oshun: whole-monorepo Rust migration audit

Date: 7 September 2026

Audited source: a55b2610459a777d86cc4683acf564e901cece5c

Decision context: A substantial rewrite is acceptable. Recommendations prioritize the intended long-term architecture over minimizing rewrite cost.

Deliverable: Architecture and migration assessment; no application migration is implemented by this report.

1. My recommendation#

Make Rust Oshun’s default language for owned backend services, durable workflows, domain computation, local engines, native daemons, and performance-sensitive shared libraries. Keep the languages that own the relevant platform or ecosystem.

Your proposed split is broadly right, but it needs several additions:

• TypeScript: browser UI, React, Next.js rendering, React Native UI, browser extensions, editor integrations, and JavaScript tooling that must run in its host. Some small web-specific server adapters can remain TypeScript.
• Kotlin: native Android UI, Android services, permissions, notifications, platform integrations, and Wear OS. Put reusable domain logic below those interfaces in Rust.
• Swift: native Apple UI and platform integrations across iOS, macOS, watchOS, and other Apple surfaces. Again, reusable logic can live in Rust.
• Python: model research, training, fine-tuning, scientific exploration, notebooks, ComfyUI nodes, and adapters for Python-hosted tools. Move ordinary Python service orchestration and business rules to Rust; do not confuse those with the model ecosystem itself.
• C++ and a little C: Unreal integration, engine/plugin ABI boundaries, vendor libraries, selected hardware interfaces, and specialized native/GPU interoperability. Rust can own more of the underlying computation without requiring Unreal to become a Rust engine.
• C#: Unity integration and Unreal’s C# build rules. Those files exist because their hosts require them.
• Solidity: existing EVM smart contracts. Rust backend services do not replace the execution language of those contracts.
• SQL, shader languages, infrastructure definitions, and small shell scripts: keep these in their native representations. They are not language sprawl to eliminate.

I would not add Go, Java, Dart, Elixir, Zig, Julia, or another general-purpose application language as a new platform default. Keep a language-specific public SDK when customers need it. Keep specialist scientific or vendor code behind a boundary when it is useful. Neither exception requires using that language for Oshun’s own backend.

The preferred result is a Rust-centered polyglot platform, with thin platform shells and deliberate boundaries. The success measure should be how much authoritative behavior Rust owns, how reliable the products are, and how well the code is reused—not the percentage of files ending in .rs.

The expensive rewrites I would actually approve#

1. Replace most first-party TypeScript and ordinary Python backend execution with Rust.
2. Extract canonical domain rules from the main BFF, shared contract implementations, and large agent packages into cohesive Rust libraries.
3. Consolidate overlapping implementations in Neith, Maya, Euterpe, Oya, and the V-series around explicit owners and conformance tests.
4. Introduce a common Rust service, persistence, workflow, telemetry, and release foundation.
5. Move shared offline/local computation into Rust libraries used by desktop, native mobile, and selected browser WASM clients.
6. Prefer native Kotlin/Swift for flagship mobile experiences where platform integration is central; decide that per product, independently of the backend rewrite.
7. Replace Yemaya’s Electron host with a Rust/Tauri host if its required desktop behavior passes a concrete compatibility suite.

I would not make replacement of Unreal, PyTorch, ComfyUI, browser rendering, or vendor GPU libraries a prerequisite for this migration. Building replacements for those systems is a separate product and research program, even with a large budget. It can be pursued deliberately, but it should not hold the backend architecture hostage.

2. Scope, method, and limits of the audit#

This is a whole-tree inventory plus a focused source-level architectural audit. It covers all tracked paths, all discovered JSON/TOML project manifests, all 48 registered domains, the platform groups, application groups, V1–V10, SDKs, native integrations, infrastructure, and verification configuration.

The inventory used git ls-files, not an unrestricted filesystem walk. This excludes untracked dependency installs and local build products. It parsed every tracked package.json, project.json, Cargo.toml, and pyproject.toml; categorized source by extension; counted physical lines; inspected declared dependencies and targets; and grouped results by directory and nearest explicit Nx project.

The source review followed representative entrypoints and boundaries: BFF startup and assistant execution, durable run/effect contracts, contract-derived persistence, queues/events, Python services and model packages, Rust service entrypoints, desktop and FFI integrations, audio/WASM, robotics, and CI. The domain-by-domain recommendations combine those findings with each domain’s source inventory and registry description. They are not a claim that every function in every domain was manually reviewed.

The tree contains tens of millions of physical source lines. An architectural audit can cover its structure comprehensively without claiming a line-by-line security review, mathematical correctness certification, hardware qualification, or production readiness assessment of every implementation.

What the measurements mean#

• Physical lines include comments, blanks, tests, declaration files, and source-like fixtures. They are not semantic lines of code or effort estimates.
• An additional heuristic separates paths resembling tests, generated files, vendor/build directories, and documentation/evidence. It is useful for screening, not a reliable production-code census.
• Rust frequently embeds tests in ordinary source files. Those tests remain in the “non-test-path” count. Comparing that number directly with TypeScript’s separate test files would mislead.
• Package dependencies are declarations, not observed runtime imports. A package can be unused, indirectly consumed, or loaded through a native boundary.
• Explicit project.json counts are not the complete inferred Nx graph and are not deployable counts.
• A Cargo manifest can be a workspace root rather than a package. A package, a workspace member, an Nx project, and a service are different units.
• Historical verification records were used to understand the test portfolio; their pass counts were not credited as fresh results.
• No credentials, private environment files, live databases, or external production accounts were needed for this audit.

Git submodule entries are inventoried as pointers; their external contents, engine installations, model weights, and untracked local files are not recursively audited.

The accompanying evidence bundle contains the reproducible inventory program, summary, complete project and Cargo catalogs, and verification receipts. Recommendations below are engineering judgments; measurements and demonstrated source behavior are identified separately.

3. Measured state of the repository#

3.1 Repository and build structure#

All enumerated JSON/TOML project manifests parsed successfully. The inventory found no missing local Cargo dependency manifest among directly declared package dependency paths. That is a limited structural result; it does not establish that dependencies resolve, workspaces admit every package, or code compiles.

The root remains a Node/pnpm/Nx workspace. Its manifest specifies pnpm@10.25.0 and Node >=22.0.0. There is no root Cargo workspace. Rust is organized into several domain/product workspaces plus standalone or explicitly isolated packages. See root package configuration, Nx configuration, and workspace package configuration.

3.2 Languages#

There were no tracked .cu files in this snapshot. CUDA belongs in the exception policy because of the model/GPU ecosystem, not because this inventory found a large owned CUDA codebase.

The heuristic leaves 23,970,549 TypeScript physical lines outside identified test paths and excluded/generated indicators. Do not turn that number into a rewrite quote. It still includes comments, wrappers, data, mixed-purpose libraries, and potentially redundant behavior. First classify capabilities and reachable product paths.

3.3 Rust is already substantial, but concentrated#

Neith and Maya together account for roughly 88% of tracked Rust physical lines. The migration is therefore partly a matter of making Rust authoritative across the product, rather than introducing Rust for the first time.

Examples already available to reuse include:

• Neith’s 600-member umbrella workspace.
• Maya’s 86-member engine workspace.
• Oya’s Rust workspace, Node/WASM bridges, and differential comparator.
• Euterpe’s DSP WASM interface.
• Kalika’s 34-member umbrella workspace.
• Iris’s native computer-use workspace.
• Existing Rust services under V3, V4, V6, and V7.

These are starting points, not blanket endorsements. Their integration and release evidence must be assessed separately from their size.

3.4 Runtime dependencies show what must move#

Across parsed package manifests, including runtime and development declarations where present, there are 96 declarations of Fastify, 53 of Hono, 16 of NestJS, 16 of BullMQ, 66 of Drizzle, 43 of pg, and 13 of Prisma’s client. There are 29 Next.js declarations, 13 React Native declarations, and eight Expo declarations. These counts overlap and are not service counts.

Python manifests declare NumPy in 40 packages, PyTorch in 28, and FastAPI in 17. The Python portion is therefore not just scripting. For example, Metis’s Python service combines FastAPI, SQLAlchemy, Alembic, Redis/Celery, document processing, telemetry, and pinned executable-mathematics dependencies. Its tree contains 1,428 Python files.

Rust has substantial serialization/error-handling adoption, while Axum is directly named in only four Cargo package manifests and SQLx in one. Dependencies inherited through workspace catalogs or wrappers can change that picture, but the observed Rust portfolio is much more engine-oriented than a unified backend service platform.

4. Findings that materially change the migration plan#

F1. The main BFF is a major domain execution boundary, not just an HTTP adapter#

Observed: BFF package configuration declares 184 runtime dependencies. The nearest explicit BFF project owns 665,584 physical source lines under the inventory’s method. Startup wires persistence, domain state, idempotency, review/audit stores, privacy deletion, assistant services, and cross-domain sources.

Implication: Replacing Fastify with Axum does not migrate the BFF’s real responsibilities. Those dependencies must become Rust libraries, generated clients, or explicit service calls. Otherwise the new Rust API simply proxies into the existing TypeScript platform.

Recommendation: Extract bounded modules first: identity/tenant context, content and contract persistence, review authority, durable run execution, assistant policy, domain adapters, and presentation aggregation. Deploy ordinary business modules together initially where that simplifies transactional consistency. Split processes for independent scaling, hardware, security, or failure isolation—not one service per Nx project.

F2. The contract layer contains behavior that schemas alone cannot preserve#

Observed: Durable effect identity uses Zod refinements, uniqueness/sorting rules, lineage restrictions, and canonical digests. The persistence registry imports a broad set of executable schemas. The Prisma schema is generated from this contract/persistence machinery.

Implication: Generating Rust structs from JSON Schema or copying TypeScript interfaces would drop validation and identity semantics. A changed hash, enum spelling, timestamp precision, optional field, or default can invalidate existing records or cause duplicate effects.

Recommendation: Separate structural wire definitions from executable invariants. Establish a language-neutral fixture corpus containing accepted and rejected inputs plus canonical serialized bytes and hashes. Port invariants into Rust and retain independent cross-language conformance checks. Keep database migration ownership separate from DTO generation.

F3. Queue and event semantics need their own migration#

Observed: The queue wraps BullMQ and translates priorities, retry policies, job envelopes, and retention options. The event bus uses Redis Pub/Sub with TTL-bounded stored envelopes, scheduling, acknowledgements, replay, and dead-letter behavior. The architecture document’s description of local Redis Streams does not match this inspected implementation.

Implication: A Rust Redis client is not a BullMQ-compatible worker, and ordinary Pub/Sub is not a durable workflow engine. Translating transport calls would risk losing ordering, acknowledgement, replay, or retry guarantees.

Recommendation: Define one owned job/effect protocol. Bridge existing BullMQ workers during transition; drain old jobs and scheduled/retry state before retiring the bridge. Prefer a transactional PostgreSQL outbox plus durable worker leases for ordinary business work. Adopt JetStream where durable fan-out/replay materially helps, after a broker decision record. Keep Kafka where an established stream workload justifies it. Avoid introducing three equivalent messaging stacks during the rewrite.

BullMQ documents its Redis-based job system, while NATS distinguishes Core NATS delivery from JetStream persistence/replay. The proposed architecture is a choice based on those capabilities, not a claim that their delivery semantics are interchangeable. BullMQ, JetStream.

F4. Some narrow Nx targets invoke whole Rust workspaces#

Observed: Eighteen explicit project configurations contain the Neith umbrella cargo test --manifest-path libs/neith/Cargo.toml command under build/test screening; the same count references its umbrella release-build command. Neith core and AI runtime are examples. Kalika CAS runs cargo test --workspace from a directory beneath the Kalika umbrella.

Implication: A command named after one library can compile/test hundreds of workspace members. Running many such Nx targets can duplicate scheduling and contention, especially on this 16 GiB host.

Recommendation: Model Cargo package dependencies in the affected graph. Give each target explicit package selection and correct transitive inputs; schedule umbrella checks once. Include workspace manifests, lockfiles, toolchains, build scripts, native sources, generated bindings, and relevant environment/tool versions in cache keys. Cargo documents workspace defaults and explicit package selection. Cargo workspace semantics.

F5. A Rust implementation is not automatically a production service#

Observed: V6 world-server startup binds a TcpListener, handles connections serially, reads a 1 KiB buffer, and serves a health response or 404 through that entrypoint. The file also contains extensive simulation/domain logic. V7 Moremi has a broader hand-written HTTP path with a request bound and read timeout, but still uses a serial accept/handle loop.

Implication: Capability lists, domain tests, and a healthy port do not establish a networked multiplayer service or production-grade API behavior. V6’s inspected health entrypoint in particular must not be counted as exposing all its library capabilities.

Recommendation: Standardize service hosting on a reviewed HTTP stack and explicitly integrate the domain engine. Test concurrency, malformed/partial requests, backpressure, disconnects, authentication, persistence, and process restart behavior. This finding is about the inspected entrypoints; it is not a claim about every V6/V7 runtime path or deployment.

F6. The current verification portfolio is large, but pass labels have different meanings#

Observed: 3,460 explicit projects declare test; 1,323 declare typecheck; other names also exist. The BFF’s explicit e2e target prints a scaffold message, despite real route/contract tests elsewhere. There are 249 project test target configurations containing passWithNoTests. Typecheck documentation explicitly says a passing baseline ratchet can retain known app errors and exclude located dependency errors.

Implication: Neither target presence nor a green task label proves migration parity. This does not imply those projects have no tests: it means actual discovered tests and assertions must be recorded.

Recommendation: Carry forward existing suites, add black-box tests against each old/new implementation, and require nonzero expected discovery. Label evidence as unit, contract, database integration, browser/native E2E, real provider, engine, hardware, or live operation. The repository already applies this distinction in its historical test-coherence record; extend it to the Rust program.

F7. Toolchain and supply-chain policy is uneven#

Observed: 460 tracked Rust toolchain files select stable; two select 1.85.0; one selects 1.95.0. Rust security audit actions appear in V3 and V6 workflows. The broader dependency security workflow gates pnpm findings and secrets while making its OSV cross-check informational.

Implication: Replacing npm packages does not automatically produce pinned or comprehensively audited native artifacts. Native dependencies, platform libraries, build scripts, and shipped binaries add their own release obligations.

Recommendation: Pin a reviewed compiler per supported release lane; define an MSRV separately; use committed lockfiles for shipping workspaces; add a complete lockfile-to-release-artifact inventory with enforced Rust advisory/license checks, SBOMs, signatures, and symbol retention. Verify which existing pipelines already provide each piece before adding another scanner. This is a coverage/configuration finding, not a discovered vulnerability report.

F8. Public SDK languages and host-required files must not be counted as failed migration#

Observed: Go is only eight source files: the Neith self-hosted blob server and SDK surfaces. Solidity lives under Lilith contracts. C# includes Unreal Build.cs/Target.cs and Unity integration. Apple/Android interfaces already exist in applications, wearables, and SDKs.

Recommendation: Port the owned Go server to Rust if consolidating backend operations is the objective. Retain Go/Python/C#/Swift/Kotlin/TypeScript SDKs according to users’ needs. Preserve host build rules and blockchain contracts. Language policy should distinguish owned runtime implementation from consumer-facing bindings.

F9. Nine existing Rust manifests fail workspace discovery#

Demonstrated: A serial sweep ran the following command against all 953 tracked manifests with installed Cargo 1.96.1:

cargo +stable metadata --offline --locked --no-deps --format-version=1 --manifest-path <manifest>

944 succeeded; nine exited 101 because the package believes it belongs to an enclosing workspace but is not a member:

Recommendation: Decide membership deliberately. Production crates should normally join their intended workspace; independent reference/validation tools may be explicitly excluded and isolated. Re-run metadata for every manifest, then targeted compilation/tests. Do not indiscriminately add everything to the umbrella: validation fixtures may intentionally need different dependencies.

The metadata receipt records every result. --no-deps checks manifest/workspace structure; it does not verify resolved dependency graphs, lockfile completeness, MSRV compatibility, linking, or runtime behavior. The +stable override intentionally avoids downloading hundreds of directory-local toolchains and therefore does not test those pins. Successful metadata calls resolved 150 distinct roots, including standalone packages; this is different from the 18 explicitly declared workspace tables. Repeated warnings also identified ignored profile settings in non-root manifests; release optimization settings must be verified at their effective workspace root.

5. Target language policy#

5.1 Where Rust should become authoritative#

This is intentionally broad. Given your cost tolerance, I would not permanently exempt ordinary CRUD, scheduling, business policy, retrieval orchestration, or API adapters merely because TypeScript/Python are adequate. Consolidation itself is a legitimate benefit. I would still require a coherent module boundary and replacement tests.

5.2 TypeScript: keep the web ecosystem, shrink backend authority#

Keep React components, Next layouts/rendering, accessibility behavior, design tokens, CSS, browser storage integration, service workers, React Native views, Storybook, Playwright, and host-required extension code.

A Next route handler may remain TypeScript when it handles cookies, SSR composition, a framework callback, or a thin proxy. It should not become a second implementation of billing, permissions, workflow recovery, scientific algorithms, or canonical content rules. Those should execute in Rust services or shared Rust libraries.

Do not move every frontend utility to WASM. Formatting a label, managing a dialog, or validating a form’s presentation state does not need a native boundary. Move substantial reusable computation: audio DSP, geometry, search indexing, document analysis, simulation, binary parsing, and offline domain behavior. Validate bundle size, startup time, copying costs, browser support, and worker scheduling before claiming a performance improvement. wasm-bindgen guide.

The large workbench-kit package particularly needs a responsibility split. Its presentation and accessibility components stay TypeScript. Any authoritative publication, trust, evidence, or workflow rules mixed into that package should move below the UI boundary.

5.3 Native mobile versus React Native#

My preference, with rewrite cost accepted: use Kotlin/Compose and Swift/SwiftUI for flagship mobile products whose quality depends on deep platform behavior—voice/capture, background execution, offline data, media playback, wearables, device control, and extensive accessibility. This is a product-engineering preference, not a measured finding that the existing React Native apps are inadequate.

For content-oriented companion apps and admin utilities, React Native remains a reasonable permanent choice. It can use the same Rust core. Choose one primary UI implementation per product/platform; do not maintain equivalent React Native, SwiftUI, and Compose versions of the same screen without a specific product reason.

A practical mobile structure is:

Rust domain/local core
  ├── Swift binding → SwiftUI / UIKit / Apple frameworks
  ├── Kotlin binding → Compose / Android framework
  └── React Native module boundary → TypeScript UI

Use generated, coarse-grained interfaces. UniFFI is a candidate for Swift/Kotlin bindings. For React Native, its C++ TurboModule/JSI architecture requires an appropriate wrapper; a Node-API addon is not a direct Hermes module. Verify thread ownership, callbacks, cancellation, handle disposal, exception/panic behavior, and app suspension on actual devices. UniFFI, React Native C++ modules.

Kotlin is aligned with Android’s documented Kotlin-first approach, and SwiftUI supports Apple’s UI platforms. These are sound platform choices; they do not require that all business logic be implemented twice. Android, SwiftUI.

Current anchors include Oshun mobile automation targets, Oshun wearable sources, Iris mobile, and the Psyche/consumer SDKs. Preserve existing deep links, secure storage, push tokens, purchases, offline stores, and account recovery during any client rewrite.

5.4 Python: retain the model/science ecosystem, migrate ordinary services#

Keep Python permanently for training and model research unless an individual workload has a demonstrated replacement with the capabilities you need. Examples include Nous Dreamer, other Nous research packages, Gaia forecasting, and ComfyUI worker integration.

Move to Rust ordinary HTTP service hosting, tenancy, identity, rate limits, worker scheduling, retrieval orchestration, structured ingestion, durable jobs, and business rules. Psyche orchestration is a strong candidate. Metis should be split: API/course/job/permission logic can migrate, while its executable math/science and document/model adapters remain isolated until replacement correctness is demonstrated.

Do not move tensor operations to Rust merely to remove the Python caller. Much of the actual compute already executes in native libraries. PyTorch supports both Python and C++ interfaces; that does not establish feature parity with an arbitrary Rust framework. Keep the best-supported model backend behind a stable protocol and evaluate exported/native inference per model. PyTorch frontend documentation.

Use process isolation for GPU workers and tools with large or conflicting environments. Use PyO3 for local Rust computation embedded in Python when sharing buffers and avoiding process overhead materially helps. Document ownership, dtype/layout, device placement, and cancellation. A Python extension may still depend on Python’s lifecycle and packaging. PyO3.

5.5 C++, C, shaders, and engine integration#

Keep Unreal-facing UObject/actor/component code, reflection metadata, Blueprint exposure, editor modules, engine callbacks, and platform integration in C++ where required by the current engine. Move reusable simulation rules, parsers, networking services, asset processing, and deterministic algorithms to Rust with narrow interfaces. Epic’s documented programming model remains C++ and Blueprint. Unreal’s programming model.

For owned C++ libraries without deep Unreal/vendor coupling, Rust is a strong rewrite destination. For mature external kernels, keep a wrapper until there is a compelling reason to replace the kernel itself. CXX or a deliberately designed C ABI can bridge supported boundaries; CXX does not make arbitrary Unreal APIs directly usable from Rust. CXX.

Keep WGSL, HLSL, Metal, GLSL, and CUDA where the execution platform needs them. Rust can generate or dispatch GPU work without replacing the shader/kernel language. NVIDIA’s CUDA programming model and C++ support are independent of which host language orchestrates the workload. CUDA documentation.

If you eventually want to retire Unreal for an owned Neith/Maya engine, define a separate engine-replacement program: content import, editor workflow, rendering, animation, networking, profiling, platform packaging, game feel, authoring tools, and compatibility. The existence of millions of Rust lines is insufficient evidence to retire Unreal.

5.6 Other languages: specific decisions#

Solidity is specifically intended for smart contracts, including EVM execution. Preserve deployed-contract compatibility and upgrade semantics rather than treating .sol files as ordinary server code. Solidity documentation.

6. Proposed architecture#

6.1 Separate authoritative behavior, interfaces, and external engines#

The diagram is a proposed ownership model, not a deployment graph extracted from the repo. It deliberately allows several Rust modules to share a process. Network boundaries should follow operational requirements; library boundaries should follow domain ownership.

6.2 Rust foundations to standardize#

Axum is designed around Tokio/Hyper and Tower middleware; SQLx supports PostgreSQL and explicit checked SQL workflows. These are recommended defaults, not claims that the existing services already use this uniform stack. Keep chosen versions pinned and qualify them against the project’s targets. Axum, SQLx.

6.3 Workspaces and crate boundaries#

Do not create a crate for every current TypeScript package. Many packages are feature-sized, generated, or have tight coupling to a larger capability. A direct 3,324-package translation would preserve the fragmentation while adding Rust compilation complexity.

Prefer a small number of deliberate workspaces: platform/services, selected native engine families, scientific compute, embedded robotics, and externally published SDKs where independent release requirements justify isolation. The current workspaces can be evolved toward this model; do not nest a new root workspace around them without a membership migration plan.

Within each domain, separate:

1. Pure types, value objects, and deterministic rules.
2. Domain application operations.
3. Persistence/provider ports.
4. Concrete adapters.
5. Executable entrypoints and platform bindings.

Avoid a giant cross-platform crate that unconditionally depends on Tokio, SQLx, a GPU runtime, Python, Tauri, and Android/Apple frameworks. A browser or no_std consumer should not resolve a server stack. Compile features and target-specific dependencies must be tested as a supported matrix, not assumed to compose.

6.4 FFI and wire-boundary rules#

Use coarse operations such as “evaluate this document” or “advance this simulation batch,” not thousands of fine-grained calls across a bridge. Define who allocates and frees buffers, how handles expire, whether cancellation interrupts work, and how errors are encoded. Do not pass Rust’s native ABI across independently released binary boundaries.

napi-rs explicitly distinguishes its Node-API ABI level from the operating systems/architectures tested by a package. Treat artifact distribution as part of the migration. napi-rs packaging model.

For untrusted generated code and plugins, Rust compilation is not a security boundary. Wasmtime can supply a sandbox, but host functions still require carefully scoped capabilities, quotas, and lifecycle controls. Wasmtime security model.

7. Domain-by-domain migration decisions#

The table covers all 48 registered domains. L/A counts explicit library/application project.json files under that domain. RS counts Rust files under both its library and application directories. These counts are measured at the audited revision and can differ from older narrative counts in domains.json. Source sizes include tests and do not establish feature maturity.

For every row, retain the relevant web UI in TypeScript and native platform interfaces in Kotlin/Swift. The last column identifies additional exceptions or particularly important acceptance evidence. Recommendations are at the capability level; the complete project catalog provides every explicit project path for implementation planning.

7.1 Where the major domains need more than translation#

Oshun/Eve/Iris/Psyche: distinguish the conversation transport, tool authority, durable run executor, memory stores, and actual model inference. Rust should own the first four where they are product authority. Preserve the current agent-turn semantics: streaming, tool-result feedback, iteration limits, the bounded argument-repair extension, provider refusal, and error propagation. Preserve server-injected identity in agent tools. A rewrite must not allow the model to choose its own authenticated tenant/user or fabricate successful actions.

Isis/Nous: organize around a Rust control plane and isolated model workers. The GPU worker already mixes TypeScript executors with Python pipelines for mesh/splat/texture processing. Port orchestration and stable CPU algorithms first; replace a model implementation only after output quality, determinism where promised, throughput, VRAM use, failure recovery, and artifact compatibility meet explicit gates. A Rust API in front of a Python model is a valid target architecture, not an unfinished migration.

Metis/Kalika/Sophia/Nyx/Gaia: preserve an independent correctness oracle. A Rust reimplementation and its own tests can agree on an incorrect formula. Use reference datasets, trusted external implementations, properties such as conservation/monotonicity, and scientific tolerances suited to each algorithm. Do not use one universal float epsilon. Metis’s explicitly pinned SymPy/Pint/mpmath verifier is a good example of an ecosystem dependency to retain until a replacement proves the same verification contract.

Neith/Maya/Euterpe: assign ownership across overlapping engine, audio, rendering, compute, scene, and authoring capabilities. A common Rust language does not resolve architectural duplication. Reuse a canonical subsystem through adapters when its behavior and deployment fit; retain distinct engines when they serve materially different requirements. For example, a domain state model such as Neith’s launcher state is useful Rust code, but is not by itself an Android launcher surface integrated with the OS.

Oya/Galatea/Uzume/Brigid: keep real-time/control execution separate from request/response services and LLM scheduling. Oya’s numerical parity is useful; it does not prove flight control. Galatea’s safety controller explicitly models watchdog and stopping faults. Preserve timing, fault transitions, device behavior, and physical interlocks under hardware testing; a memory-safe language does not establish those properties.

Bellona/Yemaya: distinguish remote-control authority and transport from the application-specific plugin. Rust is a strong owner for the daemon, command envelope, job lifecycle, transfer, and state. Python/C++/C#/Swift remain at the tool or OS boundary. Preserve cancellation, access scopes, path restrictions, user/session ownership, application versions, and artifact provenance. Test against the actual supported creative applications, not only mocked command responses.

8. Products, clients, SDKs, and other repository areas#

8.1 V1–V10#

Do not migrate ten copies of identity, billing, consent, workflow recovery, telemetry, artifact metadata, or deletion independently. Specify the shared authority and each product’s adapter. Keep genuinely game-specific protocols, simulation timing, and privacy boundaries distinct.

8.2 Desktop, mobile, wearables, extensions, and embedded views#

• Desktop: Five desktop src-tauri roots appear across Euterpe, Iris, Lilith, Neith Vault, and V10, plus a nested Euterpe core crate. Yemaya desktop explicitly uses Electron. Favor Rust-native hosting; qualify screen capture, audio, file access, updates, plugin hosting, GPU integration and platform accessibility before removing Electron. Tauri’s Rust core/webview split fits a TypeScript creative UI. Tauri architecture.
• Mobile: Thirteen app manifests explicitly declare React Native. Eight declare Expo. These overlap. Rust-core adoption does not force replacing the UI. Native UI rewrites should be justified by each product’s experience, not by a language quota.
• Wearables/XR/TV: retain their native integration surfaces and platform toolchains. Test actual target support for each Rust dependency, particularly on constrained targets; do not infer a working app from a compiler target’s existence. Rust target support.
• Extensions/embedded web: browser extensions, Telegram miniapps, widgets, and any editor/webview shells remain TypeScript where required. Backend bots, indexing, account linkage and durable delivery are Rust candidates.
• Native Java/Objective-C: treat these as interop debt to reduce where useful, not files to delete mechanically. Some glue remains necessary even with Kotlin/Swift/Rust as the preferred languages.

8.3 Platform groups and non-domain applications#

The inventory includes more top-level app/library scopes than the 48 registered domains, including concordia, infra, and V2/V4/V5. They are explicitly covered here rather than silently omitted from the domain matrix.

8.4 Data, infrastructure, and operating model#

Keep PostgreSQL, Redis, object storage, vector/search/graph stores, and model infrastructure when they meet the product’s requirements. The language used to implement those dependencies is not the same decision as the language used for Oshun-owned code.

Audit actual deployed dependencies before consolidating stores. The repo contains many Docker/Compose/Kubernetes/Terraform definitions; a checked-in deployment manifest does not prove that a service is deployed or used. Establish a deployable register containing owner, source revision, image/binary, environments, databases, incoming clients, outgoing dependencies, and rollback procedure.

For storage migrations:

1. Retain current SQL and migration history, including Prisma and Alembic histories, until a defined ownership transfer.
2. Map every old field/default/index/constraint/enum to the replacement. Preserve row-level/tenant access semantics and soft-delete/erasure rules.
3. Choose one schema migration authority for each database during transition. Do not let Prisma, Alembic, and SQLx independently own the same schema history.
4. Rehearse backfills, interrupted migrations, snapshot restore and rollback with representative data volumes.
5. Verify SQL query plans and connection pool behavior. Rust will not fix a missing index or unbounded query.
6. Use an outbox/change log and reconciliation for dual-running periods. Do not introduce uncoordinated application-level dual writes.

For production delivery, adapt the existing CI/container/signing/observability workflows. A Rust binary may still require shared libraries, TLS roots, codecs, GPU drivers, dynamic plugins, or platform entitlements. Build and test the actual shipping artifact rather than assuming everything can use a minimal static Linux image.

9. Migration sequence and priorities#

Phase 0: make the migration measurable#

Do this before mass translation.

• Repair or explicitly classify the nine workspace-membership failures.
• Establish an authoritative capability/deployable inventory: implemented, reachable, exercised against a real dependency, deployed, or historical/reference-only.
• Map Cargo dependencies into Nx’s affected graph and remove repeated umbrella execution from narrow targets.
• Pin toolchain/release policy and enumerate supported desktop/mobile/server/embedded targets.
• Record current behavior for API/schema, database, queue/effect, and client-boundary contracts.
• Establish baseline latency, memory, startup, throughput, correctness, binary size, and build/CI cost on representative workloads.
• Assign one owner to each duplicated platform capability and identify intended Rust implementations for adoption, consolidation, or rewrite.

Exit: all intended manifests discoverable; each pilot has a working baseline, a measurable acceptance contract, and a rollback path. Do not count a newly named Rust crate as migrated behavior.

Phase 1: prove three different migration patterns#

The third pilot should be selected from a concrete runtime ownership map. Prefer a bounded artifact/run read-and-transition flow with a known canonical store, not the entire Eve conversation loop or billing ledger as the first replacement.

The blob server pilot is small relative to the portfolio, but not disposable: preserve its security and atomic-write behavior. The Oya pilot is algorithmically useful, but must not be credited as hardware qualification. The platform pilot is the architectural proof that Rust can become authoritative without leaving hidden TypeScript state behind.

Phase 2: build the common Rust backend substrate#

Create shared conventions and implementation for authenticated tenant context, service hosting, structured errors, typed IDs, tracing, database pools, transactions, outbox/inbox, durable leases, idempotency, storage, feature flags, and shutdown.

Port the behavior behind libs/shared and the authoritative pieces of libs/contracts/libs/oshun/persistence. Keep the current stores and protocols stable while replacing implementations. Generate clients for existing TypeScript/native consumers. Use the pilot’s compatibility suites as the standard service template.

Exit: one real product path uses Rust from API entry to persistence and survives restarts, retries, denied requests and rolling mixed-version operation. The old path can be disabled without silent fallback.

Phase 3: move broad business/domain services#

Migrate domains with ordinary service and deterministic business logic in batches: Arete, Demeter, Hestia, Asase, Freya, Cybele, Maat, selected Lilith/V5 services, and comparable domains. Rust is the default destination even if a particular handler has no measured CPU bottleneck.

Each batch should retire a coherent old ownership boundary. Reuse the new service substrate. Preserve protocol adapters for unmigrated callers. Avoid a “Rust copy” that remains unused beside the TypeScript implementation.

Exit per batch: old state writer retired, production path switched, backfill/reconciliation complete, equivalent or improved service objectives, all client suites passing, rollback rehearsed, obsolete dependencies removed.

Phase 4: migrate agent execution and generation orchestration#

Move Eve/Iris/Psyche control logic, Isis job/provider control, Yemaya production orchestration, Metis authoring workflow and Sophia retrieval authority to Rust. Keep Python/GPU execution workers and required host adapters behind protocols.

This phase has high semantic risk. Re-run the existing assistant evaluation families, prompt-injection cases, grounding/citation checks, tool authority tests, review/approval rules, recovery certification, budget tests and real-provider release gates. Preserve prompt/model/config versions when comparing orchestration so changes in generated output have an interpretable cause.

Exit: durable runs/effects survive process termination and retry; denied tool calls remain denied; user/tenant boundaries remain intact; generated outputs carry correct lineage; real-provider artifact quality meets the existing gates.

Phase 5: consolidate native compute and clients#

Expand shared Rust cores across desktop, selected WASM browser workloads, and mobile. Consolidate Neith/Maya/Euterpe/Uzume compute where ownership is genuinely shared. Rewrite remaining suitable TS/C++ algorithms once reference tests exist.

Run any native mobile UI program alongside this phase, using the same Rust core and stable protocols. This is separately releasable from backend migration. The mobile team should not wait for every domain crate, and the backend should not wait for every native screen.

Exit: signed artifacts, real-device/simulator coverage, offline migration and rollback, resource/lifecycle correctness, accessibility and product flow parity. Native ABI compatibility and artifact distribution must be part of the release.

Phase 6: retire legacy authority and pursue optional engine replacement#

Remove obsolete implementations, adapters, deployment targets and dependencies once mixed-version clients/jobs no longer need them. Preserve historical migration records and externally supported SDK contracts.

If the product strategy still calls for replacing Unreal or major model/media engines, run that as a separate, milestone-driven program with its own product acceptance suite. The core Rust migration can be complete while those ecosystem exceptions remain.

Sequencing rules#

• Fix build/contract foundations before adding hundreds of crates.
• Move domain ownership before changing broker or database technology unless the old semantics cannot meet requirements.
• Use shadow execution only where it cannot create duplicate side effects.
• Use one writer during transition; compare read models or proposed decisions before switching authority.
• Switch by tenant/cohort/operation where possible, with versioned routing and observable fallback.
• Keep old SDK/wire versions supported for the required client-upgrade window.
• Make old implementation deletion an explicit acceptance criterion.

Scope and staffing#

The inventory is too large and heterogeneous for an honest duration estimate based on line counts. It includes usable foundations, speculative/reference surfaces, tests, generated structures, and duplicated implementations. A credible estimate requires classifying actual capabilities and measuring the three pilots.

I would organize the program around platform/backend, clients/bindings, engines/media/robotics, model/science integration, and verification/release ownership. These are engineering responsibility lanes, not a recommendation to create five disconnected frameworks. Shared contracts, telemetry, release policy and test fixtures should be maintained centrally.

Do not promise a complete rewrite in a single quarter from this evidence. The first planning horizon should deliver Phase 0 and representative vertical slices, then reforecast from observed throughput and acceptance failures. Accepting high cost makes the desired scope broader; it does not make unknown scope measurable.

10. Verification and release requirements#

10.1 Test the behavior across language boundaries#

Preserve the repository’s current automation lanes rather than replacing them wholesale with Rust unit tests. Playwright, pytest, native mobile harnesses, Unreal automation and provider evaluations remain useful regardless of implementation language.

10.2 Semantic traps to cover explicitly#

• JavaScript numbers versus Rust integer widths, overflow behavior and float conversion.
• Decimal money versus binary floating point; rounding rules, currency scale, tax/fee order and refund reversals.
• undefined versus absent fields versus JSON null; unknown fields and default insertion.
• Date/time-zone handling, daylight-saving boundaries, monotonic time versus wall time, replay clocks and leap-second assumptions.
• Unicode normalization, grapheme boundaries, text offsets, regex behavior and locale-sensitive ordering.
• Hash-map iteration versus explicit sorting; canonical JSON versus arbitrary serializer output.
• Promise cancellation/disconnect behavior versus Rust task cancellation; abandoned effects that still complete externally.
• SDK-specific streaming/tool-call/refusal/error formats; retries after partial delivery.
• Filesystem paths, symlinks, permissions, atomic rename, crash durability and Windows/macOS/Linux differences.
• Rust panic, poisoning, deadlock and unsafe/FFI behavior; memory safety does not remove these failure classes.
• Embedded/real-time allocation, locking and blocking I/O on critical threads; absence of a garbage collector does not establish deadline guarantees.

10.3 Rollout contract for each replacement#

Every migration ticket should identify:

1. The old and new authoritative owner and the externally visible behavior being replaced.
2. Current consumers, wire versions, data stores, scheduled jobs and side effects.
3. Compatibility fixtures and independent acceptance tests.
4. Performance/reliability baselines and required product objectives.
5. Data/backfill/migration steps and the rollback point beyond which reverse conversion is required.
6. Shadow/canary strategy, observability and stop conditions.
7. Old implementation, dependency, build-target and deployment deletion criteria.
8. The exact shipped artifact and revision credited by the evidence.

This avoids a permanent two-language implementation of the same business rule. Temporary coexistence is a migration mechanism, not the target ownership model.

11. Expected benefits and what to measure#

Rust is a strong fit for explicit data ownership, memory-safe native computation, predictable allocation choices, shared local/server code and consolidated backend operations. Oshun has enough existing Rust that this would build on real foundations.

The main expected benefits are:

• Common implementation of domain rules across service/local/native/WASM consumers where sharing is useful.
• Reduced Node/Python authority in long-lived services and operational daemons.
• Better control over CPU-heavy computation, memory layout, native resources and concurrency.
• Smaller and more direct native service deployment units where dependencies permit.
• Stronger compile-time modeling of state transitions, units, identifiers and ownership.
• Fewer duplicate runtime frameworks once the old implementations are actually retired.

These are opportunities, not benchmark results. LLM latency, GPU kernels, database queries, storage access and network round trips may dominate a product’s performance. As an illustrative upper bound, if replaceable orchestration is only 5% of request time, making it infinitely fast improves total latency by only about 1.05×. Measure the actual fraction before promising speedups.

Track migration progress with:

Do not use Rust line count, crate count, test count alone, or a green ratcheted task as the program’s completion metric.

12. Verification performed for this report#

The work changed documentation and audit evidence only. It did not change UI, API, contracts, database schemas, assistant behavior, or model pipelines. Consequently, the document checks and the explicitly selected architectural probes below are the relevant verification for this deliverable; the entire application release matrix was not executed.

The first offline Oya attempt could not find criterion in the local Cargo cache. Running the selected producer with --locked and network access installed dependencies and built successfully; the subsequent offline comparator passed. No tracked lockfile or application source changed.

This host has 16 GiB RAM, 3 GiB configured swap and approximately 24 GiB disk available at inspection. macOS sysctl/vm_stat, df, and process listings supplied the resource checks corresponding to the Linux commands in AGENTS.md. Cargo work was serial with one compilation job. No full Nx sweep, Next production build, Expo export, Tauri packaging, Unreal build, real-provider run, or hardware test was launched. Those gates are required for relevant future implementation changes, not evidence furnished by this report.

The nine metadata failures are existing audit findings left unchanged, not a claim that the monorepo passes all builds. The completed deliverable is this assessment and its evidence, not remediation of the codebase.

13. Decision I would adopt#

Adopt the following policy for new owned implementation and planned rewrites:

Rust owns backend/domain/local-engine authority by default. TypeScript owns web and selected React Native presentation. Kotlin and Swift own their native platform experiences. Python remains a bounded research/model/science/plugin ecosystem. C/C++/C#/Solidity and shader languages remain where engines, hosts, devices or chain runtimes require them. Declarative schemas, SQL and infrastructure definitions remain explicit. Public SDKs serve their consumers’ languages.

Then start with build topology, executable contract parity, and the three pilots in Phase 1. Your willingness to fund a costly rewrite supports a broad migration of ordinary backend behavior to Rust. The strongest final architecture still retains a small, deliberate set of ecosystem languages and verifies the boundary between each of them.