The control-plane side of the pull API (implements sharang/werkbank#6), so a
Werkbank runner can reach a real queue end-to-end:
- POST /api/v1/werkbank/jobs/{lease,heartbeat,complete} — thin handlers over the
JobQueue (WB-02), tenant-scoped from the request's `tenant` (db_pool
.for_tenant_id). lease→204 when empty; heartbeat→409 on a lost lease.
- Machine auth: a static WERKBANK_RUNNER_TOKEN bearer (require_runner_token),
mounted only when the token is set — like the admin API, and NOT a Keycloak JWT
(a runner acts across tenants). /api/v1/werkbank/* is added to the JWT
PUBLIC_PREFIXES so it routes to the runner-token gate, not the customer-JWT one.
- On completion, the runner's findings + DAST findings are persisted against the
job's target (dedup'd by fingerprint), so a job run by a remote runner lands
the same findings an in-process run would.
- Shared transport types (LeaseRequest/HeartbeatRequest/CompleteRequest/
CompleteResponse) live in compliance-core so the runner (client) and control
plane (server) agree on shapes.
Tests: 3 HTTP integration tests against a live Mongo (lease→complete→persist,
empty-queue 204, and the bearer-token gate) + a token-compare unit test. Skips
cleanly with no Mongo. clippy + fmt clean.
Follow-up: wiring the scan pipeline to enqueue plc-provision jobs needs an
artifact-fetch path for the runner (so it can pull the program blob); tracked
with the on-prem work.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>