Three help/output tests pass or fail depending on import order and TERM, never in CI

Start with tests/conftest.py and pyproject.toml, then run the three named tests in tests/test_diffusion.py and tests/test_cache_cli.py under different TERM values and import orders. Make test rendering deterministic and ensure the cache assertion is not affected by ANSI styling; done means the tests pass in isolation and in the full suite.

Three tests assert on literal substrings of rich-rendered output. Whether they pass
depends on the environment and on which test files ran before them, so locally they
produce phantom failures that look like a regression from whatever you just changed. CI's
environment happens to satisfy all three, so they are green on every PR and invisible
there.

Found while working on #344, where they cost a bisect to disprove twice.

Reproduction

On main at 2a4f9e1, each test run in isolation:

Test	TERM=xterm-256color	TERM=dumb
test_diffusion.py::TestRepoListCli::test_the_url_alias_is_hidden_from_the_help	fail	pass
test_diffusion.py::TestUriEditIoCli::test_the_help_lists_the_values_phorge_takes	pass	fail
test_cache_cli.py::TestInfo::test_mentions_accounts_cached_under_another_token	fail	pass

No single local TERM passes all three in isolation.

It is also order-dependent. The second one:

$ TERM=dumb uv run pytest tests/test_diffusion.py::TestUriEditIoCli::test_the_help_lists_the_values_phorge_takes -q
1 failed

$ TERM=dumb uv run pytest tests/test_diffusion.py -q
1 failed, 346 passed

$ TERM=dumb uv run pytest -q
1965 passed

Bisecting what makes it pass in the full run:

$ TERM=dumb uv run pytest tests/test_agent_help_footer.py <that test> -q
42 passed

Cause

Two separate ones.

The two help tests: TYPER_USE_RICH is set too late to be reliable

phabfive/cli/__init__.py:12:

os.environ.setdefault("TYPER_USE_RICH", "0")

That only takes effect if it runs before typer is imported. Under pytest it often does
not: several test modules do from typer.testing import CliRunner at module scope, so
whether typer renders help as plain text or through rich depends on collection order.
tests/test_agent_help_footer.py imports phabfive.cli early and leaves
TYPER_USE_RICH=0 in os.environ for the rest of the session, which is why the full
suite behaves differently from a single file.

Forcing it settles both tests, independent of TERM:

$ TYPER_USE_RICH=0 TERM=dumb uv run pytest <test_the_help_lists_the_values_phorge_takes> -q
1 passed
$ TYPER_USE_RICH=1 TERM=dumb uv run pytest <same> -q
1 failed

$ TYPER_USE_RICH=0 uv run pytest <test_the_url_alias_is_hidden_from_the_help> -q
1 passed
$ TYPER_USE_RICH=1 uv run pytest <same> -q
1 failed

When rich does render the help, the two fail for different reasons, which is why no single
TERM fixes both:

• test_the_url_alias_is_hidden_from_the_help looks for --show-uris, and rich splits it
  across style boundaries: '\x1b[1m …'. Colour off makes it match.
• test_the_help_lists_the_values_phorge_takes passes env={"COLUMNS": "200"} to
  CliRunner on purpose — the comment says "Wide enough that rich prints the help rather
  than eliding it". Under TERM=dumb rich ignores that and falls back to 80, the --io
  row is elided, and default, observe, mirror, read, readwrite, none is simply not in
  the output.

The cache test: asserting on a colourised number

test_mentions_accounts_cached_under_another_token asserts:

assert "1 other cached account" in result.stdout

but _display_rich builds its own Console(), which colourises the count:

This host has \x1b[1;36m1\x1b[0m other cached account, written under a
different token and not counted above.

NO_COLOR=1 does not fix this one — only TERM=dumb does, so the env var is not
reaching that Console:

	result
NO_COLOR=1	fail
TERM=dumb	pass
NO_COLOR=1 TERM=dumb	pass

Suggested fix

1. Make TYPER_USE_RICH deterministic under test rather than dependent on import
   order — set it in tests/conftest.py before anything imports typer, or via pytest's
   env in pyproject.toml. That fixes both help tests at the source and removes the
   order dependence, so a single-file run and a full run agree.
2. Stop asserting on colourised text. Either strip ANSI before the assertion, or have
   the test build the console with colour off. Given the intent is the sentence and not
   its styling, stripping in the test reads best.

Neither is urgent — nothing here is a product bug, phabfive itself behaves correctly in
all these cases. The cost is purely that a local pytest run cannot be trusted, which is
exactly when you most want to trust it.

🤖 Generated with Claude Code