python3 scripts/validate_receipts.py
python3 -m json.tool index.json >/dev/null && echo "ok ✅"

## Changed files

- `index.json` (modified, +22/-1)
- `receipts/2026/04/PT-2026-04-10-github-openclaw-57403-webhook-ack-duplicate-redelivery/receipt.json` (added, +90/-0)


---

# PR #56: manifest: update capability (v0.1.15) — add protocol ACK duplicate redelivery pattern

- Repository: SirBrenton/pitstop-truth
- Author: SirBrenton
- State: closed | merged: True
- Link: https://github.com/SirBrenton/pitstop-truth/pull/56

## Description (problem / solution / changelog)

## Summary

Updates the Pitstop capability manifest to **v0.1.15** with a new execution failure pattern derived from OpenClaw issue #57403.

This addition captures a reusable protocol-boundary failure pattern:

> **protocol ACK coupled to throttled execution causes duplicate redelivery amplification**

Source:
- https://github.com/openclaw/openclaw/issues/57403

---

## What changed

### 1. New pattern added

**`protocol-ack-coupled-to-throttled-execution`**

- **Hazard:** `retry_budget_exhausted`
- **Classification:** Protocol ACK coupled to WAIT/slow fallback path
- **Canonical receipt:** `PT-2026-04-10-github-openclaw-57403-webhook-ack-duplicate-redelivery`

### 2. Corpus / manifest updates

- **Version:** `0.1.14` → `0.1.15`
- **Receipts:** `30` → `31`
- **Corpus latest date:** remains `2026-04-10`
- **Manifest last_updated:** `2026-04-13`

---

## What this pattern captures

A provider-side 429 stalls synchronous webhook processing long enough to violate the upstream ACK deadline.

Once that happens:

- the upstream source interprets missing ACK as delivery failure
- the same message is redelivered
- duplicate processing occurs
- the original throttling event becomes duplicate workload amplification

This is stronger than a simple 429 or fallback bug.

The reusable lesson is:

> throttled model execution can escape the model layer and become a protocol-level duplicate delivery loop when ACK semantics are coupled to synchronous AI latency

---

## Why this matters

Most existing patterns in the corpus focus on:

- 429 classification failures
- Retry-After misuse
- scope mistakes
- retry budget boundaries

This pattern expands the manifest into a new but related class:

- **protocol-boundary failures caused by throttled execution**

The key architectural guardrail is:

- preserve the upstream protocol contract first
- then handle retry / fallback / rate limiting behind that boundary

Examples of the right controls include:

- immediate ACK
- async processing
- dedupe by delivery ID / idempotency key
- fallback timing bounded by protocol timeout budget

---

## Why the hazard is `retry_budget_exhausted`

This pattern is grouped under `retry_budget_exhausted` because the failure manifests as stalled execution that outlives the practical protocol budget and creates downstream amplification.

It also signals that the current hazard taxonomy is beginning to stretch beyond provider-local failure and into protocol-level execution consequences, which is a useful direction for the corpus.

---

## Validation

```bash
python3 -m json.tool capability.json >/dev/null && echo "capability ok ✅"
python3 scripts/validate_receipts.py && echo "receipts ok ✅"

## Changed files

- `capability.json` (modified, +15/-3)