forms: a plain "number" member is submitted as a JSON string — fieldJsonLiteral has no branch for bare double/float

[Yaraslaut]

Found while fixing the readiness defect for nested aggregates, and deliberately
left out of that change to keep its blast radius at zero. Filed rather than
folded, because it is a different member shape with a different fix.

What

DynamicForm.qml's fieldJsonLiteral has no branch for a schema property
declared plain "number" — a bare double or float member with no
x-decimalPlaces and no Quantity wrapper. Such a member falls through to the
same JSON-string encoding that an object-typed member used to get, so the
submitted body carries "3.5" where the schema asks for 3.5.

The action then receives a string for a numeric field. Unlike the
nested-aggregate case this is not an exotic shape: double is an ordinary
member type, and an author has no reason to expect it needs a wrapper.

Why nothing has noticed

Measured on e3471f80:

• No rung declares one. All eight (pastebin, polls, bookmarks,
  kanban, ledger, lims, crm, bank) have zero bare double/float
  members in their action headers — they use integers, Rational, or
  units::Quantity.
• The schema side is exercised, the rendering side is not.
  tests/test_nested_forms.cpp declares such a member and calls schemaJson
  17 times, so a "number" property is generated and asserted on. It never
  constructs a DynamicForm (zero references), so the missing encoding branch
  is never reached.

So the gap sits exactly between a schema that is produced correctly and a
renderer that cannot encode it, with no test spanning the two.

Verification status

Inferred from reading the dispatch in fieldJsonLiteral, not reproduced.
No fixture drives a bare-number member through DynamicForm, which is the
same reason the defect has gone unseen. The supporting counts above are
measured (grep over the eight rungs' action headers, and over
tests/test_nested_forms.cpp).

Not verified: whether the resulting string is rejected at the action
boundary with a useful diagnostic, or silently coerced. That determines whether
this presents as a clear failure or as a wrong value, and it changes the
severity rather than the validity.

Not verified: whether x-decimalPlaces-tagged numbers, Rational, and
units::Quantity all have working branches — they were not the subject here.
Those three are the shapes the rungs actually use, so they are presumably fine,
but "presumably" is the word.

Relationship to the readiness fix

The nested-aggregate fix treats an unencodable member as unrepresentable,
which keeps the form unready and tells the caller why. That mechanism is
already in place and is the obvious home for this — but pointing it at
"number" would be wrong: a bare number is representable, it just needs an
encoding branch. The fix here is to add the branch, not to declare the member
unrenderable.

Getting that backwards would make every form with a double unready, which is
strictly worse than the current wrong encoding.

What would change the verdict

Close when a form whose schema carries a plain "number" member submits a JSON
number, proven by a case that fails against the current encoding.

Close as invalid if bare double/float members are deliberately
unsupported in action types — in which case schemaJson<A>() should
static_assert on them the way it already does for an enum with no
glz::meta, rather than generating a schema the renderer cannot honour.

[Yaraslaut]

Triage: valid, bug, area: forms + area: qt

I filed this, so the thing worth testing is the claim that makes it matter:
that a bare double is an ordinary member type nobody would think needs a
wrapper. If every real action already uses Rational or Quantity by
convention, this is a corner; if not, it is a landmine.

Measured on 7a994c15. All eight rungs' action headers carry zero bare
double/float members — they use integers, Rational, or
units::Quantity. So nothing in this repository is currently broken by it, and
the blast radius today is genuinely zero.

But that is a property of the rungs, not of the API, and the reason is
instructive: those rungs were written by authors who had a reason to reach for
Quantity — money, measurements, precision. An author with a plain ratio, a
score, or a coordinate has no such signal, will write double, and will get a
form that submits "3.5".

The gap sits exactly between two things that each work

tests/test_nested_forms.cpp declares such a member and calls schemaJson 17
times, so the "number" property is generated and asserted on. It never
constructs a DynamicForm — zero references. So the schema side is tested, the
encoding side is tested, and nothing spans them for this shape. That is why
it has gone unseen, and it is the more useful finding than the missing branch
itself: the same seam could be hiding other shapes.

The trap, restated because it is easy to get backwards

The readiness mechanism that just landed treats an unencodable member as
unrepresentable, keeps the form unready, and tells the caller why. It is
sitting right there and it is the wrong tool here. A bare number is
representable — it needs an encoding branch, not a declaration that the
renderer cannot draw it. Routing "number" through the unrepresentable path
would make every form with a double unready, which is worse than the current
wrong encoding: a wrong value can be caught at the action boundary, an unready
form cannot be submitted at all.

Worth doing in the same change

Check that x-decimalPlaces-tagged numbers, Rational and units::Quantity
all have working branches. Those three are what the rungs use, so they are
presumably fine — but "presumably" is doing real work in that sentence, and the
survey costs one read of fieldJsonLiteral.

What would change the verdict

Close when a form whose schema carries a plain "number" member submits a JSON
number, proven by a case that fails against the current encoding, and the three
number-ish shapes above are confirmed rather than assumed.

Close as invalid if bare double/float are deliberately unsupported in
action types — in which case schemaJson<A>() should static_assert on them,
the way it already does for an enum with no glz::meta, rather than emitting a
schema the renderer cannot honour. That is a coherent position and it would make
this a spec-and-assert change instead.

[Yaraslaut]

Fixed as an encoding branch, and the survey turned up one shape that does not work

PR #803. Taking the two open questions in order.

1. Which outcome — branch, or static_assert?

The branch. A bare double/float is an ordinary member type that works end
to end everywhere except in fieldJsonLiteral: glaze emits an honest
{"type":"number"} for it, the action decodes one fine, and a text field is
exactly the control that collects one. static_asserting on it would delete a
working member type to avoid writing fifteen lines of QML. The unrepresentable
path was not used, for the reason this issue gives.

2. Reproduced, then mutated

src/qt/forms/tests/tst_DynamicFormPlainNumber.qml, against the renderer as it
was:

FAIL!  : DynamicFormPlainNumber::test_a_decimal_is_submitted_as_a_json_number() 'verify()' returned FALSE.
FAIL!  : DynamicFormPlainNumber::test_text_that_is_not_a_json_number_is_refused() accepted abc
FAIL!  : DynamicFormPlainNumber::test_declared_bounds_gate_a_plain_number() Compared values are not the same
... Totals: 306 passed, 9 failed

One severity correction to the filing, which asked whether the string is
"rejected with a useful diagnostic or silently coerced": there is a worse case
than either. Because a TextField validates nothing and the fall-through was
JSON.stringify(text), a plain-number field accepted banana and the form
reported ready for it. The wrong JSON type is the smaller half.

After: 317 passed, 0 failed (301 before the branch, 16 new cases). Keeping the
branch's validation and changing only its return to JSON.stringify(...)
reddens 7 of the 16, so the number-ness is asserted independently of the syntax
and bounds checks.

3. The survey — confirmed, not assumed, and one of the three is broken

Measured by printing what schemaJson<A>() emits (throwaway probe, clang 22.1.8,
7a994c15):

x-decimalPlaces and units::Quantity are one shape, not two. A generated
Quantity property is not "number" at all:

"mass": {"type": ["object","null"],
         "properties": {"den": {"$ref": "#/$defs/int64_t"},
                        "dp":  {"$ref": "#/$defs/uint32_t"},
                        "num": {"$ref": "#/$defs/int64_t"}},
         "additionalProperties": false,
         "ExtUnits": {"unitAscii": "kg", "unitUnicode": "kg"},
         "x-order": 0, "title": "Mass", "x-decimalPlaces": 2}

Working — the exact {num,den,dp} branch handles it, now pinned against that
measured schema rather than the idealised {"type":"number","x-decimalPlaces":2}
a fixture in this area had been using. The ordering in fieldJsonLiteral is
still load-bearing, because a decorated schema can put x-decimalPlaces on a
property whose type really is "number"; a case pins that the declared precision
wins there.

A bare math::Rational member does not work, and the failure is the one this
issue warned about. Its schema is an inline object:

"limit": {"type": "object",
          "properties": {"den": {"$ref": "#/$defs/int64_t"},
                         "dp":  {"$ref": "#/$defs/uint32_t"},
                         "num": {"$ref": "#/$defs/int64_t"}},
          "additionalProperties": false,
          "x-order": 0, "title": "Limit"}

No x-decimalPlaces, so isQuantity is false, nothing claims the property, and
unrepresentableMemberReason reports "a nested object member, which this
renderer does not draw" — the form never reaches ready. Before #801 the
same member was submitted as "3.5"; it has never worked.

It is a real shape, not a hypothetical: ledger::SetBudgetLimit declares
morph::math::Rational limit
(examples/ledger/include/ledger/dto/budget_dto.hpp:45). No shipped form is
affected today — ledger's QML is hand-built with no MorphForms dependency
(examples/ledger/gui/main.cpp:35) — so the blast radius is again zero and again
only because of who happens to render what.

And it is encodable, which is what makes it a recognition rule rather than a
new encoder: x-decimalPlaces on that property hands the member the
exact-decimal control, whose literal is precisely the shape the schema asks for.
Measured, in the new suite:

field_limit = "3.5"  ->  ready = true, {"limit":{"num":350,"den":100,"dp":2}}

Not folded into the PR — different member shape, different fix, per AGENTS.md.
The new suite carries it as an invariant that holds either way (whatever is
typed, the body never carries a JSON string for it) rather than pinning today's
unready verdict, so a later fix does not have to fight the test.

Verification status

• Reproduced, on 7a994c15, Release, clang 22.1.8, Qt 6, QT_QPA_PLATFORM=offscreen.
• The schema shapes above are measured output of schemaJson<A>(), not read
  off the emitter.
• Not verified: what the server does with the string body the old encoding
  produced — the fix removes the body before it is sent, so the question stopped
  being reachable from the client side.
• Not verified: whether any downstream renderer outside this repository
  relies on the old string encoding. The schema always asked for a number, so
  such a renderer was already wrong, but that is an argument rather than a
  measurement.

What would change the verdict

Close when #803 merges. Re-open if a plain-number member turns out to need an
exponent spelling (1e5 is refused today, deliberately: a text field is not
expected to collect one, and accepting it would need a bounds story for it).

The bare-Rational gap is the thing this issue should not be closed over —
it wants its own ticket, and I am leaving that to whoever triages this comment
rather than filing it from a lane.