汇总:2026-09-20 全量 open issue 核验 —— 关闭十条、三条实测仍复现、其余逐条读数

[speak-agent]

A full pass over the 44 open issues, each checked against the code that is on origin/main today rather than against what an issue or a release note says about itself. Baseline: origin/main at 05d03cd, released version 2026.9.18.3, measured 2026-09-20. Ten issues are closed by this pass; the rest are classified below with the reading that keeps each one open.

A. Closed in this pass

Each was closed with the evidence in its own thread; the column here is the shortest true reason.

Issue	Why it closed	Where it landed
#259	The llvm payload's declared glibc was never installed by any path — the two loops that were meant to do it passed a bare xim:glibc, which resolve_xpkg_path rejects, and the rejection was discarded at debug level. ensure_declared_runtime now installs it before any fixup consumes it, for gcc and llvm alike.	#660, 2026.9.17.2; e2e 737, 687 leg C
#373	The scanner's two passes became one strip_noncode that carries block-comment state across lines.	2026.9.11.2; e2e 639
#379	The machine-readable contract shipped whole: envelope, effects instead of a destructive boolean, --format unified with --json kept permanently, self env --format json on a read-only path, positive detection as the primary rule.	2026.8.8.4; docs/50-machine-output.md; e2e 733
#417	Rule B's unevaluated binding is stated once, before the loop, naming what is missing — and rule B still runs, because PT_INTERP identity is a second input.	src/build/runtime_validation.cppm:691
#622	Every bin delivered (2026.9.11.3 / .4, 2026.9.12.3, 2026.9.12.4, #624, #625); its one remaining item was carried into #634 as B6 by the issue's own instruction.	see #634
#634	All twenty-one items delivered by owner.	2026.9.14.2 / .3, plugins 0.10.0, xim-pkgindex#838, mcpp-index#426
#646 #647 #648 #649	Delivered together, verified in a SubOS sandbox against the published engine, plugins and index: fails=0 on 2026.9.16.1 and fails=10 on 2026.9.15.2, so each assertion measures the change rather than the setup.	2026.9.16.1 (#650), plugins 0.12.0, close-out #653, follow-up #651

B. Three defects that still reproduce, re-measured today

These are #397's section B, opened 2026-08-09. Four of its nine are now fixed (C-2, C-5, C-6, C-7, C-8 — see the status comment); three still reproduce on 2026.9.18.3 and were measured rather than read.

B1. A fast-path hit never rebuilds compile_commands.json (#397 C-1).

$ mcpp new cdbdemo && cd cdbdemo && mcpp build   # CDB written
$ rm compile_commands.json && mcpp build
    Finished dev in 0.00s
$ ls compile_commands.json
ls: cannot access 'compile_commands.json': No such file or directory

write_compile_commands still has one call site, inside NinjaBackend::build() (src/build/ninja_backend.cppm:3067), which the fast path does not enter. The gate in try_fast_build / try_fast_run has gained inputs since — the SubOS manifest's mtime, dependency source roots, the validated-artifact snapshot — and every one of them is an input. The class named in 2026-08 is still open: fresh inputs do not imply complete outputs. It is reachable from git clean -fd, because mcpp new's .gitignore covers target/ and .mcpp/ but not the CDB.

B2. --no-color is a no-op on a TTY (#397 C-3).

$ script -qec "mcpp build --no-color" /dev/null | cat -v | grep -c '\^\['   # 1
$ script -qec "mcpp build"            /dev/null | cat -v | grep -c '\^\['   # 1

disable_color() (src/ui.cppm:239) clears g_color but not g_inited, so the first output call's init() recomputes from detect_color(), which answers is_tty(). MCPP_NO_COLOR and NO_COLOR are unaffected: they are read inside detect_color(). The reason this survived two years of CI is structural — every e2e captures through a pipe, where detect_color() returns false anyway, so the result is right and the cause is not, and no assertion can tell the two apart. A criterion for the fix has to call ui:: directly.

B3. [modules].exports validation is a silent no-op for any namespaced package (#397 C-4).

src/modgraph/validate.cppm:98 compares u.packageName == manifest.package.name, while src/modgraph/scanner.cppm:1207-1210 fills u.packageName with the qualified name (namespace + "." + name) and :1273 / :1320 are its only writers. With namespace = "acme", actual is the empty set, so neither the ordinary check nor strict ever fires. The comment at scanner.cppm:1204 still explains the qualification by a "module must be prefixed by the package name" check that was deleted in 0b8b81b, leaving :98 dangling.

C. Verified as still open, unchanged

Each of these was checked against the current code; none is fixed, and the reading is given so the next pass need not repeat it.

Issue	Current reading
#284	src/cli.cppm:756 still declares one positional for toolchain remove while install and default declare two. The space-separated spelling still fails.
#293	tests/e2e/_inherit_toolchain.sh:33 still ln -sfs the developer's real payloads into the temporary MCPP_HOME; anything a test patches is written through the link.
#370	src/pm/resolver.cppm:229-235 still reaches matches none of without pin_hint when every candidate is an orderable prerelease. The hint fires only on the unorderable branch.
#393	src/build/prepare.cppm:13454 still substitutes ctx.plan.outputDir.string() with no make_preferred.
#421	The BOM sub-finding is fixed (src/modgraph/scanner.cppm:212 skips EF BB BF and diagnoses a non-UTF-8 file). The two M1 limits the issue is actually about are unchanged: :1032 still refuses an import inside a conditional block, :1038 still refuses header units.
#484	mcpp deliberately does not parse ld.so.cache, and nothing relocates the private one. Note that #660 changed the neighbouring ground — the declared glibc payload is now installed — so this should be re-measured before it is worked on.
#518	The #516 reporting exists (src/cli.cppm:130, path/codepage as a degraded), but item A — replacing "no source files" when the unnarrowable anchor is the project root itself — is not built, and neither is item B.
#522	modules/manifest/src/xpkg.cppm:1748 still records features.<n>.ldflags / .include_dirs as unknown keys. The publishing-order caveat in the issue still applies.
#523	.github/workflows/ci-fresh-install.yml:272 still runs zypper -n install with no separate refresh step, so a refresh failure is still reported as a missing package.
#535	No staging of a host tool's shared dependencies beside the tool.
#621	No shebang-interpreter diagnostic on the run slot.
#283	Partly addressed, and deliberately so. tc_origin_is_user_explicit (src/build/prepare.cppm:879) excludes GlobalDefault with a measured regression recorded above it: making the global default outrank a row's pin broke a working x86_64-windows-gnu build, because the pin names the payload that supplies the target's C library, not a preferred compiler. The "silently" half is fixed for one case — prepare.cppm:11262 names the one-line [target.<t>] toolchain override — but only when the target side comes from the graph. The issue's own case (x86_64-linux-musl, no graph-supplied system) still says nothing, and toolchain list still reports the ignored default.
#527	Both confirmed bugs are fixed — [toolchain] system is refused by name instead of crashing on an empty posix_spawnp, and [workspace.package] / [workspace.build] inheritance shipped (docs/07-workspace.md §4.1). RFC 2 shipped as dialect_cxxflags (docs/04 §"Dialect flags and the import std BMI"). RFC 1 was declined with a reason in-thread. RFC 4 (--cdb-aggregate) is the only item with neither an implementation nor a decision.

D. Not defects, and not to be closed as such

• Upstream, tracked deliberately: clang 23.1.0: MSVC STL std module fails with reference to 'align_val_t' is ambiguous (fixed in 23.1.1, llvm/llvm-project#218152) #640 (clang 23.1.0, fixed upstream in 23.1.1), clang 22: a builtin first looked up in a module partition's purview becomes module-owned; importing it beside a GMF use is 'ambiguous' (macOS assert / __builtin_expect) #632 (clang 22 builtin ownership in a partition's purview), clang 22: full BMI from --precompile poisons importers; -c <reduced>.pcm silently emits an object with no definitions #424 and clang 20/22 module BMI: replacement-operator templates with params not pinned by arg1 poison name lookup for all importers (frontend SIGSEGV; gcc + clang18 fine) #256 (clang BMI), ci-macos xcode-27: ld64.lld cannot parse arm64e.x1 in either available SDK (upstream, tracked) #669 (ld64.lld and arm64e.x1 on the xcode-27 image), cppfly: add Clang reflection row when upstream lands P2996 #215 (waiting on P2996). Each exists so the next person who hits the signature finds the mechanism instead of re-deriving it; none should be closed while the signature is still reachable.
• Recent, unresolved: [c-abi] Windows + presents=posix: __unix__ is defined but compat.* still fails (18 packages); engine vs. upstream code assumption #674, GCC self-host: internal compiler error importing mcpp.targetside from a new consumer, under parallel build #667, Clang-built mcpp SIGSEGVs in ELF runtime inspection (validate_changed_artifacts); GCC-built does not #666 — all filed within the last three days, all with live reproductions.
• Standing records: NULL (保留) #43 (reserved), 留言版 | 使用mcpp工具构建的项目(库/工具/应用) #260 (the project board), bench - 构建性能测试 #428 (benchmark data collection), 问题备注 #611 and 备忘:2026-09-04 生态批次之后仍未闭合的四条(armv7a 无 C 库/板级包、riscv32 无后端、ninja 空转未定因、armv7a 无 preemption) #558 (memoranda that exist so their items do not live only in design documents).
• Requirements with an answer but no implementation: feat/RFC: [system_deps] —— 经 pkg-config 集成宿主系统库 #493 (declined as an engine feature, directed to a mcpp.build.pkgconf plugin — the plugin documentation it was waiting on now exists as docs/30-build-mcpp.md and docs/31-authoring-a-rule-package.md), feat: mcpp doc — 集成 doxygen + 用模块图修复跨模块引用 (cargo doc 式注释转文档) #399 (mcpp doc), xpkg Lua 描述符的 mcpp 构建规则无法按版本区分 #290, feat/RFC: 支持 Buildroot/OpenWrt/Yocto 等嵌入式 Linux SDK 的工程化集成 #276.

E. What this pass is not

It reads the code on origin/main and, where a reading was cheap to convert into a measurement, it runs the command instead. It does not re-verify the ecosystem repositories, and it does not re-run any CI. Where an issue's subject is a Windows or macOS host, the reading is from source only — the three defects in section B were each reproduced on Linux x86_64 with the released 2026.9.18.3 binary.