# m12p5 — Idle-readiness convergence (✅ COMPLETE 2026-06-14)

Landed in `aa94fd9`. Evidence:
[docs/profiling/m12p5-idle-readiness-elasticity.md](../../profiling/m12p5-idle-readiness-elasticity.md).
Milestone index: [README.md](README.md). Backfilled record.

## The defect

A snapshot-installed joiner served `503` on its readiness probe
(`/health` → `region_health` → `is_ready`) until its sticky `converged` latch
flipped — and pre-m12p5 the only thing that flipped that latch was observing new
traffic. On an **idle** cluster there is no new traffic, so a caught-up follower
stayed unready indefinitely. The worklog records an 11.5-hour hang from exactly
this.

This is the failure class worth naming: readiness derived from *activity* instead
of from *state* is silently wrong precisely when the system is quiet.

## What shipped

1. **The leader heartbeat carries its live frontier** (`leader_last_seq`), so a
   caught-up follower can compare its own applied frontier against the leader's
   and flip `/health` Ready on an idle cluster — no ship and no status poll
   required.
2. **Cert SAN wildcard widened** for scale-to-5, removing the certificate-shaped
   blocker in front of m12p6's scale-up test.

## Evidence

Proven locally over real OS processes, with the elasticity-under-load (T4)
context recorded in the profiling doc. The 1M / 1536-D T4 run on k3s remains the
project's standing Ref-A/k3s dependency — the machinery and the fix that unblock
it are proven; the run itself is pending infrastructure access. That distinction
is the honest one: the fix is verified, the scale run is not yet done.

## Later reinforcement

The readiness contract kept being sharpened after M12 closed, which is itself
evidence the original latch was under-specified rather than merely buggy:
`0919b0a` (seed-join learner auto-promotes after snapshot install and reports the
caught-up frontier on the heartbeat), `7450cc7` ("readiness must prove
convergence, not merely lack a marker"), and `fc1cc90` (refresh frontier gauges
on the driver tick).