v1.7.2

1.7.2 — the Gate BD evidence ships, and the gate checkers run in CI

A patch. No behaviour change and no output change; everything here is evidence,
packaging and test hygiene.

The standing rule is that no finding is published until it is reproduced by a script that
does not import this package. Gate BD's checker satisfied it and lived under gitignored
assets/, so the result was reproducible on one machine and not citable.
examples/phase-d-gate/ is what that looks like done properly for Gate D, and this
mirrors it.

Added

• examples/gate-bd/ — the Gate BD evidence: five databases, the five exports, the
  five scorecards, the per-replicate chaos records, the task file and
  verify_gate_bd.py. An applied duplicate in 3 of 5 replicates against unmodified
  mcp-sqlite@1.0.9 from npm, all five realizing the same fault placement
  (t1:create_record#1=response_lost_then_closed), re-derived from the databases alone.

  178 KB on disk. +22 KB in the sdist and nothing in the wheel — examples/ is
  grafted into the tarball and is not a package, so an install is unaffected.

  The README states without softening what the number does not mean. mcp-sqlite's
  create_record is an INSERT honouring no idempotency key, so every retry duplicates
  whatever the agent sends: this measures the tool's detection, not the agent's key
  discipline. --allowedTools carried create_record alone, withholding read_records —
  so check-before-retry, the only mitigation against a server that honours no keys, was
  foreclosed by the experiment rather than declined by the agent. And the table's schema
  was given in the prompt, because denying the agent its schema lookup aborted the task
  outright on the first attempt at the gate.

  It carries the checker's trust table and does not claim parity with Gate D. Gate D
  partitions one shared ledger by a generation field the twin server itself writes; Gate
  BD has no such field, and relies on a fresh store per replicate plus one behaviour of
  the tool under test — that the scan refuses unless the clean pass applied exactly
  expected_effects.

• The sha256 of each shipped database, in that README, so a reader can confirm a
  shipped copy is the file the gate ran against. Three of the five coincide and two
  coincide, because a SQLite file holding the same schema and rows in the same order is
  byte-identical and replicates with the same outcome produce identical tables. The README
  says so rather than letting five rows imply five fingerprints: the hash proves a file is
  unmodified, it does not identify which replicate wrote it.

• Both gate checkers run in CI, in the verification-tools job. Until now neither
  did. The standing-rule comment on that job names examples/mcp_server_git_repro.py and
  stops there, so verify_gate.py has been in the tree since 1.7.0 and has never executed
  in CI — the two scripts backing the strongest claims in the README were the one class of
  verifier that nothing verified. Measured at 0.048s and 0.049s; stdlib only, no
  network, run with python3 rather than uv run because running them inside the project
  environment would not demonstrate the property they claim.

  A third step asserts the working tree is clean afterwards. The databases are WAL-mode
  and opened mode=ro they create -wal and -shm sidecars beside themselves — measured,
  not assumed — so the checker opens them immutable=1, and the step fails if that ever
  regresses.

Changed

• Six absence-of-PASS assertions tightened, ahead of a verdict-string change queued
  for its own release because it changes recorded output. assert "PASS" not in … is
  satisfied by any verdict beginning with those four letters, so each now names the verdict
  it means: "PASS:" for the three against scorecard output, "PASS score" for the three
  against ci output, whose verdict line carries no colon. Asserting "PASS:" against ci
  output would never match anything and the check would go vacuous, which is worse than the
  loose one it replaced.

• README and docs/LIMITATIONS.md cite both gates and say what each establishes that
  the other does not. Gate D varies the agent's idempotency key against a server that can
  absorb a repeat; Gate BD varies only whether the agent retried at all, against a server
  this project did not write. Neither subsumes the other.

Verification

check	result
suite, mcp 2.1.1 (repo venv, Python 3.12.14)	1557 passed, 7 skipped
suite, mcp 1.30.0 (mcp>=1,<2)	1557 passed, 7 skipped
ruff check	All checks passed
twine check	PASSED, both artifacts
five mock profiles	89 / 89 / 13 / 89 / 89, all exit 0
three agent demos	careful 100 PASS, blind 49 (1 duplicate), optimistic 49 (1 duplicate, 2 unsupported claims)
both gate checkers	exit 0, [1, 0, 1, 1, 0], 0.048s and 0.049s
checker from an unpacked sdist	exit 0, same counts
wheel	0 gate-bd entries, +810 bytes
sdist	34 gate-bd entries, +22,361 bytes (578,112 → 600,473)

Collected 1564 → 1564, unchanged. Proved rather than asserted: git diff HEAD -- tests/ contains no added or removed def test_ or class Test, only assertion bodies —
23 insertions and 6 deletions across two files.

Two failures on the first full run, both the version bump tripping reconciliation gates
that were working: the status line in assets/NextSteps.MD and the README's pasted scan
footer still said v1.7.1. Both updated.