Build GitHub issue-to-Task intake with webhook verification

[labgadget015-dotcom]

Roadmap item 5/10 · Workstream: Workflow Automation · Risk: High · Approval required: Yes · Target milestone: M2 — Governed intake

Objective

Turn GitHub issue events into validated Task records through a verified intake: HMAC over the raw body, delivery de-duplication, schema validation, and an explicit routing decision, replacing ad-hoc filtering in the Event Router.

Non-goals

• Processing pull-request or push events (separate issue)
• Running the DRC council on every task
• Storing raw webhook bodies

Acceptance criteria

• HMAC-SHA256 verified over the exact raw bytes (never a re-serialised body); constant-time compare; missing/invalid signature → 401 and an audit event
• Test suite includes a valid-signature 2xx and a retired-secret 401 — an all-negative suite does not count
• Duplicate X-GitHub-Delivery is a no-op (Implement correlation IDs, idempotency, and structured audit events #319)
• Payload mapped to the Task schema (Define canonical domain schemas and event envelope #318); invalid payloads rejected with a recorded reason
• Routing decision (ignore / task / needs-approval via Implement approval-policy evaluation and human-gate workflow #321) recorded with the matched rule; bot-sender and label rules made explicit and tested
• Health pings remain exempt but cannot create Tasks

Dependencies

• Define canonical domain schemas and event envelope #318
• Implement correlation IDs, idempotency, and structured audit events #319
• Implement approval-policy evaluation and human-gate workflow #321

Risk

High — this is the public ingress; verification bugs are security bugs, filtering bugs silently drop work.

Test evidence required

• Signed-fixture tests (valid, tampered body, wrong secret, missing header, replay)
• Read-only ping delivery verified end to end with the HMAC recomputed locally
• Routing table tests for human vs [bot] senders and the drc-review label

Definition of done

• Intake live with verification on; one real issue produces one Task with a correlation ID
• Rejections visible in audit events and alertable (see observability item)
• Runbook for secret rotation (all three locations) referenced
• Evidence URL and Correlation ID recorded on the project item