V7 Creator DX Tooling — Developer Experience for WASM Resource Creators

Status: V7 creator-tools design. Source: fills the planning gap identified in V1_V7_PLAN_SET_AUDIT_2026-06-12.md §6.2 (no developer-experience plan for resource creators). Grounded in V7/V7_features.md (features§"Hot-Reload Into Live Sessions", features§"The Scripting Surface", features§"Capability Gating and Budgets", features§"Mawu Studio — Creation Tools") and V7/V7_ARCHITECTURE.md (arch§"The WASM Sandbox", arch§"Determinism — The Cross-Cutting Invariant", arch§"Moremi — Realm Server Architecture", arch§"Testing, Eval Gates, and Golden Replays"). Owner: Ixchel runtime lead (sandbox-side tooling) + Mawu Studio lead (creator-facing surfaces). Date: 2026-06-12.

1. Why DX Is a Launch Feature, Not Polish#

FiveM's ecosystem exists because iterating on a Lua resource takes seconds on a local server. s&box and UEFN prove the same lesson V7 already cites (features§"Hot-Reload Into Live Sessions": "iteration speed determines creator throughput"). V7 asks creators to adopt a harder toolchain than Lua-on-FiveM — typed APIs, WASM compilation, capability manifests, sandbox tiers. Every unit of added rigor must be paid for with better tooling, or creators stay where iteration is cheap. The whole document rolls up to one product number: time-from-zero-to-running-resource < 30 minutes (§8).

2. The Local Dev Realm — moremi dev#

A single binary, no Kubernetes, no platform account round-trips for the inner loop:

• One process, full stack: moremi dev runs the Moremi realm server (arch§"Moremi — Realm Server Architecture") with an embedded Nephthys (same event-sourced engine, SQLite-backed local store instead of the replica service) and an embedded single-node "mesh" so Danu-facing APIs exist but trivially. It is the Solo hosting tier (features§"The Hosting Continuum") exposed as a developer tool — the same composed world and lock file that later runs Dedicated/Meshed, honoring the "promoted without rebuild" guarantee.
• Hot-reload as the inner loop: moremi dev --watch watches the resource workspace; on save it recompiles (TS→WASM via the standard toolchain, or reloads Lua source under the Lua runtime — V7/docs/community-migration.md §4.1), then hot-swaps the resource through the Ixchel lifecycle manager with state preservation, exactly the production hot-reload path (features§"Hot-Reload Into Live Sessions") — dev mode is a consumer of that spec, not a parallel mechanism. Target: save-to-live ≤2 s for a 1,000-line TS resource, ≤500 ms for Lua source reload (planning assumption adopted 2026-06-12; tracked as a DX benchmark in CI).
• Sandbox parity with relaxed ergonomics, never relaxed semantics: dev mode runs the same Wasmtime configuration, tiers, fuel/epoch budgets, and capability gating as production (arch§"The WASM Sandbox") — a resource that works in dev but trips a capability or budget wall in production is the cardinal DX betrayal. What dev mode relaxes: signing/AOT-at-upload (local JIT compile allowed in dev only), Sekhmet scanning (local artifacts are not fetchable by anyone else), and budget overruns log loudly instead of flagging to the platform.
• Client attach: the Mawu client connects to localhost dev realms via a developer mode (gated on a creator-program flag) — the attested-client posture (arch§"Anti-Cheat and Client Integrity") carves out localhost dev realms explicitly, since nothing in a dev realm crosses the trust boundary.
• Seeded content: moremi dev --seed nana-town boots with the Nàná core, a small test world, and 8 scripted residents so jobs/economy/property APIs have something to act on out of the box.

3. Step Debugging for WASM Resources#

The story, honestly staged because component-model debugging is young:

• Mechanism: resources compile with DWARF debug info (-g; source-language DWARF embedded in the .wasm). The dev-realm Wasmtime host enables guest debugging, which maps guest DWARF to native frames so LLDB/GDB-class debuggers step through source (TypeScript via source-map→DWARF in the TS toolchain; Rust/C natively; Lua via the interpreter's own line-hook debugger, not DWARF — see below).
• Protocol: the dev realm exposes a Debug Adapter Protocol (DAP) server (moremi dev --debug opens a DAP port). DAP is the deliberate choice: one protocol covers VS Code, neovim, JetBrains, and the Mawu Studio script editor without per-IDE work. The DAP adapter wraps the Wasmtime+LLDB session for compiled-language resources and the Lua line-hook debugger for interpreted resources, presenting one uniform surface: breakpoints, step in/over/out, locals, watches, and call stacks across the host-call boundary (host frames shown collapsed with the capability name).
• Tick-aware pause semantics: pausing a resource cannot stall the realm tick (the production sandbox never lets a plugin hang the realm — features§"Capability Gating and Budgets"). In dev, pause freezes the whole local sim clock (single-tenant, so this is fine); there is no breakpoint debugging against live multi-tenant realms — that path is profiling and replay (§4, §5), stated plainly in docs.
• Determinism aid: because gameplay-tier plugins are deterministic (arch§"Determinism"), a captured replay (§5) can be re-run under the debugger and will hit the same state at the same tick — "debug the exact bug from the bug report" is the headline feature cheap engines can't offer.
• Staging: DAP + breakpoints for Rust/TS resources in creator alpha; Lua debugger in RP beta; watch-expressions over component-model rich types as the toolchain matures (tracked dependency on upstream Wasmtime/component tooling — pinned per deps§3, with the gap owned, not hand-waved: until rich-type rendering lands, the adapter renders lowered core values with the WIT field names from the manifest).

4. Profiler — Fuel, Epochs, and Tick Budgets#

The sandbox already meters everything (fuel per tick, memory, host-call audit log — arch§"The WASM Sandbox"); the profiler is the lens on that telemetry:

• Per-resource flamegraphs: moremi dev --profile runs the Wasmtime guest-profiling hooks and emits speedscope-format profiles per resource per tick window; fuel-weighted (deterministic tier) or wall-time epoch-weighted (cosmetic tier), matching how production billing/throttling actually sees the resource.
• Per-tick budget attribution: a live HUD (dev realm web UI on localhost) showing, per tick: fuel consumed per resource vs. its tier budget, host-call counts by capability, memory high-water vs. StoreLimits cap, and the realm's total tick time vs. the tick-tier budget (60 Hz/16 ms or 10–30 Hz — arch§"Moremi"). The "you will be throttled in production" line is drawn on the chart — creators see the wall before they hit it live.
• Production-side: realm operators get the aggregated version in creator analytics (features§"Streaming, Spectating, and the Creator Loop"): per-resource fuel/overrun rates per realm, so "which mod is eating my tick" is a dashboard read, not a forum debate. Per-resource overrun telemetry is already a platform metric (arch§"Observability and Live Operations").

5. Test Harness — Headless Realms, Scripted Players, Deterministic Replay#

• Headless realm runner: moremi test boots the dev realm headless, loads the resource under test plus declared deps (resolved by forge-resolver exactly as production), runs a test script, and reports. Integrates as a normal test runner (process exit code + JUnit/JSON output) so creator CI is just moremi test in any CI system.
• Scripted players: the harness injects synthetic clients at the realm protocol layer (libs/v7/realm-protocol/) — real intent streams, not function-call shortcuts — with a scripting API: player.join(), player.move(to), player.interact(zone), player.chat(text), player.expectInventory(...), player.expectBalance(...). Assertions read authoritative state through a test-only read capability. Because clients send intent and the server decides (features§"Server-Authoritative Netcode"), this tests the resource the way production exercises it, including validation rejections.
• Deterministic replay fixtures: the harness records input logs and can assert replay-to-state-hash — the creator-grade version of the platform's golden replays (arch§"Testing, Eval Gates, and Golden Replays"). A creator pins a replay fixture next to the resource; moremi test re-runs it on every change and fails on hash divergence, catching accidental nondeterminism (un-seeded RNG, wall-clock reads) before upload — the same classes Sekhmet tier-policy enforcement would reject later (features§"Sekhmet": tier mismatch rejection).
• Latency/loss simulation: moremi test --net-profile lossy5 runs scripted players through the 5%-loss profile so creators test against the platform's own netcode bar (features§"Performance Budgets") locally.

6. Scaffolding CLI#

mawu new <template> generates a working, publishable resource skeleton — manifest (deps, SemVer, declared tier, capability grants), typed API bindings, a passing moremi test suite, and a README with the publish checklist. Templates at creator alpha (planning assumption adopted 2026-06-12, owner: Mawu Studio lead):

mawu publish runs the local pre-flight (lint, tier/capability static check — the same checks Sekhmet runs, so rejection happens locally first), then submits through the standard Draft→Submitted lifecycle (features§"The In-Game Realm and Mod Browser").

7. Docs and Examples Plan#

• Reference: generated from the WIT host-API world (arch§"The WASM Sandbox") so docs cannot drift from the actual capability surface; every capability page states which tiers grant it.
• Guides: "zero to running resource" (the §8 metric's script), one guide per template, the Nàná concept-mapping guide for FiveM migrants (V7/docs/community-migration.md §4.3), the determinism rules ("no wall-clock, no un-seeded RNG, and why"), and the budget/profiling guide.
• Example corpus: the Nàná core's reference institutions (features§"Civic Institutions") are published as readable, forkable source — the platform's own resources are the canonical examples (the ESX/QBCore-on-GitHub lesson: ecosystems learn from the framework's source).
• Versioning: docs are versioned with the API SemVer (features§"The Scripting Surface": documented, versioned API surface); deprecations land in docs the release they're announced.

8. The Success Metric#

Time-from-zero-to-running-resource < 30 minutes, defined precisely:

On a clean machine with a platform account: install toolchain → mawu new job → moremi dev --watch --seed nana-town → see the templated job running in the local realm via the attached client → make a visible edit → see it hot-reload. Clock stops at the observed edit.

• Measured, not asserted: instrumented in the CLI (opt-in telemetry, first-run funnel), plus a quarterly moderated usability cohort of 10 new creators (planning assumption adopted 2026-06-12). p50 target <30 min; p90 <60 min.
• Secondary DX metrics: save-to-live reload p95 (≤2 s, §2); moremi test cold-run time for the template suite (≤60 s); local-preflight catch rate (≥90% of would-be Sekhmet tier rejections caught locally); creator-alpha weekly-active-creator retention at 4 weeks (≥40%).
• Gate: the 30-minute p50 is a creator-alpha exit criterion alongside the platform gates of features§"Region Rollout Strategy" stage 1 — if creators can't start in half an hour, scaling the funnel ships frustration.