Wave protocol let a red main be pushed: a sibling-attributed failure is still a failure

[ssamba1]

WHAT

HEAD (wave 7) shipped untell/scripts/run.py in a state where every call to untell_text raised
NameError. The --inspect work added inspect: bool = False to the public wrapper and used
inspect inside _untell_text, but never added it to _untell_text's signature nor passed it at
the call site.

The defect is not the missing parameter. The defect is that it reached main at all: the package's
central entry point was dead and the suite stayed green.

EVIDENCE

On HEAD, before the fix:

$ git show HEAD:untell/scripts/run.py | grep -c 'if inspect else None'      # body uses it
1
$ git show HEAD:untell/scripts/run.py | sed -n '/^def _untell_text(/,/^) -> dict:/p' | grep -c inspect
0                                                                            # signature lacks it
$ git show HEAD:untell/scripts/run.py | grep -A4 'result = _untell_text(' | grep -c inspect
0                                                                            # call site lacks it

Reproduced by accident while generating an HTML report — an unrelated slice:

File "C:\Users\Admin\Humanize\untell\scripts\run.py", line 1073, in _untell_text
    inspect_events: list[dict] | None = [] if inspect else None
NameError: name 'inspect' is not defined

WHY THE SUITE MISSED IT

untell_text is monkeypatched or stubbed in most tests (see the holdout tests, the batch tests, the
manifest tests — all inject a fake loop). Tests that DO drive the loop appear to go through the CLI
or through higher-level wrappers that were not exercised in the fast path. A function can be
completely dead and every green test stays green.

This is the repo's own catalogued class — Result 146's dead-stub finding and Result 179's
"an adapter missing one attribute would break score_text" — arriving at the top-level entry point.

ACCEPTANCE

• inspect threaded (owned by the --inspect slice; fix is in flight).
• A smoke test that CALLS untell_text for real (no monkeypatch) on a short document, for each
  supported tier reachable without a download, asserting it returns and that final is a str.
  It must call the real function — a stubbed loop cannot catch this class.
• The same smoke test parametrised over the boolean feature flags (inspect, timings,
  scrub, polish) so a future flag added to the wrapper but not threaded fails immediately.
• Verified by breaking it on purpose: remove a parameter from _untell_text, see the smoke test
  go red, restore.

[ssamba1]

Correction — the premise of this issue is false, and I wrote it

I claimed "no test calls the core entry point end-to-end" and that the suite could not have caught
the dead untell_text. Both claims are wrong. Verified rather than assumed:

$ git worktree add --detach /tmp/w7-52 f0ccf32~1      # the broken commit
$ UNTELL_LITE_NO_TORCH=1 pytest -q -m 'not slow' tests/test_an_inert_budget_says_so.py
FAILED tests/test_an_inert_budget_says_so.py::test_it_reaches_a_real_run - NameError
FAILED tests/test_an_inert_budget_says_so.py::test_an_ordinary_run_stays_clean
2 failed, 13 passed in 2.34s

That file calls untell_text for real, is in the FAST set, runs in 2.3 seconds, and predates the
defect (added in 232205d; git cat-file -e f0ccf32~1:... confirms it existed before the P0 fix).
Several other files do the same with no monkeypatching.

So the coverage existed and it fired. Writing the smoke test this issue asks for would have added a
redundant test and left the actual defect in place.

What actually happened

The tests went red and the red was correctly attributed to sibling churn. From the slow-test
triage slice's own report, during the wave:

Three test_cli.py failures are NameError from a sibling agent modifying untell/scripts/run.py
— not ordering issues.

That agent was right about the cause, right to not touch a file another agent was mid-edit in, and
right by its brief. The consequence was that main stayed broken and was pushed anyway, because in a
20-agent wave a red test is indistinguishable from ordinary concurrent churn — and nothing re-checked
main from a clean checkout afterwards.

The defect is in the wave protocol, not in the test suite. My post-wave sweep ran only the wave's
NEW test files, and ran after the fix had already landed, so it could not have caught this either.

Revised acceptance

• Verify the existing coverage fires against the broken commit — done above.
• Wave protocol: a red test attributed to a sibling must be REPORTED to the orchestrator, not
  merely noted in a report nobody reads until the wave closes.
• Wave-close gate: run the fast suite from a CLEAN checkout of origin/main — not the working
  tree, which is exactly where this check fools itself — before the wave is declared closed.
• The gate must run the whole fast suite, not just the wave's new files.

Retitling accordingly. No smoke test will be added; the honest fix is the process one.