forms: DynamicForm renders a C++ enum class as a free-text field, and its gate accepts values outside the set

[Yaraslaut]

morph::forms::schemaJson<A>() fully describes a C++ enum class member: glaze
emits it as a closed set of const alternatives, each with its own title.

"role":{"type":"string",
        "oneOf":[{"title":"Viewer","const":"Viewer"},
                 {"title":"Member","const":"Member"},
                 {"title":"Manager","const":"Manager"}],
        "x-order":2,"title":"Role"}

The shipped renderer throws all of that away. DynamicForm.qml's resolveProp
(src/qt/forms/qml/DynamicForm.qml:175-203) collapses an oneOf to its first
non-null branch — a path added for the nullable-$ref shape morph#189 fixed,
where the branches differ only in nullability — and then fields
(:248-380) never looks at const or enum at all. isChoice is set solely
by the presence of x-optionsAction. So a closed enum renders as a plain
TextField and any string the user types is submitted verbatim.

Verification status: reproduced

Measured at 1f7a4619 (branch scenario-corpus-both-axes) on a
-DMORPH_BUILD_FORMS_QML=ON -DMORPH_BUILD_LADDER=ON -DMORPH_LADDER_RUNGS=kanban
configure, Qt 6.11.2, QT_QPA_PLATFORM=offscreen.

A scratch tst_*.qml run through the shipped suite's own runner
(morph_forms_qml_tests -input <dir>), with two schemas pasted verbatim
from schemaJson<kanban::SetMemberRole>() / schemaJson<kanban::CreateRule>()
and bound declaratively (schema: JSON.parse(...), i.e. the same shape every
app uses):

SetMemberRole FIELD projectId  jsonType="integer"  isChoice=false  isInteger=true   optionsAction=""
SetMemberRole FIELD principal  jsonType="string"   isChoice=false  isInteger=false  optionsAction=""
SetMemberRole FIELD role       jsonType="string"   isChoice=false  isInteger=false  optionsAction=""
control drawn for `role`: TextField_QMLTYPE_36(0x55e1f8c061c0, "field_role")
SetMemberRole ready with role='Emperor': true
SetMemberRole previewLine: {"projectId":1,"principal":"bob","role":"Emperor"}

CreateRule FIELD projectId        jsonType="integer" isChoice=false isInteger=true  optionsAction=""
CreateRule FIELD triggerColumnId  jsonType="integer" isChoice=false isInteger=true  optionsAction=""
CreateRule FIELD mutationType     jsonType="string"  isChoice=false isInteger=false optionsAction=""
CreateRule FIELD mutationValue    jsonType="string"  isChoice=false isInteger=false optionsAction=""
control drawn for `mutationType`: TextField_QMLTYPE_36(0x55e1f8598770, "field_mutationType")
control drawn for `triggerColumnId`: TextField_QMLTYPE_36(0x55e1f8407ef0, "field_triggerColumnId")
CreateRule ready with mutationType='Explode': true
CreateRule previewLine: {"projectId":1,"triggerColumnId":3,"mutationType":"Explode","mutationValue":"urgent"}

Two separate consequences, both in that output:

1. No affordance. The user gets a text box for a three-value set the schema
   fully enumerates, with the alternatives' titles (already the human labels)
   discarded.
2. The client gate does not gate. ready == true and a body is assembled
   for role = "Emperor" / mutationType = "Explode". The server rejects it
   (glaze's enum reader refuses an unknown name), so this is a UX defect and not
   a correctness hole — but the whole point of the client-side gate is to say
   "this cannot be submitted" before the round trip, and here it says the
   opposite. Compare isBoolean, which exists precisely so a two-valued field
   is not a text box that accepts "banana" (DynamicForm.qml:313-318).

Not verified: the HTML renderer (morph::render) — this issue is about the
Qt/QML one only. I did not check whether any shipped rung currently renders an
enum member through DynamicForm (bookmarks' CreateBookmark::visibility is a
plain reflected enum and would hit this, but I did not run its GUI).

Where it bites today

examples/kanban (the ladder's designated showcase). Converting its remaining
two screens to schema-driven forms is blocked on exactly this:
SetMemberRole::role (gui/qml/MembersView.qml) and
CreateRule::mutationType (gui/qml/RulesView.qml) are each a hand-built
three- or two-item ComboBox today, and rendering them would replace a picker
with a typo-accepting text field. They are therefore left hand-built under
examples/IMPLEMENTATION.md rule 2's justification (a), with this issue as the
gap that justification requires — see that rung's README and morph#344.

examples/IMPLEMENTATION.md rule 3 makes this general rather than incidental:
"Closed sets of states/options → enum class (never a bare integer, never
bool)". Every rung is instructed to spell closed sets exactly the way the
shipped renderer cannot draw.

A shape for the fix

resolveProp should recognise "every branch of this oneOf/anyOf (bar
null) carries a const" as a distinct case from "these branches differ only
in nullability", and fields should carry the resulting value/label pairs.
Rendering can then reuse the combo box isChoice already draws — the only
difference is that the options are in the schema instead of behind
x-optionsAction, so no fetchOptions round trip is needed. The bare JSON
Schema enum keyword deserves the same treatment for a hand-written schema.
fieldJsonLiteral should reject a value outside the set, so ready means what
it says.

What would change the verdict

Close this when a schema whose property is an oneOf of consts renders as a
selection control and a value outside the set leaves the form !ready. Re-open
if a later resolveProp change silently re-collapses the branches. The scratch
probe above is not committed; the assertion belongs in
src/qt/forms/tests/tst_dynamicform.qml, whose harness is where I ran it.

[Yaraslaut]

Triage: valid — implement as written. Two additions from checking it, both of which strengthen it.

Premise: confirmed. DynamicForm.qml contains zero occurrences of const or enum as schema keys:

$ grep -n '\bconst"\|\.const\b\|enum' src/qt/forms/qml/DynamicForm.qml
(no output)

and isChoice is keyed solely on the options action (:299 — isChoice: optionsAction !== undefined). resolveProp merges the first non-null branch under the property's own keys (:186-200), so a oneOf-of-consts does carry one branch's const into the merged object — and nothing downstream reads it. The rendering path and the gate are as described.

1. Two shipped rungs already render an enum through DynamicForm today

The issue lists this as not verified. It is:

• examples/pastebin/gui/qml/Main.qml:138 binds DynamicForm { actionType: "CreatePaste" }, and CreatePaste carries Visibility visibility and Editability editability (paste_dto.hpp:24-25, 70-71), both enum class.
• examples/bookmarks/gui/qml/BookmarkListView.qml:234 binds DynamicForm { actionType: "CreateBookmark" }, and that rung's own controller doc comment states CreateBookmark::visibility is "a plain reflected enum, not a server-fetched choice".

And docs/GETTING-STARTED.md:687-693 prints the emitted schema for exactly that member, confirming the oneOf-of-consts shape from the repo's own docs rather than from a paste:

"visibility": { "type": "string",
                "oneOf": [ { "title": "Public",  "const": "Public" },
                           { "title": "Private", "const": "Private" } ], … }

So this is not only blocking kanban's conversion — pastebin and bookmarks ship a free-text box today where the schema fully enumerates the values, and the client gate accepts anything typed into it. That raises the severity and gives the fix two existing regression sites.

2. The spec carries the false premise that justifies the current behaviour

docs/spec/forms/forms.md:819 says DynamicForm.qml resolves through anyOf

"(and oneOf, which glaze does not currently emit but a hand-written or evolved schema may)"

That is false, and GETTING-STARTED.md above is the counter-example: glaze emits oneOf for every reflected enum class, today, in a shipped rung. This matters beyond tidiness — it is the stated reason oneOf is treated as a nullability-only shape and collapsed to its first non-null branch. Correcting that sentence belongs in the same change as the resolveProp fix; leaving it would preserve the rationale for re-collapsing the branches, which is the re-open condition the issue already names.

The proposed fix shape is right and fits: "every non-null branch carries a const" is a distinguishable case from "the branches differ only in nullability", the resulting value/label pairs reuse the combo box isChoice already draws with no fetchOptions round trip, and fieldJsonLiteral rejecting an out-of-set value makes ready mean what it says — matching isBoolean's precedent (:313-318).

What would change this verdict: a docs/spec/forms/forms.md statement that a closed enum is deliberately rendered as free text. There is none; the only relevant sentence asserts a fact about glaze that is not true.