The data-field `step` (slider) is the settings `step`'s unenforced twin — `record-validator.ts` reads `min`/`max` and never `step`

[os-project-manager]

Found while implementing #6199 (settings step enforcement, PR #6501). Not in #6199's completion scope — that issue's ruling and file surface are packages/services/service-settings only, and this is a different schema judged by a different validator. Filed for triage.

Facts

packages/spec/src/data/field.zod.ts:697 declares a step on the data field surface:

step: z.number().optional().describe('Step increment for slider (default: 1)'),

packages/objectql/src/validation/record-validator.ts enforces that field's numeric window — lines 529-533:

if (def.min !== undefined && n < def.min) {
  return fail('min_value', { min: def.min });
}
...                                     fail('max_value', { max: def.max });

…and has no reader for def.step anywhere. Grep over packages/objectql/src/validation/ returns no step read at all (the only textual hits are lock-step prose and stmt.step() in the sqlite-wasm dialect, unrelated).

So the exact asymmetry #6199 named for the settings specifier exists one surface over, on the data field: min and max bind, the step declared beside them does not.

Why this is a separate issue and not a rider on #6199

Different schema (field.zod.ts, not settings-manifest.zod.ts), different validator (record-validator.ts, not SettingsService.validatePatch), different error path. #6199's ruling turned on the settings schema's own "numeric bounds and step" comment grouping step with min/max; the data-field declaration has a different doc string — "Step increment for slider (default: 1)" — which reads more like a UI increment and does not obviously inherit that ruling. That is a judgement call for triage, not something to assume.

Declaration sites

• examples/app-showcase/src/data/objects/field-zoo.object.ts:168 — f_slider: Field.slider({ label: 'Slider', min: 0, max: 100, step: 5 })
• packages/drivers/driver-sql/src/sql-driver-numeric-fidelity.test.ts:46 — f_slider: { type: 'slider', min: 0, max: 100, step: 5 }
• packages/spec/src/data/field.test.ts:698 — asserts only that the declaration round-trips (expect(sliderField.step).toBe(5)), not that anything enforces it.

Note field.zod.ts:691-695 already carries a comment listing slider showValue/marks among keys the runtime reader ignores, pointing at docs/audits/2026-06-dead-surface-disposition-plan.md (P2 field prune). step is not in that list, so it is currently neither enforced nor ledgered as deliberately inert — which is the part worth a verdict.

Impact

Observation-class. No user hits this today: the only real declaration is the showcase's f_slider with step: 5 on a 0-100 range, and an off-grid value there is a perfectly ordinary number for every downstream consumer. Recording it as a finding (no pm:queue); severity is triage's call.

If the verdict is "enforce", PR #6501 is the shape to copy — including its anchor convention (min + k * step, anchor 0 when no min) and its epsilon-tolerant comparison, since exact modulo rejects legitimate decimal grids under binary floating point. If the verdict is "UI-only", the fix is the ADR-0049 disposition (retire, or ledger it in the dead-surface plan beside showValue/marks) rather than silence.

Related

• settings 的 step 是同族第五个声明但不执行的值约束键 —— 先要一个「它算不算值约束」的判断 #6199 / PR fix(service-settings): enforce the declared step grid on the settings write path and the env path (#6199) #6501 — the settings-side step, ruled a value constraint and enforced.
• settings 写入路径只执行 required / options / pattern —— 声明的 min / max / minLength / maxLength 一条都不校验(auth.password_min_length 可被写成 1) #5932 / PR fix(service-settings): settings 写入路径与 env 路径执行声明的 min / max / minLength / maxLength (#5932) #6201 — the settings min/max/minLength/maxLength family this descends from.

---

Generated by Claude Code

[os-zhuang]

Findings round — routing repair (carried forward from the 02:47Z fire, resolving the deliberate blank): adding domain:spec; finding grade untouched, no ownership taken.

The carried instruction was to read whether the #6199 / PR #6501 ruling's reasoning extends to the data-field surface before routing. Read this round: the #6199 promotion (00:46Z findings-sweep comment) turned on the settings schema's own "numeric bounds and step" comment grouping step with min/max, inheriting #5932's declared-bounds-must-bind rationale. The data-field surface does NOT share that hook: packages/spec/src/data/field.zod.ts:697 documents step as "Step increment for slider (default: 1)" — a UI-increment reading — and field.zod.ts:691-695 already ledgers the neighboring slider keys (showValue/marks) as deliberately runtime-ignored while step is in neither list. Verified on origin/main @ 3510e4a: record-validator.ts:529-533 reads def.min/def.max; zero def.step reads anywhere in packages/objectql/src/validation/.

So the ruling does not transfer, and what this card needs is a fresh ADR-0049 enforce-or-ledger verdict on a spec-declared key — spec-seat territory whichever way it goes (enforce = an acceptance change per the standing red line; ledger = the dead-surface disposition plan). Same held shape as #6505. If the verdict is "enforce", the implementation lands in domain:engine-core (record-validator.ts) — re-route the execution card at that point.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[qq9340100]

Maintainer ruling (2026-08-08, session review of the held-findings backlog): UI-only ledger — do NOT enforce.

• The settings 的 step 是同族第五个声明但不执行的值约束键 —— 先要一个「它算不算值约束」的判断 #6199 ruling does not transfer (triage already established this): the settings-side promotion turned on that schema's own "numeric bounds and step" grouping; the data-field declaration documents step as a slider UI increment.
• Enforcement would create a stored-data hazard for zero measured demand: record-validator.ts judges updates to existing rows, so any stored off-grid value would start failing validation on its next edit — a new way for previously-valid data to become uneditable.
• Disposition (the ADR-0049 "ledger" half): add step to the runtime-ignored key list at field.zod.ts:691-695, beside showValue / marks, and add the corresponding row to docs/audits/2026-06-dead-surface-disposition-plan.md (P2 field prune). If grid enforcement ever gains a real user pull, it returns as a feature request following PR fix(service-settings): enforce the declared step grid on the settings write path and the env path (#6199) #6501's shape (anchor convention + epsilon-tolerant comparison).

Promoted finding → pm:queue. Serialized one round behind #6505 — both land in packages/spec, and same-package batch members are serialized by rule (known trap recorded per protocol: if #6505's TSDoc change triggers a reference-docs regeneration, two in-flight regenerations of the same generated tree would collide in the os-regen merge driver).

---

Generated by Claude Code