Record what staging the AWS apply found before it happened

[sethbergman]

Three defects — #91, #94, #93 — found by staging the first real AWS apply
rather than by running it. This records them in the roadmap's "What
'done' means here" section, as a sixth entry.

Why they belong there

The five entries above it are about a test that existed and was weaker
than it looked, or a claim nobody checked. These are a different answer
to the same question: code no test could reach. The cloud profiles have
never been applied, so a whole layer of this repository has only ever
been read.

Nothing was asserted weakly and nothing had drifted. What found them was
writing down the sequence someone would actually run, in order, and
asking of each step what it needed that nothing provided.

Three things the entry keeps

tests/preflight-static exists for exactly the seam the first defect
sat in, and missed it. That suite was written around two strings one
layer produces and another consumes strictly — an auto_join selector
and a leader_tls_servername. Host naming is the same shape and nobody
had thought of it. A suite aimed at a class of defect still only covers
the instances somebody enumerated.

The emulated apply could not have seen it either, because moto has no
Ansible in it. The roadmap already says a profile that applies is not a
cluster that works; this is that sentence with a worked example.

Three known defects becoming zero known defects is a statement about
what has been looked at, not about what is there. The entry says so,
because the other reading — that the profile is now closer to proven — is
the overstatement this file exists to refuse. It also says the apply is
no cheaper than the blocker list claims: every item on that list is a
question about runtime behaviour, and none of these three was.

Verified

docs-index and lint green; make docs produced no diff, so no new H1
or H2 headings. Prose wrapped at 80, tables exempt.

🤖 Generated with Claude Code