FilterConditionField cannot author spec 17.0.0 GA's new `$like` / `$ilike` — the same shape as the closed `$icontains` gap (#4023)

[os-steve]

Found while re-pointing PR #4639 (the @objectstack/spec GA pin bump, #4636). Filed
unassigned; not fixed on that branch — it is an authoring-surface decision, not a mirror
of the range lines that card owns.

The gap

@objectstack/spec@17.0.0 adds $like and $ilike to FieldOperatorsSchema. No builder
operator in FilterConditionField emits either, so the server accepts a predicate the filter
UI cannot author.

FAIL  packages/fields/src/widgets/__tests__/FilterConditionField.operators.test.ts
      > every spec field operator is reachable from the builder (#2942)
      > some builder operator emits every spec $-token

AssertionError: FieldOperatorsSchema accepts these but no builder operator can author them:
  expected [ '$like', '$ilike' ] to deeply equal []

The gate that catches it is the reachability test added by #2942 — working as designed; this
is its second live catch.

Precedent

This is the same shape as #4023 / #3567 ($icontains unreachable from the filter UI), both
closed. Whatever triage those landed on is the natural starting point, with one difference
worth deciding rather than assuming: $icontains was a case-insensitive variant of an
operator the builder already had, whereas $like / $ilike introduce pattern matching
(wildcards) as a new authoring concept. A builder row for them has to decide whether the
author writes the wildcard characters themselves or the UI composes them, which is a real UX
call and the reason this is not a mechanical addition.

The three options as I read them

• A — add builder operators for both. Closes the gap the gate names. Needs the wildcard
  authoring decision above, plus locale strings for the operator labels.
• B — add $like / $ilike to the test's exemption list with a cited reason. Legitimate
  only if the answer is "objectui deliberately does not offer raw pattern matching in the
  visual builder" — which is arguable, since a raw LIKE pattern is the one operator where a
  mis-authored value silently returns the wrong rows rather than erroring.
• C — leave the gate red. Not an option; it blocks the pin bump.

I have no measured evidence of a consumer asking for pattern matching in the builder today, so
B deserves a fair hearing against A rather than being treated as the lazy answer — but that
call belongs to whoever owns the filter UI's authoring surface, not to the pin-bump card.

Reproduce

Only after the GA pin resolves — on main (still ^17.0.0-rc.6) this test passes.

git checkout claude/issue-4636-spec-pin-ga   # PR #4639, at 47c7cc3
pnpm exec vitest run --maxWorkers=2 packages/fields/src/widgets/__tests__/FilterConditionField.operators.test.ts

Blocked-by: #4636 (the failure is only reachable once the GA pin lands).

---

Generated by Claude Code

[os-steve]

To the decision box (PM session session_01DbRmJD3iPhXjKr6vhd4Qkv, 2026-08-17). This is an authoring-surface choice — whether the visual filter builder offers raw pattern matching — which is the human floor; it also sits on the release train (one of the two cards gating the GA pin bump, PR #4639), so a quick ruling has outsized leverage.

Four-prong block:

• Platform long-term coherence: the Tier 2 (#2901): spec values that validate and then render nothing #2942 reachability principle ("server accepts ⊆ builder can author") favors building (option A); but the gate's own design provides cited exemptions for deliberate refusals, and B would be an honest first use of it. The precedent (objectui: FilterConditionField cannot author spec’s $icontains — the case-insensitive contains is unreachable from the filter UI #4023/FilterConditionField 无法生成 spec 新增的 $icontains(大小写不敏感 contains)—— 服务端已接受,筛选 UI 到不了 #3567, $icontains) built the operator — but that was a case-variant of an existing concept; $like/$ilike introduce pattern matching as a NEW authoring concept.
• Measured business pull: zero — no consumer has asked for pattern matching in the builder; the tokens arrived from the spec side (GA addition), not from user demand.
• AI-agent error-resistance: the decisive axis, and it cuts AGAINST building: a raw LIKE pattern is the one operator where a mis-authored value silently returns wrong rows instead of erroring, and the safe constrained variants (starts-with / ends-with / contains) are ALREADY authorable via existing operators — so the only net-new capability A adds is exactly the error-prone raw form.
• Startup scope discipline: B is the defer arm; A adds builder UI + wildcard-authoring UX decision + locale strings for a zero-pull surface.

Options:

• A — build both operators (requires deciding whether the author writes wildcard characters or the UI composes them, plus i18n labels).
• B — cited exemption in the Tier 2 (#2901): spec values that validate and then render nothing #2942 gate: "objectui's visual builder deliberately does not offer raw pattern matching; the constrained equivalents ($contains/$startswith/$endswith family) are the authorable surface; hand-written ObjectQL retains full access." Reopen condition: a real consumer asks for pattern authoring in the builder.

PM recommendation: B. It is reversible (an exemption deletes in one line when demand appears), keeps the gate honest through its own designed mechanism rather than weakening it, and does not gift AI authors the one silently-wrong-results operator. If ruled B, the fix is a small cited-exemption card and #4639's third red clears with it.

---

Generated by Claude Code