@@ -207,23 +207,30 @@ export function resolveAnalyticsDateRangePreset(
  * condition, one wording), quoted rather than restated — asked for the
  * `'runtime'` ORIGIN, which is the one this constructor has.
  *
- * ⚠️ That argument is not decoration (#17598 item ②). Every refusal raised
- * here is raised PAST the schema door, so the sentence the spec used to return
- * unconditionally — "Refused at the schema" — was false for every one of
- * them, and sent an author to inspect a parse call that never ran. The origin
- * is a parameter precisely so this call site states the truth it alone knows;
- * ⛔ it is never omitted and there is no default to omit it to.
+ * ⚠️ That argument is not decoration (#17598 item ②). Every refusal whose
+ * MESSAGE leaves here is raised PAST the schema door, so the sentence the spec
+ * used to return unconditionally — "Refused at the schema" — was false for
+ * every one of them, and sent an author to inspect a parse call that never
+ * ran. The origin is a parameter precisely so this call site states the truth
+ * it alone knows; ⛔ it is never omitted and there is no default to omit it to.
+ * The one caller that keeps the `.code`/`.status` and DISCARDS the message is
+ * the REST dataset door, whose own refusal is the schema's — Reachability
+ * below says why that is not an exception to the sentence.
  *
  * ⚠️ The code is registered under `@objectstack/runtime` (the door that names
  * the wire vocabulary) and this package carries a recorded provenance waiver
  * in `error-code-ledger.zod.ts` — the shared-constructor shape, the same one
  * `UPDATE_ID_MISMATCH` records.
  *
- * Reachability: on `POST /analytics/query` and `/analytics/sql` the schema door
- * refuses first and this never fires. It is the answer for the in-process
- * caller past that door — `AnalyticsService.query`, a driver's cube face
- * called directly, and `POST /analytics/dataset/query`, which types
- * `selection.timeDimensions` from `AnalyticsQuery` but does not Zod-parse it.
+ * Reachability: on EVERY REST analytics route the schema door refuses first and
+ * this never fires. `POST /analytics/query` and `/analytics/sql` parse the whole
+ * body; `POST /analytics/dataset/query` has parsed its selection's shared
+ * members — `timeDimensions` included — against `AnalyticsQuerySchema.pick(…)`
+ * since #17058 (`rest/src/analytics-selection-door.ts`, wired ahead of the
+ * executor), so that route answers "Refused at the schema" and takes only this
+ * constructor's `.code`/`.status`. This is the answer for the IN-PROCESS caller
+ * past those doors — `AnalyticsService.query`, `queryDataset` and the dataset
+ * executor behind it, and a driver's cube face called directly.
  */
 export function analyticsDateRangeUnrecognizedError(input: unknown): Error {
   const err = new Error(analyticsDateRangeRefusalMessage(input, 'runtime')) as Error & {
 
@@ -371,3 +371,84 @@ describe('#17058 §5 — a valid selection still passes, and passes through unch
         }
     });
 });
+
+// ─────────────────────────────────────────────────────────────────────────────
+// §5 — [#17598] an arity refusal is ONE condition with ONE wording ON THE WIRE
+// ─────────────────────────────────────────────────────────────────────────────
+
+/**
+ * The array arm is `z.tuple([z.string(), z.string()])` since #17598, so a
+ * 1-element window is refused HERE — on the base it was not refused by the
+ * schema at all, which is why the arm's own `Too small` text only started
+ * riding the wire with that narrowing. The prescription already names the
+ * arity, so the arm's restatement is dropped in `fieldsFromZodIssues`
+ * (`@objectstack/types`), the one mapper both analytics doors share.
+ *
+ * ⚠️ These assert the SERVED BODY. The review that found the second wording
+ * recorded that nothing pinned the wire in either direction; at `error.issues`
+ * the union has always been a single issue, so an issue-level pin would have
+ * stayed green through exactly this defect.
+ */
+describe('#17598 §5 — the arity refusal carries one wording on the wire', () => {
+    const arities: Array<[string, unknown]> = [
+        ['one bound', ['2026-01-01']],
+        ['no bounds', []],
+        ['three bounds', ['2026-01-01', '2026-01-15', '2026-01-31']],
+    ];
+
+    for (const [name, dateRange] of arities) {
+        it(`${name}: the prescription, and NOT the arm's own arity text`, async () => {
+            const { res, queryDataset } = await post({
+                dataset: inlineDataset,
+                selection: {
+                    measures: ['revenue'],
+                    timeDimensions: [{ dimension: 'close_date', dateRange }],
+                },
+            });
+
+            expect(res.statusCode).toBe(400);
+            expect(res.body.code).toBe('ANALYTICS_DATE_RANGE_UNRECOGNIZED');
+            expect(res.body.message).toContain('not the two bounds [start, end]');
+            expect(res.body.message).not.toMatch(/Too (small|big)/);
+            // One entry for the member, so the `<field>: <message>` join names
+            // it once — the shape a second wording showed up as.
+            expect(String(res.body.message).match(/selection\.timeDimensions\.0\.dateRange/g))
+                .toHaveLength(1);
+            expect(queryDataset).not.toHaveBeenCalled();
+        });
+    }
+
+    it('a selection wrong in MORE than the dateRange keeps every other diagnosis', async () => {
+        // ⛔ The collapse is not a silencer: the generic envelope still carries
+        // the other member, and the dateRange condition appears exactly once.
+        const { res } = await post({
+            dataset: inlineDataset,
+            selection: {
+                measures: ['revenue'],
+                dimensions: 'region',
+                timeDimensions: [{ dimension: 'close_date', dateRange: ['2026-01-01'] }],
+            },
+        });
+
+        expect(res.statusCode).toBe(400);
+        expect(res.body.code).toBe('VALIDATION_FAILED');
+        const fields: Array<{ field: string; message: string }> = res.body.details.fields;
+        expect(fields.map((f) => f.field)).toContain('selection.dimensions');
+        expect(fields.filter((f) => f.field === 'selection.timeDimensions.0.dateRange'))
+            .toHaveLength(1);
+        expect(fields.some((f) => /Too (small|big)/.test(f.message))).toBe(false);
+    });
+
+    it('a non-string bound still names WHICH bound — that is a location, not a restatement', async () => {
+        const { res } = await post({
+            dataset: inlineDataset,
+            selection: {
+                measures: ['revenue'],
+                timeDimensions: [{ dimension: 'close_date', dateRange: ['2026-01-01', 3] }],
+            },
+        });
+
+        expect(res.statusCode).toBe(400);
+        expect(res.body.message).toContain('selection.timeDimensions.0.dateRange.1');
+    });
+});
@@ -76,7 +76,14 @@
  * own TSDoc names this route as the caller it was waiting for.
  *
  * The `message` is built the way the sibling builds it — `<field>: <message>`
- * joined — over `zodIssuesToFields`, the one ADR-0114 D3 mapper. Field paths
+ * joined — over `fieldsFromZodIssues` (`@objectstack/types`), which is
+ * `zodIssuesToFields`, the one ADR-0114 D3 mapper, plus the two things every
+ * HTTP boundary owes on top of it: the root-path rename, and [#17598] the drop
+ * of the date-range union's own arm RESTATEMENT, so an arity refusal reaches
+ * the wire with ONE wording rather than the prescription followed by zod's
+ * `Too small: expected array to have >=2 items`. That collapse lives in the one
+ * mapper both analytics doors share, ⛔ never as a second copy here — which is
+ * why this door reads the wrapper rather than the raw D3 function. Field paths
  * are prefixed `selection.` because they are reported against the REQUEST
  * body, where the parsed object sits one level down.
  *
@@ -86,7 +93,7 @@
  * not silently override the engine's own resolution chain).
  */
 
-import { zodIssuesToFields } from '@objectstack/spec/api';
+import { fieldsFromZodIssues } from '@objectstack/types';
 import { analyticsDateRangeUnrecognizedError } from '@objectstack/core';
 
 /**
@@ -166,9 +173,13 @@ export async function datasetSelectionRefusal(
     const parsed = schema.safeParse(projection);
     if (parsed.success) return undefined;
 
-    const issues: Array<{ code: string; path: ReadonlyArray<PropertyKey>; input?: unknown }> =
-        parsed.error.issues;
-    const fields = zodIssuesToFields(issues, projection).map((entry) => ({
+    const issues: Array<{
+        code: string;
+        path: Array<string | number | symbol>;
+        message: string;
+        input?: unknown;
+    }> = parsed.error.issues;
+    const fields = fieldsFromZodIssues(issues, projection).map((entry) => ({
         ...entry,
         field: `selection.${entry.field}`,
     }));
 
@@ -143,3 +143,47 @@ describe('#16041 — /analytics/query refuses an unrecognised dateRange string a
         expect(calls.query).toEqual([]);
     });
 });
+
+/**
+ * [#17598] The same door, the arity half. The array arm is exactly two string
+ * bounds now, so `['2026-01-01']` is refused here; the union's own issue is the
+ * prescription and names the arity, and the tuple arm's `Too small: expected
+ * array to have >=2 items` is that same condition in zod's words. One condition
+ * keeps one wording (#5240), ON THE WIRE — the served envelope, not
+ * `error.issues`, where the union has always been a single issue.
+ */
+describe('#17598 — an arity refusal carries one wording on the wire', () => {
+    const arities: Array<[string, unknown]> = [
+        ['one bound', ['2026-01-01']],
+        ['no bounds', []],
+        ['three bounds', ['2026-01-01', '2026-01-15', '2026-01-31']],
+    ];
+
+    for (const [name, dateRange] of arities) {
+        it(`${name}: the registered code, the prescription, and no second wording`, async () => {
+            const { res, calls } = await post('/analytics/query', body(dateRange));
+
+            expect(res.statusCode).toBe(400);
+            expect(res.body.error.code).toBe('ANALYTICS_DATE_RANGE_UNRECOGNIZED');
+            expect(res.body.error.message).toContain('not the two bounds [start, end]');
+            expect(res.body.error.message).not.toMatch(/Too (small|big)/);
+            expect(String(res.body.error.message).match(/timeDimensions\.0\.dateRange/g))
+                .toHaveLength(1);
+            expect(calls.query).toEqual([]);
+        });
+    }
+
+    it('a body wrong in MORE than the dateRange keeps the other diagnosis and still says the arity once', async () => {
+        const { res, calls } = await post('/analytics/query', body(['2026-01-01'], { granuarity: 'day' }));
+
+        expect(res.statusCode).toBe(400);
+        expect(res.body.error.code).toBe('VALIDATION_FAILED');
+        const fields: Array<{ field: string; code: string; message: string }> = res.body.error.details.fields;
+        // The typo'd key still speaks…
+        expect(fields.map((f) => f.code)).toContain('unknown_field');
+        // …and the dateRange condition is named exactly once, prescription only.
+        expect(fields.filter((f) => f.field === 'timeDimensions.0.dateRange')).toHaveLength(1);
+        expect(fields.some((f) => /Too (small|big)/.test(f.message))).toBe(false);
+        expect(calls.query).toEqual([]);
+    });
+});
@@ -219,10 +219,11 @@ describe('ObjectQLStrategy — timeDimensions[].dateRange (#3650)', () => {
           // [#17598] The array arm now types `dateRange` as EXACTLY two string
           // bounds, so this window no longer COMPILES — that is the schema door
           // doing its half of the same rule. The half THIS test pins is the
-          // face's own refusal for a caller past that door (`POST
-          // /analytics/dataset/query` types its selection from `AnalyticsQuery`
-          // and never Zod-parses it), so the value is still handed over and the
-          // type error is expected by name rather than the case deleted.
+          // face's own refusal for a caller past that door — an IN-PROCESS
+          // `AnalyticsService.query` / `queryDataset` call, never a REST route:
+          // every analytics route parses `timeDimensions` at its own door and
+          // answers "Refused at the schema". So the value is still handed over
+          // and the type error is expected by name rather than the case deleted.
           // @ts-expect-error — one bound is not a window; write the day twice
           timeDimensions: [{ dimension: 'close_date', dateRange: ['2026-01-20'] }],
         },
 
@@ -406,9 +406,13 @@ function describeRefusedDateRange(input: unknown): string {
  * Where the refusal happened is the one clause no INPUT can supply: the same
  * value is refused at parse time by {@link AnalyticsDateRangeSchema} and, for a
  * caller past that door, in-process by `analyticsDateRangeUnrecognizedError`
- * (`@objectstack/core`) — `AnalyticsService.query`, a driver's cube face called
- * directly, `POST /analytics/dataset/query`, which types its selection from
- * `AnalyticsQuery` but never Zod-parses it. Until this parameter existed the
+ * (`@objectstack/core`) — `AnalyticsService.query`, `queryDataset` and the
+ * dataset executor behind it reached IN PROCESS, and a driver's cube face
+ * called directly. ⚠️ Every REST analytics route is a SCHEMA-origin door,
+ * `POST /analytics/dataset/query` included: since #17058 that route parses its
+ * selection's shared members — `timeDimensions` among them — against
+ * `AnalyticsQuerySchema.pick(…)` ahead of the executor, so that route's
+ * refusal is THIS schema's and says so. Until this parameter existed the
  * shared sentence asserted the SCHEMA origin for both, so an author refused past
  * the door was sent to inspect a parse call that never ran; the one package that
  * noticed (`service-analytics`, #17593) had to OVERWRITE the message instead of
 
@@ -17,7 +17,11 @@
  */
 
 import { describe, it, expect } from 'vitest';
-import { FieldErrorCode, MarkNotificationsReadRequestSchema } from '@objectstack/spec/api';
+import {
+    AnalyticsQueryRequestSchema,
+    FieldErrorCode,
+    MarkNotificationsReadRequestSchema,
+} from '@objectstack/spec/api';
 import { FlowSchema } from '@objectstack/spec/automation';
 import { fieldsFromZodIssues } from './validation-failure';
 
@@ -101,3 +105,74 @@ describe('fieldsFromZodIssues — ADR-0114 D3 catalog codes, not Zod codes (#812
         expect(informed.find((f) => f.field.endsWith('label'))?.code).toBe('required');
     });
 });
+
+/**
+ * [#17598] ONE condition, ONE wording — for the `timeDimensions[].dateRange`
+ * refusal, on the wire and not merely at `error.issues`.
+ *
+ * `AnalyticsDateRangeSchema` is a `z.union` carrying its own error map, so the
+ * single issue zod raises is already a prescription AND already names the
+ * arity ("received a 1-element array, not the two bounds [start, end]"). Its
+ * tuple arm complains about the same value at the same path in zod's own words
+ * ("Too small: expected array to have >=2 items"), and the #5014 union
+ * expansion put both on the wire — one condition, two wordings, which is what
+ * the #5240 convention exists to prevent and what `analytics.zod.ts` claims for
+ * this refusal.
+ *
+ * Before #17598 the arm was `z.array(z.string())` with no length constraint, so
+ * a 1-element window was not refused by the schema at all and there was no
+ * second wording to have; the narrowing is what introduced it, and this is
+ * where it is collapsed. The two edge cases below are as load-bearing as the
+ * collapse itself: this narrows a RESTATEMENT, never a diagnosis.
+ */
+describe('fieldsFromZodIssues — the dateRange refusal keeps one wording (#17598)', () => {
+    const analyticsBody = (dateRange: unknown) => ({
+        cube: 'orders',
+        measures: ['count'],
+        timeDimensions: [{ dimension: 'created_at', granularity: 'day', dateRange }],
+    });
+
+    const arities: Array<[string, unknown]> = [
+        ['a 1-element window', ['2026-01-01']],
+        ['an empty array', []],
+        ['three bounds', ['2026-01-01', '2026-01-15', '2026-01-31']],
+    ];
+
+    for (const [name, dateRange] of arities) {
+        it(`${name} maps to exactly one entry, and it is the prescription`, () => {
+            const fields = fieldsFromZodIssues(
+                issuesOf(AnalyticsQueryRequestSchema, analyticsBody(dateRange)),
+            );
+            expect(fields).toHaveLength(1);
+            expect(fields[0].field).toBe('timeDimensions.0.dateRange');
+            expect(fields[0].message).toContain('not the two bounds [start, end]');
+            // ⛔ The arm's own arity text is the second wording, and it is gone.
+            expect(fields[0].message).not.toMatch(/Too (small|big)/);
+        });
+    }
+
+    it('a NON-string bound keeps the branch entry naming WHICH bound is wrong', () => {
+        // The prescription says "an array with a non-string bound"; it does not
+        // say WHICH one. `dateRange.1` names a position the prescription has
+        // not, so it is a diagnosis rather than a restatement and it stays.
+        const fields = fieldsFromZodIssues(
+            issuesOf(AnalyticsQueryRequestSchema, analyticsBody(['2026-01-01', 3])),
+        );
+        expect(fields.map((f) => f.field)).toContain('timeDimensions.0.dateRange');
+        expect(fields.map((f) => f.field)).toContain('timeDimensions.0.dateRange.1');
+    });
+
+    it('CONTROL — a branch issue at its own branch ROOT still reaches the wire for every other key', () => {
+        // `unrecognized_keys` is raised at the BRANCH root — structurally the
+        // same position as the tuple arm's arity text — and it carries the
+        // #4001 campaign's curated prose. If the collapse above were written as
+        // "drop branch issues at the union's own path" rather than keyed on the
+        // date-range recogniser, this is the family it would have silenced.
+        const fields = fieldsFromZodIssues(issuesOf(FlowSchema, {
+            ...WELL_FORMED_FLOW,
+            nodes: [{ id: 'n', type: 'notify', label: 'Notify', next: 'other' }],
+        }));
+        expect(fields.map((f) => f.code)).toContain('unknown_field');
+        expect(fields.some((f) => f.message.includes('next'))).toBe(true);
+    });
+});