Mochi Enhancement Proposals

A MEP is a design document for the Mochi language, type system, and toolchain. The full process is described in MEP 0. The list below is generated from the frontmatter of every mep-NNNN.md file in the docs tree, so new proposals appear here automatically once npm run gen:meps (or any npm start / npm run build) regenerates the manifest.

All MEPs

MEP	Title	Status
0000	Index of Mochi Enhancement Proposals Index of Mochi Enhancement Proposals.	Active
0001	Lexer Mochi's token classes, reserved words, lexical errors, and conformance corpus, specified end-to-end with no corner cases.	Informational
0002	Grammar Mochi's PEG grammar in full, with the design principles and conformance obligations that fix the language.	Informational
0003	Abstract Syntax Tree Mochi's AST as a closed family of tagged unions, the encoding that makes parse output unambiguous, and the soundness invariants every consumer can rely on.	Informational
0004	Type System The kinds, the comparisons, the numeric tower, and the places where Mochi's type system does not yet do what it claims.	Informational
0005	Type Inference Strict static algebraic type inference. Principal types, no implicit any, no null.	Active
0006	Type Checker Entry point, builtin environment, statement walk, and the diagnostic catalogue.	Informational
0007	Soundness Progress, preservation, and the test obligations that prove them.	Active
0008	Test Strategy The five test layers, the golden harness, and the TAPL chapter mapping.	Active
0009	Fixture Catalogue Inventory of parser and type fixtures with a property coverage matrix.	Informational
0010	Known Gaps and Weakness Review Catalogue of soundness gaps, surprising behavior, and tracked follow-ups.	Informational
0011	Subtyping and Variance A separate subtype predicate, the variance lattice, and the closure of any.	Active
0012	Parametric Polymorphism System-F-lite call-site inference, fresh type variables, and the end of any-builtins.	Active
0013	Algebraic Data Types and Match Struct and union typing rules, match exhaustiveness, irredundancy, and recursive types.	Draft
0014	Query Algebra LINQ-shaped query expressions, clause-by-clause type rules, and aggregate semantics.	Informational
0015	Effects A labeled effect system over function types. Pure by default, inferred from the body, annotatable at module boundaries, enforced where purity matters.	Draft
0016	Null Safety Total option discipline with no force unwrap, flow narrowing, safe-call and coalesce operators, and a no-panic guarantee.	Draft
0017	VM Performance Methodology and Baseline How Mochi measures, reports, and gates VM performance changes, with a reference benchmark suite and a regression budget.	Active
0018	Bytecode Dispatch in a Go-Hosted VM What dispatch techniques work for the Mochi VM under the constraints of the Go runtime, with a concrete plan for the next 18 months.	Active
0019	Adaptive Specialization and Inline Caches Quickening generic opcodes into typed variants on first observation, plus monomorphic and polymorphic inline caches for the few remaining dynamic call sites.	Active
0020	Value Representation and Allocation Discipline A tighter Value struct, sync.Pool for frames and slabs, and an escape audit on the hot path of the Mochi VM.	Active
0021	Compiler2 and VM2 Co-Design for Maximum Interpreter Throughput A first-principles redesign of the Mochi compile-and-execute pipeline. Replace the observation-driven runtime with a typed SSA compiler (compiler2) that emits monomorphic bytecode into a redesigned vm2 with NaN-boxed 8-byte values, register allocation, tail calls, and bounds-check elision. No backward compatibility constraints. Target the absolute throughput ceiling of a Go-hosted interpreter on statically typed source.	Active
0022	Baseline JIT via Copy-and-Patch (Deferred) A non-optimizing baseline JIT built on copy-and-patch compilation, planned as the long-term tier above the interpreter once MEP-18 through MEP-21 are exhausted. Co-designed with MEP-21 typed bytecode so the JIT consumes already-typed instructions and inherits zero speculative complexity from a dynamic front end.	Deferred
0023	Cross-language Baseline Benchmarks A periodic, hand-written cross-language benchmark suite that positions Mochi against Python and Lua on the same workloads, separate from the MEP-17 per-PR gate.	Active
0024	VM2 Subsystem Design (Objects, Strings, Structs, Lists, Maps, Closures, GC, Errors) A consolidated subsystem design for vm2 that replaces the ad-hoc per-feature opcode growth of MEPs 18-21 with a single coherent plan for value representation, heap-allocated types, garbage collection, exception/Result handling, and the porting path to feature parity with the legacy VM. Co-designed with a comprehensive correctness + benchmark gate.	Active
0025	VM2 Data Model (Strings, Lists, Maps, Sets, Structs) Algorithmically modern in-memory representations for vm2's five core container kinds, strings, lists, maps, sets, structs, replacing the MEP-24 MVP shapes with shapes that close the Lua gap on the cross-language baseline and stay competitive after a future JIT lands. Specifies SSO + rope strings, type-specialized lists, Swiss-style int-keyed maps, presence-only set storage, and slot-packed structs. Implementation strategy is selected from three competing approaches detailed in MEP-26, MEP-27, MEP-28.	Active
0026	VM2 Data Model Option 1 - Monomorphic + One-Way Migration First of three competing dispatch-strategy specs for the MEP-25 data model. Each container starts in the smallest shape that fits its first operation and migrates exactly once, in place, to a more general shape on the first operation that does not fit. The monomorphic-then-generic lattice is the same one used by V8 hidden classes, PyPy storage strategies, Lua table promotion, CRuby shape trees, and Rust SmallVec. This MEP specifies the lattice formally, derives per-op steady-state cost, bounds migration cost over a program lifetime, analyzes JIT integration, and predicts MEP-23 numbers.	Draft
0027	VM2 Data Model Option 2 - Polymorphic + Inline Caches Second of three competing dispatch-strategy specs for the MEP-25 data model. Every container kind exposes one polymorphic shape, but each opcode site carries a small inline cache of recently-seen sub-shapes. The hot path stays monomorphic at the call-site granularity while the runtime remains structurally polymorphic. Lineage traces to Self, Smalltalk-80, V8, and SpiderMonkey. This MEP specifies the IC slot layout, the monomorphic / polymorphic / megamorphic state machine, per-op cost, IC memory budget, JIT integration, and predicts MEP-23 numbers.	Draft
0028	VM2 Data Model Option 3 - AOT Codegen Specialization Third of three competing dispatch-strategy specs for the MEP-25 data model. The compiler enumerates each opcode's operand-shape tuple at emit time and lowers each tuple to a distinct specialized opcode. No shape dispatch at runtime, no inline caches, no migration. The interpreter loop dispatches on opcode and runs specialized code directly. Lineage traces to LuaJIT specialized opcodes, Julia method specialization, Crystal and Nim monomorphization, and Rust generic instantiation. This MEP specifies the (op, shape) enumeration scheme, the bytecode size impact, the codegen explosion bound, the fallback path for shape-unknown sites, the JIT cooperation model, and predicts MEP-23 numbers.	Draft
0029	VM2 Dispatch Strategy - Measured Results Head-to-head benchmark of the three dispatch strategies specified in MEP-26 (Migration), MEP-27 (Inline Cache) and MEP-28 (AOT codegen) on canonical workloads for two containers, lists (fill_sum) and strings (concat_loop). Sibling prototype packages under runtime/vm2/listopt/ and runtime/vm2/stropt/ implement each strategy in isolation. Lists, AOT wins narrowly, IC regresses substantially. Strings, all three rope-aware strategies trounce the today-shape baseline because the algorithmic O(N²) to O(N) win swamps the dispatch cost. The two containers point at opposite engineering choices, and the result inverts the design-stage MEP predictions in both cases.	Informational
0030	VM2 JIT Option A - Template / Copy-and-Patch Baseline JIT First of three competing JIT strategy specs for vm2. Each opcode handler is pre-compiled once into a position-independent native snippet, stored as a byte slice keyed by (opcode, shape-tuple), then concatenated and patched into an mmap'd executable buffer at function load. No IR, no register allocator, no inliner. The result is a non-optimizing baseline JIT in the lineage of V8 Sparkplug, JSC's Baseline JIT, and CPython 3.13's copy-and-patch JIT. This MEP specifies the snippet harvesting pipeline, the patcher ABI, the interpreter-compatible frame layout that makes OSR trivial, the deopt-free guard model, the distribution story (single Go binary, no cgo), and predicts a 2-4x speedup over the vm2 interpreter on fill_sum-class workloads.	Active
0031	VM2 JIT Option B - Tracing JIT over Typed Loops Second of three competing JIT strategy specs for vm2. The interpreter counts iterations of every back-edge; when a counter trips, the runtime begins recording a linear trace of typed Cell operations starting from that back-edge. The trace is closed when control returns to the same back-edge, optimized in straight-line form (constant folding, allocation removal, guard hoisting), and compiled to native via golang-asm. Subsequent iterations execute the compiled trace; any guard failure side-exits back to the interpreter. Lineage traces to LuaJIT (single-level, hand-coded) and PyPy (meta-tracing, RPython-generated). This MEP specifies the trace recorder, the trace-IR with explicit guards, the guard-keyed side-exit table, the trace tree shape, and predicts a 5-15x speedup on numeric loops at a 4-6x larger engineering scope than MEP-30.	Draft
0032	VM2 JIT Option C - Tiered Method JIT with Type Feedback Third of three competing JIT strategy specs for vm2. Two compilation tiers stacked on the interpreter: tier 1 is the MEP-30 copy-and-patch baseline JIT; tier 2 is a typed-SSA optimizing method JIT that consumes type feedback from MEP-27 inline caches, performs profile-guided inlining and escape analysis, and emits native code with linear-scan register allocation. Bidirectional on-stack replacement (OSR) moves frames between interpreter, tier 1, and tier 2 mid-execution; speculative tier-2 code deopts back to tier 1 on guard failure. Lineage traces to HotSpot C1/C2, JSC's four-tier strategy (LLInt, Baseline, DFG, FTL), and V8's Ignition / Sparkplug / Maglev / Turbofan pipeline. This MEP specifies tier transitions, the optimizing IR, the deopt protocol, the inlining heuristic, and predicts a 4-8x speedup with the broadest workload coverage of the three options.	Draft
0033	MEP-30 Template JIT - Measured Results First measured-results report for the MEP-30 template / copy-and-patch baseline JIT. A reference prototype lives under runtime/jit/tmpljit and implements a 6-opcode register VM plus a copy-and-patch JIT that lowers each opcode to a fixed AArch64 instruction sequence and stitches them into an mmap'd executable page. On a canonical fillsum workload at N=1024 on Apple M4, the JIT runs at 418 ns/op vs 7177 ns/op for the same-shape interpreter, a 17.2x speedup, beating LuaJIT (532 ns/op) and matching hand-written Go (499 ns/op) within 17%. At N=10000 the JIT edges out Go native (3883 vs 5025 ns/op) because the JIT loop carries no Go preemption check. CPython 3.14 lands at 23899 ns/op, ~57x slower than the JIT. Results validate the MEP-30 design and recommend proceeding to a full vm2-opcode prototype.	Informational
0034	VM2 Full-Opcode JIT - Lists, Strings, Maps, Sets, Structs Production-track spec for the next JIT after the MEP-30 prototype. Extends MEP-30's template / copy-and-patch design from the 6-opcode tmpljit toy to the full vm2 opcode set, with first-class native support for the five container subsystems (lists, strings, maps, sets, structs). Specifies per-opcode codegen templates, the frame-compatibility contract that lets the JIT and the vm2 interpreter share a Cell-shaped register file across calls, the Cell NaN-boxing fast paths and slow-path runtime callbacks, the cross-architecture backend split (darwin/arm64 + linux/amd64 from day one), and the benchmark plan that gates merge: head-to-head against the vm2 interpreter, LuaJIT, Lua 5.5, and CPython 3.14 on the MEP-23 corpus and on each container's hot ops. Predicts 3-6x over vm2 on list / arithmetic loops, 1.5-3x on string and map workloads, and parity with LuaJIT on numeric loops by Phase 3.	Active
0035	Auto Memory Management for the VM2 Objects Table Survey of modern auto memory management (Perceus / Koka / Roc, Inko, Lobster, Verona / Reggio regions, Immix / LXR, MMTk, generational ZGC / Shenandoah, JSC Riptide) and a design overview for reclaiming entries in the vm2 Objects table. Today the table is append-only inside a Run: every list, map, heap string, closure, and boxed big-int allocated by a program stays live until Run exits, regardless of whether the program still references it. This MEP proposes three implementation options (Perceus-style reference counting with reuse, per-frame region arenas, and an Immix / LXR mark-region collector layered over the Objects table) and a recommendation.	Draft
0036	Restructure VM2 to Reuse Go's GC Restructure the vm2 value representation so container payloads (lists, maps, heap strings, closures, boxed big ints, structs, sets) are reachable from each operand-stack slot via a real Go pointer, and the per-Run Objects []any indirection table can be reclaimed mid-Run. Today the NaN-boxed Cell stores a 48-bit index into Objects []any, so every list/map/string read pays a bounds check plus a type assertion (5 to 8 percent of CPU on container workloads per MEP-29), and Objects is append-only within a Run so dead containers cannot be freed until Run() exits. This MEP surveys modern VM-on-host-GC designs (Goja, starlark-go, Yaegi, Truffle, WasmGC, CRuby + MMTk), the Go-specific cost of interface boxing and the hybrid write barrier, and the allocation-minimization literature (Perceus, Roc, PLDI 2024 dynamic heapification, V8 Smi, .NET / Valhalla value types). It then specifies the smallest refactor that pays off: keep the 8-byte NaN-boxed Bits field, add a single 8-byte unsafe.Pointer field that GC traces on pointer-tagged cells (so Cell becomes 16 bytes, not 24), kill the indirection in container accessors, and zero pointer slots on popFrame so dead containers become collectible. Goal: zero allocations on the hot path for pure-numeric loops, one Go-tracked allocation per container constructor and zero per element, and full reclamation of dead containers between GC cycles, with the operand stack growing by 2x rather than 3x.	Active
0037	Benchmarks Game Parity with Go Define the full Computer Language Benchmarks Game corpus as a long-running performance target for vm2, audit each program's data and control-flow shape against the current runtime, and specify the data-model and VM enhancements required to reach within 2x of `go run` on each. The catalog covers the ten canonical BG benchmarks (binary_trees, fannkuch_redux, fasta, k_nucleotide, mandelbrot, n_body, pidigits, regex_redux, reverse_complement, spectral_norm). The gap analysis identifies four bottlenecks vm2 must close to reach Go parity: missing float arithmetic opcodes (every numeric BG kernel besides binary_trees / fannkuch is double-dominated), boxed Cell storage for homogeneous arrays (each element pays 16 bytes plus indirection where Go uses 8 bytes inline), per-node heap allocation for tree-shaped data, and absence of byte-string slicing without copy. The plan lands in four phases, each independently mergeable and benchmark-gated, with the headline goal being end-to-end BG numbers within 2x of Go on the workloads phase 1+2 cover and a credible path on the remaining four.	Active
0038	Closing the BG Gap to 2x Go via Byte Views and Native Lowering Extend MEP-37 with the concrete plan that takes vm2 from its current 115x-171x ratios on the Benchmarks Game corpus down to the 2x-of-Go target stated in MEP-37's abstract. Layer one (this MEP) ships the byte-view runtime (vmBytes) and minimal stdin/stdout that MEP-37 §3.5 deferred. Layer two ships JIT lowering for the typed-array and float-arithmetic op families so each BG kernel's hot loop compiles to native arm64/amd64 instead of going through the dispatch interpreter. Layer three ships a leaf-inline emit pass that absorbs per-byte function calls like reverse_complement's complement(). Each layer is independently mergeable; the BG gate progresses one program at a time as the layer that program needs lands. The MEP also contains a deep-research appendix that derives the theoretical lower bound for each kernel's runtime from the host hardware's instruction-issue rate, cache hierarchy, and branch mispredict cost, and shows where the current vm2 dispatch loop sits relative to that bound.	Draft
0039	Full Benchmarks Game Suite Across mochi/go/python/lua Bring the cross-language benchmark harness up to the canonical Benchmarks Game suite (all 10 programs) with parity templates in mochi, go, python, and lua. MEP-37 and MEP-38 covered six programs at the IR-builder level (binary_trees, n_body, mandelbrot, fannkuch_redux, spectral_norm, reverse_complement) but only binary_trees and nsieve had cross-lang templates wired into bench/crosslang. This MEP closes that gap on two fronts: (a) scaffold cross-lang templates for the five existing IR kernels plus four missing programs (fasta, k-nucleotide, pidigits, regex-redux), and (b) add the runtime features those programs need (bignum in vm2 for pidigits, regex builtins audit for regex-redux). The MEP captures the pre-implementation baseline for the 11 currently wired programs, the post-implementation full-suite baseline, and then deep-dives the per-program optimization theory required to land each program inside the 2x-of-Go gate that MEP-37 set.	Draft
0040	vm3 + compiler3: 8-byte handle Cell, typed arenas, static-type-driven dispatch First-principles successor stack to runtime/vm2 + compiler2. Replaces the 16-byte split Cell (Bits uint64 + Obj unsafe.Pointer) with an 8-byte NaN-boxed handle Cell that addresses per-type Go-allocated arenas. Replaces the single Cell[] frame register file with three typed banks (regsI64, regsF64, regsCell). Replaces compiler2's flat IR with compiler3's static-type-driven IR that propagates Mochi's static type system end-to-end so the interpreter and JIT never reason about types at runtime. Keeps Go's GC by making arena slabs the only pointer roots (handles are uint64 indices into typed slabs, not pointers). Phased to a production cut-over of bench harness, language server, and REPL over roughly six months.	Draft
0041	Memory Safety: capability handles, generational references, and CISA-roadmap alignment A first-principles memory-safety MEP for Mochi as of May 2026. Positions Mochi as a memory-safe language in the CISA / NSA / ONCD taxonomy by formalizing the safety property already paid for by the vm3 + compiler3 stack: an 8-byte handle Cell that is mathematically a Vale generational reference (POPL 2023 wave), an MSWasm-style unforgeable capability (OOPSLA 2024 Iris mechanization), and a CHERI-shape fat pointer at the language layer. Specifies the bytecode verifier rules that make handle integrity an invariant, the typed-arena partition that doubles as a kalloc_type / xzone typed-allocator (Apple MIE 2025), generation-as-secret hygiene against Tag Confidentiality Enforcement style leaks, optional reference modes (consume / borrow / inout / weak) layered on OxCaml-style mode axes, FFI sealing for safe Go-runtime handoff, and W^X + PAC/BTI + Spectre-index-masking hardening for the vm3jit code page. Includes a phased plan that culminates in a public Mochi memory-safety statement aligned to the CISA Secure-by-Design Pledge January 1 2026 roadmap obligation.	Draft
0042	Native Code Emission: copy-and-patch JIT, C-as-target AOT, and a Wasm-first cross-platform story A first-principles native code-emission MEP for Mochi as of May 2026. compiler3 already produces a typed IR with proven SSA value types; MEP-42 specifies how that IR lowers to host machine code on every platform Mochi can credibly ship to. The architecture chooses two complementary phase-1 backends: a copy-and-patch JIT (Xu+Kjolstad PLDI 2021, validated by CPython 3.13 in October 2024) for hot-loop execution under `mochi run`, and C-as-target AOT (Nim / V / Vala lineage) for `mochi build` distributable binaries. Phase 1 targets five host combinations (x86_64 Linux, aarch64 Linux, aarch64 macOS, x86_64 macOS, wasm32+WasmGC), all reachable from any Go host without cgo. Phase 2 adds Windows x86_64/aarch64, riscv64 Linux, an APE bundler, plus a native Wasm emitter and a QBE backend for higher-quality small binaries. Linker strategy: LLD by default, system linker fallback, self-hosted ELF/Mach-O/PE writers in phase 2 following Go cmd/link. Runtime strategy: glibc default, musl static-PIE for portable mode. Debug strategy: DWARF 5 line tables phase 1, full DWARF + optional PDB phase 2. The closest existing analog is Crystal; the case study to learn most from is .NET NativeAOT.	Draft
0043	Zero-Boilerplate Go Transpiler and Go FFI via go/types Introspection A first-principles design MEP for the Mochi to Go transpiler and the Mochi to Go foreign function interface, written as one document because they are the same problem viewed from two angles. The hard constraint is that Mochi ships zero per-package and zero per-syntactic-construct hand-written glue. The architecture rests on three generic pieces: a single type-bridge function that maps `go/types.Type` to and from compiler3 IR types, a build-time binding resolver that consumes any reachable Go package via `golang.org/x/tools/go/packages`, and a typed-IR to Go-source emitter sized to compiler3's ~50 op kinds. The emitted Go module imports the user's actual Go packages and calls them directly, so the Go compiler does the static checking and the Go runtime does the execution; Mochi adds no reflection, no marshalling, and no per-call overhead. The shipped Mochi runtime for the Go target is itself a normal Go module under `runtime/mochi/`, written once in idiomatic Go with normal Go tests, that the emitter calls into. The closest existing analog on the FFI side is Yaegi's `extract.go` symbol-table generator (the only deployed example of `go/types` driving a zero-per-package binding pipeline); on the transpiler side, Nim's typed-IR C backend (~50 op kinds drive a full systems language). The anti-pattern this MEP forecloses by name is the runtime reflection registry `Call(name, args...)`, which moves glue from compile time to runtime without deleting it.	Draft
0044	Type Bridge: a structural Go-to-Mochi type mapping for the zero-glue Go target Deep-dive specification of MEP-43 Phase 1: the structural type bridge that maps `go/types.Type` to a Mochi-side structural Type and back to a Go source-level type string. This is the only finite, hand-maintained mapping in the MEP-43 pipeline. Every later phase (binding resolver, Go-source emitter, runtime/mochi, export direction) consumes the output of this bridge; if a mapping is wrong here, every consumer is wrong. The bridge is built around a small structural `Type` value type carrying a kind, optional element/key/value/field/method children, and an opaque carrier that preserves the original `go/types.Type` for round-tripping unsupported Go shapes. The bridge has no per-package code and no per-symbol code; it is per-Go-type-shape only. Phase 1 ships in eight named sub-phases (1.1 type model through 1.8 stable gob serialisation), each gated by a measurable acceptance criterion, with the final gate being 100% of the Go 1.26 stdlib's exported surface either mapping to a structural Mochi type or being explicitly marked `KindOpaque` with a documented reason.	Draft
0045	Mochi-to-C transpiler: ahead-of-time native binaries via C as target language Standalone AOT pipeline that lowers a type-checked Mochi program to ISO C23 source plus a thin portable runtime (libmochi), then drives a vendored cross-cc to ship a statically linked single-file native binary for every tier-1 triple (x86_64-linux-{gnu,musl}, aarch64-linux-{gnu,musl}, aarch64-darwin, x86_64-darwin, x86_64-windows-msvc, x86_64-windows-gnu, wasm32-wasi). MEP-45 owns its full pipeline: parser → typed AST (reused frontends) → monomorphisation → aotir (its own lowering IR) → C source → cc → binary. The implementation lives in a new tree `transpiler3/c/` and shares nothing with prior backends past the parser and type checker. The proposal is additive: `mochi run` keeps the vm3 path; `mochi build --target=c` (and every native triple) routes through this pipeline. The master correctness gate is byte-equal stdout against vm3 on the full fixture corpus; vm3 acts only as the recording oracle, not as a code dependency. The runtime stands on proven third-party pieces (BDWGC for GC, mimalloc for the allocator, minicoro for fibers, yyjson for JSON, cwisstable for hash tables, libcurl for HTTP, utf8proc for Unicode). Generic types are fully monomorphised (Mochi forbids polymorphic recursion so the instantiation set is finite). Pattern matching lowers via Maranget decision trees (ML Workshop 2008). Try/catch lowers via setjmp/longjmp. Closures are fat pointers (code + env). The 20-phase delivery plan walks from hello-world through the full language surface, then cross-architecture, then APE one-binary-for-every-OS, then LLM and datalog and FFI, then sanitiser-clean + reproducible + perf gates. Every phase is gated; no phase ships until each target in its row is green. Twelve research notes covering every lowering case live under ~/notes/Spec/0045/.	Draft
0046	Mochi-to-Erlang/BEAM transpiler: concurrent, distributed runtime via Core Erlang as target Standalone pipeline that lowers a type-checked Mochi program to Core Erlang (via the `cerl` API), drives `compile:forms/2` with `from_core`, and packages the resulting `.beam` files as either an escript or an OTP release. MEP-46 owns its emit pass and its runtime library `mochi` but reuses MEP-45's `aotir` IR plus monomorphisation/closure-conversion passes. The proposal is additive: `mochi build --target=beam-escript` and `--target=beam-release` route Mochi through the BEAM pipeline; `mochi run` keeps the vm3 path; MEP-45's C target stays the AOT performance story. BEAM is the concurrency, supervision, hot-reload, and distribution story. The master correctness gate is byte-equal stdout against vm3 on the full fixture corpus across OTP 27 and OTP 28 on x86_64-linux-gnu and aarch64-darwin. Mochi agents lower to `gen_server`, streams to `pg` process groups, async/await to monitored spawn+receive, sum types to tagged tuples, records to BEAM maps, strings to UTF-8 binaries, fun types to BEAM closures. The runtime library `mochi` (Apache-2.0) publishes to Hex.pm as a thin layer over `pg`, `gen_server`, `gun`, the OTP 27 stdlib `json` module, and `telemetry`. The 19-phase delivery plan walks from hello-world through scalars, collections, records, sums, closures, queries, datalog, agents, streams, async, FFI, LLM, fetch, then escripts, releases, AtomVM, Dialyzer, and reproducibility. Each phase is gated against vm3. Twelve research notes covering every lowering case live under ~/notes/Spec/0046/.	Final
0047	Mochi-to-JVM transpiler: Maven Central ecosystem, Loom-native agents, GraalVM native-image AOT Standalone pipeline that lowers a type-checked Mochi program to Java source emitted via `javax.tools.JavaCompiler`, with a `java.lang.classfile` (ClassFile API, JEP 484) direct-bytecode fallback for hot lowerings. Packages the resulting `.class` files as an uberjar, a `jlink` runtime image, a `jpackage` installer, or a GraalVM `native-image` ahead-of-time executable. MEP-47 owns its emit pass and its runtime library `dev.mochi.runtime` but reuses MEP-45's `aotir` IR plus monomorphisation/closure-conversion passes shared with MEP-46. The proposal is additive: `mochi build --target=jvm-uberjar` and friends route Mochi through the JVM pipeline; `mochi run` keeps the vm3 path; MEP-45's C target stays the AOT single-binary story; MEP-46's BEAM target stays the supervision/hot-reload story. The JVM target is the Maven Central, Project Loom virtual threads, java.util.stream, GraalVM AOT, and JDK FFI story. The master correctness gate is byte-equal stdout against vm3 on the full fixture corpus across JDK 21 LTS and JDK 25 LTS on x86_64-linux-gnu, aarch64-linux-gnu, aarch64-darwin, and x86_64-windows. Mochi agents lower to Loom virtual threads with `BlockingQueue` mailboxes, streams to `java.util.concurrent.Flow.Publisher`, sum types to sealed interfaces + records, match to JDK 21 switch patterns (JEP 440 + JEP 441), strings to `java.lang.String`, fun types to lambdas via `LambdaMetafactory`. The runtime library `dev.mochi.runtime` (Apache-2.0) publishes to Maven Central via the new Central Publisher Portal as a thin layer over Jackson 2.18, snakeyaml-engine, java.net.http, and JFR. The 18-phase delivery plan walks from hello-world through scalars, collections, records, sums, closures, queries, datalog, agents, streams, async, JDK FFI, LLM, fetch, then uberjars, jlink, jpackage, GraalVM native-image, and reproducibility. Each phase is gated against vm3. Twelve research notes covering every lowering case live under ~/notes/Spec/0047/.	Final
0048	Mochi-to-.NET transpiler: NuGet ecosystem, async/await colouring, NativeAOT single-file binaries Standalone pipeline that lowers a type-checked Mochi program to C# source emitted via Roslyn `SyntaxFactory`, with a `System.Reflection.Emit` (and .NET 9 `PersistedAssemblyBuilder`) direct-IL fallback for agent trampolines and hot lowerings. Packages the resulting `.dll`/`.exe` as a framework-dependent assembly, a self-contained publish directory, or a NativeAOT single-file binary. MEP-48 owns its emit pass and its runtime library `Mochi.Runtime` but reuses MEP-45's `aotir` IR plus monomorphisation/closure-conversion passes shared with MEP-46 and MEP-47. The proposal is additive: `mochi build --target=dotnet-fx-dependent` and friends route Mochi through the .NET pipeline; `mochi run` keeps the vm3 path; MEP-45's C target stays the AOT single-binary story; MEP-46's BEAM target stays the supervision/hot-reload story; MEP-47's JVM target stays the Maven Central / Loom story. The .NET target is the NuGet, CLR reified generics, value types, LINQ, `System.Threading.Channels`, async/await, and NativeAOT story. The master correctness gate is byte-equal stdout against vm3 on the full fixture corpus across .NET 8 LTS and .NET 10 LTS on x86_64-linux-gnu, aarch64-linux-gnu, aarch64-darwin, and x86_64-windows. Mochi agents lower to `Channel<TMessage>` plus async dispatch loops, streams to `IAsyncEnumerable<T>`, sum types to sealed `abstract record` + `sealed record` hierarchies, match to C# 8+ switch expressions with C# 11 list patterns, strings to UTF-8 spans at boundaries and `System.String` (UTF-16) internally, fun types to `Func<...>`/`Action<...>` delegates. The runtime library `Mochi.Runtime` (Apache-2.0) publishes to NuGet as a thin layer over `System.Text.Json`, `System.Threading.Channels`, `System.Linq.Async`, `System.Collections.Immutable`, `System.Net.Http`, and `System.Diagnostics.DiagnosticSource`. The 18-phase delivery plan walks from hello-world through scalars, collections, records, sums, closures, queries, datalog, agents, streams, async, .NET FFI, LLM, fetch, then framework-dependent, self-contained, NativeAOT publish, reproducibility, and trim-clean. Each phase is gated against vm3. Twelve research notes covering every lowering case live under ~/notes/Spec/0048/.	Active
0049	Mochi-to-Swift transpiler: Apple platforms via SwiftPM, actor + AsyncStream agents, static Linux/Windows binaries Standalone pipeline that lowers a type-checked Mochi program to Swift 6.0 source, drives swiftc through SwiftPM (`swift build`) for libraries and Linux/Windows executables, and through xcodebuild for iOS/macOS/watchOS/tvOS/visionOS app bundles. MEP-49 owns its emit pass and its runtime library `MochiRuntime` (a SwiftPM package) but reuses MEP-45's `aotir` IR plus monomorphisation/closure-conversion passes shared with MEP-46, MEP-47, and MEP-48. The proposal is additive: `mochi build --target=swift-ios`, `--target=swift-macos`, `--target=swift-linux-static`, `--target=swift-windows` and friends route Mochi through the Swift pipeline; `mochi run` keeps the vm3 path; MEP-45's C target stays the AOT single-binary story; MEP-46's BEAM target stays the supervision/hot-reload story; MEP-47's JVM target stays the Maven Central / Loom story; MEP-48's .NET target stays the NuGet / NativeAOT story. The Swift target is the Apple App Store, SwiftUI-adjacent, server-side-Swift, CLR-style reified generics and value types, AsyncSequence, and ARC story. The master correctness gate is byte-equal stdout against vm3 on the full fixture corpus across Swift 6.0 and Swift 6.1 on x86_64-linux-gnu, aarch64-linux-gnu, aarch64-darwin, and x86_64-windows. Mochi agents lower to Swift `actor` types with `AsyncStream<Message>` mailboxes, streams to `AsyncSequence`, sum types to `enum` with associated values and exhaustive `switch`, records to `@frozen public struct`, fun types to typed Swift closures (including `@Sendable` for actor-crossing), strings to Swift `String` (UTF-8-native since Swift 5.7), errors to typed `throws(E)` (SE-0413). The runtime library `MochiRuntime` (Apache-2.0) publishes to the Swift Package Index and Apple's draft Swift Package Registry as a thin re-export of apple/swift-collections, apple/swift-algorithms, apple/swift-async-algorithms, apple/swift-numerics, apple/swift-system, apple/swift-log, plus Mochi-specific helpers (agent supervisor, datalog evaluator, query DSL extensions, JSON helpers, ZonedDateTime). The 18-phase delivery plan walks from hello-world through scalars, collections, records, sums, closures, queries, datalog, agents, streams, async, Swift FFI, LLM (FoundationModels on Apple), fetch (URLSession), then iOS app bundle, reproducibility, static Linux SDK single binary, and App Store validation. Each phase is gated against vm3. Twelve research notes covering every lowering case live under ~/notes/Spec/0049/.	Draft
0050	Mochi-to-Kotlin transpiler: Kotlin Multiplatform via Gradle, coroutine + Channel agents, Android .aab, K/Native single binaries Standalone pipeline that lowers a type-checked Mochi program to Kotlin 2.1 source, drives kotlinc through Gradle (`./gradlew build`) for Kotlin Multiplatform (KMP) projects spanning JVM, Android, Kotlin/Native (iOS, macOS, Linux, Windows), Kotlin/JS, and Kotlin/Wasm, and through the Android Gradle Plugin for Android `.aab` and `.apk` bundles. MEP-50 owns its emit pass and its runtime library `MochiRuntime` (a KMP Gradle module) but reuses MEP-45's `aotir` IR plus monomorphisation, match-to-decision-tree, closure-conversion, and exhaustiveness passes shared with MEP-46, MEP-47, MEP-48, and MEP-49. The proposal is additive: `mochi build --target=kotlin-jvm`, `--target=kotlin-android`, `--target=kotlin-ios-arm64`, `--target=kotlin-macos-arm64`, `--target=kotlin-linux-x64`, `--target=kotlin-linux-arm64`, `--target=kotlin-windows-x64`, `--target=kotlin-js-browser`, `--target=kotlin-js-node`, `--target=kotlin-wasm-js`, and `--target=kotlin-kmp-library` route Mochi through the Kotlin pipeline; `mochi run` keeps the vm3 path; MEP-45's C target stays the AOT single-binary story; MEP-46's BEAM target stays the supervision/hot-reload story; MEP-47's JVM target stays the direct-bytecode Maven Central / Loom story (distinct from MEP-50's source-level JVM output); MEP-48's .NET target stays the NuGet / NativeAOT story; MEP-49's Swift target stays the App Store / Apple platform story. The Kotlin target is the Android-first, Google Play Console, Kotlin Multiplatform iOS/desktop, Jetpack Compose, server-side Ktor, K2 compiler, sealed-interface ADT, kotlinx.coroutines structured-concurrency story. The master correctness gate is byte-equal stdout against vm3 on the full fixture corpus across Kotlin 2.1.0 and Kotlin 2.1.20 on x86_64-linux-gnu, aarch64-linux-gnu, aarch64-darwin, and x86_64-windows. Mochi agents lower to a custom actor class wrapping a `Channel<Message>` plus a `CoroutineScope(SupervisorJob() + Dispatchers.Default)` receive loop (the deprecated `actor { }` builder is not used), streams to `kotlinx.coroutines.flow.Flow<T>`, sum types to `sealed interface` with `data class` and `data object` variants, records to `data class`, fun types to Kotlin function or `suspend` function types, strings to Kotlin `String`, errors to a custom sealed `MochiResult<T, E>` return value (no checked exceptions). The runtime library `MochiRuntime` (Apache-2.0, ~6000 LOC) publishes to Maven Central as a KMP artifact and re-exports `kotlinx.coroutines`, `kotlinx.serialization`, `kotlinx.collections.immutable`, `kotlinx.datetime`, plus Mochi-specific helpers (agent supervisor, Datalog evaluator, query DSL extensions, JSONValue, ZonedDateTime). The 18-phase delivery plan walks from hello-world through scalars, collections, records, sums, closures, queries, datalog, agents, streams, async, FFI, LLM, fetch, Android App Bundle, reproducibility, K/Native single binaries, and Play Console validation. Each phase is gated against vm3. Twelve research notes covering every lowering case live under ~/notes/Spec/0050/.	Draft
0051	Mochi-to-Python transpiler: typed CPython 3.12 source, asyncio.Queue + TaskGroup agents, uv + hatchling wheels, ipykernel for Jupyter, PyPI Trusted Publishing Standalone pipeline that lowers a type-checked Mochi program to typed CPython 3.12+ source, drives the produced `pyproject.toml` project through uv 0.4+ and the PEP 517 `hatchling` build backend, and ships wheels (`.whl`), source distributions (`.tar.gz`), and a Jupyter `ipykernel` kernelspec ready for cell-by-cell execution inside JupyterLab. MEP-51 owns its emit pass and its runtime library `mochi_runtime` (a pure-Python PyPI package with optional native extensions) but reuses MEP-45's `aotir` IR plus monomorphisation, match-to-decision-tree, closure-conversion, and exhaustiveness passes shared with MEP-46, MEP-47, MEP-48, MEP-49, and MEP-50. The proposal is additive: `mochi build --target=python-wheel`, `--target=python-sdist`, `--target=python-ipykernel`, `--target=python-app`, and `--target=python-source` route Mochi through the Python pipeline; `mochi run` keeps the vm3 path; MEP-45 stays the AOT single-binary story; MEP-46 stays the BEAM supervision story; MEP-47 stays the direct-bytecode JVM and Loom story; MEP-48 stays the .NET NuGet and NativeAOT story; MEP-49 stays the Apple App Store story; MEP-50 stays the Android and Kotlin Multiplatform story. The Python target is the PyPI, NumPy / pandas / scikit-learn / PyTorch / JAX, FastAPI, Jupyter notebook, data-science, scripting, and machine-learning ecosystem story. The master correctness gate is byte-equal stdout against vm3 on the full fixture corpus across CPython 3.12.0 and CPython 3.13.0 on x86_64-linux-gnu, aarch64-linux-gnu, aarch64-darwin, and x86_64-windows; secondary compile-gates are `mypy --strict --python-version=3.12` and `pyright --strict` with no diagnostics and no `Any` leakage. Mochi agents lower to a custom Python class wrapping `asyncio.Queue[Message]` plus a `TaskGroup` (PEP 654) supervision scope; the legacy `asyncio.gather` is not used as the supervision primitive. Streams lower to `collections.abc.AsyncIterator`. Sum types lower to PEP 695 `type` aliases over frozen-slots `@dataclass(frozen=True, slots=True)` variants with exhaustive `match` (PEP 634). Records lower to frozen-slots dataclasses. Function types lower to `collections.abc.Callable` (sync) or `collections.abc.Awaitable` (async). Strings lower to `str` with code-point semantics matching Mochi. Errors lower to a custom `MochiResult` tagged union (Ok/Err) rather than Python exceptions, except where Mochi `panic` lowers to `raise RuntimeError`. The runtime library `mochi_runtime` (Apache-2.0, ~7000 LOC of Python plus optional ~500 LOC of C extension) publishes to PyPI as `mochi-runtime`, depends on `httpx` for HTTP, `anyio` only via the asyncio adapter (no Trio runtime path), and exposes a small Datalog engine, JSONValue ADT, agent supervisor, ZonedDateTime helpers over `zoneinfo`, and query DSL extensions. The 18-phase delivery plan walks from hello-world through scalars, collections, records, sums, closures, queries, datalog, agents, streams, async coloring, FFI (ctypes + CFFI), LLM, fetch, wheel/sdist build, reproducibility, ipykernel, and PyPI Trusted Publishing. Each phase is gated against vm3, mypy, pyright, and ruff. Twelve research notes covering every lowering case live under ~/notes/Spec/0051/.	Draft
0052	Mochi-to-TypeScript/JavaScript transpiler: TS 5.6 strict source + ES2024 JS dist, AsyncIterableQueue + AbortController agents, npm + tsc canonical, JSR + Deno + Bun + browser secondary, npm Trusted Publishing Standalone pipeline that lowers a type-checked Mochi program to typed TypeScript 5.6 source under strict mode (`--strict --noUncheckedIndexedAccess --exactOptionalPropertyTypes --noImplicitOverride --noFallthroughCasesInSwitch --noPropertyAccessFromIndexSignature`), drives the produced `package.json` project through npm 10+ as the canonical driver, runs `tsc --build` to emit ES2024 ECMAScript modules under `dist/{node,deno,bun,browser}/` with per-runtime conditional exports, and ships either standalone `.ts` source (`mochi build --target=typescript-source`), pre-compiled npm packages (`--target=npm-package`), Deno JSR distributions (`--target=deno-jsr`), single-file browser bundles via esbuild (`--target=browser-bundle`), or Deno Jupyter kernelspecs (`--target=deno-jupyter`). MEP-52 owns its emit pass and its runtime library `@mochi/runtime` (a TypeScript ESM package shipping under MIT plus Apache-2.0 dual license to npm and JSR) but reuses MEP-45's `aotir` IR plus monomorphisation, match-to-decision-tree, closure-conversion, exhaustiveness, and sendability passes shared with MEP-46 through MEP-51. The proposal is additive: `mochi build --target=typescript-source`, `--target=npm-package`, `--target=deno-jsr`, `--target=browser-bundle`, and `--target=deno-jupyter` route Mochi through the TypeScript pipeline; `mochi run` keeps the vm3 path; MEP-45 stays the AOT single-binary story; MEP-46 stays the BEAM supervision story; MEP-47 stays the direct-bytecode JVM and Loom story; MEP-48 stays the .NET NuGet and NativeAOT story; MEP-49 stays the Apple App Store story; MEP-50 stays the Android and Kotlin Multiplatform story; MEP-51 stays the PyPI, NumPy, and Jupyter ipykernel story. The TypeScript/JavaScript target is the npm ecosystem (over 3 million packages on npmjs.org as of 2026 Q1), the React/Vue/Svelte/SolidJS UI tier, the Node.js server tier (Express/Fastify/Hono/Elysia), the Deno Deploy and Cloudflare Workers edge tier, the Bun-native server tier, the only Mochi target that reaches the browser without a server install, the Electron and Tauri desktop tier, and the Jupyter notebook tier via Deno's official kernel. The master correctness gate is byte-equal stdout against vm3 on the full fixture corpus across Node 22 LTS, Deno 2.x, Bun 1.1.x, and headless browser (Playwright + Chromium 130+) on x86_64-linux-gnu, aarch64-linux-gnu, aarch64-darwin, and x86_64-windows; secondary compile-gates are `tsc --noEmit --strict --noUncheckedIndexedAccess --exactOptionalPropertyTypes` (zero diagnostics) and `eslint --max-warnings 0` with `@typescript-eslint/recommended-type-checked`. Mochi agents lower to a hand-rolled `AsyncIterableQueue<T>` mailbox plus an `AbortController` supervision scope; `Promise.withResolvers()` (ES2024) carries the `call(req)` reply future. Streams lower to `AsyncIterable<T>` / `AsyncGenerator<T, void, undefined>`. Sum types lower to discriminated unions over a literal `kind` tag with exhaustive `switch (x.kind)` enforced by `tsc --strict`. Records lower to `class` with `readonly` fields plus a private constructor and a static `of()` factory. Function types lower to `(args) => R` (sync) or `(args) => Promise<R>` (async). Strings lower to `string` (UTF-16 internal); the runtime ships `mochiStrLen(s)` and `mochiStrIndex(s, i)` for code-point semantics. Errors lower to a `MochiResult<T, E>` discriminated union (`{kind: 'ok', value: T} | {kind: 'err', error: E}`) rather than thrown exceptions; `panic` lowers to `throw new MochiPanic(msg)`. The runtime library `@mochi/runtime` (~6500 LOC of TypeScript across approximately 35 modules, zero npm dependencies in the default build, optional Node N-API / Bun FFI / Deno FFI bindings under sub-paths) publishes to npm with `--provenance` (Sigstore + GitHub OIDC, GA April 2024) and to JSR (`jsr.io`) for Deno-native consumption. The 18-phase delivery plan walks from hello-world through scalars, collections, records, sums, closures, queries, datalog, agents, streams, async coloring, FFI, LLM, fetch, then npm packaging, reproducibility, Deno JSR plus Jupyter plus browser, and npm Trusted Publishing. Each phase is gated against vm3, tsc strict, eslint, prettier, and execution on all four runtimes. Twelve research notes covering every lowering case live under ~/notes/Spec/0052/.	Draft
0053	Mochi-to-Rust transpiler: cargo-friendly source emission, structural rtree AST, single-thread channels and streams, FFI via sidecar C, reproducible cargo builds, wasm32-wasip1, and no_std embedded variant Standalone pipeline that lowers a type-checked Mochi program to Rust source emitted via a structural rtree AST, then drives cargo to ship a single-file native binary on the host triple, x86_64-unknown-linux-musl, aarch64-unknown-linux-musl, and wasm32-wasip1, plus a no_std + alloc embedded variant. MEP-53 owns its emit pass and its runtime crate `mochi-runtime` but reuses MEP-45's `aotir` IR plus monomorphisation and closure-conversion passes shared with MEP-46, MEP-47, MEP-48, MEP-49, MEP-50, MEP-51, MEP-52, and MEP-56. The proposal is additive: `mochi build --target=rust` and `--target=rust-source / --target=rust-crate / --target=wasm32-wasip1` route Mochi through the Rust pipeline; vm3 and the C / BEAM / JVM / .NET / Swift / Kotlin / Python / TypeScript / Ruby targets are unaffected. The master correctness gate is byte-equal stdout against vm3 on the full fixture corpus across stable Rust 1.95 host (aarch64-apple-darwin), cargo-zigbuild Linux musl x64 and arm64, wasm32-wasip1 under wasmtime, and `cargo check --no-default-features --features embedded` for the no_std + alloc subset. Mochi channels lower to a single-thread `Rc<RefCell<VecDeque>>` queue (no `std::sync`), streams to a single-thread broadcast over `Rc<RefCell<Vec<Rc<RefCell<VecDeque>>>>>`, sum types to tagged `enum` variants with `#[derive(Clone, Debug, PartialEq)]`, records to `#[derive(...)]` structs, closures to `Box<dyn Fn(...)>` with explicit capture clauses, agents to plain structs plus impl blocks, panic / try / catch to `std::panic::catch_unwind` with an `i64` payload, FFI to a sidecar `cffi/` C library wired through `cc-rs` build script, `httpGet` to a hand-rolled HTTP/1.1 GET over `std::net::TcpStream`, `json_decode` to a 90-LOC string-coercing object decoder, LLM `generate <provider> { ... }` to cassette replay keyed by SHA-256 of `provider:prompt`, and reproducible builds to SOURCE_DATE_EPOCH=0 plus RUSTFLAGS=-C strip=symbols (with a known-skip on macOS for LC_UUID non-determinism). The runtime crate `mochi-runtime` (Apache-2.0) ships `io`, `conv`, `strings`, `chan`, `stream`, `panic`, `fetch`, `json`, `llm`, and `check`, gated so that the `embedded` feature drops everything except `conv` and `strings`. The 19-phase delivery plan walks from skeleton through hello-world, scalars, collections, records, sums, closures, queries, datalog, agents, streams, try/catch, FFI, LLM, fetch, publish-ready crate metadata, reproducibility, wasm, and embedded. Each phase is gated against vm3.	Active
0054	Mochi-to-Go transpiler: gofmt-rendered source via structural gotree AST, native goroutines and channels, deterministic go build, cross-compile matrix, pkg.go.dev publish Standalone pipeline that lowers a type-checked Mochi program to Go source emitted via a structural gotree AST, then drives the Go toolchain to ship a single-file native binary on Go's first-class cross-compile matrix (linux/darwin/windows/freebsd on amd64/arm64), a publishable Go module, a wasm/JS bundle, or a wasip1 module. MEP-54 owns its emit pass and its runtime module `dev.mochilang/runtime/go` (Apache-2.0) but reuses MEP-45's `aotir` IR plus monomorphisation, match-to-decision-tree, closure-conversion, and sendability passes shared with MEP-46 through MEP-53, MEP-55, and MEP-56. The proposal is additive: `mochi build --target=go-linux-amd64`, `--target=go-darwin-arm64`, `--target=go-module`, `--target=go-wasm-js`, and `--target=go-wasip1` route Mochi through the Go pipeline; vm3 and the C / BEAM / JVM / .NET / Swift / Kotlin / Python / TypeScript / Rust / PHP / Ruby targets are unaffected. The master correctness gate is byte-equal stdout against vm3 on the full fixture corpus across Go 1.26.0 and Go 1.26.x latest on ubuntu-24.04, macos-15, and windows-2025. Mochi channels lower to native `chan T` with `make(chan T, cap)`; `send` and `recv` lower to `ch <- v` and `<-ch`; agents lower to a goroutine wrapping a `chan Message` receive loop; streams lower to a struct holding `[]chan T` subscriber slots with explicit backpressure via channel capacity; sum types lower to a discriminated interface with one final struct per variant satisfying the marker method; records lower to a Go struct with field-by-field comparison; closures lower to Go `func(...)` literals with explicit captures via the `ClosureEnvStmt` lifted-environment pattern; function types lower to `func(T1, T2) R`; strings lower to Go `string` (UTF-8 byte sequence); errors lower to `try { ... } catch e { ... }` via `defer` + `recover` with an `int64` payload; `panic` lowers to a runtime helper that wraps `runtime.Panic` so cross-panic-with-recover semantics stay consistent with vm3. The runtime module `dev.mochilang/runtime/go` (~1200 LOC of Go across ~10 packages, zero third-party deps in the default build) publishes to pkg.go.dev under the standard `go install` workflow. The 19-phase delivery plan walks from skeleton through hello-world, scalars, collections, records, sums, closures, queries (filter/map/order_by/skip-take/string-ops/joins/aggregations), builtins (string/math/file-io/csv/error/omap/hof), datalog, agents, streams, async, FFI, LLM, fetch, then go-module packaging, reproducibility (`-trimpath` + `-buildvcs=false`), wasm/wasip1, and signed publish. Each phase is gated against vm3.	Active
0055	Mochi-to-PHP 8.4 transpiler: Composer + Packagist canonical, Phar + FrankenPHP + RoadRunner packaging, GPG-signed releases with Sigstore attestation Standalone pipeline that lowers a type-checked Mochi program to PHP 8.4 source under `declare(strict_types=1);`, drives the produced Composer package through `composer install` plus PHPStan level 9 strict + Psalm 6 level 1 + php-cs-fixer (PER-CS2.0 + PHP84Migration), and ships either standalone `main.php` source (`mochi build --target=php-source`), a runnable Phar archive (`--target=php-phar`), a FrankenPHP app-server bundle (`--target=php-frankenphp`), or a RoadRunner worker-mode bundle (`--target=php-roadrunner`). MEP-55 owns its emit pass and its runtime library `mochi/runtime` (a Composer package shipping under MIT to Packagist) but reuses MEP-45's `aotir` IR plus monomorphisation, match-to-decision-tree, closure-conversion, exhaustiveness, and sendability passes shared with MEP-46 through MEP-54. The proposal is additive: `mochi build --target=php-source`, `--target=php-phar`, `--target=php-frankenphp`, and `--target=php-roadrunner` route Mochi through the PHP pipeline; `mochi run` keeps the vm3 path; MEP-45 stays the AOT single-binary story; MEP-46 stays the BEAM supervision story; MEP-47 stays the direct-bytecode JVM and Loom story; MEP-48 stays the .NET NuGet and NativeAOT story; MEP-49 stays the Apple App Store story; MEP-50 stays the Android and Kotlin Multiplatform story; MEP-51 stays the PyPI, NumPy, and Jupyter ipykernel story; MEP-52 stays the npm, JSR, and TypeScript-ESM story; MEP-53 stays the Rust crates.io, no_std, and embedded story; MEP-54 stays the Erlang/OTP supervision tree story. The PHP/Packagist target is the WordPress ecosystem, the Laravel, Symfony, and Drupal application tier, the Composer registry (over 400000 packages on Packagist), and the still-largest server-side web language by CMS deployment. The master correctness gate is byte-equal stdout against vm3 on the full fixture corpus across PHP 8.4.0 and PHP 8.4 latest on `ubuntu-24.04`, with `8.5` running allow-failure as a forward-compat smoke. Secondary compile-gates are `phpstan analyse --level=9 --error-format=raw` (zero errors), `psalm --no-cache --threads=1 --show-info=true` (zero issues), and `php-cs-fixer fix --dry-run --diff` (zero rewrites). Mochi agents lower to a final class wrapping a userland Channel<Message> (FIFO array + counter) plus a synchronous receive loop, since PHP has no preemptive scheduler; streams lower to a final class implementing `IteratorAggregate` and exposing `subscribe(int $limit)` with explicit backpressure (`drop` when full); sum types lower to an `abstract readonly class` (PHP 8.4 readonly inheritance) with `final readonly class` variants; records lower to `final readonly class` with constructor promotion; closures lower to PHP 8.1 first-class callable syntax (`$obj->method(...)`); function types lower to `Closure(string, int): bool` PHPDoc with Psalm/PHPStan inference; strings lower to PHP `string` (byte sequence); errors lower to a Result-style discriminated `final readonly class Ok` / `final readonly class Err` rather than throwing exceptions; `panic` lowers to `throw new \RuntimeException`. The runtime library `mochi/runtime` (~3500 LOC of PHP across ~25 files, zero Composer runtime deps in the default build, `psalm` and `phpstan` as dev-only deps, optional `amphp/revolt` deferred to a future MEP for true non-blocking I/O) publishes to Packagist with GPG-signed tags plus a Sigstore-backed `actions/attest-build-provenance@v1` OIDC attestation plus optional `drupal/php-signify` Ed25519 detached signatures. The 18-phase delivery plan walks from hello-world through scalars, collections, records, sums, closures, queries, datalog, agents, streams, async coloring (sync wrappers), FFI (FFI extension + sodium), LLM (cassette dispatch), fetch (curl), then Composer + PHPStan + Psalm green, reproducibility, Phar + FrankenPHP + RoadRunner packaging, and signed Packagist publication. Each phase is gated against vm3, PHPStan, Psalm, and execution on `8.4.0` and `8.4` latest. MEP-55 shipped as a single umbrella PR (#22481) on 2026-05-29 with all 18 phases pre-merged onto `impl/mep-0055-php`.	Final
0056	Mochi-to-Ruby transpiler: gem-friendly source emission, Data.define records, Channel agents, Thread::SizedQueue streams, Tebako and TruffleRuby native packaging Standalone pipeline that lowers a type-checked Mochi program to Ruby source emitted via a structural rtree AST, runnable on CRuby 3.2+, JRuby 10, TruffleRuby 33, and mruby 4. Packages the resulting .rb as a single script, a RubyGems gem, a Bundler bundle, a Jupyter IRuby notebook, a Tebako single-file binary, a TruffleRuby native-image, or an mruby embedded build. MEP-56 owns its emit pass and its runtime library `mochi-runtime` but reuses MEP-45's `aotir` IR plus monomorphisation and closure-conversion passes shared with MEP-46, MEP-47, and MEP-48. The proposal is additive: `mochi build --target=ruby-source` and friends route Mochi through the Ruby pipeline; vm3 and the C/BEAM/JVM/.NET targets are unaffected. The master correctness gate is byte-equal stdout against vm3 on the full fixture corpus across CRuby 3.2 LTS, CRuby 3.4, CRuby 4.0, JRuby 10, and TruffleRuby 33. Mochi agents lower to Ruby classes (with `spawn AgentType()` constructing zero-valued instances and intent calls routing through ordinary method dispatch), streams to a bounded MPMC broadcast channel built on `Thread::SizedQueue`, sum types to `Data.define` value classes plus case/in pattern matching, match to `case/in`, strings to UTF-8 (Ruby 3.2+ default encoding), and fun types to lambdas. The runtime library `mochi-runtime` (Apache-2.0) ships `Mochi::Runtime::Stream`, `Mochi::Runtime::Panic`, and `Mochi::Runtime::IO.putln` (deterministic float formatting). The 33-phase delivery plan (phases 0-32) walks from hello-world through scalars, collections, records, sums, closures, queries, datalog, channels, agents, streams, async, deep string ops, file/JSON/CSV/HTTP, try/catch, spawn, then RubyGem, Bundler, IRuby kernel, Tebako, TruffleRuby native, mruby packaging, and five audit passes. Each phase is gated against vm3.	Active
0057	Mochi module and package system: mochi.toml manifest + mochi.lock text lockfile + PubGrub-derived solver + sparse HTTPS registry index + BLAKE3 + SHA-256 dual-hashed content-addressed object store + Sigstore + OIDC keyless trusted publishing + capability declarations at the package boundary + polyglot fan-out to npm + JSR + PyPI + Maven Central + NuGet + crates.io + Hex + Swift Package Index First source-level package management system for Mochi. Specifies a TOML manifest (`mochi.toml`, Cargo / uv / Pixi shaped, plus three Mochi-only sections: `[capabilities]`, `[targets]`, `[provenance]`); a text lockfile (`mochi.lock`, TOML-shaped, version envelope, sorted keys, byte-stable serialisation, per-platform resolution sections); a PubGrub-derived version solver with incompatibility-driven conflict explanations (the algorithm used by uv since 2024, by Cargo's RFC #3796 next-gen resolver, by Rye, and by Dart's pub since 2018); a sparse HTTPS registry index at `index.mochi.dev` (Cargo-style, GA March 2023, 5-20x faster than git-cloned indexes at scale); a content-addressed object store keyed on BLAKE3-256 (primary, parallel, 3-7x faster than SHA-256) plus SHA-256 (secondary, for SLSA / Sigstore / npm interop) under `blobs.mochi.dev`; Sigstore-keyless trusted publishing via GitHub Actions / GitLab CI OIDC token exchange with Fulcio (matching npm Trusted Publishing GA April 2024, Maven Central Sigstore GA October 2024, PyPI PEP 740 GA late 2025, Cargo RFC #3724); capability declarations at the package boundary (closed set: `fs.read`, `fs.write`, `net.dial`, `net.listen`, `env`, `ffi`, `clock`, `random`, `proc.spawn`) audited at lock time and enforced at the transpiler boundary (Deno permissions, Wasm component model imports, Python `mochi_runtime.caps` runtime checks); polyglot fan-out from one `mochi.toml` to eight ecosystem artifacts (Mochi central, npm + JSR via MEP-52, PyPI via MEP-51, Maven Central via MEP-47, NuGet via MEP-48, crates.io via MEP-53, Hex via MEP-46, Swift Package Index via MEP-49); a SBOM and provenance pipeline emitting CycloneDX 1.6 and SPDX 3.0 plus per-target in-toto attestations; a `mochi audit` advisory-database query path against an RustSec-style YAML feed; reproducible package builds under `SOURCE_DATE_EPOCH` plus a sorted-tar normaliser producing byte-identical `.mochi.tar.zst`; a `mochi vendor` offline path; a registry mirror replication protocol; and a 20-phase delivery plan from package-stub skeleton through manifest, workspaces, lockfile, solver, local + network indexes, content store, capabilities, mirror, publish, trusted publishing, polyglot, SBOM, advisory DB, reproducibility, vendor, and workspace cache. Each phase is gated against the PubGrub fixture corpus, the lockfile byte-identical reproducibility check, four-platform CI (linux-x86_64 + linux-arm64 + macos-arm64 + windows-x86_64), Sigstore round-trip via a sigstore-mock-fulcio harness, CycloneDX schema validation, and an `mochi why` explanation-quality test. The reference implementation lives under `pkg/{pkgmanifest,pkglock,pkgsolver/pubgrub,pkgindex,pkgblob,pkgsign,pkgcap,pkgfanout}` plus `cmd/mochi/pkg.go`. Twelve research notes under `~/notes/Spec/0057/` cover prior art across Cargo, Go modules + workspaces, Deno + JSR, Bun, npm + Trusted Publishing, Python uv + PEP 751, Bazel bzlmod, Nix flakes, Swift PM, Hex, NuGet central package management, Pixi, Spack, Pkl, and the recent (2024-2026) literature on PubGrub, supply-chain provenance (Sigstore, SLSA, in-toto), reproducible builds, content-addressed code (Unison), capability-safe imports (Deno permissions, Wasm Component Model, Pony, Roc platforms), and empirical package-ecosystem studies.	Draft
0066	Mochi and Erlang/OTP package bridge: bidirectional package interop with the Hex.pm ecosystem via BEAM abstract-code typespec ingest, OTP Port protocol bridge (no NIF required), EDoc XML fallback, no-boilerplate import erlang syntax, TargetErlangPort publish via Hex.pm trusted publishing, and a content-addressed Erlang dependency cache under package3/erlang/ Bidirectional package interop between Mochi and the Hex.pm ecosystem. Direction 1 (Mochi as Erlang consumer): an `import erlang "<package>@<semver>" as <alias>` surface form auto-resolves through mochi.lock, fetches the Erlang application from Hex.pm into a content-addressed blob store under `~/.cache/mochi/erlang-deps/`, ingests typespecs from BEAM abstract-code chunks (the Dbgi/Abst chunk of each .beam file, decoded via Erlang External Term Format), falls back to EDoc XML for packages without inline -spec directives, translates Dialyzer typespecs through a closed typespec-to-Mochi table, emits a synthesised shim.erl (an Erlang module implementing the bridge surface over the OTP Port protocol) plus a matching shim.mochi extern fn corpus. Direction 2 (Mochi as Erlang producer): a TargetErlangPort build target lowers a Mochi package to a rebar3 application that wraps the compiled Mochi binary as an Erlang Port driver, populates rebar3/hex metadata from mochi.toml, and ships via `mochi pkg publish --to=hex.pm` using Hex.pm trusted publishing. The bridge is implemented in `package3/erlang/` and extends MEP-57's mochi.toml plus mochi.lock infrastructure. A 14-phase delivery plan covers skeleton, Hex.pm index client, BEAM abstract-code ingest, EDoc fallback, typespec-to-Mochi mapping, Port bridge emitter, import erlang grammar, rebar3 build orchestration, mochi.lock integration, TargetErlangPort emit, Hex.pm trusted publishing, OTP behavior bindings (gen_server/supervisor), async process bridge, and distributed Erlang node bridge.	Draft
0067	Mochi and Java package bridge: bidirectional Maven Central interop with JNI reflection ingest, auto-generated JNI wrapper, no-boilerplate import java syntax, Maven Central publish via Sonatype Central Portal, mochi.lock [[java-package]] pinning, and a content-addressed JAR cache under package3/java/ Bidirectional package interop between Mochi and the Maven Central ecosystem. Direction 1 (Mochi as Maven consumer): an `import java "<groupId>:<artifactId>@<version>" as <alias>` surface form auto-resolves through mochi.lock, fetches the JAR from Maven Central into a content-addressed blob store under `~/.cache/mochi/java-deps/`, runs a JVM reflection tool to extract the public API surface as JSON, walks that surface through a closed Java-to-Mochi type translation table (int/long/float/double/boolean/String/byte[]/List<T>/Map<K,V>/Optional<T>/CompletableFuture<T>/struct/enum plus a refusal set for raw Object, wildcards, inner classes, varargs, reflective types, and unchecked generics), synthesises JNI wrapper Java source via javac, and emits matching extern java type and extern java fn Mochi declarations. Direction 2 (Mochi as Maven producer): a TargetJavaLibrary build target packages the wrapper JAR and POM for upload to Maven Central via the Sonatype Central Portal API, with optional GPG signing and Sigstore attestation. The bridge is implemented in package3/java/ and extends MEP-57's mochi.toml plus mochi.lock infrastructure. A 16-phase delivery plan covers skeleton, Maven Central HTTP client with SHA-1 verification, content-addressed JAR cache, JVM reflection tool, type mapping table, Mochi extern shim emitter, import java grammar wiring, JNI embedding driver, build orchestration pipeline and javac driver, mochi.lock integration, TargetJavaLibrary emit, Maven Central publish flow, Sigstore attestation, async CompletableFuture bridge, generics and type-erasure handling, and spec update.	Draft
0068	Mochi and .NET package bridge: bidirectional NuGet interop with CLR assembly metadata ingest, auto-generated C# shim with UnmanagedCallersOnly exports, no-boilerplate import dotnet syntax, nuget.org publish via GitHub Actions OIDC trusted publishing, and a content-addressed .NET dependency cache under package3/dotnet/ Bidirectional package interop between Mochi and the .NET NuGet ecosystem. Direction 1 (Mochi as NuGet consumer): an `import dotnet "<package>@<semver>" as <alias>` surface form auto-resolves through the mochi.lock pin, fetches the .nupkg via the NuGet v3 API into the content-addressed blob store under `~/.cache/mochi/dotnet-deps/`, runs `mochi-dotnet-meta` (a small .NET CLI tool invoking System.Reflection.Metadata.MetadataReader) to extract a stable machine-readable assembly surface as JSON, walks that surface through a closed CLR-to-Mochi type translation table (int64/float/string/bool/List<T>/Dictionary<K,V>/T?/Task<T>/struct/record/interface/enum plus a refusal set for pointer types, unsafe types, generic type parameters beyond the monomorphised concretisations declared in mochi.toml, COM interop types, and types requiring runtime conditional compilation), and emits a synthesized C# shim assembly with [UnmanagedCallersOnly] exports wrapping the package API, plus matching extern type and extern fn Mochi declarations the parser accepts as if hand-written. Mochi calls into the shim via the CLR hosting API (hostfxr_initialize_for_runtime_config, hostfxr_get_runtime_delegate, load_assembly_and_get_function_pointer), which embeds the .NET runtime in-process; an opt-in NativeAOT path compiles the shim to a native .dylib/.so/.dll with a C-compatible header for packages that support AOT trimming. Direction 2 (Mochi as NuGet producer): a new MEP-53 build target TargetDotNetLibrary lowers a Mochi package to a publishable .NET assembly via C# emit (MEP-45/53 analogue), packages it as a .nupkg with a .nuspec manifest, and ships via `mochi pkg publish --to=nuget.org` using GitHub Actions OIDC trusted publishing (GA March 2024), with no long-lived NuGet API keys. The bridge is implemented in package3/dotnet/ and consumes MEP-57's mochi.toml plus mochi.lock infrastructure. The reference build adds a [[dotnet-package]] table to mochi.lock recording the resolved package version, SHA-512 of the .nupkg, SHA-256 of the mochi-dotnet-meta JSON output and the generated shim assembly, the user-declared capability surface (net, fs), and the target-framework moniker; a `mochi pkg lock --check` fails if metadata or shim drift would silently regenerate different bindings. The 14-phase delivery plan walks from package3/dotnet/ skeleton through NuGet v3 index client, assembly metadata ingest, type-mapping table, C# shim generator, Mochi extern emitter, import dotnet grammar extension, CLR hosting integration, mochi.lock integration, NuGet package emit, NuGet trusted publishing, async bridge, generics monomorphisation, and NativeAOT opt-in path. Each phase is gated against a per-package ingest fixture corpus drawn from a curated 20-package set (Newtonsoft.Json, Serilog, Microsoft.Extensions.DependencyInjection, System.Text.Json, Dapper, NUnit, xUnit, FluentAssertions, AutoMapper, MediatR, FluentValidation, Polly, Bogus, Moq, RestSharp, StackExchange.Redis, Npgsql, EntityFramework Core, Microsoft.Extensions.Http, AWSSDK.Core) covering the top-downloaded NuGet packages (April 2026 snapshot). The bridge does NOT attempt to translate arbitrary MSIL bytecode, does NOT support COM interop without an explicit opt-in, does NOT support unsafe pointer types without [dotnet.capabilities] unsafe = true, and does NOT cover packages whose public API relies on Windows-only P/Invoke surfaces without an explicit target-platform declaration.	Draft
0070	Mochi and Kotlin package bridge: bidirectional JVM interop with Kotlin Metadata ingest, auto-generated JNI/GraalVM native wrapper, no-boilerplate import kotlin syntax, Maven Central publish via Sonatype Central Portal trusted publishing, and a content-addressed Kotlin dependency cache under package3/kotlin/ Bidirectional package interop between Mochi and the Kotlin/JVM ecosystem. Direction 1 (Mochi as Kotlin library consumer): an `import kotlin "<group>:<artifact>@<semver>" as <alias>` surface form auto-resolves through the mochi.lock pin, fetches the JAR/AAR from Maven Central (or JitPack, Google Maven) into the content-addressed blob store under `~/.cache/mochi/kotlin-deps/`, runs kotlinx-metadata-jvm to extract the public Kotlin API surface from the JAR's kotlin.Metadata annotations, walks that surface through a closed Kotlin-to-Mochi type translation table (Int/Long/Double/Boolean/String/List/Map/Set/Pair/Triple/data-class/enum-class/sealed-class/nullable-T plus a refusal set for raw generics beyond declared instantiations, suspend functions without the coroutines bridge, platform types, and dynamic types), and emits either a GraalVM Native Image ahead-of-time compiled shared library (`kotlin_wrap/<artifact>/libwrap.so`) or a JNI-based runtime bridge depending on the target, plus matching `extern type` and `extern fn` Mochi declarations the parser accepts as if hand-written. Direction 2 (Mochi as Kotlin library producer): a new MEP-53 build target `TargetKotlinLibrary` lowers a Mochi package to a publishable JVM library JAR with proper kotlin.Metadata annotations, KDoc, POM metadata, sources JAR, and Javadoc JAR, and ships via `mochi pkg publish --to=maven-central` using Sonatype Central Portal's trusted-publishing flow with GPG signing. The bridge is implemented in `package3/kotlin/` and extends MEP-57's `mochi.toml` and `mochi.lock` infrastructure with `[kotlin-dependencies]`, `[[kotlin-package]]`, and `[kotlin.publish]` tables. The 14-phase delivery plan walks from skeleton through Maven sparse metadata client, blob cache, kotlinx-metadata-jvm ingest, type-mapping table, JNI/GraalVM wrapper synthesizer, Mochi extern emitter, `import kotlin` grammar extension, MEP-53 build orchestration, mochi.lock integration, TargetKotlinLibrary emit, Maven Central publish via trusted publishing, coroutines bridge via a kotlinx.coroutines adapter, generic instantiation via explicit monomorphise table, and a Kotlin Multiplatform subset path. Each phase is gated against a per-artifact ingest fixture corpus drawn from a curated 20-artifact set covering the top Kotlin/JVM ecosystem libraries.	Draft
0071	Mochi and Python package bridge: bidirectional PyPI interop with PEP 561 stub ingest, auto-generated cffi/cpython wrapper, no-boilerplate import python syntax, PyPI publish via Trusted Publishing + PEP 740 attestations, pylock.toml + mochi.lock dual pinning, and a content-addressed Python wheel cache under package3/python/ Bidirectional package interop between Mochi and the PyPI ecosystem. Direction 1 (Mochi as PyPI consumer): an `import python "<package>@<semver>" as <alias>` surface form auto-resolves through the mochi.lock pin, fetches the wheel via the PEP 503 / PEP 691 simple index (default index https://pypi.org/simple/) into the content-addressed blob store under `~/.cache/mochi/python-deps/`, verifies against PEP 700 SHA-256 hashes and PEP 740 sigstore attestations when present, walks the package's PEP 561 type stubs (preferring an inline `py.typed` distribution, falling back to a sibling `<name>-stubs` package, falling back to a typeshed snapshot, falling back to `stubgen --inspect-mode` against the installed wheel) to extract a fully-typed surface, walks that surface through a closed Python-to-Mochi type translation table (int / float / bool / str / bytes / list / tuple / dict / set / frozenset / Optional[T] / X|Y union / Callable / Awaitable / AsyncIterator / TypedDict / dataclass / Protocol plus a refusal set for unparameterised `Any`, `**kwargs` of unknown shape, ParamSpec, Concatenate, TypeVarTuple beyond declared monomorphisations, recursive generic bounds, opaque C-extension types lacking stubs, and Pyright-narrowed `Literal` types whose narrowing depends on runtime values), and emits a synthesised CPython-3.12-compatible wrapper Python package (`python_wrap/`) plus matching `extern python type` and `extern python fun` Mochi declarations the parser accepts as if hand-written. The wrapper is loaded via the existing MEP-51 Phase 12 sidecar pattern (`<modname>_externs.py` adjacent to the .mochi source). Direction 2 (Mochi as PyPI producer): the existing MEP-51 `TargetPythonWheel`, `TargetPythonSdist`, and `TargetPythonPublish` targets are extended with a new `mochi pkg publish --to=pypi` CLI surface, which builds the wheel + sdist via the existing MEP-51 Phase 15 emit path, then runs `uv publish --trusted-publishing always` against either PyPI (production) or TestPyPI (staging) using GitHub Actions OIDC + sigstore-keyless signing + PEP 740 attestations (extending the MEP-51 Phase 18 workflow renderer). The bridge is implemented in `package3/python/` (greenfield, parallel to `package3/rust/` and `package3/go/`) and consumes MEP-57's `mochi.toml` plus `mochi.lock` infrastructure. The reference build adds a `[[python-package]]` table to `mochi.lock` recording the resolved wheel filename and version, BLAKE3-256 + SHA-256 of the wheel artefact (the SHA-256 also matches the PEP 700 hash the PyPI simple index publishes), the stub-source provenance (`py.typed` / `<name>-stubs` / `typeshed` / `stubgen`), the user-declared capability surface (`net`, `fs`, `proc`, `subprocess`, `cextension`), and the synthesised wrapper SHA-256 (so a `mochi pkg lock --check` fails if a transitive stub drift would silently regenerate the wrapper with a different signature). The 18-phase delivery plan walks from package3/python/ skeleton through PEP 503 / 691 simple-index client, PEP 700 hash verification, content-addressed wheel cache, PEP 561 stub ingest, type-mapping table, wrapper synthesiser, Mochi extern emitter, `import python` semver grammar extension, MEP-51 build orchestration, mochi.lock integration, pylock.toml co-emit, `mochi pkg publish --to=pypi` CLI, PEP 740 attestation flow, async bridge via asyncio.run, ABI-stable wheel emission (abi3), C-extension fallback story, embedded / Pyodide subset path, and a TestPyPI dry-run gate. Each phase is gated against a curated 25-package fixture corpus (anyhow-Python-equivalents are not relevant; instead: numpy, pandas, scipy, scikit-learn, requests, httpx, urllib3, pillow, pydantic, attrs, click, typer, rich, tqdm, sqlalchemy, fastapi, starlette, uvicorn, aiohttp, pyyaml, toml, tomli, msgpack, orjson, pytest) covering the top-25-most-downloaded-on-pypistats.org April 2026 snapshot. The bridge does NOT attempt to translate arbitrary Python source AST, does NOT support packages that ship only C extensions with no `.pyi` stubs and no typeshed entry without an explicit `[capabilities] cextension = true` opt-in plus a hand-written shim, does NOT support packages whose runtime behaviour depends on `sys.argv` manipulation at import time, and does NOT cover packages mutated by import-time monkey-patching.	Draft
0072	Mochi and TypeScript/JavaScript package bridge: bidirectional npm + JSR module interop with TypeScript-compiler-API .d.ts ingest, runtime-native ESM linkage (no synthesized FFI wrapper), no-boilerplate import ts syntax, dual-registry consume (npmjs.org + jsr.io) with package-lock and JSR-integrity cross-check, dual-registry publish via npm Trusted Publishing (Sigstore + OIDC) + JSR Trusted Publishing, and a content-addressed JavaScript dependency cache under package3/typescript/ Bidirectional package interop between Mochi and the TypeScript / JavaScript ecosystem covering both npmjs.org and jsr.io as first-class registries. Direction 1 (Mochi as npm/JSR consumer): an `import ts "<pkg>@<semver>" as <alias>` surface form auto-resolves through the mochi.lock pin, fetches the source via the npm registry protocol (https://registry.npmjs.org) or the JSR sparse-index protocol (https://jsr.io/@scope/pkg/meta.json) into the content-addressed blob store under `~/.cache/mochi/ts-deps/`, verifies against the registry's published SHA-512 integrity field (npm) plus the JSR-side BLAKE3 manifest (mid-2024 Trusted-Publishing addendum), runs the TypeScript compiler API (`ts.createProgram` + `ts.TypeChecker`) against the package's distributed `.d.ts` files (or against the source `.ts` files for JSR packages, which JSR transpiles server-side and never publishes a separate dist tree), walks that surface through a closed TypeScript-to-Mochi type translation table (number↔float, bigint↔int, string↔string, boolean↔bool, T[]↔list, ReadonlyArray↔readonly-list, Record<K,V>↔map, Map<K,V>↔map, Set<T>↔set, T | null / T | undefined↔T?, tagged-union string-literal unions↔Mochi sum types, plain object types and interfaces↔record types, class types↔extern type opaque handles, Promise<T>↔async fun return, AsyncIterable<T>↔stream<T>, plus a refusal set for branded types whose witnesses are not exported, conditional types beyond the eager-resolution table, mapped types beyond Pick/Omit/Partial/Required/Readonly/Record, intersection of two object types whose merged shape has overlapping non-identical members, declaration-merging across multiple `.d.ts` files where the merged shape is not a strict union, ambient module declarations with no corresponding runtime export, `this` parameter polymorphism, default exports that are arrow-function literals whose inferred type the checker prints as `() => any`, decorator-injected metadata, and TypeScript-only `enum` declarations that cannot be statically expanded to a literal union), and emits matching Mochi `extern type` and `extern fn` declarations the parser accepts as if hand-written. Crucially, MEP-72 does NOT synthesize a separate wrapper package (unlike MEP-73 Rust's extern-C wrapper or MEP-74 Go's cgo c-archive) because TS/JS lives in the same JavaScript runtime that Mochi's MEP-52 transpiler already targets; the ingest-side type binding is sufficient and the link is a plain ESM `import` at runtime. Direction 2 (Mochi as npm/JSR producer): the existing MEP-52 build targets (`TargetNpmPackage`, `TargetDenoJsr`, `TargetBrowserBundle`, `TargetReleaseWorkflow`) cover the publish path; MEP-72 adds one new target `TargetNpmLibrary` that emits a typed library package (no `bin/`, no shebang, `"type": "module"`, `exports` map with `import` / `require` / `types` conditions, `.d.ts` emitted by `tsc --declaration`, root README + LICENSE + package.json metadata harvested from `mochi.toml`'s `[ts.publish]` table) plus a parallel `TargetJsrLibrary` that emits a source-not-dist JSR package (per MEP-52 Phase 17's source-not-dist invariant), and ships via `mochi pkg publish --to=npm` and `mochi pkg publish --to=jsr` using the MEP-52 Phase 18 Trusted-Publishing workflow (`actions/setup-node@v4` + `npm publish --provenance --access=public` + `deno publish --token-source=github-actions`). The bridge is implemented in `package3/typescript/` and consumes MEP-57's `mochi.toml` plus `mochi.lock` infrastructure. The reference build adds two new repeated lockfile tables, `[[npm-package]]` and `[[jsr-package]]`, recording the resolved registry, the resolved version, BLAKE3-256 + SHA-512 (npm side) or BLAKE3-256 + JSR-integrity (JSR side) of the tarball, the TypeScript compiler-API surface SHA-256 (a stable hash of the public d.ts shape used at bind time), the user-declared capability surface (`net`, `fs`, `proc`, `worker`, `wasm`, `eval`), and the resolved import-map fragment (so a `mochi pkg lock --check` fails if a downstream consumer's lockfile would silently shadow a different name resolution). The 18-phase delivery plan walks from package3/typescript/ skeleton through npm-registry client, JSR-registry client, `.d.ts` ingest via the TypeScript compiler API, ApiSurface JSON schema + bridge-side parser, closed type-mapping table, ESM linkage emitter (the Mochi-emitted JS imports the consumed package directly with no wrapper synthesis), `import ts "<pkg>@<semver>" as <alias>` grammar extension, build orchestration + import-map synthesis, mochi.lock integration + `--check` mode, `TargetNpmLibrary` emit, `TargetJsrLibrary` emit, npm Trusted-Publishing publish flow (reusing MEP-52 Phase 18 emit), JSR Trusted-Publishing publish flow, Promise / async bridge (Mochi `async fun` ↔ TS `Promise<T>`; no runtime singleton, the JS event loop is already there), monomorphisation of generic items (the user opts in via `[ts.monomorphise]` mochi.toml entries), an edge-runtime subset that admits Cloudflare-Workers + Vercel-Edge + Deno-Deploy + Bun-Edge compatible packages only (no `node:fs`, no `node:net`, no `node:child_process`, no `node:worker_threads`), an ESM-vs-CJS dual-package interop pass (the Mochi side emits ESM as MEP-52 already does; the bridge must accept consumed packages that ship CJS only, ESM only, or dual-export), and a Deno Jupyter notebook consume-side gate (deno-Jupyter kernel imports Mochi-published JSR packages and a published Mochi-emitted npm package consumed under `npm:` specifier). Each phase is gated against a per-package ingest fixture corpus drawn from a curated 24-package set (typescript, zod, lodash, lodash-es, react, react-dom, vue, axios, dayjs, date-fns, valibot, drizzle-orm, prisma, hono, express, fastify, undici, nanoid, uuid, ts-pattern, immer, effect, neverthrow, ts-toolbelt) covering the top-most-downloaded-on-npmjs.org April 2026 weekly snapshot. The bridge does NOT attempt to translate arbitrary TypeScript source without `.d.ts` (a pure-JS package without a `@types/<pkg>` companion is refused with a clear diagnostic), does NOT support source-file-side decorators whose metadata is not surfaced via `.d.ts`, does NOT support runtime monkey-patching at module-load time without a `[capabilities] eval = true` opt-in, and does NOT cover Node-native-addon packages (`.node` binary modules) at the bridge layer (those are handled by the MEP-52 Phase 12 FFI surface, not MEP-72).	Draft
0073	Mochi and Rust package bridge: bidirectional crate interop with rustdoc JSON ingest, auto-generated extern C wrapper crate, no-boilerplate import rust syntax, crates.io publish via Cargo RFC #3724 trusted publishing, and a content-addressed Rust dependency cache under package3/rust/ Bidirectional package interop between Mochi and the Rust crates.io ecosystem. Direction 1 (Mochi as crate consumer): an `import rust "<crate>@<semver>" as <alias>` surface form auto-resolves through the mochi.lock pin, fetches the source via the Cargo sparse-index protocol into the content-addressed blob store under `~/.cache/mochi/rust-deps/`, runs `cargo doc --output-format=json` to extract a stable machine-readable API surface, walks that surface through a closed Rust-to-Mochi type translation table (i64/f64/String/Vec/HashMap/Option/Result/struct/enum/tuple plus a refusal set for lifetimes, generics beyond the monomorphised concretisations declared in mochi.toml, raw pointers, impl Trait return positions, and Pin/Future types whose erasure would lose unwind safety), and emits a synthesized extern "C" wrapper crate (`rust_wrap/`) that the MEP-53 build path links into the final binary, plus matching `extern type` and `extern fn` Mochi declarations the parser accepts as if hand-written. Direction 2 (Mochi as crate producer): a new MEP-53 build target `TargetRustLibrary` lowers a Mochi package to a publishable Rust library crate with `[lib] crate-type = ["rlib", "cdylib"]`, exports the user's public API as `pub fn` and `pub struct` items, generates a cbindgen-compatible C header so downstream non-Rust consumers can link against it, sets the publish-side `[package]` metadata (description, license, repository, documentation, keywords, categories, readme), and ships via `mochi pkg publish --to=crates.io` using Cargo RFC #3724 Sigstore-keyless OIDC trusted publishing (matching MEP-57's broader signing principle; long-lived crates.io API tokens are not accepted). The bridge is implemented in `package3/rust/` and consumes MEP-57's `mochi.toml` plus `mochi.lock` infrastructure. The reference build adds a `[[rust-package]]` table to `mochi.lock` recording the resolved crate version, BLAKE3-256 + SHA-256 of the tarball, the rustdoc JSON revision hash, the user-declared capability surface (`net`, `fs`, `proc`, `unsafe`), and the generated wrapper SHA-256 (so a `mochi pkg lock --check` fails if a transitive rustdoc-JSON drift would silently regenerate the wrapper with a different signature). The 14-phase delivery plan walks from package3/rust/ skeleton through sparse-index client, blob cache, rustdoc-JSON ingest, type-mapping table, extern-C wrapper synthesizer, Mochi extern emitter, `import rust` grammar extension, MEP-53 build orchestration, mochi.lock integration, TargetRustLibrary emit, crates.io publish via trusted publishing, async-fn bridge via a tokio singleton, monomorphisation of generic crates, and an embedded-subset path that admits `no_std`-compatible crates only. Each phase is gated against a per-crate ingest fixture corpus drawn from a curated 24-crate set (anyhow, thiserror, serde, regex, rayon, itertools, once_cell, time, uuid, url, base64, hex, sha2, blake3, rand, rand_chacha, num_cpus, bytes, smallvec, indexmap, ahash, parking_lot, crossbeam, tokio) covering the top-25-most-downloaded-on-crates.io April 2026 snapshot. The bridge does NOT attempt to translate arbitrary Rust source, does NOT support proc-macros at import time, does NOT support `unsafe fn` items without an explicit `[capabilities] unsafe = true` opt-in, and does NOT cover crate features mutated by build-time cfg conditional compilation paths.	Draft
0074	Mochi and Go package bridge: bidirectional Go-module interop with go/packages + go/types ingest, auto-generated cgo wrapper package, no-boilerplate import go syntax, proxy.golang.org consume + git-tag publish flow, sum.golang.org checksum-DB pinning, optional Sigstore cosign signing, and a content-addressed Go dependency cache under package3/go/ Bidirectional package interop between Mochi and the Go module ecosystem. Direction 1 (Mochi as Go-module consumer): an `import go "<module>@<semver>" as <alias>` surface form auto-resolves through the mochi.lock pin, fetches the source via the Go module proxy protocol (GOPROXY=https://proxy.golang.org by default) into the content-addressed blob store under `~/.cache/mochi/go-deps/`, verifies against sum.golang.org's checksum database, runs `go/packages.Load` to extract a full `*types.Package` with every exported identifier and its `types.Type`, walks that surface through a closed Go-to-Mochi type translation table (int64/int32/float64/string/[]T/map[K]V/struct/interface/chan/func/pointer/error plus a refusal set for unexported fields, generic type parameters beyond the monomorphised concretisations declared in mochi.toml, `unsafe.Pointer`, `cgo.Handle`, runtime/internal types, type-erased `interface{}` return positions whose erasure would lose statically-checkable types, and reflective `reflect.Value` / `reflect.Type` plumbing), and emits a synthesized cgo-compatible wrapper Go package (`go_wrap/`) with `//export` directives that the MEP-54 build path links into the final binary via `go build -buildmode=c-archive` plus the existing cc-rs link surface, plus matching `extern type` and `extern fn` Mochi declarations the parser accepts as if hand-written. Direction 2 (Mochi as Go-module producer): a new MEP-54 build target `TargetGoLibrary` (separate from the existing `TargetGoModule`) lowers a Mochi package to a publishable Go module with a real `package <name>` directory layout, exports the user's public API as `func` and `type` declarations with proper godoc comments, populates `go.mod` with `module <vanity-path>`, generates a matching cgo `_cgo_export.h` for non-Go consumers, sets the publish-side metadata (the README at the repo root, the LICENSE file, the doc.go package comment, the `// Package foo provides ...` summary), and ships via `mochi pkg publish --to=go+git+<repo-url>@<tag>` by tagging a git commit, pushing the tag, and waiting for the module proxy to pick it up (with an optional Sigstore-cosign signature attached as a sibling tag `<tag>.sig` per the experimental gosum-cosign workflow draft of 2026-Q1). The bridge is implemented in `package3/go/` and consumes MEP-57's `mochi.toml` plus `mochi.lock` infrastructure. The reference build adds a `[[go-package]]` table to `mochi.lock` recording the resolved module path, the resolved version (a semver tag, a pseudo-version, or a git rev), BLAKE3-256 + h1: of the .zip module artefact (the h1: hash is what sum.golang.org publishes, so the lockfile cross-verifies against the public checksum DB), the go/packages JSON-form revision hash, the user-declared capability surface (`net`, `fs`, `proc`, `cgo`, `unsafe`), and the generated wrapper SHA-256 (so a `mochi pkg lock --check` fails if a transitive go/packages drift would silently regenerate the wrapper with a different signature). The 18-phase delivery plan walks from package3/go/ skeleton through GOPROXY client, sum.golang.org cross-check, content-addressed module cache, go/packages ingest, type-mapping table, cgo wrapper synthesizer, Mochi extern emitter, `import go` grammar wiring (the keyword already exists for MEP-54 phase 10 FFI; MEP-74 extends it to take semver), MEP-54 build orchestration, mochi.lock integration, TargetGoLibrary emit, git-tag publish flow, optional cosign signing, goroutine bridge (channels↔streams + spawn↔go statement), monomorphisation of generic functions, an embedded subset that admits TinyGo-compatible packages only, a vanity-import-path resolver, and a WASI / wasm-js publish gate. Each phase is gated against a per-module ingest fixture corpus drawn from a curated 24-module set (stretchr/testify, spf13/cobra, spf13/viper, sirupsen/logrus, google/uuid, gorilla/mux, pkg/errors, google/go-cmp, golang/protobuf, json-iterator/go, davecgh/go-spew, golang/mock, cespare/xxhash/v2, mattn/go-isatty, klauspost/compress, prometheus/client_golang, uber-go/zap, gopkg.in/yaml.v3, spf13/pflag, gin-gonic/gin, labstack/echo/v4, valyala/fasthttp, jmoiron/sqlx, fatih/color) covering the top-25-most-imported-on-pkg.go.dev April 2026 snapshot. The bridge does NOT attempt to translate `internal/` packages, does NOT support build-tag-conditional compilation paths whose tags are not declared in mochi.toml, does NOT support `cgo` source files inside imported modules without an explicit `[capabilities] cgo = true` opt-in, and does NOT cover `unsafe.Pointer` arithmetic at the FFI boundary.	Draft
0075	Mochi and PHP package bridge: bidirectional Composer interop with PHP Reflection API surface extraction, auto-generated Mochi extern shims, no-boilerplate import php syntax, Packagist v2 sparse API consume, API-token-plus-GPG publish with Sigstore attestation workaround for the missing OIDC gap, TargetPhpLibrary PSR-4 emission, and a content-addressed PHP dependency cache under package3/php/ Bidirectional package interop between Mochi and the PHP Composer/Packagist ecosystem. Direction 1 (Mochi as Packagist consumer): an `import php "vendor/package@^semver" as alias` surface form auto-resolves through the mochi.lock pin, fetches from Packagist v2's sparse API (`https://packagist.org/p2/<vendor>/<package>.json`) into the content-addressed blob store under `~/.cache/mochi/php-deps/<sha256-hex>/`, then invokes a Go-side PHP reflection CLI that runs `php reflect.php <package-path>` to walk the package's classes, interfaces, and functions via PHP's built-in Reflection API and emit a JSON surface document. The bridge walks that surface through a closed PHP-to-Mochi type translation table (int to int, float to float, string to string, bool to bool, ?T to T|nil, array to list or map depending on shape heuristic, class to opaque handle or record if all-typed, interface to protocol handle, void to unit, never to panic, mixed to SkipReport, callable to closure, self/static to SkipReport) and emits synthesised Mochi extern declarations plus PHP-side glue that leverages the MEP-55 PHP output pipeline directly (no extern C needed; the bridge targets PHP-to-PHP interop, so the wrapper is just `use VendorClass;` plus type-annotated call forwarding). The mochi.lock gains a `[[php-package]]` table recording resolved version, SHA-256 of the dist zip, SHA-256 of the reflection JSON, and capability surface (net, fs, db). Direction 2 (Mochi as Packagist producer): a new MEP-55 build target `TargetPhpLibrary` lowers a Mochi package to a publishable Composer library with a PSR-4 `src/` directory, a generated `composer.json` carrying metadata from `mochi.toml`, a `README.md`, and a `LICENSE` file. The `mochi pkg publish --to=packagist` flow tags the git commit, pings the Packagist Update API, and attaches a GPG-signed git tag plus a Sigstore attestation on the dist zip (reusing the MEP-55 Phase 18 trust chain). Packagist has no OIDC trusted publishing as of May 2026 (unlike crates.io, npm, and PyPI); MEP-75 acknowledges this gap, documents the API-token-plus-GitHub-App mitigation for CI environments, and describes the roadmap toward full OIDC when Packagist ships it. The bridge is implemented in `package3/php/` and consumes MEP-57's `mochi.toml` plus `mochi.lock` infrastructure and MEP-55's existing PHP lowering pipeline. The 15-phase delivery plan walks from package3/php/ skeleton through Packagist v2 sparse client, Composer dist fetcher and SHA-256 content-addressed cache, PHP reflection CLI, PHP-to-Mochi type table, Mochi extern emitter, import php grammar wiring, autoload.php plus composer install integration, mochi.lock integration, TargetPhpLibrary emit, Packagist publish flow, interface and abstract class bridge, async PHP bridge via ReactPHP/RevoltPHP, phar distribution path, and the full 24-package fixture corpus gate. Each phase is gated against a curated 24-package fixture corpus drawn from the April 2026 top Packagist download rankings (guzzlehttp/guzzle, symfony/console, symfony/http-foundation, laravel/framework, phpunit/phpunit, monolog/monolog, doctrine/orm, psr/log, nesbot/carbon, vlucas/phpdotenv, league/flysystem, paragonie/random_compat, ramsey/uuid, bacon/bacon-qr-code, spatie/laravel-permission, barryvdh/laravel-debugbar, composer/composer, phpmailer/phpmailer, symfony/mailer, league/oauth2-server, firebase/php-jwt, socialiteproviders/google, stripe/stripe-php, and one additional utility package). The bridge does NOT attempt to translate PHP source without a Reflection-API-visible surface, does NOT support PHP version ranges below 8.1, does NOT support async PHP without the explicit `[php.async]` opt-in, and does NOT use OIDC trusted publishing (a documented gap with a clear roadmap).	Draft
0076	Mochi and Ruby gem bridge: bidirectional package interop with RubyGems.org ecosystem via RBS type-sig ingest, direct require/call (no C FFI layer), gem_rbs_collection fallback, no-boilerplate import ruby syntax, TargetRubyGem publish via OIDC trusted publishing, and a content-addressed Ruby dependency cache under package3/ruby/ Bidirectional package interop between Mochi and the RubyGems.org ecosystem. Direction 1 (Mochi as gem consumer): an `import ruby "<gem>@<semver>" as <alias>` surface form auto-resolves through the mochi.lock pin, fetches the gem via the RubyGems sparse-index into the content-addressed blob store under `~/.cache/mochi/ruby-deps/`, ingest RBS type signatures (from the gem's own `sig/` directory, then from gem_rbs_collection, then from YARD doc as a last resort) through a closed RBS-to-Mochi type translation table, and emits a synthesised `.rb` shim (a thin `require` + method-wrapper file) plus a matching `.mochi` `extern fn` corpus. Because MEP-56 already transpiles Mochi to Ruby, there is no C FFI wrapper layer: the generated Ruby code simply calls `require '<gem>'` and invokes gem methods directly, the same as any Ruby script. Direction 2 (Mochi as gem producer): a `TargetRubyGem` build target (introduced by MEP-56 phase 22) lowers a Mochi package to a publishable RubyGems gem, populates gemspec metadata from `mochi.toml`, and ships via `mochi pkg publish --to=rubygems.org` using OIDC trusted publishing (GA on RubyGems.org 2023, via GitHub Actions `id-token: write`). The `mochi-runtime` gem (Apache-2.0, ~123 LOC) already on RubyGems.org from MEP-56 is the proof that Direction 2 works end-to-end. The bridge is implemented in `package3/ruby/` and consumes MEP-57's `mochi.toml` plus `mochi.lock` infrastructure. The reference build adds a `[[ruby-package]]` table to `mochi.lock` recording the resolved gem version, SHA-256 of the gem tarball, the RBS sig revision hash, the user-declared capability surface, and the generated shim SHA-256 (so a `mochi pkg lock --check` fails if a transitive RBS drift would silently regenerate the shim with a different signature). The 14-phase delivery plan walks from package3/ruby/ skeleton through RubyGems sparse-index client, RBS bundled-sig ingest, gem_rbs_collection fallback ingest, YARD doc fallback ingest, RBS-to-Mochi type mapping, Ruby shim emit, import ruby grammar extension, Bundler-based build orchestration, mochi.lock integration, TargetRubyGem publish metadata, OIDC trusted publishing, native C extension gem handling, and a Ractor/Fiber async bridge. Each phase is gated against a per-gem ingest fixture corpus drawn from 20 curated gems (json, rake, rack, faraday, httparty, redis, sinatra, rspec-core, rubocop, dry-types, zeitwerk, dotenv, activesupport, nokogiri, pg, aws-sdk-s3, openai, sidekiq, puma, mini_magick) covering the most-downloaded RubyGems.org gems plus representative C-extension and async use cases.	Draft

Process

MEP	Title	Status
0000	Index of Mochi Enhancement Proposals Index of Mochi Enhancement Proposals.	Active
0007	Soundness Progress, preservation, and the test obligations that prove them.	Active
0008	Test Strategy The five test layers, the golden harness, and the TAPL chapter mapping.	Active
0017	VM Performance Methodology and Baseline How Mochi measures, reports, and gates VM performance changes, with a reference benchmark suite and a regression budget.	Active
0023	Cross-language Baseline Benchmarks A periodic, hand-written cross-language benchmark suite that positions Mochi against Python and Lua on the same workloads, separate from the MEP-17 per-PR gate.	Active

Informational

MEP	Title	Status
0001	Lexer Mochi's token classes, reserved words, lexical errors, and conformance corpus, specified end-to-end with no corner cases.	Informational
0002	Grammar Mochi's PEG grammar in full, with the design principles and conformance obligations that fix the language.	Informational
0003	Abstract Syntax Tree Mochi's AST as a closed family of tagged unions, the encoding that makes parse output unambiguous, and the soundness invariants every consumer can rely on.	Informational
0004	Type System The kinds, the comparisons, the numeric tower, and the places where Mochi's type system does not yet do what it claims.	Informational
0006	Type Checker Entry point, builtin environment, statement walk, and the diagnostic catalogue.	Informational
0009	Fixture Catalogue Inventory of parser and type fixtures with a property coverage matrix.	Informational
0010	Known Gaps and Weakness Review Catalogue of soundness gaps, surprising behavior, and tracked follow-ups.	Informational
0014	Query Algebra LINQ-shaped query expressions, clause-by-clause type rules, and aggregate semantics.	Informational
0022	Baseline JIT via Copy-and-Patch (Deferred) A non-optimizing baseline JIT built on copy-and-patch compilation, planned as the long-term tier above the interpreter once MEP-18 through MEP-21 are exhausted. Co-designed with MEP-21 typed bytecode so the JIT consumes already-typed instructions and inherits zero speculative complexity from a dynamic front end.	Deferred
0029	VM2 Dispatch Strategy - Measured Results Head-to-head benchmark of the three dispatch strategies specified in MEP-26 (Migration), MEP-27 (Inline Cache) and MEP-28 (AOT codegen) on canonical workloads for two containers, lists (fill_sum) and strings (concat_loop). Sibling prototype packages under runtime/vm2/listopt/ and runtime/vm2/stropt/ implement each strategy in isolation. Lists, AOT wins narrowly, IC regresses substantially. Strings, all three rope-aware strategies trounce the today-shape baseline because the algorithmic O(N²) to O(N) win swamps the dispatch cost. The two containers point at opposite engineering choices, and the result inverts the design-stage MEP predictions in both cases.	Informational
0033	MEP-30 Template JIT - Measured Results First measured-results report for the MEP-30 template / copy-and-patch baseline JIT. A reference prototype lives under runtime/jit/tmpljit and implements a 6-opcode register VM plus a copy-and-patch JIT that lowers each opcode to a fixed AArch64 instruction sequence and stitches them into an mmap'd executable page. On a canonical fillsum workload at N=1024 on Apple M4, the JIT runs at 418 ns/op vs 7177 ns/op for the same-shape interpreter, a 17.2x speedup, beating LuaJIT (532 ns/op) and matching hand-written Go (499 ns/op) within 17%. At N=10000 the JIT edges out Go native (3883 vs 5025 ns/op) because the JIT loop carries no Go preemption check. CPython 3.14 lands at 23899 ns/op, ~57x slower than the JIT. Results validate the MEP-30 design and recommend proceeding to a full vm2-opcode prototype.	Informational

Standards Track

MEP	Title	Status
0005	Type Inference Strict static algebraic type inference. Principal types, no implicit any, no null.	Active
0011	Subtyping and Variance A separate subtype predicate, the variance lattice, and the closure of any.	Active
0012	Parametric Polymorphism System-F-lite call-site inference, fresh type variables, and the end of any-builtins.	Active
0013	Algebraic Data Types and Match Struct and union typing rules, match exhaustiveness, irredundancy, and recursive types.	Draft
0015	Effects A labeled effect system over function types. Pure by default, inferred from the body, annotatable at module boundaries, enforced where purity matters.	Draft
0016	Null Safety Total option discipline with no force unwrap, flow narrowing, safe-call and coalesce operators, and a no-panic guarantee.	Draft
0018	Bytecode Dispatch in a Go-Hosted VM What dispatch techniques work for the Mochi VM under the constraints of the Go runtime, with a concrete plan for the next 18 months.	Active
0019	Adaptive Specialization and Inline Caches Quickening generic opcodes into typed variants on first observation, plus monomorphic and polymorphic inline caches for the few remaining dynamic call sites.	Active
0020	Value Representation and Allocation Discipline A tighter Value struct, sync.Pool for frames and slabs, and an escape audit on the hot path of the Mochi VM.	Active
0021	Compiler2 and VM2 Co-Design for Maximum Interpreter Throughput A first-principles redesign of the Mochi compile-and-execute pipeline. Replace the observation-driven runtime with a typed SSA compiler (compiler2) that emits monomorphic bytecode into a redesigned vm2 with NaN-boxed 8-byte values, register allocation, tail calls, and bounds-check elision. No backward compatibility constraints. Target the absolute throughput ceiling of a Go-hosted interpreter on statically typed source.	Active
0024	VM2 Subsystem Design (Objects, Strings, Structs, Lists, Maps, Closures, GC, Errors) A consolidated subsystem design for vm2 that replaces the ad-hoc per-feature opcode growth of MEPs 18-21 with a single coherent plan for value representation, heap-allocated types, garbage collection, exception/Result handling, and the porting path to feature parity with the legacy VM. Co-designed with a comprehensive correctness + benchmark gate.	Active
0025	VM2 Data Model (Strings, Lists, Maps, Sets, Structs) Algorithmically modern in-memory representations for vm2's five core container kinds, strings, lists, maps, sets, structs, replacing the MEP-24 MVP shapes with shapes that close the Lua gap on the cross-language baseline and stay competitive after a future JIT lands. Specifies SSO + rope strings, type-specialized lists, Swiss-style int-keyed maps, presence-only set storage, and slot-packed structs. Implementation strategy is selected from three competing approaches detailed in MEP-26, MEP-27, MEP-28.	Active
0026	VM2 Data Model Option 1 - Monomorphic + One-Way Migration First of three competing dispatch-strategy specs for the MEP-25 data model. Each container starts in the smallest shape that fits its first operation and migrates exactly once, in place, to a more general shape on the first operation that does not fit. The monomorphic-then-generic lattice is the same one used by V8 hidden classes, PyPy storage strategies, Lua table promotion, CRuby shape trees, and Rust SmallVec. This MEP specifies the lattice formally, derives per-op steady-state cost, bounds migration cost over a program lifetime, analyzes JIT integration, and predicts MEP-23 numbers.	Draft
0027	VM2 Data Model Option 2 - Polymorphic + Inline Caches Second of three competing dispatch-strategy specs for the MEP-25 data model. Every container kind exposes one polymorphic shape, but each opcode site carries a small inline cache of recently-seen sub-shapes. The hot path stays monomorphic at the call-site granularity while the runtime remains structurally polymorphic. Lineage traces to Self, Smalltalk-80, V8, and SpiderMonkey. This MEP specifies the IC slot layout, the monomorphic / polymorphic / megamorphic state machine, per-op cost, IC memory budget, JIT integration, and predicts MEP-23 numbers.	Draft
0028	VM2 Data Model Option 3 - AOT Codegen Specialization Third of three competing dispatch-strategy specs for the MEP-25 data model. The compiler enumerates each opcode's operand-shape tuple at emit time and lowers each tuple to a distinct specialized opcode. No shape dispatch at runtime, no inline caches, no migration. The interpreter loop dispatches on opcode and runs specialized code directly. Lineage traces to LuaJIT specialized opcodes, Julia method specialization, Crystal and Nim monomorphization, and Rust generic instantiation. This MEP specifies the (op, shape) enumeration scheme, the bytecode size impact, the codegen explosion bound, the fallback path for shape-unknown sites, the JIT cooperation model, and predicts MEP-23 numbers.	Draft
0030	VM2 JIT Option A - Template / Copy-and-Patch Baseline JIT First of three competing JIT strategy specs for vm2. Each opcode handler is pre-compiled once into a position-independent native snippet, stored as a byte slice keyed by (opcode, shape-tuple), then concatenated and patched into an mmap'd executable buffer at function load. No IR, no register allocator, no inliner. The result is a non-optimizing baseline JIT in the lineage of V8 Sparkplug, JSC's Baseline JIT, and CPython 3.13's copy-and-patch JIT. This MEP specifies the snippet harvesting pipeline, the patcher ABI, the interpreter-compatible frame layout that makes OSR trivial, the deopt-free guard model, the distribution story (single Go binary, no cgo), and predicts a 2-4x speedup over the vm2 interpreter on fill_sum-class workloads.	Active
0031	VM2 JIT Option B - Tracing JIT over Typed Loops Second of three competing JIT strategy specs for vm2. The interpreter counts iterations of every back-edge; when a counter trips, the runtime begins recording a linear trace of typed Cell operations starting from that back-edge. The trace is closed when control returns to the same back-edge, optimized in straight-line form (constant folding, allocation removal, guard hoisting), and compiled to native via golang-asm. Subsequent iterations execute the compiled trace; any guard failure side-exits back to the interpreter. Lineage traces to LuaJIT (single-level, hand-coded) and PyPy (meta-tracing, RPython-generated). This MEP specifies the trace recorder, the trace-IR with explicit guards, the guard-keyed side-exit table, the trace tree shape, and predicts a 5-15x speedup on numeric loops at a 4-6x larger engineering scope than MEP-30.	Draft
0032	VM2 JIT Option C - Tiered Method JIT with Type Feedback Third of three competing JIT strategy specs for vm2. Two compilation tiers stacked on the interpreter: tier 1 is the MEP-30 copy-and-patch baseline JIT; tier 2 is a typed-SSA optimizing method JIT that consumes type feedback from MEP-27 inline caches, performs profile-guided inlining and escape analysis, and emits native code with linear-scan register allocation. Bidirectional on-stack replacement (OSR) moves frames between interpreter, tier 1, and tier 2 mid-execution; speculative tier-2 code deopts back to tier 1 on guard failure. Lineage traces to HotSpot C1/C2, JSC's four-tier strategy (LLInt, Baseline, DFG, FTL), and V8's Ignition / Sparkplug / Maglev / Turbofan pipeline. This MEP specifies tier transitions, the optimizing IR, the deopt protocol, the inlining heuristic, and predicts a 4-8x speedup with the broadest workload coverage of the three options.	Draft
0034	VM2 Full-Opcode JIT - Lists, Strings, Maps, Sets, Structs Production-track spec for the next JIT after the MEP-30 prototype. Extends MEP-30's template / copy-and-patch design from the 6-opcode tmpljit toy to the full vm2 opcode set, with first-class native support for the five container subsystems (lists, strings, maps, sets, structs). Specifies per-opcode codegen templates, the frame-compatibility contract that lets the JIT and the vm2 interpreter share a Cell-shaped register file across calls, the Cell NaN-boxing fast paths and slow-path runtime callbacks, the cross-architecture backend split (darwin/arm64 + linux/amd64 from day one), and the benchmark plan that gates merge: head-to-head against the vm2 interpreter, LuaJIT, Lua 5.5, and CPython 3.14 on the MEP-23 corpus and on each container's hot ops. Predicts 3-6x over vm2 on list / arithmetic loops, 1.5-3x on string and map workloads, and parity with LuaJIT on numeric loops by Phase 3.	Active
0035	Auto Memory Management for the VM2 Objects Table Survey of modern auto memory management (Perceus / Koka / Roc, Inko, Lobster, Verona / Reggio regions, Immix / LXR, MMTk, generational ZGC / Shenandoah, JSC Riptide) and a design overview for reclaiming entries in the vm2 Objects table. Today the table is append-only inside a Run: every list, map, heap string, closure, and boxed big-int allocated by a program stays live until Run exits, regardless of whether the program still references it. This MEP proposes three implementation options (Perceus-style reference counting with reuse, per-frame region arenas, and an Immix / LXR mark-region collector layered over the Objects table) and a recommendation.	Draft
0036	Restructure VM2 to Reuse Go's GC Restructure the vm2 value representation so container payloads (lists, maps, heap strings, closures, boxed big ints, structs, sets) are reachable from each operand-stack slot via a real Go pointer, and the per-Run Objects []any indirection table can be reclaimed mid-Run. Today the NaN-boxed Cell stores a 48-bit index into Objects []any, so every list/map/string read pays a bounds check plus a type assertion (5 to 8 percent of CPU on container workloads per MEP-29), and Objects is append-only within a Run so dead containers cannot be freed until Run() exits. This MEP surveys modern VM-on-host-GC designs (Goja, starlark-go, Yaegi, Truffle, WasmGC, CRuby + MMTk), the Go-specific cost of interface boxing and the hybrid write barrier, and the allocation-minimization literature (Perceus, Roc, PLDI 2024 dynamic heapification, V8 Smi, .NET / Valhalla value types). It then specifies the smallest refactor that pays off: keep the 8-byte NaN-boxed Bits field, add a single 8-byte unsafe.Pointer field that GC traces on pointer-tagged cells (so Cell becomes 16 bytes, not 24), kill the indirection in container accessors, and zero pointer slots on popFrame so dead containers become collectible. Goal: zero allocations on the hot path for pure-numeric loops, one Go-tracked allocation per container constructor and zero per element, and full reclamation of dead containers between GC cycles, with the operand stack growing by 2x rather than 3x.	Active
0037	Benchmarks Game Parity with Go Define the full Computer Language Benchmarks Game corpus as a long-running performance target for vm2, audit each program's data and control-flow shape against the current runtime, and specify the data-model and VM enhancements required to reach within 2x of `go run` on each. The catalog covers the ten canonical BG benchmarks (binary_trees, fannkuch_redux, fasta, k_nucleotide, mandelbrot, n_body, pidigits, regex_redux, reverse_complement, spectral_norm). The gap analysis identifies four bottlenecks vm2 must close to reach Go parity: missing float arithmetic opcodes (every numeric BG kernel besides binary_trees / fannkuch is double-dominated), boxed Cell storage for homogeneous arrays (each element pays 16 bytes plus indirection where Go uses 8 bytes inline), per-node heap allocation for tree-shaped data, and absence of byte-string slicing without copy. The plan lands in four phases, each independently mergeable and benchmark-gated, with the headline goal being end-to-end BG numbers within 2x of Go on the workloads phase 1+2 cover and a credible path on the remaining four.	Active
0038	Closing the BG Gap to 2x Go via Byte Views and Native Lowering Extend MEP-37 with the concrete plan that takes vm2 from its current 115x-171x ratios on the Benchmarks Game corpus down to the 2x-of-Go target stated in MEP-37's abstract. Layer one (this MEP) ships the byte-view runtime (vmBytes) and minimal stdin/stdout that MEP-37 §3.5 deferred. Layer two ships JIT lowering for the typed-array and float-arithmetic op families so each BG kernel's hot loop compiles to native arm64/amd64 instead of going through the dispatch interpreter. Layer three ships a leaf-inline emit pass that absorbs per-byte function calls like reverse_complement's complement(). Each layer is independently mergeable; the BG gate progresses one program at a time as the layer that program needs lands. The MEP also contains a deep-research appendix that derives the theoretical lower bound for each kernel's runtime from the host hardware's instruction-issue rate, cache hierarchy, and branch mispredict cost, and shows where the current vm2 dispatch loop sits relative to that bound.	Draft
0039	Full Benchmarks Game Suite Across mochi/go/python/lua Bring the cross-language benchmark harness up to the canonical Benchmarks Game suite (all 10 programs) with parity templates in mochi, go, python, and lua. MEP-37 and MEP-38 covered six programs at the IR-builder level (binary_trees, n_body, mandelbrot, fannkuch_redux, spectral_norm, reverse_complement) but only binary_trees and nsieve had cross-lang templates wired into bench/crosslang. This MEP closes that gap on two fronts: (a) scaffold cross-lang templates for the five existing IR kernels plus four missing programs (fasta, k-nucleotide, pidigits, regex-redux), and (b) add the runtime features those programs need (bignum in vm2 for pidigits, regex builtins audit for regex-redux). The MEP captures the pre-implementation baseline for the 11 currently wired programs, the post-implementation full-suite baseline, and then deep-dives the per-program optimization theory required to land each program inside the 2x-of-Go gate that MEP-37 set.	Draft
0040	vm3 + compiler3: 8-byte handle Cell, typed arenas, static-type-driven dispatch First-principles successor stack to runtime/vm2 + compiler2. Replaces the 16-byte split Cell (Bits uint64 + Obj unsafe.Pointer) with an 8-byte NaN-boxed handle Cell that addresses per-type Go-allocated arenas. Replaces the single Cell[] frame register file with three typed banks (regsI64, regsF64, regsCell). Replaces compiler2's flat IR with compiler3's static-type-driven IR that propagates Mochi's static type system end-to-end so the interpreter and JIT never reason about types at runtime. Keeps Go's GC by making arena slabs the only pointer roots (handles are uint64 indices into typed slabs, not pointers). Phased to a production cut-over of bench harness, language server, and REPL over roughly six months.	Draft
0041	Memory Safety: capability handles, generational references, and CISA-roadmap alignment A first-principles memory-safety MEP for Mochi as of May 2026. Positions Mochi as a memory-safe language in the CISA / NSA / ONCD taxonomy by formalizing the safety property already paid for by the vm3 + compiler3 stack: an 8-byte handle Cell that is mathematically a Vale generational reference (POPL 2023 wave), an MSWasm-style unforgeable capability (OOPSLA 2024 Iris mechanization), and a CHERI-shape fat pointer at the language layer. Specifies the bytecode verifier rules that make handle integrity an invariant, the typed-arena partition that doubles as a kalloc_type / xzone typed-allocator (Apple MIE 2025), generation-as-secret hygiene against Tag Confidentiality Enforcement style leaks, optional reference modes (consume / borrow / inout / weak) layered on OxCaml-style mode axes, FFI sealing for safe Go-runtime handoff, and W^X + PAC/BTI + Spectre-index-masking hardening for the vm3jit code page. Includes a phased plan that culminates in a public Mochi memory-safety statement aligned to the CISA Secure-by-Design Pledge January 1 2026 roadmap obligation.	Draft
0042	Native Code Emission: copy-and-patch JIT, C-as-target AOT, and a Wasm-first cross-platform story A first-principles native code-emission MEP for Mochi as of May 2026. compiler3 already produces a typed IR with proven SSA value types; MEP-42 specifies how that IR lowers to host machine code on every platform Mochi can credibly ship to. The architecture chooses two complementary phase-1 backends: a copy-and-patch JIT (Xu+Kjolstad PLDI 2021, validated by CPython 3.13 in October 2024) for hot-loop execution under `mochi run`, and C-as-target AOT (Nim / V / Vala lineage) for `mochi build` distributable binaries. Phase 1 targets five host combinations (x86_64 Linux, aarch64 Linux, aarch64 macOS, x86_64 macOS, wasm32+WasmGC), all reachable from any Go host without cgo. Phase 2 adds Windows x86_64/aarch64, riscv64 Linux, an APE bundler, plus a native Wasm emitter and a QBE backend for higher-quality small binaries. Linker strategy: LLD by default, system linker fallback, self-hosted ELF/Mach-O/PE writers in phase 2 following Go cmd/link. Runtime strategy: glibc default, musl static-PIE for portable mode. Debug strategy: DWARF 5 line tables phase 1, full DWARF + optional PDB phase 2. The closest existing analog is Crystal; the case study to learn most from is .NET NativeAOT.	Draft
0043	Zero-Boilerplate Go Transpiler and Go FFI via go/types Introspection A first-principles design MEP for the Mochi to Go transpiler and the Mochi to Go foreign function interface, written as one document because they are the same problem viewed from two angles. The hard constraint is that Mochi ships zero per-package and zero per-syntactic-construct hand-written glue. The architecture rests on three generic pieces: a single type-bridge function that maps `go/types.Type` to and from compiler3 IR types, a build-time binding resolver that consumes any reachable Go package via `golang.org/x/tools/go/packages`, and a typed-IR to Go-source emitter sized to compiler3's ~50 op kinds. The emitted Go module imports the user's actual Go packages and calls them directly, so the Go compiler does the static checking and the Go runtime does the execution; Mochi adds no reflection, no marshalling, and no per-call overhead. The shipped Mochi runtime for the Go target is itself a normal Go module under `runtime/mochi/`, written once in idiomatic Go with normal Go tests, that the emitter calls into. The closest existing analog on the FFI side is Yaegi's `extract.go` symbol-table generator (the only deployed example of `go/types` driving a zero-per-package binding pipeline); on the transpiler side, Nim's typed-IR C backend (~50 op kinds drive a full systems language). The anti-pattern this MEP forecloses by name is the runtime reflection registry `Call(name, args...)`, which moves glue from compile time to runtime without deleting it.	Draft
0044	Type Bridge: a structural Go-to-Mochi type mapping for the zero-glue Go target Deep-dive specification of MEP-43 Phase 1: the structural type bridge that maps `go/types.Type` to a Mochi-side structural Type and back to a Go source-level type string. This is the only finite, hand-maintained mapping in the MEP-43 pipeline. Every later phase (binding resolver, Go-source emitter, runtime/mochi, export direction) consumes the output of this bridge; if a mapping is wrong here, every consumer is wrong. The bridge is built around a small structural `Type` value type carrying a kind, optional element/key/value/field/method children, and an opaque carrier that preserves the original `go/types.Type` for round-tripping unsupported Go shapes. The bridge has no per-package code and no per-symbol code; it is per-Go-type-shape only. Phase 1 ships in eight named sub-phases (1.1 type model through 1.8 stable gob serialisation), each gated by a measurable acceptance criterion, with the final gate being 100% of the Go 1.26 stdlib's exported surface either mapping to a structural Mochi type or being explicitly marked `KindOpaque` with a documented reason.	Draft
0045	Mochi-to-C transpiler: ahead-of-time native binaries via C as target language Standalone AOT pipeline that lowers a type-checked Mochi program to ISO C23 source plus a thin portable runtime (libmochi), then drives a vendored cross-cc to ship a statically linked single-file native binary for every tier-1 triple (x86_64-linux-{gnu,musl}, aarch64-linux-{gnu,musl}, aarch64-darwin, x86_64-darwin, x86_64-windows-msvc, x86_64-windows-gnu, wasm32-wasi). MEP-45 owns its full pipeline: parser → typed AST (reused frontends) → monomorphisation → aotir (its own lowering IR) → C source → cc → binary. The implementation lives in a new tree `transpiler3/c/` and shares nothing with prior backends past the parser and type checker. The proposal is additive: `mochi run` keeps the vm3 path; `mochi build --target=c` (and every native triple) routes through this pipeline. The master correctness gate is byte-equal stdout against vm3 on the full fixture corpus; vm3 acts only as the recording oracle, not as a code dependency. The runtime stands on proven third-party pieces (BDWGC for GC, mimalloc for the allocator, minicoro for fibers, yyjson for JSON, cwisstable for hash tables, libcurl for HTTP, utf8proc for Unicode). Generic types are fully monomorphised (Mochi forbids polymorphic recursion so the instantiation set is finite). Pattern matching lowers via Maranget decision trees (ML Workshop 2008). Try/catch lowers via setjmp/longjmp. Closures are fat pointers (code + env). The 20-phase delivery plan walks from hello-world through the full language surface, then cross-architecture, then APE one-binary-for-every-OS, then LLM and datalog and FFI, then sanitiser-clean + reproducible + perf gates. Every phase is gated; no phase ships until each target in its row is green. Twelve research notes covering every lowering case live under ~/notes/Spec/0045/.	Draft
0046	Mochi-to-Erlang/BEAM transpiler: concurrent, distributed runtime via Core Erlang as target Standalone pipeline that lowers a type-checked Mochi program to Core Erlang (via the `cerl` API), drives `compile:forms/2` with `from_core`, and packages the resulting `.beam` files as either an escript or an OTP release. MEP-46 owns its emit pass and its runtime library `mochi` but reuses MEP-45's `aotir` IR plus monomorphisation/closure-conversion passes. The proposal is additive: `mochi build --target=beam-escript` and `--target=beam-release` route Mochi through the BEAM pipeline; `mochi run` keeps the vm3 path; MEP-45's C target stays the AOT performance story. BEAM is the concurrency, supervision, hot-reload, and distribution story. The master correctness gate is byte-equal stdout against vm3 on the full fixture corpus across OTP 27 and OTP 28 on x86_64-linux-gnu and aarch64-darwin. Mochi agents lower to `gen_server`, streams to `pg` process groups, async/await to monitored spawn+receive, sum types to tagged tuples, records to BEAM maps, strings to UTF-8 binaries, fun types to BEAM closures. The runtime library `mochi` (Apache-2.0) publishes to Hex.pm as a thin layer over `pg`, `gen_server`, `gun`, the OTP 27 stdlib `json` module, and `telemetry`. The 19-phase delivery plan walks from hello-world through scalars, collections, records, sums, closures, queries, datalog, agents, streams, async, FFI, LLM, fetch, then escripts, releases, AtomVM, Dialyzer, and reproducibility. Each phase is gated against vm3. Twelve research notes covering every lowering case live under ~/notes/Spec/0046/.	Final
0047	Mochi-to-JVM transpiler: Maven Central ecosystem, Loom-native agents, GraalVM native-image AOT Standalone pipeline that lowers a type-checked Mochi program to Java source emitted via `javax.tools.JavaCompiler`, with a `java.lang.classfile` (ClassFile API, JEP 484) direct-bytecode fallback for hot lowerings. Packages the resulting `.class` files as an uberjar, a `jlink` runtime image, a `jpackage` installer, or a GraalVM `native-image` ahead-of-time executable. MEP-47 owns its emit pass and its runtime library `dev.mochi.runtime` but reuses MEP-45's `aotir` IR plus monomorphisation/closure-conversion passes shared with MEP-46. The proposal is additive: `mochi build --target=jvm-uberjar` and friends route Mochi through the JVM pipeline; `mochi run` keeps the vm3 path; MEP-45's C target stays the AOT single-binary story; MEP-46's BEAM target stays the supervision/hot-reload story. The JVM target is the Maven Central, Project Loom virtual threads, java.util.stream, GraalVM AOT, and JDK FFI story. The master correctness gate is byte-equal stdout against vm3 on the full fixture corpus across JDK 21 LTS and JDK 25 LTS on x86_64-linux-gnu, aarch64-linux-gnu, aarch64-darwin, and x86_64-windows. Mochi agents lower to Loom virtual threads with `BlockingQueue` mailboxes, streams to `java.util.concurrent.Flow.Publisher`, sum types to sealed interfaces + records, match to JDK 21 switch patterns (JEP 440 + JEP 441), strings to `java.lang.String`, fun types to lambdas via `LambdaMetafactory`. The runtime library `dev.mochi.runtime` (Apache-2.0) publishes to Maven Central via the new Central Publisher Portal as a thin layer over Jackson 2.18, snakeyaml-engine, java.net.http, and JFR. The 18-phase delivery plan walks from hello-world through scalars, collections, records, sums, closures, queries, datalog, agents, streams, async, JDK FFI, LLM, fetch, then uberjars, jlink, jpackage, GraalVM native-image, and reproducibility. Each phase is gated against vm3. Twelve research notes covering every lowering case live under ~/notes/Spec/0047/.	Final
0048	Mochi-to-.NET transpiler: NuGet ecosystem, async/await colouring, NativeAOT single-file binaries Standalone pipeline that lowers a type-checked Mochi program to C# source emitted via Roslyn `SyntaxFactory`, with a `System.Reflection.Emit` (and .NET 9 `PersistedAssemblyBuilder`) direct-IL fallback for agent trampolines and hot lowerings. Packages the resulting `.dll`/`.exe` as a framework-dependent assembly, a self-contained publish directory, or a NativeAOT single-file binary. MEP-48 owns its emit pass and its runtime library `Mochi.Runtime` but reuses MEP-45's `aotir` IR plus monomorphisation/closure-conversion passes shared with MEP-46 and MEP-47. The proposal is additive: `mochi build --target=dotnet-fx-dependent` and friends route Mochi through the .NET pipeline; `mochi run` keeps the vm3 path; MEP-45's C target stays the AOT single-binary story; MEP-46's BEAM target stays the supervision/hot-reload story; MEP-47's JVM target stays the Maven Central / Loom story. The .NET target is the NuGet, CLR reified generics, value types, LINQ, `System.Threading.Channels`, async/await, and NativeAOT story. The master correctness gate is byte-equal stdout against vm3 on the full fixture corpus across .NET 8 LTS and .NET 10 LTS on x86_64-linux-gnu, aarch64-linux-gnu, aarch64-darwin, and x86_64-windows. Mochi agents lower to `Channel<TMessage>` plus async dispatch loops, streams to `IAsyncEnumerable<T>`, sum types to sealed `abstract record` + `sealed record` hierarchies, match to C# 8+ switch expressions with C# 11 list patterns, strings to UTF-8 spans at boundaries and `System.String` (UTF-16) internally, fun types to `Func<...>`/`Action<...>` delegates. The runtime library `Mochi.Runtime` (Apache-2.0) publishes to NuGet as a thin layer over `System.Text.Json`, `System.Threading.Channels`, `System.Linq.Async`, `System.Collections.Immutable`, `System.Net.Http`, and `System.Diagnostics.DiagnosticSource`. The 18-phase delivery plan walks from hello-world through scalars, collections, records, sums, closures, queries, datalog, agents, streams, async, .NET FFI, LLM, fetch, then framework-dependent, self-contained, NativeAOT publish, reproducibility, and trim-clean. Each phase is gated against vm3. Twelve research notes covering every lowering case live under ~/notes/Spec/0048/.	Active
0049	Mochi-to-Swift transpiler: Apple platforms via SwiftPM, actor + AsyncStream agents, static Linux/Windows binaries Standalone pipeline that lowers a type-checked Mochi program to Swift 6.0 source, drives swiftc through SwiftPM (`swift build`) for libraries and Linux/Windows executables, and through xcodebuild for iOS/macOS/watchOS/tvOS/visionOS app bundles. MEP-49 owns its emit pass and its runtime library `MochiRuntime` (a SwiftPM package) but reuses MEP-45's `aotir` IR plus monomorphisation/closure-conversion passes shared with MEP-46, MEP-47, and MEP-48. The proposal is additive: `mochi build --target=swift-ios`, `--target=swift-macos`, `--target=swift-linux-static`, `--target=swift-windows` and friends route Mochi through the Swift pipeline; `mochi run` keeps the vm3 path; MEP-45's C target stays the AOT single-binary story; MEP-46's BEAM target stays the supervision/hot-reload story; MEP-47's JVM target stays the Maven Central / Loom story; MEP-48's .NET target stays the NuGet / NativeAOT story. The Swift target is the Apple App Store, SwiftUI-adjacent, server-side-Swift, CLR-style reified generics and value types, AsyncSequence, and ARC story. The master correctness gate is byte-equal stdout against vm3 on the full fixture corpus across Swift 6.0 and Swift 6.1 on x86_64-linux-gnu, aarch64-linux-gnu, aarch64-darwin, and x86_64-windows. Mochi agents lower to Swift `actor` types with `AsyncStream<Message>` mailboxes, streams to `AsyncSequence`, sum types to `enum` with associated values and exhaustive `switch`, records to `@frozen public struct`, fun types to typed Swift closures (including `@Sendable` for actor-crossing), strings to Swift `String` (UTF-8-native since Swift 5.7), errors to typed `throws(E)` (SE-0413). The runtime library `MochiRuntime` (Apache-2.0) publishes to the Swift Package Index and Apple's draft Swift Package Registry as a thin re-export of apple/swift-collections, apple/swift-algorithms, apple/swift-async-algorithms, apple/swift-numerics, apple/swift-system, apple/swift-log, plus Mochi-specific helpers (agent supervisor, datalog evaluator, query DSL extensions, JSON helpers, ZonedDateTime). The 18-phase delivery plan walks from hello-world through scalars, collections, records, sums, closures, queries, datalog, agents, streams, async, Swift FFI, LLM (FoundationModels on Apple), fetch (URLSession), then iOS app bundle, reproducibility, static Linux SDK single binary, and App Store validation. Each phase is gated against vm3. Twelve research notes covering every lowering case live under ~/notes/Spec/0049/.	Draft
0050	Mochi-to-Kotlin transpiler: Kotlin Multiplatform via Gradle, coroutine + Channel agents, Android .aab, K/Native single binaries Standalone pipeline that lowers a type-checked Mochi program to Kotlin 2.1 source, drives kotlinc through Gradle (`./gradlew build`) for Kotlin Multiplatform (KMP) projects spanning JVM, Android, Kotlin/Native (iOS, macOS, Linux, Windows), Kotlin/JS, and Kotlin/Wasm, and through the Android Gradle Plugin for Android `.aab` and `.apk` bundles. MEP-50 owns its emit pass and its runtime library `MochiRuntime` (a KMP Gradle module) but reuses MEP-45's `aotir` IR plus monomorphisation, match-to-decision-tree, closure-conversion, and exhaustiveness passes shared with MEP-46, MEP-47, MEP-48, and MEP-49. The proposal is additive: `mochi build --target=kotlin-jvm`, `--target=kotlin-android`, `--target=kotlin-ios-arm64`, `--target=kotlin-macos-arm64`, `--target=kotlin-linux-x64`, `--target=kotlin-linux-arm64`, `--target=kotlin-windows-x64`, `--target=kotlin-js-browser`, `--target=kotlin-js-node`, `--target=kotlin-wasm-js`, and `--target=kotlin-kmp-library` route Mochi through the Kotlin pipeline; `mochi run` keeps the vm3 path; MEP-45's C target stays the AOT single-binary story; MEP-46's BEAM target stays the supervision/hot-reload story; MEP-47's JVM target stays the direct-bytecode Maven Central / Loom story (distinct from MEP-50's source-level JVM output); MEP-48's .NET target stays the NuGet / NativeAOT story; MEP-49's Swift target stays the App Store / Apple platform story. The Kotlin target is the Android-first, Google Play Console, Kotlin Multiplatform iOS/desktop, Jetpack Compose, server-side Ktor, K2 compiler, sealed-interface ADT, kotlinx.coroutines structured-concurrency story. The master correctness gate is byte-equal stdout against vm3 on the full fixture corpus across Kotlin 2.1.0 and Kotlin 2.1.20 on x86_64-linux-gnu, aarch64-linux-gnu, aarch64-darwin, and x86_64-windows. Mochi agents lower to a custom actor class wrapping a `Channel<Message>` plus a `CoroutineScope(SupervisorJob() + Dispatchers.Default)` receive loop (the deprecated `actor { }` builder is not used), streams to `kotlinx.coroutines.flow.Flow<T>`, sum types to `sealed interface` with `data class` and `data object` variants, records to `data class`, fun types to Kotlin function or `suspend` function types, strings to Kotlin `String`, errors to a custom sealed `MochiResult<T, E>` return value (no checked exceptions). The runtime library `MochiRuntime` (Apache-2.0, ~6000 LOC) publishes to Maven Central as a KMP artifact and re-exports `kotlinx.coroutines`, `kotlinx.serialization`, `kotlinx.collections.immutable`, `kotlinx.datetime`, plus Mochi-specific helpers (agent supervisor, Datalog evaluator, query DSL extensions, JSONValue, ZonedDateTime). The 18-phase delivery plan walks from hello-world through scalars, collections, records, sums, closures, queries, datalog, agents, streams, async, FFI, LLM, fetch, Android App Bundle, reproducibility, K/Native single binaries, and Play Console validation. Each phase is gated against vm3. Twelve research notes covering every lowering case live under ~/notes/Spec/0050/.	Draft
0051	Mochi-to-Python transpiler: typed CPython 3.12 source, asyncio.Queue + TaskGroup agents, uv + hatchling wheels, ipykernel for Jupyter, PyPI Trusted Publishing Standalone pipeline that lowers a type-checked Mochi program to typed CPython 3.12+ source, drives the produced `pyproject.toml` project through uv 0.4+ and the PEP 517 `hatchling` build backend, and ships wheels (`.whl`), source distributions (`.tar.gz`), and a Jupyter `ipykernel` kernelspec ready for cell-by-cell execution inside JupyterLab. MEP-51 owns its emit pass and its runtime library `mochi_runtime` (a pure-Python PyPI package with optional native extensions) but reuses MEP-45's `aotir` IR plus monomorphisation, match-to-decision-tree, closure-conversion, and exhaustiveness passes shared with MEP-46, MEP-47, MEP-48, MEP-49, and MEP-50. The proposal is additive: `mochi build --target=python-wheel`, `--target=python-sdist`, `--target=python-ipykernel`, `--target=python-app`, and `--target=python-source` route Mochi through the Python pipeline; `mochi run` keeps the vm3 path; MEP-45 stays the AOT single-binary story; MEP-46 stays the BEAM supervision story; MEP-47 stays the direct-bytecode JVM and Loom story; MEP-48 stays the .NET NuGet and NativeAOT story; MEP-49 stays the Apple App Store story; MEP-50 stays the Android and Kotlin Multiplatform story. The Python target is the PyPI, NumPy / pandas / scikit-learn / PyTorch / JAX, FastAPI, Jupyter notebook, data-science, scripting, and machine-learning ecosystem story. The master correctness gate is byte-equal stdout against vm3 on the full fixture corpus across CPython 3.12.0 and CPython 3.13.0 on x86_64-linux-gnu, aarch64-linux-gnu, aarch64-darwin, and x86_64-windows; secondary compile-gates are `mypy --strict --python-version=3.12` and `pyright --strict` with no diagnostics and no `Any` leakage. Mochi agents lower to a custom Python class wrapping `asyncio.Queue[Message]` plus a `TaskGroup` (PEP 654) supervision scope; the legacy `asyncio.gather` is not used as the supervision primitive. Streams lower to `collections.abc.AsyncIterator`. Sum types lower to PEP 695 `type` aliases over frozen-slots `@dataclass(frozen=True, slots=True)` variants with exhaustive `match` (PEP 634). Records lower to frozen-slots dataclasses. Function types lower to `collections.abc.Callable` (sync) or `collections.abc.Awaitable` (async). Strings lower to `str` with code-point semantics matching Mochi. Errors lower to a custom `MochiResult` tagged union (Ok/Err) rather than Python exceptions, except where Mochi `panic` lowers to `raise RuntimeError`. The runtime library `mochi_runtime` (Apache-2.0, ~7000 LOC of Python plus optional ~500 LOC of C extension) publishes to PyPI as `mochi-runtime`, depends on `httpx` for HTTP, `anyio` only via the asyncio adapter (no Trio runtime path), and exposes a small Datalog engine, JSONValue ADT, agent supervisor, ZonedDateTime helpers over `zoneinfo`, and query DSL extensions. The 18-phase delivery plan walks from hello-world through scalars, collections, records, sums, closures, queries, datalog, agents, streams, async coloring, FFI (ctypes + CFFI), LLM, fetch, wheel/sdist build, reproducibility, ipykernel, and PyPI Trusted Publishing. Each phase is gated against vm3, mypy, pyright, and ruff. Twelve research notes covering every lowering case live under ~/notes/Spec/0051/.	Draft
0052	Mochi-to-TypeScript/JavaScript transpiler: TS 5.6 strict source + ES2024 JS dist, AsyncIterableQueue + AbortController agents, npm + tsc canonical, JSR + Deno + Bun + browser secondary, npm Trusted Publishing Standalone pipeline that lowers a type-checked Mochi program to typed TypeScript 5.6 source under strict mode (`--strict --noUncheckedIndexedAccess --exactOptionalPropertyTypes --noImplicitOverride --noFallthroughCasesInSwitch --noPropertyAccessFromIndexSignature`), drives the produced `package.json` project through npm 10+ as the canonical driver, runs `tsc --build` to emit ES2024 ECMAScript modules under `dist/{node,deno,bun,browser}/` with per-runtime conditional exports, and ships either standalone `.ts` source (`mochi build --target=typescript-source`), pre-compiled npm packages (`--target=npm-package`), Deno JSR distributions (`--target=deno-jsr`), single-file browser bundles via esbuild (`--target=browser-bundle`), or Deno Jupyter kernelspecs (`--target=deno-jupyter`). MEP-52 owns its emit pass and its runtime library `@mochi/runtime` (a TypeScript ESM package shipping under MIT plus Apache-2.0 dual license to npm and JSR) but reuses MEP-45's `aotir` IR plus monomorphisation, match-to-decision-tree, closure-conversion, exhaustiveness, and sendability passes shared with MEP-46 through MEP-51. The proposal is additive: `mochi build --target=typescript-source`, `--target=npm-package`, `--target=deno-jsr`, `--target=browser-bundle`, and `--target=deno-jupyter` route Mochi through the TypeScript pipeline; `mochi run` keeps the vm3 path; MEP-45 stays the AOT single-binary story; MEP-46 stays the BEAM supervision story; MEP-47 stays the direct-bytecode JVM and Loom story; MEP-48 stays the .NET NuGet and NativeAOT story; MEP-49 stays the Apple App Store story; MEP-50 stays the Android and Kotlin Multiplatform story; MEP-51 stays the PyPI, NumPy, and Jupyter ipykernel story. The TypeScript/JavaScript target is the npm ecosystem (over 3 million packages on npmjs.org as of 2026 Q1), the React/Vue/Svelte/SolidJS UI tier, the Node.js server tier (Express/Fastify/Hono/Elysia), the Deno Deploy and Cloudflare Workers edge tier, the Bun-native server tier, the only Mochi target that reaches the browser without a server install, the Electron and Tauri desktop tier, and the Jupyter notebook tier via Deno's official kernel. The master correctness gate is byte-equal stdout against vm3 on the full fixture corpus across Node 22 LTS, Deno 2.x, Bun 1.1.x, and headless browser (Playwright + Chromium 130+) on x86_64-linux-gnu, aarch64-linux-gnu, aarch64-darwin, and x86_64-windows; secondary compile-gates are `tsc --noEmit --strict --noUncheckedIndexedAccess --exactOptionalPropertyTypes` (zero diagnostics) and `eslint --max-warnings 0` with `@typescript-eslint/recommended-type-checked`. Mochi agents lower to a hand-rolled `AsyncIterableQueue<T>` mailbox plus an `AbortController` supervision scope; `Promise.withResolvers()` (ES2024) carries the `call(req)` reply future. Streams lower to `AsyncIterable<T>` / `AsyncGenerator<T, void, undefined>`. Sum types lower to discriminated unions over a literal `kind` tag with exhaustive `switch (x.kind)` enforced by `tsc --strict`. Records lower to `class` with `readonly` fields plus a private constructor and a static `of()` factory. Function types lower to `(args) => R` (sync) or `(args) => Promise<R>` (async). Strings lower to `string` (UTF-16 internal); the runtime ships `mochiStrLen(s)` and `mochiStrIndex(s, i)` for code-point semantics. Errors lower to a `MochiResult<T, E>` discriminated union (`{kind: 'ok', value: T} | {kind: 'err', error: E}`) rather than thrown exceptions; `panic` lowers to `throw new MochiPanic(msg)`. The runtime library `@mochi/runtime` (~6500 LOC of TypeScript across approximately 35 modules, zero npm dependencies in the default build, optional Node N-API / Bun FFI / Deno FFI bindings under sub-paths) publishes to npm with `--provenance` (Sigstore + GitHub OIDC, GA April 2024) and to JSR (`jsr.io`) for Deno-native consumption. The 18-phase delivery plan walks from hello-world through scalars, collections, records, sums, closures, queries, datalog, agents, streams, async coloring, FFI, LLM, fetch, then npm packaging, reproducibility, Deno JSR plus Jupyter plus browser, and npm Trusted Publishing. Each phase is gated against vm3, tsc strict, eslint, prettier, and execution on all four runtimes. Twelve research notes covering every lowering case live under ~/notes/Spec/0052/.	Draft
0053	Mochi-to-Rust transpiler: cargo-friendly source emission, structural rtree AST, single-thread channels and streams, FFI via sidecar C, reproducible cargo builds, wasm32-wasip1, and no_std embedded variant Standalone pipeline that lowers a type-checked Mochi program to Rust source emitted via a structural rtree AST, then drives cargo to ship a single-file native binary on the host triple, x86_64-unknown-linux-musl, aarch64-unknown-linux-musl, and wasm32-wasip1, plus a no_std + alloc embedded variant. MEP-53 owns its emit pass and its runtime crate `mochi-runtime` but reuses MEP-45's `aotir` IR plus monomorphisation and closure-conversion passes shared with MEP-46, MEP-47, MEP-48, MEP-49, MEP-50, MEP-51, MEP-52, and MEP-56. The proposal is additive: `mochi build --target=rust` and `--target=rust-source / --target=rust-crate / --target=wasm32-wasip1` route Mochi through the Rust pipeline; vm3 and the C / BEAM / JVM / .NET / Swift / Kotlin / Python / TypeScript / Ruby targets are unaffected. The master correctness gate is byte-equal stdout against vm3 on the full fixture corpus across stable Rust 1.95 host (aarch64-apple-darwin), cargo-zigbuild Linux musl x64 and arm64, wasm32-wasip1 under wasmtime, and `cargo check --no-default-features --features embedded` for the no_std + alloc subset. Mochi channels lower to a single-thread `Rc<RefCell<VecDeque>>` queue (no `std::sync`), streams to a single-thread broadcast over `Rc<RefCell<Vec<Rc<RefCell<VecDeque>>>>>`, sum types to tagged `enum` variants with `#[derive(Clone, Debug, PartialEq)]`, records to `#[derive(...)]` structs, closures to `Box<dyn Fn(...)>` with explicit capture clauses, agents to plain structs plus impl blocks, panic / try / catch to `std::panic::catch_unwind` with an `i64` payload, FFI to a sidecar `cffi/` C library wired through `cc-rs` build script, `httpGet` to a hand-rolled HTTP/1.1 GET over `std::net::TcpStream`, `json_decode` to a 90-LOC string-coercing object decoder, LLM `generate <provider> { ... }` to cassette replay keyed by SHA-256 of `provider:prompt`, and reproducible builds to SOURCE_DATE_EPOCH=0 plus RUSTFLAGS=-C strip=symbols (with a known-skip on macOS for LC_UUID non-determinism). The runtime crate `mochi-runtime` (Apache-2.0) ships `io`, `conv`, `strings`, `chan`, `stream`, `panic`, `fetch`, `json`, `llm`, and `check`, gated so that the `embedded` feature drops everything except `conv` and `strings`. The 19-phase delivery plan walks from skeleton through hello-world, scalars, collections, records, sums, closures, queries, datalog, agents, streams, try/catch, FFI, LLM, fetch, publish-ready crate metadata, reproducibility, wasm, and embedded. Each phase is gated against vm3.	Active
0054	Mochi-to-Go transpiler: gofmt-rendered source via structural gotree AST, native goroutines and channels, deterministic go build, cross-compile matrix, pkg.go.dev publish Standalone pipeline that lowers a type-checked Mochi program to Go source emitted via a structural gotree AST, then drives the Go toolchain to ship a single-file native binary on Go's first-class cross-compile matrix (linux/darwin/windows/freebsd on amd64/arm64), a publishable Go module, a wasm/JS bundle, or a wasip1 module. MEP-54 owns its emit pass and its runtime module `dev.mochilang/runtime/go` (Apache-2.0) but reuses MEP-45's `aotir` IR plus monomorphisation, match-to-decision-tree, closure-conversion, and sendability passes shared with MEP-46 through MEP-53, MEP-55, and MEP-56. The proposal is additive: `mochi build --target=go-linux-amd64`, `--target=go-darwin-arm64`, `--target=go-module`, `--target=go-wasm-js`, and `--target=go-wasip1` route Mochi through the Go pipeline; vm3 and the C / BEAM / JVM / .NET / Swift / Kotlin / Python / TypeScript / Rust / PHP / Ruby targets are unaffected. The master correctness gate is byte-equal stdout against vm3 on the full fixture corpus across Go 1.26.0 and Go 1.26.x latest on ubuntu-24.04, macos-15, and windows-2025. Mochi channels lower to native `chan T` with `make(chan T, cap)`; `send` and `recv` lower to `ch <- v` and `<-ch`; agents lower to a goroutine wrapping a `chan Message` receive loop; streams lower to a struct holding `[]chan T` subscriber slots with explicit backpressure via channel capacity; sum types lower to a discriminated interface with one final struct per variant satisfying the marker method; records lower to a Go struct with field-by-field comparison; closures lower to Go `func(...)` literals with explicit captures via the `ClosureEnvStmt` lifted-environment pattern; function types lower to `func(T1, T2) R`; strings lower to Go `string` (UTF-8 byte sequence); errors lower to `try { ... } catch e { ... }` via `defer` + `recover` with an `int64` payload; `panic` lowers to a runtime helper that wraps `runtime.Panic` so cross-panic-with-recover semantics stay consistent with vm3. The runtime module `dev.mochilang/runtime/go` (~1200 LOC of Go across ~10 packages, zero third-party deps in the default build) publishes to pkg.go.dev under the standard `go install` workflow. The 19-phase delivery plan walks from skeleton through hello-world, scalars, collections, records, sums, closures, queries (filter/map/order_by/skip-take/string-ops/joins/aggregations), builtins (string/math/file-io/csv/error/omap/hof), datalog, agents, streams, async, FFI, LLM, fetch, then go-module packaging, reproducibility (`-trimpath` + `-buildvcs=false`), wasm/wasip1, and signed publish. Each phase is gated against vm3.	Active
0055	Mochi-to-PHP 8.4 transpiler: Composer + Packagist canonical, Phar + FrankenPHP + RoadRunner packaging, GPG-signed releases with Sigstore attestation Standalone pipeline that lowers a type-checked Mochi program to PHP 8.4 source under `declare(strict_types=1);`, drives the produced Composer package through `composer install` plus PHPStan level 9 strict + Psalm 6 level 1 + php-cs-fixer (PER-CS2.0 + PHP84Migration), and ships either standalone `main.php` source (`mochi build --target=php-source`), a runnable Phar archive (`--target=php-phar`), a FrankenPHP app-server bundle (`--target=php-frankenphp`), or a RoadRunner worker-mode bundle (`--target=php-roadrunner`). MEP-55 owns its emit pass and its runtime library `mochi/runtime` (a Composer package shipping under MIT to Packagist) but reuses MEP-45's `aotir` IR plus monomorphisation, match-to-decision-tree, closure-conversion, exhaustiveness, and sendability passes shared with MEP-46 through MEP-54. The proposal is additive: `mochi build --target=php-source`, `--target=php-phar`, `--target=php-frankenphp`, and `--target=php-roadrunner` route Mochi through the PHP pipeline; `mochi run` keeps the vm3 path; MEP-45 stays the AOT single-binary story; MEP-46 stays the BEAM supervision story; MEP-47 stays the direct-bytecode JVM and Loom story; MEP-48 stays the .NET NuGet and NativeAOT story; MEP-49 stays the Apple App Store story; MEP-50 stays the Android and Kotlin Multiplatform story; MEP-51 stays the PyPI, NumPy, and Jupyter ipykernel story; MEP-52 stays the npm, JSR, and TypeScript-ESM story; MEP-53 stays the Rust crates.io, no_std, and embedded story; MEP-54 stays the Erlang/OTP supervision tree story. The PHP/Packagist target is the WordPress ecosystem, the Laravel, Symfony, and Drupal application tier, the Composer registry (over 400000 packages on Packagist), and the still-largest server-side web language by CMS deployment. The master correctness gate is byte-equal stdout against vm3 on the full fixture corpus across PHP 8.4.0 and PHP 8.4 latest on `ubuntu-24.04`, with `8.5` running allow-failure as a forward-compat smoke. Secondary compile-gates are `phpstan analyse --level=9 --error-format=raw` (zero errors), `psalm --no-cache --threads=1 --show-info=true` (zero issues), and `php-cs-fixer fix --dry-run --diff` (zero rewrites). Mochi agents lower to a final class wrapping a userland Channel<Message> (FIFO array + counter) plus a synchronous receive loop, since PHP has no preemptive scheduler; streams lower to a final class implementing `IteratorAggregate` and exposing `subscribe(int $limit)` with explicit backpressure (`drop` when full); sum types lower to an `abstract readonly class` (PHP 8.4 readonly inheritance) with `final readonly class` variants; records lower to `final readonly class` with constructor promotion; closures lower to PHP 8.1 first-class callable syntax (`$obj->method(...)`); function types lower to `Closure(string, int): bool` PHPDoc with Psalm/PHPStan inference; strings lower to PHP `string` (byte sequence); errors lower to a Result-style discriminated `final readonly class Ok` / `final readonly class Err` rather than throwing exceptions; `panic` lowers to `throw new \RuntimeException`. The runtime library `mochi/runtime` (~3500 LOC of PHP across ~25 files, zero Composer runtime deps in the default build, `psalm` and `phpstan` as dev-only deps, optional `amphp/revolt` deferred to a future MEP for true non-blocking I/O) publishes to Packagist with GPG-signed tags plus a Sigstore-backed `actions/attest-build-provenance@v1` OIDC attestation plus optional `drupal/php-signify` Ed25519 detached signatures. The 18-phase delivery plan walks from hello-world through scalars, collections, records, sums, closures, queries, datalog, agents, streams, async coloring (sync wrappers), FFI (FFI extension + sodium), LLM (cassette dispatch), fetch (curl), then Composer + PHPStan + Psalm green, reproducibility, Phar + FrankenPHP + RoadRunner packaging, and signed Packagist publication. Each phase is gated against vm3, PHPStan, Psalm, and execution on `8.4.0` and `8.4` latest. MEP-55 shipped as a single umbrella PR (#22481) on 2026-05-29 with all 18 phases pre-merged onto `impl/mep-0055-php`.	Final
0056	Mochi-to-Ruby transpiler: gem-friendly source emission, Data.define records, Channel agents, Thread::SizedQueue streams, Tebako and TruffleRuby native packaging Standalone pipeline that lowers a type-checked Mochi program to Ruby source emitted via a structural rtree AST, runnable on CRuby 3.2+, JRuby 10, TruffleRuby 33, and mruby 4. Packages the resulting .rb as a single script, a RubyGems gem, a Bundler bundle, a Jupyter IRuby notebook, a Tebako single-file binary, a TruffleRuby native-image, or an mruby embedded build. MEP-56 owns its emit pass and its runtime library `mochi-runtime` but reuses MEP-45's `aotir` IR plus monomorphisation and closure-conversion passes shared with MEP-46, MEP-47, and MEP-48. The proposal is additive: `mochi build --target=ruby-source` and friends route Mochi through the Ruby pipeline; vm3 and the C/BEAM/JVM/.NET targets are unaffected. The master correctness gate is byte-equal stdout against vm3 on the full fixture corpus across CRuby 3.2 LTS, CRuby 3.4, CRuby 4.0, JRuby 10, and TruffleRuby 33. Mochi agents lower to Ruby classes (with `spawn AgentType()` constructing zero-valued instances and intent calls routing through ordinary method dispatch), streams to a bounded MPMC broadcast channel built on `Thread::SizedQueue`, sum types to `Data.define` value classes plus case/in pattern matching, match to `case/in`, strings to UTF-8 (Ruby 3.2+ default encoding), and fun types to lambdas. The runtime library `mochi-runtime` (Apache-2.0) ships `Mochi::Runtime::Stream`, `Mochi::Runtime::Panic`, and `Mochi::Runtime::IO.putln` (deterministic float formatting). The 33-phase delivery plan (phases 0-32) walks from hello-world through scalars, collections, records, sums, closures, queries, datalog, channels, agents, streams, async, deep string ops, file/JSON/CSV/HTTP, try/catch, spawn, then RubyGem, Bundler, IRuby kernel, Tebako, TruffleRuby native, mruby packaging, and five audit passes. Each phase is gated against vm3.	Active
0057	Mochi module and package system: mochi.toml manifest + mochi.lock text lockfile + PubGrub-derived solver + sparse HTTPS registry index + BLAKE3 + SHA-256 dual-hashed content-addressed object store + Sigstore + OIDC keyless trusted publishing + capability declarations at the package boundary + polyglot fan-out to npm + JSR + PyPI + Maven Central + NuGet + crates.io + Hex + Swift Package Index First source-level package management system for Mochi. Specifies a TOML manifest (`mochi.toml`, Cargo / uv / Pixi shaped, plus three Mochi-only sections: `[capabilities]`, `[targets]`, `[provenance]`); a text lockfile (`mochi.lock`, TOML-shaped, version envelope, sorted keys, byte-stable serialisation, per-platform resolution sections); a PubGrub-derived version solver with incompatibility-driven conflict explanations (the algorithm used by uv since 2024, by Cargo's RFC #3796 next-gen resolver, by Rye, and by Dart's pub since 2018); a sparse HTTPS registry index at `index.mochi.dev` (Cargo-style, GA March 2023, 5-20x faster than git-cloned indexes at scale); a content-addressed object store keyed on BLAKE3-256 (primary, parallel, 3-7x faster than SHA-256) plus SHA-256 (secondary, for SLSA / Sigstore / npm interop) under `blobs.mochi.dev`; Sigstore-keyless trusted publishing via GitHub Actions / GitLab CI OIDC token exchange with Fulcio (matching npm Trusted Publishing GA April 2024, Maven Central Sigstore GA October 2024, PyPI PEP 740 GA late 2025, Cargo RFC #3724); capability declarations at the package boundary (closed set: `fs.read`, `fs.write`, `net.dial`, `net.listen`, `env`, `ffi`, `clock`, `random`, `proc.spawn`) audited at lock time and enforced at the transpiler boundary (Deno permissions, Wasm component model imports, Python `mochi_runtime.caps` runtime checks); polyglot fan-out from one `mochi.toml` to eight ecosystem artifacts (Mochi central, npm + JSR via MEP-52, PyPI via MEP-51, Maven Central via MEP-47, NuGet via MEP-48, crates.io via MEP-53, Hex via MEP-46, Swift Package Index via MEP-49); a SBOM and provenance pipeline emitting CycloneDX 1.6 and SPDX 3.0 plus per-target in-toto attestations; a `mochi audit` advisory-database query path against an RustSec-style YAML feed; reproducible package builds under `SOURCE_DATE_EPOCH` plus a sorted-tar normaliser producing byte-identical `.mochi.tar.zst`; a `mochi vendor` offline path; a registry mirror replication protocol; and a 20-phase delivery plan from package-stub skeleton through manifest, workspaces, lockfile, solver, local + network indexes, content store, capabilities, mirror, publish, trusted publishing, polyglot, SBOM, advisory DB, reproducibility, vendor, and workspace cache. Each phase is gated against the PubGrub fixture corpus, the lockfile byte-identical reproducibility check, four-platform CI (linux-x86_64 + linux-arm64 + macos-arm64 + windows-x86_64), Sigstore round-trip via a sigstore-mock-fulcio harness, CycloneDX schema validation, and an `mochi why` explanation-quality test. The reference implementation lives under `pkg/{pkgmanifest,pkglock,pkgsolver/pubgrub,pkgindex,pkgblob,pkgsign,pkgcap,pkgfanout}` plus `cmd/mochi/pkg.go`. Twelve research notes under `~/notes/Spec/0057/` cover prior art across Cargo, Go modules + workspaces, Deno + JSR, Bun, npm + Trusted Publishing, Python uv + PEP 751, Bazel bzlmod, Nix flakes, Swift PM, Hex, NuGet central package management, Pixi, Spack, Pkl, and the recent (2024-2026) literature on PubGrub, supply-chain provenance (Sigstore, SLSA, in-toto), reproducible builds, content-addressed code (Unison), capability-safe imports (Deno permissions, Wasm Component Model, Pony, Roc platforms), and empirical package-ecosystem studies.	Draft
0066	Mochi and Erlang/OTP package bridge: bidirectional package interop with the Hex.pm ecosystem via BEAM abstract-code typespec ingest, OTP Port protocol bridge (no NIF required), EDoc XML fallback, no-boilerplate import erlang syntax, TargetErlangPort publish via Hex.pm trusted publishing, and a content-addressed Erlang dependency cache under package3/erlang/ Bidirectional package interop between Mochi and the Hex.pm ecosystem. Direction 1 (Mochi as Erlang consumer): an `import erlang "<package>@<semver>" as <alias>` surface form auto-resolves through mochi.lock, fetches the Erlang application from Hex.pm into a content-addressed blob store under `~/.cache/mochi/erlang-deps/`, ingests typespecs from BEAM abstract-code chunks (the Dbgi/Abst chunk of each .beam file, decoded via Erlang External Term Format), falls back to EDoc XML for packages without inline -spec directives, translates Dialyzer typespecs through a closed typespec-to-Mochi table, emits a synthesised shim.erl (an Erlang module implementing the bridge surface over the OTP Port protocol) plus a matching shim.mochi extern fn corpus. Direction 2 (Mochi as Erlang producer): a TargetErlangPort build target lowers a Mochi package to a rebar3 application that wraps the compiled Mochi binary as an Erlang Port driver, populates rebar3/hex metadata from mochi.toml, and ships via `mochi pkg publish --to=hex.pm` using Hex.pm trusted publishing. The bridge is implemented in `package3/erlang/` and extends MEP-57's mochi.toml plus mochi.lock infrastructure. A 14-phase delivery plan covers skeleton, Hex.pm index client, BEAM abstract-code ingest, EDoc fallback, typespec-to-Mochi mapping, Port bridge emitter, import erlang grammar, rebar3 build orchestration, mochi.lock integration, TargetErlangPort emit, Hex.pm trusted publishing, OTP behavior bindings (gen_server/supervisor), async process bridge, and distributed Erlang node bridge.	Draft
0067	Mochi and Java package bridge: bidirectional Maven Central interop with JNI reflection ingest, auto-generated JNI wrapper, no-boilerplate import java syntax, Maven Central publish via Sonatype Central Portal, mochi.lock [[java-package]] pinning, and a content-addressed JAR cache under package3/java/ Bidirectional package interop between Mochi and the Maven Central ecosystem. Direction 1 (Mochi as Maven consumer): an `import java "<groupId>:<artifactId>@<version>" as <alias>` surface form auto-resolves through mochi.lock, fetches the JAR from Maven Central into a content-addressed blob store under `~/.cache/mochi/java-deps/`, runs a JVM reflection tool to extract the public API surface as JSON, walks that surface through a closed Java-to-Mochi type translation table (int/long/float/double/boolean/String/byte[]/List<T>/Map<K,V>/Optional<T>/CompletableFuture<T>/struct/enum plus a refusal set for raw Object, wildcards, inner classes, varargs, reflective types, and unchecked generics), synthesises JNI wrapper Java source via javac, and emits matching extern java type and extern java fn Mochi declarations. Direction 2 (Mochi as Maven producer): a TargetJavaLibrary build target packages the wrapper JAR and POM for upload to Maven Central via the Sonatype Central Portal API, with optional GPG signing and Sigstore attestation. The bridge is implemented in package3/java/ and extends MEP-57's mochi.toml plus mochi.lock infrastructure. A 16-phase delivery plan covers skeleton, Maven Central HTTP client with SHA-1 verification, content-addressed JAR cache, JVM reflection tool, type mapping table, Mochi extern shim emitter, import java grammar wiring, JNI embedding driver, build orchestration pipeline and javac driver, mochi.lock integration, TargetJavaLibrary emit, Maven Central publish flow, Sigstore attestation, async CompletableFuture bridge, generics and type-erasure handling, and spec update.	Draft
0068	Mochi and .NET package bridge: bidirectional NuGet interop with CLR assembly metadata ingest, auto-generated C# shim with UnmanagedCallersOnly exports, no-boilerplate import dotnet syntax, nuget.org publish via GitHub Actions OIDC trusted publishing, and a content-addressed .NET dependency cache under package3/dotnet/ Bidirectional package interop between Mochi and the .NET NuGet ecosystem. Direction 1 (Mochi as NuGet consumer): an `import dotnet "<package>@<semver>" as <alias>` surface form auto-resolves through the mochi.lock pin, fetches the .nupkg via the NuGet v3 API into the content-addressed blob store under `~/.cache/mochi/dotnet-deps/`, runs `mochi-dotnet-meta` (a small .NET CLI tool invoking System.Reflection.Metadata.MetadataReader) to extract a stable machine-readable assembly surface as JSON, walks that surface through a closed CLR-to-Mochi type translation table (int64/float/string/bool/List<T>/Dictionary<K,V>/T?/Task<T>/struct/record/interface/enum plus a refusal set for pointer types, unsafe types, generic type parameters beyond the monomorphised concretisations declared in mochi.toml, COM interop types, and types requiring runtime conditional compilation), and emits a synthesized C# shim assembly with [UnmanagedCallersOnly] exports wrapping the package API, plus matching extern type and extern fn Mochi declarations the parser accepts as if hand-written. Mochi calls into the shim via the CLR hosting API (hostfxr_initialize_for_runtime_config, hostfxr_get_runtime_delegate, load_assembly_and_get_function_pointer), which embeds the .NET runtime in-process; an opt-in NativeAOT path compiles the shim to a native .dylib/.so/.dll with a C-compatible header for packages that support AOT trimming. Direction 2 (Mochi as NuGet producer): a new MEP-53 build target TargetDotNetLibrary lowers a Mochi package to a publishable .NET assembly via C# emit (MEP-45/53 analogue), packages it as a .nupkg with a .nuspec manifest, and ships via `mochi pkg publish --to=nuget.org` using GitHub Actions OIDC trusted publishing (GA March 2024), with no long-lived NuGet API keys. The bridge is implemented in package3/dotnet/ and consumes MEP-57's mochi.toml plus mochi.lock infrastructure. The reference build adds a [[dotnet-package]] table to mochi.lock recording the resolved package version, SHA-512 of the .nupkg, SHA-256 of the mochi-dotnet-meta JSON output and the generated shim assembly, the user-declared capability surface (net, fs), and the target-framework moniker; a `mochi pkg lock --check` fails if metadata or shim drift would silently regenerate different bindings. The 14-phase delivery plan walks from package3/dotnet/ skeleton through NuGet v3 index client, assembly metadata ingest, type-mapping table, C# shim generator, Mochi extern emitter, import dotnet grammar extension, CLR hosting integration, mochi.lock integration, NuGet package emit, NuGet trusted publishing, async bridge, generics monomorphisation, and NativeAOT opt-in path. Each phase is gated against a per-package ingest fixture corpus drawn from a curated 20-package set (Newtonsoft.Json, Serilog, Microsoft.Extensions.DependencyInjection, System.Text.Json, Dapper, NUnit, xUnit, FluentAssertions, AutoMapper, MediatR, FluentValidation, Polly, Bogus, Moq, RestSharp, StackExchange.Redis, Npgsql, EntityFramework Core, Microsoft.Extensions.Http, AWSSDK.Core) covering the top-downloaded NuGet packages (April 2026 snapshot). The bridge does NOT attempt to translate arbitrary MSIL bytecode, does NOT support COM interop without an explicit opt-in, does NOT support unsafe pointer types without [dotnet.capabilities] unsafe = true, and does NOT cover packages whose public API relies on Windows-only P/Invoke surfaces without an explicit target-platform declaration.	Draft
0070	Mochi and Kotlin package bridge: bidirectional JVM interop with Kotlin Metadata ingest, auto-generated JNI/GraalVM native wrapper, no-boilerplate import kotlin syntax, Maven Central publish via Sonatype Central Portal trusted publishing, and a content-addressed Kotlin dependency cache under package3/kotlin/ Bidirectional package interop between Mochi and the Kotlin/JVM ecosystem. Direction 1 (Mochi as Kotlin library consumer): an `import kotlin "<group>:<artifact>@<semver>" as <alias>` surface form auto-resolves through the mochi.lock pin, fetches the JAR/AAR from Maven Central (or JitPack, Google Maven) into the content-addressed blob store under `~/.cache/mochi/kotlin-deps/`, runs kotlinx-metadata-jvm to extract the public Kotlin API surface from the JAR's kotlin.Metadata annotations, walks that surface through a closed Kotlin-to-Mochi type translation table (Int/Long/Double/Boolean/String/List/Map/Set/Pair/Triple/data-class/enum-class/sealed-class/nullable-T plus a refusal set for raw generics beyond declared instantiations, suspend functions without the coroutines bridge, platform types, and dynamic types), and emits either a GraalVM Native Image ahead-of-time compiled shared library (`kotlin_wrap/<artifact>/libwrap.so`) or a JNI-based runtime bridge depending on the target, plus matching `extern type` and `extern fn` Mochi declarations the parser accepts as if hand-written. Direction 2 (Mochi as Kotlin library producer): a new MEP-53 build target `TargetKotlinLibrary` lowers a Mochi package to a publishable JVM library JAR with proper kotlin.Metadata annotations, KDoc, POM metadata, sources JAR, and Javadoc JAR, and ships via `mochi pkg publish --to=maven-central` using Sonatype Central Portal's trusted-publishing flow with GPG signing. The bridge is implemented in `package3/kotlin/` and extends MEP-57's `mochi.toml` and `mochi.lock` infrastructure with `[kotlin-dependencies]`, `[[kotlin-package]]`, and `[kotlin.publish]` tables. The 14-phase delivery plan walks from skeleton through Maven sparse metadata client, blob cache, kotlinx-metadata-jvm ingest, type-mapping table, JNI/GraalVM wrapper synthesizer, Mochi extern emitter, `import kotlin` grammar extension, MEP-53 build orchestration, mochi.lock integration, TargetKotlinLibrary emit, Maven Central publish via trusted publishing, coroutines bridge via a kotlinx.coroutines adapter, generic instantiation via explicit monomorphise table, and a Kotlin Multiplatform subset path. Each phase is gated against a per-artifact ingest fixture corpus drawn from a curated 20-artifact set covering the top Kotlin/JVM ecosystem libraries.	Draft
0071	Mochi and Python package bridge: bidirectional PyPI interop with PEP 561 stub ingest, auto-generated cffi/cpython wrapper, no-boilerplate import python syntax, PyPI publish via Trusted Publishing + PEP 740 attestations, pylock.toml + mochi.lock dual pinning, and a content-addressed Python wheel cache under package3/python/ Bidirectional package interop between Mochi and the PyPI ecosystem. Direction 1 (Mochi as PyPI consumer): an `import python "<package>@<semver>" as <alias>` surface form auto-resolves through the mochi.lock pin, fetches the wheel via the PEP 503 / PEP 691 simple index (default index https://pypi.org/simple/) into the content-addressed blob store under `~/.cache/mochi/python-deps/`, verifies against PEP 700 SHA-256 hashes and PEP 740 sigstore attestations when present, walks the package's PEP 561 type stubs (preferring an inline `py.typed` distribution, falling back to a sibling `<name>-stubs` package, falling back to a typeshed snapshot, falling back to `stubgen --inspect-mode` against the installed wheel) to extract a fully-typed surface, walks that surface through a closed Python-to-Mochi type translation table (int / float / bool / str / bytes / list / tuple / dict / set / frozenset / Optional[T] / X|Y union / Callable / Awaitable / AsyncIterator / TypedDict / dataclass / Protocol plus a refusal set for unparameterised `Any`, `**kwargs` of unknown shape, ParamSpec, Concatenate, TypeVarTuple beyond declared monomorphisations, recursive generic bounds, opaque C-extension types lacking stubs, and Pyright-narrowed `Literal` types whose narrowing depends on runtime values), and emits a synthesised CPython-3.12-compatible wrapper Python package (`python_wrap/`) plus matching `extern python type` and `extern python fun` Mochi declarations the parser accepts as if hand-written. The wrapper is loaded via the existing MEP-51 Phase 12 sidecar pattern (`<modname>_externs.py` adjacent to the .mochi source). Direction 2 (Mochi as PyPI producer): the existing MEP-51 `TargetPythonWheel`, `TargetPythonSdist`, and `TargetPythonPublish` targets are extended with a new `mochi pkg publish --to=pypi` CLI surface, which builds the wheel + sdist via the existing MEP-51 Phase 15 emit path, then runs `uv publish --trusted-publishing always` against either PyPI (production) or TestPyPI (staging) using GitHub Actions OIDC + sigstore-keyless signing + PEP 740 attestations (extending the MEP-51 Phase 18 workflow renderer). The bridge is implemented in `package3/python/` (greenfield, parallel to `package3/rust/` and `package3/go/`) and consumes MEP-57's `mochi.toml` plus `mochi.lock` infrastructure. The reference build adds a `[[python-package]]` table to `mochi.lock` recording the resolved wheel filename and version, BLAKE3-256 + SHA-256 of the wheel artefact (the SHA-256 also matches the PEP 700 hash the PyPI simple index publishes), the stub-source provenance (`py.typed` / `<name>-stubs` / `typeshed` / `stubgen`), the user-declared capability surface (`net`, `fs`, `proc`, `subprocess`, `cextension`), and the synthesised wrapper SHA-256 (so a `mochi pkg lock --check` fails if a transitive stub drift would silently regenerate the wrapper with a different signature). The 18-phase delivery plan walks from package3/python/ skeleton through PEP 503 / 691 simple-index client, PEP 700 hash verification, content-addressed wheel cache, PEP 561 stub ingest, type-mapping table, wrapper synthesiser, Mochi extern emitter, `import python` semver grammar extension, MEP-51 build orchestration, mochi.lock integration, pylock.toml co-emit, `mochi pkg publish --to=pypi` CLI, PEP 740 attestation flow, async bridge via asyncio.run, ABI-stable wheel emission (abi3), C-extension fallback story, embedded / Pyodide subset path, and a TestPyPI dry-run gate. Each phase is gated against a curated 25-package fixture corpus (anyhow-Python-equivalents are not relevant; instead: numpy, pandas, scipy, scikit-learn, requests, httpx, urllib3, pillow, pydantic, attrs, click, typer, rich, tqdm, sqlalchemy, fastapi, starlette, uvicorn, aiohttp, pyyaml, toml, tomli, msgpack, orjson, pytest) covering the top-25-most-downloaded-on-pypistats.org April 2026 snapshot. The bridge does NOT attempt to translate arbitrary Python source AST, does NOT support packages that ship only C extensions with no `.pyi` stubs and no typeshed entry without an explicit `[capabilities] cextension = true` opt-in plus a hand-written shim, does NOT support packages whose runtime behaviour depends on `sys.argv` manipulation at import time, and does NOT cover packages mutated by import-time monkey-patching.	Draft
0072	Mochi and TypeScript/JavaScript package bridge: bidirectional npm + JSR module interop with TypeScript-compiler-API .d.ts ingest, runtime-native ESM linkage (no synthesized FFI wrapper), no-boilerplate import ts syntax, dual-registry consume (npmjs.org + jsr.io) with package-lock and JSR-integrity cross-check, dual-registry publish via npm Trusted Publishing (Sigstore + OIDC) + JSR Trusted Publishing, and a content-addressed JavaScript dependency cache under package3/typescript/ Bidirectional package interop between Mochi and the TypeScript / JavaScript ecosystem covering both npmjs.org and jsr.io as first-class registries. Direction 1 (Mochi as npm/JSR consumer): an `import ts "<pkg>@<semver>" as <alias>` surface form auto-resolves through the mochi.lock pin, fetches the source via the npm registry protocol (https://registry.npmjs.org) or the JSR sparse-index protocol (https://jsr.io/@scope/pkg/meta.json) into the content-addressed blob store under `~/.cache/mochi/ts-deps/`, verifies against the registry's published SHA-512 integrity field (npm) plus the JSR-side BLAKE3 manifest (mid-2024 Trusted-Publishing addendum), runs the TypeScript compiler API (`ts.createProgram` + `ts.TypeChecker`) against the package's distributed `.d.ts` files (or against the source `.ts` files for JSR packages, which JSR transpiles server-side and never publishes a separate dist tree), walks that surface through a closed TypeScript-to-Mochi type translation table (number↔float, bigint↔int, string↔string, boolean↔bool, T[]↔list, ReadonlyArray↔readonly-list, Record<K,V>↔map, Map<K,V>↔map, Set<T>↔set, T | null / T | undefined↔T?, tagged-union string-literal unions↔Mochi sum types, plain object types and interfaces↔record types, class types↔extern type opaque handles, Promise<T>↔async fun return, AsyncIterable<T>↔stream<T>, plus a refusal set for branded types whose witnesses are not exported, conditional types beyond the eager-resolution table, mapped types beyond Pick/Omit/Partial/Required/Readonly/Record, intersection of two object types whose merged shape has overlapping non-identical members, declaration-merging across multiple `.d.ts` files where the merged shape is not a strict union, ambient module declarations with no corresponding runtime export, `this` parameter polymorphism, default exports that are arrow-function literals whose inferred type the checker prints as `() => any`, decorator-injected metadata, and TypeScript-only `enum` declarations that cannot be statically expanded to a literal union), and emits matching Mochi `extern type` and `extern fn` declarations the parser accepts as if hand-written. Crucially, MEP-72 does NOT synthesize a separate wrapper package (unlike MEP-73 Rust's extern-C wrapper or MEP-74 Go's cgo c-archive) because TS/JS lives in the same JavaScript runtime that Mochi's MEP-52 transpiler already targets; the ingest-side type binding is sufficient and the link is a plain ESM `import` at runtime. Direction 2 (Mochi as npm/JSR producer): the existing MEP-52 build targets (`TargetNpmPackage`, `TargetDenoJsr`, `TargetBrowserBundle`, `TargetReleaseWorkflow`) cover the publish path; MEP-72 adds one new target `TargetNpmLibrary` that emits a typed library package (no `bin/`, no shebang, `"type": "module"`, `exports` map with `import` / `require` / `types` conditions, `.d.ts` emitted by `tsc --declaration`, root README + LICENSE + package.json metadata harvested from `mochi.toml`'s `[ts.publish]` table) plus a parallel `TargetJsrLibrary` that emits a source-not-dist JSR package (per MEP-52 Phase 17's source-not-dist invariant), and ships via `mochi pkg publish --to=npm` and `mochi pkg publish --to=jsr` using the MEP-52 Phase 18 Trusted-Publishing workflow (`actions/setup-node@v4` + `npm publish --provenance --access=public` + `deno publish --token-source=github-actions`). The bridge is implemented in `package3/typescript/` and consumes MEP-57's `mochi.toml` plus `mochi.lock` infrastructure. The reference build adds two new repeated lockfile tables, `[[npm-package]]` and `[[jsr-package]]`, recording the resolved registry, the resolved version, BLAKE3-256 + SHA-512 (npm side) or BLAKE3-256 + JSR-integrity (JSR side) of the tarball, the TypeScript compiler-API surface SHA-256 (a stable hash of the public d.ts shape used at bind time), the user-declared capability surface (`net`, `fs`, `proc`, `worker`, `wasm`, `eval`), and the resolved import-map fragment (so a `mochi pkg lock --check` fails if a downstream consumer's lockfile would silently shadow a different name resolution). The 18-phase delivery plan walks from package3/typescript/ skeleton through npm-registry client, JSR-registry client, `.d.ts` ingest via the TypeScript compiler API, ApiSurface JSON schema + bridge-side parser, closed type-mapping table, ESM linkage emitter (the Mochi-emitted JS imports the consumed package directly with no wrapper synthesis), `import ts "<pkg>@<semver>" as <alias>` grammar extension, build orchestration + import-map synthesis, mochi.lock integration + `--check` mode, `TargetNpmLibrary` emit, `TargetJsrLibrary` emit, npm Trusted-Publishing publish flow (reusing MEP-52 Phase 18 emit), JSR Trusted-Publishing publish flow, Promise / async bridge (Mochi `async fun` ↔ TS `Promise<T>`; no runtime singleton, the JS event loop is already there), monomorphisation of generic items (the user opts in via `[ts.monomorphise]` mochi.toml entries), an edge-runtime subset that admits Cloudflare-Workers + Vercel-Edge + Deno-Deploy + Bun-Edge compatible packages only (no `node:fs`, no `node:net`, no `node:child_process`, no `node:worker_threads`), an ESM-vs-CJS dual-package interop pass (the Mochi side emits ESM as MEP-52 already does; the bridge must accept consumed packages that ship CJS only, ESM only, or dual-export), and a Deno Jupyter notebook consume-side gate (deno-Jupyter kernel imports Mochi-published JSR packages and a published Mochi-emitted npm package consumed under `npm:` specifier). Each phase is gated against a per-package ingest fixture corpus drawn from a curated 24-package set (typescript, zod, lodash, lodash-es, react, react-dom, vue, axios, dayjs, date-fns, valibot, drizzle-orm, prisma, hono, express, fastify, undici, nanoid, uuid, ts-pattern, immer, effect, neverthrow, ts-toolbelt) covering the top-most-downloaded-on-npmjs.org April 2026 weekly snapshot. The bridge does NOT attempt to translate arbitrary TypeScript source without `.d.ts` (a pure-JS package without a `@types/<pkg>` companion is refused with a clear diagnostic), does NOT support source-file-side decorators whose metadata is not surfaced via `.d.ts`, does NOT support runtime monkey-patching at module-load time without a `[capabilities] eval = true` opt-in, and does NOT cover Node-native-addon packages (`.node` binary modules) at the bridge layer (those are handled by the MEP-52 Phase 12 FFI surface, not MEP-72).	Draft
0073	Mochi and Rust package bridge: bidirectional crate interop with rustdoc JSON ingest, auto-generated extern C wrapper crate, no-boilerplate import rust syntax, crates.io publish via Cargo RFC #3724 trusted publishing, and a content-addressed Rust dependency cache under package3/rust/ Bidirectional package interop between Mochi and the Rust crates.io ecosystem. Direction 1 (Mochi as crate consumer): an `import rust "<crate>@<semver>" as <alias>` surface form auto-resolves through the mochi.lock pin, fetches the source via the Cargo sparse-index protocol into the content-addressed blob store under `~/.cache/mochi/rust-deps/`, runs `cargo doc --output-format=json` to extract a stable machine-readable API surface, walks that surface through a closed Rust-to-Mochi type translation table (i64/f64/String/Vec/HashMap/Option/Result/struct/enum/tuple plus a refusal set for lifetimes, generics beyond the monomorphised concretisations declared in mochi.toml, raw pointers, impl Trait return positions, and Pin/Future types whose erasure would lose unwind safety), and emits a synthesized extern "C" wrapper crate (`rust_wrap/`) that the MEP-53 build path links into the final binary, plus matching `extern type` and `extern fn` Mochi declarations the parser accepts as if hand-written. Direction 2 (Mochi as crate producer): a new MEP-53 build target `TargetRustLibrary` lowers a Mochi package to a publishable Rust library crate with `[lib] crate-type = ["rlib", "cdylib"]`, exports the user's public API as `pub fn` and `pub struct` items, generates a cbindgen-compatible C header so downstream non-Rust consumers can link against it, sets the publish-side `[package]` metadata (description, license, repository, documentation, keywords, categories, readme), and ships via `mochi pkg publish --to=crates.io` using Cargo RFC #3724 Sigstore-keyless OIDC trusted publishing (matching MEP-57's broader signing principle; long-lived crates.io API tokens are not accepted). The bridge is implemented in `package3/rust/` and consumes MEP-57's `mochi.toml` plus `mochi.lock` infrastructure. The reference build adds a `[[rust-package]]` table to `mochi.lock` recording the resolved crate version, BLAKE3-256 + SHA-256 of the tarball, the rustdoc JSON revision hash, the user-declared capability surface (`net`, `fs`, `proc`, `unsafe`), and the generated wrapper SHA-256 (so a `mochi pkg lock --check` fails if a transitive rustdoc-JSON drift would silently regenerate the wrapper with a different signature). The 14-phase delivery plan walks from package3/rust/ skeleton through sparse-index client, blob cache, rustdoc-JSON ingest, type-mapping table, extern-C wrapper synthesizer, Mochi extern emitter, `import rust` grammar extension, MEP-53 build orchestration, mochi.lock integration, TargetRustLibrary emit, crates.io publish via trusted publishing, async-fn bridge via a tokio singleton, monomorphisation of generic crates, and an embedded-subset path that admits `no_std`-compatible crates only. Each phase is gated against a per-crate ingest fixture corpus drawn from a curated 24-crate set (anyhow, thiserror, serde, regex, rayon, itertools, once_cell, time, uuid, url, base64, hex, sha2, blake3, rand, rand_chacha, num_cpus, bytes, smallvec, indexmap, ahash, parking_lot, crossbeam, tokio) covering the top-25-most-downloaded-on-crates.io April 2026 snapshot. The bridge does NOT attempt to translate arbitrary Rust source, does NOT support proc-macros at import time, does NOT support `unsafe fn` items without an explicit `[capabilities] unsafe = true` opt-in, and does NOT cover crate features mutated by build-time cfg conditional compilation paths.	Draft
0074	Mochi and Go package bridge: bidirectional Go-module interop with go/packages + go/types ingest, auto-generated cgo wrapper package, no-boilerplate import go syntax, proxy.golang.org consume + git-tag publish flow, sum.golang.org checksum-DB pinning, optional Sigstore cosign signing, and a content-addressed Go dependency cache under package3/go/ Bidirectional package interop between Mochi and the Go module ecosystem. Direction 1 (Mochi as Go-module consumer): an `import go "<module>@<semver>" as <alias>` surface form auto-resolves through the mochi.lock pin, fetches the source via the Go module proxy protocol (GOPROXY=https://proxy.golang.org by default) into the content-addressed blob store under `~/.cache/mochi/go-deps/`, verifies against sum.golang.org's checksum database, runs `go/packages.Load` to extract a full `*types.Package` with every exported identifier and its `types.Type`, walks that surface through a closed Go-to-Mochi type translation table (int64/int32/float64/string/[]T/map[K]V/struct/interface/chan/func/pointer/error plus a refusal set for unexported fields, generic type parameters beyond the monomorphised concretisations declared in mochi.toml, `unsafe.Pointer`, `cgo.Handle`, runtime/internal types, type-erased `interface{}` return positions whose erasure would lose statically-checkable types, and reflective `reflect.Value` / `reflect.Type` plumbing), and emits a synthesized cgo-compatible wrapper Go package (`go_wrap/`) with `//export` directives that the MEP-54 build path links into the final binary via `go build -buildmode=c-archive` plus the existing cc-rs link surface, plus matching `extern type` and `extern fn` Mochi declarations the parser accepts as if hand-written. Direction 2 (Mochi as Go-module producer): a new MEP-54 build target `TargetGoLibrary` (separate from the existing `TargetGoModule`) lowers a Mochi package to a publishable Go module with a real `package <name>` directory layout, exports the user's public API as `func` and `type` declarations with proper godoc comments, populates `go.mod` with `module <vanity-path>`, generates a matching cgo `_cgo_export.h` for non-Go consumers, sets the publish-side metadata (the README at the repo root, the LICENSE file, the doc.go package comment, the `// Package foo provides ...` summary), and ships via `mochi pkg publish --to=go+git+<repo-url>@<tag>` by tagging a git commit, pushing the tag, and waiting for the module proxy to pick it up (with an optional Sigstore-cosign signature attached as a sibling tag `<tag>.sig` per the experimental gosum-cosign workflow draft of 2026-Q1). The bridge is implemented in `package3/go/` and consumes MEP-57's `mochi.toml` plus `mochi.lock` infrastructure. The reference build adds a `[[go-package]]` table to `mochi.lock` recording the resolved module path, the resolved version (a semver tag, a pseudo-version, or a git rev), BLAKE3-256 + h1: of the .zip module artefact (the h1: hash is what sum.golang.org publishes, so the lockfile cross-verifies against the public checksum DB), the go/packages JSON-form revision hash, the user-declared capability surface (`net`, `fs`, `proc`, `cgo`, `unsafe`), and the generated wrapper SHA-256 (so a `mochi pkg lock --check` fails if a transitive go/packages drift would silently regenerate the wrapper with a different signature). The 18-phase delivery plan walks from package3/go/ skeleton through GOPROXY client, sum.golang.org cross-check, content-addressed module cache, go/packages ingest, type-mapping table, cgo wrapper synthesizer, Mochi extern emitter, `import go` grammar wiring (the keyword already exists for MEP-54 phase 10 FFI; MEP-74 extends it to take semver), MEP-54 build orchestration, mochi.lock integration, TargetGoLibrary emit, git-tag publish flow, optional cosign signing, goroutine bridge (channels↔streams + spawn↔go statement), monomorphisation of generic functions, an embedded subset that admits TinyGo-compatible packages only, a vanity-import-path resolver, and a WASI / wasm-js publish gate. Each phase is gated against a per-module ingest fixture corpus drawn from a curated 24-module set (stretchr/testify, spf13/cobra, spf13/viper, sirupsen/logrus, google/uuid, gorilla/mux, pkg/errors, google/go-cmp, golang/protobuf, json-iterator/go, davecgh/go-spew, golang/mock, cespare/xxhash/v2, mattn/go-isatty, klauspost/compress, prometheus/client_golang, uber-go/zap, gopkg.in/yaml.v3, spf13/pflag, gin-gonic/gin, labstack/echo/v4, valyala/fasthttp, jmoiron/sqlx, fatih/color) covering the top-25-most-imported-on-pkg.go.dev April 2026 snapshot. The bridge does NOT attempt to translate `internal/` packages, does NOT support build-tag-conditional compilation paths whose tags are not declared in mochi.toml, does NOT support `cgo` source files inside imported modules without an explicit `[capabilities] cgo = true` opt-in, and does NOT cover `unsafe.Pointer` arithmetic at the FFI boundary.	Draft
0075	Mochi and PHP package bridge: bidirectional Composer interop with PHP Reflection API surface extraction, auto-generated Mochi extern shims, no-boilerplate import php syntax, Packagist v2 sparse API consume, API-token-plus-GPG publish with Sigstore attestation workaround for the missing OIDC gap, TargetPhpLibrary PSR-4 emission, and a content-addressed PHP dependency cache under package3/php/ Bidirectional package interop between Mochi and the PHP Composer/Packagist ecosystem. Direction 1 (Mochi as Packagist consumer): an `import php "vendor/package@^semver" as alias` surface form auto-resolves through the mochi.lock pin, fetches from Packagist v2's sparse API (`https://packagist.org/p2/<vendor>/<package>.json`) into the content-addressed blob store under `~/.cache/mochi/php-deps/<sha256-hex>/`, then invokes a Go-side PHP reflection CLI that runs `php reflect.php <package-path>` to walk the package's classes, interfaces, and functions via PHP's built-in Reflection API and emit a JSON surface document. The bridge walks that surface through a closed PHP-to-Mochi type translation table (int to int, float to float, string to string, bool to bool, ?T to T|nil, array to list or map depending on shape heuristic, class to opaque handle or record if all-typed, interface to protocol handle, void to unit, never to panic, mixed to SkipReport, callable to closure, self/static to SkipReport) and emits synthesised Mochi extern declarations plus PHP-side glue that leverages the MEP-55 PHP output pipeline directly (no extern C needed; the bridge targets PHP-to-PHP interop, so the wrapper is just `use VendorClass;` plus type-annotated call forwarding). The mochi.lock gains a `[[php-package]]` table recording resolved version, SHA-256 of the dist zip, SHA-256 of the reflection JSON, and capability surface (net, fs, db). Direction 2 (Mochi as Packagist producer): a new MEP-55 build target `TargetPhpLibrary` lowers a Mochi package to a publishable Composer library with a PSR-4 `src/` directory, a generated `composer.json` carrying metadata from `mochi.toml`, a `README.md`, and a `LICENSE` file. The `mochi pkg publish --to=packagist` flow tags the git commit, pings the Packagist Update API, and attaches a GPG-signed git tag plus a Sigstore attestation on the dist zip (reusing the MEP-55 Phase 18 trust chain). Packagist has no OIDC trusted publishing as of May 2026 (unlike crates.io, npm, and PyPI); MEP-75 acknowledges this gap, documents the API-token-plus-GitHub-App mitigation for CI environments, and describes the roadmap toward full OIDC when Packagist ships it. The bridge is implemented in `package3/php/` and consumes MEP-57's `mochi.toml` plus `mochi.lock` infrastructure and MEP-55's existing PHP lowering pipeline. The 15-phase delivery plan walks from package3/php/ skeleton through Packagist v2 sparse client, Composer dist fetcher and SHA-256 content-addressed cache, PHP reflection CLI, PHP-to-Mochi type table, Mochi extern emitter, import php grammar wiring, autoload.php plus composer install integration, mochi.lock integration, TargetPhpLibrary emit, Packagist publish flow, interface and abstract class bridge, async PHP bridge via ReactPHP/RevoltPHP, phar distribution path, and the full 24-package fixture corpus gate. Each phase is gated against a curated 24-package fixture corpus drawn from the April 2026 top Packagist download rankings (guzzlehttp/guzzle, symfony/console, symfony/http-foundation, laravel/framework, phpunit/phpunit, monolog/monolog, doctrine/orm, psr/log, nesbot/carbon, vlucas/phpdotenv, league/flysystem, paragonie/random_compat, ramsey/uuid, bacon/bacon-qr-code, spatie/laravel-permission, barryvdh/laravel-debugbar, composer/composer, phpmailer/phpmailer, symfony/mailer, league/oauth2-server, firebase/php-jwt, socialiteproviders/google, stripe/stripe-php, and one additional utility package). The bridge does NOT attempt to translate PHP source without a Reflection-API-visible surface, does NOT support PHP version ranges below 8.1, does NOT support async PHP without the explicit `[php.async]` opt-in, and does NOT use OIDC trusted publishing (a documented gap with a clear roadmap).	Draft
0076	Mochi and Ruby gem bridge: bidirectional package interop with RubyGems.org ecosystem via RBS type-sig ingest, direct require/call (no C FFI layer), gem_rbs_collection fallback, no-boilerplate import ruby syntax, TargetRubyGem publish via OIDC trusted publishing, and a content-addressed Ruby dependency cache under package3/ruby/ Bidirectional package interop between Mochi and the RubyGems.org ecosystem. Direction 1 (Mochi as gem consumer): an `import ruby "<gem>@<semver>" as <alias>` surface form auto-resolves through the mochi.lock pin, fetches the gem via the RubyGems sparse-index into the content-addressed blob store under `~/.cache/mochi/ruby-deps/`, ingest RBS type signatures (from the gem's own `sig/` directory, then from gem_rbs_collection, then from YARD doc as a last resort) through a closed RBS-to-Mochi type translation table, and emits a synthesised `.rb` shim (a thin `require` + method-wrapper file) plus a matching `.mochi` `extern fn` corpus. Because MEP-56 already transpiles Mochi to Ruby, there is no C FFI wrapper layer: the generated Ruby code simply calls `require '<gem>'` and invokes gem methods directly, the same as any Ruby script. Direction 2 (Mochi as gem producer): a `TargetRubyGem` build target (introduced by MEP-56 phase 22) lowers a Mochi package to a publishable RubyGems gem, populates gemspec metadata from `mochi.toml`, and ships via `mochi pkg publish --to=rubygems.org` using OIDC trusted publishing (GA on RubyGems.org 2023, via GitHub Actions `id-token: write`). The `mochi-runtime` gem (Apache-2.0, ~123 LOC) already on RubyGems.org from MEP-56 is the proof that Direction 2 works end-to-end. The bridge is implemented in `package3/ruby/` and consumes MEP-57's `mochi.toml` plus `mochi.lock` infrastructure. The reference build adds a `[[ruby-package]]` table to `mochi.lock` recording the resolved gem version, SHA-256 of the gem tarball, the RBS sig revision hash, the user-declared capability surface, and the generated shim SHA-256 (so a `mochi pkg lock --check` fails if a transitive RBS drift would silently regenerate the shim with a different signature). The 14-phase delivery plan walks from package3/ruby/ skeleton through RubyGems sparse-index client, RBS bundled-sig ingest, gem_rbs_collection fallback ingest, YARD doc fallback ingest, RBS-to-Mochi type mapping, Ruby shim emit, import ruby grammar extension, Bundler-based build orchestration, mochi.lock integration, TargetRubyGem publish metadata, OIDC trusted publishing, native C extension gem handling, and a Ractor/Fiber async bridge. Each phase is gated against a per-gem ingest fixture corpus drawn from 20 curated gems (json, rake, rack, faraday, httparty, redis, sinatra, rspec-core, rubocop, dry-types, zeitwerk, dotenv, activesupport, nokogiri, pg, aws-sdk-s3, openai, sidekiq, puma, mini_magick) covering the most-downloaded RubyGems.org gems plus representative C-extension and async use cases.	Draft