build(changelog): cliff.toml renders breaking releases as ordinary features — 0.18.0 and 0.20.0 both affected

[MichaelTaylor3d]

Task

cliff.toml does not render breaking changes as breaking, so every breaking release ships in
CHANGELOG.md as an ordinary feature row.

Found by a review gate that had itself asserted the opposite — it claimed adding ! to a subject would
fix the changelog, then measured it and retracted that half on the record. The measurement:

• cliff.toml mentions breaking once, as protect_breaking_commits = true — which only stops
  breaking commits being filtered out, it does not mark them.
• The body template never references commit.breaking.
• There is no breaking parser group.

Proof is in this repo's own changelog: #18 shipped as feat! and rendered with no marker at all.

Why it matters

A consumer's only warning that a release will not compile against their code is the changelog. Today
they get a compile error instead of a signal, and this crate is a wire contract — its whole job is to
be depended on by two independent implementors.

Two already-published releases are affected: 0.18.0 and 0.20.0, both genuinely breaking (each added
ControlHandler methods without defaults), both rendering as ordinary features.

Scope

Fix the config so a breaking commit renders as such, then regenerate. CHANGELOG.md is
cliff-generated — never hand-edit it; the fix is the config plus a regenerate, or the next run
silently reverts it.

One constraint that rules out the obvious approach: a footer-only parser will not work here. This
crate announces breakage with ! in the subject and has no BREAKING CHANGE: footers at all, so
a rule keyed on the footer would match nothing and pass as clean — a vacuous fix.

Backfill 0.18.0 and 0.20.0 in the same pass.

Evidence

• Prove the negative first: confirm a feat! commit currently renders without a marker — that is
  the defect, and it is what your fix must change.
• After the fix, regenerate and show the marker present for both backfilled versions.
• Read passed-counts, never ok. If you add a guard test, prove it can fail — a changelog check that
  passes against the unfixed config is worse than none.

Cross-references

Found during: #25 (eco#3127's wire contract, merged as a9fcbefc
as feat(wallet)!) — the ! there is durable and greppable in git log and matches the crate's best
precedent, but it does not reach the changelog until this is fixed.

Also worth a line while the file is open: SPEC §4.2a's authority rule is normative in the SPEC but
absent from the rustdoc a consumer reads on docs.rs — which is where the adapter actually gets written.
Same shape bit dig-keystore today: SPEC and rustdoc disagreeing, with the rustdoc being the half a
developer reads.

[MichaelTaylor3d]

This has now bitten a genuinely breaking release — raising the band

0.21.0 shipped today and it reallocates two published error codes (WALLET_COINS_RESERVED
-32044→-32046, WALLET_RESERVATIONS_UNAVAILABLE -32045→-32047). It was titled feat(wallet)!: with a
BREAKING CHANGE: footer.

The changelog will not flag it. A consumer reading only CHANGELOG.md sees a routine feature release
and discovers the reallocation as a compile error — or worse, does not recompile and branches on a
number that now means something else.

That moves this from a latent config defect to one with a live, concrete consequence.

Three affected releases now, not two

version	why breaking	renders as
0.18.0	added ControlHandler methods without defaults	ordinary feature
0.20.0	same	ordinary feature
0.21.0	reallocated two published error codes	ordinary feature

Why 0.21.0 makes this worse than the earlier two

0.18.0 and 0.20.0 break at compile time — an implementor cannot miss them for long. 0.21.0 can break
at runtime for a consumer that only reads the codes: -32044 did not disappear, it now means
WALLET_NODE_SPEND_DISABLED — "retrying cannot help" — where it previously meant "this is a wait,
retry". Exact opposite dispositions on the same number.

A client that branches on the numeric code and does not recompile will retry forever on a permanent
refusal.

The fix is unchanged

cliff.toml mentions breaking once, as protect_breaking_commits = true, which only stops
filtering. The body template never references commit.breaking, and there is no breaking parser group.

A footer-only parser will not work here — this crate announces with ! in the subject. 0.21.0 does
carry a BREAKING CHANGE: footer, but 0.18.0 and 0.20.0 do not, so a footer-keyed rule would render two
of the three as clean and pass as fixed. Key on the subject ! and the footer.

CHANGELOG.md is cliff-generated — never hand-edit it; fix the config and regenerate, or the next run
reverts it.

Evidence

Prove the negative first: confirm a feat! commit currently renders without a marker — that is the
defect. Then regenerate and show the marker present for all three backfilled versions.

Related, from the same lane

The contract's own SPEC.md error table never listed -32044/-32045 at all in 0.20.0 — the codes
shipped in code and rustdoc but not in the crate's normative catalogue. Backfilled in 0.21.0. Worth noting
that the code-uniqueness guard added alongside would not have caught that either: it checks
code-vs-code, not code-vs-SPEC. A catalogue-completeness check is a separate guard and does not exist.