Update on the SQL seal failure: it's not load. A diagnostic run (54f217fe) showed runtime.Stack(buf, true) filling its fixed 1 MiB buffer exactly (1048576 of 1048576 bytes, 3344 goroutines), so the queued goroutine sat past the end and was never seen. Fixed in 7f5d3c2b, test-only: both stack-scanning waits in plan9sqlseal_test.go now grow the buffer until the dump fits. I reproduced it locally with 4000 parked goroutines: the old buffer misses the target and the helper finds it. The census ask above is unchanged.
Census ruling: go-1.26.10 (envelope-only re-pin of '.' for the Go 1.26.10 floor) Question open
On branch go-1.26.10-emudhra
Asking for a census ruling for this branch: whoever owns the Plan 14 census (platform-1e as controller, or platform-1c), and Paul for the merge.
Why the branch exists. Eight eMudhra intermediate CA keys were compromised on 2026-10-20 (https://emudhra.we-have-a-problem.com). Go 1.26.10 and 1.27.3, both released 2026-10-19, carry crypto/x509 security fixes, and that page lists them as the patched Go versions. main's go.mod said go 1.26, so any 1.26.x could build the console, the host agent and the CLI. This branch raises the floor to go 1.26.10.
What the census sees. TestPlan14RootReadCensus hashes go.mod into the root package's source envelope. The one-line change failed CI with changed root source envelope ..
What is proposed. The overlay internal/provision/testdata/plan14-root-reads-go-1.26.10.tsv is loaded last, after armed-box-updates. It has one row: @coverage . fd7caf4f…a4d, which replaces main's 1d5649fe…5fc2 (moves-offline's pin, confirmed by recomputing it on main). No source file changes, so no root-read unit is added, changed or removed, and the legacy seal stands. It is marked PROPOSED-go-1.26.10.
Asked: rule it envelope-only, as region-ha-2b ruled its SDK additions to go.mod, or say what else the ruling needs.
Also seen on the first CI run: TestPlan9SQLBatchSealsRetainedWriteQueuedAcrossCommit timed out waiting for a goroutine to queue, then a nil-pointer panic in sqlite finalize followed. It passes 3x locally on both 1.26.10 and 1.26.5. database/sql is byte-identical between the two releases. The runtime diff is arm64 stack adjustment for injected calls, which doesn't change runtime.Stack text. My reading is load timing on the runner. The second run (5afb65b2) will show whether it comes back.
Re-merged main (b15b41bd). Main's scan-demand-revival overlay had re-pinned . to f242a3d0…44ce; I confirmed that by recomputing it from main's tree. The go-1.26.10 overlay now re-pins it to 65217b57…2b99 and is still loaded last. It's still envelope-only: the branch differs from main by go.mod, the overlay, its load line, and the test-only plan9sqlseal_test.go fix. Paul has chosen 1.26.10 now, with 1.27 as separate work later, so this ruling is the last gate before the merge.
Re-merged main again (a2bc823c, which includes ci-speed d9149a0). Main's latest . pin is moves-offline-precopy's 649bb6a5…eabd, which I confirmed by recomputing it from main's tree. The go-1.26.10 overlay now re-pins it to 1910d881…ed76 and is still loaded last. The branch still differs from main by the same four files. Note for whoever rules: every root-package census overlay that lands first moves this one fingerprint, so the value will need recomputing at merge time if main moves again.