test(project): tell == 'false' from != 'true' on an evidence output (#967)

[JarryShaw]

• Searched for similar pull requests
• Followed the coding style (make pylint, make mypy, make isort)
• make test passes, and a test case covers the change
• Added a changelog entry under docs/source/changelog/ and regenerated CHANGELOG.md, if the change is user-visible — N/A — centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

What is the purpose of your pull request?

• fix — corrects a defect
• feat — adds a feature
• perf — changes performance, not behaviour
• refactor — changes neither behaviour nor performance
• test — tests only
• docs — documentation only
• ci — workflows or build tooling
• chore — anything else

---

Description of your pull request and other information

Closes #967. gate_rows grows one row per gated job holding that job's own evidence output at the
module's existing NULL, on a non-v ref with version_check at success, and asserts the gate
skips — the only shape on which == 'false' and != 'true' disagree, and != 'true' is the
dangerous direction: it runs where == 'false' skips, so unknown evidence becomes a publish attempt.

Applying == 'false' → != 'true' to a scratch copy of each real condition (the workflow file is
untouched), violations before → after this PR:

job	evidence output	evaluator	text
tag	PCAPKIT_CONDA_TAG_EXISTS	0 → 1	0 → 0
pypi	PCAPKIT_PYPI_COMPLETE	0 → 1	0 → 0
conda	PCAPKIT_CONDA_COMPLETE	0 → 1	0 → 0

One row per job, resolved from GATE_EVIDENCE[job]; the mutation joins MUTATIONS as evaluator-only
and fails on exactly that new row. github does not have the hole — version_check published no outputs at all holds every output at null with version_check.result still success, so its
evidence clause alone decides that row, now pinned by a test since it is a property of the row.
Reachability is stated rather than overclaimed: the row guards a future change, not a present bug —
neither curl-based check can emit an empty output under set -euo pipefail, but
PCAPKIT_TAG_EXISTS/PCAPKIT_CONDA_TAG_EXISTS come from mukunku/tag-exists-action@v1.7.0 and
tag's gate reads one. Nothing is weakened; row counts go 17/17/21 → 18/18/22.

[JarryShaw]

GOOD TO GO at fe869656a — fable cross-review, first round clean. Different
model from the author (opus).

It found a second weakening the row closes, and I verified both sides. Beyond
== 'false' → != 'true' from #967, the mutant
(<evidence> == 'false' || <evidence> == '') — admitting an empty string — also
escaped the tables as #966 left them:

PRE-PR  (e1262ed4a):  tag/pypi/conda  evaluator=0  text=0   <- survived
POST-PR (fe869656a):  tag/pypi/conda  evaluator=1  text=0   <- caught
row counts: 17/17/21 -> 18/18/22

So this is a family of absent-evidence weakenings, not a single mutation.

Four mutants do survive both layers — contains(fromJSON('["false"]'), …), a
redundant always-true conjunct, == 'False', and == fromJSON('"false"'). All
four are semantically equivalent in Actions (array contains is loose-equality
membership; string comparison is case-insensitive, which the evaluator deliberately
mirrors). A truth-table layer cannot catch an equivalent mutant by construction, so
they are not held against this PR.

Also confirmed independently: no existing row was weakened — the first 17/17/21
rows are identical in name, context and expectation, the new one is a pure append,
and both polarities are still required. And a typo'd unknown= name fails loudly
rather than passing a vacuous row.

One incidental confirmation: a malformed mutant of mine made the evaluator raise
UnsupportedExpression rather than quietly return falsy — the fail-vacuously path
#966's review worried about is genuinely closed.