Follow openkal 0.8, and record why the five new interfaces are absent (#8)

* ci: 把引导阶段绑定指名的 glibc 载荷装给它(过渡步骤)

`xim:glibc` 的 `latest` 从 `2.44` 移到了 `2.44.2`。载荷目录按请求**解析成**的版本
命名,而 RuntimeBinding 带的是**声明的**版本 —— 而一个已发布的 mcpp vendor 进自己
沙箱的那份 xlings 仍然声明 `2.44`。于是干净机器装出 `2.44.2`,工具链 fixup 要
`2.44`,构建在编译任何东西之前就停住:

    error: selected RuntimeBinding glibc@2.44 requires payload
           '.../xpkgs/xim-x-glibc/2.44', but it is not installed

⚠️ 在每一台**新**机器上出现,在任何已存在的机器上都不出现 —— 所以开发机看不见。
索引的 `pkgs/g/glibc.lua` 把这次失败逐字记着,并给出规则:
「The index is DATA and the client is a PROGRAM: the consumer ships first。」

## ⚠️ 我先试过 bump xlings,撤回了

把 `XLINGS_VERSION` 提到 2026.8.27.1 会让**沙箱里那份** xlings 被换掉
(mcpp 的 `acquire_xlings_binary` 在 pin 前移时更新它),绑定于是**前移**到
`glibc@2.44.2`,而已经装好的是 `2.44` —— 请求比已装的**更新**。那是更糟的一侧:
接受一个更旧的载荷去回答更新的请求,等于静默用上索引明说
「IT IS NOT THE ONE TO INSTALL」的那份(带 mcpp#484 的 preload 缺陷)。

⇒ 保持 xlings 不动,把缺的那个载荷直接装上。

⭐ 待 mcpp 2026.8.27.1(mcpp-community/mcpp#515)发布后移除:它接受
「版本精化了请求」的已装载荷,从它引导就不需要这一步。

* Follow openkal 0.8, and record why the five new interfaces are absent

This machine provides none of them, and each absence has a reason rather than
being an omission: no network for net and datagram, no memory management unit to
copy an address space with for space, no second execution context to bound a wait
against for timeout, and a console whose settings the firmware does not expose for
terminal.

Clause 6.1 makes an interface an implementation does not provide absent at the
link, so a program requiring one is refused when it is built rather than when it
runs. The README states this beside the reasons already recorded for fs, process
and task, so that a reader asking why finds the answer where the other answers
are.

* examples: name openkal the way this repository does

mcpp refuses a graph in which one package reaches a dependency by version and
another by git:

    dependency 'mcpplibs.openkal' is requested as both a version dep (by 'hello')
    and a git dep (by 'mcpplibs.openkal-<this>@path'). Pick one.

That is the right refusal --- two forms can name two different trees --- and it
means an example inside a repository must follow that repository's own
declaration while a change spanning repositories is in flight. The example named
a released version while the package beside it followed a branch.

* Name the released specification and the released engine

openkal 0.8.0 is published and resolvable from the index, so the manifest names
it by version rather than by branch --- including the example's, where a branch
would hand a reader a reference that moves.

The engine pin moves to mcpp 2026.8.27.1 and the repository variable
MCPP_SOURCE_REF is cleared, so what this repository tests is the engine a user
installs.

---------

Co-authored-by: speak-agent <x.d2learn.org@gmail.com>

Author: Sunrisepeak

.github/workflows/ci.yml

@@ -19,7 +19,7 @@ jobs:
     runs-on: ubuntu-24.04
     timeout-minutes: 40
     env:
-      MCPP_VERSION: 2026.8.26.2
+      MCPP_VERSION: 2026.8.27.1
       XLINGS_VERSION: v2026.8.17.2
       XLINGS_NON_INTERACTIVE: '1'
     steps:
@@ -70,6 +70,34 @@ jobs:
             echo "the index has not caught up yet (attempt $attempt of 6); waiting 60s"
             sleep 60
           done
+          # ⚠️⚠️ TRANSITION: GIVE THE BOOTSTRAP THE glibc ITS BINDING NAMES.
+          #
+          # `xim:glibc`'s `latest` moved from `2.44` to `2.44.2`. A payload
+          # directory is named after the version a request RESOLVED to, while a
+          # RuntimeBinding carries the version that was DECLARED — and the xlings
+          # a released mcpp vendors into its own sandbox still declares `2.44`.
+          # So a clean machine installs `2.44.2`, the toolchain fixup asks for
+          # `2.44`, and the build stops before anything is compiled:
+          #
+          #     error: selected RuntimeBinding glibc@2.44 requires payload
+          #            '…/xpkgs/xim-x-glibc/2.44', but it is not installed
+          #
+          # ⚠️ On every NEW machine and on none that already existed, which is why
+          # it is invisible from a developer's own. Measured on `main` as readily
+          # as on any branch — the index records the same failure verbatim in
+          # `pkgs/g/glibc.lua` and states the rule it broke: "The index is DATA
+          # and the client is a PROGRAM: the consumer ships first."
+          #
+          # ⭐ REMOVE THIS once a released mcpp resolves it. `mcpp 2026.8.27.1`
+          # accepts an installed payload whose version REFINES the requested one
+          # (`payload_dir_for_version`), so a bootstrap from it needs nothing
+          # here. Until then the missing payload is simply installed.
+          if [ -x "$HOME/.mcpp/registry/bin/xlings" ]; then
+            XLINGS_HOME="$HOME/.mcpp/registry" XLINGS_NON_INTERACTIVE=1 \
+              "$HOME/.mcpp/registry/bin/xlings" install glibc@2.44 -y -g \
+              >/dev/null 2>&1 || true
+            echo "glibc payloads present: $(ls "$HOME/.mcpp/registry/data/xpkgs/xim-x-glibc" 2>/dev/null | tr '\n' ' ')"
+          fi
           mcpp --version
           mcpp self config --mirror GLOBAL
           # ⭐⭐ CROSS-VALIDATION: BUILD THE mcpp UNDER REVIEW AND USE THAT ONE.
@@ -206,7 +234,7 @@ jobs:
       run:
         shell: bash
     env:
-      MCPP_VERSION: 2026.8.26.2
+      MCPP_VERSION: 2026.8.27.1
       XLINGS_VERSION: v2026.8.17.2
       XLINGS_NON_INTERACTIVE: '1'
     steps:
@@ -267,6 +295,34 @@ jobs:
             echo "the index has not caught up yet (attempt $attempt of 6); waiting 60s"
             sleep 60
           done
+          # ⚠️⚠️ TRANSITION: GIVE THE BOOTSTRAP THE glibc ITS BINDING NAMES.
+          #
+          # `xim:glibc`'s `latest` moved from `2.44` to `2.44.2`. A payload
+          # directory is named after the version a request RESOLVED to, while a
+          # RuntimeBinding carries the version that was DECLARED — and the xlings
+          # a released mcpp vendors into its own sandbox still declares `2.44`.
+          # So a clean machine installs `2.44.2`, the toolchain fixup asks for
+          # `2.44`, and the build stops before anything is compiled:
+          #
+          #     error: selected RuntimeBinding glibc@2.44 requires payload
+          #            '…/xpkgs/xim-x-glibc/2.44', but it is not installed
+          #
+          # ⚠️ On every NEW machine and on none that already existed, which is why
+          # it is invisible from a developer's own. Measured on `main` as readily
+          # as on any branch — the index records the same failure verbatim in
+          # `pkgs/g/glibc.lua` and states the rule it broke: "The index is DATA
+          # and the client is a PROGRAM: the consumer ships first."
+          #
+          # ⭐ REMOVE THIS once a released mcpp resolves it. `mcpp 2026.8.27.1`
+          # accepts an installed payload whose version REFINES the requested one
+          # (`payload_dir_for_version`), so a bootstrap from it needs nothing
+          # here. Until then the missing payload is simply installed.
+          if [ -x "$HOME/.mcpp/registry/bin/xlings" ]; then
+            XLINGS_HOME="$HOME/.mcpp/registry" XLINGS_NON_INTERACTIVE=1 \
+              "$HOME/.mcpp/registry/bin/xlings" install glibc@2.44 -y -g \
+              >/dev/null 2>&1 || true
+            echo "glibc payloads present: $(ls "$HOME/.mcpp/registry/data/xpkgs/xim-x-glibc" 2>/dev/null | tr '\n' ' ')"
+          fi
           mcpp --version
           mcpp self config --mirror GLOBAL
           # ⭐⭐ CROSS-VALIDATION: BUILD THE mcpp UNDER REVIEW AND USE THAT ONE.

README.md

@@ -43,6 +43,16 @@ application is the only thing running, and an interface provided in part would
 be worse than one provided not at all — `import openkal.process;` does not
 resolve, which is the honest answer rather than a set of calls that always fail.
 
+The five interfaces version 0.8 adds are absent by the same rule. UEFI has no
+process model to copy an address space within, so `space` is not provided; no
+second context to bound a wait against, so `timeout` is not; and while Boot
+Services do expose a network stack, this backend forwards only the protocols
+listed above, so `net` and `datagram` are not. `terminal` is absent because
+`SIMPLE_TEXT_OUTPUT_PROTOCOL` has no mode to read or set.
+
+Clause 6.1 makes each absence a link-time absence, so a program requiring one of
+them is refused when it is built rather than when it runs.
+
 ## The three places this is not forwarding
 
 **Text.** openkal streams carry bytes; UEFI's console takes UCS-2 and treats a

examples/hello/mcpp.toml

@@ -11,5 +11,15 @@ target  = "x86_64-windows-gnu"
 ldflags = ["-nostdlib", "-Wl,--subsystem,10", "-Wl,-e,efi_main"]
 
 [dependencies]
-openkal = "0.7.0"
+# ⚠️ THE FORM MUST MATCH THE ONE THE IMPLEMENTATION USES, not merely the
+# version. mcpp refuses a graph in which one package reaches a dependency by
+# version and another by git:
+#
+#     dependency 'mcpplibs.openkal' is requested as both a version dep
+#     (by 'hello') and a git dep (by 'mcpplibs.openkal-uefi@path').
+#
+# That is the right refusal --- two forms can name two different trees --- and
+# it means an example inside a repository follows that repository's own
+# declaration while a change is in flight.
+openkal = "0.8.0"
 openkal-uefi = { path = "../.." }

mcpp.toml

@@ -15,7 +15,7 @@
 [package]
 namespace   = "mcpplibs"
 name        = "openkal-uefi"
-version     = "0.1.3"
+version     = "0.2.0"
 description = "An implementation of openkal on UEFI Boot Services, for applications the firmware loads before an operating system exists"
 license     = "Apache-2.0"
 
@@ -32,7 +32,7 @@ authors     = ["mcpplibs"]
 repo        = "https://github.com/mcpplibs/openkal-uefi"
 
 [dependencies]
-openkal = "0.7.0"
+openkal = "0.8.0"
 
 [build]
 flags = [