index.toml

# Index→client version contract (design: mcpp .agents/docs/2026-07-08-index-
# version-semantics-and-descriptor-grammar-design.md D3). The contract travels
# WITH the index tree: packed into the artifact, present in git checkouts and
# path-indices alike. mcpp >= 0.0.85 checks it at the index-open choke point
# (E0006 on violation). Bump min_mcpp ONLY together with the CI MCPP_VERSION
# pin — lint parses descriptors with the pinned mcpp, which enforces the
# "floor first, new grammar after" rollout rule mechanically.
#
# ── 2026-08-30: raised 2026.8.3.3 -> 2026.8.27.2, with the CI pin ──────────
#
# The rule above says to move this only together with MCPP_VERSION, and that is
# what this is: validate.yml has pinned 2026.8.27.2 for some time while this
# contract still claimed 2026.8.3.3, so the two had drifted apart and the floor
# was advertising support nobody tested.
#
# It was not merely untested, it was FALSE, and measurably so. Two independent
# reasons, both reproduced against this index:
#
#   * 2026.8.3.3 silently ignores `runtime.link_library_dirs` (the key does not
#     exist in that binary at all) yet still reports `parse OK`, so
#     `compat.libgbm` resolves, builds, and then dies at link:
#         libdrm.so.2, needed by .../libgbm.so, not found
#         undefined reference to `drmGetVersion'
#     A silently-ignored key is invisible to the lint, which is why the
#     "floor first, new grammar after" guard did not catch this: the guard
#     assumes unknown keys are REJECTED, and `runtime.*` subkeys are not.
#
#   * 2026.8.10.3 does not get that far. It cannot bootstrap against this index
#     at all:
#         error: selected RuntimeBinding glibc@2.44 requires payload
#                '<store>/xim-x-glibc/2.44', but it is not installed
#     which is the compiled-in-runtime-binding defect mcpp's own
#     src/xlings/xlings.cppm documents as the reason it floors xlings at
#     2026.8.27.2. Every client below that line is already broken here,
#     for reasons that predate any package in this index.
#
# So E0006 is strictly better than what those clients get today: a clear
# refusal at the index-open choke point instead of an undefined reference or a
# missing payload three layers down. 2026.8.27.2 is the version this index is
# actually tested against, and now the contract says so.
#
# ── 2026-09-18: raised 2026.8.27.2 -> 2026.9.18.1, with the CI pin ─────────
#
# 2026.9.18.1 is the mcpp release that understands `[c-abi]` (design:
# openkal/.agents/docs/2026-09-18-openkal-c-environment-and-personalities-
# design.md §3.2; plan: the sibling 2026-09-18-c-environment-execution-plan.md
# §5, step 1) and has entered xim-pkgindex (step 2). Per the rule at the top
# of this file, this moves together with `.github/workflows/validate.yml`'s
# `MCPP_VERSION`, in this same commit.
#
# This raise on its own changes nothing observable: no descriptor in this
# index declares `[c-abi]` yet, and mcpp's own release notes state that a
# package which does not declare the block gets the same command line, byte
# for byte, as before. Verified here, not merely asserted: every descriptor
# in pkgs/*/*.lua still parses with `mcpp xpkg parse` under 2026.9.18.1.
#
# ── 2026-09-18: raised 2026.9.18.2 -> 2026.9.18.3, with both CI pins ────────
#
# 2026.9.18.3 is the release whose c-abi probe on a Windows host × freestanding
# target stops mismatching on _WIN32 (host strip) and __SIZEOF_WCHAR_T__
# (realisation always emits -fno-short-wchar on freestanding). The probe's
# measurement contract is unchanged (design §3.2: a declaration is checked,
# never trusted); the realisation's previous "freestanding skips the wchar
# flag" rule was the actual bug, the wave's measurement is what caught it.
# A floor at 2026.9.18.2 would let a 2026.9.18.2 user be refused builds the
# next release accepts. Per the rule at the top of this file, this moves in
# the same commit as validate.yml's `MCPP_VERSION`; openkal-compat.yml's
# `MCPP_VERSION` moves with tests/openkal/pins.toml's `mcpp`, which that
# workflow checks for agreement.
#
# openkal-musl 0.15.0 and openkal-llvm-runtime 0.11.0 (plan step 3) -- the two
# packages that will actually declare and consume `[c-abi] presents =
# "posix"` -- are NOT registered by this raise. Neither has a version number
# or a sha256 yet; `pkgs/o/openkal-musl.lua` and
# `pkgs/o/openkal-llvm-runtime.lua` carry a note beside their version tables
# marking exactly that, and this index has no data to put in an xpm entry for
# either until the other agent handling their release reports the tag and
# hash. Registering them is plan step 4, a separate change from this one:
# 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.21.2"