GATE B, STRESS. Phase 2, 28 July 2026, re run at phase close so the whole bundle
is one measurement of one commit rather than a scrapbook of runs taken at
different times. Instrument: tools/verify/stress. Target: missionmatch_staging on
M4:5432, 2,766 organizations. The tool REFUSES to run against a database named
missionmatch, because it creates and destroys rows.

EVERY PROFILE'S POSITIVE CONTROL RAN FIRST AND FAILED AS REQUIRED.

  RACE CONTROL. The first planted defect simply removed FOR UPDATE and the run
  still produced one winner, because the timing did not happen to interleave.
  That proved the harness ran, not that the assertion can catch a second winner,
  and a control that only sometimes manifests is itself an instrument that
  passes by doing nothing. The defect was made DETERMINISTIC by removing the
  already claimed guard, so every racer claims and the exactly one winner
  assertion is put under real pressure. It elects 8 of 8 every time:
      race n=8 winners=8 (want exactly 1)
      positive control OK: the planted defect was DETECTED

  LOAD CONTROL, an unmeetable p95 target of 1ns:
      load samples=30156 rps=1005 p95=10.524ms p99=12.466ms errors=0 target=1ns
      positive control OK: the planted defect was DETECTED

  SOAK CONTROL, the same:
      soak samples=61742 rps=1029 p95=10.136ms p99=12.214ms errors=0 target=1ns
      positive control OK: the planted defect was DETECTED

COUNTED RUNS

  CONCURRENCY, the protocol asks for 8 AND 32 on every lock guarded transition:
      race n=8   winners=1  PASSED
      race n=32  winners=1  PASSED

  LOAD, 30 seconds, 8 workers:
      samples=30583  rps=1019  p95=10.402ms  p99=12.646ms  errors=0
      targets p95<300ms p99<800ms zero errors: ALL MET

  SOAK, 60 seconds at the same shape:
      samples=61329  rps=1022  p95=10.273ms  p99=12.526ms  errors=0
      Latency is flat between the load and soak runs, p95 10.402 to 10.273,
      which is the stability the soak profile exists to observe.

  Measured p95 is roughly 29 times inside the 300ms target at about a thousand
  reads per second sustained for a minute, with no errors.

A SECOND HARNESS DEFECT BELONGS IN THE RECORD. The pool was smaller than the
racer count, so the profile deadlocked and looked exactly like the contention bug
it exists to find. MaxConns is now deliberately larger than any racer count used
here, and the reason is written at the line that sets it.

SCOPE LIMIT, STATED RATHER THAN GLOSSED. The load and soak profiles measure the
DATABASE path, not authenticated HTTP. Driving the hot routes with real sessions
per role needs seeded fixture accounts for every role, which is Gate C fixture
work that does not exist yet for Phases 3 onward. Quoting a database read as an
end to end request latency would inflate the number every time it is repeated
later. Measuring what can honestly be measured today, and saying so, is better
than reporting an HTTP number produced by a harness that logged in as nobody.

ALSO PROVEN, at Gate A but concurrency shaped: eight racing promotions of one
requirement draft while an ingest loop rewrote the underlying notice 29 times
produced exactly ONE requirement with a named reviewer.