The driver-memory cube face does not resolve {date-macro} tokens in an explicit dateRange array. It does not refuse them either — it silently matches all of history, while its own refusal text advertises that tokens are accepted.
Filed by the domain:spec execution seat, session session_01MkQhmuuJAVDjmeWNixwDDH, 2026-09-13T08:53Z, out of the at-tier post-hoc contract review of merged PR #17015. ⛔ No domain:* or priority:* applied — routing and grading are triage's.
The measurement
A probe run in three dedicated worktrees — merge base 419facdd, merged head 0da638cd, and today's origin/main 2c87a48f — with the clock frozen at 2026-09-09T12:34:56.789Z, TZ=UTC, and five dated rows (2020-01-01, 2026-08-31, 2026-09-05, now, 2099-01-01), each ref source-aliased so it parses against its own schema:
| input |
door (AnalyticsQuerySchema) |
face (MemoryAnalyticsService.query) |
['{7_days_ago}','{today}'] |
ACCEPTED |
5/5 rows — at all three refs, including 2020 and 2099 |
['2026-09-01','2026-09-30'] (positive control) |
ACCEPTED |
2/5 |
today + unknown cube (negative control) |
ACCEPTED |
REFUSED Cube not found |
⇒ a seven-day window returns a row from 2099. Unchanged by #17015 — this is not a regression that PR introduced, it is a hole on the seam that PR built next to.
Why the silence is the defect, not the behaviour
packages/drivers/driver-memory/src/memory-analytics.ts:780 (from #17593) tells the caller the explicit window takes "ISO dates or {date-macro} tokens". The face does not resolve them. So the one place an author would look to find out whether tokens work says yes, and the face answers as if the bound were absent.
This is the fourth state ADR-0078 prohibits: parsed, unmarked, silently inert. A refusal would be fine. All-of-history with no marking is the shape that ships a wrong number into a dashboard and looks like data.
Who is actually exposed
Served doors resolve the macros first — analytics-service.ts:1117 and dataset-executor.ts:121 — so a caller going through AnalyticsService / queryDataset is safe. Exposed is a host calling the driver-level IAnalyticsService directly, which is exactly the population PR #17015 chose to refuse for the string arm. ⇒ the string arm of that population is now protected and the array arm is not, which is an inconsistency inside one face rather than a missing feature.
⚠️ Population size is NOT MEASURED: new MemoryAnalyticsService appears 0 times in non-test code (hosts register it), so how many direct callers exist outside this repo is unknown. That bears on priority, ⛔ not on whether the shape is wrong.
The repair
Either resolve {date-macro} tokens at the face, or refuse an unresolved token by name — ⛔ never accept-and-ignore. And add a macro case to ANALYTICS_DATE_RANGE_EXPLICIT_WINDOW in the conformance kit: today it is two ISO instants and contains 0 occurrences of '{, so the kit cannot see this gap at all. A kit that cannot express the case will not catch it on the next face either.
Generated by Claude Code
The driver-memory cube face does not resolve
{date-macro}tokens in an explicitdateRangearray. It does not refuse them either — it silently matches all of history, while its own refusal text advertises that tokens are accepted.Filed by the
domain:specexecution seat, sessionsession_01MkQhmuuJAVDjmeWNixwDDH, 2026-09-13T08:53Z, out of the at-tier post-hoc contract review of merged PR #17015. ⛔ Nodomain:*orpriority:*applied — routing and grading are triage's.The measurement
A probe run in three dedicated worktrees — merge base
419facdd, merged head0da638cd, and today'sorigin/main2c87a48f— with the clock frozen at2026-09-09T12:34:56.789Z, TZ=UTC, and five dated rows (2020-01-01, 2026-08-31, 2026-09-05, now, 2099-01-01), each ref source-aliased so it parses against its own schema:AnalyticsQuerySchema)MemoryAnalyticsService.query)['{7_days_ago}','{today}']['2026-09-01','2026-09-30'](positive control)today+ unknown cube (negative control)Cube not found⇒ a seven-day window returns a row from 2099. Unchanged by #17015 — this is not a regression that PR introduced, it is a hole on the seam that PR built next to.
Why the silence is the defect, not the behaviour
packages/drivers/driver-memory/src/memory-analytics.ts:780(from #17593) tells the caller the explicit window takes "ISO dates or{date-macro}tokens". The face does not resolve them. So the one place an author would look to find out whether tokens work says yes, and the face answers as if the bound were absent.This is the fourth state ADR-0078 prohibits: parsed, unmarked, silently inert. A refusal would be fine. All-of-history with no marking is the shape that ships a wrong number into a dashboard and looks like data.
Who is actually exposed
Served doors resolve the macros first —
analytics-service.ts:1117anddataset-executor.ts:121— so a caller going throughAnalyticsService/queryDatasetis safe. Exposed is a host calling the driver-levelIAnalyticsServicedirectly, which is exactly the population PR #17015 chose to refuse for the string arm. ⇒ the string arm of that population is now protected and the array arm is not, which is an inconsistency inside one face rather than a missing feature.new MemoryAnalyticsServiceappears 0 times in non-test code (hosts register it), so how many direct callers exist outside this repo is unknown. That bears on priority, ⛔ not on whether the shape is wrong.The repair
Either resolve
{date-macro}tokens at the face, or refuse an unresolved token by name — ⛔ never accept-and-ignore. And add a macro case toANALYTICS_DATE_RANGE_EXPLICIT_WINDOWin the conformance kit: today it is two ISO instants and contains 0 occurrences of'{, so the kit cannot see this gap at all. A kit that cannot express the case will not catch it on the next face either.Generated by Claude Code