Filed unassigned by the objectui#6868 execution seat, while establishing whether an evaluator for buildValidationRules' output already exists in the repo. Recording, not choosing — domain:*, type and grading are triage's to produce.
Dedup before filing. Repo-scoped REST listing of the 266 open issues here (PRs excluded) plus a local regex over title+body: zero hits for ValidationEngine|validateFields. A zero is not a reading on its own, so it was reverse-checked with two controls that must hit — buildValidationRules returned #6868, and 3222 returned #6909, #6868, #6803, #6778, #6776, #5213. The zero stands.
The fact
packages/core/src/validation/validation-engine.ts declares a complete ValidationEngine class plus a module-level validateFields(values, schemas) (line 522) and a defaultValidationEngine singleton. It dispatches on ValidationRuleType (packages/types/src/data-protocol.ts:748), a snake_case rule vocabulary:
'required' | 'min_length' | 'max_length' | 'pattern' | 'email' | 'url' | 'phone' | 'min' | 'max' | ...
Measured, not assumed:
- Not exported from the barrel.
grep -n "validation-engine\|ValidationEngine" packages/core/src/index.ts returns nothing, so it is not reachable as @object-ui/core public API. - Zero consumers anywhere in the repo. A repo-wide grep for
validateFields / new ValidationEngine / defaultValidationEngine across .ts/.tsx, excluding node_modules, dist/, the declaring directory itself, and the type docblocks in packages/types/src/data-protocol.ts, returns no call sites — including apps/, examples/ and e2e/.
Why it is worth recording rather than leaving
This is a third rule vocabulary sitting beside the two that are live:
| where | vocabulary | who evaluates it |
|---|
buildValidationRules (packages/fields/src/index.tsx:2645) | react-hook-form camelCase (minLength, maxLength, pattern, validate) | react-hook-form, via Controller |
@objectstack/spec FieldSchema | maxLength / minLength / min / max | objectql's record validator, at the write seam |
| this file | snake_case min_length / max_length / … | nothing |
An unreferenced validation engine is the shape that gets adopted by the next surface that needs one — which is exactly how a second de-facto contract starts (AGENTS.md #0.1). It is cheap to retire now and expensive to retire after something imports it.
What is NOT claimed here
- ⛔ No defect is asserted. Nothing reads it, so nothing is currently wrong on any surface.
- ⛔ Not a request to delete it in a specific PR, and not a route decision. Whether this is an ADR-0049 enforce-or-remove candidate or an intentional not-yet-wired capability is triage's call; the liveness reading above is the input, not the verdict.
- ⛔ Not a claim about the
AdvancedValidationSchema / ValidationRuleTypetypes in packages/types — this card is scoped to the unreferenced implementation in packages/core.
Pathspec bound of the consumer census
packages/*/src/**/*.{ts,tsx} + apps/*/src/**/*.{ts,tsx} + examples/** + e2e/** at b03ba3ad5, excluding node_modules/ and dist/. Anything a downstream consumer builds against the published package is outside this bound.
Related
Filed unassigned by the objectui#6868 execution seat, while establishing whether an evaluator for
buildValidationRules' output already exists in the repo. Recording, not choosing —domain:*,typeand grading are triage's to produce.Dedup before filing. Repo-scoped REST listing of the 266 open issues here (PRs excluded) plus a local regex over title+body: zero hits for
ValidationEngine|validateFields. A zero is not a reading on its own, so it was reverse-checked with two controls that must hit —buildValidationRulesreturned #6868, and3222returned #6909, #6868, #6803, #6778, #6776, #5213. The zero stands.The fact
packages/core/src/validation/validation-engine.tsdeclares a completeValidationEngineclass plus a module-levelvalidateFields(values, schemas)(line 522) and adefaultValidationEnginesingleton. It dispatches onValidationRuleType(packages/types/src/data-protocol.ts:748), a snake_case rule vocabulary:Measured, not assumed:
grep -n "validation-engine\|ValidationEngine" packages/core/src/index.tsreturns nothing, so it is not reachable as@object-ui/corepublic API.validateFields/new ValidationEngine/defaultValidationEngineacross.ts/.tsx, excludingnode_modules,dist/, the declaring directory itself, and the type docblocks inpackages/types/src/data-protocol.ts, returns no call sites — includingapps/,examples/ande2e/.Why it is worth recording rather than leaving
This is a third rule vocabulary sitting beside the two that are live:
buildValidationRules(packages/fields/src/index.tsx:2645)minLength,maxLength,pattern,validate)Controller@objectstack/specFieldSchemamaxLength/minLength/min/maxmin_length/max_length/ …An unreferenced validation engine is the shape that gets adopted by the next surface that needs one — which is exactly how a second de-facto contract starts (AGENTS.md #0.1). It is cheap to retire now and expensive to retire after something imports it.
What is NOT claimed here
AdvancedValidationSchema/ValidationRuleTypetypes inpackages/types— this card is scoped to the unreferenced implementation inpackages/core.Pathspec bound of the consumer census
packages/*/src/**/*.{ts,tsx}+apps/*/src/**/*.{ts,tsx}+examples/**+e2e/**atb03ba3ad5, excludingnode_modules/anddist/. Anything a downstream consumer builds against the published package is outside this bound.Related
InlineFieldInputnever callsbuildValidationRulesand never gets anerrorprop #6868 — the card whose evaluator hunt surfaced this; its hand-over question is where the live producer should live.