@@ -0,0 +1,19 @@
+---
+'@objectstack/spec': patch
+---
+
+A top-level report now corrects the same ten misspelled keys a joined-report block already corrects. Before this change, `measures:` on a plain report was rejected with no suggestion, while the same key on a block was told to use `values`.
+
+Clause-②: no
+
+`ReportSchema`'s alias table says it is kept parallel to `JoinedReportBlockSchema`'s, but ten of the block's entries were missing from it. The rejection now names the target key, and every target is a key the report declares:
+
+| authored key on a report | before | now |
+| :--- | :--- | :--- |
+| `measures`, `metrics` | no suggestion | ``Did you mean `measures` → `values`?`` |
+| `dimensions`, `groupBy`, `groupings` | no suggestion | ``Did you mean `dimensions` → `rows`?`` |
+| `sort`, `sortBy` | no suggestion | ``Did you mean `sort` → `order`?`` |
+| `orderBy` | `order`, found by edit distance | `order`, from the alias table |
+| `objectName`, `object` | no suggestion | ``Did you mean `objectName` → `dataset`?`` |
+
+**Every accept/reject verdict is unchanged.** The same reports are refused, with the same `unrecognized_keys` issue. Only the prescription in that issue's message is new. Nothing authorable is added, removed or renamed.
@@ -114,10 +114,12 @@
 //     with `rows`, in the rejection message, and the `order` refinement names
 //     both halves in one live sentence ("name a `rows`/`columns` dimension or a
 //     `values` measure").
-//   • ⭐ AND THE TWO VOCABULARIES ARE ASYMMETRIC, which is why the sentence has
-//     to exist: the alias table that converts them lives on the BLOCK and not
-//     on the top-level report. That asymmetry is asserted as a reading, ⛔ not
-//     repaired here — it is a spec-side edit outside this round's file surface.
+//   • ⭐ AND THE TWO VOCABULARIES ARE DISTINCT, which is why the sentence has to
+//     exist: the schema converts one into the other only in a rejection
+//     message. That alias table lives on the block AND on the top-level report.
+//     This round recorded it on the block only, as a reading it did not
+//     repair; #19822 closed the gap in the spec, and the reading is reversed in
+//     place below.
 //
 // ## ⚠️ The renderings depart from a literal mapping, and the row says why
 //
@@ -629,15 +631,17 @@ describe('#19403 round 9 — the semantic layer, asserted AT THE SCHEMA', () =>
     expect(issueMessages(order)).toContain('name a `rows`/`columns` dimension or a `values` measure');
   });
 
-  it('⚠️ A READING, ⛔ NOT A REPAIR — the alias table is on the BLOCK and not on the top-level report', () => {
-    // The same two keys, the same two target keys, one level apart: the block
-    // answers with the rename, the report answers with a bare unrecognised-key
-    // error. Recorded as a finding in this round's PR, ⛔ not fixed here — it is
-    // an edit to `packages/spec/src/ui/report.zod.ts`, outside this round's file
-    // surface, and it does not discharge any row above.
+  it('⭐ the alias table answers at BOTH levels — the top-level report renames `measures` onto `values` like the block', () => {
+    // The same key, the same target key, one level apart, and now the same
+    // answer: the block and the top-level report both refuse `measures` AND name
+    // `values` in the rejection. This pin used to record the opposite — the
+    // report answered with a bare unrecognised-key error — as a reading this
+    // round did not repair. #19822 closed that gap in
+    // `packages/spec/src/ui/report.zod.ts`, so the reading is reversed in place
+    // rather than deleted. It still discharges no row above.
     const onReport = ReportSchema.safeParse({ ...MINIMAL_REPORT, measures: ['revenue'] });
     expect(onReport.success).toBe(false);
-    expect(issueMessages(onReport)).not.toContain('Did you mean');
+    expect(issueMessages(onReport)).toContain('`measures` → `values`');
     const onBlock = ReportSchema.safeParse({
       name: 'joined_report',
       label: 'Joined',
 
@@ -10,6 +10,7 @@ import {
   JoinedReportBlockSchema,
   reportSelectionOrder,
 } from './report.zod';
+import { strictObjectDeclarations } from '../shared/strict-object';
 
 /**
  * ADR-0021 single-form: a report binds a `dataset` and selects `rows`
@@ -248,6 +249,92 @@ describe('ReportSchema — scope-filter aliases point at `runtimeFilter` (#5013)
   });
 });
 
+/**
+ * The selection and ordering spellings a block already corrects, pinned by
+ * PARSE on the top-level report — the surface where they were missing.
+ *
+ * `ReportSchema`'s table says it is kept parallel to the block's, and ten of
+ * the block's entries were absent from it: `measures:` on a plain report was
+ * refused with no suggestion at all, while the same key one level down was
+ * told `values`. Measured before the fix, nine of the ten got no suggestion;
+ * `orderBy` alone reached `order` by edit distance.
+ *
+ * Two halves, as in the scope-filter block above: what the author SEES (the
+ * rejection names the prescribed key), and that taking the advice parses.
+ */
+describe('ReportSchema — routes the block vocabulary the way a block does', () => {
+  const VALID = {
+    name: 'pipeline', label: 'Pipeline', type: 'summary',
+    dataset: 'sales', rows: ['stage'], values: ['revenue'],
+  } as const;
+
+  /** A value the TARGET key accepts on `VALID`, so the advice can be taken verbatim. */
+  const VALUE_FOR: Record<string, unknown> = {
+    values: ['revenue'],
+    rows: ['stage'],
+    order: [{ by: 'revenue', direction: 'desc' }],
+    dataset: 'sales',
+  };
+
+  const ROUTES: ReadonlyArray<readonly [string, string]> = [
+    ['measures', 'values'],
+    ['metrics', 'values'],
+    ['dimensions', 'rows'],
+    ['groupBy', 'rows'],
+    ['groupings', 'rows'],
+    ['sort', 'order'],
+    ['orderBy', 'order'],
+    ['sortBy', 'order'],
+    ['objectName', 'dataset'],
+    ['object', 'dataset'],
+  ];
+
+  it.each(ROUTES)('`%s` on a top-level report is renamed onto `%s`', (key, target) => {
+    const r = ReportSchema.safeParse({ ...VALID, [key]: VALUE_FOR[target] });
+    expect(r.success, `\`${key}\` must still be rejected — it is not a declared key`).toBe(false);
+    const issue = r.error!.issues.find((i) => i.code === 'unrecognized_keys');
+    expect(issue, `\`${key}\` must be refused as an unknown key`).toBeDefined();
+    expect((issue as { keys?: readonly string[] }).keys).toEqual([key]);
+    expect(issue!.message).toContain(`Did you mean \`${key}\` → \`${target}\`?`);
+  });
+
+  it.each(ROUTES)('taking the advice for `%s` parses — `%s` is a key this report accepts', (_key, target) => {
+    const r = ReportSchema.safeParse({ ...VALID, [target]: VALUE_FOR[target] });
+    expect(r.success, JSON.stringify(r.error?.issues ?? [])).toBe(true);
+  });
+
+  /**
+   * The parity claim itself, derived from the two tables at runtime rather
+   * than from a list: every key the block routes to a target this schema also
+   * declares is routed here, to the same target — or, where a key must not
+   * route at the top level, answered by a `guidance` entry that says why.
+   * Never silence.
+   */
+  it('every block alias whose target the report declares is routed here too, to the same target', () => {
+    // Force both lazy schemas so their declarations are registered.
+    ReportSchema.safeParse(VALID);
+    JoinedReportBlockSchema.safeParse({ ...VALID, type: 'tabular' });
+    const declarationOf = (surface: string) => {
+      const found = strictObjectDeclarations().filter((d) => d.options.surface === surface);
+      expect(found, `exactly one declaration answers to "${surface}"`).toHaveLength(1);
+      return found[0]!;
+    };
+    const block = declarationOf('this joined report block');
+    const top = declarationOf('this report');
+
+    const judged = Object.entries(block.options.aliases ?? {}).filter(([, target]) => target in top.shape);
+    // Not vacuous: the derivation reaches every key this pin was written for.
+    expect(judged.map(([key]) => key)).toEqual(expect.arrayContaining(ROUTES.map(([key]) => key)));
+
+    const topAliases = top.options.aliases ?? {};
+    const topGuidance = top.options.guidance ?? {};
+    const silentOrDivergent = judged
+      .filter(([key, target]) => topAliases[key] !== target && !(key in topGuidance))
+      .map(([key, target]) => `${key} → ${target} (top level: ${topAliases[key] ?? 'absent'})`);
+    expect(silentOrDivergent).toEqual([]);
+  });
+});
+
 describe('ReportChartSchema', () => {
   it('requires xAxis + yAxis', () => {
     expect(ReportChartSchema.parse({ type: 'bar', xAxis: 'stage', yAxis: 'revenue' }).type).toBe('bar');
 
@@ -251,8 +251,13 @@ export const ReportSchema = lazySchema(() => strictObject({
     'Until this shape was closed these were dropped silently — the item still registered, minus whatever the key was meant to configure.',
   // Kept deliberately parallel to `JoinedReportBlockSchema` above: a block is a
   // sub-report, so an author who learns one vocabulary must not be corrected
-  // differently on the other. The scope-filter entries are that table's,
-  // verbatim.
+  // differently on the other. Every block entry whose target this schema also
+  // declares is carried here, to the same target — today, every one of them —
+  // and `report.test.ts` derives that parity from the two tables at runtime. A
+  // key that must NOT route here gets a `guidance` line saying why, never
+  // silence. The `guidance` tables do differ, on purpose: the block's three are
+  // wrong-layer pointers to keys this schema declares, and `drillDown` below
+  // disambiguates this schema's own `drilldown` boolean, which a block lacks.
   //
   // #5013 — `filter` used to point at `filters`, a key `ReportSchema` does not
   // declare either, so taking the advice earned a SECOND rejection and that one
@@ -262,15 +267,41 @@ export const ReportSchema = lazySchema(() => strictObject({
   // only from the `unrecognized_keys` path — and `chartConfig` was not a key
   // either. `alias-integrity.test.ts` now proves both halves for every table in
   // the package.
+  //
+  // The parallel claim above was not true when it was first written: the ten
+  // selection and ordering spellings below existed only on the block, so
+  // `measures:` on a plain report was refused with no suggestion while the
+  // same key one level down was told `values`. Of the ten, only `orderBy`
+  // reached its target by edit distance alone.
   aliases: {
-    dataSet: 'dataset', source: 'dataset',
+    // ADR-0021 single-form: the legacy inline query was removed in the cutover.
+    // These are the spellings that cutover retired, aimed at their successors.
+    objectName: 'dataset',
+    object: 'dataset',
+    dataSet: 'dataset',
+    source: 'dataset',
+    // A report selects measures by name; `columns` is a real key here (the
+    // matrix across-axis), so the value list cannot borrow it — hence the
+    // explicit map.
     fields: 'values',
+    measures: 'values',
+    metrics: 'values',
+    groupings: 'rows',
+    groupBy: 'rows',
+    dimensions: 'rows',
     // Scope filter. `runtimeFilter` is camelCase, so the edit-distance fallback
     // under-reaches every one of these (#4990) — same as on a block.
     filter: 'runtimeFilter',
     filters: 'runtimeFilter',
     where: 'runtimeFilter',
     criteria: 'runtimeFilter',
+    // Ordering, spelled as the objectql/dashboard surfaces spell it. On a
+    // `joined` report the prescribed `order` is itself refused, with the
+    // pointer onto `blocks[]` — the same answer the author would get for
+    // writing `order` directly.
+    sort: 'order',
+    orderBy: 'order',
+    sortBy: 'order',
   },
   guidance: {
     // #5022 — the reverse half of a two-way disambiguation. The forward half