finding(types,i18n): after #4167 pinned PRESET_RANGES, two unpinned copies/consumers of the date-range vocabulary remain — the defaultRange TS union and the 10-locale label table

Filed while measuring #4017 (whose premise had already expired — objectui#4167 derived @object-ui/core's DATE_RANGE_PRESETS from @objectstack/spec/ui). Measured against origin/main 7d10177 with @objectstack/spec@17.0.0 (GA) installed.

Observation-class, both items: nothing a user hits today. Both copies are byte-faithful to the GA spec right now; what is missing is the tie that keeps them faithful. Recording them so the next spec release does not discover them the expensive way. Severity is the PM's call, not mine.

Item 1 — `dateRange.defaultRange` is a hand-written copy of `DATE_RANGE_DEFAULT_RANGES`

packages/types/src/complex.ts:786-794 (in DashboardComponentSchema):

   * Aligned with @objectstack/spec DashboardSchema.dateRange.
   */
  dateRange?: {
    field?: string;
    defaultRange?: 'today' | 'yesterday' | 'this_week' | 'last_week' | 'this_month' | 'last_month'
      | 'this_quarter' | 'last_quarter' | 'this_year' | 'last_year'
      | 'last_7_days' | 'last_30_days' | 'last_90_days' | 'custom';
    allowCustomRange?: boolean;
  };

The spec owns that exact vocabulary and publishes it (node_modules/@objectstack/spec/src/ui/dashboard.zod.ts:683,918):

export const DATE_RANGE_DEFAULT_RANGES = [...DATE_RANGE_PRESETS, 'custom'] as const;
// …
defaultRange: z.enum(DATE_RANGE_DEFAULT_RANGES).default('this_month')

DATE_RANGE_DEFAULT_RANGES and type DateRangeDefaultRange are both exported from @objectstack/spec/ui in GA (measured: 14 members, presets + custom). The local union has all 14, in the same order — no live drift, a latent one.

Why it matters when the spec next moves: resolveDashboardFilterDefs takes Pick< DashboardComponentSchema, 'globalFilters' | 'dateRange' >, so this union is what typechecks every TS-constructed dashboard. A preset the spec ADDS would be a legal document that objectui's own types say cannot exist — the same "narrower than the contract it implements" shape as objectui#4163's label, whose consequence was that the bad reads were invisible to tsc.

Why no gate reports it (worth writing down, it is the objectui#4607 asymmetry in the wild):

check:spec-symbols rule 1 matches by name, and this is an inline union on an interface member — there is no colliding symbol to match.
Rule 2 (the claim heuristic) fires only when the declaration references nothing spec-bound; DashboardComponentSchema references SpecGlobalFilter a few lines up, so the tie test waves the whole interface through. Exactly the asymmetry the script's own header records: the more spec-integrated a declaration is, the weaker the check on its prose became.

Fix direction (one line, plus its import): defaultRange?: DateRangeDefaultRange from @objectstack/spec/ui, which also makes the claim structural instead of prose.

Note for whoever takes it: the zod twin at packages/types/src/zod/complex.zod.ts:444 declares defaultRange: z.string().optional() — deliberately looser, and its ledger entry (SpecDashboardFields, same file, lines 414-429) says so: "both local configs are deliberately looser than spec's; migration deferred". Converging the TS union does not require touching the zod side; whether the zod side should follow is a separate decision and belongs on #2231's pile rather than being folded in silently.

Item 2 — the preset LABEL table has no tie to the vocabulary either

packages/plugin-dashboard/src/DashboardFilterBar.tsx:105:

const presetLabel = (p: string) => tt(`dashboard.filters.range.${p}`, p.replace(/_/g, ' '));

The key is built dynamically from the (now spec-owned) member name, and packages/i18n/src/locales/*.ts carry dashboard.filters.range.* by hand. Measured today: all 13 presets present in all 10 locales (ar, de, en, es, fr, ja, ko, pt, ru, zh) — clean.

But nothing connects the two lists. A preset the spec adds arrives in the dropdown by reference (that is the point of #4167's re-export) and renders as the fallback — next_week displayed as "next week", in Chinese, Japanese and Arabic alike — while check:i18n-keys cannot see a template-literal key and no test asserts coverage. So the one class of change the vocabulary extraction was designed to make painless (upstream grows a preset) is also the one that would ship untranslated in ten locales with every gate green.

Cheap fix if it is judged worth doing: a parity test asserting every DATE_RANGE_PRESETS member has an en key under dashboard.filters.range, in the same spirit as the existing "every offered preset resolves to date-macro bounds" test (packages/core/src/utils/__tests__/dashboard-filters.test.ts:475) — that one pins the BOUNDS half of the same fan-out; this would pin the LABEL half. The 10-locale spread is then the i18n channel's normal business.

Not filed, deliberately

packages/types/src/data-protocol.ts:586-607 FilterBuilderDateRangePreset (21 members incl. tomorrow / next_*) is a different vocabulary for the filter builder, already renamed off the spec's symbol name with the reason at the declaration. Not a copy of this one.
packages/plugin-dashboard/README.md:213 and content/docs/guide/dashboard-filters.md:103 list the presets in prose. Doc copies, no mechanism; mentioning for completeness only.

Triage first-touch — concentrated round #2 (triage seat, session session_019ZyCHcjXeTFPiS8RWRk4nN, 2026-08-19): promoted finding → pm:queue · Task, both items in one PR: (1) replace the hand-written defaultRange union with DateRangeDefaultRange imported from @objectstack/spec/ui (one line + import — makes the "Aligned with spec" claim structural); (2) add the label-half parity test asserting every DATE_RANGE_PRESETS member has an en key under dashboard.filters.range (mirror of the existing bounds-half test at dashboard-filters.test.ts:475). Both are tie-restoration on a vocabulary that is byte-faithful today — exactly when it is cheapest. Out of scope, per the body's own boundary: the deliberately-looser zod twin (complex.zod.ts:444, ledgered; belongs to #2231's pile) and the FilterBuilderDateRangePreset non-copy. Size/model suggestion: S-mechanical, sonnet.

Generated by Claude Code

Claim: PM loop round 13
Session: session_012u2pRjcqAYtoEjgr3wwhnK
Branch: claude/issue-4984-date-range-vocabulary
Domain: domain:ui (execution seat)

Thread read before dispatch. Triage scoped this on 2026-08-19 as both items in one PR:

Replace the hand-written defaultRange union with DateRangeDefaultRange imported from @objectstack/spec/ui — one line plus an import, which makes the "Aligned with spec" claim structural rather than asserted.
Add the label-half parity test: every DATE_RANGE_PRESETS member has an en key under dashboard.filters.range — a mirror of the existing bounds-half test at dashboard-filters.test.ts:475.

Triage's framing is worth keeping in view: both are tie-restoration on a vocabulary that is byte-faithful today — which is exactly when it is cheapest, and exactly when a pin is easiest to write badly, because everything passes either way.

⛔ Out of scope, per the card body's own boundary: the deliberately-looser zod twin (complex.zod.ts:444, ledgered — belongs to #2231's pile) and the FilterBuilderDateRangePreset non-copy. Neither is a miss; both are decided.

The pin's control is the whole risk here. A parity test over a vocabulary that already matches passes whether or not it can discriminate. Mirror the bounds-half test's shape, then give it its own mutation leg — remove one en key, or add a preset member with no label — and measure it red. A green parity test on a byte-faithful vocabulary is indistinguishable from a test that reads nothing.

Clause ②: importing a spec type in place of a local union should not move the published surface. Verify it rather than assume — clear dist/ and tsconfig.tsbuildinfo, compare the emitted .d.ts by hash, and report any movement.

⛔ OUT: packages/core/src/types/** and ComponentInput's convergence (#4972 this round — if your change reaches packages/types/src/complex.ts in a way that collides, report rather than edit), packages/data-objectstack/** (#5024), packages/components/** + content/docs/** (#5469), packages/plugin-calendar/** (#5045).

Generated by Claude Code

fix(types,i18n): bind dateRange.defaultRange to the spec, and pin the…

{
  "issue": 4984,
  "status": "done",
  "branch": "claude/issue-4984-date-range-vocabulary",
  "pr": "https://github.com/objectstack-ai/objectui/pull/5670",
  "premise_still_valid": true,
  "summary": "Both scoped items landed in one PR at 22b883bc7. (1) packages/types/src/complex.ts: the hand-written 14-member `defaultRange` union is replaced by `DateRangeDefaultRange` imported from `@objectstack/spec/ui` (aliased `SpecDateRangeDefaultRange`, matching the file's existing `Spec*` convention for `SpecDashboardWidget`/`SpecGlobalFilter`), making the file's \"Aligned with @objectstack/spec\" comment structural. Premise verified against origin/main before editing: the local union was byte-faithful — 14 members, same order as `DATE_RANGE_DEFAULT_RANGES` — so this is latent-drift repair, not a live bug. (2) New `packages/i18n/src/__tests__/dashboard-range-preset-labels-4984.test.ts` pins the LABEL half (3 assertions: non-vacuity guard, every preset has an `en` label, no orphan label), mirroring the bounds-half test's shape. Two placement decisions worth PM attention: the test lives in `@object-ui/i18n` rather than `packages/core` because the claim spans the vocabulary AND the locale packs, and i18n depends on core (core cannot reach the packs without inverting that edge); and it reads `DATE_RANGE_PRESETS` via `@object-ui/core` rather than importing `@objectstack/spec` directly, because spec is not a dependency of packages/i18n and `check:phantom-deps` would rightly object. THREE NOTES FOR THE PM, none blocking: (a) FENCE — `ComponentInput` does not appear in packages/types/src/complex.ts at all, so there is no semantic collision with #4972; the only overlap risk is textual, on the shared `@objectstack/spec/ui` import block at lines 18-22, which is a merge-conflict risk rather than an edit conflict. I did not touch anything else in that file. (b) A platform automation appended a SECOND copy of the session-URL footer (separated by `---`) to the PR body immediately after creation — my body already carried one. Per the standing rule that PR state I did not set belongs to another actor, I left it rather than 'correcting' it; future PRs from this seat should omit the footer. (c) CONTRACT CONFLICT, declared rather than silently resolved: the dispatch brief says to post the report as an issue comment only if it carries an open question or a filing (shared GitHub quota); the standing dev contract says deliver twice, GitHub first, unconditionally. I followed the standing contract — one API call is cheap next to losing the report if this process dies between PR push and the report turn.",
  "tests": "All results below at 22b883bc7 with a clean working tree; exit codes captured before any pipe, verdicts quoted from each gate's own output rather than from a bare $?.\nTESTS: `npx vitest run packages/i18n packages/core/src/utils/__tests__/dashboard-filters.test.ts --reporter=verbose --maxWorkers=2` -> exit 0, \"Test Files 52 passed (52) / Tests 925 passed (925)\", including both halves of the fan-out (the existing bounds-half pins and the 3 new label-half assertions).\nTYPE-CHECK (objectui spells it `type-check`, hyphenated; the script name was echoed in every run, so none was a zero-match pnpm no-op): `@object-ui/types` and `@object-ui/i18n` -> exit 0, both \"type-check: Done\"; plus the three packages that actually reference `defaultRange` (`@object-ui/core`, `@object-ui/plugin-dashboard`, `@object-ui/app-shell`) -> exit 0, all three \"type-check: Done\". Each dependency closure was built first (`pnpm --workspace-concurrency=2 --filter '<pkg>^...' build`, flag placed BEFORE --filter).\nGATES (all exit 0): check-changeset-presence \"2 source file(s) of 2 released package(s) changed, and this change declares 1 changeset(s)\"; changeset:check \"All workspace packages are in the changeset fixed group\" + \"No changeset declares a major bump\"; check:spec-symbols \"spec symbol derivation: 1291 files scanned against 4966 spec export names\"; check:control-bytes \"OK (scanned 4719 tracked text file(s))\"; check:phantom-deps \"Every in-scope import is declared by the package that publishes it\"; check:self-import \"No package names itself inside its own src/\"; check:i18n-keys \"Every in-scope call-site key resolves against the en pack (2919 keys)\"; check:i18n-drift \"No en value changed in this range\" (the locale packs are untouched — the ablation restored them, verified by hash); check:esm-specifiers \"no un-ledgered package emits an extensionless relative specifier\"; check:action-forward-parity; check-lint-coverage \"46/46 packages linted, 0 with outstanding errors\"; check-type-check-coverage \"45/46 via type-check\" + \"test type-check coverage: 41/41\". check:i18n-dead-keys is report-only by its own header and flagged nothing attributable here. NOT RUN, known-broken per the dispatch brief: check:eager-closure (exits 2 locally), check:doc-snippets (exits 1), check:published-dist (hits the cap) — plus the doc gates, since no docs changed.\nLINT: the repo's real gate form (`eslint .` per package, via pnpm --filter) exits 0 for both touched packages (warnings only, all pre-existing). A full-tree `eslint . --no-inline-config --format json` also completed locally in 342s: population 3524 files read from eslint's own --format json output (not from my guess of what counts), both changed files present in it, 0 errors on each. complex.ts carries 7 pre-existing no-explicit-any warnings at lines 94/169/264/338/421/718/723 — none inside my edited ranges (line 20, and 787-809); the new test file has 0 findings. eslint here is NOT type-aware (no projectService, no parserOptions.project in eslint.config.js), so this diff cannot move the verdict on any untouched file.\nABLATION / MUTATION LEGS — the parity test's own control, both measured RED, direction predicted before running. Predicted: each leg reddens exactly one assertion, the other two stay green. LEG A (delete the `last_90_days` en key): anchor asserted at exactly 1 occurrence BEFORE mutating (occurrences via `grep -o | wc -l`, not `grep -c`, which counts lines), re-read as 0 after, file hash changed -> vitest exit 1, \"Tests 1 failed | 2 passed\", `AssertionError: expected [ 'last_90_days' ] to deeply equal []` on \"every offered preset has an `en` label\". LEG B (inject `next_week: 'Next week',`, a label with no preset): injected text asserted at 0 occurrences before, 1 after -> vitest exit 1, \"Tests 1 failed | 2 passed\", `expected [ 'next_week' ] to deeply equal []` on \"has no orphan label\". Both legs restored and the restore VERIFIED BY HASH back to a16f3e78… with anchor counts back to 1 and 0; the whole script ran under `trap '<restore>' EXIT INT TERM` and the trap fired at exit.\nREBUILD STATEMENT for the ablation: no build step is owed by these legs, and that is measured rather than asserted. The root vitest config aliases `@object-ui/core` -> packages/core/src, and `../locales` is a relative source import, so neither side of the tie is served from a `dist/` that a stale build could hold green. A RED leg is itself the proof: had the test been reading built output, mutating packages/i18n/src/locales/en.ts would have left it GREEN.\nREVERSE VERIFICATION of the bound type against the REBUILT .d.ts, two legs with distinguishable exit codes (the first attempt returned exit 1 for BOTH legs on a spurious TS5112 — an unfalsifiable instrument — and was rerun with --ignoreConfig): a consumer assigning all 14 members compiles (exit 0); one assigning 'next_week' fails (exit 2) with `TS2322: Type '\"next_week\"' is not assignable to type '\"today\" | … | \"custom\" | undefined'`. The error enumerating the full union is the evidence the fresh emit was read, not a cache. The scratch files were created inside the worktree (so `@objectstack/spec` resolved) and deleted immediately; `git status` confirmed clean afterwards.",
  "dts_hash_comparison": {
    "method": "packages/types is `composite: true` with no tsBuildInfoFile, so its build info lands at packages/types/tsconfig.tsbuildinfo — OUTSIDE dist/, exactly the emit-skip trap. Both the baseline build and the after build cleared dist/ AND that file, with the clearance verified (\"dist gone? YES; tsbuildinfo gone? 0 remaining\") before each `tsc`. Had the build info survived, composite tsc would have skipped emit and 'no movement' would have been an artefact of the measurement.",
    "files_compared": 55,
    "files_moved": 1,
    "moved": {
      "file": "packages/types/dist/complex.d.ts",
      "before": "0781d2a81cdbd358c7f8fd42db536ccd6d0103f9b1a99567da3070382ce81ffd",
      "after": "79108900fea0ffa5a9c717aa68393a7aec0ae36801c0ef41bd1283bf2d945c86",
      "nature": "the inline 14-member union collapses to `defaultRange?: SpecDateRangeDefaultRange;`, plus the added named import on the emitted import line and the added doc comment. The other 54 .d.ts files are hash-identical."
    },
    "surface_movement": "NONE — measured with the TypeScript checker over the emitted declarations, never grepped, because `export *` propagates a symbol without naming it. Reachable exports from dist/index.d.ts: 679 before, 679 after. From dist/complex.d.ts: 22 before, 22 after. DashboardComponentSchema.dateRange.defaultRange resolves to the same 14 string-literal members on both sides. The two measurement JSONs are byte-identical (diff exit 0). `DateRangeDefaultRange` does NOT become a new export of @object-ui/types — it is an `import type` consumed inline, and the reachable-export count is unchanged."
  },
  "parity_test_mutation_leg": {
    "file": "packages/i18n/src/__tests__/dashboard-range-preset-labels-4984.test.ts",
    "leg_a": {
      "mutation": "delete the `last_90_days` key from en.dashboard.filters.range",
      "disk_confirmation": "anchor \"        last_90_days: 'Last 90 days',\\n\" asserted at exactly 1 occurrence before the edit (a python assert, so a zero-match would have raised rather than exiting 0 like sed/perl would), re-read at 0 occurrences after, file hash changed",
      "predicted": "RED on 'every offered preset has an `en` label', missing=['last_90_days']; other 2 green",
      "measured": "RED — vitest exit 1, Tests 1 failed | 2 passed, AssertionError: expected [ 'last_90_days' ] to deeply equal []"
    },
    "leg_b": {
      "mutation": "inject `next_week: 'Next week',` — a label with no matching preset",
      "disk_confirmation": "injected text asserted at 0 occurrences before, re-read at 1 after, file hash changed",
      "predicted": "RED on 'has no orphan label', orphans=['next_week']; other 2 green",
      "measured": "RED — vitest exit 1, Tests 1 failed | 2 passed, AssertionError: expected [ 'next_week' ] to deeply equal []"
    },
    "restore": "both legs restored from a pristine copy and verified BY HASH (a16f3e789e93df8847d0de8c48352a1968ca4f8d6505899462c3c4e8f6bf8458), anchor occurrence counts back to 1 and 0; script ran under trap '<restore>' EXIT INT TERM and the trap fired. `git status` and `check:i18n-drift` (\"0 en value(s) changed\") independently confirm the locale packs are untouched in the committed tree."
  },
  "open_questions": [],
  "out_of_scope_findings": []
}

Generated by Claude Code

fix(types,i18n): bind dateRange.defaultRange to the spec, and pin the…

Navigation Menu

Repository navigation

finding(types,i18n): after #4167 pinned PRESET_RANGES, two unpinned copies/consumers of the date-range vocabulary remain — the `defaultRange` TS union and the 10-locale label table #4984

Item 1 — `dateRange.defaultRange` is a hand-written copy of `DATE_RANGE_DEFAULT_RANGES`

Item 2 — the preset LABEL table has no tie to the vocabulary either

Not filed, deliberately

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

finding(types,i18n): after #4167 pinned PRESET_RANGES, two unpinned copies/consumers of the date-range vocabulary remain — the defaultRange TS union and the 10-locale label table #4984

Description

Item 1 — dateRange.defaultRange is a hand-written copy of DATE_RANGE_DEFAULT_RANGES

Item 2 — the preset LABEL table has no tie to the vocabulary either

Not filed, deliberately

Activity

os-support-ai commented on Aug 19, 2026

os-sales commented on Aug 22, 2026

claude commented on Aug 22, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

finding(types,i18n): after #4167 pinned PRESET_RANGES, two unpinned copies/consumers of the date-range vocabulary remain — the `defaultRange` TS union and the 10-locale label table #4984

Item 1 — `dateRange.defaultRange` is a hand-written copy of `DATE_RANGE_DEFAULT_RANGES`