Stop the virtualenv check failing a fresh clone's first command

[jehrr]

A fix to a check I added in #17, found by the one thing that keeps finding this class of bug: cloning the published repo the way a stranger does and typing the commands the README gives them.

git clone …; cd polymarket-scraper
python3 -m venv myenv
./myenv/bin/pip install -r requirements.txt
./myenv/bin/python smoke_test.py

The only failure was a check added hours earlier:

1 check(s) FAILED:
  - the virtualenv myenv/ is gitignored

Why the check was wrong, not the clone

It asserted that every directory holding a pyvenv.cfg is gitignored, "whatever its name". That is a promise .gitignore cannot keep — a glob cannot recognise a virtualenv — so the check demanded something no pattern set can satisfy, and greeted a perfectly reasonable first command with a red suite.

That is the failure this suite exists to avoid rather than to cause. A guard somebody has to argue with on their first command is one they learn to suppress, and the next real finding goes with it.

The hard assertion now covers what the project can actually promise: the virtualenv names its own instructions lead people to (.venv, venv, env, and the -engine suffix forms the "one virtualenv per engine" advice produces). An unexpected name gets one line of output instead of a failure:

NOTE  myenv is a virtualenv and is not ignored here. Nothing is wrong with
      it; `git add -A` would just pick it up. Add it to .gitignore, or name
      it .venv.

Two things inside the check that passed for the wrong reason

Both are worth naming, because a green check that cannot fail is the thing this repo keeps being bitten by.

• git check-ignore matches a trailing-slash pattern only against something it can see IS a directory. Asking about a name that does not exist in this checkout therefore answers "not ignored" for every pattern that would in fact cover it — five of the seven names the check had just been written to cover. It probes a path inside the directory now (<name>/pyvenv.cfg).

• git check-ignore skips TRACKED paths by default, and .env.example is tracked. So the assertion that it stays visible could never fail, whatever the patterns said. Caught by planting the fault — commenting out the !.env.example negation — and watching the suite stay green. It passes --no-index now, and with that the same fault turns it red.

Verification

Two faults planted, suite red on a named check for each:

planted fault	caught by
the ignore patterns narrow back to three names	a virtualenv called .venv-playwright/ would be ignored (+2)
.env.example becomes ignored by a too-broad rule	...and .env.example is still NOT ignored

And the scenario that started this: the same fresh clone, same myenv, now green with the note.

Separately — the canary dispatched after #17 merged ran both jobs and passed, so the new cross-engine job is verified on the default branch rather than only written.

🤖 Generated with Claude Code