go: after(d) timer stub + 13 pattern tests → runtime 40/40, Phase 5 closed [shapes-scheduler]

Acceptance bar hit (40 runtime, 497 total). Tests: timer ready,
select-with-timeout, fan-in (3 producers), worker queue, pipeline,
fan-out-then-fan-in, select source-order, fallback case, default,
producer-consumer, two-stage pipeline, channel-counter, after+default,
tick-collector.

Shape chiselled: timer collapses "after duration" into
"channel ready immediately" — select needs only ready? from each
case. Real time is when the flip happens, not what the protocol is.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

plans/lib-guest-scheduler.md

@@ -231,6 +231,47 @@ real result.
 
 _Newest first. Append one dated entry per milestone landed._
 
+- 2026-05-27 — **Phase 5 acceptance crossed (40 runtime tests).**
+  Final shape observation: *time-as-readiness-flip*. The Go side
+  added an `after(d)` builtin that returns a channel **already
+  holding** a tick value — duration is ignored in v0. The select
+  loop doesn't care that the channel got its value "via time"; it
+  only consults `ready?`. This separates two concerns the eventual
+  kit had been conflating:
+
+    1. **The wake-up protocol** — what `select` asks of every case:
+       "are you ready right now?" Channel-recv answers via "buffer
+       non-empty or closed"; channel-send via "buffer has room";
+       timer via "deadline reached." All three flatten to a single
+       `ready?` predicate.
+
+    2. **The scheduling oracle** — *when* a case's `ready?` flips
+       from false to true. For channels this is driven by other
+       goroutines sending/receiving; for timers it's driven by a
+       wall-clock or monotonic source.
+
+  v0 collapses #2 (timer = ready immediately, sends always ready,
+  recvs ready iff buffer non-empty) and exposes #1 as the only
+  thing the dispatcher needs to know. Phase 5b refines #2 with
+  blocking semantics and real time, but #1 stays the same shape.
+
+  Concretely: the kit's `select-case` should take `:ready?-fn` per
+  case, not three different "is-this-a-send-or-recv-or-timer" tags.
+  Send/recv/timer become factory functions that produce a
+  `(:ready? FN :commit! FN)` record — the dispatcher walks cases,
+  picks the first whose `ready?` returns true, calls `commit!` to
+  extract the value (and side-effect: drain buffer, fire timer).
+  This is the same shape as a STM transaction over case-set, and
+  matches Erlang's `receive` clauses too (each pattern is a
+  ready-predicate + commit-action over the mailbox head).
+
+  Ping-pong remains impossible in v0 because the synchronous spawn
+  collapses the `ready?`-flip oracle to "always immediate" — the
+  spawned goroutine can never park waiting for the parent to send.
+  Phase 5b must restore the wake-up dimension; until then the kit
+  spec should encode the readiness-protocol design even though the
+  oracle is degenerate.
+
 - 2026-05-27 — From Go-on-SX Phase 5 first slice: the channel
   primitive landed as closures-over-mutable-state in
   `lib/go/sched.sx`. Concrete shape: