update links under the root README file

02-performance-allocation/12-sync-pool-buffer-middleware/README.md

@@ -0,0 +1,42 @@
+# Kata 12: The sync.Pool Buffer Middleware
+**Target Idioms:** `sync.Pool`, Avoiding GC Pressure, `bytes.Buffer` Reset, Benchmarks (`-benchmem`)  
+**Difficulty:** 🔴 Advanced
+
+## 🧠 The "Why"
+In Go, performance regressions often come from allocation/GC churn, not “slow CPU”.
+People use `sync.Pool` incorrectly:
+- pooling long-lived objects (wrong),
+- forgetting to reset buffers (data leak),
+- storing huge buffers back into the pool (memory bloat).
+
+This kata is about **safe pooling** for high-throughput handlers.
+
+## 🎯 The Scenario
+You’re writing an HTTP middleware that:
+- reads up to 16KB of request body for audit logging
+- must not allocate per-request in the hot path
+
+## 🛠 The Challenge
+Implement a middleware:
+- `func AuditBody(max int, next http.Handler) http.Handler`
+
+### 1. Functional Requirements
+- [ ] Read up to `max` bytes of request body (do not consume beyond `max`).
+- [ ] Log the captured bytes with `slog` fields.
+- [ ] Pass the request downstream intact (body still readable).
+
+### 2. The "Idiomatic" Constraints (Pass/Fail Criteria)
+- [ ] **Must** use `sync.Pool` to reuse buffers.
+- [ ] **Must** `Reset()`/clear buffers before putting back.
+- [ ] **Must** bound memory: never keep buffers larger than `max` in the pool.
+- [ ] Provide a benchmark showing reduced allocations (`go test -bench . -benchmem`).
+
+## 🧪 Self-Correction (Test Yourself)
+- **If a request leaks previous request content:** you failed (no reset).
+- **If allocations are ~O(requests):** you failed pooling.
+- **If buffers grow unbounded and stay in pool:** you failed memory bounds.
+
+## 📚 Resources
+- https://pkg.go.dev/sync
+- https://go.dev/doc/gc-guide
+- https://go.dev/blog/pprof