Fixes

• A mingw build no longer sees the Linux system's headers and libraries. Inside the Flatpak the mingw-w64 prefix is the host's /usr, and it was clang's --sysroot, so clang searched /usr/include and /usr/lib for the Windows build as well: libstdc++ found glibc's sys/single_threaded.h and had shared_ptr read __libc_single_threaded, and every program that used one failed to link. CRAFTER_MINGW_DIR=/usr did the same outside the Flatpak. A prefix that also holds a Linux system (the host's /usr, or any prefix whose include/ has a C library's features.h) now reaches clang through a view of its mingw-w64 directories in the cache, and compiler messages still name its headers where they are installed. A prefix that holds mingw-w64 alone is the sysroot as before, so Windows libraries installed into its include/ and lib/ are found (#43).
• Units that import a std module rebuilt in place, after a libc++ update or a mingw-w64 update under the same compiler, are compiled again. They used to be relinked unchanged.
• A CMake external whose configure inputs changed, such as another compiler or --sysroot, is built again from an empty build directory. It used to be reconfigured in place, keeping the objects and check results of the old configure, so a mingw external built by 4.0.0 would have kept failing to link after the fix above.
• Configurations that compile the std module differently no longer share one. Two that differed only in -mtune (a project built with CRAFTER_BUILD_MTUNE set, next to its own project.cpp) or only in sysroot took turns rebuilding it, and every module built against it, on every run.
• crafter-build lint fails, and says why, when a configuration's compile command cannot be assembled or its std module cannot be built. Its files used to pass every rule that needs an AST as if they were clean.

Breaking

• Toolchain::mingwSysroot is now mingwPrefix, beside mingwPrefixIsSystem, because clang no longer always gets the prefix itself. A project.cpp that passes the mingw sysroot to a command of its own calls MingwSysroot(); passing mingwPrefix brings the bug above back for a prefix like /usr.
• The std module's cache directory is now keyed on every flag it is compiled with, and every build directory on the std module it imports, so the first build of each project after updating starts in fresh directories and compiles everything, as after a compiler update. crafter-build clean removes the old build directories; the old std module directories stay in the cache until it is cleared by hand.

New

• A project keeps its agent instructions in AGENTS.template.md, and crafter-build and crafter-build test write AGENTS.md from it with the dependencies' notes merged in: after the template's text, or between its marker lines. AGENTS.md is build output, so it goes into .gitignore, and a fresh clone has none until its first build. A project with a committed AGENTS.md moves over with git mv AGENTS.md AGENTS.template.md and echo /AGENTS.md >> .gitignore. An AGENTS.md no build wrote, such as a committed one still beside a new template, is never replaced; every build warns until it is deleted.

Fixes

• A build no longer changes a file the project commits. The dependency notes lived in a section of the committed AGENTS.md, so a dependency that edited its notes, an unpinned one that moved on, or a flag that pulled one in showed up in the project's diff as a change nobody made.

Breaking

• Without an AGENTS.template.md, a build leaves AGENTS.md alone. A section 3.0.0 kept in it is no longer updated, and every build warns about it until the file is moved to the template or the section is deleted.

New

• C++ exceptions work in WebAssembly builds. Every wasm32-wasip1 unit and the std module are compiled with WebAssembly exception handling in its standardized form (exnref), against the exception-enabled libc++ the sysroot ships under lib/<triple>/eh/, and -lunwind and -lsetjmp are linked automatically, so throw and catch, libc++'s own throws, setjmp and longjmp all work. The Flatpak's WASI sysroot is built with those libraries. A page from EnableWasiBrowserRuntime probes for the feature and names what an older browser lacks instead of failing with a CompileError.
• Scripts. A project.cpp can push a name and a C++ callback onto cfg.scripts; crafter-build run <name> [args...] runs it with everything after the name handed over untouched, a bare run lists the scripts, and the callback's return value is the exit status. ScriptContext gives it the project, the project directory, the arguments and Run(command), which runs a shell command with the terminal attached. Crafter::ShellQuote is exported. Only the scripts of the project crafter-build was pointed at can be run, never a dependency's.
• Dependency notes for agents. A library ships an AGENTS.consumer.md beside its project.cpp; crafter-build and crafter-build test keep its dependencies' notes in a marked section of a consumer's AGENTS.md, when the consumer has one, and never create the file. cfg.dependencyNotes picks the dependencies: Transitive (the default), Direct or None, which also removes the section.
• In a page from EnableWasiBrowserRuntime, exit and _Exit end the program without running any of its code on the way out, no destructor and no catch (...), with the status in window.crafter_wasi.exitCode. A program that hands the thread to the browser for good and goes on serving calls imports crafter_runtime.park instead, which never returns and leaves main's locals valid for the calls that follow.
• The mingw target is found where it is: by the x86_64-w64-mingw32-gcc on PATH, through CRAFTER_MINGW_DIR naming another prefix, and inside the Flatpak through the host's /usr when it has mingw-w64. Its std module comes from the toolchain's own libstdc++.modules.json, and a toolchain that is not there is a build error saying where it looked, not std::terminate.

Fixes

• A program that holds two builds of one module is refused before anything compiles, with both paths and what tells the builds apart. A sibling project that two paths loaded with different arg lists used to be built twice, every consumer took whichever build clang found first, and the program built cleanly and then read garbage or crashed (#41).
• An external dependency shared by the configurations of one build is fetched and built once per build pass instead of once per configuration, and each clone's fetch and build hold a file lock. The tests of a project that copies its externalDependencies into each test pulled the same clone side by side and broke its FETCH_HEAD, which failed every test (#34); they now wait for one fetch.
• Incremental builds pick up more of what changed. A shader rebuilds when a file it includes or one of its settings (stage, entry point, defines, include directories) changes, not only its own source. An executable relinks when its link command changed, such as a new link flag or a dependency's library that moved to another cache directory, not only when an object is newer.
• Submodules are checked out at the revisions the fetched commit records, after every clone, switch, checkout and pull, so a pinned commit builds against its own submodules and not the default branch's.
• A project that loads the same sibling as one of its #pragma crafter dependency tools, with the same args, got the tool's copy back: host tooling with -march=native and -fPIC, whose BMI clang then refused. Host tooling and everything it loads are now kept apart in the project cache.
• crafter-build format clean formats the rules matching "clean"; it used to delete bin/ and build/ and exit 0.
• -- ends crafter-build's options, as the help has advertised: every later word is an operand of the verb. It used to be forwarded as a project arg and change the variant hash, and the words after it were still read as options.
• ProjectDependency() works from a static initialiser of a project file; it used to find nothing there and terminate the process.

Breaking

• A wasm build needs a sysroot that ships the exception-enabled libc++ and libunwind (wasi-sdk 33 or later; the Flatpak's does), and stops with one line saying so without one. It refuses -fno-exceptions, -flto in compileFlags or linkFlags, and shared libraries, each with a message that says why; there is no switch back to building without exceptions. The result runs on engines with exnref: Chrome 137, Firefox 131, Safari 18.4 and wasmtime 47 or newer (the bundled one qualifies; an older wasmtime needs -W exceptions=y). An exception that escapes main ends the program as an uncaught WebAssembly exception without calling std::terminate, so catch it in main to report it. The flags are part of the variant hash, so the first wasm build after updating starts in a fresh directory.
• A sibling loaded through GitProject or LocalProject without .args now receives the args its loading project.cpp was given, so --target=, --march=, --debug and the project's own flags reach every sibling down the chain; releases up to 2.2.0 forwarded nothing. Set .args = {} to keep the old behaviour, and give every sibling the same list: a project that two paths load with different lists now stops the build. The default is read when the spec is made, so make it inside CrafterBuildProject; a spec made at namespace scope forwards nothing. A #pragma crafter dependency still gets none of the project's args.

A Shader entry can carry defines, spelled like the compiler's -D (NAME is defined to 1, NAME=VALUE to VALUE), and a variant that names its output, so one source compiles into several outputs: ui.comp.glsl with variant sets becomes ui.comp.sets.spv. A configuration in which two entries share an output name is refused with both named, as are a malformed define and a variant with a path separator.

Compiles with a sysroot now use the sysroot's own libc++ headers instead of the bundled toolchain's, which fixes cross builds against a musl sysroot that include a standard header textually and stops glibc sysroot builds from silently compiling against the wrong libc++ release. The project.so stamp hashes every part of the host build, so a changed declaration recompiles it. The vendored json.hpp is gone.

The bundled toolchain is now LLVM 23.1.2. Build outputs are kept per compiler, so the first build after updating recompiles each project into a fresh directory and nothing has to be cleaned by hand.

Cross builds pick the std module source that matches the sysroot's libc++ release. The source for libc++ 22 ships beside the bundled 23 for sysroots that carry libc++ without one, such as Alpine, and a sysroot nothing matches fails with one line naming both releases. crafter-build --version prints the libc++ release in use.

First release distributed as a Flatpak, with a bundled LLVM 22 toolchain and WASI sysroot. Windows host support is removed; crafter-build gains --version and resolves its compiler from one place.