chore: bootstrap from 2026.9.6.4, and the round 6 review - #582
Merged
Conversation
The bootstrap pin is what `xlings install mcpp` puts in the workspace so CI can build mcpp from source. Bumping it is not required -- the index retains every published version, so an older pin keeps resolving -- but a green round on the bumped pin is direct proof that the release just published can build the current tree on every platform, which is the one thing nothing else checks. Safe now and not before: the pin must never name a version that is not yet installable, and 2026.9.6.4 is published, mirrored on both hosts, merged into xim-pkgindex, and its index artifact is green. The review records what the round changed, the six criteria and how each was measured, and the two defects the implementation turned up: a tool conditioned on a target-side layer would be declared and never installed (refused, with e2e 619 measuring both sides), and mcpp-plugins' C-library check was reading a build graph it had not written.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #581, which had to merge before the release it describes existed.
The bootstrap pin
.xlings.json[workspace].mcppmoves2026.9.6.1→2026.9.6.4. Per docs/09 §4 this is a useful check, not a prerequisite — the index retains every published version, so an older pin keeps resolving. What the bump buys is a green CI round proving the release just published can build the current tree on every platform, which nothing else checks.The one hard constraint is direction: the pin must never name a version that is not yet installable. It is now —
v2026.9.6.4published, four platform payloads plus a sealedmcpp-release.json200with identical sizes (no localgtctop-up needed)xim-pkgindex#774exactly["latest"]lines, all naming 2026.9.6.4Publish Index Artifactgreen on the index's main — the layer xlings actually consumesThe review
.agents/docs/2026-09-07-round6-ecosystem-review.mdrecords the round: what SPEC-004's target axis changed, the six criteria and how each was measured, and the two defects the implementation turned up.The core criterion is not a build. The two axes coincide on a native build, so "the example still builds" carries zero information about the difference. It is measured instead by parsing one manifest against two different resolved targets — doable on one machine with no cross toolchain. Removing the wiring turns five of the seven assertions red; the two that survive are the host-axis regression assertions, which is what they are there for.
Two defects found while implementing:
build.mcpp. Now refused. e2e 619 measures both sides: on the previous engine that same project builds.mcpp-plugins' C-library check selected itsbuild.ninjaby glob order over fingerprint-named directories, so it read a graph written the previous day by the version before the fix it exists to guard. Fixed in mcpp-plugins#5.Sandbox verification
.agents/docs/2026-09-07-round6-verify.shagainst the published binary inverify-964: six sections, zero failures. Section B is the load-bearing one — it first reads that the sandbox registry does not holdxim:shaderc, then has the target axis install it. On any machine that has built the package before, the payload is already there and the answer is the same whether the axis was read or not, which is exactly where this round's engine defect had been hiding.