@@ -7,6 +7,25 @@ this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.htm
 
 ## [Unreleased]
 
+### Fixed — ADR-0034's removal diagnostic had one door, and adopters arrive through two
+
+1.0 removed `entityFile` / `queriesFile` / `routesFile` / `barrel` from
+`@metaobjectsdev/codegen-ts/generators`, and `removedGeneratorImportError` turns that into a
+message naming the export, the `meta eject` command and the guide — **when the config file
+itself carries the import**. A polyglot adopter arrived the other way: its
+`metaobjects.config.ts` imported an OWNED generator (`./codegen/generators/entityFileTyped`,
+the exact shape `meta eject` writes), and THAT file held the stale import. The source scan
+saw a clean config, and what the adopter got was
+`(0 , _generators.entityFile) is not a function`, exit 2 — no file, no symbol origin, no
+remedy. Precisely the failure the first door exists to prevent.
+
+`removedGeneratorRuntimeError` is the second door: the config load now catches the throw and,
+when the message names a removed export, rethrows the migration guidance. It cannot name the
+file — the TypeError carries no reference back to the import — so it names what it does know,
+including where the import usually lives (`codegen/generators/`). Matching is on the SYMBOL,
+not the message shape, because the shape belongs to whichever transpiler ran.
+
+
 ### Fixed — both advisory scanners reported findings inside BUILD OUTPUT
 
 `meta verify` on an adopter estate reported
 
@@ -141,10 +141,14 @@ function resolveCliPkg(specifier: string): string {
  * the supported home of the generators with no ownable copy), so nothing upstream of here
  * can tell a correct import from a removed one.
  *
- * It reads the config SOURCE rather than catching the throw because the throw happens inside
- * a generator factory call with no reference back to the import that produced it, and only a
- * config declaring one of these in `generators: [...]` throws at all — a stale type-only
- * import would fail silently at typecheck-time instead.
+ * It reads the config SOURCE because that is the arm that can name the FILE and the exact
+ * import. `removedGeneratorRuntimeError` below is the second arm, and an adopter estate is
+ * why there are two: the import does not have to be in the config. This project's config
+ * imported an OWNED generator — `./codegen/generators/entityFileTyped`, the shape `meta
+ * eject` itself produces — and THAT file carried the stale
+ * `import { entityFile } from "@metaobjectsdev/codegen-ts/generators"`. The source scan saw
+ * a clean config and the adopter got exactly the bare TypeError this check exists to
+ * prevent: `(0 , _generators.entityFile) is not a function`, exit 2, no file, no remedy.
  */
 const REMOVED_GENERATOR_EXPORTS = ["entityFile", "queriesFile", "routesFile", "barrel"] as const;
 const GENERATORS_SUBPATH = "@metaobjectsdev/codegen-ts/generators";
@@ -180,6 +184,39 @@ export function removedGeneratorImportError(source: string): string | undefined
   );
 }
 
+/**
+ * The same diagnostic, recovered from the THROW instead of the source — for the case the
+ * source scan structurally cannot see: a removed export imported by a module the config
+ * imports, rather than by the config itself.
+ *
+ * It cannot name the file (the TypeError carries no reference back to the import that
+ * produced it — that limitation is real, it is just not a reason to say nothing), so it
+ * names what it does know: the symbol, the removal, and the one-command remedy. Matching is
+ * on the SYMBOL, not the message shape, because the shape is the transpiler's: Bun says
+ * `(0 , _generators.entityFile) is not a function` and Node ESM says
+ * `entityFile is not a function`.
+ */
+export function removedGeneratorRuntimeError(err: unknown): string | undefined {
+  const message = err instanceof Error ? err.message : String(err ?? "");
+  if (!/is not a function/.test(message)) return undefined;
+  const hit = REMOVED_GENERATOR_EXPORTS.find((n) => new RegExp(`\\b${n}\\b`).test(message));
+  if (hit === undefined) return undefined;
+  const template = hit.replace(/File$/, "");
+  return (
+    `${hit}() is not a function — 1.0 REMOVED it from "${GENERATORS_SUBPATH}" ` +
+    `(ADR-0034 scaffold-and-own): these generators are yours to own, so the package no ` +
+    `longer ships them as an import. Your metaobjects.config.ts does not import it, so ` +
+    `the import is in a module the config imports — most often an OWNED generator under ` +
+    `codegen/generators/, which is exactly what 'meta eject' writes.\n` +
+    `  Fix — copy it into your repo:\n    meta eject ${template}\n` +
+    `  then change that module's import to: ` +
+    `import { ${hit} } from "./codegen/generators/${template}";\n` +
+    `  The subpath itself is fine — promptRender, outputParser, routesFileHono and the ` +
+    `rest still live there.\n` +
+    `  Guide: docs/features/migrations/0.x-to-1.0.md §11`
+  );
+}
+
 function rewriteImportSpecifiers(source: string, aliasMap: Record<string, string>): string {
   let result = source;
   for (const [specifier, resolvedPath] of Object.entries(aliasMap)) {
@@ -461,7 +498,18 @@ export async function loadMetaobjectsConfig(projectRoot: string): Promise<Metaob
   const prepareStackTraceBefore = Error.prepareStackTrace;
   const stackTraceLimitBefore = Error.stackTraceLimit;
   try {
-    const raw = (await jiti.import(loadPath)) as MetaobjectsGenConfig | { default: MetaobjectsGenConfig };
+    let raw: MetaobjectsGenConfig | { default: MetaobjectsGenConfig };
+    try {
+      raw = (await jiti.import(loadPath)) as MetaobjectsGenConfig | { default: MetaobjectsGenConfig };
+    } catch (err) {
+      // The second arm of the ADR-0034 diagnostic: a removed export imported by a module the
+      // config imports rather than by the config itself. Rethrown as the migration message,
+      // because what reaches the adopter otherwise is `(0 , _generators.entityFile) is not a
+      // function` — the exact unactionable failure the source scan above exists to prevent.
+      const runtime = removedGeneratorRuntimeError(err);
+      if (runtime !== undefined) throw new Error(runtime);
+      throw err;
+    }
     // jiti's interopDefault doesn't always unwrap the default export when accessed
     // across module boundaries — explicitly unwrap if present.
     const cfg = (raw && typeof raw === "object" && "default" in raw && raw.default
 
@@ -0,0 +1,63 @@
+// ADR-0034's removal has TWO doors, and only one of them was covered.
+//
+// `removedGeneratorImportError` reads the config SOURCE, so it fires when the config itself
+// imports `entityFile` / `barrel` / … from "@metaobjectsdev/codegen-ts/generators". A
+// polyglot adopter estate showed the other door: its config imported an OWNED generator —
+// `./codegen/generators/entityFileTyped`, the exact shape `meta eject` writes — and THAT
+// file carried the stale import. The source scan saw a clean config, and what the adopter
+// got was `(0 , _generators.entityFile) is not a function`, exit 2, naming no file, no
+// symbol origin and no remedy: the precise failure the first door exists to prevent.
+
+import { describe, test, expect } from "bun:test";
+import {
+  removedGeneratorImportError,
+  removedGeneratorRuntimeError,
+} from "../../src/lib/load-metaobjects-config.js";
+
+describe("removedGeneratorRuntimeError", () => {
+  test("recognises Bun's transpiled shape", () => {
+    const msg = removedGeneratorRuntimeError(
+      new TypeError("(0 , _generators.entityFile) is not a function"),
+    );
+    expect(msg).toBeDefined();
+    expect(msg).toContain("meta eject entity");
+    expect(msg).toContain("ADR-0034");
+    expect(msg).toContain("0.x-to-1.0.md");
+  });
+
+  test("recognises Node's plain shape", () => {
+    // Matching is on the SYMBOL, not the message shape — the shape belongs to whichever
+    // transpiler ran, and an adopter's runtime is not ours to choose.
+    const msg = removedGeneratorRuntimeError(new TypeError("barrel is not a function"));
+    expect(msg).toContain("meta eject barrel");
+  });
+
+  test("says WHERE to look, since the throw cannot name the file", () => {
+    const msg = removedGeneratorRuntimeError(new TypeError("entityFile is not a function"))!;
+    expect(msg).toContain("codegen/generators/");
+    expect(msg).toMatch(/module (the|your) config imports/);
+  });
+
+  test("stays out of the way of unrelated TypeErrors", () => {
+    expect(removedGeneratorRuntimeError(new TypeError("foo is not a function"))).toBeUndefined();
+    expect(removedGeneratorRuntimeError(new Error("entityFile exploded"))).toBeUndefined();
+    expect(removedGeneratorRuntimeError(undefined)).toBeUndefined();
+  });
+
+  test("a non-Error throw does not crash the diagnostic", () => {
+    expect(removedGeneratorRuntimeError("entityFile is not a function")).toContain("meta eject entity");
+  });
+});
+
+describe("the two doors agree", () => {
+  test("both name the removal, the remedy and the guide", () => {
+    const fromSource = removedGeneratorImportError(
+      `import { entityFile } from "@metaobjectsdev/codegen-ts/generators";`,
+    )!;
+    const fromThrow = removedGeneratorRuntimeError(new TypeError("entityFile is not a function"))!;
+    for (const needle of ["ADR-0034", "meta eject entity", "0.x-to-1.0.md §11"]) {
+      expect(fromSource).toContain(needle);
+      expect(fromThrow).toContain(needle);
+    }
+  });
+});