Examine the optional interfaces, which nothing did

.github/workflows/ci.yml

@@ -172,7 +172,20 @@ jobs:
 
       - name: Every interface, every kind of examination
         run: |
-          bash .spec/tools/run-conformance.sh openkal-linux . full
+          # ⚠️⚠️ `optional` IS PART OF THE SET AND WAS NOT, WHICH MADE THE STEP'S
+          # OWN NAME UNTRUE.
+          #
+          # `full` expands to `standard,abi,stability,cost`, and `standard` is
+          # the HOSTED set — core, env, time, fs, process, task. The five
+          # interfaces openkal 0.8 added are in `optional`, and this
+          # implementation provides all of them; without naming that set the
+          # suite compiled their sections with the bodies removed and reported
+          # them as not examined. Nothing failed, and nothing was checked.
+          #
+          # This implementation is the one that may name `optional` entire: it
+          # is the only one providing every interface, which is why it is the
+          # reference. A backend that declines one names the others by hand.
+          bash .spec/tools/run-conformance.sh openkal-linux . full,optional
 
       - name: Point at the specification's working tree
         run: |

src/exec.cpp

@@ -43,6 +43,45 @@ int kal_exec_publish(void* p, kal_uintptr size) {
                                 static_cast<okl_long>(bytes),
                                 okl::prot_read | okl::prot_exec);
     if (okl::failed(r)) return okl::translate(r);
+
+    // ⚠️⚠️ THE INSTRUCTION CACHE IS NOT INVALIDATED HERE, AND ONE OF THE THREE
+    // IMPLEMENTATIONS DOES INVALIDATE IT. THE ASYMMETRY HAS A RULE.
+    //
+    // A processor with separate caches for data and instructions has just had
+    // bytes written through the data path that it is about to fetch through the
+    // instruction path, and nothing in the protection call makes the second path
+    // observe the first's writes.
+    //
+    // ⭐ THE SPECIFICATION PLACES THE MAINTENANCE UPON THE PROGRAM, and the
+    // conformance suite performs it itself and says why: the program is the
+    // party that knows which bytes it wrote. So an implementation that performs
+    // it is being helpful rather than conforming, and one that does not is not
+    // deficient.
+    //
+    // ⚠️ AND THE ONLY MEANS AVAILABLE HERE IS ONE THIS IMPLEMENTATION MAY NOT
+    // USE. `__builtin___clear_cache' expands to nothing on x86_64 and becomes a
+    // CALL into the compiler's support library on the other two architectures
+    // --- `__riscv_flush_icache' on riscv64. This implementation is linked into
+    // programs that carry no other runtime, so acquiring that dependency to
+    // perform an operation the specification does not require of it is not a
+    // trade worth making.
+    //
+    // ⭐⭐ MEASURED, AND NOT ON THIS SYSTEM. openkal-macos added the builtin on
+    // the reading that aarch64 would expand it inline, and its own independence
+    // check reported within the hour:
+    //
+    //     obj/exec.o references a symbol it must not: ___clear_cache
+    //
+    // ⇒ The three implementations share a rule rather than an accident:
+    //
+    //     an implementation performs the maintenance where its environment
+    //     offers it as a CALL of the environment's own --- openkal-windows has
+    //     `FlushInstructionCache' --- and does not where the only means is a
+    //     compiler builtin that becomes a dependency upon the compiler's
+    //     support library.
+    //
+    // All three agree about what the PROGRAM must do, which is what the
+    // specification actually states.
     return kal_ok;
 }