@@ -351,7 +351,7 @@ Per finding: `file:line` → what → generated-equivalent exists? → recommend
 
     **Score only where a constant actually exists.** A fact declared in the project's CODEGEN CONFIG rather than in metadata — a bespoke route mount path, a hand-chosen JSON envelope key — is genuinely spelled twice when a client re-types it, but no generated constant holds it. That is a GENERATOR GAP, reported as one, never a literal-site finding: never invent a constant that the emitters do not emit.
 
-    **No verify subverb sees this** — `--codegen` diffs generated files, `--db` compares schema to metadata — so this audit is the only gate. Remedy: reference the constant — but **check the artifact is emitted at all before scoring the literals, because on THREE of five ports an existing project emits none**. C# and Python have a real default suite and get it by upgrading; TypeScript's `generators: [...]` and the JVM's `<generators>` are each the COMPLETE list, so `meta init` scaffolding `namesFile()` covers only a project initialized at 1.0 and upgrading the package never edits a config written earlier. Where no artifact exists, the un-wired generator is the FIRST finding and the first remedy (`namesFile()` on TS after `meta eject names`; `SpringNamesGenerator` / `KotlinNamesGenerator` in the pom) — score the literals under it rather than as N independent findings, since one config line fixes the cause and generated code stops embedding the names too.
+    **No verify subverb sees this** — `--codegen` diffs generated files, `--db` compares schema to metadata — so this audit is the only gate. Remedy: reference the constant — but **check the artifact is emitted at all before scoring the literals, because on ALL FIVE ports an existing project emits none until it asks**. ADR-0034 Amendment 2 made codegen opt-in everywhere: C# and Python require `--generators`, TypeScript's `generators: [...]` and the JVM's `<generators>` are each the COMPLETE list, and `meta init` scaffolds `generators: []` — so no port begins emitting this artifact merely because the package was upgraded. Where no artifact exists, the un-wired generator is the FIRST finding and the first remedy (`namesFile()` on TS after `meta eject names`; `SpringNamesGenerator` / `KotlinNamesGenerator` in the pom) — score the literals under it rather than as N independent findings, since one config line fixes the cause and generated code stops embedding the names too.
 
     **Report TWO numbers for this signature, always, and never just the first: (a) is the artifact EMITTED, and (b) how many of the literal sites actually IMPORT it — the adoption ratio, as `<adopted>/<total> sites`.** Emission is the cheap half and it is the half that gets done: measured on an adopter whose audit proved the artifact emitted correctly, ran the generator to show it, and then adopted it at **0 of 53 sites** (37 table + 16 column). Wiring the generator changes the scorecard; it changes nothing a reader of the code experiences, because the second spelling is still the one every query uses. An audit that reports only (a) makes the estate look upgraded while every literal it found is still there — so a project that emits the artifact and imports it nowhere scores WORSE than one that has not started, not better, because it now carries a third spelling that claims to be the source of truth.
 
 
@@ -71,10 +71,10 @@ classify it (using the classification scheme in `SKILL.md`) and route the cutove
   migration script, a body-to-column map (drift signature 11). Every port emits a per-object
   names artifact from the declaration, so a literal is a second source of truth even when it
   agrees with the naming strategy today. A typed ORM handle in its place is correct. **Check
-  the artifact is emitted at all before scoring the literals: on TypeScript and the JVM the
-  generator list in the config IS the complete list, so an existing project emits none and the
-  un-wired generator is the finding FIRST** (C# and Python have a real default suite and get it
-  by upgrading). **This entry is the physical-name INSTANCE of signature 11.** The rule that
+  the artifact is emitted at all before scoring the literals: on every port the selection IS
+  the complete list — the config's on TypeScript and the JVM, `--generators` on C# and Python —
+  so an existing project emits none and the un-wired generator is the finding FIRST** (no port
+  ships a default suite; ADR-0034 Amendment 2). **This entry is the physical-name INSTANCE of signature 11.** The rule that
   generates the rest — and the reason an enum member compared as a bare string is NOT one — is
   the Cross-cutting entry below.
 - **`@kind` = `view` / `materializedView`** — hunt hand-written SQL views where an authored
 
@@ -51,7 +51,7 @@ rejected (exit 2).
 | `FromSqlInterpolated(` outside `.g.cs` | stored-proc call — candidate for the `callable` generator |
 | `// keep in sync with` / `// mirrors the` | second-source-of-truth comment — always a finding |
 | `HasPrecision(` hand-coded | `field.decimal` with `@precision`/`@scale` drives this from the `entity` generator |
-| a table/column string in raw-SQL EF calls, or `nameof(Entity.Prop)` standing in for a column | second spelling of a declared physical name — reference `<Entity>Names.g.cs` (`AuthorNames.SourcePrimaryTable` / `<Field>Column`, default suite — `Names.Name` is the OBJECT's name, not the table); an EF property inside LINQ is the typed handle — correct |
+| a table/column string in raw-SQL EF calls, or `nameof(Entity.Prop)` standing in for a column | second spelling of a declared physical name — reference `<Entity>Names.g.cs` (`AuthorNames.SourcePrimaryTable` / `<Field>Column`, emitted when `names` is named in `--generators` — `Names.Name` is the OBJECT's name, not the table); an EF property inside LINQ is the typed handle — correct |
 
 ---
 
@@ -66,7 +66,7 @@ selection uses stable names via `dotnet meta gen --generators <names>`, over a
 **So do not score a C# project down for "not owning its generators", and do not
 recommend writing one.** The customization path here is the **declarative template**:
 `dotnet meta gen --template-spec <json> --template-root <dir>`, whose entries append to
-the default suite. A finding of the form "the built-ins do not emit the shape this
+your `--generators` selection. A finding of the form "the built-ins do not emit the shape this
 project needs" resolves to a template-spec, not to generator code. Worked example with
 the full JSON: `docs/ports/csharp.md`.
 
 
@@ -52,7 +52,7 @@ regardless of server language — see the migration reference.
 | `def get_all_` / `def create_` / `def update_` / `def delete_` in non-generated files | hand-rolled CRUD — compare to the generated router |
 | `# keep in sync with` / `# mirrors the` | second-source-of-truth comment — always a finding |
 | `try: ... except KeyError` / `?? ''` around format strings in prompt code | silent-degradation hack around a prompt payload — flag it |
-| a table/column string in the repository implementation (SQLAlchemy Core, asyncpg/psycopg SQL) | second spelling of a declared physical name — reference `<entity>_names.py` (`AUTHOR_SOURCE_PRIMARY_TABLE` / `AUTHOR_<FIELD>_COLUMN`, default suite); no typed handle exists on this port, so that is never the reason to waive it |
+| a table/column string in the repository implementation (SQLAlchemy Core, asyncpg/psycopg SQL) | second spelling of a declared physical name — reference `<entity>_names.py` (`AUTHOR_SOURCE_PRIMARY_TABLE` / `AUTHOR_<FIELD>_COLUMN`, emitted when `names` is named in `--generators`); no typed handle exists on this port, so that is never the reason to waive it |
 
 ---
 
@@ -66,8 +66,8 @@ seam to register a generator of your own. (`--provider module:symbol` registers
 
 **So do not score a Python project down for "not owning its generators", and do not
 recommend writing one.** The customization path here is the **declarative template**:
-`metaobjects gen --template-spec <json> --templates <dir>`, whose entries append to the
-default suite. A finding of the form "the built-ins do not emit the shape this project
+`metaobjects gen --template-spec <json> --templates <dir>`, whose entries append to your
+`--generators` selection. A finding of the form "the built-ins do not emit the shape this project
 needs" resolves to a template-spec, not to generator code. Worked example with the full
 JSON: `docs/ports/python.md`.
 
 
@@ -489,7 +489,8 @@ generator sets are **closed built-in registries** — `--generators` *selects* f
 ships, and there is no seam to register a `Generator` of your own. (Python's
 `--provider module:symbol` registers **metamodel vocabulary**, not a generator; do not
 reach for it here.) Use `--template-spec <json>` — plus `--templates <dir>` on Python or
-`--template-root <dir>` on C# — and your entries are appended to the default suite. Worked
+`--template-root <dir>` on C# — and your entries are appended to your `--generators`
+selection. Worked
 examples with the full JSON: `docs/ports/python.md` and `docs/ports/csharp.md`.
 
 **The spec is auto-discovered, and that is load-bearing.** With no `--template-spec`, both
@@ -544,21 +545,21 @@ everywhere — **each physical name is spelled once, and generated code referenc
 | Kotlin | `<Entity>Names.kt` | `ProgramNames.CREATED_AT_COLUMN` |
 | Python | `<entity_snake>_names.py` | `PROGRAM_CREATED_AT_COLUMN` |
 
-**Check that it is actually wired before you reference it — on three of five ports an
-EXISTING project emits none.** "In the default suite" and "what a fresh scaffold writes"
-are different facts, and only C# and Python have the first:
+**Check that it is actually wired before you reference it — on ALL FIVE ports a project
+emits none until it asks for it.** ADR-0034 Amendment 2 made codegen opt-in everywhere: no
+port ships a default suite, so there is no port on which upgrading the package starts
+emitting this artifact. "Wired" is the only fact there is.
 
-| Port | Where the suite is decided | An existing project upgrading gets it? |
+| Port | Where the selection is declared | An existing project upgrading gets it? |
 |---|---|---|
-| C# | `GenCommand.DefaultGeneratorNames` — a real default | **Yes**, with no edit |
-| Python | `cli.py` `_default_generators()` — a real default | **Yes**, with no edit |
-| TypeScript | `metaobjects.config.ts` `generators: [...]` — **the complete list; there is no default suite** | **No** — add `namesFile()` |
+| C# | `--generators <csv>` on `dotnet meta gen` — required, no default | **No** — name `names` |
+| Python | `--generators <csv>` on `metaobjects gen` — required, no default | **No** — name `names` |
+| TypeScript | `metaobjects.config.ts` `generators: [...]` — the complete list | **No** — add `namesFile()` |
 | Java / Kotlin | the pom's `<generators>` — the complete list | **No** — add `SpringNamesGenerator` / `KotlinNamesGenerator` |
 
-TypeScript's `meta init` scaffolds `namesFile()`, so a project *initialized* at 1.0 has it;
-a project initialized earlier has the config `meta init` wrote then, and upgrading the
-package never edits a config. So on TypeScript the artifact is opt-in exactly as it is on
-the JVM — the scaffold is not a default. To wire it into an existing TS project:
+`meta init` scaffolds `generators: []` and an empty `codegen/generators/`, so even a
+project *initialized* at 1.0 has to choose this one — the scaffold is deliberately not a
+default by another name. To wire it into a TS project:
 
 ```ts
 import { namesFile } from "./codegen/generators/names.js";   // after `meta eject names`
 
@@ -94,8 +94,9 @@ the Java, Kotlin, and Python backends byte-for-byte.
 Inside LINQ keep the property (`db.Authors.Where(a => a.Name == …)`): it is type-checked
 against the model, and a string constant there trades a compile error for a runtime one.
 Where LINQ does not reach — raw SQL, a migration script, a log line — take the physical
-name from the generated `<Entity>Names.g.cs`. `names` is in the default suite, and the
-generated entity and `AppDbContext` already read it, so it cannot disagree with the
+name from the generated `<Entity>Names.g.cs`. `names` is opt-in — name it in
+`--generators` — and once selected the generated entity and `AppDbContext` already read
+it, so it cannot disagree with the
 mapping: `AuthorNames.SourcePrimaryTable` is the table (the member is named for the
 source's `@kind`, so a view reads `SourceReplicaView` / `SourcePrimaryView` and a stored
 procedure `SourcePrimaryProc`), `AuthorNames.<Field>Column` the column,
 
@@ -100,7 +100,7 @@ resolve the column themselves, so that path never needs a physical name. The mom
 repository `Protocol` is backed by your own SQLAlchemy Core / asyncpg / psycopg code, it
 does — and nothing Python generates carries one: the Pydantic models, create/patch
 shapes, router and allowlist all key by field. Take it from the generated
-`<entity_snake>_names.py` (`names` is in the default suite):
+`<entity_snake>_names.py` (`names` is opt-in — name it in `--generators`):
 
 ```python
 from generated.author_names import (
 
@@ -351,7 +351,7 @@ Per finding: `file:line` → what → generated-equivalent exists? → recommend
 
     **Score only where a constant actually exists.** A fact declared in the project's CODEGEN CONFIG rather than in metadata — a bespoke route mount path, a hand-chosen JSON envelope key — is genuinely spelled twice when a client re-types it, but no generated constant holds it. That is a GENERATOR GAP, reported as one, never a literal-site finding: never invent a constant that the emitters do not emit.
 
-    **No verify subverb sees this** — `--codegen` diffs generated files, `--db` compares schema to metadata — so this audit is the only gate. Remedy: reference the constant — but **check the artifact is emitted at all before scoring the literals, because on THREE of five ports an existing project emits none**. C# and Python have a real default suite and get it by upgrading; TypeScript's `generators: [...]` and the JVM's `<generators>` are each the COMPLETE list, so `meta init` scaffolding `namesFile()` covers only a project initialized at 1.0 and upgrading the package never edits a config written earlier. Where no artifact exists, the un-wired generator is the FIRST finding and the first remedy (`namesFile()` on TS after `meta eject names`; `SpringNamesGenerator` / `KotlinNamesGenerator` in the pom) — score the literals under it rather than as N independent findings, since one config line fixes the cause and generated code stops embedding the names too.
+    **No verify subverb sees this** — `--codegen` diffs generated files, `--db` compares schema to metadata — so this audit is the only gate. Remedy: reference the constant — but **check the artifact is emitted at all before scoring the literals, because on ALL FIVE ports an existing project emits none until it asks**. ADR-0034 Amendment 2 made codegen opt-in everywhere: C# and Python require `--generators`, TypeScript's `generators: [...]` and the JVM's `<generators>` are each the COMPLETE list, and `meta init` scaffolds `generators: []` — so no port begins emitting this artifact merely because the package was upgraded. Where no artifact exists, the un-wired generator is the FIRST finding and the first remedy (`namesFile()` on TS after `meta eject names`; `SpringNamesGenerator` / `KotlinNamesGenerator` in the pom) — score the literals under it rather than as N independent findings, since one config line fixes the cause and generated code stops embedding the names too.
 
     **Report TWO numbers for this signature, always, and never just the first: (a) is the artifact EMITTED, and (b) how many of the literal sites actually IMPORT it — the adoption ratio, as `<adopted>/<total> sites`.** Emission is the cheap half and it is the half that gets done: measured on an adopter whose audit proved the artifact emitted correctly, ran the generator to show it, and then adopted it at **0 of 53 sites** (37 table + 16 column). Wiring the generator changes the scorecard; it changes nothing a reader of the code experiences, because the second spelling is still the one every query uses. An audit that reports only (a) makes the estate look upgraded while every literal it found is still there — so a project that emits the artifact and imports it nowhere scores WORSE than one that has not started, not better, because it now carries a third spelling that claims to be the source of truth.
 
 
@@ -71,10 +71,10 @@ classify it (using the classification scheme in `SKILL.md`) and route the cutove
   migration script, a body-to-column map (drift signature 11). Every port emits a per-object
   names artifact from the declaration, so a literal is a second source of truth even when it
   agrees with the naming strategy today. A typed ORM handle in its place is correct. **Check
-  the artifact is emitted at all before scoring the literals: on TypeScript and the JVM the
-  generator list in the config IS the complete list, so an existing project emits none and the
-  un-wired generator is the finding FIRST** (C# and Python have a real default suite and get it
-  by upgrading). **This entry is the physical-name INSTANCE of signature 11.** The rule that
+  the artifact is emitted at all before scoring the literals: on every port the selection IS
+  the complete list — the config's on TypeScript and the JVM, `--generators` on C# and Python —
+  so an existing project emits none and the un-wired generator is the finding FIRST** (no port
+  ships a default suite; ADR-0034 Amendment 2). **This entry is the physical-name INSTANCE of signature 11.** The rule that
   generates the rest — and the reason an enum member compared as a bare string is NOT one — is
   the Cross-cutting entry below.
 - **`@kind` = `view` / `materializedView`** — hunt hand-written SQL views where an authored