Sharang ParnerkarandClaude Fable 5
420af3af9e
CI / Check (pull_request) Successful in 5m35s
CI / Detect Changes (pull_request) Has been skipped
CI / Deploy Agent (pull_request) Has been skipped
CI / Deploy Dashboard (pull_request) Has been skipped
CI / Deploy Docs (pull_request) Has been skipped
CI / Deploy MCP (pull_request) Has been skipped
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>