[itswl]

Dependabot's three grouped PRs (#15 hookprobe, #16 hookjudge, #17 hookrelay) as one change, the way #11 did it. A bot PR edits requirements.txt but cannot regenerate requirements.lock from the venv the gate ran against, so merged as authored it fails the lock check.

The bot's edits, as proposed: fastapi>=0.149.0 for the pipe and the judge, ruff==0.17.1 for all three. The investigator's fastapi floor is lower and the bot left it alone; it stays locked at 0.141.1.

fastapi is locked at 0.161.1, above the bot's floor, as the last two rounds took the newest. FastAPI published sixteen releases between the locked 0.146.0 (10-18) and 0.161.1 (10-22 22:22 UTC, thirteen minutes before the bot ran). Each is a tagged release on its own repository, published by its release workflow and matching the PyPI upload one to one. PyPI's provenance endpoint answers 404 for every fastapi wheel, including the one locked before, so it carried no signal either way.

Two advisories published since the last lock, found when the first gate run went red at pip-audit. Every service carried both, and so does main:

package	advisory	what	reaches us via	lock
certifi	PYSEC-2026-4320	the bundle before 2026.10.18 trusts a root whose intermediates had their private keys compromised	httpx, requests	2026.7.22 → 2026.10.19
opentelemetry-api	CVE-2026-114603	the tracestate parser costs quadratic CPU on one crafted header	fastapi (pipe, judge), mcp (investigator)	1.45.0 / 1.44.0 → 1.45.1

Both fixes are the newest releases, match tagged upstream releases, and are lock-only: neither package is named in a requirements.txt.

Gate: the second run is STACK GATE GREEN, the two image builds included; ruff 0.17.1 found nothing new. CI read back before merging. Nothing to deploy: the work stack is stopped, and the pipe's and the judge's images take the new fastapi at their next build.