finding(app-shell): the flow-node inspector's declared `defaultValue` never reaches the rendered control — ten fields declare a default, the control shows none of them

[claude]

Filed unassigned by the domain:ui execution seat while implementing #6794 (branch claude/issue-6794-notify-submitter-default). Recording, not claiming — and deliberately not ridden into that PR, whose triage ruling scoped it to one missing declaration.

The observation

FlowConfigField.defaultValue in packages/app-shell/src/views/metadata-admin/inspectors/flow-node-config.ts is described in its own doc comment as the "spec default". Ten fields in the table declare one. The rendered control reads none of them.

Measured on origin/main 26896c689, by enumerating every consumer of the property in views/metadata-admin:

consumer	reads field.defaultValue?
isFieldVisible (flow-node-config.ts)	yes — and it is the only one. Resolves an unset controller when evaluating a showWhen
FlowNodeConfigField — the component that draws every field kind	no
FlowNodeInspector — computes the value it passes down	no, it passes getFieldValue(node, field), the stored value alone

So the control renders from stored metadata only:

• case 'boolean' draws checked={value === true} — an unset key is unchecked, whatever the table declares.
• case 'select' draws value != null ? String(value) : '' — an unset key is an empty select, whatever the table declares.

The ten declaring fields today: http_request.method (GET), assignment create, approval.behavior (first_response), approval.onEmptyApprovers (admin_rescue), escalation.enabled (false), escalation.action (notify), escalation.notifySubmitter (true, added by #6794), maxRevisions (3), waitEventConfig.eventType (timer), and the boundary error default. For each, an author whose node omits the key sees a blank or unchecked control while the executor applies the declared value.

Why this is filed rather than fixed

It is the half of #6794 that the ruled fix does not reach. That card's severity narrative is "the checkbox reads unchecked while the runtime notifies"; adding the missing defaultValue makes the declaration honest — the table now states what the runtime does, and the offline table stops disagreeing with the online configSchema half of the same form — but it cannot change what the checkbox renders, because nothing in the render path consults the property. Both facts belong in the record, so the surviving half gets its own card instead of being folded into a PR that does not fix it.

⚠️ Read the adjacent ruling before choosing a direction

⛔ This is not obviously "seed the control from the declared default". #6263 carries a maintainer ruling (2026-08-28) whose objectui rider is verbatim: "the console needs no second default contract", in a decision that narrowed a per-option default out of the form-view vocabulary rather than teaching the renderer to honour it. A designer that starts writing declared defaults into stored metadata would be exactly the second contract that ruling refused.

So the open question is how an effective default is shown, not whether to start writing one. Sketching the space without recommending, since this is a triage call:

• A — show, do not write. Render the declared default as placeholder text on a select, and as a distinct "on by default" affordance beside an unchecked box. Stored metadata untouched; the author can still see what an unset key does.
• B — leave it, and drop the claim. Keep the render path as it is and stop calling defaultValue a spec default in the doc comment — say plainly that it resolves showWhen and nothing else. Cheapest, and honest, but the author still cannot tell an unset key from a false one.
• C — seed on author intent. Write the default when the author first opens the block, so the stored node says what the UI shows. This is the one the A per-option default written in a *.form.ts is silently inert — the metadata-admin renderer never reads it #6263 rider argues against.

There is also a narrower, purely factual sub-question that needs no ruling: a boolean control cannot presently distinguish "key absent" from "key stored as false". That is what makes the notify-submitter case read as an assertion rather than an absence.

Not related to

escalation.enabled / #6620 is a different defect on the same lines — that one is about the declared value being wrong after a future spec bump, not about the render path ignoring declarations. It stays on hold on its own terms; nothing here should wake it.

Reproduction

node -e "import('@objectstack/spec/automation').then(A => console.log(A.ApprovalEscalationSchema.safeParse({ timeoutHours: 24 }).data))"

prints notifySubmitter: true on the installed @objectstack/spec 17.2.0, while an approval node whose config.escalation omits the key draws the "Notify submitter" box unchecked.

---

Generated by Claude Code

[claude]

Context from the domain:ui execution seat (PM session session_01CRJge11jso9TpXRWFt1Z49) — filed by the implementer of #6794 / PR #6831, out of that card's fence. ⛔ Grading and domain:* are the triage seat's; this comment adds inputs, not labels.

⭐ This card inherits a live p1 symptom — it is not a fresh finding

#6794 is now pm:blocked behind this card, and PR #6831 was changed from Fixes #6794 to Part of #6794 for that reason. The reason matters for grading here:

#6794 was graded p1 on this discriminator (triage, verbatim): "An author reads 'notify submitter: unchecked', concludes submitters are not notified, and ships an approval flow that notifies them … the surface leads the author to a wrong action, rather than merely failing to show one."

PR #6831 makes the flow-node table's declaration honest — it does not change what the control draws, and the implementer established that no table-only fix could. ⇒ the user-visible half of #6794's p1 symptom is what this card now carries. It is live today on a published admin surface with a live installed dependency, not a latent or cosmetic gap.

Verified by this seat against origin/main: the sole read of a flow-node field's defaultValue is FlowNodeInspector.tsx:236, feeding showWhen controller resolution; the boolean control draws checked={value === true} from the stored value alone. Ten fields in that table declare a default and no control kind reads any of them.

⚠️ The adjacent ruling that constrains the direction — do not re-litigate from the wrong end

The implementer already quoted this and it is the right guardrail to carry: the maintainer ruling on #6263 says "the console needs no second default contract."

⇒ the open question is how an effective default is SHOWN, ⛔ not whether the designer should start writing defaults into stored metadata. A repair that makes the inspector persist defaults into saved records would contradict that ruling while appearing to fix the symptom.

One mechanism recorded here rather than as a second card

A boolean control in this inspector cannot distinguish "key absent" from "key stored as false." That is the mechanism that turns this from a missing display into an active false assertion — an unset key and a deliberately-disabled key render identically, so the surface asserts "off" for a field the runtime treats as "on". Worth having in front of whoever grades the repair shape.

---

Generated by Claude Code