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

[os-justin]

The restart condition is now MET. Measured from the objectui#8451 implementing seat (PR #8473), which had to answer "what do you do about the one wrong declared default" and so ran this card's own probe rather than reading the range.

Nothing here discharges the card, changes its labels, or touches its fix surface. Posting because triage comment 5442325479 set a mechanical restart criterion and the criterion fires.

1. The probe prints true. Installed @objectstack/spec in this repo is 17.3.0 (node_modules/@objectstack/spec/package.json), and:

ApprovalEscalationSchema.safeParse({ timeoutHours: 24 })
  -> success = true
  -> data    = {"enabled":true,"timeoutHours":24,"action":"notify","notifySubmitter":true}

enabled === true for an omitted key. flow-node-config.ts still declares escalation.enabled with defaultValue: 'false', so installed spec and the inspector table no longer agree. Per the restart-when clause the hold is no longer correct: this is live, not latent. The wake was the lockfile resolution the triage comment predicted, not a manual bump — 17.2.0 to 17.3.0 inside the existing ^17.0.0 caret.

2. ⚠️ The probe as written cannot produce that reading. It spells the import as require('@objectstack/spec'), and ApprovalEscalationSchema is not on the root export of 17.3.0 — running it verbatim throws TypeError: Cannot read properties of undefined (reading 'parse'). That failure is easy to misread as "not available yet, the hold is correct", i.e. it fails toward leaving the card asleep. The working specifier is @objectstack/spec/automation, which is what this repo's own flow-node-config.spec-reconciliation.test.ts already imports:

import * as Automation from '@objectstack/spec/automation';
Automation.ApprovalEscalationSchema.safeParse({ timeoutHours: 24 }).data.enabled

3. Two in-repo comments are now stale, and neither can fire on its own.

• flow-node-config.spec-reconciliation.test.ts — "installed spec and table agree on it today" and "held on hold behind a future @objectstack/spec bump". They no longer agree.
• flow-node-config.inactiveRetained.test.ts — "Measured here on 2026-08-29: installed spec is 17.2.0, still .default(false)". It is 17.3.0 and .default(true).

The second is described as this card's tripwire, but its assertion reads only the table, never the spec, so a spec bump alone cannot redden it. Both files stayed green through the flip. (Deliberately not armed from PR #8473: comment 5465060700's warning against discharging this card from an unrelated PR still applies, and arming it is part of this card's own fix.)

4. The adjacency named in comment 5442325479 has closed. objectui#6499's fix has landed — inactiveRetainedKind and the "inactive values retained" affordance are in the tree — so the "price the combined fix against two passes" question resolves to a single pass.

5. The blast radius is one reader wider than comment 5465060700 recorded, in this card's favour. That comment measured FlowConfigField.defaultValue as having "exactly one consumer in the repo, isFieldVisible". As of PR #8473 there is a second: the boolean control seeds its checked state from the same declaration (objectui#6830 arm A). ⇒ this card's one-line flip of 'false' to 'true' now repairs the rendered toggle as well as the gating of timeoutHours / action / escalateTo / notifySubmitter — which is exactly the symptom in this card's title ("omitted-key blocks render OFF but are ON"). PR #8473 deliberately ships no caption naming a declared default, precisely so it does not put this wrong declaration into words before this card fixes it.

---

Generated by Claude Code