@@ -7,6 +7,58 @@ this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.htm
 
 ## [Unreleased]
 
+### Removed — the deprecated `codegen-ts/generators` export of the four ownable generators
+
+`entityFile`, `queriesFile`, `routesFile` and `barrel` are no longer exported from
+`@metaobjectsdev/codegen-ts/generators`. They carried an `@deprecated` marker since ADR-0034
+landed; removing them is the ratified 1.0 move (ADR-0035 A3, `docs/1.0-readiness.md` G2).
+**Migration is one file each:** `meta init` scaffolds owned copies into
+`codegen/generators/*.ts`, and `meta eject <name>` copies one at any time. Guide:
+[`docs/features/migrations/0.x-to-1.0.md`](docs/features/migrations/0.x-to-1.0.md) §11.
+
+**The `/generators` subpath itself is NOT removed and is not deprecated.** It stays the
+supported public home of the generators that have no ownable copy — the prompt/output tier
+(`promptRender`, `outputParser`, `outputPrompt`, `extractor`, `renderHelper`,
+`traceHelperFile`) plus `routesFileHono`, `namesFile` and `callableFile`. The CLI's own
+prompt-gate warning names that import path, so deleting the subpath would have contradicted
+the product's own instructions. Scoping this by NAME rather than by path is load-bearing: of
+six adopter estates surveyed before the cut, **five import only non-deprecated names from
+that subpath and one imports the four**; a path-wide removal would have broken all six and
+the owned-copy remedy would have applied to one.
+
+### Fixed — an ejected `queries` generator silently dropped `insertPreserving<Entity>` (#203)
+
+`src/reference/queries.ts` — the template `meta init` scaffolds and `meta eject queries`
+copies — omitted the `@autoSet` branch the built-in composer has: no
+`insertPreserving<Entity>` function and no `<Entity>InsertPreservingSchema` import. So an
+adopter who owned their queries generator lost the #203 escape hatch on exactly the entities
+that have one, with **no error** — the emitted module simply lacked the function. Two engine
+primitives it needs (`renderInsertPreservingFn`, `hasAutoSetFields`) were not public either,
+so an owned copy could not have restored it by hand.
+
+This matters more at 1.0 than it did before: with the built-in export removed, the owned copy
+is the ONLY path, so the degraded output becomes the only output.
+
+**Why the gate that exists for this was green.** `reference-byte-identical.test.ts` runs every
+reference template AND the built-in it was copied from over a fixture corpus and requires
+byte-identical output — and **not one of its seven fixtures carried `@autoSet`**, which is the
+sole trigger for the branch. The reason outlives the fixture: every model in that corpus was
+written to exercise SHAPE (packages, FKs, value objects, `extends`), and `@autoSet` is a
+per-field write RULE, so no shape-driven corpus grows one by accident. A fixture that carries
+one is added, and was confirmed to fail before the fix and pass after.
+
+`renderInsertPreservingFn` and `hasAutoSetFields` are now public engine primitives.
+
+### Fixed — the audit skill convicted correct projects of not owning their codegen
+
+`metaobjects-audit` told an auditing agent that any hit on
+`grep -r '@metaobjectsdev/codegen-ts/generators'` "means the project has not adopted
+scaffold-and-own." Five of six surveyed adopter estates hit that grep while importing only
+generators that have no ownable copy — a false finding against a correct project, and the
+recommended remedy (`meta init`) would not have changed anything. The check now matches the
+four removed NAMES, and the skill states outright that importing the non-ownable tier from
+that subpath is correct.
+
 ### Fixed — two doors disagreed about whether an object has one address (all five ports)
 
 `primaryRdbSource` — the shared authority every consumer asks "which source is this object's
 
@@ -23,8 +23,12 @@ Actual cutovers run through the existing skills mapped per finding tier (§ Brid
   `com.metaobjects:*` / `metaobjects` / `MetaObjects.*` deps).
 - [ ] Count metadata source lines + all `@generated` / `DO NOT EDIT` files repo-wide.
 - [ ] **Owned-generators check:** does the project own generators at `codegen/generators/*`
-  (scaffold-and-own via `meta init`), or still import the **deprecated** package export
-  (`@metaobjectsdev/codegen-ts/generators`)? Not owning is itself a finding.
+  (scaffold-and-own via `meta init`), or still import `entityFile` / `queriesFile` /
+  `routesFile` / `barrel` from `@metaobjectsdev/codegen-ts/generators`? Those four were
+  REMOVED at 1.0, so an import of them is an upgrade blocker, not just a style finding.
+  **Match the four NAMES, never the subpath alone** — that subpath is the supported home of
+  the non-ownable generators (`promptRender`, `outputParser`, `routesFileHono`, …), so
+  flagging a hit on the path convicts a correct project.
 - [ ] **Cross-language version consistency (silent-drift check).** If the project uses MetaObjects in more than one language (e.g. a TS web client + a Java/Python/C# backend), enumerate EVERY MetaObjects package across ALL ecosystems (npm `@metaobjectsdev/*`, Maven `com.metaobjects:*`, PyPI `metaobjects`, NuGet `MetaObjects.*`) and record each version. **The version-number LINES differ by ecosystem (npm/PyPI/NuGet `0.x`/`1.x` vs Maven `7.x`/`8.x`), so you CANNOT eyeball drift** — a `0.12` next to a `7.7` looks fine but can be badly out of sync. Compare the **`metamodelVersion`** each port reports (the shared spec version on the registry manifest): a mismatch is real cross-language drift and a **finding** — the ports disagree on vocabulary/wire behavior. Also flag any port not on the latest release for its ecosystem. (This is a known real-world failure mode: newest backend, stale client, invisible because the numbers differ.)
 - [ ] Classify: **Greenfield** (none/minimal) · **Partial** · **Deep** → choose path below.
 
@@ -343,8 +347,11 @@ Per finding: `file:line` → what → generated-equivalent exists? → recommend
 
 ## Owned-codegen & scaffold-and-own assessment
 
-- If config imports deprecated `@metaobjectsdev/codegen-ts/generators` instead of
-  owned `codegen/generators/*`, recommend the scaffold-and-own migration (`meta init`).
+- If config imports `entityFile` / `queriesFile` / `routesFile` / `barrel` from
+  `@metaobjectsdev/codegen-ts/generators` instead of owned `codegen/generators/*`,
+  recommend the scaffold-and-own migration (`meta init`, or `meta eject <name>`) — on 1.0+
+  those four no longer resolve. Importing the non-ownable generators from that subpath is
+  correct and is not a finding.
 - Audit owned generators: (a) regenerate clean? (b) drifted from reference templates —
   intentional (good) vs stale/accidental (missed upstream fix)? (c) hand-rolling a walk
   that a declarative `scope` + `outputPattern` could replace? (d) bespoke shape better as
 
@@ -69,22 +69,34 @@ import { entityFile } from "./codegen/generators/entity";
 import { queriesFile } from "./codegen/generators/queries";
 ```
 
-**Deprecated import path** (still works, removal planned):
+**Removed import path.** `entityFile` / `queriesFile` / `routesFile` / `barrel` were
+exported from `@metaobjectsdev/codegen-ts/generators` and deprecated; **1.0 removed them**
+(ADR-0035 A3). On 1.0+ this no longer resolves:
 
 ```ts
 import { entityFile, queriesFile, routesFile, barrel } from "@metaobjectsdev/codegen-ts/generators";
 ```
 
-**Finding this in a project:** grep for the deprecated path:
+**Do NOT flag the subpath itself.** `@metaobjectsdev/codegen-ts/generators` is the supported,
+non-deprecated home of the generators that have no ownable copy — the prompt/output tier
+(`promptRender`, `outputParser`, `outputPrompt`, `extractor`, `renderHelper`,
+`traceHelperFile`) plus `routesFileHono`, `namesFile` and `callableFile`. The CLI's own
+prompt-gate warning tells adopters to import `promptRender` from exactly this path. A
+project importing those from it is CORRECT, and reporting it as un-adopted scaffold-and-own
+is a false finding.
+
+**Finding this in a project:** grep for the four removed NAMES on that path, never the path
+alone:
 
 ```bash
-grep -r '@metaobjectsdev/codegen-ts/generators' .
+grep -rn '@metaobjectsdev/codegen-ts/generators' . \
+  | grep -E 'entityFile|queriesFile|routesFile|barrel'
 ```
 
-A hit means the project has not adopted scaffold-and-own — recommend `meta init`
-to scaffold the owned copies. The owned generator files themselves (`codegen/generators/*.ts`)
-are the second thing to audit: are they stale relative to the reference templates,
-or intentionally customized?
+A hit is a 1.0 upgrade blocker (the import fails to resolve) — recommend `meta init` (or
+`meta eject <name>`) to scaffold the owned copies, then import those locally. The owned
+generator files themselves (`codegen/generators/*.ts`) are the second thing to audit: are
+they stale relative to the reference templates, or intentionally customized?
 
 ---
 
 
@@ -84,9 +84,12 @@ PROJECT ROOT that CONTAINS the metadata — never the metadata directory itself.
 ## The generators
 
 Server-side, framework-neutral. The first four are **scaffolded into your repo** by
-`meta init` and imported from `./codegen/generators/*` (ADR-0034); the rest come from the
-package main entry, `@metaobjectsdev/codegen-ts`. Do **not** import any of them from
-`@metaobjectsdev/codegen-ts/generators` — that subpath is deprecated and removed at 1.0.
+`meta init` and imported from `./codegen/generators/*` (ADR-0034) — 1.0 REMOVED their
+`@metaobjectsdev/codegen-ts/generators` export, so an owned copy is the only path. The
+engine primitives come from the package main entry, `@metaobjectsdev/codegen-ts`. The
+`/generators` subpath itself is NOT deprecated: it is the supported home of the generators
+with no ownable copy — `promptRender`, `outputParser`, `outputPrompt`, `extractor`,
+`renderHelper`, `traceHelperFile`, `routesFileHono`, `namesFile`, `callableFile`.
 
 | Generator | Emits per entity |
 |---|---|
 
@@ -172,7 +172,19 @@ Status legend: ✅ done · 🔶 in progress · ⬜ not started · ❓ **[RATIFY]
 - ⬜ **G1. Execute A1** (the decoupled cut): npm/PyPI/NuGet `→1.0.0`, Java/Kotlin
   `→8.0.0`, freeze the spec version at `Metamodel 1.0` (C4). Both forward; no
   backwards move on any registry.
-- ⬜ **G2. Remove the deprecated export** if A3=remove (one-time).
+- ✅ **G2. Remove the deprecated export** — DONE 2026-09-07. `entityFile` / `queriesFile` /
+  `routesFile` / `barrel` are gone from `@metaobjectsdev/codegen-ts/generators`; owned copies
+  (`meta init`, `meta eject <name>`) are the path, as `0.x-to-1.0.md` §11 already promised.
+
+  **Scoped by NAME, not by path — the checklist's own shorthand was wrong.** That subpath
+  carries ~20 exports and only those four were deprecated; the rest (`promptRender`,
+  `outputParser`, `outputPrompt`, `extractor`, `renderHelper`, `traceHelperFile`,
+  `routesFileHono`, `namesFile`, `callableFile`) have **no other public import path**, and the
+  CLI's own prompt-gate warning tells adopters to import `promptRender` from exactly there.
+  Of six adopter estates surveyed before the cut, five import only non-deprecated names from
+  that subpath and one imports the four: a path-wide removal breaks all six and the owned-copy
+  remedy applies to one. A3's ratified intent and the published guide both name the four, so
+  this is that decision implemented, not a narrowing of it.
 - 🔶 **G3. Scope declared, promise livable, publications current, RC exercised.**
   *(G3a/G3b/G3c done; **G3d is the one open gate** and it blocks G1.)*
 
 
@@ -257,10 +257,31 @@ Importing the built-in generators from `@metaobjectsdev/codegen-ts/generators`
 (`entityFile` / `queriesFile` / `routesFile` / `barrel`) is **removed** at 1.0.
 
 - **Migration:** import the owned copies `meta init` scaffolds into
-  `codegen/generators/*` and wire those in `metaobjects.config.ts`. See
+  `codegen/generators/*` and wire those in `metaobjects.config.ts`. On an existing project,
+  `meta eject entity` / `queries` / `routes` / `barrel` copies each one in place
+  (`meta eject --list` names every ejectable generator). See
   [own-your-codegen](../own-your-codegen.md). (If you scaffolded with a recent
   `meta init`, you already import the owned copies — no change needed.)
 
+- **The `@metaobjectsdev/codegen-ts/generators` subpath itself is unchanged.** Only those four
+  names left it. It remains the supported home of the generators that have no ownable copy —
+  `promptRender`, `outputParser`, `outputPrompt`, `extractor`, `renderHelper`,
+  `traceHelperFile`, `routesFileHono`, `namesFile`, `callableFile`. If your config imports
+  only those, **there is nothing to do here.** Check with:
+
+  ```bash
+  grep -rn '@metaobjectsdev/codegen-ts/generators' . \
+    | grep -E 'entityFile|queriesFile|routesFile|barrel'
+  ```
+
+  No output means this section does not apply to you.
+
+- **If you already own a `queries` generator, re-eject it.** Copies taken before 1.0 are
+  missing the `@autoSet` branch — no `insertPreserving<Entity>` and no
+  `<Entity>InsertPreservingSchema` import — so an entity with an `@autoSet` timestamp lost the
+  #203 escape hatch silently. `meta eject queries` (over your copy, re-applying any
+  customization) restores it.
+
 ## Additive in 1.0 (no migration required)
 
 - **`field.uri` / `field.inet` subtypes + `@stringFormat`** (`email` / `hostname`)
 
@@ -0,0 +1,73 @@
+// REFERENCE TEMPLATE — copy this into your repo (e.g. codegen/generators/barrel.ts) and own it.
+// Then import it LOCALLY in metaobjects.config.ts instead of from the package:
+//   import { barrel } from "./codegen/generators/barrel.js";
+//
+// RUNTIME: this file executes under whatever runs `meta gen`, and the published CLI's
+// shebang is `#!/usr/bin/env node` — so it runs under NODE even in a Bun project. Do not
+// reach for `Bun.*` globals here; they are undefined and take the whole run down with
+// `Bun is not defined`. Use `node:` builtins instead.
+// targets:       nothing framework-specific — it re-exports whatever the other generators
+//                emitted. `extStyle` decides whether the re-export specifiers carry a
+//                `.js` extension.
+// use-when:      you want a single `index.ts` re-exporting every generated entity module.
+// emits:         <target>/index.ts with one `export * from "./<Entity>"` per entity, alphabetical.
+// customize:     the export form (star vs named), ordering, grouping by package, what to include/exclude.
+// composes-with: entity.ts (this re-exports the files entity.ts emits).
+//
+// Everything below imports ONLY from `@metaobjectsdev/codegen-ts` (the stable engine).
+// The composition (`renderBarrel`) is inlined here so you own it — change it freely.
+
+import {
+  oncePerRun,
+  type Generator,
+  type GeneratorFactory,
+  type ExtStyle,
+  type ResolvedTarget,
+  barrelModuleSpecifier,
+  formatTs,
+  GENERATED_HEADER,
+} from "@metaobjectsdev/codegen-ts";
+
+interface BarrelEntry {
+  name: string;
+  package: string | undefined;
+}
+
+// --- composition (OWNED) — the barrel file body. Customize freely. ---
+function renderBarrel(
+  entries: BarrelEntry[],
+  extStyle: ExtStyle,
+  selfTarget: ResolvedTarget,
+  entityModuleTarget: ResolvedTarget,
+): string {
+  const sorted = [...entries].sort((a, b) => a.name.localeCompare(b.name));
+  const exports = sorted
+    .map((e) => `export * from ${JSON.stringify(barrelModuleSpecifier(selfTarget, entityModuleTarget, e.package, e.name, extStyle))};`)
+    .join("\n");
+  return `// ${GENERATED_HEADER} — DO NOT EDIT.\n${exports}\n`;
+}
+
+export interface BarrelOpts {
+  target?: string;
+}
+
+export const barrel = function barrel(opts?: BarrelOpts): Generator {
+  const generator: Generator = {
+    name: "barrel",
+    generate: oncePerRun(async (entities, ctx) => ({
+      path: "index.ts",
+      content: await formatTs(
+        renderBarrel(
+          entities.map((e) => ({ name: ctx.renderContext!.valueObjectEmittedName(e), package: e.package })),
+          ctx.renderContext!.extStyle,
+          ctx.renderContext!.selfTarget,
+          ctx.renderContext!.entityModuleTarget,
+        ),
+      ),
+    })),
+  };
+  if (opts?.target) {
+    generator.target = opts.target;
+  }
+  return generator;
+} as GeneratorFactory<BarrelOpts>;