# m12p4 — Sharded ingestion (✅ COMPLETE 2026-06-14)

Landed in `31ee612`. Evidence:
[docs/profiling/m12p4-t5-sharded-throughput.md](../../profiling/m12p4-t5-sharded-throughput.md).
Milestone index: [README.md](README.md). Backfilled record.

## What shipped

1. **Scatter-gather pool with cross-shard unified reads.** Writes hash-route
   across a 3-group `shards:` topology; reads unify across groups (L4). The
   "replicated XOR sharded" split — inherited from m11p6's shard-groups work — is
   exercised end-to-end on the read path here.
2. **A real run, not a simulation.** A 3-shard-group × RF=3 cluster on `kind`
   (single node, 24 vCPU / 50 GB) under full mTLS with cert-manager-issued certs,
   driven by **two** in-cluster `tidal-stress` generator pods: real binaries, real
   WAL and quorum, real gRPC replication, real inter-node mTLS HTTP.
3. **An HTTP/2 forwarding bug fixed.** A synthesized JSON body on a 204 relay
   triggered an h2 `RST_STREAM`; a 204 forward must carry no body.

## What the run actually proved — and did not

With data rather than a hardware caveat: **at fixed per-pod CPU, full-placement
sharding scales failover, not write throughput.** The headline gate
(≥2.5× scaling AND ≥5,000 quorum writes/s) therefore remains **Ref-A/k3s-pending**,
and the ≥2.5× target properly belongs to a ≥5-node **partitioned-placement**
topology (Ref-B). Adding nodes to full-placement RF3 does not scale writes; the
gate was mis-assigned, and m12p4 is what surfaced that.

## Follow-on repair

Deploying this layer to the real 3-shard k3s cluster exposed five 3-shard
catch-up / read / reseed bugs, each root-caused and fixed in `m12-rc8` (with
adversarial failover-safety review before implementation). Record:
[docs/profiling/m12-cluster-deploy-findings.md](../../profiling/m12-cluster-deploy-findings.md).