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-capturecompute deterministic GPU/ML plans (NRC architecture, MegaLights, 4D Gaussian-splat training) with real domain math;scene,world,physicsare smaller "readiness facade" libraries. - Immersion & interop —
vr-studio,vr-studio-web,spatial-ar,standardsplan VR/WebXR sessions, persistent AR anchoring, and OpenUSD/glTF/VRM interoperability. - Application platform —
games,server,client,database,moderation,future-input,inspirations,documentation,testing,toolingare 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/loaderforge-core,forge-compositorlayer composition, semanticforge-conflictresolution,forge-resolver(PubGrub-shape) dependency solving, theforge-sandbox+forge-hot-reloadruntimes, theforge-assetspipeline, 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 cratesforge-compat(cross-game-version API grading + shims) andforge-cross-platform(per-platform packaging across nine targets). - Forge studios (Ixchel creator tools) — eight dual Rust+TS crates carrying
layer:ixchelthat 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 studiosforge-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 cratesloom-semantic(semantic-brush → terrain/erosion guidance masks),loom-diffgen(differentiable-procedural baseline with analytic gradients),loom-terrain-mlandloom-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-coreis a std-only headless simulation engine (fixed-dt tick loop, seededDeterministicRng, snapshot/replay, parallel campaign sweeps);crucible-agentsprovides scripted/heuristic AI opponents with fog-of-war observation;crucible-adversarialstatically hunts game-breaking exploits (positive-cycle DFS, one-shot-combo and invincibility scanners) over typed mod models;crucible-balance,-scenarios,-regression, and-liverun the statistics (Wilson intervals, Gini, Shannon entropy, pairwise covering arrays, Bonferroni A/B regression, z-fingerprint drift);crucible-governanceis 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, andinstancingare reallayer:domainTypeScript logic libraries for the player-facing path into a match:matchmakingis 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),lobbiesis the deterministic pre-game core (lobby lifecycle state machine, invites/deep-links, ready-check, server browser, reconnect grace, custom-game configuration), andinstancingis 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-occupationsplusanimal-database,ecology,economy-tools,env-storytelling,geospatial,jewelry,ornament,politics,social-events, andworld-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; theirproject.jsonsourceRootfields all point atnpc-occupations, but each has real code in its ownsrc/. - 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, theCompanionOrchestrator, 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 sixcommunity-*libraries (companion surface, federation, governance, health, recognition, reputation),trust-safety, andworld-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, andugc-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), andurban-evolution-manager, plus thevoice-dialogue/voice-narrative/voice-negotiation/voice-tactics/voice-ttsquintet: 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 catalog (163)#
The 163 tracked Nx projects in maya, each a code-linked entity node — package, type, source path, declared targets, and its internal dependency graph (depends-on / used-by, resolved from the package manifests, §6/§8), read from the project graph. Grouped by architectural layer; walk the dependency links to travel the system. 163 of these carry an authored deep-dive (what / why / how it fits); the rest are generated scaffolds awaiting one.
agora (7)#
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 EmergencyPowers, 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_templates (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.
Right1ConstitutionFormat8GovernanceActionKind9ConstitutionTemplateKind10TierRule16ProtectedParameter23AmendmentProcess29EmergencyPower35EconomicConstitution41ConstitutionHistoryEntry48GameConstitution54GovernanceAction66EmergencyInvocation76EconomicAmendment82 +10 moreA 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 GovernanceConfigs
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.
GovernanceTier1VotingModel2GovernanceConfig9ThemisBridgeBinding19GovernanceEvent26createThemisBridge41resolveGovernanceConfig50canPerformGovernanceAction63summarizeGovernanceEvents76A 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 BTreeMaps holds
CouncilDefinitions, time-bounded CouncilMembers, and topic-scoped
DomainDelegates (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).
ElectionMethod1DomainScope2AuthorityScope3CouncilDefinition5CouncilMember15DomainDelegate24RankedChoiceBallot31RankedChoiceRound36ElectionOutcome41OptimisticProposal46CouncilVote56MeetingSummary64CouncilDashboard71CouncilRecall79 +15 moreA 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
RecallElections 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.
TopicScope1DelegationRegistration3VoteSnapshot11DelegateVote17DelegationChain25DelegateDashboard30RecallElection38DelegationRegistry45createDelegationRegistry54setVoterPower65registerDelegation76revokeDelegation99beginVoteSnapshot109effectivePower123 +5 moreA 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 ProposalTypes (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.
ProposalType1ProposalState11ProposalChangeSpec22Proposal56ProposalCreateInput74ProposalSearchFilter76QualityGateReport87createProposal94passesSubmissionGate98passesQualityGate106isEmergencyFastTrackEligible115advanceProposalState123searchProposals149A 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.
PlayProfile1ProofOfPlayScore10ReputationStake15IdentityProof22EncryptedVote30RevealedVote37MaciRound42FundingContribution49ProjectFunding55VoteAccountSnapshot62BrigadingReport69VoteSignal77VoteAnomalyReport84proofOfPlayScore92 +12 moreA 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.
VotingModel1ProposalType14GovernanceTier20VoteOutcome22tallyQuadraticVotes29evaluateSupermajority48recommendVotingModel65bazaar (4)#
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.
MarketplacePlatform1ReportReason2ModManifest4ModAsset16MediaAsset24ModVersion30ModPackage39ValidationIssue47ValidationReport53ModListing58DiscoveryFilter73DiscoveryResult81ModReview90ModPage101 +19 moreA 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 RevenueRequirements. The
real work is compatibility: checkPairwiseCompatibility,
checkLicenseCompatibility, and scanLicenseViolations walk a mod's dependency
graph and emit coded LicenseIssues (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.
LicenseType1LicensePermission10LicenseRestriction20LicenseObligation28RevenueRequirement36MachineReadableLicense43LicensedMod55CompatibilityContext63LicenseIssue67CompatibilityReport75LicenseInheritanceResult82CustomLicenseDraft91LicenseSummary101DerivativeLink109 +8 moreA 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."
PricingModelKind1SubscriptionPeriod11PricingModel13ContributionType26RevenueAllocationType34RevenueSplit36RevenueMod45DependencyTaxSuggestion54DependencyTaxProfile60Attribution68AttributionVerifier80AttributionVisualization84AttributionContributor91AttributionEdge99 +34 moreA 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 TreasuryFundingSources (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.
TreasuryFundingSource1TreasurySpendingCategory7ProposalState15VoteChoice16BountyState17EventState18MultiSigState19TreasuryConfig21CommunityTreasury36TreasuryLedgerEntry48TreasuryFundingInput61TreasurySpendingProposal70TreasuryVote85ModBounty92 +21 morecrucible (8)#
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 ExploitKinds. 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.
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 ScriptedBehaviors 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
MatchRecords, 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.
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 LetterGrades.
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.
BalanceGrade1BalanceCategory3BalanceMetricSummary13BalanceCategoryGrade20BalanceScorecard27HeatmapCell35HeatmapRow43PickWinPoint48PickWinQuadrant54ScatterClassification56buildBalanceScorecard62heatmapRows88classifyPickWinScatter100recommendationsFor141A 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.
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
BalanceMetrics, 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.
ProposalProcess1SeverityTier2ArchiveEventKind3BalanceMetric10BalanceFingerprint16MetricImpact24SimulationBudget34ProposalImpactSimulation40WhatIfQuery51WhatIfResult59DashboardElement66ExploitBadge74BalanceHealthDashboard80AdvisorRecommendation98 +15 moreA 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 AlertChannels 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.
CRUCIBLE_LIVE_SCHEMA_VERSION1AlertSeverity3PickWinQuadrant4MetaPattern5AlertChannel6LiveWinRate8PickRateInput19PickRatePoint26DriftFinding32AnomalyFinding41SentimentFinding48MetaReport57LiveAlert64LiveDashboardInput74 +9 moreA 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 MetricFingerprints 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
AlertChannels, 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.
DiffColor1GateResponse2MonitoringTier3AlertChannel4MetricDiff10GateDecision22RegressionReport30PopularModCombination37MonitoringJob42TrendPoint48TrendSummary54BalanceAlert62buildRegressionReport69evaluateGate88 +4 moreA 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 ScenarioFindings 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.
CoverageGrade1ScenarioDefinition3ScenarioSchema15CoverageSummary23PriorityInput31RankedScenario39ValidationResult45coverageGrade50buildCoverageSummary57rankScenarios77validateScenario95pairKey120coveredPairs129domain (89)#
community-* (6)#
Companion web/mobile community APIs, discovery models, synchronized calendars, public profiles, deep links, notifications, bridges, RSVP flows, webhooks, and connected-account privacy controls
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.
CompanionSurface1FinderItemKind2DeepLinkKind3NotificationTopic4ExternalBridgeKind5RsvpStatus6WebhookAudience7PresenceSharing8CompanionFinderItem10CompanionCalendarEvent19PublicCommunityProfile29CompanionDeepLink42NotificationPreferences49ExternalCommunityBridge55 +12 moreAlliance, guest access, coalition, diplomacy, partner discovery, and governance templates for Maya Social Fabric
The inter-community diplomacy model
(libs/maya/community-federation/src/index.ts, ~215 lines): Alliance records
with member guilds, channels, events, and GovernancePermissionTemplates, 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.
DiplomaticState1AlliancePermission2CoalitionKind12AllianceMemberGuild14AllianceChannel22AllianceEvent28GovernancePermissionTemplate36Alliance42GuestAccessPass51AllianceProject61TemporaryCoalition71AllianceDiscoveryProfile81AllianceReferral90createAlliance99 +12 moreLeadership workflows, role templates, governance notes, staffing, succession, culture templates, and operations runbooks for Maya communities
Community-leadership workflows as a typed model library
(libs/maya/community-governance/src/index.ts, ~270 lines): leadership role
templates and GovernancePermissions, 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.
GovernanceScope1LeadershipDomain2GovernancePermission3GovernanceDecisionStatus12AmbassadorTrack13StaffingKind14CultureTemplateKind15RunbookKind16LeadershipRoleTemplate18EventStaffSlot26DelegatedEventPlan33GovernanceNote41GovernancePoll50GovernanceDecision58 +17 moreCommunity health metrics, warehouse schemas, social cohort analytics, funnels, safety analytics, risk models, experiments, dashboards, and intervention playbooks for Maya
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.
WarehouseEventKind1CohortMetricKind2DashboardAudience3ExperimentSurface4InterventionKind5MetricDefinition7WarehouseSchema15CohortMetric21FunnelStep29FunnelAnalytics34SafetyTrustAnalytics40PlayerRiskSignals48RiskScore57ExperimentAssignment64 +12 moreProsocial badges, ceremonies, appreciations, graduation moments, memory systems, invisible labor recognition, and incentive guardrails for Maya communities
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.
RecognitionBadgeKind1MilestoneKind2AppreciationKind3GraduationKind4MemoryArtifactKind5InvisibleLaborKind6RecognitionQualitySignals8BadgeRule15EarnedBadge22MilestoneCelebration30Appreciation39GraduationMoment48MemoryArtifact57InvisibleLaborRecord67 +8 morePrivate reliability, endorsements, compatibility, recovery workflows, anti-abuse protections, fairness audits, and selective trust surfacing for Maya Social Fabric
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.
EndorsementKind3TrustMarker10AvoidScope11RecoveryStatus12TrustSurfaceContext13PrivateReliabilityModel15Endorsement24TrustMarkerSet33AvoidBlockPreference40CompatibilityInput48CompatibilityScore58RecoveryWorkflow63ReputationAbuseAudit71FairnessAuditInput77 +12 moreforge-* (13)#
AI co-creation for the V7 forge with static policy and mandatory Moremi Wasmtime admission
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).
CapabilityPolicy12DEFAULT_REALM_CAPABILITY_POLICY12xtractInvokedCapabilities12CapabilityViolation12PolicyVerdict12FORGE_SANDBOX_ADMISSION_SCHEMA_VERSION20ForgeSandboxAdmissionError20MoremiForgeSandboxClient20assertReceiptBinding20createMoremiForgeSandboxFromEnv20ForgeSandboxAdmission20ForgeSandboxAdmissionReceipt20ForgeSandboxAdmissionRequest20ForgeSandboxViolation20 +20 moreAvatar controller for the Maya Forge companion: FACS Action-Unit blend-shape driver, VAD-emotion→FACS mapping, micro-expressions, expression transition easing & layer compositing, blink/gaze/pupil controllers, 60+ expression presets, and realtime phoneme→viseme lip sync with co-articulation, emotion modulation, emphasis, and sync-drift monitoring.
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.
End-to-end integration tests for the Maya Forge companion (Phase 78.15): voice pipeline, avatar animation, glass workshop, mod engine, and full-system/stress/multiplayer/cross-engine integration tests wiring the real forge-companion libraries together.
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.
Real-time generation pipeline for the Maya Forge companion: generation orchestration (priority queue, resource budgets, progress streaming, mid-generation feedback, quality gate, cost estimation, semantic cache), fail-loud generator seams for text-to-3D/texture/animation/audio/code/narrative/world, and real mesh retopology, PBR auto-assignment, animation retargeting, UV-stretch analysis, waveform preview, and API discovery.
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 GeneratorSeams 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.
Glass Workshop transparent workspace for the Maya Forge companion: spatial panel layout/focus/transition logic, headless panel scene-graph renderer, VR/flat adapters, theme & opacity engines, LCS-based live diff viewer with streaming/annotations/approval/history, system dependency graph with ripple highlighting and warning analysis, and a reasoning-stream model with narration bridge.
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.
Learning & adaptation system for the Maya Forge companion: per-domain skill profiling, expertise detection, adaptive complexity control, skill-progression tracking, aesthetic preference modeling, workflow pattern recognition, implicit feedback extraction, personal shortcut learning, and teaching/challenge/inspiration/cross-session-continuity modes.
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.
Universal mod engine abstraction for the Maya Forge companion: the four-layer stack (natural language -> semantic actions -> system commands -> engine primitives) with layer translation, granularity routing, transactional commit/rollback, multi-layer validation, and typed handlers for all 12 moddable domains (asset, code, rules, world, ui, narrative, physics, ai-behavior, audio, economy, social, accessibility).
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).
Safety, sandboxing & mod integrity for the Maya Forge companion: real WebAssembly sandbox runtime with capability-gated imports and cooperative gas metering, resource monitor, mod isolation, escape detection, performance-budget allocation/enforcement, content-policy & IP seams, voice content filter, provenance watermark, and multiplayer mod safety (negotiation, server-authoritative validation, compatibility matrix, anti-cheat).
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.
Integration orchestration for the Maya Forge companion: the CompanionOrchestrator event loop (voice->ASR->intent->reason->mod->workshop->TTS->avatar), typed EventBus, pipeline latency monitor, graceful degradation, session state persistence, LLM tool-calling (definitions/executor/formatter/parallel/audit), and the engine adapter layer (Maya/Godot/Unreal/Unity) with capability discovery.
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.
Semantic mod merging for the Maya Forge companion: intent-aware conflict resolution replacing load-order — mod intent extraction, semantic conflict detection (scope-aware), six resolution strategies (average/prioritize/scope-split/parameterize/compose/creative), merge preview, and a mod dependency graph for safe removal/reordering.
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.
Social & distribution integration for the Maya Forge companion: Maya Bazaar publishing (mod packaging, voice-interview descriptions, dependency bundling), Maya Variants forking (attribution chain, fork diffs, upstream merge notification), Maya Agora governance (canonical voting, curation scoring, collections, revenue tracking), and collaborative modding (shared sessions, spatial voice channel, conflict resolution, replay).
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).
Voice ASR pipeline for the Maya Forge companion: streaming provider seam, game-audio noise filtering (spectral gating), energy/ZCR voice activity detection, utterance segmentation, streaming transcript accumulation, confidence scoring, provider failover, language detection, and WER/latency metrics.
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.
Voice TTS & dialogue for the Maya Forge companion: fail-loud streaming TTS provider seam with sentence-chunked first-audio scheduling, emotion-tag→SSML prosody parsing, personality voice profiles, adaptive speech rate, rule-based grapheme-to-phoneme with viseme timing for lip sync, autocorrelation prosody analysis, HRTF spatial audio routing, phrase cache, voice-embedding consistency guard, and multi-turn dialogue management (interruption/barge-in, confirmation protocol, proactive suggestions, multimodal fusion).
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).
genesis-* (9)#
TypeScript facade for Maya Genesis procedural vegetation and landscape generation readiness
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).
MayaGenesisFloraReadiness1MayaGenesisFloraScale2MayaGenesisFloraBiome3MayaGenesisFloraTreeGenerationConfig12MayaGenesisFloraDistributionConfig23MayaGenesisFloraEcologyConfig38MayaGenesisFloraRenderExportConfig49MayaGenesisFloraExoticBiomeConfig61MayaGenesisFloraLandscapeInput72MayaGenesisFloraLandscapeIssue92MayaGenesisFloraLandscapeEvaluation108evaluateMayaGenesisFloraLandscape256Neural cellular automata generators for Maya exotic biome morphogenesis
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.
MayaNcaExoticBiomeType1MayaNcaChannel3MayaNcaSeedCell5MayaNcaTrainingExemplar13MayaNcaTrainingInput23MayaNcaRuleDiagnostics31MayaNcaExoticBiomeRule42MayaNcaTextureGenerationInput59MayaNcaGeneratedCell68MayaNcaGrowthTraceSample74MayaNcaGeneratedTexture81MayaNcaLivingTerrainSurfaceType98MayaNcaLivingTerrainEnvironment104MayaNcaLivingTerrainInput114 +74 moreNeural L-system vegetation growth tools for Maya Genesis procedural 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.
MayaNeuralFloraVector31MayaNeuralFloraEnvironment7MayaNeuralLSystemSymbol14MayaNeuralProductionRuleId15MayaNeuralLSystemToken21MayaNeuralTransformerConfig32MayaNeuralLSystemGrowthInput40MayaNeuralAttentionWeights49MayaNeuralProductionDecision56MayaNeuralLSystemBranch65MayaNeuralLSystemGrowthResult74MayaLiDARFloraSpeciesId86MayaLiDARPoint88MayaLiDARSpeciesTrainingSample95 +49 morePhysarum-inspired infrastructure network generation for Maya Genesis worlds
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.
MayaPhysarumSettlement1MayaPhysarumTerrainGrid8MayaPhysarumRoadNetworkInput16MayaPhysarumRoadGraphNode26MayaPhysarumRoadGraphEdge34MayaPhysarumTrailCell45MayaPhysarumGpuDispatchPlan51MayaPhysarumRoadNetworkPlan60MayaPhysarumTradeSettlement71MayaPhysarumTradeRouteInput75MayaPhysarumTradeRouteEdge84MayaPhysarumTradeRoutePlan90MayaPhysarumUndergroundSource101MayaPhysarumUndergroundVolume110 +33 moreLLM-agent scene and world orchestration tools for Maya Genesis
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.
MayaSceneAgentVector31MayaProceduralSceneProgramOperation7MayaSceneProgramPositionExpression12MayaSceneProgramParameterValue30MayaProceduralSceneProgramCall32MayaSceneProgramPlacement41MayaSceneProgramDiagnostic55MayaProceduralSceneProgramExecutorInput62MayaProceduralSceneProgramExecutionResult69MayaWorldCreationToolKind78MayaNaturalLanguageWorldCreationInput80MayaWorldCreationIntent88MayaWorldCreationToolInvocation97MayaNaturalLanguageWorldCreationResult105 +33 moreSketch-to-terrain control tools for Maya Genesis procedural terrain
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.
MayaSketchPoint1MayaTerrainSketchGrid7MayaRidgeSketchInput13MayaRidgeSketchCell23MayaRidgeSketchResult30MayaValleySketchInput43MayaValleySketchCell54MayaValleySketchResult62MayaRiverSketchInput70MayaRiverSketchCell84MayaRiverSketchResult95MayaCliffDropSide106MayaCliffSketchInput108MayaCliffSketchCell121 +48 moreTypeScript facade for Maya Genesis procedural outdoor terrain generation readiness
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.
MayaGenesisTerrainReadiness1MayaGenesisTerrainScale2MayaGenesisTerrainBiomeMode3MayaGenesisTerrainHeightfieldConfig5MayaGenesisTerrainClimateBiomeConfig15MayaGenesisTerrainErosionHydrologyConfig27MayaGenesisTerrainStreamingLodConfig37MayaGenesisTerrainMaterialExportConfig46MayaGenesisTerrainEnvironmentInput55MayaGenesisTerrainEnvironmentIssue74MayaGenesisTerrainEnvironmentEvaluation90evaluateMayaGenesisTerrainEnvironment221Aperiodic tiling and anti-repetition terrain chunking for Maya Genesis worlds
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.
MayaWangTerrainEdgeDirection1MayaAperiodicMonotileKind2MayaAperiodicMonotileSurfaceKind3MayaAperiodicMonotileMaterialRole4MayaTerrainTextureChannel5MayaWangDungeonConnectionKind6MayaWangDungeonRoomKind7MayaAperiodicCityBlockShape16MayaAperiodicCityZone23MayaTilingTechniqueKind30MayaAperiodicMonotilePoint36MayaAperiodicMonotilePatternInput41MayaAperiodicMonotileTile54MayaAperiodicMonotileProof74 +47 moreTypeScript facade for Maya Genesis procedural city and building generation readiness
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.
MayaGenesisUrbanReadiness1MayaGenesisUrbanScale2MayaGenesisUrbanArchetype3MayaGenesisUrbanRoadNetworkConfig12MayaGenesisUrbanParcelZoningConfig21MayaGenesisUrbanBuildingConfig31MayaGenesisUrbanInfrastructureConfig42MayaGenesisUrbanRenderExportConfig52MayaGenesisUrbanEnvironmentInput62MayaGenesisUrbanEnvironmentIssue80MayaGenesisUrbanEnvironmentEvaluation96evaluateMayaGenesisUrbanEnvironment224npc-* (5)#
Phase 83 NPC agency orchestration: emergent goal templates, circumstance triggers, emergency goals, player interaction goals, coherence checks, and narrative logging.
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.
GoalType1GoalTemplate33PersonalitySignals41NpcAgencyContext56EmergentGoal72NarrativeLogEntry81GOAL_TEMPLATES88GOAL_TEMPLATE_COUNT315generateEmergentGoals317validateGoalCoherence596logNarrative611populationGoalDistribution622Hybrid cloud LLM fallback orchestration for complex Maya NPC reasoning
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.
CloudProviderKind1CloudAction2NpcReasoningParticipant4CloudReasoningRequest12CloudReasoningResult21ProviderStatus33DistillationCompatibleRecord40CloudQueryManager53createMultiNpcReasoningRequest87integrateLatencyTolerantResult101CloudResultCache109distillCloudResult129offlineFallbackDecision146applyCloudSafetyLayer161 +3 morePhase 83 NPC cooperation negotiation: shared-goal proposals, acceptance scoring, role prompts, group schedules, and narrative hooks.
The smallest Phase 83 NPC library
(libs/maya/npc-cooperation-negotiation/src/index.ts, ~120 lines):
detectSharedGoal across NegotiatingNpcs, createCooperationOffer,
acceptanceScore, negotiateCooperation, and assignRoles, producing group
schedules and narrative hooks for cooperating NPCs. Deliberately compact pure
logic.
CooperationKind1NegotiatingNpc8CooperationOffer21NegotiationResult29detectSharedGoal37createCooperationOffer46acceptanceScore65negotiateCooperation80assignRoles103Teacher-student NPC cognition distillation pipeline for SLM decisions and tier-2 personality neural network training
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.
ActionCategory1actionCategories11PersonalityVector1222FullSlmContext37SlmDecisionInput48VersionTag62DistillationRecord68DistillationDataset72PersonalityNnWeights77TrainingMetrics84DeploymentPackage92DistillationDashboard99DistillationScheduleDecision104AbAssignment110 +15 more40+ NPC occupation templates with work behavior, production, skill progression, career dynamics, and world-generation job assignment
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.
social-* (5)#
Friend, presence, follow, activity, suggestion, and social analytics systems for Maya Nexus
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).
FriendRequestStatus17PresenceStatus18ActivityVisibility19SocialNotificationKind20ActivityFeedKind28InteractionKind34FriendRequestRecord36SocialNotification46PresenceRecord56FriendListEntry67BlockMuteRecord75FollowRecord84ActivityFeedItem90FriendSuggestion100 +7 moreIntent-aware player, guild, event, mentor, returner, and low-pressure discovery for Maya Social Fabric
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.
DiscoveryItemKind8DiscoveryLane9DiscoveryTag10GuildDiscoveryProfile21CommunityEventDiscoveryProfile36DiscoveryCandidate50DiscoveryContext61DiscoveryInputs70NotificationPolicy76NotificationDecision83buildHomeDiscoveryFeed88recommendPeopleYouShouldMeet106recommendGuilds160discoverEvents204 +4 moreFestivals, markets, performances, ceremonies and gatherings: scheduled/dynamic events, a preparation->active->cleanup lifecycle, street performers, tavern/market/religious activities, festival mini-games, and NPC schedule overrides
Festival/market/performance simulation at libs/maya/social-events/src:
schema.ts models SocialEvents 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.
AI social facilitation profiles, opt-ins, group suggestions, disclosed introductions, rehearsal, concierge, nudges, mentor and returner assistants, memory controls, and evaluation for Maya
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.
ComfortLevel1InterventionStyle2CoachingIntensity3FacilitationFeature4SuggestionKind5RehearsalScenario6ParticipationMoment7FollowUpAction8MemoryContext9SocialCompanionProfile11AiOptInSettings19GroupSuggestionCandidate24GroupSuggestion32WingmanIntroduction39 +23 moreIntent-aware player social graph, privacy, presence, reliability, and feature projections for Maya Social Fabric
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.
SocialActivity1RelationshipKind11CommunicationMode21GroupComfort22PresenceStatus23PlatformId24VisibilityAudience25FeatureProjectionKind26AvailabilityWindow28RelationshipEdge34ReliabilitySignals42CooldownRecord50ComfortControls56PrivacyMatrix65 +17 morevoice-* (5)#
NPC voice dialogue session management, turn-taking, personality prompts, knowledge boundaries, consequences, memory, eavesdropping, groups, and transcript logging.
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.
Vec31Personality7EmotionalState16NpcProfile23DialogueSession36DialogueTurn45DialogueLogEntry52DialogueConsequenceType59DialogueConsequence69shouldInitiateConversation75startDialogueSession88buildNpcSystemPrompt98generateNpcResponse111recordTurn127 +6 morePhase 83 voice-driven emergent narrative consequences: lies, promises, persuasion, information gifts, emotion, rumors, reputation, and arc detection.
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.
ConsequenceKind1VoiceStatement10NarrativeConsequence17PromiseRecord26detectConsequences33trackPromise98resolvePromises114propagateLie129reputationFromWord142detectNarrativeArc156Voice negotiation, persuasion, intimidation, deception, trade, faction negotiation, witness effects, and negotiation memory for Maya NPC conversations.
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.
NegotiationKind1NegotiationOutcome8NegotiatorPersonality15NegotiationContext26ArgumentScore40NegotiationState49ResolvedNegotiation57detectNegotiation66scoreArgument76resistance92resolveNegotiation102nextRound127rememberPromise138Natural-language squad command decomposition, temporal dependencies, signal groups, standing orders, validation, and HUD plan previews for Maya gameplay voice input.
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.
TeamId1AtomicActionType2Position18SquadAgentState24SquadState33AtomicAction39ExecutionPlan47HudPreviewMarker54ValidationIssue60atomicActionCatalog65createCommandPromptTemplate82decomposeCommand94validatePlan163executeSignal192 +1 morePersonality-matched voice profile management, emotion modulation, tactical brevity, priority queues, spatial/radio filters, lip-sync hooks, caching, and TTS quality benchmarks.
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.
VoicePriority1VoiceContext2PersonalityVoiceInput4EmotionInput11VoiceProfile18SynthesisRequest27SynthesisParams35QueuedVoice43SpatialVoiceParams50QualityBenchmark57createVoiceProfile65modulateEmotion80applyTacticalBrevity90enqueueVoice100 +4 moreworld-* (3)#
TypeScript facade for Maya world weather, time-of-day, and atmospheric simulation readiness
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.
MayaWorldReadiness1MayaWorldEnvironmentScale2MayaWorldWeatherMode3MayaWorldStreamingConfig12MayaWorldTimeOfDayConfig25MayaWorldWeatherConfig36MayaWorldAtmosphereConfig49MayaWorldWaterSurfaceConfig61MayaWorldRenderExportConfig71MayaWorldVirtualEnvironmentInput81MayaWorldVirtualEnvironmentIssue101MayaWorldVirtualEnvironmentEvaluation118evaluateMayaWorldVirtualEnvironment285Legends Mode: a queryable encyclopedia and timeline over maya-world-history generated history — figure/artifact/war/civilization lookups, era grouping, and timeline filtering
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.
World social hubs, boards, rituals, guild fairs, memory surfaces, schedules, NPC anchors, quiet zones, and validation for Maya Social Fabric
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.
SocialHubKind1BoardKind2RitualKind3MemorySurfaceKind4NpcAnchorKind5SocialMarkerKind6WorldPoint8SocialHubTemplate14InteractiveBoard24PublicCoopRitual33GuildFairground42SocialMemorySurface50RecurringCommunityEvent58NpcAnchorPoint68 +13 moreeverything else (43)#
Domestic & working animal catalog: farm/working/pet/wildlife species reference with diet, product, care needs and temperament, backing the maya-ecology domestic simulation
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.
Anti-cheat enforcement and moderation workflows for Maya
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.
MayaAnticheatBanReasonCode1MayaAnticheatReportCategory10MayaAnticheatBanStatus12MayaAnticheatBanScope13MayaAnticheatPenaltyAction14MayaAnticheatAppealStatus19MayaAnticheatTribunalVerdict20MayaAnticheatPolicy22MayaAnticheatBan32MayaAnticheatBanRequest48MayaAnticheatHardwareBanRequest58MayaAnticheatIpRangeBanRequest62MayaAnticheatNetworkObservation68MayaAnticheatBanCheck76 +10 moreA 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.
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.
UserAccountStatus7MayaUserAccountValidator7generateUserAccountTableDDL7generateUserAuditTableDDL7AvatarBodyType15AvatarSlot15AvatarDataValidator15generateAvatarTableDDL15ItemRarity23ItemCategory23RARITY_VALUE_MULTIPLIERS23ItemSchemaValidator23generateItemTablesDDL23WorldVisibility32 +103 moreA 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.
Species data-management library for the maya-ecology simulation: a typed species registry (taxonomy, diet, habitat, perception, reproduction) with Kleiber-law energetics and trophic-web queries
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.
Virtual economy primitives for Maya currencies, transactions, trading, and marketplace systems
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_PACKAGE1MayaEconomyCapability40MayaEconomyPackageDescriptor42createMayaEconomyPackageDescriptor48Economy balance-analysis tooling: price-series convergence/stability metrics and settlement economic-indicator reporting over maya-economy sim output
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.
Procedural environmental storytelling — event-to-decoration rules (battle/fire/abandonment/crime), lived-in spaces, graffiti, trails, economic/seasonal dressing, and collision-avoiding density-scaled placement
Procedural environmental storytelling at libs/maya/env-storytelling/src —
scene dressing that tells stories without dialogue: rules.ts maps
WorldEvents (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).
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.
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.
Geospatial tile-pyramid math (Web Mercator slippy-map coordinate transforms, zoom 0-21), an LRU tile cache with disk budget, predictive along-path prefetching, and hybrid real+authored region override
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.
Guild project boards, calendars, onboarding, knowledge, treasury, goals, hall scheduling, and officer coverage for Maya Social Fabric
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.
GuildWorkKind1GuildTaskStatus10GuildEventKind11GuildKnowledgeKind12GuildResourceKind13GuildGoalStatus14GuildRewardRule16GuildProjectTask22GuildProjectBoard33GuildContribution41NewcomerQueueItem51GuildCalendarEvent60GuildKnowledgeEntry75GuildResourceLogEntry85 +17 moreHealthy guild recruitment profiles, applications, trial membership, referrals, office hours, public pages, kiosks, and recommendations for Maya Social Fabric
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.
GuildCulture9GuildSize16RecruitingStatus17VoiceExpectation18ApplicationStatus19TrialStatus20RoleDemand22GuildRecruitmentProfile28GuildSearchFilters47GuildApplication58ReviewerComment70ProvisionalMembership76OnboardingChecklistItem87RecruiterOfficeHour93 +16 moreCross-platform identity primitives for Maya Nexus accounts, platform profiles, and compliance gates
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.
Session instancing and player placement core for Maya Nexus
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 InstanceTypes
(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.
InstanceType1InstanceLifecycleState3InstanceTransferReason5InstanceTransferStatus14InstanceEventKind16InstanceCapacity26InstanceLocation32InstancePlayerProfile41InstancePlayerState52InstanceEvent59InstanceRuntime70InstanceTransferTicket88InstanceManagementState99InstanceManagementConfig109 +38 moreParametric jewelry generation — gem-cut geometry with refractive-index optics (fire/brilliance/scintillation), a standard cut library, prong/bezel settings, ring bands, chains, matched ensembles, and wear states
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 Settings, 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.
Community-first LFG listings, scheduling, applications, backfill, ready-up, regroup, and squad templates for Maya Social Fabric
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.
LfgCommunityTag10ListingTone20VoicePreference21TeachingPosture22ListingTiming23JoinPolicy24ListingStatus25ApplicantStatus26ReadyState27RoleNeed29LfgReminderPolicy35LfgListing40LfgApplicant67QuestJournalRecruitmentInput76 +19 moreLive event orchestration primitives for synchronized Maya world 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_LIVE_EVENTS_PACKAGE1MayaLiveEventsCapability26MayaLiveEventsPackageDescriptor28createMayaLiveEventsPackageDescriptor34Lobby and pre-game session core for Maya Nexus
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 SessionRealtimeUpdates
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.
LobbyVisibility4LobbyLifecycleState5LobbyParticipantKind12LobbyParticipantRole13LobbyInviteState14LobbyChatKind15LobbyTeamAssignmentMode16LobbyServiceConfig18LobbyRules27LobbySettings31LobbyParticipantInput43LobbyParticipant48LobbyInvite62LobbyChatMessage75 +10 moreProduction matchmaking rating and skill systems for Maya Nexus
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 SkillDimensions). 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
RatingConfidenceIntervals. 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 —
MatchmakingTickets 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.
MatchOutcome4SkillDimension5RatingSystemName6RankTierName7RankDivisionNumber15Glicko2Config17Glicko2Rating27Glicko2MatchResult36EloConfig42EloRating52TrueSkill2Config59TrueSkillDimensionRating69TrueSkill2Rating77PlacementState84 +54 moreSocial onboarding, mentor registry, first-run support, returner rescue, protected cohorts, and mentor quality systems for Maya Social Fabric
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.
PlayerLifecycleSegment3SocialMilestone4HelpQuestionStatus5MentorCertificationStatus6TeachingPosture7PlayerLifecycleSignals9LifecycleDetection17OnboardingJourney22SocialMilestoneStep28HelpQuestion35MentorProfile45MentorQualitySignals62MentorMatch70EscortedFirstRun76 +15 moreContent moderation and trust safety planning for Maya
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.
Advanced neural capture systems for 4D Gaussian splatting, volumetric video, and AI motion 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).
Maya4DgsMultiViewVideo1Maya4DgsTrainingFromMultiViewVideoInput11Maya4DgsTrainingDecision30Maya4DgsTrainingFromMultiViewVideoPlan38Maya4DgsTemporalDeformationKeyframe70Maya4DgsTemporalDeformationGrid77Maya4DgsTemporalDeformationFieldInput83Maya4DgsTemporalDeformationDecision101Maya4DgsTemporalDeformationFieldPlan109Maya4DgsHighFpsRenderingInput144Maya4DgsHighFpsRenderingDecision167Maya4DgsHighFpsRenderingPlan175Maya4DgsMegaMemoryInput223Maya4DgsMegaMemoryDecision243 +51 moreDeployment orchestration primitives for Maya simulation fleets, regions, and server lifecycles
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_ORCHESTRATION_PACKAGE1MayaOrchestrationCapability33MayaOrchestrationPackageDescriptor35createMayaOrchestrationPackageDescriptor41Procedural ornamental pattern generators — guilloche, Greek-key meander, Islamic star-and-rosette, braid-group braids, knot/Celtic interlace, and recursive filigree — as 2D curve/point data
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, torusKnots, celticPlait over/under matrices, and braid-group
braids. 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.
TypeScript facade for Maya physics simulation readiness across cloth, fluid, destruction, and particles
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.
MayaPhysicsReadiness1MayaPhysicsSimulationType2MayaPhysicsBackend3MayaPhysicsClothConfig5MayaPhysicsFluidConfig14MayaPhysicsDestructionConfig23MayaPhysicsParticleConfig32MayaPhysicsSimulationInput41MayaPhysicsSimulationIssue61MayaPhysicsSimulationEvaluation76evaluateMayaPhysicsSimulation236Government types & governance effects, faction satisfaction & civil-unrest escalation, political schemes & succession, inter-faction diplomacy & refugees — inspired by CK3 and Dwarf Fortress
Government and faction simulation at libs/maya/politics/src, inspired by CK3
and Dwarf Fortress: government.ts maps GovernmentTypes 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.
TypeScript facade for Maya renderer GI, virtualized geometry, and neural rendering readiness
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.
valuateMayaRendererPass314designMayaNeuralRadianceCacheArchitecture314scaleMayaNrcQualityPerformance314manageMayaNrcMemoryBudget314serializeMayaNrcStateForSave314restoreMayaNrcStateFromSave314lanMayaMultiResolutionNrc446lanMayaNrcLumenClassGiIntegration446benchmarkMayaNrcAgainstGiBaselines446lanMayaTemporalMlDenoiser446createMayaMlDenoiserInferencePostProcessPass446createMayaMlDenoiserSpatialFallbackPlan446createMayaMlDenoiserArtistComparisonTool454integrateMayaMlDenoiserWithTaaTsrPipeline454 +32 moreNext-generation Maya rendering techniques including MegaLights and advanced GPU rendering
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.
createMayaLightSourceImportanceSamplingPlan378createMayaFixedRayCountPerPixelPlan378createMayaDynamicShadowCastingLightsPlan378createMayaAreaLightSoftShadowPlan378createMayaDirectionalMegaLightsPlan378createMayaNiagaraGpuParticleShadowPlan378computeMayaHairMegaLightsIntegration378computeMayaStochasticDirectLighting378createMayaAdaptiveNoiseReductionPlan378createMayaAutomaticLightOptimizationPlan378createMayaMegaLightsQualityScalabilityOptions378createMayaMegaLightsDebugVisualization378createMayaLightImportanceHeuristicsPlan392runMayaHybridMegaLightsPipeline392 +61 moreTypeScript facade for Maya virtual set scene graph, asset loading, and state persistence readiness
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.
MayaSceneReadiness1MayaSceneAssetType2MayaSceneAsset4MayaSceneNode16MayaSceneStatePersistence27MayaSceneVirtualSetInput37MayaSceneVirtualSetIssue47MayaSceneVirtualSetEvaluation61evaluateMayaSceneVirtualSet158The 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.
Persistent spatial AR content anchoring for Maya AR cloud workflows
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.
createMayaWorldScaleSpatialMap329createMayaVisualPositioningSystem329createMayaLargeGeospatialModelIntegration329createMayaNianticSpatialLocalization329createMayaCrossDeviceARContentPersistence329createMayaARContentCloudStorage329createMayaRealTimeARContentSync329createMayaARContentDiscoveryAPI329createMayaARContentPermissionsSystem329createMayaIoTSensorAROverlay329createMayaARAnnotationSystem329createMayaARNavigationAndWayfinding329createMayaARMultiplayerColocatedExperience329createMayaARCloudThirdPartyAPI329 +16 moreSpectator and broadcast camera primitives for Maya Nexus
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_SPECTATOR_PACKAGE1MayaSpectatorCapability27MayaSpectatorPackageDescriptor29createMayaSpectatorPackageDescriptor35Metaverse interoperability standards and OpenUSD compliance planning for Maya
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_OPENUSD_FULL_FORMATS258MAYA_OPENUSD_DEFAULT_VALIDATION_SUITES258createMayaOpenUSDImportExportPlan384createMayaUSDCompositionPlan384createMayaUSDGeospatialExtensionPlan384createMayaUSDInternationalCharacterPlan384createMayaUSDIoTStreamingPlan384createMayaGltfCompliancePlan384MAYA_OMI_GLTF_AVAILABLE_EXTENSIONS384createMayaOmiGltfExtensionPlan384createMayaUSDGltfBidirectionalConversionPlan394createMayaMaterialTranslationPlan394createMayaAnimationInteroperabilityPlan394createMayaPhysicsSchemaCompliancePlan394 +19 moreA 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.
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.
Tournament and esports infrastructure foundation for Maya Nexus
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_TOURNAMENTS_PROJECT_ROOT4MAYA_TOURNAMENTS_SOURCE_ROOT4MAYA_TOURNAMENT_DEFAULT_VISIBILITY4MAYA_TOURNAMENT_CREATION_STATUS4MAYA_TOURNAMENT_DEFAULT_ROUND_ROBIN_CYCLES4MAYA_TOURNAMENT_DEFAULT_GROUP_ROUND_ROBIN_CYCLES4MAYA_TOURNAMENT_DEFAULT_DOUBLE_ELIMINATION_RESET4MAYA_TOURNAMENT_SEEDING_METHODS4MAYA_TOURNAMENT_REGISTRATION_ENTRANT_TYPES4MAYA_TOURNAMENT_ENTRY_FEE_PAYMENT_STATUSES4MAYA_TOURNAMENTS_NX_TARGETS4MAYA_TOURNAMENT_FORMATS4MAYA_TOURNAMENT_MANAGEMENT_CAPABILITIES4MAYA_TOURNAMENT_INFRASTRUCTURE_CAPABILITIES4 +39 moreCommunity onboarding, moderation, case management, safety policy, report sync, retention, localization, and safety dashboards for Maya Social Fabric
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 ModeratorCases 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.
ParticipationSurface1ModerationCategory2CaseStatus3EvidenceKind4ModerationRole5SafetyNudgeKind6ReportSurface7RetentionClass8RulesAcceptance10OnboardingGate16ChannelSelection23TextModerationResult31VoiceSafetyResult37EvidenceBundle45 +20 moreSandboxed UGC multiplayer runtime foundation for Maya Nexus
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.
MayaUgcRuntimeSandboxKind1MayaUgcScriptApiPermission2MayaUgcScriptExecutionAuthority3MayaUgcClientScriptExecutionPolicy4MayaUgcAuthoritativeStateDelivery5MayaUgcHotReloadValidation6MayaUgcHotReloadStatePolicy7MayaUgcScriptVersionHistory8MayaUgcScriptRollbackTarget9MayaUgcScriptRollbackTrigger10MayaUgcDebugMode11MayaUgcDebugBreakpointKind12MayaUgcDebugStepMode13MayaUgcDebugVariableInspection14 +222 morePhase 83 urban evolution scheduling for construction, demolition, decay, disaster recovery, seasonal visuals, timelines, and player impact.
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
UrbanChanges, and playerImpact attribution. Compact pure scheduling logic
for city change over time.
UrbanChangeKind1UrbanChange9DistrictMetrics20scheduleConstruction29constructionDemand58scheduleDecay75scheduleDisasterRecovery114timeline145playerImpact151Immersive VR production studio runtime planning and capability contracts for Maya
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.
createMayaVrOpenXrRuntimePlan4createMayaVrSessionLifecyclePlan4createMayaVrReferenceSpacePlan4createMayaVrSwapchainPlan4createMayaVrControllerInputPlan4createMayaVrHandTrackingPlan4createMayaVrEyeTrackingPlan4createMayaVrFoveatedRenderingPlan4createMayaVrMixedRealityPlan4createMayaVrSpatialAnchorPlan4createMayaVrHapticFeedbackPlan4createMayaVrCompositionLayerPlan4createMayaVrCapabilityPlan4createMayaVrPerformanceOverlayPlan4 +531 moreWebXR preview bridge contracts for the Maya immersive VR production studio
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.
MayaVrWebXrFeature3MayaVrWebXrFallbackMode10MayaVrWebXrTransport11MayaVrWebXrInputSourceKind12MayaVrWebXrAnnotationTool13MayaVrWebXrSessionInput15MayaVrWebXrSessionPlan24MayaVrWebXrSceneDeltaInput34MayaVrWebXrSceneSyncInput42MayaVrWebXrSceneSyncPlan52MayaVrWebXrInputSourceProfile63MayaVrWebXrInteractionParityInput69MayaVrWebXrInteractionParityPlan75MayaVrWebGpuRenderPathInput84 +10 moreengine (1)#
Maya engine kernel — modular plugin architecture with hot-reloading, dependency resolution, and phased frame dispatch
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.
MayaEngineCoreReadiness1MayaEngineCorePbrMaterial3MayaEngineCoreRenderLight15MayaEngineCoreVirtualEnvironmentInput24MayaEngineCoreFrameIssue38MayaEngineCoreVirtualEnvironmentFrame51createMayaEngineCoreVirtualEnvironmentFrame98forge (5)#
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 GeneratedFiles), 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.
ReviewStatus1AiContentCategory2PolicyMode10AiGenerationContext12GeneratedFile19ModScaffold24TexturePlan33ModelPlan44SoundEffectPlan52QuestPlan60NpcPlan69ConflictInput78ConflictResolutionPlan84QualityReviewInput90 +20 moreA 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 ForgeModRecords
(ForgeModCreateInput / ForgeModUpdateInput CRUD, ForgeModReview moderation
state), with authorize enforcing per-ApiSubject RegisteredCredentials,
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.
ApiMethod1ApiCredentialKind2ApiRole3ApiScope4ModVisibility11GovernanceStatus12SortField13GraphQlModField14RealtimeEventType20GrpcOperation25ApiSubject27RegisteredCredential35ApiVersionSpec41RateLimitConfig48 +24 moreA 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.
CompatibilityStatus1PublishedMod3DeprecationInfo11GameVersion17CompatibilityRow24CompatibilityMatrix31ApiDeprecationWarning35CompatibilityShim43VersionPin49BreakingChangeImpact56MigrationReport62buildCompatibilityMatrix68deprecationWarnings92buildCompatibilityShims114 +3 moreA 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.
PlatformKind1CompatibilityStatus11CapabilityProfile13ModAssetProfile21PackageVariant32CurationReport41BudgetReport47VrValidationReport55WasmExecutionPlan62CloudHostingPlan68CompatibilityMatrix74profilePlatform83packageForPlatform138curateConsoleMod175 +5 moreA 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.
ForgeSdkMethod1ForgeSdkRole2ForgeSdkEventType3ForgeSdkStreamOperation8ForgeMod13ForgeCreateModInput24ForgeUpdateModInput33ForgeSdkRequest42ForgeSdkResponse50ForgeSdkTransport56ForgeSdkRetryPolicy61ForgeSdkClientOptions66ForgeListOptions74ForgePage80 +17 moreixchel (27)#
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 BehaviorTreeExtensions grafted
onto a BehaviorTree; explicit priority-ranked BehaviorReplacements resolved
through a BehaviorOverrideRegistry (highest priority wins, ties broken by mod
id, losers recorded as IgnoredReplacements 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.
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.
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.
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 HookPoints (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 BTreeMaps; 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.
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.
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.
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.
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.
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.
CurrencyDefinition1ShopItem9ShopInventoryMod16ResourceGeneratorMod22EconomyModelInput31EconomyExploitFinding38EconomyBalanceReport45detectEconomyExploits52createEconomyBalanceReport60A 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
ResourceHandles 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
WorldDeltas. 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.
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
NarrativeNodes (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 BranchModifications 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 BTreeMaps 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").
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.
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.
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 RuleSchemaFields (hierarchical paths
with min/max bounds and defaults) bounds-checks every RuleValue. Each mod
contributes RulePatches 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.
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."
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 SocialUiHooks by
descending priority then id, and places them into conflict-free slots
(deterministically suffixing collisions slot:2, slot:3) as
ArrangedUiHooks, while collecting mini-game state_namespaces 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.
SocialCapability1SocialUiHook3SocialFeature10EmoteDefinition17ChatExtension24MiniGameDefinition31SocialCompositionReport37composeSocialFeatures43registerEmote72registerChatExtension82A 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.
FORGE_STUDIO_CINEMA_SCHEMA_VERSION1TimelineTrackKind3EditOperation11CameraMovement12CameraShakePreset13CompositionGuide14ExpressionPreset15TransitionKind16CinematicTrigger24CinemaReadiness25TimelineClip27TimelineTrack33CinematicTimeline39TimelinePlaybackReport48 +23 moreA 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 StudioAssets (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 QualityFindings,
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.
FORGE_STUDIO_CORE_SCHEMA_VERSION1StudioAssetKind3DomainSource12AssetFormat13DeviceKind25DevicePermission32CollaboratorRole33ValidationSeverity34StudioReadiness35StudioAsset37StudioWorkspace54DomainAssetOutput62QualityBudget77QualityFinding86 +28 moreA 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.
FORGE_STUDIO_MOCAP_SCHEMA_VERSION1CaptureChannel3PerformancePosture4EnhancementKind5MocapReadiness10CaptureFrame12CaptureSessionInput20CaptureSessionPlan31PerformanceClip47RetargetInput56RetargetReport66MotionBlend78ChoreographyInput85ChoreographyPlan93 +16 moreA 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.
FORGE_STUDIO_MUSIC_SCHEMA_VERSION1InstrumentFamily3ArrangementSection4MusicState5AudioLayerKind14LicenseTag22MusicReadiness23MidiNote25CompositionPlan33MidiValidationReport45HumCapturePlan52AiMusicPlan61AdaptiveTransitionRule75AdaptiveMusicSystem83 +15 moreA 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.
FORGE_STUDIO_SCULPT_SCHEMA_VERSION1SculptSource3SkeletonTemplate4VariantKind5SculptReadiness6MeshAsset8GenerationPlan23PhotogrammetryPlan30MeshCleanupPlan38MaterialPlan48RigPlan56AttachmentPlan66VariantPlan74PreviewValidationReport80 +11 moreA 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 PresetCategorys),
createShaderGraph/compileShaderGraph, designPostProcess,
createVolumetricEffect, attachEffect (maps TriggerEvents to forge-code:*
hooks), planLodBudget (four QualityTiers, 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.
FORGE_STUDIO_VFX_SCHEMA_VERSION1EmitterShape3ForceKind4PresetCategory5ShaderNodeKind6MaterialOutput14PostProcessKind15VolumeShape23TriggerEvent24AttachmentTarget31QualityTier32VfxReadiness33ParticleEffectPlan35VfxPreset53 +22 moreA 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.
FORGE_STUDIO_VOICE_SCHEMA_VERSION1AudioAssetKind3VoiceEffect4EmotionTarget11VoiceReadiness12RecordedTake14RecordingPlan24VoiceProfile36VoiceClonePlan43LipSyncTrack51DialogueNode59DialogueBatchReport67SoundEffectPlan74AmbientSoundscapePlan82 +15 moreA 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 TerrainTools) 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.
FORGE_STUDIO_WORLD_SCHEMA_VERSION1TerrainTool3TerrainMaterial11TerrainType12Biome18PlacementMode19LightKind20TimeOfDayPreset21GameplayRegionKind22NavLinkKind30DungeonModuleKind31OverlayKind32WorldReadiness33TerrainBrush35 +33 moreA 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.
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 UIModClaims 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 BTreeMaps. A parallel
~213-line TS mirror (index.ts, tag type:ts-lib) re-implements a subset.
UiSlotName1UiRect11UiSize18UiSlot23UiModClaim29PlacementMode38UiPlacement40UiLayoutConflict49UiLayoutComposition55AccessibilityLayer61ComposedAccessibility70UiHotReloadEvent78createDefaultSlots82composeUiLayout95 +2 moreA 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 SpatialDiffs, 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.
loom (10)#
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 WorldBlocks 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.
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.
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
DimensionDefinitions 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.
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.
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
PortalDefs 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.
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 SoulDirectives), 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.
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.
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: MultiverseNodes (typed by
NodeKind, with PortalVisibility and AccessControl) connected by
PortalEdges 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.
LoomNodeKind1LoomPortalVisibility2LoomNode4LoomPortal15LoomPlayerAccess28LoomTopology34LoomIdentityMode39LoomCharacterIdentity44LoomInventoryItem51LoomInventoryPolicy57LoomExchangeRatePolicy68LoomTradeQuote76LoomCouncilRepresentative82LoomMultiverseCouncil88 +12 moreA 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 BrushStrokes carrying
one of seven SemanticLabels (DenseForest, RockyCliff, UrbanArea, WaterBody,
FrozenWasteland…) across six BrushToolModes, 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.
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 TerrainTrainingTiles: 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.
nexus (2)#
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), VoteRecords 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.
NexusVoteChoice1NexusProposalStatus2NexusModAction9NexusRisk10NexusThresholdRule12NexusVotingConfig17NexusConflictAnalysis25NexusLiveProposal31NexusVoteRecord44NexusVotingSession51NexusVoteTally62NexusOverlayModel75thresholdBps96validateVotingConfig102 +10 moreA 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 DownloadJobs is
ordered across DownloadSources 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.
sentinel (4)#
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
ScanStages under a ScanPipelineConfig (each stage carrying a
FailurePolicy), collects ScanFindings by FindingSeverity into
StageScanResults, 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.
SentinelScanStage1SentinelFailurePolicy2SentinelSeverity3SentinelDecision4SentinelViolationType5SentinelModeratorPower6SentinelAppealStatus7SentinelContentWarning8SentinelStageConfig10SentinelFinding17SentinelStageResult25SentinelAuditRecord33SentinelModerationThreshold41SentinelViolationEvent48 +14 moreA 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 ReferenceWorks into IpMatches that
reduce to an IpDecision. build_themis_bridge_requests packages flagged
assets into ThemisBridgeRequests (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.
THEMIS_MUSIC_SHIELD_PACKAGE1THEMIS_UNIVERSAL_ORIGINALITY_SHIELD_PACKAGE2SentinelIpAssetKind4SentinelIpDecision6SentinelIpLicenseKind8SentinelIpModAsset17SentinelIpAssetFingerprint25SentinelIpReferenceWork34SentinelIpMatch43SentinelThemisBridgeRequest51SentinelThemisBridgeConfig64SentinelThemisMusicShieldScanRequest71SentinelThemisOriginalityShieldScanInput82SentinelMeshDescriptor99 +25 moreA 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 (AttributionNodes + AttributionEdges) 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.
ProvenanceKycStatus1ProvenanceVerificationStatus2ProvenanceTamperSeverity3CreatorRegistrationInput5CreatorKeyPair12CreatorIdentity17CreatorRegistration26ModPackageManifest31ModSignature41AttributionNode50AttributionEdge59AttributionChain65ContributionInput73ContributionRecord81 +18 moreA 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
ScannerFindings graded by FindingSeverity with a final ScannerDecision:
analyze_static_code runs StaticPattern rules (from
default_static_analysis_config) over ModSourceFiles 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.
unclassified (1)#
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.
variants (5)#
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 VariantNodes
(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.
DifferenceKind1CompatibilityClass2VariantNode4VariantDifference13CompatibilityReport21SharedRuleset29CompatibilityUiModel35PlaylistEntry49VariantPlaylist55SwitchImpact60VariantAchievement68AchievementProgress75LeaderboardEntry82VariantLeaderboard88 +10 moreA 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; VariantCommits 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.
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 GameObjectKinds —
Entity, Spatial, Rule, Narrative, Asset. diff_game_objects keys objects by
StableObjectId into BTreeMaps 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.
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 GameObjectStates) 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 TestSuiteResults rather than running any
game tests.
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 ServerListings 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.
ActivityType1VariantSummary3ForkTreeNodeView17VariantSearchFilter22VariantSearchResult30PlayPattern35VariantRecommendation40CuratedCollection46VariantReview55VariantRatingSummary64ServerListing70MatchmakingRequest79MatchmakingGroup86ActivityEvent92 +8 more