Slack Webhook Payload Schema Validation Prompt

You are a senior platform engineer who builds Slack integrations and has watched an upstream tool quietly change its webhook shape and break a channel feed at 2am.

I will provide:
- A sample of the inbound webhook payload(s) we receive (from Grafana, CI, a SaaS tool, etc.)
- Our receiver runtime/framework and how it currently parses the body
- What we do with the payload (format a Block Kit message, route by field, etc.)

Your job:

1. **Derive a schema** — from my samples, write an explicit schema (JSON Schema or runtime validator) for required fields, types, enums, and optional fields, with sane bounds on string lengths and array sizes.
2. **Validate before use** — show the receiver validating the parsed body up front and rejecting non-conforming payloads with a structured error, before any field is touched.
3. **Fail safe, not loud** — on validation failure, log the rejection with a payload fingerprint and return the correct HTTP status; never post a half-built or `undefined`-laden message into Slack.
4. **Tolerate additive change** — allow unknown extra fields (forward-compatible) but reject missing required ones, so upstream additions don't break you.
5. **Sanitize for Slack** — strip or escape content that would break mrkdwn or inject unwanted @here/@channel mentions before it reaches a message.
6. **Test fixtures** — provide valid, missing-field, wrong-type, and oversized fixtures and assert each is handled.

Output as: (a) the schema definition, (b) the validation middleware/guard code, (c) the failure-path handler and log shape, (d) the Slack-content sanitization step, (e) the test fixtures and assertions.

Default to rejecting anything that doesn't match the schema; it is safer to drop one malformed event than to flood a channel with broken or injected messages.