the measured graph moves onto the wave, now that its runtime is published (#450)

`tests/openkal/pins.toml` moves to openkal-llvm-runtime 0.13.0, which was
registered and published in the preceding change. That version pins
openkal-musl 0.18.0, which pins openkal-linux 0.15.0, openkal-windows 0.10.0
and openkal-macos 0.12.0 --- the first graph in which ALL THREE
implementations declare which interfaces of the layer they provide.

WHY THAT MATTERS TO A MEASUREMENT AND NOT ONLY TO A BUILD. Below this pin a
member's `[kernel-abi] requires-interfaces` was answered on two of the three
implementations and silently unanswered on the third: openkal-macos carried no
array, and mcpp treats a provider that states nothing as stating nothing
rather than as providing nothing. A measurement taken there records "builds"
for a member whose requirement nothing checked.

`mcpp` moves to 2026.9.20.1 because the set difference being measured is what
that release added, and openkal-compat.yml's pin moves with it --- that
workflow fails the run when the two disagree. validate.yml moves too: an index
that lints itself with an engine ten releases behind validates against
something no user runs.

`latest_mcpp` moves. `min_mcpp` DOES NOT, and the reason is recorded beside
it: both new manifest keys are top-level tables an older engine ignores, and
all 231 descriptors parse with 2026.9.18.3, so the descriptor grammar this
floor governs did not change. Raising it would take the whole index from every
client below it for a diagnostic note they merely would not receive.

THE BASELINE THIS REPLACES, from the preceding run on the old graph: 60
member-target results, 50 pass (47 of them `runs (posix)`), 10 fail --- four
on `windows.h` reached through the borrowed `__CYGWIN__`, two on
`__cxa_thread_atexit`, two on `linux/` uapi headers, one `arc4random_buf`, one
`curl_off_t`. The first two groups are known and recorded; this move is what
lets the next run be compared against them.

Author: Sunrisepeak

.github/workflows/openkal-compat.yml

@@ -33,7 +33,7 @@ env:
   # run if this drifts from pins.toml. See the comment beside `mcpp` in
   # pins.toml for why this pin, not just validate.yml's, is gated by the
   # index floor.
-  MCPP_VERSION: "2026.9.18.3"
+  MCPP_VERSION: "2026.9.20.1"
   XLINGS_NON_INTERACTIVE: "1"
 
 jobs:

.github/workflows/validate.yml

@@ -301,7 +301,7 @@ env:
   # is a cold one (mcpp's build-cache epoch moved from 2 to 3 in this same
   # release, because the old cache key did not cover the realised [c-abi]
   # environment).
-  MCPP_VERSION: "2026.9.18.3"
+  MCPP_VERSION: "2026.9.20.1"
 
 jobs:
   lint:

index.toml

@@ -79,7 +79,26 @@
 # raising the floor was gated on the engine, not on those two packages, and
 # gating on both at once would have held this raise hostage to something it
 # does not need.
+# ── 2026-09-20: latest_mcpp -> 2026.9.20.1, min_mcpp DELIBERATELY UNCHANGED ──
+#
+# That release adds two manifest keys, `[kernel-abi]` and `[c-abi-absent]`, and
+# neither asks anything of this floor. mcpp IGNORES a top-level table it does
+# not know and REFUSES an unknown MEMBER of a table it does know; both keys are
+# top-level, so a client stopped at 2026.9.18.3 loads the manifests carrying
+# them and loses only the check.
+#
+# Measured, not assumed. The absence table was first written as
+# `[c-abi].absent`, and the published 2026.9.18.3 archive refused openkal-musl's
+# whole manifest on every target with `[c-abi] has no member 'absent'`; moved to
+# the top level, that same published binary builds it, and openkal-musl's own CI
+# pins 2026.9.18.3 and is green on 0.17.0 and 0.18.0. All 231 descriptors parse
+# with 2026.9.18.3 as well, so the DESCRIPTOR grammar --- what this floor
+# actually governs --- did not change either.
+#
+# Raising it would cost every client below the floor the WHOLE index (E0006 at
+# the index-open choke point) for a diagnostic note they merely would not have
+# received.
 [index]
 spec        = "1"
 min_mcpp    = "2026.9.18.3"
-latest_mcpp = "2026.9.18.3"
+latest_mcpp = "2026.9.20.1"

tests/openkal/pins.toml

@@ -4,7 +4,7 @@
 # `runtime` is the C++ runtime for openkal; it pins openkal-musl exactly, and
 # openkal-musl selects the openkal implementation for each target, so this one
 # version names the whole graph.
-runtime   = "0.12.0"
+runtime   = "0.13.0"
 toolchain = "llvm@22.1.8"
 # `mcpp` here moves together with index.toml's `min_mcpp` and
 # .github/workflows/openkal-compat.yml's own MCPP_VERSION (that workflow
@@ -18,7 +18,25 @@ toolchain = "llvm@22.1.8"
 # index requires mcpp >= 2026.9.18.1 but this is mcpp 2026.9.17.3 [E0006]"
 # before a single line of the member's own source is read.
 #
-# `runtime` MOVES HERE NOW, AND UNTIL IT DID THE WINDOWS LEG MEASURED A GRAPH
+# 2026-09-20: `runtime` -> 0.13.0, THE FIRST GRAPH IN WHICH EVERY IMPLEMENTATION
+# DECLARES ITS INTERFACES. It pins openkal-musl 0.18.0, which pins
+# openkal-linux 0.15.0, openkal-windows 0.10.0 and openkal-macos 0.12.0 --- the
+# last of those is the release that closed the gap. Below it a member's
+# `[kernel-abi] requires-interfaces` was answered on two of the three
+# implementations and silently unanswered on the third, and a measurement taken
+# there records "builds" for a member nothing had checked.
+#
+# 0.13.0 WAS REGISTERED AND PUBLISHED BEFORE THIS LINE MOVED, in a separate
+# change. Moving both at once fails EVERY member at once: `compat.py` gives each
+# copied member an `[indices] compat = { path = <this checkout> }` so a changed
+# DESCRIPTOR is measured, and that serves resolution but not INSTALLATION, which
+# is delegated to xlings and reaches only the repositories it has synced. Since
+# the runtime pin is in every member's manifest, a version that exists only in
+# this checkout fails all of them, and the failure reads as a compatibility
+# result rather than as a missing registration.
+#
+# (the note below is from the previous move, and its reasoning still holds)
+# `runtime` MOVED, AND UNTIL IT DID THE WINDOWS LEG MEASURED A GRAPH
 # WITH NO `[c-abi]` IN IT. openkal-llvm-runtime 0.12.0 (openkal-musl 0.16.0,
 # openkal 0.14.0) is the first pinned graph in which a package declares the
 # block, so it is the first in which mcpp realises `presents = "posix"` at all:
@@ -33,7 +51,7 @@ toolchain = "llvm@22.1.8"
 # openkal-musl 0.16.0 and openkal-llvm-runtime 0.12.0), because a pin that
 # moves onto an unreachable or divergent asset fails every member at once and
 # reports it as a compatibility result.
-mcpp      = "2026.9.18.3"
+mcpp      = "2026.9.20.1"
 
 targets = ["x86_64-linux-gnu", "x86_64-windows-gnu"]