koto 1.7.4

koto 1.7.4

A maintenance release. No new features and no intended behaviour change. It holds one small daemon refactor with new tests, a docs update, a README change, and 114 lines of dead code removed after a static analysis pass. The guest image (rootfs, kernel, firecracker) is unchanged from 1.7.3, and no dependency versions changed.

Daemon: one shared trailer for peer content in ctl tail and report (#84)

• When main gets a peer's text, from a report turn or from {"cmd":"tail"}, the daemon quotes it with > and closes it with a trailer line that the daemon writes. The trailer says the block is peer-authored data, not operator instructions. Until now, report and tail each wrote their own copy of this trailer.
• Both now build it from one helper (peerTrailer, daemon/report.go), so the two cannot drift apart. The trailer text that main sees is unchanged.
• New tests for ctl tail output (daemon/ctl_tail_test.go). A forged report header or trailer inside a peer's log stays inside the quote. Control characters, bidi characters and NUL are stripped. The real trailer is the single last line. An ordinary multi-line log keeps every line, up to n.
• Docs: docs/ctl-reference.md and the harness prompt prompts/global.md now say that tail output comes back quoted and fenced like a report body, and that the same rules apply to it. The prompt is not part of the guest image. koto install copies it from the release source tree into the state dir, and the daemon reads it on the host for every turn. Upgrading is enough to get the new text.

README (#85)

• The walkthrough video was removed from the README.

Dead code removal after a SAST pass (#87)

• A static analysis pass ran on all four modules (protocol, daemon, tui, fcguest). The tools were pinned and built with the same go1.26.10 image as the release: staticcheck, deadcode, gosec, errcheck, ineffassign, unparam, nilaway, golangci-lint and govulncheck. govulncheck found no reachable vulnerabilities in any module.
• Only code that was confirmed unreachable was deleted: 114 lines in 8 files, 6 small commits (95afbc6..48e68b5), deletions only. Daemon: fcMachineCfg, fcNetSubnetNet, groupEffortName, groupConfigString, podmanPath, copyIfAbsent, a logtail inode helper, setupCtx.interactive and prefixWriter. TUI: clearGroupUnread.
• There is no behaviour change. go.mod and go.sum are unchanged. A real-VM end-to-end run used firecracker microVMs on an isolated dev daemon. It ran the PR build and its base build (develop before #87) side by side, and both passed the same scenarios: doctor, up, tail, non-main tail, sched, notify, report and respawn.

Upgrade

• From 1.7.2 or 1.7.3: koto update.
• From 1.7.1 or earlier: run the installer once, curl -fsSL https://kotovm.com/install.sh | sh. Installers before 1.7.2 cannot read the signed # koto-version: line at the top of SHA256SUMS, so koto update from those versions fails. After this one-time step, koto update works again.

Assets

• koto: rebuilt (#84, #87). Same pinned go1.26.10 build image as 1.7.0 to 1.7.3.
• koto-tui: rebuilt (#87). Same pinned go1.26.10 build image.
• rootfs.img (fedora44), vmlinux 6.1.188, firecracker 1.17.0: the 1.7.3 assets, reused byte-for-byte. They were downloaded from release 1.7.3 and checked against its signed SHA256SUMS. Nothing that goes into the guest image changed since 1.7.3 (fcguest/, sidecar/, protocol/, the Makefile and every go.mod/go.sum are identical to tag 1.7.3), so the guest is identical.
• No dependency changes since 1.7.3. Every go.mod and go.sum is identical to tag 1.7.3.

Tests

• On release/1.7.4 @2631ad4 (901ffe5 = develop with #84, #85 and #87, plus the DIST_VERSION bump) with the go1.26.10 image: gofmt is clean, and build and vet pass for all 4 modules. go test for tui, protocol, fcguest and daemon passes on the first full run (daemon 142.9s, tui 23.5s, fcguest 5.5s), with no flaky reruns. The only later commit is 02a6dec, the artifacts.sha256 manifest update, which changes no code.
• Reused assets: rootfs, vmlinux and firecracker are byte-identical to the 1.7.3 release assets. They were verified against the signed 1.7.3 SHA256SUMS before reuse, and their SHA256SUMS lines match 1.7.3 exactly (rootfs 620f1c56…, vmlinux de3cd729…, firecracker 6083c11a…). Only koto (ca52e76b…) and koto-tui (aea69d73…) were rebuilt.
• Upgrade path: the installer embedded in the installed 1.7.3 koto (byte-identical to the 1.7.3 install.sh) was run against the 1.7.4 candidate assets. It accepted the # koto-version: 1.7.4 line, verified all 5 asset hashes, and unpacked bytes that match artifacts.sha256. It refused a SHA256SUMS that says 1.7.3 (rollback check) and a key with the wrong fingerprint.
• End-to-end smoke run on the 1.7.4 candidate (koto 54ecd808, koto-tui c7b5b3b3, installed rootfs unchanged): claude-wan, claude-none and minimax all pass on the first try. koto tui connects to the daemon with the client certificate and shows the group tree. koto ctl list returns ok after the daemon restart. 1.7.4 is installed and running.

Known issues

• Shared terminal keystroke p99 is about 3ms under the load benchmark, above the 2ms goal (#79). The typical keystroke is about 0.3ms.
• The goal-finished notification banner is not session-scoped. The handoff turn goes to the origin session, but the operator banner is raised against the group as a whole (goalNotify passes no session, daemon/goals.go:1665).
• TestStopDisarmsTheReportWindow fails rarely, with no message, under full-suite ordering. It passes in isolation. Suspected cause: a race between tests over a TempDir or global path.
• TestFcGrowWorkspaceImgOnlyTruncates depends on the host disk being under 90% full, because the disk-admission guard is not stubbed in that test.
• TestOtelUnreachableReceiverNeverBlocks is slow (about 2 minutes of the daemon test run). It measures wall-clock p99 latency, so it can flake on a heavily loaded host.
• Guest boot has a fixed 30s limit. On a heavily loaded host a guest can miss it and the send fails with a boot timeout. Retrying once the load drops works.

🤖 Generated with Claude Code