Fix: watch was executing the flags it did not recognise

[0xLeif]

Three defects that surfaced during the last triage but were out of that PR's scope. Each was verified here before being planned.

watch was executing the flags it did not recognise

Anything flag-shaped that watch did not own stayed in the argv and became the command.

My first probe of this was worthless, and worth saying so: a non-tty run refuses on "stdin is not a TTY" before parsing anything, so the refusal was the TTY check and proved nothing about flags. Driven through a real PTY.spawn:

before   rune watch --timeout 5 -- echo hi   ->  exit 127, child never ran
after    rune watch --timeout 5 -- echo hi   ->  exit 1, "--timeout takes its value inline: --timeout=VALUE"
control  rune watch --timeout=5 -- echo hi   ->  exit 0, child ran (unchanged)

run has guarded this since it grew flags. watch never did, which made it the worse of the two — run at least says something. The guard now lives in Command.flag_error and is shared rather than copied: the two had already drifted once, with run growing the inline-value branch and watch having no guard to grow it in.

--grep ignored --since

filter was handed the sliced text and then called transcript.grep, which searched the whole transcript. A read from a cursor recorded after the first line still returned that line, and grep_matches counted it — so a caller paging with --since=<last cursor> got the entire history back on every page, under a count that looked like it had filtered.

--max-output did not bound the separate streams

A 200-byte budget returned 10,506 bytes across four fields, because only clean_output and raw_output went through apply_output_limit. Now 1,012. With neither bound set, the shape is byte-for-byte unchanged.

An adversarial pass found two merge-blockers in this work, and was right about both

The watch guard shipped with no test. Reverting all three guard files left the suite fully green — CI could not distinguish the fix from its absence, including its own headline case. That is the failure this repo cares most about, and I had walked straight into it. Six tests now cover it, including a drift guard and the case it must not lose: a child's own flags surviving.

Moving exports broke the spec contract. unknown_flag_error and INLINE_VALUE_ERROR moved from RunCommand to Command, leaving pty_runner.spec.md documenting things that no longer exist and six new exports documented nowhere. specsync coverage reported two hard errors; both are gone.

It also caught a false claim in my own comment: watch's VALUE_FLAGS said it "cannot drift from the parser" while --log is appended by hand, because its pattern is written inline in scan_head. Corrected to what is actually true.

One reported loss was checked and deliberately left: the guard covers the leading position only, so rune watch echo hi --log=/tmp/x still writes rune's own log to the child's path. Measured byte-identical before and after this change, so it is pre-existing — recorded in watch.spec.md invariant 20 rather than fixed here.

Test Plan

• 584 examples, 0 failures; rubocop clean; docs-check green
• specsync check — 4/4 specs, 31/31 files, 7181/7181 LOC (100%)
• Controls: watch guard reverted → 4 of 33 fail; grep reverted → 1 of 2; stream bounds reverted → 1 of 3
• watch re-verified through a real controlling terminal, not a non-tty stub

One API change worth naming

RunCommand::INLINE_VALUE_ERROR still resolves through inheritance but now carries a second placeholder, so format(..., name:) alone raises KeyError. It was introduced days ago and has never appeared in a tagged release, so the exposure is a caller who took it from main.

🤖 Generated with Claude Code

https://claude.ai/code/session_018rf59AtQmJcodUJ6vXDZNY