The windows user-state step ran the installed CLI's one-shot chat with its
stdout piped into the evidence log:
& $hermes chat -q "..." 2>&1 | Add-TsPrefix | Out-File $log
A released tag prints through prompt_toolkit, whose create_output() on Windows
returns Win32Output, and that constructor needs a console screen buffer. A pipe
has none, so every windows leg that reached this step died with
prompt_toolkit.output.win32.NoConsoleScreenBufferError:
No Windows console found. Are you running cmd.exe?
HEAD guards its own print path (cli.py's _pt_print_ansi falls back to print),
but the tags under test cannot be changed, so the console has to come from the
rig. tests/install/e2e-assets/pty-run.py runs the command under a pseudoconsole
and captures what the child writes; the driver uses it for that turn, and the
windows job installs pywinpty (the same ConPTY spawner the product uses on
Windows, pinned to the version pyproject requires) for the runner. Without
pywinpty the runner falls back to a pipe and says so in the log, so a missing
dependency degrades the evidence rather than silently changing what the leg
proves.
Verified against a real installed venv on Windows, not just in CI:
- piped stdout reproduces the CI traceback exactly (defaults.py:91 ->
Win32Output -> win32.py:219 raise NoConsoleScreenBufferError);
- under pty-run.py the same print path succeeds for the old CLI's exact call
(print_formatted_text(ANSI(...)) through _cprint), and the capture is clean.
6f8f8e695a