Wayreel: Scripted Demos Across the Wayland Stack

Date: 2026-10-04 Scope: Portfolio review of the Wayreel repository, with recent activity from 2026-08-23 onward. Starting state: A mature Go project with a reel scripting language, a growing issue tracker, and an existing static product website.

Executive summary

Wayreel automates recording and playback of scripted terminal and graphical application demonstrations under Linux's Wayland display system. A .reel describes actions and presentation settings; Wayreel coordinates terminals, applications, a nested Sway compositor, keyboard input and media capture.

During the six-week review window, the repository logged 22 commits. The most instructive recent work paired a declarative dependency check with an external-tool canary: missing commands now fail before reel input begins, while a separately retained experiment established what a smaller terminal-only capture path could deliver. The project has 201 commits overall, 13 Go test files containing 134 test functions, and 31 .reel scripts.

What worked well

Issue 31 documents a concrete failure mode: a reel expected Vim to open, but on a host without Vim, later keystrokes landed in the interactive shell. The fix added a requires field to the reel language and checks for required commands before playback or recording. The implementation spans the parser and schema, lint/preflight behavior, examples and tests. The commit adding the gate wired lint into record/play and added 137 lines of tests (023d821, aa70d53; issue 31). This is a useful example of turning a hazardous assumption into an explicit, inspectable contract.

Issue 37 is a strong canary-first example. Rather than integrating a speculative alternate renderer into Wayreel, the project tested a shell recording rendered with agg and transcoded by FFmpeg, then repeated the experiment with full-screen Neovim. The issue records caveats—such as the lack of Wayreel's key overlay and window chrome—and recommends a separate companion tool rather than changing Wayreel's core. The canary commit touched 24 files and added 1,022 lines (c6075c5; issue 37).

The issue tracker has 38 numbered tickets plus a few unnumbered topic files. Issues 29–38 capture research, design choices, bugs and delivered features, and the index records which experiments completed and what remains open. The checked-in docs/Canary.md describes an explicit mechanism → observation → finding sequence. These artifacts show disciplined use of issues and canaries. The reviewed history does not establish whether advisors, subagents, reverse-sprints or other multi-agent workflows were used, so this review makes no authorship claim.

A concrete episode: proving the smaller path

The script/agg investigation asked whether terminal-only reels could be rendered without Wayreel's nested Wayland compositor. Issue 36 scoped the research, and issue 37 turned one route into a two-stage experiment: a plain shell, then Neovim's alternate screen. Checked-in evidence let the team judge fidelity directly. The path works for tested cases, but lacks Wayreel's full presentation, so issue 38 tracks it as a possible companion tool.

This episode shows how agentic development benefits from repository memory: a ticket defines the question, a canary reduces uncertainty, and evidence supports the decision. It does not prove multiple agents produced the result, but the artifacts make the work reviewable by another developer or agent.

Honest post-mortem and quality audit

The website currently overstates the product: its hero says Wayreel updates READMEs automatically in CI/CD, but this repository contains no README-update implementation or CI workflow. Issue 39 records that discrepancy. This is a product-polish problem and a useful reminder that site copy needs the same grounding as technical documentation.

Efficiency and lessons

The repo is active, with 22 commits in six weeks, including parser/schema work, runtime preflight behavior, docs, demos and evidence-heavy research. Repository facts cannot prove one person could not do this or that agents wrote it. The evidence supports a well-instrumented workflow, not an authorship claim.

Keep external assumptions in canaries, make reel dependencies explicit, and retain evidence with research tickets. For public-facing materials, check every capability claim against shipped code or a maintained integration example.

Facts

File and diff summary

Created this study and issue 39. No application source was changed, and no tests or builds were run for this review. The study was not added to docs/README.md because the requested file scope excludes edits to that existing index.