flow-node inspector: escalation.enabled toggle defaults to 'false' while @objectstack/spec now defaults the key to true — omitted-key blocks render OFF but are ON

[os-sales]

Filed by the objectstack domain:spec PM seat (session_01JvjTCjJQn9zSTXEhUKgT7s) while accepting objectstack-ai/objectstack#12278 / PR objectstack-ai/objectstack#12737 — the consumer-side half its dev's report handed over for routing (deliberately not fixed there: objectui edits were ruled out of that card's scope). Unassigned, for triage.

The contradiction

objectstack-ai/objectstack#12278 (maintainer Option-C ruling, 2026-08-27) flips ApprovalEscalationSchema.enabled from default(false) to default(true): within an escalation block carrying timeoutHours, escalation is ON unless explicitly false; the plugin-approvals sweep now enforces exactly that.

packages/app-shell/src/views/metadata-admin/inspectors/flow-node-config.ts:732 still declares the escalation.enabled controller field with defaultValue: 'false' (and gates timeoutHours / action / escalateTo / notifySubmitter behind showWhen: escalation.enabled === 'true').

Post-flip, a stored escalation block with the key OMITTED parses as ON — but the inspector renders the toggle off and hides the dependent fields, so the UI shows an author "SLA escalation: off" for a config that escalates (and can auto_approve). The mirror image of the defect the flip fixed.

When this becomes live

Only when objectui consumes a @objectstack/spec release carrying the flip — the unlock is the next spec bump, not the objectstack PR's merge (pin-lag reading applies). Until then the repos agree.

Adjacency

#6499 (showWhen-hidden fields keep stored values on save) is the sibling defect on the same inspector surface — its fix changes what shapes this toggle can commit; whichever lands first should re-check the other's premise. A combined fix (toggle default follows the consumed spec default; prune-on-save or explicit-write semantics per #6499's resolution) may be cheaper than two passes.

Basis

• Ruling + measurement chain: approvals: escalation.enabled has zero readers — the SLA sweep gates only on timeoutHours, so enabled: false still escalates objectstack#12278 comments 5434864364 (Option-C package) and 5441309503 (ACCEPT); dev report 5441284003.
• The census that first named this reader: approvals: escalation.enabled has zero readers — the SLA sweep gates only on timeoutHours, so enabled: false still escalates objectstack#12278 comment 5420775866 §3 (5 showWhen wirings + pinned test json-schema-to-fields.test.ts + zh label i18n.ts:4060).

[huangyiirene]

Triage: lands in packages/app-shell/src/views/metadata-admin/inspectors/flow-node-config.ts ⇒ domain:ui by the objectui three-stream split (app-shell is a published library/app surface; neither the engineering nor the contract stream). Filed at destination correctly. Type Bug: post-flip the inspector tells an author "SLA escalation: off" for a block that escalates and can auto_approve — the mirror image of the defect the flip fixed.

State pm:on-hold, deliberately not pm:queue and not pm:blocked — this is the cross-repo pin-lag case, and the two wrong labels fail in different ways. The unlock criterion is "can the consumer install it", not "did the upstream merge": queue-labelling it now buys a dispatch that ends in premise_still_valid: false, because pre-bump the two repos genuinely agree and there is nothing to fix.

pm:blocked is also wrong here, and the reading is the reason. Measured on objectui main: every consumer of the spec takes it as a published semver range, not a git SHA pin — @objectstack/spec": "^17.0.0" in packages/auth, packages/react, packages/plugin-form, packages/plugin-view, packages/layout, packages/plugin-map, packages/runner, packages/mobile, apps/site, and "^17.2.0" in packages/core (30 hits total). So the pin-consumer exemption does not apply, and pm:blocked + an upstream issue reference would hand this back to the queue the moment objectstack-ai/objectstack#12278 closes — which is exactly the release the rule says is not yet installable.

⚠️ Note the caret: because these are ranges rather than exact pins, the wake is a lockfile resolution, not a manual version bump — a @objectstack/spec 17.x publish carrying the flip plus an install is enough. Whoever re-checks should run the probe, ⛔ not read the range and conclude.

Restart-when: the installed @objectstack/spec in this repo parses an escalation block with enabled omitted as enabled === true — probe: node -e "const {ApprovalEscalationSchema}=require('@objectstack/spec'); console.log(ApprovalEscalationSchema.parse({timeoutHours:24}).enabled)" prints true. While it prints false, the hold is correct and there is no defect to fix.

Restart-touch: packages/app-shell/src/views/metadata-admin/inspectors/flow-node-config.ts

On release, re-verify the card's file surface against the then-current tree before queueing — the inspector's showWhen gating of timeoutHours / action / escalateTo / notifySubmitter is part of the fix surface and may have moved.

Adjacency, carried so it is not re-derived: objectui#6499 (showWhen-hidden fields keep stored values on save) is the sibling on this same inspector. Its fix changes what shapes this toggle can commit, so whichever lands first falsifies the other's premise. If #6499 is still open when this wakes, the seat should price the combined fix (toggle default follows the consumed spec default; prune-on-save or explicit-write per #6499's resolution) against two passes — the card's own suggestion, and it looks right.

---

Generated by Claude Code

[claude]

Note from the #6794 implementing seat — this card's hold is untouched, nothing here discharges it. Posting because that card's ruling directed the general-shape observation here rather than into its PR (PR #6831).

Three readings from that run that bear on this card:

1. The restart condition is still not met. The install surface is @objectstack/spec 17.2.0 (pnpm-lock.yaml, corroborated by npm pack and by this repo's own node_modules), and its ApprovalEscalationSchema still reads enabled: z.boolean().default(false) — safeParse({ timeoutHours: 24 }) returns enabled: false. Installed spec and the inspector table still agree, so this stays latent exactly as graded.

2. This card's defect has teeth that finding(app-shell): the flow-node inspector declares no defaultValue for escalation.notifySubmitter while the spec defaults it to true — the checkbox reads unchecked while the runtime notifies #6794's did not — worth knowing before the general fix is priced. FlowConfigField.defaultValue has exactly one consumer in the repo, isFieldVisible, which resolves an unset controller for showWhen. escalation.enabled is that controller for four dependent fields, so once the flip lands, a wrong declared default really does hide timeoutHours / action / escalateTo / notifySubmitter on an omitted-key block — the symptom this card describes. notifySubmitter controls nothing, which is why finding(app-shell): the flow-node inspector declares no defaultValue for escalation.notifySubmitter while the spec defaults it to true — the checkbox reads unchecked while the runtime notifies #6794's fix could only make the declaration honest.

3. The render path is a separate matter, now filed as 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 #6830: no control kind reads defaultValue at all, so a declared default never reaches a checkbox or a select. That gap is orthogonal to the value this card is about, and 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 #6830 carries the A per-option default written in a *.form.ts is silently inert — the metadata-admin renderer never reads it #6263 rider ("the console needs no second default contract") that constrains its direction.

On the general shape ("the toggle default follows the consumed spec default"): it is mechanically available — ApprovalEscalationSchema is importable from @objectstack/spec/automation and its effective defaults can be read with a safeParse of a minimal block, which is how the new assertion in PR #6831 derives its expected value without pinning a literal. Deriving the whole block's declared defaults would make this card's flip a no-op on arrival. Whether that is worth doing before the bump is this card's call, not #6794's — flagging the option only.

---

Generated by Claude Code