docs(requirements): the decision record and port pages state the final behaviour

ADR-0057 says what is realized and states the stale-witness signal per language. The port pages, the changelog, the ledger spec and the corpus README are corrected where a review found them wrong or silent: the owned Program.cs advice for C#, the Python refusal of a project package under a standard-library name, how hooks and providers are imported, the Kotlin generator count, which loaders refuse a non-integer level, bare-name binding, and what verify does with metadata that does not load.

Refs docs/superpowers/plans/2026-10-05-requirements-slice-1-checks-and-test-generators.md and ADR-0057.

Author: dmealing

CHANGELOG.md

@@ -57,6 +57,13 @@ it until 1.1 ships._
   already errors in `meta verify`; the other ports loaded the same ledger and said nothing.
   The seven requirement authoring-lint advisories stay TypeScript-only. See
   [docs/features/requirements.md](docs/features/requirements.md), "The gate in every port".
+
+  Metadata that does not load is not a project with no requirement, and the gate fails on
+  it. **Python: `metaobjects verify <dir> --out <dir>` with no `--generators` now exits 1 on
+  metadata the loader refuses, where it exited 0**, because that invocation loads nothing
+  else; the gate's load is strict unless `--lax`, so an unknown attribute counts. `dotnet
+  meta verify` likewise prints the load errors itself when no gate in its own process loaded
+  the model (`--codegen` handed off to an owned `codegen/` project, or given no `--out`).
 - **`--require-implementers`, in every port.** `WARN_REQUIREMENT_NOTHING_IMPLEMENTS` (a
   `live` or `partial` functional requirement that nothing implements) stays a warning by
   default. `meta verify --require-implementers`, `metaobjects verify --require-implementers`,
@@ -305,6 +312,15 @@ until you regenerate.
 - **TypeScript: `requirementTests({ grain })` refuses an unknown grain.** Any value other
   than `"concern"` or `"member"` throws when the generator is built, whatever the model
   holds, instead of running as something in between. Every other port refuses the same way.
+- **Python: project code under a standard-library module name is refused where a
+  `module:symbol` names it.** Affected: a project whose owned generator (a `module:symbol`
+  entry in `generators`) or `requirementTests.renderer` / `requirementTests.filter` hook lives
+  under a top-level name such as `types`, `json`, `code` or `platform`, as a package directory
+  or as a `<name>.py` file. `gen` and `verify --codegen` now stop with `cannot import
+  '<module>': the project package '<name>' (<path>) shadows a standard-library module of the
+  same name; rename it` (`the project module` for a file). Before, an owned generator under
+  such a name loaded, by replacing the standard-library module for the rest of the process.
+  Rename the package or module, and the `module:symbol` that names it.
 
 - **TypeScript: `runValidators` rejects more than it did — a behaviour change for
   `ObjectManager` users.** `ObjectManager.create`, `createMany`, `update`, `updateMany` and

README.md

@@ -133,7 +133,7 @@ first-week wedge plan — and `meta init` picks up from there.
 |---|---|---|---|
 | TypeScript | **npm `1.0.13`** — the `@metaobjectsdev/*` packages | [`docs/ports/typescript.md`](docs/ports/typescript.md) | [`server/typescript/`](server/typescript/) · [`client/web/`](client/web/) |
 | Java | **Maven Central `8.0.13`** (`com.metaobjects:*` — the JVM major is npm major + 7) — loader + OMDB + render + Maven plugin all shipped; full conformance green | [`docs/ports/java.md`](docs/ports/java.md) | [`server/java/`](server/java/) |
-| Kotlin | **Maven Central `8.0.13`** — codegen tier on top of Java: 14 generators (entity, Exposed table, relations, repository, payload, output-parser, output-prompt, render-helper, extractor, filter-allowlist, validator, Spring config, storedProc, Spring controller); 24 / 24 persistence-conformance | [`docs/ports/kotlin.md`](docs/ports/kotlin.md) | [`server/java/codegen-kotlin/`](server/java/codegen-kotlin/) · [`server/java/metadata-ktx/`](server/java/metadata-ktx/) |
+| Kotlin | **Maven Central `8.0.13`** — codegen tier on top of Java: 15 generators (entity, Exposed table, names, relations, repository, output-parser, output-prompt, render-helper, extractor, filter-allowlist, validator, Spring config, storedProc, Spring controller, requirement-tests); 24 / 24 persistence-conformance | [`docs/ports/kotlin.md`](docs/ports/kotlin.md) | [`server/java/codegen-kotlin/`](server/java/codegen-kotlin/) · [`server/java/metadata-ktx/`](server/java/metadata-ktx/) |
 | C# | **NuGet `1.0.13`** — loader + conformance + EF Core codegen + render engine + `dotnet meta` CLI all shipped | [`docs/ports/csharp.md`](docs/ports/csharp.md) | [`server/csharp/`](server/csharp/) |
 | Python | **PyPI `1.0.13`** — loader + conformance + render + entity-model codegen + ObjectManager runtime shipped; schema migrations are TS-owned (ADR-0015) | [`docs/ports/python.md`](docs/ports/python.md) | [`server/python/`](server/python/) |
 

docs/features/cli.md

@@ -340,9 +340,12 @@ by the other port's docs command.
 
 Alongside its flag-only mode (`metaobjects gen <metadata_dir> --out <dir>`), the
 Python `metaobjects` CLI supports a declarative project config,
-`metaobjects.config.yaml` (#267). The **schema keys are identical to the TS
-`metaobjects.config.ts` vocabulary** — a polyglot adopter learns one
-targets-registry shape regardless of port. A JSON Schema ships at
+`metaobjects.config.yaml` (#267). Its **`targets` registry uses the TS
+`metaobjects.config.ts` vocabulary** (named targets, each with its own `outDir`) — a
+polyglot adopter learns one targets-registry shape regardless of port. The keys are not
+identical beyond that: a Python target carries its own `generators` and `entities`, and
+`requirementTests` is a block that exists only here, where TypeScript passes that
+generator's options to `requirementTests({ … })` in code. A JSON Schema ships at
 [`server/python/src/metaobjects/codegen/metaobjects-config.schema.json`](../../server/python/src/metaobjects/codegen/metaobjects-config.schema.json)
 for editor autocomplete and non-Python validation.
 
@@ -351,6 +354,12 @@ metadata: metaobjects            # optional, default "metaobjects" — relative
 providers:                       # optional; "module:symbol" refs, resolved config-relative (no PYTHONPATH=)
   - my_project.providers:register_custom_types
 libraries: [ai]                  # optional; MetaObjects-shipped library packages (see below)
+requirementTests:                # optional; options of the `requirement-tests` generator, every key optional
+  witnessModule: tests.requirement_witnesses   # the default
+  grain: concern                 # or: member
+  filter: codegen.requirement_hooks:include    # "module:symbol", resolved config-relative
+  renderer: codegen.requirement_hooks:render   # "module:symbol", resolved config-relative
+  warnUncovered: true            # the default
 targets:
   api:
     outDir: src/generated/api

docs/features/requirements.md

@@ -358,7 +358,7 @@ the summary at `info`, warnings as warnings and errors as errors.
 |---|---|---|
 | `ERR_REQUIREMENT_BAD_LEVEL` | error | The level is outside 1 to 5, on a functional requirement or a levelled architectural one. |
 | `ERR_REQUIREMENT_LEVEL_NESTING` | error | A levelled requirement sits at or above the level of the requirement it is nested under. |
-| `ERR_REQUIREMENT_LINK_ABOVE_FLOOR` | error | `@implementedBy` on a levelled requirement at L1 to L3. Nothing else is reported for that node. |
+| `ERR_REQUIREMENT_LINK_ABOVE_FLOOR` | error | `@implementedBy` on a levelled requirement at L1 to L3. Nothing further is reported for that node: the checks below this row are skipped, and the two above it have already run. |
 | `ERR_REQUIREMENT_L4_NOT_OBJECT` | error | A functional L4 names a member. |
 | `ERR_REQUIREMENT_L5_NOT_MEMBER` | error | A functional L5 names an object. |
 | `ERR_REQUIREMENT_DANGLING_REF` | error | An `@implementedBy` reference does not resolve on `live` or `partial`, or `@supersededBy` does not name a requirement in the ledger. |
@@ -396,15 +396,22 @@ diagnostics, and when any is an error, `<prefix> <n> error(s).` and a non-zero e
 TypeScript caps the warnings it prints at `--limit` (20 by default); the other ports print
 every one. The structured `--format json|toon` payload is TypeScript-only.
 
+**Metadata that does not load** is not a model with no requirement: `verify` fails on it in
+every port. The load errors are printed once. Where the drift gate that ran loaded the model,
+that gate prints them; where none did (`metaobjects verify` with no generators selected,
+`dotnet meta verify --codegen` handed off to an owned `codegen/` project), the requirement
+gate prints them itself. Its load is strict unless `--lax`, as the drift gates' is.
+
 ### Known differences between ports
 
 - The package a requirement is taken to be in can differ between ports for two multi-file
   shapes: a root document with no package loaded beside packaged ones, and a child merged
   from a package-less document into a requirement that declares its own package.
 - Python applies only the dependency-import rule to decide which of a project's own
   entities are counted; TypeScript also applies the project's `scope` patterns.
-- A `level` that is not an integer is refused by some loaders and reaches the gate in
-  TypeScript.
+- A `level` that is not an integer (`4.5`) is refused at load by the Python, Java and C#
+  loaders (`ERR_BAD_ATTR_VALUE`). The TypeScript loader lets it through, and the gate reports
+  it as `ERR_REQUIREMENT_BAD_LEVEL`.
 
 ## Requiring implementers
 

docs/ports/csharp.md

@@ -479,7 +479,11 @@ return CodegenCli.Run(args, generators);
 The example is the file as it stands after `dotnet meta eject requirement-tests`: the class
 is your owned copy, in `Codegen.Generators`. If `Program.cs` exists because you ejected
 something else and you are constructing the packaged generator, the class is in
-`MetaObjects.Codegen.Generators`, so add `using MetaObjects.Codegen.Generators;`.
+`MetaObjects.Codegen.Generators`: write it fully qualified, as
+`new MetaObjects.Codegen.Generators.RequirementTestsGenerator { … }`. Do not add
+`using MetaObjects.Codegen.Generators;`, because every generator you ejected has a packaged
+class of the same simple name there, and the second `using` makes each `new <Name>Generator()`
+already in the file ambiguous (CS0104).
 
 | Property | Meaning |
 |---|---|

docs/ports/python.md

@@ -391,7 +391,9 @@ them on every run: it prints the ledger summary, and an error (a dangling refere
 live requirement, a link above the floor, a live policy applied to nothing) exits non-zero.
 `--require-implementers` (or `META_REQUIRE_IMPLEMENTERS=1`) also fails the run on a live
 functional requirement that nothing implements. Those checks are core and are not
-ejectable. A model with no requirement sees no change.
+ejectable. A model with no requirement sees no change. Metadata that does not load is not
+that: `verify` prints the load errors and exits non-zero, also when no generators are
+selected and so no drift gate loaded it.
 
 The `requirement-tests` generator is the other half. It is a reference helper and a
 recommended approach, not a contract: `metaobjects eject requirement-tests` copies it, with
@@ -407,7 +409,7 @@ targets:
 requirementTests:                               # every key optional
   witnessModule: tests.requirement_witnesses    # the default
   grain: concern                                # or: member
-  filter: codegen.requirement_hooks:include     # module:symbol, resolved like `providers`
+  filter: codegen.requirement_hooks:include     # module:symbol, relative to this file's directory
   renderer: codegen.requirement_hooks:render    # module:symbol
   warnUncovered: true                           # the default
 ```
@@ -440,10 +442,15 @@ or deleted is simply never called again: nothing reports it, and you delete it b
 The block is read in config mode. The flag-only form
 (`metaobjects gen ./metaobjects --out ./tests/generated --generators requirement-tests`)
 runs the generator with its defaults. A `filter` or `renderer` whose module raises on
-import is reported with the real cause. `metaobjects verify` goes out of sync when a claim
-changes, because each test carries a digest of its requirement. A package that loses its
-last requirement leaves its file behind: `gen` does not remove it, `verify` lists it as
-`extra:`, and you delete it. The model and the other ports' spelling are in
+import is reported with the real cause. Both hooks, like a `providers` entry, are found
+relative to the config file's directory, with no `PYTHONPATH=`. They differ in how they are
+imported: a provider is imported with plain `importlib`, and a hook goes through the resolver
+an owned generator is imported with, which loads the project's own copy of a module when
+another copy is already cached and refuses a project package or module whose top-level name
+is a standard-library module name (`types`, `json`): rename it. `metaobjects verify` goes
+out of sync when a claim changes, because each test carries a digest of its requirement. A
+package that loses its last requirement leaves its file behind: `gen` does not remove it,
+`verify` lists it as `extra:`, and you delete it. The model and the other ports' spelling are in
 [Generated requirement tests and witnesses](../features/requirements.md#generated-requirement-tests-and-witnesses).
 
 ### Declarative template-codegen (`--template-spec`)
@@ -645,7 +652,9 @@ each as `<Name>.py`. So the prompt+parse story is two generators:
 
 **Own a generator.** Every generator is a reference helper you can copy and change:
 `metaobjects eject <name>` copies it into `codegen/generators/`, and you wire the copy as
-`module:symbol` in place of its name. See
+`module:symbol` in place of its name. A project package or module whose top-level name is a
+standard-library module name (`types`, `json`) is refused there with an error naming it:
+rename it. See
 [Own your codegen → Python](../features/own-your-codegen.md#python-metaobjects-eject).
 
 Ejecting `routes` also hands over the helper runtime the generated routers call:

fixtures/requirement-check-conformance/README.md

@@ -62,8 +62,9 @@ it is wrong, unless the reference is shown to be wrong first.
   requirement that is not `planned`, whatever its level and whatever the gate says about
   the reference's grain. `link-above-floor`, `l4-names-member`, `l5-names-object` and
   `arch-levelled-tree` each report an error on a claim and no unclaimed entity.
-- **`ERR_REQUIREMENT_LINK_ABOVE_FLOOR` ends that requirement's checks.** Nothing else is
-  reported for the node (`link-above-floor`).
+- **`ERR_REQUIREMENT_LINK_ABOVE_FLOOR` ends that requirement's checks.** Nothing further is
+  reported for the node (`link-above-floor`): the level and nesting checks run before it, so
+  a node can carry those as well.
 - **A grain error replaces the dangling check for that reference.** `l4-names-member` and
   `l5-names-object` each hold a reference that does not resolve and report it once.
 - **Existence is about naming, not resolving.** A requirement whose subtree holds any

spec/capability-ledger.md

@@ -233,9 +233,11 @@ supersession chain stays walkable.
 ### `implementedBy` resolution, severity conditional on status
 
 References resolve against the loaded model through the loader's own resolver, so the
-package-local contract (ADR-0042) applies uniformly. A ledger entry has no package of its
-own, so a **bare** name binds only a root-level object: fail-closed, and a bare name that
-exists in two packages resolves to nothing rather than to a coin flip.
+package-local contract (ADR-0042) applies uniformly. A **bare** name binds in the ledger
+entry's own package first (the package the loader resolved for it: its own, or its file's),
+then to an unpackaged root-level node of that name. It never reaches into another package:
+fail-closed, and a bare name that exists in two other packages resolves to nothing rather
+than to a coin flip.
 
 | status | dangling reference |
 |---|---|

spec/decisions/ADR-0057-requirement-checks-and-tests-in-every-port.md

@@ -23,9 +23,10 @@ TypeScript only:
 - **The test scaffold.** `requirementTests()` emits one test stub per claim, which the project
   fills in by hand and the three-way merge preserves.
 
-The split was a decision, and the only place it was recorded as one is `docs/CONFORMANCE.md`,
-"Split coverage" (`docs/features/requirements.md` and the pillar summaries stated the split
-without the reasoning):
+The split was a decision, recorded as one in two places: `docs/CONFORMANCE.md`, "Split
+coverage", quoted below, and `spec/capability-ledger.md`, in a section titled "The verify gate
+is TypeScript-only, on purpose" (`docs/features/requirements.md` and the pillar summaries stated
+the split without the reasoning):
 
 > *Checks — TypeScript only, by decision.* The `meta verify` diagnostics over requirements ship
 > in the TypeScript CLI; the other ports load and validate and stop there. Same call as ADR-0015:
@@ -113,8 +114,11 @@ them is open.
     member per test that is not skipped and a failing default for each. The project names one
     class that implements it. There is no run-time lookup by name (ADR-0001). A requirement that
     becomes live adds a failing default, which is a red test and not a compile break. A
-    requirement that is retired or deleted removes its member, so a stale override stops
-    compiling.
+    requirement that is retired or deleted removes its member. Whether a witness left behind
+    then stops compiling depends on the language: always in Kotlin, where `override` is
+    mandatory; in Java only when the witness method carries `@Override`; in C# only when the
+    witness implements the member explicitly. A witness written in the other form goes stale
+    silently, and each generated header names the form that does not.
 14. **A Python generated test looks its witness up by name** in a configured module. Python has
     no static binding to offer, and this is test code, so it is the one by-name lookup in the
     design.
@@ -162,11 +166,16 @@ them is open.
 
 ## Realization status
 
-At acceptance, TypeScript has the gate, the generator and (with this ADR) the strict switch. The
-two corpora and the Python, Java, C# and Kotlin implementations land in the order the plan
-gives. `docs/CONFORMANCE.md`, `docs/features/requirements.md` and the pillar summaries still
-state the TypeScript-only split until the ports that make it false have landed; they are
-corrected with them, not ahead of them.
+Realized by the change this ADR was accepted with. All five ports run the gate in their
+`verify` and ship a `requirement-tests` generator, ejectable through each port's own mechanism.
+Both corpora are asserted by every port; Kotlin has no CLI of its own and takes the gate and the
+identity function from Java, with its emitted names asserted by its own generator test.
+`docs/CONFORMANCE.md`, `docs/features/requirements.md`, `spec/capability-ledger.md` and the
+pillar summaries were corrected in the same change and no longer state the TypeScript-only
+split.
+
+Two things remain TypeScript-only: the seven authoring-lint advisories (Consequences), and the
+structured `--format` payload of `verify`.
 
 ## Alternatives considered
 
@@ -178,7 +187,9 @@ corrected with them, not ahead of them.
   Object coverage already works the other way, with one code and a named severity constant.
 - **A run-time lookup by name for JVM and .NET witnesses, as Python does.** Rejected: it is
   runtime reflection (ADR-0001), and a witness for a deleted requirement would go on existing
-  unnoticed. The interface makes that a compile error.
+  unnoticed. The interface makes that a compile error in Kotlin always, in Java when the
+  witness method carries `@Override`, and in C# when the witness implements the member
+  explicitly (clause 13).
 - **Port the three-way merge to four more languages.** Rejected: none of those ports has one,
   and the witness model keeps hand-written code out of the generated file altogether.
 - **Emit JUnit 4 as well as Jupiter.** Rejected: the renderer hook and eject already cover a