no-mistakes(document): Docs now say C# consumes shared models (FR-023 S6); stale "C# doesn't read dependencies" claims fixed in README, cli, metadata-sources, metadata-dependencies, spec/roadmap, and the agent-context codegen reference plus its five mirrored fixture copies.

Author: dmealing

README.md

@@ -276,8 +276,8 @@ sixth ships two libraries at their own stability labels:
    `meta eject <library>`. See [`docs/features/libraries.md`](docs/features/libraries.md).
 
 **Sharing a model across your own projects** *(the TypeScript toolchain publishes;
-TypeScript, Python, Java and Kotlin projects consume, from an installed npm or Python
-package or over a `path` dependency such as a sibling checkout; C# arrives in Phase 2)* — one project publishes
+TypeScript, Python, Java, Kotlin and C# projects consume, from an installed npm or Python
+package or over a `path` dependency such as a sibling checkout)* — one project publishes
 part of its model (a common `Customer`, an audited base, a set of enums) with
 `sharedModelFile()`, and another declares it in `dependencies`, syncs it into a
 committed, hash-locked snapshot and builds on it with `extends` and references. When the

agent-context/skills/metaobjects-codegen/references/dependencies-and-shared-models.md

@@ -44,8 +44,7 @@ as package data), run `meta gen`, then release the package as usual; consumers
 declare an `npm` or `python` dependency on it. With no `version` option the
 manifest takes the nearest `package.json` version, else a `pyproject.toml`
 `[project]` version — pass `version` when neither is the package consumers install.
-Only TypeScript can run it in Phase 1a. TypeScript, Python, Java and
-Kotlin (through Java's loader and Maven plugin) can *consume* a dependency, and
-only the TypeScript toolchain can *publish* one; C# does not read
-`dependencies` yet (Phase 2).
+Only TypeScript can run it in Phase 1a. TypeScript, Python, Java, Kotlin (through
+Java's loader and Maven plugin) and C# can *consume* a dependency, and only the
+TypeScript toolchain can *publish* one.
 Full detail: `docs/features/metadata-dependencies.md`.

docs/features/cli.md

@@ -33,7 +33,7 @@ command surface splits in two:
 | **Template/prompt drift** (`verify --templates`) | **Node `meta`** | `meta verify --templates` | TS reference (ADR-0021 D2) — `{{field}}`↔payload; part of the bare-`verify` default |
 | **Vocabulary upgrade** (`upgrade`) | **Node `meta`** | `meta upgrade [--to <version>] [--apply]` | **any backend** — rewrites RETIRED metadata vocabulary (`@violation` → `@counterexample`, `@readOnly` → `@mutability`, dropping `@verifiedBy`) and resolves ATTRIBUTE CONTRADICTIONS (`@fields` beside `@expr` on an index key). Node-only because it edits the metadata documents themselves, which every port shares; a non-TS project runs `npx meta upgrade` against its own `metaobjects/`. **Canonical JSON and YAML alike.** Previews by default. Retirements needing a human decision are refused and the run exits non-zero, so CI cannot record a partial migration as finished |
 | **Vocabulary search** (`types`) | **Node `meta`** | `meta types [query]` | **any backend** — apropos/`kubectl explain` over the live metamodel registry (names + descriptions + when-to-use); the vocabulary is cross-port identical (registry-conformance) |
-| **Dependency sync** (`deps`) | **Node `meta`** | `meta deps sync \| check \| list` | **any backend** — resolves a declared metadata dependency (`path`, or an installed `npm` / `python` package) into a committed snapshot + lock (FR-023), so `sync`/`check`/`list` themselves stay Node-only regardless of your server language. TypeScript, Python and Java then LOAD that snapshot at every rung of their own source ladder (Kotlin loads through Java's loader and Maven plugin); C# doesn't read `dependencies` yet (Phase 2). On a project whose own metadata Node `meta` cannot read (a Maven `src/main/resources/metadata` directory, a C# metadata directory, or another port's vocabulary), `sync` and `check` prove the locked dependencies load together and say that the port's own `verify` is the full check. See [`metadata-dependencies.md`](metadata-dependencies.md) |
+| **Dependency sync** (`deps`) | **Node `meta`** | `meta deps sync \| check \| list` | **any backend** — resolves a declared metadata dependency (`path`, or an installed `npm` / `python` package) into a committed snapshot + lock (FR-023), so `sync`/`check`/`list` themselves stay Node-only regardless of your server language. TypeScript, Python and Java then LOAD that snapshot at every rung of their own source ladder (Kotlin loads through Java's loader and Maven plugin); C# loads the snapshot through `dotnet meta` (Phase 2 S6). On a project whose own metadata Node `meta` cannot read (a Maven `src/main/resources/metadata` directory, a C# metadata directory, or another port's vocabulary), `sync` and `check` prove the locked dependencies load together and say that the port's own `verify` is the full check. See [`metadata-dependencies.md`](metadata-dependencies.md) |
 | **Canonical format** (`fmt`) | every port | `meta fmt` / `dotnet meta fmt` / `mvn metaobjects:fmt` / `metaobjects fmt` | (#304) ships in **every** port — the canonical serializer already exists in all five, so formatting is local, not Node-only. `--check` lists non-canonical files and exits non-zero without changing anything. Formats each file STANDALONE — own-mode, declared-here layer only (ADR-0039); an `extends` onto another file's base is preserved as-is, never resolved or erred on; a file declaring `overlay: true` anywhere — whether or not a same-file base exists — is reported as skipped rather than merged (merging would drop the overlay marker, a structural change fmt never makes). A YAML file is always skipped — no canonical YAML emitter exists (ADR-0006). Before writing, every port reloads the whole project with the candidate swapped in and refuses the write unless the reloaded model's canonical form is byte-identical to the untouched baseline — fmt never changes meaning. See [Fixture corpus](#meta-fmt--canonical-formatting-304) below and `fixtures/fmt-conformance/README.md` |
 | TS codegen | Node `meta` | `meta gen` | TS projects. **No `--template-spec` flag, deliberately** — `metaobjects.config.ts` already takes generator VALUES, so a declarative template generator is declared there (`templateGenerator()`, or `templateSpecToGenerators(parseTemplateSpec(spec))` to reuse a C#/Python spec file). Keeping it in the config is what lets `meta verify --codegen` regenerate WITH it, since that gate re-runs the config's generator list; see [declarative template scopes](codegen-concepts.md#declarative-template-scopes) |
 | C# codegen | `dotnet meta` | `dotnet meta init` / `gen` / `verify --templates` / `verify --codegen` | a .NET tool (`ToolCommandName=dotnet-meta`); invoked `dotnet meta` so it never shadows the Node `meta`; ships the ADR-0021 D2 subverbs (`--db` rejected, exit 2; bare `verify` = `--templates` plus `--codegen` when an output directory (`csharp.outDir` in `.metaobjects/config.json`, or `--out`) and `codegen/Generators.cs` are present). **The generator list is `codegen/Generators.cs`** (ADR-0034 Amendment 9): `dotnet meta init` writes it with `codegen/Program.cs` (two lines that run it) and `codegen/Codegen.csproj`, and `gen` / `verify --codegen` always run it through `dotnet run --project codegen`. With no `codegen/Generators.cs` they exit 2 and write nothing; `--generators` only narrows the list to declared entries. Every entry may set its own output directory (`ApiDocsGenerator { OutDir = ... }`), and `verify --codegen` compares each one. A declarative Mustache template-spec (the cross-port JSON contract shared with Python) is one more entry, `TemplateSpecGenerator { Spec = "<json>", TemplateRoot = "<dir>" }`; `gen` no longer reads `--template-spec` or a project-root `template-spec.json`, and a run that finds either with no such entry fails before writing anything; see [declarative template scopes](codegen-concepts.md#declarative-template-scopes). `dotnet meta docs` was removed in 1.1.0: it prints the line that points at [the migration section](migrations/docs-are-generators.md#c) and exits 2 |

docs/features/metadata-dependencies.md

@@ -631,7 +631,7 @@ Tracked in [#482](https://github.com/metaobjectsdev/metaobjects/issues/482). Tod
 Python, Java, Kotlin and C# consume a dependency (Java and Kotlin shipped in slice S3, C# in S6).
 A port that does not read the lock fails loudly on a model that references a node a dependency
 would supply (`ERR_UNRESOLVED_OBJECT_REF`), never silently. Phase 2 adds no new contract. The manifest, the
-lock, the committed snapshot and the 24-case resolution corpus are plain files that every port
+lock, the committed snapshot and the 26-case resolution corpus are plain files that every port
 already has the pieces to read; what is missing is each port *loading* the snapshot.
 
 Two rulings shape it:

docs/features/metadata-sources.md

@@ -57,9 +57,9 @@ sources.** It answers a different question than the ladder above — not "where
 my metadata live" but "what does my metadata build on that lives elsewhere" — so a
 TypeScript project using a declared `sources` list and a Python project using its
 own `metadata:` key both get their declared dependencies resolved the same way, on
-top of whichever rung supplied their own files. **TypeScript, Python, Java and Kotlin**
-(Kotlin through Java's loader and Maven plugin) — C# doesn't read `dependencies` yet
-(Phase 2). See
+top of whichever rung supplied their own files. **TypeScript, Python, Java, Kotlin and C#**
+(Kotlin through Java's loader and Maven plugin) — each reads `dependencies` at every rung
+of its own source ladder. See
 [`metadata-dependencies.md`](metadata-dependencies.md).
 
 A config file that exists but is malformed is an error at its own rung; it never

fixtures/agent-context-conformance/java-kotlin-react-tanstack/expected/.claude/skills/metaobjects-codegen/references/dependencies-and-shared-models.md

@@ -44,8 +44,7 @@ as package data), run `meta gen`, then release the package as usual; consumers
 declare an `npm` or `python` dependency on it. With no `version` option the
 manifest takes the nearest `package.json` version, else a `pyproject.toml`
 `[project]` version — pass `version` when neither is the package consumers install.
-Only TypeScript can run it in Phase 1a. TypeScript, Python, Java and
-Kotlin (through Java's loader and Maven plugin) can *consume* a dependency, and
-only the TypeScript toolchain can *publish* one; C# does not read
-`dependencies` yet (Phase 2).
+Only TypeScript can run it in Phase 1a. TypeScript, Python, Java, Kotlin (through
+Java's loader and Maven plugin) and C# can *consume* a dependency, and only the
+TypeScript toolchain can *publish* one.
 Full detail: `docs/features/metadata-dependencies.md`.

fixtures/agent-context-conformance/java-react/expected/.claude/skills/metaobjects-codegen/references/dependencies-and-shared-models.md

@@ -44,8 +44,7 @@ as package data), run `meta gen`, then release the package as usual; consumers
 declare an `npm` or `python` dependency on it. With no `version` option the
 manifest takes the nearest `package.json` version, else a `pyproject.toml`
 `[project]` version — pass `version` when neither is the package consumers install.
-Only TypeScript can run it in Phase 1a. TypeScript, Python, Java and
-Kotlin (through Java's loader and Maven plugin) can *consume* a dependency, and
-only the TypeScript toolchain can *publish* one; C# does not read
-`dependencies` yet (Phase 2).
+Only TypeScript can run it in Phase 1a. TypeScript, Python, Java, Kotlin (through
+Java's loader and Maven plugin) and C# can *consume* a dependency, and only the
+TypeScript toolchain can *publish* one.
 Full detail: `docs/features/metadata-dependencies.md`.

fixtures/agent-context-conformance/python/expected/.claude/skills/metaobjects-codegen/references/dependencies-and-shared-models.md

@@ -44,8 +44,7 @@ as package data), run `meta gen`, then release the package as usual; consumers
 declare an `npm` or `python` dependency on it. With no `version` option the
 manifest takes the nearest `package.json` version, else a `pyproject.toml`
 `[project]` version — pass `version` when neither is the package consumers install.
-Only TypeScript can run it in Phase 1a. TypeScript, Python, Java and
-Kotlin (through Java's loader and Maven plugin) can *consume* a dependency, and
-only the TypeScript toolchain can *publish* one; C# does not read
-`dependencies` yet (Phase 2).
+Only TypeScript can run it in Phase 1a. TypeScript, Python, Java, Kotlin (through
+Java's loader and Maven plugin) and C# can *consume* a dependency, and only the
+TypeScript toolchain can *publish* one.
 Full detail: `docs/features/metadata-dependencies.md`.

fixtures/agent-context-conformance/ts-react-tanstack/expected/.claude/skills/metaobjects-codegen/references/dependencies-and-shared-models.md

@@ -44,8 +44,7 @@ as package data), run `meta gen`, then release the package as usual; consumers
 declare an `npm` or `python` dependency on it. With no `version` option the
 manifest takes the nearest `package.json` version, else a `pyproject.toml`
 `[project]` version — pass `version` when neither is the package consumers install.
-Only TypeScript can run it in Phase 1a. TypeScript, Python, Java and
-Kotlin (through Java's loader and Maven plugin) can *consume* a dependency, and
-only the TypeScript toolchain can *publish* one; C# does not read
-`dependencies` yet (Phase 2).
+Only TypeScript can run it in Phase 1a. TypeScript, Python, Java, Kotlin (through
+Java's loader and Maven plugin) and C# can *consume* a dependency, and only the
+TypeScript toolchain can *publish* one.
 Full detail: `docs/features/metadata-dependencies.md`.

fixtures/agent-context-conformance/ts-requirements/expected/.claude/skills/metaobjects-codegen/references/dependencies-and-shared-models.md

@@ -44,8 +44,7 @@ as package data), run `meta gen`, then release the package as usual; consumers
 declare an `npm` or `python` dependency on it. With no `version` option the
 manifest takes the nearest `package.json` version, else a `pyproject.toml`
 `[project]` version — pass `version` when neither is the package consumers install.
-Only TypeScript can run it in Phase 1a. TypeScript, Python, Java and
-Kotlin (through Java's loader and Maven plugin) can *consume* a dependency, and
-only the TypeScript toolchain can *publish* one; C# does not read
-`dependencies` yet (Phase 2).
+Only TypeScript can run it in Phase 1a. TypeScript, Python, Java, Kotlin (through
+Java's loader and Maven plugin) and C# can *consume* a dependency, and only the
+TypeScript toolchain can *publish* one.
 Full detail: `docs/features/metadata-dependencies.md`.