objectui: FilterConditionField cannot author spec’s $icontains — the case-insensitive contains is unreachable from the filter UI

[os-zhuang]

Migrated from objectstack-ai/objectstack#6337 under the file-at-destination ruling (objectstack-ai/objectstack#7167, maintainer 2026-08-10). Originally filed 2026-08-07T14:06:06Z. The full prior thread — including triage rulings and hold/restart conditions — remains on the source issue and MUST be read before acting on this card.

---

Part of #3567 (transferred to the main backlog by the triage seat — feature-level work lives in objectstack whatever repo the code lands in; see the multi-repo coordination rule "One main backlog").

Blocked-by: objectstack-ai/objectstack#5702

What is missing

packages/spec's FieldOperatorsSchema gained $icontains (case-insensitive contains, spec describe: "folds ASCII case") between 17.0.0-rc.2 and rc.5. objectui's FilterConditionField has no builder operator that can author it, so the capability is unreachable from the filter UI. The existing bidirectional parity test in packages/fields/src/widgets/__tests__/FilterConditionField.operators.test.ts ("every spec field operator is reachable from the builder", objectui#2942) went red on the rc.5 bump and was handled by objectui#3560 as an explicit, ratcheted KNOWN_UNREACHABLE entry rather than a silent exclusion.

Deliverable (lands in objectui)

1. Add a case-insensitive contains operator to the FilterConditionField builder vocabulary; condToMongo emits { field: { $icontains: value } }.
2. kvToCondition reads it back — without the reverse mapping a saved filter view degrades on reopen.
3. Ten locale packs gain the label key (the t() call-site key gate, objectui#3547).
4. Remove the $icontains entry from KNOWN_UNREACHABLE in FilterConditionField.operators.test.ts; the parity assertion then takes over, and objectui#3560's ratchet simultaneously validates that the removal was legitimate.

Why this is blocked, and it is not the reason the filing issue gave

⚠️ The originating issue states the server already accepts $icontains. Half true, and the half that is false is the blocking half. Measured against objectstack origin/main:

• $icontains is present in packages/spec only — filter.zod.ts, filter-operator-vocabulary.test.ts, filter-text-conformance.ts, the authorable-surface baselines and the CHANGELOG.
• git grep -l icontains origin/main -- packages/drivers returns nothing. No backend implements it.
• The driver half is objectstack#5702 (pm:queue + pm:blocked + domain:drivers), itself blocked by spec: $regex 按 ADR-0049 退役 + $icontains 入算子词表与 FILTER_LOGIC_CASES(#4706 裁决 B 案 · 契约半边,先行) objectstack#5701 (contract half: vocabulary + FILTER_LOGIC_CASES) and plugin-auth: better-auth 的 contains 被译成裸 $regex,用户输入当正则求值 —— 且是 $regex 退役唯一挡路的生产者 objectstack#5710 (producer-first: plugin-auth's contains branch). driver-memory / driver-mongodb implementations sit inside the [裁决] driver-memory / driver-mongodb 投入冻结 —— 维护者 2026-08-05 口径（跨单锚点） objectstack#5499 freeze.

So the spec vocabulary accepts the token while no driver can execute it. Shipping the builder operator first would put a filter in users' hands that every backend fails — strictly worse than the capability being absent. This card returns to the queue when objectstack-ai/objectstack#5702 merges.

Open product question (default recorded, not blocking)

Should today's contains have been case-insensitive all along? If so, the better shape is to have contains emit $icontains and add an explicit containsCaseSensitive for $contains — but that changes the behaviour of stored filter views, so it needs the maintainer. Default for this card: add a new operator, leave contains semantics untouched. A dev implements the default; if the maintainer wants the flip, say so here first and this card is re-scoped (it would then move to the decision inbox).

Provenance

Measured during objectui#3560 (@objectstack/* family bump to 17.0.0-rc.5). Not a regression introduced by that bump — a capability gap it exposed. Original filing: #3567.

---

Generated by Claude Code