test(cli): pin ALLOW_TOKEN_MAP against ALLOW_TOKENS in the drift guard

allow-tokens-pinned.test.ts covered ALLOW_TOKENS (the --allow validator) and
sdk's AllowTokenEnum, but not ALLOW_TOKEN_MAP (lib/allow.ts) — the structure
that actually grants a validated token's permission. A token present in
ALLOW_TOKENS but missing from the map would pass validation cleanly and
tokensToAllowOptions would silently grant nothing for it: --allow <token>
looks accepted but authorizes no destructive drop, and the diff blocks it
anyway with no indication the flag was ever a no-op. Same drift class that
left adopt-view broken in sdk's config schema since 0.20.4, but worse here
because there's no error to notice.

- cli/src/lib/allow.ts: export ALLOW_TOKEN_MAP (was module-local) so the
  test can import the real structure instead of a hardcoded copy.
- allow-tokens-pinned.test.ts: two new assertions — ALLOW_TOKEN_MAP's key
  set matches ALLOW_TOKENS in both directions, and its AllowOptions values
  are unique (no two tokens silently grant the same permission).

Verified non-vacuous: removing an entry from ALLOW_TOKEN_MAP makes the new
assertion fail (confirmed with adopt-view specifically); restoring it goes
green again.

Author: dmealing

server/typescript/packages/cli/src/lib/allow.ts

@@ -5,7 +5,12 @@
 import type { AllowOptions, Change } from "@metaobjectsdev/migrate-ts";
 
 // Map CLI allow tokens → migrate-ts AllowOptions field names.
-const ALLOW_TOKEN_MAP: Record<string, keyof AllowOptions> = {
+// Exported (not just module-local) so allow-tokens-pinned.test.ts can pin its
+// key set against ALLOW_TOKENS (args.ts). ALLOW_TOKENS is the *validator* —
+// this map is what actually *grants* the permission; a token present in
+// ALLOW_TOKENS but missing here would pass validation and silently grant
+// nothing, on a destructive operation.
+export const ALLOW_TOKEN_MAP: Record<string, keyof AllowOptions> = {
   "drop-column": "dropColumn",
   "drop-table": "dropTable",
   "type-change": "typeChange",

server/typescript/packages/cli/test/unit/allow-tokens-pinned.test.ts

@@ -1,18 +1,33 @@
 /**
- * Drift guard between the CLI's authoritative `--allow` token list
- * (`ALLOW_TOKENS`, `lib/args.ts` — the list that actually validates
- * `--allow <csv>`) and `sdk`'s `AllowTokenEnum` (`config.ts` — the list that
- * validates the STATIC `migrate.allow` array in `.metaobjects/config.json`).
+ * Drift guard across the three token-bearing structures behind `--allow`:
  *
- * These silently drifted before this test existed: sdk's enum had only 6 of
- * the 11 real tokens, missing `drop-check`, `drop-view`, `drop-view-cascade`,
- * `adopt-view` and `drop-identity-default`. A user who set any of those five
- * in `.metaobjects/config.json`'s `migrate.allow` got a schema rejection for
- * a flag the CLI itself accepted fine on the command line — `adopt-view` had
+ * - `ALLOW_TOKENS` (`lib/args.ts`) — the CLI's authoritative list; what
+ *   actually VALIDATES `--allow <csv>`.
+ * - `AllowTokenEnum` (`sdk`'s `config.ts`) — validates the STATIC
+ *   `migrate.allow` array in `.metaobjects/config.json`.
+ * - `ALLOW_TOKEN_MAP` (`lib/allow.ts`) — what actually GRANTS the permission,
+ *   translating a validated token into the `AllowOptions` field `diff()`
+ *   reads.
+ *
+ * `ALLOW_TOKENS` and `AllowTokenEnum` silently drifted before this test
+ * existed: sdk's enum had only 6 of the 11 real tokens, missing
+ * `drop-check`, `drop-view`, `drop-view-cascade`, `adopt-view` and
+ * `drop-identity-default`. A user who set any of those five in
+ * `.metaobjects/config.json`'s `migrate.allow` got a schema rejection for a
+ * flag the CLI itself accepted fine on the command line — `adopt-view` had
  * shipped since 0.20.4 and was affected the whole time.
  *
- * Import BOTH sides rather than hardcoding a third "expected" list here — a
- * hardcoded list would just be a fourth copy that can itself drift.
+ * `ALLOW_TOKEN_MAP` is a distinct, worse failure mode if it drifts from
+ * `ALLOW_TOKENS`: a token present in `ALLOW_TOKENS` (and `AllowTokenEnum`)
+ * but missing from the map passes validation cleanly and then
+ * `tokensToAllowOptions` silently grants NOTHING for it — the user believes
+ * `--allow <token>` authorized a destructive drop; it didn't, and the diff
+ * blocks it anyway with no indication the flag was ever a no-op. That is a
+ * silent-failure mode on exactly the path this whole feature exists to
+ * protect.
+ *
+ * Import ALL of these rather than hardcoding a fourth "expected" list here —
+ * a hardcoded list would just be a fifth copy that can itself drift.
  *
  * Package-dependency direction: `cli` depends on `sdk` (`workspace:*`), not
  * the other way around, so this test can only live in `cli` — `sdk` cannot
@@ -22,6 +37,7 @@
  */
 import { test, expect, describe } from "bun:test";
 import { ALLOW_TOKENS } from "../../src/lib/args.js";
+import { ALLOW_TOKEN_MAP } from "../../src/lib/allow.js";
 import { AllowTokenEnum } from "@metaobjectsdev/sdk";
 
 describe("--allow token lists stay pinned across packages", () => {
@@ -36,4 +52,22 @@ describe("--allow token lists stay pinned across packages", () => {
     expect(missingFromCli).toEqual([]);
     expect(sdkTokens.size).toBe(cliTokens.size);
   });
+
+  test("ALLOW_TOKEN_MAP grants a permission for every validated token, and nothing extra", () => {
+    const cliTokens = new Set<string>(ALLOW_TOKENS);
+    const mapKeys = new Set<string>(Object.keys(ALLOW_TOKEN_MAP));
+
+    const validatedButNotGranted = [...cliTokens].filter((t) => !mapKeys.has(t));
+    const grantedButNotValidated = [...mapKeys].filter((t) => !cliTokens.has(t));
+
+    expect(validatedButNotGranted).toEqual([]);
+    expect(grantedButNotValidated).toEqual([]);
+    expect(mapKeys.size).toBe(cliTokens.size);
+  });
+
+  test("ALLOW_TOKEN_MAP's AllowOptions fields are unique — no two tokens grant the same permission", () => {
+    const fields = Object.values(ALLOW_TOKEN_MAP);
+    const uniqueFields = new Set(fields);
+    expect(uniqueFields.size).toBe(fields.length);
+  });
 });