[test-coverage — low] This no longer verifies the ok-guard it names.

The old test asserted !f.contains("low") / !f.contains("sourceIndex") — a guard-dropped field was literally absent from the QVariantMap, so removing the if (ok) would flip contains() to true and fail the test. The rewrite asserts d.low == 0.0 and d.sourceIndex == 0, but MeterDef's defaults are exactly 0.0/0, and an unguarded "junk".toDouble() / "nope".toInt() also yields 0.0/0 — so the assertion holds whether or not the guard exists. This is the only test covering the meter guard (grep-confirmed), so it's now unpinned: a future deletion of the if (ok) from carryRealInto/carryIntInto ships green. The comment "malformed low dropped → default 0.0" is self-defeating — it asserts the exact value both branches produce.

Root cause: for a plain struct field the fallback (default) equals the parse-failure value, so no plain-field assertion can distinguish guarded from unguarded. To actually pin the contract you'd test at a call site whose default differs from 0 (i.e. the std::optional carriers, where nullopt ≠ 0) — see the companion comment on FlexBackend.cpp about the guard being inert here.

[doc-accuracy — low] The guard is inert for meter; this comment overstates it.

"a bad low/hi would otherwise collapse a meter's scale" is true for the std::optional slice/transmit carriers (a dropped malformed value leaves the field nullopt, so the model keeps its previous value), but not here: a fresh MeterDef def; is built each iteration with low/high defaulting to 0.0, so a malformed low=junk yields 0.0 with the guard and "junk".toDouble()==0.0 without it — the same collapse either way. The carryRealInto/carryIntInto guard gives real fail-closed protection only at the optional<T> call sites, not at the plain-field MeterDef sites.

Since meter status is a full definition and defineMeter full-replaces, the plain carryInto/unconditional-assign would be equally correct here — consider either dropping the guarded variant's pretense for meter or reworiding the comment to "defensive/consistency only" so a maintainer doesn't trust a protection that isn't there.

[cleanup — low] The shared header ships the very duplication its rationale warns against.

Two parallel families with identical present-only + ok-guard bodies, distinguished only by target type: carryStr/carryInt/carryReal/carryBool write std::optional<T>&; carryInto/carryIntInto/carryRealInto write plain T&. The header's own comment says "a future tweak (base-0 parse, whitespace trim) can't be applied to one copy and silently skipped in the others" — yet carryInt and carryIntInto are two copies of the int parse (and carryIntInto already carries a base param carryInt lacks), and likewise for real. Overloading a single carry(kvs, wire, target) on std::optional<T>& vs T& (or one template dispatching to a small assign) collapses both families and makes every call site read uniformly — the Into suffix doesn't signal "plain vs optional" to a reader anyway.

[cleanup — low] Three call conventions for one helper family in one TU.

Slice keeps these forwarding lambdas (oStr → flexkv::carryStr, …), transmit calls carryBool unqualified via the file-scope using namespace flexkv, and meter qualifies flexkv::carryInto. Transmit already proved the forwarders unnecessary — dropping them (call flexkv::carryStr(kvs, "pan", d.panId) directly) or keeping one convention everywhere would make the contract legible and mean a future carrier-signature change threads through one layer, not two. Relatedly, the local splitList lambda at the slice site is redundant: the using-directive already makes flexkv::splitList callable unqualified, so the lambda is a no-op wrapper that only obscures whether it adds behavior.

These two assertions no longer distinguish a guarded from an unguarded parse. MeterDef defaults low/sourceIndex to 0.0/0, and an unguarded "junk".toDouble() / "nope".toInt(&ok,0) also yields 0.0/0 — so both branches produce the same value and the test stays green if carryRealInto/carryIntInto lose their if (ok). The // malformed low dropped → default 0.0 comment is self-defeating: it asserts the exact value both paths produce.

For a plain struct field the parse-failure value equals the default, so no meter-site assertion can pin the fail-closed contract. Two honest options:

1. Move the guard test to an optional<T> call site (slice/transmit), where a dropped malformed value stays nullopt ≠ 0 — that's where the guard actually protects, per your FlexBackend.cpp:394 note.
2. Accept the guard is inert here and reword this to a plain "malformed value → field keeps default" check (drop the "dropped"/guard framing), and let (1) carry the real contract.

Confirmed: this comment is accurate for the optional<T> slice/transmit carriers (a dropped value stays nullopt, model keeps its previous value) but not here — a fresh MeterDef def; defaults low/high to 0.0, so a malformed low=junk collapses to 0.0 with the guard and "junk".toDouble()==0.0 without it. Since defineMeter full-replaces, an unconditional assign would be equally correct at these plain-field sites. Either reword to "defensive/consistency only" so a maintainer doesn't trust protection that isn't there, or drop the guarded variant for the meter path.

The file-scope using namespace flexkv; already makes splitList callable unqualified, so this forwarder lambda is a no-op wrapper — calling flexkv::splitList (or just splitList) directly is equivalent. More broadly, this TU now uses three conventions for one helper family: slice wraps in forwarding lambdas (oStr/oInt/…), transmit calls carryBool unqualified via the using, and meter qualifies flexkv::carryInto. Transmit already proved the forwarders unnecessary; settling on one convention would keep a future carrier-signature change threading through one layer, not two.

Non-blocking design note: carryInt/carryIntInto (and carryReal/carryRealInto) are two copies of the same parse distinguished only by optional<T>& vs T& — the exact duplication this header's rationale warns against, and carryIntInto already carries a base param carryInt lacks. Overloading a single carry(kvs, wire, target) on the two target types (or one template dispatching to a small assign) would collapse both families; the Into suffix doesn't signal "plain vs optional" to a reader anyway. Fine to defer, but worth a note before a 5th touchpoint copies it.