2026.9.26.1: paths in UTF-8, a C standard per package, a graph link without the host, and the level that was declared

[speak-agent]

Closes #693, #694, #695, #696. Plan, measurements and the implementation record: .agents/docs/2026-09-25-issues-693-696-triage-and-repair-plan.md (§12.4 for what departs from the plan, Appendix A for the readings).

#693: one text encoding

mcpp held paths in the Windows ANSI code page while compile_commands.json holds UTF-8 only. Every build under a non-ASCII project directory or MCPP_HOME failed with internal: unhandled exception: [json.exception.type_error.316], including names the code page can spell (every Chinese name on code page 936); a Latin-1 directory name fails the same way on Linux. The report's silent 0xC0000409 is the xlings shim (openxlings/xlings#613).

• mcpp.exe declares the UTF-8 code page through [resources] files = ["res/mcpp.rc"] (the bootstrap engine that builds a release does not know the new key). build.mcpp is linked with the same manifest; host tools default to it; [targets.<name>] windows_code_page = "utf-8" | "legacy" states it for a project's own executables.
• A path with no UTF-8 spelling is refused (project directory, MCPP_HOME), skipped and reported (a name inside a project, the path/codepage channel of Windows 解压包含 UTF-8 路径的归档时因多字节代码页转换失败 #516), or refused by key (a build.mcpp directive). A serialiser failure in compile_commands.json is that document's write failure.
• The response files of the msvc dialect begin with a UTF-8 byte order mark: cl.exe, link.exe and lib.exe read UTF-8 only with it (measured, Appendix A.13). When build.ninja holds a non-ASCII byte, ninja -t wincodepage must answer UTF-8.
• On a Windows older than 1903 the diagnostics name the process code page.

#695: c_standard applies to the package that declares it

The root's value was on the file-level $cflags; a dependency's own declaration was parsed, hashed and not applied. Each package's C units (the entry main included) now compile at their own standard, an undeclared package at c11; the cl.exe dialect reports, in one line, the declarations it does not apply. The #690 record carries a correction note.

#696: a graph link searches no host directory

An ELF link over a graph-supplied C library, by clang, carries --sysroot=<build>/graph-sysroot (empty), and the hermetic check holds every -L to the store, the build directory and the graph's packages. An unanswered -l fails with a note that names openkal-musl 0.19.2, which ships musl's eight empty archives (mcpplibs/openkal-musl#43, registered in mcpplibs/mcpp-index#467).

#694: the declared optimization level

The *-linux-musl -Og workaround is removed; the compile and the Finished line read one realised level.

Tests

• Unit: per-package C standard (7), hermetic graph link (4), optimization level over every target row, response-file BOM, Ninja encoding, UTF-8 validity and escaping, directive encoding, windows_code_page parsing, the rc scanner.
• e2e 776 (paths with no UTF-8 spelling, four entry points), 777 (per-package C standard), 778 (graph link, two legs; run in openkal-cross.yml where llvm is installed). Each fails against 2026.9.25.1 at the criterion it names.
• Windows: .github/tools/check_unicode_paths.sh builds and runs llvm, MSVC and MinGW rows in an ASCII, a caf + U+00E9 and a U+6D4B U+8BD5 directory, plus a path through build.mcpp.

Still to come on this branch

kXlingsVersion moves to the xlings release that carries openxlings/xlings#613.

[speak-agent]

CI on 15317aa: 40 checks pass. The two that fail are the xcode-27 legs (macOS ARM64 — xlings LLVM end-to-end (xcode-27) and e2e suite (macOS ARM64, self-host, xcode-27)), which fail the same way on main: ld64.lld 22.1.8 cannot parse arm64e.x1 in that image's SDK stubs (tracked in #669, upstream).

What the run measured for this change:

• toolchains + regressions (windows x64): check_unicode_paths.sh builds and runs the llvm, MSVC and MinGW rows in an ASCII, a caf + U+00E9 and a U+6D4B U+8BD5 directory, plus a path through build.mcpp; every row passes.
• The packaged mcpp-2026.9.26.1-windows-x86_64.zip carries RT_MANIFEST ID 1 with activeCodePage UTF-8 in bin/mcpp.exe, and the bundled registry/bin/xlings.exe (2026.9.26.2) carries the same.
• openkal e2e: e2e 778 passes all four legs (the graph answers -lm on x86_64-linux-musl; an unanswered -lm fails with the note; aarch64-linux-musl links and runs under qemu-aarch64; a host -L is refused by the hermetic check).
• e2e 776 and 777 pass on the Linux shards; the unit suites pass on Linux, macOS and Windows.

Run 1 failed test_cache_key on every platform (it stated the old key rule) and e2e 778 (it paired openkal-musl 0.19.2 with runtime 0.15.1, which the exact pin refuses); both are corrected in 9697b21.