Today — the README's "What TestBackend cannot see" table says output printed outside the framework — "a println!, a logger, a panic" — is visible to termlens and assertable with s.contains("panicked"); skills/termlens/SKILL.md §1 makes the same promise. Measured on 0.10.1: no fixture in fixtures/ ever panics, and grep -rn 'panicked' crates/termlens/tests/*.rs finds only an absence check (inspect.rs asserting the example did not panic). Nothing tests that a panicking child's message reaches the grid.
Why it is worth fixing — a documented capability with no test, and it is the one users reach for when their TUI dies in CI: the panic goes to stderr, which is the same terminal, so the message should land on the screen once the alternate screen is torn down. If that is not exactly what happens, the README is overclaiming and this test is how we find out.
Fix — give fixtures/emit a --panic MESSAGE step (it is the fixture with a step language, so a whole new fixture is unnecessary), then add a test in crates/termlens/tests/process.rs that spawns it, waits for the message on the grid, and asserts the exit status a panicking Rust process actually produces.
Write down what you observe, not what you expect. If the message does not survive the teardown, that is the finding, and the README should be corrected instead of the test bent to pass.
Done when
A good first contribution: one file, no architecture decisions. Start with
CONTRIBUTING.md
— §1 lists every gate you can run locally, and §3 asks that a change land
with a test. Commits are Conventional Commits and need git commit -s
(DCO). Happy to review a draft PR early.
Today — the README's "What
TestBackendcannot see" table says output printed outside the framework — "aprintln!, a logger, a panic" — is visible to termlens and assertable withs.contains("panicked");skills/termlens/SKILL.md§1 makes the same promise. Measured on 0.10.1: no fixture infixtures/ever panics, andgrep -rn 'panicked' crates/termlens/tests/*.rsfinds only an absence check (inspect.rsasserting the example did not panic). Nothing tests that a panicking child's message reaches the grid.Why it is worth fixing — a documented capability with no test, and it is the one users reach for when their TUI dies in CI: the panic goes to stderr, which is the same terminal, so the message should land on the screen once the alternate screen is torn down. If that is not exactly what happens, the README is overclaiming and this test is how we find out.
Fix — give
fixtures/emita--panic MESSAGEstep (it is the fixture with a step language, so a whole new fixture is unnecessary), then add a test incrates/termlens/tests/process.rsthat spawns it, waits for the message on the grid, and asserts the exit status a panicking Rust process actually produces.Write down what you observe, not what you expect. If the message does not survive the teardown, that is the finding, and the README should be corrected instead of the test bent to pass.
Done when
A good first contribution: one file, no architecture decisions. Start with
CONTRIBUTING.md
— §1 lists every gate you can run locally, and §3 asks that a change land
with a test. Commits are Conventional Commits and need
git commit -s(DCO). Happy to review a draft PR early.