the measured graph moves onto the wave

.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"]