# Maya — Systems Deep Dive

> The `libs/maya/` area: ~100 Nx projects that make up Maya, the metaverse /
> world-building domain — a large Rust engine workspace plus a constellation of
> TypeScript libraries spanning procedural generation, rendering, gameplay,
> server, client, UGC tooling, creator studios, adversarial playtesting,
> moderation, and interoperability standards.

## What this area is

Maya is Oshun's immersive world / metaverse domain, and `libs/maya/` is where it
lives as code. Unlike most Oshun lib areas (which are uniformly TypeScript),
Maya is deliberately **polyglot**: the performance-critical runtime is a Rust
engine workspace, and the orchestration, content-pipeline, gameplay-logic, and
"readiness/plan" surfaces around it are TypeScript. The Nx tags reflect this
split — the Rust projects carry `type:rust` / `type:rust-lib` and `layer:engine`
or `layer:ixchel`, while the TS libraries carry `type:lib` / `layer:domain`, and
everything shares `scope:maya`.

The single largest entity is `maya-engine-core` (`libs/maya/engine-core`), a
30-crate Cargo workspace (its `Cargo.toml` lists every member) that is the
actual engine: kernel + plugin registry, an archetype ECS, a job/fiber
scheduler, a render graph, physics-backend abstraction, spatial audio,
atmosphere/weather, avatar embodiment, AI "souls" (NPC/dialogue), and three
procedural-generation crates (`maya-genesis-flora` / `-terrain` / `-urban`). The
rest of the area divides into recognisable families:

- **Procedural generation (`genesis-*`)** — nine TS libraries that each own one
  generative technique. Some compute deterministic _readiness evaluations_
  (`genesis-flora`, `genesis-terrain`, `genesis-urban`), while others run real
  generative algorithms in TypeScript: neural cellular automata (`genesis-nca`),
  Physarum-slime road/network growth (`genesis-physarum`), transformer-guided
  L-systems (`genesis-neural-flora`), Wang/aperiodic tiling (`genesis-tiling`),
  sketch-to-terrain (`genesis-sketch`), and an LLM-driven scene-program agent
  (`genesis-scene-agent`).
- **Rendering & capture facades** — `renderer`, `renderer-advanced`,
  `neural-capture` compute deterministic GPU/ML _plans_ (NRC architecture,
  MegaLights, 4D Gaussian-splat training) with real domain math; `scene`,
  `world`, `physics` are smaller "readiness facade" libraries.
- **Immersion & interop** — `vr-studio`, `vr-studio-web`, `spatial-ar`,
  `standards` plan VR/WebXR sessions, persistent AR anchoring, and
  OpenUSD/glTF/VRM interoperability.
- **Application platform** — `games`, `server`, `client`, `database`,
  `moderation`, `future-input`, `inspirations`, `documentation`, `testing`,
  `tooling` are large TS libraries holding real gameplay systems, services,
  schemas, and content/QA pipelines.
- **Forge / Ixchel UGC** — `forge-assist` (TS LLM co-creator) plus ~24 Rust
  crates for the layered user-generated-content modding system: the
  manifest/registry/loader `forge-core`, `forge-compositor` layer composition,
  semantic `forge-conflict` resolution, `forge-resolver` (PubGrub-shape)
  dependency solving, the `forge-sandbox` + `forge-hot-reload` runtimes, the
  `forge-assets` pipeline, per-domain mod composition (`forge-ai`,
  `forge-audio`, `forge-code`, `forge-economy`, `forge-narrative`,
  `forge-physics`, `forge-rules`, `forge-social`, `forge-ui`, `forge-worlds`,
  `forge-total-conversion`), and the publish-time portability crates
  `forge-compat` (cross-game-version API grading + shims) and
  `forge-cross-platform` (per-platform packaging across nine targets).
- **Forge studios (Ixchel creator tools)** — eight dual Rust+TS crates carrying
  `layer:ixchel` that give creators authoring studios on top of the Forge layer:
  `forge-studio-core` (undo/redo workspace, domain→maya asset conversion,
  quality-budget validation, mod packaging) with the per-discipline studios
  `forge-studio-world`, `-cinema`, `-vfx`, `-mocap`, `-music`, `-sculpt`, and
  `-voice`. The Rust side holds the deterministic core; the TS mirror presents
  it.
- **Loom (world-genome)** — `loom-core`, `loom-biomes`, `loom-dimensions`,
  `loom-evolution`, `loom-multiverse`: the procedural world-DNA, custom biome
  and dimension systems, the living-world evolution simulation, and the
  connected-multiverse portal graph. A second wave adds the ML-flavoured Rust
  crates `loom-semantic` (semantic-brush → terrain/erosion guidance masks),
  `loom-diffgen` (differentiable-procedural baseline with analytic gradients),
  `loom-terrain-ml` and `loom-agent`/`loom-inverse` — honestly a mix of real
  deterministic generators and typed capability-contracts standing in for a
  future ML/LLM pipeline (the per-crate deep-dives say which is which; all
  Rust).
- **Bazaar (UGC marketplace)** — `bazaar-core`, `bazaar-licensing`,
  `bazaar-revenue`, `bazaar-treasury`: marketplace listings, licensing, revenue
  splits, and the creator treasury (TS).
- **Variants (game-variant management)** — `variants-core`, `variants-diff`,
  `variants-merge`, `variants-compat`, `variants-registry`: semantic diff,
  merge, and compatibility analysis of game-object trees.
- **Agora (governance)** — `agora-core`, `agora-constitution`, `agora-councils`,
  `agora-delegation`, `agora-proposals`, `agora-sybil`, `agora-voting`:
  machine-readable constitutions, council elections, liquid-democracy
  delegation, proposal lifecycle, sybil resistance, and voting-model adapters
  (all Rust).
- **Nexus (multiplayer mod sync)** — `nexus-mod-sync`, `nexus-live-voting`:
  server/client mod-manifest exchange, auto-download planning, synchronized
  activation/hot-reload, and in-session weighted voting on live mod changes.
- **Sentinel (mod safety, moderation, IP & provenance)** — `sentinel-core`,
  `sentinel-scanner`, `sentinel-ip`, `sentinel-provenance`: the
  scan-pipeline/audit and moderation control-plane, the automated
  security-scanning stages (static analysis, sandbox-behaviour, network policy,
  resource profiling, anti-cheat, signature verification), the IP/copyright
  bridge to the Themis shield, and creator-identity/attribution provenance for
  submitted mods (Rust).
- **Crucible (adversarial playtest & balance)** — eight crates that
  automatically playtest a modded game to certify its balance and safety before
  it ships. The Rust cores are real, deterministic algorithmic code (not
  readiness facades): `crucible-core` is a std-only headless simulation engine
  (fixed-dt tick loop, seeded `DeterministicRng`, snapshot/replay, parallel
  campaign sweeps); `crucible-agents` provides scripted/heuristic AI opponents
  with fog-of-war observation; `crucible-adversarial` statically hunts
  game-breaking exploits (positive-cycle DFS, one-shot-combo and invincibility
  scanners) over typed mod models; `crucible-balance`, `-scenarios`,
  `-regression`, and `-live` run the statistics (Wilson intervals, Gini, Shannon
  entropy, pairwise covering arrays, Bonferroni A/B regression, z-fingerprint
  drift); `crucible-governance` is the TS sign-off toolkit. Most carry a thin TS
  presentation mirror beside the Rust engine, plus small Python proof/training
  companions that are honest plan facades (no GPU/RL runtime).
- **Competitive session (Nexus multiplayer)** — `matchmaking`, `lobbies`, and
  `instancing` are real `layer:domain` TypeScript logic libraries for the
  player-facing path into a match: `matchmaking` is the rating/skill brain plus
  the queue and server-allocation modules (genuine Glicko-2, Elo, and
  multi-dimensional TrueSkill2, placement, rank tiers, decay, smurf detection),
  `lobbies` is the deterministic pre-game core (lobby lifecycle state machine,
  invites/deep-links, ready-check, server browser, reconnect grace, custom-game
  configuration), and `instancing` is the session-instance lifecycle and
  player-placement/sharding core plus matchmade activity instancing (spawn,
  place, split/merge, transfer, drain; missions/dungeons/raids/tournaments). All
  are dependency-free in-memory rules engines a transport/persistence layer
  wraps.
- **Settlement simulation (§79 world-life TS libraries)** — `npc-occupations`
  plus `animal-database`, `ecology`, `economy-tools`, `env-storytelling`,
  `geospatial`, `jewelry`, `ornament`, `politics`, `social-events`, and
  `world-history`: compact, pure TypeScript data/logic libraries for the living
  settlement layer (occupations, species, festivals, factions, scene dressing,
  map tiles, ornament math, legends). Real domain math with honest scope notes
  deferring rendering/ingestion to the engine; their `project.json` `sourceRoot`
  fields all point at `npc-occupations`, but each has real code in its own
  `src/`.
- **Forge companion (Phase 78)** — twelve TS libraries under
  `libs/maya/forge-companion/` forming the voice-driven AI modding companion:
  ASR front-end and expressive TTS, the FACS avatar controller, the Glass
  Workshop workspace, the four-layer mod abstraction, a real WASM sandbox, the
  generation pipeline (fail-loud model seams plus runnable post-processing),
  semantic merge, the learning system, social integration, the
  `CompanionOrchestrator`, and a testing-only e2e suite. Cloud model backends
  are honest not-configured seams throughout.
- **Social Fabric** — model libraries for healthy communities: `social-graph`
  (privacy-first projections), `social-discovery`, `lfg-community`,
  `mentorship`, `social-facilitation` (opt-in, disclosed AI facilitation),
  `guild-operations`/`guild-recruitment`, the six `community-*` libraries
  (companion surface, federation, governance, health, recognition, reputation),
  `trust-safety`, and `world-social-runtime`. Mostly single-module typed records
  plus pure helpers, deliberately without persistence of their own.
- **Nexus platform services** — player-facing platform TS libraries: `identity`
  (real PBKDF2/TOTP), `economy` (double-entry ledger through creator payouts),
  `social` (friends/presence/chat/voice), `anticheat`, `live-events`,
  `orchestration` (fleet/deployment control plane), `spectator`, `tournaments`,
  and `ugc-runtime` — service classes with typed fail-loud errors; the largest
  (`tournaments`, `ugc-runtime`) are single multi-thousand-line modules.
- **Phase 83 NPC agency & voice gameplay** — `npc-agency-orchestrator`,
  `npc-cooperation-negotiation`, `npc-distillation`, `npc-cloud-fallback` (a
  cloud-LLM policy layer whose transport is external), and
  `urban-evolution-manager`, plus the `voice-dialogue` / `voice-narrative` /
  `voice-negotiation` / `voice-tactics` / `voice-tts` quintet: compact
  deterministic TS logic that turns NPC goals and player speech into durable
  world state.

#### A note on "plan" / "readiness" libraries

Many TypeScript libraries here are honest **planners and readiness evaluators**:
they take a typed description of a workload and return a deterministic plan or
diagnostic (memory budgets, throughput estimates, coverage ratios, blocking
issues) rather than executing the GPU/engine runtime themselves. These are not
stubs — they contain domain-specific math (e.g. `renderer`'s
`designMayaNeuralRadianceCacheArchitecture` estimates MLP parameter counts and
training/inference cost; `engine-core`'s TS
`createMayaEngineCoreVirtualEnvironmentFrame` validates PBR materials and
estimates frame latency). The package `description` fields say so plainly
("TypeScript facade … readiness", "… compliance planning"). Where a project is
genuinely a deferred scaffold, that is called out below.

## How it fits the wider system

Within Maya, the Rust `maya-engine-core` workspace is the runtime foundation;
the TS facade libraries (`scene`, `world`, `physics`, `renderer`,
`engine-core`'s own `src/index.ts`) describe and validate what the engine should
do, and the generation/standards/immersion libraries produce the plans and
assets it consumes. The application-platform libraries (`games`, `server`,
`client`, `database`) build the playable product on top, and `forge-assist` +
the Rust forge crates implement the UGC ("Ixchel") layer that lets creators
extend realms inside a capability sandbox. `forge-assist` is the one node that
reaches outside Maya — it imports `@oshun/ai` (`LLMProviderInterface`) so the
assistant runs on the shared LLM gateway, and injects the V7 quality judge
rather than hard-wiring a provider. Walk the dependency edges on any node below
to see exact consumers.

## Entity reference

### maya-engine-core

The Rust engine workspace at `libs/maya/engine-core` (`sourceRoot` is `crates`,
tags `type:rust` / `layer:engine`) — a 30-crate Cargo workspace and by far the
largest entity in the area. `Cargo.toml` enumerates the members: foundation
crates (`maya-kernel` plugin registry, `maya-ecs` archetype ECS, `maya-jobs`
work-stealing scheduler, `maya-fibers`, `maya-alloc` arena allocators,
`maya-math` SIMD, `maya-spatial` octree/BVH/k-d tree, `maya-reflect`,
`maya-serialize`, `maya-events`, `maya-resource`, `maya-hot-reload`) and large
domain crates (`maya-renderer` render graph, `maya-physics` Havok/PhysX/Jolt
backend abstraction, `maya-audio` spatial acoustics, `maya-atmosphere`,
`maya-embodiment` avatars, `maya-souls` NPC/dialogue AI, `maya-nexus`
client-server networking, `maya-world` chunked streaming, and the
`maya-genesis-flora/-terrain/-urban` procedural crates). Each crate's
`description` in its `Cargo.toml` is authoritative; `maya-physics` is explicitly
"backend abstraction and integration planning". The project also ships a small
TS `src/index.ts` that is a readiness evaluator
(`createMayaEngineCoreVirtualEnvironmentFrame` validating PBR materials and
estimating frame latency), distinct from the Rust runtime.

### @maya/client

A large TypeScript library (`libs/maya/client/src`, ~75 implementation files)
for the Maya runtime client across platforms. Its files group into browser asset
delivery (chunked/progressive-mesh/texture-mipmap streaming, CDN integration,
service-worker offline support, bandwidth-adaptive quality), a WebGPU render
path (~16 `webgpu-*` files), a WASM bridge (~15 `wasm-*` files), and
native/device targets (`android-mobile-build`, `apple-vision-pro-build`,
`steamvr`, Windows). `browser-bandwidth-adaptive-quality.ts` is representative:
real network-class / quality-tier types and adaptive logic, not a stub.

### @maya/database

The Maya persistence layer (`libs/maya/database/src`). Its `index.ts` barrel
re-exports a full set of schema validators with DDL generators
(`generateUserAccountTableDDL`, avatar, inventory, world/zone, building, NPC AI
state, quest/progression, economy with `parseCents`/`formatCents`, analytics,
moderation, asset metadata, permissions, audit) plus a data-access tier:
`MayaRepository`, query builders, `MayaTransactionManager`, a Redis cache layer,
read-replica routing, sharding, archival, backup/PITR, GDPR tooling, anonymizer,
retention, and a query optimizer. Real schema/validator/DDL logic throughout —
e.g. `asset-metadata-schema.ts` defines concrete `AssetType`/`AssetStatus` enums
and record shapes.

### @maya/documentation

A documentation-pipeline library (`libs/maya/documentation/src`) split into two
groups: `api-documentation/` (TypeDoc generation, versioned docs, changelog
generation, API diff/deprecation tracking, interactive API explorer, PDF/offline
export, search, localization, CI/CD) and `tutorials-guides/` (authored tutorials
such as `ai-npc-tutorial`, `asset-pipeline-guide`, `building-basics-tutorial`).
`typedoc-generation.ts` works against real `fs`/`path` and concrete
`TypedocConfig` / `DocSymbol` models, not placeholders.

### @maya/forge-ai-assist

A Rust crate (`libs/maya/forge-ai-assist/src/lib.rs`, ~629 lines, tag
`layer:forge`) with a TS mirror (dual `type:rust-lib` / `type:ts-lib`); module
doc "Deterministic planning primitives for AI-augmented Forge modding tools." It
is the planning layer behind the Forge authoring tools' AI assistance: from an
`AiGenerationContext` it produces deterministic plans across an
`AiContentCategory` taxonomy — a `ModScaffold` (a set of `GeneratedFile`s), plus
`TexturePlan`, `ModelPlan`, `SoundEffectPlan`, `QuestPlan`, and `NpcPlan` — and
a `ConflictResolutionPlan` from `ConflictInput`, with a `ReviewStatus` gate so
AI-suggested content is human-reviewed before it lands. Honesty: as the module
doc says, these are deterministic _planning primitives_ (4 unit tests) — the
crate computes what to generate and how to structure it, but the actual
generative model is a deferred seam (it emits plans and scaffolds, not
model-generated textures/meshes/audio/prose), the same boundary `forge-ai` and
the `@themis/universal-*` libs document. It is the AI-assist companion to the
`forge-*` UGC authoring stack.

### @maya/forge-api

A TS library (`libs/maya/forge-api/src/index.ts`, ~1,084 lines, single module;
no package description — per its barrel, the Forge public API gateway). It is
the REST + GraphQL surface over the Forge mod catalog. `ForgeApiGateway` (built
by `createForgeApiGateway`) handles `RestRequest`→`RestResponse` calls and
`GraphQlRequest`→`GraphQlResponse` queries over `ForgeModRecord`s
(`ForgeModCreateInput` / `ForgeModUpdateInput` CRUD, `ForgeModReview` moderation
state), with `authorize` enforcing per-`ApiSubject` `RegisteredCredential`s,
`ApiVersionSpec` version negotiation, `RateLimitConfig` + `rateLimitHeaders`
throttling, typed `ApiErrorBody` errors, and `PaginatedResult` cursoring.
Honesty: this is a deterministic, in-memory request-handling layer — it
processes request/response _objects_ and stores mod records in memory; it binds
no real HTTP/GraphQL server, database, or transport (those wrap this gateway
downstream). It is the public-API leg of the Forge UGC stack — the surface
external clients reach the mod catalog through.

### @maya/forge-assets

A Rust crate (`libs/maya/forge-assets/src/lib.rs`, ~2,194 lines, tag
`layer:ixchel`; module doc "Maya Forge asset mod pipeline contracts"). It is the
deterministic, **codec-free** planning-and-validation layer for modded textures,
models, animations, audio, fonts/localization, particles/VFX, and materials: it
never decodes or transcodes real bytes, instead emitting plans that
engine-specific importers execute
(`FORGE_ASSETS_SCHEMA_VERSION = "maya.forge.assets.1"`). Within that declared
scope the work is real, not a scaffold. `TextureModLoader` drives a
shelf-packing `AtlasPacker`, `recommend_texture_format` (BC7/BC5/BC4 on desktop,
ASTC on iOS, ETC2 on Android/Web per usage), `generate_mip_chain`, and
`estimate_texture_size_bytes`; `ModelModLoader` derives LODs, collision, and a
`NaniteTessellationPlan`; `AnimationModLoader` handles blend trees,
motion-matching, and retargeting; audio carries `SpatialAudioMetadata` with
`validate_hrtf_compatibility`. `NamespaceRegistry` resolves the highest-priority
mod asset, `AssetDependencyGraph::cascade_invalidations` runs a BFS over
dependents, `AssetStreamingQueue` orders by `StreamingPriority`,
`AssetValidationPipeline` enforces power-of-two / triangle / bone / sample-rate
limits, and `AssetPerformanceBenchmarks` summarizes loading/resolution/hot-swap
latency. Fourteen unit tests assert domain-specific values. It sits beneath the
Forge UGC stack — beside `forge-compositor`/`forge-resolver`/`forge-sandbox` —
giving the Ixchel modding layer one consistent, engine-agnostic asset contract.

### @maya/forge-assist

The AI co-creator for V7 realm builders (`libs/maya/forge-assist/src`). Its
`forge-assist.ts` `ForgeAssistService` takes a creator brief, calls an injected
`@oshun/ai` `LLMProviderInterface` to write a forge artifact (entity script,
behavior, or UI panel against the sandbox API), then runs every artifact through
the `CapabilityPolicy` trust boundary (`capability-policy.ts`) — artifacts that
declare or use non-`realm.*` capabilities are rejected with named violations and
never reach the sandbox. It also supports an optional injected §9.6
`ForgeQualityGate` with critique→rewrite refine passes, and stamps SHA-256
provenance on each proposal. This is the one node that bridges Maya to the
shared LLM gateway; the quality judge is injected (`[~]` for full V7 sandbox
wiring).

### @maya/forge-compositor

A Rust crate (`libs/maya/forge-compositor/src/lib.rs`, ~1,736 lines, tag
`layer:ixchel`) implementing Maya Forge layer composition. It applies Ixchel
layers in a fixed deterministic priority order (`LayerPriority`: Engine →
BaseGame → ContentPack → ServerRealm → CommunityVariant → PersonalOverride) and
records field provenance so realm operators can inspect which layer supplied
each composed value. It also carries the Maya "Loom" world-genome /
runtime-expression schema versions. It is one of 19 Rust forge crates; at ~1,736
lines it is no longer the largest — `forge-core` (~2,440), `forge-narrative`
(~2,349), `forge-assets` (~2,194), `forge-conflict` (~2,005), and
`forge-hot-reload` (~1,925) are all bigger.

### @maya/forge-conflict

A Rust crate (`libs/maya/forge-conflict/src/lib.rs`, ~2,005 lines,
`layer:ixchel`) for semantic, intent-aware conflict detection — modelling layer
changes as composition strategies (`ForgeConflictStrategy`: Additive,
Multiplicative, Minimum, Maximum, Replace, Exclusive) rather than load-order
overrides. It is no longer a scaffold: the module doc now states it "composes
category-specific results across all 12 mod categories, validates composed
outcomes, and persists user/community decisions," with real per-category
resolvers (`compose_rules`, `compose_hooks`, `compose_assets`,
`compose_ui_layout`, `compose_physics_zones`, `compose_behavior_layers`,
`compose_social_features`, `compose_total_conversions`) applying those
strategies. `FORGE_CONFLICT_SCHEMA_VERSION` has advanced to
`maya.forge.conflict.2`.

### @maya/forge-core

A Rust crate (`libs/maya/forge-core/src/lib.rs`, ~2,440 lines, tag
`layer:ixchel`; module doc "Maya Forge core manifest, registry, loader, and
lifecycle primitives") that is the phase-76 foundation every other Ixchel Forge
crate builds on. It defines the strict `ModManifest` (`deny_unknown_fields`)
over the 12-category `ModCategory` taxonomy, the six-tier `ModLayer` stack
(Engine → BaseGame → ContentPack → ServerRealm → CommunityVariant →
PersonalOverride), and an eight-state `ModState` machine whose
`can_transition_to` enumerates every legal edge
(`Downloaded → Validated → Resolved → Loading → Active`, plus
`Suspended`/`HotReloading`/`Error`). Manifests parse from TOML or YAML
(`parse_manifest_with_recovery`), normalise and SHA-256 into a
`canonical_manifest_hash` for content addressing, and ship inside a `.forgemod`
tar+gzip envelope via streaming `write_forgemod_package` /
`read_forgemod_manifest_streaming`. A thread-safe `ModRegistry` (`Arc`/`RwLock`;
id/name/category indexes, `search`) plus a debounced `ModDiscoveryScanner` feed
a `ModLifecycleManager` (enable/disable/suspend/resume/hot-reload).
`compute_load_order` is a genuine Kahn topological sort with deterministic
layer→priority→category tie-breaking and cycle/missing-dependency diagnostics;
`ModValidator::verify_declared_checksums` recomputes SHA-256s. Unlike the
contract-only forge crates, this is the most fully-implemented forge crate
(`unsafe_code = "forbid"`). It honestly carries `SignatureSpec` /
governance/pricing/revenue as manifest data — cryptographic signature
verification lives in downstream scanner/marketplace subsystems.

### @maya/forge-hot-reload

A Rust crate (`libs/maya/forge-hot-reload/src/lib.rs`, ~1,925 lines, tag
`layer:ixchel`, `unsafe_code = "forbid"`) whose own doc-comment calls it "Maya
Forge live mod injection primitives." It is the deterministic coordination layer
for development and realm-operator hot reloads, modelling each reload path as a
typed state machine rather than executing the runtime itself. `ReloadKind`
enumerates the five paths — `Asset`, `WasmModule`, `Rules`, `EcsSystem`, `World`
— each with its own engine: `AssetHotSwapPipeline` swaps indirected
`ResourceHandle`s under a frame-latency budget; `WasmHotReloadRuntime` snapshots
module state and restores it through a type-checked `StateMigrationFramework`,
where `FieldMapping`/`ReflectionSchema` validate every field's `ReflectedType`
before migrating; `RulesHotPatchEngine`, `EcsHotReloadRuntime`, and
`WorldHotEditStreamer` patch balance data, replace systems, and stream
`WorldDelta`s. `MultiplayerHotReloadCoordinator` broadcasts a
`ServerUpdateIntent`, records per-client downloads, and applies only when all
clients are ready within a frame timeout, with `RollbackController` and
`ReloadProgressTracker` covering rollback decisions and a progress UI model.
Honesty: like `@maya/forge-sandbox`, the real WASM runtime is absent —
`estimate_wasm_compile_ms` is a byte-length heuristic (`byte_len/4096 + 1`) and
`validate_wasm_bytes` only checks the `\0asm` magic header. This is
fully-implemented, 14-test coordination logic that deliberately stops at the
engine-execution boundary.

### @maya/forge-resolver

A Rust crate (`libs/maya/forge-resolver/src/lib.rs`, ~1,551 lines,
`layer:ixchel`) for Forge dependency resolution. It establishes the lock-file
and manifest API (`ForgePackageId`, `ForgeDependency`, `ForgeLayerManifest`,
`FORGE_RESOLVER_SCHEMA_VERSION`), and PubGrub-shape version solving is now
implemented, not deferred: the module doc states the resolver "models the
PubGrub shape used by package managers — constraints are accumulated as
dependencies are selected, the highest compatible candidate wins
deterministically," adding capability alternatives, optional feature gates,
platform filtering, lock-file generation, partial re-resolution, and cache
invalidation by registry revision.

### @maya/forge-sandbox

A Rust crate (`libs/maya/forge-sandbox/src/lib.rs`, ~1,583 lines,
`layer:ixchel`) defining the Forge sandbox contract: capability tiers
(`SandboxTier`: DataOnly → Scripted → Extended → System → Native → Trusted),
per-tick resource budgets (`SandboxBudget` with deterministic fuel units, memory
bytes, wall-time micros), and manifest types that upload/scanner/realm-runtime
code can compile against. Binding a concrete Wasmtime runtime is still deferred,
but the crate is now far more than an API/contract layer: it is a deterministic,
dependency-free implementation of hierarchical permission tokens, pre-warmed
instance pooling, module compilation/cache metadata, filtered host-API imports,
resource enforcement with graceful degradation, audit logging, state snapshots,
inter-mod messaging, API-version compatibility, and crash isolation — "so the
rest of the engine can integrate against stable contracts before binding a
concrete Wasmtime runtime."

### @maya/forge-ai

A Rust crate (`libs/maya/forge-ai/src/lib.rs`, ~1,231 lines, tag `layer:ixchel`;
Cargo.toml carries no `description`, so its module doc: "Maya Forge AI behavior
mod layers") that lets Ixchel mods reshape NPC behavior deterministically. It
models seven composition surfaces: additive `BehaviorTreeExtension`s grafted
onto a `BehaviorTree`; explicit priority-ranked `BehaviorReplacement`s resolved
through a `BehaviorOverrideRegistry` (highest priority wins, ties broken by mod
id, losers recorded as `IgnoredReplacement`s and re-pointed in parents/root);
`BigFiveProfile` personality deltas summed then clamped to `0.0..=1.0` by
`PersonalityComposer`; `DialogueStyleMod` prompt-template injection;
`SocialRuleComposer` faction/reputation/hierarchy precedence; `CombatAiMod`
tactical branches; and `DailyRoutineComposer` schedule merging. Every
composition emits provenance — `source_mod_id` per node plus an
`AiModDebugReport` so realm operators see which mod supplied each branch.

Honesty: this is pure, dependency-free (`unsafe_code = "forbid"`) in-memory data
composition with 6 unit tests, schema `maya.forge.ai.1`. It deliberately stops
at the engine boundary — it shapes behavior-tree and dialogue-prompt _data_, but
binds no actual behavior-tree executor or dialogue model.

### @maya/forge-audio

A Rust crate (`libs/maya/forge-audio/src/lib.rs`, ~1,046 lines, tag
`layer:ixchel`, `unsafe_code = "forbid"`; no Cargo description, module doc "Maya
Forge audio mix-bus composition") that models how Ixchel audio mods layer and
resolve. `AudioMixBusAllocator::allocate` hands every audio mod one independent,
deterministically-sorted mix bus (`forge.audio.{mod_id}`) carrying volume, pan,
and a declarative `AudioEffect` chain (EQ/compressor/reverb/delay), and
`AudioVolumeControlSurface` exposes the player-facing per-mod volume/mute rows
with `effective_volume`. Five in-memory registries do priority-aware
composition: `SoundscapeRegistry::active_layers` filters by biome (`*` wildcard)
and `DayPhase`; `MusicPackRegistry`/`SoundEffectRegistry` split a context into
one replacement plus layered additions; `VoicePackRegistry::resolve` does
language fallback and `LipSyncMetadata::validate` checks viseme cue timing;
`AcousticRuleRegistry` and `DynamicMusicRegistry` pick highest-priority room
reverb and tension-driven music transitions with crossfades. Honesty: this is a
pure, dependency-free composition/contract layer (BTreeMap/Vec,
`maya.forge.audio.1`) — no audio is decoded, mixed, or played and effects are
metadata only; the actual DSP/playback binds these resolved descriptors
downstream. Fully implemented, 5 tests, no stubs.

### @maya/forge-code

A Rust crate (`libs/maya/forge-code/src/lib.rs`, ~1,483 lines, tag
`layer:ixchel`, `unsafe_code = "forbid"`; the manifest carries no `description`,
so per its own module doc the "Maya Forge code mod hook system") — the Ixchel
layer that lets user-supplied _code_ mods declare how they splice into the
engine. It defines built-in `HookPoint`s (`EntitySpawn`, `EntityDamage`,
`StateWrite`, …), a `HookPointRegistry`, and a `HookExecutor` that runs
registrations in deterministic priority order with `HookConflictAnalyzer`
flagging overlapping field writes and `HookPerformanceMonitor` throttling hot
hooks. It also models WASM gameplay hooks (`WasmHookBinding`,
`ScriptApiSurface::tier1`), ECS-system mods whose
`EcsSystemModRegistry::execution_order` is a real Kahn topological sort with
cycle detection, shader mods validated against a `GpuCapabilityProfile`,
native-plugin ABI checks (`FORGE_PLUGIN_ABI_MAGIC`), and a small
`ModScriptingDslCompiler`. Honesty: this is contract-and-coordination logic, all
in-memory `BTreeMap`s; no real WASM/shader runtime binds here — the DSL emits
_pseudo_-WASM (`\0asmforge-dsl…`), the shader pipeline returns a
`ShaderCompilePlan` with an FNV-1a `stable_hash` not compiled bytecode, and the
re-exported `forge_hook` proc-macro only validates required keys, leaving
runtime registration explicit. 12 tests.

### @maya/forge-code-macros

A Rust proc-macro crate (`libs/maya/forge-code-macros/src/lib.rs`, ~27 lines,
tag `layer:ixchel`; the `Cargo.toml` has no `description`, so per its module doc
"Procedural macros for Maya Forge code mods") declaring `proc-macro = true` and
exposing a single attribute, `#[forge_hook]`. The macro is a compile-time
guardrail for native Rust hooks in the Forge code-mod registry: it stringifies
the attribute and requires the keys `event`, `priority`, `hook_type`, and
`capabilities`, emitting a `compile_error!` (via the `compile_error` helper)
naming any missing key. Be honest about its thinness — the `[dependencies]`
table is empty, so there is no `syn`/`quote`; validation is a literal
`attr_text.contains(key)` check rather than structural token parsing, and on
success it returns `item` untouched, generating no registration glue because, as
the doc states, "runtime registration is still explicit so engines can attach
deterministic testable metadata." It forbids `unsafe_code` and denies missing
docs. The smallest of the seven Ixchel Forge crates, it gives code-mod authors
an early, testable failure alongside `forge-core` and `forge-sandbox` in Maya's
layered UGC stack.

### @maya/forge-economy

A Rust crate (`libs/maya/forge-economy/src/lib.rs`, ~718 lines, tag
`layer:ixchel`, also `type:ts-lib`; Cargo.toml carries no `description`, so per
its module doc "Maya Forge economy mod simulation" — it "models currencies,
shops, crafting recipes, loot tables, trade rules, resource generation, exploit
detection, and balance reporting for combined economy mods"). An `EconomyModel`
aggregates `CurrencyDefinition`, `ExchangeRate`, `ShopInventoryMod` (whose
`ShopItem::dynamic_price` clamps a supply/demand pressure to 0.25–4.0),
`CraftingRecipe`, `LootTableMod`/`RarityTier`, `TradeSystemMod`, and
`ResourceGenerator`. `EconomyExploitDetector::detect` runs three real algorithms
— O(n²) circular-arbitrage cycle detection, uncapped/infinite-generator
flagging, and cross-merchant buy-low/sell-high `WealthGeneration` — while
`EconomyBalanceReporter::report` computes a genuine Gini wealth-concentration
coefficient and a progression-speed index. Economy is one of Forge's 12 Ixchel
mod categories: when community economy mods stack across layers, this crate
simulates the combined result and flags balance-breaking exploits, sitting
beside `forge-conflict`/`forge-compositor`. Honesty: it is pure, dependency-free
(zero Cargo deps), in-memory analysis over declared definitions — a
simulator/static analyzer, not a live engine economy runtime; `src/index.ts`
(~190 lines) is a narrower parallel TypeScript port covering only the
currency/shop/generator subset.

### @maya/forge-narrative

A Rust crate (`libs/maya/forge-narrative/src/lib.rs`, ~2,349 lines, tag
`layer:ixchel`; Cargo.toml carries no description, so per its module doc "Maya
Forge narrative graph merging") that lets Ixchel mods extend a base game's story
without trampling each other. A `NarrativeBeatGraph` holds typed
`NarrativeNode`s (`NarrativeNodeKind`: StoryEvent, QuestObjective, DialogueNode,
BranchCondition, LoreEntry, Ending); `add_edge` rejects cycles
(`CycleDetected`), `topological_order` is a genuine Kahn sort, with
`reachable_from`/`root_node_ids` helpers.
`NarrativeMergeEngine::merge_additive_branches` folds branch graphs into a base;
`merge_branch_modifications` orders per-node `BranchModification`s by
priority/version and accepts them only when `dialogue_intents_compatible` holds
across the `DialogueIntent` matrix, otherwise emitting an
`LlmNarrativeMergeRequest`. A `LoreLibrary` (contradiction detection),
`CharacterArcTracker` (composed profiles), `EndingVariantRegistry`
(condition-gated endings) and `NarrativeCoherenceValidator` feed a
`CoherenceReport`. Honesty: state is all in-memory `BTreeMap`s with
`encode`/`decode` round-tripping (schema `maya.forge.narrative.1`), no
persistence; the real Maya Souls LLM is a deferred injected seam — the sole
`NarrativeMergeAdvisor` impl, `MayaSoulsMergeAdvisor`, is a deterministic
offline adapter that concatenates candidate texts with `[mod_id]` tags rather
than performing model-driven merges (`unsafe_code = "forbid"`).

### @maya/forge-physics

A Rust crate (`libs/maya/forge-physics/src/lib.rs`, ~1,334 lines, tag
`layer:ixchel`; no Cargo `description`, so quoting its module doc, "Maya Forge
physics zone composition") that lets Ixchel mods author and layer physics
behaviour over a base game. A `PhysicsZone` carries a `PhysicsRuleset` (gravity,
surface friction/elasticity, fluid viscosity, force fields), and a
`PhysicsZoneRegistry` resolves which mod's zone is authoritative at a world
point: a coarse `spatial_index` (`BTreeMap<(i32,i32,i32), BTreeSet<String>>`)
narrows candidates, `compare_zones` orders them by priority so
`resolve_authority` picks one ruleset, and `interpolated_parameters` blends
across boundaries via `distance_to_boundary_inside / transition_distance`. The
math is real: `GravityRule::Planetary` computes inverse-square `(G·mass)/r²`
acceleration alongside `Directional`/`Constant`/`ZeroGravity`, `ForceFieldKind`
samples (Wind/Magnetic/Telekinetic/TemporalDistortion) combine, and
`DimensionPhysicsRegistry` gives isolated dimensions their own base ruleset.
Honesty: this is fully-implemented, std-only, dependency-free deterministic
composition (7 tests, `unsafe_code = "forbid"`, in-memory `BTreeMap` registries)
— but it stops at the authoring boundary, binding no rigid-body integrator or
collision solver; time-stepped simulation is left to a downstream runtime. It is
the physics analogue of `forge-compositor`/`forge-conflict` in the Forge UGC
stack.

### @maya/forge-rules

A Rust crate (`libs/maya/forge-rules/src/lib.rs`, ~1,274 lines, tag
`layer:ixchel`; Cargo.toml has no `description`, so per the module doc it does
"Maya Forge algebraic rules composition") covering the numeric-balance slice of
the Ixchel Forge UGC stack — how rules mods edit gameplay parameters across the
layer stack. A `RulesSchema` of typed `RuleSchemaField`s (hierarchical paths
with `min`/`max` bounds and defaults) bounds-checks every `RuleValue`. Each mod
contributes `RulePatch`es whose `RuleOperation` is
`Set`/`Add`/`Multiply`/`Min`/`Max` or a state-predicated `Conditional`;
`RuleCompositor::compose_path` folds them in canonical algebraic order
(`set < add < multiply < min < max`, via `canonical_order` 0–4) — summing adds,
multiplying products, clamping floors/ceilings, deduping, and recording
per-field `provenance` plus `set_conflicts` — the same deterministic,
provenance-tracked spirit as `forge-compositor`. Around it sit a `RulesParser`,
`CombatFormulaDefinition::evaluate` (real armor-mitigation damage math),
`BalanceTable` diff/merge, `RulesDiffEngine`, a `ReactiveRulesBindingBus`, and
`RulesImpactAnalyzer`. Honest scope: fully implemented, zero-dependency,
`unsafe_code = "forbid"` pure logic — but in-memory only, the parser is a
bespoke YAML/TOML-like mini-format (not full YAML/TOML), and the impact analyzer
is a substring heuristic keyed on `damage`/`health`/`spawn_rate` path names, not
a simulation.

### @maya/forge-sdk

A dual Rust + TS library (tag `layer:forge`, `type:rust-lib` / `type:ts-lib`):
the TS client SDK (`libs/maya/forge-sdk/src/index.ts`, ~555 lines) plus a Rust
mirror (`src/lib.rs`, ~333 lines, "Native SDK planning primitives for Maya Forge
clients"). It is the client SDK for the Forge API gateway (`@maya/forge-api`).
`ForgeSdkClient` (built via `createWebForgeSdk` / `client`) wraps `ForgeMod`
CRUD (`ForgeCreateModInput` / `ForgeUpdateModInput`),
`ForgeListOptions`→`ForgePage` pagination, `ForgeGraphQlQuery` queries, and
`ForgeRealtimeSubscription` streaming (`ForgeSdkStreamRequest` /
`ForgeSdkStreamFrame`) over a pluggable `ForgeSdkTransport` with a
`ForgeSdkRetryPolicy` and a `MemoryWebForgeCache`;
`createUnityWrapperDescriptor` / `createUnrealWrapperDescriptor` describe the
engine-side bindings. Honesty: this is a deterministic SDK shell — only
`InMemoryForgeTransport` ships, so out of the box it talks to an in-memory
Forge; the real HTTP/GraphQL transport is an injected `ForgeSdkTransport` seam,
and the Unity/Unreal wrappers are descriptors, not compiled bindings. It is how
web and engine clients reach the Forge mod catalog — the SDK companion to
`@maya/forge-api`.

### @maya/forge-social

A Rust crate (`libs/maya/forge-social/src/lib.rs`, ~522 lines, tag
`layer:ixchel`; no Cargo `description`, so per its module doc "Maya Forge social
feature composition") modelling the social-feature mod category of the layered
Ixchel Forge UGC stack. It holds in-memory registries — `EmotePackRegistry` plus
a `SocialModRegistry` aggregating `ChatExtension`, `GuildFeatureMod`,
`MiniGameDefinition`, `HousingSystemMod`, and `SocialEventMod` — that reject
duplicate ids with `SocialError::DuplicateFeature`. Its real logic is
`SocialFeatureCompositor::compose`: it unions each feature's `SocialCapability`
set (Emote/Chat/Guild/MiniGame/Housing/Event), sorts `SocialUiHook`s by
descending priority then id, and places them into conflict-free slots
(deterministically suffixing collisions `slot:2`, `slot:3`) as
`ArrangedUiHook`s, while collecting mini-game `state_namespace`s for isolation
into a `SocialCompositionReport`
(`FORGE_SOCIAL_SCHEMA_VERSION = "maya.forge.social.1"`). Honesty:
dependency-free, `unsafe_code = "forbid"`, in-memory only — it arranges social
mods as data and runs no runtime (no emote playback, chat transport, or
mini-game execution); the `EmptyId` error variant is declared but never
constructed, and a partial TypeScript mirror (`index.ts`, ~93 lines)
re-implements `composeSocialFeatures`.

### @maya/forge-total-conversion

A Rust crate (`libs/maya/forge-total-conversion/src/lib.rs`, ~512 lines, tag
`layer:ixchel`, `unsafe_code = "forbid"`). Its `Cargo.toml` carries no
description, so per the `//!` module-doc it is the "Maya Forge total conversion
framework," modelling complete base-game replacement manifests, genre and
setting conversions, mechanical overhauls, standalone game identity, and sub-mod
compatibility layers. A `TotalConversionManifest` pins
`ReplacementScope::complete()` (assets+rules+world+narrative) and validates
optional `GenreConversion` (requires a real `from`→`to` genre swap plus
`gameplay_system_swaps`), `SettingOverhaul`, `MechanicalOverhaul` (whose
`required_engine_capabilities` are checked against a caller-supplied capability
set), and `StandaloneExperience` (must declare identity assets and must not
depend on base-game content). A `SubModCompatibilityLayer` gates the ten
`SubModCategory` kinds by exposed API surface, and `TotalConversionLoader::load`
returns a `TotalConversionLoadReport` partitioning sub-mods into
accepted/rejected. Honesty: this is a pure, std-only, dependency-free
validation/contract crate
(`FORGE_TOTAL_CONVERSION_SCHEMA_VERSION = "maya.forge.total_conversion.1"`) — it
classifies and validates manifests in-memory and never executes a conversion,
swaps assets, or loads runtime code. One of the smaller layered Ixchel Forge
crates, sitting atop `forge-core`'s category taxonomy to give
upload/scanner/realm code a stable target for the most extreme mod category.

### @maya/forge-ui

A Rust crate (`libs/maya/forge-ui/src/lib.rs`, ~980 lines, tag `layer:ixchel`,
`unsafe_code = "forbid"`; Cargo.toml has no `description`, so per its module doc
"Maya Forge UI mod layout composition"). It is the UI-mod tier of the Ixchel UGC
stack, letting community mods reshape the HUD, menus, theme, and accessibility
deterministically. `UISlotRegistry::with_defaults` lays out eight named regions
(`TopBar`…`TooltipArea`, plus `Custom`) on a 1920×1080 canvas;
`UISlotCompositor::compose` groups `UIModClaim`s by slot, orders them by
priority then component id, and resolves multi-claim conflicts into `Tabbed`
(slots that `allows_tabs`) or `Collapsed` placements, emitting a
`UILayoutComposition`. `HudOverlaySystem::route_pointer` picks the topmost
non-passive layer; `MenuRegistry::resolve` does replace/extend/fallback-to-base;
`ThemeCompositor` and `AccessibilityCompositor` layer by priority with
provenance; `InfoDisplayRegistry::allowed_widgets` gates DPS-meter/calculator
widgets by permission subset; `UiHotReloadEngine::apply` relayouts on
`Upsert`/`Remove` without restart. Honesty: its own doc calls it "a
deterministic composition engine rather than a renderer" — it produces layout
data and draws nothing; all stores are in-memory `BTreeMap`s. A parallel
~213-line TS mirror (`index.ts`, tag `type:ts-lib`) re-implements a subset.

### @maya/forge-worlds

A Rust crate (`libs/maya/forge-worlds/src/lib.rs`, ~1,063 lines, tag
`layer:ixchel`, `unsafe_code = "forbid"`; Cargo.toml carries no `description`,
so per its own module doc the "Maya Forge world-mod spatial system"). It is the
spatial dimension of the Ixchel UGC/modding stack — how a world mod declares the
ground it touches and how those declarations compose. `SpatialClaim` pairs a
`WorldModType` and `SpatialIntent` with a `SpatialRegion` (`Aabb`, `ConvexHull`,
`VoxelRegion`), and `SpatialClaimRegistry` buckets claims into a coarse
`GridCell` grid for `query`/`detect_overlaps`. `classify_overlap` and
`SpatialMergeEngine` compose additive claims while flagging replacement/terrain
conflicts; `MapPatchApplicator` validates and applies `SpatialDiff`s, capturing
rollback snapshots; `PointOfInterestRegistry`, `AtmosphereCompositor`,
`NavmeshRegenerator`, and `WorldStreamingQueue` cover POIs, priority-ordered
sky/weather layers, dirty-tile tracking, and mod-priority streaming
(`FORGE_WORLDS_SCHEMA_VERSION = "maya.forge.worlds.1"`). Honesty:
dependency-free, in-memory, deterministic, with 8 unit tests. Non-AABB regions
overlap only via their cached `bounds` (not exact hull/voxel intersection);
`AtmosphereCompositor::compose` is last-wins highest-priority override, not a
per-field blend; the navmesh regenerator only tracks/returns dirty tiles and the
streaming queue only decrements chunk counters — it deliberately stops at the
real engine boundary.

### @maya/instancing

A real TypeScript domain library (`libs/maya/instancing/src/index.ts`, ~2,009
lines; description "Session instancing and player placement core for Maya
Nexus", tags `layer:domain`/`domain:instancing`) — the third sibling of the
Nexus multiplayer-session family, after `@maya/matchmaking` (rating + queue +
allocation) and `@maya/lobbies` (pre-game). It ships two services.
**`InstanceManagementService`** owns the **instance lifecycle**
`active → idle → draining → shutting-down → closed` across four `InstanceType`s
(`persistent`, `temporary`, `social`, `competitive`) and the placement of
players into the right shard: `spawnInstance` (capacity +
region/`InstanceLocation`), `placePlayer` (a `PlacementReason`-tagged
best-instance selector honouring `InstanceCapacity` min/target/max), population
snapshots (`population` → `InstancePopulationSnapshot`), **overflow/underflow
rebalancing** (`splitOverflowInstance` shards a full instance,
`mergeUnderpopulatedInstances` consolidates near-empty ones), **cross-instance
transfers** (`beginTransfer`/`completeTransfer` mint and resolve an
`InstanceTransferTicket` with a typed `InstanceTransferReason`/`-Status`),
graceful drain (`beginGracefulShutdown`), and a `sweepLifecycle` tick that ages
idle instances and reaps closed ones. **`ActivityInstancingService`** layers
matchmade PvE/PvP **activities** on top — `ActivityKind`
(`mission`/`dungeon`/`raid`/ `tournament`) at an `ActivityDifficulty`
(`story`→`mythic`/`competitive`) — driving an activity through
`reserveActivityInstance` → `spawnActivityInstance` → `activateActivity` →
`mutateActivityState`/checkpoint saves → `completeActivity`/`failActivity`, with
`ActivityDifficultyScaling`, `ActivityCheckpointDefinition`/`-Save` progress,
party messaging, friend status, return transfers, and `formMatchmadeActivity`
(an `ActivityMatchmakingEntry` former) plus `ActivityAnalytics`. Like its
siblings both are dependency-free and deterministic — callers pass `nowMs` and
ids, no clock or network of their own — validated by 12 value-asserting spec
cases; it is the tested placement-sharding-and-activity rules engine a real
session-orchestration layer drives, not a server fleet itself.

### @maya/lobbies

A real TypeScript domain library (`libs/maya/lobbies/src`, ~3,050 implementation
lines across three services; description "Lobby and pre-game session core for
Maya Nexus", tags `layer:domain`/`domain:lobbies`) — the deterministic,
in-memory logic core for everything that happens between matchmaking and the
match itself. **`LobbyService`** (`index.ts`, ~1,094 lines) drives the lobby
lifecycle state machine
`Forming → ReadyCheck → Launching → InGame → PostGame → Disbanded`
(`transitionLifecycle` validates each edge) and owns the full pre-game surface:
`createLobby`/`joinLobby` with separate player and spectator caps, time-boxed
invites (`createInvite`/`expireInvites` honour `inviteTtlMs` and mint deep-links
off `deepLinkBaseUrl`), a bounded chat ring with per-viewer mute
(`postChatMessage`/`visibleChatFor`/`setMute`, capped at `maxChatMessages`),
ready-check (`setReady`/`readiness` → `LobbyLaunchReadiness`),
disconnect/reconnect with a `reconnectGraceMs` window
(`disconnectParticipant`/`reconnectParticipant`/`expireDisconnected`), and team
assignment that is either manual (`assignTeam`) or `autoBalanceTeams`.
**`SessionDiscoveryService`** (`discovery.ts`, ~620 lines) is the server
browser: `upsertSession`/`removeSession` emit sequenced `SessionRealtimeUpdate`s
drained by `realtimeUpdatesSince`, `listSessions`/`paginateSessions` filter and
sort by `ping`/`player-count`/`age`/`friend-presence`, plus favorites with
notifications, join history with `quickRejoin`, `friendActivity`, `quickJoin`,
and profile-weighted `recommendSessions`. **`CustomGameService`**
(`custom-game.ts`, ~1,336 lines) covers private/custom matches —
`registerMap`/`registerMutator`, `selectMap`/`mapRecommendations`, saved rule
presets and published templates, scheduling with `scheduled`/`starting-soon`
notifications, spectator controls and views, a replay policy with
`private`/`friends`/`public` share modes, and analytics snapshots with popular
configurations. All three are dependency-free and deterministic (no clock or
network of their own — callers pass `now` ISO strings and IDs), validated by 25
value-asserting spec cases (`index` 10, `custom-game` 8, `discovery` 7); they
are the tested rules engine a real transport/persistence layer wraps, not a
networking stack themselves.

### @maya/loom-biomes

A Rust crate (`libs/maya/loom-biomes/src/lib.rs`, ~795 lines, tag `layer:loom`;
Cargo.toml carries no `description`, so per its module-doc the "Maya Loom custom
biome system" that "models player-authored biomes with climate constraints,
deterministic terrain/flora/fauna/resource/structure planning, atmosphere
identity, smooth biome transitions, and conflict-aware biome composition"). A
`CustomBiome` (with `source_mod_id`/`priority`) is constrained by
`BiomeConditions` of fixed-point `FixedRange` axes
(temperature/humidity/altitude plus custom axes like magic_saturation).
`evaluate_biome` scores a `WorldSample` with a Whittaker-style 45/45/10
weighting plus priority boost; `plan_terrain`, `place_flora`, `spawn_fauna`
(predator-prey and humidity limits), `distribute_resources` (balance-tier
density caps), and `place_structures` emit deterministic plans driven by an
internal SplitMix64-style `DeterministicRng` seeded from `seed ^ stable_hash`
(FNV-1a). `blend_transition` does boundary-distance weighting; `compose_biomes`
resolves overlapping mod biomes via
`BiomeCompositionStrategy::{Priority, Blend}`. `validate_biome` enforces
ecological plausibility (`BiomeError::Implausible`). Within Maya Forge UGC, this
is Loom's world-genome authoring layer feeding the Ixchel composition stack.

### @maya/loom-core

A Rust crate (`libs/maya/loom-core/src/lib.rs`, ~1,509 lines, tag `layer:loom`,
`unsafe_code = "forbid"`; Cargo has no `description`, so its module doc names it
the "Maya Loom world genome core"). It is the procedural world-DNA subsystem of
the Forge UGC/metaverse stack: a `WorldGenome` aggregates `PhysicsConstants`,
`TerrainGenome`/`NoiseParameters`/`ErosionRule`, `ClimateGenome`/`WindSystem`,
`EcologyGenome`/`BiomeDistributionRule`, `CivilizationGenome`, and
`DimensionDefinition`s as fixed-point `i64` fields (`FIXED_SCALE = 1_000`) under
schema `maya.loom.core.1`. A lightweight `parse_world_genome` reads TOML-like
`key = value` / YAML-like `key: value` lines via `set_genome_field`;
`serialize_canonical` + `hash_genome` give content-addressable identity;
`generate_world`/`generate_chunk` expand a genome deterministically through a
seeded RNG into world summaries and chunk height samples. `compose_genomes`
blends two genomes by basis points like genetics, with `apply_genome_overlay`
and `diff_genomes` alongside, and a `GenomeRegistry` backs marketplace
upload/download/browse. Honesty: dependency-free and deterministic, but the
registry is an in-memory `BTreeMap` (no persistence); `hash_genome` is FNV-1a
(`stable_hash`), not cryptographic; the RNG is SplitMix64; previews are
synthesized `maya://genomes/{hash}/preview.png` URLs; and outputs are scalar
fixed-point summaries — the heavy world build stays in the engine.

### @maya/loom-dimensions

A Rust crate (`libs/maya/loom-dimensions/src/lib.rs`, ~721 lines, tag
`layer:loom`; `Cargo.toml` carries no `description`, so its own module doc:
"Maya Loom custom dimension system"). It is the world-genome layer that lets
independently authored mods declare parallel dimensions with isolated physics,
generation, visual style, gameplay, portals, inventory-transfer policy, and
discovery gates. A `DimensionDef` aggregates `DimensionPhysics`,
`DimensionGeneration`, `DimensionVisualStyle`, and `DimensionGameplay` plus
`PortalDef`s and a `DiscoveryRule`; `validate_dimension` range-checks the
basis-point fields (no floats — everything is fixed-point/`bps`). The logic is
real and deterministic: `generate_dimension_chunk` seeds a SplitMix64
`DeterministicRng` from an FNV-1a `stable_hash` of the dimension id and chunk
coordinates to pick a material and roll structure inclusion;
`evaluate_gameplay`, `transition_portal` (item/level/governance/cooldown gates),
`transfer_inventory` (`InventoryPolicy::All/None/Filtered/Transform`), and
`is_dimension_discovered` enforce per-dimension rules; `compose_dimensions`
merges mods and rejects portal-location collisions so independently authored
worlds can coexist. Honesty: dependency-free (empty `[dependencies]`,
`unsafe_code = "forbid"`), pure functions with no persistence — it emits typed
definitions and deterministic content rolls, not a runtime. Actual terrain
meshing, physics, and rendering live downstream in the engine; chunk
"generation" here is a seeded palette/structure selection, not voxel synthesis.

### @maya/loom-evolution

A Rust crate (`libs/maya/loom-evolution/src/lib.rs`, ~1,354 lines, tag
`layer:loom`; module doc "Maya Loom world evolution and living world
simulation"). It advances persistent world state over time through six change
drivers — geological, ecological, civilizational, seasonal, player-driven, and
catastrophic — and records major events for player-facing timelines.
`RegionState` is the unit of simulation; `GeologicalConfig`, `EcologyConfig`
(with per-`SpeciesState` populations and `SoulDirective`s), and
`CivilizationConfig` parameterise the drivers, while `SettlementState`,
`TradeRoute`, `CivilConflict`, and `Alliance` model the civilizational layer —
settlements grow, trade, war, and ally. All rates are fixed-point against
`BPS_SCALE = 10_000` (basis points) so evolution is deterministic and replayable
rather than floating-point-divergent, and `EvolutionError` makes invalid
transitions fail loud. It is the "living world" engine of the Loom world-genome
subsystem: where `loom-core`'s genome defines a world's DNA, this crate runs
that world forward.

### @maya/loom-multiverse

A Rust crate (`libs/maya/loom-multiverse/src/lib.rs`, ~709 lines, tag
`layer:loom`; module doc "Maya Loom connected multiverse core"). It models
worlds and dimensions as a **portal graph**: `MultiverseNode`s (typed by
`NodeKind`, with `PortalVisibility` and `AccessControl`) connected by
`PortalEdge`s into a `MultiverseTopology`, with `PlayerAccess` gating who may
traverse and `PortalTransition` describing a crossing. On top of the graph it
carries cross-world player identity (`CharacterIdentity` with an `IdentityMode`
choosing how much of a character persists between worlds), `InventoryItem`
transfer, marketplace exchange, multiverse governance, and player-facing
world-catalog data. `MultiverseError` makes illegal traversals or transfers fail
loud. It is the inter-world connective tissue of the Loom subsystem — letting
the persistent worlds that `loom-core` / `loom-evolution` define link into one
navigable multiverse. A 1:1 TypeScript mirror lives at `src/index.ts` (~280
lines, 9 exported functions — `createTopology`, `canAccessPortal`,
`resolveIdentity`, `transferInventory`, …), hence the dual `type:rust-lib` /
`type:ts-lib` tags.

### @maya/variants-compat

A Rust crate (`libs/maya/variants-compat/src/lib.rs`, ~582 lines, tags
`scope:maya` + `layer:variants`; the Cargo manifest has no `description`, so
quoting its `//!` doc: "Maya cross-variant compatibility analysis"). It is the
game-variant subsystem of the Maya Forge: given a `BTreeMap` of `VariantNode`s
(each carrying `rules`, `features`, `cosmetics`, `structures`, and a
`parent_id`), `compute_variant_differences` yields a typed `VariantDifference`
list and `classify_compatibility` maps it to a `CompatibilityClass` — any
`Structural` diff is `Incompatible`, any `Gameplay` diff `CheckRules`, otherwise
`Compatible`. From there it negotiates a `SharedRuleset` (keep identical params,
omit divergent ones), renders a `CompatibilityUiModel` with a player-facing
`primary_action`, walks `parent_id` chains for the `closest_common_ancestor`,
and models playlists, mid-game switch impact, per-variant achievements, and
sorted leaderboards. Honestly scoped: zero dependencies, pure-std
`BTreeMap`/`BTreeSet`, `unsafe_code = "forbid"`, deterministic — real diff/LCA
algorithms, not a contract scaffold, but operating purely over in-memory inputs
with no persistence (achievements/leaderboards are `Vec` operations;
`save_file_id` is just a formatted string). A 1:1 TypeScript mirror lives at
`src/index.ts` (~288 lines), hence the dual `type:rust-lib`/`type:ts-lib` tags.

### @maya/variants-core

A Rust crate (`libs/maya/variants-core/src/lib.rs`, ~678 lines incl. tests, tag
`layer:variants`; no Cargo description, module doc "Maya game variant system
core") that models git-like game variants — refs, metadata, object-level diffs,
fork trees, version history, and upstream tracking. It is dependency-free (pure
`std` `BTreeMap`/`BTreeSet`/`VecDeque`, `unsafe_code = "forbid"`). A
`VariantRef` carries `parent_lineage` and a `ForkPoint`; `GameObjectChange`
enumerates `Add`/`Remove`/`Modify`/`Relocate`/`Replace`; `VariantCommit`s chain
by `parent_commit_id`. The in-memory `VariantRepository` (node map plus
tag/author indexes) drives `create_root`, `fork_variant`, `commit_variant`,
`tag_latest`, `create_release_branch`, `track_upstream`, `record_merge`, and a
BFS `traverse_subtree`; `divergence_report` genuinely computes
upstream/local-ahead counts via `saturating_sub`. Be honest about scope: this is
the data-model and bookkeeping layer, not the algorithms — the caller supplies
each `VariantDiff` (nothing is actually diffed), `record_merge` only logs a
`MergeRecord` rather than performing a three-way object merge,
`CompatibilityInfo` is stored not validated, and `commit_id` is a plain
`id@version` string, not forge-core's SHA-256 content hash. The store is
in-memory only (no persistence bound despite the "persistence-backed querying"
doc; no serde). It gives Maya Forge's fork-and-remix UGC culture its
lineage/provenance backbone, complementing forge-core's layer/manifest model.

### @maya/variants-diff

A Rust crate (`libs/maya/variants-diff/src/lib.rs`, ~908 lines, tag
`layer:variants`, `unsafe_code = "forbid"`; no Cargo description, so per its
`//!` doc the "Maya semantic game-object diffing engine"). It computes
change-sets between two game-variant states across the five `GameObjectKind`s —
Entity, Spatial, Rule, Narrative, Asset. `diff_game_objects` keys objects by
`StableObjectId` into `BTreeMap`s and classifies each edit into a typed
`GameObjectChange` (Add/Remove/Modify/Relocate/Replace); `diff_properties` walks
`PropertyValue` trees including nested `Map` paths; `diff_spatial_by_region`
buckets changes per `SpatialRegion`; `diff_rules`, `diff_narrative`, and
`diff_assets` (content-hash plus a `format_compatible` flag) cover balance,
branch graphs, and asset swaps. `serialize_compact`, `human_summary`, and
`build_visualization` emit a one-line wire format, a counts string, and a
sectioned `DiffVisualization` for UGC review UIs. Honesty: this is real,
dependency-free std-only code with 4 unit tests — but purely the
diff/serialize/visualize half. Despite the "variants management" framing there
is no merge or apply path, no serde, and no persistence;
`VARIANTS_DIFF_SCHEMA_VERSION` sits at `maya.variants.diff.1`. It feeds Maya
Forge's Ixchel layer pipeline by turning community-variant edits into
inspectable change-sets.

### @maya/variants-merge

A Rust crate (`libs/maya/variants-merge/src/lib.rs`, ~572 lines, tag
`layer:variants`, `unsafe_code = "forbid"`; no Cargo `description`, so its `//!`
doc calls it the "Maya three-way game merge engine") for semantic diff/merge of
game-variant trees in the Forge UGC stack. `three_way_merge` walks the union of
object/property keys across a `base`, `variant_a`, and `variant_b` `GameState`
(`BTreeMap`-keyed `GameObjectState`s) and applies real three-way logic —
agreeing edits and one-sided changes auto-merge into `auto_merged_changes`,
while same-property divergence becomes a `MergeConflict` carrying base/A/B
values. Each conflict yields a `ConflictResolutionView` with manual options
(`ResolutionSource::VariantA/VariantB/Base`) and an AI suggestion;
`apply_resolution` resolves and prunes them. `cherry_pick`, `validate_merge`,
and `create_merge_commit` add selective application, regression aggregation, and
provenance-stamped merge commits
(`VARIANTS_MERGE_SCHEMA_VERSION = "maya.variants.merge.1"`). Honesty: state is
in-memory only (no persistence); `suggest_resolution` is not a model — it is a
deterministic keyword/numeric heuristic (`hardcore`/`difficulty` → higher value,
`accessibility`/`casual` → lower) with hardcoded confidences; and
`validate_merge` aggregates supplied `TestSuiteResult`s rather than running any
game tests.

### @maya/variants-registry

A TS library (`libs/maya/variants-registry/src/index.ts`, ~352 lines;
`package.json` has no `description` field and the source carries no module-doc,
so this is described from its symbols) — the discovery and social layer for Maya
Forge game variants. It exports eight pure, dependency-free functions over
caller-supplied arrays. `exploreForkTree` walks `parentId` links into a
`ForkTreeNodeView` sorted by popularity then recency; `searchVariants` applies
faceted filters (tags, `minReviewScore`, `compatibilityGroup`) then a weighted
token-relevance score (name ×5, tags ×3, description ×2, changelog ×1);
`recommendVariants` is real collaborative filtering over `PlayPattern` overlaps
(`overlap / sqrt(len)` plus a popularity nudge); `summarizeRatings` weights each
`VariantReview` by play-time (`1 + sqrt(playMinutes)/60`); `matchmakePlayers`
groups players onto compatible `ServerListing`s by
region/`compatibilityGroup`/ping; `rankCuratedVariants`,
`createCuratedCollection`, and `activityFeed` round it out. Honesty: the
formulas are genuine, but the lib is wholly in-memory and stateless — no
persistence, no async, no I/O. It is a variant-metadata/discovery surface, NOT a
semantic object-tree diff/merge engine; `compatibilityGroup` tagging is its only
"compat" notion. It sits player-facing above the Ixchel layer-composition forge
crates.

### @maya/bazaar-core

A TS library (`libs/maya/bazaar-core/src/index.ts`, ~464 lines, tag
`layer:bazaar`; `package.json` has no `description` and the file carries no
module-doc, so this is read from its symbols) implementing the
listings/discovery slice of the Maya Forge UGC bazaar. It is a pure, stateless
function module — no classes, no persistence, no HTTP, no in-memory store:
callers pass arrays of `ModListing`/`ModReview` plus a subscriptions record, and
every exported function returns fresh data. `validateModPackage` enforces
semver, asset hash/byte-size integrity and screenshot warnings;
`publishModPackage` mints a `ModListing`; `discoverMods` runs token relevance
scoring (`modRelevance`) with category/tag faceting and pagination;
`resolveCollection` does DFS dependency ordering that throws on cycles;
`summarizeReviews` weights ratings by reviewer credibility and playtime while
filtering spam; `createDownloadSession` selects a regional CDN endpoint with
resumable byte offsets. Its `ModManifest` echoes `forge-core`'s manifest but is
a separate, looser TS shape (`category` is a free `string`, no
`deny_unknown_fields`). Honestly scoped: despite "bazaar" implying economy,
there is no revenue-split, licensing, or creator-treasury code here — only
listings, discovery, reviews, downloads, reporting, and per-platform packaging.

### @maya/bazaar-licensing

A TS library (`libs/maya/bazaar-licensing/src/index.ts`, ~524 lines;
package.json has no `description` field and the source carries no module
doc-comment, so this summary is read from its exported symbols) — the
machine-readable licensing law for Maya's Bazaar UGC marketplace. `LicenseType`
defines six tiers (OpenForge, ShareAlikeForge, CommercialForge, PersonalForge,
ExclusiveForge, Custom), each minted by
`createStandardLicense`/`buildCustomLicense` into a `MachineReadableLicense` of
typed permissions, restrictions, obligations, and `RevenueRequirement`s. The
real work is compatibility: `checkPairwiseCompatibility`,
`checkLicenseCompatibility`, and `scanLicenseViolations` walk a mod's dependency
graph and emit coded `LicenseIssue`s (`no-derivatives`, `non-commercial`,
`share-alike-required`, `revenue-share-required`…); `enforceLicenseInheritance`
propagates parent terms onto derivatives, auto-coercing a child to
ShareAlikeForge when required. It sits upstream of `@maya/forge-resolver` and
the marketplace economy, governing how creators may fork, sell, and depend on
each other's mods. Honesty: pure, stateless functions — no persistence, no
registry beyond the per-call `Map` built from inputs, and no treasury or payment
runtime. `RevenueRequirement` (`bps`/`fixedCents`/`recipientId`) is policy data
only; no money moves here, and `legalLanguage` is template-generated, not vetted
legal text. Real deterministic policy logic with a spec, not a stub — actual
revenue-split/creator-treasury execution lives in deferred downstream
subsystems.

### @maya/bazaar-revenue

A TS library (`libs/maya/bazaar-revenue/src/index.ts`, ~836 lines, tag
`layer:bazaar`; no `package.json` description or module-doc, so the role is read
from the symbols) implementing the Bazaar UGC marketplace economy for Maya
Forge. It models seven pricing modes (`PricingModelKind`: Free, PayWhatYouWant,
FixedPrice, Subscription, Patronage, AdSupported, TipJar) and a basis-point
`RevenueSplit` that `validateRevenueSplit` forces to total 10000
(`DEFAULT_REVENUE_SPLIT` = 1000/7000/1500/500 across
platform/creator/dependency/treasury). The core is `calculateRevenueChain`:
`collectDependencyClaims` walks the mod dependency graph with depth-decayed
weights, circular-chain detection, and missing-dependency warnings, then
`allocateByWeight` apportions cents by largest-remainder so the splits sum
exactly. Around it sit attribution graphs, ledger and dashboard rollups
(earnings by mod, dependency chain, and period), tip intents, crowdfunding
pledges with refund policy, and `processPayouts` (gated on an enabled payment
method plus verified tax docs). Honest scope: these are pure in-memory functions
over readonly data — no DB, no real payment rails (payouts emit `'queued'`
records), and signature checks delegate to a caller-injected
`AttributionVerifier`. This is genuine apportionment logic, not a stub; it
realises the pricing/revenue data `@maya/forge-core` carries but defers to
"downstream marketplace subsystems."

### @maya/bazaar-treasury

A TS library (`libs/maya/bazaar-treasury/src/index.ts`, ~666 lines, tag
`layer:bazaar`; `package.json` carries no `description` and the file has no
module-doc, so this summary is drawn from its exported symbols) modelling a
community-governed treasury for the Maya Forge UGC bazaar. It is a
pure-functional, dependency-free kernel: every operation takes a
`CommunityTreasury` and returns a new immutable one. `fundTreasury` records
ledger credits from four `TreasuryFundingSource`s (`mod_sales`, donations,
`community_asset_revenue`, grants), applying a real basis-points revenue split
(`Math.round(grossCents * allocationBps / 10000)`). Spending flows through
weighted governance — `createSpendingProposal` → `castTreasuryVote` →
`finalizeSpendingProposal` tallies quorum against an approval threshold — then
an N-of-M `MultiSigRequest` above a cent threshold, and
`executeSpendingProposal` debits only against `availableCents`. It also runs
mod/bug-bounty lifecycles and tournament prize pools (`allocatePrizePool` does
real largest-remainder apportionment by rank). `buildTreasuryDashboard` folds
the ledger into balance/encumbered/income-by-source/expense-by-category.
Honesty: in-memory only — no persistence, no payment rails, and multi-sig
`signature` is an unverified string, not a real cryptographic check; this is the
economic accounting/governance logic a service must persist and wire to real
money and identity.

### @maya/agora-constitution

A Rust crate (`libs/maya/agora-constitution/src/lib.rs`, ~1,071 lines, tag
`layer:agora`; `Cargo.toml` carries no `description`, so per its module doc the
"Maya Agora machine-readable constitution framework"). It is the
constitutional-constraint layer of Maya's Agora governance subsystem. A
`GameConstitution` binds `inalienable_rights` (`Right`: `DataPortability`,
`CreatorAttribution`, `SafeEnvironment`, …), amendment-only `protected_params`,
an `AmendmentProcess` (supermajority basis points, extended voting, grace
period), time-limited `EmergencyPower`s, and an `EconomicConstitution`
(treasury/revenue/tax basis points). `validate` checks the schema;
`enforce_action` rejects any `GovernanceAction` that overrides a right or
mutates a protected parameter without a qualifying amendment;
`authorize_emergency_power` role- and time-scopes exploit responses;
`apply_amendment` bumps the version and appends a `diff_constitutions` history
entry. Four `constitution_template`s (DirectDemocracy → Anarchy) ship ready-made
charters.

Honesty: dependency-free pure-`std` (`BTreeMap`/`BTreeSet`),
`unsafe_code = "forbid"`, five unit tests. It is _not_ on-chain and _not_ the
vote tallier — vote share arrives pre-computed as `yes_basis_points`; no
liquid-democracy delegation, sybil resistance, or persistence lives here. The
"YAML/TOML" reader is a hand-rolled flat `key:`/`key =` line scanner, not a real
grammar. A sanctioned sibling TS port (`index.ts`, `type:ts-lib`) re-declares
the same types for orchestration.

### @maya/agora-core

A Rust crate (`libs/maya/agora-core/src/lib.rs`, ~580 lines, tag `layer:agora`,
`unsafe_code = "forbid"`). Cargo.toml has no description, so its module doc:
"Maya Agora governance core" defining "the tier hierarchy, governance
configuration merging, Themis bridge metadata, event sourcing, permission
checks, and analytics for game-community governance." A five-level
`GovernanceTier` chain (`Global → Game → Realm → Server → GuildParty`) drives
`GovernanceContextResolver::resolve`, composing per-tier `GovernanceConfig`s
through `merge_restrictive` — a child tier may tighten but never widen authority
(voting-model intersection, max quorum, min voting period, ANDed delegation).
`VotingModel` enumerates
Quadratic/RankedChoice/TokenWeighted/Approval/Optimistic; `GovernanceEventStore`
event-sources the proposal lifecycle (`GovernanceEventKind`), while
`GovernancePermissionSystem` and `GovernanceAnalytics` gate by reputation plus
role and compute participation/success rates. Honesty: this is a small,
zero-dependency foundation layer for Maya Forge governance, not a live chain.
`ThemisBridgeBinding` only names `@themis/voting`/`dao`/`deliberation` packages
— metadata, not an invoked integration; the store is in-memory `Vec`/`BTreeSet`;
constitutions and delegate registrations are opaque ID sets (no delegation-graph
or sybil logic); per-model tallying lives downstream. A parallel TypeScript
mirror (`src/index.ts`) ports the same shapes for orchestration callers.

### @maya/agora-councils

A Rust crate (`libs/maya/agora-councils/src/lib.rs`, ~594 lines, tag
`layer:agora`; Cargo carries no `description`, so per its module doc the "Maya
Agora council and delegate election system") modelling the council tier of Maya
Forge's Agora governance for UGC realms. It is dependency-free std-only with
`unsafe_code = "forbid"`: a `CouncilRegistry` of `BTreeMap`s holds
`CouncilDefinition`s, time-bounded `CouncilMember`s, and topic-scoped
`DomainDelegate`s (`DomainScope`: CombatBalance, Narrative, Economy, Content,
Security), while `run_ranked_choice_election` is a genuine multi-seat
instant-runoff elimination with deterministic lowest-name tie-breaking.
`OptimisticProposal::challenge`/`finalize` implement challenge-window optimistic
approval; `trigger_recall` fires on a sub-threshold approval plus a ≥0.1
petition ratio; `dashboard` aggregates public votes, participation, and average
approval for realm transparency. State is schema-pinned at
`maya.agora.councils.1`. Honesty: this is in-memory only — no persistence, DB,
or actual on-chain layer; `approval_score` is a stored field (default 1.0), not
a computed reputation, and `generate_meeting_summary` is a `format!` vote-count
template with two hard-coded action items, not real summarisation. It scopes to
councils/delegates — constitutions, liquid-democracy delegation graphs, and
sybil resistance would live in sibling Agora crates. A parallel TypeScript
mirror (`src/index.ts`) re-declares the same types (`type:rust-lib` +
`type:ts-lib`).

### @maya/agora-delegation

A Rust crate (`libs/maya/agora-delegation/src/lib.rs`, ~624 lines, tag
`layer:agora`, `unsafe_code = "forbid"`; Cargo.toml carries no `description`, so
its `//!` doc names it "Maya Agora liquid democracy delegation"). It implements
the delegation slice of Maya's Agora governance subsystem: a `DelegationManager`
over in-memory `BTreeMap`/`BTreeSet` stores routes topic-scoped voting power
(`TopicScope`: Combat, Economy, Content, Governance, Treasury, Any) from
delegators to delegates. `register_delegation` rejects self-delegation and runs
`cycle_path_with_edge`, which simulates the new edge, walks the graph, and
returns the offending `CycleDetected` path; `effective_power` sums power by
resolving each voter's final delegate under a `max_depth` cap (transitive liquid
democracy with an `Any`-topic fallback). `begin_vote_snapshot` freezes
delegations so `revoke_delegation` is instant going forward while
`effective_power_for_vote` preserves an open ballot. `dashboard` reports public
votes, chains, participation rate, and satisfaction; `trigger_recalls` files
`RecallElection`s below threshold. Six tests assert exact power, cycle paths,
and recalls.

Honesty: despite the "on-chain-style" framing, this is a pure, dependency-free,
deterministic in-memory model — no ledger, persistence, networking, signatures,
or sybil resistance, and no constitutions/councils/proposal-lifecycle here. A
parallel TypeScript port (`src/index.ts`, ~340 lines, immutable
`DelegationRegistry`) mirrors the same logic for orchestration callers.

### @maya/agora-proposals

A Rust crate (`libs/maya/agora-proposals/src/lib.rs`, ~932 lines, tag
`layer:agora`, `unsafe_code = "forbid"`; Cargo.toml carries no `description`, so
per its `//!` doc a "Maya Agora proposal lifecycle manager" that "models
proposal creation, quality gates, review, voting, grace, enactment, rollback,
structured proposal payloads, and search"). It is the governance backbone for
Maya Forge UGC. A `ProposalLifecycleManager` drives a nine-state `ProposalState`
machine (Draft → Review → Voting → GracePeriod → Enacted/Rejected/Challenged →
RolledBack) over eight `ProposalType`s (balance, content adoption, rule change,
mod endorsement, constitution amendment, emergency, treasury, election).
`submit_for_review` enforces a deposit-or-reputation anti-spam gate;
`QualityGateReport::passes` blocks voting on failing mod tests, >10% perf
regression, or security issues; `close_voting` folds quorum and yes>no into a
`ClosingCeremonyReport`; `open_emergency_voting` fast-tracks
security-board-approved actions; `rollback_if_degraded` reverts on
`RuntimeMetrics` thresholds. Honesty: all state lives in an in-memory `BTreeMap`
— no persistence or actual chain; "sybil resistance" is a plain
deposit/reputation numeric gate, and liquid-democracy delegation and councils
are not implemented here. A parallel TS façade (`src/index.ts`, ~184 lines)
mirrors the model for orchestration-side use.

### @maya/agora-sybil

A Rust crate (`libs/maya/agora-sybil/src/lib.rs`, ~611 lines, tag `layer:agora`,
`unsafe_code = "forbid"`). Cargo.toml carries no description, so per its module
doc: "Maya Agora sybil resistance and vote integrity" — "deterministic models
for proof-of-play weighting, reputation staking, privacy-preserving identity
proofs, MACI-style encrypted vote commitments, quadratic funding, brigading
detection, and vote anomaly detection." It is the integrity layer beneath Agora,
the Forge's on-chain-style governance subsystem: `proof_of_play_score` weights
active, diverse play over AFK time; `ReputationStakeLedger` slashes stakes on
rolled-back proposals; `MaciRound` hides votes until close then reveals by
`vote_commitment`; `allocate_quadratic_funding` matches broad community support
over whales; and `detect_brigading`/`detect_vote_anomalies` flag new-account
influx, vote bursts, and uniform-choice clusters. Honesty: it is dependency-free
and fully in-memory (`BTreeMap` ledgers and rounds), with no persistence, and
the "encryption"/ZK is modelled, not real — `encrypt_vote`/`vote_commitment`
format a non-cryptographic FNV-1a `stable_hash`, and
`identity_weight_multiplier` merely trusts the `kyc_verified`/`zk_proof_valid`
booleans. A parallel TypeScript port (`src/index.ts`, ~313 lines, tag
`type:ts-lib`) mirrors every function. All seven algorithms ship with passing
tests.

### @maya/agora-voting

A Rust crate (`libs/maya/agora-voting/src/lib.rs`, ~733 lines incl. tests, tag
`layer:agora`, `unsafe_code = "forbid"`; Cargo.toml carries no `description`, so
per its `//!` doc: "Maya Agora voting model adapters … dependency-light adapters
for common Themis-style voting models used by game-community governance"). It
implements eleven real tally algorithms behind one `VoteOutcome` type and a
`VotingModel` enum: quadratic (enforcing the N² credit cost), conviction (tokens
× committed days), instant-runoff ranked choice, Condorcet pairwise-majority,
token-weighted with optional `sqrt` damping, approval, holographic-consensus
(stake + small quorum), optimistic (timeout unless challenged), futarchy (goal
gate then highest belief market), supermajority (yes-ratio + quorum), and a
`LiquidDemocracyAdapter::resolve_delegate` that walks delegation chains with
cycle and depth-limit detection. `VotingModelSelector` maps
`ProposalType`×`GovernanceTier` to a recommended model — the governance math for
realm/guild/global councils in the Maya Forge UGC stack. Honesty: these are pure
deterministic functions over caller-supplied ballots — no persistence, no
chain/ledger, no constitution/council storage, no sybil resistance, no
proposal-lifecycle state (despite the "on-chain-style" framing).
`[dependencies]` is empty;
`AGORA_VOTING_SCHEMA_VERSION = "maya.agora.voting.1"`. A thin parallel
`src/index.ts` (~89 lines) mirrors a subset (quadratic, supermajority,
recommend); the project is dual-tagged `type:rust-lib`/`type:ts-lib`.

### @maya/future-input

A TypeScript library (`libs/maya/future-input/src`, ~31 files, ~21K lines) for
next-generation input modalities. The two clusters are brain-computer interface
(`bci-*`: device abstraction, calibration, focus/attention detection, emotional
and meditation-state detection, game input mapping, privacy controls,
accessibility, multiplayer, research data export, Neuralink preparation) and
advanced haptics (force-feedback gloves, full-body exoskeleton,
electrical-muscle stimulation, audio transducers, design/recording tools).
`bci-focus-attention-detection.ts` operates on real EEG-style feature vectors
(beta/alpha and theta/beta ratios, engagement index, gamma share) to classify
attention states — real signal logic.

### @maya/games

The largest TypeScript library in the area (`libs/maya/games/src`, ~109 files,
~123K lines) — the gameplay-systems toolkit. It is organised into ~18
subsystems: `abilities`, `classes`, `combat`, `companions`, `crafting`,
`equipment`, `gathering`, `hathor`, `inventory`, `items`, `loot`, `mmo`,
`party`, `progression`, `quests`, `skills`, `stats`, `survival`. The combat
module alone holds melee/ranged/projectile, blocking-parrying, combo chains,
status effects, cover, dodge-roll, AI combat behavior, and a
`damage-calculation-system.ts` with real armor/resistance mitigation,
penetration, and outcome-multiplier formulae that compose `CharacterStatBlock`
and `ResolvedWeaponInstance` — concrete game logic, not CRUD.

### @maya/genesis-flora

A TypeScript readiness-evaluator library
(`libs/maya/genesis-flora/src/index.ts`, ~376 lines) for procedural vegetation.
It exports rich config types (tree-generation, biome distribution with Poisson
sampling and clustering, ecology with competition/succession/seasonal-growth,
render/export with SpeedTree/Nanite handoff) and a single
`evaluateMayaGenesisFloraLandscape` function that scores coverage ratios and
emits blocking/warning issues. It evaluates _readiness_ of a flora pipeline
rather than running L-system growth itself (that lives in `genesis-neural-flora`
and the Rust `maya-genesis-flora` crate).

### @maya/genesis-nca

A substantial TS library (`libs/maya/genesis-nca/src/index.ts`, ~5.6K lines)
implementing **neural cellular automata** for exotic-biome and living-terrain
texture generation. It actually trains and runs the automata:
`trainMayaNcaExoticBiomeRule` learns per-channel
growth/decay/diffusion/anisotropy rules from exemplars,
`growMayaNcaExoticBiomeTexture` evolves the grid, and there are morphogenesis,
vegetation-pattern, biome-boundary, Whittaker-biome classification,
painted-texture training, and a WebGPU compute-integration planner. Real
generative algorithms with diagnostics (loss curves, distinctiveness scores),
not a facade.

### @maya/genesis-neural-flora

A TS library (`libs/maya/genesis-neural-flora/src/index.ts`, ~2.2K lines) for
transformer-guided procedural vegetation. `createMayaNeuralLSystemGrowthModel`
runs an attention-weighted L-system whose production rules respond to a real
environment vector (soil quality, light direction, wind exposure, neighbor
density); additional functions cover LiDAR species-model training, single-image
plant reconstruction, growth animation, a classical-vs-neural benchmark, and
growth-style transfer. Concrete grammar-expansion logic over typed
`MayaNeuralLSystemToken` streams.

### @maya/genesis-physarum

A TS library (`libs/maya/genesis-physarum/src/index.ts`, ~1.5K lines)
implementing **Physarum (slime-mould) network growth** for organic
infrastructure. `createMayaPhysarumRoadNetwork` does terrain-aware pathfinding
between settlements (`findTerrainAwarePath`) then selects a Physarum-weighted
minimum spanning tree, accumulating trail intensity per cell; sibling functions
generate trade-route, tunnel, river-enhancement, and utility networks plus a
morphology controller and a comparison benchmark. Real graph/pathfinding math
over slope and water-penalty terrain grids.

### @maya/genesis-scene-agent

A TS library (`libs/maya/genesis-scene-agent/src/index.ts`, ~1.5K lines) for
agentic, natural-language world creation. It defines a procedural scene-program
IR (`place_terrain` / `place_building` / `scatter_flora` calls with
absolute/relative/between position expressions) and
`executeMayaProceduralSceneProgram` resolves references and corrects spatial
overlaps deterministically. It also provides a tool catalog + selector,
incremental world editing, multi-agent parallel generation, and an
audit-trail/decision-explanation layer for the generation agent — real
planner/interpreter logic.

### @maya/genesis-sketch

A TS library (`libs/maya/genesis-sketch/src/index.ts`, ~2.1K lines) for
sketch-to-terrain authoring. It maps stroke styles to terrain operations
(`createMayaRidgeLineSketchTerrain`, valley/canyon, river-path, cliff-face,
coastline, crater/caldera), supports multi-stroke composition, an undo/redo
stack (`applyMayaSketchTerrainUndoRedo`), and a feature-eraser. Concrete
heightfield-from-strokes algorithms with a style-preset library, not a scaffold.

### @maya/genesis-terrain

A TS readiness-evaluator library (`libs/maya/genesis-terrain/src/index.ts`, ~346
lines) for procedural terrain. It models heightfield, climate/biome (Whittaker
biomes, microclimate, seasonal variation), erosion/hydrology (hydraulic/thermal,
river networks, sediment transport), streaming/LOD, and material/export config,
and `evaluateMayaGenesisTerrainEnvironment` scores coverage and emits typed
issues (determinism-missing, coverage-low, generation/memory budget exceeded).
Like `genesis-flora`/`-urban` it evaluates pipeline readiness; the heavy terrain
runtime is the Rust `maya-genesis-terrain` crate.

### @maya/genesis-tiling

A substantial TS library (`libs/maya/genesis-tiling/src/index.ts`, ~3.7K lines)
implementing aperiodic/Wang tiling for anti-repetition content. It generates
Wang terrain-chunk plans, aperiodic monotile surface patterns, stochastic
terrain texture synthesis, Wang dungeon-room layouts, aperiodic city-block
placement, and stochastic vegetation scatter, plus an anti-repetition quality
report and a technique-comparison. Real tiling/constraint algorithms with
measured repetition quality.

### @maya/genesis-urban

A TS readiness-evaluator library (`libs/maya/genesis-urban/src/index.ts`, ~346
lines, mirroring `genesis-terrain`'s shape) for procedural urban generation. It
exports the urban config types and a single
`evaluateMayaGenesisUrbanEnvironment` that scores coverage and emits blocking /
warning issues. The full urban-generation runtime lives in the Rust
`maya-genesis-urban` crate (the largest genesis crate); this TS library
evaluates the pipeline's readiness.

### maya-inspirations

A large TS library (`libs/maya/inspirations/src`, ~74 files) — an
aesthetic/reference-library system (project name `maya-inspirations`, tag
`type:lib`). It holds named real-world and fictional reference sets (Blade
Runner, Coruscant, BioShock, Dark Souls, Deus Ex, Elder Scrolls, Dubai-futurism,
African urban patterns, biome photography, crystal/cave landscapes) plus
cross-cutting tools: `color-palette-extraction.ts` (harmony modes, color roles),
mood-board integration, a Yemaya inspiration-import system, atmosphere-preset
sharing, and cross-domain aesthetic mapping. Real palette/reference modelling
that feeds the generation libraries.

### @maya/moderation

A TS trust-and-safety library (`libs/maya/moderation/src`, ~31 files; package
description "Content moderation and trust safety planning for Maya"). It covers
hate-speech detection (`hate-speech-detection.ts` with coded-hate /
dehumanization / protected-class categories and an allow/reject/review decision
with evidence sourcing), harassment-pattern and ban-evasion detection, CSAM
detection/reporting, copyright-infringement detection, image/audio/model content
classification, age verification, GDPR/COPPA tooling, appeals workflow,
graduated-response and human-moderator tools, and a moderation dashboard/queue.
Real classification and policy logic.

### @maya/neural-capture

A TS planning library (`libs/maya/neural-capture/src/index.ts`, ~5K lines;
description "Advanced neural capture systems for 4D Gaussian splatting,
volumetric video, and AI motion capture"). Its `create…Plan` functions compute
deterministic 4DGS pipelines from real inputs —
`createMaya4DgsTrainingFromMultiViewVideoPlan` derives synchronized frame
counts, densified Gaussian counts, memory budgets, and a convergence score from
calibration/motion-blur quality; siblings plan temporal deformation fields,
high-FPS rendering, compression, relighting, editing, and quality metrics. Real
estimation math (a planner, not the GPU runtime).

### @maya/nexus-live-voting

A Rust crate (`libs/maya/nexus-live-voting/src/lib.rs`, ~680 lines, tag
`layer:nexus`; module doc "Maya Nexus live-session mod voting core") with a
parallel TS surface (dual `type:rust-lib` / `type:ts-lib`, `surface:ui`). It
models how players vote, mid-session, on changing the active mod set of a live
multiplayer realm: a `LiveModAction` proposal opens a vote within a bounded
window (`MIN_VOTE_WINDOW_MS` 30s … `MAX_VOTE_WINDOW_MS` 120s), `VoteRecord`s are
weighted and tallied against a configurable `ThresholdRule` (via `VotingConfig`,
basis points against `BPS_SCALE = 10_000`), and a passing proposal advances
through `ProposalStatus` into trial activation, a confirmation vote, and
rollback-on-failure with cooldown enforcement. `ConflictAnalysis` /
`ConflictRisk` gate proposals that would clash with active mods, and
`LiveVotingError` fails loud on out-of-window or invalid votes. Honesty:
deterministic, in-memory governance logic (3 unit tests) — it tallies and
sequences the vote but binds no real-time transport or activation runtime (those
plug in downstream, alongside `nexus-mod-sync`). It is the live-session
companion to the Agora subsystem's longer-form proposal flow.

### @maya/nexus-mod-sync

A Rust crate (`libs/maya/nexus-mod-sync/src/lib.rs`, ~1,140 lines, tag
`layer:nexus`; module doc "Maya Nexus multiplayer mod synchronization core"). It
models how a server and its clients reconcile mod sets when joining a
multiplayer realm: a `ServerModManifest` vs `ClientModManifest`
`ManifestExchange` produces a `ManifestDiff` of missing / extra /
`VersionMismatch` mods, each classified by `ModRequirement` (required vs
client-optional via `ModTag`), from which a `DownloadPlan` of `DownloadJob`s is
ordered across `DownloadSource`s with `DownloadProgress` tracking. It also
covers activation ordering, synchronized hot-reload, validation, delta
compression, schema negotiation, graceful degradation, and connection-timeout
handling, with `GovernanceConfig` gating what a server may require and
`ModSyncError` failing loud on incompatibilities. Honesty: this is
deterministic, in-memory protocol/coordination logic with 6 unit tests — it
plans and orders the exchange but binds no real network transport, file
downloader, or hot-reload runtime (those plug in downstream, as with the sibling
`forge-hot-reload`). It is the first crate of the new Nexus multiplayer-mod
layer, complementing the Forge authoring stack and the Bazaar marketplace.

### @maya/physics

A small TS "facade" library (`libs/maya/physics/src/index.ts`, ~340 lines;
description "TypeScript facade for Maya physics simulation readiness across
cloth, fluid, destruction, and particles"). It exports physics-readiness config
types and `evaluateMayaPhysicsSimulation`, which scores simulation coverage and
emits typed issues. The actual physics-backend abstraction (Havok/PhysX/Jolt) is
the Rust `maya-physics` crate inside `maya-engine-core`; this library evaluates
readiness rather than stepping a solver.

### @maya/renderer-advanced

A very large TS planning library (`libs/maya/renderer-advanced/src/index.ts`,
~20K lines; description "Next-generation Maya rendering techniques including
MegaLights and advanced GPU rendering"). It computes deterministic plans for
MegaLights (light-source importance sampling, fixed-ray-count-per-pixel,
area-light soft shadows, directional mega-lights, stochastic direct lighting,
adaptive noise reduction) and GPU-driven rendering (Nanite voxel geometry,
foliage voxelization, instance culling, persistent buffer management,
million-instance rendering). Real GPU-budget heuristics, complementary to the
core `renderer`.

### @maya/renderer

A very large TS "facade" library (`libs/maya/renderer/src/index.ts`, ~22K lines;
description "TypeScript facade for Maya renderer GI, virtualized geometry, and
neural rendering readiness", with two author-facing tuning guides under
`renderer/docs`). It plans neural rendering pipelines:
`designMayaNeuralRadianceCacheArchitecture` estimates MLP parameter counts,
memory budgets, and training/inference cost from scene complexity; further
functions cover NRC warmup/memory/serialization, multi-resolution NRC,
Lumen-class GI integration, a temporal ML denoiser (training, ONNX runtime, TAA/
TSR integration, hot-swap), and neural-material/texture compression. Concrete
performance-model math.

### @maya/scene

A small TS "facade" library (`libs/maya/scene/src/index.ts`, ~258 lines;
description "TypeScript facade for Maya virtual set scene graph, asset loading,
and state persistence readiness"). It exports scene-readiness types and
`evaluateMayaSceneVirtualSet`, scoring scene-graph / asset-loading / persistence
coverage and emitting issues. It is the readiness companion to the Rust
`maya-scene` crate in the engine core.

### @maya/sentinel-core

A Rust crate (`libs/maya/sentinel-core/src/lib.rs`, ~690 lines, tag
`layer:sentinel`; module doc "Maya Sentinel mod safety and moderation core")
with a TS mirror (dual `type:rust-lib` / `type:ts-lib`). It is the moderation
control-plane for user-submitted mods: `run_scan_pipeline` runs ordered
`ScanStage`s under a `ScanPipelineConfig` (each stage carrying a
`FailurePolicy`), collects `ScanFinding`s by `FindingSeverity` into
`StageScanResult`s, and reduces them to a `ScanDecision` persisted as a
`ScanAuditRecord` in a `ScanResultStore`. On top of scanning it models
moderation escalation, elected-moderator powers, DAO appeal resolution,
content-warning filtering, and safe-space policy validation. Honesty:
deterministic, in-memory coordination logic (4 unit tests) — it orchestrates and
records the moderation decision but delegates the actual code/content analysis
to the scanner stages (`sentinel-scanner`) and binds no persistence backend. It
is the policy/audit half of the new Sentinel safety subsystem.

### @maya/sentinel-ip

A Rust crate (`libs/maya/sentinel-ip/src/lib.rs`, ~887 lines, tag
`layer:sentinel`) with a TS mirror (dual `type:rust-lib` / `type:ts-lib`);
module doc "IP and copyright protection integration for Maya mod submissions."
It is the IP/copyright leg of the Sentinel mod-safety subsystem and the bridge
from Maya mods to the Themis Originality Shield. `fingerprint_asset` derives a
deterministic `AssetFingerprint` per `ModAsset` (by `AssetKind`), and calibrated
similarity scoring matches those against `ReferenceWork`s into `IpMatch`es that
reduce to an `IpDecision`. `build_themis_bridge_requests` packages flagged
assets into `ThemisBridgeRequest`s (under a `ThemisBridgeConfig`) for the
cross-domain Themis shield to adjudicate, and the crate validates provenance /
`LicenseKind` and maps derivative works. Honesty: deterministic, in-memory
fingerprint/scoring/bridge-request logic (4 unit tests) — it computes the
fingerprints and the bridge payloads but does not itself run the heavy
neural-similarity detectors; those live behind the Themis shield it bridges to
(the same injected-seam boundary the `@themis/universal-*` libs document). It
adds the originality/IP dimension to Sentinel's `sentinel-core` /
`sentinel-scanner` safety/security stack.

### @maya/sentinel-provenance

A Rust crate (`libs/maya/sentinel-provenance/src/lib.rs`, ~780 lines, tag
`layer:sentinel`) with a TS mirror (dual `type:rust-lib` / `type:ts-lib`,
`surface:ui`); module doc "Provenance and attribution verification for Maya mod
packages." It is the provenance/attribution leg of the Sentinel mod-safety
subsystem: it registers creator identities (`CreatorRegistration` from a
`CreatorRegistrationInput`, with a `KycStatus` and a `CreatorKeyPair`), binds a
`ModPackageManifest` to its creator through a `ModSignature`, classifies tamper
findings by `TamperSeverity`, reduces them to a `VerificationStatus`, and builds
an `AttributionChain` (`AttributionNode`s + `AttributionEdge`s) tracing a mod's
derivation lineage. Honesty: this is a deterministic, dependency-free
(`unsafe_code = "forbid"`) provenance _data model_ with 5 unit tests — the
signatures and keys are modelled as opaque handles (`public_key: String`,
`private_key_handle: String`), not real cryptographic operations; actual signing
and KYC bind to a key-management / identity provider downstream. It complements
`sentinel-ip` (originality) and `sentinel-core` / `sentinel-scanner` (safety)
with the who-made-this provenance dimension.

### @maya/sentinel-scanner

A Rust crate (`libs/maya/sentinel-scanner/src/lib.rs`, ~1,587 lines, tag
`layer:sentinel`; module doc "Automated security scanning stages for submitted
Maya mods") that implements the analysis stages `sentinel-core` orchestrates.
Each `ScannerStage` is independent and composes into a `ScannerReport` of
`ScannerFinding`s graded by `FindingSeverity` with a final `ScannerDecision`:
`analyze_static_code` runs `StaticPattern` rules (from
`default_static_analysis_config`) over `ModSourceFile`s by `SourceKind`, joined
by sandbox-behaviour monitoring, network-policy checks, resource profiling,
anti-cheat heuristics, and package-signature verification. Honesty: this is
real, deterministic pattern/heuristic analysis (5 unit tests) over mod-source
and declared-behaviour _descriptors_ — it does not execute mods in a live
sandbox or capture real network traffic; it scores the static/declared signals
and leaves dynamic execution to downstream engine integration (mirroring
`forge-sandbox`'s deferred Wasmtime runtime). It is the analysis half of the
Sentinel safety subsystem.

### @maya/server

The Maya authoritative-server library (`libs/maya/server/src`, ~31 services).
Files are real backend services: `matchmaking-service.ts` implements ELO skill
matching with a concrete formula (`K_FACTOR = 32`, `ELO_BASE = 400`,
`expectedScore`/rating updates and match-quality estimation); alongside it are
achievement, analytics, anti-cheat, asset-storage, authentication, economy
(service + transactions), inventory, leaderboard, notification, payment,
player-connection, session, social-graph, world-simulation-loop, zone-handoff,
clustering, hot-reload, metrics, service-mesh, and the game-server application.
Real service logic.

### @maya/spatial-ar

A large TS planning library (`libs/maya/spatial-ar/src/index.ts`, ~18K lines;
description "Persistent spatial AR content anchoring for Maya AR cloud
workflows"). It plans world-scale spatial maps, visual-positioning systems,
large-geospatial-model and Niantic spatial localization, cross-device AR content
persistence (visionOS / Android-XR / iOS-AR / WebXR), AR cloud storage and
real-time sync, content discovery/permissions, colocated multiplayer AR, hand/
eye/gesture controls, passthrough optimization, and real-world occlusion. Typed
readiness/plan structures with tracking-state and persistence-backend models.

### @maya/standards

A very large TS interoperability library (`libs/maya/standards/src/index.ts`,
~25K lines; description "Metaverse interoperability standards and OpenUSD
compliance planning for Maya"). It plans OpenUSD import/export and composition,
USD geospatial/international-character/IoT-streaming extensions, glTF + OMI-glTF
extension compliance, USD↔glTF bidirectional conversion, material-translation
and animation-interoperability, physics/audio schema compliance,
behavior-scripting portability, asset-provenance metadata, MSF certification,
and avatar formats (VRM, Ready Player Me, MSF avatar standard, cross-platform
portability, feature-mapping, clothing-portability, animation-retargeting).
Concrete format/compliance modelling with real extension catalogs.

### @maya/testing

A TS test-infrastructure library (`libs/maya/testing/src`, ~46 files) for the
Maya domain, split into `integration-testing/`, `unit-testing/`, and
`visual-testing/`. It provides an integration-test framework plus suites
(authentication-flow, client-server, cross-platform, database, e2e-scenario,
economy-transaction, multiplayer, world-streaming, VR-device,
chaos-engineering), a `MayaLoadTester` with weighted-scenario selection and
p50/p95/p99 reporting, and unit-test helpers (AI, audio, API-contract,
data-structure, coverage reporting). Real harness/runner logic.

### @maya/tooling

A TS developer-tooling library (`libs/maya/tooling/src`, ~46 files) in three
groups: `asset-tools/` (asset converter CLI, comparison, dependency analyzer,
migration, size reporter, validation, audio processing, batch processing,
collision/navmesh/LOD/lightmap generation, mesh optimization, texture
compression), `profiling/` (AI/audio debuggers, breakpoint system, console
logging, crash-dump analysis), and `world-editor/`. `mesh-optimization-tools.ts`
models Quadric/Decimate simplification with concrete mesh stats/analysis
(degenerate faces, non-manifold, UV overlap) and optimization results — real
pipeline logic.

### @maya/vr-studio-web

A TS library (`libs/maya/vr-studio-web/src/index.ts`, ~424 lines; description
"WebXR preview bridge contracts for the Maya immersive VR production studio").
It plans the browser/WebXR side of the studio: `createMayaVrWebXrSessionPlan`,
scene-sync, interaction-parity (WebXR vs native), a WebGPU render-path plan, a
spectator-review plan, and the preview-bridge that connects the web preview to
the native `vr-studio`. Capability-contract / plan structures.

### @maya/vr-studio

A large TS library (`libs/maya/vr-studio/src/index.ts`, ~28K lines; description
"Immersive VR production studio runtime planning and capability contracts for
Maya"). It plans the native VR studio runtime: OpenXR runtime + session
lifecycle, reference spaces, swapchains, view/projection, controller/hand/eye
input, foveated rendering, mixed reality, spatial anchors, haptics, composition
layers, capability + performance overlays, comfort settings, and a full
spatial-panel / workspace-layout UI system (placement, lifecycle, adaptive
rendering, interaction, text rendering, panel communication). Typed VR-readiness
plans with `MayaVrIssue` diagnostics.

### @maya/world

A small TS "facade" library (`libs/maya/world/src/index.ts`, ~415 lines;
description "TypeScript facade for Maya world weather, time-of-day, and
atmospheric simulation readiness"). It exports world-environment config types
and `evaluateMayaWorldVirtualEnvironment`, scoring
weather/time-of-day/atmosphere coverage and emitting issues. It is the readiness
companion to the Rust `maya-world` (chunk streaming) and `maya-atmosphere`
crates in the engine core.

### @maya/forge-compat

A dual Rust+TypeScript crate (tags `type:rust-lib`, `type:ts-lib`,
`layer:forge`) for backward-compatibility management of published Maya Forge
mods across game versions — the Rust module doc reads "Backward compatibility
management for Maya Forge mods," and `package.json` (`0.1.0`) carries no
description. Unusually for the maya area, this is _not_ a TS plan over a Rust
engine: `libs/maya/forge-compat/src/lib.rs` (270 lines incl. tests) and
`libs/maya/forge-compat/src/index.ts` (157 lines) are parallel mirror
implementations of the same API, both real and both tested. Around shared types
— `PublishedMod`, `GameVersion`
(`availableApis`/`deprecatedApis`/`removedApis`), `CompatibilityStatus`
(`pass`/`degraded`/`fail`) — six pure functions do the work:
`buildCompatibilityMatrix` set-diffs each mod's `apiCalls` against a version to
grade every row; `deprecationWarnings` surfaces
replacement/`migrationGuide`/`sunsetVersion`; `buildCompatibilityShims` maps
`removedApis`; `pinGameVersion` mints a `simultaneousLoaderSlot`;
`detectBreakingChanges` flags impacted mods/authors; `migrateModSource` rewrites
a mod's `wasmSource`. Honesty: deterministic and dependency-free, but
`migrateModSource` is naive substring replacement (not semantic WASM rewriting),
`buildCompatibilityShims` stamps a constant `"next-major"` lifetime, and there
is no registry or persistence — these are pure functions over caller-supplied
data. Three Rust `#[test]`s and five Vitest cases assert specific computed
values.

### @maya/forge-cross-platform

A dual Rust+TypeScript library (tags `scope:maya`, `layer:forge`,
`type:rust-lib`, `type:ts-lib`) whose two surfaces —
`libs/maya/forge-cross-platform/src/lib.rs` (393 lines incl. tests,
`unsafe_code = "forbid"`, zero dependencies) and
`libs/maya/forge-cross-platform/src/index.ts` (271 lines) — are line-for-line
parallel ports of the same logic, not one FFI facade over the other. Neither
`Cargo.toml` nor `package.json` carries a `description`, so the Rust module doc
names it: "Cross-platform mod packaging and execution planning for Maya Forge."
Within the Ixchel Forge UGC stack (beside `@maya/forge-core`'s
`ModManifest`/registry) it answers "will this mod run, and how does it package,
across the nine `PlatformKind` targets" —
`pc`/`playstation`/`xbox`/`switch`/`ios`/`android`/`vr`/`web`/`cloud`.

This is real, deterministic policy logic, not a scaffold: `profilePlatform` maps
each target to a `CapabilityProfile` (GPU features, `cpuArch` of
`x86_64`/`aarch64`/`wasm32`, OS capabilities); `packageForPlatform` derives a
`PackageVariant` with texture-compression selection (`astc`/`basisu`/`bc7`),
per-platform texture/LOD clamps and a 44.1 kHz audio cap; `enforceMobileBudget`
(512 MB / 1024 px / 25k-poly ceilings), `curateConsoleMod`,
`validateVrRequirements` (11 ms budget), `planWebWasmExecution` and
`planCloudHosting` emit typed `compatible`/`requiresOptimization`/`blocked`
verdicts that `validateCrossPlatform` folds into a `CompatibilityMatrix`. Both
surfaces carry matching tests (3 Rust `#[cfg(test)]` cases; a 91-line
`index.spec.ts` over the same `mod.weather` asset). Honesty: budgets, GPU lists
and cloud regions (`iad`/`sfo`/`fra`) are hardcoded heuristics and outputs are
plans/reports — actual cooking, signing and certification stay downstream in the
engine and platform toolchains.

### @maya/forge-studio-core

A dual Rust + TypeScript crate (tags `scope:maya`, `layer:ixchel`,
`type:rust-lib`, `type:ts-lib`; neither `Cargo.toml` nor `package.json` carries
a `description`) — the creator-studio core of the Maya Forge UGC layer, where a
creator assembles a mod from generative-domain outputs and exports a
`forge-mod-package` for `@maya/forge-core` to load. Both surfaces share schema
`maya.forge.studio.core.1` and are dependency-free and deterministic
(`unsafe_code = "forbid"`). The **Rust** `src/lib.rs` (~1,113 lines, with unit
tests) is the authoritative stateful editor: a `StudioWorkspace` of
`BTreeMap`-keyed `StudioAsset`s (each with revision `history`) driven by a
`WorkspaceCommand` (`AddAsset`/`RemoveAsset`/`UpdateAsset`) command pattern with
real `undo_stack`/`redo_stack`
(`apply_workspace_command`/`undo_last`/`redo_last`) and
`save_workspace`/`load_workspace` snapshot round-trips. The **TypeScript**
`src/index.ts` (~682 lines) mirrors the same pure pipeline —
`convertDomainAsset` (`aja`/`isis`/`euterpe`/`aphrodite` → maya formats),
`validateAssets` against `defaultQualityBudget` (64 MiB / 75k polys / 4096px /
10k particles / 0.98 anim score) into severity-tagged `QualityFinding`s,
`aggregateCreationAnalytics`, `packageForgeModExport` — and adds a layer Rust
lacks: `buildStudioSurface` composes an `assetRail`/`inspector`/`commandBar`
view-model via `classifyReadiness`. Honesty:
`planLivePreview`/`planCollaborationSession`/`planDeviceSetup` return typed
_plans_ (viewport ids, literal `workspace-crdt` channels, role permissions), not
live engine/WebRTC/device runtimes; `optimizeSize` is a fixed 0.82/0.95
heuristic. A real pipeline and state model — the engine and IO stay downstream.

### @maya/forge-studio-world

A dual crate (tags `scope:maya`, `layer:ixchel`, `type:rust-lib` +
`type:ts-lib`): a Rust surface `libs/maya/forge-studio-world/src/lib.rs` (~994
lines, with the in-crate `#[cfg(test)]` suite) and an independent TypeScript
port `libs/maya/forge-studio-world/src/index.ts` (~646 lines), both implementing
one spec, `FORGE_STUDIO_WORLD_SCHEMA_VERSION = 'maya.forge.studio.world.1'`.
They are full, parallel implementations — neither a thin facade over the other;
both carry tests (the Rust `lib.rs` plus a 137-line TypeScript `index.spec.ts`
of 5 value-asserting cases). package.json has no description and neither file
opens with a module doc, so the schema constant names it. Under the forge-studio
creator suite in the Ixchel UGC layer, this is the world-building workbench that
turns a loom-style `WorldGenomeParams` (terrainType/biome/featureDensity/seed)
plus manual edits into a validated, exportable map.

The terrain core is genuine deterministic logic:
`sculptTerrain`/`sculpt_terrain` runs a radial-falloff brush (`hypot` distance,
neighbor-average smoothing, 7 `TerrainTool`s) with before/after snapshots and
`undoTerrain`; `generateProceduralTerrain` seeds per-cell heights via a
`stableHash` (Murmur-style finalizer / SplitMix64 mix) keyed by `TerrainType`
amplitude and `biomeBias`; `validateMap` weighs texture-memory and draw-call
estimates against `MapBudgets`, and `validateSpawnFairness` flags >15%
objective-distance variance — asserted by 5 domain tests. The remaining surfaces
— `generateNavigationMesh`, `buildDungeon`, `designLightingAtmosphere`,
`launchPlaytest` — are typed plan/readiness contracts, not runtimes: they emit
preset or hardcoded fields (`pathLengthM: 33`,
`aiAgentFindings: ['no-unreachable-critical-paths']`, `unreachableAreas: 0`)
that reference but never run crucible agents or an actual navmesh bake.

### @maya/forge-studio-cinema

A dual-language Ixchel crate (tags `scope:maya`, `layer:ixchel`,
`type:rust-lib`, `type:ts-lib`) pairing a Rust surface
(`libs/maya/forge-studio-cinema/src/lib.rs`, ~692 lines incl. 5 `#[cfg(test)]`
cases, `unsafe_code = "forbid"`) with a near-identical TypeScript mirror
(`libs/maya/forge-studio-cinema/src/index.ts`, 435 lines). Neither `Cargo.toml`
nor `package.json` carries a description; both pin schema
`maya.forge.studio.cinema.1`. It is the in-engine cinematic-authoring tool of
the forge-studio creator suite — a "solo film studio" for timelines, camera
paths, character direction, mocap, lighting, transitions, and subtitles.

Honestly, the two surfaces are independent ports of the _same_ logic; Rust is
canonical (default `build`/`test`/`typecheck` targets, TS gets the `:ts`
variants). About half the API is canned exemplar emitters — `plan_camera_path`,
`direct_characters`, and `generate_subtitle_track` return fixed keyframes,
hero/villain beats, and hardcoded subtitle text, and `generated_by_iris: true`
is an unenforced flag, not an Iris call. The other half is real deterministic
logic: `create_timeline` derives
`playback_drift_ms = (duration_ms/300_000).min(1.0)` and FNV-1a (`0x811c9dc5`)
clip IDs, `mocap_to_cinematic_workflow` is input-driven, and
`validate_cinematic`/`build_cinema_workbench` run genuine threshold predicates
(jitter ≤0.5, lip-sync ≤50 ms) that accumulate issues and gate a
`Ready`/`NeedsReview`/`Blocked` workbench. A plan-and-validate harness, not a
runtime cinematic engine.

### @maya/forge-studio-vfx

A dual Rust + TypeScript crate (tags `scope:maya`, `layer:ixchel`,
`type:rust-lib`, `type:ts-lib`; `package.json` has no `description`) that is the
visual-effects authoring slice of the Ixchel creator studio. The Rust surface
(`libs/maya/forge-studio-vfx/src/lib.rs`, ~633 lines plus a five-test suite —
the primary `cargo build`/`test` target) and the TypeScript mirror
(`libs/maya/forge-studio-vfx/src/index.ts`, 452 lines) are parallel
reimplementations of the same deterministic logic under schema
`maya.forge.studio.vfx.1`; neither bridges the other via FFI/WASM. Both expose
the VFX workbench: `createParticleEffect` (clamps spawn rate to `[16, 12_000]`),
`vfxPresetLibrary` (23 curated + 1 bazaar preset over six `PresetCategory`s),
`createShaderGraph`/`compileShaderGraph`, `designPostProcess`,
`createVolumetricEffect`, `attachEffect` (maps `TriggerEvent`s to `forge-code:*`
hooks), `planLodBudget` (four `QualityTier`s, first-fit under budget),
`validateVfxBudget`, and `buildVfxWorkbench` (a `ready`/`needs-review`/`blocked`
verdict).

Honesty: this is a typed planning facade, not a running VFX engine. The genuine
logic is budget summation, memory-bound checks, LOD ratio planning, structural
shader-graph validation, and FNV-1a `stableId` content addressing; outputs are
`ParticleEffectPlan`/`ShaderGraphPlan`/`VfxBudgetValidationReport` structures.
There is no simulation or shader compilation — `wgsl`/`glsl` are template
literals, `compileShaderGraph` is substring validation, and each `gpuTimeMs` is
a formula estimate (`min(1.95, maxParticles / 25_000 + 0.35)`), not measured.
Real execution stays in the downstream engine.

### @maya/forge-studio-mocap

A dual crate (tags `scope:maya`, `layer:ixchel`, `type:rust-lib` +
`type:ts-lib`; `package.json` carries no `description`) modelling the
creator-studio motion-capture workflow under schema `maya.forge.studio.mocap.1`.
The Rust surface (`libs/maya/forge-studio-mocap/src/lib.rs`, ~550 lines incl.
tests) and the TypeScript surface (`libs/maya/forge-studio-mocap/src/index.ts`,
344 lines) are near-identical parallel mirrors — neither is the "real engine"
behind a thin shim — both exporting
`CaptureChannel`/`PerformancePosture`/`EnhancementKind`, the
`CaptureSessionInput → CaptureSessionPlan` planner, `buildPerformanceClip`,
`retargetAndCleanup`, `blendClips`/`compositeClips`, `planChoreography`,
`referenceMotionLibrary`, and `enhanceMotion`. Rust additionally carries a
stateful `MotionLibrary` (`BTreeMap`-backed `save_clip`/`search`) plus six unit
tests asserting domain thresholds; TS adds the `buildMocapCockpit` aggregator
with `classifyReadiness`.

Honesty: this is a typed planning/readiness facade, not a capture runtime —
there is no pose estimation, retarget solver, or motion-blend engine. The
genuine computation is metric aggregation and evaluation: `planCaptureSession`
averages joint error, maxes FACS/finger error, and derives calibration steps
from flags; `planChoreography` computes real beat-alignment error
(min-over-beats, then max-over-keyframes); `classifyReadiness` applies
`ready`/`needs-calibration`/`blocked` thresholds. The remainder are hardcoded
contract values — `mayaBoneCount: 67`, `faceActionUnits: 52`, the `0.75`
phone-depth gain, `jointPopsAfterCleanup` always 0 (`saturating_sub` of itself),
`loopSeamMs: 16` — with synthesized `forge-mod/animations/*.maya-anim` export
paths and a typed-only `enhanceMotion`. It supplies the mocap cockpit for the
forge-studio creator layer atop Ixchel UGC.

### @maya/forge-studio-music

A dual Rust+TypeScript crate (`scope:maya`, `layer:ixchel`, tags
`type:rust-lib`+`type:ts-lib`) — the music vertical of the Forge creator studio.
Neither `package.json` nor `Cargo.toml` carries a description; both surfaces
share schema `maya.forge.studio.music.1`.
`libs/maya/forge-studio-music/src/lib.rs` (~636 lines, `unsafe_code = "forbid"`,
~130 of them an inline `#[cfg(test)]` suite) and
`libs/maya/forge-studio-music/src/index.ts` (350 lines) are parallel ports —
identical types and thresholds in snake_case vs camelCase, not one facade over
the other.

It covers MIDI composition (`create_composition`), hum-to-melody capture
(`captureHumToMelody`), AI generation (`generateAiMusic`), interactive
game-music state machines (`designAdaptiveMusic` over a `MusicState` from
`exploration` to `boss-phase-3`), a `SoundDesignWorkspace`,
`designSpatialAudio`, and rights (`manageMusicRights` with
`LicenseTag`/Themis-scan/provenance). Honesty: the generators are hardcoded
typed plans — `captureHumToMelody` ignores audio and emits `60 + index % 5`
pitches at a fixed `pitchAccuracyPct: 93.5`; `generateAiMusic` echoes the prompt
but returns a constant `D minor`/140 bpm/`themisOriginalityScore: 0.94`. The
validators are real and input-driven: `validateMidi` is a genuine O(n²)
same-lane (channel+pitch) overlap plus velocity-range check, and
`validateMusicProject` applies actual numeric thresholds (duration error ≤10%,
peak ≤0 dBFS, `maxSilenceGapMs ≤ 50`, inverse-square error ≤2 dB) to derive
`MusicWorkbench` readiness. DSP, synthesis and pitch-detection stay in the
engine; this is the typed authoring-and-validation contract.

### @maya/forge-studio-sculpt

A dual crate (tags `scope:maya`, `layer:ixchel`, plus
`type:rust-lib`/`type:ts-lib`) pairing a Rust
`libs/maya/forge-studio-sculpt/src/lib.rs` (428 lines incl. 5 tests,
`unsafe_code = "forbid"`, dependency-free) with a near-identical TypeScript
`libs/maya/forge-studio-sculpt/src/index.ts` (278 lines); neither manifest
carries a `description`, so both self-identify via
`FORGE_STUDIO_SCULPT_SCHEMA_VERSION = "maya.forge.studio.sculpt.1"`. Within the
forge-studio creator-tooling family (beside `forge-studio-core`, `-cinema`,
`-mocap`, `-voice`, `-world`), this is the 3D-asset-authoring pane: it models
`SculptSource` (text/image/photogrammetry/manual), `MeshAsset` quality metrics,
and
`GenerationPlan`/`MeshCleanupPlan`/`MaterialPlan`/`RigPlan`/`AttachmentPlan`/`VariantPlan`
via `textTo3dAsset`, `photogrammetryScan`, `cleanupMesh`, `authorMaterial`,
`rigAsset`, and `generateVariants`.

Honesty: this is a typed readiness/capability facade, not a 3D engine.
`validMesh` returns a hardcoded "valid" mesh (`polygonCount 40_000`,
`quadRatio 0.91`, `uvCoverage 0.98`, `silhouetteSsim 0.94`) and `stableId` is a
char-code checksum, so the generation/retopo/rigging functions emit canned plans
— the real diffusion/photogrammetry/auto-rig runtime lives elsewhere. The
genuinely computed logic is `validatePreview`, which inspects topology, polygon
budget, UV coverage, material channels, and rig validity to push issue strings
and set `exportReady`; the TS surface additionally carries
`SculptReadiness`/`buildSculptWorkbench`, reducing that report to a
`ready`/`needs-review`/`blocked` workbench. Otherwise the two surfaces are exact
mirrors at identical maturity.

### @maya/forge-studio-voice

A dual Rust+TypeScript crate (tags `type:rust-lib`/`type:ts-lib`,
`layer:ixchel`; `package.json` carries no `description`) modelling the voice and
audio panel of the Maya forge-studio creator suite under the Ixchel UGC layer.
Both surfaces — `libs/maya/forge-studio-voice/src/lib.rs` (~437 lines, including
a 5-test `#[cfg(test)]` module) and `src/index.ts` (315 lines) — mirror the same
nine planners under schema `maya.forge.studio.voice.1`: `planRecording` selects
the best non-discarded take (starred, then SNR) and reports `snrAfterGateDb`;
`designVoiceProfile`, `planVoiceClone`, `generateLipSync`, `batchDialogueTree`,
`designSoundEffect`, `designAmbientSoundscape`, `coachPerformance`, and
`buildLocalizationPack` emit typed
`RecordingPlan`/`VoiceClonePlan`/`LipSyncTrack`/`DialogueBatchReport`/`LocalizationPack`
records. The TypeScript surface alone adds
`buildVoiceConsole`/`classifyReadiness`, folding inputs into a `VoiceReadiness`
verdict (`blocked` when `dialogue.exportReady` is false or `snrAfterGateDb` <=
40; `needs-review` on lip-sync error >= 50 ms or clone similarity <= 0.85).

Honesty: this is a capability-contract / readiness-planner facade, not a DSP or
voice-cloning runtime — neither surface is "the engine." Scores are heuristics
(`perceptualDistinctness = min(0.98, 0.72 + n*0.05)`,
`speakerSimilarity = referenceMinutes >= 3 ? 0.88 : 0.72`), pipeline booleans
and `blendshapeWeights {jawOpen:0.6,...}` are hardcoded, and governance flags
(`reviewRequired`, `aiGeneratedLabelRequired`) are always set. The genuine logic
is deterministic set/threshold computation — best-take ranking,
missing-audio/lip-sync detection, max viseme-alignment error, localization gap
collection, and the `classifyReadiness` gate — over already-measured inputs like
`snrDb`, `detectedScore`, and `speakerSimilarity`. Real recording DSP, neural
cloning, and viseme synthesis stay downstream/in-engine.

### @maya/loom-agent

A Rust crate (`libs/maya/loom-agent/src/lib.rs`, ~801 lines, tags
`scope:maya`/`layer:loom`/`type:rust-lib`, `unsafe_code = "forbid"`).
`Cargo.toml` carries no `description`; its module contract and
`LOOM_AGENT_SCHEMA_VERSION = "maya.loom.agent.1"` identify it as the rule-based
orchestration layer over Loom's procedural world-genome stack (sibling to
`@maya/loom-core`). From a `WorldGenomeBrief` it sequences a fixed
`GenerationTool` pipeline
(`TerrainGenerator → UrbanGenerator → FloraGenerator → AtmosphereGenerator`) and
models CityGenAgent / WorldGrow concepts as typed plans and reward structures,
without representing an LLM or trained RL execution. Its deterministic logic
includes: `generate_citygenagent_city` sizes block/road/building/floor programs
by parametric formulas off `settlement_density`/`tech_level`;
`grow_world_from_seed` expands a Chebyshev-distance grid of `WorldBlock`s with
FNV-stable IDs and per-cell terrain/vegetation/settlement summaries;
`coordinate_multi_agent_generation` builds a round-robin owner graph with linear
region dependencies; `edit_world_from_natural_language` keyword-edits genome
parameters; `build_agent_generation_audit_trail` derives an FNV
`provenance_hash`. `score_agent_visual_consistency` aggregates caller-supplied
measured viewpoint scores and checks their completeness; it does not inspect
pixels. The `0.91` and `0.88` values emitted by `generate_citygenagent_city` are
explicitly named design targets, not measured rewards. Readiness fields describe
coherence of the generated plan. Honesty: this is a measurable procedural
baseline and capability layer, not a running agent, LLM, RL training system, or
renderer.

### @maya/loom-diffgen

A dependency-free Rust crate (`libs/maya/loom-diffgen/src/lib.rs`, 916 lines,
tags `scope:maya`/`layer:loom`/`type:rust-lib`, `unsafe_code = "forbid"`;
`Cargo.toml` carries no `description`, schema
`LOOM_DIFFGEN_SCHEMA_VERSION = "maya.loom.diffgen.2"`). It is explicitly the
`differentiable-procedural-baseline-v1` counterpart to `@maya/loom-core`'s
world-DNA: each pipeline stage returns a value plus a 9-component
`GradientVector` (real L2 `magnitude`, `add_scaled` accumulation) over
`TerrainGenomeParameters` (`frequency`, `amplitude`, `lacunarity`,
`persistence`, `seed_offset`, `erosion_strength`, `temperature`,
`precipitation`, `vegetation_density`), so a world genome can be fitted by
bounded optimizers — `apply_gradient_step` is a real clamped update — toward
scalar procedural targets rather than hand-tuned.

The gradients are genuinely hand-derived: `differentiable_noise` chain-rules
analytic trig derivatives into the parameter gradient; `differentiable_erosion`
uses the real `tanh` adjoint `(1 - flow*flow)`; `assign_soft_biome`,
`render_differentiable_heightmap`, and `optimize_vegetation_density` use
`sigmoid` soft boundaries to keep gradients flowing;
`run_differentiable_world_pipeline` chains Noise→Erosion→Biome→Vegetation→Render
with a weighted accumulated gradient.

The prompt-guided path is named `prompt_hash_guided_world_baseline` and records
its source as `fnv1a32-prompt-hash-target-v1`; it executes bounded gradient
steps and reports its measured initial and final parameter losses. The residual
erosion path is named `procedural_residual_erosion_baseline`, labels its
trigonometric source, and records `trained_model_used: false`. Render output
records `perceptual_loss_backend_configured: false`.
`benchmark_procedural_optimizers` actually runs gradient descent, a
deterministic evolution strategy, and random search, measures each initial/final
loss and improvement, and derives the winner from the lowest measured final
loss.

Honesty: the `NoisePrimitive::{Perlin,Simplex,Worley}` cases are differentiable
trig proxies, not true lattice noise. No CLIP/image encoder, perceptual model,
neural erosion, diffusion model, or trained model is configured. Outputs stay
scalar/low-dimensional; this measurable baseline does not substitute for an
advertised neural experience or a full engine build.

### @maya/loom-inverse

A dependency-free Rust crate (`libs/maya/loom-inverse/src/lib.rs`, ~1,063 lines,
tag `layer:loom`, `unsafe_code = "forbid"`, schema `maya.loom.inverse.2`). It is
the _inverse_ counterpart to `@maya/loom-core`'s forward genome→world
generation. The executable local path accepts decoded `ReferenceImage` RGB8
pixels, measures channel/luminance statistics, horizontal/vertical edge energy,
and saturation, then trains an 8→12→4 sigmoid MLP to infer normalized aridity,
forest cover, elevation bias, and rockiness. `train_reference_vision_model` uses
caller-separated training/validation sets, rejects duplicate reference IDs
across them, retains the learned parameters, records held-out MAE, and binds
them to a labeled FNV-1a-64 digest. `estimate_terrain_parameters_from_image`
revalidates that digest before inference.

The deterministic fixture trains on 16 RGB images for 900 epochs and measures
four held-out images at MAE `0.032510392`; rerunning produces the same
parameters and metric. Seven tests cover training, inference, malformed pixels,
invalid labels, split duplication, tampering, priors, and the existing spectral
analysis/workflow contracts.

Honesty: this is a small, framework-free CPU visual-feature MLP, not a CNN,
foundation model, or evidence from a production image corpus. Image decoding
stays at the application edge, and the FNV parameter digest is an integrity
label rather than a cryptographic identity. The ID-only
`estimate_terrain_parameters_from_reference` and product-CNN
`train_neural_parameter_predictor` paths still fail loud. CMA-ES/LPIPS quality
targets, the design priors, and external-model ingest remain contracts rather
than results from this bounded model.

### @maya/loom-semantic

A dependency-free Rust crate (`libs/maya/loom-semantic/src/lib.rs`, 917 lines,
tags `scope:maya`/`layer:loom`/`type:rust-lib`, `unsafe_code = "forbid"`; empty
`[dependencies]`, no Cargo `description`; schema
`LOOM_SEMANTIC_SCHEMA_VERSION = "maya.loom.semantic.1"`). It is Loom's
artist-guided _semantic painting_ layer: creators stamp `BrushStroke`s carrying
one of seven `SemanticLabel`s (DenseForest, RockyCliff, UrbanArea, WaterBody,
FrozenWasteland…) across six `BrushToolMode`s, and the crate rasterizes them
into typed guidance for the heavier world-generation passes that loom-core/biome
run. `create_semantic_brush_painting_system` paints a `LabelTexture` through a
`stroke_weight` radial `smoothstep` falloff; `map_semantic_to_generation`
resolves each label to concrete `SemanticGenerationMapping` constants
(DenseForest → `tree_density` 0.92 with oak/cedar/fern canopy; RockyCliff →
`erosion_multiplier` 1.85, `cliff_face_generation`).

This is real algorithmic code, not a readiness facade.
`create_artist_guided_erosion_mask`/`paint_erosion_constraints` emit per-cell
iteration, transport and protection multipliers; `paint_vegetation_density`
converts density into Poisson spacing; `blend_semantic_brushes` computes
normalized per-cell `BTreeMap<SemanticLabel, f32>` transition weights;
`train_pcgml_semantic_layer` fills unpainted cells by nearest-neighbour over
`TerrainFeature` (height/slope/moisture) distance with a moisture/slope
fallback; `build`/`undo`/`redo_semantic_history` keep undo stacks. Honestly: it
emits guidance fields — masks, weights, Poisson targets, predicted labels —
consumed downstream; the erosion sim, scattering and world build live elsewhere,
and a few struct booleans (`overlay_2d_ready`, `reproducible_generation`) are
static capability flags. Five `#[cfg(test)]` tests cover each path.

### @maya/loom-terrain-ml

A dependency-free Rust crate (`libs/maya/loom-terrain-ml/src/lib.rs`, ~1,363
lines, tag `layer:loom`, `unsafe_code = "forbid"`, schema
`maya.loom.terrain.ml.2`). Its separate local learned path trains a 10→12→1
sigmoid MLP from caller-supplied `TerrainTrainingTile`s: per-pixel position,
canny/mountain/lake/road sketch channels, and four `WorldGenomeTerrainCondition`
axes become a predicted height. Training and validation tile IDs must be
disjoint, dimensions/channels/targets are fully validated, the run is capped at
one million supplied pixels and 50 million updates, and
`generate_local_ml_terrain` revalidates the retained parameter digest before
emitting a result tagged `procedural_stand_in: false`.

The deterministic fixture trains six tiles (384 pixels) for 600 epochs and
measures two held-out tiles (128 pixels) at MAE `0.013766719`; deterministic
retraining yields the same model and metric. Seven tests cover learned
training/generation, holdout separation, invalid inputs, parameter tampering,
and the pre-existing terrain paths.

Honesty: this is real learned CPU inference but only a small supervised MLP
baseline. It is not diffusion and does not establish Earthbender, TerraFusion,
Mesa, neural inpainting, super-resolution, or ONNX runtime availability. Those
named functions remain explicitly tagged deterministic procedural fallbacks;
their real erosion/heightmap arithmetic remains useful but does not inherit the
local model's evidence. The fixture data are synthetic and establish executable
correctness, not product-corpus quality or artist preference.

### @maya/crucible-core

A Rust crate (`libs/maya/crucible-core/src/lib.rs`, ~2,147 lines, tags
`scope:maya`/`layer:crucible`/`type:rust-lib`; `Cargo.toml` carries no
`description`, zero dependencies, `unsafe_code = "forbid"`, schema
`maya.crucible.core.2`). Unlike Maya's plan/readiness TS facades, this is a
real, std-only deterministic playtest engine — the headless simulation core of
the Crucible balance/adversarial harness. `HeadlessSimulation::run` drives a
fixed-dt tick loop that, per `headless_system_order(fidelity)`, applies
`apply_economy`/`apply_ai`/`apply_combat`/`apply_rules` (per-attacker damage
`dps + dps*bonus/1000 + jitter`, kill/death tracking, a `SimulationEvent` log)
over a seeded xorshift64 `DeterministicRng`, sampling
`EconomySnapshot`/`PowerCurveSample`; `excluded_headless_engine_systems` drops
rendering/audio/input. `bootstrap_simulation` content-addresses the `ModLoadout`
via FNV-1a `derive_mod_loadout_hash` and rejects mismatches.
`capture_snapshot`/`replay_from_snapshot` round-trip a compressed envelope,
`run_parallel_simulations` fans scenarios across real `thread::spawn` workers
(parallel result hashes equal sequential), and
`run_campaign`/`pause_campaign`/`resume_campaign` expand parameter sweeps with
checkpointing. Declared `learned:{conservative,balanced,aggressive}` strategies
now apply explicit damage/survival trade-offs at bootstrap so measured policy
training changes a gameplay strategy without silently changing skill. Eleven
tests assert 1000x determinism, mid-match replay equality, and the strategy
trade-offs. Honesty: gameplay systems remain simplified integer models, the
snapshot codec is explicitly `Rle`, and content/state hashes are FNV-1a rather
than cryptographic identities. Full-engine parity no longer self-compares:
`verify_headless_parity_against_reference` now requires an externally supplied
reference bound to a supported full runtime, engine build, executable SHA-256,
run and artifact identities, UTC completion, and a length-framed digest of the
complete scenario plus loop configuration. The comparison requires an exact
state-hash match as well as a margin delta no greater than 1%. Unit fixtures
exercise validation and comparison semantics but are not full-engine evidence;
no Unreal or assembled Maya runtime receipt was captured in this slice.

### @maya/crucible-agents

A Rust crate (`crucible-agents` v0.1.0, `libs/maya/crucible-agents/src/lib.rs`,
~2,093 lines, tags `layer:crucible` + `type:rust-lib`/`type:python`,
`unsafe_code = "forbid"`, with `crucible-core` and `sha2` dependencies; no
Cargo/package description, so
`CRUCIBLE_AGENTS_SCHEMA_VERSION = "maya.crucible.agents.2"` names it). It is the
AI-opponent cast for the Maya Crucible playtest/adversarial-evaluation harness —
the bot populations that actually play modded matches so sibling crates can
measure balance, exploits, and coordination. The simulation core is real,
deterministic logic: a `CrucibleAgent` trait (`agent_id`/`act`) with
`ScriptedAgent` (eight `ScriptedBehavior`s dispatched in `scripted_action`, e.g.
`AlwaysStrongestAttack` = `max_by_key(threat_milli)`, `RushObjective` = nearest
objective) and `HeuristicAgent` (branching on a 13-field `PlaystyleProfile`); a
six-tier `skill_calibration` (Bronze→Champion) feeding
`estimate_matchup_win_rate`; a 12-entry `archetype_library`;
`build_observation`'s genuine fog-of-war / line-of-sight / hidden-stat
redaction; `validate_action`'s legality+cooldown gate; and a seeded xorshift
`DeterministicRng` (a test asserts identical actions across 10,000 frames).
`test_coordination` computes premade and solo rates from measured
`MatchRecord`s, while `run_exploit_hunter` detects the first threshold crossing
in measured episode telemetry.

`train_rl_agent` now has one real, deliberately bounded execution mode: one-step
tabular Q-learning over conservative/balanced/aggressive strategy actions. Each
update consumes an actual `crucible-core` match; the checkpoint stores learned Q
parameters, the measured reward curve, actual frames, held-out wins/matches, and
separate SHA-256 training/evaluation digests. Evaluation alternates red/blue
sides. `run_match_based_meta_discovery` likewise executes side-balanced matches,
selects parents by measured wins, mutates the next generation, and hashes all
result identities before Wilson ranking. The owning tests run 6,000 training
frames, 50 held-out matches, and 48 evolutionary matches deterministically.

Honesty: this is a small CPU baseline, not PPO, distributed GPU training, or
self-play; those modes fail loud. The Python `training.py` remains an
orchestration/ingest seam and explicitly points to the Rust baseline rather than
fabricating a Python trainer.

### @maya/crucible-adversarial

A dependency-free, std-only Rust crate
(`libs/maya/crucible-adversarial/src/lib.rs`, ~2,021 lines, tags
`layer:crucible`/`type:rust-lib`, `unsafe_code = "forbid"`; `Cargo.toml` carries
no `description`, schema const
`CRUCIBLE_ADVERSARIAL_SCHEMA_VERSION = "maya.crucible.adversarial.1"`). Within
the crucible adversarial-playtest harness it is the exploit hunter: it
statically searches typed models of a modded game for game-breaking
combinations, ranking them on a five-tier `ExploitTier` (T1Cosmetic →
T5EconomyDestroying) across nine `ExploitKind`s. This is real algorithmic code,
not a readiness facade. `scan_infinite_resource_exploits` runs a depth-bounded
positive-cycle DFS (`dfs_positive_cycle`) over crafting/currency graphs, plus
price-arbitrage and uncapped-modifier checks; `scan_one_shot_combos` enumerates
ability sequences in a time window and stacks fixed-point multipliers
(`multiply_milli`, i128, fields in `_milli`) against `ProgressionStage` health;
`scan_invincibility` sums additive/compound mitigation, regen, shield and
lifesteal versus incoming DPS. `generate_exploit_proof` minimizes the mod set
and emits a deterministic FNV-1a replay id, `suggest_mitigations` maps each kind
to `MitigationStrategy` patches, and `synthetic_known_exploit_suite` seeds a
regression corpus of real exploits (skyrim-restoration-loop, diablo-dupe,
poe-mirror). Honesty: it reasons over declarative mod-effect structs, never a
live engine — the economy, combo and movement scanners genuinely derive
findings, while the AI, grief and physics-numeric paths are threshold gates over
self-reported fields (`ai_win_rate_milli`, `produces_nan`). A 302-line Python
companion (`python/crucible_adversarial/proofs.py`) mirrors the proof/report
path.

### @maya/crucible-balance

A dual crate (`layer:crucible`, tags `type:rust-lib` + `type:ts-lib`) whose real
engine is the Rust side: `libs/maya/crucible-balance/src/lib.rs` (~1,463 lines
incl. 11 inline tests, `unsafe_code = "forbid"`, dependency-free, schema
`maya.crucible.balance.1`; neither `Cargo.toml` nor `package.json` carries a
description). It is the balance-analysis facet of the crucible playtest harness:
it ingests match telemetry and emits flagged reports certifying a mod
combination. The statistics are genuine, deterministic, and fixed-point
(`_milli` u32): `win_rate_matrix` with `wilson_interval_milli` (Wilson score,
z=1.96), `analyze_pick_win` quadrants
(`PickWinQuadrant::{NoobTrap,HiddenOp,BalancedPopular,Niche,Watch}`, 2σ
outliers), `analyze_power_curve` (`Convexity` via second differences, inflection
points), `analyze_ttk` (p10/median/p90), `economy_health` (Gini,
supply-vs-demand inflation, velocity), `strategy_diversity` (Shannon entropy
normalized by log2), `matchup_graph` (intransitive-cycle / degenerate-RPS
detection), plus `comeback_potential`, `blowout_rate`, `cross_mod_interactions`,
`progression_pace`, and `sensitivity_analysis` — aggregated by
`balance_scorecard` into eight `ScoreCategory` `LetterGrade`s.

The TypeScript surface (`src/index.ts`, 184 lines) is a thinner
presentation/recommendation mirror, not a second engine: `buildBalanceScorecard`
maps already-computed `BalanceMetricSummary[]` to A-F grades, `heatmapRows` lays
out matchup cells, `classifyPickWinScatter` re-derives the quadrant taxonomy on
rates, and `recommendationsFor`/`recommendationForFlag` turn flags into
remediation text ("add currency sinks or reduce generator yield"). It shares the
grade/quadrant vocabulary but on a 0-100 scale, not Rust's 0-1000 milli, and
recomputes none of the Wilson/Gini/entropy math.

### @maya/crucible-scenarios

A dual Rust+TypeScript crate (tags `scope:maya`, `layer:crucible`,
`type:rust-lib`, `type:ts-lib`; neither `Cargo.toml` nor `package.json` carries
a description, so the constant
`CRUCIBLE_SCENARIOS_SCHEMA_VERSION = "maya.crucible.scenarios.1"` names it). It
is the scenario-design surface of the crucible adversarial/playtest harness,
building the combinatorial test-matrix that `@maya/crucible-core` then
validates, snapshots, and replays. The real engine is the Rust side —
`libs/maya/crucible-scenarios/src/lib.rs`, 915 lines, dependency-free,
`unsafe_code = "forbid"`. `generate_pairwise_campaign` is a genuine greedy
pairwise covering-array generator: it enumerates `all_factor_pairs`, expands
capped `cartesian_rows` (≤50_000), greedily selects rows by `max_by_key` over
uncovered-pair intersection, then patches residual pairs — compressing a
`full_combinatorial_size: u128` space into a compact `ScenarioCampaign`. Around
it sit threshold balance analyzers emitting `ScenarioFinding`s over a
nine-variant `ScenarioFlagKind` (`analyze_asymmetry`, `generate_map_findings`,
`analyze_new_player_experience`, `analyze_endgame_stagnation`), a curated
seven-pattern `edge_case_library`, a six-factor `rank_scenarios`, and
`spearman_rho` rank-correlation — all covered by value-asserting tests
(`full_combinatorial_size == 192`, coverage `1.0`, grade `'A'`). `src/index.ts`
(156 lines) is a thinner typed companion, not a full mirror: it re-exports
`coverageGrade`, `buildCoverageSummary`, `validateScenario`, `coveredPairs` and
a reduced four-factor `rankScenarios`, but omits the generator and analyzers.
The analyzers flag supplied metrics against fixed thresholds rather than
simulating matches.

### @maya/crucible-regression

A dual crate (tags `type:rust-lib` + `type:ts-lib`, `layer:crucible`) whose
statistical core lives on the Rust side.
`libs/maya/crucible-regression/src/lib.rs` (~915 lines, schema
`maya.crucible.regression.1`; `package.json` carries no description) is a
genuine balance-regression engine for the crucible playtest/evaluation harness.
`compute_balance_fingerprint` snapshots a loadout's `MetricFingerprint`s across
the 12-variant `RegressionMetric` taxonomy (`MatchupWinRate`, `TtkMedian`,
`EconomyGini`, `StrategyEntropy`, …); `diff_fingerprints` computes a
pooled-standard-error `z_score` and classifies each metric Green/Yellow/Red
against `RegressionThresholds` (0.01/0.05/0.10 abs, 1.96/3.29 z), with direction
set by `higher_is_risk`. `evaluate_regression_gate` returns a graduated
Informational/Warning/Blocking `GateDecision` (blocking attaches a
`governance_note`); `run_ab_simulation` is a paired-seed, Bonferroni-corrected
A/B test with 95% CIs and effect sizes; `analyze_historical_trend`
least-squares-fits power-creep and mean-reversion failure; `schedule_monitoring`
tiers popular combos Daily/Weekly/Monthly; `alerts_for_gate` routes severity to
`AlertChannel`s, backed by `FingerprintStore` and `AlertDeduper`. Nine tests
assert domain correctness, including zero false positives on cosmetic-neutral
updates.

The TypeScript surface (`libs/maya/crucible-regression/src/index.ts`, 215 lines)
is a thinner typed mirror of the reporting layer — `buildRegressionReport`,
`evaluateGate`, `buildMonitoringPlan`, `summarizeTrend` (adding a `sparkline`
renderer), `alertsForReport`/`dedupeAlerts` — operating on already-diffed
`MetricDiff` rows. It re-implements the color gate, tiering, and least-squares
slope, but not the fingerprint statistics or Bonferroni A/B simulation, which
live only in Rust.

### @maya/crucible-live

A dual crate (tags `type:rust-lib` + `type:ts-lib`, `layer:crucible`) pairing a
Rust detection engine with a TypeScript dashboard surface; neither `Cargo.toml`
nor `package.json` carries a `description`, and both pin schema
`maya.crucible.live.1`. The Rust crate (`libs/maya/crucible-live/src/lib.rs`,
~688 lines, `unsafe_code = "forbid"`, zero deps) holds the real statistics:
`ingest_telemetry` does exactly-once `BTreeSet` dedup plus k-anonymity drops
(loadouts under 10 events), `track_win_rates` computes 99%-`z` Wilson intervals
(`wilson_interval`) with mode-aware min-sample gating, `detect_anomalies` flags
≥3-sigma shifts plus win-rate spikes / population drops with known-event
suppression, `detect_simulation_drift` measures relative drift versus simulator
predictions, and `track_meta_evolution` derives Shannon `entropy`,
`kl_divergence`, top-K stability and oscillation into a `MetaPattern`. Six
`#[cfg(test)]` cases assert these against known values.

The TypeScript surface (`libs/maya/crucible-live/src/index.ts`, 389 lines) is
not a thin mirror but the complementary presentation/governance layer:
`buildLiveDashboard` fans six finding streams through per-source builders
(`winRateAlerts`…`metaAlerts`) into `dedupeAlerts` (severity-weighted, seen-key
suppressed), routes each `LiveAlert` to `AlertChannel`s with `slaMinutes`, and
scores a 0–100 `healthScore` plus a `pickWinUrgency` scatter;
`packageHotfixProposal` mints an `emergency-fast-track` proposal with
`humanApprovalRequired: true`. The two sides overlap only in shared constants
(`classifyPickWin`, quadrant/sentiment cutoffs). Within crucible's
playtest-evaluation family this is the live-ops arm — watching post-ship meta
telemetry and measuring live drift against the pre-ship balance simulation.

### @maya/crucible-governance

A TypeScript library (`libs/maya/crucible-governance/src/index.ts`, 367 lines,
tags `scope:maya`/`layer:crucible`/`type:ts-lib`; `package.json` carries no
`description`) that is the governance and balance-policy layer riding on top of
Crucible's adversarial-playtest engines. Unlike the maya Rust forge/loom crates,
it is pure, dependency-free, deterministic TypeScript: nine exported functions
over seventeen `readonly` interfaces (`BalanceFingerprint`, `MetricImpact`,
`SimulationBudget`, `ArchiveEvent`, `Bounty`, `DraftBalanceProposal`). Its
genuine algorithmic core is `diffFingerprints`, which Map-joins before/after
`BalanceMetric`s, derives absolute/relative change, flags `regression` by each
metric's `higherIsRisk` direction, and sorts by impact magnitude;
`evaluateWhatIfQuery` adds per-user/per-day rate limiting plus a `parameterHash`
cache; `appendArchiveEvent`/`searchArchive` keep an append-only, dedup-guarded
precedent log; `validateBountySubmission` gates exploit payouts on severity rank
and simulation reproduction; `draftBalancePatchProposal` routes `T4`+ severities
to an `emergency-fast-track` process with `councilReviewRequired`.

Honesty about scope: it evaluates data handed to it rather than running
simulations. `simulateProposalImpact` is an SLA/budget calculator
(`estimatedMinutes = ceil(scenarios / 50)`) wrapped around a fingerprint diff,
and `buildBalanceHealthDashboard`/`buildAdvisorOutput` mostly sort, select, and
template over supplied metrics (the `narrativeSummary` is a boilerplate
one-liner that interpolates the dominant build name). The heavy balance
simulation lives in sibling `crucible-*` packages; this is the tested
(`index.spec.ts`, 7 value-asserting cases) decision/precedent toolkit layered on
top.

### @maya/matchmaking

A real TypeScript competitive-multiplayer library (`libs/maya/matchmaking/src`,
~3,074 lines across three modules; description "Production matchmaking rating
and skill systems for Maya Nexus", tags `layer:domain`/`domain:matchmaking`).
The **rating core** (`index.ts`, ~1,479 lines) implements three competitive
rating systems as genuine algorithms, not facades: **Glicko-2**
(`updateGlicko2Rating` runs Glickman's full update — `preRatingPhi = √(φ²+σ²)`,
iterative volatility convergence to `convergenceTolerance`, and
`newPhi = 1/√(1/preRatingPhi² + 1/variance)`), **Elo** (`updateEloRating`,
`eloExpectedScore`, `calculateEloKFactor`), and a multi-dimensional
**TrueSkill2** (`aggregateTrueSkill2Mean`/`-Deviation` over the `overall`,
`aim`, `positioning`, and `teamwork` `SkillDimension`s). On top sit the full
competitive surface: 10-match placement (`recordPlacementMatch`,
`placementRatingMultiplier`), `DEFAULT_RANK_TIERS` divisions with
`rankFromRating`/`evaluateRankMovement`, `applyRatingDecay` and
`applySeasonalSoftReset`, `detectPlacementSmurfing`, team-skill aggregation, and
`RatingConfidenceInterval`s. `runRatingSystemBenchmark` checks the
implementations against `LICHESS_PUBLIC_BENCHMARK_SAMPLE` — honestly an 8-row,
hand-authored fixture shaped like Lichess data (it carries a `dataset` label and
a `sourceUrl`, but is committed in-source, not loaded from the live public
database) — backed by spec tests. The library also ships the rest of the path
into a match: a **matchmaking queue** (`queue.ts`, ~994 lines —
`MatchmakingTicket`s with priority classes, team assignment,
`MatchQualityScore`, backfill, dodge penalties, and wait-time/satisfaction
analytics) and **server allocation** (`allocation.ts`, ~601 lines —
`GameServerInstance` health, `ServerAllocationPolicy`, player connection
routing, demand forecasting, reservations, and loading-abandon penalties). It is
the rating-and-routing brain behind the Maya Nexus multiplayer layer, paired
with its sibling `@maya/lobbies`.

### @maya/animal-database

A small reference-data library at `libs/maya/animal-database/src` backing the
maya-ecology `domestic` husbandry simulation: `catalog.ts` defines the
`AnimalEntry` shape (an `AnimalCategory` of farm/working/pet/wildlife, `Diet`,
products, care needs) over a committed `ANIMALS` catalog, with lookup helpers
`getAnimal`, `animalsByCategory`, and `producers`. It is a data catalog plus
query helpers — the husbandry simulation itself lives in the maya-ecology Rust
crate, not here.

### @maya/anticheat

A single-module TypeScript library (`libs/maya/anticheat/src/index.ts`, ~740
lines) implementing anti-cheat enforcement as one stateful
`MayaAnticheatModerationSystem`: bans (`MayaAnticheatBan` with
account/hardware/ip-range scopes), `applyEscalatingPenalty` ladders, player
reports, appeals (`submitAppeal`/`reviewAppeal`), and a community tribunal
(`openTribunalCase`, `castTribunalVote`), governed by a
`DEFAULT_MAYA_ANTICHEAT_POLICY` and failing loud via
`MayaAnticheatModerationError`. It is the moderation workflow engine — cheat
_detection_ signals and persistence are the caller's.

### @maya/community-companion

A single-file model library (`libs/maya/community-companion/src/index.ts`, ~170
lines) for the companion web/mobile surface of Maya Social Fabric: typed records
for finder feeds, synchronized calendars, public profiles, deep links,
notification preferences, Discord/external bridges, RSVP flows, and webhooks,
with small pure constructors and validators (`buildCompanionFinderFeed`,
`syncEventCalendar`, `createDeepLink`, `updateNotificationPreferences`). It is a
schema-plus-helpers library, not a running API service.

### @maya/community-federation

The inter-community diplomacy model
(`libs/maya/community-federation/src/index.ts`, ~215 lines): `Alliance` records
with member guilds, channels, events, and `GovernancePermissionTemplate`s, guest
access via `issueGuestAccessPass`/`canUseGuestPass` expiry-and-rights checks,
coalition kinds, partner discovery, and `DiplomaticState` stances. Thirteen
small pure functions over typed records; persistence and transport are left to
consumers.

### @maya/community-governance

Community-leadership workflows as a typed model library
(`libs/maya/community-governance/src/index.ts`, ~270 lines): leadership role
templates and `GovernancePermission`s, event-ownership delegation, decision
logging (`logGovernanceDecision`), ambassador tracks, staffing shifts with
`evaluateStaffingCoverage`, and a `buildBurnoutDashboard` over leadership
workloads, plus culture-template and operations-runbook kinds. Pure helpers over
records — no storage layer.

### @maya/community-health

Community-health analytics models (`libs/maya/community-health/src/index.ts`,
~240 lines): metric definitions and warehouse event schemas, social cohort
metrics (`computeCohortMetric` for first-friend/first-repeat-squad/first-guild),
guild and LFG funnels (`buildGuildFunnel`, `buildLfgFunnel`), safety-trust
summaries, a `scorePlayerRisk` risk model, experiment definitions, and
intervention playbooks. It computes real ratios and scores over counts the
caller supplies; it does not own a data warehouse.

### @maya/community-recognition

Prosocial recognition models (`libs/maya/community-recognition/src/index.ts`,
~185 lines): badge rules with `evaluateBadgeEligibility` quality signals,
milestone ceremonies, appreciations, graduation moments, memory artifacts, and
`recognizeInvisibleLabor` for logistics/moderation/welcoming/conflict-resolution
work, with incentive guardrails expressed in the types. Seven pure
constructors/evaluators over typed records.

### @maya/community-reputation

Private-first reputation for Maya Social Fabric
(`libs/maya/community-reputation/src/index.ts`, ~325 lines):
`computePrivateReliabilityScore` over a `PrivateReliabilityModel`, endorsements
with `summarizeEndorsements`, `deriveTrustMarkers`, avoid/block preferences with
`shouldSuppressForPreference`, `computeCompatibilityScore`, recovery workflows,
and fairness-audit shapes. Scores are computed for selective surfacing in a
`TrustSurfaceContext` (discovery, matching, private ops), deliberately not for
public display.

### @maya/ecology

Species data management at `libs/maya/ecology/src` — the TypeScript counterpart
to the maya-ecology Rust crate: `species.ts` defines the typed species schema
(`Taxon`, `Archetype`, diet, `SocialStructure`, habitat, perception) including a
Kleiber's-law sublinear metabolic-energy model, and `registry.ts` provides the
queryable `SpeciesRegistry` with taxonomy/habitat/diet queries, predator/prey
trophic-web traversal, and `validateSpecies` referential checks.

### @maya/economy

A broad virtual-economy library (`libs/maya/economy/src`, 26 modules): a
double-entry ledger (`MayaLedgerTransaction`), currencies and conversion,
idempotent transaction processing, IAP receipt validation with refund/clawback,
escrowed direct trading, marketplace listings/auctions
(`MayaMarketplaceAuctionService`), fees, fraud detection
(`MayaMarketplaceFraudDetectionService`), trade restrictions, gifting, price
history, economy-health monitoring, and a creator-revenue tier (dashboard,
payouts, pricing, promotions, tax compliance, IP disputes). The barrel's
`MAYA_ECONOMY_PACKAGE` descriptor enumerates 32 capabilities that map onto the
modules.

### @maya/economy-tools

Balance-analysis tooling over maya-economy simulation output at
`libs/maya/economy-tools/src`: `convergence.ts` computes price-series statistics
(`seriesStats`, `detectConvergence`, `volatilityReduction`) and `report.ts`
grades settlement economic indicators (`gradeHealth` into
thriving/stable/struggling/crisis, `formatReport`, `rankByHealth`). The barrel
says plainly that the live debugging dashboard's charts are the app's rendering
concern; this library is the analysis that feeds them.

### @maya/env-storytelling

Procedural environmental storytelling at `libs/maya/env-storytelling/src` —
scene dressing that tells stories without dialogue: `rules.ts` maps
`WorldEvent`s (battle/fire/abandonment/celebration/crime) to decoration sets
with `battleAftermath` and `abandonmentDecay`, `surfaces.ts` covers lived-in
spaces, graffiti, creature trails and economic/seasonal dressing, and
`placement.ts` does collision-avoiding, density-scaled placement
(`placeAvoidingCollision`, `densityForDetail`, `thinToCount`).

### @maya/forge-companion-avatar-controller

The Forge companion's expressive-avatar layer
(`libs/maya/forge-companion/avatar-controller/src`, 15 modules): a FACS
Action-Unit blend-shape driver (`ACTION_UNITS`, rig mapping, `intensityCurve`),
VAD-emotion→FACS mapping with micro-expressions, transition easing and layer
compositing, blink/gaze/pupil eye controllers, 60+ expression presets,
gesture/IK/idle/cloth-hair/personality layers, and a realtime phoneme→viseme
lip-sync pipeline (`VisemeMapper`, `CoArticulationBlender`,
`RealtimeLipSyncDriver`, `EmotionalLipSyncModifier`) with emphasis animation and
sync-drift monitoring.

### @maya/forge-companion-e2e-tests

A testing-only project (`libs/maya/forge-companion/e2e-tests/src`): the Phase
78.15 end-to-end suites (`voice-e2e`, `avatar-e2e`, `workshop-e2e`,
`mod-engine-e2e`, `integration-e2e` spec files) wire the real sibling
forge-companion libraries together, and the barrel exports only shared scenario
helpers — a 55-entry `MOD_SCENARIOS` corpus of voice-modding utterances labelled
with their expected mod domain. No production runtime ships from here.

### @maya/forge-companion-generation-pipeline

The Forge companion's real-time generation pipeline
(`libs/maya/forge-companion/generation-pipeline/src`): `orchestration.ts` is
real local logic (`GenerationOrchestrator` priority queue, progress streaming,
`MidGenerationFeedbackLoop`, `GenerationQualityGate`, cost estimation, semantic
cache), while `generators.ts` is honestly fail-loud — `TextTo3DGenerator` and
its siblings are `GeneratorSeam`s that throw `GeneratorNotConfiguredError` until
a model backend is attached rather than fabricating output. The
`mesh.ts`/`media.ts`/`content.ts` post-processing is runnable locally:
`AutoRetopology`, `PBRMaterialAutoAssignment`, animation retargeting, UV-stretch
analysis, and waveform preview.

### @maya/forge-companion-glass-workshop

The transparent "Glass Workshop" workspace
(`libs/maya/forge-companion/glass-workshop/src`, 10 modules): spatial panel
layout/focus/transitions, a headless panel scene-graph renderer with VR and flat
adapters, theme and opacity engines, an LCS-based live diff viewer
(`LiveDiffPanel`, `DiffStreamRenderer`, category colour coding, approval and
history), a system dependency graph with ripple highlighting, and a
reasoning-stream model (`ReasoningStreamPanel`, `ReasoningToSpeechBridge`) that
narrates the companion's thinking. Headless UI logic — the actual surface
rendering is the client's.

### @maya/forge-companion-learning-system

Player modelling and adaptation for the Forge companion
(`libs/maya/forge-companion/learning-system/src`, three modules): `skill.ts`
per-domain skill profiling and expertise detection, `preference.ts` learning
(`AestheticPreferenceModel`, `WorkflowPatternRecognizer`,
`FeedbackSignalExtractor`, `PersonalShortcutLearner`), and `teaching.ts` with
`TeachingMode`, `GuidedModTutorials`, `ChallengeMode`, and a
`ModInspirationEngine`.

### @maya/forge-companion-mod-abstraction

The universal mod-engine abstraction
(`libs/maya/forge-companion/mod-abstraction/src`): `layers.ts` types the
four-layer stack — natural-language `ModIntent` → `SemanticAction`
(`SemanticVerb`) → `SystemCommand` → `EnginePrimitive` — with
novice/intermediate/expert `Granularity` routing, layer translation, and
transactional commit/rollback, and `src/domains/` carries typed handlers for all
12 moddable domains (asset, code, rules, world, physics, ui, audio, economy,
social, narrative, ai-behavior, accessibility).

### @maya/forge-companion-mod-sandbox

Safety and mod integrity for the Forge companion
(`libs/maya/forge-companion/mod-sandbox/src`): `runtime.ts` is a real
WebAssembly host — `WASMSandboxRuntime` instantiates mod WASM with an import
object exposing only capability-gated functions (`SandboxCapabilitySystem`,
`CapabilityViolation`) plus cooperative gas metering — and the rest covers
`SandboxResourceMonitor`, `ModIsolation` and escape detection, the
performance-budget system (`PerformanceBudgetAllocator`/`-Enforcer`,
`AdaptiveBudgetScaling`), content-policy/IP-protection seams, a voice content
filter, provenance watermarking, and multiplayer mod safety.

### @maya/forge-companion-orchestrator

The integration layer that ties the companion together
(`libs/maya/forge-companion/orchestrator/src`): `orchestrator.ts` runs the
`CompanionOrchestrator` event loop over an `EventBus` with
`PipelineLatencyMonitor`, `GracefulDegradationController`, and
`SessionStateManager`; `tools.ts` defines the LLM tool-calling surface
(`ToolDefinition`); and `adapters.ts` is the engine adapter layer — a native
`MayaEngineAdapter` plus `GodotEngineAdapter`/`UnrealEngineAdapter`/
`UnityEngineAdapter` external adapters that fail loud with
`EngineNotConnectedError` when no engine is attached.

### @maya/forge-companion-semantic-merge

Intent-aware mod conflict resolution replacing load-order last-wins
(`libs/maya/forge-companion/semantic-merge/src`) — deliberately small: one
~310-line `merge.ts` with `ModIntentExtractor`, `ConflictDetector`, typed
`ModChange`/`ModIntent`/`Conflict` shapes, directional-intent analysis
(increase/decrease/set/toggle), and `ResolutionMode` strategies.

### @maya/forge-companion-social-integration

Social and distribution integration for the Forge companion
(`libs/maya/forge-companion/social-integration/src`, four modules):
`publishing.ts` Bazaar publishing (`ModPublisher`, `VoiceModDescription`),
`forking.ts` Variants-style forking (`ModForkingInterface`,
`ForkDiffVisualization`, `UpstreamMergeNotifier`, `AttributionChainTracker`),
`governance.ts` the Agora governance bridge, and `collaboration.ts`
collaborative modding (`CollaborativeModSession`, `ModSessionVoiceChannel`,
`CollaborativeConflictResolver`, `ModSessionReplay`).

### @maya/forge-companion-voice-asr

The streaming ASR front-end of the companion voice pipeline
(`libs/maya/forge-companion/voice-asr/src`, 15 modules) — the deterministic,
locally-runnable core: spectral-gating `GameAudioNoiseFilter`,
`VoiceActivityDetector` and `UtteranceBoundaryDetector`, streaming transcript
accumulation with confidence scoring, intent parsing (`ModIntentClassifier`,
`CompoundCommandParser`, `ConditionalCommandParser`, `ClarificationGenerator`),
language detection/switching, latency scheduling, spatial-voice geometry, and
WER/latency metrics. Cloud ASR backends are honest fail-loud provider seams in
`providers.ts`, not simulated recognizers.

### @maya/forge-companion-voice-tts

Expressive TTS and multi-turn dialogue
(`libs/maya/forge-companion/voice-tts/src`): a streaming TTS provider seam that
fails loud (`TtsNotConfiguredError`, `CloudTtsProvider`, `TTSProviderFailover`)
with `SentenceChunker`/`StreamingTTSEngine` first-audio scheduling, emotion-tag
→ SSML prosody, personality voice profiles, rule-based grapheme-to-phoneme
(`wordToPhonemes`) with viseme timing, autocorrelation `ProsodyAnalyzer`, HRTF
spatial routing, a phrase cache, and dialogue management (barge-in,
confirmation, proactive suggestions, memory bridge).

### @maya/geospatial

Web-Mercator tile mathematics and streaming at `libs/maya/geospatial/src`:
`tiles.ts` implements the slippy-map tile pyramid (`lonLatToTile`, `tileBounds`,
zoom 0–21), `cache.ts` an LRU `TileCache` with a disk budget, and `streaming.ts`
predictive prefetching plus hybrid real+authored region overrides. The barrel is
honest about scope: live tile/DEM/vector ingestion and neural building
reconstruction need external APIs, large datasets, and a GPU — this library is
the addressing/caching/streaming logic they plug into.

### @maya/guild-operations

Guild day-to-day operations as a single-module model library
(`libs/maya/guild-operations/src/index.ts`, ~325 lines): project boards
(`createProjectBoard`, `updateTaskProgress`), contribution summaries by
`GuildWorkKind`, a newcomer welcome queue with `pairMentor`, calendar events
with RSVP/ownership-delegation/`expandRecurringEvent`, plus knowledge, treasury,
goal, hall-scheduling, and officer-coverage records. Pure functions over typed
records.

### @maya/guild-recruitment

Healthy guild recruitment (`libs/maya/guild-recruitment/src/index.ts`, ~410
lines): recruitment profiles and `searchGuilds`, `quickApply` and
`reviewApplication` flows, provisional trial membership with
`updateTrialChecklist`, referrals, recruiter office hours
(`scheduleOfficeHour`/`bookOfficeHour`), public pages, kiosks, and
recommendations. Model-plus-workflow helpers; no persistence of its own.

### @maya/identity

Cross-platform identity for Maya Nexus (`libs/maya/identity/src`, 19 modules):
`MayaOshunAccountService` with real PBKDF2 password hashing
(`createNodePbkdf2PasswordHasher`) and password/email validation,
`MayaOAuthIntegrationService`, `MayaTwoFactorService` with a genuine
`generateTotpCode` TOTP implementation, and `MayaPlatformComplianceLayer`
compliance gates, alongside account-merge, age gating, cross-platform ban sync,
entitlements, friends/party, sessions, SSO, security, and telemetry modules.

### @maya/jewelry

Parametric jewelry and gem generation at `libs/maya/jewelry/src`: `gems.ts` does
refractive-index optics (`criticalAngle`, `totalInternalReflection`,
`idealPavilionAngle`) over real material constants (`DIAMOND` n=2.42,
`SAPPHIRE`, `EMERALD`, `QUARTZ`) with a standard cut library, and `metalwork.ts`
builds prong/bezel/channel `Setting`s, ring bands (`makeBand`,
`bandCircumference`), chains, and matched ensembles. The barrel states plainly
that mesh LOD generation and character try-on physics belong to the
render/physics layers — this is the parametric math.

### @maya/lfg-community

Community-first looking-for-group (`libs/maya/lfg-community/src/index.ts`, ~480
lines): listings (`createListing`, `createListingFromQuest`), applications
(`requestJoin`, `reviewApplicant`), `routeBackfillCandidates`, ready-up flows
(`createReadyCheck`, `confirmReady`), `buildExpectationSummary`, scheduling,
regroup, and squad templates. A pure in-memory rules layer for the social LFG
path, sibling to `@maya/social-discovery`.

### @maya/live-events

Live-event orchestration for synchronized Maya world events
(`libs/maya/live-events/src`, 16 modules): a `MayaGlobalEventStateCoordinator`
state machine, event sequences/cameras/replays, countdown notifications, asset
preloading, instance scaling, participation tracking, limited-time modes,
world-state mutation (`MayaLiveEventWorldMutationService`), and a seasonal tier
(season pass progression via `MayaSeasonPassProgressionService`, seasonal
content, leaderboards, world changes, archives, analytics). Each service fails
loud through its own typed error class; the barrel exports a package descriptor
enumerating capabilities.

### @maya/mentorship

Social onboarding and mentorship (`libs/maya/mentorship/src/index.ts`, ~375
lines): `detectPlayerLifecycle` over lifecycle signals, onboarding journeys with
milestone recovery after churn (`createOnboardingJourney`,
`recoverMilestonesAfterChurn`), `routeHelpQuestion`, a mentor registry
(`registerMentor`, `updateMentorCertification`, `matchMentors`), returner
rescue, protected cohorts, and mentor quality tracking. Pure typed helpers for
the Social Fabric layer.

### @maya/npc-agency-orchestrator

Phase 83 NPC agency orchestration
(`libs/maya/npc-agency-orchestrator/src/index.ts`, ~640 lines):
`generateEmergentGoals` derives goals from an `NpcAgencyContext` using emergent
goal templates, circumstance triggers, emergency and player-interaction goals;
`validateGoalCoherence` filters incoherent goals; `logNarrative` records the
resulting story beats and `populationGoalDistribution` reports goal spread
across the NPC population.

### @maya/npc-cloud-fallback

Hybrid cloud-LLM fallback orchestration for complex NPC reasoning
(`libs/maya/npc-cloud-fallback/src/index.ts`, ~215 lines) — the policy layer,
not the transport: `CloudQueryManager` is a narrative-importance priority queue
with concurrency and rate limits, plus `CloudResultCache`,
`createMultiNpcReasoningRequest`, latency-tolerant result integration,
`distillCloudResult` back into local decision rules, a deterministic
`offlineFallbackDecision`, and `applyCloudSafetyLayer`. Actual calls to the
typed `CloudProviderKind` backends (claude/gemini/gpt/vllm) are the caller's.

### @maya/npc-cooperation-negotiation

The smallest Phase 83 NPC library
(`libs/maya/npc-cooperation-negotiation/src/index.ts`, ~120 lines):
`detectSharedGoal` across `NegotiatingNpc`s, `createCooperationOffer`,
`acceptanceScore`, `negotiateCooperation`, and `assignRoles`, producing group
schedules and narrative hooks for cooperating NPCs. Deliberately compact pure
logic.

### @maya/npc-distillation

Teacher–student NPC cognition distillation
(`libs/maya/npc-distillation/src/index.ts`, ~370 lines): `SlmDecisionLogger` and
a `DecisionRingBuffer` capture SLM decisions,
`compressContextToPersonalityInput` reduces full context to a
`PersonalityVector12`, then `filterHighQualityRecords`,
`stratifiedSampleByArchetype`, and `createVersionedDataset` build training sets
for `trainOfflineDistillation`, with A/B rollout (`assignAbWeights`,
`compareAbCoherence`), deployment packaging, and a distillation dashboard. The
"training" here is the deterministic dataset/weight-evaluation pipeline in TS —
GPU training infrastructure is out of scope.

### @maya/npc-occupations

NPC occupation simulation at `libs/maya/npc-occupations/src`: `templates.ts`
holds the committed `OCCUPATIONS` catalog (40+ templates) with category queries,
`work.ts` computes work behaviour and production (`produceOutput`,
`qualityFromSkill`, `gainSkill`, schedule checks), `career.ts` drives worker
lifecycle (`hire`/`fire`/`changeCareer`, apprentice graduation, retirement), and
`worldgen.ts` assigns occupations to settlement populations (`assignOccupations`
over `SettlementNeeds`). The barrel notes the economy-system integration is left
to the economy domain this library feeds.

### @maya/orchestration

Deployment orchestration for Maya simulation fleets
(`libs/maya/orchestration/src`, 23 modules): `MayaFleetManagementService`,
Agones and Edgegap integrations, autoscaling, blue-green/canary/hotfix/
zero-downtime deployment services (e.g. `MayaCanaryDeploymentService` with typed
policies), multi-region fleets with geographic routing, latency probes, region
failover and cross-region transfer, a global session directory, client-version
gating, health monitoring, and capacity/deployment dashboards. Each module pairs
a service class with a fail-loud error type; it is the control-plane logic, not
the cloud provisioning itself.

### @maya/ornament

Procedural ornamental pattern generators emitting 2D curve/point data at
`libs/maya/ornament/src`: `curves.ts` produces `guilloche`, Greek-key `meander`,
and `filigree` scrolls, and `interlace.ts` produces `islamicStar` and `rosette`
patterns, `torusKnot`s, `celticPlait` over/under matrices, and braid-group
`braid`s. The barrel is explicit that extruding these into 3D relief and mapping
onto meshes belongs to the geometry/render layer — this library is the pattern
mathematics.

### @maya/politics

Government and faction simulation at `libs/maya/politics/src`, inspired by CK3
and Dwarf Fortress: `government.ts` maps `GovernmentType`s and policies to
`governanceEffects`, `factions.ts` runs faction power, loyalty, and civil-unrest
escalation (`unrestLevel` from content through riots to `rebellion`), and
`diplomacy.ts` covers stances, treaty acceptance, refugees, elections
(`runForOffice`), and bribery. It integrates with the Hathor faction system at
the `Faction` boundary and emits gossip-shaped news via `toGossip`.

### @maya/social

The Maya Nexus social platform library (`libs/maya/social/src`, 16 modules): the
~840-line `index.ts` implements `MayaSocialService` — an in-memory
friends/presence/follow/activity engine (`addFriendship`, `followPlayer`,
`recordActivity`, `suggestFriends`, social analytics) with a typed
`MayaSocialError` — alongside party, guild, chat and chat-formatting,
smart-ping, communication-wheel modules and a voice tier (spatial voice, VAD,
push-to-talk, volume, moderation, effects, noise suppression, server
infrastructure, VR integration).

### @maya/social-discovery

Intent-aware discovery for Maya Social Fabric
(`libs/maya/social-discovery/src/index.ts`, ~455 lines):
`buildHomeDiscoveryFeed`, `recommendPeopleYouShouldMeet`, `recommendGuilds`,
`discoverEvents`, `buildReturnerResurfacing`, and a deliberate
`buildLowPressureLane` for players who want low-stakes contact, plus
`applyDiversityGuardrails` and notification-policy evaluation to keep
recommendations from becoming spammy or homogeneous.

### @maya/social-events

Festival/market/performance simulation at `libs/maya/social-events/src`:
`schema.ts` models `SocialEvent`s with a scheduled→preparation→active→cleanup
`EventPhase` lifecycle, `calendar.ts` derives seasons and scheduled/dynamic
events (`seasonOf`, `dynamicEvent`), and `activities.ts` simulates street
performers (`performerCrowd`, `coinsTossed`), vendors (`shopperBuys`), and
tavern drunkenness (`drunkModifier`), including festival mini-games and NPC
schedule overrides. Ambient audio and speech bubbles are the engine's rendering
concern.

### @maya/social-facilitation

Consent-first AI social facilitation
(`libs/maya/social-facilitation/src/index.ts`, ~275 lines): opt-in
`AiOptInSettings` gating every feature (`isFeatureEnabled`), companion profiles,
`suggestGroups`, disclosed AI introductions (`generateWingmanIntroduction`),
rehearsal sessions, party concierge summaries, participation nudges,
novice-question routing, mentor/returner assistants, memory controls, and
evaluation shapes. The disclosure/opt-in gating is built into the types, not
bolted on.

### @maya/social-graph

The intent-aware player social graph model
(`libs/maya/social-graph/src/index.ts`, ~390 lines): a
`createDefaultPrivacyMatrix` privacy layer with `canViewField` checks,
`computeReliabilityScore`, `aggregatePresence` over presence signals,
relationship-kind counting, comfort tags, and `buildFeatureProjection` — the
projection other Social Fabric libraries (discovery, LFG, facilitation) consume
instead of raw graph data.

### @maya/spectator

Spectator and broadcast primitives for Maya Nexus (`libs/maya/spectator/src`, 14
modules): camera systems (directed camera, free camera, player lock, X-ray
observer, picture-in-picture, minimap overview), a `MayaKillCamService` and
`MayaPlayOfGameService`, and a full replay tier (storage, rendering, highlight
detection, annotation, sharing, timeline UI), each service paired with a typed
fail-loud error class. Control-plane logic for spectating — actual frame
capture/encoding is the engine's.

### @maya/tournaments

Tournament and esports infrastructure as one very large module
(`libs/maya/tournaments/src/index.ts`, ~12,100 lines, 163 exported
classes/functions/interfaces): typed tournament formats, seeding methods, and
registration guards (`isMayaTournamentFormat` and friends) feeding per-subsystem
services that each fail loud through their own error class — creation, bracket
formats, seeding, registration and entry fees, scheduling, dedicated-server
reservation, match results, anti-cheat escalation, the observer system, and
streaming integration.

### @maya/trust-safety

Community trust & safety for Maya Social Fabric
(`libs/maya/trust-safety/src/index.ts`, ~245 lines): `evaluateOnboardingGate`,
channel selection, `moderateText` against a `LocalizedModerationPolicy`,
`processVoiceSafety`, report intake into `ModeratorCase`s with
`updateModeratorCase` action history, plus retention, report-sync, localization,
and safety-dashboard shapes. The moderation here is the deterministic
policy/case layer, not an ML classifier.

### @maya/ugc-runtime

The sandboxed UGC multiplayer runtime foundation
(`libs/maya/ugc-runtime/src/index.ts`, ~5,450 lines, 42 exported functions):
script-API policy construction (`createMayaUgcScriptApiPolicy`), a scene-graph
state machine with validated mutation application
(`applyMayaUgcSceneGraphMutation`/`-Mutations`), game-mode templates
(list/get/`instantiateMayaUgcGameModeTemplate`), creator documentation and
tutorial-progress tracking, and server-authority plus hot-reload policies. It is
the typed policy/state layer of the runtime — script execution itself happens in
the engine sandbox.

### @maya/urban-evolution-manager

Phase 83 urban evolution scheduling
(`libs/maya/urban-evolution-manager/src/index.ts`, ~165 lines):
`scheduleConstruction` driven by `constructionDemand`, `scheduleDecay`,
`scheduleDisasterRecovery`, seasonal visual changes, a `timeline` view over
`UrbanChange`s, and `playerImpact` attribution. Compact pure scheduling logic
for city change over time.

### @maya/voice-dialogue

NPC voice dialogue sessions (`libs/maya/voice-dialogue/src/index.ts`, ~230
lines): `shouldInitiateConversation`, `startDialogueSession` and turn-taking
(`manageTurnTaking`, `recordTurn`), `buildNpcSystemPrompt` for the LLM path plus
a deterministic rule-based `generateNpcResponse` bounded by the NPC's typed
knowledge (it answers "I don't know that." rather than inventing facts),
consequence derivation, conversation memory, eavesdropping, groups, and
transcript logging. The LLM transport itself is not in this library.

### @maya/voice-narrative

Phase 83 voice-driven emergent narrative consequences
(`libs/maya/voice-narrative/src/index.ts`, ~180 lines): `detectConsequences`
from player speech, promise tracking (`trackPromise`/`resolvePromises`),
`propagateLie` through rumor spread, `reputationFromWord`, emotion effects, and
`detectNarrativeArc` over accumulated consequences. What players say to NPCs
becomes durable world state.

### @maya/voice-negotiation

Voice negotiation mechanics for NPC conversations
(`libs/maya/voice-negotiation/src/index.ts`, ~185 lines): `detectNegotiation`
classifies an utterance into a `NegotiationKind`
(persuasion/intimidation/deception/trade/faction), `scoreArgument` against
context, personality-derived `resistance`, `resolveNegotiation` and multi-round
`nextRound` state, witness effects, and `rememberPromise` negotiation memory.

### @maya/voice-tactics

Natural-language squad command processing
(`libs/maya/voice-tactics/src/index.ts`, ~240 lines):
`createCommandPromptTemplate` over `SquadState`, `decomposeCommand` into an
`ExecutionPlan` with temporal dependencies and signal groups, `validatePlan`
issue detection, `executeSignal` releasing held actions, standing orders, and
`createPlanPreview` HUD markers so the player can confirm before execution.

### @maya/voice-tts

Gameplay NPC voice-output policy (`libs/maya/voice-tts/src/index.ts`, ~175 lines
— distinct from `@maya/forge-companion-voice-tts`): `createVoiceProfile`
personality-matched profiles, `modulateEmotion` producing `SynthesisParams`,
`applyTacticalBrevity` text compression under combat context, priority queues
(`enqueueVoice`), `precacheCommonCallouts`, `estimateVisemes` lip-sync hooks,
spatial/radio filters, and `benchmarkQuality`. It emits synthesis parameters and
queue decisions — the audio synthesizer itself lives elsewhere.

### @maya/world-history

Legends Mode over generated history at `libs/maya/world-history/src`:
`legends.ts` builds a queryable `Legends` encyclopedia from the
maya-world-history Rust generator's `WorldHistory` output —
figure/artifact/war/civilization lookups over typed `HistoryEntry` kinds, era
grouping, and timeline filtering. The barrel notes the timeline visualization
rendering is the app's; this is the query layer feeding it.

### @maya/world-social-runtime

In-world social infrastructure (`libs/maya/world-social-runtime/src/index.ts`,
~205 lines): social hub templates, interactive boards, public co-op rituals
(`createPublicCoopRitual`), guild fairgrounds, social memory surfaces, recurring
community-event expansion, NPC anchor points, and quiet social zones
(`createQuietSocialZone`), each constructor validating its typed record.
Definitions and validation for the world layer — spawning them into a running
world is the engine's job.