The directory the helper actually lands in, and a release that reads its own benchmark
Release v2.8.79 repairs one boundary on Windows — a packaged application that starts a helper program inside a package directory now has that directory prepared where the helper can reach it, instead of a spelling that exists only inside the image — and it is the first release whose own conclusion includes the performance covenant's verdict, read from the benchmark run the release dispatched.
The Tebako team
github.com/tamatebakoRelease v2.8.79 has been published. It carries one runtime repair and one pipeline milestone, and both are about the same discipline: a mechanism is finished when the name it answers to is a place that exists.
The directory the helper lands in
A packaged Ruby application sometimes asks the interpreter to start a helper program and to change into a directory inside the package first — the sass compiler’s embedded protocol is the instance that surfaced it, because it spawns its helper with exactly that instruction. On Windows, the runtime prepares the helper’s host copy in a scratch area and applies the directory change against the prepared layout. The preparation computes the scratch spelling from the in-package path, and the computation had a seam: when the in-package path arrives drive-qualified, as the Windows runtime’s paths do, the join that should have placed the twin beneath the scratch root replaced the root instead. The directory change was then aimed at the in-package spelling — a path that exists only inside the mounted image, where no host process can change into it — and the helper never started. The failure was quiet: the caller received an exit status, not an error that named the boundary.
The repair moves the computation onto the flattening rule the download cache has used since its introduction, so the twin’s host spelling is derived the same way everywhere it is prepared. The defect was found by instrumentation rather than by luck: the runtime factory’s Windows acceptance suite includes the Metanorma document toolchain’s HTML-to-XML check, which exercises the sass helper’s spawn; when the check began answering the silent status, a purpose-built rig separated the three cases — a plain spawn, a directory change into a host directory, and a directory change into the mounted image — and named the third as the failing one. Both Ruby lines carry the repair: the runtime pairs in the v0.17.11 line, which publishes on this release, rebuild every series against it.
A release that reads its own benchmark
Every release has dispatched the benchmark suite for some time, and the suite’s covenant — the per-axis budgets the numbers are judged against — has gated the suite’s own fan-in since 2026-11-08, including a proof that an injected breach turns the gate red. What the release pipeline did not do until now is read that verdict into its own conclusion. This release does: its final gate waits for the dispatched benchmark run, reads the covenant’s verdict document, and fails the release on a breach, on a missing verdict, or on a stall past the named bound. The gate’s first live exercise is this release’s own run, which passed on the verdict rather than on the assumption.
The numbers
The platform matrix built and shipped 164 assets, each covered by the published checksums, with the macOS installer legs signed and notarized under the Developer ID pair. The covenant gate read the dispatched benchmark run’s verdict as a pass within its budget window. The spawn repair’s evidence is the runtime factory’s acceptance: the v0.17.11 publish runs the Windows legs' HTML-to-XML check against the repaired materialization, on both Ruby lines.
The upgrade is the usual one. The release page carries every platform’s binaries and their checksums, and an existing installation picks the new line up on its next resolution.