@@ -1124,6 +1124,35 @@ inline ArtifactNaming artifact_naming(const Triple& t, const ArtifactNaming& hos
             .sharedNeedsImportLib = false,
         };
     }
+    if (t.os == "emscripten") {
+        // `artifact_naming`'s one sentence, unchanged: the executable is the
+        // file a runner executes, in the row's own convention. On this row
+        // that file is the JavaScript launcher — what the emsdk payload's
+        // `node` runs and what a browser loads — so the row's convention for
+        // "the executable" is `.js`, not the ELF/host-borrowed bare name this
+        // used to fall back to (a different file on Linux vs. Windows hosts).
+        //
+        // Read, not recalled: Emscripten's own CMake toolchain fixes
+        // `CMAKE_EXECUTABLE_SUFFIX ".js"` (`Platform/Emscripten.cmake`) and
+        // Rust's `wasm32-unknown-emscripten` target spec sets
+        // `exe_suffix: ".js"` — both because emcc's `-o` extension selects
+        // what it emits, and anything but `.js`/`.html`/`.wasm` falls back to
+        // the `.js` case. A future `wasm32-wasi` row would answer `.wasm` by
+        // the same sentence, the way Rust's other wasm targets do, because
+        // there the module IS the executable a runner executes.
+        //
+        // `sharedLibExt` is empty and `sharedNeedsImportLib` is set as the
+        // "shared libraries are not supported for this target" marker (see
+        // the field comment above): a wasm side module needs `-sSIDE_MODULE`,
+        // a link contract this engine does not render, so the fallback answer
+        // (a `.so`-shaped file that does not work as one) is refused instead
+        // of produced — see the plan-time refusal in prepare.cppm.
+        return ArtifactNaming{
+            .exeSuffix = ".js", .libPrefix = "lib",
+            .staticLibExt = ".a", .sharedLibExt = "",
+            .sharedNeedsImportLib = true,
+        };
+    }
     // Outside the triple language: fall back to the host answer rather than
     // guessing. A wrong guess here silently misnames every artifact.
     return hostNaming;
 
@@ -128,7 +128,7 @@ struct CompileFlags {
     }
 };
 
-enum class LinkIntentFlavor { Elf, MachO, PeGnu, PeMsvc };
+enum class LinkIntentFlavor { Elf, MachO, PeGnu, PeMsvc, Wasm };
 
 // Spell a provider-neutral LinkIntent for one output format.  Kept pure so
 // every platform contract can be asserted on every CI host.  deployFiles are
@@ -758,14 +758,16 @@ CompileFlags compute_flags(const BuildPlan& plan) {
                 case mcpp::toolchain::triple::ObjectFormat::Pe:
                     return LinkIntentFlavor::PeGnu;
                 case mcpp::toolchain::triple::ObjectFormat::Wasm:
-                    // No `LinkIntentFlavor::Wasm` exists, and inventing one
-                    // here would be a link-contract decision rather than a
-                    // format question -- what `link_lib` and a search path
-                    // even mean for an Emscripten link is the open half of
-                    // #597. `Elf` is the wrong answer and is the one this
-                    // returns; it is named here so the gap is visible rather
-                    // than reached by falling off the end of a switch.
-                    return LinkIntentFlavor::Elf;
+                    // #622 A5 closes the open half of #597: what `link_lib`
+                    // and a search path mean for an Emscripten link is ELF's
+                    // own spelling. `-L` for a search directory and `-l<name>`
+                    // for a library are both flags emcc's driver accepts
+                    // unchanged (`-lidbfs.js` is one of its own JS system
+                    // libraries), and `frameworks` and `link_library_dirs`
+                    // carry no Emscripten-specific rendering either. So the
+                    // flavor exists to give the switch below an honest arm —
+                    // not because the rendering differs from `Elf`'s.
+                    return LinkIntentFlavor::Wasm;
                 case mcpp::toolchain::triple::ObjectFormat::Elf:
                     return LinkIntentFlavor::Elf;
             }
 
@@ -2148,6 +2148,20 @@ std::string emit_ninja_string(const BuildPlan& plan) {
     }
     if (!plan.resourceUnits.empty()) append("\n");
 
+    // #622 A5: on `wasm32-emscripten` the link command is a single emcc
+    // invocation that writes the named output (`<name>.js`, this plan's
+    // artifact naming — see triple.cppm) AND `<name>.wasm` beside it in one
+    // run. The `.wasm` is not a second edge (nothing would sequence it against
+    // the first) and not a naming convention applied after the fact — it is
+    // declared as an implicit output of the SAME edge, so `ninja -t clean`,
+    // the incremental check and `mcpp pack`'s graph walk all see it.
+    const auto planTargetTriple =
+        mcpp::toolchain::triple::parse(plan.toolchain.targetTriple);
+    const bool wasmTarget =
+        planTargetTriple
+        && planTargetTriple->object_format()
+               == mcpp::toolchain::triple::ObjectFormat::Wasm;
+
     // Link units
     for (auto& lu : plan.linkUnits) {
         std::string ins;
@@ -2213,6 +2227,16 @@ std::string emit_ninja_string(const BuildPlan& plan) {
         std::string implicitOut;
         if (!lu.importLibrary.empty())
             implicitOut = " | " + escape_ninja_path(lu.importLibrary);
+        // The `.wasm` module emcc writes beside the JavaScript launcher for
+        // every executable link on this row (see the comment above the loop).
+        // Not the test binary's rule alone and not the `bin` rule alone: both
+        // ARE the executable form on this row, so both get the sibling.
+        if (wasmTarget
+            && (lu.kind == LinkUnit::Binary || lu.kind == LinkUnit::TestBinary)) {
+            auto wasmSibling = lu.output; wasmSibling.replace_extension(".wasm");
+            implicitOut += (implicitOut.empty() ? " | " : " ")
+                         + escape_ninja_path(wasmSibling);
+        }
         // The link map, DECLARED rather than merely written. It is produced by
         // a flag on the link command, so it cannot be its own edge — a second
         // edge claiming to produce it would run the link twice. Declaring it
 
@@ -2521,6 +2521,32 @@ prepare_build(bool print_fingerprint,
                     parsed->str(), which, which));
             }
         }
+        // A `shared` TARGET NAMES A LINK CONTRACT THIS ENGINE DOES NOT RENDER.
+        //
+        // `-sSIDE_MODULE` is a different Emscripten link mode from the
+        // ordinary one (one static image, `artifact_naming`'s `.js`+`.wasm`
+        // pair) and mcpp emits no flag for it. Falling through to the
+        // ordinary link would still WRITE a `.so`-shaped file — the fallback
+        // naming's `sharedLibExt` is empty, so the linker would be asked for
+        // an empty-named output — so this is caught here, by NAME, rather
+        // than reached as an obscure link failure.
+        //
+        // REFUSED HERE AND NOT AT PLAN TIME, same reasoning as the Apple SDK
+        // check above: `parsed` and the manifest's own target list are both
+        // already known, resolving neither an emsdk payload nor any other
+        // toolchain, so an offline build (no emsdk installed) gets this
+        // sentence instead of downloading the SDK first.
+        if (parsed && parsed->object_format()
+                          == triple::ObjectFormat::Wasm) {
+            for (auto const& t : m->targets) {
+                if (t.kind != mcpp::manifest::Target::SharedLibrary) continue;
+                return std::unexpected(std::format(
+                    "[targets.{}] kind = \"shared\" is not supported on "
+                    "wasm32-emscripten: a side module needs -sSIDE_MODULE, "
+                    "which mcpp does not render",
+                    t.name));
+            }
+        }
         // Known, supported — and IMPOSSIBLE ON THIS HOST.
         //
         // Without this the target falls through to the host toolchain and the
 
@@ -40,11 +40,13 @@ import mcpp.config;
 import mcpp.pack.binfmt;
 import mcpp.pack.host_requirements;
 import mcpp.pack.relocate;
+import mcpp.pack.stage_tree;
 import mcpp.pack.strip;
 import mcpp.pack.zip;
 import mcpp.platform;
 import mcpp.xlings;
 import mcpp.manifest;
+import mcpp.toolchain.triple;
 
 export namespace mcpp::pack {
 
@@ -167,6 +169,13 @@ struct Plan {
     // Is the artifact a PE? Read from the FILE, not inferred from the triple —
     // the file is the thing being packaged, and a triple is a request.
     bool                                 targetIsPe = false;
+    // Is the artifact a wasm32-emscripten launcher? Read from the TRIPLE, not
+    // the file: the packed file is `bin/<name>.js`, plain JavaScript text
+    // carrying none of ELF/PE/Mach-O's magic, so `binfmt::identify` cannot
+    // answer this the way it answers `targetIsPe`. The triple is what named
+    // the file `.js` in the first place (see `artifact_naming`), so it is the
+    // one fact this format IS recorded under.
+    bool                                 targetIsWasm = false;
     // The search set the PE closure resolves names against, after the
     // contract has had its say (see make_plan).
     std::vector<std::filesystem::path>   searchDirs;
@@ -378,6 +387,11 @@ make_plan(const mcpp::manifest::Manifest& manifest,
     p.targetIsPe =
         mcpp::pack::binfmt::identify(builtBinary).format
             == mcpp::pack::binfmt::Format::Pe;
+    // The triple, not the file — see the field comment on `targetIsWasm`.
+    if (auto t = mcpp::toolchain::triple::parse(p.triple)) {
+        p.targetIsWasm =
+            t->object_format() == mcpp::toolchain::triple::ObjectFormat::Wasm;
+    }
 
     // THE CONTRACT REACHES PACKAGING. Until now it stopped at the compile and
     // link flags, so the step that decides which files travel could not see
@@ -1055,6 +1069,64 @@ run_pe(const Plan& plan)
     return {};
 }
 
+// The wasm32-emscripten half of `run`. No dependency closure: the ordinary
+// Emscripten link produces one static image with everything embedded (a
+// `shared` target on this row is refused at plan time, before packaging ever
+// sees it — see prepare.cppm), so there is nothing here to trace under a
+// dynamic linker the way the PE and ELF halves do.
+//
+// THE STEM FAMILY RULE. The launcher (`<name>.js`) is the executable; the
+// family is every other `<name>.<anything>` the link wrote beside it. `.wasm`
+// is required — the link edge declares it as an implicit output
+// (ninja_backend.cppm), so its absence names a build directory that does not
+// match the graph rather than a program that legitimately has none. A
+// `.data` (from `--preload-file`), a `.worker.js` or a `.wasm.map` are
+// optional and travel exactly when the link wrote them: this packer stages
+// whatever it finds, and asks the link, never a fixed extension list.
+std::expected<void, Error>
+run_wasm(const Plan& plan)
+{
+    std::error_code ec;
+    std::filesystem::remove_all(plan.stagingRoot, ec);
+    std::filesystem::create_directories(plan.stagingRoot / "bin", ec);
+    if (ec) return std::unexpected(Error{std::format(
+        "cannot create staging '{}': {}", plan.stagingRoot.string(), ec.message())});
+
+    auto stagedJs = plan.stagingRoot / "bin" / plan.binaryName;
+    std::filesystem::copy_file(plan.builtBinary, stagedJs,
+        std::filesystem::copy_options::overwrite_existing, ec);
+    if (ec) return std::unexpected(Error{std::format(
+        "copy launcher failed: {}", ec.message())});
+
+    const auto builtDir = plan.builtBinary.parent_path();
+    auto family = mcpp::pack::emscripten_stem_family(builtDir, plan.binaryName);
+    if (!family.hasWasm) {
+        const auto stem = plan.builtBinary.stem().string();
+        return std::unexpected(Error{std::format(
+            "'{}.wasm' is missing beside the built launcher '{}' -- the "
+            "wasm32-emscripten link declares it as an implicit output, so its "
+            "absence means the build directory does not match the graph",
+            stem, plan.builtBinary.string())});
+    }
+    for (auto const& name : family.siblings) {
+        std::error_code fec;
+        std::filesystem::copy_file(builtDir / name,
+            plan.stagingRoot / "bin" / name,
+            std::filesystem::copy_options::overwrite_existing, fec);
+        if (fec) return std::unexpected(Error{std::format(
+            "failed to copy {} -> {}: {}", (builtDir / name).string(),
+            (plan.stagingRoot / "bin" / name).string(), fec.message())});
+    }
+
+    if (auto r = stage_runtime_files(plan, stagedJs.parent_path()); !r) return r;
+
+    copy_if_exists(plan.projectRoot / "README.md", plan.stagingRoot);
+    copy_if_exists(plan.projectRoot / "LICENSE",   plan.stagingRoot);
+
+    if (plan.opts.format != Format::Tar) return {};
+    return make_tarball(plan.stagingRoot, plan.archivePath);
+}
+
 } // namespace detail
 
 std::expected<void, Error>
@@ -1066,6 +1138,13 @@ run(const Plan& plan, const mcpp::config::GlobalConfig& cfg)
     // the host: `LD_TRACE_LOADED_OBJECTS` cannot trace a PE from Linux either.
     if (plan.targetIsPe) return detail::run_pe(plan);
 
+    // wasm32-emscripten, before the Mach-O refusal and the ELF closure below:
+    // this artifact is neither. `binfmt::identify` reports `Unknown` for the
+    // `.js` launcher (plain text, none of the three magics), which is exactly
+    // the branch the ELF path's own comment warns cannot be assumed away by
+    // exclusion any more.
+    if (plan.targetIsWasm) return detail::run_wasm(plan);
+
     // A Mach-O artifact is REFUSED, on every host including macOS.
     //
     // The closure below asks the dynamic linker for the dependency list by
 
@@ -122,4 +122,39 @@ bool is_builtin_pack_format(std::string_view name) {
     return std::ranges::find(kBuiltinPackFormats, name) != kBuiltinPackFormats.end();
 }
 
+// #622 A5 — the wasm32-emscripten stem family, read from the directory the
+// link wrote into rather than assumed from a fixed extension list.
+//
+// THE RULE: the launcher (`<name>.js`) is the executable; the family is every
+// other `<name>.<anything>` the SAME link also wrote. `.wasm` is required —
+// the link edge declares it as an implicit output (see ninja_backend.cppm),
+// so a missing one names a build directory that does not match the graph,
+// not a program that legitimately produced none. A `.data`
+// (`--preload-file`), a `.worker.js` (`-pthread`) or a `.wasm.map` are
+// optional and travel exactly when the link wrote them — this asks the link,
+// never a list this module would have to keep in step with emcc's.
+struct EmscriptenStemFamily {
+    std::vector<std::string> siblings;    // sorted; excludes the launcher itself
+    bool                     hasWasm = false;
+};
+
+EmscriptenStemFamily emscripten_stem_family(const std::filesystem::path& builtDir,
+                                            std::string_view launcherName) {
+    EmscriptenStemFamily out;
+    const auto stem = std::filesystem::path(launcherName).stem().string();
+    const auto prefix = stem + ".";
+    std::error_code ec;
+    for (auto const& entry : std::filesystem::directory_iterator(builtDir, ec)) {
+        if (ec) break;
+        auto name = entry.path().filename().string();
+        if (name == launcherName || !name.starts_with(prefix)) continue;
+        std::error_code fec;
+        if (!entry.is_regular_file(fec)) continue;
+        if (name == stem + ".wasm") out.hasWasm = true;
+        out.siblings.push_back(std::move(name));
+    }
+    std::ranges::sort(out.siblings);
+    return out;
+}
+
 } // namespace mcpp::pack