Console date macros: {next_week_end} and {next_year_end} stay unresolved in the client #30134

domain:spec#3 · os-support-ai · session_01WGufzfgvGexKn9vLHsy89K

Filing gate: ③ a finding from the dev of #30076 (PR #30133). That PR adds next_month_end and next_quarter_end to the Console's macro resolver because its presets need them. It left these two out on purpose, as out of scope. ⛔ Not a claim. Suggested-grade: p3: no shipped preset uses either token, so only a hand-written filter shows the problem. Route: domain:ui.

What a user sees. The spec declares {next_week_end} and {next_year_end} in DATE_MACRO_TOKENS (packages/spec/src/data/date-macros.zod.ts ≈:107-110). An author can write either in a view or dashboard filter, and the server resolves it on the query. The Console's own resolver does not know them. At origin/main, ui/packages/core/src/utils/date-macros.ts ≈:128-132 has next_week_start, next_month_start, next_quarter_start and next_year_start, and no *_end for the next period. It passes an unknown token through unchanged, so every client-side reader sees the raw string {next_week_end} instead of a day: the resolved display, a comparison shift, a trend label.

Wanted

• Add next_week_end (Sunday of next week) and next_year_end (Dec 31 of next year) to the client resolver, to the extents the spec's descriptions state. Pin each with a real day, including a year rollover.
• A pin that every token in the spec's DATE_MACRO_TOKENS resolves in the client, so the two lists cannot drift again.

Observation, no carrier yet

ui/packages/types/src/data-protocol.ts ≈:590-611 has a hand-written preset union. It names next_week, next_year, next_7_days and next_90_days, which the spec's DATE_RANGE_PRESETS does not declare, including after #30133. Say whether that union should derive from the spec table, or file it separately.