User test cases

What a person actually drove for each feature, on what hardware, and what those runs found.

Every feature and every release records the cases a person actually drove, and what those runs found. Written down here, not in a chat log and not only in a commit message.

The reason is narrow and evidence-backed: the tests in this repo are good at what they were written for and blind to what nobody thought of, and almost every expensive bug in Rux so far was found by a person using the thing rather than by CI. Touch spent releases half-built because there was no hardware here; it broke within a minute of a phone opening the playground. A swipe was unreachable on any element that also declared a drag, and the suite was green through all of it. As mobile approaches this gets worse, not better, because the gap between what the machine here can exercise and what a user's device does is about to widen.

How to use this file

One section per feature or release. For each, the case as a person would perform it, on what hardware, and the outcome. A case that found something is worth more than a case that passed, so record those first and say what changed.

State the hardware explicitly. "Works" on a desktop with a mouse says nothing about a phone, and this document exists to stop that sentence being written.

An unverifiable case is recorded as unverifiable, with the reason. A gap that is written down is a gap someone can close; a gap that is assumed to be covered is the one that ships.

Write the cases before the release, not after it. Standing rule as of 2026-08-19. Every capability a release adds gets its cases written here while it is being built, pointing at what the new thing can now do, so there is a list for a person to drive before the release goes out rather than a record assembled afterwards from what happened to be tried. A case written afterwards only ever documents what somebody thought to look at; a case written up front is the thing that gets looked at.

The cases below are therefore a mix: outcomes where the run has happened, and open where it is waiting for a person. Open cases are release-blocking in the sense that shipping with them untouched is a decision, not an oversight.

v0.7

Lifecycle hooks, per instance (2026-08-17)

setInterval (2026-08-17)

Component computed and effect (2026-08-18)

Nested routes (2026-08-18)

The pointer vocabulary (2026-08-18)

Enter, leave and route transitions (2026-08-18/19)

Everything here is new in v0.7. The first five were driven and each one found something; the rest are written for a person and are open.

<path>, vector geometry (2026-08-19)

New in v0.7 and added mid-milestone at the user's request. Driven in the window the same day, once the screen was unlocked. Three of the first four cases found a bug, none of which the 615 passing tests had an opinion about, and two of the three stopped something dead rather than making it slightly wrong.

One example flaw worth recording separately, because it was authoring and not the engine: the chart was written 480 logical pixels wide and the default window is narrower, so it ran off the right edge. A drawing does not resize with its box, deliberately, which means a fixed-coordinate path has to be written to fit.

Slow motion, and what it exposed (2026-08-19)

Read a measurement's floor before believing what it says. Sampling a band that both halves of a crossfade occupy cannot tell a departure from an arrival: peak brightness there is the greater of the two, so the departing page appears to end the moment the arriving one passes it. Two of the readings in this table were taken that way, and one of them was written up as an open bug that had already been fixed. Give each half its own colour channel, or read the value the animator wrote rather than the pixel it produced.

This is the fourth time this project has shipped a rule that applied to only half of what it claimed (rem honored by half the box model, a swipe made unreachable by a drag, decorations drawn outside their transform, and now the cascade). Every one of them was silent, and every one was found by a person looking rather than by the suite.

Recipes (2026-08-19)

Every recipe was driven in the window before its page was written, which is the point of writing them: three defects came out of three ordinary patterns.

position, all four values (2026-08-19)

Asked directly whether the limit could be lifted instead of embraced. It was not a limit, it was four silent wrong answers and a divergence nobody had noticed.

Route guards (2026-08-19)

The playground against the v0.7 candidate (2026-08-19)

Driving the site locally while building an app against the v0.7 candidate.

Settled the same day, by the user: local builds track the tip, CI builds track the tag. site.yml had said the playground runs the last release "so it demonstrates what /learn and /reference describe instead of unreleased work". That reasoning holds for /learn, which tracks releases, and was false for the other two: /reference/ is generated from docs/05-as-built.md, which describes the tip, and /recipes/ tracks the tip by design.

site/build-playground.sh is now the one implementation of the build. --from-tag is what CI passes, so the deployed site still shows what a visitor can install; a developer running it bare gets the tip, so the recipes they are writing run in the playground beside them. The two modes cannot drift on anything except the flag, which is the point of there being one script.

Two things the script does that the inline CI step did not: it reads wasm-bindgen's version out of the lockfile of the tree being built (under --from-tag that is the tag's lockfile, not main's, and an older tag can resolve an older wasm-bindgen), and it confirms the emitted binary actually carries the version it was asked to build. A wasm-bindgen step that silently reuses a stale --out-dir is otherwise indistinguishable from a successful one, which is the exact confusion this whole arrangement exists to end.

"The whole file" was not the whole file (2026-08-19)

Driving the message-list recipe in the playground on the v0.7 bundle. The user's read was that the output "isn't what a desktop window would give us".

Why it stopped being a nit. It was a documentation imprecision for as long as a fence was something you read. It became a defect the day every fence grew a Copy button and a Try it link: both hand the fence straight to the playground, so a reader copying "the whole file" gets an unstyled screen that looks exactly like a broken renderer.

Fixed: site/sync-examples.sh fills any fence marked <!-- FROM: <path> --> from that file, --check fails on drift, and gate_docs_synced runs it. The examples are already under test, so a hand-copied second version on the page was a copy of tested code that nothing tested. Same drift this repo has now been bitten by three times: the extension's void-tag list, the site's grammar copy, and this.

Method note. The window capture walked straight into the trap [[driving-the-window-headlessly]] already records: a $hwnd named $h collides with a -H height parameter, because PowerShell variable names are case-insensitive. The window was sized to the handle value and clamped to 65535 tall, and the capture "succeeded".

Writing a real app against the 0.4.0 extension (2026-08-19)

The user built a WhatsApp-shaped header in their own workspace, which is the first time the extension has been driven by someone writing Rux rather than by its own tests. Four findings, none of which any test had an opinion about.

All four fixed.

• Snippets are served from the completion provider, filtered by section, and a test asserts every one is placed. The contributes.snippets entry is gone.
• ScriptError carries rhai's position; extract_imports now leaves a blank line where it strips a use so the numbers still line up (it dropped the line before, shifting everything below by one); Document::load_checked adds Sfc::script_line, which had existed and never been read by anything. The mapping refuses to place a position past the end of the document's own script, because past that point the compiled text is appended component functions and a confident wrong number is worse than none.
• explain is applied to load errors, so it reads "there is no function signal taking 0 arguments" at 12:19.
• The editor scans the document for let / computed / fn, ranks those above everything the runtime provides, and offers them in <script>, in {{ … }}, in :bound attributes and in handlers. An r-for row variable comes with them. After a ., an element handle from query() offers its own members and everything else offers the string and array methods.

An open design question for the user, not a defect: signal() with no argument is an error. signal("") is the fix and the message now says so, but whether an empty signal() should mean an empty value is a call worth making rather than leaving to whoever hits it next.

Seen once and not reproduced: one cargo test run reported 1 failure in a 12-test suite, and seven subsequent runs of the same combination were clean. Not diagnosed. The warning sinks are process-wide and check_file already clears them for exactly that reason, so a parallel-run race is the suspicion and not more than that.

The extension never activated (2026-08-20)

Found while the user was driving the 0.4.x extension in their own app. Six rounds of "the fix does not work" against code that was demonstrably correct when called directly.

activationEvents was absent from package.json, and had been since 0.3.0, the version published to the Marketplace. With no activation event VS Code never calls activate(), so completions, hover, diagnostics, formatting and every command lived behind a function nothing invoked.

Why it stayed hidden for three versions: the declarative contributions need no activation. The TextMate grammar coloured every file, and contributes.snippets answered completions from a static JSON list. Together those look exactly like a working, if thin, extension. The user's first report this session, "no CSS completions, just script/signal/slot/sticky", was that static snippet list being the only thing answering. Removing the static snippets in favour of a section-aware provider took even that away, which is why the symptom got worse right after a fix that was correct.

The lesson is about the evidence, not the bug. Every check that was run (unit tests, driving the provider through a stand-in for the VS Code API, inspecting the installed files on disk) tested code that was never reached. The one check that would have caught it was asking whether activate() ran at all. A provider verified in isolation says nothing about whether the editor calls it.

Also fixed in the same pass, all found by the user:

Method note, recorded because it cost the most. Editing JavaScript through a shell heredoc turned  in a regex into a literal backspace (U+0008) three separate times. The file parsed, the regex compiled, and it matched nothing. editors/vscode/test/sources.test.js fails on any stray control character now.

Three extension symptoms still open at 0.4.8 (2026-08-20)

Left open deliberately rather than closed on an assumption. The user reports, after a confirmed 0.4.8 install: component tags still coloured as elements, length still showing the query() text, and no hover on a declared variable.

None of the three reproduces here. Driven through the registered providers against the user's own file, search_item hovers as a signal holding an array, length reads from the value methods, and the grammar scopes <side-panel> as a component and <view> as an element.

The clue worth starting from: the component colour is pure TextMate grammar. It needs no activation, no binary, and no provider. A grammar change failing to land while a behavioural one apparently lands says the editor is not loading the artifact that was installed, and points away from the features entirely.

Ruled out along the way, each having been a genuine cause earlier: activationEvents absent since 0.3.0; a same-version reinstall not replacing a running extension; an uninstall leaving its directory behind; and a stale rux on PATH overriding the extension's vocabulary per field.

What this cost, and why: more than six rounds of "the fix does not work" against fixes that were real. Every verification ran against the working tree or an isolated provider call, and neither is what the editor loads. No evidence was ever collected from the user's side until a diagnostic command was written, far too late. scripts/dev-install.sh now rebuilds the binary, regenerates the vocabulary, bumps the version, wipes the old install and reinstalls in one step, and --check reports whether the four moving parts agree.

The three extension symptoms, all closed (2026-08-20)

The first of the three above is closed, and the answer rules out the theory the entry above it was built on.

The grammar had been scoping component tags as entity.name.tag.component.rux since 0.4.8, and that is a correct, distinct TextMate scope. It was reaching the editor the whole time. A theme resolves a scope through its prefixes, and no stock theme has ever heard of .component, so every one of them matched the entity.name.tag rule underneath and painted <header/> exactly the colour of <screen>. In Abyss, the theme in use, both came out #225588.

So the artifact was loading. The distinction existed in the grammar file, in the crate's scope table, and on the website. It existed nowhere on screen, in the one place it had been asked for.

Components are now scoped support.class.component.rux, which is what Vue and Svelte use and what themes colour on its own.

Why every test passed through this. rux-highlight resolves a scope by longest matching prefix in its own table, where entity.name.tag.component duly beat entity.name.tag. Rux's renderer and a VS Code theme resolve the same scope by opposite rules, so the crate's tests could not have caught it and the site was genuinely right the whole time. There is now a test that reads the grammar directly and refuses a component scope that begins with the element scope, whatever either happens to be.

The other two, and they were one bug. No hover on a declared variable and no completion of one had the same cause, found by sweeping hover across every offset of the user's real files rather than sampling a few: declarations() returned nothing at all on either file.

The three declaration patterns in locals.js are anchored with $. In JavaScript, $ without the m flag matches at the end of the string or before a final newline, and never before a carriage return; . does not match one either, so the lazy group in the let pattern could not step over it to reach the anchor. The section body was split on the newline alone, so every line of a CRLF file arrived with a carriage return still on it and not one declaration in the file matched. Completion offered only the globals, hover answered nothing on a name the author had just typed, and no error was raised anywhere. .rux files on Windows are CRLF, which is to say this was the normal case and not an edge of it.

The outline kept working throughout, and that was the tell nobody read: it scans with /m and no $, so it was the one feature the carriage return could not reach.

Why the whole suite passed. Every fixture in it was written in a JS string literal with . A fixture set that only spells documents one way cannot test the way the users' documents are actually spelled. test/line-endings.test.js now runs declarations, inference, completion, hover and loop scoping over the same document in both endings, and asserts the two agree; six of its cases fail without the fix.

And the verification was worse than the bug. This session reported the two as not reproducing, on the strength of a harness run that normalised the endings away: a string replace meant to disable that normalisation silently did not match, the output looked the same as the run before it, and it was read as proof. An unasserted edit to a test harness is not evidence. The instruction is now: reproduce from the user's file bytes, and assert that the bytes under test are the bytes on disk.

A second lying instrument, found on the way. dev-install.sh --check reported 0.4.8 installed while VS Code was running 0.4.9. It listed the extensions directory and took the first entry, and an install leaves the previous version's directory behind. It now reads VS Code's own extensions.json, and names the leftovers rather than being fooled by them.

Standing gaps

Cases nothing here can currently exercise. They are the shape of what v0.8 has to prove.

• Two or more fingers: reported by the runtime, never yet produced.
• Kinetic scrolling and inertial fling: unimplemented, untestable here.
• The axis claim in full: a @drag claims the finger, but whether a scroll can take it back mid-gesture needs a real screen to have an opinion about.
• Native pickers, safe areas, orientation, density: no device.
• A locked screen captures as pure black. Not a standing gap, but worth knowing: on 2026-08-19 every screenshot came back black until the user unlocked the machine, including one of a known-good example. Run the control before concluding a feature is broken, and if the control is black too, it is the screen and not the code.