#646 to #649 close: the review before the release, the sandbox reading, and both records

[Sunrisepeak]

Summary

The two records of #646 to #649 close. The triage record is marked closed and names the releases that carry it; the implementation plan gains the review that ran before the release (§1.10), the readings that close the plugin and ecosystem rows, and the closure itself (§9).

What the records now state that they did not

§1.10, the review before the release. Both pull requests were read once more after #650 merged and before 2026.9.16.1 was tagged. Four findings survived measurement, and the release dispatch was cancelled to carry the first, so 2026.9.16.1 ships from the follow-up branch rather than from f4529b2a.

• A gate refused what the previous release builds. The E4.2 comparison normalised a path and not a version constraint, so ">= 11.0.0" and ">=11.0.0" read as two sources. The manifest builds on the released 2026.9.15.2 with no error and no warning, and was refused on f4529b2a. Two spellings of one version constraint are one source (#647 E4.2 follow-up) #651.
• The record claimed a call the code does not make. The first custom-index sync restates two of decide_for_miss's conditions rather than calling it, which is correct: that pair's guard is about the index that resolves a dependency, and taking it would let an earlier refresh suppress a clone the build cannot proceed without. The comment now states which half is taken and why the other is not.
• Two contributors naming one file: the deepest won. The assets merge walked contributions forwards into a copy that overwrites, while the resources merge walks it backwards; and two contributors carrying one library name produced two build steps with one id and one output. 0.12.0: omit_keys, a named web page, the engine's strip decision, rules-swift, and contributions from the resolved graph mcpp-plugins#28.
• A reader that could not represent what it accepted. mcpp::plugins::json split surrogate pairs into unpaired surrogates, which is not UTF-8.

§9, the closure. What shipped, in which pull request, and how the release was verified: each of the four archives was compared with its published sha256 on GitCode, and the plugins source archive with cmp against the GitHub archive of the tag.

§9.3, four probe defects. Three runs of the sandbox script against the published engine read fails=4, fails=2 and fails=1, and not one failure was an engine defect. Two probes wrote std::println into a build program whose fixture states C++20; one printed its reading to standard output, which mcpp discards when a build program exits 0; and one measured the previous run, because the sandbox's $HOME persists, a build program is cached by its source, and a cache hit neither re-runs it nor replays its warnings.

The third is the one worth keeping. The first two sections passed on the run where their sources had just changed, and would have failed on the next run for the reason the third failed on that one. Every build program the script writes now carries a per-run token.

Verification

Documentation only; no engine, plugin or index source changes.

The reading that closes the batch

A SubOS sandbox with xlings config --mirror CN and mcpp self config --mirror CN inside it, against the published engine, plugins and index:

version=2026.9.16.1 fails=0

Seventeen assertions, including the program runs on one C++ runtime, the graph lists b before a, with b's [package.metadata], the graph-built libdep.so is stripped, T: cjson@1.7.19 resolves through the rung and asks for no refresh, and mcpp:plugins 0.12.0 resolves and a consumer builds. The same script against 2026.9.15.2 reads fails=10, every change detector failing and every guard passing.

§9.2.1 records why section K failed twice before it passed: an index artifact reaches its publisher before its consumers, and the same lag made the bootstrap pull request report twelve red checks while its pin was correct. Neither is visible from the publishing side, so both were settled by resolving through a consumer and only then re-running.